What is happening
#1052 froze bin/smoke/ci-suites.txt and introduced bin/smoke/ci-suites.d/, one file per suite, so that two branches adding unrelated suites stop conflicting. That closed #998 ("GitHub ignores merge=union on ci-suites.txt, so suite-adding PRs falsely conflict and then run no CI"). The mechanism works — there are 55 fragments on main.
Nothing enforces it. The freeze is a sentence in a comment inside the file:
# ORDER IS EXECUTION ORDER and it is not alphabetical: ... This legacy list is now FROZEN;
# add new suites one-file-per-suite under `ci-suites.d/`.
Since #1052 merged, main has appended to the frozen list three times anyway:
50a6356a6 test(manager): reproduce the two-root renewal adoption refusal (#773)
398c85820 test(manager): reproduce the stack-stop agent reap (#964)
45ae9d788 test(ci): keep this branch's three suites at the end of the suite list
All three confirmed descendants of the #1052 merge (git merge-base --is-ancestor f2b52954c <sha>).
Why it matters rather than being untidy
Every append re-arms the exact failure #1052 closed, for everyone else. Two open PRs, #880 and #1069, both add a line to that tail right now, so whichever lands first re-conflicts the other on a line neither one cares about. And per #998 the cost is not just the conflict: a conflicting PR gets no CI run at all, so the branch also stops being testable until someone resolves a merge that carries no information.
The erosion is invisible at review time. An append looks correct, is shard-safe if it is a genuine tail append, and passes every gate. The cost lands on a different branch, later, and reads there as an ordinary merge conflict rather than as a consequence of this choice.
What would fix it
A gate that fails when a commit adds a suite line to ci-suites.txt, pointing at ci-suites.d/ and naming the sha256(<suite name>) filename the author needs. Deletions and comment edits stay legal, since the list still has to be prunable. smoke:gate-inventory already parses both sources and is the natural place.
Whether the three existing appends get migrated to fragments is a separate and lower-stakes question — they are already on main and cost nothing further where they sit. The value is in stopping the next one.
Not this issue
What is happening
#1052 froze
bin/smoke/ci-suites.txtand introducedbin/smoke/ci-suites.d/, one file per suite, so that two branches adding unrelated suites stop conflicting. That closed #998 ("GitHub ignores merge=union on ci-suites.txt, so suite-adding PRs falsely conflict and then run no CI"). The mechanism works — there are 55 fragments on main.Nothing enforces it. The freeze is a sentence in a comment inside the file:
Since #1052 merged, main has appended to the frozen list three times anyway:
All three confirmed descendants of the #1052 merge (
git merge-base --is-ancestor f2b52954c <sha>).Why it matters rather than being untidy
Every append re-arms the exact failure #1052 closed, for everyone else. Two open PRs, #880 and #1069, both add a line to that tail right now, so whichever lands first re-conflicts the other on a line neither one cares about. And per #998 the cost is not just the conflict: a conflicting PR gets no CI run at all, so the branch also stops being testable until someone resolves a merge that carries no information.
The erosion is invisible at review time. An append looks correct, is shard-safe if it is a genuine tail append, and passes every gate. The cost lands on a different branch, later, and reads there as an ordinary merge conflict rather than as a consequence of this choice.
What would fix it
A gate that fails when a commit adds a suite line to
ci-suites.txt, pointing atci-suites.d/and naming thesha256(<suite name>)filename the author needs. Deletions and comment edits stay legal, since the list still has to be prunable.smoke:gate-inventoryalready parses both sources and is the natural place.Whether the three existing appends get migrated to fragments is a separate and lower-stakes question — they are already on main and cost nothing further where they sit. The value is in stopping the next one.
Not this issue