DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-191 — B-70: finish what 0054 started (v0.3)

Version. 0.3 · Date. 2026-08-08 · Author. Claude.ai (v0.1) / Claude Code (v0.2, v0.3 amendments) / Marvin Percival (ratifying). Supersedes. v0.2 at record 6cd6c4c. v0.1 and v0.2 stand as siblings. Target. /Users/dunin7/loomworks-engine, branch main. Engine only. Baseline. Engine 3bcf4f6, tag cr-2026-190-b54-fixtures.

What changed from v0.2. v0.2 asked the ratification and proposed no remedy. The Operator has ratified. The remedy follows from it, and is specified here.

1. The ratification

0041's claim holds. An operational identifier that did not exist when the object was created is not an audit-trail fact. The record is about content, state and commit facts; a display number is what the record is addressed by. Adding a handle is not editing the account.

Filed as standing-notes/loomworks-standing-note-operational-identifiers-are-not-audit-trail-facts-v0_1, with its boundary, because three migrations relied on it unratified and the next one should not have to rediscover it.

Two reasons, both recorded:

1. The counterfactual test. Had display_number existed from the start, every object would carry exactly the number 0054 computed — verified, zero drift across all 54 values. The backfill writes down something the log already determined. A content edit has no such counterfactual: absent the assertion there is no fact of the matter.
2. The compensating-event path fails its own standard. It would write 52 revisions that never happened into a record whose purpose is truthfulness about what happened. Keeping the letter of append-only while making the record false about the past is worse than the mutation it avoids. And the missing author is not a gap to route around — no actor did anything, which is the schema saying the event should not exist.

The boundary travels with the principle: it covers identifiers that are derived, verifiable, and determined by facts already in the log. It does not cover content, state, commit facts, attribution, or any value that is a judgment rather than a computation. A future migration wanting to write something unrecomputable does not inherit this answer.

2. The remedy

Finish what 0054 started, following 0041 and 0094's pattern.

A migration that, for every shape_event and render_event in memory_events whose payload lacks display_number, writes the number the projection already holds for that object.

• Source of truth: the projection, which was verified to hold exactly what 0054's formula computes. Recompute-and-compare rather than recompute-and-write — if any object's stored number disagrees with the recomputation, halt rather than paper over it.
• Every version of an object gets the number, as 0041 established. 32 shapes and 20 renders across 90 events.
• Idempotency: NOT (payload ? 'display_number'). The key is absent, never JSON-null, in all 90 events, so the predicate is unambiguous. Re-running is safe.
• Downgrade strips the key, as 0041 and 0094 do.
• current_memory_objects is written too where it carries these object types — the sibling migrations wrote both projections, and leaving one behind recreates the defect in miniature.

3. Out of scope, unchanged

• Option (a) — projector-assigns-on-missing. Ruled out permanently.
• The NOT NULL constraint. It is unblocked by this CR but is not in it. B-54's database half returns as its own change request once this lands and rebuild is verified faithful.
• Any change to how numbers are assigned going forward. CR-2026-176 settled that.
• Any other migration's backfill. 0055's and 0094's work is ratified, not reopened.

4. Verification — the point of the whole item

The acceptance test is not that payloads changed. It is that a rebuild reproduces the view.

A test that takes an engagement with legacy events, records the view's numbers, runs rebuild_shape_events_view and rebuild_render_events_view, and asserts the numbers come back identical. That is the defect B-70 exists to close, and nothing short of it demonstrates closure.

Observe it failing first — against pre-migration payloads it must fail, and the failure must name the invariant, not merely report a mismatch.

5. Seed-mutability impact

Kind C, checked, no contact — established at Step 1 and unchanged by the remedy. All 64 shape events carry seed_version_at_production; numbering never reads it; the backfill carries it forward untouched.

6. Build steps

| Step | What | Mode | |---|---|---| | 0 | Pre-flight. | Auto | | 1 | Read per v0.1 §2. Done — findings filed. | done | | R | Operator ratification. Done — §1. | done | | 2 | The migration, with downgrade. | Auto | | 3 | Drift guard: recompute and compare before writing; halt on disagreement. | Auto | | 4 | Rebuild-faithfulness test per §4, observed failing first. | Auto | | 5 | Apply to playground_dev; verify the counts go to zero. | Auto | | 6 | Full suite; ruff 0; mypy at/below baseline. | Auto | | A | Checkpoint. | Checkpoint | | 7 | Tag cr-2026-191-b70-log-reconstruction. Push. | Auto |

7. Acceptance gate

1. A rebuild of a legacy engagement reproduces the view's display numbers — proven by a test observed failing before the migration.
2. Zero shape_event / render_event payloads lack display_number after the migration.
3. The migration is idempotent and has a working downgrade.
4. The drift guard exists and would halt on disagreement — not merely that it did not fire.
5. Full suite green; both gates clean.
6. Seed-mutability recorded — Kind C.
7. B-54's database half is recorded as unblocked, and left for its own change request.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-191 — B-70 finish what 0054 started — v0.3 — 2026-08-08