[onedr0p]

Two CI defects, both swept across the org after they surfaced in home-operations/miroir. Sibling PRs are open elsewhere with the identical changes.

Build Success treated cancelled as passing

The job runs under if: ${{ !cancelled() }}, which still fires when individual needs were cancelled but the run as a whole was not. needs.*.result then contains cancelled, not failure, so Any jobs failed? is skipped and All jobs passed or skipped? exits 0. Branch protection sees the gate green even though a required job never reached a verdict.

Reachable here: concurrency.cancel-in-progress is on for pull_request, so a superseded push is the ordinary way into that state, not a corner case.

The golangci-lint cache could poison itself

That cache holds analyzer facts (staticcheck's "does this call return?"), so a stale or partial entry does not just cost time: it turns checks like SA5011 into false positives on code the commit never touched. miroir hit exactly that, twice, on byte-identical trees, and it blocked its merge queue.

The key hashed only go.sum and .golangci.yml, so a bad entry survives any commit touching neither, and the bare-prefix restore-keys hands it to every subsequent run until GitHub's 7-day eviction.

• the key now covers .mise/mise.lock, so a golangci-lint or Go bump starts fresh instead of handing a new binary the old one's facts
• restore-keys is gone: a miss must start cold rather than fall back to the newest entry under the prefix

Exact hits stay the norm, since the three hashed inputs are stable across most PRs. When one does change, a cold cache is the correct outcome.

Verified: actionlint (with the org's -ignore flags), zizmor, oxfmt --check.