A guard you have not watched fail is not a guard — plant both failure branches before you
trust it. A check that has only ever printed "clean" is indistinguishable from a check that
cannot fire: a wrong regex, an over-narrow file filter or an inverted condition all look exactly
like success. The XSLT loader ratchet (012a060) has two failure branches — a load site outside
the baseline, and a baseline entry whose file no longer loads a transform — and both were planted
deliberately, observed to fail, and removed before the guard was committed. The same run then
caught the guard flagging itself, because the interface's XML-doc names the construct it
forbids; that was fixed in the scanner (skip comment lines) rather than by rewording the prose.
How to apply: ship no guard whose failure you have not seen with your own eyes, and prefer
fixing the detector over editing the code that legitimately tripped it. This is the guard-shaped
case of the broader rule that an instrument reporting only failures cannot distinguish "passed"
from "never ran" — see memory/feedback_no_failures_is_not_evidence_of_success.md and #30.
Receipt: 012a060, 0a78a9a.

Source: plans/AgencyArchitecture.md section 10, #42.