Elnor Repo Reader

# Stage 5R3 Proposal R2 — Cross-Doc Obligation Audit + Forward Discipline Automation

**Status:** Proposal for architect and reviewer assessment. Not authorized for execution.
**Date:** 2026-05-27
**Author:** Claude (R2 incorporates architect feedback on forward discipline and automation backstops)
**Supersedes:** Stage 5R3 Audit Proposal R1 (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 (elnor-nightly-spec-sync, elnor-new-chat-context-sync, elnor-openclaw-release-tracker, elnor-recent-work-summary, elnor-onedrive-backup).

---

## What changed in R2

R1 was scoped narrowly to a one-time audit producing OP-A V4. R2 retains that audit and adds three forward-discipline deliverables informed by architect feedback:

1. Recognition that the §15A "non-negotiable" session-close discipline is in practice hand-applied and will sometimes be skipped — by acknowledgment from the architect. The fix is automation backstops, not louder rules.
2. Explicit automation pieces: a nightly OP-A drift detector and a Monday early-AM weekly maintenance pass, both implemented as Cowork SKILLs that surface work to the architect without modifying trackers directly.
3. A freeze mechanic for periods (like the current flatten) when OP-A intentionally pauses updates, so the drift detector doesn't generate noise. Deferred items queue separately and aren't lost.
4. A short Spec Development Discipline R1 companion doc, drafted from the audit's empirical findings, that codifies pre-flight, session-close, retargeting, and audit-cadence rules.

The audit (R1's §§1–5) is unchanged and remains the foundation.

---

## 1. Calibrating the actual state of OP-A

OP-A V3.18 is in materially better condition than my earlier framing implied. Honest baseline before proposing the audit:

- **528 active obligation rows** across 25 target-doc sections in §6 (DOC1 / DOC2 / DOC3 / DOC4 / DOC6 / DOC7 / DOC8 / DOC10 / DOC11 / DOC12 / DOC13 / DOC14 / DOC15 / DOC16 / DOC18 / DOC20 / DOC21–22 / DOC23 / DOC24 / DOC25 / DOC72 / DOC73 / EC Core / BDSM / KDA / PropA).
- **Maintenance discipline is running.** Eight versioned patch sessions in five weeks (V3.10 → V3.18), each with documented trigger, source, and additions summary. V3.18 was itself a deep-audit corrections pass that caught structural misplacements of V3.14/V3.16 rows and added two missed KDA rows.
- **§3 Source Document Registry is well-designed.** It distinguishes "folded-in" sources from "NOT yet folded — planned for OP-A V4" with explicit dispositions, and carries a scope rule that handles spec-internal §22 content (migrates on revision), outdated guides, unverified docs, and "documents being superseded by major revisions in progress" (cited example: DOC10).
- **§9 Open Meta-Architecture Questions is the soft-state buffer** for items that aren't obligation-grade but should not be lost. V3.16 promoted one of these (Core R0.8 InjectionSlotRegistry mechanics) into an obligation row when it ripened — showing the soft→hard promotion path is working.
- **§15A session-close discipline is documented but unevenly applied.** The architect explicitly acknowledges this. Discipline-as-written is brittle when applied across months of work; the cross-doc obligation backlog grew large precisely because session-close updates were sometimes missed, requiring a major reconciliation pass each time.

What this does NOT mean: that OP-A is complete or that the memory rebuild is properly accounted for. The actual gaps are specific.

## 2. The actual gaps

Seven gaps, calibrated to OP-A V3.18 as inspected directly:

### Gap 1 (load-bearing): The new memory plane is absent

OP-A V3.18 has **zero references to DOC80–DOC87**. The 528 rows all target pre-flatten owners. The flatten reallocates ownership of memory-architecture concerns 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), but OP-A has not yet been updated to:

- Add §6 sections for each new member.
- Retarget existing rows that point at DOC1 memory governance, DOC8 self-learning, DOC72 memory storage, DOC25 ingestion, DOC15 CIL context-injection, etc., where the flatten has moved ownership.
- Identify rows that split across multiple new members (e.g., a DOC1 row that's now half DOC81 policy and half DOC82 lifecycle).
- Identify rows that no longer make sense in the new architecture.

**This is the load-bearing gap.** Stage 6 charters will consume OP-A to draft DOC80–DOC87 schemas. If OP-A still says "DOC1 emits memory-directive schema" and "DOC8 owns runtime learning," charters either ignore those rows (lose information) or draft against stale ownership (compound error).

### Gap 2: Three sources explicitly pending in §3

§3 NOT-yet-folded list explicitly marks these as "Session 2 — planned for OP-A V4":
- DOC3 Companion Doc Delta Plan R9.2 Canonical
- DOC14 Cross-Document Delta Companion R2
- CD-A 4.1.26 DOC3/DOC24 Cycle staging doc

These are intentional deferrals on the existing fold-in roadmap, not oversights.

### Gap 3: Spec-internal §22-style sections not yet migrated

The scope rule says spec-internal cross-doc content (DOC24 §22, DOC3 §22, etc.) migrates to OP-A when the owning spec next revises. In practice:

- Recently-active specs HAVE migrated (DOC24 R3.1.1, DOC23 Addenda B family, KDA R3, BDSM V6.5, etc.).
- Less-active specs MAY NOT have migrated. DOC3 R11.3 Addenda A R2.2 §§13–16 (DOC72 graph writes, DOC24 delivery, DOC1 governance, DOC8 self-learning) — uncertain coverage. DOC72 R5.73 Appendix A — uncertain.

The audit needs to inventory which active specs have §22-style sections and verify each is reflected in §6.

### Gap 4: Scope rule blind spot for unrevised consumers

The scope rule excludes "documents being superseded by major revisions in progress" but if no revision is actively scheduled, "wait for post-revision tracker" becomes indefinite. DOC10 R10 has real obligations on the memory plane that don't go away because DOC10 isn't being revised right now.

### Gap 5: In-flight proposals not yet registered

DOC20 Q Browser Intake Architecture has explicit memory-plane obligations and isn't in §3 (folded or pending). Likely other in-flight proposals are in the same state.

### Gap 6: Soft-state items in §9 ripening

§9 currently has open items including DOC15-derived row triage, DOC1 R1 status check, RRB-derived row triage, DOC74 reference verification, CD Master Integration Index inherited list. Should be resolved as part of the audit.

### Gap 7: No structural defense against §22-migrate-on-revision being silently skipped

A spec could revise without its §22 obligations being pulled into OP-A and nothing would flag it. The V3.18 deep audit caught structural misplacement but not missing rows. The §15A discipline assumes session-close updates happen; in practice they sometimes don't.

## 3. Goals (calibrated to both architect-named goals)

**Goal A — Memory rebuild completeness.** Every obligation in the current spec corpus that the new memory plane should accommodate is reflected 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.** When the architect revises specs later, the cross-doc obligation discipline supports the revision rather than requiring archaeological reconstruction. Cross-doc obligations are addressed in small weekly batches rather than as massive end-of-cycle reconciliations.

The audit (§4) serves Goal A directly. The forward-discipline automation (§6) serves Goal B directly. Both are needed.

## 4. The audit: two passes

(Unchanged from R1.)

### Pass 1 — Coverage audit (Codex)

Walk Master Spec List R3.62 (~141 entries). For each spec with memory-plane references, locate its §22 / Appendix / OBL-XDOC section, confirm it's listed in OP-A §3 (folded or pending) with correct disposition, spot-check that §6 rows reflect §22 content, resolve §9 carry-forwards. Deliverable: revised §3 registry and §22-inventory. **No row additions yet.**

### Pass 2 — Retargeting audit (Claude Code)

Tag every existing §6 row `pre_flatten` / `flatten_aware` / `not_memory`. For each `pre_flatten` row, produce retarget / split / absorbed / unhandled disposition against DOC80–DOC87 ownership. Add §6 sections for DOC80–DOC87. Produce architect-decision list. Walk §9 triage items. Deliverable: OP-A V4 candidate; architect-decision list; resolved §9 items.

### Why two passes, two tools

Codex is strong at corpus walking with file-line citations and cross-artifact verification. Claude Code is strong at structured patch application and OP-A row authoring. Architect reviews between passes.

## 5. Staleness handling

(Unchanged from R1.)

**(a) Stable vs. version-dependent obligations.** Retargeting captures stable architectural concerns, not version-dependent specifics. When consumer specs eventually revise, they express newly-needed obligations against the now-stable memory plane via the same V3.X discipline (backed by automation per §6).

**(b) Scope rule refinement.** Replace "wait for post-revision tracker" with a tighter rule that folds stable architectural concerns from unrevised consumers immediately, only deferring specs being actively revised or with imminent confirmed revisions.

**(c) Flatten itself is a major revision.** One comprehensive retargeting at Stage 5R3 (now, against skeletal baseline + Owner Map ownership), then light verification at Stage 7 completion (does the schema actually carry the field the OP-A row claims?).

## 6. Forward discipline (Goal B)

R1 mentioned this section briefly. R2 expands it to four named deliverables. **All four are designed to surface work to the architect without modifying trackers directly** — automation as backstop, not as authority.

### Piece 1 — Nightly OP-A drift detector (Cowork SKILL)

Add a sixth Cowork SKILL alongside the existing five (or extend `elnor-nightly-spec-sync`). Each night, it compares spec-file commits against OP-A commits via GitHub history. For each spec where last-commit is more recent than OP-A's last-commit, it identifies the likely §6 target section and notes whether the spec has a §22-style obligation section. Output: a `PENDING_OPA_UPDATES.md` file in the OP-A operations folder (overwritten nightly), rendered into a new "Pending OP-A Updates" panel on the dashboard.

**The detector never modifies OP-A or specs.** It only surfaces candidates.

Closes Gap 7 by making missed §15A session-close updates visible within 24 hours.

Sketched prompt in Appendix A.

### Piece 2 — Monday early-AM weekly maintenance pass (Cowork SKILL)

Add a weekly Cowork SKILL scheduled for Monday early morning (before normal work). It produces a one-page maintenance report covering:

- Drift items from `PENDING_OPA_UPDATES.md` carried forward from the prior week plus this week's new items, deduped.
- §9 Open Meta-Architecture Questions items that may have ripened.
- §3 NOT-yet-folded sources whose target specs have now stabilized (no commits in 7 days).
- SPEC_STATE.md and ADDENDA_STATE.md rows that look stale relative to their referenced files' commits.
- Top 5 recommended maintenance actions for the week.

Output: `MAINTENANCE_REPORT.md` (overwritten each Monday), rendered into a "This Week's Maintenance" dashboard panel. Optional one-paragraph email digest.

**The weekly pass never modifies OP-A, SPEC_STATE, ADDENDA_STATE, or any spec.** It surfaces work and ranks priorities.

Closes Gap 6 by giving §9 items a regular ripening cadence. Closes Gap 2 by surfacing pending-fold candidates as their target specs stabilize. Supports Goal B by addressing cross-doc obligations in small weekly batches.

Sketched prompt in Appendix A.

### Piece 3 — Freeze mechanic

During periods when OP-A is intentionally paused — the current flatten is the canonical example; the architect expects 1–2 week pauses while major work is in flight — the drift detector would otherwise generate noise that isn't actionable.

Solution: a freeze flag file at `OP-A and Operations and Trackers/OPA_FREEZE.md`. Contents describe the active freeze, its expected end, and which folders/specs are in-scope. The drift detector reads this file:

- **In-scope items** queue to a separate `PENDING_OPA_UPDATES_DEFERRED.md` (still visible, still trackable, but explicitly marked as deferred-per-freeze).
- **Out-of-scope items** queue to the normal `PENDING_OPA_UPDATES.md` as actionable.

The weekly pass surfaces both queues but in separate dashboard panels. When the freeze ends, the deferred queue becomes the input to the next OP-A update session.

For the current freeze, the OPA_FREEZE.md content should list the entire `Memory Rebuild Docs/` folder, the `Current Specs/DOC80 Memory Control Plane/` folder, and any other spec edits whose primary purpose is memory-plane retargeting.

### Piece 4 — Spec Development Discipline R1 (companion doc)

After the audit completes, draft a short companion doc (5–10 pages) that codifies:

- Pre-flight checklist for spec revisions (what to load before starting; which OP-A rows target this spec; which §22 obligations might be affected).
- Session-close checklist (extends §15A with the retargeting protocol learned from Stage 5R3).
- Standardized cross-doc obligation section format (allows the existing variety — DOC72 Appendix A, DOC23 OBL-XDOC tables, DOC24 §22 amendment matrix — but defines the minimum fields each must include to be lint-checkable).
- Supersession / retargeting protocol when ownership moves between specs.
- Deep audit cadence (e.g., every 5 OP-A versions or every quarter, whichever comes first).
- Version-bump conventions (V3.X for incremental patches, V→V+1 for substantive retargeting passes).
- Explicit references to Pieces 1–3 as the automation safety net.

This is drafted FROM the audit, not BEFORE it, because the audit's findings provide empirical evidence of what discipline-level changes would have prevented each gap.

## 7. Sequencing

| Item | Status | Work |
|---|---|---|
| Stage 5R2 must-fix patches | Authorized; instructions exist | Twelve must-fix items + fold-ins from consolidated synthesis. Runs in parallel with everything below. |
| **Piece 3 (Freeze mechanic)** | **Proposed; needed immediately** | **Create `OPA_FREEZE.md` for the current flatten freeze before Pieces 1–2 set up.** No code, just a manifest file. |
| **Piece 1 (Nightly drift detector)** | **Proposed; can run in parallel with audit** | **Set up sixth Cowork SKILL. Runs nightly starting whenever Will configures it.** |
| **Piece 2 (Monday maintenance pass)** | **Proposed; can run in parallel with audit** | **Set up weekly Cowork SKILL. Runs Monday early AM starting whenever Will configures it.** |
| **Stage 5R3 Pass 1 (Coverage audit)** | **Proposed** | **Codex walks corpus, produces §3 inventory + §22-section status, resolves §9 carry-forwards.** Architect reviews. |
| **Stage 5R3 Pass 2 (Retargeting audit)** | **Proposed** | **Claude Code applies retargeting decisions, adds DOC80–DOC87 sections, surfaces architect decisions.** Architect ratifies. OP-A bumps to V4. |
| **Piece 4 (Spec Development Discipline R1)** | **Proposed; drafted from audit findings** | **Short companion doc codifying pre-flight, session-close, retargeting, audit-cadence rules.** Drafted after Stage 5R3 completes. |
| Stage 6 (Charter authoring) | Pending | Slice charters for DOC80–DOC87 consume the V4 OP-A. |
| Stage 7 (Schema authoring) | Pending | Schema drafting per slice. Light verification against OP-A V4. |

**Critical sequencing note:** Piece 3 (freeze mechanic) should happen first because the architect is in active flatten work right now and won't update OP-A for 1–2 weeks. Without the freeze flag, Pieces 1 and 2 would generate noise. Setting up the freeze flag is a 30-minute task (write the manifest file).

Pieces 1 and 2 can be set up in parallel with the Stage 5R3 audit — they're independent infrastructure.

Piece 4 is drafted FROM the audit's findings and so runs after.

## 8. Deliverables

From Stage 5R3 itself:

- **OP-A V4** — comprehensive, with DOC80–DOC87 §6 sections; retargeted pre-flatten rows; new rows from Pass 1 spec-internal sources; resolved §9 carry-forwards; expanded §3 registry; revised scope rule per §5(b).
- **Architect decision list** — unhandled rows from Pass 2; rule-refinement ratification.
- **Stage 6 charter input package** — per-slice cross-reference index pointing each charter at its OP-A rows and source-doc sections.

From the forward-discipline pieces:

- **`OPA_FREEZE.md`** — manifest file for the active freeze (Piece 3).
- **`elnor-opa-drift-detector` Cowork SKILL** — nightly drift surfacing (Piece 1; sketched in Appendix A).
- **`elnor-weekly-maintenance-pass` Cowork SKILL** — Monday early-AM maintenance report (Piece 2; sketched in Appendix A).
- **Dashboard panels** — "Pending OP-A Updates," "Deferred Per Freeze," "This Week's Maintenance."
- **`Spec_Development_Discipline_R1.md`** — companion doc (Piece 4; drafted after audit completes).

What is explicitly NOT a Stage 5R3 deliverable:

- Rewriting any consumer or intake-source spec (DOC3, DOC10, DOC20, DOC23 family). Those revise on their own cycles, supported by the forward-discipline pieces.
- Creating new schemas or family members.
- Re-running Stage 5R2 patches under a different framing.

## 9. Open questions for review

Seven questions a reviewer should engage with:

1. **Is the two-pass split (Codex coverage / Claude Code retargeting) the right work division?** Or cleaner to have one tool do both?
2. **Is the scope-rule refinement in §5(b) too aggressive or too conservative?**
3. **Should Stage 7 verification be elevated to a Stage 7.5 audit (more rigor), or is light verification the right shape?**
4. **For Gap 6 (§9 carry-forwards), should the audit resolve them inline or surface them as architect decisions?**
5. **Is "OP-A V4" the right naming?** (V3.X has been incremental patches; V4 implies substantive change.)
6. **Are the Piece 1 / Piece 2 SKILL designs surface-only the right call?** Alternative: let the SKILLs make some low-risk OP-A edits autonomously (e.g., move clearly-absorbed rows to §7 with a confirmation flag). Pro: less architect work; con: erodes the "single durable writer" invariant for OP-A.
7. **Is the freeze mechanic too lenient?** Alternative: during freeze, drift detector still runs but ALL items go to deferred queue regardless of in-scope/out-of-scope. Pro: simpler; con: loses visibility on out-of-scope drift that should still be actionable.

A reviewer should also stress-test whether the cumulative discipline (manual §15A + nightly drift detector + Monday weekly pass + periodic deep audits + the freeze mechanic + the companion doc) is the right amount of process, or whether it's over-engineered for a single-architect spec corpus.

---

## Appendix A — Sketched Cowork SKILL prompts

These are starter prompts. They would be refined against the actual repo state and Cowork's SKILL conventions when set up. Both designed to surface work to the architect, never to modify trackers.

### A.1 `elnor-opa-drift-detector` (nightly)

```
ROLE: Surface specs that have changed since OP-A was last updated, so Will
can decide whether each needs a §15A pass. Never modify OP-A or specs.

INPUTS:
- /Users/OpenClaw1/Elnor/Elnor Specs/ (GitHub repo wbrody/Elnor-Specs)
- 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/DRIFT_LOG.md (appendable log)

EACH NIGHT:
1. Read OPA_FREEZE.md. Extract the in-scope freeze paths/folders if present.
2. Find OP-A's last-modified commit (OPA_LAST).
3. For each .md file under Current Specs/, Active Working and Red Team/,
   and Memory Rebuild Docs/, find its last-modified commit.
4. If a spec file's last commit is AFTER OPA_LAST, it is a DRIFT CANDIDATE.
5. For each candidate:
   a. Infer most-likely OP-A target section (§6.X) by spec filename/folder.
   b. Note whether the spec contains a section matching /§22|Appendix|
      OBL-XDOC|cross-doc obligation|XDI|amendment matrix/ (case-insensitive).
   c. If the candidate matches an in-scope path from OPA_FREEZE.md, mark
      DEFERRED. Otherwise mark ACTIONABLE.
6. Write:
   a. ACTIONABLE items to PENDING_OPA_UPDATES.md (overwrite). Columns: spec,
      last_commit, OPA_last_commit, has_obligation_section, likely_target,
      recommended_action.
   b. DEFERRED items to PENDING_OPA_UPDATES_DEFERRED.md (overwrite). Same
      columns plus freeze_reason and freeze_end_estimate.
7. Append a single summary line to DRIFT_LOG.md: timestamp, count actionable,
   count deferred, top 3 actionable items.

NEVER modify OPA_V3_18.md or any spec file. Only the three output files
listed above.

OUTPUT: Two .md files plus DRIFT_LOG.md append. Dashboard refresh task
renders PENDING_OPA_UPDATES.md and PENDING_OPA_UPDATES_DEFERRED.md into
separate panels.
```

### A.2 `elnor-weekly-maintenance-pass` (Monday early AM)

```
ROLE: Produce a weekly maintenance report so Will can address cross-doc
obligation drift in small batches each Monday morning. Never modify OP-A,
SPEC_STATE, ADDENDA_STATE, or any spec.

SCHEDULE: Monday early AM, before Will starts work (e.g., 5:00 AM local).

INPUTS:
- /Users/OpenClaw1/Elnor/Elnor Specs/ (GitHub repo)
- OP-A and Operations and Trackers/OPA_V3_18.md
- 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/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, for
  carry-forward)
- OP-A and Operations and Trackers/OPA_FREEZE.md (freeze flag if present)

EACH MONDAY:
1. CARRY-FORWARD: Read prior MAINTENANCE_REPORT.md. Pull any open items
   that weren't addressed (compare against current PENDING_OPA_UPDATES.md
   and recent OP-A commits).
2. THIS WEEK'S ACTIONABLE DRIFT: Read PENDING_OPA_UPDATES.md. Dedupe
   against carried-forward items.
3. THIS WEEK'S DEFERRED DRIFT: Read PENDING_OPA_UPDATES_DEFERRED.md.
   Report count and top items so Will sees the deferred backlog growing.
4. §9 RIPENING ITEMS: Walk OP-A §9 Open Meta-Architecture Questions. For
   each, check if referenced spec/version has shipped, ownership clarified,
   or related decision recorded since the entry was made. Flag ripened
   items with a one-line reason.
5. §3 PENDING FOLD-INS: Walk OP-A §3 "NOT yet folded in" table. For each
   row, check if the referenced 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. TOP 5 ACTIONS: Rank the 5 highest-leverage maintenance tasks for the
   week based on the above. Consider: load-bearing items first, items
   that block other work second, items at risk of becoming archaeological
   later third.
8. Optionally produce a one-paragraph email-style digest at the top of
   the report.

OUTPUT: Write MAINTENANCE_REPORT.md (overwrite). Sections:
  - This Week's Top 5 Actions
  - Carried Forward from Prior Weeks
  - This Week's New Actionable Drift
  - Deferred Per Freeze (count and 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.

NEVER modify OP-A, SPEC_STATE, ADDENDA_STATE, 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
**Reason:** Memory rebuild flatten in progress (Stage 5R → 5R3 → Stage 6).
  OP-A will not be updated for memory-plane retargeting until Stage 5R3
  audit completes and OP-A V4 ships.
**Expected end:** When Stage 5R3 audit completes and OP-A V4 is ratified.
  Estimated 1–2 weeks from 2026-05-27 but unbounded.

## In-scope (drift items DEFERRED, not actionable)

- `Memory Rebuild Docs/` (entire folder)
- `Current Specs/DOC80 Memory Control Plane/` (entire folder)
- Any spec edits whose primary purpose is memory-plane retargeting
- DOC72 / DOC73 / DOC1 / DOC8 / DOC25 / DOC15 edits made in service of
  the memory plane (operator judgment)

## Out-of-scope (drift items ACTIONABLE as normal)

- All other spec edits in `Current Specs/`
- DOC11 / DOC20 / DOC23 / DOC24 / DOC10 / DOC12 / DOC14 / DOC16 / DOC17 /
  DOC18 / DOC21 / DOC22 etc. unless explicitly noted above
- EC Core edits unless explicitly memory-plane retargeting

## Resolution

When Stage 5R3 audit completes:
1. Move DEFERRED queue items into the audit's input.
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.
```

---

*End of proposal R2. Hand to reviewers; revise based on assessment; commission audit + automation when settled.*