Elnor Repo Reader

# E0 / DOC80 Core — Claude Code APPLICATION COMMISSION

**Purpose:** Apply the fully-adjudicated red-team patch to the DOC80 core charter draft, producing a *ratification-ready* draft. The adjudication is COMPLETE and is **not** to be re-opened. Your job is faithful application + internal-consistency maintenance. You do **not** ratify, you do **not** redesign, you do **not** run git.

---

## 0. Context (one paragraph)
You are editing `DOC80_Core_Charter_Draft.md`, the Stage-6 E0 charter draft for **DOC80 — Memory Control Plane Core** (family member **1 of 8**; the core/contracts member). It is currently round **R1** and contains **none** of the adjudicated edits. Two red-team/adjudication cards define the patch. Apply them, keep the whole document internally consistent, self-verify against the §15.5 regression gate, and write an application report. The ratified draft later becomes the operative DOC80 core spec and feeds Stage-7 schema-body work — but ratification is the architect's separate act, not yours.

## 1. Files (repo root, local: `/Users/OpenClaw1/Elnor/Elnor Specs`; GitHub `wbrody/Elnor-Specs`, `main`)
- **TARGET (edit in place):** `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` (~1088 lines, 17 sections §0–§17).
- **PATCH — base:** `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/DOC80 S6 E0 RT Adj Card R2.md`
  - R2 §1 = section-map diff (identifies the dropped sections). R2 §2 = **master decision index = the complete checklist of every accepted item**. R2 §3 = **per-item rows = the detailed edit specs, with exact code blocks**. R2 §9 = verdict + "deliverable = the full revision = every accepted item (~80 edits), no minimum subset." R2 §15.5 = the regression gate. R2 §8 = cross-artifact/discharge items (do NOT edit those files — see §5).
- **PATCH — egress delta:** `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/DOC80 S6 E0 RT Adj Card R3.md`
  - R3 **fully replaces R2's §22** (§(a) egress-enforcement binding) and **adds a non-egress lock patch** (§(b) item list). Apply **both** §(a) and §(b).
  - **Precedence:** R3 wins for §22 and the non-egress items; R2 governs everything else.
- **Charter framing (read for section targets / intent):** same folder — `Charter_Opening_Brief.md`, `README.md`, `Charter_Input_Deck.md`.
- **Cited source specs (resolve paths via `OP-A and Operations and Trackers/MASTER_SPEC_DOCUMENT_LIST.md` + `Current Specs/DOC##/`):**
  - **ABC R0.2** — §9.2 = canonical **17** `ContextProductKind`; §9.3 = registry-entry typing; §9.4 = disposition enum. (Senior per DR-001 / Skeletal §3.3.)
  - **PropA R6.3** — EC PolicyDecisionEngine, `SharingRuleSchema`, P1 privilege / P3 PII classifiers, the L94 unified-gate principle, the fail-closed defaults.
  - **DOC24 R3.1.1**, **KDA R3**, **EC Core Addendum A V3.3**.
  - **Locate each cited source before applying any edit that depends on it. If a cited source cannot be found, STOP and report — do not guess.**
- **Skeletal baseline (numbering reference):** `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/`.

## 2. The exact task
Apply to `DOC80_Core_Charter_Draft.md` the FULL adjudicated package and nothing beyond it:
1. **Every accepted item in R2** — work from R2 §2 (checklist) using R2 §3 (specs). No minimum subset.
2. **R3's §22** (egress-enforcement binding) — **add it to the draft as a NEW section** (the draft currently has no §22). "R3 fully replaces R2's §22" refers to the *card* content: use R3's version, discard R2's.
3. **Every item in R3 §(b)** (non-egress lock patch).
4. **The four dropped sections** (R2 §1) restored from the bodies R2/R3 provide — see §4 below.

**Apply ACCEPTED items only.** Skip R2 §I rejects and §J defers (see §5). **Sanity scale:** R2 §2 enumerates the full set (~80 edits per R2 §9); R3 adds §22 + the §(b) non-egress items (~11). If your applied-items count is materially short of that, you have missed items — recheck R2 §2 before reporting done.

