Merge Queue & Manual Merge-Train Runbook

Since v3.8.49 (WS3.2/WS3.4 of the quality/velocity plan) the default merge path for reviewed PRs into release/vX.Y.Z is the Mergify merge queue (.mergify.yml); the manual merge-train documented below is the FALLBACK — used during incidents, release freezes, or if the Mergify Open Source plan ever changes.

Default path: the Mergify queue

1. PR is reviewed/greened by the campaigns and approved by the owner's pre-merge ⭐ gate (the report + per-item decision — see /merge-prs Step 0.75).
2. The owner (or the session acting on the owner's decision) applies the queue label. The label IS the merge approval; Mergify only executes it.
3. Mergify batches up to 10 queued PRs, validates the batch against the fast-gates, and merges (squash). A red batch is bisected automatically — the offending PR is isolated in ~log2(N) revalidations and unqueued; the rest proceed.
4. Post-merge, the continuous release-green workflow validates the new tip on push and opens an attribution issue if the combination regressed (never auto-revert).

Guardrails (mirror CLAUDE.md Hard Rules #21/#22):

• Release freeze open → do NOT label PRs targeting the frozen branch; retarget to the active release/vX+1 first.
• Another session's in-flight PR → never label it; only the owning session queues its own work.
• Tests-only diffs and hotfix-labeled PRs already run reduced CI (see RELEASE_CHECKLIST.md → Hotfix Fast-Lane); the queue conditions accept whatever check set actually ran (#check-failure=0 + #check-pending=0).

Fallback: the manual merge-train

Used when the queue is unavailable. This codifies the practice that drained 33 PRs in one day during the v3.8.47 cycle:

1. Assemble the batch (~10–30 reviewed+approved PRs). Check linked: collisions (same tap.testFiles, same CHANGELOG hunks) and serialize those.
2. Validate ONCE: in an isolated worktree off the release tip, merge all batch heads locally, then run the release-equivalent suite (npm run check:release-green, add --with-build before a release). scripts/release/merge-train.sh <base> <PR#>… automates steps 1–2 (conflicting PRs eject, the train continues). Full mode runs npm run test:unit — the box-tuned runner (--test-concurrency=20), not the two sequential 4-core CI shards, which drove the dominant phase at ~25% of a 16-core box (fixed 2026-07-18). --fast (intra-day mega-train drains, owner-approved 2026-07-18) keeps every static gate + vitest but runs only the node:test files changed by the boarded PRs; the FULL suite must still run at least once per day on the accumulated tip (one train without --fast).
3. Green → merge the PRs in sequence (re-checking state,headRefOid before each — a PR whose head moved re-enters review). Prove the net diff of each merge is the PR's own change (no auto-resolve reverts: audit git diff --stat for out-of-scope deletions).
4. Red → bisect the batch by halves (validate each half) instead of re-validating one-by-one; drop the offending PR back to the review queue with the evidence.
5. Never: merge during a freeze into the frozen branch; git stash anywhere; blanket-rerun CI hoping a red goes away (rule: a red is information).

Tiering (why the queue is safe with fast-gates only)

• Per PR (quality.yml fast-gates): TIA-impacted tests + full unit 4-shard + vitest + lint bag + typecheck + docs/changelog integrity.
• Per batch/tip (continuous release-green): --quick HARD gates on every push to the release branch; full --with-build --full-ci sweeps 3×/day.
• Per release (ci.yml on the release PR): the complete matrix incl. E2E ×9, package-artifact + tarball boot-smoke, coverage/ratchets.

Nothing is validated less than before — the heavy surface just runs per batch/tip instead of per PR, which is what removes the O(N) round-trips.