Read Copilot's Excluded-Files Refusal as Its Own Kind and Align Merge Gate Item 2

.agents/skills/pr-review-conduct/SKILL.md

@@ -54,6 +54,8 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    whose own file table names exactly the changed files covers it, `coverage=table`. That is the
    reading a Copilot round at Balanced review effort gives. Where no round covering the head carries a table of its own, the newest round
    that does stands in as `coverage=carried:table`. Its table has to name exactly the changed files.
+   Either table may leave out an added, modified, or deleted file with no changed line, such as a
+   binary. That holds while some changed file has one.
    A table stands in only where no Copilot round on the pull request, on any commit, states
    partial coverage. So a pull request that ever had a partial round goes to the maintainer.
    `coverage=none` and `coverage=UNKNOWN` leave this item unsatisfied and decide no exit code,
@@ -67,13 +69,17 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    `other_reviewed`, with an empty review body and no new threads, is not a missing review. It is
    its own ordinary "reviewed, nothing to flag" shape.
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
-   it where it can. A file-count refusal is cleared by splitting the pull request, which is the
-   only cause on record that the loop can clear. `pr_review.py wait` exits `41` on every refusal
-   and quota state, its `status=` line naming which. The digest's `refusal=` field carries a
+   it where it can. A file-count refusal is cleared by splitting the pull request. A refusal saying
+   every changed file is in Copilot's default review exclusions says nothing about the content, and
+   no round follows it. On a pull request into a branch other than the default, the attested local
+   pass covers that head. Where none can, it goes to the maintainer, `wait` exiting `41` as
+   `REVIEW_EXCLUDED_FILES_ONLY`. `pr_review.py wait` exits `41` on every other refusal and quota
+   state no local pass covers, its `status=` line naming which. The digest's `refusal=` field carries a
    refusal on this pull request.
    `refusal=QUOTA` or `refusal=ERROR` means the pull request's newest Copilot review is an
    account-quota refusal or an error refusal read as a possible quota hit. That review can sit on
-   this head or an earlier one. Nothing the loop does clears it, which is the case "Which
+   this head or an earlier one. On a pull request into a branch other than the default, an attested
+   local pass on a later head clears it, `coverage=local`. Otherwise nothing the loop does clears it, which is the case "Which
    Reviewers a Repository Actually Has" below states. An error refusal whose `RUN LOG READING` line says
    transient is the exception. `wait` re-requests it once and exits `30` while that request is
    pending. A second error refusal in a row, or a re-request made with no round answering it,
@@ -237,11 +243,12 @@ must have done.
   step below is where a missing one is answered, on the terms stated there. A refusal naming the
   account quota is its own case rather than a review. So is one saying only that Copilot
   encountered an error, which is what the
-  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied. Nothing the
-  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied where no local pass
+  stands in. Nothing the loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
   reviewer's run log names a reset time `pr_review.py` reports it. Where it names a transient
-  fetch failure instead, `pr_review.py wait` re-requests once. Every other refusal, a repeat of
-  that one included, goes to the maintainer rather than into a wait.
+  fetch failure instead, `pr_review.py wait` re-requests once. Where no local pass stands in, every
+  other refusal goes to the maintainer rather than into a wait, a repeat of that one included. A
+  file-count refusal is the exception, since splitting the pull request clears it.
 
 The hub's `docs/pr-reviewer-reference.md` records what each reviewer does, what shapes it, and
 which repositories its plan covers. That is the record for a reviewer whose behavior still

.claude-plugin/fleet-skills/.source-digests/pr-review-conduct

@@ -1 +1 @@
-94139f992662a1b1
+0836f698ad11cc4b

.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md

@@ -54,6 +54,8 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    whose own file table names exactly the changed files covers it, `coverage=table`. That is the
    reading a Copilot round at Balanced review effort gives. Where no round covering the head carries a table of its own, the newest round
    that does stands in as `coverage=carried:table`. Its table has to name exactly the changed files.
+   Either table may leave out an added, modified, or deleted file with no changed line, such as a
+   binary. That holds while some changed file has one.
    A table stands in only where no Copilot round on the pull request, on any commit, states
    partial coverage. So a pull request that ever had a partial round goes to the maintainer.
    `coverage=none` and `coverage=UNKNOWN` leave this item unsatisfied and decide no exit code,
