DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path inspection-briefs/loomworks-walk-audit-w1-door-3-correction-note-v0_1.md

Loomworks — correction to walk-audit W-1 ("door 3") — v0.1

Version. 0.1 Date. 2026-08-07 Author. Claude Code (Wave 0 session). Operator: Marvin Percival. Charter. standing-notes/dunin7-standing-authorization-charter-v0_1, §2 R-3 — correction notes filed beside what they correct. Corrects. inspection-briefs/loomworks-walk-audit-report-v0_1.md (record 66c2a74), finding W-1, at its §"W-1 — Door-3 engagements cannot derive a Manifestation". Closes. Build-list item B-26, "Correct the record about door 3."

What this is. Two corrections to W-1 — one of scope, one of status. Per the seed's corrections preserved, not smoothed, nothing is deleted from the walk-audit report; the superseded position stands there and this note sits alongside it.


Correction 1 — W-1's scope was too narrow. The defect was never door 3's.

Prior position (walk-audit report v0.1). W-1 is stated as a door-3 defect: "Door 3 produces engagements that cannot reach Stage 2 at all. Every engagement created through the shipped door-3 path writes one discovery_to_seed_extracted Memory event, and that event type is not registered in the Memory registry." The report's headline list, its stage table, and its finding title all attribute the failure to door 3 specifically.

Current position. The unregistered type was one of eight, and door 3 was not the common case. CR-2026-158's Step 0 sweep (recorded in change-requests/cr-2026-158-memory-registry-completeness-v0_2.md, record 64f1f54) established the real class:

> discovery_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

Every creation door poisoned replay, not door 3 alone, and upload_event_received made it the common case — any engagement that had ever received an upload was in the affected class. The live affected class was six engagements, not the two the walk observed, including three of the four protected ones.

Why W-1 got the scope wrong, and it is not a diligence failure. The walk audit was a walk — it exercised one path and correctly reported what that path did. Door 3 was the door it walked, so door 3 was the door whose breakage it saw. The isolation control it ran (§4) was sound and its conclusion — this engagement cannot derive, the control can — was true. What a single-path walk structurally cannot see is that the same fault sits behind every other door too. The registry simply stopped registering at Phase 37; everything added since was unregistered. The defect was general, and door 3 was the symptom that happened to be under the light.

> The finding worth keeping. A walk that finds a broken door has found a broken door. Whether the breakage belongs to the door or to something the door merely touches is a second question, and it needs a sweep rather than a walk. W-1 named the door because the door was what it walked.

Correction 2 — W-1 is fixed. It was fixed by CR-2026-158, not by anything door-3-specific.

Prior position. W-1 is open and BROKEN; the walk-audit report's stage table marks Stage 2 broken on the walked engagement, and states "Fixed would mean: an engagement created through the shipped door-3 path can derive a Manifestation."

Current position — verified against the engine on 2026-08-07, not inferred from the merge report. All eight types are registered in src/loomworks/memory/registry.py; each was checked individually:

| Event type | Registry state | |---|---| | discovery_to_seed_extracted | registered (registry.py:253) | | engagement_created_from_assistance | registered | | grant_request_received | registered | | jurisdiction_routing_decided | registered | | manual_content_contributed | registered | | reconciliation_proposal | registered | | seed_committed_from_brief | registered | | upload_event_received | registered |

Two standing tests guard it: tests/test_cr_2026_158_registry_guard.py (the completeness guard — a newly written event type that is never registered fails the suite) and tests/test_cr_2026_158_replay_heal.py.

W-1's own "fixed would mean" condition is therefore met, and met more broadly than it was written: every door can derive, not only door 3.

One thing this note does NOT claim. It makes no assertion about the two walk-audit engagements (WALK-AUDIT-2026-07-28 and …-CONTROL) or the six live affected engagements. CR-2026-158 recorded that affected engagements heal on next derive rather than being repaired in place; whether each has since been re-derived is live-database state, not source state, and was not checked here — this was a read-only source pass.


What this changes elsewhere


DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — correction to walk-audit W-1 ("door 3") — v0.1 — 2026-08-07