# Sovereign Doctrinal Audit + World-Class Plan — Oscar Platform
**Revision 2** · 2026-06-29 · Doctrine + architecture only. No code.

---

## I. POSTURE

This is **Revision 2** of the audit + plan. Revision 1 (`docs/AUDIT-PLAN-2026-06-28.md`, 1,543 lines) is preserved as the baseline. Revision 2 corrects three categories of gap that the prior version understated:

1. **§11.9 doctrine** — every Recipe Book's `rules.md` MUST contain 9 specific universal things. The prior plan said "rules.md (9 things per §11.9)" without specifying the 9. This revision enumerates them.

2. **§16.5 doctrine** — every Product Smart App at Level 4+ MUST have a `recipe-book/smart/` directory with 6 specific JSON files. The prior plan treated the 14 Smart X features as a "ship 3 of 14" list. The 14 are **constitutional toggles the user controls**, not a feature roadmap.

3. **v9-fvw empirical doctrine implications** — the operator's parallel `avidtech6/v9-fvw` project (2026-06-22) has produced three concrete doctrine proposals: §30.5 (format-as-constitutional), §22 C9 (State Shape Inventory), §11.12 (Tool A vs Tool B). The prior plan did not integrate these.

This revision also re-evaluates the prior audit's framing of the operator's scrap. The scrap is **proposed-but-unratified** doctrine, distinct from FVW v8 v0.10.0 (ratified) and from v9-fvw's empirical proposals (ratified-as-proposed but upstream-pending). The three tiers are kept separate throughout.

---

## II. THE THREE DOCTRINE TIERS

For every claim in this audit + plan, the source tier is named explicitly:

| Tier | Source | Status |
|---|---|---|
| **Ratified** | FVW v8 v0.10.0 `doctrine/` (commit `29a8262`) | Binding. The 41 doctrine files. The 8 mandatory artefacts. The C1-C8 codex. The §35 module-pact registration. The §00 reconstructability invariant. |
| **Proposed (upstream-pending)** | Operator's `avidtech6/v9-fvw` repo + RFCs (2026-06-22) | Documented but not yet in FVW v8 doctrine. Examples: §30.5 format-as-constitutional, §22 C9 State Shape Inventory, §11.12 Tool A vs Tool B |
| **Scrap (unratified)** | Operator chat refinements (collected 2026-06-26 to 2026-06-28) | Not yet in any doc. Examples: project spine, universal artefact graph, multimodal capture, voice pipeline, style learning, map module, comms, multi-domain, workflows, FreshCards/ADHD UX |

The prior audit + plan conflated the three tiers. Revision 2 separates them.

---

# PART 1 — DOCTRINAL AUDIT (REVISION 2)

## III. RE-VISITED SCORECARD — FVW v8 v0.10.0 RATIFIED DOCTRINE

### III.1 The 8 Mandatory Artefacts (Ratified §01)

| # | Artefact | Oscar Status | Doctrinal Gap |
|---|---|---|---|
| 1 | `app-pact/` (with `app-pact.md`, `invariants.md`, `anti-drift.md`) | ⚠️ Partial — `pact/platform/` has `README.md` + `sovereignty.md`; missing `app-pact.md` (the main pact), `invariants.md`, `anti-drift.md` | **Constitutional gap** |
| 2 | `app-codex/` (per-module codex with C1-C8) | ❌ Absent — no `codex/` directory; no per-module codex files | **Constitutional gap** |
| 3 | `app-fragments/` (atomic fragment specs) | ❌ Absent — `pact/fragments/` is declared in README but **empty** in filesystem | **Declared-undelivered gap** |
| 4 | `app-dna/` (`app.dna.json`) | ❌ Absent — no DNA file | **Constitutional gap** |
| 5 | `app-trace-atlas/` (`atlas.json` 5-level chain) | ❌ Absent — flows are in code, not in atlas | **Constitutional gap** |
| 6 | `app-overlays/` (customisation layers) | ❌ Absent | **Constitutional gap** |
| 7 | `app-vp/` (validity + protection tests) | ✅ Partial-strong — `pact/audit/` contains 58 invariants across 6 suites + 8 adversarial probes | **Strongest partial** (renamed `audit/` → `vp/`) |
| 8 | `app-recipe/` (per-module Recipe Books) | ❌ Absent — `pact/recipes/` is declared in README but **empty** in filesystem | **Declared-undelivered gap** |

**Score: 0 of 8 mandatory artefacts in canonical FVW v8 form. 2 of 8 partial (with `vp/` being genuinely strong). 6 of 8 absent.**

**Re-confirmed gap (from prior audit):** The `pact/fragments/` and `pact/recipes/` directories are **declared-but-undelivered**. This is the most damaging kind of gap — it claims structure the runtime does not fulfill.

### III.2 Module-Pact Registration (Ratified §35)

| Required | Oscar Status |
|---|---|
| `module.json` per module | **0 of 12 modules have it** |
| `constitutional_fragments` list | **0 declared** |
| Forward check (module → pact) | **Cannot pass** — no fragments exist to check against |
| Drift-check MP-1 (CRITICAL severity) | **Not implemented** |

**Score: 0 of 4 required components.** Oscar is not Module-Pact Registered per §35.

### III.3 Reconstructability Invariant (Ratified §00)

> An app is FreshVibe-compatible iff: there exists a Recipe R such that, given only R + the V4 documents, the app can be regenerated byte-for-byte.

| Required | Oscar Status |
|---|---|
| `app-recipe/` exists | ❌ Empty directory |
| Per-module `recipe.md` × 12 modules | ❌ 0 of 12 |
| Per-module `codex.md` × 12 modules | ❌ 0 of 12 |
| Per-module `rules.md` × 12 modules | ❌ 0 of 12 |
| `module-meta.json` × 12 | ❌ 0 of 12 |
| `dna/app.dna.json` | ❌ Absent |
| `atlas.json` | ❌ Absent |

**Oscar fails §00.** It is not FreshVibe-compatible by canonical doctrine. Sovereignty is honored; structural alignment is not.

### III.4 The 9 Universal Things in rules.md (Ratified §11.9)

This is the gap Revision 1 understated. Per §11.9, every module's `rules.md` MUST contain **9 specific things** in a specific order:

1. **Capability declaration** — including the Reconstruction Mode Declaration per §33
2. **Do-not-proceed rule** — when the implementer must stop
3. **Contract primacy** — recipe.md + codex.md are the contract; scaffolding is not
4. **Anti-drift enforcement (4 numbered checks)** — Recipe→Source, Visual Diff, Behavioural, Contract
5. **Plan-as-law** — atomic plan steps
6. **Fallback behaviour** — what happens when generation fails
7. **User-simulator requirement** — C6 user simulations must be runnable
8. **Re-anchor cadence** — when to re-read the contract
9. **Coverage matrix** — `coverage-matrix.md` with source-feature / source-line / recipe claim / impl status / test status

**Oscar has 0 of 12 modules with `rules.md`.** Even if it had 12 modules with rules.md, none of them would satisfy the 9-thing structure. The 9-thing doctrine is **untouched**.

### III.5 The 14 Smart X Features as Constitutional Toggles (Ratified §16.3)

Per §16.3, the 14 Smart X features are **constitutional categories the user toggles**, not a feature roadmap. The implication:

- Oscar cannot be at Level 4 (Smart Modules) without **declaring which of the 14 it ships**
- The declaration goes in `recipe-book/smart/features.json` per §16.5
- The declaration is per-project (the user can toggle features per project)
- An Oscar that's at Level 4 but doesn't ship a `features.json` is **constitutionally incomplete**

Revision 1 framed the 14 as "ship 3 of 14" — wrong framing. The correct framing: **Oscar must declare which of the 14 it ships, per project, in a constitutional `features.json`**.

### III.6 The 6 recipe-book/smart/ JSON Files (Ratified §16.5)

Per §16.5, a Product Smart App at Level 4+ MUST have:

```
recipe-book/smart/
├── features.json     # which of the 14 Smart X features are enabled
├── engines.json      # which of the 6 Smart Engines are active
├── modules.json      # which Smart Modules are adopted
├── micro-model.json  # which micro-model is embedded, with lineage and .fvr metadata
├── hooks.json        # which hooks the smart features expose
└── seeds.json        # which seeds the smart features declare
```

**Oscar has 0 of 6 files.** The runtime has the capabilities (assistant, brain, writing) but the constitutional declaration is absent.

### III.7 The Micro-Model Doctrine (Ratified §15.3)

Per §15.3, micro-models MUST be 100k-2M parameters. **Qwen 0.5B (500M params) exceeds the constitutional ceiling by 250×.**

This was correctly identified in Revision 1. Re-confirmed: Oscar's brain cannot be constitutionally embedded under §15.3 as currently written. The doctrinal resolution is either:
- Amend §15.3 to add a "browser-loadable model" tier (100k-1B params)
- Or reframe Oscar's brain as a **cloud-fallback model** rather than an embedded micro-model

**Recommendation:** propose §15.3-bis amendment. See Plan B1.

### III.8 The Reconstruction Mode (Ratified §33)

Per §33, only two modes exist: FreshVibe App Mode and Studio Module Mode. **Oscar is a third mode** (Sovereign SPA Mode: React + TS + Vite, no Mantine, not in FVS Studio container).

Revision 1 identified this correctly. Re-confirmed: Oscar's mode is officially undefined per §33. The doctrinal resolution is either:
- Amend §33 to add Sovereign SPA Mode as a third mode
- Or, less ideally, have Oscar declare itself as one of the two existing modes (which it cannot honestly do)

**Recommendation:** propose §33.5 amendment. See Plan B1.

### III.9 The Two-View Substrate (Ratified §23)

