Elnor Repo Reader

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

---

# Stage 5R3 Pass 2 — Commission Prompt for Claude Code

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Session type:** Fresh Claude Code session in the repo working directory.
**Authority:** Will Brody (architect). All architect decisions for this pass are pre-resolved in `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`. You do NOT need to ask Will mid-pass except where this prompt explicitly says so.

---

## 1. Mission

Produce the seven Stage 5R3 Pass 2 deliverables listed in §4 below. These collectively constitute the OP-A V4 candidate + Stage 6 charter input deck.

You are retargeting OP-A V3.18's 528 §6 active obligation rows against the post-flatten DOC80 family architecture per the architect decisions in Pass 1. You are NOT making new architecture decisions. Where Pass 1 left a decision open, this prompt or the resolved-decisions file gives you the answer.

## 2. Read first (mandatory, in this order)

1. **`PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`** — Will's resolved decisions for the 13 items Pass 1 surfaced. **THIS IS THE LOAD-BEARING FILE.** Every Pass 2 row decision must trace to either (a) a Pass 1 architect decision here, (b) a resolved ADQ row in the Architect Decision Queue, (c) an OPA-031–035 obligation row, or (d) a DOC80 family member's named ownership in the Owner Map / Skeletal / Import Graph.
2. **`Stage_5R3_Source_Package.md`** — input manifest. Verify the sha256 hashes match the live files before reading any source. The two DOC80 baseline files were refreshed at Stage 5R2c (2026-05-28); the source package hashes reflect that refresh.
3. **`Stage_5R3_Control_Board.md`** — Pass 0 state.
4. **`PASS_1_INVENTORY.md`** — coverage walk (147 MSL rows + 25 CURRENT-EXTRA rows; 4 seed + 40 ADQ + 8 conflict + 49 supersession matrix entries).
5. **`PASS_1_DISTRIBUTION_PREVIEW.md`** — heuristic destination counts.
6. **`PASS_1_ROW_SOURCE_DRIFT.md`** — drift analysis on the 54-row sample.
7. **`PASS_1_S9_TRIAGE.md`** — 28 §9 triage items.
8. **`PASS_1_MISSING_SOURCES.md`** — automated source-pointer drift.
9. **`PASS_1_SELF_AUDIT.md`** — Pass 1's own self-audit and residual limitations.

Then read the frozen DOC80 baseline (in `baseline_snapshot/`, not the live files):

10. **`baseline_snapshot/DOC80_Skeletal_Target_Baseline.md`** — sha256 `3976b29a69da`
11. **`baseline_snapshot/DOC80_Owner_Map.md`** — sha256 `461d138404b8`
12. **`baseline_snapshot/DOC80_Import_Graph.md`** — sha256 from source package
13. **`baseline_snapshot/DOC80_Retired_Names.md`** — sha256 from source package

Then read the operative OP-A V3.18 (live file, not a snapshot — but DO NOT modify it):

14. **`OP-A and Operations and Trackers/OPA_V3_18.md`** — 528 §6 rows. This is your input; Pass 2 produces an OP-A V4 candidate in the Execution Ledger, NOT a modification of V3.18.

Then the ledgers (live files, but again DO NOT modify):

15. **`Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md`**
16. **`Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md`**
17. **`Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md`**
18. **`Memory Rebuild Docs/Flattening/Execution Ledger/OP-A Disposition/OP_A_Candidate_Disposition.md`**

## 3. Plan / Runbook references

If you need to re-derive the Pass 2 method from first principles, the governing plan + runbook are:

- `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`
- `Memory Rebuild Docs/Flattening/Plans Runbooks Index/Stage_5R3_Audit_Runbook.md` (if present)

But: do NOT let plan-level discovery slow you down. The architect decisions are pre-resolved. Trust `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` as the operative direction.

## 4. Deliverables (write these — exact filenames, all into `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`)

### 4.1 `BUCKET_A.md` — high-confidence retargets

Every OP-A V3.18 §6 row whose post-flatten owner is unambiguous from the Owner Map and Pass 1 decisions. For each row:

- `opa_row_id` (existing V3.18 ID)
- `current_target_doc` (V3.18 value)
- `proposed_target_doc` (post-flatten — one of DOC80–DOC87 + named externals)
- `mapping_basis` (which Owner Map row / ADQ / OPA-031–035 / Pass 1 decision)
- `confidence` = `high`
- `legacy_id_aliases` (e.g. `OBL-DAMS-*` → kept as alias for the new DOC84 substrate row)
- `notes`

This is the bulk of the work. Most rows should land here.

### 4.2 `BUCKET_B_SPLITS.md` — mid-confidence row splits

