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

---

# Stage 5R3 Audit Proposal R3 — Final Review (Unified)

**Status:** Final review pass. Two reviewers (Claude, ChatGPT) plus architect synthesis. Ready for Appendix B R3.1 patch and commission.
**Date:** 2026-05-27
**Subject:** Stage 5R3 Audit Proposal R3 (`Stage_5R3_Audit_Proposal_R3.md`)
**Scope:** Operational review of Appendix B launch prompts (Pass 0 / Pass 1 / Pass 2) plus holistic process walkthrough. Architectural shape was ratified through R2 cycle and is locked.
**Suggested repo path:** `Memory Rebuild Docs/Flattening/Reviews/`

---

## Bottom-line disposition

**Approve R3 to launch after a small Appendix B cleanup patch (R3.1).** No further architectural review needed. Both reviewers converged on this disposition independently.

The R3 architecture is right: Pass 0 sets up state, Pass 1 does corpus coverage without retargeting, Pass 2 produces OP-A V4 candidate with three-bucket architect review, and three forward-discipline automation pieces (nightly drift detector, Monday weekly maintenance pass, freeze mechanic) ship as a coupled increment. The freeze is correctly bounded (21 days, 30-day cap, allowlist scope, auto-expiration). The §15A rewrite folds into OP-A V4 rather than a separate companion doc. Sunset criteria exist for the automation pieces.

The corrections below are operational refinements to Appendix B's launch prompts, not structural changes. Most are one-line additions or field specifications. After patching, commission Pass 0 the same day.

---

## Major reviewer disagreement and resolution

One substantive disagreement between reviewers, resolved in favor of ChatGPT's approach.

**§15A rewrite handling.** Claude's review proposed splitting §15A rewrite into a dedicated Pass 2.5 with its own prompt, justified by the §15A revision being the most consequential single deliverable and benefiting from dedicated authoring attention informed by completed Pass 2 retargeting findings. ChatGPT's review proposed keeping it inside Pass 2 but adding a standalone `SECTION_15A_REWRITE_PREVIEW.md` deliverable, with a contingent Pass 2.5 only if the architect materially revises or rejects §15A during V4 ratification.

**Resolution:** Adopt ChatGPT's approach. The preview deliverable accomplishes the goal Claude cared about (architect can review §15A standalone without reading all of V4), and triggering Pass 2.5 only as a contingency avoids paying for it when it might not be needed. Claude's concerns about Task H being under-specified can be addressed by expanding the Pass 2 task specification (target length, structural requirements, source authorities for each sub-area) rather than by sequencing a whole separate pass.

**Net decision:** Keep §15A inside Pass 2 with expanded Task H. Add `SECTION_15A_REWRITE_PREVIEW.md` as a Pass 2 deliverable. Hold Pass 2.5 in reserve as a contingency only.

No other substantive disagreements between reviewers. The rest is largely complementary.

---

## Where the reviewers converged

Both reviews approve R3 architecturally and treat the final pass as operational cleanup on Appendix B. Both flag the same core operational gaps:

- Pass 0 needs to locate the ADQ ledger / Conflict Register / Supersession Matrix (not Pass 1).
- Pass 1's existing-row source validation needs stratified sampling biased toward high-risk owner moves, not uniform.
- Pass 2 needs to read frozen baseline snapshots rather than live files.
- The Bucket A criterion needs adjustment.
- The audit needs explicit handling of cross-family or mixed obligations.
- Forward-discipline pieces are correctly shaped; freeze mechanic is correctly bounded.

---

## Items from ChatGPT's review adopted in the unified patch

Six substantive items ChatGPT caught that strengthen the audit:

**BUG — Stage_5R3/ output path is ambiguous.** Appendix B uses `Stage_5R3/` without a repo-relative path. Codex or Claude Code might create it at the repo root, under OP-A, or under Memory Rebuild Docs. The canonical path should be `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/` — that's where the flattening workspace lives per the repo layout.

**BUG — Absorbed rows have no review surface.** Pass 2's three buckets are Confident Retargets, Splits, and Architect Decisions. Absorbed rows (the disposition that moves an active §6 obligation to §7) aren't in any of them. That's a real risk — absorption removes obligations and removal should never be invisible. Fix is either Bucket A2 (`BUCKET_A2_ABSORBED_MECHANICAL.md`) or an absorbed sub-section inside Bucket A.

**GAP — Stage 6 Charter Input Index isn't in Pass 2 deliverables.** Proposal §8 mentions "Stage 6 charter input package" as an audit deliverable, but Appendix B.3's Pass 2 deliverables list only V4 candidate and the three bucket files. This needs to be an explicit Pass 2 deliverable: `STAGE_6_CHARTER_INPUT_INDEX.md`. Without it, each charter session re-derives the index from raw V4.

**RISK — "Continue with partial coverage" can hide an incomplete audit.** Pass 1's instruction to "surface in PASS_1_ARCHITECT_DECISIONS.md and continue with partial coverage" is reasonable for noncritical inputs but not for core ones. Splitting into `critical_missing_input → stop` and `noncritical_missing_input → continue with coverage_gap` is the right discipline.

**SUGGESTION — Bucket A needs a summary/full split for large sets.** If Bucket A grows to 100+ rows, the summary becomes hard to review. Format: `BUCKET_A_SUMMARY.md` (count by old target, count by new target, top 10 highest-load-bearing, grouped by family) + `BUCKET_A_FULL.md` (every row with one-line rationale).

