Elnor Repo Reader

# ELNOR Session Carryover — 2026-06-08 → next session (E3/E4 / DOC82 in flight)

*Paste this into the new chat window. It is a complete working brief: status, the red-team/charter workflow that's proven out, working instructions (CODEX bridge, approval discipline, etc.), the recent E3/E4 decisions, and filing locations. You are continuing as Will's ELNOR architecture collaborator.*

---

## 0. First actions in the new session
1. This is the **Elnor Memory Rebuild** project. Per the project instructions, the **stable architectural context** is `ELNOR_UNIFIED_CARRYOVER_PROMPT.md` in `Elnor Specs/Active Working and Red Team/Instructions and Prompts/`, and **volatile/current state** is the dashboard in `Elnor Specs/OP-A and Operations and Trackers/`. This document is the *session-specific* layer on top of those.
2. Repo: local `/Users/OpenClaw1/Elnor/Elnor Specs/` (GitHub `wbrody/Elnor-Specs`, branch `main`). Read by path; no attachments needed.
3. **Standing rules that never change:** **do NOT run git — Will commits manually.** **Discuss + get explicit approval before creating/modifying spec content** (status/tracker files are fine to edit freely). **No version suffixes on new filenames** (git is the version record). **No-phantom rule** — every contract/field/lint/fixture traces to a citation or is flagged `OPEN_FOR_ARCHITECT_REVIEW`. **Verify before asserting** — grep the actual file, never trust a self-report or a status stamp. Use **AskUserQuestion** for genuine architect decisions. **Store everything** (analyses, cards, commissions go in the repo).

## 1. WHERE WE ARE (status)
The **flattening** reorganizes ELNOR's memory system into the **DOC80 family — 8 members**, drafted as Stage-6 "charters" (the contract layer: paste-ready TS interfaces + owner tables + lifecycle + unhappy paths + lints/fixtures + invariants + cross-charter wiring, heavily citation-annotated). Charters → Stage 7 schema bodies → Stage 8 fixtures → Stage 9 lints → graduation to `Current Specs/DOC8#/`.

**The 8 members + slice names:**
- **DOC80** core (E0) — **RATIFIED 2026-06-01**
- **DOC81** Scope & Policy (E1/E2) — **RATIFIED 2026-06-08** (R3.1)
- **DOC82** Knowledge + Source/Evidence (E3/E4) — **CHARTER DRAFTING NOW** (Claude Code running the R1 draft; Will brings it back to the new window)
- **DOC83** Extraction + Temporal (E5/E6) — next after DOC82
- **DOC87** Organization & Membership (E_org, inserted between E6 and E7)
- **DOC84** Delivery + Prompt + Proof (E7/E8) — *(this is the injection/delivery plane; the legacy DOC24/KDA become rendering machinery under it)*
- **DOC85** Learning (E9)
- **DOC86** UI / Inspector (E10)

Topological order (acyclic `schema_import`): `DOC80 < DOC81 < DOC82 < DOC87 < DOC83 < DOC84 < {DOC85, DOC86}`.

**Immediate state:** DOC82's R1 charter draft is being produced by Claude Code per the commission at `…/E3_E4_DOC82_Knowledge_Source_Evidence/E3_E4_Drafting_Commission_Claude_Code.md`. When Will returns the draft, the next step is the **fidelity audit** (see §3).

