Ask cubic for a review when the intake gate lets a PR back in
When the intake gate lets a pull request back in, it now leaves one @cubic-dev-ai review this PR comment so cubic reviews it.
Motivation and Context
cubic starts a review on opened, and the gate closes an unlinked external PR about 13 seconds later, at which point cubic abandons the run ("AI review cancelled"). cubic doesn't act on reopened, so when that PR later comes back (the author gets assigned to the issue, fixes the description, or a maintainer reopens it or adds bypass-issue-check) nothing triggers a review until the next push. #3413 is an example: closed by the gate one second after cubic started, reopened with the bypass label, head unchanged, and it never got a cubic review.
Every route back to open goes through pass() while the PR still carries missing-issue-link, and that label is removed right there, so it's the one place that runs exactly once per return. The request is posted from there. Drafts are skipped, since cubic reviews those by itself on ready_for_review and we don't want it reviewing drafts. The comment goes through mutate(), so the PR_GATE_ENFORCE=false kill switch covers it too.
How Has This Been Tested?
node --test '.github/scripts/*.test.js': the five existing "comes back open" scenarios now also assert that exactly one review request was left, and there are new assertions that none is left for a returning draft, for a PR GitHub refuses to reopen, or for a PR that stays closed. Those five scenarios fail against the old script and pass with the change.
One thing this can't test from here: whether cubic honours a @cubic-dev-ai mention written by github-actions[bot]. Their docs describe the mention as working for anyone commenting on the PR (an outside contributor's own summon worked on #3347) but say nothing about bot authors. The comment webhook does reach the cubic app regardless of who wrote it. If cubic turns out to ignore it, the fallback is a maintainer typing the same comment, and this can be reverted; the first PR that comes back after merge will show which.
Breaking Changes
None.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to change)
- Documentation update
Checklist
- I have read the MCP Documentation
- My code follows the repository's style guidelines
- New and existing tests pass locally
- I have added appropriate error handling
- I have added or updated documentation as needed
Additional context
A PR that returns because a maintainer manually reopened it also gets the comment, even if cubic had somehow finished a review before the gate closed it (only possible for PRs gated after the fact by a manual dispatch). A second review there seemed better than special-casing it.