Elnor Repo Reader

# E0 / DOC80 Core — Final Design Review Commission

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Date issued:** 2026-06-01
**Architect:** Will Brody. **You produce the review; Will saves it and decides ratification.**

**You are:** an independent design reviewer giving the **final soundness pass** on the DOC80-core charter before ratification. The draft is the foundation of the 8-member DOC80 family — its contracts cascade into E1–E10 + E_org — so this is the last gate to catch a design flaw before it multiplies.

**This is a DESIGN review of the integrated whole — not a fidelity check and not a re-adjudication.** Read the framing carefully so you spend effort where it's useful:

- **Fidelity is already confirmed.** An independent CODEX application-fidelity + regression audit verified every locked edit landed and the §15.5 checks pass; its four defects were fixed and re-verified. **Do not re-audit whether edits landed** — assume the text is faithful and review the *design it expresses*.
- **The architecture is settled.** The family decomposition, the 47 ADQ resolutions, and the locked R2 + R3 adjudication decisions are final. If you disagree with a settled decision, mark it `OUT_OF_SCOPE_ADVISORY` — do not relitigate it as a defect.
- **Your value is the whole.** The earlier red-team saw the R1 draft + the fix cards *separately*. You are the first to read the **fully integrated** spec (~100 edits folded in, incl. the §22 egress binding and the litigation proof layer). Look for problems that only appear when it all sits together: contradictions introduced by the edits, seams that don't compose, a contract that no longer fits its consumers.

A clean "no blocking design defects → ratify" is a valid and welcome outcome. Do not manufacture issues to look thorough; do not soften real ones.

---

## 1. What to find