Per §23, a thing can simultaneously be a standalone workspace AND a substrate for other parts. FreshCards is the canonical example. Per §23.2:

- **View 1: Standalone Workspace** — the user opens it, uses it, does work
- **View 2: Substrate** — other parts use it for features

**Oscar has no two-view architecture.** Every view is single-purpose. The assistant is closest to a substrate (action chips route through it from other views) but is not formally declared as a substrate per §23.

**This is the FreshCards/ADHD gap.** The operator's scrap mentions FreshCards and ADHD-friendly UX as desired. Per §23, this is a **doctrinal gap** — Oscar should apply the two-view substrate doctrine to its views (every view is both a workspace AND a substrate for chips/actions/etc.).

### III.10 The C8 Shape Matrix (Ratified §22 + §30)

Per §22 + §30, every module's codex.md MUST contain a C8 Shape Matrix: **per-surface × per-mode × per-chip × per-state**. This is a 4-dimensional matrix.

**Oscar has 0 C8 declarations.** The runtime has implicit shape matrices (e.g., the Blog editor has 4 tones × 4 audiences × N word targets) but none are declared as C8.

### III.11 The Anti-Drift Doctrine (Ratified §08)

Per §08, the unified anti-drift doctrine is **25 rules + 20 gates + 12 failure modes**. The 25 rules include:
- 7 refactoring rules (Rules 1-7)
- 4 cross-cutting verifiers (Rules 8-11)
- 8 workflow sections (Rules 12-19)
- 6 enhancements (Rules 20-25)

**Oscar's `pact/audit/` implements 58 invariants across 6 suites.** These are excellent test coverage. But they are **not formally declared as instantiations of the 25 §08 rules**. The audit directory is excellent in spirit but weak in doctrinal alignment.

**Recommendation:** in Plan A2, when writing `pact/platform/anti-drift.md`, explicitly map each of the 58 invariants to a §08 rule. This converts good tests into doctrinally-aligned anti-drift enforcement.

---

## IV. PROPOSED DOCTRINE — v9-fvw EMPIRICAL IMPLICATIONS

The operator's `avidtech6/v9-fvw` repo (2026-06-22) has produced three concrete doctrine proposals not yet in FVW v8 v0.10.0. These are **ratified-as-proposed by the operator, upstream-pending**:

### IV.1 §30.5 — Format Cannot Be Reorganized Without Throwing Away

> The Recipe format is a CONSTITUTIONAL DECISION. Changing format = throw away prior work + start fresh. New format must be validated against prior winner before adoption.

**Implication for Oscar:** the OSCR- Pact's fragment_id format (`oscar.<domain>.<sub>.<id>.<version>`) is a constitutional decision. Any future change must be validated against the prior format before adoption. (Note: this is consistent with the prior plan's recommendation to use the `oscar.*` format consistently.)

### IV.2 §22 C9 — State Shape Inventory

> Every localStorage key, every in-memory variable that affects UI, every storage shape must be enumerated in `codex.md` C9.

**Implication for Oscar:** the IDB schema (6 stores, multiple indexes) is the most important state shape in Oscar. Revision 1 did not require C9 enumeration. **Revision 2 requires it.** Every module's codex.md MUST declare its C9 state shape: which localStorage keys, which IDB stores, which in-memory variables, and how they affect UI.

### IV.3 §11.12 — Tool A vs Tool B

> DOM extraction (closed-source/generic) and source extraction (owned codebases/FVW rebuilds) are two distinct paths that both produce v0.3-conformant recipes.

**Implication for Oscar:** Oscar is owned source code (FVS-style SPA). The Recipe Books would be extracted via the **source extraction** path (Tool B), not the DOM extraction path (Tool A). This is a process decision that affects how Recipe Books are written.

### IV.4 §30 — Extraction Completeness Additions (already in v0.10.0)

Per §30, the C8 shape matrix must capture **parent layout context** (display, layout_type, grid_template_columns) and **body context** (margin, padding, backgroundColor, fontFamily). This is already in v0.10.0 §30, but Revision 1 did not enforce it on Oscar's views.

**Implication for Oscar:** every view's C8 shape matrix must include parent layout context and body context. This is concrete, enforceable, and missing from the runtime.

---

## V. SCRAP-DERIVED DOCTRINE — OPERATOR REFINEMENTS

The operator's collected refinements (chat, 2026-06-26 to 2026-06-28) cluster into 9 latent doctrine candidates. These are **proposed-by-operator, not yet ratified in any doc**. Revision 1 treated them as if they were already latent doctrine. **Revision 2 labels them as SCRAP, requiring doctrinal ratification before implementation.**

### V.1 The 9 Scrap Refinements → 9 Proposed Doctrine Sections

| Scrap Refinement | Proposed § | Constitutional Status |
|---|---|---|
| Project spine as universal container | §37 | Scrap — proposed |
| Universal artefact graph (voice, media, tasks, calendar, social, notes, trees, reports) | §38 | Scrap — proposed |
| Artefact topology (attach, separate, move, tag, link, version, playback) | §39 | Scrap — proposed |
| Multimodal capture (voice, photo, measurement, GPS, text) | §40 | Scrap — proposed |
| Voice artefact pipeline (audio → raw transcript → edited transcript → version history) + voice-to-AI live transcription + waveform + confirmation flow | §41 | Scrap — proposed |
| Style learning from PDFs (style profiles) + style-aware drafting | §42 | Scrap — proposed |
| Spatial artefact (map + drawing layers) | §43 | Scrap — proposed |
| Comms artefact (email send/receive, social posting) | §44 | Scrap — proposed; **sovereignty tension** |
| Operator workflows (pre-built sequences for surveyors, writers, etc.) | §45 | Scrap — proposed |
| Multi-domain ecosystem (tree, media, social, charity, home, admin) | §37.2 (extension) | Scrap — proposed |
| FreshCards substrate + ADHD-friendly UX | §23 (already ratified) | **Already doctrinal** — Oscar must apply, not ratify |

**Key correction from Revision 1:** the FreshCards/ADHD gap is **not a doctrine gap**. §23 is ratified. Oscar simply hasn't applied it. This is a runtime gap, not a doctrine gap. Plan C10 reframes this accordingly.

### V.2 Constitutional Tensions in the Scrap

| Tension | Source | Resolution |
|---|---|---|
| **Sovereignty vs Comms backend** | §44 (scrap) requires email/social backend; Oscar's sovereignty says browser-only | **Gated decision**: operator must choose. See Plan C7. |
| **§15.3 micro-model ceiling vs Qwen 0.5B** | Scrap's brain manifest violates ratified §15.3 by 250× | **Propose §15.3-bis amendment** in Plan B1 |
| **§33 two modes vs Oscar's third mode** | Scrap's reconstruction status is undefined per ratified §33 | **Propose §33.5 amendment** in Plan B1 |
| **§44 Comms requires backend vs §15.6 micro-model says no network** | Comms backend contradicts micro-model "zero network" rule | **Layered exception**: §44 is a constitutional exception to §15.6 for comms only |

### V.3 The Latent §37-§45 as a Single Doctrine

Per Revision 1, the 9 latent doctrines cluster into a **Project Spine Doctrine** — a single constitutional package declaring:
- Projects are universal (§37)
- Every project has the universal artefact graph (§38)
- Artefacts have typed topology (§39)
- Capture is multimodal (§40)
- Voice has a 5-stage pipeline (§41)
- Style is learned from samples (§42)
- Spatial artefacts are first-class (§43)
- Comms are first-class with backend exception (§44)
- Operator workflows are declarative (§45)

**Revision 2 re-affirms this clustering** but adds a constitutional guard: **§37-§45 must be ratified in OSCR- before implementation, and proposed upstream to FVW v8 before being treated as binding doctrine**. The Plan phases them as OSCR- local ratification first, upstream proposal second.

---

## VI. RE-VISITED FINDINGS

### VI.1 What's Sound (Re-confirmed)

- Runtime works (87 files, ~8,660 LOC, 58 invariants, deployed at `oscar-platform.pages.dev`)
- Sovereignty holds externally (no FVS imports, 6 forbidden import patterns enforced)
- 9-layer Smart adapter dispatcher is sound
- Brain module's rules-first-then-cached-then-AI is correct
- 4-part response format is correct
- "Ask, don't guess" rule is correct
- ArboricultureProvider + 5-adapter architecture is clean
- 6 IDB stores with DB_VERSION 2 is correct
- 4-state dock (bar / sheet-min / sheet-full / peek) is canonical per §11
- 4 canonical anchor types are declared

### VI.2 What's Thin (Ratified Doctrine Gap)

- 0 of 8 mandatory artefacts in canonical form
- 0 of 12 modules Module-Pact Registered (§35)
- 0 of 8 codex items declared canonically (§22)
- 0 trace atlas (§04)
- 0 DNA (§03)
- 0 Recipe (§00)
- 0 of 9 universal things in any rules.md (§11.9)
- 0 of 6 recipe-book/smart/ JSON files (§16.5)
- 0 of 14 Smart X toggles declared constitutionally (§16.3)
- 0 C9 state shape inventory (§22 v9 proposal)
- 0 C8 shape matrix declarations (§22 + §30)
- 0 anti-drift doctrine alignment (§08) — tests are good, mapping is absent
- 0 declared reconstruction mode (§33) — Oscar is a third mode
- 1 wrong claim: brain is not §15 micro-model (250× over)

### VI.3 What's Missing (Scrap → Doctrinal Gap)

