An Owner Manual: a private product x-ray that explains the product to its own founder
Building an in-app, founder-only surface that maps all 64 product concepts to honest statuses — and the deliberate choice to label its 64-row matrix a hand-written static snapshot while only the backlog signals are repo-derived at build time.
A platform that connects business, architecture, issues, flows, and billing eventually outgrows the founder's own head. You can no longer answer "what does context engineering actually mean in our product, and is it shipped or aspirational?" without re-reading the code. So in this parallel wave (workers D01, D02, D04) we built an Owner Manual — a private, in-app surface whose only job is to explain the product to the person selling it, without marketing hype.
D01 wrote the content model, not a page. It produced docs/product/founder-owner-manual-concept-status-matrix-2026-06-17.md (added in 979f52f): a 64-of-64 concept matrix where every row carries an honest status, a plain-language explanation, why it matters, a sees (what a user can observe today), a remains (what's still missing), and repo-relative code/doc references. The discipline here is that statuses are grounded in checked code — GraphStore against capture.rs, RAG/embeddings against memory.rs, runner/receipts/approval against packages/action-sdk/src/index.ts. A whole section, What Must Not Be Claimed Yet, exists to stop the founder from overselling live connectors, managed AI, Windows, or prompt-injection defense that don't exist.
D02 turned the matrix into app UI (af30a14). The desktop startup view gets an internal Owner tab beside Mission (StartupView.tsx, page key ownerManual), opening OwnerManualPanel.tsx backed by ownerManualData.ts. The header literally reads Private owner x-ray, and rows bucket into Implemented / Partial / Planned / Not started, with a Claim risks filter. Across all 64 rows the real distribution is sobering and honest: 5 implemented, 47 partial, 10 planned, 2 not-started. Forty-seven "partial" is the truthful shape of a young platform where a real slice exists but the product promise is broader than the code.
D04 added grounding (fc500d4) — and this is where the most important honesty call lives. The temptation was to make the manual feel "live." It is not, and it says so. ownerManualData.ts carries an ownerManualFreshness block with isStaticSnapshot: true and a verbatim warning:
The 64-concept matrix is still a static owner snapshot. Backlog candidates and result-doc counts are derived from repo docs when this app bundle is built.
The grounding that is real (ownerManualGrounding.ts) is build-time, not runtime. It uses Vite's ?raw import and import.meta.glob over docs/parallel-work/2026-06-17-results/*-result.md and the active backlog markdown — so next-wave candidates, phase counts, and the latest verification summary are parsed from repo docs at bundle time. There is no Tauri filesystem read, no refresh button, no LLM call, no analytics. The parser also degrades visibly: if the backlog table format drifts, it surfaces a warning and tells the founder to keep trusting the static matrix, rather than rendering fake candidates.
Why label your own snapshot as stale? Because the alternative — a confident-looking dashboard that silently rots — is exactly the "AI magic" overclaim the manual exists to prevent. A product x-ray that lies to its founder is worse than no x-ray. The label is the feature.
Privacy is by placement, not auth: the surface lives inside the desktop app and is never exposed on landing/web. No founder-role gate was added yet (an acknowledged gap). The standing follow-up: every future wave that ships a connector, eval, or managed-AI cap must update its row, or the manual stops being honest.