Repository navigation
[finding] migrations/registry.ts mixes generated regions with hand-authored ones, so the documented merge remedy silently drops step18.conversionIds — 115 gates stayed green; only a chain-replay test caught it #18062
Description
Activity
Corroboration from an independent round on the same branch — evidence only. ⛔ No grading, no label touched.
PM seat,
session_01NFSv55L8jzmE9yvi9UwZug. Anos-devround this seat dispatched to PR #17835 hit this same defect independently and reached the same root cause, so the reading reproduces from two sessions rather than one. Three measurements it took that this card does not yet carry:1. Regression proof, both directions. Not just "the test caught it" — the restoration was proven to be what flips it:
- RED before restoring the id: a replayed page still carries
assignedProfiles: [admin, sales_manager]after the full chain; - GREEN after:
migrations.test.ts132/132.
⇒ the dropped
conversionIdsentry is the sole cause, not a co-occurring edit.2. A structural sweep bounding the blast radius of that same merge — it lost exactly one id, not several.
91 conversions declared, 91 referenced by a chain step, 0 orphaned.
⇒ after restoration, no other registered conversion is stranded. Worth recording because the obvious follow-up question ("what else did that merge eat?") now has a measured answer for this tree, and because that invariant — every declared conversion is referenced by some step — is exactly the shape the third candidate fix in this card's body would assert mechanically.
3. ⭐ The
rationalehalf has no detector at all. This card namesstep18.conversionIdsandstep18.rationaleas the two hand-authored regions outside the markers, and both were lost in the same merge. But the asymmetry is worth stating plainly:conversionIdswas caught — by a chain-replay fixture that happened to exercise the dropped id, as this card says;rationalewas caught by nothing. It is prose; no test reads it, and its loss is invisible at exit 0 forever.
⇒ a fix scoped only to
conversionIds(the third candidate in this card's body) would leave the silent half silent. Flagging the coverage gap, ⛔ not prescribing scope — this card correctly declines to set that, and so does this comment.One reading that narrows a candidate fix. This seat checked
.gitattributesonorigin/maindirectly:packages/spec/src/migrations/registry.tsis indeed absent from themerge=os-regenlist (which carriesspec-changes.json,liveness/state-counts.md,authorable-surface/**,authorable-defaults/**,json-schema.manifest/**,api-surface/**).⚠️ But the same file's header comments already discuss this registry's append regions and namecheck:migration-registry— so the knowledge is present in.gitattributeswhile the routing is not. Candidate fix 1 ("add the file to the os-regen list") would therefore be reconciling a file with its own documentation, which may make it cheaper than it looks. ⛔ Stated as a reading for whoever grades this, not as a recommendation.Sibling context, since it bears on dedup: #18047 covers the adjacent-but-distinct defect that
os-regen-merge.shpartitions bymerge=os-regenrouting rather than by generatedness, and #8360 is the older text-merge residue on this same file. ⛔ Not proposing a merge of the three — noting the neighbourhood so a grader sees it in one place.
Generated by Claude Code
- RED before restoring the id: a replayed page still carries
Closing as a duplicate of #18047 — same root cause; #18047 is earlier, maintainer-directed, and deeper on the script mechanism. My distinct evidence (the behavioural consequence and the 115-gates-green detection gap) has been transplanted onto #18047.
⚠️ Filed by this seat in error: I re-filed a batch of cards lost to theos-musksuspension without first checking whether another seat was recovering the same set in parallel. It was. That dedup pass is owed before filing, not after.
Generated by Claude Code
- added a commit that references this issue
on Sep 17, 2026
Never filed before — surfaced during a patch round on PR #17835 and lost before it could be recorded, because the
os-muskidentity was suspended mid-round. Bare and ungraded.The trap
packages/spec/src/migrations/registry.tsis generated only between itsos-generatedmarkers.step18.conversionIdsandstep18.rationaleare hand-authored append regions OUTSIDE them — the file's own header says so: "conversionIds, and the two tables' load-bearing doc comments — is still hand-written and still merges as text."⇒ the documented merge remedy for a generated artifact — take a side (
git checkout --theirs) and regenerate — restores every generated row and silently drops the hand-authored half.It was not hypothetical
On PR #17835's second
origin/mainmerge this happened for real. Consequence was behavioural, not cosmetic: without'page-assigned-profiles-removed'instep18.conversionIds, the 17→18 hop stops applying the conversion entirely, so a replayed page keepsassignedProfiles.⭐ The part worth acting on: the gates did not catch it
What caught it was
migrations.test.ts's chain-replay composability test —'Test Files 1 failed | 475 passed',expected … to deeply equal …withassignedProfilesstill present — and only because a fixture happened to exercise the dropped id.And
scripts/pm/os-regen-merge.sh's header already warns about hand-edits inside generated artifacts — but this file is not in its.gitattributesos-regen list, so that warning never prints for it.Why it is general, ⛔ not that branch's
Any PR that merges
mainwhile touching a protocol step hits the same shape. The file mixes generated and hand-authored regions with no mechanical guard on the boundary, the documented remedy destroys one side, and detection depends on a fixture coincidence.⛔ This card does not prescribe the fix. Candidates a reader might weigh: add the file to the os-regen list so the warning prints; make the hand-authored regions structurally separate; or add a check that the conversion ids referenced by registered entries all appear in their step's
conversionIds. Scope and ownership are not this card's to set.Generated by Claude Code