[rudycelekli]

A poteto-mode babysit or watch session stops when watch-pr says READY, and in queued mode it treats a blocker-free WAITING whose reason is merge-queue as merge-ready too. GitHub's mergeStateStatus BEHIND means the head ref is out of date: the branch is behind its base and GitHub refuses the merge until the branch is updated. conflictBlocker only treats CONFLICTING and DIRTY, so a pull request with green checks and no review threads is reported READY, and a queued frontier is reported merge-queue, while the merge is still blocked.

An open pull request whose merge state is BEHIND, and whose checks are not still pending, now waits instead of becoming ready. Single and stack watches emit WAITING with reason branch-behind and, at the deadline, TIMEOUT with that same reason. A queued frontier does the same, so the babysit loop does not treat it as merge-ready. Conflicts, review threads, failing checks, draft and changes-requested gates, and pending CI keep their current precedence. UNSTABLE and UNKNOWN merge states are unchanged.

Validation: on origin/main, watch-pr/behind.test.ts fails. A clean-CI, no-thread BEHIND pull request is READY, a stack of them is READY, and a queued frontier waits as merge-queue and times out as queued-stack. After this change those cases wait and time out as branch-behind, and a single pull request becomes READY only once GitHub no longer reports BEHIND. UNSTABLE and UNKNOWN merge states still report READY. bun test watch-pr passes (60), bun run typecheck passes, node scripts/validate-plugins.mjs passes, node scripts/generate-pstack-harness-trees.mjs --check passes, and git diff --check passes.

Made with Cursor

---

Note

Medium Risk
Changes merge-readiness logic in poteto-mode’s PR babysit loop; wrong handling could still stop too early or wait too long, but scope is limited to watch-pr policy and rendering.

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