## 3. Architect fork decisions — ALL SIX CONFIRMED (apply the decided variant exactly)
1. **N3 — plane cascade:** keep the **5-plane** cascade; do **not** add a 6th plane; do **not** add the promotion-time invariant; clawbacks are handled manually. (R2 §G, UR-08.)
2. **17-row ContextProduct registry seed table (§3.1.1):** populate ONLY cells confirmable from ABC §9.3; mark every other cell `⚠owner-confirm@E3/E4/E7`. **Do not guess owners.** (R2 §C, A3/A10.)
3. **DebugModeContract:** NAMED-only, **scoped to F30's actual text only**; do not broaden. (R2 §C, Finding 4.)
4. **Verdict token + regression gate:** retain the verdict token; add the **§15.5 post-patch regression gate** as a numbered section (body in R2 §15.5). (R2 §H.)
5. **UR-37 — DOC25 ReasonCode producer:** ACCEPTED, **scoped** — narrow DOC25's grounding to **parse / materialization / ingestion** conditions; route **source-revocation** reason codes to **DOC82**. Insert the rationale sentence + scoping clause. (The "amend Owner Map L86" piece is a discharge item — record it, do **not** edit Owner Map.) (R2 §B, UR-37.)
6. **§22 egress enforcement binding:** **fold in as substantive** (R3's version). It is a **lint that makes PropA's existing "every outbound boundary runs through the policy engine" rule (PropA L94) provable** — it is **NOT** a new structured output-gate primitive. (R3 §(a).)

## 4. Four dropped sections to restore (R2 §1 section-map diff)
Restore using the bodies the cards provide:
- **§4 Shared runtime vocabularies (B10)** — R2 §4 body (`OwnerDocId` / `ProducerDocRef` / `BudgetBand` value types; anti-junk-drawer rule; helper-type ownership — `UseWarrant`/`SupportRole`/`MemoryObjectRole` are **DOC82-owned**, referenced not redefined; `OwnerDocId`/`ProducerDocRef`/`BudgetBand` are §4-owned).
- **§18 Golden scenario** — per R2 UR-35.
- **§19 Per-external-doc amendment-magnitude** — R2 §19 body.
- **§20 Per-member obligations tables** — R2 §20 body.
- **§17 Family-wide acceptance standard** — complete the partial per R2 ADJ-3.
**Placement (applies to the four restored sections AND the §22 egress binding):** the draft uses its own numbering (§0–§17), which diverges from the Skeletal/card numbering for these sections. **Do NOT renumber the existing sections.** Add each as a new section with a clear descriptive heading at a logical point: **shared-runtime-vocabularies early** (it is foundational — later sections reference it); the **golden scenario / amendment-magnitude / per-member-obligations** as back-matter alongside the §15–§17 acceptance/exit material; the **§22 egress binding** with the proof-spine / policy-enforcement material (it makes the outbound-enforcement rule provable). Cross-reference appropriately and **record every placement decision** in the report.

## 5. How to apply — HARD RULES
- **Apply every accepted item.** The full revision, not a subset. Tick each R2 §2 item + each R3 item in the report.
- **Accepted items ONLY.** Do NOT apply R2 §I rejects (UR-28 meta-schemas; the `ContextProduct`→`ContextArtifact` rename; the full lifecycle/erasure state-machine — UR-29 affirms a per-event certificate is not an engine) or R2 §J BETTER_IDEA/DEFER items (UR-42–45). They appear in R2 §3 marked REJECT / DEFER — skip them.
- **Target by content, not section number.** The R2 per-item `[§X]` tags align with the draft's sections for the low-numbered sections but diverge for the dropped/back-matter ones (the draft uses its own §0–§17 scheme). Apply each edit by locating its literal `REPLACE` target / anchor in the draft, not by its card section number.
- **Verbatim where given.** Where a card supplies a code block or exact replacement text, apply it verbatim. Where it says ``REPLACE `X` ``, the literal `X` is the target string.
- **R3 supersedes R2 §22.** Apply R3's §22 in full; discard R2's §22.
- **INTERNAL-CONSISTENCY MAINTENANCE (critical — this is most of the real work).** Every edit that changes a name, enum, or field obliges you to update **all** downstream references in the draft. **Worked example you MUST handle correctly (UR-01):** the 14-kind `ContextProductKind` enum (old names incl. `assertion_pack`, `orientation_rollup`, `resume_card`, `inspector_explanation`, `search_affordance_result`) is replaced by ABC §9.2's canonical **17** (new names incl. `assertion_packet`, `recent_work_orientation`, `issue_frame_orientation`, `search_affordance`). After the swap you MUST: (a) replace `ContextProductDescriptor` with `ContextProductRegistryEntry` per UR-01 (ABC-§9.3 fields); (b) re-author every prose reference to the old kinds — the lifecycle paragraph, the surface-kinds paragraph, the §3.4 trace example — to the new kinds, noting that **resume is now `ResumeProjection`/`ResumeCard` (a NAMED concept in §5.3), not a `ContextProductKind`**; (c) fix the `ContextProductProductionContract.registry` type reference; (d) sweep every remaining "14" in §3.1 / the §6 classification table / fixtures to "17" — but **do NOT touch the "fold-in count" numerals** (the "14 vs 17 Skeletal fold-ins" reconciliation in §17.2 / §16.1); (e) update fixture token `…registry_has_exactly_14_kinds` → `…_17_kinds`; (f) the §16.1 "confirm at Stage 7" open item for the kind count is now **resolved** by ABC §9.2 being senior — update it. Apply the same diligence to every rename/typing edit (e.g., `LifecycleState` → `RegistryEntryLifecycleState`, the `E0DurableRecord` base, the MFC union additions).
- **Authoring-to-spec from cited sources.** For items a card defines from a cited source (the 17-row §3.1.1 table from ABC §9.3; the ABC-§9.3-aligned `ContextProductRegistryEntry`), read the source and author accordingly. Fill only what the source confirms; mark the rest `⚠owner-confirm@<charter>`.
- **INVENT NOTHING.** If you cannot determine the correct application of an item from the cards + cited sources, do **not** fabricate. Leave a clearly-marked `<!-- OFAR: … -->` flag at that spot in the draft and list it in the report's OPEN_FOR_ARCHITECT_REVIEW section. A flagged gap is correct; a guess is a failure.
- **Do NOT edit tracker / cross-artifact files.** The discharge sweep (Owner Map, Import Graph, Retired Names, Source Registry, STAGE_6_CHARTER_INPUT_INDEX, E0_Red_Team_Review_Prompt path fix, ADQ ledger, OPA, SPEC_STATE) is a **separate post-ratification step**. Where an edit references one, record it under "Discharge obligations" in the report; do not edit those files.
- **Do NOT ratify.** Update only the draft header's status line from "round R1" to "patch applied — ratification pending." Do not mark it ratified; ratification is the architect's act via a separate `Ratification.md`.
- **Preserve everything untouched** — voice, structure, ordering, all non-targeted content verbatim. No reformatting, summarizing, or unrequested "improvements."
- **Do NOT run git.** Edit files in place; the architect reviews and commits. No commit, push, or branch.

## 5.5 Read efficiently — context strategy (so you don't jam your window)
- **Keep resident:** this commission + the **R2** card + the **R3** card + **`DOC80_Core_Charter_Draft.md`**. That is your working set (~50–55K tokens — it fits a 200K window comfortably). Do not let these get summarized/compacted away mid-task; if context fills, checkpoint which R2 §2 items are done so you can resume rather than dropping the cards.
- **Cited source specs — TARGETED reads only.** Do **NOT** load ABC R0.2 / PropA R6.3 / DOC24 R3.1.1 / KDA R3 / EC Core Add A in full — they are large and only specific cited sections matter (ABC §9.2/§9.3/§9.4 for the 17-kind enum + registry entry; the PropA line ranges named inside R3's §22 and in UR-37; etc.). `grep`/read just the cited section, apply it, move on.
- **Work the draft in passes by region**, returning to **R2 §2 as the running checklist** — you do not need the entire patch in working memory at once.

## 6. Self-verification before reporting done (the §15.5 regression gate — R2 §15.5)
(Note: the §15.5 section's body **is** this checklist — the section you add per fork #4 and the checks you run here are the same content.)

Run and record each; if any fails, fix and re-run:
- `ContextProductKind` reads **17** everywhere; no stale "14 kinds" / "exactly 14" in §3.1 / §6 / fixtures (fold-in-count numerals untouched).
- **No orphaned old kind-names** anywhere in the draft.
- The **four forks** landed exactly as decided (§3 above).
- **§15.4** deferral gate table, **§15.5** regression gate, **§17.4** preservation matrix all present.
- The **four restored sections** (§4/§18/§19/§20) + §17 completion present and cross-referenced.
- **§22 = R3's version** (egress binding) with its lints + fixtures; **every R3 §(b)** item present.
- **No retired names reintroduced** (the 14 invented kind-names go to Retired Names at discharge, not back into the draft).
- Every R2 §2 accepted item + every R3 item is ticked in the report.
- Markdown fences balanced; TypeScript blocks syntactically intact; no dangling section references.

## 7. Outputs
1. **`DOC80_Core_Charter_Draft.md`** — edited in place (uncommitted).
2. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Application_Report.md`**, containing:
   - **Applied-items table** — every R2 §2 item ID + every R3 item → draft section landed in + one-line note + ✓.
   - **Restored sections** — §4/§18/§19/§20 + §17 completion, with placement decisions.
   - **§15.5 regression results** — each check pass/fail.
   - **OFAR list** — every `<!-- OFAR -->` you left, with location + why.
   - **Discharge obligations** — the post-ratification cross-artifact items (SM-060 14→17; Owner Map L86 + ResumeProjection/ResumeCard row; Import Graph EC §1/§3/§7/§8 pins; Retired Names 14 kind-names; Source Registry ABC §9.2/9.3/9.4; STAGE_6_CHARTER_INPUT_INDEX +ADQ-313; E0_Red_Team_Review_Prompt path fix; ADQ ledger resolved-by-E0 marks incl. the **ADQ-207/312 consumed-not-resolved** nuance; OPA §6.Z / §6.Z2 / §6.Z3 obligations (the §6.Z3 egress obligations were added this session); SPEC_STATE DOC80 entry).
   - **Open questions** for the architect, if any.

## 8. Do NOT
- Re-open the adjudication or "improve" the design.
- Add anything not in R2 + R3 + the six confirmed forks.
- Ratify, or run git.
- Edit tracker / cross-artifact files.
- Guess — flag OFAR instead.

*After you finish: the architect (with a second reviewer) verifies this draft edit-by-edit against R2 + R3, then ratifies via `Ratification.md`, then runs the discharge sweep.*