A ccr-overview-v2 Round States No File Coverage, and the Exit-45 Remedy Cannot Clear It

[ptr727]

status exits 45, COVERAGE_IS_UNSTATED, on a Copilot round written in the ccr-overview-v2 format, and the remedy that exit names does not clear it. Measured across every round in that format read here so far.

What was measured

Four rounds in that format, across two pull requests, read for both coverage spellings:

Pull request	Head	fleet-review marker	Files reviewed line
1687	d0e722f9	yes	no
1690	95f95297	no	no
1690	c8b38cd1	no	no
1690	6efc875c	no	no

Every head above carries .github/skills/code-review/SKILL.md, which asks the reviewer to end its body with the marker, and .github/copilot-instructions.md. The three rounds on 1690 were separated by two explicit re-requests through requestReviews, so this is not one round being unlucky.

The exit's own text says to confirm the head carries the current instructions and then request another review. The head did carry them and another review was requested twice, so the stated remedy is unavailable on this shape.

Why the second format is worse placed than the first

The first format states coverage in its Review details section, as - **Files reviewed:** N/M, and COVERAGE_BULLET requires the bullet. The second format has no Review details section at all and states its metadata on bare bold lines, which is why EFFORT_LINE had to drop its own bullet requirement to keep reading effort=.

So the spelling a second-format round would most plausibly use for coverage is the one the coverage reader cannot see. Executed against a constructed body in that format:

**Files reviewed:** 3/4      -> coverage_of reads 'unstated', unrecognized_in reads []
- **Files reviewed:** 3/4    -> coverage_of reads 'partial'

Files reviewed sitting in VETTED_LABELS does nothing about it, since LABEL_LINE also requires a bullet and the line never reaches that comparison. The result is a round that stated its coverage being read as stating none, silently, with no shape reported.

Why it matters

Exit 45 is a blocking state whose remedy is a re-request, and here the re-request is inert. That is the cry-wolf shape this script names as its own failure mode elsewhere: a gate that fires on a condition nobody can clear teaches a reader to route around it. It also puts the maintainer in the position of waiving the coverage item on every second-format round, which is what happened on 1690.

Nothing here is a false green. A round that states no coverage is read as stating none, which blocks, and that is the honest direction. The defect is that the block is unclearable and, on the bare-bold spelling, that a real statement reads as absent.

Shape of the work

Three parts, and the first two are independent of each other.

• Read the bare-bold spelling. coverage_statements and its patterns require a bullet where this format states metadata without one. Widening that has the same hazard the LABEL_LINE decision already records, since this format's own **Changes:** prose label would read as metadata, so the coverage line needs its own pattern rather than a widened label reader.
• Settle what the reviewer actually emits. Whether the marker's absence is the format dropping the instruction, the instruction not reaching a round in that format, or something about how the round is requested, is unmeasured. A round requested a third way, or a round on a different repository carrying the same instructions, would separate those.
• Decide what exit 45 should do on a round that states nothing in a format known not to state it. Blocking on an unclearable condition and blocking on a clearable one read identically today, and only the second has a remedy worth printing.

[ptr727]

A fifth round, and the marker correlates with the base branch

The promotion pull request for the same change carried the marker, and status read coverage=full and exited 0 on it. Every round read in this format so far, by base branch:

Pull request	Base	Head	fleet-review marker
1687	main	d0e722f9	yes
1690	develop	95f95297	no
1690	develop	c8b38cd1	no
1690	develop	6efc875c	no
1691	main	1561c1df	yes

The two main-based rounds stated coverage and the three develop-based rounds did not.

What this does not establish. Three of the five observations are the same pull request, so the base branch and the pull request itself are confounded: a per-pull-request effect and a per-base effect produce exactly this table. Separating them takes a second develop-based pull request in this format, or a main-based one that omits the marker.

What it rules out. It is not the instructions being absent from the head, nor the trees differing: main and develop held identical trees when 1690 and 1691 were open, and the content 1691 promotes is the content 1690 merged. It is also not the comments label, which both carried.

So the third bullet in the shape of the work above is now the first thing worth measuring, and the reader-side half stands unchanged: a bare-bold **Files reviewed:** line would still read as no coverage at all whatever the reviewer decides to emit.

[ptr727]

Six more rounds in this format, measured while driving #1694 to release on 2026-09-19, across three pull requests. They change the second bullet's answer and they contradict the first bullet's premise.

Pull request	Head	fleet-review marker	Files reviewed, either spelling	Verdict	Sections
1694	095da786	reviewed=41 changed=41 findings=5	no	Changes recommended	Open (5), What changed in this PR
1694	8783f4ef	reviewed=41 changed=41 findings=0	no	Approval recommended	Resolved since last review (5)
1694	bebc881a	absent	no	Approval recommended	none
1696	9ff38fe7	reviewed=41 changed=41 findings=1	no	Changes recommended	Open (1), What changed in this PR
1697	a310194f	reviewed=1 changed=1 findings=0	no	Approval recommended	What changed in this PR
1696	a409f818	absent	no	Approval recommended	Resolved since last review (1)

What this settles, and what it unsettles

The marker is emitted most of the time. Four of six carry it, against one of four in the table above. Taken together that is five of ten rounds in this format, so its absence is intermittent rather than structural, and "the format dropped the instruction" is not the explanation.

No round has ever stated Files reviewed, in either spelling. Ten rounds now, bulleted or bare-bold, none. So the first bullet hardens a reader against a spelling the reviewer does not appear to use, and the premise that it is "the spelling a second-format round would most plausibly use" has ten rounds of evidence against it. Worth keeping as defensive reading, worth demoting as the explanation for exit 45.

