Stop pr_review.py Requesting Copilot on Feature Pull Requests into Develop #3758

Activity

1. ptr727

   added

   bugSomething isn't workingSomething isn't working

   scriptA defect in hub toolingA defect in hub tooling

   on Nov 1, 2026
2. ptr727 commented on Nov 1, 2026

   

   ptr727

   on Nov 1, 2026

   Last edited by ptr727

   OwnerAuthor

   More actions

   Released (2026-11-01): worktree and branch removed, so this claim holds no files. PR #3775 merged without fixing this issue. The repeated Copilot request comes from outside pr_review.py (see the evidence comment above), so this issue needs the maintainer.

   Backlog burndown claim (round 1, group G1). Branch: feature/burn-3758. Issues: #3758, #3571, #2180, #3732, #3713, #3726.

   Predicted file set:

   • scripts/pr_review.py, scripts/pr_review_rounds.py, scripts/pr_review_copilot.py, scripts/reviewers/copilot.json
   • tests/test_pr_review.py, tests/test_pr_review_copilot.py
   • .agents/skills/pr-review-conduct/SKILL.md and its generated trees (.github/skills/pr-review-conduct/, .claude-plugin/fleet-skills/skills/pr-review-conduct/, .claude-plugin/fleet-skills/.source-digests/pr-review-conduct)
   • drive-pr generated trees (included section), GOVERNANCE.md "PR Review Etiquette", .github/copilot-instructions.md
