GH#18538: gate review-followup issues on human triage (complement to #18607)#18610
Conversation
Completion Summary
|
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 24 minutes and 51 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report SonarCloud: 0 bugs, 0 vulnerabilities, 226 code smells Mon Apr 13 04:43:01 UTC 2026: Code review monitoring started 📈 Current Quality Metrics
Generated on: Mon Apr 13 04:43:04 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
Up to standards ✅🟢 Issues
|
…triage (GH#18538) PR #18607 made review-followup issue bodies worker-actionable (file:line refs, full bot bodies, Worker Guidance), but rich body context cannot rescue a finding whose factual premise is wrong. The original GH#18538 was triggered by a Gemini comment claiming the TODO.md "Ready" section is auto-generated (it is not — todo-ready.sh is read-only). Workers reading even a perfectly-mentored body would still chase a false premise. This PR adds a `needs-maintainer-review` label by default at issue creation time, gating worker auto-dispatch until a human verifies the bot's premise. The triager picks one of three paths (accept/reject/modify-scope), each documented in a new "Triage required" preamble in the issue body. Together with #18607 this turns 0 wasted dispatches per false-premise finding (instead of GH#18538's 2 dispatches → t2008 escalation → manual intervention). Configurable via SCANNER_NEEDS_REVIEW env var (default true). Set to "false" to allow direct dispatch for trusted-finding pipelines. Resolves #18538
1bf1e9b to
df29d57
Compare
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report SonarCloud: 0 bugs, 0 vulnerabilities, 226 code smells Mon Apr 13 04:50:48 UTC 2026: Code review monitoring started 📈 Current Quality Metrics
Generated on: Mon Apr 13 04:50:51 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
Completion Summary
Merged via PR #18610 to main. aidevops.sh v3.8.6 spent 44m on this as a headless bash routine. |



Summary
Follow-up to PR #18607 (worker-actionable bodies). #18607 made review-followup issue bodies rich and structured but did not address the upstream root cause of GH#18538: bot findings can have false premises that no amount of body context rescues.
The original #18538 was triggered by a Gemini comment claiming TODO.md's
## Readysection is auto-generated by/readyorbeads-sync-helper.sh. I verifiedtodo-ready.shis read-only — the section is not auto-generated. Workers reading even a perfectly-mentored body would still chase a false premise. Two sonnet workers tried it, both stale-recovered, and the issue ended up at the t2008 escalation path (needs-maintainer-review) anyway — after burning 2 dispatches.This PR moves that human triage gate upstream to issue creation time:
SCANNER_NEEDS_REVIEWenv var (defaulttrue)create_issueappliesneeds-maintainer-reviewlabel up-frontTogether with #18607 (rich bodies) this turns 0 wasted dispatches per false-premise finding instead of GH#18538's 2.
Files Changed
.agents/scripts/post-merge-review-scanner.sh— env var, label-list construction increate_issue, triage preamble inbuild_pr_followup_body.Runtime Testing
bash -nparse OK; isolated body-builder smoke test against stubbedfetch_*_mdhelpers renders the new preamble correctly between Source PR and Worker Guidance sections.Why this isn't in #18607
#18607 was already merged when I finished my analysis. Both PRs target the same issue but address different layers of the same failure mode:
needs-maintainer-reviewby defaultBoth are needed. The #18607 author may have considered gating but chose not to add it; this PR makes that decision explicit and the rationale durable in the script's header comment.
Resolves #18538