What correlates with absence, on this sample. Both markerless rounds are incremental re-reviews whose diff since the previous round was very small: bebc881a was four files and one deleted sentence, a409f818 was one file and one line. Both were triggered by an explicit requestReviews. But so was 8783f4ef, which is seven files and carries the marker, so the trigger is not it. The candidate is the size of the delta since the previous round, not how the round was requested.

If that holds, exit 45 is honest on exactly those rounds. A re-review that skims a one-line delta has not re-assessed coverage of the full diff, and a round that says so by omission is telling the truth. That reframes the third bullet: the question is not how to clear an unclearable block, it is whether a round that did not re-assess coverage should block at all when an earlier round on the same pull request stated full coverage and the delta since is readable.

The shape that worked here, twice

Both promotions this round were merged over exit 45 by proving coverage across two rounds rather than by re-requesting:

• round N states reviewed=M changed=M at one head;
• round N+1 covers the next head and raises nothing;
• git diff --stat <head N> <head N+1> is small enough to read in the proof.

On #1696 that was one file and one line. The proof went on the pull request before the merge, and the exit's own text says the call is the maintainer's. This is cheaper than a re-request the issue measures as inert, and it is mechanizable: the two heads and the delta are all available to status.

Suggested revision to the three bullets

1. Keep the bare-bold reader as hardening, but stop treating it as the cause. Ten rounds say the coverage statement is the marker.
2. Answered as far as this sample goes: the marker is intermittent and correlates with delta size, not with the trigger. What would separate it further is a re-request on a large delta that still omits the marker.
3. The live question. Rather than clearing the block, consider carrying the previous round's coverage forward when a later round on the same pull request states none, and reporting the delta between the two heads so the reader can judge it. That is the manual proof above, done by the script.

A separate defect in the same format reader turned up while measuring this and is filed on its own.

[ptr727]

Implemented and parked, unpushed, on the local branch feature/ccr-overview-reader (commits 9f3127c and 9ca1fbb), so #1700 can go first while it is blocking a pull request elsewhere.

What is done. The carry is implemented as decided, with the delta reported beside it, and reads correctly on the live case: coverage=carried:full with 1 file changed over 1 commit since, exit 0, which is the hand proof this morning done by the script. A carried partial still exits 42. Exit 45 names only a pull request no round ever stated coverage on. #1699's per-severity sum is in the same branch. The whole gate set is green and the suite is 392 cases.

What is not done. Two adversarial passes returned 14 findings and then 12. The second pass's list, strongest first, each reproduced against the branch:

1. The gh_rest mock moved to GqlCase.setUp is a net regression: TestCli and TestCoverageExitCodes override setUp without calling super(), so they lost a mock they had through answer(). Latent today, live on the next carry payload added to either.
2. delta_since's jq change is a no-op for .files, since length on null is 0, and the docstring claiming it now reads as unread is false. Only the .ahead_by half changed behavior.
3. The regression case for that fix mocks gh_rest and feeds a literal stdout, so it exercises no jq at all and passes against the reverted filter.
4. findings_on's stated reason for checking None last is inverted, and the case named for that ordering passes under either ordering.
5. On a carried partial the verdict still states the earlier commit's file count in this head's terms, in the same sentence that says the counts are not about this head.
6. The carried-partial branch prints "a re-request has never cleared this", where a re-request is the one thing that would clear it, by producing a head round that states its own coverage.
7. .github/copilot-instructions.md, carried fleet-wide, still says a review is complete only when it states full diff coverage, which the carry makes untrue.
8. The status half of the module docstring describes pre-carry behavior while the wait half was updated.
9. A **Findings:** line pairing one count and leaving another unpaired drops the unpaired one silently.
10. carried_coverage admits UNVETTED, so the digest can say an earlier round "states any" coverage about a line it has just reported as unreadable.
11. A test docstring still describes the deleted MARKUP substitution.
12. The badge-numbers case pins the right outcome for a reason its docstring no longer describes.

None of these is a false green in the shipped sense: the exit codes are right on every path the passes exercised, and 10 is reported at exit 43 regardless. They are claims that are wrong and one isolation regression.

Resuming. The branch is local only. Fix 1, 2, 5, 6, 7 and 9 before the pull request, since those are behavior or carried content, and take the rest with them. The two passes are recorded receipts, so a resume needs one more pass over whatever it changes rather than a fresh read of the whole diff.

[ptr727]

A fourth measured PR, and the first where the gap decided a merge

#1705 ran four Copilot rounds. Only the first stated coverage.

Round	Head	Marker	Findings
1	0779f884	reviewed=1 changed=1	1
2	d8cc0120	none	None
3	4f482acf	none	None
4	4f482acf	none	None

Round 4 came from an explicit requestReviews, so the re-request the
COVERAGE_IS_UNSTATED remedy prescribes was run and produced another silent round.

Two things this measurement rules out as causes.

The instruction was present. The head carried
.github/skills/code-review/SKILL.md byte-identical to develop, and its marker
paragraph was intact. So this is not a branch missing the current skill, which is the
first thing the remedy text tells the reader to check.

Carry-forward could not rescue it. Round 1's reviewed=1 changed=1 was truthful when
written, over a one-file diff. The diff grew to three files afterward, so the earlier
round's statement covered a strictly smaller change set. That is the case the
carry-forward design has to refuse, and it refused correctly here.

That leaves reviewer nondeterminism, at 1-of-4 on this PR. The running rate across
measured rounds is now well under the 5-of-10 recorded earlier.

The consequence is the part worth recording. The remedy is a loop with no exit: it says
re-request, the re-request lands a round, the round states nothing, and the digest
prints the same remedy again. Nothing in the loop distinguishes a reviewer that has not
gotten to it yet from one that will never state coverage on this PR. The merge went to
the maintainer, which is what the status text says should happen, but it went there
after four rounds rather than after the first, and the three extra rounds bought no
information.