**Will Review Packet / Control Board (holistic addition).** Every pass and every weekly maintenance cycle produces a single short "this is what you read" document pointing to the supporting artifacts. Contents: current process state, files created/updated, critical missing inputs, architect decisions required, bulk-ratifiable items, blocked items, recommended next action, exact prompt or instruction for Claude Code if needed. Raw inventories, buckets, ledgers, and row tables are supporting artifacts you can drill into but aren't expected to read by default.

This is the most important UX addition. Without it, the audit produces 14 markdown files and the discipline becomes "find what matters in the pile." With it, the discipline becomes "read the packet, drill in as needed."

---

## Items from Claude's review not in ChatGPT's response

Eleven items that should still land in the patch:

- Pass 0 records audit-start commit hashes for every input as a unified snapshot reference (ChatGPT had partial pinning).
- Pass 0 records the Master Spec List entry count, giving Pass 1 a coverage target.
- Task A's corpus classification scheme allows multi-classification or adds `non_memory_with_memory_section` bucket — real specs straddle (DOC11 native-memory authority, DOC14 graph writes, DOC16 memory feeds).
- Task A's enumerated lists get a fallback step: classify by §22 content when no list match.
- Task B clarifies presence-check vs coverage-check intent: presence check (sample 5-10) for all non-skip specs; full coverage check for high-obligation specs.
- Task C changes "within 2 OP-A versions of absorption" to date-based ("any OP-A version between absorption-date and audit-start").
- Task G distribution preview adds DOC80 explicitly.
- Non_memory-classified specs still run Task B presence check as a sanity check.
- Bucket A criterion drops the source_stability requirement; source_stability remains as informational row metadata, not a routing gate.
- Confidence field on every row in V4 (high/medium/low based on bucket).
- Pass 2 reconciliation rule when Pass 1 inventory and Pass 2 tagging disagree about whether an existing row is memory-related.
- Multiple §22 sections in one spec — Pass 1 task B inventories each separately.
- Spec-archival case — §15A revision explicitly covers archived specs leaving dangling rows.
- Freeze renewal procedure documented in Pass 0.

---

## Unified patch list for Appendix B R3.1

Consolidated patch list combining both reviews. Numbered for execution.

### Pass 0 additions

1. Define canonical output directory: `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`. Update every Appendix B reference to use this path.

2. Add explicit Pass 0 tasks to find and pin paths plus commit hashes for: ADQ ledger, Conflict/Disagreement Register, Supersession Matrix, OP-A Candidate Disposition file, Stage 5R2 consolidated patch / delta package, DOC80 Skeletal Baseline, DOC80 Owner Map, DOC80 Import Graph, DOC80 Retired Names.

3. Pass 0 produces a frozen snapshot of Skeletal Baseline, Owner Map, Import Graph, Retired Names at `Stage_5R3/baseline_snapshot/`. Pass 2 reads from snapshot, not live files. Stage 5R2 deltas import as explicit delta package over the snapshot.

4. Pass 0 declares a hold on OP-A patching for the audit duration (max 21 days per current freeze). Out-of-scope drift accumulates in `PENDING_OPA_UPDATES.md` but no OP-A patches land until V4 ships.

5. Pass 0 records audit-start commit hashes for every input as a unified snapshot reference.

6. Pass 0 records the Master Spec List entry count.

7. Pass 0 documents a freeze-renewal procedure for the case where audit runs long.

8. Pass 0 produces `Stage_5R3_Control_Board.md` (the first Will Review Packet) showing: current phase, what files were read, what is frozen, what is missing, what you must review, what is safe to ignore for now, next action.

9. Pass 0 splits missing inputs into `critical_missing_input → stop` vs `noncritical_missing_input → continue with coverage_gap`. Critical list: OP-A current file, Master Spec List, Source Package, ADQ ledger, Conflict Register, Supersession Matrix, Stage 5R2 target snapshot.

### Pass 1 additions

10. Task A allows multi-classification or adds `non_memory_with_memory_section` bucket for specs primarily non-memory but with memory-touching §22 entries.

11. Task A enumerated lists get a fallback step: "If a spec doesn't match any list, classify based on whether its §22-style content references memory-plane concepts (entity graph, node types, memory directives, extraction, ConsolidatedUnderstanding, KDA, BDSM, CIL injection, EC Core memory operations, knowledge intake, knowledge delivery)."

12. Task A's "DOC80–DOC87: skip as not yet operative" qualifies: skip as operative source obligations; include as target architecture / retargeting authority if part of Stage 5R2 frozen snapshot.

13. Task B clarifies presence-check vs coverage-check intent. Recommended: presence check (sample 5-10) for all non-skip specs; full coverage check (every §22 obligation) for high-obligation specs (DOC72, DOC24, DOC23, EC Core, BDSM, KDA).

14. Task B handles multiple §22 sections per spec by inventorying each as a separate entry.

15. Non_memory-classified specs still run Task B step 1 (presence check + §3 listing confirmation) as a sanity check.

16. Task C changes "within 2 OP-A versions of absorption" to "in any OP-A version between absorption-date and audit-start."

17. Task E replaces uniform sampling with stratified sampling: 60% from pre_flatten-candidate sections (DOC1, DOC8, DOC72 memory, DOC25, DOC15 memory); 25% from active-recent-revision sections (DOC24, DOC23, BDSM, KDA, EC Core V3.3); 15% from stable sections. Add `sample_reason` field (high_risk_owner_move / large_section / random / source_recently_changed / known_stale_candidate).

