DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-158-memory-registry-completeness-v0_2.md

CR-2026-158 — Memory Registry Completeness: unregistered event types and replay integrity — v0.2

Version. 0.2 Date. 2026-07-29 Status. Change request. Ready for CC execution. Supersedes v0.1, which stands as a sibling. What changed from v0.1. The early Step 0 sweep (run 2026-07-29 against engine 1aac815) landed before execution and corrected the CR's grounding in three ways, recorded not smoothed: (1) the class is eight unregistered event types, not one — including the doors-1/2 creation events, so every creation door and every upload poisons replay, not door 3 alone; (2) the live affected class is six engagements, not two, including three of the four protected ones; (3) E0005 exhibits a second failure mode v0.1's fixture would not catch — healthy for 283 versions, poisoned mid-life by an upload, 19 manifestations already on disk, the newest permanently stale with no surface saying so. §3c now carries two fixture shapes. CR-2026-157's merge status is resolved: NOT EXECUTED against 1aac815; its event types are out of sweep scope. CR number. CR-2026-158 (verified free at filing across all three CR locations). Baseline. Engine main = origin/main = 1aac815, in sync, verified 2026-07-29. Step 0 reconciles at execution time. Grounding. loomworks-walk-audit-report-v0_1 (W-1, the Stage-2 500 and its control-test isolation); the 2026-07-28 perimeter probe (masking by W-9; the never-registered drift dispatch; replay-backed routes at rule_sets.py:154, assertion_groups.py:168, cadences.py:153); the 2026-07-29 early sweep (this version's §2a). Why now. Unchanged, strengthened: no user can trigger the failure today only because the Manifestation room is a placeholder. The completion arc removes the mask; six live engagements — E0005, E0060, E0006, E0030, E0121, E0089 — are standing on it.


1. Executive summary

The engine's Memory replay fails on any engagement whose history contains an event type written by the codebase but never registered in memory/registry.py. The sweep establishes the class: eight typesdiscovery_to_seed_extracted, engagement_created_from_assistance, grant_request_received, jurisdiction_routing_decided, manual_content_contributed, reconciliation_proposal, seed_committed_from_brief, upload_event_received — written by the door-3 extract path, the doors-1/2 creation paths, the upload pipeline, and four other writers; registrations stop at Phase 37 and every event family added since is unregistered. upload_event_received makes this the common case (80 events across 4 engagements): any engagement that has ever received an upload is in the affected class.

Six live engagements are affected. Five have never derived a Manifestation and cannot. The sixth, E0005, is the sharper case: it derived nineteen manifestations across 283 healthy versions, was poisoned mid-life by an upload, and can never derive again — its newest manifestation is permanently 25 versions stale, and no surface reports the staleness.

This CR fixes the class: register all eight types with writer-derived replay semantics; land a structural guard making an unregistered write impossible to reintroduce; prove replay healed against two fixture shapes — poisoned-from-creation (the E0060 shape) and poisoned-mid-life-with-manifestations-on-disk (the E0005 shape); live-verify on the standing walk-audit engagement. A rider removes or repairs the unsatisfiable create-from-conversation route (W-2). Engine-only; no live-engine deployment inside the CR.

2. Step 0 — Pre-flight

2a. Consumed early findings (recorded 2026-07-29; re-verify at execution HEAD, do not re-derive)

2b. Remaining pre-flight items

  1. Reconcile baseline (if HEAD ≠ 1aac815, re-run the sweep at HEAD and report any delta); full suite count; confirm 158 still unclaimed by any parallel work.
  2. The registry's contract end to end; the exact unknown-type failure site replay raises from.
  3. Each of the eight types' semantics from its writer. For each: what the payload carries; what, if anything, replayed state must do with it. Likely most are state-neutral records; engagement_created_from_assistance and seed_committed_from_brief sit at creation and deserve particular care — if either should have mutated replayed state and didn't, halt and surface rather than registering a guess. Report per-type verdicts before writing any registration.
  4. The rider's question, unchanged from v0.1: create-from-conversation abandoned (remove, history in commit message) versus intended (halt and surface). The doors-1/2 deployed path committing via /operator/converse intents is now established fact from the perimeter probe — weigh it.

