kristianwindandClaude Opus 5
b18d9a26e6
Retur-handleren udskyder rettelsen ét hak, fordi der før delingen ikke er nogen ny blok at rette. Men rettelsen spurgte, hvor markøren stod *nu*, og et hak er nok: skriver man hurtigt, er næste retur nået igennem først, og så stod markøren i den NÆSTE blok. Så rettede den den — to gange — og lod den blok, rettelsen var ment for, stå tilbage som browserens bare <div>. En <div> læses som brødtekst og er ikke formateret som en, så afstanden mellem afsnit forsvandt stille, hos netop de brugere der skriver hurtigst. Målt frem for gættet: "flere markerede afsnit bliver til én monotypeblok" faldt på en CI-runner med alle tre linjer skrevet rigtigt, hvor "linje et" var en <div> og "linje to" og "linje tre" var <p>. Rettelsen er delt efter hvad der er sikkert at røre: * Der hvor markøren står, gør execCommand det fortsat. Det er den, der lægger ændringen i browserens fortryd-historik, og filen vælger den bevidst andre steder af samme grund — ⌘Z skal tage afsnittet tilbage, ligesom den tager et ord tilbage. * Den blok, delingen lige skabte, får samme regel uden markør at låne. Den dækker overskriften: retur for enden af en overskrift efterlader endnu en overskrift i de fleste browsere. * Og hver <div> i noten bliver fejet op. En <div> er altid browserens egen beholder og aldrig nogens valg, så den kan rettes hvor som helst. En <h1> bliver IKKE fejet: menuen har en Titel-stil, så en overskrift midt i en note kan være en linje, nogen selv har valgt, og den er deres at beholde. Fejning frem for et håndtag til blokken, og det er målt: når den første udskudte rettelse bytter tagget, peger den næstes håndtag på en node uden for dokumentet, og blokken midt i kæden bliver aldrig rettet. Prøven planter to efterladte blokke og er kontrolleret i tre retninger — ingen rettelse: 2 efterladte <div>, håndtag til blokken: 1, fejning: 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
web
The SvelteKit PWA. Not written yet — this directory holds its place so the Docker build has something to copy, and so the frontend stage can tell "not built yet" apart from "the build failed".
The Dockerfile builds this directory when it finds a package.json here, and
otherwise emits a placeholder page. So adding the real app is exactly: put a
SvelteKit project in this directory whose npm run build produces build/.
What it needs to be
- SvelteKit,
adapter-static, output inbuild/. The Go binary embeds that directory at compile time and serves it, falling back toindex.htmlso client-side routes survive a reload. - A PWA: installable, offline reading of already-cached lists, swipe gestures for complete and schedule.
- Nordic minimalism. Dark by default, light available. One accent colour, everything else neutral. Runic mark for Verdande.
- Optimistic on every local action. No spinner ever appears for something the browser could already know the answer to.
Talking to the backend
Same origin — the Go binary serves both. /api/v1 for REST, /api/v1/ws for the
live sync. Session cookie is httpOnly, so the frontend never handles the token
itself.
During development, run the backend on 8080 and point the Vite dev server's proxy at it:
VERDANDE_DATA_DIR=./data VERDANDE_DEV=true go run ./cmd/verdande