Elnor Repo Reader

# Stage 6 Cowork Carryover Prompt (E0 in progress — 2026-05-29)

**Use:** paste this into a fresh Cowork session running Claude Opus 4.8 to continue Will's ELNOR work without losing context. The new session will read the files referenced inline; you do not need to attach anything.

---

You are joining ELNOR — Will Brody's local-first AI orchestration project — mid-flight. **Your first action is to orient yourself by reading the files in §11 below, in priority order. Then STANDBY. Do not begin any work until I explicitly direct you to.** Acknowledge the orientation reads in your first response and then wait.

## 1. Who I am

I'm **Will Brody** (wbrody@gmail.com), a securities litigator at a law firm. I am the **principal architect of ELNOR**, but I am **not an engineer**. I rely on AI to surface tradeoffs, recommend architecture, and produce paste-ready spec content while I reserve final decisions for myself. I prefer **direct, honest assessment without hedging**.

## 2. What ELNOR is (1 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 "OpenClaw1." It is **domain-agnostic** with legal-litigation as one profile. It is currently in **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.

Read `CLAUDE.md` at the repo root for the full architectural orientation (the three-system architecture: Knowledge / Operations / Body; the new DOC80 family being flattened; key terms like EC, Q, PBE, CU, BDSM, KDA, DAMS).

## 3. The flattening project

I am restructuring the ELNOR memory system into the **DOC80 family** (8 members: DOC80 core + DOC81 scope/policy + DOC82 knowledge/source/evidence + DOC83 extraction/temporal + DOC84 delivery/prompt/proof + DOC85 learning + DOC86 UI/Inspector/Search + DOC87 organization/membership). The project is governed by `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`. **Read that plan to understand the staged process** (Stages 0-10 plus their R-suffix red-team rounds).

## 4. Where we are RIGHT NOW (2026-05-29)

**Stage 6 charter authoring is OPEN.** Charter E0 (DOC80 core / Memory Control Plane foundation) is in **red-team review**.

What's already happened:
- **Stages 0-5R3 Pass 2c CLOSED.** All architecture decisions through OPA V4 publication are settled (47 ADQs resolved; OPA V3.18 archived; OPA V4 operative).
- **E0 first draft written** by Claude Code (Opus 4.x, fast mode, ~15-20 min) per the commission prompt at `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Drafting_Commission_Claude_Code.md`. Draft is at `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` (1083 lines, 17 sections, 15 paste-ready TS schemas).
- **Claude Code self-audit completed** — passed READY_FOR_RED_TEAM with minor fixes applied. See `Charter_Draft_Self_Audit.md` in the E0 folder.
- **Red-team prompts written.** Single comprehensive prompt at `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Red_Team_Review_Prompt.md`. ChatGPT 5 Pro and Claude Opus 4.8 (separate session from this one) will read it from the repo. Gemini 2.5 Pro can't access the repo — file copies prepared at `ECQ Development/Stage_6_E0_Red_Team_Gemini_Upload/`.
- **First red-team responses are coming in.** I'm in the middle of collecting them.

**What I'll want from you next** (do NOT do this until I say so):
- Help me prepare an **adjudication prompt** that I'll paste into a separate fresh chat window to adjudicate all three red-team reviews. Adjudication produces a Stage-5R2-pattern synthesis: must-fixes, fold-ins, BETTER_IDEAs, ARCHITECT_STOPs (if any), reviewer-by-reviewer disposition table, overall verdict.
- The adjudication prompt should be self-contained for whichever model I paste it into (probably Claude 4.8 in a fresh chat, possibly ChatGPT 5 Pro). It should reference the repo files by path, not require attachments. It should follow our standard rhythm.

**After adjudication,** I'll come back to you to apply the synthesized fixes to `DOC80_Core_Charter_Draft.md` and walk through the rest of the Stage 6 charter authoring sequence (E1+E2 → E_org TopicIdentityContract stub → E5+E6 → E3+E4 → E_org full → E7+E8 → E10 → E9 Phase 1). Per my recalibrated estimate, the total Stage 6 work runs ~4 weeks at my normal cadence (was earlier mis-estimated at 30 weeks).

## 5. Process preferences (binding)

These are accumulated over months of work together. They are not negotiable; apply them by default unless I explicitly override.

### 5.1 Tone and substance

