[sentry-junior]

When a PR in a gh stack stack merges, GitHub tries to rebase the next PR onto the trunk. If that rebase hits a conflict, the PRs above it stay stuck, and nothing tells Junior. GitHub sends no webhook for a new conflict, and a conflicted PR gets no new checks.

The watch Junior creates after it opens a PR already gets pull_request.merged. That guidance now checks GET /repos/{owner}/{repo}/stacks?pull_request=N first. If open PRs remain above the merged one and Junior pushed their branches, Junior restacks them before it replies (gh stack checkout + gh stack sync). On a conflict, it runs gh stack rebase, resolves the conflict, continues, runs the checks, and pushes. This applies only to that watch, so user watches and event automations on pull_request.merged don't pick up side effects.

pull_request.merge_conflict guidance and the github-code workflow used to always say "merge the base, never rebase." A stack can merge only with a linear history, so a merge commit blocks it. Stacked PRs now restack with gh stack rebase. Non-stacked PRs still merge the base.

Known gaps:

• Only guidance changed here. No eval covers the restack path yet, because that needs a gh stack fixture with a remote stack.
• If a human opens the bottom PR and Junior's PR sits above it, Junior doesn't watch the bottom PR. Junior then finds the conflict only from the next event on its own PR.
• Plain base-branch chains that aren't linked with gh stack aren't handled.

via @BYK.

--

View Session in Sentry

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
junior-docs	Ready	Preview	Nov 3, 2026 10:42am UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ab5bc31. Configure here.}