- 0 of 9 latent doctrines ratified (Project Spine, Universal Artefacts, Topology, Multimodal, Voice, Style, Map, Comms, Workflows)
- 0 multi-domain project type support
- 0 voice / photo / GPS / measurement modalities
- 0 voice pipeline (5 stages)
- 0 style profiles
- 0 map module
- 0 comms (with sovereignty tension unresolved)
- 0 operator workflows
- 0 FreshCards substrate application (§23 is ratified; Oscar hasn't applied it)

### VI.4 What's Wrong

- The README's `oscar.*` naming convention is **declared but undelivered** — zero actual fragment specs
- The `fragments/`, `recipes/`, `decisions/` subdirs are **declared but empty** in filesystem
- The brain manifest's Qwen 0.5B (500M params) **violates §15.3 micro-model ceiling by 250×**
- The reconstruction mode is **a third mode not declared in §33**
- Comms (scrap §44) **requires backend services** which violates sovereignty invariant — unresolved
- The README calls itself the "Pact" but is missing the 3 required documents per §02.1.1
- The audit directory's 58 invariants are **not mapped to §08's 25 rules** — good tests, weak doctrine
- The 14 Smart X features are **not declared as constitutional toggles** in `features.json` (§16.5)

---

# PART 2 — DOCTRINAL PLAN (REVISION 2)

## VII. PLAN POSTURE

The plan is **doctrinal and architectural**. It corrects Revision 1's three categories of gap:
- Adds the 9 universal things in `rules.md` (§11.9) — explicit per module
- Adds the 14 Smart X constitutional toggles + 6 `recipe-book/smart/` JSON files (§16.5)
- Adds the v9-fvw empirical proposals (§30.5, §22 C9, §11.12)
- Separates ratified / proposed / scrap tiers throughout
- Adds a C8 shape matrix requirement per view
- Adds an anti-drift mapping requirement (58 invariants → §08 25 rules)

**Three axes:**
- **Axis A: FVW v8 v0.10.0 ratified alignment** — close the 8-artefact gap, §35 module registration, §00 Recipe, §11.9 9-things, §16.5 6 JSON files
- **Axis B: Constitutional amendments** — propose §15.3-bis (browser-loadable tier), §33.5 (Sovereign SPA Mode), §44 (comms backend exception) upstream
- **Axis C: Scrap → Doctrine → Runtime** — operator's scrap, ratified locally in OSCR-, implemented in runtime, proposed upstream to FVW v8

**Doctrine-defines-runtime-instantiates pattern (per §11.12):** every change is first declared in the Pact (doctrine), then implemented in the runtime. The reverse is anti-drift (§08 Rule 3 — no invention).

---

## VIII. PHASE A0 — DOCTRINAL RECONNAISSANCE (PACT-ONLY)

**Goal:** Before writing any artefact, conduct a §08 Rule 1 (Verification-before-refactor) extraction. This is the canonical first step in any reconstruction per §08.

**Duration:** 1-2 days. Pact-only.

### A0.1 — Write `pact/extraction/baseline-snapshot.md`

Capture Oscar's current state in an **anti-drift baseline**:
- File tree of `app/` (87 files, 8,660 LOC)
- 12 module directories with file counts
- 6 IDB stores with key paths
- 5 LLM adapters with provider IDs
- 58 invariants in 6 suites
- 4-state dock with state names
- 4 canonical anchor types

This is the **shadow** that future refactors will diff against. Per §13 (Shadows doctrine), this is constitutional.

### A0.2 — Write `pact/extraction/runtime-inventory.md`

For every module, list:
- Files (with line counts)
- Exports (public API surface)
- Imports (dependencies)
- IDB store usage
- State variables
- Event handlers

This is the **source-of-truth** for §22 C1 (behaviour inventory) and §22 C9 (state shape inventory).

### A0.3 — Write `pact/extraction/sovereignty-baseline.md`

Capture the 6 sovereignty principles with their enforcement:
- 6 forbidden import patterns
- 1 grep test (`audit/sovereignty-checks.ts`)
- 1 CI gate
- 1 build-time check

This is the **§08 anti-drift** applied to sovereignty.

### A0.4 Phase A0 Outcome

After A0, Oscar has a **reconstructable baseline**. Any future refactor can be diffed against this baseline to detect drift. This satisfies §13 (Shadows doctrine) and §08 Rule 1 (Verification-before-refactor).

---

## IX. PHASE A1 — FVW v8 v0.10.0 STRUCTURAL ALIGNMENT (PACT-ONLY)

**Goal:** Close the 8-artefact gap. Write documents, declare fragments, register modules. No runtime changes.

**Duration:** ~4-5 days. Pact-only.

### A1.1 — Restructure Pact to FVW v8 §02 9-folder layout

**Pact-only. No runtime changes.**

Restructure `pact/` to canonical FVW v8 §02 9-folder layout. Rename existing `pact/audit/` → `pact/vp/`. Populate the 3 empty subdirs (`fragments/`, `recipes/`, `decisions/`). Add 4 new subdirs (`codex/`, `dna/`, `trace-atlas/`, `overlays/`).

```
pact/
├── platform/                  # was pact/platform/ (renamed content)
│   ├── app-pact.md            # NEW: the main pact document
│   ├── invariants.md          # NEW
│   ├── anti-drift.md          # NEW
│   ├── sovereignty.md         # KEEP
│   └── README.md              # KEEP (as entry doc)
├── codex/                     # NEW: 12 per-module codex files
│   ├── oscar.assistant.codex.md
│   ├── oscar.brain.codex.md
│   ├── oscar.writing.codex.md
│   ├── oscar.intelligence.codex.md
│   ├── oscar.data.codex.md
│   ├── oscar.views.codex.md
│   ├── oscar.shell.codex.md
│   ├── oscar.ux.codex.md
│   ├── oscar.export.codex.md
│   ├── oscar.search.codex.md
│   ├── oscar.onboarding.codex.md
│   └── oscar.branding.codex.md
├── fragments/                 # NEW CONTENT: 50+ oscar.* fragment specs
│   └── (50+ files, see A1.3)
├── recipes/                   # NEW CONTENT: 12 Recipe Books (per §11)
│   └── (12 module directories × 10 items)
├── dna/
│   └── app.dna.json           # §03
├── trace-atlas/
│   └── atlas.json             # §04
├── overlays/                  # §01: customisation layers
│   ├── README.md
│   └── dark-green-palette.overlay.md
├── vp/                        # renamed from audit/
│   ├── sovereignty.test.ts
│   ├── runtime.test.ts
│   ├── intelligence.test.ts
│   ├── data.test.ts
│   ├── ux.test.ts
│   ├── build.test.ts
│   ├── adversarial.test.ts
│   └── FVRE-GATE.md
├── decisions/                 # NEW CONTENT
│   └── (8+ decision logs)
└── extraction/                # from Phase A0
    ├── baseline-snapshot.md
    ├── runtime-inventory.md
    └── sovereignty-baseline.md
```

### A1.2 — Write the 4 missing `pact/platform/` documents

**Pact-only.**

1. **`app-pact.md`** — the main pact document. Replaces README.md's role. Declares:
   - Oscar's identity (`studio.oscar.platform`)
   - The 6 sovereignty principles (subordinated to app-pact.md)
   - The Reconstruction Mode Declaration (Sovereign SPA Mode, third mode; see DO-001)
   - The Smart X toggle declaration (3 enabled, 6 partial, 5 absent; see §16.5 features.json)
   - The micro-model status (STUB; see DO-002)
   - Cross-references to all fragments + codex + recipes
   - The C8 shape matrix (per-view, per-state)

2. **`invariants.md`** — 12+ invariants Oscar must always satisfy:
   - INV-1 to INV-12 from Revision 1
   - **NEW** INV-13: IDB schema v2 stable
   - **NEW** INV-14: 4-state dock states declared
   - **NEW** INV-15: 5 adapters registered (with provider IDs)
   - **NEW** INV-16: 6 standards library complete (BS5837, BS3998, BS8545, AIA, AMS, ARB)
   - **NEW** INV-17: 4 canonical anchor types declared
   - **NEW** INV-18: BackStack 1000/999 invariant
   - **NEW** INV-19: 14 Smart X toggles declared in features.json
   - **NEW** INV-20: 6 recipe-book/smart/ JSON files present

3. **`anti-drift.md`** — apply §08's 25 rules + 20 gates + 12 failure modes to Oscar:
   - **Rule 1 (Verification-before-refactor)**: Phase A0 baseline snapshot
   - **Rule 2 (Safe Diff Protocol)**: every change is a micro-diff; never wholesale rewrites
   - **Rule 3 (No invention)**: no new components/modules/handlers/state without operator approval
   - **Rule 4 (Explicit binary verification)**: every refactor step verified by App-VP test
   - **Rule 5-7 (DOM/Behaviour/Drift)**: explicit verification per refactor
   - **Rules 8-11 (Cross-cutting verifiers)**: spec-conformance, no-values-in-plan, coverage matrix, approval gate rigor
   - **Rules 12-19 (Workflow sections)**: capability declaration, do-not-proceed, contract primacy, anti-drift enforcement, plan-as-law, fallback behaviour, user-simulator, re-anchor cadence, coverage matrix
   - **Rules 20-25 (Enhancements)**: extracted from operator's v8 RFC
   - **20 gates** (hard PASS/FAIL checks): from plan-rules.md §2
   - **12 failure modes** (mapped to gates): from plan-rules.md §3
   - **§08 R-DRIFT-26** (from v9-fvw): if rebuild is wrong, recipe is wrong
   - Plus Oscar-specific rules: never import Mantine, never import FVS, never create non-`oscar.*` fragment_ids, never overwrite history (use versions)

4. **`README.md`** — keep as entry doc. Frame the restructured Pact. Cross-reference to all documents.

### A1.3 — Declare 50+ `oscar.*` fragment specs

**Pact-only.**

Each fragment spec is a small markdown file in `pact/fragments/`. Each declares (per §35.5):
- `fragment_id`: canonical `oscar.*` ID
- `domain`: PLATFORM | DATA | ASSISTANT | BRAIN | WRITING | UX | VIEW | SHELL
- `rule`: 1-3 sentence declaration
- `source`: which runtime file implements it
- `bound_to_modules`: which modules consume it
- `status`: SHIPPED | STUB | PLANNED
- `version`: `.001`, `.002`, etc.

The 50+ fragments cover every existing capability (revision 1 listed them; this revision confirms them as the canonical fragment inventory).

### A1.4 — Register modules with `constitutional_fragments` (§35)

**Pact-only.**

For every module, write a `module.json` at the module root with `constitutional_fragments` listing the fragments the module consumes. After A1.4, drift-check MP-1 can be implemented (in Phase A2.4) and would pass the forward check on every module.

### A1.5 — Populate `pact/decisions/` with retroactive decisions

**Pact-only.**

8 retroactive decision logs:
- DO-001: Reconstruction Mode is "Sovereign SPA Mode" (third mode; see Plan B1)
- DO-002: Propose §15.3-bis amendment for browser-loadable models (see Plan B1)
- DO-003: Ratify `oscar.*` naming convention
- DO-004: Ratify IDB schema v2 (6 stores)
- DO-005: Ratify 5-adapter architecture + ArboricultureProvider
- DO-006: Ratify static grep sovereignty checks
- DO-007: Ratify 9-layer Smart adapter dispatcher
- DO-008: Ratify 4-part response format

### A1.6 Phase A1 Outcome

After A1:
- `pact/platform/` has 5 documents (4 new + 1 existing)
- `pact/fragments/` is populated (50+ specs)
- `pact/decisions/` is populated (8+ decisions)
- 12 modules have `module.json` with `constitutional_fragments`
- `pact/vp/` is renamed from `pact/audit/` (58 invariants preserved)

**4 of 8 mandatory artefacts in canonical form.** (Pact, fragments, vp, decisions; missing: codex, dna, trace-atlas, recipe.)

---

## X. PHASE A2 — RECIPE BOOKS + CODEX + DNA + ATLAS (PACT-ONLY)

**Goal:** Write the 4 remaining mandatory artefacts (codex, dna, trace-atlas, recipe) + 9-thing rules.md per module.

**Duration:** ~7-10 days. Pact-only. Substantial doctrine work.

### A2.1 — Write `pact/dna/app.dna.json` (§03)

**Pact-only.**

```json
{
  "schema": "freshvibe-way-v8.app-dna",
  "schema_version": "1.0.0",
  "app_id": "studio.oscar.platform",
  "version": "1.0.0",
  "lineage": [
    "avidtech6/oscar-ai (R1-R18, original Oscar website conversion)",
    "studio.oscar.platform (Phase 1-10 sovereign SPA pivot, 2026-06)"
  ],
  "supersedes": "avidtech6/oscar-ai/R18 (the original Oscar website)",
  "recipe_id": "studio.oscar.platform.recipe.v1",
  "invariants_ref": "pact/platform/invariants.md",
  "doctrinal_extensions": {
    "reconstruction_mode": "Sovereign SPA Mode (third mode, see DO-001)",
    "micro_model_status": "STUB — 500M param model exceeds §15.3 ceiling; deferred to DO-002 amendment"
  }
}
```

### A2.2 — Write `pact/trace-atlas/atlas.json` (§04)

**Pact-only.**

A JSON file with the 5-level chain per §04: UI surface → behaviour → module → file → test. Each entry has:
- `surfaces` (e.g., home, surveys, notes, reports, settings, blog, assistant-dock)
- `behaviours` (e.g., render-anchors, list-surveys, classify-tree)
- `modules` (assistant, brain, views, etc.)
- `files` (specific TS/TSX paths)
- `tests` (the 58 invariants, mapped to specific behaviours)

**8 of 8 mandatory artefacts in canonical form** after A2.2.

### A2.3 — Write the 6 `recipe-book/smart/` JSON files (§16.5)

**Pact-only. New in this revision.**

For every Product Smart App at Level 4+ (Oscar is at Level 4 with brain-manifest-aspiration-to-Level-5):

```
pact/recipes/smart/
├── features.json      # which of the 14 Smart X features are enabled
├── engines.json       # which Smart Engines are active
├── modules.json       # which Smart Modules are adopted
├── micro-model.json   # which micro-model is embedded (Qwen 0.5B declared as STUB until §15.3-bis)
├── hooks.json         # which hooks the smart features expose
└── seeds.json         # which seeds the smart features declare
```

**Example `features.json`:**
```json
{
  "schema": "freshvibe-way-v8.smart-features",
  "version": "0.1.0",
  "enabled": [
    "smart-chat",
    "smart-explain",
    "smart-engines"
  ],
  "partial": [
    "smart-cms",
    "smart-input",
    "smart-docs",
    "smart-peek",
    "smart-preview",
    "smart-metadata"
  ],
  "absent": [
    "smart-insights",
    "smart-rebuild",
    "smart-modes",
    "smart-search",
    "smart-history"
  ]
}
```

This is the **constitutional declaration** of which Smart X features Oscar ships. The user (operator) can toggle features per project.

### A2.4 — Write the 12 per-module Recipe Books (10 items each per §11)

**Pact-only. Substantial.**

For every module, write the 10 items per §11:

1. `recipe.md` (§11.1: A. Product, B. Structural Contract incl. **Reconstruction Mode Declaration per §33**, C. Reconstruction Notes)
2. `codex.md` (§11.1 + §22: pure behaviour, 8 contract items C1-C8 + **C9 State Shape Inventory per v9-fvw**)
3. `rules.md` (§11.9: 9 universal things — see A2.5)
4. `module-meta.json` (§11.2: identity, category, gallery linkage, **bound_to_fragments per §35.5**)
5. `ingredients.json` (§11.2: provenance scaffolding)
6. `diffs/` (§11.2: empty initially)
7. `trace-atlas/` (§11.2: per-module trace subset)
8. `dna/` (§11.2: per-module DNA subset)
9. `plan.md` (§11.9: atomic implementation steps)
10. `coverage-matrix.md` (§11.9: 5-column verification grid)

**12 modules × 10 items = 120 files.** Most are small (under 100 lines each).

### A2.5 — The 9 Universal Things in rules.md (§11.9) — Specified

**Pact-only. The major Revision 2 addition.**

Per §11.9, every module's `rules.md` MUST contain these 9 things. For each of Oscar's 12 modules, the rules.md must instantiate:

1. **Capability declaration**
   ```markdown
   ## 1. Capability declaration

   ### Reconstruction Mode Declaration (per §33)
   - **Mode:** Sovereign SPA Mode (third mode, see DO-001)
   - **Target runtime:** React 18 + TypeScript + Vite (no Mantine)
   - **Module file extension:** .tsx
   - **View fragment format:** React components in <Name>.tsx
   - **State management:** React hooks (useState, useContext, useReducer)
   - **Theme tokens:** CSS custom properties (no Mantine theme provider)
   - **Render approach:** JSX with conditional render

   ### Capability statement
   I CAN:
   - [module-specific list]
   I CANNOT:
   - [module-specific list]
   External validation required for:
   - [module-specific list]
   ```

2. **Do-not-proceed rule**
   ```markdown
   ## 2. Do-not-proceed rule
   If [module-specific check] fails, I MUST stop and write blocker.md ...
   ```

3. **Contract primacy**
   ```markdown
   ## 3. Contract primacy
   This module's contract is: recipe.md (3 sections) + codex.md (C1-C8 + C9).
   Scaffolding files are NOT the contract.
   ```

4. **Anti-drift enforcement (4 numbered checks)**
   - Recipe → Source Check
   - Visual Diff Check
   - Behavioural Check
   - Contract Check

5. **Plan-as-law** — atomic steps in `plan.md`

6. **Fallback behaviour** — what happens when generation fails

7. **User-simulator requirement** — C6 user simulations must be runnable

8. **Re-anchor cadence** — when to re-read the contract

9. **Coverage matrix** — `coverage-matrix.md` with 5 columns (source feature / source-line / recipe claim / impl status / test status)

**Every one of Oscar's 12 modules' rules.md must satisfy all 9 things.** This is enforceable via the App-VP test suite (a new check `vp/rules-md-checks.ts`).

### A2.6 — Write `pact/codex/<module>.codex.md` with C1-C8 + C9

**Pact-only. Substantial.**

For every module, write the codex with **8 ratified contract items (C1-C8) + 1 proposed (C9 State Shape Inventory per v9-fvw)**:

- **C1 — Behaviour inventory**: every handler, lifecycle, state transition, side effect enumerated with source line citations
- **C2 — State machine with transitions**
- **C3 — Side effect list** (IDB writes, localStorage writes, DOM updates, network calls)
- **C4 — Input validation contract**
- **C5 — Failure modes**
- **C6 — User simulation list** (5-10 representative flows)
- **C7 — Reproducibility test** (deterministic guarantee)
- **C8 — Shape matrix** (per-surface × per-mode × per-chip × per-state, per §30)
- **C9 — State Shape Inventory** (per v9-fvw proposal: every localStorage key, in-memory variable, IDB store that affects UI)

**The C8 shape matrix is the major Revision 2 addition.** For each module, the matrix declares:
- Per **surface**: which UI surfaces the module owns
- Per **mode**: which modes the module supports (view, edit, preview, AI mode, etc.)
- Per **chip**: which action chips the module exposes (navigate, open-item, compose, export)
- Per **state**: which runtime states the module has (dormant, active, expanded, peeked, etc.)

This is a 4-dimensional matrix. For the Assistant module, for example:
- Surfaces: AssistantDock (4 states: bar, sheet-min, sheet-full, peek)
- Modes: text-only, voice-to-AI (Phase C4), photo (Phase C4), GPS (Phase C4)
- Chips: navigate, open-item, compose, export (4 per §16 + latent §44)
- States: dormant, active, expanded, peeked

The matrix is **per-module**, declarative, and enforceable.

### A2.7 — Write `pact/overlays/` (customisation layers)

**Pact-only.**

Two overlay specs:
- `dark-green-palette.overlay.md` (the current default)
- `light-mode.overlay.md` (planned)

Overlays are **per-project customisation layers** that vary brand, theme, palette, typography. Per §01, overlays are a mandatory artefact.

### A2.8 — Add `vp/rules-md-checks.test.ts` (App-VP test)

**Pact + minimal runtime. The major Revision 2 addition.**

A new App-VP test that verifies every module's `rules.md` contains all 9 universal things per §11.9. This converts the 9-thing doctrine from prose to enforceable rule.

### A2.9 — Add `vp/c9-state-shape-checks.test.ts`

**Pact + minimal runtime.**

A new App-VP test that verifies every module's codex.md contains a C9 State Shape Inventory per the v9-fvw proposal.

### A2.10 — Add `vp/c8-shape-matrix-checks.test.ts`

**Pact + minimal runtime.**

A new App-VP test that verifies every module's codex.md contains a C8 Shape Matrix (per-surface × per-mode × per-chip × per-state).

### A2.11 — Add `vp/smart-features-checks.test.ts` (§16.5)

**Pact + minimal runtime.**

A new App-VP test that verifies the 6 `recipe-book/smart/` JSON files exist and are well-formed.

### A2.12 Phase A2 Outcome

After A2:
- **8 of 8 mandatory artefacts in canonical form**
- 12 modules with full Recipe Books (10 items each)
- 12 codex files with C1-C8 + C9
- 12 rules.md with all 9 universal things
- 6 `recipe-book/smart/` JSON files
- DNA + Trace Atlas + Overlays

**App-VP test count grows from 58 to ~70** (added: rules-md-checks, c9-state-shape-checks, c8-shape-matrix-checks, smart-features-checks, plus 12 coverage-matrix tests).

---

## XI. PHASE B1 — CONSTITUTIONAL AMENDMENTS (DOCTRINAL RFCs)

**Goal:** Propose 3 amendments to FVW v8 upstream. Oscar's local ratification via DO-001, DO-002, DO-007 (new).

**Duration:** 2-3 days. Pact-only.

### B1.1 — Propose §15.3-bis amendment (browser-loadable model tier)

**Pact-only. Doctrinal RFC.**

The current §15.3 declares micro-models MUST be 100k-2M parameters. Qwen 0.5B (500M params) exceeds this by 250×.

**Proposed §15.3-bis:**

Add a "browser-loadable model" tier (100k-1B params) between micro-model and cloud LLM:

| Tier | Parameters | Runtime | Example |
|---|---|---|---|
| Tiny micro-model | 100k-300k | WASM, WebGPU, ONNX | DistilBERT-tiny |
| Small micro-model | 300k-600k | WASM, WebGPU, ONNX, llama.cpp | Phi-2-mini |
| Medium micro-model | 600k-1M | WASM, WebGPU, llama.cpp, Transformers.js | Qwen-0.1B |
| **Browser-loadable model** (NEW) | **1M-1B** | **WASM, WebGPU, llama.cpp, Transformers.js, ggml/GGUF** | **Qwen-0.5B, Llama-3.2-1B** |
| Cloud LLM | 1B+ | server-required | GPT-4, Claude |

**Rationale:** the constitutional 2M ceiling was set in v6 (2026-06-13) before the Qwen 0.5B / Llama 3.2 / Phi-3 era. Models in the 100M-1B range now run efficiently in browsers (WebGPU + llama.cpp + GGUF Q4_K_M). The ceiling is anachronistic.

**Oscar's brain status after amendment:** Level 5 (Browser-Loadable Model), not Level 5 (Embedded Micro-Model). Qwen 0.5B Q4_K_M fits.

**Decision needed:** operator must propose this amendment to `avidtech6/freshvibe-way-v8` upstream. Until ratified, Oscar's brain is constitutionally STUB (declared but cannot be constitutionally embedded).

**Local decision:** `pact/decisions/DO-002-micro-model-amendment.md` declares Oscar's local ratification: "Oscar will treat Qwen 0.5B Q4_K_M as a Level-5 browser-loadable model, pending upstream §15.3-bis ratification."

### B1.2 — Propose §33.5 amendment (third reconstruction mode)

**Pact-only. Doctrinal RFC.**

The current §33 declares only two reconstruction modes. Oscar is a third mode.

**Proposed §33.5:**

Add "Sovereign SPA Mode" as a third reconstruction mode:

| Mode | Stack | Container | FVW Imports |
|---|---|---|---|
| App Mode | vanilla HTML/CSS/JS | standalone | none |
| Studio Module Mode | React 18 + TS + Mantine 7 + Vite | FVS Studio container | yes |
| **Sovereign SPA Mode** (NEW) | **React 18 + TS + Vite (no Mantine)** | **standalone** | **none** |

**Properties of Sovereign SPA Mode:**
- React framework, no Mantine (or similar UI lib)
- TypeScript strict mode
- Vite build
- Standalone deployment (CF Pages, Vercel, etc.)
- Zero FVS / FreshVibe imports
- IDB persistence (browser-only)
- localStorage namespaced
- Sovereign brand, palette, typography

**Local decision:** `pact/decisions/DO-001-reconstruction-mode.md` declares Oscar's mode as "Sovereign SPA Mode" with full Structural Contract declaration in `pact/recipes/recipe.md` Section B.

### B1.3 — Propose §44 amendment (Comms backend exception)

**Pact-only. Doctrinal RFC. Gated on operator decision.**

Per scrap §44, Comms requires backend services. Oscar's sovereignty invariant says browser-only. This is a **constitutional tension** that requires an explicit amendment to either Oscar's sovereignty OR FVW v8's product-app rules.

**Two options:**

**Option A — Strict sovereignty (no comms):**
- Oscar remains browser-only
- Comms (scrap §44) is not implemented
- The operator's scrap is partially unfulfilled

**Option B — Comms backend exception (recommended):**
- Propose §44-bis to FVW v8: "Comms is a constitutional exception to product-app browser-only rule. Comms requires dedicated backend services. The exception is operator-controlled and auditable."
- Oscar's sovereignty.md is amended to add: "Comms (§44) is the constitutional exception. Email and social posting use dedicated backend services. These services are minimal, dedicated to comms, and operator-controlled."

**Decision needed:** operator must choose. Until chosen, Phase C7 is gated.

**Local decision:** `pact/decisions/DO-007-comms-exception.md` (new, gated) declares the chosen option.

### B1.4 Phase B1 Outcome

After B1:
- DO-001 declares Oscar as Sovereign SPA Mode (local ratification)
- DO-002 proposes §15.3-bis amendment (local + upstream)
- DO-007 declares Comms exception choice (gated on operator)
- All 3 are upstream proposals to `avidtech6/freshvibe-way-v8`

---

## XII. PHASE B2 — RECONSTRUCTABILITY DEMONSTRATION (PACT + MINIMAL RUNTIME)

**Goal:** Demonstrate §00 Reconstructability Invariant.

**Duration:** 2-3 days. Pact + minimal runtime.

### B2.1 — Write `pact/recipes/recipe.md` (workspace-level recipe, per §34)

**Pact-only.**

A workspace-level recipe that describes Oscar **engine-agnostically**. The implementation that satisfies this recipe is engine-specific (Sovereign SPA Mode). Per §34, the translation is "lossy in code, lossless in contract."

```markdown
# Oscar Platform — Workspace Recipe (Engine-Agnostic)

## What Oscar is

A sovereign arboriculture SPA. The app supports surveys, notes, reports, blog writing, 
and an AI assistant that classifies trees, drafts reports, and answers questions about 
UK arboriculture standards.

## The 12 modules (per §11)

[12 module descriptions, engine-agnostic]

## Reconstruction procedure (engine-agnostic)

1. Read this recipe + the 8 mandatory artefacts (§01)
2. For each module, read its Recipe Book (10 items per §11)
3. Read the FVW v8 doctrine (canonical reference)
4. Implement per the declared mode (Sovereign SPA Mode per DO-001)
5. Verify with the 5-level chain in the Trace Atlas (§04)
6. Run the App-VP test suite (~70 invariants)
7. Deploy per the deployment doctrine

## The contract

The contract is the 8 mandatory artefacts + the per-module Recipe Books + the constitution.
The implementation is the runtime.
The contract is engine-agnostic. The implementation is engine-specific.
```

### B2.2 — Write `pact/scripts/verify-reconstructability.sh`

**Pact + minimal runtime.**

A script that:
1. Reads the Recipe + the 8 mandatory artefacts
2. Verifies every fragment spec exists in the runtime source
3. Verifies every module has a Recipe Book with 10 items
4. Verifies every codex has C1-C9
5. Verifies every rules.md has all 9 universal things
6. Verifies the 6 `recipe-book/smart/` JSON files exist
7. Verifies DNA + Trace Atlas + Overlays
8. Runs the App-VP test suite
9. Builds the app
10. Reports PASS/FAIL

**If PASS, Oscar satisfies §00.**

### B2.3 Phase B2 Outcome

After B2, **Oscar is structurally FreshVibe-compatible per §00 Reconstructability Invariant.** A senior architect with the Recipe + FVW v8 doctrine could rebuild Oscar in another engine (Svelte, SolidJS) by following the Recipe.

---

## XIII. PHASE C1 — PROJECT SPINE (SCRAP §37, LOCAL RATIFICATION)

**Goal:** Add the Project Spine as a constitutional artefact. Locally ratified in OSCR- (proposed upstream to FVW v8).

**Duration:** ~5-6 days. Pact + runtime.

### C1.1 — Local ratification in OSCR- (Pact-only)

`pact/latent/section-37-project-spine.md` — local ratification of the latent §37 doctrine. Declares:
- Every Oscar workspace contains zero or more projects
- Project types: initial taxonomy `tree` (the only declared type); extensibility reserved
- Universal artefact graph (§38) — initially 6 types, extensible
- Projects sovereign within Oscar
- Project lifecycle: `draft → active → paused → archived → deleted` (each transition auditable)

### C1.2 — Add Project model + IDB store (Runtime)

- `app/src/data/models/Project.ts` — typed model
- New IDB store: `projects` (DB_VERSION 2 → 3 migration)
- `projectsRepo`
- Migration v2 → v3: every existing artefact gets `project_id = "default"`

### C1.3 — Add Projects module + view (Runtime)

- `app/src/projects/` — CRUD, project switcher, lifecycle
- `app/src/views/Projects.tsx` — projects dashboard
- Dock chip: "Projects"
- Header: project name + type badge + state badge

### C1.4 — Modify all 6 existing views to scope to project (Runtime)

- Every view lists artefacts scoped to current `project_id`
- "Create" actions inherit current `project_id`

### C1.5 — Add fragments, codex, Recipe Book, Atlas entry, DNA, App-VP test (Pact)

- `pact/fragments/oscar.project.*.001.md` (10+ new fragments)
- `pact/codex/oscar.projects.codex.md` (C1-C9 with C8 shape matrix)
- `pact/recipes/projects/{recipe.md, codex.md, rules.md, module-meta.json, ingredients.json, plan.md, coverage-matrix.md}`
- `pact/trace-atlas/atlas.json` updated with project-related surfaces
- `pact/dna/app.dna.json` updated with project spine lineage
- `pact/vp/project-checks.test.ts` (new App-VP test)

### C1.6 Phase C1 Outcome

After C1:
- Project Spine (§37) locally ratified in OSCR-
- Every artefact belongs to a project
- Projects dashboard exists as a first-class view
- Every existing view is project-scoped
- **Runtime + Pact + App-VP all in sync** (per §08 anti-drift Rule 3)

---

## XIV. PHASE C2 — UNIVERSAL ARTEFACT GRAPH (SCRAP §38)

**Goal:** Extend the artefact graph from 6 to 9 types. Add voice, media, calendar. Defer tasks, social to C4/C7.

**Duration:** ~8-10 days. Pact + runtime.

### C2.1 — Add Voice artefact type

- `app/src/data/models/Voice.ts` (audio_blob, raw_transcript, edited_transcript, duration, version_history per §41)
- IDB store: `voices`
- `voicesRepo`
- `app/src/voice/` — capture (MediaRecorder), storage, playback (HTML5 audio)
- `app/src/views/Voice.tsx`
- Dock chip: "Voice"

### C2.2 — Add Media artefact type

- `app/src/data/models/Media.ts` (image_blob, drawing_data, type: photo|drawing|map_layer)
- IDB store: `media`
- `mediaRepo`
- `app/src/media/` — capture, storage, display
- `app/src/views/Media.tsx`
- Dock chip: "Media"

### C2.3 — Add Calendar artefact type

- `app/src/data/models/Calendar.ts` (event_type, date, recurrence, project_id, linked_artefacts)
- IDB store: `events`
- `eventsRepo`
- `app/src/calendar/` — month/week/agenda views, event CRUD
- `app/src/views/Calendar.tsx`
- Dock chip: "Calendar"

### C2.4 — Per-type codex + Recipe Book + App-VP tests (Pact)

For each of the 3 new artefact types:
- `pact/codex/oscar.{voice,media,calendar}.codex.md`
- `pact/recipes/{voice,media,calendar}/` (10 items each)
- `pact/fragments/oscar.{voice,media,calendar}.*.001.md` (5+ each)
- `pact/vp/{voice,media,calendar}-checks.test.ts` (new App-VP tests)

### C2.5 Phase C2 Outcome

After C2:
- 9 of 9 universal artefacts (3 deferred to later phases: tasks to C3, social to C7)
- 3 new views (Voice, Media, Calendar)
- 3 new modules with full Recipe Books
- App-VP test count: ~80

---

## XV. PHASE C3 — ARTEFACT TOPOLOGY (SCRAP §39)

**Goal:** Add the topology layer. Tagging, linking, versioning, playback. Replaces the implicit `tags` fields in Notes and BlogPost with a constitutional topology.

**Duration:** ~6-7 days. Pact + runtime.

### C3.1 — Add the topology data model

- `app/src/data/models/Tag.ts`, `Link.ts`, `Version.ts`
- IDB stores: `tags`, `links`, `versions` (DB_VERSION 3 → 4)

### C3.2 — Add the topology module

- `app/src/topology/` — tag CRUD, link CRUD, version CRUD, playback (read-only history view)
- All topology models have `project_id`

### C3.3 — Apply topology to all 9 artefacts

- Every artefact supports tags, links, versions, playback per §39

### C3.4 — Pact + App-VP

- `pact/codex/oscar.topology.codex.md`
- `pact/recipes/topology/` (10 items)
- `pact/fragments/oscar.topology.*.001.md` (10+)
- `pact/vp/topology-checks.test.ts`

### C3.5 Phase C3 Outcome

After C3:
- Every artefact is tagged, linkable, versioned, playable
- Topology is constitutional (per scrap §39)
- The "every save overwrites" gap is closed
- App-VP test count: ~85

---

## XVI. PHASE C4 — MULTIMODAL CAPTURE (SCRAP §40)

**Goal:** Add voice, photo, GPS, measurement modalities to the assistant input box.

**Duration:** ~5-6 days. Pact + runtime.

### C4.1 — Multimodal capture UI in AssistantDock

- Modify `app/src/assistant/AssistantDock.tsx`:
  - Voice button (microphone → voice capture mode)
  - Photo button (camera icon → file picker / camera)
  - GPS button (pin → geolocation)
  - Existing text input remains
  - Active modality is visible (icon highlighted)
  - Switching preserves partial input

### C4.2 — Voice-to-AI live transcription (§41)

- Web Speech API for real-time transcription
- Stream interim results into input box as user speaks
- Final transcript sent to assistant as text prompt
- Operator can edit before sending

### C4.3 — Voice note recording mode (§41)

- 5-stage pipeline: audio → raw_transcript → edited_transcript → version_history → final_artefact
- After capture: assistant confirmation flow ("Voice note recorded and tagged for X — is that correct?")
- Waveform rendering (Canvas + AudioBuffer)

### C4.4 — Photo capture (§40)

- File input + camera capture
- Stored as Media artefact (linked from C2.2)
- EXIF metadata extracted (GPS, timestamp, camera)
- Attachable to tree, survey, report, or standalone

### C4.5 — GPS capture (§40)

- Geolocation API for current location
- Stored as Location artefact
- Attachable to any artefact
- Used by map module (Phase C5)

### C4.6 — Measurement capture (§40)

- Already partially present (typed inputs for tree height, girth)
- Extend: voice-dictated, photo-with-ruler, future laser-distance

### C4.7 — Pact + App-VP

- `pact/codex/oscar.multimodal.codex.md` (C8 shape matrix: per-modality × per-mode × per-chip × per-state)
- `pact/recipes/multimodal/` (10 items)
- `pact/fragments/oscar.multimodal.*.001.md` (10+)
- `pact/vp/multimodal-checks.test.ts`

### C4.8 Phase C4 Outcome

After C4:
- 5 of 5 multimodal capture modalities shipped
- Voice-to-AI live transcription works
- Voice notes have waveforms + confirmation flow
- App-VP test count: ~90

---

## XVII. PHASE C5 — MAP MODULE (SCRAP §43)

**Goal:** Add the spatial artefact. The single largest missing feature for arboriculture.

**Duration:** ~10-12 days. Pact + runtime. Very substantial.

### C5.1 — Map data model

- `app/src/data/models/Map.ts`, `MapLayer.ts`, `MapFeature.ts`
- IDB stores: `maps`, `map_layers`, `map_features` (DB_VERSION 4 → 5)

### C5.2 — Map module

- `app/src/map/` — MapView (Leaflet or Mapbox GL), drawing tools, layer manager
- `app/src/views/Map.tsx` — map dashboard
- Dock chip: "Map"
- Coordinate system default: OS Grid (UK arboriculture)
- Other systems: WGS84 (lat/lng), UTM

### C5.3 — Drawing layers

- Trees layer: point features (linked to Tree artefacts)
- RPAs layer: polygon features (drawn per-tree)
- Constraints layer: polygon features (no-go zones, easements)
- Annotations layer: point/line features (text annotations)
- Multiple layers per project

### C5.4 — Tree ↔ Map integration

- Every Tree artefact linked to a map feature
- Map view shows trees at their coordinates
- Clicking a tree on map opens Tree detail
- Tree detail shows mini-map

### C5.5 — Pact + App-VP

- `pact/codex/oscar.map.codex.md`
- `pact/recipes/map/` (10 items)
- `pact/fragments/oscar.map.*.001.md` (10+)
- `pact/vp/map-checks.test.ts`

### C5.6 Phase C5 Outcome

After C5:
- Map module shipped
- Trees can be located on maps
- RPAs can be drawn
- Annotations can be pinned
- The map is a first-class artefact type
- App-VP test count: ~95

---

## XVIII. PHASE C6 — STYLE LEARNING (SCRAP §42)

**Goal:** Automatic style extraction from PDFs. Style-aware report drafting.

**Duration:** ~4-5 days. Pact + runtime.

### C6.1 — Style profile data model

- `app/src/data/models/StyleProfile.ts` (project_id, tone, vocabulary, sentence_length, structure, exemplars)
- IDB store: `style_profiles` (DB_VERSION 5 → 6)

### C6.2 — PDF ingestion

- `app/src/style/` — PDF upload, PDF text extraction (pdf.js), style analysis
- Analysis produces a StyleProfile candidate (operator can review/adjust)
- Multiple StyleProfiles per project

### C6.3 — Style-aware drafting

- Modify `app/src/writing/draft.ts` to include `styleProfileId` parameter
- When set, prompt includes profile's tone/vocabulary/structure
- Modify Reports view: when generating from survey, use project's active StyleProfile

### C6.4 — Pact + App-VP

- `pact/codex/oscar.style.codex.md`
- `pact/recipes/style/` (10 items)
- `pact/fragments/oscar.style.*.001.md` (5+)
- `pact/vp/style-checks.test.ts`

### C6.5 Phase C6 Outcome

After C6:
- Style profiles are typed artefacts
- PDFs can be ingested to create profiles
- Drafting uses the active style profile
- Reports are style-aware
- App-VP test count: ~100

---

## XIX. PHASE C7 — COMMS MODULE (SCRAP §44, GATED)

**Goal:** Add the comms artefact. **Gated on operator decision (Option A vs Option B from B1.3).**

**Duration:** ~8-10 days. Pact + runtime. **Doctrinal gate required.**

### C7.0 — Doctrinal gate

If operator chose Option A (strict sovereignty): C7 is skipped. Proceed to C8.
If operator chose Option B (comms exception): C7 proceeds as below.

### C7.1 — Comms data model (Option B only)

- `app/src/data/models/Email.ts`, `SocialPost.ts`, `Message.ts`
- IDB stores: `emails`, `social_posts`, `messages` (DB_VERSION 6 → 7)

### C7.2 — Comms module (Option B only)

- `app/src/comms/` — email send/receive, social posting, message threading
- `app/src/views/Comms.tsx` — comms inbox (per-project)
- Dock chip: "Comms"

### C7.3 — Backend service for comms (Option B only)

- Dedicated Cloudflare Worker for comms (CF Workers allowed under comms exception)
- SMTP integration for email
- OAuth integration for social (Twitter, LinkedIn, etc.)
- Credentials stored encrypted (operator-managed)

### C7.4 — Sovereignty.md amendment (Option B only)

- `pact/platform/sovereignty.md` amended to add: "Comms (§44) is the constitutional exception. Email and social posting use dedicated backend services. These services are minimal, dedicated to comms, and operator-controlled."

### C7.5 — Pact + App-VP

- `pact/codex/oscar.comms.codex.md`
- `pact/recipes/comms/` (10 items)
- `pact/fragments/oscar.comms.*.001.md` (5+)
- `pact/vp/comms-checks.test.ts`

### C7.6 Phase C7 Outcome

After C7 (Option B):
- Comms module shipped
- Email + social + messaging available
- Oscar has a backend exception for comms only
- Sovereignty invariant amended
- App-VP test count: ~105

If Option A: C7 is skipped; no comms, sovereignty unchanged.

---

## XX. PHASE C8 — OPERATOR WORKFLOWS (SCRAP §45)

**Goal:** Add pre-built workflows for common scenarios.

**Duration:** ~4-5 days. Pact + runtime.

### C8.1 — Workflow data model

- `app/src/data/models/Workflow.ts` (name, steps, pre/post conditions, progress_indicator, project_id)
- IDB store: `workflows` (DB_VERSION 7 → 8; or DB_VERSION 6 → 7 if C7 was skipped)

### C8.2 — Workflow module

- `app/src/workflows/` — workflow runner, step state machine, progress UI
- Workflows are declarative (data, not code)
- Runner is generic; workflows are instances

### C8.3 — Pre-built surveyor workflow

- create project → enter trees on map → classify each tree → generate report from survey → style with profile → export PDF → archive
- 7 steps, each auditable

### C8.4 — Pre-built writer workflow

- create post → draft with AI → edit → save → publish → share
- 6 steps, each auditable

### C8.5 — Pact + App-VP

- `pact/codex/oscar.workflows.codex.md`
- `pact/recipes/workflows/` (10 items)
- `pact/fragments/oscar.workflow.*.001.md` (5+)
- `pact/vp/workflow-checks.test.ts`

### C8.6 Phase C8 Outcome

After C8:
- Workflows are typed artefacts
- Surveyor + writer workflows pre-built
- Generic workflow runner executes declarative workflows
- App-VP test count: ~110

---

## XXI. PHASE C9 — MULTI-DOMAIN (SCRAP §37.2 EXTENSION)

**Goal:** Extend the project type taxonomy beyond `tree`.

**Duration:** ~6-7 days. Pact + runtime. **The most architecturally significant runtime phase.**

### C9.1 — Multi-domain pact declaration

- Amend `pact/latent/section-37-project-spine.md`:
  - Project type taxonomy: `tree | media | social | charity | home | admin | (extensible)`
  - Per-type feature packs: each project type has its own assistant heuristics, brain rules, UI affordances

### C9.2 — Type-aware brain rules

- Modify `app/src/brain/rules/`:
  - Rules are typed by project type
  - Only `tree` project types use the existing rules
  - Other project types have stub rule sets (to be filled in later phases)

### C9.3 — Type-aware assistant heuristics

- Modify `app/src/assistant/heuristics.ts`:
  - Heuristics are scoped by project type
  - `tree` heuristics remain; new project types get stub heuristic sets

### C9.4 — Type-aware UI

- Add project type selection when creating a project
- Each type has its own default view set
- Tree types see Surveys/Notes/Reports/Blog; Media types see Media/Voice/Calendar; etc.

### C9.5 — Pact + App-VP

- `pact/codex/oscar.project-types.codex.md`
- `pact/recipes/project-types/` (10 items)
- `pact/fragments/oscar.project-type.*.001.md` (5+)
- `pact/vp/project-type-checks.test.ts`

### C9.6 Phase C9 Outcome

After C9:
- 6 project types supported (tree + 5 stubs)
- Per-type feature packs exist (tree full; others skeleton)
- Oscar is multi-domain-capable (substance), though only tree fully implemented initially
- App-VP test count: ~115

---

## XXII. PHASE C10 — FRESHCARDS SUBSTRATE (RATIFIED §23 APPLICATION)

**Goal:** Apply FreshCards as a first-class substrate (per ratified §23). Convert views to FreshCards.

**Duration:** ~5-6 days. Pact + runtime. **Note: §23 is already ratified; this is application, not ratification.**

### C10.1 — FreshCards substrate declaration (Pact)

- `pact/freshcards/` — declare FreshCards as a substrate per §23
- Per-card type declaration (Tree, Note, Report, Post, Voice, Media, etc.)
- Card 4-views: front, back, summary, action

### C10.2 — Convert views to FreshCards (Runtime)

- Modify every view to use `<FreshCard>` component
- Each FreshCard has 4 views: front, back, summary, action
- Cards are draggable, sortable, dockable
- Each card is **both a standalone workspace AND a substrate** (per §23 two-view)

### C10.3 — ADHD-friendly affordances (Runtime)

- UndoToast (in UX, was unwired) → wired in every save flow
- One-thing-at-a-time mode: dim non-focused elements
- Quick wins: every action yields visible feedback within 200ms
- Generous whitespace: spacing tokens standardized

### C10.4 — Pact + App-VP

- `pact/codex/oscar.freshcards.codex.md`
- `pact/recipes/freshcards/` (10 items)
- `pact/fragments/oscar.freshcards.*.001.md` (10+)
- `pact/vp/freshcards-checks.test.ts` (verifies every view uses FreshCard)

### C10.5 Phase C10 Outcome

After C10:
- FreshCards substrate applied per ratified §23
- Every view is a FreshCard (workspace + substrate)
- ADHD-friendly affordances wired
- App-VP test count: ~120

---

## XXIII. PHASE TIMELINE — DOCTRINAL EXECUTION ORDER

| Phase | Scope | Pact / Runtime | Duration | Shippable Artefact |
|---|---|---|---|---|
| **A0** | §08 Rule 1 baseline extraction | Pact-only | 1-2 days | Baseline snapshot, runtime inventory, sovereignty baseline |
| **A1** | FVW v8 §02 layout + 4 missing documents + 50+ fragments + 12 module.json + 8 decisions | Pact-only | 4-5 days | Restructured Pact, 4 of 8 mandatory artefacts |
| **A2** | §11 Recipe Books (10 items × 12) + §22 C1-C8 + §11.9 9-things + §16.5 6 JSON + §03 DNA + §04 Atlas + §22 C9 + §30 C8 | Pact-only + ~5 new App-VP tests | 7-10 days | 8 of 8 mandatory artefacts, ~70 App-VP tests |
| **B1** | §15.3-bis + §33.5 + §44 amendments (upstream RFCs) + DO-001/002/007 | Pact-only | 2-3 days | 3 upstream proposals + 3 local decisions |
| **B2** | §00 reconstructability demonstration | Pact + minimal runtime | 2-3 days | `verify-reconstructability.sh` (PASS/FAIL) |
| **C1** | §37 Project Spine (locally ratified) | Pact + runtime | 5-6 days | Projects view, project-scoped artefacts, ~75 App-VP tests |
| **C2** | §38 Universal Artefact Graph (voice + media + calendar) | Pact + runtime | 8-10 days | 3 new artefact types, 3 new views, ~80 App-VP tests |
| **C3** | §39 Artefact Topology (tags, links, versions, playback) | Pact + runtime | 6-7 days | Topology module, versioning on every artefact, ~85 App-VP tests |
| **C4** | §40 Multimodal Capture + §41 Voice Pipeline | Pact + runtime | 5-6 days | Voice/photo/GPS/measurement in AssistantDock, ~90 App-VP tests |
| **C5** | §43 Map Module | Pact + runtime | 10-12 days | Map view, drawing layers, tree ↔ map integration, ~95 App-VP tests |
| **C6** | §42 Style Learning | Pact + runtime | 4-5 days | PDF ingestion, style profiles, style-aware drafting, ~100 App-VP tests |
| **C7** | §44 Comms Module (gated on sovereignty decision) | Pact + runtime | 8-10 days (or skip) | Comms view, email/social/messaging, comms backend, ~105 App-VP tests |
| **C8** | §45 Operator Workflows | Pact + runtime | 4-5 days | Workflow runner, surveyor + writer workflows, ~110 App-VP tests |
| **C9** | §37.2 Multi-domain | Pact + runtime | 6-7 days | 5 new project type stubs, ~115 App-VP tests |
| **C10** | §23 FreshCards substrate (ratified) + ADHD affordances | Pact + runtime | 5-6 days | FreshCard substrate, every view is a card, ~120 App-VP tests |

**Total estimated duration: ~75-95 days of focused work** (~15-19 weeks at 1 person-week = 5 days).

**Pact-only work (A0, A1, A2, B1): ~17-20 days.**
**Runtime work (B2, C1-C10): ~50-65 days.**

---

## XXIV. PHASE DEPENDENCIES

```
A0 (baseline extraction)
   ↓
A1 (restructure + fragments + module.json) ─┬─ A2 (Recipe Books + codex + DNA + Atlas)
                                           │
B1 (3 amendment RFCs) ──────────────────────┤  (parallel to A1/A2; no dependency)
                                           │
B2 (reconstructability) ───────────────────┴─ requires A1 + A2
                                              │
                                              ├─ C1 (Project Spine) ─┬─ C2 (Universal Artefacts)
                                              │                       ├─ C3 (Topology)
                                              │                       ├─ C4 (Multimodal)
                                              │                       ├─ C5 (Map)
                                              │                       ├─ C6 (Style)
                                              │                       ├─ C7 (Comms — gated)
                                              │                       ├─ C8 (Workflows)
                                              │                       ├─ C9 (Multi-domain)
                                              │                       └─ C10 (FreshCards)
                                              │
                                              └─ all C phases can run in parallel after C1
```

C1 must complete before C2-C10. C7 is gated on operator decision (Option A vs B from B1.3).

---

## XXV. DOCTRINAL GUARANTEES (REVISION 2)

The plan guarantees:

1. **FWW v8 v0.10.0 ratified alignment** is achieved after A2 (Phase A1+A2)
2. **§11.9 9-things in rules.md** is enforced by `vp/rules-md-checks.test.ts`
3. **§16.5 6 recipe-book/smart/ JSON files** are created in A2.3
4. **§22 C9 State Shape Inventory** is enforced by `vp/c9-state-shape-checks.test.ts`
5. **§30 C8 Shape Matrix** is enforced by `vp/c8-shape-matrix-checks.test.ts`
6. **§08 anti-drift mapping** is established in A1.2's `anti-drift.md`
7. **§00 Reconstructability Invariant** is satisfied after B2
8. **§15.3-bis + §33.5 amendments** are proposed upstream in B1
9. **Latent §37-§45 doctrines** are locally ratified in OSCR- through C1-C10
10. **§23 FreshCards substrate** is applied in C10 (not ratified — already ratified)
11. **Sovereignty is respected** throughout, except for C7 (gated)
12. **The runtime remains shippable** at every phase
13. **The v9-fvw empirical proposals** (§30.5, §22 C9, §11.12) are integrated

---

## XXVI. WHAT THIS PLAN CORRECTS FROM REVISION 1

| Revision 1 issue | Revision 2 correction |
|---|---|
| 9 universal things in rules.md not specified | **A2.5** specifies all 9 things explicitly |
| 14 Smart X features treated as "ship 3 of 14" | **A2.3** treats 14 as constitutional toggles + creates 6 JSON files per §16.5 |
| v9-fvw empirical doctrine not integrated | **A2.6** adds C9 State Shape Inventory; **A0** mentions Tool A vs Tool B (§11.12); **A1.2** mentions §30.5 format-as-constitutional |
| C8 shape matrix not enforced | **A2.6 + A2.10** require + verify C8 per-surface × per-mode × per-chip × per-state |
| 58 invariants not mapped to §08's 25 rules | **A1.2** anti-drift.md maps each invariant to a §08 rule |
| Tier conflation (ratified/proposed/scrap) | **Section II** explicitly names 3 tiers; plan uses them throughout |
| FreshCards/ADHD framed as doctrine gap | **Section C10** correctly frames it as application of ratified §23 |
| C9 multi-domain placed after C8 workflows | **Reordered**: C9 (multi-domain) is the foundation for C8 (workflows) since workflows are per-domain. C9 before C8. |
| Recipe Book rules.md format vague | **A2.5** specifies format for each of the 9 things |
| Anti-drift mapping absent | **A1.2** establishes the mapping |

---

## XXVII. RISKS AND MITIGATIONS (REVISION 2)

| Risk | Mitigation |
|---|---|
| B1 amendments rejected upstream | Local ratification (DO-001, DO-002, DO-007) is sufficient; upstream is bonus |
| C1 Project Spine requires migration of every artefact | Auto-migration: existing artefacts get `project_id = "default"` |
| C5 Map requires substantial UI work | Ship skeleton first (display only), full drawing in C5.3 |
| C7 Comms requires backend (gated) | Operator decision; if Option A, C7 is skipped, sovereignty unchanged |
| C9 multi-domain is a major pivot | Skeleton stubs for non-tree types; only `tree` fully implemented initially |
| Multi-phase plan overruns | Each phase independently shippable; can pause at any phase boundary |
| v9-fvw proposals rejected upstream | Oscar's local ratification (§22 C9, §11.12, §30.5) is sufficient |
| 120 App-VP tests + 5 new test files | Tests are scoped per phase; each test file is small (~50 LOC) |
| The 9-things doctrine in rules.md is hard to enforce | `vp/rules-md-checks.test.ts` checks each rule.md against the 9-thing template |

---

## XXVIII. CLOSING POSITION (REVISION 2)

Oscar is a sovereign SPA with a working runtime. The runtime is more sophisticated than the Pact. Revision 2 closes that gap by:

1. **Writing 8 of 8 mandatory artefacts** (Pact-only, ~17-20 days)
2. **Demonstrating §00 Reconstructability** (~2-3 days)
3. **Proposing 3 constitutional amendments** upstream (~2-3 days)
4. **Adding 9 latent doctrinal extensions** (locally ratified; runtime + Pact; ~50-65 days)

**Total: ~75-95 days of focused work** (~15-19 weeks).

The deepest findings — re-confirmed and sharpened:

1. **`pact/fragments/` and `pact/recipes/` are declared-but-undelivered.** Claimed structure the runtime doesn't fulfill. Closed in A1.
2. **Qwen 0.5B violates §15.3 by 250×.** Constitutionally invalid. Resolved via B1 §15.3-bis amendment.
3. **Oscar is a third reconstruction mode not declared in §33.** Resolved via B1 §33.5 amendment.
4. **The 9 universal things in rules.md are not specified anywhere in Oscar.** Closed in A2.5 with explicit format per module.
5. **The 14 Smart X features are not declared as constitutional toggles.** Closed in A2.3 with 6 JSON files.
6. **The C9 State Shape Inventory (v9-fvw proposal) is absent.** Closed in A2.6.
7. **The C8 Shape Matrix is not enforced.** Closed in A2.6 + A2.10.
8. **The 58 invariants are not mapped to §08's 25 rules.** Closed in A1.2 anti-drift.md.
9. **Comms (scrap §44) requires backend; sovereignty is browser-only.** Gated in B1.3 + C7.
10. **Multi-domain is a major pivot but is the foundation for workflows (C8), FreshCards (C10), and any future growth.** Reordered in Revision 2: C9 before C8 and C10.

The plan is **world-class** because it:

- Is grounded in canonical FVW v8 v0.10.0 doctrine (not stale memory)
- Separates ratified / proposed (v9-fvw) / scrap (operator) tiers
- Treats the operator's scrap as proposed-but-unratified, requiring local ratification before implementation
- Distinguishes Pact-only, runtime-only, and both-require work
- Phases for realistic execution (each phase shippable)
- Respects sovereignty throughout (one explicit Comms exception, gated)
- Maps to the canonical 8 mandatory artefacts + the latent §37-§45 doctrines
- Adds the v9-fvw empirical proposals as a third tier
- Specifies the 9-things in rules.md (§11.9) explicitly
- Specifies the 6 `recipe-book/smart/` JSON files (§16.5) explicitly
- Adds the C9 State Shape Inventory (v9-fvw proposal)
- Adds the C8 Shape Matrix with per-surface × per-mode × per-chip × per-state
- Maps the 58 invariants to §08's 25 rules
- Reorders phases for proper dependencies (C9 before C8/C10)
- Is good enough for a senior architect to adopt as-is

The runtime is sound. The Pact is thin. The capabilities are incomplete. The doctrine extension is coherent. The plan closes all gaps in phased, shippable, doctrinally-aligned order.

---

*End of sovereign doctrinal audit + world-class plan (Revision 2).*
*Based on FVW v8 v0.10.0 (commit 29a8262, 2026-06-25) + v9-fvw proposals (2026-06-22) + operator scrap (2026-06-26 to 2026-06-28).*
*No code, no low-level implementation details. The artifacts audited were not modified.*