llvm-inprocess reports green on PRs while skipping its only real job (hazard 4), and fails when it does run

[proggeramlug]

#7966 lists llvm-inprocess.yml as the extreme outlier — "last success 194.1h ago (budget 12h)". The 194h figure is real but it understates the problem, and the cause is not (only) starvation.

1. Its PR "successes" are vacuous

Sampled three recent success runs — 31505530279, 31499833415, 31476724152. Every one shows:

changes        = success
native-backend = skipped

The path filter skips the only job that does anything, and the workflow reports green. So the gate has not merely been silent for 8 days; it has been actively reporting success while executing nothing.

This is CLAUDE.md's "★ Four ways a gate can be unable to fail" hazard 4 in its purest form — the gate runs but its subject never did — and it is the most dangerous of the four precisely because the job is genuinely green. Any confidence drawn from llvm-inprocess passing on a PR in the last week is unfounded.

2. When it does execute, it fails

Its three most recent main runs — 31461469705, 31461474406, 31461478986 (all created 2026-08-11T05:23Z) — concluded failure, with changes=success, native-backend=failure.

Run 31461478986: created=2026-08-11T05:23:28Z, updated=2026-08-12T15:06:17Z — 33.7h in queue, then it ran and failed.

3. It is also starved

Its four scheduled runs since #7856: 08-11T19:45 queued (still), 08-12T03:10 cancelled, 08-12T08:03 cancelled, 08-12T14:06 pending. Zero completed. #7969 fixes that arm; it does not touch (1) or (2).

Failure detail (partial)

The Native-mode smoke step dies with a bare exit 1 under set -euo pipefail and emits no diagnostic on that path. The log ends at Collecting modules… / Generating code… on the third compile of spike.ts — i.e. the PERRY_LLVM_INPROCESS=diff arm — after spike_text and the native compile both succeeded (in-process LLVM backend active (LLVM 22.1.8)).

I cannot determine from the artifacts whether this is a real backend regression or a toolchain/environment issue. The step needs to say something before it exits; that is arguably the first fix regardless of the underlying cause.

What needs doing

1. Make the vacuous-green impossible. A workflow whose only substantive job is skipped should not report success. The usual shape is an aggregator job (if: always()) that requires the real job's result to be success or a genuinely-unaffected skipped, rather than letting the path filter silently stand in for a verdict. gc-native-roots-complete is the in-repo precedent for the fan-in pattern.
2. Give Native-mode smoke a diagnostic before exit 1, so the next failure is triageable from the log.
3. Re-run and triage the actual native-backend failure once (2) is in.

Per #7966, this workflow is "the promotion prerequisite" for the in-process LLVM backend arm. It cannot serve that role in its current state: it has been green-by-skipping on PRs and red-when-executed on main.

Found while diagnosing #7966. Related: #7969, #7970.