--- name: coverage-mind-map-deliverable description: "⭐⭐⭐ OWNER-SPEC'D DELIVERABLE — split in two: PART 1 the COVERAGE VIEW (rule → what enforces it → what proves the enforcement works, generated, built as a museum room) and PART 2 the VISUAL WEB (parked, not cancelled; Gource is the owner-confirmed aesthetic reference). Holds the spec, the governance constraints, and the legibility objection that gates Part 2." metadata: node_type: project type: project originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 modified: 2026-07-22T00:33:41.130Z --- --- ## ⚠⚠ SPLIT DECISION — OWNER, 2026-07-20. READ THIS BEFORE ANYTHING BELOW. The Atlas is **TWO deliverables, sequenced.** Owner: *"go with recs but save the visual web in parked items bc I do want that but I want it done right."* **PART 1 — THE COVERAGE VIEW. Build first, as a ROOM IN THE MUSEUM, not a separate product.** Not a graph. A generated three-column view: **RULE → WHAT ENFORCES IT → WHAT PROVES THE ENFORCEMENT WORKS**, with the blanks left visibly blank. Generated from source — rules from the rulebook, guards from the test file, tests from the runner. Reuses the museum generator's machinery (same artifact class: generated, static, browsable, honest about its own gaps). ⭐ **Why this jumped in value — two pieces of hard evidence (2026-07-19/20):** 1. **A batch of rules that got cut had ZERO enforcement** — pure prose, with no test, script or hook referencing them. Nobody knew until a session went looking. 2. **A guard was written, hooked, tested — and completely INERT for weeks**, because it compared against the wrong branch while all the work happened on another. So **"has a guard" and "is actually protected" are DIFFERENT COLUMNS.** Both would have been visible instantly in this view. It is the evidence the trim ([[trim-stages-plan]]) needs, and that argument currently lives only in scattered audit files. **PART 2 — THE VISUAL WEB. ⛔ PARKED. The owner WANTS it — "done right", not dropped.** ⭐⭐ **RE-CONFIRMED 2026-07-21 as the ENDGAME that ties everything together.** Owner: *"by the end there should be something like Gource but with our requirements and intents not the original Gource intent to tie everything together. that should be the visual web ya know?"* This lands it squarely inside the museum's organizing thesis ([[museum-core-thesis-the-self-maintaining-system]]): the Visual Web is the CAPSTONE render of the self-maintaining system — the living web of failure→guard→protocol→test→improvement arcs. It is the same thing as the "connection graph as centerpiece" museum recommendation (folded into item P, 2026-07-21) — do NOT treat them as two separate deliverables; the connection-graph centerpiece IS this Visual Web, and the knowledge graph (R11, built 2026-07-21) is the first real slice of the underlying graph data it renders. The two live gates below (Part-1-used, and legibility) still apply unchanged — it is "by the end" precisely because it needs the pieces under it first and a legibility answer, not as arbitrary deferral. ⭐⭐ **SCOPE CLARIFIED 2026-07-21 — the web is NOT just the failure→guard→protocol arcs.** Owner: *"not even just 'The failure → guard → protocol →' but like how the Atlas and the archive connect, how the skill and the rules and architecture connect. how all of those connect to help the AI."* ⇒ The Visual Web spans the WHOLE knowledge architecture and its self-connections, with a first-class layer being **how the apparatus serves the AI**: skill → `CLAUDE.md` → retrieval map → `rules/*.md` → `ARCHITECTURE.md` (the routing chain); Atlas ↔ archive; `memory/` ↔ museum; library ↔ code; queue ↔ log. This is exactly the "ONE GRAPH, MANY VIEWS" principle already at the core of this file (the assurance/failure-arc view is ONE lens; the knowledge-architecture-serving-the-AI view is another; the app-structure view another) — the owner has now independently re-derived it. **The knowledge graph (R11, built 2026-07-21) is the FIRST BUILT SLICE of exactly this AI-serving layer** — it already maps skill→contract→notes→architecture and where they route/claim/drift. So the Visual Web = the unified render of all these layers over one graph; R11 is layer one, the assurance arcs are layer two, app structure is layer three. ⭐ **THE AESTHETIC REFERENCE IS GOURCE — owner-confirmed 2026-07-20.** He was shown [gource.io](https://gource.io/) as prior art and confirmed: *"yes, that's what caught my eye about gource."* It is the LOOK he wants — nodes radiating from a centre, organic branching, things pulsing when touched then settling, inactive branches dimming, the whole graph feeling alive rather than drawn. ⚠ **He wants the FEELING, not the tool.** Gource itself was REJECTED on scale (built for many contributors over years; this is one person over a short span, so it renders as a single dot orbiting a small tree) and on cost (installs Gource + ffmpeg, emits a large stale video). **Do NOT re-propose running Gource.** **What transfers to a generated, no-build-step, static artifact — all achievable in generated SVG + CSS, no framework:** radial/organic node layout instead of a grid or list · edges drawn between related nodes · opacity/dimming driven by age or activity (data we already have) · hover/tap pulse via CSS · colour coding by node type. **What does NOT transfer:** real-time animated playback of history. That's the video, and it's rejected. ⇒ **Hand this to FABLE at the design pass** as a reference for the visual language, framed as "make the RobCo-native version of this feeling," never as "build this tool." Everything below this block (one graph, 8 filtered views, node/edge interaction spec, brain-dumps as perspective layers, gap classification) is Part 2 and stays parked until: - Part 1 exists and has actually been used — same evidence-gate discipline as the trim stages; and - **the legibility problem has an answer. This was the real objection and it does NOT expire with time:** both external reviewers independently said a graph of every rule against every guard, test and file is an unreadable hairball (Gemini: *"spaghetti graphs are illegible"*; GPT: control granularity aggressively or it becomes an unmaintainable everything-blob). The original deferral had TWO reasons — (a) don't map a moving target, since largely resolved; (b) **legibility, still live.** - Dispatch's read, recorded honestly: build the table first and see whether the owner ever wishes it were a graph. What he actually asked for was *"see everything that's covered and why"* — a table may do that better than a web. **But he has said he wants the visual version, so it is PARKED, not cancelled. Do not quietly drop it.** - If/when built: it must be GENERATED, never maintained; primary layer + drill-down (never every node at once); and a **DSM (dependency-structure matrix)** is the better instrument for the one question it answers superbly — circular dependencies, which this project does have real instances of. --- **Grew across several owner messages (2026-07-16). Started as a "mind map of protocols/tests/guards + WHY," refined into an assurance/dependency map, then BROADENED into the full ROBCO SYSTEM ATLAS. Build to THIS.** ## ⭐ THE CORE PRINCIPLE — ONE GRAPH, MANY VIEWS The Atlas is a **visual explanation of the entire application**, not just its safety net. It uses **ONE underlying graph of RobCo reality** and provides multiple FILTERED VIEWS over it. **Do NOT create several independent maps that can drift apart** — every view is a lens on the same single graph. The old Assurance Map is one selectable view inside it. ## THE UNDERLYING GRAPH — node types (include where supported by REPO / source-of-truth EVIDENCE) screens/tabs/panels/menus/modals/navigation · player-facing features & player goals · deterministic systems & calculations · application state & state ownership · databases/registries/game-specific content · saves/migrations/local persistence/cloud/sync/undo/recovery · service-worker & offline systems · AI capabilities, context inputs, validation, authority boundaries · shared vs per-game systems · rules/guards/tests/CI/release gates/live verification · source-of-truth documents · roadmap items, dependencies, planned consumers · AI brain dumps & other representations of project understanding. ## EDGE / RELATIONSHIP TYPES NAVIGATES TO · RENDERS · READS · WRITES · OWNS STATE · DERIVES · PERSISTS · SYNCS · VALIDATES · INVOKES · EXPLAINS · DEPENDS ON · CONSUMES · PROVIDES CONTEXT TO · GAME-SPECIFIC VERSION OF · SHARED BY · PROTECTED BY · TESTED BY · DOCUMENTED BY · PLANNED CONSUMER OF · SUPERSEDES · CONFLICTS WITH. (Plus the Assurance-view edges: ENFORCES, VERIFIES, BLOCKS RELEASE, RECOVERS FROM, MAKES VISIBLE, DERIVED FROM INCIDENT, LEAVES UNVERIFIED.) ## ⭐⭐ EXTERNAL-REVIEW CORRECTIONS (ChatGPT, 2026-07-16 — every finding was adjudicated ADOPT for the *design* of these unbuilt artifacts, since they cost nothing to fold in now). Headlines to build to: 1. **⭐ EVIDENCE — not the brain dump — is the epistemic ROOT.** The chain is: **evidence baseline (owner intent · repo reality · deployed reality · runtime reality · scoped verification evidence) → canonical internal reconstruction (the brain dump, evidence-linked) → generated projections (portable brief + Atlas).** The brain dump is a *synthesis of evidence*, and never outranks the system it summarizes. 2. **Round Baseline Manifest** — the ONE new small (mostly machine-readable) artifact: pins every artifact to ONE baseline (commit/branch/timestamp/brain-dump version/deployed rev/SW+cache version/schema version/game-data version/test run/post-deploy result/exclusions) so cross-artifact comparisons are valid — "same RobCo?" 3. **Two independent axes per node/claim: LIFECYCLE status** (current/incomplete/queued/proposed/deprecated/superseded/intentionally-absent) **× EVIDENCE status** (verified/inferred/unverified/contradicted/stale/unknown). 4. **+3 Atlas views:** provenance/freshness · change-since-last-round (needs STABLE IDs) · repository→deployment→client version-plane (the silent-service-worker-failure lens). 5. **System review = "External System MODEL Review"** — it reviews the REPRESENTATION, not RobCo itself. Findings format: Concern → why → evidence-needed → what-would-falsify → confidence. **Agreement raises PRIORITY, not truth.** 6. **Every external finding gets ADJUDICATION** (verdict + owner decision), not a permanent Atlas node. 7. One entity/relationship MODEL, but the Atlas is an INDEX into evidence, not a swallow-everything graph. 8. Aggressive granularity control (primary layer + drill-down); the default view is not every file and function. 9. Explicit MAP-COVERAGE BOUNDARY — "no material gap" means only "within mapped + verified scope," **never proof-of-absence.** 10. Reviews are RISK-TRIGGERED, not ceremonial per round. 11. The reviewer's don't-add list matched our own restraint; candidate-additions stay attached to their baseline, never a silent backlog. ## ⭐ FOLDED-IN REFINEMENTS (owner "fold all in", 2026-07-16) — required in the built versions **Atlas, 3 enhancements:** - **(A) External-review overlay** — a view mapping returned external review findings onto the graph (the seam tying the Atlas to the workflow review). Build the Atlas FIRST so its reality can fact-check the external claims. - **(B) External AIs as perspective LAYERS** — returned reviews become perspective layers alongside the brain dumps, same treatment (retain model/date/purpose/claims/evidence/matches-reality). ⛔ Never trust on agreement without repo evidence. - **(C) Confidence / evidence-strength marker on every NODE**, so the gap-analysis view can visibly flag weakly-verified nodes. **Workflow-review prompt — required refreshes when it is finalized (it predates these):** 1. the session-launch discipline ([[dispatch-session-launch-discipline]]: fresh session per task, wait-on-resend after a launch timeout); 2. the "explain every result in plain English every time" reporting standard (owner reinforced 2026-07-16); 3. the rule consolidation as evidence the process PRUNES itself, not only grows (net growth was the concern — [[engineering-metrics-log]]); 4. deliver as a fenced COPY-PASTE BLOCK ([[external-ai-prompt-delivery]]). 5. ⭐⭐ **THE TACIT LAYER — owner demand 2026-07-18: "I want EVERYTHING included."** The prompt describes only the FORMAL process, and a reviewer cannot critique what's invisible. Must add: - **The shorthand, decoded**: "go"/"keep going" = proceed, stop asking (auto-advance the whole chain) · **"yo" = a check-in; usually "are you alive / what's happening," and after I've asked something it means "yes, get on with it" — a nudge forward, not a question** · "resend" = the launch timed out or died, fire fresh (never reuse) · "go with recs" = adopt my recommendation as stated · "fold all in" = incorporate every flagged item · terse one-word replies = he's on a phone, semi-attentive, wants momentum over ceremony · **and the rule underneath: he is ALLOWED to be scattered — consolidating his scattered messages into one coherent spec is Dispatch's job, never his.** - **The human↔AI channel's OWN failure modes**: messages that silently never arrive · launches that time out AND spawn a duplicate anyway · sub-sessions that HANG when they stop to ask a question · abort commands a running session ignores · gates outliving the tool timeout, so "push failed" usually means "still running." (Two real collisions on 2026-07-18.) - **How memory works** — disposable amnesiac sub-sessions; continuity lives in Dispatch's persistent file memory. - **The economics** — usage is a real budget; the efficiency burden is Dispatch's, not the owner's. - **What is NOT delegated** — the owner owns design calls, roadmap order, destructive actions, real-device verification. - **The rework loop** — a failed audit returns to PLANNING, not more grinding. - **The attention pattern** — marathon sessions, intermittent one-word check-ins. - **⭐ The UNRESOLVED TENSIONS, named outright** (the best thing to hand a critic): "auto-advance, don't ask" vs "wait for me on resends"; and there is NO rule for when a long run should checkpoint vs keep going. **Do NOT send a flattering version of how we work — name the real frictions.** Keep them SEPARATE deliverables (owner-confirmed): the prompt stays a lean BLIND outbound question — its power is the outside view, so do NOT put the Atlas inside it; the Atlas is the internal whole-system map. They connect at the seams (A/B above), not by merging. ## THE 8 VIEWS (at least) 1. **PRODUCT** — what the player sees, where they navigate, which player need each panel/feature serves. 2. **ARCHITECTURE / DATA-FLOW** — state ownership, reads/writes, persistence, services, rendering, dependencies, duplicated authority. 3. **FEATURE-CHAIN** — player need → UI → deterministic behavior → data → state mutation → persistence → AI enrichment → assurance. 4. **GAME-CONTEXT** — shared systems vs per-game implementations or MISSING equivalents. 5. **AI-BOUNDARY** — what is deterministic, what AI reads, what AI may interpret, what AI output is validated, what AI must NEVER own as application truth. 6. **ASSURANCE** — risk → invariant → rule → enforcement → evidence → release gate → deployed truth → recovery (the originally-requested chain; full spec below). 7. **ROADMAP / DEPENDENCY** — current/incomplete/queued/proposed/deprecated/intentionally-absent systems, incl. which foundations each future item consumes. 8. **GAP-ANALYSIS** — missing capabilities, missing connections, orphan nodes, duplicate authority, unused data, weak foundations, stale mechanisms. ## ASSURANCE VIEW (#6) — full chain preserved FAILURE/RISK → INVARIANT → RULE → ENFORCEMENT MECHANISM → TEST/EVIDENCE → RELEASE GATE → POST-DEPLOY VERIFICATION → USER-VISIBLE FAILURE HANDLING/RECOVERY. For every safeguard: what it protects · **the exact failure or incident that birthed it** · where enforced (doc/code/runtime/test/CI/branch-protection/manual/live) · what evidence proves it works · **what that evidence does NOT prove** · dependencies · what happens when it still fails · whether the failure is user-visible or silent. Three territories: PRODUCT/RUNTIME, REPO/TEST/RELEASE, HUMAN/AI-WORKFLOW safety. ## AI BRAIN DUMPS = PERSPECTIVE LAYERS, NOT TRUTH Treat every brain dump as a perspective layer. Per dump retain: model or role · creation date · repo state it describes · intended purpose · its claims · the evidence behind each claim · whether the claim matches CURRENT repo reality. Overlays: canonical repo reality · each AI's understanding · consensus · disagreements · stale claims · features REAL but missing from dumps · claims in dumps but ABSENT from reality. **⛔ Agreement between several AIs must NOT become project truth without repo/source-of-truth evidence** (same rule as the blind-review pattern — [[reframing-review-2026-07-13]]). ## GAP DETECTION — look specifically for: player need with no supporting system · visible panel with little or no meaningful behavior · useful internal capability with no player UI · data collected but not meaningfully consumed · two systems whose MISSING connection prevents obvious value · duplicated state / competing authorities · roadmap feature with no architectural or data foundation · AI feature with insufficient deterministic data beneath it · a repeatable DETERMINISTIC capability unnecessarily delegated to AI · a feature with no assurance or recovery chain · a safeguard whose original feature/risk no longer exists · a system described DIFFERENTLY by code vs docs vs roadmap vs AI dumps. **Classify EVERY proposed gap:** CONFIRMED GAP · POSSIBLE GAP · INTENTIONAL ABSENCE · OUTDATED EXPECTATION · **NO MATERIAL GAP**. ⭐ **Do NOT assume every empty space needs a feature** — RobCo is already feature-rich; "NO MATERIAL GAP" is acceptable and LIKELY. ## INTERACTION **Select a NODE →** explain: what it is · why it exists · where the user meets it · what player need it serves · what owns its state · what it reads/writes/derives/persists · what depends on it · which games support it · what AI capabilities use it · what tests/safeguards protect it · what roadmap items consume it · what's uncertain/absent/disputed · which evidence supports each claim. **Select an EDGE →** explain why the connection exists and what breaks or becomes impossible if it's missing. ## ⭐⭐ GOVERNANCE CONSTRAINTS (hard) - Mapping EXISTING reality is free and may be automated. **This does NOT authorize implementing any new feature, rule, test, release gate, workflow step, recurring audit, source-of-truth doc, maintenance obligation, or governance artifact.** - Any proposed product OR process change stays in a **"CANDIDATE ADDITIONS — NOT ADOPTED"** section until the owner approves it after review. Each candidate carries all 7: (1) the evidence/gap prompting it · (2) the exact change · (3) the real outcome it would change · (4) could an EXISTING mechanism absorb it · (5) implementation + maintenance cost · (6) downside/risk · (7) verdict ADD / ABSORB / INVESTIGATE / REJECT. **"NO MATERIAL ADDITIONS" is fully acceptable.** - Don't let AI agreement become truth without evidence; a genuine gap is shown as a gap, never papered over. - **Treat the Atlas as a GENERATED end-of-round ARTIFACT.** Do NOT assume it becomes a permanently-maintained subsystem until it demonstrably changes real decisions, reveals genuine gaps, corrects stale understanding, or improves roadmap sequencing. ## FORMAT + ORDERING One interactive visual (HTML/SVG node-graph with the view filters + node/edge inspectors), bidirectionally traceable. **The ORDER is load-bearing:** re-baseline the brain dump FIRST — it is the linchpin, and it drifts as sessions patch it in passing — then, all from the fresh dump: (a) generate the **portable external brief** (never a standing second copy — generated fresh each time), (b) run the blind external **workflow review** ([[external-ai-prompt-delivery]]), (c) build the **Atlas**, which uses the brain dump as a SOURCE *and* as one perspective LAYER. ⭐ **STANDING INSTRUCTION (owner 2026-07-16):** whenever `QUEUE.md` next gets a FULL update, **evaluate the whole queue to ensure everything is planned in the CORRECT ORDER** — dependencies first, foundations before consumers — not just append. ⭐ **BLIND CROSS-REVIEW METHOD:** send the same core BLIND to each external model separately, then synthesize — **weight DISAGREEMENTS highest** (the reframing-review rule), and do not let convergence become truth without repo evidence. Source material to hand a reviewer: the rulebook (rules + incidents), the runner + test catalog (guards), `library/CODE_MAP.md` + `library/BRAIN_DUMP.md` (architecture, and the dump itself as a perspective layer), `index.html`/`sw.js`/CI (product + release), `QUEUE.md` (roadmap), the `planning/*` audits, the game definitions (shared vs per-game). *Correction 2026-07-20: the deferral gate this file was waiting on has since been met, and the in-flight review status it recorded is no longer current. Deferral state, queue items and round labels have been removed — live roadmap state is `QUEUE.md`.* Related: [[external-ai-prompt-delivery]], [[reframing-review-2026-07-13]], [[deep-systems-review-2026-07-13]], [[architecture-review-2026-07-13]], [[data-provenance-program-complete]], [[robco-os-architecture]], [[roadmap-parked-placement]], [[trim-stages-plan]].