Detect merge conflicts on idle PRs when the default branch moves #2416

Follow-up to #2303. Its fix (#2302) checks mergeability only after Junior pushes to a PR branch. #2303 lists this as an accepted gap: a conflict caused by the default branch moving while the PR is idle is not detected.

This happened: #2374 got conflicts after #2373 and #2375 merged to main. Junior was maintaining the PR, but did not notice. The PR stayed conflicted until a person pointed it out.

Why no event fires:

• GitHub sends no webhook when a PR becomes unmergeable.
• pull_request workflows do not run on a conflicted PR, so pull_request.checks.failed never fires.
• The PR watch events (failed checks, comments, reviews, merge or close) all stay quiet.

Goal: while Junior maintains an open PR, a conflict caused by the default branch moving is detected and resolved by the existing #2302 flow (merge the default branch, never rebase, keep both sides, rerun checks, push, report the conflicted files).

Options to evaluate:

1. Read mergeability whenever PR maintenance handles any event for that PR. Cheap, but misses PRs that get no events at all.
2. On a push to the default branch, read mergeability only for open PRs that have an active maintenance watch. Detect and resolve merge conflicts on Junior's PRs #2303 rejected push webhooks as too noisy, but filtering to watched PRs may remove that cost.
3. A periodic check of watched open PRs. Simple, but adds delay and polling.

Option 1 is a likely first step either way. This should also settle the open question from #2303: whether the mergeability check belongs in a tool or runtime step in packages/junior-github instead of prose in the github-code skill (policies/agent-steering.md).

Done when: a watched, idle bot PR that gets a conflict from a default-branch merge is detected without a person reporting it, and an integration test covers that path.

Related: #2302, #2303

via David Cramer.

--

View Session [Sentry]