Stage_5R3_Audit_Proposal_R3.md
Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/Stage_5R3_Audit_Proposal_R3.md
# Stage 5R3 Proposal R3 — Cross-Doc Obligation Audit + Forward Discipline Automation
**Status:** Proposal ready for final quick review pass focused on Appendix B (audit-launch prompts). Architectural shape ratified via R2 review cycle.
**Date:** 2026-05-27
**Author:** Claude (R3 incorporates review consensus from two reviewers + one self-correction)
**Supersedes:** Stage 5R3 Audit Proposal R2 (2026-05-27)
**Calibration anchors:** OP-A V3.18 (2026-05-21); Master Spec List R3.62; DOC80 Stage 5R Skeletal Target Baseline; updated ELNOR Unified Carryover (2026-05-27); the five existing nightly Cowork SKILLs.
---
## What changed in R3 from R2
Eleven changes from review consensus, plus Appendix B (audit-launch prompts).
1. **Piece 4 dropped as a separate companion doc.** The discipline rules for maintaining OP-A live in OP-A. The audit's findings inform a tightened §15A revision authored into OP-A V4 itself, eliminating sync risk between OP-A and a parallel doc.
2. **§3 inventory scope broadened.** Pass 1 explicitly walks absorption events since OP-A V3.10 and includes: GIE V2.2 Appendix A/C, KIE R2, EC Core Addendum A V3.3 cross-doc surface, DOC23 family coordination ledger, ADQs (43 resolved in Stage 5R Round 1 alone), Conflict/Disagreement Register, Supersession Matrix rows, in-flight addenda, DAMS V4.1 disposition, MultiDoc PropA R6.3, Sub-Agent Architecture V5.2 DOC73-consumer references.
3. **Pass 0 setup stage added.** Formalizes freeze manifest creation, path/version confirmation, output-path confirmation, and Stage 5R2 status check before Pass 1 begins.
4. **Pass 1 produces distribution preview** at close — counts of likely DOC81/DOC82/etc. retargets, splits, absorbed — so the architect can catch shape mistakes before Pass 2 commits.
5. **Pass 1 partitions output by DOC family.** Avoids monolithic Pass 1 dump that's hard to validate.
6. **Pass 1 produces existing-row source validation** — samples ~10% of §6 rows; checks whether content still matches source section. Closes the row-content drift gap V3.18's structural audit didn't catch.
7. **Pass 2 partitions output into three buckets** — confident retargets (bulk ratify), splits (per-row review), decisions (architect-decision queue). Avoids undifferentiated 500+ item list.
8. **`source_stability` field on retargeting rows** — five values (stable_architectural_concern / version_specific_detail / actively_revised_source / imminent_revision_expected / unknown_requires_architect_review). Makes the §5(b) scope rule mechanical.
9. **Stage 5R2 sequencing fix.** Pass 1 may run in parallel with Stage 5R2. Pass 2 must run after Stage 5R2 stabilizes OR explicitly imports 5R2 deltas. Prevents retargeting against pre-5R2 ownership.
10. **Piece 1 folded into existing `elnor-nightly-spec-sync` SKILL.** No sixth SKILL. Two-tier detection (`drift_candidate` vs. `obligation_likely_drift`) instead of raw last-commit comparison. Tracks dismissal rate for self-tuning.
11. **Piece 2 includes queue health metrics** and ships coupled with Pieces 1+3 (no deferral). Sunset criteria added for all automation pieces.
Additional substantive change: §11 (new) **Stage 7 OP-A Conformance Check** replaces R2's "light verification" with a concrete rule: every DOC80–87 OP-A row maps to a drafted section/schema/fixture/lint, OR has documented defer/reject/owner-doc amendment.
Freeze duration capped at 30 days renewable; current flatten freeze sized at 21 days from 2026-05-27.
---
## 1. Calibrating the actual state of OP-A
OP-A V3.18 condition (verified directly):
- 528 active obligation rows across 25 target-doc sections in §6.
- Eight versioned patch sessions in five weeks (V3.10 → V3.18). V3.18 was a deep-audit corrections pass that caught V3.14/V3.16 structural misplacements + added two missed KDA rows.
- §3 Source Document Registry distinguishes "folded-in" from "NOT yet folded — planned for OP-A V4" with explicit dispositions.
- §9 Open Meta-Architecture Questions buffers soft-state items; V3.16 demonstrated working soft→hard promotion when items ripen.
- §15A session-close discipline documented but unevenly applied — architect-acknowledged, treated as automation-backstop problem rather than discipline-failure problem.
What this does NOT mean: OP-A is complete or memory rebuild is properly accounted for.
## 2. The actual gaps
Seven gaps, ordered by load-bearing weight:
### Gap 1 (load-bearing): The new memory plane is absent
OP-A V3.18 has **zero references to DOC80–DOC87**. All 528 rows target pre-flatten owners. The flatten reallocates ownership across an 8-member family (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). OP-A has not yet:
- Added §6 sections for each new member.
- Retargeted existing rows pointing at DOC1 memory governance, DOC8 self-learning, DOC72 memory storage, DOC25 ingestion, DOC15 CIL context-injection, EC Core memory concerns.
- Identified rows that split across multiple new members.
- Identified rows that no longer apply in the new architecture.
**Why this can't be deferred to per-charter retargeting:** A meaningful fraction of rows will split across multiple flatten members. Per-slice retargeting means different sessions make inconsistent split decisions on the same row. The audit's whole-corpus pass makes split/absorb decisions once, consistently, before charters consume them.
### Gap 2: §3 inventory undercount (broadened scope from R2)
R2 listed three explicitly pending sources (DOC3 R9.2, DOC14 R2, CD-A 4.1.26). The real undercount is larger. Pass 1 scope explicitly includes:
- GIE V2.2 Appendix A and Appendix C cross-doc obligations (carryover notes these "still need adoption into corresponding companion docs" post-V2.2 absorption).
- KIE R2 cross-doc content (same question post-absorption).
- EC Core Addendum A V3.3 cross-doc surface (touches DOC72, DOC24, DOC8, DOC11, DOC12, DOC20, DOC21/22, DOC1, DOC15, DOC23).
- DOC23 Addenda B family-topology coordination ledger (recent + substantive).
- DOC11 R15 R3 amendment (OpenClaw releases through 2026.5.12).
- MultiDoc PropA R6.3 cross-doc surface (DOC72, DOC1, DOC24).
- Sub-Agent Architecture V5.2 (MemoryAgent/DocumentIntelligenceAgent as DOC73 consumers).
- ADQs — Stage 5R Round 1 resolved 43; resolution decisions may carry cross-doc obligations.
- Conflict/Disagreement Register and Supersession Matrix.
- DAMS V4.1 disposition (currently archived; may carry obligations relevant to DOC80 family).
- In-flight addenda not yet absorbed.
Pass 1 walks every absorption/integration event since V3.10 and flags every cross-doc-touching artifact lacking a §3 entry.
### Gap 3: Spec-internal §22-style sections not yet migrated
Discipline says spec-internal §22 content migrates on revision. Active specs have migrated (DOC24 R3.1.1, DOC23 Addenda B family, KDA R3, BDSM V6.5). Less-active specs uncertain: DOC3 R11.3 Addenda A R2.2 §§13–16, DOC72 R5.73 Appendix A. Pass 1 inventories and verifies.
### Gap 4: Scope rule blind spot for unrevised consumers
Resolved by §5(b) refinement below.
### Gap 5: In-flight proposals not yet registered
DOC20 Q Browser Intake Architecture is the named example. Likely others. Pass 1 surfaces and registers in §3.
### Gap 6: Soft-state items in §9 ripening
DOC15-derived row triage, DOC1 R1 status, RRB-derived row triage, DOC74 reference verification, CD Master Integration Index inherited list. Pass 1 classifies each as "resolvable from inventory" or "requires architect decision" and produces two queues.
### Gap 7: No structural defense against §22-migrate-on-revision being silently skipped
Closed by Piece 1 (nightly drift detector, see §6).
### Gap 7b (new in R3): Existing row content drift
A row entered §6 referencing a §22 obligation; the source section has since changed; the row is now stale even though physically in the right place. V3.18's structural audit didn't check for this. Pass 1 samples ~10% of §6 rows and validates content against current source.
## 3. Goals
**Goal A — Memory rebuild completeness.** Every obligation in the corpus that the new memory plane should accommodate is in OP-A with a target somewhere in DOC80–DOC87 (or explicitly absorbed/N/A). Stage 6 charters consume a complete, correctly-targeted OP-A.
**Goal B — Long-term maintainability.** Future spec revisions are easier to do, not harder. Cross-doc obligations addressed in small weekly batches via automation backstops, not as massive end-of-cycle reconciliations.
§4 + §11 serve Goal A. §6 serves Goal B.
## 4. The audit: Pass 0, Pass 1, Pass 2
### Pass 0 — Freeze and source package setup (precondition for Pass 1)
Architect or Cowork task. Estimated 1 hour.
- Write `OPA_FREEZE.md` per Appendix A.3 template.
- Confirm OP-A path/version (currently `OPA_V3_18.md`).
- Confirm Master Spec List path/version (currently R3.62 / `MASTER_SPEC_DOCUMENT_LIST.md`).
- Confirm output paths for `PENDING_OPA_UPDATES.md`, `PENDING_OPA_UPDATES_DEFERRED.md`, `DRIFT_LOG.md`, `MAINTENANCE_REPORT.md`, and OP-A V4 candidate location.
- Confirm Stage 5R2 status (in progress / patches applied / complete).
- Produce `Stage_5R3_Source_Package.md` listing every source Pass 1 will walk, with paths and disposition flags.
### Pass 1 — Coverage audit (Codex)
See Appendix B.2 for executable launch prompt.
**Scope:** All ~141 entries in Master Spec List + all absorption events since OP-A V3.10 + ADQ ledger + Conflict Register + Supersession Matrix.
**Method:**
1. Walk Master Spec List. For each entry: classify (memory-plane member / memory-plane owner / downstream consumer / intake source / non-memory).
2. For each non-skip spec: locate §22/Appendix/OBL-XDOC/cross-doc obligation section. Confirm in OP-A §3 (folded or pending). For folded: spot-check 3–5 obligations are present as §6 rows. For pending: confirm disposition still correct. For missing: flag for §3 addition.
3. Walk absorption events V3.10+ (GIE V2.2, KIE R2, EC Core V3.3, BDSM landings, KDA landings, etc.). For each, flag obligations that should have folded but didn't.
4. Walk ADQ ledger. For each resolved ADQ since 2026-04-26, identify cross-doc obligations from resolution. Walk Conflict Register and Supersession Matrix similarly.
5. **Existing-row source validation:** sample 10% of §6 rows. Check whether row content still matches cited source section. Output: `existing_row_source_mismatch` table.
6. Resolve §9 carry-forwards into "resolvable from inventory" and "requires architect decision" queues.
7. **Distribution preview at close:** count candidates by likely retarget destination (DOC81/DOC82/.../DOC87/split/absorbed).
8. Partition all outputs by DOC family so architect can review subsets independently.
**Deliverables:**
- `PASS_1_INVENTORY.md` — §22-section inventory by spec, partitioned by DOC family.
- `PASS_1_MISSING_SOURCES.md` — sources not in §3 with recommended disposition.
- `PASS_1_ROW_SOURCE_DRIFT.md` — sampled rows whose content drifted from source.
- `PASS_1_S9_TRIAGE.md` — §9 items classified.
- `PASS_1_DISTRIBUTION_PREVIEW.md` — retarget counts by likely destination.
- `PASS_1_ARCHITECT_DECISIONS.md` — items requiring decision before Pass 2.
**Constraints:** Never modify OP-A or any spec. No retargeting decisions (Pass 2's job).
**Estimated volume:** ~141 specs walked; ~30–50 active §22-section specs to inventory; ~50 sampled rows for source validation; ~10–20 §3 rows added; ~15–25 architect decisions surfaced.
### Pass 2 — Retargeting audit (Claude Code)
See Appendix B.3 for executable launch prompt.
**Precondition:** Stage 5R2 must-fix patches applied to skeletal baseline (or explicit 5R2 delta package available for import).
**Method:**
1. Tag every §6 row: `pre_flatten` / `flatten_aware` / `not_memory`.
2. For each `pre_flatten` row, produce disposition: retarget / split / absorbed / unhandled.
3. For each retarget/split: classify `source_stability` (5 values).
4. Add §6 sections for DOC80–DOC87 with retargeted rows.
5. Add new rows from Pass 1's missing-sources and row-source-drift outputs.
6. Resolve §9 items per Pass 1's triage (mechanical only).
7. Update §3 source registry with broadened scope and dispositions.
8. Update §5(b) scope rule text per refinement below.
9. **Rewrite §15A in V4** incorporating audit findings: pre-flight checklist, standardized cross-doc obligation section format, supersession/retargeting protocol, deep-audit cadence, version-bump conventions, explicit references to Pieces 1–3 as automation backstop.
10. Partition output into three buckets.
**Deliverables:**
- `OPA_V4_CANDIDATE.md` — proposed V4 of OP-A.
- `BUCKET_A_CONFIDENT_RETARGETS.md` — bulk-ratify list with one-line justification each.
- `BUCKET_B_SPLITS.md` — per-row review list with split rationale and proposed destination owners.
- `BUCKET_C_ARCHITECT_DECISIONS.md` — decision queue for unhandled/unresolved rows.
**Constraints:** Surface-only for trackers other than the V4 candidate file. Never modify a spec.
**Estimated volume:** ~80–150 `pre_flatten` rows evaluated; ~30–80 retargeted rows after dedupe/absorption; ~5–15 new rows from Pass 1 sources; ~5–15 architect decisions surfaced.
### Why three stages, three tools
Pass 0 sets up state; cheap and bounded. Pass 1 is breadth (corpus walk, no decisions). Pass 2 is depth (retargeting decisions, V4 production). Different tools for natural strengths: Codex on Pass 1 corpus-walking with file-line citations; Claude Code on Pass 2 row authoring. Architect reviews between Pass 1 and Pass 2.
## 5. Staleness handling
**(a) Stable vs. version-dependent.** Pass 2 captures stable architectural concerns via `source_stability` field. Version-dependent specifics revise out later via the V3.X discipline + automation backstop.
**(b) Scope rule refinement.** Replace "wait for post-revision tracker" with:
> A spec's obligations fold into OP-A when (i) the spec is itself active and current, OR (ii) the spec is stable-but-unrevised AND has stable architectural concerns on the memory plane. Specs being actively revised stay in the "pending — fold on revision" lane. Specs being superseded by a confirmed-imminent revision (commits to a draft file within the last 14 days) stay in the "wait for post-revision tracker" lane. Otherwise, fold the stable concerns now.
Resolves DOC10 R10 (no active revision; stable concerns fold now). Resolves DOC20 Q Browser Intake similarly. The 14-day commit window prevents "imminent revisions" from being elastic.
**(c) Flatten itself is a major revision in progress.** One comprehensive retargeting at Stage 5R3 (now, against post-5R2 skeletal baseline + Owner Map). Stage 7 OP-A Conformance Check (§11) verifies placement at schema completion.
## 6. Forward discipline (Goal B)
Three automation pieces ship as a coupled increment after Pass 0. The fourth deliverable from R2 is dropped — its content folds into the §15A rewrite in OP-A V4.
All pieces are **surface-only**: never modify OP-A, SPEC_STATE, ADDENDA_STATE, or any spec. They produce reports and queues; the architect (or a Claude Code session the architect commissions) does the writes.
### Piece 1 — Nightly OP-A drift detector (extends existing `elnor-nightly-spec-sync`)
See Appendix A.1 for sketched extension.
**Folded into the existing nightly sync SKILL** rather than creating a sixth standalone SKILL. Overlapping inputs (commit history, spec paths) and cadence (nightly).
**Two-tier detection:**
- `drift_candidate` — spec file last-commit > OP-A last-commit.
- `obligation_likely_drift` — drift_candidate AND (file contains §22/Appendix/OBL-XDOC/cross-doc-obligation/amendment-matrix section, OR changed lines mention owner names / MUST / SHALL / consumes / owns / imports / target-doc references, OR file is in a known high-obligation family: DOC72, DOC73, DOC24, DOC23, DOC15, EC Core, PropA, KDA, BDSM, DOC80–DOC87).
Output: `PENDING_OPA_UPDATES.md` (actionable items) and `PENDING_OPA_UPDATES_DEFERRED.md` (in-scope per active freeze). Both overwritten nightly. Each row carries `drift_signal_strength` (low/medium/high).
**Dismissal tracking:** the architect can move false-positive items from `PENDING_OPA_UPDATES.md` to `PENDING_OPA_UPDATES_DISMISSED.md` (sketched in A.1). The weekly pass surfaces dismissal rate over time; if it exceeds 50% for 4 consecutive weeks, detection logic gets tightened (sunset criterion below).
Closes Gap 7. Missed §15A session-close updates become visible within 24 hours.
### Piece 2 — Monday early-AM weekly maintenance pass
See Appendix A.2 for sketched SKILL prompt.
Ships coupled with Pieces 1 and 3. First run scheduled for the Monday after Piece 1 has 7+ nights of data so the report has carry-forwards to compile.
**The architect's weekly load is ~30–45 minutes total, not line-item review.** The report is a triage surface. The architect picks which batches to commission, hands them to Claude Code sessions ("Update OP-A for these items per §15A; surface anything that needs my decision"), and reviews the Claude Code diff later in the week. Row work is done by the commissioned session, not the architect.
Report sections (per Appendix A.2):
- This week's top 5 actions (carry-forwards + new actionable + ripened §9 + stable §3 pending fold-ins + stale trackers).
- Queue health metrics: actionable_count_this_week, actionable_count_last_week, net_delta, deferred_count, oldest_actionable_age, oldest_deferred_age, items_over_14_days, items_over_30_days, top recurring sources of drift, discipline_status (improving / stable / worsening).
- Sections: This Week's New Actionable / Carried Forward / Deferred Per Freeze (count + top items) / §9 Ripening / §3 Pending Fold-Ins Ready to Promote / Stale Tracker Rows / Notes-Anomalies.
Optional one-paragraph email digest.
### Piece 3 — Freeze mechanic (anti-abuse hardened)
See Appendix A.3 for `OPA_FREEZE.md` template and current-flatten initial content.
**Guardrails:**
- Hard end date (max 30 days from declaration). Renewable only by writing a new manifest with documented reason. Current flatten freeze sized at 21 days from 2026-05-27.
- Explicit scope allowlist of folders/paths. No "operator judgment" fallback. (Current flatten freeze in-scope: `Memory Rebuild Docs/` entire folder, `Current Specs/DOC80 Memory Control Plane/` entire folder. Out-of-scope: all other `Current Specs/` edits.)
- Expiration warning at 7 days from end date: drift detector flags; weekly pass surfaces as top maintenance item.
- Auto-expiration behavior: when end date passes without renewal, deferred items move back to actionable queue requiring triage.
- Anti-indefinite-defer rule: if deferred queue grows for 2 consecutive weeks while freeze is active, weekly pass surfaces as top maintenance item.
Keeps in-scope/out-of-scope distinction so out-of-scope drift remains actionable during freeze. Resolves the unbounded-duration concern.
### §15A rewrite in OP-A V4 (replaces R2's Piece 4)
The audit's findings inform a tightened §15A in OP-A V4 itself rather than a separate companion doc. New §15A covers:
- Pre-flight checklist for spec revisions (what to load before drafting; which OP-A rows target this spec; which §22 obligations might be affected).
- Session-close checklist (extends current §15A).
- Standardized cross-doc obligation section format — defines minimum fields (target doc, source citation, why, acceptance criteria, calibrated-against version, source_stability classification) while allowing per-spec format variation (DOC72 Appendix A, DOC23 OBL-XDOC tables, DOC24 §22 amendment matrix all remain valid shapes).
- Supersession/retargeting protocol when ownership moves between specs.
- Deep audit cadence: every 5 OP-A versions or every quarter, whichever first.
- Version-bump conventions: V3.X for incremental patches, V→V+1 for substantive retargeting passes.
- Explicit references to Pieces 1/2/3 as the automation safety net.
### Sunset criteria for automation pieces
To prevent process accumulation forever:
- **Piece 2 retires** if it produces zero unique actions for 8 consecutive weeks.
- **Piece 1 detection logic tightens** if `PENDING_OPA_UPDATES_DISMISSED.md` rate exceeds 50% for 4 consecutive weeks.
- **Freeze mechanic retires** if no freeze is declared for 60 consecutive days after the current flatten freeze ends.
- **Deep audit cadence reviewed** annually for whether quarterly is right or should be longer/shorter.
Architect reviews these criteria at OP-A V5 ratification (next substantive retargeting after V4).
## 7. Sequencing
| Item | Status | Work | Gate |
|---|---|---|---|
| Pass 0 (freeze + source package) | Proposed; runs today | Write `OPA_FREEZE.md`, confirm paths/versions, produce source package | None |
| Stage 5R2 must-fix patches | Authorized | Twelve must-fix items + fold-ins from consolidated synthesis | None (runs in parallel with Pass 1) |
| Piece 1 (nightly drift detector) | Proposed | Extend `elnor-nightly-spec-sync` with detection logic | After Pass 0 |
| Piece 2 (Monday weekly pass) | Proposed | New weekly SKILL; first run Monday after Piece 1 has 7+ nights data | After Pass 0; coupled with Piece 1 |
| Stage 5R3 Pass 1 (Codex coverage) | Proposed | Walk corpus per Appendix B.2 | After Pass 0; may parallel with 5R2 |
| Architect review of Pass 1 | Proposed | Review six Pass 1 deliverables; resolve architect-decision queue items | After Pass 1 |
| Stage 5R3 Pass 2 (Claude Code retargeting) | Proposed | Retargeting + V4 candidate per Appendix B.3 | **After Stage 5R2 stabilizes OR 5R2 deltas explicitly imported** |
| Architect review + V4 ratification | Proposed | Review three-bucket output; bulk-ratify Bucket A; per-row review Bucket B; decide Bucket C | After Pass 2 |
| OP-A V4 ships | Proposed | V4 supersedes V3.18 | After ratification |
| Stage 6 (Charter authoring) | Pending | Slice charters for DOC80–DOC87 consume V4 | After V4 |
| Stage 7 (Schema authoring) | Pending | Schema drafting per slice | After Stage 6 |
| **Stage 7 OP-A Conformance Check (§11)** | Proposed | Per §11 below | After Stage 7 schema completion |
**Critical gates:**
- Pass 0 happens today (30-min freeze manifest + path confirmation).
- Pieces 1/2/3 set up in parallel with Pass 1 (they're independent infrastructure).
- Pass 2 gated on Stage 5R2 stabilization.
## 8. Deliverables
From the audit:
- OP-A V4 (DOC80–87 §6 sections; retargeted rows; new rows from Pass 1; resolved §9 carry-forwards; expanded §3; refined §5(b); rewritten §15A).
- Architect decision list (Bucket C ratifications).
- Stage 6 charter input package (per-slice cross-reference index).
From forward discipline:
- `OPA_FREEZE.md` for current flatten (Piece 3).
- Extended `elnor-nightly-spec-sync` with drift detection (Piece 1).
- New `elnor-weekly-maintenance-pass` SKILL (Piece 2).
- Dashboard panels: "Pending OP-A Updates," "Deferred Per Freeze," "This Week's Maintenance."
NOT a Stage 5R3 deliverable:
- Rewriting any consumer/intake-source spec (DOC3, DOC10, DOC20, DOC23 family, etc.). Those revise on their own cycles.
- Creating new schemas or family members.
- Re-running Stage 5R2 patches.
## 9. Open questions resolved from R2 review
All seven R2 open questions resolved:
1. Two-pass split: confirmed, plus Pass 0.
2. §5(b) refinement: confirmed with 14-day commit-window tightening.
3. Stage 7 verification: concrete Conformance Check (§11), not full Stage 7.5 audit.
4. §9 carry-forwards: split into "resolvable from inventory" (Pass 2 mechanical) and "requires decision" (architect queue).
5. V4 naming: confirmed.
6. Piece 1/2 surface-only: confirmed.
7. Freeze in-scope/out-of-scope: confirmed; duration bounded.
## 10. Open questions for R3 review (focused on Appendix B)
The R3 review pass is scoped to the audit-launch prompts in Appendix B. Three questions:
1. **Are the Pass 0 / Pass 1 / Pass 2 launch prompts sufficient to execute the audit as described in §4?** Specifically: do they correctly bound the tool's scope, identify all required inputs, specify outputs in a reviewable shape, and prevent the tool from making decisions reserved for the architect?
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 the proposal §4 implies should be found?
3. **Risky framings in the prompts** — instructions that could lead the tool to over-step (modify trackers it shouldn't; make decisions it shouldn't; produce output the architect can't review).
Substantive architectural questions are resolved; this final review is operational.
## 11. Stage 7 OP-A Conformance Check (new in R3)
After Stage 7 schema completion, run a single check (not a full audit):
For every DOC80–DOC87 OP-A row in V4 (or V4.X by Stage 7 time), verify one of:
1. The drafted slice section/schema/fixture/lint implements the obligation;
2. The obligation has documented defer with ADQ or new OP-A row;
3. The obligation has documented reject with architect-approved rationale;
4. The obligation has been re-routed to an external owner-doc amendment.
Mismatches surface as architect-decision items, not as failures.
Implementable as a Cowork SKILL or one-pass Claude Code session at Stage 7 completion. ~30 min architect review.
---
## Appendix A — Forward-discipline SKILL prompts
Sketched starter prompts. Refine against actual SKILL conventions when set up.
### A.1 Extension to `elnor-nightly-spec-sync` (drift detection)
```
ADD TO existing elnor-nightly-spec-sync SKILL:
ROLE: After mechanical drift tracking completes, surface specs that have
changed since OP-A was last updated. Never modify OP-A or specs.
ADDITIONAL INPUTS:
- OP-A and Operations and Trackers/OPA_V3_18.md (latest OP-A)
- OP-A and Operations and Trackers/OPA_FREEZE.md (freeze flag file)
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DISMISSED.md
(architect dismissals; informs detection tuning)
ADDITIONAL STEPS (after current sync logic):
1. Read OPA_FREEZE.md. Extract active-freeze in-scope paths if status=ACTIVE.
Check if today is within 7 days of freeze end_date; if yes, set
freeze_expiring_warning=true.
2. Find OP-A's last-modified commit (OPA_LAST).
3. For each .md file under Current Specs/, Active Working and Red Team/,
Memory Rebuild Docs/, find last-modified commit.
4. Classify each file:
- drift_candidate: last_commit > OPA_LAST.
- obligation_likely_drift: drift_candidate AND (file contains regex
match for §22|Appendix|OBL-XDOC|cross-doc obligation|XDI|amendment
matrix [case-insensitive], OR changed lines since OPA_LAST contain
owner names / MUST / SHALL / consumes / owns / imports / target-doc
references, OR file is in family: DOC72, DOC73, DOC24, DOC23, DOC15,
EC Core, PropA, KDA, BDSM, DOC80–DOC87).
5. For each candidate, set drift_signal_strength:
- high: obligation_likely_drift + high-obligation family
- medium: obligation_likely_drift only
- low: drift_candidate only
6. If candidate path matches active-freeze in-scope: mark DEFERRED.
Otherwise mark ACTIONABLE.
7. Read prior PENDING_OPA_UPDATES_DISMISSED.md. Exclude any candidate
whose path + commit_hash matches a dismissal within last 30 days.
8. Write outputs:
- PENDING_OPA_UPDATES.md (overwrite): ACTIONABLE candidates with
columns: spec, last_commit, OPA_last_commit,
has_obligation_section, drift_signal_strength, likely_target,
recommended_action.
- PENDING_OPA_UPDATES_DEFERRED.md (overwrite): DEFERRED candidates
with same columns plus freeze_reason, freeze_end_date.
- DRIFT_LOG.md (append): one-line summary with timestamp, count
actionable by signal_strength, count deferred, top 3 high-strength,
freeze_expiring_warning if set.
NEVER modify OPA_V3_18.md (or current OP-A version), specs, or
PENDING_OPA_UPDATES_DISMISSED.md.
```
### A.2 `elnor-weekly-maintenance-pass` (new weekly SKILL)
```
ROLE: Produce a weekly maintenance report so Will can address cross-doc
obligation drift in small batches each Monday morning. The report is a
triage surface — Will picks batches to commission, then hands them to
Claude Code sessions for row work. The architect never does line-item
row review from this report.
SCHEDULE: Monday early AM (e.g., 5:00 AM local), before Will starts work.
First run: 7+ days after extended nightly sync starts producing
PENDING_OPA_UPDATES.md so there's carry-forward data to compile.
INPUTS:
- /Users/OpenClaw1/Elnor/Elnor Specs/ (GitHub repo)
- OP-A and Operations and Trackers/OPA_V3_18.md (or current OP-A)
- OP-A and Operations and Trackers/SPEC_STATE.md
- OP-A and Operations and Trackers/ADDENDA_STATE.md
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES.md
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DEFERRED.md
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DISMISSED.md
- OP-A and Operations and Trackers/DRIFT_LOG.md
- OP-A and Operations and Trackers/MASTER_SPEC_DOCUMENT_LIST.md
- OP-A and Operations and Trackers/MAINTENANCE_REPORT.md (prior week)
- OP-A and Operations and Trackers/OPA_FREEZE.md
EACH MONDAY:
1. CARRY-FORWARD: Read prior MAINTENANCE_REPORT.md. Pull open items not
addressed (cross-check against current PENDING_OPA_UPDATES.md and OP-A
commits since prior report).
2. THIS WEEK ACTIONABLE: Read PENDING_OPA_UPDATES.md. Dedupe vs.
carry-forward.
3. THIS WEEK DEFERRED: Read PENDING_OPA_UPDATES_DEFERRED.md. Report
count + top items.
4. §9 RIPENING: Walk OP-A §9. For each item, check whether referenced
spec/version has shipped, ownership clarified, or related decision
recorded since the item was added. Flag ripened items with one-line
reason.
5. §3 PENDING FOLD-INS: Walk OP-A §3 NOT-yet-folded table. For each,
check whether source file still exists, and whether its target spec
has had no commits in 7 days (stabilized). If yes, flag for fold-in.
6. STALE TRACKERS: Walk SPEC_STATE.md and ADDENDA_STATE.md. Flag rows
where referenced file has been modified but tracker row date is
older than file's last commit.
7. QUEUE HEALTH METRICS: Compute:
- actionable_count_this_week
- actionable_count_last_week (from prior MAINTENANCE_REPORT.md)
- net_delta
- deferred_count, oldest_deferred_age
- oldest_actionable_age
- items_over_14_days, items_over_30_days
- top 5 recurring source docs (frequency of appearance in
PENDING_OPA_UPDATES.md over last 4 weeks)
- discipline_status: improving (net_delta negative, oldest < 14
days) / stable (net_delta near zero) / worsening (net_delta
positive 2+ weeks running, OR items_over_30_days > 5).
8. FREEZE STATUS: If OPA_FREEZE.md is ACTIVE, report status, end_date,
days_remaining, deferred_queue_growth_rate. If days_remaining <= 7,
surface as top maintenance item. If deferred queue grew for 2+
consecutive weeks, surface as top maintenance item.
9. TOP 5 ACTIONS: Rank by load-bearing weight (Bucket-A-style splits >
high-signal drift > §9 ripened needing decision > §3 ready-fold-in >
stale tracker > low-signal drift). Tie-break by age.
10. Optional: produce one-paragraph email-style digest at top of report.
OUTPUT: MAINTENANCE_REPORT.md (overwrite). Sections:
- Week-of [date]
- Discipline Status (one line: improving/stable/worsening + why)
- This Week's Top 5 Actions
- Queue Health Metrics
- Freeze Status (if active)
- Carried Forward from Prior Weeks
- This Week's New Actionable Drift
- Deferred Per Freeze (count + top items)
- §9 Ripening Items
- §3 Pending Fold-Ins Ready to Promote
- Stale Tracker Rows
- Notes / Anomalies
Dashboard refresh task renders summary into "This Week's Maintenance"
panel including queue trend chart.
NEVER modify OP-A, SPEC_STATE, ADDENDA_STATE, OPA_FREEZE.md, or any
spec. Only writes to MAINTENANCE_REPORT.md.
```
### A.3 Initial `OPA_FREEZE.md` content (for the current flatten)
```markdown
# OPA Freeze Manifest
**Status:** ACTIVE
**Started:** 2026-05-27
**End date (hard):** 2026-06-17 (21 days from start)
**Renewable:** Yes, by writing a new manifest with documented reason.
Max single freeze duration: 30 days.
**Reason:** Memory rebuild flatten in progress (Stage 5R → Stage 5R3 →
OP-A V4). OP-A will not be updated for memory-plane retargeting until
Stage 5R3 audit completes and OP-A V4 ships.
**Freeze owner:** Will (architect)
**Review cadence:** Weekly Monday maintenance pass reports status.
Warnings fire 7 days before end_date and if deferred queue grows
2+ consecutive weeks.
## In-scope (drift items DEFERRED, not actionable)
Allowlist — no operator-judgment fallback:
- `Memory Rebuild Docs/` (entire folder)
- `Current Specs/DOC80 Memory Control Plane/` (entire folder)
## Out-of-scope (drift items ACTIONABLE as normal)
All other paths under `Current Specs/`, `Active Working and Red Team/`,
`OP-A and Operations and Trackers/` (excluding tracker files themselves).
This includes edits to DOC72 / DOC73 / DOC1 / DOC8 / DOC25 / DOC15 that
are NOT primarily memory-plane retargeting work — those edits still
generate actionable drift signals on the normal queue.
## Auto-expiration behavior
When 2026-06-17 passes without renewal:
1. Status flips to EXPIRED.
2. Deferred items in PENDING_OPA_UPDATES_DEFERRED.md move to
PENDING_OPA_UPDATES.md as ACTIONABLE (requires triage).
3. Weekly Monday pass surfaces the merged queue as top maintenance item.
## Resolution
When Stage 5R3 audit completes and OP-A V4 ships:
1. Move DEFERRED queue items into the audit's input (if not already
consumed by Pass 2).
2. Update this file's status to RESOLVED.
3. Archive to `OP-A and Operations and Trackers/Archived DOC OP-A and
Operations DOCS/` with timestamp.
```
---
## Appendix B — Audit-launch prompts (NEW IN R3 — focus of final review)
These are the operational prompts to launch the audit. Pass 0 is architect/Cowork. Pass 1 is Codex. Pass 2 is Claude Code. All three are scoped to surface work to the architect; none modify OP-A, specs, or other trackers without explicit architect ratification.
### B.1 Pass 0 — Freeze + Source Package Setup (Cowork or architect)
```
ROLE: Set up state for Stage 5R3 audit. Confirm inputs, declare freeze,
produce source package for Pass 1.
ESTIMATED TIME: 1 hour.
INPUTS:
- /Users/OpenClaw1/Elnor/Elnor Specs/ (GitHub repo wbrody/Elnor-Specs)
- This proposal (Stage_5R3_Audit_Proposal_R3.md)
- OP-A and Operations and Trackers/OPA_V3_18.md (or current OP-A)
- OP-A and Operations and Trackers/MASTER_SPEC_DOCUMENT_LIST.md
(currently MASTER_SPEC_DOCUMENT_LIST_R3.62.md until renamed)
- Stage 5R2 deliverables location (consolidated synthesis must-fix
instructions)
TASKS:
1. Write OPA_FREEZE.md at OP-A and Operations and Trackers/OPA_FREEZE.md
using the template in Appendix A.3 of this proposal, with these
specifics:
- Status: ACTIVE
- Started: today
- End date: 21 days from today
- In-scope: Memory Rebuild Docs/ entire folder; Current Specs/DOC80
Memory Control Plane/ entire folder
- Out-of-scope: everything else under Current Specs/, Active Working
and Red Team/, OP-A and Operations and Trackers/ (excluding
tracker files themselves)
2. Confirm OP-A path and version. Record in Stage_5R3_Source_Package.md.
3. Confirm Master Spec List path and version. Record.
4. Confirm output paths and create empty stubs:
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES.md
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DEFERRED.md
- OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DISMISSED.md
- OP-A and Operations and Trackers/MAINTENANCE_REPORT.md (placeholder)
- Stage_5R3/PASS_1_INVENTORY.md (and other Pass 1 output paths)
- Stage_5R3/OPA_V4_CANDIDATE.md (Pass 2 output path)
5. Confirm Stage 5R2 status. Record one of: in_progress / patches_applied
/ complete. If patches_applied or complete, identify the patch
summary file so Pass 2 can import 5R2 deltas if Pass 2 runs before
5R2 fully completes.
6. Produce Stage_5R3_Source_Package.md listing every source Pass 1 will
walk. Include:
- Path
- Type (operative spec / absorbed addendum / coordination ledger /
ADQ ledger / conflict register / supersession matrix / in-flight
proposal)
- Last-modified commit
- §3 disposition (folded / pending / not-yet-listed)
- Notes on known §22-style sections
DELIVERABLES:
- OPA_FREEZE.md (active)
- Stage_5R3_Source_Package.md (Pass 1 input)
- Empty output stubs in place
CONSTRAINTS:
- Do not modify OP-A.
- Do not modify any spec.
- If a path cannot be confirmed, surface and stop; do not guess.
```
### B.2 Pass 1 — Coverage audit (Codex)
```
ROLE: Walk the ELNOR spec corpus and produce a coverage inventory for
the Stage 5R3 retargeting audit. Inventory only. No retargeting
decisions. Surface work; do not modify trackers or specs.
INPUTS:
- /Users/OpenClaw1/Elnor/Elnor Specs/ (GitHub repo wbrody/Elnor-Specs)
- Stage_5R3_Source_Package.md (from Pass 0)
- OP-A and Operations and Trackers/OPA_V3_18.md (or current OP-A)
- Stage_5R3_Audit_Proposal_R3.md (this proposal, for context)
SCOPE:
- All ~141 entries in Master Spec List R3.62.
- All absorption events since OP-A V3.10 (per OP-A's §3 source
registry and the maintenance log §10).
- ADQ ledger (Stage 5R Round 1 resolved 43 ADQs; locate ledger and
surface its location if not in source package).
- Conflict/Disagreement Register (locate; surface location).
- Supersession Matrix (locate; surface location).
- In-flight proposals not yet absorbed.
TASKS:
A. CORPUS CLASSIFICATION
For each spec in Master Spec List, classify into one of:
- memory_plane_member: DOC80–DOC87 (skip — not yet operative)
- memory_plane_owner: DOC72, DOC73, DOC1, DOC8, DOC15, DOC25, EC Core,
BDSM, KDA, PropA (verify each has a §6 section in OP-A; spot-check
coverage)
- downstream_consumer: DOC3, DOC10, DOC20, DOC23 family, DOC12 (verify
coverage; flag §22-style sections not yet folded)
- intake_source: DOC25 partly, DOC20 Q Browser Intake, possibly DOC23
task-output-to-memory proposals, DOC12 rooms (verify)
- non_memory: skip
Partition all subsequent outputs by this classification AND by DOC
family.
B. §22-SECTION INVENTORY
For each non-skip spec:
1. Locate cross-doc obligation section. Pattern match for any of:
§22, Appendix [letter], OBL-XDOC tables, XDI tables, amendment
matrix, "Cross-Doc Obligations" header.
2. Confirm spec is listed in OP-A §3 (folded-in OR pending). Output:
- matched_in_section_3: yes/no
- section_3_disposition: folded/pending/missing
3. If folded: sample 3–5 obligations from the §22-style section;
check whether each has a corresponding row in OP-A §6 with
matching target, source citation, and acceptance criteria. Output
for each: row_id_or_missing, content_matches/drifted/missing.
4. If pending: confirm disposition still correct given current spec
state.
5. If missing: flag for §3 addition.
C. ABSORPTION-EVENT WALK
For each absorption event recorded in OP-A §3 since V3.10 (GIE V2.2,
KIE R2, EC Core V3.3, KDA R3, BDSM V6.5, DOC23 Addenda B family
landings, etc.):
1. Locate the absorbed source's cross-doc obligation section
(typically Appendix A/C or similar).
2. For each obligation in the absorbed source: check whether it
produced a §6 row in OP-A within 2 OP-A versions of absorption.
3. Flag any obligation in an absorbed source that has no
corresponding §6 row.
D. ADQ + REGISTER WALK
For each resolved ADQ since 2026-04-26 (Stage 5R Round 1 resolved 43
including ADQ-220 adding DOC87):
1. Identify cross-doc obligations created by the resolution.
2. Check whether each is reflected in OP-A §6 or §9.
3. Flag missing.
Walk Conflict Register and Supersession Matrix similarly.
E. EXISTING-ROW SOURCE VALIDATION (10% SAMPLE)
Sample 50–55 rows from §6 across multiple target-doc sections.
For each sampled row:
1. Open cited source spec at the cited section.
2. Check whether row content (target doc, obligation, acceptance
criteria) still matches source content.
3. Classify: matches / drifted-source-changed / drifted-target-stale /
row-obsolete-no-longer-applicable.
Output: PASS_1_ROW_SOURCE_DRIFT.md with sampled rows + classifications.
F. §9 TRIAGE
For each item in OP-A §9 Open Meta-Architecture Questions:
1. Classify: resolvable-from-inventory (mechanical) vs.
requires-architect-decision (judgmental).
2. For resolvable items: produce one-line proposed resolution.
3. For decision items: produce one-line framing.
G. DISTRIBUTION PREVIEW
Across all coverage findings, count candidate retarget destinations:
- DOC81 likely-retargets: N
- DOC82 likely-retargets: N
- DOC83 likely-retargets: N
- DOC84 likely-retargets: N
- DOC85 likely-retargets: N
- DOC86 likely-retargets: N
- DOC87 likely-retargets: N
- Likely splits across 2+ members: N
- Likely absorbed-into-DOC72-§42A: N
- Likely no-clean-target (architect decision needed): N
This is a preview, not a decision. Pass 2 produces actual retargets.
DELIVERABLES (all to Stage_5R3/ output folder):
- PASS_1_INVENTORY.md — §22-section inventory by spec, partitioned by
DOC family. Each entry: spec_path, family, classification,
has_section_22, section_3_disposition, sampled_obligations_matching,
flags.
- PASS_1_MISSING_SOURCES.md — sources not in §3 with recommended
disposition (fold_now / fold_next_session / defer_pending_revision /
out_of_scope).
- PASS_1_ROW_SOURCE_DRIFT.md — 10% sample row validation results.
- PASS_1_S9_TRIAGE.md — §9 items classified.
- PASS_1_DISTRIBUTION_PREVIEW.md — retarget destination counts.
- PASS_1_ARCHITECT_DECISIONS.md — items requiring decision before Pass
2 begins (e.g., uncertain ADQ resolutions, ambiguous classification
cases, source documents found but disposition unclear).
CONSTRAINTS:
- NEVER modify OPA_V3_18.md (or current OP-A version).
- NEVER modify any spec.
- NEVER produce retargeting decisions (Pass 2's job).
- For every claim, cite source file path and line number or section
reference.
- If a required input cannot be located, surface in
PASS_1_ARCHITECT_DECISIONS.md and continue with partial coverage
rather than guessing.
ARCHITECT REVIEW between Pass 1 and Pass 2:
After Pass 1 completes, the architect reviews the six deliverables
(can be reviewed independently by DOC family thanks to partitioning),
resolves PASS_1_ARCHITECT_DECISIONS.md, and confirms readiness for
Pass 2.
```
### B.3 Pass 2 — Retargeting audit (Claude Code)
```
ROLE: Take Pass 1's inventory and produce OP-A V4 candidate with
retargeted §6, expanded §3, refined §5(b), and rewritten §15A.
Surface unhandled decisions to architect via three-bucket
partitioning. Do not modify any spec.
PRECONDITION:
- Pass 1 complete; architect has resolved
PASS_1_ARCHITECT_DECISIONS.md.
- Stage 5R2 must-fix patches applied to skeletal baseline OR Stage 5R2
delta package available for explicit import.
INPUTS:
- All Pass 1 deliverables (six files in Stage_5R3/).
- OP-A and Operations and Trackers/OPA_V3_18.md (or current OP-A).
- Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/
DOC80_Skeletal_Target_Baseline.md (post-5R2 state).
- Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/ (Owner Map for
ownership rules).
- Stage 5R2 patch summary file (from Pass 0 confirmation, if Pass 2
runs before 5R2 fully complete).
- Stage_5R3_Audit_Proposal_R3.md (this proposal, for §5(b) refinement
text and §15A rewrite scope).
TASKS:
A. ROW TAGGING
For every existing §6 row in OP-A V3.18, assign:
- pre_flatten: row's current target is a pre-flatten memory owner
whose ownership is moved by the flatten (DOC1 memory governance,
DOC8 self-learning, DOC72 memory storage, DOC25 ingestion, DOC15
CIL memory concerns, EC Core memory concerns).
- flatten_aware: row already targets a memory-plane member, or
targets an owner whose ownership is unchanged by the flatten.
- not_memory: orthogonal to the memory plane (e.g., DOC11 OpenClaw
runtime concerns, DOC20 non-memory UI surfaces).
Output partitioned counts.
B. RETARGETING (for each pre_flatten row)
Produce a disposition:
- retarget: single new owner. Specify new target doc + section.
- split: multiple new owners. Specify each destination owner with
portion of original obligation that lands there. Assign
split_group_id grouping the resulting rows.
- absorbed: new architecture handles this differently; obligation no
longer needed. Specify which member's design absorbs it and why.
Row moves to §7 (Absorbed Obligations).
- unhandled: no clean target. Specify the difficulty. Goes to
Bucket C for architect decision.
For each retarget/split decision, classify source_stability:
- stable_architectural_concern
- version_specific_detail
- actively_revised_source
- imminent_revision_expected (commits to source draft in last 14 days)
- unknown_requires_architect_review
C. NEW §6 SECTIONS
Add §6 sections for DOC80, DOC81, DOC82, DOC83, DOC84, DOC85, DOC86,
DOC87. Each section lists retargeted rows + any new rows from Pass 1
sources targeting that member.
D. NEW ROWS FROM PASS 1
For each entry in PASS_1_MISSING_SOURCES.md with disposition fold_now,
author corresponding §6 rows. For each entry in
PASS_1_ROW_SOURCE_DRIFT.md, either update the existing row to current
source content or flag for replacement.
E. §9 RESOLUTION
For each PASS_1_S9_TRIAGE.md resolvable-from-inventory item, resolve
mechanically (remove from §9; if it ripened into an obligation, add as
§6 row). Requires-architect-decision items remain in §9 with one-line
framing; ratification happens at V4 architect review.
F. §3 EXPANSION
Update §3 source registry with all Pass 1 findings. Add new folded
sources; add new pending sources; update dispositions for existing
sources. Expand to include ADQ ledger, Conflict Register, Supersession
Matrix as standing sources.
G. §5(B) REFINEMENT
Replace existing §5(b) text with the refined scope rule from §5(b) of
Stage_5R3_Audit_Proposal_R3.md (active/current; stable-but-unrevised
with stable architectural concerns; actively revised; imminent
confirmed revisions with 14-day commit window).
H. §15A REWRITE
Replace existing §15A with expanded version covering:
- Pre-flight checklist for spec revisions
- Session-close checklist (extend current §15A)
- Standardized cross-doc obligation section format (minimum fields)
- Supersession/retargeting protocol
- Deep audit cadence (every 5 OP-A versions or quarterly)
- Version-bump conventions
- Explicit references to Pieces 1/2/3 automation backstop
Draw the specifics from §6 and §11 of Stage_5R3_Audit_Proposal_R3.md.
I. THREE-BUCKET PARTITIONING
Partition all retargeting decisions:
- BUCKET_A (confident retargets): 1:1 ownership moves where the new
target is unambiguous from Owner Map and source_stability is
stable_architectural_concern. Bulk-ratifiable.
- BUCKET_B (splits): rows splitting across 2+ members. Per-row
review needed.
- BUCKET_C (architect decisions): unhandled rows, unresolved §9
items, contested classifications, anything with
source_stability=unknown_requires_architect_review.
DELIVERABLES (all to Stage_5R3/ output folder):
- OPA_V4_CANDIDATE.md — proposed V4 of OP-A with all changes above
applied. Mark V4 in header; preserve V3.18 as prior version reference.
- BUCKET_A_CONFIDENT_RETARGETS.md — list of rows in Bucket A with
one-line justification each, formatted for bulk ratification.
- BUCKET_B_SPLITS.md — list of split rows with split rationale,
destination owners, split portions, and per-row review prompt.
- BUCKET_C_ARCHITECT_DECISIONS.md — decision queue for unhandled
rows + unresolved §9 items + contested classifications.
ROW FIELD STANDARD for every retargeted row in V4:
row_id, old_target_doc, old_target_section, source_doc,
source_section_ref, source_stability, flatten_status, disposition,
new_target_doc_or_docs, split_group_id (if applicable), reason,
architect_review_required, stage6_slice_refs, stage7_verification_
required.
CONSTRAINTS:
- NEVER modify any spec file under Current Specs/, Memory Rebuild
Docs/, or any other repo location outside Stage_5R3/.
- Produce OPA_V4_CANDIDATE.md, not in-place edits to OPA_V3_18.md.
- For every retargeting decision, cite Pass 1 source (which Pass 1
deliverable / line) and the Owner Map / Skeletal Baseline section
that establishes the new ownership.
- If a row's correct disposition is genuinely ambiguous, place it in
Bucket C rather than guessing.
- Do NOT autonomously promote items between buckets after initial
classification.
ARCHITECT REVIEW after Pass 2:
- Bucket A: read summary; bulk-ratify or kick back the bucket.
- Bucket B: per-row review (typically 10-30 rows; each takes 1-2
minutes).
- Bucket C: decide each item.
- Ratify OPA_V4_CANDIDATE.md → publish as OP-A V4.
- §15A rewrite reviewed inline as part of V4 ratification.
```
---
*End of proposal R3. Final review pass scoped to Appendix B (audit-launch prompts). After ratification, execute Pass 0 today; Pass 1 follows; architect review; Pass 2 follows Stage 5R2 stabilization; V4 ratification; Stage 6 commences.*