18. Task E classifications get finer granularity: `source_file_missing`, `source_section_missing`, `source_ref_ambiguous`, `source_content_changed`, `target_owner_stale`, `acceptance_criteria_drifted`, `row_obsolete`.

19. Task G distribution preview adds DOC80 explicitly (likely zero but not omitted).

20. `PASS_1_MISSING_SOURCES.md` gets a fixed row standard: `source_path`, `source_kind`, `why_missing_from_OPA_3`, `has_cross_doc_obligation_section`, `obligation_count_estimate`, `recommended_disposition`, `candidate_target_docs`, `architect_review_required`, `notes`.

21. Pass 1 produces `PASS_1_WILL_REVIEW_PACKET.md` — the single document read by default. Contents per Control Board template; points to six supporting deliverables.

### Pass 2 additions

22. Pass 2 reads from `Stage_5R3/baseline_snapshot/` (created by Pass 0), not live Skeletal Baseline / Owner Map files. Pass 2 refuses to run against moving target files unless `explicit_delta_import = yes` is set in the source package.

23. Task A row tagging adds rule for mixed obligations: rows containing both memory-plane and non-memory obligations get tagged `pre_flatten` with disposition `split`. Do not let mixed rows be classified `not_memory`.

24. Task A adds reconciliation rule: if Pass 1 inventory identifies an existing §6 row as memory-related and Pass 2's tagging marks it `not_memory`, surface to Bucket C with both pieces of evidence cited.

25. Task B's "absorbed" disposition gets explicit review-surface treatment. Either Bucket A includes an absorbed sub-section or a separate `BUCKET_A2_ABSORBED_MECHANICAL.md` deliverable. Each absorbed row carries: `row_id`, `old_target`, `source`, `why_absorbed`, which DOC80-87 design element absorbs it, why no active §6 row remains necessary, `stage7_verification_required`, `architect_review_required`. If absorption isn't mechanically obvious, the row goes to Bucket C.

26. Task B's split disposition enumerates sub-obligations by destination, not percentages. Splits may cross family boundaries (memory-plane member + non-memory consumer).

27. Task E mechanical §9 resolution guard: Pass 2 may mechanically resolve §9 items only if Pass 1 marked them resolvable-from-inventory AND architect approved or did not modify that classification during Pass 1 review.

28. Bucket A criterion drops the `source_stability` requirement: "1:1 ownership move where the new target is unambiguous from Owner Map." `source_stability` remains as informational row metadata.

29. Bucket A gets a summary/full split when row count exceeds ~100: `BUCKET_A_SUMMARY.md` (counts, top 10 highest-load-bearing, grouped by new family member) + `BUCKET_A_FULL.md` (every row with one-line rationale).

30. Row field standard adds `confidence` (high/medium/low based on bucket) and `audit_pass` (1 for Pass 1 originated, 2 for Pass 2 originated, 3 for Bucket C resolved).

31. Pass 2 produces `STAGE_6_CHARTER_INPUT_INDEX.md` as explicit deliverable: per DOC80-87 member, list OP-A row IDs, source docs/sections, retarget/split/absorbed status, `stage6_slice_refs`, `stage7_verification_required`, unresolved ADQ/Bucket C dependencies.

32. Pass 2 produces `SECTION_15A_REWRITE_PREVIEW.md` — the proposed §15A text in standalone form, plus a short mapping table (R3 requirement → §15A paragraph). §15A still lands inside V4 candidate; the preview lets architect review it without reading all of V4.

33. Task H (§15A rewrite) expanded with explicit specifications: target length 400-800 words; structure (numbered checklists for pre-flight, session-close, supersession protocol; prose for cadence and version-bump conventions; explicit cross-references to Pieces 1/2/3 by name and to new SKILLs by ID); preserve V3.18 §15A text where it still applies rather than rewriting wholesale; explicit coverage of spec-archival case; future-process rule (every spec revision that touches another owner doc must update OP-A inline, queue a pending OP-A item, or explicitly certify no cross-doc obligation).

34. Pass 2 produces `PASS_2_WILL_REVIEW_PACKET.md` per Control Board template, pointing to V4 candidate, three bucket files, charter input index, and §15A preview.

### Future-process additions

35. §15A rewrite includes the future-process rule: every spec revision that touches another owner doc must either update OP-A inline, add a pending OP-A queue item, or explicitly certify no cross-doc obligation.

36. §15A rewrite explicitly covers the spec-archival case (when a spec is archived, walk OP-A for rows targeting it and retarget or move to §7).

37. Weekly Monday maintenance pass produces `MAINTENANCE_REPORT.md` styled as a Will Review Packet (current top-5, queue health, ratings, next actions). Daily Piece 1 panel stays minimal.

### Contingencies

38. If §15A is materially revised or rejected during V4 ratification, trigger a narrow Pass 2.5 cleanup pass with a focused prompt. Otherwise §15A ships inside V4 as Pass 2 produced it.

39. If audit runs longer than 21 days, renew freeze per the Pass 0 procedure before expiration.

---

## Commission recommendation

The R3 architecture is right. The corrections above are operational refinements.

**Commission sequence:**

1. **Today:** apply patches 1-9 (Pass 0 additions) to the Pass 0 prompt. Run Pass 0. Verify the Control Board / source package / freeze manifest / baseline snapshot are all in place.

