Kristian WindandClaude Opus 5
fc32fea607
Release / Build and publish image (push) Failing after 9m53s
Two things from the same report — an external member who could see a project but could not get work into it. **A section with no tasks could not be filled by dragging.** Only the task rows accepted a drop, so the target was always another row; a section with none had nothing to aim at, and a section you have just made is empty by definition, which is exactly when you want to put something in it. The board has taken a drop on the column since it was written. The list now does the same: the section is the target, and a drop on it puts the task at the end. Dropping on a row still means "here exactly" and stops there rather than bubbling to the section behind it. The unsectioned block at the top is a target too, which is how a task comes back *out* of a section — previously only possible if some other loose task happened to be there to aim at. **And the page said "Projektet findes ikke, eller du har ikke adgang til det" for three different things.** `project` started null with no loading state, so that sentence was what you saw before the first request returned, what you saw when it failed, and what you saw when you genuinely had no access — and the effect never asked again, so the wrong one stayed until somebody reloaded. That is very likely what was reported: the container was restarted twice while people had the app open, and a request that lands mid-restart leaves the page insisting the project does not exist. Four states now. Loading renders nothing, as the shell does. 404 keeps the old sentence, since the server deliberately answers 404 for both "no such project" and "not yours" and the interface must not guess between them. Anything else says the request failed and offers to try again. What is *not* a bug: a viewer cannot create or move tasks. Checked at the API — an editor invited by link gets 201 on create, 201 on quick add and 200 on a move into a section; a viewer gets 404 on all of them, which is the rule working. If the person reporting this cannot add tasks, their membership is viewer rather than editor. 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