@@ -67,13 +69,17 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    `other_reviewed`, with an empty review body and no new threads, is not a missing review. It is
    its own ordinary "reviewed, nothing to flag" shape.
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
-   it where it can. A file-count refusal is cleared by splitting the pull request, which is the
-   only cause on record that the loop can clear. `pr_review.py wait` exits `41` on every refusal
-   and quota state, its `status=` line naming which. The digest's `refusal=` field carries a
+   it where it can. A file-count refusal is cleared by splitting the pull request. A refusal saying
+   every changed file is in Copilot's default review exclusions says nothing about the content, and
+   no round follows it. On a pull request into a branch other than the default, the attested local
+   pass covers that head. Where none can, it goes to the maintainer, `wait` exiting `41` as
+   `REVIEW_EXCLUDED_FILES_ONLY`. `pr_review.py wait` exits `41` on every other refusal and quota
+   state no local pass covers, its `status=` line naming which. The digest's `refusal=` field carries a
    refusal on this pull request.
    `refusal=QUOTA` or `refusal=ERROR` means the pull request's newest Copilot review is an
    account-quota refusal or an error refusal read as a possible quota hit. That review can sit on
-   this head or an earlier one. Nothing the loop does clears it, which is the case "Which
+   this head or an earlier one. On a pull request into a branch other than the default, an attested
+   local pass on a later head clears it, `coverage=local`. Otherwise nothing the loop does clears it, which is the case "Which
    Reviewers a Repository Actually Has" below states. An error refusal whose `RUN LOG READING` line says
    transient is the exception. `wait` re-requests it once and exits `30` while that request is
    pending. A second error refusal in a row, or a re-request made with no round answering it,
@@ -237,11 +243,12 @@ must have done.
   step below is where a missing one is answered, on the terms stated there. A refusal naming the
   account quota is its own case rather than a review. So is one saying only that Copilot
   encountered an error, which is what the
-  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied. Nothing the
-  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied where no local pass
+  stands in. Nothing the loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
   reviewer's run log names a reset time `pr_review.py` reports it. Where it names a transient
-  fetch failure instead, `pr_review.py wait` re-requests once. Every other refusal, a repeat of
-  that one included, goes to the maintainer rather than into a wait.
+  fetch failure instead, `pr_review.py wait` re-requests once. Where no local pass stands in, every
+  other refusal goes to the maintainer rather than into a wait, a repeat of that one included. A
+  file-count refusal is the exception, since splitting the pull request clears it.
 
 The hub's `docs/pr-reviewer-reference.md` records what each reviewer does, what shapes it, and
 which repositories its plan covers. That is the record for a reviewer whose behavior still

.github/copilot-instructions.md

@@ -28,7 +28,7 @@ For every review:
 
 The review automation is `scripts/pr_review.py`, run from a hub checkout. Use its `status`, `wait`, `attest`, `comment`, and `reply --resolve` commands instead of reconstructing GraphQL queries or copying review identifiers by hand. Use `comment` for a suppressed-finding answer in the pull request conversation. Its status gate verifies the current head, diff coverage, output shape, inline threads, body-only findings, and required checks.
 
-A formal review with no findings is complete only when it covers the current head. It also needs full diff coverage of the change set that head has, stated or read from a file table as below. A round covering the head states it. Where none does, a round covering the head whose own file table names exactly the changed files covers it. That is the reading a round at Balanced review effort gives. Where no round covering the head carries its own table, the newest round that does stands in where its table names exactly the changed files. A table stands in only where no Copilot round on the pull request, on any commit, states partial coverage. So a pull request that ever had a partial round goes to the maintainer. A round reporting partial coverage of the diff blocks the merge, and so does a refusal. So does a head that no coverage statement, file table, or attested local pass covers. So does an output shape the digest notes and nobody has read by hand, an unresolved thread, or a body-only finding. On a pull request into a branch other than the default, an attested local pass covers the head, `coverage=local` in the digest. A partial round, a truncated review history, or a refusal on the head still blocks that reading. A pull request into the default branch, a promotion among them, always carries a Copilot round on its head. Re-run the loop after every fix push. Never infer review completion from `mergeStateStatus: CLEAN`.
+A formal review with no findings is complete only when it covers the current head. It also needs full diff coverage of the change set that head has, stated or read from a file table as below. A round covering the head states it. Where none does, a round covering the head whose own file table names exactly the changed files covers it. That is the reading a round at Balanced review effort gives. Where no round covering the head carries its own table, the newest round that does stands in where its table names exactly the changed files. Either table may leave out an added, modified, or deleted file with no changed line, such as a binary. That holds while some changed file has one. A table stands in only where no Copilot round on the pull request, on any commit, states partial coverage. So a pull request that ever had a partial round goes to the maintainer. A round reporting partial coverage of the diff blocks the merge, and so does a refusal. So does a head that no coverage statement, file table, or attested local pass covers. So does an output shape the digest notes and nobody has read by hand, an unresolved thread, or a body-only finding. On a pull request into a branch other than the default, an attested local pass covers the head, `coverage=local` in the digest. A partial round, a truncated review history, or a refusal on the head still blocks that reading. A refusal saying every changed file is in Copilot's default review exclusions is the exception. A pull request into the default branch, a promotion among them, always carries a Copilot round on its head. Re-run the loop after every fix push. Never infer review completion from `mergeStateStatus: CLEAN`.
 
 Review effort is user-controlled. The automation observes `Lite`, `Balanced`, or `Max`, including an inherited `Default (<level>)`, and never selects or changes the setting. Effort does not determine coverage or completion. A request can complete without a `copilot_work_started` event, so absence of that event is not a stalled-review verdict. When `wait` returns `PENDING` with `requested=yes`, report the state and rerun `wait` for another bounded interval by default. Read that field as acceptance of the request rather than as delivery of a round. Do not clear the request on that first timeout, because it may still be active. Where a second bounded wait times out as well, read the pending set. In that case, clear it only where no human or team reviewer is requested alongside the bot, and rerun `wait`. That rerun then has nothing outstanding to defer to and requests afresh. Where it finds no reviewer node id to request with, it polls instead and says so on its own auto-request line. The clear replaces that set rather than adding to it, and nothing restores a request it drops. So a stall on a pull request that has a human or team reviewer requested goes to the maintainer. So does one still pending after the wait that follows a clear. That clear is a recovery step the script does not implement, and `docs/pr-reviewer-reference.md`, in the hub checkout the script is run from, carries it. This recovery replaces only the review request and never changes the effort setting. A `wait` ending `REQUEST_NOT_RECORDED`, exit 40, is a different state and takes none of this recovery. The request returned success and left neither a pending reviewer nor a review-request event. That is how an exhausted Copilot allowance has shown itself. So clearing and requesting again does not clear this state, and it goes to the maintainer.
 