2. **Same week:** configure Pieces 1/2/3 SKILLs. Piece 3's freeze manifest is already created by Pass 0. Piece 1 starts firing nightly. Piece 2's first run schedules 7+ days out.

3. **After Pass 0 ratification:** apply patches 10-21 to the Pass 1 prompt. Run Pass 1. Receive `PASS_1_WILL_REVIEW_PACKET.md` plus six supporting deliverables. Review the packet (~30 min) and drill into supporting files only as the packet directs.

4. **In parallel with Pass 1:** Stage 5R2 stabilization continues on its own workstream.

5. **After Pass 1 review AND Stage 5R2 stabilization (or explicit delta import):** apply patches 22-34 to the Pass 2 prompt. Run Pass 2. Receive `PASS_2_WILL_REVIEW_PACKET.md`. Bulk-ratify Bucket A, per-row review Bucket B, decide Bucket C, review §15A preview, ratify V4.

6. **V4 ships. Freeze resolves. Stage 6 begins** consuming `STAGE_6_CHARTER_INPUT_INDEX.md`.

7. **Patch 38 (Pass 2.5 contingency)** only triggers if §15A is rejected at V4 ratification.

**Architect time budgets:**

- Audit phase total: ~4-7 hours, spread over 2-3 weeks.
- Future per-revision overhead: ~30-45 min/week steady state.
- Stage 7 OP-A Conformance Check: ~30 min one-time.

**Holistic conclusion:** the process works. The flatten benefits because Stage 6 charters consume a correct V4 instead of stale pre-DOC80 obligation rows. Future spec maintenance benefits because drift is caught in small weekly batches instead of multi-day quarterly reconciliations. The process stays simple for the user if and only if the Will Review Packet / Control Board requirement is enforced — every stop gate produces one short document the architect reads by default, with raw audit artifacts as supporting material drilled into on demand.

After patching Appendix B with the items above, commission. No further architectural review needed.

---

---

# Appendix — ChatGPT's reviews (verbatim)

The following two responses were produced by ChatGPT in a separate review window and are preserved here for traceability. They form the second-reviewer input synthesized into the unified review above.

---

## ChatGPT Response 1 — Appendix B launch-prompt review

### Bottom-line disposition

**Approve to launch after a small Appendix B cleanup patch.** The R3 architecture is locked, and I agree this review should stay operational: Pass 0 / Pass 1 / Pass 2 are the right execution shape; Pass 0 sets up freeze/source package, Pass 1 does corpus coverage without retargeting, and Pass 2 produces the OP-A V4 candidate with three-bucket architect review. The proposal correctly says R3 is focused on Appendix B prompts, not re-litigating the audit's architecture.

I would not ask for another substantive proposal round. But I would patch Appendix B before execution because a few prompt-level gaps could cause exactly the problems this audit is meant to prevent: ambiguous output locations, incomplete Pass 0 source-package setup, uniform rather than high-risk source validation, "absorbed" rows disappearing from architect review, and §15A being buried inside OP-A V4 without a standalone review surface.

### 1. Are the launch prompts sufficient?

**CONFIRMED — Pass 0 / Pass 1 / Pass 2 are the right shape.**

The three-stage split is sound. Pass 0 confirms paths, declares the freeze, and creates the source package; Pass 1 walks the corpus and inventories obligations without retargeting; Pass 2 performs retargeting and produces an OP-A V4 candidate. The proposal's stated goals are exactly right: OP-A must be complete enough for Stage 6 charters, and future cross-doc obligations should be handled in small maintenance batches instead of end-cycle archaeology.

**CONFIRMED — The Pass 1 prompt is substantially executable.**

Pass 1 has the right high-level scope: Master Spec List, absorption events since OP-A V3.10, ADQ ledger, Conflict Register, Supersession Matrix, in-flight proposals, §22-style sections, existing-row validation, §9 triage, and distribution preview. It also correctly forbids retargeting and spec/OP-A edits.

**CONFIRMED — The Pass 2 prompt has the right review architecture.**

The three-bucket partitioning is the correct way to keep your review burden manageable:

```text
Bucket A — confident 1:1 retargets, bulk-ratifiable.
Bucket B — splits, per-row review.
Bucket C — unresolved / contested / architect decisions.
```

The row field standard is also good: it forces each retargeted row to carry old target, source, stability, disposition, new target(s), reason, review requirement, Stage 6 slice refs, and Stage 7 verification status.

### 2. Required prompt fixes before launch

**BUG — `Stage_5R3/` output path is ambiguous.**

Appendix B repeatedly says outputs go to `Stage_5R3/`, but does not define the full repo-relative path. That is a real execution risk: Claude Code/Codex may create `Stage_5R3/` in the repo root, under OP-A, or under Memory Rebuild Docs.

**Fix:** In Pass 0, define a canonical output directory, for example:

```text
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/
```

Then update every Appendix B reference to use that path. The current repo layout already has `Memory Rebuild Docs/` as the flattening workspace and `OP-A and Operations and Trackers/` for state trackers, so Stage 5R3 audit outputs belong under Memory Rebuild Docs, while ratified OP-A V4 eventually belongs under OP-A and Operations.

**GAP — Pass 0 should locate and pin the ADQ, Conflict Register, Supersession Matrix, Stage 5R2 patch, and OP-A disposition files.**

Pass 1 is told to locate the ADQ ledger, Conflict Register, and Supersession Matrix if not in the source package. That is too late. The R3 review prompt specifically flags that if those files do not have stable findable paths, it is a Pass 0 setup issue.

