Version: v0.1
Date: 2026-08-24
Status: Correction note. Sits beside cr-2026-235-remove-the-unconsumed-rendering-roster-role-v0_1; that document is not edited.
Corrects: change-requests/cr-2026-235-remove-the-unconsumed-rendering-roster-role-v0_1 §7.3.
Superseded by: cr-2026-235-retire-the-rendering-roster-role-in-place-v0_2, which is what executed.
Related: the correction filed beside loomworks-scoping-the-roster-exception-v0_2, which carries the same error from one step earlier in the chain.
> test_native_agent_roster_matches_migration_seed passes — it iterates generically and asserts uniqueness rather than count, so it should pass unchanged. If it fails, halt: it means the binding is tighter than believed and the migration must move in step.
The named test does not iterate generically and does not assert uniqueness. It parses _SEED_ROSTER out of migration 0113 with ast.literal_eval and asserts set equality with the module's roster:
assert from_module == _migration_seed_roster()
So removing the module entry fails it immediately — demonstrated on a backup-and-restore probe rather than reasoned about:
Extra items in the right set:
('rendering', 'Claude (rendering)', '00000000-0000-0000-0000-000000022702')
The clause that saved it. §7.3's own second sentence — if it fails, halt: it means the binding is tighter than believed — is exactly what happened, and it is why v0.1's Gate 1 halted at pre-flight instead of landing a red suite. The CR carried a correct instruction attached to a wrong premise, and the instruction did the work.
The binding is not merely tighter than believed. It is tighter than the halt clause imagined: not a count that could be updated, but an equality against a migration literal that may not be edited, which means neither half moves alone and removal is unavailable rather than expensive.
The claim entered at a §7.1 trace report, which described test_roster_entries_are_unique_on_role_and_id — the test sitting directly above the binding test in the same file — and reported it as the binding test. It then travelled by citation: trace report → loomworks-scoping-the-roster-exception-v0_2 §3b ("zero test changes") → this CR's §7.3.
Three documents, one reading, no re-derivation. Each step read the document before it rather than the file, so the error was preserved intact until execution was attempted.
Named generally at the correction beside the scoping note: opening the file is not reading the test. This arc's fifth instance of a scan narrower than the claim it supports.
§1's table — that nothing resolves the rendering role, and that the three resolved roles are seed_induction, render_dispatch and shaping — was re-derived by AST at current main and holds. §2's argument for acting holds and is what v0.2 executes, by a different means. §6's three shapes were correctly identified as open; the ruling since taken is the first of them.
The CR's finding and its reasoning stand. One premise about a test was wrong, and it changed the remedy from removal to retirement in place.
DUNIN7 — Done In Seven LLC — Miami, Florida Correction — CR-2026-235 v0.1's binding-test claim — v0.1 — 2026-08-24