feat(2114): a missing Bugbot review is a finding, not a clean PR

[LukasWodka]

Closes backend#2114.

The failure, measured

Cursor Bugbot's auto-trigger silently drops PRs. On 2026-08-17, five open PRs across three repos carried no Cursor Bugbot check at all, while PRs opened minutes before and hours after were reviewed normally.

No discriminator survived:

hypothesis	counter-example
diff size	1-file/66-line PR reviewed; 1-file/29-line PR not
file type	two 3-file Go diffs, same repo — one reviewed, one not
repo	three repos affected, each with reviewed PRs too
time	cli#521 10:54 absent, client#738 10:55 present
quota	PRs opened hours later reviewed fine
author / draft	all human, all non-draft

Posting bugbot run started a review within a minute and both came back clean. The reviews were not failing — they were never starting.

Why it belongs in this watcher specifically

bricked-prs.py's own header already makes the argument:

A required status check that never reports... is the one CI failure mode with NO red signal at all — nobody is notified, and no reviewer sees a problem, because there is no failure, only an absence. So it needs a watcher; nothing inside a PR can detect it.

That describes this bug exactly, one class over — checks then, the reviewer now.

A per-PR required check would be the wrong shape: it would sit pending for the minutes Bugbot legitimately takes, and a check that is pending-by-design is precisely what this repo refuses to ship.

Four rules, each earned from the measurement

• A skipped Bugbot counts as present. It ran and decided; that is a verdict. Only total absence is the silent drop.
• Bot authors are exempt, keyed on GitHub's [bot] suffix rather than a hand-kept list that would go stale. dependabot[bot]'s absence was the one legitimate case in the sample.
• Same young-head rule as the required-check case, and an unreadable age reads as young — a false finding is what makes a report ignorable.
• Reported even when every required check is present, because that is exactly the case that renders as a completely clean PR.

Its own label, and this is the part I nearly got wrong

The renderer sent anything not conflicted to BRICKED. A missing review is not a bricked PR — the PR merges perfectly well. Labelling it BRICKED would send the reader to branch protection for something one comment fixes: the same true-count-false-name defect this file already avoids for conflicted.

It now renders as UNREVIEWED, names bugbot run as the remedy, and the summary says the quiet part:

a bricked PR cannot merge; an unreviewed one merges perfectly well, which is the worse of the two.

That rendering is asserted from the source, because it lives in main() and no decision-table case reaches it.

Verification

Six mutations, all caught:

mutation	result
the Bugbot check removed	2 fail
bot exemption disabled	1 fail
young-head guard dropped	1 fail
cause collapsed into never-reported	2 fail
label collapsed to BRICKED	1 fail
remedy text removed	1 fail

bricked-prs selftest 21 passed (was 14) · make selftests41 passed · actionlint clean.

The default PR fixture now carries a Bugbot row, so a normal PR is the baseline and absence has to be constructed deliberately — otherwise every existing case would trip the new finding and the two would be untestable apart.

---

Note

Low Risk
Changes are confined to the offline bricked-PR audit script and its selftests; behavior is heavily specified in tests with no production runtime or auth surface.

