DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-226-w7-system-actor-kind-v0_1-amendment-v0_1.md

CR-2026-226 — W7: the system actor kind — amendment v0_1 — engine landing citation

Version. 0.1 Date. 2026-08-20 Amends. change-requests/cr-2026-226-w7-system-actor-kind-v0_1.md and the citation carried in its filing commit (loomworks-record 0ea0690). Nature. Correction beside, not correction over. The original citation stands as written; this note adds the second SHA the original could not have named. Status. Read alongside CR-2026-226 v0_1. Nothing in the CR's scope, out-of-scope, or acceptance sections changes.


The correction

The filing commit cited the engine landing as 1b850d5. That citation was true and is incomplete. CR-2026-226 landed in two commits, not one:

Engine main is at b606309. A reader who checks out 1b850d5 gets a tree whose CI stand-up fails.

Why the follow-up was needed, in one line

The bootstrap actor started writing actor_kind='system' at migration 0033, but the CHECK constraint was not widened until 0112 — and CI's staged stand-up (upgrade to 0033 → run bootstrap_engagements.py → upgrade to head) runs the bootstrap in that gap. The 0039/0057 recreates write absolute kind sets, so they would have refused validation against existing system rows even had 0033 admitted them.

What this is an instance of

The CR's own migration-0112 design was correct for deployed databases and silent about fresh ones. Widening a CHECK at revision N assumes no writer produces the new value before N; the bootstrap is exactly such a writer, and it runs mid-chain. Worth carrying into W1/W2/W4: any new enum value written by bootstrap must be admitted by the constraint as of the revision bootstrap runs at, not merely by head.

Nothing about the allowance lane, the allowlist-as-data shape, or ruling R1 is affected.