Render the dogfood OKF KB app-native in @dossier/app near /graph (the prerequisite that frees Starlight for product docs)

task-render-dogfood-kb-native-in-app

task confidence inferred status done 2026-06-22 owner sveltekit-engineer
source log-auditor — filed recording the founder-directed DEC-0072 refinement (2026-06-22, two renderers split by register). Board globbed before filing — no open task covered rendering the dogfood KB app-native (task-stand-up-product-docs-register covers the product-docs Starlight repurpose that DEPENDS on this; task-app-graph-view-register-dxa-types / the graph tasks cover the graph explorer, not the atom-reading pages).

Render the dogfood OKF KB app-native in @dossier/app

The prerequisite of the DEC-0072 two-renderer refinement (founder direction, 2026-06-22) and the DEC-0073 visibility floor: render Dossier's sovereign dogfood OKF KB natively in @dossier/app, near /graph, via @dossier/okf-view (readKbAtoms + the route map / sidebar / view-model) + @dossier/design — as first-class app content with the app's full design language + motion, "much better than the old docs" (the founder's bar), not the stock Starlight docs reader.

Why a task, not a fix-in-place

This is real authored + routing work needing the Principal SvelteKit Engineer's judgment (route group, atom-page rendering, redirects, the docsUrl seam) and the Principal UX Engineer's for the "much-better-looking" bar (the app's design language + motion applied to atom reading pages). The log-auditor files it so the founder-directed prerequisite is durable and owned. confidence: inferred (agent-derived from the DEC-0072 refinement).

Scope

  • Atom reading pages, app-native, under the (app) chrome route group — styled with @dossier/design, read via readKbAtoms + the existing route map/sidebar (the exact reader the Astro docs use — no forked KB).
  • /graph stays the entry. The graph explorer is unchanged; a node click lands on the app-native atom page via in-app nav.
  • Routing flip. packages/app/vercel.json's catch-all rewrite is flipped so /knowledge + the atom routes (/decisions/*, /tasks/*, /roles/*, /model/*, /references/*, /log, /mission) are served by the app, the docs origin serving product docs.
  • No broken links. Redirects for every prior /knowledge/* + atom-route URL into the new app pages.
  • Seam update. docsUrl() (packages/app/src/lib/docs.ts) updated for the new topology — KB links resolve in-app; the header "Docs" link is freed to point at the product-docs surface (new tab — Stand up the product-docs register — REPURPOSE the @dossier/docs Starlight surface to official product docs at /docs/* (new-tab "Docs")).

Feasibility (grounded, not speculative)

@dossier/okf-view already exposes readKbAtoms + the route map / sidebar / view-model, and the app already renders the real OKF graph inline (DEC-0047) and reads KB atoms (DEC-0044). This is mostly authoring + routing, not new machinery.

Guardrail

The KB stays the sovereign OKF system of record; ZERO marketing prose enters knowledge/** (DEC-0072 purity invariant). This task frees the Astro/Starlight surface for product docs — Stand up the product-docs register — REPURPOSE the @dossier/docs Starlight surface to official product docs at /docs/* (new-tab "Docs") depends on it.

Board globbed before filing — no open task covered rendering the dogfood KB app-native.

Done (2026-06-22)

Track 1 of the visibility topology is built + browser-verified. The dogfood OKF KB renders app-native in @dossier/app via a (app)/[...slug] catch-all over the shared @dossier/okf-view reader — 159 atoms prerendered, URLs byte-preserved; vercel.json flipped off the Starlight proxy for the 10 KB segments; in-app graph/board → atom nav; token-only reading UI.

During FDE browser verification a hydration defect was found and fixed: OkfMeta.svelte (a client component) imported a runtime value (conceptBadgeClass) from the @dossier/okf-view barrel, which re-exports the fs-based route/kb readers — so node:fs leaked into the client bundle and threw on hydration (SSR HTML looked fine; only a real browser exposed it). Fix: OkfMeta now imports types only; the badge class + owner/decided_by routes are pre-computed server-side and passed as plain props (the pattern OkfRelated already used). Re-verified in a real browser: console clean (zero errors), full DOM intact, wiki-links + typed-edge relations + owner link all resolve; svelte-check 0 errors; production build green; kb:check clean.

Scope of this done: implemented + locally browser-verified (Track 1). It does not promote DEC-0072 beyond its frame — the broader register-topology promotion still depends on Track 2 (product docs, Stand up the product-docs register — REPURPOSE the @dossier/docs Starlight surface to official product docs at /docs/* (new-tab "Docs")). The leaky-barrel root cause is hardened forward by Split @dossier/okf-view into a client-safe entry (view-model + types) vs a server-only entry (the fs readers) + guard against node:fs leaking into the client.