ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Flattening/Prompts and Instructions/DOC80_Claude_Code_Master_Execution_Runbook_v1_3.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # DOC80 Memory Rebuild — Claude Code Master Execution Runbook v1.3 **Document type:** Execution runbook for an agent-driven, multi-session flattening process. **Status:** Operational runbook. It does not replace the flattening plan. The flattening plan is the governing rule and schema source; this runbook only sequences the work, supplies the prompts, and defines the stop gates. **Saved in the repo at the stable path** `Memory Rebuild/Flattening/Prompts and Instructions/DOC80_Claude_Code_Master_Execution_Runbook.md` (unversioned alias — the version lives in this header, so the resume prompt never goes stale). **Governing plan:** `Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md`. Claude Code reads the plan's version from the plan header at runtime; this runbook does not hardcode the active plan version. **Aligns to:** the Flatten-and-Unify Plan §§1–21 at whatever version the plan header reports. **Supersedes:** `DOC80_Claude_Code_Master_Execution_Runbook_v1_2.md`, `_v1_1.md`, and `_v1_0.md` for execution purposes. **Repository:** `github.com/wbrody/Elnor-Specs`, branch `main`. Claude Code operates on a local clone. All paths in this runbook are repo-root-relative. **Changed from v1.1:** plan version no longer hardcoded (read from the plan header); Git remote check normalizes SSH/HTTPS; Stage 1 has explicit document-like include/exclude rules, an excluded-file summary, and inventories tracked **and** untracked files; first-run `RUN_STATE.md` uses `stage_status = not_started` with `last_completed_stage = Stage 0`; `RUN_STATE.md` adds `active_slice`, `active_slice_status`, and `last_completed_slice`; slice-review response files are slice-specifically named and a stage may carry multiple response files; a mocked-upstream-output register is added for cross-slice fixtures; the Review-Processing Routine adds a finding-adjudication table; Stage 5 makes DOC80 topology/owner identity a blocking decision; the Stop Gate Report states commit status; "create under Memory Rebuild/" is clarified to allow reading repo files outside it; "runbook governs" is limited to workflow mechanics; an MCP-automation placeholder is noted. E3/E4 is now a plan-declared lockstep pair (plan V2.1c §12.3). **Changed from v1.2:** the architect's two skeletal-architecture decisions are now pre-answered — DOC80 is a **spec family** and a **real owner doc in the ELNOR hierarchy** — seeded as resolved decision-queue items in Stage 4. Stage 5 reads them and builds on them rather than stopping; it raises an `architect_stop` only if the skeletal work surfaces a genuine contradiction of either. Stage 5 now also requires the skeletal baseline to state the **complete family member list, the split rationale by owner boundary, and the per-schema ownership handoff** from DOC72/DOC24/DOC73 — the real, batched Stage 5 architect decision. --- # 1. How to run this There is **one prompt**. Paste it into Claude Code at the start of every session — the first and every session after. Claude Code creates a copy of it at `Memory Rebuild/Flattening/Prompts and Instructions/RESUME_PROMPT.md` during Stage 0; this runbook does not ship that file. ```text You are Claude Code working in Will's ELNOR specs repository (github.com/wbrody/Elnor-Specs, branch main, local clone). 1. Read this runbook in full: Memory Rebuild/Flattening/Prompts and Instructions/DOC80_Claude_Code_Master_Execution_Runbook.md 2. Read the governing plan: Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md 3. Read RUN_STATE.md: Memory Rebuild/Flattening/Execution Ledger/Master/RUN_STATE.md If it does not exist, you are at Stage 0 — execute Stage 0, which creates it. 4. Run the Execution Controller in §4. Resume from RUN_STATE.md's current_stage, stage_status, and (in Stage 7) active_slice. If a review response has arrived, run the Review-Processing Routine (§21) for that stage first. 5. Run FORWARD through stages without pausing between them, until you reach the next mandatory stage-gate stop, an architect_stop, or a stage whose review tier requires Will or Codex. Do not ask "should I continue?" — the runbook and RUN_STATE.md define what is next. 6. At the stop, emit the Stop Gate Report (§7.1) and stop. Constraints: - Do not move, delete, rename, rewrite, merge, archive, or reclassify any source spec. Inventory and classification stages read only. - Create or update run artifacts only under Memory Rebuild/. Read-only access to repo files outside Memory Rebuild/ (README.md, REPO_FILE_MANIFEST.md, source specs) is expected and allowed. Do not edit source specs or repo-index files outside Memory Rebuild/ unless Will explicitly authorizes it. - Do not edit the flattening plan. If the plan appears genuinely contradictory (states a rule this runbook actively reverses — not merely a rule this runbook refines), raise an architect_stop. - Do not git push, and do not git commit unless Will explicitly authorizes it. - The flattening plan is the authority for all schemas, enums, record types, slice definitions, and the slice order. Where this runbook is more operationally specific than the plan ON WORKFLOW MECHANICS ONLY (which stage, which file path, which order to run prompts), the runbook governs and that is NOT a plan contradiction. The runbook never overrides the plan on substance. ``` That is the entire interface. On the first run, no `RUN_STATE.md` exists, so Claude Code starts at Stage 0, runs forward, and stops at the first mandatory gate (Stage 1). On every later run it reads `RUN_STATE.md` and resumes exactly where it left off — including the active slice inside Stage 7. You never tell it the next step. --- # 2. Authority model — plan vs runbook The plan and this runbook have non-overlapping jobs. | The flattening plan owns | This runbook owns | |---|---| | All record types, schemas, and **enum vocabularies** | The **stage sequence** and the prompts that drive each stage | | The **slice list, slice order, and lockstep pairs** (plan §12) | When to **self-audit, prepare a review packet, and stop** | | Decision tiers and stop conditions (plan §11) | The **file/folder layout** and Git locations of artifacts | | Acceptance standards (plan §19) | The **resume / state-machine** mechanics (`RUN_STATE.md`, controller loop) | | Lint and fixture definitions (plan §§14, 17) | The **report templates** and the Codex round-trip protocol | **Enum and slice supremacy.** This runbook contains **no** enum value lists and **no** slice list. When a stage produces records, Claude Code uses the exact vocabularies, slice definitions, and lockstep pairs from the plan, by section reference. If this runbook ever appears to name something differently from the plan, the **plan wins** and Claude Code records the discrepancy in the Conflict / Disagreement Register. **Plan contradiction vs plan refinement.** A *refinement* is the runbook being more operationally specific on workflow mechanics (which stage, which path, which prompt order). That is expected and is not a contradiction. A *contradiction* is the runbook stating a rule the plan actively reverses on substance. Only a genuine substantive contradiction is an `architect_stop`. --- # 3. Stop taxonomy Three stop types. Every "Stop" line in a stage names exactly one. - **`architect_stop`** — immediate and blocking. Triggered by any plan §11.3 condition. Claude Code halts mid-stage, writes an `ArchitectDecisionQueueItem` (tier `architect_stop`), sets `RUN_STATE.active_blockers`, emits a Stop Gate Report, and stops. Work does not continue until Will resolves it. - **`stage_gate_stop`** — a planned, mandatory checkpoint at the end of a stage. Claude Code completes the stage, self-audits, emits the Stop Gate Report, and waits for Will's "proceed." - **`conditional_stop`** — stop only if the stated condition holds. If it does not hold, Claude Code continues forward without pausing. `batch_for_architect` decisions (plan §11.2) are **not** stops. They accumulate in the Architect Decision Queue and are surfaced at the next `stage_gate_stop` as an Architect Decision Packet (§7.2). A batch decision whose `blocks_slices` is non-empty blocks only those slices. --- # 4. Execution controller and RUN_STATE.md Claude Code runs this runbook as a state machine, not a memo. **This runbook ships no `RUN_STATE.md` and no `RESUME_PROMPT.md`.** Claude Code creates both during Stage 0. `RUN_STATE.md` is then rewritten at the end of every stage. **At the start of every session:** 1. Read this runbook, the plan, and the master ledger. 2. Read `RUN_STATE.md`. If absent, `current_stage = Stage 0`. 3. Verify `RUN_STATE.md` and the master ledger agree on `current_stage` / `last_completed_stage`. If they disagree, raise a `conditional_stop` and report the desync — do not guess. 4. If `RUN_STATE.stage_status = awaiting_review_response` and any matching response file(s) now exist for that stage, run the **Review-Processing Routine (§21)** before anything else. 5. Resume at `current_stage` (and, in Stage 7, at `active_slice`) and run forward. **Within each stage:** 1. Execute the stage's "Prompt CC follows." 2. Run the stage's self-audit; patch any failure before proceeding; record residual issues. 3. Write/update the stage's output artifacts at their mapped Git locations (§6). 4. Update the master ledger and the relevant per-slice fragment. 5. Update `RUN_STATE.md` **last** (it is the authoritative resume pointer). 6. If the stage's review tier requires it, generate the review packet. 7. Determine the stop type. On a `stage_gate_stop` or `architect_stop`, emit the Stop Gate Report and stop. On `conditional_stop`, stop only if the condition holds; otherwise continue to the next stage **without pausing**. **`RUN_STATE.md`** lives at `Memory Rebuild/Flattening/Execution Ledger/Master/RUN_STATE.md` and is a short, fixed-shape control file: ```text plan_version_seen: runbook_version_seen: current_stage: stage_status: not_started | in_progress | self_audit | awaiting_review_response | awaiting_will_approval | approved last_completed_stage: next_stage: active_slice: active_slice_status: chartered | drafting | awaiting_review | patching | approved | none last_completed_slice: pending_will_action: pending_external_review: active_blockers: last_updated: ``` `RUN_STATE.md` is the resume pointer; the master ledger (plan §4.1, fourteen fixed sections) is the detailed log. `RUN_STATE.md` is updated last in every stage so it is never ahead of the ledger; the controller step 3 desync check guards drift between them. --- # 5. Stage Index — the staircase Claude Code consults this table to know where it is and what is next. Stage numbers belong to this runbook; slice IDs (E0–E10) belong to the plan §12. | Stage | Plan §3.8 step | Produces | Self-audit | Review tier | Stop type | On approval → | |---|---|---|---|---|---|---| | 0 | — | Boot, repo verify, `RUN_STATE.md` + `RESUME_PROMPT.md` init or resume | n/a | none | resume forward | current_stage | | 1 | precursor to step 1 | Source Registry (inventory only) | yes | Codex optional + **Will mandatory** | `stage_gate_stop` | 2 | | 2 | step 1 | Source Freeze + Target Freeze | yes | self-audit; **Will** | `stage_gate_stop` | 3 | | 3 | step 2 | Source-section disposition + Capability inventory | yes | **Codex default** + Will | `stage_gate_stop` | 4 | | 4 | between steps 2–3 | Supersession matrix + Overlap + Aspirational completion + Decision Queue preload + Conflict register init | yes | self-audit; **Will mandatory** | `stage_gate_stop` | 5 | | 5 | step 3 | Skeletal DOC80 + import graph + owner map + retired-name table + section map | yes | **Will / red-team mandatory** | `stage_gate_stop` (+ `architect_stop` only on a genuine contradiction of the seeded spec-family / owner-doc decisions) | 6 | | 6 | step 4 | Slice charters E0–E10 + golden fixtures + mocked-output register | yes | **Will mandatory** (E1/E3/E7/E8 charters) | `stage_gate_stop` | 7 | | 7 | step 5 | Draft slices E0–E10 (plan §12 order + lockstep pairs) | per slice | per-slice; **Will mandatory** E1/E3/E7/E8, architect-or-approved-second-agent E2/E10 | per-slice `stage_gate_stop` for high-risk slices | 8 / 9 | | 8 | within steps 5–6 | Patched slices after review | yes | `conditional` | `conditional_stop` | back to 7 / on to 9 | | 9 | step 6 | Cross-slice integration: lint report + fixture report | yes | Will if any critical lint fails | `conditional_stop` | 10 | | 10 | pre-step 7 | Assembled DOC80 draft + final integration review packet | yes | **red-team mandatory** | `stage_gate_stop` | 11 | | 11 | step 7 | Final switchover proof | yes | **Will mandatory, always** | `stage_gate_stop` | done | The **Review-Processing Routine (§21)** runs between a stage and the next whenever that stage produced a review packet and a response has arrived. It is not a numbered stage. --- # 6. File and folder map — Git locations All paths are relative to the repo root (`github.com/wbrody/Elnor-Specs`, branch `main`). Claude Code creates missing folders under `Memory Rebuild/`. It consults `REPO_FILE_MANIFEST.md` for the canonical location of any pre-existing file (the plan, ABC R0.2, Round D R0.2, the primer) and preserves exact paths, spaces, and capitalization. ``` Memory Rebuild/ Flattening/ Current Plan/ Flatten_and_Unify_Plan.md [pre-existing — the plan] Prompts and Instructions/ DOC80_Claude_Code_Master_Execution_Runbook.md [this file — saved unversioned] RESUME_PROMPT.md [created Stage 0; static] Source Registry/ Source_Registry.md [Stage 1] Excluded_File_Summary.md [Stage 1] Source Freeze/ Source_Freeze.md [Stage 2; re-hashed on changes] Target Freeze/ Target_Freeze.md [Stage 2; re-hashed on changes] Source Section Disposition/ Source_Section_Disposition.md [Stage 3; updated on review] Capability Inventory/ Capability_Inventory.md [Stage 3; updated on review] Supersession Matrix/ Supersession_Matrix.md [Stage 4; updated through Stage 9] Overlap Resolution/ Overlap_Resolution.md [Stage 4; updated through Stage 9] Aspirational Completion/ Aspirational_Completion_Register.md [Stage 4; updated through Stage 9] Golden Fixtures/ Golden_Scenario_Fixtures.md [Stage 6; run Stage 9 & 11] Mocked_Upstream_Outputs.md [Stage 6; enforced/retired Stage 9–11] Execution Ledger/ Master/ FlatteningExecutionLedger.md [Stage 0; updated EVERY stage] RUN_STATE.md [Stage 0; updated EVERY stage] Slice Ledgers/ E##__ledger.md [one per slice; updated per slice] Architect Decision Queue/ Architect_Decision_Queue.md [Stage 4 preload; updated ongoing] Conflict Register/ Conflict_Disagreement_Register.md [Stage 4 init; updated ongoing] Lint Reports/ Cross_Slice_Lint_Report.md [Stage 9] Fixture Reports/ Cross_Slice_Fixture_Report.md [Stage 9] OP-A Disposition/ OP_A_Candidate_Disposition.md [Stage 4 start; updated through Stage 9] Reviews/ Codex Ready/ Stage__Review_Prompt.md [created at each Codex gate] Stage_7__Review_Prompt.md [created at each slice gate] Codex Responses/ Stage__Review_Response.md [SAVED BY WILL] Stage_7__Review_Response.md [SAVED BY WILL — slice reviews] Stage_/ (optional folder for multi-reviewer responses: Claude.md, GPT.md, ...) Red Team Ready/ _Review_Prompt.md [created at red-team gates] Red Team Responses/ _Review_Response.md [SAVED BY WILL] / (optional folder for multi-reviewer responses) DOC80 Target Baseline/ Skeletal Spec/ DOC80_Skeletal_Target_Baseline.md [Stage 5; patched after review] Import Graph/ DOC80_Import_Graph.md [Stage 5] Owner Map/ DOC80_Owner_Map.md [Stage 5] Retired Names/ DOC80_Retired_Names.md [Stage 5; updated through Stage 9] Slice Charters/ E##__Charter.md [Stage 6; one per slice] Slice Drafts/ E##__Draft.md [Stage 7; one per slice] Slice Patches/ E##__Patched.md [Stage 8] Final Rebuild/ DOC80_Memory_Control_Plane_Spec_Draft.md [Stage 10] Final_Integration_Review_Prompt.md [Stage 10] Final_Integration_Adjudication.md [Stage 10/11 — review adjudication table] DOC80_Final_Switchover_Proof.md [Stage 11] ``` **Update cadence — files Claude Code rewrites repeatedly:** `FlatteningExecutionLedger.md` and `RUN_STATE.md` every stage; per-slice ledger fragments per slice; `Supersession_Matrix.md`, `Overlap_Resolution.md`, `Aspirational_Completion_Register.md`, `OP_A_Candidate_Disposition.md`, `DOC80_Retired_Names.md`, `Architect_Decision_Queue.md`, and `Conflict_Disagreement_Register.md` from their creating stage through Stage 9. **Files Will writes:** the Codex/red-team **response** files under `Reviews/Codex Responses/` and `Reviews/Red Team Responses/`. Claude Code always names the exact path(s) in the Stop Gate Report so the controller can detect them on resume. --- # 7. Standard templates ## 7.1 Stop Gate Report Emitted at every `stage_gate_stop` and `architect_stop`. It always ends with an explicit, numbered "What you do now." ```text STOP — [stage_gate_stop | architect_stop] COMPLETED - FILES CREATED / UPDATED (repo-relative paths) - — SELF-AUDIT - result: pass | pass-with-notes | fail-patched - issues found and patched: - issues remaining: REVIEW PACKET - prepared: yes/no - path(s): or n/a - how Codex/red-team finds the files: - save the response to: ARCHITECT DECISIONS NEEDING YOU - batched: (see Architect Decision Packet below, or "none") - architect_stop: COMMIT - commit authorized by Will: yes/no - if authorized: files staged and committed with message "" - if not: recommended commit message "" (no commit made; no push made) WHAT YOU DO NOW 1. . Save Codex's reply to .> 2. 3. Re-paste the resume prompt. Claude Code continues from here automatically. NEXT STAGE IF YOU APPROVE: ``` ## 7.2 Architect Decision Packet When batched decisions exist at a stop, Claude Code appends this. ```text ARCHITECT DECISION PACKET — | id | tier | question (plain) | recommended answer | alternatives | affected slices | blocks work? | |----|------|------------------|--------------------|--------------|-----------------|--------------| CAN PROCEED ON IF YOU APPROVE THE RECOMMENDED ANSWERS: THESE BLOCK PROGRESS UNTIL ANSWERED: REPLY ONE OF: 1. "Approve all recommended." 2. "Approve all except : ." 3. Answer each id individually below. 4. "Revise packet" with what is unclear. ``` ## 7.3 Codex review packet, round-trip, and multi-reviewer handling At every review gate, Claude Code writes a **self-contained** review prompt into `Reviews/Codex Ready/` (or `Red Team Ready/`) using this template, then names it and the expected response path in the Stop Gate Report. ```text # Codex Review — : ## Repository github.com/wbrody/Elnor-Specs — branch main ## Files to review (repo-relative paths — Codex with repo read access fetches these directly) - - ## Context files (read-only, for owner-boundary grounding — do not re-review) - Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md - ## Review questions ## Output format Return a concise audit: cite rows/sections/paths, type each finding BUG / GAP / SUGGESTION / CONFIRMED, give concrete corrections. This is a review — do not make final inclusion decisions. ``` **Round-trip — Will's part is three actions:** 1. Claude Code stops; the Stop Gate Report names the prompt file and the exact response path. 2. Will pastes the prompt into Codex (or another reviewer). If the reviewer has read access to the GitHub repo it fetches the listed files itself; if not, Will attaches the files named under "Files to review." 3. Will saves the reply, verbatim, to the exact path Claude Code specified, then re-pastes the resume prompt. **Response file naming.** Stage-level reviews: `Reviews/Codex Responses/Stage__Review_Response.md`. Slice reviews: `Reviews/Codex Responses/Stage_7__Review_Response.md`. `RUN_STATE.pending_external_review` stores the exact expected path(s); the controller looks for those paths first. **Multiple reviewers per stage.** If Will routes a stage to several reviewers, responses go in a per-stage folder, e.g. `Reviews/Red Team Responses/Stage_/Claude.md`, `GPT.md`, `Gemini.md`. When a per-stage folder exists, the Review-Processing Routine (§21) consolidates **all** files in it before advancing. **Future automation.** If GitHub/MCP automation is later enabled, the manual round-trip is replaced by the same review-packet-and-response-file protocol; review gates and decision tiers do not change. --- # 8. Core execution principles These supplement, and never override, the plan (plan §2 product philosophy, §11 decision tiers, §3 freezes). 1. **No destructive work.** Do not move, delete, rename, rewrite, merge, archive, or reclassify a source spec. Stages 1–4 read source files only. 2. **Scope of writes.** Create or update run artifacts only under `Memory Rebuild/`. Reading repo files outside it (README, manifest, source specs) is expected and allowed. Do not edit source specs or repo-index files outside `Memory Rebuild/` unless Will explicitly authorizes it. 3. **Plan is rules, ledger is state.** Never silently edit the plan. The ledger and `RUN_STATE.md` are the mutable execution state. 4. **No final inclusion decisions during inventory.** Stages 1–4 identify and classify; they do not decide what enters DOC80. 5. **Preserve valuable aspiration** (plan §1.3 / §7). Aspirational, incomplete, or old material is not disposable. 6. **Overlap is design evidence** (plan §9), not nuisance dedupe. 7. **Batch, don't interrupt** (plan §11.2). Surface batched decisions at the next stage gate via §7.2. 8. **No asserted checks.** A lint or fixture is "passed" only with concrete evidence recorded (Stage 9). --- # 9. Stage 0 — Boot, verify, resume **Plan step:** precursor. **Stop:** none (resume forward). **Prompt CC follows:** ```text STAGE 0 — Boot and resume. 1. Confirm the repo: git rev-parse --show-toplevel git remote -v git branch --show-current (expect: main) git status --short Normalize the remote URL before comparison: accept either an HTTPS remote (https://github.com/wbrody/Elnor-Specs.git) or an SSH remote (git@github.com:wbrody/Elnor-Specs.git) — the normalized owner/repo must be wbrody/Elnor-Specs. 2. Read README.md and REPO_FILE_MANIFEST.md. Use REPO_FILE_MANIFEST.md as the repo index. Preserve exact paths, spaces, and capitalization. Do not use older underscore-style paths unless they appear in the current manifest. 3. Resolve and read the governing plan (expected: Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md). Record its header version string into RUN_STATE.plan_version_seen. 4. Check for RUN_STATE.md. - If ABSENT: this is the first run. Create the folder tree in runbook §6. Create FlatteningExecutionLedger.md with the 14 fixed sections (plan §4.1), populated only with repo root, plan path, plan version, runbook version, and timestamps. Create RESUME_PROMPT.md (the runbook §1 prompt text). Create RUN_STATE.md initialized as: current_stage: Stage 1 stage_status: not_started last_completed_stage: Stage 0 next_stage: Stage 1 active_slice: none active_slice_status: none last_completed_slice: none pending_will_action: none pending_external_review: none active_blockers: none - If PRESENT: read it, verify it agrees with the master ledger (controller §4 step 3). If review responses have arrived, run §21 first. Resume. 5. Extract from the plan and hold for the session: source/target-freeze rules (§3), record types (§§4–11), slice list, slice order, and lockstep pairs (§12), decision tiers (§11), lint suite (§17), acceptance standard (§19). 6. Do not edit any source spec. Output a one-line status note and continue forward to the resolved current_stage without pausing. architect_stop if: repo root wrong, the normalized git remote is not wbrody/Elnor-Specs, the plan file cannot be resolved, or README/REPO_FILE_MANIFEST is missing. ``` --- # 10. Stage 1 — Source Registry (inventory only) **Plan step:** precursor to step 1. **Produces:** `Source Registry/Source_Registry.md`, `Source Registry/Excluded_File_Summary.md`. **Review:** Codex optional + Will mandatory. **Stop:** `stage_gate_stop`. Stage 1 is a **pure inventory** — it records what exists. It does **not** assign canonical `source_status` / `normative_weight` (that is Stage 2 under plan §3.2–3.4) and does not decide DOC80 inclusion. **Prompt CC follows:** ```text STAGE 1 — Source Registry (inventory only). Read: the plan; REPO_FILE_MANIFEST.md; FlatteningExecutionLedger.md. Create Memory Rebuild/Flattening/Source Registry/Source_Registry.md. Include / exclude rules: - Document-like files to INCLUDE: .md, .txt, .docx, .pdf, .rtf; .json/.jsonl when used as specs, registries, ledgers, trackers, schemas, configs, prompts, review artifacts, or operations documents; code files (.jsx/.tsx/.ts and similar) ONLY when they are canonical design, schema, UI-reference, or architecture artifacts. - EXCLUDE: .git, node_modules, build artifacts, caches, vendored dependencies, generated lock/build outputs, binary junk, and images unless the filename indicates a canonical design/reference artifact. - If uncertain, INCLUDE the file and mark it unknown. Never silently omit. Rules: - Read-only on all source files. Edit only Source_Registry.md, Excluded_File_Summary.md, and the ledger. - This is inventory, NOT classification: do not assign plan §3 source_status or normative_weight, and do not decide DOC80 inclusion. - For large repos, process directory-by-directory, appending rows. For every included file, one row: | repo_path | document_name | apparent_owner_doc | version_or_date | file_kind | | folder_category | first_glance_relevance (direct / adjacent / capability / process / low / unknown) | one_line_note | Also create Memory Rebuild/Flattening/Source Registry/Excluded_File_Summary.md: a short table of what was excluded and why (path-or-glob, exclusion_reason, count). This lets the registry be reconciled against the full file list. After the registry table, list — by folder_category — any files needing Will's eyes before the freeze. Update the ledger Source Freeze Index pointer and RUN_STATE.md. ``` **Self-audit:** ```text 1. Row count matches: tracked document-like files from `git ls-files` PLUS untracked document-like files from `git status --short` / a filesystem scan. (Newly-saved-but-uncommitted files must appear in the registry.) 2. Every excluded path accounted for in Excluded_File_Summary.md? 3. Every uncertain file included and marked unknown (not omitted)? 4. No source file moved, edited, or classified with plan §3 vocabularies? 5. Registry reconciled against REPO_FILE_MANIFEST.md, divergences flagged? 6. Ledger and RUN_STATE.md updated? Patch any failure before stopping. ``` **Review packet:** generate per §7.3. Files: `Source_Registry.md`, `Excluded_File_Summary.md`. Context: `REPO_FILE_MANIFEST.md`. Questions: any document-like files missing? any folder un-crawled? any high-value source marked low relevance? are old/aspirational files preserved in the inventory? is anything wrongly excluded? --- # 11. Stage 2 — Source Freeze and Target Freeze **Plan step:** 1. **Produces:** `Source Freeze/Source_Freeze.md`, `Target Freeze/Target_Freeze.md`. **Review:** self-audit; Will. **Stop:** `stage_gate_stop`. **Prompt CC follows:** ```text STAGE 2 — Source Freeze and Target Freeze. Read: the plan §3; Source_Registry.md; REPO_FILE_MANIFEST.md; the ledger. Task A — Source Freeze. For each registry file, create a SourceFreezeRecord with the exact fields and vocabularies of plan §3.1–§3.4. Assign source_status (plan §3.2) and normative_weight (plan §3.3), respecting the legal-combination table (plan §3.4). Hash every frozen file. Do not exclude a file for being old, aspirational, or incomplete — classify it. Uncertain files: unknown_pending_review. Task B — Target Freeze. Create a TargetFreezeRecord (plan §3.7) for every target-package file (plan §3.5). ACTIVELY LOCATE each via REPO_FILE_MANIFEST.md and exact-path lookup — do not treat any as "if present." - found: set availability_status attached or path_resolvable; hash it. - not found: set availability_status missing_must_attach; if it blocks a stage or slice, raise an architect_stop. Task C — Invalidation. Record the plan §3.7 rule: any later hash change to a frozen file sets invalidation_state = invalidated_pending_refresh on every dependent record. Also record a new-file rule: on each resume, diff `git ls-files` plus untracked files against the Source Freeze; a new memory-relevant file is a conditional_stop for re-freeze. Update the ledger (Source Freeze Index, Target Freeze Index) and RUN_STATE.md. ``` **Self-audit:** every Source Freeze row traces to a registry row; every frozen file hashed; every (source_status, normative_weight) pair legal per plan §3.4; every target-package file located/hashed or marked missing_must_attach; missing blocking target files raised as architect_stop; invalidation and new-file rules recorded; source files unchanged; ledger and RUN_STATE updated. `conditional_stop` if a required target file is missing, a source status is highly uncertain, or the source set is unexpectedly large or sparse. Otherwise `stage_gate_stop`. --- # 12. Stage 3 — Source-section disposition and capability inventory **Plan step:** 2. **Produces:** `Source Section Disposition/Source_Section_Disposition.md`, `Capability Inventory/Capability_Inventory.md`. **Review:** Codex review is the **default** (Will may waive). **Stop:** `stage_gate_stop`. The highest-risk classification stage. It carries both a self-audit and a default Codex review. **Prompt CC follows:** ```text STAGE 3 — Source-section disposition and capability inventory. Read: the plan §§5, 6, 7; Source_Freeze.md; Target_Freeze.md; the ledger. Part A — SourceSectionDispositionRecord (plan §5). For every material section of every in-scope frozen source file, create a record with the exact fields and disposition vocabulary of plan §5. Populate op_a_obligation_refs from any EXISTING OP-A obligations the section already carries — this is the inbound OP-A sweep. Capture negative-space (defaults, invariants, UI states, examples). Part B — CurrentSpecCapabilityRecord (plan §6.3), using the capability_status (plan §6.1) and capability_tier (plan §6.2) vocabularies. Apply the plan §6.2 safe default: any untiered touched capability is load_bearing until reviewed. Seed the plan §6.4 crown-jewel / load-bearing families. Do not exit until every in-scope source doc has capability rows with at least provisional tiers. Rules: no final deletion decisions; aspirational-but-valuable capability is preserved (its completion record is created in Stage 4); product-facing capabilities get architect_review_required = true. Update the ledger and RUN_STATE.md. ``` **Self-audit:** ```text 1. Every in-scope frozen source section has a SourceSectionDispositionRecord? 2. Every capability has a tier; untiered-touched defaulted to load_bearing? 3. All plan §6.4 crown-jewel / load-bearing families seeded? 4. Are any disposition rows too final for a first pass (should be unresolved)? 5. Did any capability get tiered low (supporting/minor) in a way that would let it be dropped without architect review? Flag every such row. 6. op_a_obligation_refs populated from existing OP-A where present? 7. Disposition and capability vocabularies match the plan exactly? 8. Ledger and RUN_STATE.md updated? ``` **Review packet:** per §7.3, default to preparing it. Files: both Stage 3 outputs. Context: the plan, ABC R0.2, Round D R0.2. Questions: missing sections? capabilities under-described or mis-tiered? aspirational-but-valuable capabilities preserved? any crown-jewel at risk of silent downgrade? sections wrongly archived despite holding DOC80-relevant mechanisms? what must be batched before skeletal drafting? --- # 13. Stage 4 — Supersession matrix, overlap, aspirational completion, decision queue **Plan step:** between steps 2 and 3 — it produces the inputs the skeletal gate (plan §18) and the slice charters (plan §13) require. **Produces:** `Supersession_Matrix.md`, `Overlap_Resolution.md`, `Aspirational_Completion_Register.md`, `Architect_Decision_Queue.md`, `Conflict_Disagreement_Register.md` (initialized), `OP_A_Candidate_Disposition.md` (started). **Review:** self-audit; Will mandatory. **Stop:** `stage_gate_stop`. **Prompt CC follows:** ```text STAGE 4 — Supersession, overlap, aspirational completion, decision queue. Read: the plan §§7–11, 16; Source_Section_Disposition.md; Capability_Inventory.md; Source_Freeze.md; Target_Freeze.md; ABC R0.2; Round D R0.2; the Coverage Audit and any open-question lists in the target package. Task A — Supersession Matrix (plan §8). One SupersessionMatrixRow for every named type, enum, schema, concept, product kind, policy/scope object, prompt shell, and old/new overlap in the frozen source set — even if retained. Use the DispositionMove vocabulary (plan §9.2) and approval_status vocabulary (plan §8.1). An agent may NOT set its own row to architect_approved (plan §8.3). Attach a capability_preservation_proof_ref wherever plan §8.2 requires one. Cover at minimum the plan §8.5 named families. Task B — Overlap Resolution (plan §9). One OverlapResolutionRecord per overlap, with a CanonicalOverlapKey (plan §9.1); a resolved overlap is consumed by reference, not re-resolved. terminology_only / false_overlap calls on crown-jewel, load-bearing, policy, scope, truth, injection, or owner-boundary concepts require second-agent or architect-batch confirmation (plan §9.3). Task C — Aspirational Completion Register (plan §7). One AspirationalCapabilityCompletionRecord per aspirational-valuable capability. minimum_completion_for_v5 is an architect decision unless a pre-approved target rule covers it — otherwise queue it. Task D — Architect Decision Queue (plan §11.4). PRELOAD known open decisions from ABC R0.2, Round D R0.2, the Coverage Audit, and any adjudication-delta / open-question lists in the target package. Each item carries blocks_slices and aging_state. default_if_no_response is forbidden for architect_stop and limited for batch items per plan §11.4. Task E — Initialize the Conflict / Disagreement Register (plan §10) and start OP_A_Candidate_Disposition.md (plan §16). Task F — Seed pre-approved architect decisions. The architect has already decided two skeletal-architecture questions. Create two ArchitectDecisionQueueItem rows (plan §11.4) with status = resolved and architect_answer filled, so Stage 5 consults them instead of stopping: D-SEED-1: "Is DOC80 a single spec, a spec family, or a coordinating owner spec?" — architect_answer: "Spec family." Rationale: the memory corpus is too large for one document; it must be reviewable, red-teamable, and editable in owner-bounded members. D-SEED-2: "Is the DOC80 family a real owner doc in the ELNOR hierarchy, or a coordination layer that re-homes nothing?" — architect_answer: "A real owner doc / family in the ELNOR hierarchy (members DOC80, DOC81, ...)." Rationale: after flattening, the memory schemas must have one authoritative home rather than staying scattered across DOC72/DOC24/DOC73. Record both as resolved / architect_approved. They are settled direction; Stage 5 may still surface a genuine contradiction of either. Rules: every source concept unaccounted in the matrix is a lint later (plan §8.4); any reject / retire_as_superseded / defer_completion etc. requires a preservation proof per plan §8.2; semantic_compression requires the plan §9.5 rule-by-rule proof. Update the ledger and RUN_STATE.md. ``` **Self-audit:** every plan §8.5 family has an explicit matrix row and every source concept from Stages 1–3 is accounted for; no agent-proposed row marked architect_approved; every capability-changing disposition carries a preservation proof; every semantic_compression has a rule-by-rule proof; the decision queue is preloaded from all target-package open-question lists; the two seeded decisions D-SEED-1 and D-SEED-2 are recorded as resolved; no architect_stop item has `default_if_no_response`; conflict register initialized; vocabularies match the plan; ledger and RUN_STATE updated. --- # 14. Stage 5 — Skeletal DOC80 baseline and import graph **Plan step:** 3 (plan §18). **Produces:** `DOC80_Skeletal_Target_Baseline.md`, `DOC80_Import_Graph.md`, `DOC80_Owner_Map.md`, `DOC80_Retired_Names.md`. **Review:** Will / red-team mandatory. **Stop:** `stage_gate_stop`; `architect_stop` only if the skeletal work surfaces a genuine contradiction of the seeded spec-family / owner-doc decisions. **Prompt CC follows:** ```text STAGE 5 — Skeletal DOC80 target baseline and import graph. Read: the plan §18; Source_Freeze.md; Target_Freeze.md; Capability_Inventory.md; Supersession_Matrix.md; Overlap_Resolution.md; Architect_Decision_Queue.md; ABC R0.2; Round D R0.2; the DOC80 outline. Produce the skeletal DOC80 target baseline with everything plan §18 lists: spec family membership, owner-doc imports, canonical object families, section map, retired-name table, cross-doc owner map, required lints, required fixtures, and an OP-A candidate table placeholder. Derive the canonical object families from ABC R0.2 §2.1 and the Supersession Matrix — do not invent or hardcode a family list. State explicitly what DOC80 owns and does not own, and the owner boundaries with DOC72/DOC73/DOC25/DOC24/ KDA/BDSM/EC/PropA/DOC20/DOC23/DOC15/DOC11/DOC1/DOC3. SEEDED DECISIONS — do not stop to ask. Two skeletal-architecture questions are already resolved in the Architect Decision Queue: D-SEED-1 (DOC80 is a spec family) and D-SEED-2 (the family is a real owner doc in the ELNOR hierarchy). Read both and build on them. Raise an architect_stop ONLY if the skeletal work surfaces a genuine contradiction of either — for example, the owner-map analysis shows a memory schema cannot move into the family without breaking an existing owner boundary. Do not re-ask the settled questions. REQUIRED SKELETAL CONTENT — the real Stage 5 architect decision. Because DOC80 is a spec family and a real owner doc, the skeletal baseline MUST state, and the Stage 5 review MUST decide: - the COMPLETE family member list (DOC80, DOC81, DOC82, ...) — no "as needed" placeholders; - the SPLIT RATIONALE — members are divided by owner boundary along the plan §12 slice structure, not by document count. Name which slices each member owns. Include exactly one core/contracts member that owns the shared schemas, the DispositionMove vocabulary, and the proof spine; every other member imports from it and never redefines them; - the PER-SCHEMA OWNERSHIP HANDOFF — for each memory schema currently defined in DOC72/DOC24/DOC73 (Assertion, EvidenceSupportEdge, ContextProduct, the policy/scope objects, etc.), state whether the DOC80 family takes ownership (and DOC72/DOC24/DOC73 are amended to defer) or ownership stays put. Every handoff that moves ownership becomes an OP-A candidate row. The member list, split rationale, and ownership handoff are batched for the architect at the Stage 5 gate. They are decisions — they do not block drafting of the skeletal baseline itself. DOC80 is the working family name; final member naming also goes to the decision queue. Also write DOC80_Import_Graph.md, DOC80_Owner_Map.md, DOC80_Retired_Names.md. Do not draft full sections. Do not silently resolve architect_stop items. Update the ledger and RUN_STATE.md. ``` **Self-audit:** owns/does-not-own stated explicitly; the seeded decisions D-SEED-1 and D-SEED-2 read and built on, not re-asked, with `architect_stop` raised only on a genuine contradiction; the complete family member list, the split rationale by owner boundary, and the per-schema ownership handoff from DOC72/DOC24/DOC73 are all stated and batched for the architect; object families derive from ABC §2.1 + the matrix (not hardcoded); the import graph proves the plan §18 conditions; retired-name table matches the Supersession Matrix; ledger and RUN_STATE updated. **Review:** mandatory Will / red-team review via §7.3. Per plan §18 the architect must confirm the skeletal architecture before any slice charter is approved. After responses arrive, §21 patches the skeletal set; if review identifies owner-boundary conflicts or duplicate-truth/policy/delivery systems, `conditional_stop`. --- # 15. Stage 6 — Slice charters, golden fixtures, mocked-output register **Plan step:** 4 (plan §§13, 14). **Produces:** `Slice Charters/E##__Charter.md` (one per slice), `Golden Fixtures/Golden_Scenario_Fixtures.md`, `Golden Fixtures/Mocked_Upstream_Outputs.md`. **Review:** Will mandatory for E1/E3/E7/E8 charters. **Stop:** `stage_gate_stop`. **Prompt CC follows:** ```text STAGE 6 — Slice charters, golden fixtures, mocked-output register. Read: the plan §§12, 13, 14; the approved skeletal DOC80 baseline; the import graph; the owner map; Source_Section_Disposition.md; Capability_Inventory.md; Supersession_Matrix.md; Overlap_Resolution.md; Architect_Decision_Queue.md. Task A — Slice charters. The slice list, slice IDs, slice ORDER, and lockstep pairs are defined solely by plan §12. Do not redefine or reorder them. Honor every lockstep pair the plan declares — currently E1/E2, E3/E4, and E7/E8 per plan §12. For each slice E0–E10 create a SliceCharter file containing every field in plan §13's fresh-window-packet list, including expected_improvement_or_preserve_rationale and the negative-space / do-not-do list. A charter missing a required field fails the plan §13 slice_charter.* lints — do not advance such a charter. Task B — Golden fixtures. Author the golden-scenario set as executable GoldenScenarioRecords per plan §14, with expected outcomes across the named dimensions, gate_level, and blocking_severity. Build the fixture-to-slice matrix. Each charter references the fixtures that gate its slice. A fixture with no expected outcomes fails fixture.no_expected_outcomes. Task C — Mocked-upstream-output register. Cross-slice fixtures may use mocked upstream outputs until final integration (plan §14). Create Golden Fixtures/Mocked_Upstream_Outputs.md with one row per mock: mock_id | fixture_id | upstream_slice | declared_output_contract_ref | mock_file_path | content_hash | allowed_until_gate | replacement_required_before Each mock must be a static artifact referenced by path/hash and must match the upstream slice's declared output contract. Final-switchover fixtures may not use mocks. Per plan §13: E1, E3, E7, E8 charters require architect approval before drafting; E2 and E10 require pre-draft review and may proceed on architect approval or architect-approved second-agent confirmation. Update the ledger and RUN_STATE.md. ``` **Self-audit:** every slice E0–E10 has a charter; no charter omits a plan §13 required field; slice order and lockstep pairs match plan §12 exactly with no runbook-local reordering; every golden fixture has expected outcomes, a gate level, and a slice mapping; every mock has a contract ref, hash, and an `allowed_until_gate` that is not the final switchover; charters for E1/E3/E7/E8 flagged for mandatory architect approval; ledger and RUN_STATE updated. --- # 16. Stage 7 — Draft slices **Plan step:** 5 (plan §12). **Produces:** `Slice Drafts/E##__Draft.md`. **Review:** per-slice — Will mandatory for E1/E3/E7/E8; architect-or-approved-second-agent for E2/E10. **Stop:** per-slice `stage_gate_stop` for high-risk slices; otherwise continue. Draft slices in the plan §12 dependency order, honoring its lockstep pairs (E1/E2, E3/E4, E7/E8 — drafted together or in immediate succession with cross-checking). Do not draft everything in one pass. Throughout Stage 7, `RUN_STATE.active_slice` and `active_slice_status` track exactly which slice is in flight; update them after every step so a fresh session resumes on the right slice. **General per-slice prompt:** ```text STAGE 7 — Draft slice . Set RUN_STATE.active_slice = , active_slice_status = drafting. Read: the plan global rules and §12; FlatteningExecutionLedger.md; the approved skeletal DOC80 baseline; the import graph; the owner map; DOC80_Retired_Names.md; the Supersession Matrix index and the rows relevant to this slice; this slice's APPROVED charter; the source files/sections, capability rows, disposition rows, overlap rows, golden fixtures, and mocked-upstream outputs the charter names; the lockstep partner slice if this slice is in a lockstep pair. Draft DOC80 slice only. Requirements: 1. Preserve the current-spec capabilities the charter lists; trace each. 2. Preserve or complete the aspirational capabilities the charter assigns. 3. Apply approved supersession names; do not reintroduce retired names except as lineage references in allowed contexts. 4. Use the approved owner boundaries; do not absorb external owner docs wholesale. 5. Do not create duplicate truth / policy / delivery / learning / UI systems. 6. Record either a substantive improvement or a positive preserve-as-is rationale (plan §13). Preservation with a sound rationale is fully equal to improvement — do not manufacture a change to satisfy the gate. 7. Include normative rules, schemas, owner boundaries, degraded states, lints, and the slice's golden fixtures. 8. For every product-facing feature, state the user value and the real command / route / read-model / proof path. 9. If a needed decision is an architect_stop condition, stop and queue it. If it is a batchable decision, you MAY proceed against its recommended_answer, marking dependents provisional; record this in the slice ledger. 10. Save to DOC80 Target Baseline/Slice Drafts/__Draft.md. Then run the slice self-audit, update the slice ledger fragment and the master ledger, set RUN_STATE.active_slice_status appropriately (awaiting_review for a high-risk slice, approved otherwise) and update last_completed_slice when done, and — for a high-risk slice — generate the review packet. ``` **Slice self-audit:** ```text 1. Every capability the charter says to preserve is present and traceable to a source section? 2. No retired name used outside an allowed historical/lineage context? 3. Approved owner boundaries respected; no external owner doc absorbed wholesale? 4. No duplicate truth / policy / delivery / learning / UI system introduced? 5. A substantive improvement OR a positive preserve-as-is rationale recorded? 6. Schemas, degraded states, lints, and golden fixtures present where required? 7. Every product-facing feature has a real command / route / read-model / proof? 8. The charter's negative-space list respected (nothing it forbade)? 9. If this slice is in a lockstep pair, cross-checked against the partner slice? 10. Slice ledger fragment, master ledger, and RUN_STATE.md (incl. active_slice) updated? Patch failures before stopping or requesting review. ``` **Per-slice review:** for E1/E3/E7/E8 (and E2/E10 per plan §13), generate a review packet via §7.3 named `Stage_7__Review_Prompt.md`, set `active_slice_status = awaiting_review`, store the expected response path in `pending_external_review`, and `stage_gate_stop`. Questions: does the slice preserve the capabilities it claims? does it conflict with the skeletal baseline, ABC R0.2, Round D R0.2, or the plan? duplicate truth/policy/delivery/learning/UI? retired/old concepts reintroduced? aspirational capabilities preserved or completed? product-facing capability weakened or hidden without an architect decision? owner boundaries correct? do its golden fixtures make it testable? Lower-risk slices: continue without stopping unless the charter requires review or an architect_stop fires. --- # 17. Stage 8 — Patch slices after review **Plan step:** within 5–6. **Produces:** `Slice Patches/E##__Patched.md`. **Stop:** `conditional_stop`. **Prompt CC follows:** ```text STAGE 8 — Patch slice after review. Set RUN_STATE.active_slice_status = patching. Read: the slice draft; the review response(s) (Will / Codex / red-team). If a per-stage response folder exists, consolidate all files in it. 1. Build a finding-adjudication table: finding_id | review_source | finding_type (BUG/GAP/SUGGESTION/CONFIRMED) | disposition (accepted / accepted_with_mods / rejected / deferred) | reason | affected_sections | patch_ref | architect_decision_ref. 2. Patch the slice draft per the accepted findings. 3. Update the Supersession Matrix / Capability / Overlap / Decision Queue rows the review changes; if two rows now conflict, log it in the Conflict Register before either is overwritten (plan §10). 4. Update golden fixtures and lints if the review changed them. 5. Save to DOC80 Target Baseline/Slice Patches/__Patched.md. 6. Update the slice ledger, master ledger, and RUN_STATE.md; set active_slice_status = approved and last_completed_slice = . 7. If the review raises a plan-level issue or changes the skeletal architecture / owner map / retired-name table / object families, raise an architect_stop. ``` `conditional_stop` if a slice review changes the skeletal architecture, owner map, retired-name table, or object families. Otherwise continue to the next slice or to Stage 9. --- # 18. Stage 9 — Cross-slice integration checks **Plan step:** 6 (plan §17). **Produces:** `Lint Reports/Cross_Slice_Lint_Report.md`, `Fixture Reports/Cross_Slice_Fixture_Report.md`. **Stop:** `conditional_stop` (Will if any critical lint fails). A lint is not "passed" by assertion. For every lint Claude Code records the concrete check it ran and its evidence. **Prompt CC follows:** ```text STAGE 9 — Cross-slice integration checks. Read: all approved/patched slice drafts; Supersession_Matrix.md; Source_Section_Disposition.md; Capability_Inventory.md; Overlap_Resolution.md; Golden_Scenario_Fixtures.md; Mocked_Upstream_Outputs.md; OP_A_Candidate_Disposition.md; the plan §§14, 17. Run the full plan §17 lint suite. For EACH lint, record in the lint report: the lint id, the concrete check performed, the evidence (counts, the specific rows or names inspected), and pass / fail / waived. A bare "pass" with no evidence is itself a failure. Method guidance by category: - Ledger consistency (§17.1): cross-check the named ledger sections — every deferred_completion row has a completion record; every architect_decision_ref resolves to a real queue item; every tiered-capability change has a preservation proof. - Supersession (§17.2): extract every type/schema/concept name used across the slice drafts; cross-reference against Supersession Matrix canonical names and each slice's declared schemas; flag any used-but-undeclared name, retired name outside allowed context, local redefinition, or dual-running family. - Source-section (§17.3): every frozen source section has a disposition; no absorbed row without a target; no rejected row without a reason. - Policy/scope/UI from Round D (§17.4): structural checks against the Round D rules — no bare render action, no visible action without a command/route/ no-op, no reference-only item carrying a substantive summary. - Fixture (§17.5): every GoldenScenarioRecord has expected outcomes and a slice mapping; run each fixture at its gate level and record the result. Cross-slice fixtures may use mocked upstream outputs from Mocked_Upstream_Outputs.md — verify each mock's hash and contract match; final-switchover fixtures may not use mocks. Save Cross_Slice_Lint_Report.md and Cross_Slice_Fixture_Report.md. Update the ledger (Fixture / Lint Status Index, MemoryCoordinationTrace Coverage Index) and RUN_STATE.md. ``` `conditional_stop` if any blocking-severity lint or fixture fails: stop and report. Otherwise continue when Will approves assembly. --- # 19. Stage 10 — Assemble DOC80 draft **Plan step:** pre-7. **Produces:** `Final Rebuild/DOC80_Memory_Control_Plane_Spec_Draft.md`, `Final Rebuild/Final_Integration_Review_Prompt.md`. **Review:** red-team mandatory. **Stop:** `stage_gate_stop`. **Prompt CC follows:** ```text STAGE 10 — Assemble the DOC80 draft. Read: all approved/patched slice drafts; the skeletal baseline; the Stage 9 lint and fixture reports; the plan §19. Assemble Final Rebuild/DOC80_Memory_Control_Plane_Spec_Draft.md: 1. Preserve the section map from the approved skeletal baseline unless a recorded decision changed it. 2. Use approved canonical names from the Supersession Matrix; no retired names except in lineage/supersession sections. 3. Include owner boundaries, schemas, invariants, lints, fixtures, degraded states, proof chains, and UI/Inspector contracts. 4. Include the external owner landing table and the source/target/supersession/ capability appendix references. 5. Do NOT claim any old spec is superseded — that waits for Stage 11. Then create Final Rebuild/Final_Integration_Review_Prompt.md as a red-team packet (use the §7.3 template) covering: capability preservation and completion; old/new name reconciliation; absence of duplicate truth/policy/delivery/learning/ UI systems; owner boundaries with all adjacent docs; clean buildable knowledge objects; A–E red-team findings preserved or explicitly rejected/deferred; aspirational capabilities preserved or given completion obligations; lints/fixtures real and non-phantom; whether this can become the active DOC80 baseline. Update the ledger and RUN_STATE.md. ``` `stage_gate_stop`: Will routes the red-team review. After responses arrive, §21 processes them — including the finding-adjudication table written to `Final Rebuild/Final_Integration_Adjudication.md` — then Stage 11. --- # 20. Stage 11 — Final switchover proof **Plan step:** 7 (plan §19). **Produces:** `Final Rebuild/DOC80_Final_Switchover_Proof.md`. **Review:** Will mandatory, always. **Stop:** `stage_gate_stop`. **Prompt CC follows:** ```text STAGE 11 — Final switchover proof. Create Final Rebuild/DOC80_Final_Switchover_Proof.md demonstrating each item of the plan §19 final acceptance standard, point by point, with evidence: source-freeze coverage; every source section dispositioned; every named type/enum/schema/concept has a supersession row; every load-bearing/crown-jewel capability preserved, redesigned-with-proof, deferred, or rejected by decision; aspirational capabilities have completion records; Conflict Register has no unresolved blockers; Decision Queue has no unresolved stop items; golden fixtures pass at gate level WITHOUT mocked upstream outputs; lints pass or have LintWaiverRecords; MemoryCoordinationTrace proof gates pass; OP-A candidate dispositions exist for all accepted cross-doc obligations; no old/new duplicate concept families remain live; every final-prompt/injection/learning path has proof; every slice records an improvement or preserve-as-is rationale; every material source concept traces to a retained / redesigned / federated / deferred / parked / retired status. End with a DOC80 status recommendation: active_target_baseline / operative / needs_patch. State exactly which old files would be superseded, retained, or archived — but do not perform any archival; that is Will's decision. Update the ledger and RUN_STATE.md. ``` Always `stage_gate_stop`. Will approves the final status and any switchover. --- # 21. Review-Processing Routine (generic — replaces bespoke 1R / 5R) Whenever a stage produced a review packet and a response has arrived (controller §4 step 4), Claude Code runs this routine for that stage **before** advancing. ```text REVIEW-PROCESSING ROUTINE — Stage (or Stage 7 / SLICE_ID). Input: the Stage artifact(s); the response file(s). If a per-stage folder exists (e.g. Reviews/Red Team Responses/Stage_/Claude.md, GPT.md, Gemini.md), consolidate ALL files in it; process every reviewer's response before advancing. 1. Build a finding-adjudication table: finding_id | review_source | finding_type (BUG/GAP/SUGGESTION/CONFIRMED) | disposition (accepted / accepted_with_mods / rejected / deferred) | reason | affected_sections | patch_ref | architect_decision_ref For Stage 10, save this table to Final Rebuild/Final_Integration_Adjudication.md. For other stages, record it in the stage's ledger fragment. 2. Patch the Stage artifact(s) only per accepted / accepted_with_mods findings. Do not make new final inclusion decisions. A rejected or deferred finding still gets a row and a reason — nothing is silently dropped. 3. Where reviewers dispute a classification, log it in the Conflict / Disagreement Register (plan §10) before changing any row. 4. Update the master ledger and RUN_STATE.md (stage_status -> approved or awaiting_will_approval as appropriate). 5. Summarize the adjudication in the next Stop Gate Report. 6. If a review raises a plan-level issue or changes skeletal architecture, owner map, retired-name table, or object families, raise an architect_stop. Then continue forward from Stage per the Stage Index. ``` --- # 22. Git handling Claude Code creates files under `Memory Rebuild/` as part of normal execution — that is pre-authorized by Will commissioning this process. It does **not** commit unless Will explicitly authorizes commits, and **never** pushes without an explicit instruction. ```text If Will has authorized commits, after each completed stage or approved patch: git status --short git add git commit -m "" Never git push unless Will explicitly says to push. ``` Every Stop Gate Report states, in its COMMIT block, whether commits are authorized, what was committed (if anything), and the recommended commit message. Suggested messages: "Initialize DOC80 memory rebuild ledger and run state", "Create DOC80 source registry", "Add DOC80 source and target freeze", "Add DOC80 section dispositions and capability inventory", "Add DOC80 supersession matrix, overlap, and decision queue", "Draft skeletal DOC80 target baseline", "Add DOC80 slice charters, golden fixtures, and mock register", "Draft DOC80 slice ", "Add DOC80 cross-slice lint and fixture reports", "Assemble DOC80 Memory Control Plane draft", "Add DOC80 final switchover proof". If GitHub/MCP automation is later enabled, the same review-packet-and-response protocol applies; review gates and decision tiers do not change. --- # 23. Quick reference **Mandatory stage-gate stops:** end of Stages 1, 2, 3, 4, 5, 6, 10, 11; high-risk slice drafts in Stage 7 (E1, E2, E3, E7, E8, E10 per plan §13). **Conditional stops:** Stage 2 (missing target file / uncertain source set), Stage 8 (review changes architecture), Stage 9 (a blocking lint or fixture fails). **Immediate `architect_stop`:** any plan §11.3 condition; a genuine substantive plan contradiction; repo/remote wrong at Stage 0; a `RUN_STATE.md`↔ledger desync; a Stage 5 skeletal finding that genuinely contradicts the seeded spec-family / owner-doc decisions. **The one rule for Will:** paste the resume prompt (§1) at the start of every session. Read the Stop Gate Report, do the numbered "What you do now," re-paste the resume prompt. Nothing else is procedure.