ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/Pass_2_Review_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 — External Review Prompt

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Date issued:** 2026-05-28
**You are:** an external red-team reviewer (Claude / ChatGPT / Codex with GitHub repo access). Will is the architect; he will save your findings to the repo himself.

---

## What this is

Stage 5R3 Pass 2 (executed 2026-05-28 by Claude Code) mechanically retargeted OP-A V3.18's 511 §6-active obligation rows onto the post-flatten DOC80 family of owner docs. Pass 2 produced 8 deliverables and was bulk-ratified after only the two Bucket C architect-judgment items were resolved by Will. OPA_V4 has now been published as the operative OP-A.

**Pass 2 was not externally red-teamed before publication.** Every prior Stage gate (5R, 5R2, 5R2b, 5R2c, 5R3 Pass 1) was multi-reviewer red-teamed. This review fills that gap.

**Stakes:** if Pass 2 contains retargeting errors, Stage 6 charters will inherit them. Catching errors now is cheap; catching them at charter time is expensive rework. Be honest about what you find; do not soften.

## What to read (in this order)

All paths are repo-relative.

### A. The post-publication operative file (the actual final product)
1. `OP-A and Operations and Trackers/OPA_V4.md` — operative. Reflects Bucket C resolutions applied at publication (PBE cluster → DOC73; corpus/library identity → DOC87). 80KB; readable in full.

### B. The Pass 2 work products (what to validate)
2. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/BUCKET_A.md` — 512 high-confidence retargets
3. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/BUCKET_B_SPLITS.md` — 3 splits into 7 owner-clean children
4. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/BUCKET_C_ARCHITECT_DECISIONS.md` — 2 architect-judgment items (now both resolved per OPA_V4 header)
5. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/OPA_V4_CANDIDATE.md` — pre-publication candidate (RESERVED rows still present here for lineage)
6. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/STAGE_6_CHARTER_INPUT_INDEX.md` — per-charter input deck (each Stage 6 charter author reads this first)
7. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/SECTION_15A_REWRITE_PREVIEW.md` — OP-A §15 prose update preview
8. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_2_WILL_REVIEW_PACKET.md` — Pass 2's own architect-review packet
9. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/Stage_5R3_Pass_2_Self_Audit.md` — Pass 2's internal self-audit (not external review)

### C. The inputs Pass 2 retargeted against (the ground truth)
10. `OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/OPA_V3_18.md` — the source. 767KB. **Use as targeted lookup, not full read.**
11. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` — Will's 13 resolved Pass 1 decisions; this is the authoritative direction Pass 2 was supposed to apply mechanically.
12. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md` — post-flatten ownership target.
13. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` — DOC80 family skeletal architecture.

### D. Context for the architecture (read only if needed)
14. `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — includes the two new ADQ-PASS2-01 / -02 resolutions.
15. `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md`
16. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2c_Patch_Summary.md` — Stage 5R2c (the cleanup patch just before Pass 2) so you know the as-of architecture state.

## What to check

Eight check areas. Treat them as independent passes; mark each with a verdict.

### 1. Bucket A retarget spot-checks
- Sample at least 20-25 rows from `BUCKET_A.md` (pick across the full alphabet of `OBL-Dxx-*` IDs, not clustered).
- For each, look up the same row in `OPA_V3_18.md` (the source) and `OPA_V4.md` (the live target).
- Verify: does the Pass 2 owner reassignment match (a) the `DOC80_Owner_Map.md` for any schemas/objects named in the row, AND (b) the `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` direction for that section?
- Verdict: hit-rate. If 95%+ match, Bucket A is clean. Below that, list every miss with row ID + your alternative owner.

### 2. Bucket B split integrity
- Read all 3 parent → 7 child decompositions in `BUCKET_B_SPLITS.md`.
- For each: does the split fall on a Pass-1-resolved owner boundary, or did Pass 2 hide multi-owner ambiguity inside the split (i.e. one child still has compound ownership)?
- Verdict: each split = clean / ambiguous / wrong.

### 3. ADD rows
- 7 new rows (6 from D3a — DOC24 R3.1.1; 1 from D13a — DOC25 degraded).
- Verify each ADD row carries: (a) a proper obligation body (not just a stub), (b) the right owner per Pass 1 architect decisions, (c) any required cross-refs (depends_on, blocks, fixture refs).
- Verdict: each ADD = warranted+complete / warranted+incomplete / not warranted.

### 4. D10 duplicate merge
- One V3.18 → V4 merge applied. Find it in OPA_V4 (search for `D10` or the alias note). Verify the loser's content (acceptance criteria, depends_on, why, blocks, fixture refs) was preserved in the winner — nothing dropped except the redundant ID.

### 5. OPA_V4 internal consistency
- Row count reconciliation: 511 V3.18 §6 active + 7 ADD + 4 net Bucket B − 1 D10 merge = 521 V4 §6 active; + 17 §8 deferred = 538 total. Verify against the live file.
- Cross-references: pick 5 rows that name `depends_on` / `blocks` / `legacy_id_aliases` and verify each target row exists in V4.
- Header consistency: does the OPA_V4 header change-log match the actual content?

### 6. STAGE_6_CHARTER_INPUT_INDEX completeness
- Every Stage 6 charter (E0 DOC80 core, E1+E2 DOC81, E3+E4 DOC82, E5+E6 DOC83, E7+E8 DOC84, E9 DOC85, E10 DOC86, E_org DOC87) listed?
- Per-charter row count match: Pass 2's PASS_2_WILL_REVIEW_PACKET.md → KEY NUMBERS section claims `DOC80/E0 = 0; DOC81/E1+E2 = 10; DOC82/E3+E4 = 9; DOC83/E5+E6 = 7; DOC84/E7+E8 = 34; DOC85/E9 = 45; DOC86/E10 = 3; DOC87/E_org = 9. Total family-owned = 117.` Verify per-charter counts match what's actually in the index file.
- Do deferred ADQs / Conflict Register entries / Stage 5R2 fold-ins appear in the right charter's input?

### 7. Section 15A rewrite preview
- Does the prose preview in `SECTION_15A_REWRITE_PREVIEW.md` accurately reflect the actual V4 row structure (one-owner discipline, legacy_id_aliases convention, charter-input cross-ref convention)? Or does it claim conventions Pass 2 didn't actually apply?

### 8. Bucket C resolutions applied at publication
- ADQ-PASS2-01: `OBL-D72-NEW-PBE-CLUSTER-01` should be retargeted DOC72 → DOC73 in `OPA_V4.md`. Find the row, verify.
- ADQ-PASS2-02: `OBL-D24-CORPUS-LIB-MAP-01` should be retargeted DOC24 → DOC87 in `OPA_V4.md`. Find the row, verify.
- Both rows physically remain in their original sections (DOC72 / DOC24) per the publication note — that's intentional, not an error. Verify the cell text reflects the new owner.

## Out of scope for this review

- The Bucket C architect decisions themselves (PBE cluster → DOC73; corpus/library → DOC87) — those are architect calls and not yours to challenge.
- The 13 Pass 1 architect decisions (in `PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`) — same.
- The 33 DOC23 Addenda B deferrals — Will ruled them out of scope per D3b; tracked in `Current Specs/DOC73/DOC73 Helper Home and Deferral List/DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` §10.
- The DOC80 family architecture itself — settled at Stage 5R2c.

If you have findings in these areas anyway, flag them as `OUT_OF_SCOPE_ADVISORY` rather than as Pass 2 defects.

## What to produce

Output your findings as a single markdown document. Will saves it as:

`Memory Rebuild Docs/Flattening/Reviews/Stage_5R3_Pass_2_Review_<your_model_name>.md`

Use this structure:

```
# Stage 5R3 Pass 2 — External Review (<your model identifier>)

