A green CI run does not verify a CI fix: path-filtered jobs skip silently and report success

When you repair a CI job (runner disk, cache action, build args) the change usually lives entirely in .github/**. If the broken job is gated on a paths filter, that path set almost never includes .github/** — the filters name source dirs (gtsrv/**, web/**, Dockerfile, docker-compose.yml). So:

the fix commit lands,
Detect Changes emits backend=false frontend=false,
the expensive job is skipped, not run,
the aggregate CI Complete gate treats skipped as acceptable,
and the run is green.

I hit exactly this: pushed a runner-disk fix, saw completed success inside 45 seconds, and the image build had never executed. Observable tell is the duration and the job status — gh run view <id> --json jobs | jq -r '.jobs[]|"\(.name) \(.status) \(.conclusion)"' shows Build Runtime Image completed skipped, and the whole run finishes far faster than the job you were fixing takes on its own.

Two conditions to actually verify, not one:

Make the gated job run. Include a filtered path in the same commit — ideally a real part of the fix (I pinned target: runtime in docker-compose.yml, which is in the backend filter), not a whitespace poke.
Make it take the failing branch. Jobs that short-circuit on a cache hit will pass without exercising anything. If the job pulls a content-addressed image (deps-<hash>), the fix must also rotate that hash, or you verify the pull path and learn nothing about the build path. Folding the new target and build-args inputs into the key hash did both jobs at once: correctness fix plus a guaranteed cache miss.

Then read the log for proof of the branch, not just the conclusion:

jid=$(gh run view $RUN --json jobs | jq -r '.jobs[]|select(.name=="Build Runtime Image")|.databaseId')
gh api repos/$OWNER/$REPO/actions/jobs/$jid/logs | grep -iE 'Cache (HIT|MISS)|/dev/root'
# Cache MISS - will build image
# /dev/root  72G  38G  35G  52% /

Related trap in the same family: if the job dies hard enough to kill the runner worker (out of disk), the step log is never uploaded and gh run view --job <id> --log answers log not found. Use the run-level annotations (gh run view <id>) for the cause, and once fixed, use the job log as the evidence that the fix ran.

General rule: for infra changes, the verification artifact is a log line proving which code path executed, not the run's green checkmark. Skipped is not passed.