3. The changes

3a — Registrations. All eight types, semantics per §2b item 3. State-neutral registrations carry an explicit no-op handler with a comment citing the writer and stating the neutrality is deliberate.

3b — The structural guard. Unchanged from v0.1: a mechanically honest test asserting every written event type is registered; red against the unfixed registry first; halt if mechanical honesty is unachievable.

3c — Replay-heal verification, two fixture shapes.

3d — Rider, conditional per §2b item 4.

Named and passed on, not absorbed: E0005's staleness invisibility — a newest manifestation 25 versions behind with no surface signal — is W-14 meeting W-1 and belongs to the completion arc's Manifestation surface, which should carry a staleness indicator from its first version. This CR restores the ability to derive; it does not add the surface that says derivation is overdue.

4. Tests

As v0.1, extended: the guard; both heal fixtures across all four replay-backed paths; eight per-type registration tests; the walk-shape regression; Shape B's manifestation-untouched assertion; rider tests per its outcome. Estimated ~16–20 new tests. Suite green throughout; the Stele router-mount waiver status confirmed at Step 0, not assumed.

5. Steps and checkpoints

Step 0 — §2b; branch cr-2026-158-registry-completeness; archive this CR (v0.2) to docs/phase-crs/ alongside v0.1. Step 1 — guard, red. Step 2 — registrations; guard green. Step 3 — both heal fixtures and regressions. Step 4 — rider. Checkpoint A — dev-stack live verification per the walk-audit environment pattern (spare port, playground_walkaudit, inline env only, live processes and playground_dev untouched): derive on WALK-AUDIT-2026-07-28 — which now carries both creation-poisoning and upload events, exercising both shapes live — plus one of the other replay paths; tear down; halt for Operator acceptance. Checkpoint B — merge --no-ff, tag registry-completeness-v0_1, implementation notes, halt before push. Post-CR, Operator-owned: live deployment is a launchd restart after merge — until it happens, all six live engagements remain unfixed on the serving perimeter with the fix one restart away; E0005 and the others then heal by replay the first time anything derives them.

6. Acceptance gate

  1. Sweep re-verified at execution HEAD; all eight (plus any HEAD delta) registered with per-type writer-derived verdicts reported.
  2. The guard: red against the unfixed registry, green after, and structurally binding on future writes.
  3. Both fixture shapes green across all four replay-backed paths; Shape B's pre-existing manifestations byte-untouched.
  4. WALK-AUDIT-2026-07-28 derives live at Checkpoint A.
  5. Rider resolved per its condition.
  6. playground_dev and live processes untouched throughout; no schema change unless surfaced; the staleness-surface item explicitly handed to the completion arc in the implementation notes.

7. What this CR does not do

Unchanged from v0.1, plus: it does not surface manifestation staleness (completion arc); it does not backfill or force-derive any live engagement (healing is replay-on-next-derive after the Operator's deployment step); it does not absorb the June→July manifest gap, though the sweep's eight types are themselves evidence for that absorption pass — five of the eight writers postdate the last absorbed entry, and the pass should cite this CR's Step 0.

8. Kickoff prompt for the CC session


Read /Users/dunin7/Downloads/cr-2026-158-memory-registry-completeness-v0_2.md and execute it. v0.2 supersedes v0.1 (already filed); archive both at Step 0.

Baseline engine main 1aac815 (reconcile; if HEAD moved, re-run the sweep at HEAD and report the delta). §2a findings are consumed facts — re-verify, don't re-derive. Branch cr-2026-158-registry-completeness. Steps 0-4 auto-proceed, per-step commits, suite green at each. Checkpoint A per the walk-audit environment pattern; derive on WALK-AUDIT-2026-07-28; tear down after. Checkpoint B: merge, tag, halt before push.

Halt-and-surface conditions: any of the eight types with ambiguous replay semantics (especially the two creation events); the guard cannot be made mechanically honest; the rider route shows intended-future evidence; any schema need.

Stage by explicit path; never git add -A; halt before every push.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-158 — Memory Registry Completeness — v0.2 — 2026-07-29