- **Composition failures** — contracts that are individually fine but don't compose. Walk the core pipeline end to end: `ContextProduct` → `MemoryContextPlan` → proof spine (`ContextPacketProof` / `RenderSafetyProof` / `MemoryFlowCertificate`) → `MemoryCoordinationTrace` → (for outbound) the §22 egress binding. Does a real flow thread through cleanly?
- **Contradictions introduced by integration** — the ~100 folded edits may have left two sections disagreeing (a field, an enum, an invariant, an owner, a count). Flag any internal contradiction.
- **The new material, scrutinized** — the §22 egress layer (`INV-E0-EGRESS-1`, `E0EgressAttestation`, the per-source convergence ledger), the litigation proof layer (`ErasureMFC` / `RestampMFC` / `RestoreMFC` + `MemoryDestructionLedger`), `SemanticProjectionContract`, the 17-kind `ContextProduct` registry, `FinalPromptTruthRef`. Are these sound, well-typed, and consistent with the rest? Any phantom field/lint/fixture, any owner/EC-boundary error, any missing unhappy path?
- **Cross-charter wiring** — for the contracts E0 owns, will the consuming charters actually be able to bind? Spot-check against `STAGE_6_CHARTER_INPUT_INDEX.md`: pick E1/E2 (DOC81 scope/policy, the next charter) and E7/E8 (DOC84 delivery/proof, the heaviest consumers) and verify E0 delivers what they need.
- **Missing contracts** — anything the family will need that E0 should own but doesn't (versioning/migration discipline, a concurrency primitive, a telemetry seam, etc.). Flag as GAP with why DOC80 should own it.
- **Schema quality** — are the TypeScript contracts production-grade: right discriminated unions, branded IDs, consistent casing/timestamps, no leaky abstractions, exhaustive enums, optionality marked? Grade the load-bearing schemas A/B/C/D.
- **Failure / unhappy paths** — every contract should specify empty / degraded / error / blocked / suppressed / revoked states. Flag happy-path-only contracts.
- **Coding-agent + Stage-7 test** — where would a Stage-7 schema-body author or a Claude Code implementer have to *guess*? Every such point is a defect.
- **Golden scenario + lints/fixtures** — is the §18 end-to-end scenario adequate to prove the integrated pipeline? Are there load-bearing invariants with no named lint, or fixtures that can't be implemented?
- **Better patterns (BETTER_IDEA)** — where a cleaner architectural pattern exists, propose it (don't relitigate settled choices; propose genuinely additive improvements).

---

## 2. Read order (paths repo-relative; read directly if you have repo access — if not, stop and tell Will)

**The artifact under review**
1. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` — the integrated, corrected DOC80 core (R2 + R3 applied; CODEX F1–F4 fixed). **This is what you review.**

**Scope + the settled decisions (so you don't relitigate)**
2. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Opening_Brief.md` — E0 scope, the 20 draft targets, exit criteria. Verify the draft delivers against this.
3. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Input_Deck.md` — the 8 ADQs + fold-ins E0 consumed.
4. `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/DOC80 S6 E0 RT Adj Card R2.md` and `.../DOC80 S6 E0 RT Adj Card R3.md` — the **locked** adjudication (what was decided; treat as settled).
5. `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/E0_Application_Fidelity_Audit_CODEX.md` — the fidelity audit (already passed; don't repeat it).

**Ground truth (for trace + composition 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`
10. `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` (ADQ resolutions — settled)
11. `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md`
12. `OP-A and Operations and Trackers/OPA_V4.md` (§6.Z / §6.Z2 / §6.Z3)
13. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/STAGE_6_CHARTER_INPUT_INDEX.md` (what downstream charters consume — for the wiring check)
14. `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` (§12 slices; §18 golden scenario; §19 final-acceptance bar)
15. `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** (§9.2 = the 17 canonical ContextProduct kinds; the only copy outside `.git`).

---

## 3. What ELNOR is (90 seconds)

Local-first AI orchestration platform on OpenClaw (Node.js), single M4 Pro MacBook, isolated macOS user. Domain-agnostic personal-OS with securities-litigation as one profile. Spec / red-team / design-hardening phase — nothing implemented. The bar is specs dense enough that an implementer can't drift or guess.

**Three systems:** Knowledge (DOC72 graph, DOC73 PBE, DOC25 ingest, DOC1 write-gate) · Operations (DOC24 packet assembly, DOC15 CIL, DOC10/11 runtime) · Body (DOC23 tasks, DOC12/16/18/20 UI, DOC17 Q).
**DOC80 family:** DOC80 core (this) · DOC81 scope/policy · DOC82 knowledge/source/evidence · DOC83 extraction/temporal · DOC84 delivery/prompt/proof (DAMS substrate) · DOC85 learning · DOC86 UI/Inspector/Search · DOC87 organization/membership.
**Key terms:** EC = Elnor Core (sole durable writer). PBE = DOC73. DAMS = substrate in DOC84 (ADQ-210). MFC = MemoryFlowCertificate.
**Will's failure modes:** phantom buttons/memories · over-aggressive ingestion · silent auto-promotion · missing empty/degraded/error states · under-specified schemas · cross-doc seams that sound wired but aren't · unregistered content types/surfaces · living memory eroding static facts · search-engine-not-personal-OS feel.

---

## 4. Specific questions (answer each, cite §+line)

1. **Pipeline composition.** Walk a durable Assertion write triggered by user input from `ContextProduct` selection through `MemoryContextPlan`, the proof spine, `MemoryCoordinationTrace`, and (if it egresses) §22. Does every handoff have a defined producer/consumer and a proof artifact? Where does it break?
2. **§22 egress binding.** Is `INV-E0-EGRESS-1` + `E0EgressAttestation` actually enforceable as specified, and does it compose with the MFC layer (does an outbound render produce both a RenderMFC and an egress attestation without double-gating or a gap)? Is the same-machine no-lookup carve-out safe?
3. **Litigation proof layer.** Are `ErasureMFC` / `RestampMFC` / `RestoreMFC` + `MemoryDestructionLedger` coherent as certificate shells (not a lifecycle engine, per UR-29)? Is EC-sole-writer honored (destruction ledger EC-written; convergence ledger EC-signed/DOC24-appended, NOT a write)? Any way a destructive effect escapes a certificate?
4. **Proof spine completeness.** With nine MFC flows now, does the §4.3 B8 table cover every flow's failure mode? Any privileged flow with no proof artifact or no lint?
5. **17-kind ContextProduct registry.** Is the registry entry contract (`ContextProductRegistryEntry`) sufficient for DOC84 to assemble each kind without guessing? Are the owner-confirm placeholders honest (no guessed owners)?
6. **Cross-charter wiring (E1/E2 + E7/E8).** Do `ReasonCode`, `DomainProfile`, `ContextProduct`, `MemoryContextPlan`, `MemoryFlowCertificate`, the proof spine, and `PromptShellVariant` deliver what DOC81 and DOC84 will need? Name any contract a consumer can't bind to.
7. **Deferral triangle integrity.** §16.2 ↔ §15.4 ↔ §17.4 — is every deferral genuinely tracked, and is anything marked "deferred" that should actually be resolved in E0?
8. **NAMED-only scoping.** For `MemoryMutationEnvelope`, `MemoryProvenanceGraph`, `ResumeProjection`/`ResumeCard`, `FinalPromptTruthRef` — is the scope tight enough that Stage 7 can write the body without re-deciding architecture? What's missing?
9. **Internal consistency.** Any two sections that now disagree (enum values, counts, owners, invariants) after the integration?
10. **Ratification readiness.** Is this draft an A/A+ foundation a downstream charter author can build on without hitting an undefined seam? If not, what specifically blocks it?

---

## 5. Output

A single Markdown document. Tag findings `BUG / GAP / SUGGESTION / CONFIRMED / BETTER_IDEA / ARCHITECT_STOP / OUT_OF_SCOPE_ADVISORY`. Cite §+line for every finding; for proposed changes give paste-ready (or near-paste-ready) spec text anchored to the draft. Structure:

1. **Summary + verdict** — one of `RATIFY` (no blocking design defects) · `MINOR_FIXES_THEN_RATIFY` (small list, each with a fix) · `DESIGN_REVISION_NEEDED` (a real design problem in the integrated whole) · `ARCHITECT_STOP` (family-level issue — should be rare; architecture is settled). State the single biggest strength and weakness.
2. **Per-finding sections** for the §1 lenses and the §4 questions, value-tiered: **Blocking** / **Substantive** / **Minor** / **Considered-and-declined** (show the value-vs-cost reasoning on anything you decline — this tier is load-bearing).
3. **Schema grades** — load-bearing schemas A/B/C/D with one-line reasons.
4. **Cross-charter wiring** — the E1/E2 + E7/E8 binding check result.
5. **Ranked top changes** (if any) — the 5 highest-leverage, ordered.

Match the depth of the original E0 red-team and the Stage 5R synthesis (the benchmark). If you find nothing blocking, say so plainly and recommend `RATIFY` — that is the goal of a final pass on a well-worked spec.

---

## 6. Delivery

Produce the review as **one Markdown document in your reply.** Will saves it to `Memory Rebuild Docs/Flattening/Reviews/Stage 6 Reviews/Stage 6 E0 Red Teaming/E0_Design_Review_<your_model_name>.md`. **Start by** confirming repo access, the file's current line count, and your one-line bottom-line; then the review. If you can't reach the repo, stop and tell Will.

**You are the final design gate on the foundation of the DOC80 family. Read it whole; judge whether it's ready.**