Overview
Extends bricked-prs.py so PRs with no Cursor Bugbot check are surfaced even when all required status checks are green—addressing silent auto-trigger drops (backend#2114).

Bugbot detection: Fetches author on PR list; flags human PRs missing the Bugbot context after the same 60-minute head-age grace. Bot authors are exempt via author.is_bot (not login suffix). bugbot-absent is reported separately from missing required checks, including on branches with no required checks (removed early continue on empty protection).

Audit loop: Classifies unreviewed / missing before head_age_minutes so healthy PRs pay zero age API calls and dual findings share one lookup. Undateable heads emit COULD NOT AUDIT errors instead of silent young skips. rollup_truncated (≥100 rollup entries) refuses audit only when an absence would be reported—not for healthy PRs at the cap.

Output: CLI/GitHub summary use UNREVIEWED (not BRICKED) and print bugbot run as the fix. Selftests grow coverage for bot exemption shape, lookup counts, rollup pagination, and rendered remedy text.

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

[saadqbal]

The is_bot fix in 7c7d9ae is right — I'd independently confirmed app/dependabot on backend and cli before you pushed it, and keying on the field rather than the login form is the correct call. Polarity and the young-head rule read fine, and Cursor Bugbot is the exact check-run name in the rollup (verified on this PR and on cli/backend), so detection is anchored on the real thing. Two things left, below.

One more that isn't on a diffed line: gh fetches at most 100 rollup contexts and says nothing when it truncates. client#746 is already at 77 (81 check runs on the sha). Under the old polarity a truncated rollup gave a false BRICKED; under the new one it gives a false UNREVIEWED on a repo that's within ~20 checks of the cap — worth the same explicit refuse-rather-than-guess treatment you gave PR_LIST_LIMIT.

[LukasWodka]

Third finding addressed in 91b0e5b — you were right that it deserved the same treatment as PR_LIST_LIMIT, and it is worse than that one because it fails in the direction this file exists to close.

Measured your client#746 number, and it needs a caveat. The rollup shows 77 contexts; REST reports 81 check runs on that sha. The gap is not truncation — the rollup is latest-per-context, so 81 runs collapsing to 77 names is correct. 77 distinct contexts is the real figure, and it is 23 from the cap.

The guard: at-or-over ROLLUP_CONTEXT_CAP = 100, the PR becomes an error naming it and saying it was NOT audited, and is skipped before either check. >= rather than > because at exactly 100 there is no way to tell 100 contexts from 140, and "cannot tell" is a finding.

Where I could not derive it. The constant is gh's page size, not something I observed failing — I could not construct a >100-context head. That is said plainly in the comment rather than dressed up as a measurement. What I could do is make the branch provably reachable: the selftest builds a synthetic 100-context rollup, and the fixture is deliberately shaped so that without the guard it produces two findings (bugbot-absent + never-reported), both confident and both false. A pass there cannot come from the scenario being harmless.

Mutation-proved three ways, each reddening the suite: guard removed (27/2), >= → > (27/2), cap zeroed (18/11). The last one is what keeps the boundary meaningful — without the one-under-cap test the guard could be >= 0 and the first test would still pass.

make check green, 41 selftests.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

1 issue from previous review remains unresolved.

Comment @cursor review or bugbot run to trigger another review on this PR

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

[LukasWodka]

@saadqbal re-requesting review — your CHANGES_REQUESTED predates the fix, so this reads as blocked when it isn't.

Timeline: your review landed 2026-08-18 14:33Z; the third finding (the rollup page-size guard) was pushed in 91b0e5b afterwards. Current head 4366ecf:

every check	green — gate, audit, selftest, selftests, actionlint, all five quality/*
Cursor Bugbot	NEUTRAL (terminal, no findings)
unresolved threads	0

All three findings addressed: the is_bot fix you'd independently confirmed, the empty-required-set continue that made a missing review structurally unreportable on the least-protected branches, and the rollup truncation guard. One correction to your client#746 figure, on the thread: the rollup shows 77 distinct contexts, not 81 — the rollup is latest-per-context, so 81 check runs collapsing to 77 names is correct rather than truncation. 77 is still 23 from the cap, so the finding stands.

This one is also now on the critical path: #284 (the last of the 19 add-to-kanban repos) is open, and the #1979 stale-backlog reusable branch was cut from this branch — so its diff isn't clean until this merges.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[LukasWodka]

@saadqbal — the rollup-truncation gap you flagged is closed in 4366ecf: a rollup at gh's 100-context page size is now classified UNKNOWN — an error that names the PR and keeps it out of the findings table — the same refuse-rather-than-guess treatment PR_LIST_LIMIT gets one level up. A context paginated away is indistinguishable from one that never ran, so under the new polarity it would give a false UNREVIEWED, failing open in exactly the direction this watcher exists to close. Measured client#746 at 77 contexts, 23 from the cap. The selftest builds a synthetic 100-context rollup and is mutation-proved three ways: remove the guard, flip >= to >, zero the cap.

The other points are in: is_bot keyed on the field not the login form (7c7d9ae), reviewer check no longer gated on branch protection (31ecc2c), classify-first-then-date-the-head (6bf6eac). CI green, Bugbot clean on the head. Re-requesting your review to clear the change request.

[saadqbal]

Re-derived the control flow at 6bf6eac rather than spot-checking the fixed case, and "classify first, date the head after" is the right shape — one lookup for a candidate, none for a healthy PR, no cached flag to go stale, and nothing left over from the young hoist. Every cell I walked lands where it should: zero-required + human + no Bugbot + old head reports bugbot-absent; zero-required + Bugbot present stays quiet and costs no API call; a bot PR is still bricked-checked for required contexts; a skipped Bugbot still counts as present, since present_contexts reads names and ignores conclusions; missing = ... if required else [] keeps the required block from firing on an empty set. The one PR that produces two findings (missing review + missing check) already did before and the suite asserts it deliberately, so it is not new double-reporting. Detection is unchanged and still keys on the Cursor Bugbot check-run name in the rollup, not the cursor review author.

Ran the suite off the PR head: 33 passed. Deleting the fix: comment ... print now reddens it (32 passed, 1 failed), so the remedy assertion is genuinely anchored to the printed line this time.

One blocking thing on the truncation guard, below. Three smaller notes that aren't on diffed lines:

• head_age_minutes's docstring at line 220 still says "the caller treats an undateable head as young and skips". 6bf6eac made that false — the caller now turns None into an error. Same class of stale statement you fixed one paragraph up in this push.
• The module exit-code contract at lines 49-51 is now stale in both directions: 1 is no longer only "bricked", and 2 now covers a truncated rollup and an undateable head, not just "an unreadable repo, branch, or PR list".
• The fork / docs-only escape hatch I raised last round isn't addressed by this push. Bugbot doesn't run on fork PRs, and the public repos can get them, so those land as UNREVIEWED with no override. Still not a blocker — just noting it hasn't silently dropped off the list.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[aptracebloc]

Approving at 83d8020. The guard move is correct and its reasoning holds.

The change:rollup_truncated(pr) moved from above the classification to below it. Three consequences, all good:

• A healthy PR at the 100-context cap is now silent instead of an error. That closes a real operational problem: main() returns 2 on any non-empty errorsbeforereturn 1 if findings, so a single healthy big-rollup PR anywhere across the 19 repos turned every four-hourly run into "could not evaluate" and demoted genuine findings to a second-class exit code.
• The refusal message can now name which absence is uncertain, which is also what makes the old placement structurally impossible — above the classification, unreviewed is undefined.
• Refused PRs now cost zero age lookups.

The monotonicity argument is sound.present_contexts only ever shrinks under truncation, so missing = required - present only grows and unreviewed only becomes more likely true. Both can be falsely TRUE, never falsely false, so healthy-on-partial genuinely implies healthy-on-full.

I reconstructed the module and ran it: 34 passed, and reproduced the commit message's mutation table exactly — guard back above classification → 33/1, guard removed → 32/2, >=→> → 32/2. Also re-probed the still-running-Bugbot case across QUEUED/null, IN_PROGRESS, SKIPPED, FAILURE, NEUTRAL and a legacy PENDING status: all produce zero findings, only true absence fires bugbot-absent. No false finding on a fresh PR.

Non-blocking, but the last one is worth taking before merge

The PR body. It becomes the merge commit message, and it now contradicts itself. Still says bots are exempt "keyed on GitHub's [bot] suffix" while the Cursor summary in the same body correctly says author.is_bot "not login suffix"; still says "an unreadable age reads as young", which is now reversed; still describes "Four rules" and never mentions the truncation cap, COULD NOT AUDIT, or classify-first. And every count is stale — the file has 34 tests against a claimed 21, and I measured the mutation numbers: young-head guard dropped → 3 fail (body: 1), bot exemption disabled → 2 (body: 1), cause collapsed → 6 (body: 2).

The boundary test doesn't pin the boundary (scripts/tests/bricked-prs-selftest.py:330-338). It's commented "One under the cap" and framed as "what makes the boundary mean something", but builds ROLLUP_CONTEXT_CAP - 2 contexts — 98, two under. Verified: mutating the comparison to >= CAP - 1 gives 34/34 green, and >= CAP - 2 also gives 34/34 green. Someone tightening the cap by one turns every 99-context PR into a permanent COULD NOT AUDIT → exit 2, with the suite fully green. One-character fix: build CAP - 1 fillers.

Three stale contracts still standing from my earlier pass, all in the class of thing this PR is about:

• bricked-prs-selftest.py:178-180 — comment says the exemption is keyed on the [bot] suffix; the code keys on is_bot, and the case two lines down asserts the login form is not what exempts.
• bricked-prs.py:220 — head_age_minutes's docstring still ends "the caller treats an undateable head as young and skips"; the caller errors and reports NOT audited.
• bricked-prs-selftest.py:109-113 — case 3 passes for a different reason than it documents. Proved inert: reverting age is None to a silent continue fails only the dedicated test at :294; case 3 stays green. not f and len(e) == 1 fixes it, or delete it as superseded.

Smaller: the GITHUB_STEP_SUMMARY line at :517 still says only "No PR is missing a required context" while stdout says "or a review" — the Actions summary under-claims what was audited. LABELS is still local to main(), so a change to the dispatch key alone leaves both source-greps green while nothing renders (hoisting it and asserting bp.LABELS[f[0]["cause"]] == "UNREVIEWED" against a real finding closes it). The ROLLUP_CONTEXT_CAP comment still names no operator escape hatch for a genuinely-sick PR stuck above the cap. And there's a stray double blank line at :294-295 where the guard was cut out — ruff doesn't select E3, so nothing catches it.

For the record on review state: the CHANGES_REQUESTED currently showing is @saadqbal's second review, filed 11:52:44Z against 6bf6eac — a live ask at the time, answered by this commit four minutes later. Not the 08-18 review persisting. All 7 threads are resolved.

— drafted with Claude Code

[LukasWodka]

/fr-pass

Best-effort FR passed (triage; behavioral evidence limited while e2e journey red — backend#2206). Advancing to Ready for prod.