CI: the merge queue is wired up in ci.yml but has never run — it is not enabled on the branch

[dborgards]

Found while checking a review finding on #104, not while looking for it.

What is the case

.github/workflows/ci.yml carries a merge_group trigger, and the comment above it records exactly why:

A merge queue builds main plus the queued pull requests together and merges only if that combination is green. […] The reason it exists: #81 and #83 were each green and merged four minutes apart, and their combination broke the net48 leg on main (#85). Neither pull request was ever built against the other.

The trigger has never fired. Filtering CI runs by event: merge_group returns total_count: 0. Every merge to main, including #100 and #101 today, went in as a plain merge commit.

So the workflow half is done and the repository-settings half is not: GitHub's merge queue has to be turned on in the branch protection / ruleset for main before the trigger can ever be reached.

Why it matters

The failure it was built for is not hypothetical — #85 already happened, from two green pull requests merged four minutes apart. The workflow change that was supposed to prevent a repeat is inert, and nothing surfaces that: an unused trigger looks identical to a working one in the file.

It also affects a rule being added in #104. One pull request open at a time has two justifications — supervision cost, and the base merges that a merge to main forces on everything else in flight. The second one is only true while the queue is off. With the queue on, a queued branch is tested against current main on a temporary ref, with no base merge and no new head. Worth knowing so the rule is not later dismissed on the grounds that "we have a merge queue" when in practice we do not.

What to check when picking this up

• Whether the queue was deliberately left off (it interacts with required checks, and every required check must also run on merge_group, which this workflow does handle).
• Whether the version job's GitVersion behaviour on a gh-readonly-queue/... ref is really tolerated — the comment claims it is, but that claim has never been executed, so it is unverified rather than known.
• That concurrency: ci-${{ github.workflow }}-${{ github.ref }} gives each queue entry its own group, as the comment states.

Low priority, no user-visible effect. But it is a guard that is currently only decorative, which is worse than not having it, because it reads as protection that is not there.

Refs #81, #83, #85, #104.

[dborgards]

Decision: enable it. The settings half is the maintainer's; the verification is mine.

What to switch on — Settings → Rules/Branches, on the ruleset or branch protection for main: Require merge queue. The workflow half needs nothing: ci.yml already carries the merge_group trigger, which is why this issue exists.

Two settings inside the queue are worth choosing deliberately rather than leaving at the default:

• Merge method — the repository merges pull requests as two-parent merge commits today, and CLAUDE.md § Pull requests depends on that: semantic-release reads every branch commit, so a squash would change which commits decide the release. Set the queue to the same merge strategy the repository already uses, or the queue quietly changes the release semantics.
• Required checks on merge_group — whatever is required for a pull request must also be required for a queue entry, otherwise the queue merges on a signal nobody checked.

What I verify once it is on, which is the list this issue already carries:

1. That the required checks actually run and report on a merge_group event, rather than sitting pending forever.
2. That the version job's GitVersion behaves on a gh-readonly-queue/... ref. This issue calls that "unverified rather than known", and it is the one that could block main if it is wrong — so it wants watching on the first queued pull request rather than assumed.
3. That the concurrency group gives each queue entry its own group, so two entries do not cancel one another.

If any of the three misbehaves, the queue can be turned off again in the same place, and the failure is worth recording here either way.

Why now. The case the guard was built for has already happened — #81 and #83 merged four minutes apart and their untested combination broke the net48 leg on main (#85). A protection that is configured but never runs is worse than none, because the configuration reads as coverage.

One consequence worth flagging: CLAUDE.md's one pull request open at a time rule cites the base-merge cost as one of its two reasons, and an enabled queue removes exactly that cost — a queued branch is tested against current main without a base merge and without a new head. The supervision cost, which is the rule's actual reason, is untouched. So the rule stands, but its aside will want rewriting once the queue has run a few times, and that is a separate change from this one.

---

Generated by Claude Code