Version: v0.1
Date: 2026-08-24
Status: Correction note. Sits beside loomworks-scoping-the-roster-exception-v0_2; that note is not edited.
Corrects: standing-notes/loomworks-scoping-the-roster-exception-v0_2 §3b, the paragraph beginning "Removal cost:".
Related: change-requests/cr-2026-235-retire-the-rendering-roster-role-in-place-v0_2 §6 and §8; and the correction filed beside cr-2026-235-…-v0_1.
> Removal cost: two code sites, one new migration, zero test changes. The binding test iterates the roster generically and asserts uniqueness rather than count. No fixture names the role or …022702. Three documents in loomworks-record describe it and none depends on it.
All three particulars are wrong, and the conclusion they support is wrong.
"Zero test changes" — no. test_native_agent_roster_matches_migration_seed parses _SEED_ROSTER out of migration 0113 with ast.literal_eval and asserts set equality with the module's roster. Removing the module entry fails it immediately:
Extra items in the right set:
('rendering', 'Claude (rendering)', '00000000-0000-0000-0000-000000022702')
"One new migration" — no. The row cannot be deleted at all. Two agent_lifecycle_events rows reference …022702, and both foreign keys into agent_identities are ON DELETE NO ACTION. Postgres refuses the delete outright; there is no migration that succeeds.
"Two code sites" — no. There is one code site, and it stays. Migration 0113's literal is not a site that can move, because it is history.
The conclusion: §3b treats removal as small and available. The entry cannot be removed at all — not cheaply, not expensively. It is retired in place instead (CR-2026-235 v0.2), which is a comment and a test and no schema change.
Worth stating, because "the removal was blocked" reads like an obstacle and it is not.
The binding test is doing its job. Its docstring says the roster is written twice deliberately and this test is what makes the duplication safe rather than a drift hazard. Removing one side is precisely the drift it exists to refuse.
The foreign key is doing its job. The rows it protects are the arc's two most-cited pieces of evidence — the unresolvable 2026-08-23 actor, and Test 8's unrecorded widening. Evidence cannot be deleted is already ruled, and here the database enforces the ruling without being asked.
The halt was caused by two controls working, which is the best kind.
The error is upstream of this note, and naming where it entered matters more than the correction.
The §7.1 trace report (2026-08-24, read-only, at engine 7136e34) was asked what removal would take. It reported: "binding test — no hardcoded reference, iterates generically, asserts uniqueness not count — passes either way."
That describes test_roster_entries_are_unique_on_role_and_id. The binding test is test_native_agent_roster_matches_migration_seed, which sits directly above it in the same file. The uniqueness test was read in place of the binding test, and the sentence was written with confidence because the file had genuinely been opened.
From there it propagated by citation, not by re-derivation:
cr-2026-235-…-v0_1 §7.3, as it should pass unchanged →Nobody re-checked it at any step, because each step was reading a document that said it, not the file. It was caught only by attempting the change and watching the test fail.
The general form, and it is this arc's fifth instance: a scan narrower than the claim it supports. Earlier instances were a discard fence, an unsessioned baseline, a FORAY census, and a pre-flight that read construction sites rather than what they referred to. This one read a test's neighbour. Opening the file is not reading the test — the same shape as reading a call site and not what it resolves to.
§3b's other claims hold and were re-derived by AST at current main: nothing resolves the rendering role; the three resolved roles are seed_induction, render_dispatch and shaping; every other "rendering" in the codebase is a different concept sharing the word; no fixture names the role or the id; the record documents describe it and none depends on it. The finding stands. Only its costing was wrong.
DUNIN7 — Done In Seven LLC — Miami, Florida Correction — the roster-exception note's removal cost — v0.1 — 2026-08-24