Rows where the V3.18 obligation should split into multiple V4 rows because the post-flatten ownership distributes across two or more DOC80 members. Each split entry:

- `opa_row_id` (existing)
- `split_kind` = `owner_split` | `contract_split` | `executor_split`
- `proposed_v4_rows` (list of new rows with `proposed_target_doc`, normalized title, ownership cell)
- `confidence` = `medium`
- `mapping_basis`
- `architect_review_required` = `no` (these are mechanical splits derivable from Owner Map; if it requires judgment beyond mechanical mapping, push to Bucket C)

Examples of legitimate Bucket B splits: rows currently targeting `DAMS V5` that the Owner Map decomposes into DOC81 (threshold rule) + DOC84 (computation); rows targeting `Library` that decompose into DOC25 / DOC82 / DOC87 / DOC86; rows targeting "DOC8 runtime learning" that split into DOC85 architecture + BDSM substrate consumption.

### 4.3 `BUCKET_C_ARCHITECT_DECISIONS.md` — low-confidence — architect review

Rows where retargeting requires architect judgment beyond what `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` already covers. Each entry:

- `opa_row_id`
- `current_target_doc`
- `candidate_targets` (the 2-4 plausible owners with rationale)
- `recommended_default` (your best guess)
- `why_architect_judgment_needed` (one sentence)
- `blocks_what` (which Stage 6 charter or downstream artifact this gates)
- `proposed_ADQ` (if this needs a new ADQ row opened — give the question text)

Bucket C should be SMALL. If it's growing beyond ~10 rows, you're punting too much. Push items into Bucket A or B where the architect decisions resolve them.

### 4.4 `OPA_V4_CANDIDATE.md` — full V4 row deck

The composed result of applying Bucket A + Bucket B to V3.18. Format:

- Same header block as `OPA_V3_18.md` (Built-from line, row-count summary, change log table)
- §6 active obligation rows in V4 form — applies all Bucket A retargets and Bucket B splits
- §6 row count after Pass 2 (expect a small net increase from Bucket B splits)
- Add a `legacy_id_aliases` cell to every row that traces back to a V3.18 row ID
- Bucket C rows are RESERVED PLACEHOLDERS in V4 — they retain V3.18 target but carry a `pending_architect_review` flag and a pointer to the BUCKET_C entry

This is the candidate. Will reviews it, ratifies (or sends Bucket C decisions), and after ratification Will publishes it as the new live `OPA_V4.md`.

### 4.5 `STAGE_6_CHARTER_INPUT_INDEX.md` — charter-by-charter input deck

For each Stage 6 charter (E1 through E10 plus the DOC87 / E_org charter), list:

- All OPA V4 rows targeting that charter's owner doc
- All ADQ rows resolved-but-deferred-to-this-charter (e.g. ADQ-301 → E7; ADQ-302 → E5; ADQ-308 → E10)
- All Conflict Register entries deferred to this charter
- All Stage 5R2 / 5R2b skeletal §10/§11 fold-ins relevant to this charter
- The `minimum_completion_for_v5` for any AC-001/002/003/004/005 obligations that apply
- Any open seam (OPA-024 RecentActivityRollup E6 lint; OPA-032 DOC83↔DOC87 Topic identity; etc.)
- Required pre-conditions (e.g. E5 needs OPA-032 TopicIdentityContract stub before drafting TopicCollectionDirective)

This is what each charter author reads first when their slice opens.

### 4.6 `SECTION_15A_REWRITE_PREVIEW.md` — OP-A §15 prose update

OP-A V3.18 §15 contains narrative prose about scope, conventions, and discipline. Pass 2 produces a rewrite preview reflecting the 8-member family + post-flatten ownership conventions. Keep it brief — this is a preview, not a final draft. Cover: family naming convention, owner-cell discipline, legacy_id_aliases convention, charter-input cross-ref convention, bucket discipline carry-forward for future patch rounds.

### 4.7 `PASS_2_WILL_REVIEW_PACKET.md` — architect review packet (Will Review Packet format §6.5)

Use this exact section structure (7 sections in this order):

```
STATE
WHAT YOU MUST DECIDE
SAFE TO BULK-APPROVE
BLOCKED-MISSING
KEY NUMBERS
NEXT ACTION
SUPPORTING FILES
```

Notes per section:

- **STATE:** one paragraph — Pass 2 status, deliverables produced, any pivots from the Pass 1 plan.
- **WHAT YOU MUST DECIDE:** the Bucket C items (architect calls). Each item: one-sentence question + recommended default + impact. Aim for ≤10. If more, you punted too much.
- **SAFE TO BULK-APPROVE:** the Bucket A + Bucket B totals; one paragraph confirming these are mechanically derived from Owner Map / Pass 1 decisions and require no architect judgment.
- **BLOCKED-MISSING:** anything you could not resolve due to missing inputs or ambiguity not covered by Pass 1 decisions. Empty section is fine if nothing's blocked.
- **KEY NUMBERS:** V3.18 row count (528) → V4 candidate row count → Bucket A count, B count, C count. New OPA-* rows added (if any). Charter inputs counted per charter.
- **NEXT ACTION:** what Will does next (typically: review Bucket C, ratify, then publish V4 and open Stage 6 charters).
- **SUPPORTING FILES:** relative paths to all 7 Pass 2 deliverables.

## 5. Constraints (hard rules)

1. **DO NOT modify any live file outside `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`.** All Pass 2 work lands in that folder. The operative OP-A V3.18 stays untouched. The live DOC80 baseline files stay untouched.

2. **DO NOT modify the baseline_snapshot/ files.** They are the Pass 0 frozen reference. If you find a sha256 mismatch between snapshot and live, STOP and report — do not refresh.

3. **DO NOT open new architect decisions casually.** If a decision is needed: first check whether `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` already covers it (often it does, transitively); second check whether a resolved ADQ row covers it; only then push to Bucket C with a proposed ADQ.

4. **DO NOT redo Pass 1 work.** The 13 architect decisions are RESOLVED. Treat them as inputs, not as questions to revisit.

5. **DO NOT touch the Conflict Register, Architect Decision Queue, Supersession Matrix, or Owner Map.** Pass 2 reads these; ratification at Pass 2 close updates them, but that's a separate step Will performs.

6. **DO NOT run git commands.** Will handles git operations manually.

7. **Apply Pass 1 architect decisions verbatim.** Specifically:
   - DOC24 R3.1.1 6 IDs → Bucket A with `confidence = high`
   - DOC23 Addenda B 33 IDs → defer entirely (out of scope until flatten complete) — do NOT add Bucket A/B/C rows for these
   - Running Brief deprecation → apply CSA extraction report §6.1/§6.2/§6.3 verbatim
   - Duplicate pairs → merge with confidence-winner
   - V1.6.1 in-scope; normalize to V4 single-row with `legacy_id_aliases`
   - DOC25 degraded → add explicit row
   - Knowledge Pack + nightly extraction → route to DOC85 (E9 charter input)
   - ADQ-222 = tracked seam only (no schema body in Pass 2)
   - DOC74 = typo (no action)
   - OBL-D14-09 chain → in-scope
   - Memory Intake proposal → defer
   - InjectionSlotRegistry → owner-doc work (route to relevant owner)

8. **DO NOT create or modify scheduled tasks, skills, or any infrastructure outside Stage_5R3/.**

## 6. Acceptance criteria — Pass 2 is done when

- All 7 deliverables in §4 exist in `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`
- `OPA_V4_CANDIDATE.md` row count = V3.18 row count + Bucket B splits − any explicit Bucket A merges; reconciled in the §4.7 KEY NUMBERS section
- Bucket C is ≤ 10 entries (push back if higher)
- `PASS_2_WILL_REVIEW_PACKET.md` follows the §4.7 7-section format exactly
- Every row in `OPA_V4_CANDIDATE.md` carries either a `mapping_basis` or a `pending_architect_review` flag
- Final self-check: do a `Stage_5R3_Pass_2_Self_Audit.md` (8th deliverable, recommended not required) noting any residual limitations, sha256 verification of inputs read, and confirmation that no live file outside Stage_5R3/ was modified

## 7. If you get stuck

- If `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` doesn't cover a decision: push the row to Bucket C with the proposed ADQ text. DO NOT skip the row.
- If a baseline snapshot file sha256 doesn't match its source-package pin: STOP, write a one-paragraph report at `Stage_5R3/PASS_2_HALT_REPORT.md`, and exit. Will will refresh.
- If you find an architectural problem genuinely not covered by Pass 1 (e.g. an owner conflict the Owner Map doesn't resolve): push to Bucket C; do NOT attempt to resolve it yourself.
- If a charter input cannot be assembled because a required pre-condition (Stage 5R2/5R2b/5R2c artifact) is missing or corrupted: STOP and write the HALT report.

## 8. Time bound

Pass 2 should complete in one Claude Code session. If you find yourself spawning subagents or exploring beyond the ledger, you've drifted — return to §4 deliverables.

---

**End of commission prompt. Begin by reading §2 file 1: `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`. Acknowledge the read in your first response, then proceed.**