**Fix:** Add to Pass 0:

```text
Confirm and record paths + current commit/hash for:
- Architect Decision Queue
- Conflict / Disagreement Register
- Supersession Matrix
- OP-A Candidate Disposition / OP-A Disposition file
- Stage 5R2 consolidated patch / delta package
- DOC80 Skeletal Baseline
- DOC80 Owner Map
- DOC80 Import Graph
- DOC80 Retired Names
```

If any path is missing, Pass 0 should stop rather than let Pass 1 do partial guessing.

**GAP — Pass 1 source validation should be stratified, not just a 10% sample.**

The proposal says Pass 1 samples 10% of §6 rows for source drift. That is useful, but uniform sampling is the wrong default because the known risk is not evenly distributed. The review prompt specifically asks whether the sample should bias toward high-risk rows such as DOC1 / DOC8 rows whose ownership has clearly moved.

**Fix:** Replace "sample 50–55 rows" with:

```text
Sample 50–55 rows total, with mandatory stratification:
- include all known high-risk retarget candidates if row IDs are known;
- oversample DOC1, DOC8, DOC72, DOC73, DOC24, DOC25, DOC15, EC Core, BDSM, KDA, PropA;
- include at least 2 rows from every large §6 target section;
- include a random remainder sample across all other sections.
```

Also add a field:

```text
sample_reason: high_risk_owner_move | large_section | random | source_recently_changed | known_stale_candidate
```

**BUG — "absorbed" rows can disappear from review.**

Pass 2 says an absorbed row moves to §7 because the new architecture handles it differently, but the bucketing rules only explicitly put confident retargets, splits, and architect decisions into review buckets.

That is risky. "Absorbed" is a disposition that removes an active §6 obligation. It should never be invisible.

**Fix:** Add a fourth review surface or include absorbed rows in Bucket A with a separate subsection:

```text
BUCKET_A2_ABSORBED_MECHANICAL.md
```

or:

```text
BUCKET_A_CONFIDENT_RETARGETS.md
  Section 1 — confident retargets
  Section 2 — confident absorbed rows
```

Each absorbed row should include:

```text
row_id
old target
source
why absorbed
which DOC80–DOC87 design element absorbs it
why no active §6 row remains necessary
stage7_verification_required
architect_review_required
```

If absorption is not mechanically obvious, it belongs in Bucket C.

**GAP — Pass 2 needs a Stage 6 charter input package deliverable.**

Proposal §8 says the audit produces a "Stage 6 charter input package," but Appendix B.3's Pass 2 deliverables list only `OPA_V4_CANDIDATE.md` and the three bucket files.

**Fix:** Add:

```text
STAGE_6_CHARTER_INPUT_INDEX.md
```

Required contents:

```text
- DOC80–DOC87 member
- OP-A row IDs targeting that member
- source docs / source sections
- retarget/split/absorbed status
- stage6_slice_refs
- stage7_verification_required
- unresolved ADQs / Bucket C dependencies
```

This should be the file Stage 6 charters actually consume.

**GAP — §15A rewrite should have a standalone review preview.**

The proposal correctly folds the discipline rules into OP-A §15A rather than creating a separate companion doc. That is the right architecture. But the §15A rewrite is the most consequential single Pass 2 text change, and Appendix B currently buries it inside `OPA_V4_CANDIDATE.md`. The proposal says §15A will include pre-flight checklist, session-close checklist, cross-doc obligation section format, retargeting protocol, deep audit cadence, version conventions, and automation references.

**Fix:** Keep §15A inside OP-A V4, but add a standalone Pass 2 deliverable:

```text
SECTION_15A_REWRITE_PREVIEW.md
```

This should show only the proposed §15A text plus a short mapping:

```text
R3 requirement → §15A paragraph
```

I do **not** think this needs a separate Pass 2.5 by default. But if Will rejects or materially revises §15A during V4 ratification, then do a narrow 2.5 cleanup.

**GAP — Pass 2 needs a frozen Stage 5R2 snapshot, not just "post-5R2 state."**

Pass 2's precondition says Stage 5R2 must-fix patches must be applied, or a Stage 5R2 delta package must be available. That is directionally right. But Pass 2 must know exactly which target architecture it is retargeting against.

**Fix:** Add to Pass 0 / Pass 2:

```text
Stage_5R2_Target_Snapshot.md
```

or include this section inside `Stage_5R3_Source_Package.md`:

```text
Stage 5R2 target snapshot:
- Skeletal Baseline path + commit/hash
- Owner Map path + commit/hash
- Import Graph path + commit/hash
- Retired Names path + commit/hash
- Stage 5R2 patch summary path + commit/hash
- status: complete | patches_applied | explicit_delta_import
```

Pass 2 should refuse to run against moving target files unless `explicit_delta_import = yes`.

### 3. Blind spots in the prompts

**GAP — Pass 2 row tagging needs a "mixed / partial memory" rule.**

The current row tags are:

```text
pre_flatten
flatten_aware
not_memory
```

But many rows may be mixed: a DOC72 row may contain graph topology plus memory-object schema; a DOC23 row may contain task execution plus task-output-to-memory obligations; a DOC20 row may contain generic UI plus memory Inspector controls.

**Fix:** Keep the three tags, but add this rule:

```text
If a row contains both memory-plane and non-memory obligations, tag as pre_flatten_mixed and split.
```

If you do not want a fourth tag, add:

