fix(gates): demo-data-coverage moves to 102, and gate numbers are now checked - #623
Merged
Conversation
added 2 commits
August 28, 2026 11:48
… checked TWO SESSIONS FIXED ONE COLLISION AND MADE IT WORSE. gate-99 was claimed by `manifest-l10n-coverage` and `demo-data-coverage` at once. #612 moved demo-data-coverage to 101. #615 moved manifest-l10n-coverage to 101. Both diffs were correct in isolation; together they relocated the collision from 99 to 101 and left gate-99 orphaned. Nothing noticed until the same acceptance suite failed again with the number changed: FAIL — expected FAIL on planted, got: [gate-101] manifest-l10n-coverage: NOT APPLICABLE ... demo-data-coverage takes 102. manifest-l10n-coverage keeps 101, because #615 says so in its title and its own suite keys on it; mine is the newer claim in conflict, so mine moves. gate-99 stays vacant rather than being reused: its history now points at two different gates, and a number that has meant two things is worse than a gap. 🔴 MY OWN VERIFICATION MISSED IT. After the first renumbering I checked the `# GATE N — name` COMMENT headers and confirmed "no duplicates". The headers were distinct (99 and 101) while both gates called `_pass 101`. I verified the labels and not the behaviour. So the new check reads the CALL SITES, which are what the report, the COVERAGE tally and every acceptance suite actually key on. There is a gate-95 for ADR number collisions and nothing for GATE numbers; this is that check. Five arms, and ARM 2 reconstructs the exact state that reached main and asserts both gate names appear in the error. ARM 3 plants distinct headers over colliding calls — the precise thing my manual check waved through. ARM 4 pins that a runner with no gates exits 2, because a silent zero is how this class hides. 81 gates, every number claimed once.
main already fixed the gate-99 collision, the other way round from this branch:
main manifest-l10n-coverage=102 demo-data-coverage=101
this branch manifest-l10n-coverage=101 demo-data-coverage=102
Mirror images. Both internally consistent, neither conflicting in git — and
merging them naively produced exactly the failure this branch exists to
prevent: the auto-merge left TWO gates declaring 102. That is the same trap as
the original incident, one number along: two correct fixes for one collision
combining into another.
Resolved to main's numbering. The renumbering half of this branch is now
redundant and is dropped; what survives is the part main does not have —
`check_gate_numbers_unique.sh` and its suite.
🔴 THE FIXTURES WERE STALE, NOT THE CHECKER. ARM 2 and ARM 3 failed after the
merge because both plant their collision with
sed 's/_pass 102 "demo-data-coverage"/_pass 101 .../'
which matches nothing once demo-data-coverage is 101. A fixture that plants
nothing asserts nothing, and both arms were passing a checker that had not been
handed a collision at all. Re-pointed onto main's numbering — demo-data moved
onto manifest-l10n's 102 — and both arms now fail the checker as intended.
ARM 3 is the one that matters: distinct `# GATE N` headers must not excuse
colliding call sites. I made exactly that mistake when I verified the first
renumbering by reading headers and reported "no duplicates" over a runner where
both gates still called `_pass` on the same number.
5 arms, all passing; the shipped runner reports 81 gates, every number claimed
once.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two sessions fixed one collision and made it worse.
gate-99was claimed bymanifest-l10n-coverageanddemo-data-coverageat once. #612 moved demo-data-coverage to 101. #615 moved manifest-l10n-coverage to 101. Both diffs were correct in isolation; together they relocated the collision from 99 to 101 and left gate-99 orphaned. Nothing noticed until the same acceptance suite failed again with the number changed:The resolution
setup-demo-data-firstmanifest-l10n-coveragedemo-data-coveragemanifest-l10n-coverage keeps 101 — #615 says so in its title and its suite keys on it. Mine is the newer claim in conflict, so mine moves.
gate-99stays vacant rather than being reused: its history now points at two different gates, and a number that has meant two things is worse than a gap.🔴 My own verification missed it
After the first renumbering I checked the
# GATE N — namecomment headers and confirmed "no duplicates". The headers were distinct (99 and 101) while both gates called_pass 101. I verified the labels, not the behaviour.So the new check reads the call sites — what the report, the COVERAGE tally and every acceptance suite actually key on. There is a
gate-95for ADR number collisions and nothing for gate numbers; this is that check.Five arms
81 gates, every number claimed once.