400 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Kristian WindandClaude Opus 5	8d5dd1f1c3	fix(notes): grupperne stod tomme — hver liste rullede for sig ... Meldt ind som "noter vises ikke i den nye listeform": hver eneste overskrift stod der med sit tal, og der var ikke en eneste note under nogen af dem. Før var der ét `<ul>`, og *det* rullede. Da listen blev delt i grupper, blev hver gruppe sit eget `<ul>` — og dermed sit eget flex-element med `overflow-y: auto`. Flex-elementer skrumper som udgangspunkt, og et element, der skrumper og klipper, viser ingenting. Med tyve måneder i søjlen fik hver liste nul at være høj i. Rulningen hører til kassen om dem alle, ikke til hver af dem. **Prøven fangede det ikke, og det er værd at forstå hvorfor.** Den lavede to noter, altså tre grupper, i et vindue på 720 pixels — og med så få grupper er der plads nok til, at skrumpningen ikke bider. Fejlen kræver pres. Prøven gør vinduet lavt nu og kigger efter, at rækkerne kan *ses* og ikke bare findes, og den siger desuden hvor rulningen ligger: på kassen, ikke på listerne. Den er set fejle med den gamle stil. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.40.1	2026-08-21 13:00:15 +02:00
Kristian WindandClaude Opus 5	c8d67dd07d	feat(notes): notekroppe forsegles, og søgningen åbner dem selv ... Grunden er den samme som for postkassers kodeord og OAuth-tokens: en sikkerhedskopi kan hentes gennem fladen, og indtil nu bar hver eneste af dem hver eneste note i klartekst. Noter er dér, folk skriver kodeord og API-nøgler ned — det ved vi, fordi der ligger sådan nogle i den installation, det her blev bygget til. **Både titel og krop.** Titlen *er* første linje, så en forseglet krop ved siden af en læselig titel ville efterlade begyndelsen af hver eneste note i klartekst. **Og de to kopier gik med.** Det var derfor det ikke var gjort for længe siden: `notes_fts` indekserede kroppen, og den genererede `fold`-søjle bar en translittereret kopi af den. At forsegle kroppen og lade dem stå ville have været teater — en angriber med filen kunne læse hver note ud af indekset. Begge er væk, og tabellen er bygget om, fordi SQLite ikke kan fjerne en genereret søjle på plads. **Søgningen åbner teksten i Go.** Målt frem for gættet: tolv hundrede noter à 3,3 kB koster 33–43 ms pr. søgning, og fladen venter 250 ms efter sidste tastetryk, før den spørger — så det ligger inde i pausen. Tiden går ikke med at åbne konvolutterne; fire megabyte AES-GCM er få millisekunder. Den går med at folde og småskrive hver krop, og det er lineært: regn med omtrent 350 ms ved ti tusind noter. Dér er det den forkerte form, og svaret er da et nøglet indeks — hvis pris er, at præfiks- og delordssøgningen falder bort. bm25 forsvandt med indekset. Det, der er beholdt, er den halvdel, der betød mest: titlen vejer ti gange kroppen. Med et loft pr. ord, så en note, der nævner ordet fyrre gange, ikke slår en, der nævner alle ordene én gang — det er den fejl, en ren optælling laver, og den er let at lave og svær at få øje på. **En bagudfyldning ved opstart, ikke efterhånden.** Instansens indstillinger forsegles, når de skrives, og det er rigtigt for dem. For et arkiv på tolv hundrede importerede noter, som ingen redigerer igen, betyder "når de skrives" aldrig — og det er præcis dét arkiv, der er værd at forsegle. Idempotent, så den koster et gennemløb af id'er hver anden gang, og `updated_at` røres ikke: at lukke en konvolut om en note er ikke at skrive den, og et stempel med i aften ville kaste den rækkefølge væk, importen brugte en dag på at hente hjem. En fejl under bagudfyldningen stopper opstarten. Halvdelen af noterne lukket er ikke i stykker — `v1:`-præfikset gør, at begge slags kan læses — men en instans, der starter og lader som om den beskytter noget, den ikke gør, er værre end en, der siger fra. Hvad der stadig ligger åbent, står i SECURITY.md og på dokumentationssiden: opgavetitler, beskrivelser, kommentarer, og `note_links`, som røber hvilke projekter og opgaver en note peger på, men ikke hvad der står. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.40.0	2026-08-20 22:40:55 +02:00
Kristian WindandClaude Opus 5	23bd784b07	docs: SECURITY.md sagde noget, dagen havde gjort forkert ... "Ingen ratebegrænsning ud over login og nulstilling" var sandt i morges. Det er det ikke længere: andenfaktoren, beaconet og indgående post har fået deres eget loft i løbet af dagen — det sidste tilføjede jeg selv og skrev ikke det her. En SECURITY.md, der siger noget forkert, er værre end de fleste fejl. Den er netop den fil, nogen læser for at afgøre, om de tør køre det her, og hvert eneste punkt i den er en påstand, de ikke selv kan efterprøve uden at læse koden. Samme sted mangler den største åbne ting: notekroppe, opgavetitler, beskrivelser og kommentarer er ikke krypteret. Forseglingen dækker legitimation — postkassers kodeord, OAuth-tokens, andenfaktorens hemmelighed, AI-nøgler — og intet andet. En note med et kodeord i har det i klartekst i hver sikkerhedskopi, man kan hente. Det stod i overleveringen og på dokumentationssiden for noter, og det hørte hjemme her. README's "ikke færdigt"-liste havde Gmail med. Den kører i produktion, inklusive flagningen og dubletbehandlingen, der tog en dag at få rigtig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:16:52 +02:00
Kristian WindandClaude Opus 5	264f48ae11	fix(quickadd): "hver anden tirsdag" blev til en dato og to ord i titlen ... Vendingen er den, folk bruger, og recurrence-pakken har kunnet den siden den blev skrevet — den oversætter "hver anden" til "hver 2." netop for at slippe for at skrive hvert eneste mønster i to udgaver. Sætningen nåede bare aldrig frem til den. Mønsteret i hurtig tilføjelse tog et tal efter "hver", men ikke et ord, så det, der blev givet videre, var "hver anden". Det er ikke en regel. Så blev de to ord stående i titlen, "tirsdag" blev læst som en forfaldsdato, og opgaven gentog sig ikke — uden at noget sagde det. Sløjfen, der prøver sig frem, kunne ikke redde den: den fjerner ord fra enden, én ad gangen, og kan ikke hente et ord, mønsteret aldrig tog med. Fundet af en prøve, jeg skrev til noget andet, hvor jeg brugte vendingen som en selvfølge og opdagede, at den ikke var det. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.39.1	2026-08-20 22:11:01 +02:00
Kristian WindandClaude Opus 5	2219f6af13	fix(i18n): en gentagelse siges nu på læserens sprog ... `recurrence.Describe` skriver dansk. Fladen kunne navngive de fem almindelige regler selv, og alt andet — "hver mandag", "hverdage", "hver anden uge tirsdag" — faldt tilbage til serverens tekst, som er dansk uanset hvad kontoen er sat til. Serveren kan ikke bare tage en locale med, og det er ikke dovenskab: `toTaskJSON` har niogtyve kaldesteder, og mange af dem er WebSocket-udsendelser, hvor én nyttelast når alle i et projekt på én gang. Der findes ikke ét sprog at skrive den i. Men reglen er den samme, uanset hvem der læser den. Den ligger allerede i nyttelasten, så beskrivelsen hører hjemme dér, hvor læseren er — i fladen. Serverens tekst bliver stående som reserve. Den er stadig den, et API-kald og en MCP-forbindelse får, og de har ingen flade at oversætte i. Ugedagen kommer fra `Intl` og ikke fra en tabel — ikke for at spare syv strenge pr. sprog, men for at få de navne, sproget faktisk bruger. Dagene sorteres, som ugen går, frem for som reglen tilfældigvis skrev dem: "mandag og torsdag" og "torsdag og mandag" er den samme regel, og den ene af dem er den, folk siger. Og to har sit eget ord på begge sprog — "hver anden", "every other". Det er ikke tallet to sat ind i den samme sætning, så det er sin egen nøgle. Et sprog, der bøjer enheden efter tallet, kan ikke sættes sammen af stumper; derfor står tallet inde i teksten frem for at blive limet på. Prøven bruger `hver mandag` og `hverdage`, fordi de netop *ikke* står på listen over de fem, fladen altid har kunnet. En tredje vending, jeg først skrev prøven med — "hver anden tirsdag" — viste sig ikke at være en, hurtig tilføjelse overhovedet læser: den lagde "hver anden" i titlen og gjorde "tirsdag" til en dato. Det er en anden sag, og den står nu skrevet ét sted, hvor den kan tages op. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.39.0	2026-08-20 22:00:05 +02:00
Kristian WindandClaude Opus 5	f64b7c1f01	docs: Noter og Kalender havde ingen sider, mens forsiden lovede begge ... Landingssiden reklamerer for noter og for en kalender, og dokumentationen havde hverken en side om den ene eller den anden. Det hul blev skrevet ned i morges og er det her. **Noter** siger, hvad der er værd at vide, og hvad der ikke virker: at første linje *er* titlen og udledes ved hver gemning, at arkivet og papirkurven er to forskellige ting, at søgningen finder `grøn` når man skriver `gron` og `keepInventory` når man skriver `inventory` — og at notekroppe ligger i klartekst i hver sikkerhedskopi, man kan hente. Det sidste hører hjemme dér, hvor nogen står med en note og overvejer at skrive et kodeord i den. **Kalender** samler det, der før var spredt: gitteret, ugen som et døgn, træk der sætter et klokkeslæt, abonnementer på ICS og webcal, og Google-forbindelsen med det forbehold, den skal have — den er skrevet efter dokumentationen og har aldrig kørt mod Google. `caldav.md` er nu den anden retning alene: verdandes egne opgaver læst af noget andet. En ting, byggeriet lærte: `</>` i inline-kode vælter Pythons html-parser på 3.9 med "we should not get here!". CI kører 3.12 og er ligeglad, men en side, der ikke kan bygges lokalt, er en side ingen retter. Knappen er beskrevet med ord i stedet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 21:50:27 +02:00
Kristian WindandClaude Opus 5	868588de10	feat(projects): et projekts kalender kan vises som en uge ... Ugen fandtes på Kommende og på Kalender, men ikke dér hvor et projekt bor — og det er dér, "hvornår sker de her fire ting" oftest bliver spurgt. Inde i kalendervisningen frem for som en fjerde `view_mode`. `view_mode` er projektets og delt med alle, der kan se det, mens uge eller måned er et spørgsmål om hvor bred skærmen er, foran hvilken der sidder én person — samme grund som sidebjælkens bredde ligger i localStorage af. Og en fjerde værdi ville kræve en tabelombygning: `CHECK (view_mode IN ('list','board','calendar'))` kan SQLite ikke ændre på plads. **Og så fandt den en fejl, der har ligget og ventet.** `cursor` blev sat med `span === 'week' ? … : …`, hvilket læser `span` i det øjeblik komponenten bliver til og fanger den værdi for altid. Byggeriet har advaret om det lige så længe. Så længe hver visning havde sin egen komponent, gjorde det ingen forskel — og det gjorde det i samme sekund, en vælger begyndte at skifte `span` på den samme. Markøren stod på den 1. i måneden, og et skift til uge landede på ugen omkring den 1.: "27. jul.–2. aug." for en person, der kiggede på august. Rettet, med den ene undtagelse skrevet ned: en månedsvisnings markør *er* den første i måneden, så et skift til uge, mens man står i den indeværende måned, skal lande på den uge, i dag ligger i — ikke på ugen omkring den 1. Og en anden fælde, jeg selv gik i undervejs: en underklasses felter sættes *efter* basens konstruktør er kørt. Nøglen til localStorage som et felt på en underklasse betød, at valget blev gemt ét sted og læst et andet — en uge, man havde valgt, var en måned igen efter en genindlæsning. Nøglen er et argument nu; et argument har ingen rækkefølge at tage fejl af. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 21:45:38 +02:00
Kristian WindandClaude Opus 5	dcb71f4c14	feat(calendar): abonnement på flere kalendere, ICS og webcal ... Bedt om som "abonnering af flere kalendere (ics og webcal?)". Det er også den eneste vej for en privat konto: instansens OAuth-klient er Internal, og Google afviser en konto udefra med `org_internal`, uanset hvad der ellers er sat op. **Samme tabeller.** Et abonnement er én kalender med begivenheder i, og det er præcis det, `calendars` og `calendar_events` allerede beskriver — med vinduet, farven, `shown` og hele fejemaskinen omkring sig. En tabel til ville være en anden vej til det samme sted, og to veje til ét sted er to steder at rette den dag noget om begivenheder ændrer sig. Det, der skulle laves om, var identiteten. En OAuth-konto er én pr. person og udbyder — tokenet er identiteten — mens et abonnement er én pr. adresse, og man har flere. `calendar_accounts_once` er derfor delvist nu: det holder for rækkerne uden adresse, og et andet indeks holder adresserne unikke. Delvise indekser er den ene ting, SQLite kan her, som ellers krævede en tabelombygning. **`webcal://` skrives om til `https://`.** Det er ikke en protokol, noget taler — det er en konvention, der får et skrivebord til at give adressen til kalenderprogrammet i stedet for til browseren, og alle udgivere skriver deres links sådan. At afvise den ville være at afvise folk på en teknikalitet. **Adressen gennem `safedial`, begge halvdele.** Afvist hvor den skrives ned, så den, der står med feltet, får svaret med det samme — og igen på den *opslåede* adresse hver gang den hentes, fordi et navn, der blev godkendt ved indtastningen, kan svare 127.0.0.1, når fejemaskinen kører klokken tre om natten. Det er den sætning, `internal/safedial` selv står og advarer om, og den blev skrevet efter et SSRF-fund i morges. **Hentet én gang, før den gemmes.** En adresse, der ikke kan læses, er en tastefejl langt oftere end en server, der tilfældigvis er nede, og at sige det, mens nogen står med feltet, er de to sekunder værd. Et abonnement, der lydløst aldrig fyldes, er den samme tavshed, notifikationerne havde. Læseren er ny i `internal/ics`, som hidtil kun kunne skrive. To ting, den med vilje ikke gør, står skrevet ved den: den udfolder ikke gentagelser, og den opløser ikke tidszoner. Begge dele er større end de ser ud, og begge har ét sted at høre til den dag de skal. En ting, formatet lærte: DTEND er eksklusiv for en heldagsbegivenhed. Gemmes den, som filen skriver den, dækker hver eneste helligdag også dagen efter sig. Én adresse, der fejler, stopper ikke de andre. Et abonnement er en anden persons server, og den ordinære tilstand for en anden persons server er, at den er i orden indtil en morgen hvor den ikke er. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.38.0	2026-08-20 21:26:13 +02:00
Kristian WindandClaude Opus 5	968a29ca67	feat(notes): listen står i grupper, og projektet har sin egen farve ... Meldt ind som "den er for tæt på en eller anden måde". Grunden var ikke afstanden mellem rækkerne: hver række sagde tre ting, og to af dem gentog sig selv nedad. Datoen stod på hver eneste række — også når tyve noter deler dag — og projektet fik en linje for sig selv. Tre linjer pr. note, gange tolv hundrede. Gentagelserne er flyttet derhen, hvor de siger noget. **Datoen er blevet til overskriften.** I dag · I går · Denne uge · August 2026 … og så er den væk fra rækken. Noten går fra tre linjer til to, og luften kommer af, at der er mindre at skrive — ikke af at listen bliver længere. **Favoritterne har fået deres egen gruppe.** De lå allerede først; der stod bare ikke hvorfor. **Grupperingen følger sorteringen.** Sorteret på "Oprettet" grupperes der på oprettelsesdatoen, på "Senest rørt" på den — ellers ville listen stå i én rækkefølge og være grupperet efter en anden, og så er overskrifterne løgn. Sorteret på navn er der ingen dato at gruppere på, så det bliver forbogstavet, og datoen kommer tilbage i rækken, hvor den så er det eneste tilbage, der siger noget. **Arkivet grupperes med.** Det er dér, de tolv hundrede importerede ligger, og dér, det betyder mest. **Projektet har sin egen farve** — den samme prik som i sidebjælken. Mærkaten sagde det samme som alle de andre i en grå, der var lysere end uddraget, og projektet er dét, man skanner efter, når man leder i tolv hundrede noter. Prikken bærer farven og ikke teksten: fem projektfarver som skriftfarve er fem forskellige grader af læsbarhed, og den lyseste er ikke læsbar. Fire ting, der blev fundet ved at se på det: - Uddraget gentog titlen, fordi titlen *er* første linje. Det var skjult, så længe en dato stod imellem dem. - Uddraget klippes ikke af sig selv. Det lå før i en flex-boks, der ejede afkortningen; da datoen flyttede op, forsvandt boksen, og sætningen løb videre ind under favoritstjernen. - Overskriftens stjerne hed `.star` ligesom rækkens favoritknap og arvede dens gennemsigtighed. Den stod der aldrig. To ting, der ligner hinanden, er ikke det samme. - En `aria-label` på foldeknappen erstatter knappens indhold som dens navn — og knappen *er* overskriften, så overskriften kom til at hedde "Fold I dag sammen". Sidebjælkens gruppehoveder gør det rigtigt, og gør det nu begge steder. Sammenfoldning huskes ikke på tværs af besøg: en gruppe, der åbner foldet uden at nogen bad om det, er en liste, der ser tom ud. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.37.0	2026-08-20 21:01:40 +02:00
Kristian WindandClaude Opus 5	fcd6dca852	fix(push): "der kommer ikke nogen" kunne ikke besvares ... Alt om det var usynligt. Indstillingssiden sagde "til for denne enhed", så snart der fandtes et abonnement — også når hver eneste push blev afvist. Og en afvist push gik i en logline på **Debug**, som ikke skrives på en instans, der kører på standardniveau. Så en levering, der fejler lydløst, og en levering, der aldrig sker, så ens ud, og forskellen er hele diagnosen. Tre forskellige problemer havde ét udseende: browseren tilmeldte sig aldrig, tjenesten afviste den, eller der var ikke noget forfaldent endnu. **En prøveknap** under Indstillinger → Notifikationer sender én notifikation gennem den rigtige rute — ikke en genvej, så det, den beviser, er det, der faktisk skal virke — og siger hvad hver enhed gjorde ved den. Kom den ikke frem, og afviste ingen den, står der, at det så er browseren eller styresystemet, der holder den tilbage. Nu peger svaret på ét af de tre steder. Loglinjen er hævet fra Debug til Warn. Det var den ene linje, der ville have sagt hvorfor. Teksten kommer fra klienten, fordi ordbøgerne gør. En server, der bærer sin egen kopi af "det her er en prøve", bærer den på ét sprog. **Og en lækage, prøven fandt.** Go pakker en transportfejl som `*url.Error`, og dens tekst er `Post "https://fcm.googleapis.com/fcm/send/dQw4…": dial tcp: …` — hele endepunktet, som er den legitimation, push-tjenesten udstedte til den enhed. Den var på vej ud i svaret, i loglinjen og i ethvert skærmbillede af nogen af dem. Prøven var skrevet for at bevise, at kun værten blev nævnt, og det var sådan den blev fundet. Fejlen pakkes ud, og adressen skrubbes bagefter alligevel: den næste fejltype, der bærer den med, kommer ikke med en advarsel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.36.1	2026-08-20 20:41:33 +02:00
Kristian WindandClaude Opus 5	ae673086bc	feat(tasks): tid på en opgave, og et træk i kalenderen sætter den ... Bedt om: "jeg vil have tid på opgaver, og jeg vil kunne justere dem i kalenderen." Serveren kunne det hele i forvejen — `due_date` og `due_time` læses sammen og bliver til et `due_datetime` i kontoens tidszone. Det var fladen, der ikke havde nogen vej til at sige det. **Et felt i opgaveruden.** Tomt, indtil nogen sætter det: en opgave uden klokkeslæt er det almindelige, og et felt, der åbner på 00:00, påstår, at noget skal ske ved midnat. **Og en fejl, der lå og ventede.** Serveren læser en dato uden en tid som "ryd tiden". Så et gem af datoen alene tog klokkeslættet med sig — man rettede dagen og mistede timen — og det samme gjorde hvert eneste træk i kalenderen. Ingen af delene sagde noget. `reschedule` siger nu tiden højt, tre måder, fordi de to første ligner hinanden i JavaScript og derfor skal skilles ad ét sted frem for at blive forvekslet fire: undefined behold den, opgaven har — månedens ruder, hvor der ingen tid er at læse '' ryd den — heldagsbåndet 'HH:MM' sæt den — et sted på døgnet **Hvor på søjlen man slipper, er klokkeslættet.** Målt mod søjlens egen kasse frem for mod siden, så det bliver rigtigt uanset hvor gitteret sidder og hvor langt der er rullet. Rundet til kvarter: minuttet under markøren er ikke en oplysning, nogen har — pegefingeren er bredere end et minut — og 14:07 er et tal, der ser ud som om det blev valgt. Prøven går hele vejen: sæt tiden, genindlæs og se at serveren tog den, ret datoen og se at timen bliver, find opgaven på sit klokkeslæt i ugegitteret, og træk den op i båndet igen. To ting, den lærte undervejs, står skrevet ved den: et træk over fire hundrede pixels skal gå i skridt, ellers har browseren for få mellemstationer til at holde gesten i live — og klokken skal være tidlig, for klokken fjorten ligger under skærmkanten, og at måle noget dernede ruller siden væk under målet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.36.0	2026-08-20 20:29:03 +02:00
Kristian WindandClaude Opus 5	e29fd04abd	docs: noternes opbygning, skrevet til at blive løftet ud ... Hvordan noter er bygget her: modellen, syntaksen, søgningens tre lag, editorkontrakten, vedhæftninger, ind- og udførsel — og begrundelserne, som er den del, der ikke kan læses ud af skemaet. Den begynder med fjorten spørgsmål, der skal besvares før der skrives kode, og siger det til den, der læser den, med rene ord: gæt ikke en standard. Grunden står i filen — omtrent en tredjedel af designet her er arvet fra de omgivelser, noterne bor i, og løftet ind i et program med andre omgivelser uden at afgøre hvad der skal med, giver noget, der virker en uge og derefter slås med én. Den siger også, hvad der ikke virker: notekroppe i klartekst i hver sikkerhedskopi, import der aldrig fletter, ingen sync. En specifikation, der kun beskriver det, der virker, lyver ved fortielse. I repoet frem for uden for det, som HANDOFF.md og NOTES-PLAN.md er. De to er arbejdspapirer om *dette* program; den her er beskrivelsen af en del af det, og den bliver kun forkert, hvis koden flytter sig uden at den følger med — hvilket er lettere at opdage, når den ligger ved siden af. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 20:02:59 +02:00
Kristian WindandClaude Opus 5	be581eb8ae	fix(search): et ord inde i et ord kunne ikke findes ... Meldt ind som "søgning har ikke det store held": en note med `gamerule keepInventory true` kunne ikke findes ved at skrive "keep inventory". Et indeks er bygget af tokens, og et token er det, en tokenizer besluttede var et ord. `keepInventory` er ét. Så "keep inventory" spørger efter to ord, der ikke findes nogen steder, og søgningen svarer, at der ikke er noget — mens noten står lige der. Præfikssøgningen tager halvdelen af det. `keep*` rammer faktisk `keepinventory`; `inventory*` kan ikke, for det er ikke et præfiks af noget. Og de to led er bundet sammen med AND, så den halvdel, der virker, bliver kasseret af den, der ikke kan. Det er ikke et sært tilfælde i en notesapp. Ti års noter er fulde af kommandoer, identifikatorer og filnavne, og hver eneste af dem er flere ord, indekset tror er ét: `keepInventory`, `VACUUM INTO`, `apple-notes-til-markdown`. Indekset svarer først. Har det ingenting, læses teksten: hvert ord skal stå et sted i noten, hvor som helst, i hvilket som helst ord. `fold` er `title || ' ' || body` med de danske bogstaver translittereret, så én søjle dækker titlen, brødteksten og "gron" for "grøn" på én gang. Opgavesøgningen har fået den samme arm. At have den i den ene af de to ville være værre end at have den i ingen af dem: "den finder det i mine noter, men ikke i mine opgaver" er den næste melding, og svaret på den ville være denne linje. Hvad det koster, og hvornår formen er forkert, står skrevet ved koden: en LIKE med et indledende % kan ikke bruge et indeks, så den læser hver note. Ved tolv hundrede noter er det fire megabyte og et par millisekunder, og den kører kun, når den hurtige vej allerede kom tomhændet tilbage — altså netop den søgning, der var ved at skuffe nogen. Ved hundrede tusind er svaret et FTS5-`trigram`-indeks, ikke en større scanning. Prøverne er set fejle uden rettelsen, og de dækker begge veje: "inventory" alene, som ingen præfikssøgning kan nå, og "Bedrock", som stadig skal besvares af indekset — ellers er rangeringen, der blev bygget til tolv hundrede noter, stille forsvundet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.35.1	2026-08-20 18:33:22 +02:00
Kristian WindandClaude Opus 5	9d34b57166	feat(calendar): ugen er et døgn, og dagene er lige brede ... To ting, meldt ind fra en uge, der ikke svarede på det, man åbnede den for. **Dagene var ikke lige brede.** Gitteret stod på `repeat(7, 1fr)`, og `1fr` er `minmax(auto, 1fr)`: `auto` som minimum betyder, at en søjle ikke kan blive smallere end sit længste ord. Én opgave, der hed "Gårdbutikken på Møllerup Gods — opfølgning på mail", gjorde onsdag dobbelt så bred som mandag og klemte resten af ugen sammen om den. `minmax(0, 1fr)` lader søjlen blive så smal, den skal, og så klipper brikken sin tekst af — hvilket den allerede kunne. **Ugen var syv punktopstillinger.** Den svarede på "hvad skal der ske torsdag" og ikke på "hvornår", og det andet er det, man åbner en uge for. To møder klokken ti er en konflikt, man skal kunne se, ikke læse sig til. Nu et gitter med en tidsrende og syv dage: timerne ned ad siden, begivenheder placeret efter klokkeslæt, og et bånd foroven til det, der ikke har et — en heldagsbegivenhed lagt klokken nul ville påstå, den holdt fra midnat til midnat. Overlappende ting deler bredden i sammenhængende klynger frem for parvist: overlapper A med B og B med C, skal alle tre dele, også når A og C ikke rører hinanden. Ellers ville A og C hver tro, de havde halvdelen, og lægge sig oven på hver sin halvdel af B. Hvilke timer der tegnes, kommer fra ugens egne begivenheder med arbejdsdagen som gulv. Et helt døgn er fireogtyve rækker, hvoraf de otte altid er tomme, og så er gitteret noget man ruller i frem for noget man ser — men en vagt klokken fem skal med, uden at alle andre uger betaler for den med tomme rækker. Måneden er ikke rørt ud over søjlebredden. En dag i en månedsrude er halvanden centimeter høj; et døgn tegnet i den er ikke en visning, det er en streg. Brikkerne er flyttet ud i to snippets, som begge visninger tegner med. De viser de samme to ting og skal vise dem ens; det er placeringen, der er forskellig, og så er det kun placeringen, der står to steder. `data-date` følger med over på ugens timesøjler — det er sådan noget uden for komponenten peger på en dag. Båndet får sit eget `data-allday`, så de to ikke bliver til det samme svar på ét spørgsmål. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.35.0	2026-08-20 17:01:58 +02:00
Kristian WindandClaude Opus 5	4b3abc44fb	feat(site): hvad der er landet, og hvad man tager på sig ved at køre det ... To dele. **Lately** siger, hvad der er kommet til, fem linjer med versionsnummer i egen søjle. En landingsside kan påstå, at et projekt er i live; en liste over hvad der faktisk landede siger det bedre. Ikke en changelog — den ville gå i stå — så den peger på release-noterne, som skrives alligevel. **At your own risk** siger det, MIT-licensen siger, og som ingen læser: uden garanti af nogen art. Dertil det, der er sandt om netop dette: én persons projekt, version 0.x, du hoster det selv, så data og sikkerhedskopier er dine — og en sikkerhedskopi, ingen har gendannet, er ikke en sikkerhedskopi endnu. At der er lavet to gennemgange af koden, at hvert fund er skrevet ned og lukket, og at **ingen udefra har auditeret det**. Sat i samme skriftstørrelse som alt andet på siden. Et forbehold med mindre skrift end resten er skrevet for at kunne peges på bagefter, og det er den ene ting, siden ikke skal gøre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 16:19:44 +02:00
Kristian WindandClaude Opus 5	b87c9ea6e2	fix(auth): en afvist passkey sagde "forkert e-mail eller adgangskode" ... Der er hverken en e-mail eller en adgangskode i et passkey-login. Loginet er discoverable — enheden ved selv, hvilken konto nøglen hører til, og der bliver ikke tastet noget. Alligevel fik en afvisning fladens generiske 401-tekst, og den nævner begge dele. Det sendte en person ud at lede efter en tastefejl i sin konto, der aldrig havde været der. Det, der faktisk var sket, var at instansen var flyttet fra http til https: en passkey hører til præcis den adresse, den blev lavet på — `RPOrigins` bygges af `VERDANDE_BASE_URL` med skema og alt — så et login på det ene skema mod en server, der venter det andet, kan ikke verificeres. Beskeden siger nu det, og siger også hvor man skal kigge. Serveren har hele tiden svaret "that key was not accepted"; det var oversættelsen i fladen, der gjorde den til noget andet. Aflysning bliver behandlet som før — den er ikke en fejl, og en fejl for den ville læse som om nøglen blev afvist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.34.3	2026-08-20 15:59:34 +02:00
Kristian WindandClaude Opus 5	ce1d27f8ca	fix(notes): én note, der ikke kunne tegnes, låste hele ruden ... Meldt ind som "jeg kan ikke skifte mellem noter — uanset hvilken jeg trykker på, åbner de ikke". Editoren indlæste med `note.body.trim()` uden værn. `body` er en streng fra serveren hver eneste gang — indtil den ikke er, og så kaster den her inde i et `$effect`. En effekt, der kaster, tager komponentens opdateringer med sig: den forrige note bliver stående, og *ingen* note kan åbnes bagefter. Klikket kan ikke engang lande, hvilket er derfor det ikke ligner en fejl i noten, man klikkede på, men i hele ruden. To ting, ikke én. Værnet, så en manglende krop er en tom note. Og en ramme om tegningen, så det næste, der en dag ikke kan tegnes, heller ikke bliver til det her: en note, der fejler, viser sin egen tekst uden formatering, og resten af ruden virker videre. `loadedId` sættes nu før tegningen frem for efter. Ellers ville effekten prøve igen ved hver eneste ændring bagefter og kaste hver gang. `textContent` og ikke `innerHTML` i faldbakken: teksten er ikke tegnet, og at lægge den ind som markup ville være at køre præcis det, tegningen nægtede. Gemningen er ikke i fare — den skriver `draft`, som kommer fra svaret og ikke fra det, der står i editoren, indtil nogen taster i den. Prøven tvinger formen frem i stedet for at vente på den nyttelast, der gjorde det. Hvad der end fik `body` til at mangle, er svaret det samme: én note må ikke kunne låse de tolv hundrede andre ude. Den er set fejle uden rettelsen — med netop den fejl, konsollen viste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.34.2	2026-08-20 15:32:36 +02:00
Kristian WindandClaude Opus 5	cab4e703f5	fix(sikkerhed): CalDAV lod en viewer skrive, og Web Push kunne ringe indad ... To huller fundet ved en gennemgang efter dagens arbejde. Begge har en prøve, der er set fejle før rettelsen. CalDAV PUT afgjorde adgang på det projekt, klienten *nævnte i adressen*, og tog derefter opgavens id fra den samme adresse. Intet bandt de to sammen. En viewer på et delt projekt kunne pege på et projekt, de selv ejer — indbakken, som alle har og alle må redigere — og lægge den delte opgaves id i filnavnet. Projekt- tjekket gik godt på indbakken, og skrivningen landede på en opgave, de kun må læse. GetTask lukkede det ikke: den svarer "må denne person se det", og det må en viewer. `CanEdit` er spørgsmålet, og det er det samme, handleUpdateTask altid har stillet — API-døren har spurgt hele tiden, CalDAV-døren spurgte ikke. Opgaven skal nu også ligge, hvor adressen siger. Uden det kan en redaktør på to projekter nå det ene gennem det andets adresse; intet eskaleres af det i sig selv, men en adresse, der har lov at lyve om hvor noget bor, er sådan sagen ovenfor kom ind. Web Push blev leveret med en almindelig http.Client. Adressen kommer fra browserens abonnement — altså fra den, der er logget ind — og serveren POSTer til den på et skema, de selv vælger: sæt en påmindelse et minut ude, og jobbet går igen hvert minut. Tilmeldingen afviser en privat adresse, og den kontrol er ikke nok alene: den kører på URL'en som skrevet, og et navn, den godkender, kan svare 127.0.0.1 næste gang det slås op. Det er præcis den sætning, `internal/safedial` selv står og advarer om. Leveringen går gennem safedial nu, som tjekker den opslåede adresse ved forbindelsen og hvert viderestillingshop på samme måde. Kontrollen ved tilmelding bliver, fordi den siger nej, mens nogen kigger på skærmen. Og en hærdning: /inbound/mail har fået et loft. Det er den svagere af de to offentlige skriveveje — beaconet skriver en række for en fremmed, denne skriver ingenting uden en 256-bit adresse, man skal kende i forvejen — men adressen deles med mailservere og står på en indstillingsside, og når den først er kendt, var der intet loft på, hvad der kunne laves med den. Tallet er sat generøst: modtageren er mailserveren, én adresse der leverer det hele. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.34.1	2026-08-20 15:15:28 +02:00
Kristian WindandClaude Opus 5	43f8c0ea85	feat(site): landingssiden siger hvad der findes nu, og siger det med kanter ... Siden stod fra før kalenderen, noternes billeder og arkiv, sikkerhedsarbejdet og beaconet. Nu står de der: søgning der læser dansk, kalenderen, Venter på andre, gentagelser, AI slået fra som udgangspunkt, andenfaktor, at ingen skriver sig selv op, og beaconet — sagt som det er, tændt fra start og med ét klik til at slukke. Google Kalender står med sit forbehold på selve kortet. Den er skrevet efter dokumentationen og har aldrig kørt mod Google, og en landingsside, der siger noget andet, er den ene sætning, resten af siden ikke kan bære. Ikke-målene løj om posten: "No mail integration beyond Gmail and the forwarding address" har været forkert, siden IMAP kom til. iCloud og Fastmail virker. Det, der faktisk ikke virker, er Outlook, og det er nu det, der står. Designet: en bjælke der bliver stående, fordi siden er 5.600 px og vejen ud kun lå i toppen. Fire fakta under knapperne, hvor en landingsside plejer at sætte logoer, den ikke har gjort sig fortjent til. Kort med egne kanter frem for celler i ét gitter — ti celler i tre søjler er et hul i tegningen, atten kort i tre grupper er ikke. To paneler under "Running it", fordi de er alternativer og ikke trin. Ikke-målene som en liste, der kan tælles. Og tre skærmbilleder, der lå i site/screenshots uden at være brugt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.34.0	2026-08-20 14:57:15 +02:00
Kristian WindandClaude Opus 5	8ecefbbdc2	fix(notes): rullebjælken svævede midt i arket ... Det er `.page`, der ruller — og det var også `.page`, der blev smallere for at holde linjelængden nede. Så bjælken fulgte med ind til tekstsøjlens kant og stod med en håndflade tom rude til højre for sig, en tredjedel inde i ruden. Grænsen sættes som polstring i stedet for som bredde. Elementet er lige så bredt som ruden — bjælken bliver ved kanten, hvor den hører til — og teksten er nøjagtig lige så bred som før. `max()` mod nul, fordi en smal rude ellers ville få negativ polstring, og `border-box` er sat globalt, så bredden er hele boksen og ikke boksen plus polstringen; uden det ville det give en vandret rullebjælke. Kildevisningen deler `.page` med editoren og havde samme fejl. Den følger med. Målt: elementet slutter nu på rudens indholdskant i stedet for 74 px inde, og `scrollWidth - clientWidth` er nul. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 14:57:15 +02:00
Kristian WindandClaude Opus 5	6b4448b245	fix(settings): AI, Gmail og kalenderen delte én række og slettede hinanden ... Meldt ind som "AI-informationerne gemmes ikke". De blev gemt. De blev taget bagefter. `user_settings` blev oprettet med `user_id` som hele sin primærnøgle — én række per person, uanset scope — og upserten skrev `scope` om ved konflikt. Der er tre scopes i live: `ai`, `gmail` og `calendar`. De delte den ene række, så hver skrivning slettede de to andre, og hver eneste svarede 204. Det virker begge veje: at forbinde kalenderen slettede Gmail-forbindelsen, og Gmail slettede kalenderen. Fælden var set komme to gange. 0011 gav instansens indstillinger deres egen tabel delvis af den grund og skrev advarslen ned med rene ord; 0014 flyttede postkasserne ud og skrev, at advarslen "nær var trådt i for anden gang". Tredje gang var kalenderen, som lagde et `calendar`-scope ved siden af de to andre. Lektien værd at holde fast i: en advarsel i en migration bliver læst af den, der redigerer *den* migration, og det var ingen. Formen er rettet her, så der ikke er noget tilbage at advare om — `PRIMARY KEY (user_id, scope)`, og upserten rammer den nøgle. Tabellen bygges om, fordi SQLite ikke kan ændre en primærnøgle på plads. De rækker, der findes, kopieres som de er: hver person har højst én, og den holder det scope, der vandt sidst. Det, de tidligere skrivninger tog, er overskrevet og kan ikke hentes tilbage her — efter opdateringen skal AI-udbyderen sættes op igen, og Gmail-forbindelsen tjekkes. To prøver: én mod store-laget, hvor formen var fejlen, og én gennem handlerne, hvor den blev set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 14:56:48 +02:00
Kristian WindandClaude Opus 5	e46aaa462a	feat(projects): sektioner kan trækkes op og ned, og båndet står ikke længere skævt ... Rækkefølgen af sektioner *er* planen — "Planlægning" står før "I gang", fordi det er den vej arbejdet går — og indtil nu kunne den kun laves om ved at slette en sektion og lave den igen, hvilket smider dens opgaver ud i det usektionerede område på vejen. Hele overskriften er håndtaget. En sektionsoverskrift indeholder ikke noget, der selv bliver trukket, så der er ingen geste at stjæle — hvilket er grunden til, at sidebjælkens rækker skulle have et greb, og grunden til at disse ikke skal. Ikke draggable mens den omdøbes: et draggable element lader ikke markøren vælge tekst i det felt, det indeholder. Serversiden er hele listen på én gang som projekter og grupper, og af samme grund: et projekt har en håndfuld sektioner, så 0, 1, 2 … er én lille transaktion uden præcision at løbe tør for, og en liste kan ikke ende halvt anvendt. `ReorderSections` er scopet til projektet og ikke til en ejer — en sektion har ingen ejer, den hører til et projekt, og om du må rykke rundt er et spørgsmål om det projekt, som handleren allerede har stillet. Id'er fra et andet projekt springes over af WHERE-klausulen; der er en prøve på præcis det, fordi ingenting ellers kontrollerer id'erne enkeltvis. Båndet stod fire pixels skævt. Det var trukket ud med --s2 og polstret med --s3 — samme idé gjort med to forskellige tal — så det blev otte pixels bredere end listen i hver side, og teksten landede fire pixels uden for den kolonne, rækkerne holder. Til venstre var det usynligt. Til højre var det Omdøb og Slet, der stod fire pixels forbi alt over og under sig, hvilket er præcis langt nok til at ligne en fejl og ikke langt nok til at se hvorfor. En række er `.row` med `padding: var(--s2)` inde i en boks uden, så båndet har nu samme polstring og ingen margen. Board-visningen er ikke rørt: der er kolonnerne vandrette, og det er en anden geste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 14:56:26 +02:00
Kristian WindandClaude Opus 5	98bfa216d6	fix(look): mærket og de faste visninger fulgte med op, når listen rullede ... Hele sidebjælken rullede, så runen og I dag forsvandt over kanten, så snart der var projekter nok — og de er dem, man er på vej hen til oftest. Alt under de faste visninger ligger i en rulleboks nu, så rullebjælken begynder under dem. En boks indeni frem for `position: sticky` udenom: et klæbende hoved efterlader rullebjælken i fuld højde ved siden af sig, og det var netop den, der skulle starte længere nede. Snippet-erklæringerne bliver liggende udenfor — de tegner ikke noget selv, men de kaldes oppe fra .views, og en snippet erklæret indeni hører kun til indeni. Chevronen for en mappe dækkede gruppens prik med et felt i --surface. På den sænkede bjælke er det en lys firkant, og en foldet gruppe har sin chevron fremme permanent, så klodsen stod der hele tiden. Prikken tones ud i stedet. Det kostede en fælde: en `opacity` under 1 laver en stakkontekst og maler elementet, som var det placeret med `z-index: 0`. Prikken lagde sig dermed oven på knappen, den lige var forsvundet for, og tog klikket — usynlig og stadig i vejen, så gruppen ikke kunne foldes. Ét lag op på knappen, og rækkefølgen er som før. Prøven for vandret rul måler nu begge bokse. Bjælken selv er `overflow: hidden`, så en for bred række ville blive klippet dér og aldrig nå at tælle med — den ville bestå af den forkerte grund. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 14:56:01 +02:00
Kristian WindandClaude Opus 5	6c3d66108b	fix(look): stregen under hurtig tilføjelse havde ingen luft under sig ... Den skiller "skriv en ny" fra "det, der allerede er". Uden afstand sad den første sektion klods op ad den, så den læste som en kant om sektionen frem for som en afslutning på feltet over. En streg skal have plads på begge sider for at kunne ses som en streg. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.33.3	2026-08-20 11:36:23 +02:00
Kristian WindandClaude Opus 5	1437667483	fix(notes): stjerne og arkiv står oven på hinanden ... To knapper ved siden af hinanden er toogfyrre pixels taget fra en liste, der er tre hundrede bred — og de er det, man rører en gang imellem, mens titlen og uddraget er det, man læser hele tiden. I en søjle koster de toogtyve. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.33.2	2026-08-20 11:23:21 +02:00
Kristian WindandClaude Opus 5	035d079a8e	fix(notes): teksten fulgte ikke med, når ruden blev bred ... 46rem var sat for at holde linjelængden i skak, og det er stadig det rigtige hensyn — men det blev sat som ét tal, og på en skærm halvanden gang så bred stod teksten i en smal søjle med en håndflade tom plads ved siden af. Kodeblokke og billeder, som er de to ting i en note, der *vil* have bredde, blev klemt sammen uden grund. clamp frem for et tal: en smal rude får det hele, en bred får en linjelængde, øjet kan finde tilbage i. På 1920 er tekstsøjlen nu 1088 px af arkets 1304 i stedet for 736. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.33.1	2026-08-20 11:08:26 +02:00
Kristian WindandClaude Opus 5	aadfb197b6	feat(notes): arkiv, flere ad gangen, og en kopiér-knap på koden ... **Arkivet, fordi papirkurven er det forkerte redskab.** Den siger "det her var en fejl, og om tredive dage er det væk" — så alt, der er værd at beholde, kan ikke komme i den. Et arkiv på tolv hundrede importerede noter er præcis det tilfælde, hvor de fleste er værd at beholde og næsten ingen er værd at kigge på; uden et sted at lægge dem er listen hele arkivet for evigt, og at finde ugens note betyder at læse forbi et årti. En kolonne, ikke en mappe. Noterne afviste et andet hierarki i 0018, og arkivering er ikke arkivering i den forstand: det er én oplysning om, hvorvidt en note er aktuel, og den skal kunne besvares ved siden af `deleted_at`, som er den anden af samme slags. `updated_at` røres ikke — at rydde op er ikke at skrive. **Flere ad gangen.** ⌘-klik lægger til, skift-klik tager intervallet i den rækkefølge, listen faktisk står i — ikke notens egen, som er en anden, når der er sorteret eller søgt. Trækker man en note, der er markeret, følger hele markeringen med; trækker man en, der ikke er, er det den ene, for ellers ville et træk i en tilfældig række flytte halvtreds noter, man havde glemt var markeret. Ét kald frem for et pr. note: efter en import af tolv hundrede er det at vælge halvtreds det almindelige tilfælde. Hver note kontrolleres stadig for sig — et sæt er en bekvemmelighed for den, der kalder, og aldrig en vej til noget, de ikke kunne have rørt én ad gangen. En kant *og* en tone på det markerede: `--accent-sunken` er meget lys i lyst tema, og tre markerede rækker var svære at skelne fra tre, der ikke var — en dårlig ting at være i tvivl om lige inden man trykker Slet. **Kopiér-knappen spiste næsten den kode, den skulle kopiere.** Den ligger inde i `<pre>` for at kunne stå i hjørnet af blokken, og `colourCode` læste `pre.textContent` og malede resultatet tilbage — så et klik på "Kopiér" skrev "Kopieret" ind i koden, og næste gemning lagde det i filen. Nu ét sted, der siger hvad en kodeblok indeholder, brugt af både farvelægningen og oversættelsen til Markdown: var de to uenige, ville forskellen ende i noten. Prøven klikker, læser udklipsholderen og læser filen bagefter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.33.0	2026-08-20 11:03:02 +02:00
Kristian WindandClaude Opus 5	8aad7c13b0	perf(notes): listen sendte hele noter for at vise halvfems tegn af dem ... Chrome frøs på notesiden, og der var to grunde. **Nyttelasten.** Listen viser en titel og omkring halvfems tegn. Den fik hele noter for at gøre det: med tolv hundrede blev svaret 3,9 MB, hvoraf otteoghalvfems procent var brødtekst, ingen ville læse på den skærm — hentet, tolket og holdt i hukommelsen hver gang siden blev åbnet. Nu 763 KB. Kroppen tømmes frem for at blive forkortet, og det er den vigtige halvdel. Et felt, der hedder `body` og indeholder et *stykke* af kroppen, er en fælde: editoren ville åbne det, pausen ville gemme det, og noten ville være skåret ned til sit eget uddrag af ingenting andet end at være blevet kigget på. Tom er en form, klienten kan se efter — og den gør det og henter hele noten, når den åbner en. Det kostede en adskillelse mere: hvilken række der er *valgt*, og hvilken note der er *indlæst*, er nu to ting. Editoren indlæser sin tekst, når notens id skifter, så hvis den fik uddraget først og hele noten bagefter, ville id'et være det samme begge gange og den anden aldrig blive vist. Man ville sidde med en tom note, der lige havde haft en titel. **Tegningen.** Alle tolv hundrede rækker fik layout og maling, også de tusind ingen kan se: 2,1 sekunder til første tegning. `content-visibility: auto` lader browseren springe det over og tage det, når man ruller derhen — 0,95 sekunder, og uden en eneste linje JavaScript, ingen rullematematik og ingen liste, der kan komme ud af trit med sig selv. **Og søgefeltet.** Det var en pille med et forstørrelsesglas tegnet ind som et baggrundsbillede med farven skrevet i hånden — #8b918d, uanset tema — hvilket gjorde det til det ene sted på siden, der ikke fulgte resten. Nu samme form som søgefeltet i toppen, et rigtigt ikon i `currentColor`, en ryd-knap og et antal fundne. Det havde heller ingen pause: hver tast sendte en søgning gennem tolv hundrede noter, så "kaffe" var fem forespørgsler, hvoraf de fire var forældede inden de kom tilbage — og svarene kunne lande i den forkerte rækkefølge. Nu én. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.32.0	2026-08-20 10:36:35 +02:00
Kristian WindandClaude Opus 5	3a02bc8304	fix(notes): søgningen svarede med det forkerte først, og et træk gjorde ingenting ... **Søgningen sorterede efter dato.** Usynligt med ti noter og ubrugeligt med tolv hundrede: de blev alle importeret samme aften, så `updated_at` siger ingenting, og loftet skar listen af ved halvtreds vilkårlige rækker. At søge "Tesla" svarede med en note om nginx først og noten, der hedder "Tesla Model Y", bagefter — hvilket læses som en søgning, der ikke virker, fordi det fra brugerens plads er præcis dét. Nu bm25, med titlen vægtet ti gange kroppen: et ord i titlen er, hvad noten *handler om*, mens det samme ord én gang i en lang krop er en henvisning. `fold` vejer som kroppen, ellers ville et dansk match slå et præcist. Sammenføjet frem for `rowid IN (…)`, fordi rangeringen hører til matchet, og en underforespørgsel smider den væk. Fladen sorterer ikke om, når der er søgt — det ville kaste netop det væk, der gør en søgning i tolv hundrede noter brugbar. **Et træk af en note hen på et projekt gjorde ingenting.** `ondragover` tog imod både opgaver og noter, så rækken lyste op — og `ondrop` sendte kun opgaver videre, mens noten faldt ned i grenen, der omarrangerer projekter, hvor den ikke betyder noget. Den værst mulige form for i stykker: den så ud, som om den ville virke, helt indtil man slap. Det står i overleveringen som "virker i koden, men ikke fastholdt i prøver, fordi prøven blev upålidelig". Den er skrevet igen, og den ser på resultatet — ligger noten i projektet bagefter — frem for på om rækken blev fremhævet, hvilket var netop det, den gamle kunne se og som blev ved med at være sandt, mens funktionen var i stykker. **Og datoen i listen var altid `updated_at`.** For tolv hundrede importerede noter er det i aftes, så en note fra 2017 stod som "i går", og den dato, man sorterede efter, var ingen steder at se. Rækken viser nu den dato, listen er sorteret efter, og har begge i sit værktøjstip. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.31.0	2026-08-20 09:58:41 +02:00
Kristian WindandClaude Opus 5	4aa8bd6a40	fix(sikkerhed): resten af gennemgangen — SSRF, tre ubegrænsede veje, og fire hemmeligheder ... **H2 — SSRF gennem AI-udbyderens adresse.** `base_url` blev gemt uden kontrol og hentet med en almindelig klient, og udbyderens svar blev givet tilbage ordret. Det var en fungerende skanner af det interne net for enhver bruger: peg den på en vært, læs de første tre hundrede bytes af det, der svarede. På en homelab er det det meste af, hvad der er værd at nå. Nu gennem `safedial`, og svarets krop går i loggen frem for i svaret. Operatøren har stadig brug for beskeden — for en lokal model er den som regel selve problemet — så den er der, bare kun for den, der kører instansen. **M2 — Web Push havde tre.** Endepunktet blev gemt ukontrolleret og POSTet til på en tidsplan, den, der ringer, selv vælger: sæt en påmindelse et minut ude, og serveren henter adressen, hvert minut. Upserten flyttede desuden ejerskabet med `user_id = excluded.user_id`, så enhver, der kendte en andens endepunkt, kunne overtage det — offerets telefon ville få angriberens beskeder og ingen af sine egne. Og `DeletePushSubscription` havde ingen ejer-kontrol. **H3 — tre veje uden loft.** FTS-udtrykket byggede omkring halvtreds bytes pr. ord uden grænse; en søgning på en kvart megabyte blev til to megabyte MATCH-udtryk og seksogtyve sekunder inde i SQLite, mens den holdt på én af kun fire til otte forbindelser. Nogle få af dem samtidig, og databasen er utilgængelig for alle på instansen, logins inklusive. `filterquery.Parse` er kvadratisk — halvtreds tusind led er syv sekunders CPU og seksogfyrre gigabyte allokering i én forespørgsel — og havde hverken loft på antal eller på dybde. Og noteimporten læste hver fil i arkivet uden grænse: 64 MB komprimeret kan blive til seksogtres gigabyte skrevet ned på den disk, databasen ligger på. **M1 — `comment_id` blev taget på tro.** Rettighedskontrollen så på opgaven i adressen, mens filen blev hængt på den kommentar, formularen bad om. En viewer på et delt projekt kan liste dets kommentarer, så hun kunne læse et id og lægge en fil under en andens kommentar i et projekt, hun kun må læse. **M4 — fire hemmeligheder lå i klartekst i hver sikkerhedskopi.** TOTP-koden og AI-nøglen forsegles nu; begge konverterer sig selv næste gang de skrives. Kalenderfeedets og mailadressens tokens gør ikke — de slås op på deres præcise værdi og vises i fladen mere end én gang, hvilket en hash ikke kan. Det står nu skrevet i `SECURITY.md`, som påstod det modsatte. At rette det betyder, at adressen kun kan vises én gang, og det er en beslutning om, hvordan funktionen virker. Og en prøve på, at politikken overhovedet bliver sendt. Det var den, der gjorde XSS-en i nat til indsat HTML frem for kørt script, og der var ingen prøve, der rørte den — en foranstaltning, ingen prøve rører, kan forsvinde i en oprydning, uden at nogen opdager det. Målt på script-src alene: `style-src 'unsafe-inline'` står der med vilje, og en indsat stil kan gøre en side grim, ikke køre kode. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.30.0	2026-08-20 08:39:52 +02:00
Kristian WindandClaude Opus 5	ce3fc466b2	fix(auth): andenfaktoren kunne gættes igennem, og et token kunne tilmelde sin egen ... To huller fra sikkerhedsgennemgangen, og de er samme historie fortalt to gange: den ene kontrol, der findes til når adgangskoden allerede er tabt, kunne omgås af netop den, der havde adgangskoden. **H1 — spanden blev fyldt af adgangskoden alene.** `handleLogin` nulstillede ratebegrænseren ved hver korrekt adgangskode, *før* den så på, om der var en andenfaktor. Det gav én, der havde kodeordet, ubegrænsede portioner på ti gæt: log ind, få en frisk spand og en frisk ventende session, brug ti gæt på koden, log ind igen. Med tre gyldige koder i ethvert øjeblik og tyve forespørgsler i sekundet er det lige odds inden for en eftermiddag. Spanden ryddes nu først, når login er *færdigt*, og der er kommet en spand mere: koder tælles pr. konto og ikke kun pr. adresse. Adressespanden er slået af enhver med mere end én adresse, hvilket er det almindelige — en telefon og en bærbar er allerede to. Det, der gør en sekscifret kode sikker, er at gæt er en knap ressource, og knapheden skal tælles imod det, der bliver angrebet. Den ventende session får lov at leve. At afslutte den ved første forkerte ciffer blev overvejet og valgt fra: det ville koste en, der taster ét tal forkert, sin adgangskode igen, og det køber næsten ingenting oven i loftet pr. konto. **M3 — et lækket token kunne tilmelde sin egen andenfaktor.** `/auth/totp/setup` lå kun bag `requireAuth` og spurgte om ingenting, mens `disable` altid har krævet adgangskoden: døren åbnede med et token og lukkede kun med et kodeord. Et stjålet token kunne hente hemmeligheden, lægge den i sin egen godkender, bekræfte den og beholde den eneste kopi af gendannelseskoderne. Ejerens næste login ville stoppe ved en kode, de ikke havde, og de kunne ikke slå den fra uden at logge ind først. Et tyveri bliver til et lejemål — den sætning står allerede i filen ved siden af om passkeys, og det er den samme regel. Nu bag `requireSession` sammen med passkeys og sessionerne, og `setup` spørger om adgangskoden ligesom `disable`. Symmetrien er pointen: at slå den til er mindst lige så indgribende som at slå den fra. Og en note kan oprettes inde fra et projekt. At ligge i et projekt *er* måden en note deles på, så det er én handling frem for to — man skulle før oprette noten under Noter og bagefter finde projektet frem i "Del i". Ruden findes nu, også før der er en eneste note, for ellers er der ingen knap dér, hvor man opdager at der skal skrives noget ned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:29:43 +02:00
Kristian WindandClaude Opus 5	bdde9cc6a5	merge: Google Kalender som menupunkt, med Verdandes egen kalender lagt over ... Læs bredt, skriv snævert — decision 5 i planen, og kun den første halvdel: kalenderen læses, og der skrives ingenting tilbage. **OAuth-blokeringen er reel og blev ikke gået udenom.** En klient registreret som *Internal* tager kun konti i sit eget workspace — også til kalendere, ikke kun Gmail. Andreas' private konto bliver afvist med `org_internal`, og det er klienten, der virker efter hensigten, ikke en fejl. Fladen siger det nu med ord, man kan handle på, frem for at vise Googles egen skærm, der ikke gør. Vejen udenom, som ikke er bygget: kalenderens egen hemmelige ICS-adresse. Ingen OAuth, virker for enhver konto, og `internal/ics` findes allerede. Det er det næste stykke, og det eneste, der låser den private konto op. `internal/google` er flyttet ud af `internal/gmail`, fordi de to er det samme flow, der er uenige om én streng. Egen callback-adresse frem for at dele Gmails: én callback, der finder ud af hvilken token-butik den skal skrive i, går galt ved at overskrive en Gmail-forbindelse, der virkede. Egne tabeller frem for `mailboxes`. `trigger_kind`, `seen` og `last_uid` svarer alle på "hvad gør en besked til en opgave", og ingenting her bliver til en opgave; én konto har mange kalendere, og `mailboxes` har ikke plads til en en-til-mange. Afgørende i praksis: `mailboxes.kind` har en CHECK, og SQLite kan ikke ændre en — en tredje værdi koster den tabelombygning, som migration 0021 skulle igennem. Begivenheder erstattes pr. kalender pr. vindue frem for at flettes med et sync-token: et vindue, der slettes og skrives forfra, kan ikke komme ud af trit, og et sync-token er endnu en ting, der skal være rigtig for altid, for at gitteret ikke stille viser noget forkert. `CalendarView` er udvidet, ikke kopieret. En begivenhed er et fyldt bånd, hvor en opgave er et kort med en farvet kant, så de to læses forskelligt før et ord er læst — og den kan ikke trækkes og er aldrig en knap: der er ikke noget at gøre færdigt ved en andens møde. To værn på det, der kommer fra Google: farven skal matche et hex-mønster, før den må stå i en style, og linket bliver kun til et href, hvis det begynder med https. Konflikten i jobs.go var to nye jobs skrevet på samme linje. Begge skal med. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.29.0	2026-08-20 07:39:12 +02:00
Kristian WindandClaude Opus 5	6b2cd0f259	merge: engelske skærmbilleder, og otte steder hvor fladen blev ved med at være dansk ... Skærmbillederne er engelske, fjorten i alt, og der er to mennesker i dem. Det sidste er ikke pynt: halvdelen af det, programmet er til, findes ikke med én konto — en ansvarlig, et navn i historikken, en medlemsliste, og "Venter på andre" som andet end en tom side. Sproget kommer fra kontoens locale og ikke fra strenge skrevet i hånden, hvilket er dét, der fandt fejlene: otte steder, hvor grænsefladen blev ved med at være dansk, uanset hvad kontoen sagde. "Forsinket" og "I dag" skrevet ind i markup, "Uden sektion" som boardets første kolonne, gentagelsesreglerne halvt oversat, alle nitten navne på hændelser i historikken, og et `da-DK` hårdkodet i Kommende. Gentagelsesreglerne er flyttet til `when.js`, så menuen og mærket ikke kan blive uenige igen — det er præcis, hvad den fil er til. README's billeder havde været brudte siden `37605ba`, som lavede PNG'erne om til WebP og slettede dem, uden at teksten fulgte med: forsidebilledet og alle seks i tabellen var 404 på GitHub. Og noterne — hele funktionen — stod ikke nævnt hverken i README, på forsiden eller i dokumentationen. Nu skrives PNG til docs og WebP til site, altså præcis dét, de to steder læser. Før efterlod hver kørsel tolv usporede PNG'er i site, som intet pegede på. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.28.0	2026-08-20 07:34:16 +02:00
Kristian Wind	dcd66b415e	docs(web): registreringsteksten fortæller nu, at klienten dækker begge dele ... Hjælpeteksten sagde "slå Gmail API til", og det er kun det halve nu. Den samme klient bærer både Gmail og Google Kalender og skal have begge redirect-URI'er — og kalenderpanelet siger, hvor dets egen kommer fra, så ingen leder efter et felt til en klienthemmelighed, der allerede står ovenfor.	2026-08-20 07:33:24 +02:00
Kristian WindandClaude Opus 5	3991ec9445	feat(notes): et billede kan indsættes og trækkes ind i en note ... Rapporteret fra brug: man kunne ikke indsætte billeder eller trække filer ind i noter. Det passede — importen kunne tage billeder med, og intet andet kunne. Indsætningen tog kun `text/plain` og smed resten væk, og der var slet ingen håndtering af et træk. At indsætte et skærmbillede er det mest almindelige, der findes i et noteprogram, og det gjorde ingenting overhovedet. Der manglede også et sted at lægge filen. Vedhæftninger på en note fandtes i databasen, siden migration 0021, men kun importen kunne skrive dem; der var ingen rute. Nu er der en, med editor-rettigheder på noten og samme svar for "findes ikke" og "ikke din", så et id ikke kan afprøves. Skrevet ind som `` og ikke som en data-URL: en note er Markdown i en database, og et fotografi fra en telefon som base64 midt i teksten ville gøre noten til fire megabyte tekst, der skal læses hver gang listen tegnes. `execCommand` frem for at bygge noden selv, fordi det er dét, der lægger handlingen i browserens egen fortryd-historik — ⌘Z tager billedet ud igen, ligesom det tager et ord ud. `preventDefault` på både dragover og drop. Uden den første kommer der intet drop; uden den anden åbner browseren filen i stedet, og man mister det, man var i gang med at skrive, til en fane med et billede i. Kun filer: et træk inde fra appen selv bærer vores egen nyttelast og skal falde igennem til den, der lyttede. Prøven går begge veje ind, ser at billederne bliver hentet og tegnet, og læser filen bagefter for at sikre, at der står to bilagsadresser og ingen data-URL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 07:32:03 +02:00
Kristian Wind	a5f2f769c4	fix(web): begivenhederne i en celle sorteres, hvor de tegnes ... Serveren sorterer allerede, men en celle, der viser 14:00 over 09:15, ligner ikke en liste i forkert rækkefølge — den ligner et forkert klokkeslæt på chippen, og det er langt værre at skulle udelukke. Heldags først: en heldags begivenhed er et bånd hen over dagen, ikke noget der sker på et punkt i den.	2026-08-20 07:30:55 +02:00
Kristian WindandClaude Opus 5	9d743a5d46	fix(tools): shots skrev PNG'er ned i mappen med WebP ... Standardstien var site/screenshots, som siden landingssiden gik over til WebP kun indeholder WebP. En kørsel lagde tolv PNG'er ved siden af dem, som ingen tekst peger på. Den skriver nu til docs/, hvor de andre PNG'er ligger. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 07:27:48 +02:00
Kristian Wind	031bb18067	fix(calendar): en tom kalender skal sige hvorfor, ikke bare være tom ... At vælge en kalender er nogen, der siger "vis mig den her". At gemme valget og lade gitteret stå tomt, til fejeren kommer forbi et kvarter senere, er en kalender, der påstår, at fjorten dage er fri — og personen står på siden med knappen under hånden. Gemningen henter nu selv. Og er der forbundet en konto uden at der er valgt nogen kalendere, siger visningen dét. "Der er ikke valgt en kalender" og "der er ikke booket noget" ser ens ud, og kun den ene er noget at gøre noget ved.	2026-08-20 07:27:42 +02:00
Kristian WindandClaude Opus 5	71a9fe63d6	docs: noterne findes også i teksten, og hvert billede har et sted at høre til ... README'ets billeder havde været brudte siden landingssiden gik over til WebP: site/screenshots/*.png blev slettet dengang, og markup'en pegede stadig på dem. Den peger nu på PNG'erne i docs/, som er dem, der findes. Noter er en af de største ting i appen og stod ikke ét sted i teksten — hverken i README'et, på landingssiden eller i dokumentationen. Nu gør de, med de to nye billeder. Fem billeder pegede ingen tekst på: upcoming, sections, delegated, settings og admin. De har fået et afsnit i docs/index.md, hvor hvert enkelt beviser noget, siden siger. Landingssidens gitter viste den lyse udgave to gange — den ene af dem er blevet til noterne. Og to billedtekster passede ikke længere på billedet: temaerne viser nu også de fire udseender, og opgaven i skuffen viser ikke sin samtale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 07:25:43 +02:00
Kristian WindandClaude Opus 5	eeaaf7506b	docs: skærmbillederne er engelske, og der er to mennesker i dem ... Landingssiden og dokumentationen læses på engelsk, og billederne var danske hele vejen — både grænsefladen og indholdet. Kontoen bliver nu oprettet med engelsk sprog frem for at oversætte noget her: det er sådan appen selv gør det, og det er også dét, der får en glemt oversættelse til at stå i et billede i stedet for at vente på en bruger. Demodataene er skrevet om til engelsk arbejde og husholdning. Og der er en person mere: en invitation, en konto, tre opgaver hun sidder på og en kommentar. Halvdelen af det, appen er til for, findes først, når der er to i den — en ansvarlig på en opgave, et navn i historikken, og "Venter på andre" som andet end en tom side. Tre billeder viste ikke det, teksten sagde. `detail` var en tom formular, så opgaven har fået beskrivelse, undertasks, en fil, en påmindelse og en samtale. `themes` viste profilfeltet over temaerne, så den ruller nu ned til dem. `delegated` var en tom tilstand. Noterne er kommet til — listen med en note åben, og den samme note som kilde. Fjorten billeder i alt. WebP'en skrives af den browser, der i forvejen står åben, frem for af cwebp: et program mere at installere hører ikke til i et script, hvis hele pointe er, at der ikke er noget at installere. PNG'erne ligger nu kun i docs/ og WebP'en kun i site/, hvilket er præcis dét, de to steder læser — før lagde et kørsel tolv usporede PNG'er i site/, som ingen brugte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 07:24:12 +02:00
Kristian Wind	1b1e57df29	docs: kalenderen den anden vej, og én registrering til begge Google-ting ... `caldav.md` beskrev to måder at sende opgaver *ud*. Den tredje er den modsatte retning og hører til samme sted, fordi det er dér, man ville lede. `configuration.md` hed "Gmail" og handler nu om Google: samme klient, to redirect-URI'er, to API'er, to scopes. Bemærkningen om en Internal-app står begge steder, fordi den gælder begge veje — og for én privat konto er kalenderens egen hemmelige ICS-adresse den kortere vej. Intet i verdande abonnerer på sådan en endnu.	2026-08-20 07:24:01 +02:00
Kristian WindandClaude Opus 5	dce8800f93	fix(web): otte steder hvor grænsefladen blev ved med at være dansk ... Skærmbillederne skulle tages på engelsk, og det var dét, der fandt dem: en konto sat til engelsk fik stadig "Forsinket" over de forsinkede opgaver, "Uden sektion" over den første kolonne på tavlen, "Aldrig" i gentagelses- menuen, "hver dag" på rækken, "til instansen · inviteret af" på invitationen, "3 projekter" på kontoen, og hele historikken — nitten hændelser, alle på dansk. En funktion, der kun virker på det ene sprog, er en funktion, der er i stykker. Gentagelsen er den eneste, der ikke bare manglede en nøgle. Serveren skriver `recurrence_text` på dansk og skal blive ved med det: én besked går over WebSocket til alle i projektet på én gang, og de læser ikke det samme sprog. Så de regler, der har et navn, får det i when.js — på den side, der ved, hvis skærm det er — og alt mere specifikt falder tilbage til serverens ord. Mellemrummet i historikken er skrevet ud. Svelte fjerner det, der åbner en blok, så "inviterede" og adressen løb sammen til ét ord. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 07:23:42 +02:00
Kristian Wind	c3f2181efe	feat(web): Kalender som menupunkt, med Googles begivenheder lagt over egne opgaver ... Samme gitter som Kommende, givet en liste mere at tegne. Ikke et gitter nummer to, og grunden er den del, der er nem at få næsten rigtig: et mål skal afgøre ud fra `dataTransfer.types` alene, om det tager imod, og to kopier af det er to steder at være næsten rigtig. En opgave trukket her flyttes præcis som alle andre steder, fordi det er den samme kode, der gør det. En begivenhed er ikke en opgave, og cellen siger det før et eneste ord er læst: en flade af farve, hvor en opgave er et kort med en farvet kant. Den kan ikke trækkes — forbindelsen er læsende, og en chip, der letter fra siden og så ikke vil lande, læses som en fejl frem for som en regel — og den er ikke en knap, for der er ikke noget at lukke ved en andens møde. Farven er Googles egen for den kalender, så to kalendere i ét gitter kendes fra hinanden på den farve, personen allerede kender dem på. Farven tjekkes frem for at blive troet: den ender i en inline `style`, og en værdi, der ikke er en farve, kan lukke erklæringen og åbne en anden. Linket tegnes kun, hvis det begynder med `https://` — et href er dér, hvor en `javascript:`-adresse bliver til et klik, der kører. Prøven bruger uge-visningen med vilje: en månedscelle skæres af ved tre chips, og resten af suiten lægger opgaver på andre dage. Datoen læses ud af siden, ikke ud af testprocessen, som de øvrige har lært at gøre.	2026-08-20 07:22:25 +02:00
Kristian WindandClaude Opus 5	241c5ed37d	fix(mail): den samme mail blev en opgave igen og igen ... Rapporteret fra drift med et skærmbillede af den samme mail seks gange i træk. **IMAP: flaget kommer af, når mailen er blevet en opgave.** Markøren var et uid — husk det højeste, begynd over det næste gang — og den holdt kun, hvis uids var, hvad serveren sagde. Den brød på et fetch-svar uden uid, på en UIDVALIDITY, der skiftede under en genopbygget postkasse, og på to postkasse-rækker, der pegede samme sted og hver især førte deres eget regnskab. Alle tre gav det samme symptom. Så regnskabet flytter derhen, hvor spørgsmålet bliver stillet. "Flaget" betyder "lav det her om til en opgave"; når den er en opgave, har flaget gjort sit arbejde og er ikke sandt længere. Så er der ingenting at huske, og dermed ingenting, der kan komme ud af trit — en anden synkronisering, en anden postkasse-række eller en database gendannet fra en kopi finder alle det samme svar, fordi svaret ligger i postkassen. Flaget tages af *efter* opgaven er skrevet. Et flag fjernet fra en mail, hvis opgave aldrig blev gemt, er en mail, ingen ser igen. **Gmail havde den samme fejl af en anden grund.** Listen over allerede behandlede beskeder blev bygget om ved hver kørsel af *kun de id'er, Gmail svarede med den gang* — for at den ikke skulle vokse uendeligt. Men forespørgslen er begrænset, så på en konto med mere stjernemarkeret post, end der er plads til i ét svar, glemte hver kørsel det, den forrige havde husket. De kom tilbage som ubehandlede og blev opgaver igen. Det var ikke en grænse, det var en måde at glemme på. Listen har nu et loft på antal i stedet, nyeste først. Gmail kan ikke få taget stjernen af: scopet er `gmail.readonly`, med vilje, fordi det er dét, der gør samtykkeskærmen til noget, et menneske kan sige ja til. Derfor skal regnskabet blive på vores side dér — men det skal så være et regnskab, der kan holde. Prøven kører hele vejen mod en rigtig IMAP-server: find de flagede, tag flaget af, og spørg så forfra med markøren sat til nul — altså det værst tænkelige tilfælde, hvor alt, vi selv havde husket, er væk. Der kommer ingenting tilbage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.27.0	2026-08-20 07:04:40 +02:00
Kristian Wind	987d4edfce	feat(calendar): en læst Google-kalender, med sit eget endpoint og sin egen sweep ... Samme registrering som Gmail, et andet scope og en anden redirect-URI. Google udsteder en refresh-token pr. godkendelse og holder op til hundrede i live pr. konto, hver med sine egne scopes — så en forbundet kalender rører ikke en Gmail, der virker, og at afbryde den ene tager ikke den anden med. Callbacken har sin egen sti. Én callback, der ud fra gemt tilstand afgjorde, hvilket af de to flows der kom tilbage, ville lægge valget af *hvilket token-lager der skrives* bag et opslag — og går det galt, går det galt ved at overskrive en virkende Gmail-forbindelse med kalender-tokens. Begivenhederne caches i et vindue på 90 dage tilbage og et år frem. Et månedsgitter bladrer, og et kald til Google pr. piletast er en kalender, der er langsommere end den kalender, den viser. Vinduet har en kant, og endpointet siger hvor den er: et tomt svar uden forklaring er en kalender, der lydløst påstår, at en dag er fri.	2026-08-20 07:01:14 +02:00
Kristian WindandClaude Opus 5	78891bae6f	feat(beacon): tæl installationer, sig præcis hvad der sendes, og lad folk sige nej ... Spørgsmålet er ét: hvor mange bruger det her. Svaret er to værdier én gang i døgnet — et tilfældigt id, installationen selv fandt på, og versionen. Ikke andet. Beskeden er lille nok til at stå i fuld længde på indstillingssiden, og den gør det, fordi et løfte om telemetri er præcis så meget værd som læserens mulighed for at efterprøve det. **Ikke obligatorisk, og grunden er praktisk frem for principiel:** det kan ikke håndhæves. Domænet kan blokeres, binæren kan patches, og en fork fjerner den i første commit — så obligatorisk køber intet over slået-til-som-udgangspunkt og koster den tillid, resten af programmet arbejder for. Hemmeligheder forsegles her, nøglen holdes uden for databasen, og sikkerhedskopisiden advarer om, hvad en kopi indeholder. Telemetri, man ikke må sige nej til, er den ene sætning i den historie, der ikke passer. Uenigheden med `config.UpdateCheck`, som er slået fra med den modsatte begrundelse, står skrevet i pakkens egen dokumentation frem for at blive glattet ud. Den er reel, og læseren fortjener at se begge halvdele. Id'et findes på og gemmes ved første brug frem for at blive udledt af værtsnavn eller adresse. En hash af noget om maskinen ville være stabil, bekvem og samtidig en værdi, modtageren kunne holde op mod et gæt — og det er forskellen mellem anonym og pseudonym. Modtagerens side er den samme binary med en kontakt: `POST /api/v1/beacon` uden login, fordi den, der ringer, er en fremmed installation. Den svarer 404, når instansen ikke er tælleren, så en almindelig installation ikke er en spamspand, der svarer 200 på alt. Ratebegrænset som login-ruterne, og tabellen har et loft: endepunktet indsætter en række på et id, den, der ringer, har fundet på, og uden et loft kunne enhver fylde disken. Tallet er "set inden for tredive dage" og ikke et løbende total. Et total stiger kun og holder op med at betyde "hvor mange bruger det" og begynder at betyde "hvor mange har prøvet det". `internal/safedial` kom til undervejs: modtagerens adresse kan skrives i fladen, og en adresse, en bruger angiver, må ikke kunne pege indad. Kontrollen ligger på den opslåede adresse og ikke på URL'en, fordi et navn kan svare 127.0.0.1 — og svare noget andet anden gang, efter en kontrol ved parsning er gået godt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 06:59:50 +02:00
Kristian Wind	7828c1e6ed	feat(gcal): Google Calendar kan læses, og kalenderen får sine egne tabeller ... Klienten henter kalenderlisten og begivenhederne i et vindue, og laver Googles to former om til den ene, et gitter kan spørge om: dage i begge ender, begge med. Googles heldags-slutdato er eksklusiv, og et møde, der slutter ved midnat, slutter aftenen før — begge dele rettes ét sted frem for hos hver læser. Egne tabeller frem for `mailboxes`. De to ligner hinanden på afstand og er uenige om hver eneste kolonne bagefter: `trigger_kind`, `seen`, `last_uid` og `project_id` svarer alle på "hvad laver en besked om til en opgave", og intet her bliver til en opgave. Én konto rummer desuden mange kalendere, og en en-til-mange er der ikke plads til. Det afgørende er mindre og mere praktisk: `mailboxes.kind` har en CHECK, og SQLite kan ikke ændre en CHECK — en tredje værdi koster en tabelombygning med fremmednøgler slået fra. Derfor er der ingen CHECK på `provider` her: CalDAV skal koste en række, ikke en ombygning.	2026-08-20 06:50:57 +02:00
Kristian Wind	a46d9158e1	refactor(google): OAuth-flowet flytter ud af gmail, så to ting kan dele det ... Gmail og Google Calendar logger ind gennem den samme registrering med den samme PKCE og den samme fornyelse. Det eneste, der adskiller dem, er ét ord: scopet. En kopi mere ville være et sted mere, hvor `access_type=offline` kan blive glemt — og det er dén fejl, der får en forbindelse til at dø lydløst en time efter, den blev lavet. internal/gmail beholder sit API og sit scope; navnene på flowet er aliaser, så hverken kaldere eller prøver ændrer sig. Prøverne for PKCE, AuthURL og Configured flytter med koden.	2026-08-20 06:46:10 +02:00
Kristian WindandClaude Opus 5	4b5f3f0864	chore: agenternes arbejdstræer hører ikke i repoet ... Et `git add -A` fangede .claude/worktrees/ som et indlejret repo. Det er en agents arbejdskopi og skal ingen steder. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.26.3	2026-08-20 06:39:45 +02:00
Kristian WindandClaude Opus 5	052f8a43fb	fix(notes): en note kunne smugle et script ind gennem et billedes alt-tekst ... Indført i aften, sammen med billedvisningen, og fundet ved at læse den igen. `escapeHtml` tager &, < og > — ikke anførselstegn, og det er rigtigt for tekst mellem to tags, hvor et anførselstegn ikke betyder noget. `alt` er ikke tekst mellem to tags. Det står inde i en attribut, og der lukker det første anførselstegn den, hvorefter resten står som markup:  blev til et <img> med en onerror på. Adressen var i forvejen bundet til vores eget bilagsmønster, så den var ikke vejen ind — teksten ved siden af var. Det er ikke en teoretisk vej. En note deles ved at ligge i et projekt, så den læses af alle, der kan læse projektet, og scriptet ville køre på vores eget domæne med sessionscookien, hos den der åbnede noten. En værdi i en attribut har brug for sin egen undslipning, og har nu en. Prøven skriver noten, åbner den og ser efter, at hændelsen står som tekst i alt og ikke som en attribut på elementet — og at billedets 404, som er selve vejen en onerror ville blive kaldt ad, ikke kalder noget. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 06:39:19 +02:00