```text
Mixed rows MUST be classified as pre_flatten and disposition = split.
```

Do not let mixed rows become `not_memory`.

**GAP — Pass 1 should not "skip" DOC80–DOC87 without qualification.**

The Pass 1 classification says `memory_plane_member: DOC80–DOC87 (skip — not yet operative)`. That is fine for treating DOC80–DOC87 as non-operative source specs. But the Stage 5R / Stage 5R2 artifacts may carry OP-A candidate rows, ADQs, retired-name decisions, and owner-map facts that Pass 2 needs.

**Fix:** Change to:

```text
memory_plane_member: DOC80–DOC87
  - skip as operative source obligations;
  - include as target architecture / retargeting authority if part of the Stage 5R2 frozen snapshot.
```

**GAP — Pass 1 should explicitly cover existing §6 rows whose cited source is missing or stale.**

R3 added existing-row source validation, which is good. But the prompt should distinguish:

```text
source file missing
source section missing
source content changed
target owner stale
acceptance criteria stale
row obsolete
```

Right now it has `matches / drifted-source-changed / drifted-target-stale / row-obsolete-no-longer-applicable`, which is close but not enough to catch missing path/section separately.

**Fix:** Add classifications:

```text
source_file_missing
source_section_missing
source_ref_ambiguous
acceptance_criteria_drifted
```

**SUGGESTION — Pass 1 missing-source rows need stronger output fields.**

`PASS_1_MISSING_SOURCES.md` currently has recommended dispositions but not a fixed row standard beyond the deliverable name. Add fields:

```text
source_path
source_kind
why_missing_from_OPA_3
has_cross_doc_obligation_section
obligation_count_estimate
recommended_disposition
candidate_target_docs
architect_review_required
notes
```

This will make Pass 2 much easier.

### 4. Risky framings

**RISK — "Continue with partial coverage" can hide an incomplete audit.**

Pass 1 says if a required input cannot be located, surface it in `PASS_1_ARCHITECT_DECISIONS.md` and continue with partial coverage. That is reasonable for noncritical inputs, but not for core inputs.

**Fix:** Split missing inputs into:

```text
critical_missing_input → stop
noncritical_missing_input → continue with coverage_gap
```

Critical inputs should include:

```text
OP-A current file
Master Spec List
Stage_5R3_Source_Package
ADQ ledger
Conflict Register
Supersession Matrix
Stage 5R2 target snapshot
```

If any of those are unavailable, the audit should not pretend coverage is meaningful.

**RISK — Pass 2 "resolve §9 items mechanically" needs a stronger guard.**

The proposal says Pass 2 resolves `resolvable-from-inventory` §9 items mechanically and leaves judgmental items in §9. That is okay, but only if Pass 1's classification is trusted after architect review.

**Fix:** Add:

```text
Pass 2 may mechanically resolve §9 items only if Pass 1 marked them resolvable-from-inventory AND Will approved or did not modify that classification during Pass 1 review.
```

**RISK — Bucket A can become too large to review.**

Bulk ratification is right. But if Bucket A has 100+ rows, even the summary may be too large.

**Fix:** Add a Bucket A summary format:

```text
- total count
- count by old target
- count by new target
- top 10 highest-load-bearing rows
- all rows grouped by new DOC80-family member
- every row has one-line rationale
```

Also add an escape hatch:

```text
If Bucket A > 100 rows, produce BUCKET_A_SUMMARY.md plus BUCKET_A_FULL.md.
```

### 5. Final recommendation

**Approve R3 after Appendix B R3.1 cleanup.** No architecture re-review is needed. The operational plan is basically right and ready to execute once the launch prompts are made more deterministic.

Patch Appendix B with these exact changes:

```text
1. Define canonical Stage_5R3 output directory.
2. Pass 0 must pin paths/hashes for ADQ, Conflict Register, Supersession Matrix, OP-A Disposition, Stage 5R2 target artifacts.
3. Pass 1 source validation must be stratified toward high-risk owner-move rows, not uniform random only.
4. Pass 1 must classify source-file-missing / source-section-missing / ambiguous-source-ref separately.
5. Pass 1 missing-source output gets fixed fields.
6. Pass 2 must use a frozen Stage 5R2 target snapshot.
7. Pass 2 mixed memory/non-memory rows must split; do not classify mixed rows as not_memory.
8. Absorbed rows must appear in a review bucket.
9. Add STAGE_6_CHARTER_INPUT_INDEX.md as a Pass 2 deliverable.
10. Add SECTION_15A_REWRITE_PREVIEW.md as a Pass 2 deliverable.
11. Add critical_missing_input vs noncritical_missing_input behavior.
12. Bucket A gets summary/full split if too large.
```

After those edits, run Pass 0 immediately, then Pass 1. Pass 2 should wait until Stage 5R2 is stabilized or its frozen delta package is explicit, exactly as R3 already requires.

---

## ChatGPT Response 2 — Holistic walkthrough

I think the process works, and it should make both the current flattening and future spec maintenance **materially better**. It does need one small user-experience refinement before you finalize it:

> Add a single **Will Review Packet / Control Board** output at each stop, so you are never asked to inspect raw audit sprawl.

That is the main change I'd make after thinking about it holistically.

### The whole process, step by step

Here is how it should work in practice.

#### Step 0 — Freeze and source package

Claude Code creates the freeze file, confirms OP-A path/version, confirms the Master Spec List, confirms where Stage 5R3 outputs go, and pins the active target artifacts. R3 already added Pass 0 for this exact reason.

