green-gate-never-examined-the-case

A green gate that never examined the case

Clean is indistinguishable from safe. A check that did not run, ran on the wrong object, or ran on an input that made it succeed trivially reports exactly what a genuinely passing check reports. The signal you get is the same; the information is not.

The test, two clauses:

1. Make the check fail on purpose once. If you cannot produce a failing run, you have established that the check printed something, not that it can fail.
2. Check what the failure already cost before you clear it. A guard tells you a state is wrong. It does not tell you what that wrong state already did.

The five mechanisms

Each of these was measured, not imagined. All five surfaced within one working session, which is the reason to treat this as a family rather than five unrelated bugs.

1. Scope excludes the case

A description-length gate built its worklist as:

live = [s for s in skills if not s.disabled]

A disabled skill's 1,548-character description therefore reported over: False against a 1,536 cap. Harmless while disabled — and it truncates mid-word the moment anyone enables it, which is exactly when nobody re-runs the check.

Generalises to: any gate scoped to "active", "enabled", "published" or "current" objects stops guarding the moment something is deactivated. Deactivation is when nobody is looking.

2. Malformed input makes the check succeed trivially

A test named for a corrupt base64 payload never reached the decode branch it was named after. % falls outside the base64 alphabet, so the capture group matched empty, and b64decode("") returned cleanly. The test passed because the input was broken.

The tell: a test whose name describes a failure mode, which has never been seen to go red.

3. The error lands on a channel nobody reads

git diff --diff-filter=D --name-only a...b     # unrelated histories
  stdout: (empty)
  stderr: fatal: a...b: no merge base
  exit:   128