A red test that fails only because the build fails proves nothing: show a behavioural failure with deliberate mutations

In red-then-green workflows, it's tempting to commit a new check that's 'red' because the tool or target it calls doesn't exist yet (e.g. the makefile names a missing binary, so the suite errors out). That red is vacuous: it would also be red if the check itself were broken or always passed. Once the tool builds, prove the check works. Apply one or two deliberate mutations that should trip exactly that check (feed one arm a different seed, so inputs differ; or build a variant that flips one bit of one arm's answer hash), confirm the suite fails on that check and nowhere else, then revert and confirm it's green again. Record the mutations and results in a follow-up commit note (no amend) and in the review request, so the reviewer can see the check has teeth. Same idea when reviewing: break the guarded condition on purpose and make sure the test fails.