prove-checkslisted

# Prove the Check Can Fail A green result is evidence only if red was reachable. Every check runs in a state, and when that state is wrong the check does not error — it passes, cheaply and convincingly. The failure is silent by construction: nothing in the output distinguishes "the system works" from "the system was never asked". Five ways a check goes green without testing anything: | Shape | What happened | What green meant | |---|---|---| | Setup no-op | The mutation the check depends on never applied | The check compared the old state to itself | | Subject not exercised | Only the downstream half ran, or it ran its no-op branch | The upstream half is still unverified | | Failure suppressed | The failure path was routed to a warning or a forced exit 0 | Exit status carries no information | | Nothing executed | The gate was set and the run exercised none of the subject anyway | Zero checks ran, and exit 0 says what a full pass says | | Subject substituted | The named target was unreachable and the tool silently chose another one | The work was done correctly, on the wrong thing | ## Trigger Run this before recording any green as proof, and always when one of these is true: - The check depends on a setup mutation: an in-place text edit, an env var, a secret, a generated fixture, a checked-out revision, a temporary config override. - The job or step is wrapped in `continue-on-error`, `|| true`, `set +e`, `if: always()`, or emits `::warning::`/`echo` instead of a non-zer