This is good. It prevents the audit from starting with "I think these are the files."

What it should produce:

```text
Stage_5R3_Source_Package.md
OPA_FREEZE.md
Stage_5R3_Control_Board.md
```

The new thing I'd add is `Stage_5R3_Control_Board.md`, which should always show:

```text
current phase
what files were read
what is frozen
what is missing
what Will must review
what is safe to ignore for now
next action
```

That keeps you from having to remember process state.

#### Step 1 — Pass 1 coverage audit

Codex or another broad-audit agent walks the source corpus and finds what OP-A may be missing: §22-style sections, appendices, OBL-XDOCs, ADQs, Conflict Register entries, Supersession Matrix implications, in-flight proposals, existing OP-A rows whose source text changed, and so on. R3 broadened the scope to include ADQs, Conflict Register, Supersession Matrix, GIE/KIE appendices, EC Core V3.3 cross-doc surfaces, DOC23 coordination ledgers, and existing-row validation.

This is the right place to be broad. It does **not** retarget anything yet. It answers:

```text
What source obligations exist?
What is missing from OP-A?
What old OP-A rows may be stale?
What likely targets exist?
What needs architect review?
```

User burden should be low. You should only see:

```text
Pass 1 Summary
Distribution Preview
Architect Decisions
Critical Missing Inputs, if any
```

Not a 500-row raw table unless you ask for it.

#### Step 2 — You review only shape, not rows

After Pass 1, you should not be asked to adjudicate every obligation. You should answer questions like:

```text
Did it miss a major source family?
Does the distribution look obviously wrong?
Are there critical missing files?
Are there architect decisions needed before retargeting?
```

This is where the process becomes manageable. The proposal already includes a Pass 1 distribution preview and partitioned output by DOC family, which is exactly the right move.

#### Step 3 — Stage 5R2 stabilizes

Pass 2 should not run until the Stage 5R2 target is stable or its deltas are explicitly imported. R3 already has that sequencing rule: Pass 1 can run in parallel, but Pass 2 is gated on Stage 5R2 stabilization or explicit delta import.

This is important. Otherwise OP-A V4 would retarget obligations against a moving skeleton and create another cleanup cycle.

#### Step 4 — Pass 2 retargeting

Claude Code retargets OP-A rows against DOC80–DOC87. This is where old rows get classified as:

```text
confident 1:1 retarget
split across multiple targets
absorbed by new architecture
not memory / not DOC80-family
unresolved / architect decision
```

R3's three-bucket output is the right design:

```text
Bucket A — confident retargets
Bucket B — splits
Bucket C — architect decisions
```

I still recommend adding an explicit absorbed-row review surface, or including absorbed rows inside Bucket A as a separate section. Absorbed rows are dangerous because they remove active obligations. They should be bulk-ratifiable, but not invisible.

#### Step 5 — OP-A V4 candidate

Pass 2 produces OP-A V4 candidate, with DOC80–DOC87 sections and retargeted/split/absorbed rows. This should be called OP-A V4 if it does the full memory-plane retargeting. R3's scale justifies a major version: OP-A V3.18 has 528 active rows and zero DOC80–DOC87 references, while the memory plane has moved to an 8-member family.

You should see:

```text
OP-A V4 Candidate Summary
Bucket A/B/C review packets
§15A Rewrite Preview
Stage 6 Charter Input Index
```

The `Stage_6_Charter_Input_Index.md` is important. Stage 6 should not consume OP-A raw. It should consume an index that says:

```text
DOC81 gets these rows.
DOC82 gets these rows.
DOC83 gets these rows.
These split rows affect multiple members.
These unresolved rows block these charters.
```

#### Step 6 — Stage 6 charters

After OP-A V4 is ratified, Stage 6 charters draft from a clean obligation set. This is the whole point of Stage 5R3. Without it, the charters would inherit stale pre-flatten targets: DOC72, DOC73, DOC8, DOC15, EC Core, etc., even where ownership moved into DOC80–DOC87.

This makes flattening better because each slice starts with:

```text
correct owner map
correct source obligations
correct retired names
correct split/absorbed rows
known unresolved decisions
```

#### Step 7 — Stage 7 conformance check

R3 correctly replaces vague "light verification" with a concrete Stage 7 OP-A Conformance Check: every DOC80–DOC87 OP-A row must map to a drafted section/schema/fixture/lint, or have a documented defer/reject/owner-doc amendment.

This is essential. It prevents OP-A V4 from becoming a theoretical tracker that the actual DOC80 drafts ignore.

### What happens later, after flattening

This is where the process really matters.

After the flattening is done, you will keep changing specs. Those changes will create new cross-doc obligations. The future process should work like this:

#### Normal future spec change

Example: you revise DOC23 and add task-sharing behavior that affects memory exposure.

The workflow should be:

```text
1. Claude Code edits DOC23.
2. Session-close discipline requires an OP-A check.
3. Nightly drift detector sees DOC23 changed after OP-A.
4. It detects likely cross-doc obligation language.
5. It writes a pending OP-A update, not a tracker edit.
6. Monday maintenance groups it with other pending items.
7. You see a short packet:
   "3 likely OP-A updates from DOC23; 1 affects DOC80/DOC84/DOC86; approve?"
8. Claude Code applies approved OP-A updates.
```

That is the right model.

#### Why this is better than today

