Cross-family re-review of the previous fix commit. It did NOT pass, and it was right
not to: the round that fixed the reviewers' findings introduced two of its own, both in
the tests written to close them. That is this file's recurring shape, and it is the
reason the fix commit gets re-reviewed rather than the initial diff only.
TRUNCATION (High). `read_existing_verdict` asks for 100 statuses and never checked
whether the page was full. If a head ever carried more contexts than that, an existing
`review-verdict/h10` could fall off page 1, the job would conclude no verdict exists,
and it could post an exemption `success` over a human `failure` — the worst thing this
gate can do. Six contexts exist today, so this guards a future shape, not a live bug.
BUT THE PROPOSED GUARD WAS A NO-OP, and measuring is what showed it. The review asked
for `.statuses | length` compared against `.total_count`. On this instance `total_count`
is the count for the PAGE RETURNED, not for the commit: on 3aed43c6 (6 contexts),
`?limit=1` gives `len=1, total_count=1` and `?limit=3` gives `len=3, total_count=3`.
The two are equal by construction, so that check would have read as a completeness
proof while proving nothing — and it would have been the second guard in this file to
look like a check and not be one. What IS observable is a page at the requested limit,
which means "maybe more", so that is now treated as unreadable: post nothing, leave the
required check absent. The stub mirrors the per-page `total_count` deliberately, so the
new test cannot pass for the wrong reason either.
THE TESTS THAT CLOSED THE LAST ROUND'S FINDINGS:
* The behavioural guard test — added to answer "a bare `exit 1` substring is satisfiable
by dead code" — extracted the two marker lines BY TEXT and ran them alone. That
passes even if the write is moved into a function nobody calls: the extractor finds
the text, runs it at top level, the marker appears, and the test reports the guard
proven while production writes no marker. It now executes the classify body's real
PREFIX down to and including the write, which reproduces the production control flow
instead of a reconstruction of it. Mutation: move the write into an uncalled function
-> RED (it previously passed).
* The anti-vacuity check — added to replace an over-broad assertion — hand-counted
`run:` keys with a regex that only matched an indented `run:` starting `|` or `>`. It
false-redded legal spellings (`- run: |`, a single-line `run: echo ok`) and could
count a `run: |` sitting inside a heredoc. Hand-parsing YAML to validate a YAML parse
is the wrong shape: it adds a second, worse parser whose every disagreement is a
false alarm, and a red here blocks all merges. Now asserted on CONTENT — the walk
reached >=3 bodies and one over 5000 chars.
FALSE RED, THIRD INSTANCE IN THIS FILE. The repo-wide expression test scanned raw file
text, so a delimiter in an inert top-level YAML comment redded the repo even though the
runner never evaluates it. It now scans PARSED scalars: PyYAML drops YAML comments,
while a `run:` body is itself a scalar and keeps its SHELL comments — which is exactly
the distinction that matters, since inside a `run:` scalar a comment is not inert.
Verified in both directions: an inert top-level comment passes, the same payload in a
run-body comment still reds.
Also: the `total_count` zero check now requires the JSON TYPE to be number — `jq -r`
renders `0` and `"0"` identically, so a text compare accepted a corrupted
`"total_count": "0"` as "no statuses".
Verification: 455 green. Six further mutations, each landing as intended — the uncalled
function (red), an inert YAML comment (PASSES, no false red), the same payload in a
run-body comment (red), accepting a full status page (red), comparing total_count as
text (red), and breaking the YAML walk's job key (red). Seventeen mutations across the
three rounds.
Re-probe of both live controls follows on this body; the previous probe evidence was
taken before this commit and no longer describes what would merge.
Refs: #751
Decisions-Edit: yes
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
timothyandClaude Opus 5
46ec532745