.github/skills/pr-review-conduct/SKILL.md

@@ -54,6 +54,8 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    whose own file table names exactly the changed files covers it, `coverage=table`. That is the
    reading a Copilot round at Balanced review effort gives. Where no round covering the head carries a table of its own, the newest round
    that does stands in as `coverage=carried:table`. Its table has to name exactly the changed files.
+   Either table may leave out an added, modified, or deleted file with no changed line, such as a
+   binary. That holds while some changed file has one.
    A table stands in only where no Copilot round on the pull request, on any commit, states
    partial coverage. So a pull request that ever had a partial round goes to the maintainer.
    `coverage=none` and `coverage=UNKNOWN` leave this item unsatisfied and decide no exit code,
@@ -67,13 +69,17 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    `other_reviewed`, with an empty review body and no new threads, is not a missing review. It is
    its own ordinary "reviewed, nothing to flag" shape.
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
-   it where it can. A file-count refusal is cleared by splitting the pull request, which is the
-   only cause on record that the loop can clear. `pr_review.py wait` exits `41` on every refusal
-   and quota state, its `status=` line naming which. The digest's `refusal=` field carries a
+   it where it can. A file-count refusal is cleared by splitting the pull request. A refusal saying
+   every changed file is in Copilot's default review exclusions says nothing about the content, and
+   no round follows it. On a pull request into a branch other than the default, the attested local
+   pass covers that head. Where none can, it goes to the maintainer, `wait` exiting `41` as
+   `REVIEW_EXCLUDED_FILES_ONLY`. `pr_review.py wait` exits `41` on every other refusal and quota
+   state no local pass covers, its `status=` line naming which. The digest's `refusal=` field carries a
    refusal on this pull request.
    `refusal=QUOTA` or `refusal=ERROR` means the pull request's newest Copilot review is an
    account-quota refusal or an error refusal read as a possible quota hit. That review can sit on
-   this head or an earlier one. Nothing the loop does clears it, which is the case "Which
+   this head or an earlier one. On a pull request into a branch other than the default, an attested
+   local pass on a later head clears it, `coverage=local`. Otherwise nothing the loop does clears it, which is the case "Which
    Reviewers a Repository Actually Has" below states. An error refusal whose `RUN LOG READING` line says
    transient is the exception. `wait` re-requests it once and exits `30` while that request is
    pending. A second error refusal in a row, or a re-request made with no round answering it,
@@ -237,11 +243,12 @@ must have done.
   step below is where a missing one is answered, on the terms stated there. A refusal naming the
   account quota is its own case rather than a review. So is one saying only that Copilot
   encountered an error, which is what the
-  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied. Nothing the
-  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  weekly rate limit posts. Each covers no head, so the gate stays unsatisfied where no local pass
+  stands in. Nothing the loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
   reviewer's run log names a reset time `pr_review.py` reports it. Where it names a transient
-  fetch failure instead, `pr_review.py wait` re-requests once. Every other refusal, a repeat of
-  that one included, goes to the maintainer rather than into a wait.
+  fetch failure instead, `pr_review.py wait` re-requests once. Where no local pass stands in, every
+  other refusal goes to the maintainer rather than into a wait, a repeat of that one included. A
+  file-count refusal is the exception, since splitting the pull request clears it.
 
 The hub's `docs/pr-reviewer-reference.md` records what each reviewer does, what shapes it, and
 which repositories its plan covers. That is the record for a reviewer whose behavior still