ELNOR REPO READER TEXT MIRROR Original path: Active Working and Red Team/Instructions and Prompts/DOC80_Claude_Code_Master_Execution_Runbook_v1_0.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.0 **Purpose.** This is the one-shot instruction file for Claude Code to run the DOC80 / Memory Control Plane rebuild process. It tells Claude Code what to do, in what order, which prompts to follow, which files/folders to create, where to save outputs, when to self-audit, when to prepare Codex/secondary-review packets, and when to stop for Will. **Status.** Execution runbook. It does not replace the active flattening plan. The active flattening plan is the governing rule source. This runbook operationalizes it. **Primary governing plan:** ```text Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md ``` **Repo root expected by default:** ```text /Users/OpenClaw1/Elnor/Elnor Specs ``` **Primary current specs directory:** ```text /Users/OpenClaw1/Elnor/Elnor Specs/Current Specs ``` **Memory rebuild workspace:** ```text /Users/OpenClaw1/Elnor/Elnor Specs/Memory Rebuild ``` --- # 0. One-shot instruction for Claude Code Will should paste this instruction to Claude Code together with this runbook, or place this runbook in the repo and tell Claude Code to read it. ```text You are Claude Code working in Will's ELNOR specs Git repository. Read and follow: Memory Rebuild/Flattening/Prompts and Instructions/DOC80_Claude_Code_Master_Execution_Runbook.md The active process rules are in: Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md Execute the runbook in order. Create folders and files as needed. Do not ask Will to manage the process manually. Stop only at explicit STOP_FOR_WILL gates, architect_stop conditions, or when the runbook instructs you to request external red-team/Codex review. Before doing any work, verify the git root and repo status. Do not move, delete, rename, or rewrite source specs unless this runbook explicitly authorizes it. Do not silently change the active flattening plan. Treat the plan as rules and the execution ledger as mutable state. At each stop gate, tell Will exactly: 1. what you completed; 2. what files you created/updated; 3. what review packet, if any, is ready; 4. the exact prompt Will should send to Codex or red-team windows; 5. whether you recommend proceeding. ``` --- # 1. Core execution principles Claude Code must follow these principles throughout. ## 1.1 Plan versus ledger The active flattening plan contains the rules. Claude Code may not silently edit it. If the plan itself appears wrong, incomplete, or contradictory, Claude Code must create an architect_stop item and stop. The execution ledger contains mutable state. Claude Code updates it continuously. ## 1.2 No hidden destructive work Claude Code must not move, delete, rename, rewrite, merge, archive, or reclassify source specs unless the current stage explicitly authorizes it and Will has approved the relevant decision. The first several stages are inventory and classification only. ## 1.3 No final inclusion decisions during inventory The Source Registry and early inventories do not decide what goes into DOC80. They only identify what exists and why it may matter. ## 1.4 Preserve valuable aspiration Aspirational, incomplete, or old material is not disposable. If it appears valuable, preserve it as a capability-mining source, aspirational completion candidate, parked future decision, or archive lineage item. ## 1.5 Overlap is design evidence When old specs overlap the DOC80 target framework, Claude Code must not merely choose one. It must record whether the overlap indicates: ```text same thing duplicated; partial versions of a stronger unified mechanism; old mechanism stronger than new target; new framework fixes old bug but risks losing old capability; old object should become edge/function/static table/projection; owner-boundary conflict; false overlap / terminology only. ``` ## 1.6 Batch Will's decisions Do not interrupt Will with many small questions. Batch product-facing and architecture-facing questions into decision packets unless an immediate architect_stop condition applies. ## 1.7 Stop conditions Stop immediately if any of these occur: ```text policy/privacy/firewall change; durable truth ownership change; new canonical object family; final-prompt/injection architecture change; EC/DOC72/DOC73/DOC24/KDA/BDSM/DOC20/DOC23 owner-boundary conflict; deletion/downgrade of a crown-jewel or load-bearing capability; uncertain source classification that blocks source freeze; plan contradiction; missing required target-freeze file; unsafe default with no safe fallback. ``` --- # 2. Required folder structure Claude Code must create missing folders under `Memory Rebuild/` as needed. Use these folder names unless the repo already has equivalent names. ```text Memory Rebuild/ Review Packs/ Flattening/ Current Plan/ Prompts and Instructions/ Source Registry/ Source Freeze/ Target Freeze/ Execution Ledger/ Master/ Slice Ledgers/ Artifact Index/ Conflict Register/ Architect Decision Queue/ Lint Reports/ Fixture Reports/ OP-A Disposition/ Source Section Disposition/ Capability Inventory/ Supersession Matrix/ Overlap Resolution/ Aspirational Completion/ Reviews/ Codex Ready/ Codex Responses/ Red Team Ready/ Red Team Responses/ Patches/ DOC80 Target Baseline/ Skeletal Spec/ Import Graph/ Owner Map/ Retired Names/ Slice Charters/ Slice Drafts/ Slice Reviews/ Slice Patches/ Final Rebuild/ ``` --- # 3. Stage 0 — Boot, verify repo, read governing files ## Goal Establish that Claude Code is in the correct Git repo, read the active flattening plan, and create the initial execution ledger if it does not exist. ## Inputs ```text Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md Current Specs/ Memory Rebuild/ ``` ## Prompt CC follows ```text STAGE 0 — Boot and initialize. 1. Confirm git root: git rev-parse --show-toplevel 2. Confirm git status: git status --short 3. Confirm these paths exist, or create missing Memory Rebuild subfolders: - Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md - Memory Rebuild/Flattening/Execution Ledger/Master/ - Memory Rebuild/Flattening/Source Registry/ - Memory Rebuild/DOC80 Target Baseline/ 4. Read the active flattening plan in full enough to extract: - execution sequence; - required record types; - decision tiers; - source/target freeze requirements; - slice list E0–E10; - stop conditions; - acceptance standards. 5. Create or update: Memory Rebuild/Flattening/Execution Ledger/Master/FlatteningExecutionLedger.md 6. The ledger must initially include: - repo root; - active plan path; - active plan version from file header; - active stage = source_registry; - created/updated timestamp; - current git status summary; - list of required next outputs; - open architect_stop items, initially empty unless you find a blocker. 7. Do not edit any source spec. 8. Output a short status note for Will and proceed to Stage 1 unless you hit an architect_stop condition. ``` ## Expected outputs ```text Memory Rebuild/Flattening/Execution Ledger/Master/FlatteningExecutionLedger.md ``` ## Stop gate No stop unless a required governing file is missing or the repo root is wrong. --- # 4. Stage 1 — Complete Source Registry ## Goal Create the complete file-level inventory of the repo. This is broad and lightweight. It is not the detailed source-section disposition or capability inventory. ## What Source Registry means The Source Registry is the authoritative inventory of every document-like file in the repo that may matter to DOC80, the flattening plan, source/target freeze, capability inventory, supersession mapping, OP-A disposition, or future spec-completion work. It is not a merge plan. It is not a rewrite. It is not a final inclusion decision. It is not cleanup. ## Output ```text Memory Rebuild/Flattening/Source Registry/Source_Registry.md ``` ## Prompt CC follows ```text STAGE 1 — Create complete Source Registry. Read first: - Memory Rebuild/Flattening/Current Plan/Flatten_and_Unify_Plan.md - Memory Rebuild/Flattening/Execution Ledger/Master/FlatteningExecutionLedger.md Task: Create Memory Rebuild/Flattening/Source Registry/Source_Registry.md. Rules: 1. Do not move, delete, rename, rewrite, merge, archive, or reclassify any source files. 2. Do not edit any file except Source_Registry.md and the execution ledger. 3. Do not decide final inclusion in DOC80. 4. Inventory every document-like file in the repo. 5. If uncertain, include the file and mark it unknown / needs architect review. Document-like files include: - .md - .txt - .docx - .pdf - .rtf - .json / .jsonl if they are specs, registries, ledgers, trackers, schemas, configs, prompts, review artifacts, or operations documents - .jsx / .tsx / .ts only if they are canonical design/spec source files, UI reference artifacts, schemas, or architecture references - any file whose name suggests spec, addendum, proposal, review, tracker, registry, plan, patch, prompt, adjudication, source registry, obligation file, archive document, or lineage document Exclude: - .git/ - node_modules/ - build artifacts - cache folders - obvious binary junk - duplicate downloaded ZIPs unless intentional review-pack snapshots - images unless filename indicates canonical design/reference artifact For every included file, create a table row with columns: | file_path | document_name | apparent_owner_doc | version_or_date | folder_category | file_kind | status_guess | DOC80_relevance | relevance_reason | valuable_capabilities_or_concepts | overlaps_with_DOC80_or_flattening | recommended_disposition | architect_review_required | notes | status_guess values: - current_active - draft_active - accepted_proposal - operations_tracker - review_artifact - parked_future - archive_lineage - superseded_or_legacy - unknown DOC80_relevance values: - direct - adjacent_seam - capability_source - review_or_process_source - low - unknown recommended_disposition values: - include_in_source_freeze - adjacent_owner_boundary - capability_mining_source - aspirational_completion_candidate - review_context_only - parked_future_decision - archive_lineage_only - unknown_needs_architect_review Classification guidance: - If a file appears to define memory, knowledge, extraction, ingestion, source handling, policy, scope, injection, delivery, prompt assembly, rendering, learning, UI controls, search, procedures, graph behavior, task outputs, project/library/topic behavior, or user-facing memory behavior, mark architect_review_required = yes. - Aspirational but valuable material is not disposable. Use aspirational_completion_candidate or capability_mining_source. - Old material is not automatically irrelevant. - OP-A and operations trackers should be operations_tracker and review_or_process_source, not normal specs. - Review packs and red-team reviews should be review_artifact unless they contain accepted patch content or explicit obligations. - Do not use vague labels like “bloat.” - Do not decide deletion. After the table, add short sections: ## Potentially Direct DOC80 Inputs ## Adjacent Owner / Seam Sources ## Capability-Mining / Aspirational Completion Sources ## Parked / Future / Architect Decision Sources ## Archive / Lineage Sources ## Unclear / Needs Architect Review Update the execution ledger with: - path to Source_Registry.md; - count of files inventoried; - count of architect_review_required rows; - open uncertainties; - recommendation whether Will/Codex audit is needed. ``` ## Self-audit prompt After creating the registry, Claude Code must run this self-audit: ```text Audit Source_Registry.md for completeness. Checks: 1. Did I include every document-like file in the repo, including archive, old EC, DOC9, DOC3/addenda, DOC15 addenda, OP-A, review packs, and red-team materials? 2. Did I exclude only true non-document junk? 3. Did I mark uncertain items as unknown rather than omit them? 4. Did I avoid final inclusion decisions? 5. Did I avoid moving/deleting/editing source files? 6. Are all allowed enum values from the prompt used consistently? 7. Did I update the execution ledger? If any check fails, patch Source_Registry.md before proceeding. ``` ## Codex/secondary review packet Create: ```text Memory Rebuild/Flattening/Reviews/Codex Ready/Stage_1_Source_Registry_Review_Prompt.md ``` with this prompt: ```text Review Source_Registry.md for completeness and classification errors. Do not reclassify final inclusion. This is an inventory audit. Questions: 1. Are any document-like files missing? 2. Are any files obviously misclassified as current/archive/parked/review/etc.? 3. Are any high-value capability sources marked low relevance? 4. Are any old or aspirational files incorrectly treated as disposable? 5. Are OP-A, DOC72, DOC73, DOC24, DOC25, DOC15, DOC3, DOC20, DOC23, DOC8, DOC9, EC Core, PropA, KDA/BDSM, and review packs handled appropriately? 6. What rows require Will's architect review before source freeze? Return a concise audit report with row/path references and recommended corrections. ``` ## STOP_FOR_WILL Stop after Stage 1. Tell Will: ```text Source Registry created. Please optionally run Codex/secondary review using the prepared review prompt, or approve proceeding to Source/Target Freeze. ``` Do not proceed to Stage 2 until Will approves or provides audit feedback. --- # 5. Stage 1R — Process Source Registry review feedback ## Goal Incorporate Codex/secondary review feedback on the Source Registry. ## Prompt CC follows ```text STAGE 1R — Process Source Registry review feedback. Input: - Source_Registry.md - Codex/secondary review response, if provided by Will Task: 1. Read the review response. 2. Identify concrete corrections. 3. Patch Source_Registry.md only where the review clearly identifies missing files, bad classifications, or unclear notes. 4. Do not make final inclusion decisions. 5. If the review raises disputed classifications, add them to: Memory Rebuild/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md 6. Update the execution ledger. 7. Summarize changes for Will. ``` ## Stop gate If the review identifies major missing folders/files or unresolved classification disputes that block source freeze, stop and ask Will to decide. Otherwise proceed to Stage 2 when Will approves. --- # 6. Stage 2 — Source Freeze and Target Freeze ## Goal Create source freeze and target freeze records. This is the first formal freeze. It does not draft DOC80. ## Outputs ```text Memory Rebuild/Flattening/Source Freeze/Source_Freeze.md Memory Rebuild/Flattening/Target Freeze/Target_Freeze.md Memory Rebuild/Flattening/Execution Ledger/Master/FlatteningExecutionLedger.md ``` ## Prompt CC follows ```text STAGE 2 — Source Freeze and Target Freeze. Read: - Flatten_and_Unify_Plan.md - Source_Registry.md - FlatteningExecutionLedger.md - ABC Structural Patch R0.2, if present - Round D Policy/Scope/UI Micro-Patch R0.2, if present - DOC80 / DAMS V5 Spec Outline, if present - Source Context Primer, if present - Coverage Audit, if present Task A — Source Freeze: Create Memory Rebuild/Flattening/Source Freeze/Source_Freeze.md. For each source file selected from Source_Registry.md, create a SourceFreezeRecord with: - file_path - document_name - content_hash - source_status - normative_weight - source_role - included_in_source_freeze yes/no - reason - architect_review_required yes/no Do not exclude uncertain files merely because they are old or incomplete. If uncertain, include as unknown / architect review required, unless clearly irrelevant junk. Task B — Target Freeze: Create Memory Rebuild/Flattening/Target Freeze/Target_Freeze.md. Create TargetFreezeRecord rows for the active target package: - Flatten_and_Unify_Plan.md - ABC Structural Patch R0.2 - Round D Micro-Patch R0.2 - DOC80 / DAMS V5 Spec Outline - Concept Model and Canonical Knowledge Resolution - Worked Examples and Fixtures - Source Context Primer - Coverage Audit and Patch Log - any later approved target patch For each target file, include: - file_ref - target_role - availability_status - required_by_slices - blocks_if_missing - content_hash - notes Task C — Invalidation rule: Record that if any content_hash changes, dependent rows must become invalidated_pending_refresh. Task D — Update execution ledger: - source freeze path - target freeze path - counts - missing/blocking target files - architect decisions needed ``` ## Self-audit prompt ```text Audit Source_Freeze.md and Target_Freeze.md. Checks: 1. Does every source-freeze row point to a file in Source_Registry.md? 2. Do all frozen files have content hashes? 3. Are current/active, draft/active, accepted proposal, review, parked, and archive statuses differentiated? 4. Are target files either attached/path-resolvable or marked missing_must_attach? 5. Are missing blocking target files captured as architect_stop items? 6. Is the invalidation rule structurally recorded? 7. Did I avoid changing source files? ``` ## STOP_FOR_WILL Stop after Stage 2 if: - any required target file is missing; - any source status is highly uncertain; - the source set is unexpectedly huge or unexpectedly sparse; - Claude Code recommends excluding files Will may care about. Otherwise prepare a short approval packet and ask Will whether to proceed to Stage 3. --- # 7. Stage 3 — Source-section disposition and capability inventory ## Goal Create the first deep classification records: source-section dispositions and current-spec capability inventory. This is where detailed classification begins. ## Outputs ```text Memory Rebuild/Flattening/Source Section Disposition/Source_Section_Disposition.md Memory Rebuild/Flattening/Capability Inventory/Capability_Inventory.md ``` ## Prompt CC follows ```text STAGE 3 — Source-section disposition and capability inventory. Read: - active flattening plan - Source_Registry.md - Source_Freeze.md - Target_Freeze.md - current execution ledger Task: For all direct and adjacent DOC80-relevant files, create first-pass section-level and capability-level records. Part A — SourceSectionDispositionRecord: For each material section of each in-scope source file, create a row with: - source file - section ID / heading / line range if available - section summary - source status - normative weight - apparent function - target landing guess - disposition guess: absorbed / absorbed_with_redesign / federated_reference / external_owner_preserved / capability_mining / aspirational_completion / parked_future / archive_lineage / unresolved - capability refs - obligation refs, if visible - blocking_level: none / blocks_slice_exit / blocks_final_integration / future_version_only - architect_review_required yes/no - notes Part B — CurrentSpecCapabilityRecord: For each capability found, create a row with: - capability ID - source files/sections - plain-language capability description - product/user value - capability_status: actually_specified / partially_specified / implied_by_controls / aspirational_only - provisional capability_tier: crown_jewel_must_showcase / crown_jewel_preserve / load_bearing / important / supporting / unknown_load_bearing - target disposition guess: preserve / preserve_with_redesign / complete / defer_completion / retire_as_superseded / unknown - overlaps with DOC80 target - completion needs - architect review required Rules: - Untiered touched capabilities default to load_bearing or unknown_load_bearing until reviewed. - Aspirational valuable capabilities get completion records later; do not discard. - Product-facing capabilities require architect review. - Do not make final deletion decisions. Update execution ledger with counts and unresolved blockers. ``` ## Review packet Create: ```text Memory Rebuild/Flattening/Reviews/Codex Ready/Stage_3_Disposition_Capability_Review_Prompt.md ``` with: ```text Review Source_Section_Disposition.md and Capability_Inventory.md. Questions: 1. Are any source sections missing? 2. Are capabilities under-described or incorrectly tiered? 3. Are aspirational but valuable capabilities preserved as completion candidates? 4. Are any product-facing or crown-jewel capabilities at risk of silent downgrade? 5. Are any sections classified as archive/parked despite containing DOC80-relevant mechanisms? 6. Are any source-section disposition rows too final for a first pass? 7. What architect decisions must be batched before skeletal DOC80 drafting? ``` ## STOP_FOR_WILL Stop if the inventory surfaces major owner-boundary conflicts, major missing current specs, or many architect decisions. Otherwise ask Will whether to run review or proceed to Stage 4. --- # 8. Stage 4 — Supersession matrix, overlap resolution, and open decisions ## Goal Map old names/concepts to new names/concepts, prevent dual-running types, and preload known decisions. ## Outputs ```text Memory Rebuild/Flattening/Supersession Matrix/Supersession_Matrix.md Memory Rebuild/Flattening/Overlap Resolution/Overlap_Resolution.md Memory Rebuild/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md Memory Rebuild/Flattening/Aspirational Completion/Aspirational_Completion_Register.md ``` ## Prompt CC follows ```text STAGE 4 — Supersession matrix, overlap resolution, aspirational completion, and decision queue. Read: - active flattening plan - Source_Freeze.md - Target_Freeze.md - Source_Section_Disposition.md - Capability_Inventory.md - ABC R0.2 and Round D R0.2 target patches - Coverage Audit / Adjudication Delta / open issues, if present Task A — Supersession Matrix: Create Supersession_Matrix.md. For every named type, enum, schema, object, concept, product kind, policy object, scope object, prompt shell, and known old/new overlap, create a row with: - old_name - new_name / retained_name / retired_name - disposition_move using canonical DispositionMove vocabulary - approval_status - architect_decision_ref if approved - requires_local_data_migration - allowed_aliases - retired_name enforcement - preservation proof ref if required - notes Known names requiring explicit rows include at least: PremiseFamily, PremiseVariant, generic Claim, Assertion, AssertionVariant, ConsolidatedUnderstanding, CU/SourceSetSynthesis, ScopeMembrane, ScopeBoundary, PolicyMembraneDecision, MemoryPolicyDecision, EffectiveMemoryPolicy, WorkingStateEvent, IssueFrameUpdate, SearchAffordance, TopicLens, TopicCollectionDirective, ContextProduct, UserContextSurfacePlan, DAMS standalone ranking, Library/Corpus. Task B — Overlap Resolution: Create Overlap_Resolution.md. For each significant overlap, record: - overlap key - source concepts - overlap kind - disposition move - preservation rationale or semantic compression proof - lost/changed capabilities, if any - architect review required Task C — Aspirational Completion: Create Aspirational_Completion_Register.md. For each aspirational valuable capability, record: - source - value - missing pieces - minimum_completion_for_v5 - proposed target landing - owner - OP-A needed yes/no - architect review required Task D — Architect Decision Queue: Preload known open decisions from target patches, coverage audits, adjudication deltas, and the current inventory. Each row must have: - decision ID - tier: batch_for_architect or architect_stop - question in plain terms - options - recommended answer - affected slices - blocks_slices - default_if_no_response only if safe/non-blocking - status = open Rules: - Agents may not mark their own supersession rows as approved. - Every old/new overlapping concept gets a row. - Every source concept not accounted for triggers a lint later. - Any `intentionally_drop`, regardless of tier, requires architect queue and preservation proof. - For semantic_compression, require rule-by-rule coverage table. ``` ## Self-audit prompt ```text Audit Stage 4 outputs. Checks: 1. Are all known old/new type names represented in the Supersession Matrix? 2. Are any retired names still allowed without alias approval? 3. Did I create a row for every major overlap from the source/capability inventory? 4. Did I preserve aspirational valuable concepts as completion candidates? 5. Did I avoid approving my own supersession rows? 6. Are architect_stop items properly marked and blocking? 7. Are defaults limited to safe non-blocking actions? 8. Are there conflicts requiring the Conflict Register? ``` ## STOP_FOR_WILL Stop after Stage 4. Tell Will: - number of supersession rows; - number of unresolved architect decisions; - number of architect_stop items; - whether skeletal DOC80 can begin. Do not draft skeletal DOC80 until Will approves. --- # 9. Stage 5 — Skeletal DOC80 target baseline and import graph ## Goal Create the skeletal DOC80 target baseline before full slice drafting. This is not the full spec. It is the architecture skeleton. ## Outputs ```text Memory Rebuild/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md Memory Rebuild/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md Memory Rebuild/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md Memory Rebuild/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md ``` ## Prompt CC follows ```text STAGE 5 — Draft skeletal DOC80 target baseline and import graph. Read: - active flattening plan - 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 target patches - DOC80 outline Task: Draft a skeletal DOC80 / Memory Control Plane target baseline. The skeletal baseline must include: 1. DOC80 purpose and status. 2. What DOC80 owns. 3. What DOC80 does not own. 4. Owner boundaries with DOC72, DOC73, DOC25, DOC24, KDA, BDSM/DOC8, EC/PropA, DOC20, DOC23, DOC15, DOC11/OpenClaw, DOC1, DOC3. 5. Major object families: - Source / Evidence - Assertions / AssertionVariants / EvidenceSupportEdges - ConsolidatedUnderstandings and source-bound synthesis - Directives / Procedures / Standing procedures - Topics / TopicCollectionDirectives - Libraries / corpora / source collections - Episodes / IssueFrames / RecentActivity - Policy / Scope - Extraction spine - Context Products / DAMS / DOC24 delivery - Prompt shells / KDA rendering / final-prompt proof - Learning / BDSM / DOC8 - UI / Inspector / SearchAffordance 6. Import graph: what current docs/sections feed each DOC80 area. 7. Retired-name table from Supersession Matrix. 8. External owner landing table: what must remain in DOC72/DOC73/DOC24/DOC20/etc. 9. Open architect decisions blocking slice charters. 10. Explicit note that this is a skeletal target baseline, not final operative switchover. Also create DOC80_Import_Graph.md, DOC80_Owner_Map.md, and DOC80_Retired_Names.md. Do not draft full sections yet. Do not silently resolve architect_stop items. ``` ## Skeletal review packet Create: ```text Memory Rebuild/DOC80 Target Baseline/Slice Reviews/Skeletal_DOC80_Review_Prompt.md ``` with: ```text Review the skeletal DOC80 target baseline and import graph. Questions: 1. Does the skeleton correctly state what DOC80 owns and does not own? 2. Are owner boundaries with DOC72/DOC73/DOC25/DOC24/KDA/BDSM/EC/PropA/DOC20/DOC23/DOC15/DOC11/DOC1/DOC3 correct? 3. Are old names and retired names correctly handled? 4. Does the import graph preserve current-spec capabilities and aspirational completion candidates? 5. Are CUs, Directives, Procedures, Topics, Libraries, Assertions, IssueFrames, Episodes, Policy, Scope, Delivery, Learning, and UI all placed cleanly? 6. Does the skeleton avoid duplicate truth, duplicate policy, duplicate delivery, duplicate learning, and phantom UI systems? 7. What must be patched before slice drafting begins? ``` ## STOP_FOR_WILL Stop after skeletal DOC80 draft. Tell Will to review/red-team the skeleton. Do not approve slice charters until Will confirms the skeletal architecture. --- # 10. Stage 5R — Patch skeletal DOC80 after review ## Prompt CC follows ```text STAGE 5R — Patch skeletal DOC80 after review. Input: - skeletal DOC80 review responses from Will / red-team / Codex Task: 1. Read review responses. 2. Identify required patches. 3. Patch skeletal DOC80, import graph, owner map, and retired-name table. 4. Update Supersession Matrix / Architect Decision Queue if needed. 5. Do not proceed to slice charters unless Will confirms the skeleton. ``` ## Stop gate Stop if review identifies owner-boundary conflicts or duplicate-truth/policy/delivery systems. --- # 11. Stage 6 — Slice charters ## Goal Create slice charters for E0–E10 before drafting full slice text. ## Outputs ```text Memory Rebuild/DOC80 Target Baseline/Slice Charters/E0_... ... Memory Rebuild/DOC80 Target Baseline/Slice Charters/E10_... ``` ## Slice list Use the final flattening plan's dependency order. Default slice map: ```text E0 Cross-cutting contracts / import graph / proof spine E1 Scope and policy object declarations / boundary objects E2 Policy meet, disclosure meet, stamps, fail-closed validation E3 Canonical knowledge objects: Assertions, CUs, Evidence, Directives, Procedures, IssueFrames, NullResults E4 Source / Evidence / parse-quality and source-grounding contracts E5 Canonical Extraction Spine E6 Temporal / working-state / episodes / RecentActivity E7 Context Products + DAMS seam + DOC24 delivery plan E8 Prompt Shells + KDA render + final-prompt proof artifacts E9 Learning / DOC8 / BDSM integration E10 UI / Inspector / SearchAffordance / DOC20 landing contracts ``` If the active flattening plan defines a different map, follow the active plan and record any difference. ## Prompt CC follows ```text STAGE 6 — Create slice charters. Read: - active flattening plan - approved skeletal DOC80 baseline - DOC80 import graph - owner map - Source_Section_Disposition.md - Capability_Inventory.md - Supersession_Matrix.md - Overlap_Resolution.md - Architect_Decision_Queue.md For each slice E0–E10, create a SliceCharter file with: - slice ID and title - purpose - dependencies - source docs/sections to consume - target DOC80 sections to draft - owner boundaries - required imports - relevant supersession rows - relevant capability inventory rows - expected improvement_or_preserve_rationale - negative space: what this slice must not do - fixtures/lints applicable - OP-A candidate rows needed - unresolved architect decisions - required outputs - review requirement: none / Codex / red-team / Will approval Special rule: E1, E3, E7, and E8 require architect approval before drafting. Second-agent confirmation cannot substitute. Do not draft slice prose yet. ``` ## STOP_FOR_WILL Stop after slice charters. Tell Will: - which charters require approval; - whether any charters have architect_stop decisions; - recommendation for which slices can draft first. --- # 12. Stage 7 — Draft slices ## Goal Draft DOC80 slice text in dependency order. Do not draft everything in one uncontrolled pass. ## General prompt for each slice ```text STAGE 7 — Draft slice [SLICE_ID]. Read: - active flattening plan global rules - FlatteningExecutionLedger - approved skeletal DOC80 baseline - import graph - owner map - retired names table - Supersession Matrix index and relevant rows - this slice's approved SliceCharter - source files/sections listed in the charter - relevant capability inventory rows - relevant source-section disposition rows - relevant overlap-resolution rows - relevant fixtures/lints Task: Draft DOC80 slice [SLICE_ID] only. Requirements: 1. Preserve current-spec capabilities listed in the charter. 2. Preserve or complete valuable aspirational capabilities assigned to this slice. 3. Apply approved supersession names. Do not reintroduce retired names except as lineage references. 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 at least one substantive improvement or a positive preserve-as-is rationale. 7. Include normative rules, schemas, owner boundaries, degraded states, lints, and fixtures where required. 8. For every product-facing feature, state the user value and the real command/read-model/proof path if applicable. 9. If a needed decision is blocked, stop and add architect_stop. 10. Save output to: Memory Rebuild/DOC80 Target Baseline/Slice Drafts/[SLICE_ID]_[name]_Draft.md After drafting: - update the slice ledger fragment; - update the master ledger; - create a slice self-audit; - prepare the review prompt if the slice requires review. ``` ## Slice-specific notes ### E0 Focus on cross-cutting contracts, naming, import graph, proof spine, and no-dual-running types. Do not rewrite policy or extraction in detail. ### E1/E2 Scope and policy are lockstep. Scope identifies relation/boundary; policy decides capability/disclosure. Do not let scope emit allow/block/render/export/learn decisions. ### E3 Place all canonical knowledge objects. Include Assertions, AssertionVariants, AssertionRelations, Evidence, CUs, Directives, Procedures, IssueFrames, NullResults. Do not make Topics or Libraries truth stores. ### E4/E5 Use the Canonical Extraction Spine. Do not invent a parallel MemoryExtractionRun object. Reuse DOC72 intake, DOC73/DOC25 source machinery, EC writer, DOC1 write gate. ### E6 Episodes remember what happened. IssueFrames remember what we currently think. RecentActivity is orientation only, not evidence. ### E7/E8 Draft together or with tight cross-checking. Context Products, DAMS salience, DOC24 composition, KDA rendering, prompt shells, ContextPacketProof, and MemoryFlowCertificate are coupled. ### E9 Before drafting, reconcile actual DOC8 capabilities, BDSM contracts, consumer assumptions, missing learning engine capabilities, and phantom/aspirational assumptions. ### E10 DOC80 owns UI memory contracts; DOC20 owns implementation. Every visible control must map to EC command / route / degraded no-op / read-model refresh. Inspector must obey disclosure policy. ## Review prompt generated for each high-risk slice Create: ```text Memory Rebuild/DOC80 Target Baseline/Slice Reviews/[SLICE_ID]_Review_Prompt.md ``` with: ```text Review DOC80 slice [SLICE_ID] only. Questions: 1. Does this slice preserve the current-spec capabilities it claims to preserve? 2. Does it conflict with the skeletal DOC80 baseline, ABC R0.2, Round D R0.2, or the final flattening plan? 3. Does it create duplicate truth, policy, delivery, learning, or UI systems? 4. Are old concepts silently retained or reintroduced? 5. Are aspirational but valuable capabilities preserved or completed appropriately? 6. Are product-facing capabilities weakened, hidden, or deferred without architect decision? 7. Are owner boundaries with adjacent docs correct? 8. Do fixtures/lints make this slice testable? 9. Can this slice proceed, or what must be patched? ``` ## STOP_FOR_WILL Stop after drafting and self-auditing high-risk slices: ```text E1/E2 E3 E7/E8 E9 E10 ``` For lower-risk slices, stop only if the charter says review is required or an architect_stop is hit. --- # 13. Stage 8 — Patch slices after review ## Prompt CC follows ```text STAGE 8 — Patch slice after review. Input: - slice draft - review responses from Will / red-team / Codex Task: 1. Read review responses. 2. Identify accepted changes, rejected changes, and open questions. 3. Patch the slice draft. 4. Update supersession/capability/overlap/decision records if the review changes them. 5. Update fixtures/lints if needed. 6. Save patched slice to: Memory Rebuild/DOC80 Target Baseline/Slice Patches/[SLICE_ID]_[name]_Patched.md 7. Update ledger. 8. If review raises a plan-level issue, create architect_stop and stop. ``` ## Stop gate Stop if a slice review changes the skeletal architecture, owner map, retired-name table, or target object families. --- # 14. Stage 9 — Cross-slice integration checks ## Goal Run integration lints and fixtures before final DOC80 assembly. ## Prompt CC follows ```text STAGE 9 — Cross-slice integration checks. Read: - all approved/patched slice drafts - Supersession Matrix - Source Section Disposition - Capability Inventory - Overlap Resolution - Fixture records - Lint list - OP-A disposition candidates Run structured checks: 1. No dangling type references. 2. No retired names used outside lineage/alias contexts. 3. No duplicate truth store. 4. No duplicate policy evaluator. 5. No duplicate prompt assembler. 6. No duplicate learning engine. 7. No phantom UI controls. 8. Every visible action has command/route/degraded no-op/read-model refresh. 9. Every source section has a disposition. 10. Every load-bearing capability has preservation/completion/disposition proof. 11. Every intentionally dropped capability has architect decision. 12. Every aspirational valuable capability has completion/defer disposition. 13. Every OP-A relevant obligation has proposed disposition. 14. Every context product has proof/render/learning path. 15. Final-prompt proof and learning gates are intact. 16. Policy/scope/UI disclosure gates are intact. 17. Hot-path constraints are not violated. 18. Golden fixtures have expected outcomes. Save lint report to: Memory Rebuild/Flattening/Execution Ledger/Lint Reports/Cross_Slice_Lint_Report.md Save fixture report to: Memory Rebuild/Flattening/Execution Ledger/Fixture Reports/Cross_Slice_Fixture_Report.md ``` ## STOP_FOR_WILL Stop if any critical lint fails. Otherwise proceed to final assembly when Will approves. --- # 15. Stage 10 — Assemble DOC80 target baseline / active spec draft ## Goal Assemble the approved slices into the DOC80 target-baseline spec draft. ## Output ```text Memory Rebuild/Final Rebuild/DOC80_Memory_Control_Plane_Spec_Draft.md ``` ## Prompt CC follows ```text STAGE 10 — Assemble DOC80 spec draft. Read approved slice drafts and cross-slice reports. Create: Memory Rebuild/Final Rebuild/DOC80_Memory_Control_Plane_Spec_Draft.md Requirements: 1. Preserve section order from skeletal DOC80 baseline unless a recorded decision changed it. 2. Use approved canonical names from Supersession Matrix. 3. Do not include retired names except in lineage/supersession sections. 4. Include owner boundaries, schemas, invariants, lints, fixtures, degraded states, proof chains, and UI/Inspector contracts. 5. Include external owner landing table. 6. Include source/target/supersession/capability appendix references. 7. Do not claim old specs are superseded yet unless final switchover proof passes. ``` ## Final red-team packet Create: ```text Memory Rebuild/Final Rebuild/Final_Integration_Review_Prompt.md ``` with: ```text Review the assembled DOC80 Memory Control Plane spec draft for final integration. Questions: 1. Does DOC80 preserve and complete the current-spec capabilities identified in the flattening records? 2. Are all old/new concept names reconciled? 3. Are there duplicate truth, policy, delivery, learning, or UI systems? 4. Are owner boundaries with DOC72/DOC73/DOC25/DOC24/KDA/BDSM/EC/PropA/DOC20/DOC23/DOC15/DOC11/DOC1/DOC3 correct? 5. Are Topic, Library, CU, Assertion, Directive, Procedure, IssueFrame, Episode, Policy, Scope, Extraction, Context Product, Prompt Shell, and Learning concepts clean and buildable? 6. Are red-team findings from A/B/C/D/E preserved or explicitly rejected/deferred? 7. Are aspirational valuable capabilities preserved or given completion obligations? 8. Are lints/fixtures/pass-fail checks real and non-phantom? 9. Can this become the active DOC80 target baseline, or what blocks it? ``` ## STOP_FOR_WILL Stop after assembling the draft and creating final review prompt. Will decides red-team routing. --- # 16. Stage 11 — Final switchover proof This stage occurs only after final integration review and patching. ## Prompt CC follows ```text STAGE 11 — Final switchover proof. Create: Memory Rebuild/Final Rebuild/DOC80_Final_Switchover_Proof.md The proof must show: 1. Source coverage complete. 2. Source-section disposition complete. 3. Capability inventory resolved. 4. Supersession matrix complete. 5. Retired names absent or allowed as lineage aliases only. 6. OP-A obligations mapped. 7. Lints pass or have architect-approved LintWaiverRecord. 8. Golden fixtures pass without mocked upstream outputs. 9. No duplicate truth/policy/delivery/learning/UI systems. 10. External owner landing table complete. 11. Architect decisions closed or deferred with accepted consequence. 12. DOC80 status recommendation: active_target_baseline / operative / needs_patch. ``` ## STOP_FOR_WILL Always stop. Will approves final status. --- # 17. Git handling Claude Code should not assume GitHub MCP/Composio write access unless Will explicitly authorizes it. ## If Git writes are authorized After each completed stage or major approved patch: ```text git status --short git add git commit -m "" ``` Do not push unless Will explicitly says to push. Suggested commit messages: ```text Initialize DOC80 memory rebuild ledger Create DOC80 source registry Add DOC80 source and target freeze records Add DOC80 capability inventory and source dispositions Add DOC80 supersession matrix and decision queue Draft skeletal DOC80 target baseline Add DOC80 slice charters Draft DOC80 slice E3 canonical knowledge objects Assemble DOC80 memory control plane draft ``` ## If Git writes are not authorized Claude Code still creates files. At each stop gate it tells Will: ```text Recommended commit message: ``` --- # 18. What Will should not have to manage manually Claude Code should handle: ```text folder creation; file creation; prompt generation; ledger updates; self-audits; review packet preparation; record tables; slice charters; slice drafts; patch integration; final review packet creation. ``` Will should only need to: ```text approve stop gates; run optional external red-team/Codex reviews when requested; return review responses; answer batched architect decisions; approve final switchover. ``` --- # 19. Quick stop-gate map Claude Code must stop after: ```text Stage 1 — Source Registry complete. Stage 2 — Source/Target Freeze if blockers or uncertainties exist. Stage 4 — Supersession/Overlap/Decision Queue complete. Stage 5 — Skeletal DOC80 target baseline complete. Stage 6 — Slice charters complete. High-risk slice drafts: E1/E2, E3, E7/E8, E9, E10. Stage 9 — Cross-slice lints if critical failures. Stage 10 — Assembled DOC80 draft complete. Stage 11 — Final switchover proof complete. Any architect_stop condition. ``` --- # 20. First next step Claude Code should begin with Stage 0 and Stage 1. The first actual deliverable is: ```text Memory Rebuild/Flattening/Source Registry/Source_Registry.md ``` Do not start source-section disposition, capability inventory, supersession matrix, skeletal DOC80, or slice drafting until Source Registry has been reviewed or approved.