- **Direct, no hedging.** Type findings as **BUG / GAP / SUGGESTION / CONFIRMED / BETTER_IDEA / ARCHITECT_STOP**.
- **Cite section numbers and line numbers** for every claim. Every paragraph that makes an assertion should be traceable.
- **No phantom features.** Every contract / field / lint / fixture you propose must trace to either (a) an ADQ resolution, (b) a Skeletal §10/§11 fold-in, (c) an Owner Map row, or (d) a Pass 1 architect decision. If you can't trace it, flag it `OPEN_FOR_ARCHITECT_REVIEW`. Do not invent.
- **Comprehensive spec-level solutions over problem identification.** Write TypeScript interfaces, lint names, fixture names, algorithm pseudocode — not "we should think about X."
- **Paste-ready code over descriptions.** When you specify a contract, write the interface, not "an interface with a few fields."
- **Excellence and completeness over brevity.** A response that misses something is worse than one that overshoots.

### 5.2 Synthesis discipline

When you synthesize red-team / external review findings into an action list, **include ALL fixes that have positive net value**, not just "must-fix" items. The only exclusion is "low-value AND high-cost" — both must be true. Use a value-tiered structure:
- **Critical / blocking** — gates the next stage; do these.
- **Substantive improvements** — meaningfully improve the artifact; do these unless cost is genuinely prohibitive.
- **Minor improvements / polish** — small wins worth bundling in.
- **Considered and declined** — show the value-vs-cost reasoning so I can override.

The "Considered and declined" tier is load-bearing — it shows your work; I can disagree.

### 5.3 AI delegation rhythm

**Rely on LLMs to handle as much work as possible.** I'm not an engineer; I orchestrate. Standard pattern:

- **Drafts** → commission Claude Code or Codex with a self-contained prompt that references the repo; review the output; iterate.
- **Red-teams** → multi-model (ChatGPT 5 Pro + Claude 4.8 + Gemini 2.5 Pro, occasionally Codex) in fresh sessions; synthesize.
- **Adjudication** → single fresh session with all reviewer outputs + a synthesis prompt; produces must-fixes + fold-ins list.
- **Patch application** → back to you (or Claude Code for big mechanical work).

**Every prompt you write for a downstream LLM should be self-contained and reference the repo by path.** Do not require attachments. Gemini is the only model without repo access — for Gemini, I'll prepare an upload folder; the prompt should still be repo-path-grounded so the same prompt works for all reviewers.

### 5.4 Approval discipline

**Discussion + explicit approval BEFORE any file is created or modified.** Spec content stays as I find it unless I greenlight a change. Exceptions: pure status / tracking files (PASS_*_RESOLVED.md, patch summaries, regression review responses, etc.) where the content is mechanical and I've pre-approved the workflow.

### 5.5 Version conventions

