ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_CODEX_Application_Audit_Prompt.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# E0 / DOC80 Core — Application-Fidelity & Regression Audit Commission (CODEX)

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Date issued:** 2026-06-01
**Architect:** Will Brody. **You produce the audit report; Will fixes + ratifies.**

**You are:** an independent auditor verifying that the E0 / DOC80-core charter draft was **faithfully and completely** updated from its locked adjudication package, and that the resulting draft is **internally sound**. This is a **fidelity + regression audit**, not a design review and not a re-adjudication. The edits were already decided and locked; your job is to confirm they actually landed, correctly, with nothing lost, duplicated, garbled, or silently changed — and to independently re-run the post-patch checks.

**Why this audit exists (read this):** the draft was edited by Claude Code, and the only existing check (`E0_Application_Report.md`) is that *same agent's self-report*. A self-report of "all ~80 edits applied, all regression checks pass" is precisely what an independent pass must verify. **Do not trust the Application Report's claims — re-derive every one against the actual draft text and the source cards.** The draft also grew 1,089 → 1,822 lines in one pass; that magnitude is where dropped, half-applied, duplicated, or mis-anchored edits hide.

---

## 1. Inputs (all paths repo-relative; read in this order)

If you have repo access, read directly. If a path 404s, list its parent folder (folder names contain spaces). If you cannot access the repo, **stop and tell Will** — do not audit from assumption.

