Svelte-ify the board's ~270 lines of vanilla-JS interactivity (the DEC-0043 / Phase-7 fast-follow)

task-svelteify-board-interactions

task confidence inferred status backlog 2026-06-17 owner sveltekit-engineer
source log-auditor — split from task-sveltekit-app-migration's deferred fast-follow when DEC-0043 Phases 0–5 landed (board JS carried verbatim in onMount, Svelte-ification explicitly deferred to Phase 7)

Svelte-ify the board's vanilla-JS interactivity (Phase-7 fast-follow)

Migrate chrome-light app surfaces to SvelteKit; docs stay on Astro/Starlight (two apps, one origin) moved /board to @dossier/app. To keep the framework migration honest (change one thing at a time), the board's ~270 lines of filter / sort / quick-look-dialog / Refine-popover JS were carried verbatim from the old Astro board.astro into the Svelte page's onMount — working code, proven in-browser, but still imperative querySelector/addEventListener DOM-wiring rather than Svelte.

DEC-0043 names this Svelte-ification as an explicit fast-follow — deferred, not dropped. The migration (Execute the SvelteKit app migration (DEC-0043) — phased, no big-bang, apex domain moved only at final cutover) landed Phases 0–5; this is the deferred Phase-7 rewrite, split out so it has a durable, owned home rather than living as a TODO in onMount.

The work

Replace the imperative onMount wiring with idiomatic Svelte 5: reactive $state for the filter/sort criteria, derived task lists, {#each}/{#if} for the rendered status groups, a bound <dialog> for quick-look, and the Refine popover as a component. Behavior must not change — filter, sort, dialog, and popover were proven in-browser at migration time and must stay byte-identical. board.css moves unchanged; the read-only / KB-agnostic / no-mutation invariants (Agentic "sprint board" architecture — a git-resident OKF task board worked by bounded, hook-governed Agent SDK loops — the site only reads task atoms via `readKbAtoms`, never mutates them) are preserved, and the persistent-chrome / zero-flash behavior (Persistent read-only chrome via an (app) route-group layout — stop the header re-animating on intra-app nav) is unaffected.

Why a task, not a fix-in-place

A ~270-line behavior-preserving rewrite on the new surface is real Principal SvelteKit Engineer work with its own in-browser re-proof — owner judgment, not a one-token hygiene fix. confidence: inferred (agent-split from DEC-0043's named fast-follow, not human-curated). Depends on (ordering hint) Execute the SvelteKit app migration (DEC-0043) — phased, no big-bang, apex domain moved only at final cutover landing first — the surface must exist before its JS is rewritten.

Board globbed before filing — no open task covered the board Svelte-ification (Render the board as a derived `/board` surface in @dossier/site is the old Astro board.astro surface task, a different concern, made moot by the migration).