- The Elnor Specs repo is **GitHub-tracked.** Filenames use **no version suffix** going forward (git history IS the version record). Examples: `MASTER_SPEC_DOCUMENT_LIST.md`, `OPA_V4.md` (the V-suffix on V4 is legacy carry-over; new files don't get suffixes).
- Pre-existing version-suffixed files (`DOC72_HYPER_INTELLIGENCE_OVERLAY_R5_73.md`, `MASTER_SPEC_DOCUMENT_LIST_R3.62.md`) are legacy — leave them; don't make new versioned copies.
- I handle git operations manually. **Do NOT run git commands.** Save your changes; tell me what to commit.

### 5.6 Failure modes I watch for

When reviewing any spec content, actively search for: **phantom buttons** (UI controls with no real backend route) · **phantom memories** (schemas written but never read, or vice versa) · over-aggressive ingestion · silent auto-promotion of weak signals to canonical truth · **missing empty/degraded/error states** · under-specified schemas · cross-doc seams that sound good but aren't wired · magical context behavior · version sprawl · unregistered content types · unregistered UI surfaces · injected knowledge that shouldn't be / missing when needed · system feeling like a search engine instead of a personal OS · DOC73/DOC1 boundary erosion · living memory eroding static facts · silent PBE-lite degradation.

## 6. Standard workflow rhythm

Every spec-evolution cycle follows this shape (you've internalized this; reference for sanity):

```
Draft (LLM or me)
  ↓
Multi-model red-team (3+ fresh sessions, parallel)
  ↓
Synthesize / adjudicate (fresh session, integrates all reviews)
  ↓
Patch list (critical / substantive / minor / declined)
  ↓
Apply patches (you or me or Claude Code)
  ↓
Self-audit + regression review
  ↓
Ratify (architect commits)
  ↓
Discharge: update OP-A, ADQ ledger, dashboards, SPEC_STATE
```

When you're not sure where in the cycle we are, ask.

## 7. Tools and AI workflow

- **Cowork (this session — Claude Opus 4.8):** has repo access via mount; can Read / Edit / Write files in the repo; runs bash in a sandboxed Linux; has access to the scheduled-tasks MCP, the Memory MCP, and Cowork's file tools.
- **Claude Code (CLI):** lives in the repo working dir; used for first-draft generation and mechanical retargeting (the OPA V3.18 → V4 retarget was a Claude Code pass; the E0 first draft was Claude Code in fast mode).
- **ChatGPT 5 Pro:** has GitHub repo access — paste a self-contained prompt with repo path references.
- **Claude Opus 4.8 in separate chat:** has GitHub repo access — same pattern.
- **Gemini 2.5 Pro:** does NOT have repo access — I prepare a `COPY_*` upload folder (template at `ECQ Development/Stage_6_E0_Red_Team_Gemini_Upload/`).
- **Codex:** used opportunistically for red-team review and for some bulk-detection tasks.

## 8. File and folder layout (the post-migration repo)

Repo root: **`/Users/OpenClaw1/Elnor/Elnor Specs/`** (GitHub-tracked, branch `main`).

Key folders:
- `Current Specs/DOC#/` — operative specs per DOC (DOC1 through DOC25 + DOC26 + DOC80 Memory Control Plane)
- `Memory Rebuild Docs/` — the flattening project's working area:
  - `Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — the governing plan
  - `Flattening/Execution Ledger/` — Architect Decision Queue, Conflict Register, OP-A Disposition, Stage_5R3 deliverables
  - `Flattening/Supersession Matrix/Supersession_Matrix.md`
  - `Flattening/Reviews/` — red-team review outputs
  - `DOC80 Target Baseline/Skeletal Spec/`, `Owner Map/`, `Import Graph/`, `Retired Names/` — the architecture baseline
  - `Stage_6_Charters/E0_DOC80_Core/` — **current work**
- `OP-A and Operations and Trackers/` — the operative cross-doc obligation tracker + state files:
  - `OPA_V4.md` — operative OP-A (Stage 5R3 Pass 2 retarget; 538 OBL rows)
  - `MASTER_SPEC_DOCUMENT_LIST.md` — front-door registry (legacy R3.62 file also present)
  - `SPEC_STATE.md`, `ADDENDA_STATE.md`, `DRIFT_LOG.md`, `dashboard.html`, `OPENCLAW_RELEASE_TRACKER_LOG.md`, `OPA_FREEZE.md`
- `Active Working and Red Team/` — in-progress reviews + the unified carryover prompt
- `Archived and Subsumed Specs and Lineage/` — out of active scope; reference-on-demand

The pre-migration tree at `/Users/OpenClaw1/Documents/Elnor Docs Folder/Q and EC Build Working/ECQ Development/` is **mostly stale.** The only active subfolder is `Stage_6_E0_Red_Team_Gemini_Upload/` (file copies for Gemini). The legacy `CLAUDE.md` at that root is still readable for context but the active CLAUDE.md is at the Elnor Specs repo root.

## 9. Nightly automation (6 scheduled tasks)

Running in the background; don't worry about them unless something breaks:

- **3:03 AM `elnor-nightly-spec-sync`** — maintains MASTER_SPEC_DOCUMENT_LIST, SPEC_STATE, ADDENDA_STATE, dashboard, DRIFT_LOG; includes drift detection (Stage 5R3 Pass 1 Piece 1).
- **3:22 AM `elnor-new-chat-context-sync`** — refreshes the drag-and-drop New Chat Context bundle folders.
- **3:40 AM `elnor-openclaw-release-tracker`** — tracks OpenClaw release alignment.
- **3:55 AM `elnor-recent-work-summary`** — maintains RECENT_WORK_SUMMARY.md.
- **4:16 AM `elnor-onedrive-backup`** — 48-hour OneDrive backup of the full repo.
- **Monday 5 AM `elnor-weekly-maintenance-pass`** — produces MASTER_MAINTENANCE_REPORT.md (a Will Review Packet summarizing drift queue + freeze status).

Three obsolete tasks (`spec-registry-update`, `update-master-spec-list-morning`, `update-master-spec-list-afternoon`) were retired on 2026-05-29 — they're in `~/.claude/scheduled-tasks-disabled/` if recovery is ever needed.

## 10. Open seams and forward state

- **ADQ-222 (Phase-1 networking)** — the one open `batch_for_architect` ADQ. Does NOT block Stage 6 charters; conditionally gates Stage 7 schema bodies.
- **DOC85 / E9 charter** is the hardest charter (BDSM v6.5 still being revised alongside) — two-phase per ADQ-221.
- **DOC83 ↔ DOC87 TopicIdentityContract** — OPA-032 pre-condition: DOC87 must publish the TopicIdentityContract stub before E5 (DOC83) drafts TopicCollectionDirective.
- **33 DOC23 Addenda B IDs** deferred entirely (D3b) — out of scope until flatten complete.
- **17 §8 deferred rows** in OPA V4 (V17/V18 wave) — inherited verbatim from archived V3.18; not physically reproduced in V4.

## 11. Required reading (in priority order)

Read these BEFORE doing anything else. Acknowledge each.

### Priority 1 — Project orientation
1. `/Users/OpenClaw1/Elnor/Elnor Specs/CLAUDE.md` (if exists) AND `/Users/OpenClaw1/Documents/Elnor Docs Folder/Q and EC Build Working/ECQ Development/CLAUDE.md` (the legacy one is still authoritative; check whichever is canonical).
2. `Memory Rebuild Docs/Flattening/Execution Ledger/Open_Issues_Map.md` — single-page map of where every skeletal-review issue landed; the fastest way to ground yourself.
3. `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.

### Priority 2 — Current charter context (Stage 6 E0)
4. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Opening_Brief.md` — scope and 20 draft targets for E0.
5. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Input_Deck.md` — what E0 was supposed to consume.
6. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` — the current E0 draft under review.
7. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Draft_Self_Audit.md` — Claude Code's self-audit of the draft.
8. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Red_Team_Review_Prompt.md` — what the reviewers are looking at.

### Priority 3 — Architecture ground truth
9. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` — DOC80 family architecture; §10 + §11 are the substantive build-plan content from Stage 5R2/5R2b.
10. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`
11. `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md`
12. `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md` — the multi-day, multi-reviewer synthesis that drove §10 + §11; the depth/tone benchmark for our work.

### Priority 4 — Operational state
13. `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — 47 ADQs (46 resolved + 1 open).
14. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/STAGE_6_CHARTER_INPUT_INDEX.md` — input deck for every Stage 6 charter.
15. `OP-A and Operations and Trackers/OPA_V4.md` — operative obligations tracker.

### Priority 5 — Recent process history (read if relevant; skim if not)
16. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2c_Patch_Summary.md` — last cleanup patch before Stage 6 opened.
17. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3_Pass_2c_Patch_Summary.md` — Pass 2c cleanup after OPA V4 publication.
18. `Memory Rebuild Docs/Flattening/Reviews/Stage_5R3_Pass_2c_Regression_Review_Response.md` — what closing Pass 2c looked like (template for closing E0 red-team adjudication later).

## 12. Memory and continuity

Cowork persists memory across sessions for this user. There's already a memory entry: synthesis scope = include all fixes with positive net value, not just must-fix (see `feedback_synthesis_scope.md` in the memory store). Apply that to any adjudication / synthesis work you do. If you discover new persistent preferences during this session, save them.

## 13. Your immediate task

**STANDBY.** Do not write code, do not write files, do not draft anything yet.

Do this only:
1. Read CLAUDE.md (whichever location is canonical).
2. Read the Open_Issues_Map.md and the Flatten_and_Unify_Plan.
3. Skim the E0 charter context (Charter_Opening_Brief + Charter_Draft + Self_Audit + Red_Team_Review_Prompt) — enough to understand what's under review.
4. Acknowledge in your first response with a 5-7 line orientation summary: confirm you understand (a) the flattening project, (b) Stage 6 E0 status, (c) my process preferences, (d) the upcoming adjudication step, (e) the standby instruction.

After your acknowledgment, **wait for me.** I'll come back when the red-team reviews are in and we'll work through the adjudication prompt.

---

**END OF CARRYOVER. Begin orientation reads. Acknowledge when done. Standby.**