[rudycelekli]

GitHub reports mergeable: UNKNOWN for a while after a push or after the base branch moves, because it recomputes the merge in the background. watch-pr only treats CONFLICTING (or a DIRTY merge state) as a conflict, so a PR whose checks and threads are clean but whose mergeability is still UNKNOWN gets a terminal READY with proof.mergeability: "clear". In --stack mode the whole stack clears the same way, and in --queued-stack mode the frontier gets the merge-queue wait that the babysit playbook treats as merge-ready. The playbook defines ready as "the forge agrees the PR can merge", but at that point GitHub has not decided yet, and a PR that turns out to conflict gets reported as merge-ready and the watcher stops.

Single and stack decisions now return a computing-mergeability decision for an otherwise clean open PR whose mergeable is UNKNOWN. It is checked after blockers and pending checks, so conflicts, threads, failing checks, gates and pending CI keep their current precedence. runSimple emits a non-terminal WAITING with reason mergeability-unknown and polls again on the usual interval. At the deadline it returns TIMEOUT with that reason instead of guessing. The queued frontier wait reports mergeability-unknown instead of merge-queue for the same state. --pretty renders both reasons. The CI truth table for mergeStateStatus: UNKNOWN is unchanged.

Validation: the new watch-pr/mergeability.test.ts covers single mode (wait, then READY once GitHub settles), the deadline timeout, a stack with one PR still computing, and a queued frontier. All four tests fail on origin/main and pass with this change. bun run typecheck passes, and the watch-pr suite passes except requests and parses fork identity from gh before stack discovery, which hits a 2s spawnSync timeout on this machine and fails the same way on origin/main. node scripts/generate-pstack-harness-trees.mjs --check, node scripts/validate-plugins.mjs and git diff --check pass.

---

Note

Medium Risk
Changes when automation declares PRs merge-ready across single, stack, and queued modes; incorrect behavior could still stop watchers early or delay merges, but scope is limited to watch-pr polling logic.

Overview
Fixes a false READY when GitHub still has mergeable: UNKNOWN after a push or base update—checks and reviews can look clean while mergeability is still being recomputed.

Single/stack decisions now treat that state as computing-mergeability (after blockers and pending CI). The watcher emits non-terminal WAITING with mergeability-unknown, keeps polling, and on timeout returns TIMEOUT instead of claiming merge-ready. Queued-stack frontiers use the same wait reason rather than a merge-queue wait that implied readiness.

Types, queue evaluation keys, and --pretty output were extended for the new reason; mergeability.test.ts covers wait→ready, timeout, stack hold, and queued frontier behavior.

^{Reviewed by Cursor Bugbot for commit 99ce4e3. Bugbot is set up for automated code reviews on this repo. Configure here.}