What happens

When external services (Vercel, Netlify, etc.) post deployment statuses with state failure on a PR's head commit, in observed runs GitHub reported mergeable=UNSTABLE for those PRs. gh-aw's CLI auto-merge path rejects anything that isn't MERGEABLE, so PRs are blocked from auto-merging even when all required CI checks pass.

There is no mechanism in gh-aw's auto-merge gating to distinguish required CI checks from non-required third-party deployment statuses.

What should happen

gh-aw's auto-merge gating should provide a way to ignore configured non-required status contexts, or use required-check evaluation instead of raw mergeable when deciding whether to auto-merge.

Where in the code

All references are to main at 2d91393f3.

CLI auto-merge path:

• pr_automerge.go:38 — queries mergeable field via gh pr list --json
• pr_automerge.go:93 — skips any PR where Mergeable != "MERGEABLE", including UNSTABLE

Safe-output PR creation path:

• create_pull_request.cjs:881 — requests GitHub enable auto-merge; only warns if GitHub rejects it. Does not evaluate check state.

Check classification (reporting only, not used for merge gating):

• checks_command.go:308 — classifyCheckState() normalizes check runs and commit statuses into a single state
• checks_command.go:286 — policyCheckPatterns exempts policy/account-gate checks, but does not filter Vercel/Netlify-style deployment statuses. Any non-policy failed commit status is marked as failed.

Neither gh aw checks, mergeStateStatus, nor statusCheckRollup is used in any merge decision path.

Evidence

Production:

• In a pipeline with Vercel preview deployments, PRs that passed all required GitHub Actions CI were blocked from auto-merge because GitHub reported mergeable=UNSTABLE after Vercel's deployment status posted failure
• Consumer-side workaround: commit 81b741b in our pipeline ignored third-party deployment CI failures in the review agent. The current review workflow separately chose to use gh aw checks output for CI verdicts. Both are consumer-side workarounds, not fixes in gh-aw.

Source-level verification (2026-03-01, main at 2d91393f3):

• Confirmed pr_automerge.go:93 rejects UNSTABLE with no option to override
• Confirmed create_pull_request.cjs:881 delegates to GitHub auto-merge with no check evaluation
• Confirmed classifyCheckState() does not filter external deployment statuses — any non-policy failure is marked failed
• Confirmed no merge decision path uses gh aw checks, mergeStateStatus, or statusCheckRollup

Proposed fix

Add a mechanism to ignore non-required third-party deployment statuses in gh-aw's auto-merge gating. Possible approaches:

1. Allow pr_automerge.go to accept UNSTABLE when all required status checks pass (query statusCheckRollup or required status checks separately)
2. Add a configuration option to specify which commit status contexts should be ignored for merge gating (e.g., vercel/*, netlify/*)
3. Integrate classifyCheckState() into merge decisions, with an additional filter for external deployment contexts

Impact

Frequency: Affects repos that both have third-party deployment integrations (Vercel, Netlify, Cloudflare Pages, etc.) posting commit statuses and rely on gh-aw's auto-merge gating when those statuses fail.
Cost: Medium — PRs stall until manual merge or consumer-side workaround. Forces workarounds that bypass gh-aw's intended auto-merge gating.