Render the client's REAL board inline on the dev-only preview

The dev-only client landing preview renders the client's REAL OKF knowledge graph inline — via three atomic no-copy-paste extractions (readKbAtoms(dir), buildGraphView, GraphExplorer) that read the client's served OKF directly without perturbing the process-wide DOSSIER_KB or the prerendered /graph made the dev-only client landing preview (/preview/<slug>) render the client's REAL OKF knowledge graph inline beneath the landing — over a shared buildGraphView + <GraphExplorer>, reading the client's served OKF directly via the new readKbAtoms(dir) param (Lenient KB-atom reader in @dossier/okf-view (readKbAtoms) — faithful getCollection reproduction for the SvelteKit app), without perturbing the process-wide DOSSIER_KB or the prerendered /graph.

The board half is still un-tailored. The preview's "live surfaces" showcase card for /board links to Dossier's own board in the monorepo dev server (DOSSIER_KB unset → /board reads knowledgeDir() = Dossier's own task atoms), which contradicts the tailored page's claim that both surfaces read the client's OKF — the exact gap DEC-0047 just closed for the graph, still open for the board.

The work

Render the client's OWN task atoms inline beneath the landing — the board sibling of DEC-0047's inline graph. The mechanism mirrors DEC-0047 exactly:

• Extract the board's payload/grouping recipe into a shared board view-model (the analog of buildGraphView in $lib/server), consumed by BOTH the production /board loader and the preview — one recipe, never copy-pasted (the standing fully-open-and-atomic rule).
• The preview loader reads the client dir directly: readKbAtoms(okfDir).filter((e) => e.data.type === 'task') → the shared view-model → getRouteMap() for deep-links (host route map → null links for client ids with no reading surface, the honest state).
• Render it in the same dev-only preview wrapper (preview/[client]/+page.svelte), as a banded appendage below <LandingPage> — the shared LandingPage template stays untouched (The marketing landing becomes a tailorable per-client template — a typed LandingContent model rendered by LandingPage.astro; the Dossier render stays byte-for-byte identical; client instances are values of the same type, canonical in the client's own repo, generated by the generate-landing skill invariant #1).

Invariants (same as DEC-0047)

READ-ONLY + KB-agnostic (Adopt OKF as Dossier's canonical knowledge format / Agentic "sprint board" architecture — a git-resident OKF task board worked by bounded, hook-governed Agent SDK loops — the surface only reads task atoms, never git add/commit/push); read the client dir directly so the process-wide DOSSIER_KB and the prerendered /board are untouched; crash-safe honest empty board on a missing/empty dir; DEV-ONLY by construction (the preview route 404s in prod, the registry imports only inside the import.meta.env.DEV gate, so no client copy ships).

Why a task, not a fix-in-place

A shared board view-model extraction + a new inline render on the preview surface, with its own in-browser re-proof, is real Principal SvelteKit Engineer work — owner judgment, not a one-token hygiene fix. confidence: inferred (agent-filed from DEC-0047's named follow-up, not human-curated).

Coordinate, don't duplicate

Depends on (ordering hint) Svelte-ify the board's ~270 lines of vanilla-JS interactivity (the DEC-0043 / Phase-7 fast-follow) — the board's onMount interactivity is being Svelte-ified separately; land the shared view-model against whichever board shape is current. Board globbed before filing: Render the board as a derived `/board` surface in @dossier/site is done (the production /board, a different surface) and Svelte-ify the board's ~270 lines of vanilla-JS interactivity (the DEC-0043 / Phase-7 fast-follow) is the JS rewrite, not the inline-on-preview rendering — neither covers this.