ELNOR REPO READER TEXT MIRROR Original path: Active Working and Red Team/Memory Rebuild Working/Stage_5R3_Review_Prompt_R2.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Review Prompt R2 — Stage 5R3 Audit + Forward Discipline Automation Proposal ## Context for the reviewer ELNOR is a local-first AI memory architecture for high-stakes knowledge work, with a spec corpus of ~141 docs maintained over months of iteration. A central operations file — **OP-A (Cross-Doc Obligation Tracker)** — captures cross-doc obligations between specs: when DOC X says "DOC Y must do Z," that obligation lands as a row in OP-A targeting DOC Y. OP-A is at V3.18 with **528 active obligation rows across 25 target-doc sections**, maintained via per-version patch sessions that run after spec revisions. A major architectural change is in progress: the **memory rebuild flatten**, which reorganizes memory governance, knowledge storage, evidence, extraction, delivery, learning, and inspector/search surfaces into an 8-member family (DOC80–DOC87). The flatten is currently at Stage 5R (Skeletal Target Baseline) on its way to Stage 6 (slice charters) and Stage 7 (schemas). Five nightly Cowork SKILLs already run on the repo: elnor-nightly-spec-sync (mechanical drift), elnor-new-chat-context-sync, elnor-openclaw-release-tracker, elnor-recent-work-summary, elnor-onedrive-backup. They handle file-level mechanical tracking but no semantic obligation tracking. ## Reasoning for the proposal Two interlocking problems: **Problem 1 — Memory plane absent from OP-A.** OP-A V3.18 has zero references to DOC80–DOC87. All 528 existing rows target pre-flatten owners (DOC1, DOC8, DOC72, DOC25, DOC15, EC Core, etc.). When Stage 6 charters draft against OP-A, they'll see stale ownership for the entire memory plane. Existing rows need retargeting; the new family needs §6 sections; some obligations may need splitting or absorption. This is a one-time-pass problem. **Problem 2 — Discipline-as-written is brittle.** The §15A "non-negotiable" session-close OP-A update is hand-applied and the architect explicitly acknowledges it sometimes gets skipped. The result: cross-doc obligations accumulate quietly and then require massive end-of-cycle reconciliation passes. This isn't a discipline-failure to be solved by trying harder — it's a missing automation backstop. This is a standing-system problem. The proposal addresses both. It pairs a one-time audit (R1 scope) with four forward-discipline pieces (R2 scope expansion): a nightly OP-A drift detector, a Monday early-AM weekly maintenance pass, a freeze mechanic for periods when OP-A intentionally pauses (like the active flatten), and a short Spec Development Discipline R1 companion doc drafted after the audit. All forward-discipline automation is **surface-only** — it never modifies OP-A or specs, only generates reports the architect reviews. That preserves the "architect as the durable writer" invariant for OP-A. ## Goals the proposal must serve **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. Without this, the memory plane gets designed against stale ownership data and Stage 6 either ignores rows (lost information) or drafts against the wrong target (compound error downstream). **Goal B — Long-term maintainability.** Future spec revisions are easier to do, not harder. Cross-doc obligations get addressed in small weekly batches rather than as end-of-cycle reconciliations. The §15A discipline has automated backstops that catch missed updates within 24 hours. Trackers (OP-A, SPEC_STATE, ADDENDA_STATE) stay in sync without requiring perfect discipline from a single human operator. The audit (§4 of the proposal) serves Goal A directly. The forward-discipline pieces (§6) serve Goal B directly. ## What to assess **1. Do we need this at all, in the proposed shape?** - Is the load-bearing gap (zero DOC80–87 references in OP-A) real and significant enough to require Stage 5R3 before Stage 6? - Are the forward-discipline pieces appropriately scoped, or is this over-engineering for a single-architect spec corpus? - Are there cheaper alternatives — wait until Stage 7 schemas land; do retargeting incrementally as Stage 6 charters are drafted; build no automation and rely on discipline + periodic deep audits? **2. Does the proposal accomplish the goals?** - Does the two-pass audit (Codex coverage, Claude Code retargeting) actually surface what it needs to and produce durable decisions? - Does the scope-rule refinement in §5(b) hold up — especially for the DOC10 case (unrevised consumer with stable architectural concerns)? - Do Pieces 1 (nightly drift detector), 2 (Monday weekly pass), 3 (freeze mechanic), and 4 (Spec Development Discipline R1 companion doc) together provide a reliable backstop for the §15A discipline failure mode? - Is the "one comprehensive retargeting now + light verification at Stage 7" handling of the flatten's incompleteness sound? **3. Is there a better way to do this?** - One-pass audit that does coverage and retargeting together - Defer the audit until Stage 7 so retargeting happens against actual schemas - Build a separate "Memory-Plane Obligation Index" rather than folding into OP-A V4 - A fully different obligation-tracking model — each spec declares its own obligations in a structured format that OP-A derives from on rebuild - Stricter scope rule that excludes unrevised consumers entirely (different tradeoff) - Different work split between Codex and Claude Code - Combining the nightly drift detector into the existing `elnor-nightly-spec-sync` SKILL rather than creating a sixth SKILL - Letting Pieces 1/2 make some low-risk OP-A edits autonomously (e.g., move clearly-absorbed rows to §7 with confirmation flag), rather than being strictly surface-only **4. Coverage gaps in the proposal itself.** - Are there obligation sources or scope cases the proposal misses? E.g., the DOC23 family coordination ledger; the various ADQs (Architect Decision Queue items); unmigrated GIE V2.2 Appendix A/C obligations; in-flight addenda not yet absorbed; obligations that may have entered §6 but no longer match the spec they were drawn from. - Are there failure modes for the forward-discipline pieces the proposal doesn't anticipate? E.g., the freeze mechanic being abused as a way to indefinitely defer work; the weekly pass becoming background noise the architect stops reading; the drift detector firing false positives during periods of heavy spec churn. **5. Design questions for the forward-discipline pieces.** - Should Piece 1 (drift detector) include a "this spec changed AND has a §22-style section AND OP-A doesn't have a row for at least one obligation in that section" check, or is "last-commit-after-OPA-last-commit" sufficient as a first cut? - Should Piece 2 (Monday weekly pass) include a sentiment check that asks "is the actionable queue growing or shrinking over time" so the architect can see whether discipline is keeping pace? - Is the freeze mechanic (Piece 3) too lenient — should ALL items during freeze go to deferred queue, including out-of-scope, to keep the queue clean? Or is the in-scope/out-of-scope distinction correct? - Should Piece 4 (Spec Development Discipline R1) be authored before the audit instead of after, so the audit can use its checklists? **6. Sequencing.** - Stage 5R2 must-fix patches and Stage 5R3 audit run in parallel — is that the right sequencing, or should they be serialized? - Pieces 1/2/3 run in parallel with the audit — is that safe, or should they wait? - Piece 4 (companion doc) runs after audit — is that the right order, or should it lead? **7. General suggestions.** - Framing, version-bump convention (V4 vs. V3.19), deliverable shape, work split between Codex / Claude Code / Cowork, anything else worth surfacing before commission. ## Practical notes - The proposal is at `Stage_5R3_Audit_Proposal_R2.md` and supersedes R1. - Current OP-A is V3.18 (2026-05-21), 528 rows, file `OPA_V3_18.md`. - The architect is currently in active flatten work and will not update OP-A for an estimated 1–2 weeks; the freeze mechanic (Piece 3) is designed to handle this. - The DOC80–DOC87 family is at Stage 5R skeletal baseline; Stage 5R2 stabilization patches are queued as a separate, parallel workstream. - The Cowork SKILL prompts in Appendix A are starter sketches; reviewers can suggest refinements but final SKILL configuration is the architect's call. - Architect prefers direct assessment without hedging, BUG/GAP/SUGGESTION/CONFIRMED typing on findings, section-number citations where applicable. A substantive review (~2000–4000 words) is preferred over a quick sanity check. Be explicit about which assessments can be made with confidence from the proposal alone and which would require reading additional source material (OP-A V3.18, DOC80 baseline artifacts, specific consumer docs, existing Cowork SKILLs). The proposal will be reviewed across multiple LLM windows and synthesized. Reviewers should be especially explicit about disagreements with the proposal's framing — for instance, if a reviewer thinks the forward-discipline automation is over-engineered, that's a substantive disagreement worth stating clearly rather than couching as a minor concern.