3. ptr727 commented on Nov 1, 2026

   

   ptr727

   on Nov 1, 2026

   OwnerAuthor

   More actions

   Finding from the burndown worker on feature/burn-3758: the request does not come from pr_review.py, so no change to run_wait closes this.

   • run_wait already requests nothing on a pull request into a non-default branch, attested or not. It requests only under --request, a partial round on record, or a truncated review history. test_a_feature_pull_request_with_no_round_is_never_requested pins the no-attestation case.
   • On each of seven recent feature pull requests into develop (Place a Copilot Outstanding Findings List and Read a Table Leaving Out Only Lineless Files as Covering #3702, Merge a Gate-Met Feature Pull Request Through pr_review.py and Own the Kit's autoMode Entries #3704, Read a Push's Remote and Branch in the Repository Git Uses in the Write Guard #3709, Keep a Bare Push's Branch Unresolved Behind an Unrecognized env Option in the Write Guard #3731, Add an Away Mode to backlog-burndown and Retire unattended-handoff #3735, Read a Closed Read-Back as Unmerged in pr_review.py merge #3737, Improve decision-triage From Its First Full Run #3760), the review_requested event for Copilot lands one to two seconds after the pull request's createdAt. That is before any driver could run wait, and it lands once per pull request.
   • The develop ruleset carries no copilot_code_review rule. The main ruleset does.
   • Read Copilot's Excluded-Files Refusal as Its Own Kind and Align Merge Gate Item 2 #3775, opened by this worker, got the same request two seconds after creation, before the worker had run any pr_review.py command on it.

   So the request comes from GitHub when the pull request is created. The likely source is the account-level Copilot setting that automatically requests a review on every pull request the account opens. That setting is not visible through the API, and changing it is the maintainer's call. Turning it off would leave promotions covered by the main ruleset's own Copilot rule. This issue stays open for that decision rather than closing on a code change.
4. ptr727

   added a commit that references this issue on Nov 1, 2026

   Read Copilot's Excluded-Files Refusal as Its Own Kind and Align Merge…

   ...

   c24836e
5. ptr727 commented on Nov 2, 2026

   

   ptr727

   on Nov 2, 2026

   OwnerAuthor

   More actions

   Decision triage: researched question

   A Copilot review request lands on every feature pull request into develop one to two seconds after creation, before any pr_review.py command runs. Should the maintainer turn off the GitHub-side setting that sends it, or should this issue close with the code as it is?

   Options, recommended first:

   1. (Recommended) Turn off the account-level automatic Copilot review, then close Stop pr_review.py Requesting Copilot on Feature Pull Requests into Develop #3758 once a feature PR shows no Copilot request. run_wait on main already requests nothing on a PR into a non-default branch, and the develop ruleset has no copilot_code_review rule. The main ruleset's rule (review_on_push: false) still gives one review per promotion, which is the "once per change, at the promotion" rule. The setting cannot be read through the API, so the check is that the next feature PR shows no review_requested event. It also stops auto-review on PRs this account opens outside the fleet. No code work in flight.
   2. Keep the setting, close Stop pr_review.py Requesting Copilot on Feature Pull Requests into Develop #3758 as not a code defect, and change the rule text to accept a Copilot round on feature PRs. No settings change. It gives up the cost cut Run Copilot Review Once per Change at the Promotion #3403 was for, and the pr-review-conduct and drive-pr text saying "once per change, at the promotion" stays false in practice.
   3. Keep the setting and have tooling remove Copilot's pending request right after each PR is created. Adds a write to every PR, races a review that may already have started, and fights the platform rather than fixing the source.

   Evidence: #3758 (comment) (seven PRs, request 1-2s after createdAt); #3792, #3793, #3796, #3798, #3799 each show a Copilot review_requested event 1-2s after creation, base develop; develop ruleset has no copilot_code_review rule, main ruleset carries it with review_on_push: false; scripts/pr_review.py:1551 (run_wait) and tests/test_pr_review.py:4939 on main; #3403 (96d1396); #3775; #3391 (comment). The account-level source is inferred from timing and actor, since the API cannot show that setting.

   Blocks: none. Option 1 is a settings change only the maintainer can make.
6. ptr727

   added

   decisionA question waiting on the maintainer, alone or beside whatever else the issue carriesA question waiting on the maintainer, alone or beside whatever else the issue carries

   on Nov 2, 2026
7. ptr727 commented on Nov 2, 2026

   

   ptr727

   on Nov 2, 2026

   OwnerAuthor

   More actions

   Maintainer answer (2026-11-02, via decision triage): the maintainer turns off the account-level automatic Copilot review.

   No code change. With that setting off, a feature PR into develop gets no Copilot request unless pr_review.py runs with --request, and a promotion PR into main gets one review from the main ruleset at open, with pr_review.py wait requesting the follow-up rounds on new heads. Remaining work: confirm the next feature PR into develop shows no Copilot review_requested event, then close this issue.
8. ptr727

   removed

   decisionA question waiting on the maintainer, alone or beside whatever else the issue carriesA question waiting on the maintainer, alone or beside whatever else the issue carries

   on Nov 2, 2026
9. ptr727 commented on Nov 2, 2026

   

   ptr727

   on Nov 2, 2026

   OwnerAuthor

   More actions

   Maintainer answer (2026-11-02, given in the backlog-burndown session, recorded by the orchestrator):

   copilot on auto review is still in use by otehr agents using the existing workflow, if i turn it off now that work will break, copilot's auto review being disabled should be scheduled along with possibly the auto review disabled for coderabbit and quodo at the same time so that the nbehavior to require explicit bot reivews is consistent and can be gated across the fleet and otehr running agents.

   What this means for the work:

   • Do not turn off the account-level Copilot automatic review on its own. Other agents still depend on the existing workflow.
   • Schedule the cutover instead: one moment at which automatic review is turned off and explicit bot review requests become the required behaviour. A gate makes that behaviour consistent across the fleet and across running agents.
   • Turning off automatic review for CodeRabbit and Qodo at the same time is possibly part of the same cutover. That part is not decided yet.

   So this issue is not waiting on a single setting toggle. It needs a coordinated cutover plan, and the settings change comes last. The next backlog-burndown planner decides which in-repo preparation can be worked now and files the open CodeRabbit/Qodo question as a decision.
10. ptr727 commented on Nov 2, 2026

    

    ptr727

    on Nov 2, 2026

    OwnerAuthor

    More actions

    Maintainer answer, follow-up (2026-11-02, given in the backlog-burndown session, recorded by the orchestrator). This settles the part the previous comment left open:

    the auto review for bots should be consistent, be that for copilot or quodo or coderabbit, i am using the free for open source versions of coderabbit and quodo so there is no cost factor, while i do pay for copilot, the bot review workflow should be consistent, so scratch that "possibly" and make that "consistncy required"

    What this settles:

    • Consistency is required, not optional. Copilot, CodeRabbit and Qodo follow the same review workflow.
    • One scheduled cutover turns off automatic review for all three. From then on, explicit review requests are the required behaviour, gated the same way across the fleet and across running agents.
    • Cost is not a reason to treat them differently. CodeRabbit and Qodo are on their free open-source plans, and the maintainer pays for Copilot, but the workflow is the same for all three.

    There is no open CodeRabbit/Qodo question left to file as a decision.
11. ptr727 commented on Nov 2, 2026

    

    ptr727

    on Nov 2, 2026

    OwnerAuthor

    More actions

    Held back by the backlog-burndown away run (2026-11-02, round 3), re-judged against the maintainer's answers above.

    • Held as reaching past the tree: turning off automatic review for Copilot, CodeRabbit, or Qodo, and any change to current review behaviour before the cutover.
    • Undetermined: the cutover's trigger, schedule, and the in-repo switch and gate that make explicit requests required. This is filed as decision Decide: How the Coordinated Cutover to Explicit Bot-Review Requests Is Triggered, Scheduled, and Gated #3826, with a recommended answer. CodeRabbit and Qodo inclusion is settled and is not asked again.
    • No preparation dispatched this round. The only in-repo preparation found, an explicit CodeRabbit and Qodo request in scripts/pr_review.py and a switch keyed gate, depends for its interface on how Decide: How the Coordinated Cutover to Explicit Bot-Review Requests Is Triggered, Scheduled, and Gated #3826 is answered. So it waits for that answer rather than landing an interface the decision could change.
12. ptr727 commented on Nov 3, 2026

    

    ptr727

    on Nov 3, 2026

    OwnerAuthor

    More actions

    Maintainer answer on #3826 (decision triage via the windows handoff #3853, 2026-11-03): Option 1: land behaviour-neutral preparation behind one hub-hosted switch and release it, then flip everything in one maintainer-chosen window when no session is mid-drive. The preparation can be dispatched as its own group. The settings changes and the switch flip stay with the maintainer, and this issue stays held until the cutover.