## Summary
[Verdict: clean / needs Pass 2 patch round / has architect-tier findings.
One paragraph stating bottom line.]

## 1. Bucket A retarget spot-checks
[N rows sampled, hit rate, list every miss with row ID + alternative owner.]

## 2. Bucket B split integrity
[Per-split verdict.]

## 3. ADD rows
[Per-row verdict.]

## 4. D10 duplicate merge
[Verdict + preservation check.]

## 5. OPA_V4 internal consistency
[Row count reconciliation result; cross-reference spot-check result; header consistency.]

## 6. STAGE_6_CHARTER_INPUT_INDEX completeness
[Per-charter coverage + count-match result.]

## 7. Section 15A rewrite preview
[Accuracy verdict.]

## 8. Bucket C resolutions at publication
[Both rows verified or flagged.]

## OUT_OF_SCOPE_ADVISORY (if any)

## Overall assessment
[One of: STAGE_6_CAN_OPEN | NEEDS_V4_PATCH_ROUND | ARCHITECT_STOP.
If patch needed: minimum patch list (which rows, which files).]
```

## How to be useful

- **Be specific.** "Row N has wrong owner" is useless. "Row `OBL-D24-FOO-01` line 1234 of OPA_V4 lists owner DOC24, but Owner Map line 88 assigns it to DOC81 per ADQ-XXX" is useful.
- **Distinguish defect from preference.** Pass 2 was mechanical retargeting against Pass 1 architect decisions. If you disagree with an architect decision, that's preference (out of scope). If Pass 2 failed to apply an architect decision faithfully, that's a defect.
- **Don't propose new architecture.** Stage 6 charters will do design work. Your job is to verify Pass 2's mechanical correctness.
- **Don't soften.** If 30% of Bucket A is wrong, say so. If you find nothing material, say so plainly — clean findings are valuable too.

## Calibration note

For context, Stage 5R2c (the cleanup patch just before Pass 2) found 13 prose residuals in 5 files — small, mechanical, all traceable to already-resolved decisions. If Pass 2 is similarly clean, expect a short findings list with mostly green verdicts. If Pass 2 has larger drift (e.g. systematically applied a Pass 1 decision wrong, missed a class of rows), expect a longer list with red verdicts and a NEEDS_V4_PATCH_ROUND overall.

The Stage 5R2 regression review (`Memory Rebuild Docs/Flattening/Reviews/Stage_5R2_Regression_Review_Responses.md`) is a good reference for tone and depth — it's how thorough you should be.

---

**Begin by reading `OP-A and Operations and Trackers/OPA_V4.md` for orientation, then `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_1_ARCHITECT_DECISIONS_RESOLVED.md` to ground yourself in the architect direction Pass 2 was supposed to apply. Then proceed through the 8 check areas.**