**The artifact under audit**
1. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` — THE APPLIED DRAFT (R1 → R2+R3 applied). This is what you verify.

**The source-of-truth fix list (what SHOULD be in the draft)**
2. `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/DOC80 S6 E0 RT Adj Card R2.md` — the base package (~80 edits; every ACCEPT / ACCEPT-WITH-MODIFICATIONS / ACCEPT-AS-FIX item should be present; every REJECT / DEFER item should be absent).
3. `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/DOC80 S6 E0 RT Adj Card R3.md` — the lock delta: the §22 egress full-replacement + the 11-item non-egress lock patch (§(b) items 1–11).

**The claim you are checking (distrust it)**
4. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Application_Report.md` — Claude Code's self-report of what it applied + a self-run of the §15.5 gate. Treat every "✓ / PASS" as a claim to independently confirm or refute.
5. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Application_Commission_Claude_Code.md` — what Claude Code was instructed to do.

**Ground truth (for the no-invention / trace checks)**
6. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` (§2 section map; §10/§11)
7. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`
8. `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md`
9. `Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md` (no retired/invented name may be reintroduced)
10. `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md` (SM-060)
11. `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/12_ABC_Consolidated_Structural_Patch_R0_2.md` — **ABC R0.2** (the only copy outside `.git`); §9.2 enumerates the **17** canonical `ContextProductKind`s.
12. `OP-A and Operations and Trackers/OPA_V4.md` — §6.Z / §6.Z2 / §6.Z3 egress + design-discussion obligations.

---

## 2. What to check

### 2.A Edit-by-edit fidelity (the core)
Enumerate **every** applied item from R2 (all ACCEPT/AWM/ACCEPT-AS-FIX rows) and R3 (the §22 replacement + non-egress items 1–11). For each, locate it in the applied draft and classify:

- `LANDED` — present, in the right section, intact and complete.
- `MISSING` — not in the draft.
- `PARTIAL` — only some of the item's fields/lints/fixtures/prose made it.
- `GARBLED` — present but corrupted (wrong field names/types, broken code fence, truncated, merged with adjacent text).
- `DUPLICATED` — applied more than once / collides with another edit.
- `MISPLACED` — landed in the wrong section or anchor.

Produce a table: `item id | expected (per card) | draft location §+line | status | note`. Pay special attention to the high-risk edits: the 17-kind `ContextProductKind` rewrite (UR-01), the discriminated-union MFC with all **9** flow kinds (UR-03/04 + R3 erasure/restamp/restore), `SemanticProjectionContract` (UR-31), the §22 egress binding (INV-E0-EGRESS-1, `E0EgressAttestation`, lints, fixtures), and the R3 non-egress items (destruction-ledger EC-ownership, `initiating_member_ref` promoted to `BaseMFC`, `RegistryEntryLifecycleState += candidate`, legal-hold-for-redaction, restore re-eval invariant).

### 2.B Rejects/defers correctly excluded
Confirm R2 §I REJECT items (e.g., meta-schemas UR-28, `ContextProduct→ContextArtifact` rename, full lifecycle engine) are **absent**, and §J DEFER items are **not** applied but **are** enrolled (deferral register §16.2 / gate table §15.4 / matrix §17.4). Flag any reject that leaked in or any defer that was silently dropped.

### 2.C Fork decisions reflected
Confirm the architect's seven fork calls are applied as decided: UR-37 (DOC25 producer, scoped to parse/materialization/ingestion); UR-38 (§4 + §18 + §19 + §20 restored); N3 (5-plane cascade, no 6th plane, no promotion-time invariant); the 17-row registry table guesses **no** owners (unconfirmable cells marked `⚠owner-confirm@E3/E4/E7`); DebugModeContract scoped to F30 only; verdict token + §15.5 gate present; §22 folded as the Critical binding.

### 2.D Independent §15.5 regression re-run (do NOT copy the report's results)
Re-derive each against the actual draft and report PASS/FAIL + evidence:
(a) `ContextProductKind` reads 17 everywhere — no stray "14" except genuine fold-in-count numerals; (b) the MFC union has all 9 flow kinds and every `issued` variant carries its required refs; (c) every lint name is tagged `[canonical]` (verbatim source) or `[proposed]` — none silently promoted; (d) every §16.2 deferral has a §15.4 gate row **and** a §17.4 matrix row; (e) `SemanticProjectionContract` (§3.6) is defined; (f) §18 golden scenario present; (g) §4/§19/§20 restored; (h) no retired/invented name reintroduced (cross-check `DOC80_Retired_Names.md`); (i) the OPA §6.Z/Z2/Z3 obligations + ADQ-406/407/408 referenced from the gate table + preservation matrix.

### 2.E Architect-decision items surfaced
List every `OPEN_FOR_ARCHITECT_REVIEW` item (the Application Report's §5) and confirm each is present in the draft **as an open flag**, not silently resolved. These are Will's calls before ratification — surface them, don't adjudicate them.

### 2.F Internal soundness (coding-agent lens)
- TypeScript blocks well-formed: balanced braces, no truncated interfaces, discriminated unions internally consistent, every type referenced inside the draft is defined or explicitly NAMED-only.
- No dangling cross-references: every `§X.Y` pointer resolves to a real section; check the **§22-vs-§21 renumber note** specifically (the report kept the card's `§22` identity and parked the baseline §21 retired-names pointer at §17.3 — confirm no broken §21 references and the note is present).
- No duplicate, orphaned, or out-of-order sections; section numbering intact end to end.
- Naming/casing conventions (branded IDs, snake_case JSON / PascalCase interfaces, RFC3339 timestamps, sha256) applied consistently per §8.

### 2.G Cross-artifact / discharge status (report, don't fail on)
The discharge sweep (SM-060 "14→17", Owner Map, SPEC_STATE entry, OPA per-owner folding, ADQ landing notes) is the architect's **separate next step** and is expected to be **not done yet** — do **not** mark the audit failed for it. But confirm the draft's *internal* references to those artifacts are consistent, and produce the checklist of exactly what the discharge will need to touch (so nothing is missed).

---

## 3. Scope boundary

- **Not a design review.** Architecture and contract design were settled and locked. If you spot a genuine design concern, log it under a separate `DESIGN_ADVISORY` heading for the architect's later design pass — do **not** fold it into fidelity findings or propose redesigns.
- **Not a re-adjudication.** Do not relitigate accepted/rejected items; only verify they were applied/excluded as decided.
- **No invention.** Every defect you assert must cite the card item or ground-truth source it violates, plus the draft §+line.

---

## 4. Output

A single Markdown report. Type each finding: `MISSING_EDIT / PARTIAL_EDIT / GARBLED_EDIT / DUPLICATED_EDIT / MISPLACED_EDIT / REGRESSION_FAIL / SOUNDNESS_BUG / REJECT_LEAKED / DEFER_DROPPED / CONFIRMED / ARCHITECT_DECISION_PENDING / DESIGN_ADVISORY`. Sections:

1. **Summary + verdict** — one of `FIDELITY_CONFIRMED` (ready to ratify) · `FIXES_NEEDED_BEFORE_RATIFY` (defects listed, each with a paste-ready fix) · `MAJOR_GAPS` (substantial edits missing/garbled → re-application pass needed). State the raw count of edits checked and how many LANDED vs not.
2. **Edit-fidelity table** (§2.A).
3. **Independent §15.5 results** (§2.D) — PASS/FAIL per check with evidence; explicitly note any place the Application Report claimed PASS but the draft disagrees.
4. **Rejects/defers check** (§2.B) · **Forks check** (§2.C).
5. **Architect-decision items** (§2.E) — the list for Will.
6. **Internal-soundness findings** (§2.F).
7. **Discharge checklist** (§2.G) — what ratification's discharge sweep must touch.
8. **`DESIGN_ADVISORY` annex** (anything for the separate design pass).

For every defect (anything not `LANDED`/`PASS`/`CONFIRMED`), give a **paste-ready fix** anchored to the draft (`REPLACE:`/`INSERT AFTER:` + the corrected text) so Will can fix-then-ratify without re-deriving.

**Cite §+line for every finding.** Be specific; don't soften. If the draft is clean, say so plainly and verdict `FIDELITY_CONFIRMED` — a fidelity audit that confirms faithful application is a successful audit, not a weak one.

---

## 5. Delivery

Produce the report as **one Markdown document in your reply.** If your environment can write to the repo, also save it to `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/E0_Application_Fidelity_Audit_CODEX.md`; otherwise return it inline and Will saves it. **Start by** confirming repo access, listing the files you read, and stating the raw count of edits you will verify (R2 accepted items + R3 §22 + R3's 11 non-egress items). If you can't reach the repo, stop and say so.

**You are the independent check between a self-reported application and ratification of the foundational DOC80 spec. Verify everything; assume nothing.**