Version. 0.1 · Date. 2026-08-08 · Author. Claude.ai (drafting) / Marvin Percival (approving).
Target. /Users/dunin7/loomworks-engine, branch main.
Baseline. Engine 3bcf4f6, tag cr-2026-190-b54-fixtures. CC confirms at Step 0.
Companion to. standing-notes/ B-70's note (legacy engagements cannot be rebuilt from the log); CR-2026-190 v0.2, where this was found; standing-notes/dunin7-build-list-v0_43 (B-70).
Charter. Autonomous regime. Status. Read-first. Step 1 halts unconditionally — see §2.
Migration 0054 backfilled display_number into the projections and never into the event payloads. Replaying the log therefore cannot reconstruct the view: 63 of 64 shape events and 27 of 28 render events in playground_dev carry no display_number in their payload. Incremental projection is safe (the upsert COALESCEs), but rebuild-from-scratch — the recovery path you reach for when a projection is already damaged — produces nulls.
Settled already, and not reopened here. The remedy is compensating events carrying the numbers 0054 computed, so the log holds what the view holds. Rejected: having the projector assign a number when the payload lacks one — that makes a reader into a writer of facts, allows two rebuilds to disagree, and inverts the log-is-truth relationship the substrate rests on.
This CR writes to the event log. That is the most load-bearing surface in the system and the one thing the whole architecture treats as authoritative. No amount of pre-settling in this document substitutes for reading what is actually there, and this CR does not pre-decide the event's shape.
Three questions in particular are not answerable from outside the code, and one of them may not have a good answer:
The log is provenance-bearing. An event written today recording a fact from 2026-05 has to answer: who is the author, and when is the assertion dated?
Two shapes, and they are not equivalent:
CC reports what the log's existing event model can express and what precedent exists for a system-authored corrective event. If no precedent exists, say so — inventing one is a substrate decision, not a CR decision.
The numbers exist in the projection. Are they recoverable in a form that can be written into events — and is the projection's current content still what 0054 computed, or has anything since modified it? A compensating event that records a drifted number makes the log agree with a view that was already wrong.
This is the question that could make the CR much larger. If one migration wrote to a projection rather than the log, others may have. CC surveys the migration history for the same pattern and reports what it finds. If others exist, halt and report rather than expanding scope — the remedy might be general rather than display_number-specific, and that changes the shape of everything.
A findings document, and then a halt. Not code.
Report: the answers to §2.1–2.3, a recommended event shape with reasoning, the count of events needing compensation across all engagements (not only playground_dev), and whether the operation is idempotent — running it twice must not double-write.
Explicitly report anything that suggests this should be a substrate decision rather than a repair. If the honest answer to §2.1 is that the event model cannot express a system-authored correction without either lying about time or breaking replay order, that is a finding worth more than a workaround.
NOT NULL constraint. It waits behind this. B-54's database half is deferred, not cancelled.B-69's instruction applies, and this CR is a plausible Kind B site: if any event payload carries or derives from seed state, compensating events raise the question of which seed version the compensation is written under. Record the check with its Kind label, including if the answer is C (checked, no contact).
| Step | What | Mode | |---|---|---| | 0 | Pre-flight. | Auto | | 1 | Read per §2. File findings. HALT unconditionally. | Auto, hard halt | | 2+ | Scoped in a v0.2 amendment after the Operator decides. | Blocked |
Execute CR-2026-191 v0.1 STEP 1 ONLY, at ~/Downloads/cr-2026-191-
loomworks-b70-log-reconstruction-v0_1.md. Confirm the CR number first.
This CR writes to the event log — the most load-bearing surface in the
system. Step 1 halts unconditionally. Nothing is built in the session
that reads.
Three questions, and §2.1 is the one that matters most: a compensating
event is an assertion, and the log is provenance-bearing. What does it
assert, who authors it, and what is it dated? Dated-now is honest but
puts the number after everything that depended on it in replay order.
Backdated makes replay correct and lies about when the assertion was
made — and this project preserves corrections rather than smoothing
them. Report what the event model can express and what precedent exists
for a system-authored corrective event. If none exists, say so; don't
invent one.
§2.3 is the one that could make this much larger: survey the migration
history for other migrations that wrote to a projection rather than the
log. If others exist, halt and report — the remedy may be general
rather than display_number-specific.
Report the count across ALL engagements, not just playground_dev, and
whether the operation is idempotent.
And if the honest answer to §2.1 is that the event model can't express
a system-authored correction without either lying about time or
breaking replay order — say that. It's a more valuable finding than a
workaround.
Option (a) is permanently out of scope. Do not revisit it.
DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-191 — B-70 log reconstruction — v0.1 — 2026-08-08