17 Commits

Include renames

Author	SHA1	Message	Date
kristianwindandClaude Opus 5	d8f5f6e236	feat(noter): nævn en person i en note, og den er delt med dem ... At skrive nogens navn i en note *er* at ville have dem til at læse den. Indtil nu var det to handlinger — skriv navnet, åbn panelet, find personen, del — og den anden blev glemt, så noten stod med en besked til en, der ikke kunne se den. Nu deler `@Navn` noten med den, der bliver nævnt, og siger det til dem. Editoren foreslår personer efter `@`, ligesom `#` foreslår projekter. Slået op i navnene frem for tolket ud af teksten. Et navn kan have mellemrum i sig, og et udtryk, der skulle fange dem alle, ville også fange sætningen bagefter: `@Sofie i morgen` ville blive til en person, der hed noget i den retning. Her er der ikke noget at gætte — der står et navn, eller der gør ikke. Det er også dét, der gør det forsvarligt at dele på: adgang må ikke afhænge af, hvor langt et regulært udtryk valgte at læse. En mailadresse er ikke en omtale, det længste navn vinder, og ejefaldets s hører til sætningen. Kun nye omtaler, sammenlignet med teksten før gemningen på samme måde som links: en note gemmes ved hver tastepause, så uden sammenligningen var hver gemning en ny deling og en ny besked om det samme navn. Kun ejerens omtaler deler. En medredaktør må skrive i noten, men ikke give den videre — ellers kunne den, ejeren har delt med, skrive et navn og dermed dele ejerens note med en, ejeren aldrig har hørt om. Det er den samme regel, panelet følger. Læser, ikke medredaktør: en omtale siger "se på det her", og det mindste, der opfylder sætningen, er det rigtige at give. En rolle, ejeren har hævet i panelet, sænkes ikke igen af en omtale. Og én besked pr. handling: den, der lige er blevet nævnt, får "nævnte dig" og ikke også "rettede en note" om den samme gemning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 12:08:12 +02:00
kristianwindandClaude Opus 5	ab77024ec9	feat(beskeder): klokken siger til, når nogen rører noget, der er dit ... En delt note blev rettet af en anden, og man opdagede det kun ved at åbne den. En opgave blev givet til en, og den lå bare der. Det, andre gør ved det, man deler, skal man kunne se uden at lede efter det. Klokken i hovedet: ulæste beskeder om noter, der er blevet rettet, delt med en, eller opgaver, man har fået. Sætningen skrives i browseren, ikke på serveren, så et engelsk interface får en engelsk klokke. Beskeder om den samme note bliver slået sammen, mens de er ulæste. En note gemmes på en tastepause, så en række pr. gem ville lave én person, der skriver i fem minutter, om til tyve ens linjer. Er beskeden læst, er den næste rettelse en ny ting at få at vide — ikke en gentagelse. note_id får sin egen søjle ved siden af project_id og task_id frem for et generisk (kind, id)-par: de tre er ikke det samme slags nul, og fremmednøglen — dén, der rydder beskeden op, når noten slettes — kan et generisk par ikke have. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 11:40:43 +02:00
kristianwindandClaude Opus 5	916a0c0224	feat(noter): en delt note tager de noter med, den peger på ... Den anden halvdel af den melding, der begyndte det her: linkene i en delt note førte ingen steder hen, fordi det, de pegede på, ikke var delt. At dele en note er at dele det, den *siger*, og et link er en del af det. note_shares får en `linked`-søjle. 0 er en deling, nogen har valgt; 1 er en, der er udledt af et link. Skellet er hele modellen. Fladen kan sige *hvorfor* en person har en note — "fulgte med" er en anden sætning end "du delte den" — og de udledte rækker kan regnes forfra efter hver ændring, uden at røre dem, ejeren selv har sat. SyncLinkedShares regner billedet om fra bunden efter enhver af ejerens egne handlinger: en deling, en fjernet deling, en gemning der har ændret links eller titel, en sletning. Hele kæden følger med, ikke kun første led, med et loft på hundrede noter — "del denne ene note" må ikke kunne blive til fire hundrede. Rollen arves fra den note, man kom fra, og stærkest vinder, når en note kan nås ad to veje. Kun ejerens egne noter følger med, og det er ikke en optimering: et link peger på en titel, og en medredaktør må skrive titler. Kunne et link hente hvad som helst, kunne den, man har delt med, skrive [[Bankoplysninger]] og læse med. Derfor slås der kun op blandt ejerens egne noter, og derfor regner kun ejerens egne gemninger om. Begge dele har en Go-prøve. Det lukker ikke hullet helt: skriver medredaktøren linket, og gemmer ejeren bagefter sin egen note, følger den note med dér. Det, der står imod, er synlighed — linket står som tekst i ejerens egen note, og panelet viser hver note, der er fulgt med, og hvem der har den. Udregningen åbner hver af ejerens noter, fordi titlerne er forseglet. Derfor to værn: har man ikke delt noget, svares der med det samme ud fra ét EXISTS, og en gemning regner kun om, når links eller titel faktisk har flyttet sig. Uden det første kostede "Ny note" halvfems millisekunder, og i det hul nåede e2e-prøven for monospace at taste sin titel ind i den forrige note, som editoren så tegnede væk. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013r4DxpUZcSShxfCZZaeMGZ	2026-09-07 22:28:58 +02:00
kristianwindandClaude Opus 5	4bbc49fe7e	fix(notes): export the notes in a stable order ... AllNotes returns newest-first by the second, so two notes written in the same second have no order between them — and the notes export walks that list assigning filenames, giving the first note of a name the plain filename and the next the "(2)". With the order undecided, which of two same-titled notes got which name was a coin toss that landed differently on each export, and the export test failed roughly one run in three. Sort the export by when each note was made, with the id to break a same-second tie. The first note of a name keeps the name; the archive is the same twice running. Ids are time-ordered, so the tie-break agrees with creation order rather than fighting it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 12:39:11 +02:00
kristianwindandClaude Opus 5	91671a4f97	feat(notes): share a note with a person, not only through a project ... Until now a note was shared exactly one way: file it in a shared project, and everyone who could read the project could read the note. That is right when the note belongs with a body of work and wrong when it is just "let Sofie see this" — it made you stand up a project to hand over a single page. A note can now be shared with named people directly, at viewer or editor — the same two roles a project membership uses, so there is one idea of a role in the program and not two. The paths stack: a note can be loose, filed, shared with people, or any mix, and access is the most any of them allow. The store: - note_shares (migration 0030): note ↔ user ↔ role, one row per person, owner recorded. Visibility (AllNotes, and search via mayTouchNote) widens to include notes shared directly with the reader. - the effective role folds a direct share on top of the owner and project paths. The rules, drawn where they protect the owner: - read = viewer, edit text = editor, on any path. - MOVE a note (change its project) is owner-only: an editor filing it into a project the owner is not in would take the owner's own note away from them. - DELETE is owner or project-editor — a direct share, however high its role, does not reach to throwing the note away. - SHARE and UNSHARE are the owner's alone, like a project's invitations. - the picker is everyone on the instance (a closed, invited set) minus who is already on the note; a made-up id and the owner themselves are refused. The list: - a "Delt med mig" group at the top, collapsible, that appears only when it has something in it — the same rule Favoritter follows — so it costs nothing when you share nothing. A shared note lives there, not also in a time bucket. - every shared note carries a small chip in its owner's avatar colour, the project mark's shape said for a person. - no star or archive button on a note somebody else owns: those change the note itself, and it is not yours to put away. - the editor grows a "Del med personer" panel for the owner: who can see it, at what role, and an add row drawn from the instance's other people. The old comment in the notes footer argued against a note having an access list of its own. That was the right call until the case it did not cover — sharing without a project — turned out to be the one actually asked for. Updated to match. Person now carries json tags, so a note's owner serialises as id/name/avatar_color like every other person in the API rather than as Go field names. Tests: a shared note reaches the other person marked and owned; a viewer reads but cannot write; an editor writes but cannot re-share or delete; unshare removes access and is owner-only; the candidate list excludes who is already on and the owner; and a made-up id and self are refused. OpenAPI covers the three new routes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 07:36:55 +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>	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>	2026-08-20 10:36:35 +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>	2026-08-20 08:39:52 +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 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>	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>	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>	2026-08-19 22:02:20 +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>	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	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>	2026-08-19 18:36:31 +02:00
Kristian WindandClaude Opus 5	1bbae698d5	feat(notes): en note deles ved at ligge i et projekt ... Ikke en adgangsliste af sin egen. Projekter har allerede medlemmer, roller og invitationer — alt sammen afprøvet, og alt sammen noget folk har lært her i forvejen. En anden måde at give adgang på er et andet sted at gøre det forkert, og de to ville være uenige den dag, den ene blev ændret. To ting, prøven fandt, som begge var rigtige fejl. Projektsiden viste kun noter, der NÆVNTE projektet, ikke dem, der lå i det — så en note, man lige havde delt derind, dukkede ikke op. Nu vises begge slags. Og noteoversigten viste kun dem uden projekt, så en note forsvandt fra listen i det øjeblik, den blev delt. Det fik deling til at se ud som sletning. Listen viser nu alt, man kan se: sine egne løse, og dem i de projekter, man er med i. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 17:03:28 +02:00
Kristian WindandClaude Opus 5	fbfc98e217	feat(notes): noter kan nås — listet, søgt og fundet baglæns ... Anden etape. Handlere, ruter og OpenAPI. Adgang følger projektet, for det er der, noten bor: en note i et delt projekt kan læses af alle, der kan læse projektet, og ændres af en redaktør. En note uden projekt er sin forfatters alene — samme svar som en opgave i indbakken får, nået frem til på samme måde frem for ved en regel, noter fandt på for sig selv. Listning og søgning er samme endepunkt, fordi de svarer på det samme spørgsmål med forskellige ord. Filtreringen sker EFTER indekset: FTS5 svarer om tekst, og at lære indekset om roller ville lægge en adgangsregel et sted, ingen ville kigge den dag den var forkert. Der er en prøve for, at en fremmeds søgning ikke finder noget, og at en fremmed får 404 og ikke 403 — så et id ikke kan afprøves. Den baglæns rute hænger på det, der spørges om: et opgave-id giver hver note, der nævner den; et projektnavn giver hver note med det #tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 13:00:41 +02:00