271 Commits

Author	SHA1	Message	Date
Claude Fable 5	3bf9363c34	Merge and split table cells (#337) ... prosemirror-tables already ships mergeCells/splitCell and the schema (tableNodes) already carries colspan/rowspan -- only the controls were missing. Adds the two commands, toolbar buttons whose enabled state follows the selection (merge needs a multi-cell selection, split a merged cell), and de+en labels. Both render paths now carry the spans: docToHtml emits colspan/rowspan (read mode, exports via the HTML path), and the markdown serializer pads a colspan with empty cells so every row keeps the table's column count -- rowspan stays lossy there, GFM cannot express it. e2e drives merge and split through the toolbar; the cell selection is made per Shift+Click because a keypress in the same tick as the preceding click races the editor's post-click rendering (keyboard cell selection itself works, verified interactively with a settled editor). Closes #337 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aoPvnakfBP28nAfijgUY9	2026-08-15 21:32:14 +02:00
Claude Fable 5	b1165a37e6	Unambiguous delete row/column toolbar icons (#336) ... The delete buttons paired the minus-box with a double arrow (bidirectional arrows next to the symbol) which reads as "resize/expand", not "delete". Replace them with axis stripes plus the x delete marker that deleteTable already established: vertical stripes with x for delete column, horizontal stripes with x for delete row. Labels/tooltips were correct all along and stay unchanged. Closes #336 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aoPvnakfBP28nAfijgUY9	2026-08-15 20:44:37 +02:00
Claude Fable 5	69563348ca	Gap cursor for block-edge positions (#335) ... A table (or any other block node without a text position of its own) as the page's first, last, or only block was unreachable from before/after: neither mouse nor arrow keys could place the cursor there, so no paragraph could be created around it. - add the prosemirror-gapcursor plugin as a TipTap extension (via @tiptap/pm, no new dependency; schema-neutral, so the editorSchema drift fence is unaffected) - style the gap cursor bar in base.css -- the upstream package does not ship its stylesheet through our import path; the blink animation honors prefers-reduced-motion - e2e: keyboard-only round trip that creates paragraphs before and after a lone table Closes #335 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aoPvnakfBP28nAfijgUY9	2026-08-15 20:41:23 +02:00
Claude Fable 5	7e17a2dba6	settings-nav fence: 10 sections since the invitations section (#332)	2026-08-05 13:06:32 +02:00
Claude Fable 5	c2a4dde5cc	Invitation flow with per-user quota (#332) ... Any authenticated user can invite an e-mail address; the mailed single-use token lets exactly one signup through even while registration is closed. Open (pending, unexpired) invitations count against the new instance setting invitations.maxOpenPerUser (default 5, 0 disables inviting) — plus a 20/day per-user rate limit so a revoke-and-recreate loop cannot become a mail cannon. Only the SHA-256 token hash is stored (auth-tokens pattern); a failed signup (taken username) un-redeems the token so the invitee can retry. Surfaces: invitations section in the user settings (list, invite, revoke, quota line; wide table in a focusable .table-scroll region), signup page reads ?invitation=<token> (preview banner, e-mail prefill, closed-mode gate opens only for a previewed-valid token), admin general card gets the quota field (flat RHF name per #322; VS-NfD marked and hideable). Governance: audit actions invitation.created/revoked/accepted (catalogue 1.10), VS-NfD profile entry (compliant: 0) + hardening-guide row, i18n de+en including the invitation mail template. Tests: api e2e-db (mail link, closed-mode single-use signup with un-redeem on failure, quota + revoke frees slot, quota 0 = 403, auth matrix), new web e2e pack invitations.spec.ts (full UI loop through Mailpit, wired into ci.yml with its own rate-limit reset), a11y scan waits for the new section. Full api suite (107 files / 607 tests), auth/admin-settings/a11y packs green against a fresh local stack. Closes #332	2026-08-05 12:44:20 +02:00
Claude Fable 5	9cf7b85b93	Admin can create user accounts directly (#331) ... POST /admin/users (Site-Admin guard) creates an account with the same field rules as self-registration, but active immediately: the admin vouches for the address, so the e-mail is marked verified and the personal pond is provisioned exactly like the verify-email path does (markEmailVerified alone would skip the pond). The user manager gains a create dialog (useModalFocus/useDismissable, Field wiring, flat RHF field names per the #322 lesson). New audit action user.created_by_admin, catalogue bumped to 1.9. Tests: api e2e-db (create + immediate login + personal pond, duplicate username 409, non-admin 403), web e2e through the dialog, and the admin a11y scan now opens the dialog too. Both packs verified locally against a fresh stack. Closes #331	2026-08-05 12:23:01 +02:00
Claude Fable 5	64f2deb40f	Quota override cell stays a table cell, flex on an inner wrapper (#329) ... Same defect and same fix as the user list's actions cell (#177): display:flex directly on the override td removed its table-cell behaviour, so the cell stopped growing to row height and its bottom border no longer met the row's — visibly uneven separator lines (Stefan's screenshot from the self-hosting walkthrough). The flex layout now lives on .quota-row__override-inner. Measured locally like #177: bottom-delta across all cells of every quota row was 24–49 px before, 0 px after (override set, so the cell carries input + two link buttons); admin-quotas e2e pack green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-04 12:44:17 +02:00
Claude Fable 5	20677ea247	Self-hosting findings: URL-safe password advice, operator-readable pre-seed errors (#324, #325) ... Two findings from Stefan's manual clean install per the guide, both ending in an api restart loop that was hard to diagnose: - #324: the guide recommended `openssl rand -base64 32` for POSTGRES_PASSWORD, but the compose interpolates the password unescaped into DATABASE_URL — base64's `/`, `+`, `=` break the URL. Misleadingly, db stays healthy (it gets the password as a plain env var) while api/collab/backup crash. Guide and .env.example now recommend `openssl rand -hex 24` for both secrets and say why; Troubleshooting gained the symptom line. - #325: SETUP_ADMIN_PASSWORD's minimum (10 chars, packages/shared/src/auth.ts) was undocumented, and a violation crashed the boot with a raw ZodError naming schema fields and i18n keys. Failing the boot stays — deliberately, no half-seeded instance — but preseedFromEnv now translates validation errors into operator terms ("Pre-seeding failed: SETUP_ADMIN_PASSWORD must be at least 10 characters. Fix .env and recreate the api container."). Documented in the guide's first-run section, .env.example, and Troubleshooting; new test pins the message and that nothing is half-seeded afterwards. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-04 12:44:16 +02:00
Claude Fable 5	6999b3dd73	Document title follows the configured instance name (#323) ... useDocumentTitle pinned APP_NAME = 'Dorfteich', so every route title — tab, bookmarks, the window title a screen reader announces (WCAG 2.4.2) — named the product instead of the operator's instance. The trailing name now comes from the public branding query, exactly like the TopBar brand (#306); until the query resolves (or when it cannot, e.g. maintenance mode) the shipped default keeps the title stable, so an untouched instance reads exactly as before. The static index.html title stays the pre-JS placeholder — server-rendering it is #179's territory, deliberately out of scope (recorded in the issue). The admin-settings e2e now also asserts the title carries the new name right after saving, without a reload. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-04 11:43:05 +02:00
Claude Fable 5	4d6a27194f	Follow the field rename in vs-nfd-marking locators ... The pack addresses the registration-mode select by its DOM name attribute, which react-hook-form derives from the field name — now `registrationMode` (dot-free, see admin-settings-form.ts). Caught by CI run 713; the pack needs VS_NFD_MODE stages and was not part of the local verification set. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-04 11:42:55 +02:00
Claude Fable 5	9f754649d4	Fix admin general settings form: dot-free field names, flat PATCH keys (#322) ... The general and quota cards registered their react-hook-form fields under the dotted settings keys. RHF treats dots as nested-path separators, so the form DISPLAYED fine (its getter falls back to the literal flat key) but typing nested the value ({ instance: { name } }) and the api's strict PATCH schema rejected the body — none of these fields ever saved through the UI, on any instance. Found by Stefan on a fresh self-hosted install. - admin-settings-form.ts: dot-free form model with one explicit mapping to the dotted settings keys and converters in both directions; the submit now also carries ONLY the settings these cards edit, so the internal branding metadata keys never ride along. - Saving invalidates the branding query too — the TopBar reads the instance name from it and kept the old name until its staleTime ran out. - admin-settings.spec.ts (new e2e pack, registered in ci.yml): drives the rename THROUGH THE FORM — success message, TopBar update without reload, value survives reload, api returns it. Verified locally to fail against the unfixed page and pass against the fix. Every existing admin-settings test patched the api directly, which is why this bug was invisible to CI. - admin-settings-form.test.ts pins that no form field name contains a dot and the mapping round-trips. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-04 11:18:26 +02:00
Claude Fable 5	78258c4f9b	test: give the 10k-iteration sort-key property test its own timeout ... Under parallel CI load the test repeatedly exceeded the default 5000 ms per-test timeout (run 685 on main, run 699 on an unrelated PR); the identical test passed on rerun. Locally it finishes in about 1.3 s, so 30 s is generous headroom, not a mask for a regression. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P	2026-08-02 14:01:14 +02:00
Claude Opus 5	a327126fac	#307: pond-level branding overrides the instance logo and favicon ... Built on #306's storage, serving and crop control — a layer, not a parallel implementation. `resolveBranding` in shared is the ONE place that answers "which asset applies here?", and both the sidebar logo and the favicon swap read it. The decision most likely to be "fixed" by accident, so it is pinned by name in `branding.test.ts`: **a logo set belongs to one level and variants are never mixed across levels.** A pond that uploaded only a light logo shows THAT logo in dark mode; it does not borrow the instance's dark variant. Decided 2026-08-01 — a logo silently swapping to a different image when the viewer switches theme is a change nobody ordered, and a design that looks wrong is more honest than one that is quietly substituted. Only a pond with no logo at all inherits the instance's set, again as a set. The settings screen warns about a missing dark variant; it never blocks. Consequences that fall out of that rule and are easy to get wrong: - The serving route does NOT fall back when given a pond scope. The caller already decided which level applies; a "helpful" fallback in the route would mix variants across levels behind the resolver's back. - The logo link's accessible name follows the LEVEL: a pond logo is named by the pond, an instance logo by the instance. It is the link home, and a link's name has to say where it goes. - **Charged to the pond's storage quota**, before the write, like attachments. Without it branding would be a way around the quota, and replacing a logo repeatedly would consume disk with no ceiling. The replaced asset's bytes are released FIRST, so re-uploading the same logo costs nothing — and a refused upload puts the released reservation back, so a rejection cannot leave the pond with more room than it had. - **Purge removes the branding files.** The purge standard is absolute: after it nothing referencing the pond survives, rows or files. Asserted against the real purge path, not the new code alone. - Security unchanged from #306 and not relaxed because the uploader is now an ordinary Pond Admin: SVG refused, magic bytes and IHDR checked server-side, size caps, content type pinned, no image parsing. - The favicon swap is driven by the RESOLVED pond, never the raw route parameter — an unreadable or unknown slug must not leave a stale icon in the tab. That it happens after first paint is accepted and stated in the code and the UI: avoiding it would mean server-rendering index.html, which is #179's territory. Same audit id as #306 (`branding.changed`) with `scope: 'pond'` — the catalogue already carries the field, so no version bump. Verified: api suite 105 files / 592 tests green; 5 pond-branding e2e tests (pond scope serves the pond's bytes while the instance level still 404s, the quota is charged and released exactly, SVG refused at pond level, a reader may read but not change, purge deletes the files); 9 shared unit tests on the resolution order including both mixing directions.	2026-08-01 20:44:02 +02:00
Claude Opus 5	3310ae3926	#305: a full pond archive before deletion and before purge ... Deleting a pond already had a strict prompt — typing the pond name, stricter than a confirm dialog. That was never the gap. The gap is that the person who deletes it loses access the moment they do: the pond leaves their view, only a Site Admin can bring it back, and the export is no longer reachable for them. So the archive is offered INSIDE the deletion flow, before the button. What it contains, and why it is not the existing export: - Every page the requester may read, as Markdown, as before. - **Every attachment of the pond**, not only the embedded ones. An attachment nobody put on a page would otherwise vanish unnoticed — which is the whole reason this issue exists. - `manifest.json`: pond settings (EFFECTIVE, defaults filled in — a preservation format must not require its reader to know Dorfteich's defaults), labels, the page hierarchy and sort keys, comments, and attachment metadata including the #199 hash so a reader can verify bytes. It extends the #210 manifest rather than adding a second descriptor, and carries an explicit `formatVersion`. - `README.txt`, because the manifest is for machines: whoever unpacks a folder of Markdown a year from now must not believe they hold a one-click restore. Decisions worth naming: - **"Complete" describes the RESULT, not the route.** A pond admin who may read every page gets `complete: true`; only an archive that actually leaves pages out is incomplete. The Site-Admin route skips the read filter (an archive taken before an irreversible purge must not depend on which ponds the operator happens to be a member of) — those are two different questions and the first version of this conflated them. - **The omission is named before the download**, with its number, in the UI and in the manifest. An archive silently missing content is worse than no archive, because it ends the search. - **Not downloading stays allowed.** A pond of test pages should not require one, and the server cannot tell whether a file arrived anyway — so the finality is stated in text instead of enforced. - **A plain link, not fetch-into-a-blob.** The api streams the ZIP; buffering a whole pond in the tab to draw a progress bar would trade memory for cosmetics. The browser reports progress and completion; what it cannot say — that the archive is being BUILT — is announced in a live region. - Read trail unchanged in kind (ADR 0023): one `export` event per classified page before any classified byte enters the stream. Attachments never travel without their page, so the same events cover them. - New audit action `pond.archived` (catalogue v1.7) with page and attachment counts, omitted pages, and completeness. Format documented in `docs/architecture/pond-archive-format.md`, including what is deliberately NOT in it (history, permissions, trash). Verified by hand, not only asserted: a real pond's archive downloaded and unpacked — README, manifest, three page files, the media file; the manifest's effective settings, per-page classification, the VS-NfD frontmatter and marking preserved in the classified page's Markdown, and the attachment's sha256 present. Plus six api tests (including that an unembedded attachment travels and that a Site Admin gets a complete archive without membership) and the a11y pack 11/11 in both schemes, which now also scans the pond settings screen. Not done, because there is nothing to attach it to: the Site Admin's purge dialog (#193) exists only as an api endpoint — there is no pond-trash UI in the web app. The api half is here and tested, so it becomes a link when that screen is built.	2026-08-01 20:24:35 +02:00
Claude Opus 5	8752cf0c5a	#179: negotiate the SPA shell's lang attribute in nginx ... `apps/web/index.html` carries a hard `lang="en"`. The app corrects it at runtime (#163), but nginx answers every SPA route with that same file, so a crawler or a no-JS visit — `/public/...` on prod is exactly that — saw `en` for German content, permanently. WCAG 3.1.1 is about the delivered document, not the one JavaScript later fixes. nginx-only, no backend involved: a `map` on `Accept-Language` and a `sub_filter` in the index.html path. Only the FIRST tag decides, which is what "the browser's preferred language" means and mirrors #163 — `de-CH` counts as German, `en-US,de` does not. `Vary: Accept-Language` is new. The response now genuinely depends on a request header, and without it a shared cache could hand one language's copy to the other. Everything else in the location is untouched: same CSP, same `Cache-Control: no-cache`, same `nosniff`. The known limit is documented in the config rather than worked around: nginx cannot read `instance.defaultLocale`, so an unlisted or absent Accept-Language yields `en` even on a German instance. For public content that is not the authoritative rendering anyway — the api's server shell (`/api/v1/public/...`) already renders those with the instance locale. Verified against a real nginx 1.27 (the image the stage runs) with the config mounted as-is: `de-DE,de;q=0.9,en;q=0.8` and `de` yield `lang="de"`; `en-US,en;q=0.9`, `en-US,en;q=0.9,de;q=0.8`, `fr-FR,fr` and a request with no header yield `lang="en"`; an SPA route (`/public/teich/seite`) negotiates the same way; the gzipped response is rewritten too, and a JavaScript asset comes through byte-identical.	2026-08-01 20:01:53 +02:00
Claude Opus 5	6377faf332	#306: instance branding — logo and favicon, cropped in the browser ... An instance had no way to look like itself: the top bar said "Dorfteich" whatever the operator called their instance, `instance.name` was never rendered in the running app at all, and there was no favicon anywhere — `index.html` had no `<link rel="icon">` and `public/` held only fonts and theme-init.js. Where the line is drawn, and why: - **The api never decodes an image.** Cropping, scaling and the conversion to PNG happen on a canvas in the browser; the api checks the PNG signature, reads the IHDR dimensions at their fixed offsets and enforces the caps. An image library would put a decoder in front of attacker-supplied bytes AND would have to be carried through the `--network none` offline build. Reading two big-endian integers is not decoding. - **SVG is refused**, with its own error message rather than a generic "not a PNG": it can carry script, and serving it from our own origin would be a cross-site-scripting vector. An operator who tried one should learn that it is deliberate. - **The crop is driven by number inputs, not by dragging.** A drag-only cropper excludes keyboard and switch users outright; a number input is arrow-key operable and screen-reader readable without any custom aria. The resulting pixel size is stated in text, not only drawn as a frame. - **The variant is chosen by CSS, not JavaScript.** `theme-init.js` has already resolved `data-theme` before first paint, so the correct logo is the one painted rather than the one that appears after a flash. Without a dark variant the LIGHT logo carries both themes — the operator's own asset shown unchanged beats one they did not choose (the rule #307 extends to ponds). The settings screen warns; it never blocks. - **The favicon link is static, its resource dynamic.** index.html stays a static file and the api answers with the uploaded icon or a shipped default — that route must never 404, or the browser keeps its generic icon for good. The default is generated by a script from Node's own zlib (`gen-default-favicon.mjs`), for the same offline-build reason. - Both favicon sizes are uploaded together: one source, one crop, so the tab icon and the home-screen icon can never disagree. - Branding is served WITHOUT a session, because the login screen carries it and the browser fetches the favicon before anyone signs in. The admin screen says so — an operator may not expect their logo to be public. - The metadata is not writable through the settings endpoint: it describes bytes on disk, and hand-writing it would claim an asset that is not there. `./data/branding` follows the three-step rule #303 paid for: env default + `data-dirs.ts` entry, compose volume (repo AND the stages on ONE), and the `mkdir`/`chown` line in the api Dockerfile. `data-dirs.test.ts` is new and closes the hole that made #303's variant invisible: the nightly archive skips a missing directory WORDLESSLY, so the fence now demands that every `*_DIR` the backup env declares actually travels in the archive. Verified against the real defect — removing the line fails it by name. Audit catalogue v1.7 (`branding.changed`), carrying `scope` from the start so #307 is the same event with a different scope, not a second id. Verified: api suite 103 files green (a lone `public-api` ECONNRESET under local parallel load, green in isolation — the documented local flake); branding suite 12 tests against a real directory; crop arithmetic unit tests; a11y pack 11/11 in both schemes; /admin measured at 320px with the new section (overflow 0); and the whole flow walked in the browser: upload → crop 780×180 → stored as 512×118 → logo in the sidebar linking home with the instance name as its accessible name → topbar wordmark following `instance.name` → light logo still shown under `data-theme="dark"`.	2026-08-01 19:30:52 +02:00
Claude Opus 5	942f7b13d3	#304: scope the legal spec's status locator to its own form ... The font manager's upload live regions made `getByRole('status')` ambiguous on /admin, and legal.spec.ts — which asserts the legal form's success message — started failing in the e2e pack. That is the documented trap in CLAUDE.md: a new label or region makes an existing page-wide locator ambiguous, and the fix is to scope the SPEC, not to drop the region a screen reader needs. The section gets a named class for exactly that purpose. Verified locally against the running stack: legal, fonts, admin-users, admin-quotas and the a11y pack all pass.	2026-08-01 19:05:18 +02:00
Claude Opus 5	ee6a11f9b0	#304: declare the font-list route's access rule explicitly ... The route-permission fence (#52) failed in CI, not locally: I had run the fonts and import-export suites, not the full api suite, and that fence needs a database. `@AuthenticatedOnly()` is the rule the route always meant — a session, no further permission. Re-verified with the FULL api suite against a fresh database: 103 files / 575 tests passed.	2026-08-01 18:46:47 +02:00
Claude Opus 5	f8c241b11a	#304: custom fonts in the pickers, an admin screen, and the licence page ... The backend from #303 could store an operator's font but nothing could choose one: no list endpoint outside the Site-Admin routes, no @font-face rules for a family that only exists at runtime, and no management UI. Found while wiring it up — a real defect in #303, invisible to its tests: `fontStack` cannot tell an uploaded family from a deleted one, so the PDF exporter embedded the face and then never named it. Every export of a pond using an operator font rendered in the system font while the job reported success. Both `fontStack` call sites now take the uploaded families (`buildPdfHtml`, `pondFontVariables`); `pdf-html.test.ts` pins the regression from both sides. Verified against a real Gotenberg: with the families the PDF embeds PlayfairDisplay-Bold, without them NotoSans-Bold — that was the whole bug, in one diff of two PDFs. - `GET /fonts/custom` is readable by any signed-in user, not Site Admins only: the pickers, the licence page and the injected `@font-face` rules all need it, and gating it would have forced a second, admin-only UI. - Bundled and uploaded families are told apart by their `<optgroup>`, not by a badge — the grouping is then part of the control's semantics, so a screen reader announces it and the native mobile select keeps it. Within each source the catalog's category grouping is preserved. - The delete confirmation names how many ponds use the family and what happens to them; focus moves to it and back on cancel. Deletion stays unblocked (the api's decision, #303) — the ponds degrade, they do not break. - The licence page grew a second table. That is what makes an attribution obligation satisfiable: a commercial licence that requires naming the foundry needs a page to name it on. Verified in the browser end to end (upload two weights → listed and rendered in its own font → chosen in a pond → page renders in it → deleted → pond falls back): api suite for fonts/export 77 passed, a11y pack 11/11 locally in both schemes, lint/typecheck/i18n:check green.	2026-08-01 18:32:46 +02:00
Claude Opus 5	485c8fa538	#303 follow-up: the fonts volume must mount node-owned ... Found on the real deploy, not in any test: `/data/fonts` in the running api container was `root:root` and the non-root `node` user could not write to it. Every upload would have failed with EACCES at runtime while the api reported ready. The api Dockerfile already explains the mechanism for uploads and plugins — Docker copies an image directory's ownership into a fresh named volume on first mount — and pre-creates them chowned. #303 added `CUSTOM_FONTS_DIR` to the ENV but not to that mkdir/chown line. Adds a CI fence so it cannot recur: every `/data/…` path the api image defaults to must also appear in the mkdir AND the chown. Verified against the actual defect — removing `/data/fonts` from the chown makes it fail.	2026-08-01 15:12:06 +02:00
Claude Opus 5	b96997501a	#303: operator-uploaded fonts — storage, API, PDF embedding, backup ... An operator holding a font licence could only use it by baking the file into a custom image, which tied every change to a rebuild and left the file out of the backup. ADR 0016 said there is no runtime font management. It also listed this exact case under "Alternatives considered" — *may become a Site-Admin- level feature later*. The amendment takes that option and answers the two objections it raised: licensing risk (Site Admins only, licence recorded with the family) and file-format attack surface (magic-byte check and a size cap, never a parse). - `CUSTOM_FONTS_DIR` (default `./data/fonts`) — a sibling of uploads and plugins, NOT inside the image-baked `FONTS_DIR`, where a deploy would overwrite it and no backup would ever see it. - One list of data directories (`apps/backup/src/data-dirs.ts`) now feeds both the nightly archive and the restore, so they cannot drift. #306 and #307 add one line each instead of a second mechanism. - Both Dockerfiles bake the path. The backup image sets its volume paths itself ("self-sufficient without compose env" — #71's lesson) and reads no *_DIR from compose; without the ENV entry the archive would have skipped the directory silently. - The PDF path already read WOFF2 from disk at request time, so it only had to pick the other base directory for a custom family. - `fontStack`/`fontEntry` take the instance's uploaded families as an argument — they are runtime data. The catalog is searched first, and a colliding family name is rejected at upload, so a custom font can never shadow a catalog one. - Deletion is never blocked by usage: an unknown family already falls back to the system stack, so affected ponds degrade instead of breaking. The count of affected ponds travels into the audit entry. - Audit catalogue v1.6 (`font.uploaded`, `font.deleted`). Verified: api full suite against a fresh database, 102 files / 571 tests. The upload suite writes into a real temp directory and reads the bytes back off disk, so the storage layer is exercised rather than mocked.	2026-08-01 14:49:13 +02:00
Claude Opus 5	69882ecbea	#301: the token tables need the same scroll wrapper ... The sorted report finally named it: `table.api-tokens__table` at 833px wide, with its `.visually-hidden` heading reaching right=737 — exactly the document's scrollWidth. Same mechanism as the sessions table, a second table I had not wrapped. Locally the API-tokens table was empty and therefore narrow, which is why this only ever appeared in CI. With a token present it reproduces: without the wrapper 345px of page overflow, with it none. The feed-token table gets the same treatment — it is built the same way and would fail as soon as someone holds a feed token with a long name. The "[in fitting scroller]" marker in the report is misleading for these: `main.main` is a scroller, but it is `position: static`, so it never clipped the absolutely positioned heading. Only a positioned ancestor does — which is what `.table-scroll` now is. Verified locally against a real stack, with a wide token table present: reflow guard green, whole a11y pack green in both colour schemes.	2026-08-01 12:31:30 +02:00
Claude Opus 5	2422f3a28f	#301: sort the reflow report so the culprit cannot be buried ... CI still reports 737 while the local stack is now clean, and the box list was capped at 15 entries — all of them nav links clipped by their own scroller. Whatever pushes the page in CI sits past that cap. The list is now sorted by reach, marks each entry as either clipped by a fitting scroller or actually pushing the page, and shows 40.	2026-08-01 12:31:30 +02:00
Claude Opus 5	b65339ae13	#301: the overflow was an escaping visually-hidden heading ... Found by standing up the local stack instead of guessing through CI. The DOM tree under `.app-body` shows it in one line: span.visually-hidden rect=[342,343] pos=absolute Its right edge is 343, and `.app-body` reports scrollWidth 343 against a 320 client. The table's actions column carries a `.visually-hidden` heading, which is `position: absolute`. `.table-scroll` was `position: static`, so it was NOT that span's containing block — the span escaped the scroller's clipping, kept its static position out at the table's right edge, and pushed the page. `position: relative` on the wrapper makes it the containing block, and the span is clipped like the rest of the table. This is one cause behind both numbers: 23px locally, matching the original report, and 417px in CI, where different font metrics make the table wider and carry the span further out. Chasing them as separate problems is what cost three CI rounds. Verified locally against a real stack: the reflow guard passes and the whole a11y pack is green, 11 tests in both colour schemes.	2026-08-01 12:31:30 +02:00
Claude Opus 5	194f144797	#301: dump raw box metrics from the reflow guard ... Two rounds now reported no element past the viewport edge while the document still claimed 417px of overflow — a combination that rules out every hypothesis I had, including my own filter. So stop inferring. The guard now prints the html/body metrics, every element whose own content is wider than its box (with its overflow-x, so the intentional scrollers are distinguishable), and every box reaching past the edge with no filtering at all. Diagnostics ride in the assertion message, not the compared value, so they show up even when they match.	2026-08-01 12:31:30 +02:00
Claude Opus 5	9fce824a8e	#301: make the reflow guard report the ancestor chain ... The previous run came back with an empty offender list and an unchanged 417px overflow: the filter treated everything under a scroll container as innocent, including the container that was itself too wide. A scroller only absolves its children when the scroller fits. It now reports the chain from body down to the widest offender with each box's width, so the first element wider than the viewport is visible instead of inferred.	2026-08-01 12:31:30 +02:00
Claude Opus 5	18c2ed0bfe	#301: the real culprit was the jump nav, not the wide content ... The first attempt fixed plausible suspects. CI measured the actual page and named something else: six `.settings-nav__link` buttons, 417px of page-level overflow at 320px. `.settings-nav` already had `overflow-x: auto`, but as a flex child it also had the default `min-width: auto` — the min-content width of the whole jump strip. That forced the column wider than the viewport, so its own overflow rule never had anything to scroll. `min-width: 0` is exactly the case CLAUDE.md warns about under Reflow. The guard now ignores elements that sit inside a scroll container. Such content is *meant* to be wider than the viewport — reporting it buried the one finding that mattered under twelve lines of noise, and the cap truncated the list before it could show anything else. The table wrapper and the wrapping settings rows from the first commit stay. Neither was the cause here, but a table cannot shrink below its min-content width and those rows cannot wrap on their own, so both are hardening that holds regardless of content.	2026-08-01 12:31:30 +02:00
Claude Opus 5	f938ee9880	#301: stop /settings scrolling horizontally at 320px ... WCAG 2.1 SC 1.4.10 asks for no two-dimensional scrolling down to 320px, which is also what 400% zoom on a 1280px screen produces. The layout skeleton was already hardened for this in #165; the overflow came from content inside the sections. - The sessions table cannot shrink below its min-content width — four columns, one of them the full user-agent string. It now scrolls inside its own container rather than pushing the page. The container is focusable with a role and a name, because a scroll area that only a mouse can reach trades one barrier for another. - `.settings-checkbox` rows may wrap. The accent swatches have a fixed size and cannot shrink, so an unwrappable row set a floor for the whole page width. Adds a reflow guard to the a11y pack. axe does not cover 1.4.10 — the criterion is not derivable from the DOM — so this is a separate check, and it names the overflowing elements when it trips instead of only reporting that something overflows.	2026-08-01 12:31:30 +02:00
Claude Opus 5	f9149eba13	#302: the vault import test reaches its page through the sidebar ... The Obsidian fixture vault contains a note called "Startseite", and the pond now creates one too — the seeded fixtures use locale `de`. Two consequences, and the second is the one that mattered: - the unscoped title locator matched two sidebar entries; - `/p/<pond>/startseite` no longer belongs to the imported note. The pond's own start page took that slug, so the import landed on a suffixed one and the test was about to assert against the wrong page. Both are fixed by scoping to the mount page and navigating through the sidebar instead of guessing a slug. The test stays meaningful: it then clicks a wikilink inside the page content, which the empty auto-created start page would not have. CI caught this; the local run passed it. Worth remembering that a title-based locator can go green by luck.	2026-08-01 11:29:54 +02:00
Claude Opus 5	30fd1ff53b	#302: the permission matrix counts the start page ... Every pond created through the api now carries one, and the matrix pond is created that way. The start page is an ordinary page with no grant of its own, so it follows the pond-wide permissions: the three member subjects each see one more, the label-restricted editor too, and the outsider — who reaches only the explicitly public page — still sees one. The 429 in the same run was the login rate limit, reached through the retries of this failure rather than on its own.	2026-08-01 08:25:51 +02:00
Claude Opus 5	45f1925917	#302: configurable pond start page, created with every new pond ... Opening a pond landed on whatever sorted first in the sidebar — stable, but a rule nobody could see, and one whose target moved as soon as someone added a page ahead of it. New ponds landed on the empty-pond hint instead of anything useful. - `startPageId` joins the pond settings. No migration: `Pond.settings` is already jsonb. It stores an id, not a slug, so renaming or moving the page keeps it working. - `PondHomePage` prefers it, but only when the page is in this user's page list. That list already holds just what they may see, so a start page hidden by a page-scoped grant — or trashed — falls back silently instead of landing them on a 404, and it costs no extra request. - Both creation paths give the pond a start page, titled from the creator's stored locale. It happens after the creating transaction commits: the owner's grant is written inside it and permissions cache per pond, so creating the page any earlier would ask about rights the grant has not published yet. A failure is logged, not fatal — a pond without a start page still works. `PagesModule` imported `PondsModule` without using it. Removing that vestigial edge let PondsModule depend on PagesModule in the honest direction instead of tying the two together with forwardRef. Every pond created through the api now owns a page, which broke eight suites whose teardown deleted ponds directly — `Page.pond` deliberately has no cascade, because a real purge removes contents explicitly and audits it. A shared `deletePondsWhere` helper deletes pages first. Two tests that counted pages now account for the start page rather than pretending the pond began empty.	2026-08-01 08:06:35 +02:00
Claude Opus 5	5a4a99196e	#300: route icon-only controls through IconButton/IconLink ... The notification bell sat higher and larger than search and the theme toggle next to it. The cause was not the glyph: `.notifications-bell__button` carried its own rules with neither flex centring nor an icon size, so the svg was laid out inline on the text baseline and rendered at lucide's 24px default instead of the 1.15rem the shared `.icon-button` enforces. Route every icon-only control through the shared components instead: - `IconLink` joins `IconButton`, sharing one class helper. Three controls navigate (pond settings, graph, trash) and are links, not buttons — without a link twin they would have stayed the one group gluing the class on by hand. - 17 hand-applied `className="icon-button …"` usages across nine files now go through the components, which is what enforces the accessible name on a control that shows only an icon. - The bell's unread count reaches assistive technology. The badge sits inside the control, so `aria-label` hid it and a screen reader announced "Notifications" without ever saying how many. An ESLint rule keeps it that way: `icon-button` on a raw button, anchor or Link is now an error, in both string and template-literal form. The plugin uninstall button keeps a title that differs from its name (it explains why a required plugin is locked); IconButton spreads rest last, so the explicit title still wins. Also drops the graphify block from CLAUDE.md — it duplicates the workspace-level instructions.	2026-08-01 06:56:13 +02:00
Claude Fable 5	1f56f34113	#296: remove the unsubscribe-token dual-verify window early ... Operator decision at the ADR 0020 acceptance: verification is subkey-only now instead of waiting for the stated 2026-11-01 expiry. Links in digest mails sent before the #188 key separation stop working; recipients use the in-app notification settings. A regression test pins that the legacy derivation (root key + purpose prefix) can never verify again; security.md records the removal. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 23:03:03 +02:00
Claude Fable 5	9b7acab294	#232: plugin allowlist with SHA-256 hash pinning ... The install path records the SHA-256 of the delivered bundle ZIP (plugins.bundle_hash; pre-#232 installs show it as unknown until reinstalled). plugins.allowlist in instance_settings names permitted ids with their pinned hashes: empty (default) = not enforced, existing instances unchanged; non-empty = installs of unlisted or deviating bundles are rejected (plugin_not_pinned / plugin_hash_mismatch, 403), and an installed plugin outside the list or with a deviating hash does not load — absent from pond mount lists, frame/assets 404. Every rejection is audited (plugin.rejected, catalogue v1.5). A version bump changes the hash and therefore requires an explicit re-pin — the intended friction (ADR 0025). Admin UI shows observed vs pinned hash per plugin with pin/re-pin/unpin. Scope stated honestly in plugin-architecture.md: the pin answers "is this the reviewed bundle"; post-install disk tampering is platform integrity (ADR 0019), sandbox containment stays the sandbox's job. Hardening guide row + catalog advisory triage; residual risk R-03 resolved. e2e: empty-allowlist compatibility, pinned load, unpinned and tampered installs rejected and audited, pin drift blocks loading while the admin still sees the mismatch, version bump needs re-pin. Full api suite 101 files / 561 green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 21:26:36 +02:00
Claude Fable 5	4d9f913845	#246: mode enforced — reject profile-violating configuration writes ... In enforced mode the ONE settings write path every caller uses rejects catalog-violating values with the stable code vs_nfd_profile_violation (403 — the request is well-formed, the policy says no). Existing violating values are reported at startup (log line, database-less boots must not fail) and on the admin card, never auto-changed. The UI renders as in hidden (#245 already keys on hidden|enforced). The hardening guide now names enforced as the recommended mode for VS-NfD reference operation. Tests: violating write rejected with the stable code and nothing stored; compliant writes pass; the same violating write passes in marked and hidden (own app boots); pre-existing violation reported and untouched. Full api suite 100 files / 555 green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 19:48:37 +02:00
Claude Fable 5	0d95e1304e	#245: mode hidden — hide profile-violating options, mark the hiding ... In hidden (and later enforced) mode, catalog-listed controls whose only purpose is enabling a violation are not rendered while their saved value is compliant (the four master switches, the Nextcloud backup block); value-listed selects keep only their compliant choices (registration mode, new-page classification, upload policy, SVG policy). Every affected section shows one accessible policy note (i18n de+en) so policy is distinguishable from missing features. A value that was already violating is surfaced exactly like in marked — never silently hidden. The API stays unchanged; enforcement is #246. e2e: hidden half of the marking pack (rows disappear, note visible, already-violating row stays marked, axe WCAG A/AA clean) — verified live locally; CI runs it against a second api (VS_NFD_MODE=hidden, same database) behind its own static server. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 19:27:17 +02:00
Claude Fable 5	5fdef95f67	#244: mode marked — flag profile-violating configuration in the UI ... Every catalog-listed control on the admin surfaces carries an accessible deviation marking in mode marked: text + icon under the control (never colour alone), part of the control's accessible description (aria-describedby), i18n de+en. The check runs against the CURRENT control value, so a violating choice is marked before saving. Covered controls: registration mode, new-page classification, upload policy, SVG policy, the four master switches (api/mcp/feeds/plugins), the legal texts (violating while empty), and the Nextcloud backup toggle on the system panel. The profile card (#243) gains the warning summary and the hardening-guide reference. e2e: new vs-nfd-marking pack (marked half in CI — the e2e api now runs VS_NFD_MODE=marked, which also puts the marked state into the a11y admin scan; off half in local default runs; both halves verified live). hidden/enforced follow in #245/#246. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 18:49:26 +02:00
Claude Fable 5	da5fd7c770	#243: VS_NFD_MODE and the machine-readable hardening-profile catalog ... The deployment declares through VS_NFD_MODE (off | marked | hidden | enforced, default off) how the application treats configuration that violates the VS-NfD reference profile — deploy-level like BACKUP_ALLOWED_TARGETS, so a compromised Site Admin cannot widen it. The catalog in shared (vs-nfd-profile.ts) is the single source of truth: every profile-relevant setting with a decidable compliant value, judgement calls in an explicit advisory list, and a fence test parsing the hardening guide's reference tables so neither can drift (pattern #201). The api evaluates the catalog against the typed settings registry and validated env and exposes mode + verdict on GET /admin/system/vs-nfd-profile; the admin settings view shows the card whenever the mode is not off. Display only — the treatments land with #244–#246 (ADR 0027, proposed). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 18:24:04 +02:00
Claude Fable 5	4f6596e8a2	#288: reset schema before pg_restore — partitioned tables broke --clean ... Since #224 read_events is partitioned; the dump carries per-partition primary keys as own entries, and pg_restore --clean emitted DROP CONSTRAINT against inherited constraints, which PostgreSQL refuses. The restore then reported FAILED although the content was restored. Dropping and recreating the public schema first makes every --clean drop a no-op and the restore faithful: objects created after the backup no longer survive. Verified in the isolated environment of #220 (set 20260731-132200, exit 0, readyz green). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 17:00:05 +02:00
Claude Fable 5	6aac785841	#217: map IdP groups and roles onto the permission model ... Declarative instance setting idpMapping.rules turns ID-token claims into pond roles and the site-admin flag on every OIDC login — configuration, not code. Mapped grants travel through the SAME GrantsService path as manual ones (permission cache invalidated, collab access notify fires so live sessions revalidate — asserted by test), never raw rows. Ownership makes precedence explicit: role_grants.origin marks mapped rows, users.is_site_admin_managed marks a mapping-set admin flag. The mapping only creates and revokes what it owns — manual wins: hand-made grants and hand-promoted admins are never revoked by a missing claim (a manual toggle clears the marker and takes ownership). Removal of a claim revokes the mapped grant and the managed flag on the next login. Every mapping-driven change is audited with origin idp_mapping. Failure containment: unknown pond slugs and the last-Pond-Admin protection log-and-skip — a mapping problem must never become a login lockout. Tests drive real OIDC logins against the fake IdP with group claims: grant + working access, revocation incl. notify, manual-wins, managed site-admin promote/demote/hands-off. Documented in permissions.md (own section), ADR 0021, data-model.md and the hardening guide (care rule: same PR). Refs #217. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 13:09:11 +02:00
Claude Fable 5	13f0311d8e	#216: hard AUTH_LOCAL_ENABLED switch over every local credential flow ... The deploy-level realization of auth.local.enabled (ADR 0021): FALSE answers 404 on every local credential flow — login, signup, e-mail verification, resend, password forgot/reset/change — enforced centrally in the auth guard via the @LocalCredentialFlow() marker before any session or CSRF logic runs. Deploy-level on purpose: a compromised Site Admin cannot reopen the local path, so the runtime-flip residual risk from ADR 0021 does not materialize (R-02 closed in the risk list). An enumeration fence fails when an auth route is neither marked nor on the reviewed allowlist, so a new credential flow cannot ship unswitched. Stated decisions, each tested: sessions/logout keep working for externally authenticated users; PAT and feed-token issuance stays available (API authorization under its own switches, not interactive sign-in). Bootstrap: complete setup (or SETUP_ADMIN_* pre-seed) before flipping; the api warns at boot when local auth is off with neither OIDC nor proxy auth configured. GET /auth/methods reports local:false and the login page hides the local form and credential links. Hardening guide: the planned auth.local.enabled row moves from 1.3 into the live deploy table with the bootstrap ordering, and the verification checklist gains the login-404 probe. Refs #216. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:58:07 +02:00
Claude Fable 5	4c7f001cab	#215: trusted reverse-proxy header / mTLS client-certificate path ... For perimeters that authenticate before the application (ADR 0021 §4). Off unless BOTH AUTH_PROXY_HEADER and AUTH_PROXY_TRUSTED_PEERS are set — nothing about the header is guessed. The peer check runs against the TCP peer address only (a forwarded header is attacker-influenced): a request carrying the header from any other peer is rejected outright and audited as auth.proxy_rejected (catalogue v1.4) — that is a spoof attempt, not a misconfiguration — even when a valid session cookie rides along. From a trusted peer the header IS the identity; a session cookie never escalates beyond it; with the feature off the header is inert. Mapping is explicit (AUTH_PROXY_MAP: username or e-mail); deliberately no just-in-time creation — the header carries no verified address. The mTLS variant (AUTH_PROXY_MODE=mtls-dn) maps the configured attribute (default CN) out of the certificate subject DN the TLS terminator forwards, under the same peer rules. Session-less proxy requests key the read trail per user (user:<id>). The trust boundary is stated in security.md (the section an assessor reads closest), the VS-NfD security documentation and the hardening guide's deploy table. Tests cover all four decisions: off = inert, trusted peer authenticates (username and DN mapping), untrusted peer rejected + audited, no escalation past a session cookie. Refs #215. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:50:09 +02:00
Claude Fable 5	5796b7a5dd	#214: OIDC Authorization Code with PKCE, Keycloak as reference IdP ... External authentication (ADR 0021) built on jose (#188's vetted library) plus fetch — no new dependency enters the supply chain for a security base function. Discovery-configured; ID tokens validate against the IdP's JWKS under an explicit RS256/ES256 allowlist with issuer, audience, expiry and nonce binding. State, nonce and the PKCE verifier travel in a signed HttpOnly Lax cookie keyed by a dedicated HKDF purpose (oidc-state, ADR 0020). Deploy-level configuration (OIDC_ISSUER/CLIENT_ID/CLIENT_SECRET/SCOPES/ PROVIDER_LABEL): who authenticates users is a platform decision. The login page discovers the provider via GET /auth/methods and renders the SSO button (i18n de+en). Identities use the existing slot (provider oidc:<issuer>, subject from the token). First login creates the account just-in-time — ACTIVE and mail-verified only when the IdP asserts a verified address. An existing local account is NEVER adopted silently by e-mail (account-takeover path): login refuses with oidc_link_required and the owner links explicitly via GET /auth/oidc/link (audited auth.identity_linked, catalogue v1.3). Sessions come from the one existing session service. Tests run the full flow against a protocol-faithful fake IdP: PKCE verifier at the token endpoint, JIT creation incl. personal pond, invalid state/nonce/signature/issuer/audience/expiry each rejected, the linking refusal and the explicit link flow. Verified end-to-end against a real Keycloak 26.0 (repeatable procedure documented in security.md §External authentication). Refs #214. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:44:52 +02:00
Claude Fable 5	4af5e6e81f	#225: read-trail master switch and written purpose limitation ... New instance switch readTrail.enabled, default OFF: read logging is employee monitoring in a works council's eyes — an ordinary instance must not surveil reads. Off means no event is written ANYWHERE (no row, no stdout line, verified by test); the api announces the switch position once per boot, so an eventless trail is never ambiguous — a gap reads as "was off", never "was lost". The written purpose limitation ships as section 7 of the VS-NfD security documentation (#228): what is recorded (no content, no titles, no IPs, no fingerprinting), why (evidence for reads of marked content only — variant A is the technical anchor of the promise), who may read it (Site Admin, API-only), for how long (readTrail.retentionDays, audited pruning), and what it may NOT be used for (no performance or behaviour monitoring). The hardening guide's reference configuration turns the trail on (reference value true) and points to that text; the existing trail suites now enable the switch explicitly. Refs #225. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:35:18 +02:00
Claude Fable 5	2bdb0ec2cf	#224: read-trail storage — partitioning, retention, admin query path ... Convert read_events to monthly RANGE partitions on occurred_at, with a DEFAULT partition as safety net: a lagging maintenance job must never turn the trail's hard-failure semantics into an outage for classified reads. The dedup unique pair (#223) moves to per-partition indexes (PostgreSQL cannot carry it on the parent); a bucket spanning a month boundary may record one duplicate — over-recording is acceptable, gaps are not. New daily job read-trail-maintenance (job-count fence 9 -> 10) creates months ahead — each with its dedup index — and applies the trail's own retention readTrail.retentionDays (default 365, deliberately independent of audit.retentionDays): whole expired months are DROPped without scanning, remainders deleted by range, every run audited as read_trail.pruned (catalogue v1.2; the fence regex now admits an underscore namespace). Site-Admin query path GET /admin/system/read-events answers "who read page X" and "what did user Y read" within a period — API-only by design, documented. Growth measured and documented in data-model.md: ~1 MB per 1000 events including indexes. Tests: retention pruning + audited deletion + admin queries on the shared database; the partitioned shape, per-partition P2002 dedup, months-ahead creation and DROP-based pruning against a fresh database built by the real migration chain. Refs #224. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:21:45 +02:00
Claude Fable 5	fd4fd60c99	#223: dedup window for the read trail ... One event per (session, page, channel) within an aligned window of readTrail.dedupWindowMinutes (default 5): buckets are floor(epoch / windowSeconds), and a unique (dedup_key, window_bucket) pair collapses concurrent duplicates race-free at insert time — the first access in a window is always recorded, a later duplicate lands on the unique violation and is skipped quietly (a skipped duplicate is not a gap; only real write failures still abort the read). Each row carries windowSeconds, so the evidence states it represents a window, never a request count. Reconnects within a window stay one event; a new session records again even for the same user; channels never collapse into each other; the page-less attachment key uses the documented `-` placeholder. Load evidence: 30 collab-token renewals inside one window produce exactly one event (test), bounding a live editing session at ~12 events/hour/page. Window semantics documented in ADR 0023, the VS-NfD security documentation (#228) and as a hardening-guide line for the new setting (care rule: same PR). Refs #223. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:13:21 +02:00
Claude Fable 5	05a979bac3	#222: read-access trail for classified pages ... Instrument every full-content read channel for pages with classification = vs_nfd (ADR 0023, variant A): SPA state fetch and read rendering, public JSON content, no-JS shell, expanded embeds, public API GET (incl. the MCP read_page path and write echoes), attachment download under the #212 effective classification, all export shapes (markdown, pond ZIP, account data export, queued docx/odt/pdf at enqueue), and collab-token issuance as the api-side proxy for the WS join. Events land in the new read_events table (no FKs — evidence survives page purges and hard user deletions) with actor, session key (session:/token:/job:/anon), page, pond, channel and the classification at read time. Recording failures are NOT swallowed: a failed write aborts the read (hard failure, the deliberate contrast to AuditService — decision recorded in ADR 0023 and security.md §Logging, together with the recorded residuals: content fragments and feeds). One e2e test per channel proves both the event and its absence for unclassified pages, plus the hard-failure semantics. Refs #222. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 12:12:55 +02:00
Claude Fable 5	868b79c8bc	#213: warn on uploads to classified pages; instance policy can block ... The attachments panel of a classified page shows a persistent notice naming the consequence (de+en): the file inherits the page's classification but its content carries no marking (#212). The new instance setting classification.uploadPolicy (default warn, documented; the VS-NfD reference configuration blocks, #227) hardens the warning into a server-side rejection (403 classified_upload_blocked) — enforced in the upload service, not only in the UI. Tests: warning visible in the local attachments pack; block enforced server-side with warn/block both ways and open pages unaffected. Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>	2026-07-31 07:33:34 +02:00
Claude Fable 5	e505fc74dc	#212: mark attachment downloads by filename prefix and companion file ... Downloads whose effective classification is vs_nfd carry the documented VS-NfD_ filename prefix (single source classificationFilenamePrefix() in shared; ADR 0022 records the short form for file names). Effective classification: the linked page's level; an attachment with unset pageId (paste-then-insert, pond-level) FAILS CLOSED to the highest level of any live page in its pond. The pond export ZIP adds a sibling <file>.classification.txt companion with the full marking for classified media, next to the manifest entry (#210). Documented in operations.md, incl. the deliberate residual risk: the file's own content carries no marking (recorded on #231, not hidden). Tests: prefixed classified download, unchanged open download, fail-closed orphan both ways, ZIP companion + manifest level. Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>	2026-07-31 07:29:16 +02:00
Claude Fable 5	521ea514b4	#211: classification through feeds, public API, search and the no-JS shell ... Feeds: classified entries carry a standard Atom <category> (term=level, scheme=urn:dorfteich:classification, label=the fixed wording); the feed document states the highest contained level once; all-open feeds carry none. Public API: page representations (list+get) gain the classification field, OpenAPI + public-api.md documented. Search: every hit carries the level and the palette renders the marking with the snippet (compact form of the banner, text token only). No-JS shell: banner above and below the content, own markup for the separate render path; unclassified pages unchanged everywhere. One test per channel (feed categories + count, public API list/get with the switch on, search hit levels, shell top+bottom). Also: fidelity CI sidecars get per-job container names — the fixed names collided across parallel runs on the shared host (run 547's red fidelity job; a fixed-name cleanup could even kill a sibling's live sidecars). Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>	2026-07-31 07:23:53 +02:00