ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Flattening/Reviews/Stage_5R3_Audit_Proposal_R3_1.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Stage 5R3 Proposal R3.1 — Cross-Doc Obligation Audit + Forward Discipline Automation **Status:** Ready to commission. Architectural shape ratified through R2 cycle; Appendix B operational refinements ratified through R3 final-review cycle. This R3.1 folds in the final-review patch list. **Date:** 2026-05-27 **Author:** Claude (R3.1 incorporates the unified R3 final review: Claude + ChatGPT) **Supersedes:** Stage 5R3 Audit Proposal R3 (2026-05-27) **Canonical output directory for all audit artifacts:** `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/` **Ratified OP-A V4 destination:** `OP-A and Operations and Trackers/` --- ## What changed in R3.1 from R3 R3.1 applies the unified final-review patch list (39 items across two reviewers) plus two architect-side simplifications. To keep the patch from sprawling, overlapping items were merged and a few over-engineered items were cut. The net effect: **The one big addition — Will Review Packet.** Every stop gate (Pass 0, Pass 1, Pass 2) and the weekly maintenance cycle produces a single short document — the only thing you read by default. Raw inventories, buckets, and row tables become drill-down-only supporting artifacts. Defined once in §6.5; referenced by every pass. **Operational fixes folded in:** - Canonical output path defined (`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`); every Appendix B reference uses it. - Pass 0 pins paths + commit hashes for all inputs (ADQ ledger, Conflict Register, Supersession Matrix, Stage 5R2 artifacts, DOC80 baseline family) and produces a frozen baseline snapshot Pass 2 reads from. - Absorbed rows get an explicit review surface (a delimited section inside Bucket A — see simplification 2). - Stage 6 Charter Input Index added as a Pass 2 deliverable. - §15A Rewrite Preview added as a Pass 2 deliverable; Task H (the §15A rewrite) expanded with explicit length/structure/source specs. - Critical vs. noncritical missing inputs: critical inputs stop the audit; noncritical continue with a logged coverage gap. - Pass 1 source-drift validation uses stratified sampling biased toward high-risk owner moves, not uniform. - Mixed memory/non-memory rows must be tagged `pre_flatten` + `split`, never `not_memory`. - Finer source-drift classifications; Bucket A summary/full split if >100 rows; `confidence` field on rows. **Two architect simplifications (subtractive):** 1. **Pass 2 is a hard gate on Stage 5R2 stabilization + snapshot.** The R3-review "explicit delta import over snapshot" escape hatch is removed. Pass 2 does not start until Stage 5R2 is stabilized and snapshotted. Removes a fragile path where retargeting could run against stale architecture. (If you want the early-start option back, say so.) 2. **Absorbed rows are a delimited section inside the Bucket A summary, not a separate `BUCKET_A2` file.** Absorbed rows are bulk-ratifiable like Bucket A; keeping them in one file with a clear heading avoids an extra artifact while preserving visibility. **Merged/cut from the 39-item list (so you know what I didn't pass through mechanically):** - Three separate "pin commit hashes" items merged into one Pass 0 task. - The standalone `BUCKET_A2_ABSORBED_MECHANICAL.md` deliverable cut in favor of simplification 2. - The "explicit delta import" alternative cut in favor of simplification 1. - Field-level enum specs (e.g., `sample_reason` values, `confidence` values) kept but live entirely inside the agent prompts in Appendix B — they never surface to you. Body sections §§1–3, §5, §7, §9, §10, §11 are unchanged from R3 except where a patch touches them. Appendix B is fully rewritten. --- ## 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. - §3 Source Document Registry distinguishes "folded-in" from "NOT yet folded — planned for OP-A V4." - §9 Open Meta-Architecture Questions buffers soft-state items; working soft→hard promotion observed at V3.16. - §15A session-close discipline documented but unevenly applied — architect-acknowledged; treated as an automation-backstop problem. What this does NOT mean: OP-A is complete or the memory rebuild is accounted for. ## 2. The actual gaps ### 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 added §6 sections for the new members, retargeted existing rows, identified split rows, or identified obsolete rows. Why it can't be deferred to per-charter retargeting: a meaningful fraction of rows split across multiple members; per-slice retargeting produces inconsistent split decisions. The whole-corpus pass makes split/absorb decisions once, before charters consume them. ### Gap 2: §3 inventory undercount Pass 1 walks every absorption/integration event since OP-A V3.10 plus: GIE V2.2 Appendix A/C, KIE R2, EC Core Addendum A V3.3 cross-doc surface, DOC23 Addenda B family coordination ledger, DOC11 R15 R3, MultiDoc PropA R6.3, Sub-Agent Architecture V5.2, ADQs (43 resolved in Stage 5R Round 1), Conflict/Disagreement Register, Supersession Matrix, DAMS V4.1 disposition, in-flight addenda. Flags every cross-doc-touching artifact lacking a §3 entry. ### Gap 3: Spec-internal §22-style sections not yet migrated Active specs migrated; less-active 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. ### Gap 5: In-flight proposals not registered DOC20 Q Browser Intake and likely others. Pass 1 surfaces and registers. ### Gap 6: Soft-state §9 items ripening Pass 1 classifies each as "resolvable from inventory" or "requires architect decision." ### Gap 7: No structural defense against silent §22-skip Closed by Piece 1 (nightly drift detector). ### Gap 7b: Existing row content drift A row's source section changed since the row was authored; the row is stale though physically placed correctly. Pass 1 samples §6 rows (stratified) and validates content against current source. ## 3. Goals **Goal A — Memory rebuild completeness.** Every obligation the new memory plane should accommodate is in OP-A with a target 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; cross-doc obligations addressed in small weekly batches via automation backstops, not 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, source package, baseline snapshot (Cowork or architect) Estimated 1 hour. Executable prompt in Appendix B.1. - Write `OPA_FREEZE.md`. - Pin paths + commit hashes for every input: current OP-A, Master Spec List (+ entry count), ADQ ledger, Conflict/Disagreement Register, Supersession Matrix, OP-A Disposition file, Stage 5R2 patch/delta package, DOC80 Skeletal Baseline, Owner Map, Import Graph, Retired Names. - Produce a frozen baseline snapshot at `Stage_5R3/baseline_snapshot/` (Skeletal Baseline, Owner Map, Import Graph, Retired Names). Pass 2 reads from the snapshot, not live files. - Classify missing inputs: critical (stop) vs. noncritical (continue with logged coverage gap). - Produce `Stage_5R3_Source_Package.md` and `Stage_5R3_Control_Board.md` (the first Will Review Packet). - Document freeze-renewal procedure. ### Pass 1 — Coverage audit (Codex) Inventory only. No retargeting. Executable prompt in Appendix B.2. Walks the corpus + absorption events + ADQ/Conflict/Supersession ledgers. Inventories §22-style sections; confirms §3 coverage; validates a stratified sample of existing rows against source; triages §9; produces a distribution preview; partitions all output by DOC family. Deliverables (in `Stage_5R3/`): `PASS_1_WILL_REVIEW_PACKET.md` (the one you read) + six supporting files (`PASS_1_INVENTORY.md`, `PASS_1_MISSING_SOURCES.md`, `PASS_1_ROW_SOURCE_DRIFT.md`, `PASS_1_S9_TRIAGE.md`, `PASS_1_DISTRIBUTION_PREVIEW.md`, `PASS_1_ARCHITECT_DECISIONS.md`). ### Pass 2 — Retargeting audit (Claude Code) **Hard gate:** does not start until Stage 5R2 is stabilized AND the baseline snapshot reflects post-5R2 state. Executable prompt in Appendix B.3. Tags every §6 row (`pre_flatten` / `flatten_aware` / `not_memory` / mixed→split); produces retarget/split/absorbed/unhandled dispositions against the frozen snapshot; adds DOC80–DOC87 §6 sections; resolves §9 mechanical items; expands §3; refines §5(b); rewrites §15A. Deliverables (in `Stage_5R3/`): `PASS_2_WILL_REVIEW_PACKET.md` (the one you read) + `OPA_V4_CANDIDATE.md`, `BUCKET_A.md` (confident retargets + absorbed section), `BUCKET_B_SPLITS.md`, `BUCKET_C_ARCHITECT_DECISIONS.md`, `STAGE_6_CHARTER_INPUT_INDEX.md`, `SECTION_15A_REWRITE_PREVIEW.md`. ### Why three stages, three tools Pass 0 sets up state (cheap, bounded). Pass 1 is breadth (corpus walk, no decisions, Codex). Pass 2 is depth (retargeting + V4, Claude Code). Architect reviews between each via the Will Review Packet. ## 5. Staleness handling **(a) Stable vs. version-dependent.** Pass 2 captures stable architectural concerns via `source_stability`. 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 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. **(c) Flatten itself is a major revision in progress.** One comprehensive retargeting now (against post-5R2 frozen snapshot). 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. All are **surface-only**: never modify OP-A, SPEC_STATE, ADDENDA_STATE, or any spec. They produce reports and queues; the architect (or a commissioned Claude Code session) does the writes. ### Piece 1 — Nightly OP-A drift detector (extends `elnor-nightly-spec-sync`) Folded into the existing nightly sync. Two-tier detection (`drift_candidate` / `obligation_likely_drift`). Reads `OPA_FREEZE.md` to defer in-scope items. Tracks dismissals for self-tuning. Outputs `PENDING_OPA_UPDATES.md` + `PENDING_OPA_UPDATES_DEFERRED.md`. Closes Gap 7. Sketch in Appendix A.1. ### Piece 2 — Monday early-AM weekly maintenance pass (new SKILL) Ships coupled with Pieces 1+3. First run the Monday after Piece 1 has 7+ nights of data. Produces `MAINTENANCE_REPORT.md` styled as a Will Review Packet (top-5 actions, queue health metrics, freeze status). The daily Piece 1 panel stays minimal. Sketch in Appendix A.2. Your weekly load is ~30–45 min: scan the report, pick batches to commission, hand each to a Claude Code session, review its diff later. Row work is done by the commissioned session, not you. ### Piece 3 — Freeze mechanic (anti-abuse hardened) Hard end date (max 30 days; current flatten freeze 21 days), explicit scope allowlist (no operator-judgment fallback), expiration warning at 7 days, auto-expiration moving deferred items back to actionable, anti-indefinite-defer rule. In-scope/out-of-scope distinction preserved. Template in Appendix A.3. ### §15A rewrite in OP-A V4 (replaces a separate companion doc) Audit findings inform a tightened §15A authored into OP-A V4 itself. Covers pre-flight checklist, session-close checklist, standardized cross-doc obligation section format, supersession/retargeting protocol (incl. spec-archival case), deep-audit cadence, version-bump conventions, future-process rule (every revision touching another owner doc updates OP-A inline / queues a pending item / certifies no obligation), and explicit references to Pieces 1/2/3. Authored in Pass 2 (Task H); previewed standalone in `SECTION_15A_REWRITE_PREVIEW.md`. ### Piece 4 (contingency) — Pass 2.5 Only triggered if you materially revise or reject §15A during V4 ratification. A narrow cleanup pass with a focused prompt. Not run by default. ### 6.5 — The Will Review Packet (required at every stop gate) **Mandatory deliverable.** Pass 0, Pass 1, Pass 2, and every weekly maintenance cycle produce exactly one Will Review Packet. It is the only document you read by default. Every other artifact (inventories, buckets, ledgers, row tables, the V4 candidate itself) is a supporting artifact you drill into only if a line in the packet points you there. If an agent skips the packet, the stop gate is incomplete — the prompts in Appendix B make it a hard requirement, not a suggestion. **Fixed template** (same skeleton every time): ```markdown # [Stage / Pass / Week] — Will Review Packet STATE: WHAT YOU MUST DECIDE ( items): 1. (recommendation: ) 2. ... (If none: "Nothing — this is informational.") SAFE TO BULK-APPROVE: BLOCKED / MISSING: KEY NUMBERS / SHAPE: NEXT ACTION: SUPPORTING FILES (drill in only if a line above sends you there): ``` Length target: one screen (≈half a page). Recommendations always included so you can ratify-by-default and only intervene where you disagree. ### Sunset criteria - Piece 2 retires if zero unique actions for 8 consecutive weeks. - Piece 1 detection tightens if dismissal rate >50% for 4 consecutive weeks. - Freeze mechanic retires if no freeze declared for 60 days after the current flatten freeze ends. - Deep audit cadence reviewed at OP-A V5. ## 7. Sequencing | Item | Status | Gate | |---|---|---| | Pass 0 (freeze + source package + snapshot) | Ready; runs today | None | | Stage 5R2 must-fix patches | Authorized | Runs in parallel with Pass 1 | | Piece 1 (drift detector) | Ready | After Pass 0 | | Piece 2 (weekly pass) | Ready | After Pass 0; coupled with Piece 1 | | Pass 1 (Codex coverage) | Ready | After Pass 0; may parallel 5R2 | | Architect review of Pass 1 | — | After Pass 1 (read the packet) | | Pass 2 (Claude Code retargeting) | Ready | **HARD GATE: Stage 5R2 stabilized + snapshotted** | | Architect review + V4 ratification | — | After Pass 2 (read the packet) | | OP-A V4 ships | — | After ratification | | Stage 6 (charters) | Pending | After V4 (consume Charter Input Index) | | Stage 7 (schemas) | Pending | After Stage 6 | | Stage 7 OP-A Conformance Check (§11) | Proposed | After Stage 7 schema completion | ## 8. Deliverables **Pass 0:** `OPA_FREEZE.md`, `Stage_5R3_Source_Package.md`, `Stage_5R3/baseline_snapshot/`, `Stage_5R3_Control_Board.md` (Will Review Packet). **Pass 1:** `PASS_1_WILL_REVIEW_PACKET.md` + six supporting files. **Pass 2:** `PASS_2_WILL_REVIEW_PACKET.md`, `OPA_V4_CANDIDATE.md`, `BUCKET_A.md`, `BUCKET_B_SPLITS.md`, `BUCKET_C_ARCHITECT_DECISIONS.md`, `STAGE_6_CHARTER_INPUT_INDEX.md`, `SECTION_15A_REWRITE_PREVIEW.md`. **Forward discipline:** extended `elnor-nightly-spec-sync`, new `elnor-weekly-maintenance-pass`, three dashboard panels. **NOT in scope:** rewriting consumer/intake specs; new schemas/members; re-running Stage 5R2. ## 9. Open questions resolved All R2 and R3 questions resolved. Final-review disagreement (Pass 2.5 vs. preview) resolved in favor of preview-by-default with contingent Pass 2.5. ## 10. (reserved) ## 11. Stage 7 OP-A Conformance Check After Stage 7 schema completion, one check (not a full audit): every DOC80–DOC87 OP-A row maps to a drafted section/schema/fixture/lint, OR has documented defer (ADQ/new row) / reject (architect rationale) / re-route (owner-doc amendment). Mismatches surface as architect-decision items. ~30 min architect review. Implementable as a Cowork SKILL or one Claude Code session. --- ## Appendix A — Forward-discipline SKILL prompts ### A.1 Extension to `elnor-nightly-spec-sync` (drift detection) ``` ADD TO existing elnor-nightly-spec-sync SKILL: ROLE: After mechanical drift tracking, surface specs 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 (or current OP-A) - OP-A and Operations and Trackers/OPA_FREEZE.md - OP-A and Operations and Trackers/PENDING_OPA_UPDATES_DISMISSED.md STEPS (after current sync logic): 1. Read OPA_FREEZE.md. If status=ACTIVE, extract in-scope paths. If today is within 7 days of end_date, set freeze_expiring_warning=true. 2. Find OP-A last-modified commit (OPA_LAST). 3. For each .md under Current Specs/, Active Working and Red Team/, Memory Rebuild Docs/: find last-modified commit. 4. Classify: - drift_candidate: last_commit > OPA_LAST. - obligation_likely_drift: drift_candidate AND (matches regex §22|Appendix|OBL-XDOC|cross-doc obligation|XDI|amendment matrix [case-insensitive], OR changed lines mention owner names / MUST / SHALL / consumes / owns / imports / target-doc refs, OR file in family DOC72/DOC73/DOC24/DOC23/DOC15/EC Core/PropA/KDA/BDSM/DOC80-87). 5. Set drift_signal_strength: high (obligation_likely + high-oblig family) / medium (obligation_likely) / low (candidate only). 6. In-scope per freeze → DEFERRED; else ACTIONABLE. 7. Exclude candidates matching a PENDING_OPA_UPDATES_DISMISSED.md entry (path+commit) within last 30 days. 8. Write PENDING_OPA_UPDATES.md (actionable) and PENDING_OPA_UPDATES_DEFERRED.md (deferred), both overwrite. Columns: spec, last_commit, OPA_last_commit, has_obligation_section, drift_signal_strength, likely_target, recommended_action [+ freeze fields for deferred]. 9. Append one summary line to DRIFT_LOG.md (timestamp, counts by strength, deferred count, top-3 high, freeze_expiring_warning). NEVER modify OP-A, specs, or PENDING_OPA_UPDATES_DISMISSED.md. ``` ### A.2 `elnor-weekly-maintenance-pass` (new SKILL) ``` ROLE: Produce the weekly Will Review Packet so Will addresses drift in small batches. The report is a triage surface; Will picks batches and hands them to Claude Code sessions. Never modify OP-A, trackers, or specs. SCHEDULE: Monday ~5:00 AM local. First run: 7+ days after drift detection starts producing PENDING_OPA_UPDATES.md. INPUTS: repo; current OP-A; SPEC_STATE.md; ADDENDA_STATE.md; PENDING_OPA_UPDATES.md; PENDING_OPA_UPDATES_DEFERRED.md; PENDING_OPA_UPDATES_DISMISSED.md; DRIFT_LOG.md; MASTER_SPEC_DOCUMENT_LIST.md; prior MAINTENANCE_REPORT.md; OPA_FREEZE.md. EACH MONDAY: 1. Carry-forward open items from prior report. 2. This week's actionable drift (dedupe vs carry-forward). 3. This week's deferred drift (count + top items). 4. §9 ripening: walk OP-A §9; flag items whose referenced spec/version shipped or whose decision was recorded. 5. §3 pending fold-ins: flag sources whose target spec has stabilized (no commits 7 days). 6. Stale trackers: flag SPEC_STATE/ADDENDA_STATE rows older than their file's last commit. 7. Queue health: actionable_count_this_week, _last_week, net_delta, deferred_count, oldest_actionable_age, oldest_deferred_age, items_over_14_days, items_over_30_days, top-5 recurring source docs, discipline_status (improving/stable/worsening). 8. Freeze status: if ACTIVE, report end_date, days_remaining, deferred growth; surface as top item if days_remaining<=7 or deferred grew 2+ wks. 9. Rank top-5 actions (load-bearing > high-signal drift > §9 ripened needing decision > §3 ready fold-in > stale tracker > low-signal drift; tie-break by age). OUTPUT: MAINTENANCE_REPORT.md (overwrite), formatted as a Will Review Packet per proposal §6.5 (STATE / WHAT YOU MUST DECIDE / SAFE TO BULK-APPROVE / BLOCKED-MISSING / KEY NUMBERS = queue health / NEXT ACTION / SUPPORTING FILES). Dashboard renders summary + queue trend chart into "This Week's Maintenance." NEVER modify OP-A, SPEC_STATE, ADDENDA_STATE, OPA_FREEZE.md, or any spec. ``` ### A.3 Initial `OPA_FREEZE.md` (current flatten) ```markdown # OPA Freeze Manifest **Status:** ACTIVE **Started:** 2026-05-27 **End date (hard):** 2026-06-17 (21 days) **Renewable:** Yes, by writing a new manifest with documented reason. Max single freeze: 30 days. **Reason:** Memory rebuild flatten (Stage 5R → Stage 5R3 → OP-A V4). OP-A not updated for memory-plane retargeting until V4 ships. **Freeze owner:** Will **Review cadence:** Weekly Monday pass. Warnings fire 7 days before end_date and if deferred queue grows 2+ consecutive weeks. ## In-scope (DEFERRED, not actionable) — allowlist, no judgment fallback - `Memory Rebuild Docs/` (entire folder) - `Current Specs/DOC80 Memory Control Plane/` (entire folder) ## Out-of-scope (ACTIONABLE as normal) All other paths. Edits to DOC72/DOC73/DOC1/DOC8/DOC25/DOC15 that are NOT primarily memory-plane retargeting still generate actionable drift. ## Auto-expiration When 2026-06-17 passes without renewal: status → EXPIRED; deferred items move to PENDING_OPA_UPDATES.md as ACTIONABLE; Monday pass surfaces merged queue as top item. ## Resolution When V4 ships: move deferred items into audit input (if not already consumed); status → RESOLVED; archive to Archived DOC OP-A and Operations DOCS/ with timestamp. ``` --- ## Appendix B — Audit-launch prompts (R3.1) Paste each into the named tool. All three are surface-only; none modify OP-A, specs, or other trackers without explicit architect ratification. Each ends by producing a Will Review Packet per §6.5. ### B.1 Pass 0 — Freeze + Source Package + Baseline Snapshot (Cowork or architect) ``` ROLE: Set up state for the Stage 5R3 audit. Confirm and pin inputs, declare the freeze, snapshot the target baseline, produce the source package and the first Will Review Packet. ESTIMATED TIME: 1 hour. CANONICAL OUTPUT DIRECTORY: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/ Create it if absent. ALL audit artifacts go here. INPUTS (repo: /Users/OpenClaw1/Elnor/Elnor Specs/, GitHub wbrody/Elnor-Specs): - This proposal (Stage_5R3_Audit_Proposal_R3_1.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 (R3.62 file until renamed) - Stage 5R2 deliverables (consolidated synthesis must-fix instructions) TASKS: 1. FREEZE. Write OP-A and Operations and Trackers/OPA_FREEZE.md per Appendix A.3 of this proposal (Status ACTIVE; Started today; End date 21 days out; in-scope: Memory Rebuild Docs/ and Current Specs/DOC80 Memory Control Plane/; out-of-scope: everything else). Document the renewal procedure inside the manifest. 2. PIN INPUTS. Confirm path AND current commit hash for each of: - Current OP-A (record version + entry count: number of active §6 rows) - Master Spec List (record version + entry count) - Architect Decision Queue (ADQ ledger) - Conflict / Disagreement Register - Supersession Matrix - OP-A Candidate Disposition file (if present) - Stage 5R2 consolidated patch / delta package - DOC80 Skeletal Baseline - DOC80 Owner Map - DOC80 Import Graph - DOC80 Retired Names For any that cannot be located, classify: - CRITICAL (stop the audit): current OP-A, Master Spec List, ADQ ledger, Conflict Register, Supersession Matrix, Stage 5R2 target snapshot. - NONCRITICAL (continue, log a coverage gap): everything else. If any CRITICAL input is missing, STOP and surface in the Control Board; do not proceed to snapshot. 3. SNAPSHOT. Copy Skeletal Baseline, Owner Map, Import Graph, Retired Names into Stage_5R3/baseline_snapshot/ with their commit hashes recorded. Record Stage 5R2 status: complete | patches_applied | not_yet_stable. NOTE: Pass 2 reads from this snapshot. If Stage 5R2 is not_yet_stable, Pass 2 MUST NOT run until 5R2 stabilizes and this snapshot is refreshed. 4. SOURCE PACKAGE. Write Stage_5R3/Stage_5R3_Source_Package.md listing every source Pass 1 will walk: 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. 5. CONTROL BOARD. Write Stage_5R3/Stage_5R3_Control_Board.md as a Will Review Packet per proposal §6.5: - STATE: Pass 0 complete / blocked on missing critical input. - WHAT YOU MUST DECIDE: usually "none — confirm and run Pass 1" unless a critical input is missing. - SAFE TO BULK-APPROVE: n/a for Pass 0. - BLOCKED / MISSING: list any noncritical gaps; flag critical stops. - KEY NUMBERS: OP-A row count, Master Spec List entry count, Stage 5R2 status, freeze end date. - NEXT ACTION: "Run Pass 1" (paste B.2) — or resolve the missing critical input first. - SUPPORTING FILES: source package, freeze manifest, snapshot dir. DELIVERABLES: OPA_FREEZE.md; Stage_5R3_Source_Package.md; Stage_5R3/baseline_snapshot/; Stage_5R3_Control_Board.md. CONSTRAINTS: Do not modify OP-A or any spec. If a path can't be confirmed, surface and (for critical inputs) stop; never 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. Never modify OP-A or specs. CANONICAL OUTPUT DIRECTORY: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/ INPUTS: - Stage_5R3/Stage_5R3_Source_Package.md (from Pass 0) - Current OP-A (path/hash per source package) - This proposal (for context) SCOPE: all Master Spec List entries; all absorption events since OP-A V3.10 (per §3 registry + §10 maintenance log); ADQ ledger; Conflict Register; Supersession Matrix; in-flight proposals. TASKS: A. CORPUS CLASSIFICATION. For each spec, classify: - memory_plane_member (DOC80-87): skip as operative source; include as target architecture only if part of the frozen snapshot. - memory_plane_owner (DOC72, DOC73, DOC1, DOC8, DOC15, DOC25, EC Core, BDSM, KDA, PropA): verify §6 section exists; spot-check coverage. - downstream_consumer (DOC3, DOC10, DOC20, DOC23 family, DOC12): verify coverage; flag unfolded §22-style sections. - intake_source (DOC25 partly, DOC20 Q Browser, DOC23 task-output-to- memory, DOC12 rooms): verify. - non_memory: still run Task B step 1 (presence check) as a sanity check. - non_memory_with_memory_section: primarily non-memory but has a memory- touching §22 entry (e.g., DOC11 native-memory authority, DOC14 graph writes, DOC16 memory feeds). Inventory the memory-touching part. Fallback when no enumerated match: classify by whether the spec's §22-style content references memory-plane concepts (entity graph, node types, memory directives, extraction, ConsolidatedUnderstanding, KDA, BDSM, CIL injection, EC Core memory ops, knowledge intake, knowledge delivery). Partition all outputs by classification AND DOC family. B. §22-SECTION INVENTORY. For each non-skip spec: 1. Locate cross-doc obligation section(s): §22 / Appendix [letter] / OBL-XDOC / XDI / amendment matrix / "Cross-Doc Obligations" header. Inventory EACH such section separately if a spec has more than one. 2. Confirm spec in OP-A §3 (folded / pending / missing). 3. Presence check (all non-skip specs): sample 5-10 obligations; confirm each has a §6 row. Full coverage check (high-obligation specs: DOC72, DOC24, DOC23, EC Core, BDSM, KDA): check EVERY obligation. 4. Pending → confirm disposition still correct. Missing → flag for §3. C. ABSORPTION-EVENT WALK. For each absorption event in OP-A §3 since V3.10 (GIE V2.2, KIE R2, EC Core V3.3, KDA R3, BDSM V6.5, DOC23 Addenda B landings, etc.): locate the absorbed source's obligation section; for each obligation, check whether it produced a §6 row in any OP-A version between absorption-date and audit-start. Flag any with no row. D. ADQ + REGISTER WALK. For each resolved ADQ since 2026-04-26 (Stage 5R Round 1 resolved 43 incl. ADQ-220 adding DOC87): identify cross-doc obligations created; check reflection in §6/§9; flag missing. Walk Conflict Register and Supersession Matrix similarly. E. EXISTING-ROW SOURCE VALIDATION (stratified sample, ~50-55 rows): - 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. Include every known high-risk retarget candidate if row IDs are known; at least 2 rows from every large §6 section. For each sampled row, open the cited source section and classify: source_file_missing / source_section_missing / source_ref_ambiguous / source_content_changed / target_owner_stale / acceptance_criteria_drifted / row_obsolete / matches. Add sample_reason field (high_risk_owner_move / large_section / random / source_recently_changed / known_stale_candidate). F. §9 TRIAGE. For each §9 item: classify resolvable-from-inventory (give one-line proposed resolution) vs. requires-architect-decision (one-line framing). G. DISTRIBUTION PREVIEW. Count candidate retarget destinations: DOC80, DOC81, ..., DOC87, likely-splits, likely-absorbed-into-DOC72-§42A, likely-no-clean-target. Preview only; Pass 2 decides. DELIVERABLES (all to Stage_5R3/): - PASS_1_WILL_REVIEW_PACKET.md — the ONLY file Will reads by default, per proposal §6.5. STATE / WHAT YOU MUST DECIDE (architect-decision items + ambiguous classifications) / SAFE TO BULK-APPROVE (e.g., §3 fold-now adds) / BLOCKED-MISSING (critical stops, noncritical gaps) / KEY NUMBERS (distribution preview, coverage counts) / NEXT ACTION ("resolve decisions, then run Pass 2; Pass 2 also requires Stage 5R2 stabilized — status: X") / SUPPORTING FILES (the six below). - PASS_1_INVENTORY.md — §22-section inventory by spec, partitioned by family. - PASS_1_MISSING_SOURCES.md — fields: source_path, source_kind, why_missing_from_OPA_3, has_cross_doc_obligation_section, obligation_count_estimate, recommended_disposition (fold_now / fold_next_session / defer_pending_revision / out_of_scope), candidate_target_docs, architect_review_required, notes. - PASS_1_ROW_SOURCE_DRIFT.md — sampled-row validation with classifications + sample_reason. - PASS_1_S9_TRIAGE.md — §9 items classified. - PASS_1_DISTRIBUTION_PREVIEW.md — destination counts. - PASS_1_ARCHITECT_DECISIONS.md — items needing a decision before Pass 2. CONSTRAINTS: never modify OP-A or specs; no retargeting decisions; cite source path + line/section for every claim; if a CRITICAL input is unavailable, STOP and surface in the packet; for NONCRITICAL gaps, continue and log the gap. ARCHITECT REVIEW: Will reads PASS_1_WILL_REVIEW_PACKET.md, drills into supporting files only as the packet directs, resolves architect decisions, confirms readiness for Pass 2. ``` ### B.3 Pass 2 — Retargeting audit (Claude Code) ``` ROLE: Take Pass 1's inventory and produce the OP-A V4 candidate with retargeted §6, expanded §3, refined §5(b), and rewritten §15A. Surface unhandled items via buckets. Never modify any spec. CANONICAL OUTPUT DIRECTORY: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/ HARD PRECONDITIONS (refuse to run if unmet): - Pass 1 complete; PASS_1_ARCHITECT_DECISIONS.md resolved by Will. - Stage 5R2 stabilized AND Stage_5R3/baseline_snapshot/ reflects post-5R2 state. If the snapshot predates 5R2 stabilization, STOP and request a refreshed snapshot. (No delta-import path; the snapshot must be correct.) INPUTS: - All six Pass 1 deliverables (Stage_5R3/). - Current OP-A (path/hash per source package). - Stage_5R3/baseline_snapshot/ (Skeletal Baseline, Owner Map, Import Graph, Retired Names) — read ownership from HERE, not live files. - This proposal (for §5(b) text and Task H §15A scope). TASKS: A. ROW TAGGING. Tag every existing §6 row: - pre_flatten: target is a pre-flatten memory owner whose ownership moves. - flatten_aware: already targets a memory-plane member or unchanged owner. - not_memory: orthogonal to the memory plane. MIXED RULE: a row containing BOTH memory-plane and non-memory obligations is tagged pre_flatten with disposition split. Never classify mixed rows not_memory. RECONCILIATION: if Pass 1 inventory flags a row memory-related but tagging says not_memory, send to Bucket C with both evidences cited. B. RETARGETING (each pre_flatten row): disposition = - retarget: single new owner (specify doc + section). - split: multiple owners (enumerate sub-obligations by destination, not percentages; splits may cross family boundaries — memory member + non-memory consumer). - absorbed: new architecture handles it; obligation no longer needed (specify absorbing design element; row moves to §7). - unhandled: no clean target → Bucket C. For retarget/split, classify source_stability (stable_architectural_concern / version_specific_detail / actively_revised_source / imminent_revision_expected [draft commit in last 14 days] / unknown_requires_architect_review). C. NEW §6 SECTIONS for DOC80-DOC87 with retargeted + new rows. D. NEW ROWS from PASS_1_MISSING_SOURCES.md (fold_now) and PASS_1_ROW_SOURCE_DRIFT.md (update or replace drifted rows). E. §9 RESOLUTION: resolve an item mechanically ONLY if Pass 1 marked it resolvable-from-inventory AND Will approved/didn't modify that during Pass 1 review. Else leave in §9. F. §3 EXPANSION: add new folded + pending sources; update dispositions; add ADQ ledger, Conflict Register, Supersession Matrix as standing sources. G. §5(b) REFINEMENT: replace with the refined scope rule from §5(b) of this proposal (14-day commit window for imminent revisions). H. §15A REWRITE: replace §15A with an expanded version. SPECS: target 400-800 words; numbered checklists for pre-flight and session-close and supersession protocol; prose for cadence and version-bump conventions; preserve existing §15A text where still valid (don't rewrite wholesale); explicit spec-archival case (when a spec is archived, walk OP-A for rows targeting it, retarget or move to §7); future-process rule (every revision touching another owner doc updates OP-A inline / queues a pending item / certifies no obligation); explicit references to Pieces 1/2/3 by name and SKILL id. Source the specifics from §6 and §11 of this proposal. I. BUCKETING: - BUCKET_A.md: confident retargets (1:1 ownership move unambiguous from Owner Map; source_stability is informational metadata, NOT a gate) PLUS a clearly-delimited "## Absorbed (mechanical)" section listing absorbed rows (row_id, old_target, source, why_absorbed, absorbing DOC80-87 element, why no active row remains, stage7_verification_required). If an absorption isn't mechanically obvious, the row goes to Bucket C instead. If total Bucket A rows > 100, also produce BUCKET_A_SUMMARY.md (counts by old target, by new target, top-10 load-bearing, grouped by family) and keep BUCKET_A.md as the full list. - BUCKET_B_SPLITS.md: split rows with rationale, destinations, per-row review prompt. - BUCKET_C_ARCHITECT_DECISIONS.md: unhandled rows, unresolved §9 items, contested classifications, source_stability=unknown rows. ROW FIELD STANDARD (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 any), reason, confidence (high/medium/low by bucket), audit_pass (1/2/3), architect_review_required, stage6_slice_refs, stage7_verification_required. DELIVERABLES (all to Stage_5R3/): - PASS_2_WILL_REVIEW_PACKET.md — the ONLY file Will reads by default, per §6.5. STATE / WHAT YOU MUST DECIDE (Bucket C items; §15A confirm) / SAFE TO BULK-APPROVE (Bucket A incl. absorbed) / BLOCKED-MISSING / KEY NUMBERS (retarget/split/absorbed counts; bucket sizes) / NEXT ACTION (ratify buckets → publish V4) / SUPPORTING FILES (below). - OPA_V4_CANDIDATE.md — proposed V4; header marks V4, supersedes V3.18. - BUCKET_A.md (+ BUCKET_A_SUMMARY.md if >100 rows). - BUCKET_B_SPLITS.md. - BUCKET_C_ARCHITECT_DECISIONS.md. - STAGE_6_CHARTER_INPUT_INDEX.md — per DOC80-87 member: OP-A row IDs, source docs/sections, retarget/split/absorbed status, stage6_slice_refs, stage7_verification_required, unresolved ADQ/Bucket C dependencies. - SECTION_15A_REWRITE_PREVIEW.md — proposed §15A text standalone + mapping table (R3.1 requirement → §15A paragraph). CONSTRAINTS: never modify any spec; produce OPA_V4_CANDIDATE.md, not in-place edits to OP-A; cite Pass 1 source + snapshot Owner Map/Baseline section for every decision; genuinely ambiguous rows → Bucket C, don't guess; no autonomous bucket promotion after classification. ARCHITECT REVIEW: Will reads PASS_2_WILL_REVIEW_PACKET.md; bulk-ratifies Bucket A (incl. absorbed); per-row reviews Bucket B; decides Bucket C; reviews SECTION_15A_REWRITE_PREVIEW.md; ratifies → publish V4. If §15A is materially revised/rejected, trigger contingency Pass 2.5. ``` --- *End of proposal R3.1. Commission Pass 0 today.*