## 2. THE CHARTER WORKFLOW THAT WORKS (the rhythm — proven on E0 + DOC81)
For each charter pair:
1. **Scaffold** — `Charter_Opening_Brief.md` (draft targets, owned objects, lockstep, exit criteria) + `Charter_Input_Deck.md` (OPA rows, ADQs, Owner Map rows, Import Graph edges, Skeletal fold-ins, seams). Architect approves scope. *(Scope is usually already settled by the Stage 1–5 planning baseline — don't re-litigate it.)*
2. **Pre-charter analysis** (only if the Stage-6 index pins "resolve before drafting" items) — research + resolve, architect confirms. *(DOC82 needed this; E0/DOC81 didn't.)*
3. **Drafting commission** (Claude Code) → R1 draft.
4. **Fidelity audit** (CODEX or orchestrator-direct) — did the draft faithfully realize the commission + bind correctly + invent nothing? A pre-red-team screen, NOT a design review.
5. **Multi-model design red-team** — fresh ChatGPT 5 Pro + Claude (+ optionally Grok/Codex), each running a **TWO-PART** review: **Part A** = did the work land well / consistent with the rest of the planned + current specs; **Part B** = a *fresh substantive pass* (new bugs, missing/inconsistent contracts, better/simpler patterns, the A/A+ gap). **This is binding: every round is substantive, not just mechanical.** A "confirm-only, looks fine" review is a failed review unless the reviewer shows the work (walked cases, attempted breaks).
6. **Adjudication card** — dedupe findings across models/rounds, adjudicate each (accept/modify/decline + reasoning + exact spec change), **value-tier** them (Blocking / Substantive / Minor / Considered-and-declined). **Synthesis discipline (binding):** include EVERY fix with positive net value; exclude only items that are BOTH low-value AND high-cost, with reasoning shown. Resolve open flags; reconcile verdicts; surface architect fork-decisions. Then a **coverage audit** of the card (every reviewer finding dispositioned — no silent drops).
7. **Apply** (Claude Code commission, or orchestrator-direct for small sets) → next revision (R2, R3, …). **Merge seams between two review bodies are the highest-risk lines** — re-derive merged behavior, don't paste.
8. **Application-fidelity audit** (CODEX) — did the application land exactly as the card directs; self-report accuracy is itself audited.
9. **Delta design re-review** (scoped) once close — only the changed sections, walk the prescribed cases; "ratify after minor fixes" is a valid outcome.
10. **Ratify** (`Ratification.md` with the full basis chain + architect rulings + sign-off line) + **discharge sweep** (Owner Map rows, Retired Names, SM, RUN_STATE, STAGE_6 index, OPA, ADQ landings; SPEC_STATE row deferred to graduation).

**Multi-model earns its keep** — repeatedly each model caught real defects the other missed (e.g., on DOC81 R3: Claude caught a render egress-floor skip GPT rated "mostly fine"; GPT caught a cache-key principal gap Claude under-rated). Always run ≥2.

## 3. WORKING INSTRUCTIONS / TOOLS
- **CODEX bridge (agent-CLI automation):** `codex` CLI is installed in the Cowork sandbox; auth is Will's ChatGPT-plan login copied to `/Users/OpenClaw1/Elnor/.codex-auth/auth.json` (outside the repo). The orchestrator can run `codex exec` against the repo and read its report. **Standing default: `-c model_reasoning_effort=xhigh`** for audits/reviews. **Detached-run hygiene:** launch via `setsid bash -c '... ; touch <sentinel>.DONE'` + `disown`; poll the `.DONE` sentinel (not process-grep, which self-matches); match the process by binary path `\.local/bin/codex`. **KNOWN LIMIT:** heavy multi-minute runs **die when the Cowork sandbox suspends on idle/restart** — each bash call is an ephemeral sandbox, so a backgrounded job is torn down at the call boundary. The bridge is reliable for **quick** runs or **with Will present** (active polling); for heavy unattended audits the orchestrator does **direct verification** instead, or Will runs ChatGPT/Claude in their apps. *(This durability gap is logged as a build requirement for the DOC11 external-agent adapter — see `OP-A and Operations and Trackers/CAPABILITY_NOTE_EXTERNAL_AGENT_CLI_ADAPTERS.md`.)* Capture: the file-bus pattern (commission in repo → agent runs against working dir → report back to repo) is the durable channel; it doubles as a prototype of how ELNOR itself will orchestrate Claude/Codex at build time.
- **Engines for the build (captured, not yet built):** ELNOR will embed the **Claude Agent SDK** (subscription-billed via Claude Code OAuth — NOT API key; an exported `ANTHROPIC_API_KEY` silently overrides and bills API, so keep it out) + the Codex SDK, gated through the already-ratified egress machinery. DOC11 proposal for the adapter is commissioned (`Active Working and Red Team/Instructions and Prompts/DOC11_External_Agent_Engine_Adapter_Proposal_Prompt.md`).

## 4. RECENT DECISIONS — E3/E4 / DOC82 (the truth plane)
DOC82 owns the **Assertion family** (full lifecycle/state machine), the **warrant ladder** (EpistemicKind/UseWarrant/EffectiveWarrant), **evidence + source envelopes**, and **bitemporal axes** (`valid_time`/`transaction_time` — serves Will's litigation "what did I know as of date D" queries). It does NOT own CU semantics (DOC73), source artifacts/corpus (DOC25), graph storage (DOC72), policy/scope (DOC81), or Library/membership (DOC87). ABC R0.2 is **senior for SEMANTICS** (DR-001); the **Owner Map is canonical for PLACEMENT** (D-SEED-2) — re-homed schemas defined at DOC82 only.

**Two pre-conditions RESOLVED (full analysis: `…/E3_E4_DOC82_…/Pre_Charter_Analysis_ADQ202_ADQ219.md`):**
- **ADQ-202 (corpus hierarchy):** DOC82 owns the **`SourceEnvelope` interface + pointer types + consumption contracts, NO container schemas.** The user-facing **Library** (DOC87/DOC26/DOC81 — curated set + treatment + access policy) is DISTINCT from the ingestion **Corpus** (DOC25). `SourceEnvelope` is **library-agnostic + multi-membership-safe** (one content-deduped source, many memberships).
- **ADQ-219 (CU reconciliation): DIRECT CONSUME.** DOC73's `ConsolidatedUnderstanding` already matches ABC §4.5's source-bound-synthesis contract (spans required; never canonical reusable truth). Consume directly via a thin contract; the `SourceBoundSynthesisAdapter` is **documented-not-built** (escape-hatch note only). Three guardrails: **R-CU-1** no-spans CU can never support an Assertion (Will's legal-work-product safety rule); **R-CU-2** DOC73 `cu_authority` ≠ DOC82 warrant; **R-CU-3** a CU is synthesis, not evidence (no auto `EvidenceSupportEdge`).

**Four architect-discussion locks (binding on the draft):**
- **(A) `principal_authored` epistemic kind** — Will's own statements (esp. statements of law) are first-class sources (author = principal; span = the statement), with an **"orient/hypothesize, do NOT cite as controlling authority"** warrant profile in the `(temporal_class, epistemic_kind)` validity table (ADQ-314). **MINIMAL lock only** — the deeper provisionality / claim-vs-directive / injection-weight work is **deferred + tracked at the new ADQ-223** (do not over-build).
- **(B) Adapter documented, not built** — no dead schema.
- **(C) Indexed = source-memory** — **Linked** (accessible on demand) < **Indexed** (the source IS durably in memory — `SourceEnvelope` + DOC25 doc-intelligence; retrievable/citable; NO mined knowledge) < **Learned** (Indexed + DOC83 extraction → Assertions/CUs). "Source in memory" (Indexed/Learned) is distinct from "knowledge mined from it" (Learned only). DOC26's "Indexed is not a memory lane" is imprecise — it means "not an extracted-knowledge lane." Treatment statuses are DOC87/DOC26/DOC81, not DOC82.
- **(D) Extraction origin-stamp lock (load-bearing)** — a source can be Learned in Library A and Indexed in Library B (same source, multi-membership). **Treatment gates extraction, not injection.** `AssertionCandidateEmission` (DOC82 contract, DOC83-produced) MUST carry the **originating library/scope membership**, so the canonical Assertion inherits scope (DOC81) + membership (DOC87); DOC84 then injects by **active-scope eligibility**, never per-document treatment. Lint `assertion.emission_missing_origin_scope_membership`. This is what makes multi-treatment coherent.

**The Library model (Will's, confirmed via DOC26 R0.4):** a Library = a *curated selection of sources treated a certain way* (Linked/Indexed/Learned), NOT a Matter. A Project (matter) contains multiple libraries; the same document lives in multiple libraries with different treatments; libraries are reusable across matters (e.g., a "2nd-Circuit securities law" library). Organization = DOC87 + DOC26 (UI surface) + DOC81 (treatment/access policy).

**New: ADQ-223 (open, batch)** — principal-authored content provisionality / claim-vs-directive / injection-weight, deferred across DOC73 (CU provisionality)/DOC82 (epistemic sub-kinds)/DOC85 (settled-vs-tentative learning)/DOC84-KDA (weight + framing). DOC82 lands only the minimal `principal_authored` lock. Note: change-of-mind itself is ALREADY handled — DOC73 PBE `VersionedClaim`/`supersedes` lineage + retraction cascade (GIE/KIE are just graph/knowledge substrate primitives, not the belief-revision engine).

## 5. FILING LOCATIONS (key paths under `Elnor Specs/`)
- **Charters:** `Memory Rebuild Docs/Stage_6_Charters/E#_…/` — each folder holds the Opening Brief, Input Deck, drafting commission, the `*_Charter_Draft.md`, `Reviews/`, adjudication cards, fidelity/fix records, `Ratification.md`.
  - DOC82 in flight: `…/Stage_6_Charters/E3_E4_DOC82_Knowledge_Source_Evidence/` — `Charter_Opening_Brief.md`, `Charter_Input_Deck.md`, `Pre_Charter_Analysis_ADQ202_ADQ219.md`, `E3_E4_Drafting_Commission_Claude_Code.md` (the draft is being written to `DOC82_Knowledge_Source_Evidence_Charter_Draft.md`).
  - DOC81 (ratified): `…/E1_E2_DOC81_Scope_Policy/` — `DOC81_Scope_Policy_Charter_Draft.md` (R3.1, 2,718 lines), `Ratification.md`, the R1/R2/R3 adjudication cards, `Reviews/`.
  - DOC80 (ratified): `…/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` + `Ratification.md`.
- **Baseline (ratified placement/architecture):** `Memory Rebuild Docs/DOC80 Target Baseline/` — `Owner Map/DOC80_Owner_Map.md` (canonical placement), `Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`, `Import Graph/`, `Retired Names/`.
- **Trackers/ops:** `OP-A and Operations and Trackers/` — `OPA_V4.md` (obligations), `SPEC_STATE.md`, `dashboard.html`, `CAPABILITY_NOTE_EXTERNAL_AGENT_CLI_ADAPTERS.md`.
- **Flatten ledger:** `Memory Rebuild Docs/Flattening/Execution Ledger/` — `Master/RUN_STATE.md` (current: Stage 6, E0+DOC81 ratified), `Architect Decision Queue/Architect_Decision_Queue.md` (50 ADQs; ADQ-222 + ADQ-223 open), `Stage_5R3/STAGE_6_CHARTER_INPUT_INDEX.md` (per-DOC charter inputs).
- **Reference specs consumed by DOC82:** `Current Specs/DOC73/` (CU — Artifact1 §8.2, Artifact3 §9.2), `Current Specs/DOC25/` (source artifacts/corpus), `Current Specs/DOC26 UnifiedWorkspaceLibrary/` (Library/Project surface), ABC R0.2 at `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_…_2026-05-25/12_ABC_Consolidated_Structural_Patch_R0_2.md`.

## 6. IMMEDIATE NEXT STEPS (when the DOC82 R1 draft returns)
1. **Independent fidelity audit** of the draft against the commission + the four locks + the resolved pre-conditions (CODEX with Will present, or orchestrator-direct). Verify: bitemporal axes present; the origin-stamp lock on `AssertionCandidateEmission` + its lint; `SourceEnvelope` library-agnostic; CU direct-consume with R-CU-1/2/3; `principal_authored` minimal only (not over-built); ABC §7.8 enums DOC82-only; no E0/DOC81 re-declaration; `OPEN_FOR_ARCHITECT_REVIEW` ≤ 5.
2. **Multi-model two-part design red-team** (ChatGPT + Claude), then **adjudication card** → apply → re-audit → delta review → **ratify** + discharge.
3. Then **E5/E6 (DOC83 Extraction + Temporal)** — note DOC82 hands it `AssertionCandidateEmission` (with the origin stamp), and DOC83 produces instances into that contract.

## 7. EASY-TO-LOSE CONTEXT
- Delivery/injection = **DOC84** (not DOC24; DOC24/KDA render under it).
- **EC** is the sole durable writer + executor (`dependency_status = partial/moving`); DOC82 defines contracts, EC executes writes/warrant/resolution.
- **DOC81's product rulings (ratified, still binding everywhere):** internal-use-permissive / egress-gated (privilege is an egress concern, not an internal barrier; the four internal-block bases are wall / revoked-source / sealed-PO-outside-matter / malformed-record); silent restamps (human approval only for ethical-wall crossings); surface-keyed notices (specific in-app, generic in outputs, walls invisible); privacy-topic ambiguity = don't-save-reviewable; Phase-2 multi-principal readiness (principal keys mandatory).
- **Not-evidence guardrail** (recurring): CUs, RecentActivityRollup, orientation signals are NOT evidence — must never auto-create an `EvidenceSupportEdge` or self-authorize an Assertion.
- ELNOR is a local-first personal OS on a single M4 Pro MacBook; first/primary use is Will's securities-litigation practice, but specs stay work-type-agnostic in the view. Full networking is Phase 2 (Phase 1 must be ready for it).