DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-190 — B-54 remaining half: fixtures, then the constraint (v0.1)

Version. 0.1 · Date. 2026-08-08 · Author. Claude.ai (drafting) / Marvin Percival (approving). Target. /Users/dunin7/loomworks-engine, branch main. Baseline. Engine ad83960. CC confirms exact HEAD at Step 0. Companion to. inspection-briefs/loomworks-b54-residue-findings-v0_1.md (Wave 0.5); CR-2026-171 §2.2, where the migration was first reverted; CR-2026-176, which landed the code half. Charter. Autonomous regime. Status. Ready for CC execution.

1. Summary

B-54's code half landed in CR-2026-176 — three production call sites that created shapes and renders with no sequence number now assign one. What remains is the database-level guarantee: display_number should be NOT NULL, and cannot be until the test fixtures stop violating it.

Two prior attempts inform this one. CR-2026-171 tried the migration first and reverted when it broke 230 fixtures. Wave 0.5's investigation then found the fixture debt was the smaller half — three real production paths were writing NULL rows, which CR-2026-176 fixed. That ordering discipline holds here: fixtures, then constraint, and the constraint goes last.

Field-note citation. Wave 0.5 reported roughly 73 sites across 42 files, with three edits covering about 48 of them. CR-2026-171 reported 230 failing fixtures. Those two figures count different things (call sites vs. failing tests) and both predate CR-2026-176's changes. CC re-measures at Step 1 rather than building against either.

2. Scope

Step 1 — re-measure (read-only)

Apply the constraint locally without committing it, run the suite, and record:

How many tests now fail, and in how many files.
Whether the three-edits-cover-48 grouping from Wave 0.5 still holds after CR-2026-176.
Whether any failure is not a fixture — i.e. a production path still writing NULL that CR-2026-176 missed. If so, halt and report: that is a code fix, and the constraint waits behind it exactly as before.

Revert the local constraint before proceeding.

Step 2 — fixtures

Fix the fixtures so they populate display_number. Two rules:

Route through the same assignment helper the production paths use wherever the fixture is constructing a realistic object. A fixture that hardcodes a number the production path would compute differently is a fixture that tests a state the system cannot produce.
Where a fixture is deliberately minimal and routing it through the helper would be heavier than the test needs, assigning a literal is fine — but CC states which approach it used for each group and why.

Step 3 — the constraint

The migration tightening display_number to NOT NULL on both the render and shape views. Only after Step 2 is green.

Step 4 — prove the constraint holds

A test asserting an insert with a null display_number fails at the database level. Per the standing note, observe it failing for the right reason before trusting it — and make the failure message say what invariant broke, not merely that an insert was rejected.

3. Production data check

Before the migration lands, confirm zero NULL-numbered rows remain in playground_dev for both tables — CR-2026-176 backfilled, and this verifies the backfill held. A count query, read-only.

If any row is NULL, halt. The migration would fail on apply, and a partially-applied migration is worse than an unapplied one.

4. Seed-mutability impact

B-69's standing instruction applies. display_number is a sequence within an engagement; if anything about its assignment reads or derives from the seed, record the contact point under a seed-mutability impact heading, labelled Kind A or Kind B per the taxonomy in B-69's entry. Likely nothing here — recorded as a null finding if so, since an empty check is still an inventory entry.

5. Out of scope

Any change to how numbers are assigned. CR-2026-176 settled that. This CR makes the database require what the code already does.
Backfilling historical rows beyond what CR-2026-176 already did. If Step 3 finds rows CR-2026-176 missed, that is a halt, not a scope extension.

6. Build steps

| Step | What | Mode | |---|---|---| | 0 | Pre-flight — confirm baseline HEAD, tree clean. | Auto | | 1 | Re-measure per §2. Report figures. Halt if any failure is a production path. | Auto, conditional halt | | 2 | Production data check per §3. Halt if any NULL row. | Auto, conditional halt | | 3 | Fixtures, with the per-group approach stated. | Auto | | 4 | Suite green with fixtures fixed, constraint still absent. | Auto | | 5 | Migration. | Auto | | 6 | Constraint-holds test, observed failing first. | Auto | | 7 | Full suite; ruff 0; mypy at/below baseline. | Auto | | A | Checkpoint. | Checkpoint | | 8 | Tag cr-2026-190-b54-display-number-not-null. Push. | Auto |

7. Acceptance gate

display_number is NOT NULL on both tables, and a null insert fails at the database level — proven by observation, not asserted.
Every fixture populates it; the approach per group is stated with reasoning.
Zero NULL rows in production data, verified before the migration rather than assumed from CR-2026-176.
Full suite green; both gates clean.
Step 1's re-measured figures recorded, alongside the two prior figures they supersede.
Seed-mutability check recorded, including as a null finding.

8. Kickoff prompt


Execute CR-2026-190 v0.1 at ~/Downloads/cr-2026-190-loomworks-b54-
display-number-not-null-v0_1.md. Confirm the CR number against the
ledger first.

This closes B-54's remaining half. The code fix landed in CR-2026-176;
what's left is the database constraint and the fixtures blocking it.

ORDERING IS THE POINT: fixtures first, constraint last. CR-2026-171
tried the constraint first and reverted. Don't repeat it.

Step 1 re-measures rather than trusting either prior figure — Wave 0.5
said ~73 sites / 42 files, CR-2026-171 said 230 failing tests. Those
count different things and both predate CR-2026-176. Apply the
constraint locally, run the suite, record what actually fails now, then
revert it before continuing.

HALT at Step 1 if any failure is a production path rather than a
fixture — that means CR-2026-176 missed a site, and the constraint
waits behind the code fix exactly as before.

HALT at Step 2 if any NULL row remains in playground_dev. A migration
that fails on apply is worse than one not attempted.

Step 3: prefer routing fixtures through the same assignment helper the
production paths use. A fixture hardcoding a number the production path
would compute differently tests a state the system cannot produce.
Where a deliberately minimal fixture makes that heavier than the test
needs, a literal is fine — state which you used per group and why.

Step 6: observe the constraint test failing for the right reason before
trusting it, and make its message name the invariant, not just report a
rejected insert.

§4: B-69 applies. Likely a null finding here — record it as one anyway,
labelled Kind A or Kind B. An empty check is still an inventory entry.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-190 — B-54 remaining half — v0.1 — 2026-08-08