@@ -80,13 +80,19 @@ async function hasCIFailures(github, owner, repo, sha) {
8080/**
8181 * Determine the correct queue label for a PR based on approval counts.
8282 *
83- * Phase 1 logic (4-stage pipeline):
84- * maintainerApprovals >= 1 AND coreApprovals >= 2 → status: ready-to-merge (CODEOWNERS + min core reviews)
85- * coreApprovals >= 1 → queue:maintainers (senior review present, needs more)
86- * anyApproval >= 1 → queue:committers (has any approval, needs committer)
83+ * Phase 1 logic (5-stage pipeline):
84+ * ciFailing → queue:junior-committer (CI broken, block promotion)
85+ * maintainerApprovals >= 1 AND coreApprovals >= 2 → status: ready-to-merge (CODEOWNERS + min core reviews)
86+ * maintainerApprovals >= 1 (but coreApprovals < 2) → queue:committers (maintainer already in, need committer next)
87+ * coreApprovals >= 1 (no maintainer yet) → queue:maintainers (committer reviewed, needs maintainer)
88+ * anyApproval >= 1 → queue:committers (has soft approval, needs committer)
8789 * else → queue:junior-committer (no approvals yet)
8890 *
89- * Note: status: ready-to-merge requires BOTH a maintainer approval AND at least 2
91+ * Note: When a maintainer "jumps in early" before triage/committers, the PR should
92+ * route to queue:committers (not queue:maintainers) to attract a committer review
93+ * rather than a second maintainer. This prevents wasting maintainer bandwidth.
94+ *
95+ * status: ready-to-merge requires BOTH a maintainer approval AND at least 2
9096 * total core reviews (maintainer or committer). This prevents a single maintainer approval
9197 * + a soft approval from marking a PR as ready when branch protection requires 2+ core reviews.
9298 *
0 commit comments