Elnor Repo Reader

Stage_5R3_Review_Prompt_R3.md

Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/Stage_5R3_Review_Prompt_R3.md

Short text page e6b2097bd22e. Generated 2026-06-09T01:23:58.539Z from commit dbaa25962edc11ab30e8d4ca1715f9ae5bf77331. Worktree: clean.

Open readable HTML page · Open raw txt · Open path URL

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/Stage_5R3_Review_Prompt_R3.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# Review Prompt R3 — Final Quick Review: Audit-Launch Prompts (Appendix B)

## Context

You are reviewing R3 of the Stage 5R3 audit proposal. The architectural shape (audit necessity, two-pass split, §5(b) scope rule refinement, freeze mechanic, forward-discipline automation) was ratified through the R2 review cycle and is locked. **This is a final quick review focused on Appendix B — the operational launch prompts for Pass 0, Pass 1, and Pass 2.**

If you have not seen the prior reviews: the proposal commissions a one-time audit that retargets OP-A's 528 cross-doc obligation rows against the new DOC80–DOC87 memory plane, plus three forward-discipline automation pieces (nightly drift detector, Monday weekly maintenance pass, freeze mechanic) that act as standing backstops to the §15A session-close discipline.

R3 incorporates all consensus changes from the R2 review cycle:
- Pass 0 setup stage added
- Pass 1 scope broadened (ADQs, Conflict Register, Supersession Matrix, GIE V2.2 Appendix A/C, EC Core V3.3 cross-doc surface, DOC23 family coordination ledger, existing-row source validation)
- Pass 1 produces distribution preview + partitioned output by DOC family
- Pass 2 produces three-bucket output (confident retargets / splits / decisions) + `source_stability` field
- Stage 5R2 sequencing: Pass 1 may parallel; Pass 2 gated on 5R2 stabilization
- Piece 1 folded into existing nightly sync with two-tier detection
- Piece 2 includes queue health metrics; ships coupled with 1 + 3
- Piece 3 freeze has hard duration cap (30 days max, current freeze 21 days), explicit scope allowlist, expiration warning, auto-expiration
- Piece 4 dropped — discipline updates fold into §15A revision in OP-A V4 itself
- Sunset criteria for automation pieces
- Stage 7 OP-A Conformance Check (concrete check, not full audit)

**Do not re-litigate architectural decisions.** Surface them only if the launch prompts would change them or fail to honor them.

## What to assess (focus on Appendix B)

Three questions:

**1. Are the Pass 0 / Pass 1 / Pass 2 launch prompts sufficient to execute the audit as described in proposal §4?**

For each prompt:
- Does it correctly bound the tool's scope?
- Does it identify all required inputs (input files, paths, prior-pass outputs)?
- Does it specify outputs in a reviewable shape?
- Does it prevent the tool from making decisions reserved for the architect?
- Are the deliverables file names, locations, and column conventions consistent across passes (e.g., does Pass 2 know how to read Pass 1's outputs without ambiguity)?
- Are the architect-review touchpoints correctly placed between passes?

**2. Are there blind spots in the prompts?**

Categories of obligation, sources, or row dispositions the prompt doesn't tell the tool to look for, that proposal §4 implies should be found. For example:
- Does Pass 1 actually walk every source the proposal §2 Gap 2 lists?
- Does Pass 1's "existing-row source validation" sample correctly bias toward high-risk rows (e.g., DOC1 / DOC8 rows where ownership has clearly moved) vs. uniform random sampling?
- Does Pass 2's row tagging logic correctly identify `pre_flatten` vs. `flatten_aware` for edge cases (e.g., rows that target DOC72 but for non-memory concerns)?
- Does Pass 2 handle obligations that should split across memory-plane members AND non-memory members?

**3. Are there risky framings in the prompts?**

Instructions that could lead the tool to over-step:
- Modify trackers it shouldn't.
- Make decisions reserved for the architect.
- Produce output the architect can't review in proportional time.
- Silently degrade when input is unavailable.
- Cascade Pass 1 errors into Pass 2 retargeting without architect catching them.
- Use ambiguous language that lets the tool decide what "ambiguous" means.

Also worth flagging if relevant:
- The Pass 1 prompt for Codex assumes Codex can locate the ADQ ledger, Conflict Register, and Supersession Matrix. If these don't have stable, findable paths in the repo, that's a Pass 0 setup issue the prompt should surface.
- The Pass 2 prompt for Claude Code reads Owner Map and Skeletal Baseline to establish new ownership. If these are themselves still in flux post-5R2, the prompt may need to specify a frozen snapshot.
- The §15A rewrite in Pass 2 is the most consequential single deliverable — does the prompt give Claude Code enough specification to produce a §15A revision the architect can ratify inline, or should §15A rewrite be a separate Pass 2.5 with its own prompt?

## Practical notes

- Proposal R3 is at `Stage_5R3_Audit_Proposal_R3.md`. Appendix B starts roughly two-thirds in.
- Architect prefers direct assessment without hedging. BUG / GAP / SUGGESTION / CONFIRMED typing on findings.
- A focused review (~1000–2000 words) is appropriate. The architectural review took ~3000 words; this is a tighter operational pass.
- If you find a substantive architectural issue surfaced by reading the launch prompts, flag it — but do so explicitly as a re-opening, not as a minor concern.

After this review, the audit is commissioned. Pass 0 runs the same day. Pass 1 begins shortly after. Pass 2 awaits Stage 5R2 stabilization.