E0_Drafting_Commission_Claude_Code.md
Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Drafting_Commission_Claude_Code.md
ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Drafting_Commission_Claude_Code.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # E0 Charter Draft — Commission Prompt for Claude Code **Repository:** github.com/wbrody/Elnor-Specs — branch `main` **Session type:** Fresh Claude Code session in the repo working directory. **Authority:** Will Brody (architect). All architect decisions for this draft are pre-resolved upstream (Stage 4 / Stage 5R / Stage 5R2 / Stage 5R3 Pass 1 + 2 + 2c). You do NOT need to ask Will mid-draft except where this prompt explicitly says so. **Mission:** produce a complete first draft of the DOC80 Memory Control Plane Core charter (E0). The draft becomes the operative DOC80 member spec after Will's review + red-team rounds + ratification. **You are writing the foundation of the DOC80 family.** Every other charter (E1 through E10 + E_org) will bind to the contracts you draft here. --- ## 1. Read first — background on ELNOR and the project (mandatory orientation) You are joining a multi-stage spec-rebuilding project mid-flight. The 2-minute orientation: ### 1.1 ELNOR in one paragraph ELNOR is a **local-first AI orchestration platform** built on OpenClaw (Node.js/npm), running on a single M4 Pro MacBook under an isolated macOS user account. The architect is Will Brody, a securities litigator who built ELNOR as a domain-agnostic personal-OS platform with legal-litigation as one profile. ELNOR is in the **spec completion / red-team / design-hardening phase** — nothing is implemented yet. The goal is specs complete enough that future implementation cannot drift, guess, or recreate "phantom button / phantom memory / phantom wiring" failures Will has experienced with other AI tools. ### 1.2 The three-system architecture - **Knowledge** (the brain): DOC72 (graph store), DOC73 (PBE — Positronic Brain Enhancement), DOC25 (source ingestion), DOC1 (Write Gate), DOC8 (legacy learning — capability-mining only, NOT a runtime owner) - **Operations** (the nervous system): DOC24 (packet assembly), DOC15 (CIL), DOC10/DOC11 (final runtime), DOC4 - **Body** (the muscles): DOC23 (tasks), DOC12/16/18/20 (UI), DOC14 (CANDOR), DOC17 (Q dashboard) Plus the new **DOC80 family** (the memory control plane being flattened): DOC80 (core — what you are drafting), DOC81 (scope/policy), DOC82 (knowledge/source/evidence), DOC83 (extraction/temporal), DOC84 (delivery/prompt/proof, contains DAMS substrate), DOC85 (learning architecture), DOC86 (UI/Inspector/Search), DOC87 (organization/membership). Family member count = 8 per ADQ-220. ### 1.3 Key terms you will encounter | Term | Meaning | |------|---------| | **EC** | Elnor Core — deterministic orchestrator, sole durable writer. Treats as `dependency_status = partial / moving` per ECSeamContract (OPA-031). | | **Q** | Q Dashboard — Electron desktop UI; React + Vite + TypeScript + Tailwind | | **OpenClaw** | Native runtime; owns native prompt/session/workspace truth | | **PBE** | Positronic Brain Enhancement — DOC73, additive layer over DOC72 | | **CU** | ConsolidatedUnderstanding — DOC73 source-bound synthesis (NOT canonical reusable truth per ADQ-219) | | **BDSM** | Big Dynamic Satisfaction Machine — DOC24 Addendum A V6.4/V6.5, self-learning utility ledger. `dependency_status = partial` per ADQ-221. | | **KDA** | Knowledge Delivery Architecture — DOC24 Addendum B R2 | | **DAMS** | Substrate inside DOC84 per ADQ-210 — NOT an independent owner doc | | **DeliveryDirective** | Three-dim tag: primary_tag + hedge_mode + force_level. ONE tag vocabulary, no second prompt-control language | | **PropA** | MultiDoc Proposal A R6.3 — Knowledge Pipeline Sensitivity & Self-Improvement; whole-section retargeted to DOC81 in OP-A V4 | ### 1.4 The flattening project — where you sit in the timeline | Stage | Status | What it produced | |-------|--------|------------------| | Stage 0–3 | Closed | Plan + Codex adjudication + 41 ADQs resolved | | Stage 4 | Closed | OP-A Candidate Disposition + seed decisions | | Stage 5 | Closed | Skeletal Target Baseline + Owner Map + Import Graph + Retired Names | | Stage 5R | Closed | DOC87 added (8th member); B1-B9 patches; ADQ-220 / ADQ-221 resolved | | Stage 5R2 | Closed | 12 must-fix items + 14 fold-ins (§10 of Skeletal); 22 additional fold-ins at 5R2b (§11) | | Stage 5R2c | Closed | 13 prose-residual cleanup fixes | | Stage 5R3 Pass 0–2 + 2c | Closed | OP-A V4 published; 117 rows retargeted to DOC80 family; ADQ-PASS2-01/-02 resolved | | **Stage 6 — Charter authoring** | **OPEN — you are at E0, the first charter** | DOC80 family member specs | | Stage 7 | Future | Schema bodies for NAMED concepts (MemoryMutationEnvelope, MemoryProvenanceGraph, etc.) | | Stage 8 | Future | Preservation proofs + fixtures | | Stage 9 | Future | Lints | ### 1.5 Will's working style (binding for your draft) - **No phantom features.** Every contract you specify must trace to either (a) an ADQ resolution, (b) a Skeletal §10/§11 fold-in, (c) an Owner Map row, or (d) an explicit Pass 1 architect decision. If you can't trace it, flag it `OPEN_FOR_ARCHITECT_REVIEW`, do not invent it. - **Excellence + completeness over brevity.** Will values exhaustive coverage. A draft that misses a target is worse than one that overshoots. - **Cite section numbers.** Every claim should cite its source: Skeletal §10.5, Owner Map line 144, ADQ-310, Stage 5R2 synthesis #9, etc. - **Comprehensive spec-level solutions over problem identification.** Write TS schemas, lint names, fixture names, algorithm pseudocode — not "we should think about X." - **Paste-ready code over descriptions.** When you specify a contract, write the TypeScript interface or schema, not "an interface with a few fields." - **Three perspectives simultaneously: Coder + Product Designer + Integration Architect.** Schemas must be implementable, defensible to users, and wire correctly across the 8 family members. - **Type findings as BUG / GAP / SUGGESTION / CONFIRMED** if you surface issues mid-draft (don't just bury them). - **No version-suffix sprawl in filenames within charter folder.** Your output file is `DOC80_Core_Charter_Draft.md` (no version). Git history is the version record for charter work. ### 1.6 Will's failure modes to actively guard against These are anti-patterns Will has fought repeatedly across the spec. Every section you draft should pass these guards: - **Phantom buttons** — UI controls or commands with no real backend route. Don't specify a contract field unless it's backed by a real producer/consumer pair. - **Phantom memories** — memory schemas that get written but never read, or read but never written. - **Over-aggressive ingestion** — schemas that suck in everything without policy gating. - **Silent auto-promotion** — promoting weak signals to canonical truth without explicit gating. - **Missing empty / degraded / error states** — every contract needs the unhappy paths specified. - **Under-specified schemas** — every field needs type, owner, lifecycle, and "may not / must" semantics. - **Cross-doc seams that sound good but aren't wired** — every cross-member reference needs an actual contract surface, not a vibe. - **Magical context behavior** — context products must be deterministic from named inputs, not "the system figures it out." - **Unregistered content types** — every content type passing through DOC80 must be in the registry (cf. DOC20 §6.18.2 lesson). - **Living memory eroding static facts** — durable Assertions don't get silently mutated by orientation rollups. - **Silent degradation** — if a substrate (BDSM, DAMS) is partial, every contract that depends on it states the partial-coverage behavior explicitly. --- ## 2. Read second — the operative DOC80 family architecture (your direct input material) In priority order. All paths repo-relative. ### 2.1 Charter-folder files (read first; this is your immediate context) 1. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/README.md`** — folder index + state. 2. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Opening_Brief.md`** — scope, 20 draft targets, exit criteria, drafting approach. **This is the load-bearing brief.** 3. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Input_Deck.md`** — extracted input from the Stage 6 charter index — 8 ADQs + 14 skeletal §10/§11 fold-ins + open seams. ### 2.2 DOC80 baseline files (mandatory — the architecture you're formalizing) 4. **`Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`** — the family skeletal architecture. **§10 (Stage 5R2 fold-ins) and §11 (Stage 5R2b additions) are your direct charter input material.** Read these sections in full; cite them when you draft. 5. **`Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`** — schema/object ownership truth across the 8-member family + external owners. Cite line numbers when binding contracts. 6. **`Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md`** — 4-edge-kind dependency graph (schema_import / runtime_instance_flow / command_or_control_flow / storage_or_execution_flow). Your contracts must respect this graph. 7. **`Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md`** — lineage of retired schemas; ensure you're not reintroducing retired names. ### 2.3 Decision authority (read before drafting any contract) 8. **`Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md`** — 47 ADQs (46 resolved + 1 open). The 8 ADQs pinned to E0 (per Input Deck §"ADQ rows pinned to E0") are your direct authority. Other ADQs may surface as cross-cutting. 9. **`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`** — Will's 13 Stage 5R3 Pass 1 resolutions. These are pre-applied to OP-A V4 already; reference for completeness. ### 2.4 Operational state (read for cross-references) 10. **`OP-A and Operations and Trackers/OPA_V4.md`** — operative cross-doc obligation tracker. 0 rows directly target DOC80 core, but DOC80 contracts are upstream of many DOC80-family obligations. Skim §6 for the obligations targeting DOC81/82/84/85/87 to understand what your contracts must support. 11. **`Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md`** — 49 SM rows. SM-050 (proof spine), SM-051 (ContextPacketProof), SM-100 (MemoryCoordinationTrace), SM-213 (ReasonCode registry) are direct E0 input. 12. **`Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md`** — 8 resolved conflicts. None pinned to E0 exclusively; review for cross-cutting. ### 2.5 Background reference (read only if disoriented) 13. **`CLAUDE.md`** at repo root — project instructions for AI agents (defines Will's preferences, file conventions, etc.). 14. **`OP-A and Operations and Trackers/MASTER_SPEC_DOCUMENT_LIST.md`** — what specs exist + their official status (R3.62 latest). 15. **`Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md`** — the synthesis Pass 2 just reviewed against. Shows what good standards look like and what gets caught. 16. **`Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`** — the governing plan. §12 has the slice list; §18 has the golden-scenario end-to-end test. --- ## 3. What to produce (the deliverable) A single markdown file: **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md`** This is the operative draft of the DOC80 Core member spec. It must cover all 20 draft targets in §"Draft targets" of the `Charter_Opening_Brief.md`. After Will's review + red-team rounds + ratification, this draft becomes the operative DOC80 spec. ### 3.1 Required structure (the document outline) The draft must follow this section structure (deviation allowed if you justify it; default is to keep this skeleton): ``` # DOC80 — Memory Control Plane Core (Stage 6 E0 Charter Draft R1) ## §1. Identity, scope, and non-goals §1.1 Member identity (family member 1 of 8) §1.2 Family naming convention (ADQ-210) §1.3 V5 non-goal (Skeletal §10.1) §1.4 EC manual-deletion + unreachable=uninjectable (Skeletal §10.2) §1.5 Consistency model (Skeletal §11.2) ## §2. Cross-cutting registries §2.1 ReasonCode registry (ADQ-310) §2.2 Domain profile registry + fallback (ADQ-313) §2.3 PromptShellRegistry + PromptShellVariant + PromptShellLearningContract (ADQ-208) §2.4 Warrant-degradation-trigger registry (ADQ-312; Owner Map line 171) ## §3. Cross-cutting consumption contracts §3.1 ContextProduct contract (ADQ-203) §3.2 MemoryContextPlan contract (ADQ-211; three-plan model per ADQ-209) §3.3 MemoryFlowCertificate (ADQ-207; Owner Map line 150) ## §4. Proof spine §4.1 ContextPacketProof contract (SM-051) §4.2 RenderSafetyProof contract (DOC84 executes; DOC11 finalizes) §4.3 Proof spine invariants + lints ## §5. Named cross-cutting concepts (schema body deferred to Stage 7) §5.1 MemoryMutationEnvelope (Skeletal §10.5; §11.2; §11.8) §5.2 MemoryProvenanceGraph (Skeletal §10.6) §5.3 ResumeProjection / ResumeCard (Skeletal §10.13) ## §6. Memory-object classification table (Skeletal §10.12) §6.1 Column set §6.2 Seed rows §6.3 Classification invariants ## §7. ExternalDependencyRecord posture §7.1 ECSeamContract (Skeletal §10.9; OPA-031) §7.2 BDSM posture (ADQ-221; dependency_status = partial) §7.3 DOC8 capability-mining-only posture (ADQ-221) §7.4 External dependency table ## §8. Cross-cutting field conventions §8.1 Embedding-model-migration refs (Skeletal §10.14) §8.2 Bitemporal axes carrier (Skeletal §11.8) §8.3 Policy-generation carrier (per ADQ-305 + Skeletal §11.3) §8.4 Charter-input cross-ref convention ## §9. Observability + health seam (Skeletal §10.15) §9.1 MemoryPlaneHealthReadModel §9.2 Seed counters §9.3 Health-signal vocabulary ## §10. MemoryOperationQuota + scale assumptions (Skeletal §10.16) §10.1 Family-wide compute budget §10.2 Quota fields §10.3 Bound-enforcement model ## §11. Recovery / replay seam (Skeletal §11.1) §11.1 Owner posture (EC + DOC72 + DOC25 owned) §11.2 DOC80 family rebuild hooks §11.3 Replay-completeness invariant ## §12. Invariant enforcement-point naming (Skeletal §11.4) §12.1 Cross-family invariants table §12.2 Stage 9 lint roll-up ## §13. ABC §21 normalization-object placement check (Skeletal §10.17) §13.1 Verification table per object §13.2 Owner Map gap dispositions ## §14. Future completion obligations (AC-004 + AC-005) §14.1 Memory Intake & At-Use Disciplines (ADQ-403 / AC-004) §14.2 EC Core Addendum A intake-routing (ADQ-404 / AC-005) §14.3 minimum_completion_for_v5 summary ## §15. Stage 6 charter exit + cross-charter dependencies §15.1 What E0 unblocks (E1/E2 via ReasonCode; E7/E8 via ContextProduct/MemoryContextPlan/PromptShellVariant) §15.2 What E0 depends on (none — foundational) §15.3 Discharge sweep checklist ## §16. Open items + architect-review flags §16.1 OPEN_FOR_ARCHITECT_REVIEW items (if any — should be few) §16.2 Deferral-to-other-charter items (e.g., schema body deferrals) §16.3 Lint and fixture roll-up for Stage 9 / Stage 8 ## §17. Sources + lineage §17.1 ADQ landings table (every ADQ pinned to E0 → its section) §17.2 Skeletal §10/§11 fold-in landings table §17.3 Owner Map row references ``` ### 3.2 Per-section quality bar Each section must include: - **Source citation block.** "Per ADQ-310 / Skeletal §10.x / Owner Map line N." If you can't cite, you can't write. - **Schema(s) where applicable.** TypeScript interfaces, or YAML schemas, or equivalent paste-ready code. NOT prose descriptions of what fields might exist. - **Owner cell** (per the one-owner rule). Every schema names its single owner; consumers and executors are separate cells. - **Producer / consumer / executor breakdown.** Who writes? Who reads? Who runs the operation? - **Lifecycle states** (where applicable). What states does the entity move through? Who transitions? - **Unhappy paths**: empty / degraded / error / blocked / suppressed / revoked. Every contract has them. - **Lints (Stage 9 placeholders).** Name the invariant lints that protect the contract. (You don't implement; you name.) - **Fixtures (Stage 8 placeholders).** Name the fixtures that prove the contract works. (You don't implement; you name.) - **Cross-charter consumption notes.** Which other E-slice charters consume this contract? List them. ### 3.3 Required schemas / contracts to produce (full TypeScript-style, paste-ready) At minimum the following must have full schema bodies (not "NAMED only" — these are E0 owns at body-level): - `ReasonCode` (the entry) + `ReasonCodeRegistry` (the registry contract) + namespace rules - `DomainProfile` + `DomainProfileRegistry` + `'conservative' fallback` rule - `PromptShellVariant` + `PromptShellRegistry` + `PromptShellLearningContract` - `ContextProduct` + `ContextProductProductionContract` (DOC24 binds to this) - `MemoryContextPlan` (with the three-plan structure: ExtractionContextPlan + MemoryContextPlan + UserContextSurfacePlan per ADQ-209) - `MemoryFlowCertificate` (with mandatory invocation points) - `ContextPacketProof` - `RenderSafetyProof` contract (DOC84 executes; you specify the contract DOC84 must satisfy) - `WarrantDegradationTriggerRegistry` (per ADQ-312 + Owner Map line 171) - `MemoryPlaneHealthReadModel` (per Skeletal §10.15) - `MemoryOperationQuota` (per Skeletal §10.16) NAMED-only (schema body deferred to Stage 7 — but the NAMED concept is fully scoped): - `MemoryMutationEnvelope` - `MemoryProvenanceGraph` - `ResumeProjection` / `ResumeCard` The NAMED-only treatment means: you describe what the concept IS, what it carries, who its producer/consumer is, where it sits in the architecture — but you DO NOT write the field-level schema. Schema body is Stage 7. --- ## 4. Hard constraints (do not violate) 1. **DO NOT modify any file outside `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/`.** Your output is `DOC80_Core_Charter_Draft.md` only. The skeletal baseline, Owner Map, Import Graph, ADQ ledger, OP-A V4 — read-only. 2. **DO NOT open new ADQ rows casually.** Architect decisions are pre-resolved. If you genuinely find a question not answered by ADQ + Skeletal + Owner Map + Pass 1, flag it `OPEN_FOR_ARCHITECT_REVIEW` in §16; do not invent an answer. 3. **DO NOT redraw family boundaries.** The 8-member family is settled. DOC80 owns what the Owner Map says it owns, no more, no less. 4. **DO NOT phantom-create features.** Every contract / field / lint / fixture you specify must trace to a citation. If you can't trace, flag. 5. **DO NOT use prose where schemas are required.** "A registry with reason codes" is wrong; the TypeScript interface for `ReasonCode` + `ReasonCodeRegistry` is right. 6. **DO NOT propose schema bodies for NAMED-only concepts** (`MemoryMutationEnvelope`, `MemoryProvenanceGraph`, `ResumeProjection`). Stage 7 writes those. 7. **DO NOT skip the unhappy paths.** Every contract must specify empty / degraded / error / blocked / revoked / suppressed states. 8. **DO NOT run `git` commands.** Will handles git operations manually. 9. **DO NOT introduce retired names** (check `DOC80_Retired_Names.md`). 10. **DO NOT use bullet points for substantive design rationale.** Prose is required for explanation; bullets only for actual lists. --- ## 5. Acceptance criteria — when E0 draft is done - `DOC80_Core_Charter_Draft.md` exists at the specified path. - All 17 §1-§17 top-level sections present with substantive content. - All 20 draft targets from `Charter_Opening_Brief.md` §"Draft targets" addressed. - All 8 ADQ rows from `Charter_Input_Deck.md` have explicit landing sites in §17.1. - All 14 Skeletal §10/§11 fold-ins from Input Deck have explicit landing sites in §17.2. - ABC §21 normalization-object placement check completed in §13 (verify / assign / defer each of `WarrantEvaluationResult`, `WarrantConsequenceRegistry`, `DomainProfileWarrantPolicy`, `IngestionCostBudget`, `PromotionGateRecord`, `ConsideredItemLedger`, `PromptShellExposure`). - Every full schema in §3.3 of this commission has a paste-ready TypeScript-style interface body in the draft. - Every NAMED-only concept has a complete scoping paragraph (what it carries, producer, consumer, where it sits) but no field-level schema. - `OPEN_FOR_ARCHITECT_REVIEW` items are SMALL — aim for ≤ 5. If you find yourself flagging more than 5, you're punting too much. - Cross-charter consumption notes are explicit for every consumed-elsewhere contract (which E-slice charter consumes it). - The draft is read-once-understandable by a Stage 7 schema-body author and a red-team reviewer who has not been in the project. --- ## 6. How to be useful - **Be specific.** "DOC80 owns the ReasonCode registry" is useless. "DOC80 owns the `ReasonCodeRegistry` contract (schema below); producer docs (EC / PropA / DOC24 / DOC20 / etc.) own their namespace prefix and their own `ReasonCode` entries within the registry per ADQ-310" is useful. - **Pick concrete schemas.** TypeScript-style interfaces are required. Don't write "fields like ..."; write the interface. - **Use the multi-perspective lens.** A schema must be: implementable (Coder), defensible to users (Product Designer), and correctly wired across the family (Integration Architect). - **Lint-name and fixture-name liberally.** Stage 9 (lints) and Stage 8 (fixtures) consume your names. Every contract should propose 2-4 lints and 1-3 fixtures (you name them; you don't implement them). - **Cite Skeletal section numbers in the draft itself.** "Per Skeletal §10.5, `MemoryMutationEnvelope` carries..." is the right form. - **Don't soften.** If a contract has a known weakness, flag it `GAP: <description>` inline. --- ## 7. If you get stuck - If a Skeletal section or Owner Map row says something you cannot reconcile with a pinned ADQ: flag in §16.1 with both citations, propose the read you prefer, and continue. - If a contract field could go to two members (e.g. DOC80 vs DOC84): default to the more restrictive placement (closer to the source; further from delivery) and flag in §16.2. - If you find that a draft target requires content from a Stage 5R2c file you cannot read: STOP, write `Charter_Draft_HALT.md` with the blocker, and exit. Do not guess. - Do NOT spawn subagents unless absolutely needed; do NOT explore beyond the read list. --- ## 8. Tone, length, format - **Tone:** technical-spec voice. Direct, declarative, no hedging, no "we should consider" — say what the contract IS. - **Length:** the draft will be substantial. The Skeletal §10 + §11 is about 300 lines; you are expanding that into a member-spec-grade document — probably 1500-3000 lines. Don't compress to be brief; don't pad to be long. Match content density to substance. - **Format:** Markdown. Headings as in the structure above. TypeScript-style code blocks for schemas. Tables for ownership / consumer / lifecycle mappings. Prose for rationale. - **Citations inline:** "per ADQ-310" or "per Skeletal §10.5" or "per Owner Map line 144" as inline citations, every paragraph that makes a claim. --- ## 9. Time bound E0 draft should complete in one focused Claude Code session. If you find yourself spawning subagents, doing extensive exploration beyond the read list, or producing files outside the E0 folder — you've drifted. Return to §3 (deliverable spec) and §5 (acceptance criteria). Estimated session length: 60-120 minutes of focused work. Will reviews the draft after, then takes it to red-team rounds (Claude / ChatGPT / Codex), then synthesizes findings, then revises to ratify. --- **Begin by reading §2 file 1 (`README.md` in the charter folder), then §2 file 2 (`Charter_Opening_Brief.md`), then §2 file 3 (`Charter_Input_Deck.md`). Acknowledge the read in your first response. Then proceed through the Skeletal §10/§11 + Owner Map for the contract material. Then begin drafting `DOC80_Core_Charter_Draft.md` per the §3.1 structure. Mid-draft, you may continue to consult §2.4 (operational state) and §2.5 (background reference) as needed. Do not produce the draft until you've completed at least §2.1 + §2.2 reads.**