Today, missed obligations accumulate until you need a giant archaeological pass. R3 explicitly identifies that §15A session-close discipline exists but is unevenly applied; the proposal treats that as an automation-backstop problem, not a "try harder" problem.

That is exactly right. You will keep skipping manual tracker updates sometimes. The system should assume that and catch it.

#### What the future backstop should do

The nightly detector should not rewrite OP-A. It should surface likely obligations.

The weekly pass should not dump noise on you. It should report:

```text
new actionable items
deferred items
oldest unresolved items
queue size trend
items older than 14 / 30 days
top recurring drift sources
top 5 recommended actions
```

R3 already includes queue-health metrics and integrates the drift detector into the existing nightly sync instead of creating a sixth SKILL. That is good. It reduces process creep.

### Does this stay simple enough for you?

It can, but only if Claude Code is required to shield you from raw process artifacts.

The danger is not that the system has too many internal tables. The danger is that you are asked to read them.

So every stop gate should produce exactly this kind of output:

```text
1. What changed?
2. What decisions do I need to make?
3. What can be bulk-approved?
4. What is blocked?
5. What happens next?
6. Recommended command/prompt to continue.
```

Not:

```text
Here are 14 markdown files. Please inspect.
```

The proposal is close to this, but I would explicitly add a required **Control Board / Will Review Packet** deliverable.

### My main holistic change

Add this requirement to the proposal:

```text
Every pass and every weekly maintenance cycle must produce a Will Review Packet.

The Will Review Packet is the only document Will is expected to read by default.

It must contain:
- current process state;
- files created/updated;
- critical missing inputs;
- architect decisions required;
- bulk-ratifiable items;
- blocked items;
- recommended next action;
- exact prompt or instruction for Claude Code if needed.

Raw inventories, buckets, ledgers, and row tables are supporting artifacts, not default reading.
```

That one addition makes the process much more user-friendly.

### Does the proposal make future maintenance better?

Yes, if three conditions are met.

First, **the standard cross-doc obligation format must become routine.** Every future spec/addendum/proposal that creates obligations should have a standard section. OP-A §15A should specify the format. R3 already folds the discipline update into OP-A V4 itself rather than creating a separate companion doc, which I agree with because it avoids another sync problem.

Second, **the detector must distinguish noise from likely obligations.** R3's two-tier detection is right:

```text
drift_candidate
obligation_likely_drift
```

The weekly pass should focus mostly on obligation-likely drift, not every file change.

Third, **OP-A must not become an agent-edited free-for-all.** R3 keeps the automation surface-only, which is correct. The detector and maintenance pass should queue and recommend; Claude Code can edit OP-A only after your approval or under a clear explicit instruction. The proposal's "surface-only" posture is still the right safety line.

### What could still go wrong

The biggest risk is **report fatigue**. If the nightly detector or Monday pass produces long reports every week, you will stop reading them. The cure is the Review Packet / Control Board plus top-five prioritization.

The second risk is **freeze abuse**. R3 helps by giving the freeze a hard cap, current flattening freeze of 21 days, max 30 days, explicit scope allowlist, expiration warning, and auto-expiration. I would keep that. A freeze should never become "the place obligations go to die."

The third risk is **Pass 2 retargeting stale architecture**. R3 already handles this by gating Pass 2 on Stage 5R2 stabilization or explicit delta import. Keep that as a hard rule.

The fourth risk is **too much trust in bulk ratification.** Bucket A is useful, but large Bucket A sets need summaries and random/high-risk sampling. If Bucket A has 100+ rows, use:

```text
Bucket_A_Summary.md
Bucket_A_Full.md
```

and surface the top load-bearing items.

### Final tweaks before finalizing

I would finalize R3 with these additions/clarifications:

```text
1. Add Stage_5R3_Control_Board.md / Will Review Packet as a required output for Pass 0, Pass 1, Pass 2, and weekly maintenance.

2. Make absorbed rows visible in Bucket A as a separate subsection or as BUCKET_A2_ABSORBED_MECHANICAL.md.

3. Require Stage_6_Charter_Input_Index.md as a Pass 2 deliverable.

4. Require SECTION_15A_REWRITE_PREVIEW.md so the discipline rewrite can be reviewed without reading all of OP-A V4.

5. Keep Pass 2 gated on Stage 5R2 stabilization or explicit Stage 5R2 snapshot/delta import.

6. Make critical missing inputs stop the audit; noncritical missing inputs can continue with coverage-gap notation.

7. Use stratified sampling for existing-row source validation, biased toward high-risk owner moves and large sections, not only uniform random.

8. Add a future-process rule:
   every spec revision that touches another owner doc must either update OP-A, add a pending OP-A queue item, or explicitly certify no cross-doc obligation.
```

### Does this change my answer?

Only slightly.

Earlier I said "approve R3 after Appendix B cleanup." After thinking holistically, I would still approve it, but I would add the **Will Review Packet / Control Board** as a required user-experience artifact.

That is the main missing piece from the user perspective.

### Bottom line

The process works.

It improves flattening because Stage 6 charters will consume a correct OP-A V4 instead of stale pre-DOC80 obligation rows.

It improves future spec work because drift is caught in small weekly batches instead of massive archaeological audits.

It is only easy enough for you if the agents produce **one short review packet per stop** and keep raw audit machinery in the background.

So my final recommendation:

> **Finalize R3, but add the Control Board / Will Review Packet requirement before launch. Then run Pass 0.**

---

*End of document.*