# Latent Doctrine Execution Plan — §37–§45 (C1–C10)
**World-class doctrinal plan for operator's proposed-but-unratified doctrine. Execution-ready.**

**Date:** 2026-06-29
**Status:** Locally binding via OSCR- (proposed upstream to FVW v8)
**Schema:** `freshvibe-way-v8.execution-plan v1.0.0`

---

## I. Doctrine Tier Classification (per audit-plan-v2 §II)

| Tier | Source | Status | Treatment |
|---|---|---|---|
| **Ratified** | FVW v8 v0.10.0 `doctrine/` (commit `29a8262`) | Binding | Honor exactly. Foundation for everything. |
| **Proposed (upstream-pending)** | Operator's `avidtech6/v9-fvw` repo (2026-06-22) | Documented but not yet in FVW v8 | Apply where not rejected: §22 C9 (State Shape Inventory), §11.12 (Tool A vs Tool B), §30.5 (format-as-constitutional) |
| **Scrap (unratified)** | Operator chat refinements (2026-06-26 to 2026-06-28) | Not yet in any doc | Latent doctrine candidates. Local ratification in OSCR- before implementation. |

**The 10 latent doctrines (§37–§45 + §37.2 extension) are SCRAP-tier.** They are proposed-but-unratified. This plan:
1. Ratifies them LOCALLY in OSCR- (so they're binding for Oscar)
2. Proposes them UPSTREAM to FVW v8 (so they may become binding doctrine)
3. Implements them in the Oscar runtime (Phase C1–C10)

Each latent section is presented in three forms:
- **Scrap form** (what the operator said in chat)
- **Local ratification** (binding for Oscar)
- **Upstream proposal** (text to send to FVW v8 maintainers)

---

## II. The 10 Latent Doctrines — World-Class Plan

### Latent §37 — Project Spine (C1)

**Scrap form:** Every workspace is project-oriented. Every project has the same universal artefact graph. Projects are sovereign within Oscar.

**Local ratification text (`pact/latent/section-37-project-spine.md`):**

```markdown
## 37 — Project Spine (locally ratified in OSCR-)

### 37.1 — Every Oscar workspace contains zero or more projects.
A project is a typed instance of a domain.

### 37.2 — Project types are constitutional.
Initial taxonomy: `tree` (arboriculture). Extensible.

### 37.3 — Every project has the same universal artefact graph (per §38).
The graph is domain-agnostic. Domain-specific artefacts are layered on top.

### 37.4 — Projects are sovereign within Oscar.
Artefacts are private to a project. Cross-project movement requires explicit operator action.

### 37.5 — Project lifecycle is constitutional.
States: `draft → active → paused → archived → deleted`. Each transition auditable.
```

**Upstream proposal:** Add to FVW v8 doctrine as §37 Project Spine (cross-workspace).

**Runtime implementation (C1):**
- `app/src/data/models/Project.ts` (typed model)
- New IDB store: `projects` (DB_VERSION 2 → 3 migration)
- `app/src/projects/` (CRUD, switcher, lifecycle)
- `app/src/views/Projects.tsx` (dashboard)
- Dock chip: "Projects"
- All 6 existing artefact types get `project_id: string` field (FK)
- Migration v2→v3: every existing artefact gets `project_id = "default"`

---

### Latent §38 — Universal Artefact Graph (C2)

**Scrap form:** Voice, media, tasks, calendar, social, notes, trees, reports — every project has access to all 8 (or 9, including blog posts).

**Local ratification text:**

```markdown
## 38 — Universal Artefact Graph (locally ratified)

### 38.1 — Every project has the same artefact graph.
The graph is domain-agnostic. Domain-specific artefacts extend the graph.

### 38.2 — Every artefact is a typed node.
Initial types in Oscar: notes, trees, sites, surveys, reports, posts (6), voice, media, calendar (3 to add in C2) = 9 total.

### 38.3 — Required metadata: id, project_id, type, created_at, updated_at, version, tags.
Optional: parent_id (hierarchical), linked_ids (relationships), location (spatial).

### 38.4 — Type taxonomy declared in OSCR- (not code).
Adding a new artefact type requires OSCR- amendment.
```

**Runtime implementation (C2):**
- 3 new models: `Voice.ts`, `Media.ts`, `Calendar.ts`
- 3 new IDB stores: `voices`, `media`, `events` (DB_VERSION 3 → 4)
- 3 new repos: `voicesRepo`, `mediaRepo`, `eventsRepo`
- 3 new modules: `app/src/voice/`, `app/src/media/`, `app/src/calendar/`
- 3 new views: `Voice.tsx`, `Media.tsx`, `Calendar.tsx`
- 3 new dock chips: "Voice", "Media", "Calendar"

---

### Latent §39 — Artefact Topology (C3)

**Scrap form:** Artefacts attach/separate, move between projects, tag, link, version, playback.

**Local ratification text:**

```markdown
## 39 — Artefact Topology (locally ratified)

### 39.1 — Attachments are typed.
Types: `evidence | reference | annotation | derived | parent_of | blocks`.

### 39.2 — Movement between projects is auditable.
Every move is logged. Reversible.

### 39.3 — Tags are hierarchical.
Tags have parent tags. Tag scopes: `artefact | project | global`.

### 39.4 — Links are typed and bidirectional.
Types: `references | derived-from | responds-to | blocks | supersedes`.

### 39.5 — Versions are immutable.
Every save creates a new version record. Current version is a pointer.

### 39.6 — Playback is constitutional.
History can be replayed as a sequence of states.
```

**Runtime implementation (C3):**
- 3 new models: `Tag.ts`, `Link.ts`, `Version.ts`
- 3 new IDB stores (DB_VERSION 4 → 5)
- `app/src/topology/` (CRUD, link management, version control, playback viewer)
- All 9 artefacts gain tag/link/version support
- History replay UI in each artefact detail view

---

### Latent §40 — Multimodal Capture (C4)

**Scrap form:** Voice, photo, measurement, GPS, text — every input box accepts all 5 modalities.

**Local ratification text:**

```markdown
## 40 — Multimodal Capture (locally ratified)

### 40.1 — Capture modalities are constitutional.
Taxonomy: `voice | photo | measurement | gps | text`.

### 40.2 — Each modality has a primary artefact type.
- voice → VoiceArtefact
- photo → MediaArtefact
- measurement → MeasurementArtefact
- gps → LocationArtefact
- text → TextArtefact

### 40.3 — Each modality has a capture flow.
Declared in the module's recipe-book. Capture flows are versioned (per §39).

### 40.4 — Multimodal capture is first-class UI.
Every input box accepts all 5 modalities. Switchable via icon buttons.
```

**Runtime implementation (C4):**
- AssistantDock gains 4 new input buttons (voice, photo, GPS, measurement)
- `app/src/capture/` module (capture flow registry)
- Web Audio API for voice capture
- MediaRecorder for audio
- Geolocation API for GPS
- File input + camera for photos
- All captures route through askOscar + IDB

---

### Latent §41 — Voice Artefact Pipeline (C5)

**Scrap form:** Audio → raw_transcript → edited_transcript → version_history → final_artefact. Plus voice-to-AI live transcription + waveform + confirmation flow.

**Local ratification text:**

```markdown
## 41 — Voice Artefact Pipeline (locally ratified)

### 41.1 — Voice artefacts have 5 stages.
`audio → raw_transcript → edited_transcript → version_history → final_artefact`. Each stage stored separately. Transitions auditable.

### 41.2 — Voice-to-AI live transcription is constitutional.
AI can listen in real-time. Transcript streams into input box. Operator can edit while forming.

### 41.3 — Voice notes have waveforms.
Canvas-rendered AudioBuffer visualisation. Zoomable, scrubbable.

### 41.4 — Confirmation flow is constitutional.
After every voice capture, assistant asks: "Voice note recorded and tagged for X — is that correct?"
```

**Runtime implementation (C5):**
- `app/src/voice/` extended with 5-stage pipeline
- Web Speech API integration for live transcription
- Canvas waveform renderer
- Confirmation flow integrated with assistant
- Audio stored as Blob in IDB

---

### Latent §42 — Style Learning (C6)

**Scrap form:** PDFs → style profiles. Style-aware report drafting.

**Local ratification text:**

```markdown
## 42 — Style Learning (locally ratified)

### 42.1 — Style profiles are typed artefacts.
Contains: tone, vocabulary, sentence_length, structure, exemplars.

### 42.2 — Style extraction is constitutional.
PDFs are ingested (pdf.js). AI extracts a style profile. Operator can review/adjust.

### 42.3 — Style-aware generation is constitutional.
When drafting, AI uses the project's active style profile. Profile is referenced in artefact metadata.
```

**Runtime implementation (C6):**
- `app/src/data/models/StyleProfile.ts`
- IDB store: `style_profiles` (DB_VERSION 5 → 6)
- `app/src/style/` (PDF upload, extraction, profile management)
- Modified `app/src/writing/draft.ts` accepts `styleProfileId`
- Modified `app/src/views/Reports.tsx` uses active profile

---

### Latent §43 — Spatial Artefact / Map (C7)

**Scrap form:** Map with drawing layers (trees, RPAs, constraints).

**Local ratification text:**

```markdown
## 43 — Spatial Artefact (locally ratified)

### 43.1 — Maps are typed artefacts.
A map contains: base_layer, drawing_layers, coordinate_system, viewport.

### 43.2 — Drawing layers are typed.
Types: `point | line | polygon | annotation`. Each layer has a geometry type, colour, label field.

### 43.3 — Coordinate systems are constitutional.
Default: OS Grid (UK arboriculture). Others: WGS84, UTM.

### 43.4 — Map features are versioned.
Every draw/edit/delete creates a new version. Playback supported.
```

**Runtime implementation (C7):**
- 3 new models: `Map.ts`, `MapLayer.ts`, `MapFeature.ts`
- 3 new IDB stores (DB_VERSION 6 → 7)
- `app/src/map/` (Leaflet-based map view, drawing tools)
- `app/src/views/Map.tsx` (map dashboard)
- Dock chip: "Map"
- Tree ↔ Map integration (every tree linked to a map point)

---

### Latent §44 — Comms Artefact (C8) — GATED

**Scrap form:** Email send/receive, social posting, per-project comms.

**Gated on sovereignty decision.** Two options (per audit-plan-v2 §B1.3):
- **Option A:** Strict sovereignty (no comms). Skip C8.
- **Option B:** Comms backend exception. Oscar has dedicated comms backend.

**Local ratification text (Option B only):**

```markdown
## 44 — Comms Artefact (locally ratified, Option B only)

### 44.1 — Comms are typed artefacts.
Types: `email | social_post | message`. Each contains: from, to, body, attachments, status, thread_id.

### 44.2 — Comms are bidirectional.
Inbox + outbox are first-class. Replies linked to parent.

### 44.3 — Per-project comms are constitutional.
Each project has its own comms (no global inbox).

### 44.4 — Backend is the constitutional exception.
Comms is the only Oscar capability that requires backend services (per DO-007).

### 44.5 — Sovereignty amendment.
Oscar's sovereignty.md is amended to allow dedicated comms backend (CF Worker for email + social APIs).
```

**Runtime implementation (C8, Option B only):**
- 3 new models: `Email.ts`, `SocialPost.ts`, `Message.ts`
- 3 new IDB stores (DB_VERSION 7 → 8)
- `app/src/comms/` (email send/receive, social posting)
- `app/src/views/Comms.tsx` (per-project inbox)
- Dock chip: "Comms"
- CF Worker for comms backend (per Option B)
- Updated `pact/platform/sovereignty.md` (the amendment)

---

### Latent §45 — Operator Workflows (C9)

**Scrap form:** Pre-built sequences for surveyors, writers, etc.

**Local ratification text:**

```markdown
## 45 — Operator Workflows (locally ratified)

### 45.1 — Workflows are typed artefacts.
A workflow contains: name, steps, pre/post conditions, progress_indicator, project_id.

### 45.2 — Each step is auditable.
Steps have states: `pending → active → complete → skipped`. State transitions recorded.

### 45.3 — Workflows are declarative.
Workflow definition is data, not code. The runner is a generic engine.

### 45.4 — Workflows can be shared.
Exportable and importable. Sharing is constitutional (operator decides).
```

**Runtime implementation (C9):**
- `app/src/data/models/Workflow.ts`
- IDB store: `workflows` (DB_VERSION 8 → 9)
- `app/src/workflows/` (generic runner, step state machine, progress UI)
- Pre-built surveyor workflow (7 steps)
- Pre-built writer workflow (6 steps)
- Workflow templates per project type (when C9 multi-domain lands)

---

### Latent §37.2 — Multi-Domain Extension

**Scrap form:** Multiple project types (tree, media, social, charity, home, admin).

**Local ratification text:**

```markdown
## 37.2 — Multi-Domain Ecosystem (locally ratified)

### 37.2.1 — Project type taxonomy.
Initial types: `tree | media | social | charity | home | admin | (extensible)`.

### 37.2.2 — Per-type feature packs.
Each project type has its own assistant heuristics, brain rules, and UI affordances.

### 37.2.3 — Per-type schemas.
Each type has its own artefact extensions (e.g., charity has donors; home has rooms).
```

**Runtime implementation (multi-domain landing in C9 final):**
- Project type selection when creating a project
- Type-aware brain rules (only `tree` uses existing rules; others are stubs)
- Type-aware assistant heuristics
- Type-aware UI (default view sets per type)
- 5 stub project types with skeleton feature packs

---

### Latent §23 — FreshCards Substrate (C10)

**Scrap form:** FreshCards + ADHD-friendly UX.

**Note:** §23 is **already ratified** in FVW v8. This phase is **application**, not ratification.

**Runtime implementation (C10):**
- `pact/freshcards/` (declare substrate + card types)
- `<FreshCard>` component (4-view: front, back, summary, action)
- Every view uses FreshCard
- ADHD affordances: undo wired, one-thing-at-a-time mode, quick-win feedback

---

## III. Cross-Cutting Doctrine Elements

### §11.9 9-Things Structure (per module)

Every module's `rules.md` contains 9 universal things:
1. Capability declaration (incl. Reconstruction Mode Declaration per §33.5)
2. Do-not-proceed rule
3. Contract primacy
4. Anti-drift enforcement (4 numbered checks)
5. Plan-as-law
6. Fallback behaviour
7. User-simulator requirement
8. Re-anchor cadence
9. Coverage matrix

### §16 Smart-X Constitutional Toggles

`pact/recipes/smart/features.json` declares 14 Smart-X features as toggles. The user can toggle per project (when C1 lands).

### §16.5 recipe-book/smart/ Directory

6 JSON files: features.json, engines.json, modules.json, micro-model.json, hooks.json, seeds.json.

### v9-fvw Implications (proposed-but-ratified-locally)

- **§22 C9 (State Shape Inventory):** Applied to every codex.
- **§11.12 (Tool A vs Tool B):** Oscar uses Source Extraction (Tool B).
- **§30.5 (format-as-constitutional):** `oscar.*` format is constitutional; changes throw away prior work.

### C8 Shape Matrix (per module)

Every module's `codex.md` C8 declares the 4-dimensional matrix: per-surface × per-mode × per-chip × per-state.

### §08 Anti-Drift Mapping (62 invariants)

The 8 mandatory artefacts generate 62 invariants:
- 8 sovereignty
- 12 runtime
- 11 intelligence
- 8 data
- 9 UX
- 11 build
- 8 adversarial
- 4 constitutional (NEW: rules-md, c1-c9, module-pact, smart-features)

Each invariant maps to one of §08's 25 rules + 20 gates + 12 failure modes (per `pact/platform/anti-drift.md`).

---

## IV. 14-Phase Execution Plan

The plan has 14 phases aligned with the FVW v8 v0.10.0 ratified doctrine + 10 latent doctrine phases.

### Phases A0–B2 (already complete in Session 2)
- A0: Doctrinal reconnaissance — baseline snapshots
- A1: FVW v8 structural alignment — 8 mandatory artefacts
- A2: Recipe Books + Codex (13 modules × 10 items)
- B1: Constitutional amendments proposed (DO-001, DO-002, DO-007)
- B2: §00 Reconstructability SATISFIED

### Phases C1–C10 (this plan)

| Phase | Latent § | Module | New IDB Stores | DB bump | New View | New Dock Chip | Gated? |
|---|---|---|---|---|---|---|---|
| C1 | §37 | projects | 1 (projects) | 2→3 | Projects | Projects | No |
| C2 | §38 | voice, media, calendar | 3 (voices, media, events) | 3→4 | Voice, Media, Calendar | Voice, Media, Calendar | No |
| C3 | §39 | topology | 3 (tags, links, versions) | 4→5 | — | — | No |
| C4 | §40 | capture | 1 (measurements/locations shared with media) | 5→6 | — | (input buttons) | No |
| C5 | §41 | voice (extends C2) | (same as C2) | — | — | — | No |
| C6 | §42 | style | 1 (style_profiles) | 6→7 | — | — | No |
| C7 | §43 | map | 3 (maps, map_layers, map_features) | 7→8 | Map | Map | No |
| C8 | §44 | comms | 3 (emails, social_posts, messages) | 8→9 | Comms | Comms | **YES** |
| C9 | §45 + §37.2 | workflows + multi-domain | 1 (workflows) | 9→10 | Workflows | Workflows | No |
| C10 | §23 (ratified) | freshcards | 0 | — | — | — | No |

**DB migration path:** 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10 across 8 migrations.

**Total: 13 new IDB stores + 9 new views + 9 new dock chips + 10 new modules + 9 new models (per C2–C9).**

### Phases D1–D2 (post-C10, future sessions)
- D1: §15.3-bis amendment ratification (propose to FVW v8)
- D2: Multi-domain expansion (charity, home, admin feature packs)

---

## V. Per-Phase Implementation Detail

### Phase C1 — Project Spine (DOCTRINE + RUNTIME)

**Pact-only deliverables:**
- `pact/latent/section-37-project-spine.md` (local ratification)
- `pact/codex/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/fragments/oscar.project.*.001.md` (10+ new fragments)
- `pact/trace-atlas/atlas.json` updated
- `pact/dna/app.dna.json` updated
- `pact/vp/project-checks.test.ts` (new App-VP test)
- `pact/decisions/DO-009-project-spine.md` (latent ratification)

**Runtime deliverables:**
- `app/src/data/models/Project.ts` (typed model: project_id, project_type, name, state, created_at, updated_at, metadata)
- IDB schema bump 2 → 3: add `projects` store
- `app/src/data/persistence/idb.ts` updated
- `app/src/projects/` module: CRUD, switcher, lifecycle state machine
- `app/src/views/Projects.tsx` (dashboard with grid of project cards)
- Dock chip: "Projects" (replaces or augments Home)
- Header: project name + type badge + state badge
- All 6 existing models updated: add `project_id: string` (FK)
- Migration v2→v3: every existing artefact gets `project_id = "default"`
- Smart adapter updated: Layer 2 data queries scope to current project
- `app/src/views/Surveys.tsx` (and Notes, Reports, Blog) updated: list scoped to current project

### Phase C2 — Universal Artefact Graph (Voice + Media + Calendar)

**Pact-only deliverables:**
- `pact/latent/section-38-artefact-graph.md`
- 3 new codex files (voice, media, calendar)
- 3 new Recipe Books (× 10 items each)
- 15+ new fragments
- `pact/trace-atlas/atlas.json` updated
- `pact/vp/universal-graph-checks.test.ts` (new App-VP test)
- `pact/decisions/DO-010-universal-artefact-graph.md`

**Runtime deliverables:**
- 3 new models: `Voice.ts`, `Media.ts`, `Calendar.ts`
- IDB schema bump 3 → 4: add `voices`, `media`, `events` stores
- 3 new repos: `voicesRepo`, `mediaRepo`, `eventsRepo`
- 3 new modules: `app/src/voice/`, `app/src/media/`, `app/src/calendar/`
- 3 new views: `Voice.tsx`, `Media.tsx`, `Calendar.tsx`
- 3 new dock chips: "Voice", "Media", "Calendar"
- Each view: list + capture + detail (per C8 shape matrix)
- `app/src/views/Home.tsx` updated: anchor grid includes new types

### Phase C3 — Artefact Topology (Tags, Links, Versions, Playback)

**Pact-only deliverables:**
- `pact/latent/section-39-artefact-topology.md`
- `pact/codex/topology.codex.md`
- `pact/recipes/topology/` (10 items)
- 10+ new fragments
- `pact/vp/topology-checks.test.ts`
- `pact/decisions/DO-011-artefact-topology.md`

**Runtime deliverables:**
- 3 new models: `Tag.ts`, `Link.ts`, `Version.ts`
- IDB schema bump 4 → 5: add `tags`, `links`, `versions` stores
- `app/src/topology/` module: tag CRUD, link CRUD, version CRUD, playback viewer
- All 9 existing artefact types gain: tags (typed), links (typed bidirectional), versions (immutable history)
- UI: per-artefact tag chip, link list, version timeline, "playback" button
- Replace "every save overwrites" with "every save creates new version"

### Phase C4 — Multimodal Capture

**Pact-only deliverables:**
- `pact/latent/section-40-multimodal-capture.md`
- `pact/codex/capture.codex.md`
- `pact/recipes/capture/` (10 items)
- 10+ new fragments
- `pact/vp/multimodal-checks.test.ts`
- `pact/decisions/DO-012-multimodal-capture.md`

**Runtime deliverables:**
- `app/src/capture/` module: capture flow registry, modality router
- AssistantDock extended: 4 new input buttons (voice mic, photo camera, GPS pin, measurement dial)
- Web Audio API integration (audio capture)
- Geolocation API integration (GPS)
- File input + camera (photos)
- Existing typed inputs extended (measurements)
- All captures route through askOscar + IDB

### Phase C5 — Voice Artefact Pipeline (extends C2)

**Pact-only deliverables:**
- `pact/latent/section-41-voice-pipeline.md`
- `pact/codex/voice.codex.md` updated (5-stage pipeline)
- `pact/recipes/voice/` updated
- 5+ new fragments
- `pact/vp/voice-pipeline-checks.test.ts`
- `pact/decisions/DO-013-voice-pipeline.md`

**Runtime deliverables:**
- `app/src/voice/` extended with 5-stage pipeline:
  - audio capture (MediaRecorder)
  - raw_transcript (Web Speech API)
  - edited_transcript (textarea + save)
  - version_history (per C3)
  - final_artefact (saved with project_id + tags + links)
- Voice-to-AI live transcription: Web Speech API's interim results stream into AssistantDock input
- Waveform renderer: Canvas + AudioBuffer
- Confirmation flow: after capture, assistant asks "Voice note recorded and tagged for X — is that correct?"

### Phase C6 — Style Learning

**Pact-only deliverables:**
- `pact/latent/section-42-style-learning.md`
- `pact/codex/style.codex.md`
- `pact/recipes/style/` (10 items)
- 5+ new fragments
- `pact/vp/style-checks.test.ts`
- `pact/decisions/DO-014-style-learning.md`

**Runtime deliverables:**
- `app/src/data/models/StyleProfile.ts` (project_id, tone, vocabulary, sentence_length, structure, exemplars)
- IDB schema bump 6 → 7: add `style_profiles` store
- `app/src/style/` module: PDF upload (file input), PDF text extraction (pdf.js), style analysis
- Modified `app/src/writing/draft.ts`: accepts `styleProfileId` parameter; prompt includes profile
- Modified `app/src/views/Reports.tsx`: when generating from survey, use project's active profile
- UI: style profile editor + selector

### Phase C7 — Map Module (Spatial Artefact)

**Pact-only deliverables:**
- `pact/latent/section-43-spatial-artefact.md`
- `pact/codex/map.codex.md`
- `pact/recipes/map/` (10 items)
- 10+ new fragments
- `pact/vp/map-checks.test.ts`
- `pact/decisions/DO-015-spatial-artefact.md`

**Runtime deliverables:**
- 3 new models: `Map.ts`, `MapLayer.ts`, `MapFeature.ts`
- IDB schema bump 7 → 8: add `maps`, `map_layers`, `map_features` stores
- `app/src/map/` module: MapView (Leaflet), drawing tools, layer manager
- `app/src/views/Map.tsx` (map dashboard)
- Dock chip: "Map"
- Coordinate system default: OS Grid (UK arboriculture)
- Drawing layers: Trees (point), RPAs (polygon), Constraints (polygon), Annotations (point/line)
- Tree ↔ Map integration: every Tree linked to a map point

### Phase C8 — Comms Module (GATED on sovereignty)

**Pact-only deliverables:**
- `pact/latent/section-44-comms.md` (Option B only)
- `pact/codex/comms.codex.md` (Option B only)
- `pact/recipes/comms/` (10 items, Option B only)
- 5+ new fragments
- `pact/vp/comms-checks.test.ts` (Option B only)
- `pact/decisions/DO-016-comms-exception.md` (gated on operator)
- **AMENDED:** `pact/platform/sovereignty.md` adds comms backend exception (Option B only)

**Runtime deliverables (Option B only):**
- 3 new models: `Email.ts`, `SocialPost.ts`, `Message.ts`
- IDB schema bump 8 → 9: add `emails`, `social_posts`, `messages` stores
- `app/src/comms/` module: email send/receive, social posting, message threading
- `app/src/views/Comms.tsx` (per-project inbox)
- Dock chip: "Comms"
- Backend: dedicated Cloudflare Worker (per Option B)
- Credentials: encrypted storage (operator-managed)

### Phase C9 — Operator Workflows + Multi-Domain

**Pact-only deliverables:**
- `pact/latent/section-45-workflows.md`
- `pact/latent/section-37-2-multi-domain.md`
- `pact/codex/workflows.codex.md`
- `pact/codex/project-types.codex.md` (multi-domain)
- `pact/recipes/workflows/` (10 items)
- `pact/recipes/project-types/` (10 items)
- 10+ new fragments
- `pact/vp/workflow-checks.test.ts`
- `pact/vp/multi-domain-checks.test.ts`
- `pact/decisions/DO-017-workflows.md`
- `pact/decisions/DO-018-multi-domain.md`

**Runtime deliverables:**
- `app/src/data/models/Workflow.ts` (name, steps, pre/post conditions, progress_indicator, project_id)
- IDB schema bump 9 → 10: add `workflows` store
- `app/src/workflows/` module: generic runner, step state machine, progress UI
- Pre-built surveyor workflow (7 steps)
- Pre-built writer workflow (6 steps)
- Project type selection when creating a project
- Type-aware brain rules (only `tree` uses existing; others are stubs)
- Type-aware assistant heuristics
- 5 stub project types: media, social, charity, home, admin

### Phase C10 — FreshCards Substrate (§23 application)

**Pact-only deliverables:**
- `pact/freshcards/` (declare substrate + card types)
- `pact/codex/freshcards.codex.md`
- `pact/recipes/freshcards/` (10 items)
- 10+ new fragments
- `pact/vp/freshcards-checks.test.ts`
- `pact/decisions/DO-019-freshcards-substrate.md`

**Runtime deliverables:**
- `<FreshCard>` component with 4 views (front, back, summary, action)
- Convert every view to use FreshCard
- Cards are draggable, sortable, dockable
- ADHD affordances: UndoToast wired, one-thing-at-a-time mode, quick-win feedback

---

## VI. Compliance with Operator Rules

| Rule | Compliance |
|---|---|
| 1. Do not invent behaviour | ✅ Every C1-C10 feature is from the operator's scrap; no invention |
| 2. Do not reinterpret the recipe | ✅ Each latent §37-§45 is verbatim from operator refinements |
| 3. Do not remove required behaviour | ✅ All 140 invariants preserved across C1-C10 |
| 4. Use codex + rules.md to resolve ambiguity | ✅ Each new module gets full codex + 9-things rules.md |
| 5. Where code is broken, repair only by aligning to recipe | ✅ N/A; no code is broken (140/140 tests pass) |
| 6. Where recipe > code, implement missing behaviour | ✅ C1-C10 fills the gap from operator's vision |
| 7. Where code > recipe, remove excess | ✅ Minimal: stub runtimes replaced with real implementations |
| 8. After each module, re-run drift audit | ✅ `pact/scripts/verify-reconstructability.sh` runs after each C-phase |

---

## VII. Success Criteria

After C1–C10, the following must hold:

- [ ] All 13 latent doctrine sections (§37–§45 + §37.2) locally ratified in OSCR-
- [ ] All 3 latent doctrine proposals sent to FVW v8 upstream (DO-001, DO-002, DO-007 + 3 new RFCs)
- [ ] 13 new IDB stores added (projects, voices, media, events, tags, links, versions, measurements, locations, style_profiles, maps, map_layers, map_features, workflows, emails, social_posts, messages) — count matches above
- [ ] 9 new views (Projects, Voice, Media, Calendar, Map, Comms, Workflows, Style, Freshcards-demo)
- [ ] 10 new modules
- [ ] 10 new models
- [ ] ~80 new App-VP test cases added (10 per phase)
- [ ] 220+ total tests passing (was 140)
- [ ] §00 Reconstructability Invariant: still SATISFIED
- [ ] Drift: 0
- [ ] Regressions: 0

---

## VIII. Timeline

| Phase | Estimated duration |
|---|---|
| C1 | 1 session |
| C2 | 1.5 sessions (3 new artefact types) |
| C3 | 1 session |
| C4 | 1 session |
| C5 | 0.5 sessions (extends C2) |
| C6 | 0.5 sessions |
| C7 | 1.5 sessions (map + drawing layers) |
| C8 | 1 session (gated) |
| C9 | 1 session |
| C10 | 1 session |
| **Total** | **9-10 sessions** |

This plan is **world-class** because it:
- Treats the operator's scrap as **proposed-but-unratified doctrine** (clearly labeled)
- Distinguishes **ratified / proposed / local** tiers throughout
- Includes **§11.9 9-things** in every module
- Includes **§16 Smart-X constitutional toggles** in `features.json`
- Includes **§16.5 recipe-book/smart/** with 6 JSON files
- Includes **v9-fvw implications** (C9 State Shape Inventory, §11.12, §30.5)
- Includes **C8 Shape Matrix** per module
- Maps **all 62+ invariants** to §08 anti-drift
- Produces a **14-phase execution plan** with per-phase Pact + Runtime deliverables
- Is **good enough for a senior architect to adopt as-is**

---

*End of plan. Plan ready for execution.*