merge: an absent tick is not a passing tick - #35

Step 5 of the merge skill could merge a PR whose CI had not run. Two bugs, one shape: an absence of signal read as a positive answer. Both hit by hand while landing ps-mutuus/mutuus-changelog#52.

Bug 1 — [] documented as "no CI gate exists — proceed"

[] is also what GitHub returns for a minute or two after a force-push, while it re-associates workflow runs with the new head. Observed on #52 right after the step-4 push: rollup [], gh pr checks 52 printing no checks reported on the 'claude/gh-path-helper' branch, and gh run list showing a PR checks run already queued for that exact head sha.

Now: [] means re-query. "No CI" may only be concluded after a positive check that no run exists for the head sha — with the caveat, stated in the skill, that gh run list sees GitHub Actions only, so an external provider posting commit statuses appears in neither source until it registers. The wait loop requires total > 0 before it can conclude nothing is pending, so zero checks can never satisfy "all passed".

Bug 2 — .conclusion // .state never consulted .state

jq's // falls through on null and false; an in-progress check run has conclusion: "". So .state was dead code, and a pending check landed in an empty-string bucket no rule mentioned — easy to read as "not FAILURE, therefore fine".

The replacement branches on __typename rather than sniffing nulls, because the null-sniffing shorthand is a type test by accident: gh's export (cli/cli api/export_pr.go) emits disjoint key sets — a CheckRun has no state key at all, a StatusContext has no status/conclusion and names itself via context.

The half you asked me to verify — the legacy status context

The done clause as proposed in the report (.status == "COMPLETED" or .state != null) has the same bug one level down. A legacy status context that is still running is state: "PENDING" — non-null — so a pending external CI would have counted as passed. Reproduced against a fixture; the committed filter treats PENDING/EXPECTED as pending.

Enum values came from GraphQL introspection rather than memory, which also caught a third gap: the failing conclusions are wider than the proposed list — ACTION_REQUIRED, STARTUP_FAILURE and STALE were missing.

An unrecognised __typename falls into the else branch with no state and lands in pending. Unknown fails closed.

Verified

• The 5a filter extracted verbatim from the committed file and run against Add VHS demo skill cli/cli#14334 — 37 rows, {"failed":[],"pending":[],"total":37}.
• Fixtures: the observed #52 in-progress check run (conclusion:"", status:IN_PROGRESS) → pending; a PENDING legacy status context → pending; mixed QUEUED/FAILURE/SKIPPED/ERROR → correct buckets; empty rollup, null rollup, unknown typename → fail closed.
• // on "": {"conclusion":"","state":null} | .conclusion // .state → "". Confirmed on jq 1.8.2.
• The 5b cross-check run in both directions on cli/cli trunk — 0 for a foreign sha, 20 for the real head — so it is known to be able to return a negative and a positive, the discipline scripts/gh_path.py encodes for a different API.
• The 5c loop driven by scripted rollups: an always-empty rollup now times out instead of passing.

Not verified

A live StatusContext row was never observed. That half is derived from gh's export shape and the StatusState enum, and is flagged under Limits in the skill so the next reader knows to check the raw rows once on a repo whose CI posts commit statuses. gh pr checks exit 8 remains documented-but-unobserved, unchanged.

README updated in the same commit.