gh pr checks does not list the copilot-pull-request-reviewer check run, so it can report zero pending checks while that reviewer is still running. Anything keyed on gh pr checks -- a watcher, a readiness gate, an ARDI round-close -- can therefore call a PR terminal mid-review.
Measured
On #1056 at head cbf39b6452e33188524f3f8a233ba1a9190906ad, 2026-08-02, the two surfaces disagreed:
$ gh pr checks 1056 --json bucket --jq '[.[]|select(.bucket=="pending")]|length'
0
$ gh api repos/Morrison-Lab/ai-config/commits/cbf39b64.../check-runs \
--jq '.check_runs[] | select(.status != "completed") | "\(.name) \(.status)"'
copilot-pull-request-reviewer in_progress
gh pr checks returned 10 contexts, none Copilot-attributable. The check-runs API returned 11.
Why it matters here
shared/workflow/fully-clean.md's criterion 1 requires every check to be completed and passing, and warns that a still-running check must never be read as clean. gh pr checks is the instrument most sessions reach for to evaluate that criterion, and on this repo it silently omits one reviewer's check run.
This also bears on that file's fifth-case record, which reports that on #1005 and #1008 Copilot "contributed no check run at all" and concludes "the check surface is silent about that reviewer by construction". Today it does contribute one. So either the behaviour changed since 2026-07-31, or those two PRs differ from this one in some way the record does not capture. Either way "by construction" is too strong as written, and the section's advice to settle the question from get_reviews rather than the check surface is right for a reason slightly different from the one it gives.
Suggested fix
Two parts, and the second matters more than the first:
- Note in
fully-clean.md criterion 1 that gh pr checks is not a complete enumeration of check runs, and that the commit check-runs endpoint is the authority when the question is "has everything finished".
- Soften the fifth case's "no check run at all / by construction" claim to what was actually measured on those PRs, with the date, since this observation contradicts it.
Not yet established
Why the two disagree. Candidates worth checking before writing the fix: whether gh pr checks filters by check-suite app, whether it reflects only the required/branch-protection set, or whether an in_progress app check is simply omitted until it completes. I did not determine which, and the fix should not assert a mechanism that was not measured.
gh pr checksdoes not list thecopilot-pull-request-reviewercheck run, so it can report zero pending checks while that reviewer is still running. Anything keyed ongh pr checks-- a watcher, a readiness gate, an ARDI round-close -- can therefore call a PR terminal mid-review.Measured
On #1056 at head
cbf39b6452e33188524f3f8a233ba1a9190906ad, 2026-08-02, the two surfaces disagreed:gh pr checksreturned 10 contexts, none Copilot-attributable. The check-runs API returned 11.Why it matters here
shared/workflow/fully-clean.md's criterion 1 requires every check to be completed and passing, and warns that a still-running check must never be read as clean.gh pr checksis the instrument most sessions reach for to evaluate that criterion, and on this repo it silently omits one reviewer's check run.This also bears on that file's fifth-case record, which reports that on #1005 and #1008 Copilot "contributed no check run at all" and concludes "the check surface is silent about that reviewer by construction". Today it does contribute one. So either the behaviour changed since 2026-07-31, or those two PRs differ from this one in some way the record does not capture. Either way "by construction" is too strong as written, and the section's advice to settle the question from
get_reviewsrather than the check surface is right for a reason slightly different from the one it gives.Suggested fix
Two parts, and the second matters more than the first:
fully-clean.mdcriterion 1 thatgh pr checksis not a complete enumeration of check runs, and that the commit check-runs endpoint is the authority when the question is "has everything finished".Not yet established
Why the two disagree. Candidates worth checking before writing the fix: whether
gh pr checksfilters by check-suite app, whether it reflects only the required/branch-protection set, or whether anin_progressapp check is simply omitted until it completes. I did not determine which, and the fix should not assert a mechanism that was not measured.