385 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
Kristian WindandClaude Opus 5	dee2d5e30b	fix(faerdige): en opgave lukket efter midnat lå under "I går" ... Fundet af prøverne, som for første gang kørte forbi midnat. Dagen blev læst som `completed_at.slice(0, 10)` — de ti første tegn af et tidsstempel, der er i UTC. Overskriften sammenlignede med *lokal* dato. I dansk sommertid er de to ikke den samme dag i de første to timer efter midnat, så en opgave lukket 00.30 blev sat under "I går", indtil klokken blev to. Tyve timer i døgnet er de ens, hvilket er derfor prøven har været grøn hver eneste gang før. Dagen udregnes nu lokalt, som den overskrift den skal svare til. Og prøven for invitationslinket kunne kun bestå seks dage om ugen. Den ledte efter "males inden fredag" som én tekst, men hurtig tilføjelse læser "fredag" som forfaldsdatoen og tager ordet ud af titlen — tilbage står "males inden" plus et mærke, hvis ord skifter med ugedagen. Kørt på en torsdag hedder mærket "I morgen", og så fandt den ingenting. Prøven handler om invitationer, ikke om datoer, så den ser nu på titlen alene. Uddraget i notelisten viste `![](/api/v1/attachments/01a0…` for hver note med et billede i — den eneste tekst i listen, ingen havde skrevet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.26.2	2026-08-20 00:17:50 +02:00
Kristian WindandClaude Opus 5	2bd8e48aba	fix(notes): en note med tre prikker i titlen blev smidt væk ved importen ... `skipFile` afviste ethvert navn, der indeholdt "..", for at stoppe en zip i at skrive uden for sin egen mappe. Det er den rigtige idé rettet mod det forkerte: det beskriver ikke en sti, der klatrer ud af arkivet, men ethvert filnavn med to prikker ved siden af hinanden. En ellipse i en overskrift er almindelig, og noten "Så blev det endelig jul! Stay tuned... ☕️" blev derfor aldrig oprettet. Lydløst, oven i købet: filen blev sprunget over, før den blev talt, så svaret sagde det samme, som hvis den var kommet med. Én note ud af tolv hundrede, og den blev kun fundet ved at tælle efter, hvor mange der kom ud i den anden ende — 1140 hvor der skulle stå 1141. Nu læses ".." som et stiled, ikke som to tegn, og en Markdown-fil, filteret afviser, tælles som sprunget over. En import, der taber noget, skal sige det. Og move-ikonet i sidebjælken er væk. ⠿ sad i den to pixels brede rende til venstre for teksten og lå oven i rækkens egen kant — idéen var rigtig, pladsen var det ikke. Elementet bliver: det er dét, der ejer trækket, og gjorde man i stedet hele rækken draggable, ville alt indeni også blive det, og en opgave trukket hen på I dag holdt op med at lande. Nu er håndtaget usynligt og lidt bredere, og hånden ved hover er hele forklaringen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.26.1	2026-08-20 00:04:08 +02:00
Kristian WindandClaude Opus 5	9b4e7686f9	feat(notes): datoerne følger med, billederne bliver tegnet, og listen kan sorteres ... Fire ting, som en rigtig import af tolv hundrede noter fandt på en time. **Billederne blev vist som ord.** `markdownToHtml` havde ingen regel for `` overhovedet, så en note fra Apple Noter viste sin egen billedadresse som tekst. Filen var hentet, gemt og hæftet på noten; det eneste, der manglede, var at nogen tegnede den. Kun vores egen adresse bliver til et billede — et `` fra en indsat tekst ville ellers hente fra en fremmed vært, når noten åbnes, og en note er det sidste sted, man vil have en sporingspixel. Og vejen tilbage skulle med: uden `IMG` i inlineToMarkdown ville den første gemning have taget hvert billede ud af noten igen. **Titlen blev revet i stykker.** Noter deler en linje op i så mange stumper, den har brug for — "Aalborg Kommune" står som `<h1>A</h1><h1>alb</h1><h1>org Kom</h1><h1>mune</h1>`, fordi der er en attributkørsel bag hver stump — og eksporten læste et linjeskift ved hver af dem. Noten kom ud som fire overskrifter oven på hinanden, altså ødelagt på den mest synlige måde der findes: i sin egen titel. Samme rod gav `**M****øde**` for fed og `*M**øde*` for kursiv, hvor de to stjerner i midten læses som fed. Nu brydes der kun, når blokken skifter, og et mærke, der lukkes og straks åbnes igen, er ingenting. **Datoerne fandtes ikke.** Eksporten læste dem aldrig, og Markdown havde ingen plads til dem — så en flytning af tolv hundrede noter blev en bunke, der alle var skrevet samme aften. Rækkefølgen er halvdelen af, hvad et arkiv er. Nu står de i et YAML-hoved, som Obsidian og Bear allerede skriver, og importen læser det. `SetNoteTimes` frem for gennem SaveNote: `updated_at` betyder "hvornår skrev *dette* program noten sidst", og lod man enhver kalder sætte den, ville kolonnen betyde det, den sidste skriver havde lyst til. **Og listen kan sorteres** — senest rørt, oprettet, navn. Favoritter står øverst uanset hvad; det er hele meningen med at gøre en note til favorit. Eksporten henter nu i klumper. Ét kald pr. note tog halvanden time for tolv hundrede, ikke fordi Noter er langsom, men fordi hvert kald er en proces, der skal startes — og det gjorde det umuligt at rette en fejl i oversættelsen og se resultatet, for hver runde var en frokostpause. Antallet af bilag kom med i klumpen af samme grund: ni ud af ti kald var en proces startet for at få svaret nul. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.26.0	2026-08-19 22:58:19 +02:00
Kristian WindandClaude Opus 5	2ffbd9533b	fix(notes): billederne i en importeret note pegede på ingenting ... Fundet ved at importere rigtige noter frem for ti prøvenoter. Linket blev skrevet halvt om. attachToNote kendte to måder, en note kan nævne en fil på — den bare filnavn og stien i forhold til noten — men ikke den, en Apple Noter-eksport faktisk skriver: `vedhaeftninger/751-2-IMG_0615.heic`, med noten i roden ved siden af mappen. Kun det bare navn matchede, så kun det blev erstattet, og hver eneste billede i hver eneste importerede note endte som `vedhaeftninger//api/v1/attachments/…`, som er ingenting. Filerne var gemt og hæftet rigtigt på; det var linket, der var forkert. Længste match først, ellers bliver mappen stående foran adressen. Og billederne kunne alligevel ikke vises. Alt blev serveret som application/octet-stream med Content-Disposition: attachment, hvilket er en god regel med en god grund — en uploadet SVG eller HTML vist inline ville køre sit eget script på dette domæne med sessionscookien på. Men en note bærer sine billeder i teksten som ``, og under den regel er hvert eneste af dem et brudt billede. Hele importen findes for at tage dem med. En kort liste af rasterformater vises nu inline med deres egen type. Det er ikke en opblødning: listen er navngivet ét format ad gangen frem for matchet på "image/", fordi præfikset ville lukke image/svg+xml ind — et dokument, der kan køre script — og en liste, der vokser ved et uheld, er præcis sådan det sker. nosniff står, så browseren skal læse filen som netop det billede eller slet ikke. Titlen stod to gange i fjorten noter. Noter kalder noten det, der står på de første linjer sat sammen med mellemrum, så en note, hvis to første linjer er "CPU" og "CAN", hedder "CPU CAN" — og sammenligningen med kun den første linje gik fri. Overskrifterne øverst tages nu med, så længe de tilsammen stadig er begyndelsen på titlen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.25.0	2026-08-19 22:02:20 +02:00
Kristian WindandClaude Opus 5	f6c6bdccbb	fix(notes): projektmenuen står ved det # der bliver skrevet ... Den var lagt fast øverst i ruden, med den begrundelse at en menu, der følger markøren, rykker sig et par pixels for hvert bogstav. Det er rigtigt, og det var alligevel forkert: i en note på en skærmfuld skriver man `#` nederst og får en menu i toppen — fire hundrede pixels fra det, øjet ser på, og langt nok væk til at man ikke opdager, at den er der. Begge dele kan lade sig gøre. Positionen måles, når menuen åbner, og ikke igen mens listen snævres ind: den står ved tegnet, og den står stille. Målt på `#term` frem for på markøren, fordi et sammenfaldet område ikke har nogen kasse på en tom linje. Klemt inden for ruden, og vendt op over linjen, når der ikke er plads under — ellers ville en note, der er skrevet helt ned i bunden, lægge menuen uden for skærmen. Og pak-noter-i-portioner.py, fordi en Apple Noter-eksport er hundrede og enoghalvfems megabyte, hvoraf teksten er fire: importen tager 64 MB ad gangen, og tunnelen foran den tager mindre. Delt efter hvad en note vejer med sine billeder, og altid med billederne i samme portion som den note, der peger på dem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 21:44:03 +02:00
Kristian WindandClaude Opus 5	9e687185fb	feat(notes): vis noten som kode, og giv teksten en margen at ånde i ... Kildevisningen, fordi den rige flade ikke kan tage imod Markdown. Indsat i den er "## Overskrift" fem tegn og ikke en overskrift, og der var ingen vej ind for tekst skrevet et andet sted — hvilket er en mærkelig mangel i et program, hvis hele lager er Markdown. Knappen </> viser filen, som den ligger i databasen, og det, man skriver der, går tilbage gennem den samme oversætter som altid. Fyldt fra kilden og ikke fra note.body, når man går tilbage: gemningen venter på sin pause, så den vej ville kaste det nyeste væk. Og kildevisningen hører til den note, den blev slået til på — skifter man note, er det den rige flade, man møder. Margenerne. Teksten lå helt ude ved kanten, og på en bred skærm blev linjerne hundrede og fyrre tegn — dér mister øjet hvilken linje det var på, når det springer tilbage. Arket har nu marginer, der vokser med ruden, og teksten en grænse på 46rem. Kun teksten: værktøjslinjen og foden hører til ruden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.24.0	2026-08-19 21:28:16 +02:00
Kristian WindandClaude Opus 5	8229800767	fix(notes): lister overlevede ikke en gemning, og tallene blev klippet af ... Seks ting fundet ved at bruge appen, i den rækkefølge de gjorde ondt. En liste inde i en blok blev læst som tekst. htmlToMarkdown havde én gren for ul og ol og lod alt andet falde ned i inlineToMarkdown, som samler efterkommere til én streng — så et blokcitat med en liste i kom tilbage som "> PunktPunkt 2", og en note fra Apple Noter, der er fuld af citater, mistede hvert punktmærke ved den første gemning. Ingen havde rørt de linjer. Nu læses en blok, der rummer blokke, igennem frem for flad, og et citat sætter "> " foran det, der kommer indefra. Indlejrede lister fandtes ikke. Den flade `list`-variabel kunne kun beskrive ét niveau, så et indrykket punkt blev lagt ved siden af sit ophav. Nu en stak, og underlisten lægges inde i sit <li> — det er den forskel, der kan læses tilbage. En liste, der begyndte ved ti, begyndte ved ét bagefter. `start` skrives nu med og læses med, så en gemning uden ændringer ikke gør noten om. Tallet blev klippet af. Mærket sættes uden for tekstkanten, og 16px rakte til et punkttegn og ikke til "10." — resten hang ud over kanten, hvor .page beskærer. Renden er nu 2.2em og deles af begge slags, så punkter og tal flugter. # viste seks vilkårlige projekter ud af tyve og så færdig ud. Loftet er væk, listen kan rulle, og det, der begynder med det tastede, står øverst. Og to ting om, hvordan det ser ud. Noteruden har fået sin egen flade, fordi et ark, der holder op et sted, skiller det, man skriver, fra det program, man skriver det i — `--surface` frem for `#fff`, så de fem temaer hver får deres. Noter stod for sig selv over en streg, hvilket sagde det rigtige og kostede halvfjerds pixels; den står nu i rækken med de faste visninger og bærer et ark i stedet for en prik, hvilket siger det samme gratis. Prøven skriver de fem listeformer, gemmer gennem den rigtige editor og læser filen bagefter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 21:24:43 +02:00
Kristian WindandClaude Opus 5	a4b12f3601	feat(notes): listen som Apple Noters, ⌘K finder noter, og de kan trækkes ... Rækken har nu titel i samme størrelse som en opgavetitel — en note og en opgave er to ting af samme slags, og hver sin størrelse får den ene til at se mindre vigtig ud. Under den står dato og begyndelse på samme linje, som Apple Noter gør det: to linjer pr. note frem for tre, og datoen først, fordi det er den, man skanner efter. Ligger noten i et projekt, står det nedenunder. ⌘K søgte kun i opgaver og projekter. Feltet ser ud til at kunne finde alt, så det er svært at gætte, at halvdelen af programmet ikke var med. Og mens jeg var der: "Projekt" og "Opgave" stod hårdkodet på dansk i paletten. En note kan trækkes ind på et projekt i sidebjælken — samme mål som en opgave, fordi det er samme gestus: læg denne her. To fejl i søgefeltet, begge Safaris egen type="search": Fokusringen tvang sin egen hjørneradius og tegnede en firkantet bue uden om en rund kant — to streger, hvor der skulle være én. Den følger nu elementets form, overalt i programmet. Og feltet skiftede udseende ved fokus: forstørrelsesglasset forsvandt og pilleformen blev firkantet. Det tegnes nu af os. Trækket og palettens noter er ikke fastholdt i en prøve. ⌘K, tastning og en debounce oven på hinanden gjorde den upålidelig, og en flakkende prøve siger mindre end ingen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.23.0	2026-08-19 20:46:05 +02:00
Kristian WindandClaude Opus 5	43ad60a84a	feat(notes): formateringen overlever, og monospace bliver til en terminal ... Konverteringen læser nu Apple Noters HTML frem for at flade den ud med textutil. Overskrifter, fed, kursiv, understreget, lister og monospace kommer med. En note er ikke kun sine ord — et referat med overskrifter er ikke det samme referat som en klump — og ti prøvenoter viste hvad det kostede. Skrevet om til Python, fordi HTML skal læses og ikke gættes med regulære udtryk. Den alvorligste fejl, prøvekørslen fandt: navn og krop blev hentet i hvert sit kald, og Noter sorterer listen efter ændringsdato. Flyttede noget sig imellem de to kald, fik en note én titel og en andens indhold. På ti noter er det synligt; på tolv hundrede ville det være ubemærket rod. Der hentes nu ved id, og navn og krop kommer i samme kald. Sammenhængende monospace-linjer bliver til én blok. Hver linje i Noter er pakket ind i sin egen div, hvis starttag tømmer den forrige — så mellem to tt-linjer kom der altid en tom flush forbi, og hver linje i en terminaludskrift blev sin egen blok. Og i editoren ser en kodeblok ud som en terminal: mørk flade, monospace, sproget i hjørnet, farver på strenge, tal, kommentarer, nøgleord og prompten. Monospace ER kode i praksis, og en mørk flade siger det på afstand. Farverne lægges på de blokke, markøren IKKE står i. At farve mens nogen skriver betyder at bygge indholdet om ved hvert tastetryk og sætte markøren tilbage bagefter — det virker ni gange ud af ti og flytter markøren midt i en sætning den tiende. Et API-token er ét ord, der er bredere end skærmen. Uden min-width: 0 skubbede en sådan note hele listen bredere og klemte editoren sammen — på en note, man ikke engang havde åben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 20:31:10 +02:00
Kristian WindandClaude Opus 5	08fc355bf9	fix(tools): tre fejl, en prøvekørsel på ti noter fandt med det samme ... Kodningen. textutil gætter på inddataets kodning og gætter forkert, så "Ansøgning" kom ud som "Ansøgning". Det ser ud som én underlig note, indtil man opdager, at det er hver eneste note med et dansk bogstav i. Titlen stod to gange. Kroppen af en Apple-note begynder med notens egen titel, så en overskrift ovenover gav den dobbelt overalt. Og listerne var ikke lister. Apple skriver dem som tabulator, tegn, tabulator — en liste for et menneske og ingenting for en Markdown-læser, så en huskeliste ankom som en klump linjer. Punkttegnet er flerbyte, og BSD sed hakkede det midt over, så hver linje begyndte med to halve tegn; perl med -CSD gør det rigtigt. Scriptet tager nu et antal som andet argument, så en prøvekørsel er til at gentage. Det er billigere at opdage den slags på ti noter end på tolv hundrede. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 19:37:52 +02:00
Kristian WindandClaude Opus 5	414a35eaba	feat(notes): billeder og bilag følger med ind — og ud ... Du spurgte, hvad der sker med bilag og indsatte billeder. Svaret var: de forsvandt stille. Scriptet konverterede til ren tekst, og en note fra Apple Noter, der kommer over som ord alene, er ikke den note — den er et referat af den. En note kan nu bære filer, i samme tabel som opgaver og grupper allerede bruger. Filerne er indholdsadresserede og deduplikeres på disken, upload-vejen er skrevet og afprøvet, og oprydningen af forældreløse filer går allerede den tabel igennem. En tabel mere ville være et alt-sammen mere. Importen læser arkivet i to omgange. Alt, der ikke er Markdown, gemmes først, så en note, der bliver læst, allerede har adresser at få sine links rettet til — noter og billeder ligger i den rækkefølge, arkivet nu har dem, og ét gennemløb ville efterlade halvdelen af henvisningerne pegende på ingenting. Kun de filer, noten faktisk nævner. Et arkiv er én mappe til mange noter, og at hænge hvert billede på hver note ville gøre hundrede noter til ti tusind bilag. Hentningen af en note-fil gav 404, fordi adgangskontrollen ikke kendte noter som forælder. Et billede midt i den tekst, der navngav det, svarede altså "findes ikke". Den følger nu noten, som følger sit projekt — samme kæde som alt andet. AppleScriptet gemmer nu hver vedhæftning og skriver en henvisning til den i noten. Vedhæftninger uden fil bag sig — links til websider, kort — springes over frem for at vælte kørslen. Migration 0021. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.22.0	2026-08-19 19:12:54 +02:00
Kristian WindandClaude Opus 5	11fdbefe1b	feat(notes): hver note som en Markdown-fil, i et zip ... Det er løftet, hele designet blev lagt til rette omkring: noten på disken ER den fil, man ville eksportere. Der konverteres ingenting på vejen ud, så der er ingenting, konverteringen kan tage fejl af — filerne åbner i Obsidian, i en teksteditor, i hvad som helst. To ting, en eksport kan tabe stille, og som prøven holder fast: Et skråstreg i en titel ville lave en mappe på Mac og Linux og blive afvist på Windows. De tegn, ingen af de tre vil have, bliver til bindestreger. Og to noter med samme titel er to noter — et arkiv med den samme post to gange er et arkiv, der har mistet den ene. Den anden får et nummer. Fejler skrivningen midtvejs, stopper den frem for at rydde op. Svaret er allerede på vej ud, så der er ingen statuskode tilbage at sende: et afkortet zip siger selv, at det er afkortet, hvilket er bedre end en komplet fil med en note færre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 19:03:25 +02:00
Kristian WindandClaude Opus 5	6e83291444	feat(notes): opgaven viser de noter, der nævner den — og har fået en adresse ... Den anden vej af samme forbindelse. En note, der nævner en opgave, viste den; nu viser opgaven noten. Uden det virker forbindelsen kun, hvis man tilfældigvis sidder og læser noten, og det er den halvdel, ingen har brug for hjælp til. Undervejs viste det sig, at en opgave slet ikke havde en adresse. Skuffen åbner over den liste, man står på, og ændrer ingenting i URL'en — hvilket er rigtigt for et klik og ubrugeligt for et link: man kan ikke sende nogen en opgave, og en note, der nævner en, har ingen steder at sende dem hen. Min egen henvisningsform pegede altså på noget, der ikke fandtes. /opgave/{id} findes nu. Den åbner skuffen og træder til side — erstatter sig selv med opgavens eget projekt, så man lander hvor opgaven bor, med den åben, og tilbage-knappen ikke går gennem en side, der kun nogensinde viderestillede. Prøven henter opgavens id fra API'et frem for fra adresselinjen, netop fordi den ikke står der. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 18:59:34 +02:00
Kristian WindandClaude Opus 5	f6c60bdaf9	fix(notes): #garageristeriet og #GarageRisteriet er samme projekt ... De var det ikke. Nøglen blev gemt præcis som skrevet og slået op på samme måde, så en note, der nævnte et projekt med lille begyndelsesbogstav, dukkede simpelthen ikke op på det — stille, og uden noget der antydede hvorfor. Foldet på vej ind og foldet i opslaget, så sammenligningen bliver ved med at være en nøjagtig lighed og bruger sit indeks. Havde man i stedet sænket kolonnen i forespørgslen, skulle hele tabellen læses. Kun projekter. En [[notetitel]] er en titel, ikke en nøgle: to noter, der hedder "Møde" og "møde", er to noter, og at folde dem sammen ville slå noget sammen, nogen havde holdt adskilt. Der er en prøve for begge dele. Migrationen samler de rækker, der allerede er skrevet. Primærnøglen er (note_id, kind, target_id), så en note, der skrev begge stavemåder, ville kollidere med sig selv — derfor bygges sættet forfra med INSERT OR IGNORE frem for en opdatering, der ville fejle på parret. Fladen viser projektets egen stavemåde og ikke den foldede nøgle. En etiket, ingen har skrevet, og som står hverken i noten eller på projektet, ville være værre end ingen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.21.1	2026-08-19 18:48:00 +02:00
Kristian WindandClaude Opus 5	5e670119db	feat(notes): titlen er første linje, og # foreslår projektet ... Titlen var udledt én gang og derefter ladt i fred, så den gik i stå i det øjeblik nogen skrev begyndelsen om — en note med overskriften "Ny note" stod i listen som "fdgfgfgh", hvilket var, hvad dens første linje havde været nogle rettelser tidligere. Den udledes nu ved hver gemning, og ingen kan sætte den ved siden af teksten: kolonnen er en kopi af kroppen, ikke et felt derudover. Feltet er væk fra både HTTP-fladen og MCP-værktøjerne, for et felt, serveren ignorerer, er et løfte, den ikke kan holde. Skriver man #Kaf, foreslås #Kaffebaren. Ordet læses fra den tekstknude, markøren står i, og ikke fra hele dokumentet — en note kan nævne tyve projekter, og kun det under markøren er ved at blive skrevet. Listen ejer piletasterne og retur, mens den er åben, som enhver anden fuldførelse. Og under feltet står nu, hvad teksten forstår: # projekt, [[en anden note]], ⌘B, ⌘U. Samme idé som linjen under hurtig tilføjelse — en note er det andet sted i programmet, hvor det, man skriver, bliver læst for betydning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.21.0	2026-08-19 18:36:31 +02:00