Four findings acted on; two more are real but pre-existing and are being filed rather
than fixed here (see below).
**The job's Gitea config was not authoritative.** `pr-changed-files.sh` resolves
`ETV_GITEA_URL` BEFORE `GITEA_BASE_URL` (and `ETV_GITEA_TOKEN` before `GITEA_TOKEN`),
because its other caller is a developer Mac using the ETV_* convention. Setting only the
GITEA_* names meant a runner exporting a stale ETV_GITEA_URL would enumerate a DIFFERENT
Gitea instance and this job would post a verdict here from a diff read there. Both names
are now set to the same value, so precedence cannot matter.
**Three guards passed their tests for the wrong reason.** Each was confirmed by deleting
the clause and watching the suite stay green — the reviewer asserted it, mutation proved
it:
- The explicit empty-response clause was uncovered on jq 1.8, because jq 1.8 rejects
empty input by itself. jq 1.6 does not, and THE RUNNER SHIPS 1.6 — so the one
environment where the clause is load-bearing had no coverage. That is the #643/#647
failure class reproduced inside the suite meant to prevent it. Now covered by importing
the existing jq-1.6 shim (imported, not copied — a second quirk emulator is the same
drift problem one level down), with a verify-the-verifier test and a positive control.
- `type == "array"` needed a body whose VALUES are valid rows. Two earlier attempts
failed for a third reason: `jq`'s `all(.[]; …)` iterates an object's values, so
`{"message":"…"}` and a single flat row are both rejected by `.filename` erroring on a
string. Only `{"0": {…valid row…}}` reaches the fail-open, where a non-array body
enumerates as a complete docs-only list.
- `.filename | ok` is now isolated by a row carrying a valid `.status` and no filename,
removing the closed-allow-list as a second reason to reject.
**Two assertions proved less than their names claimed.** `"jq-preflight.sh" in code` also
matched the `[ -x … ]` presence guard, so deleting the invocation left it green; it now
requires an invoking line. `_run_classify` accepted every POST, so a status aimed at the
wrong endpoint or sha would not have been noticed; it now asserts the POST lands on
`/statuses/<full head sha>`.
**One test name overclaimed** and is narrowed rather than left implying coverage it does
not have: the head-movement test proves "final head != expected sha", not movement
*during* enumeration.
Deferred, both pre-existing and neither introduced here — filed as follow-ups:
- A commit status is repo-global, so a `review-verdict/h10=success` obtained for head H
on one PR is inherited by any other PR with the same head, including one opened against
a different base. Same class as #632, reached by a third route.
- The A->B->A force-push race: paging is several round-trips and the head is re-read once
at the end, so a restore to the original sha passes the binding while the pages came
from two states. Inherent to enumerating a mutable list over an API with no
commit-pinned files endpoint.
Refs #649
timothy
322dd43d10