voidguard — does your green actually check anything?

A guard that fails is doing its job.

A guard that's absent is at least honest.

The dangerous one runs, reports green , and verifies nothing.

What it catches

1 · Tests that never run<br>Skips gated on an environment flag that is set nowhere your repo actually<br>runs; markers every CI invocation deselects; go, rust and js best-effort.

2 · Type gates that check nothing<br>A mypy that cannot see your own types and passes vacuously; imports<br>skipped; check targets matching no files; a weak tsconfig behind an advertised<br>typecheck.

3 · Settings silently discarded<br>PYTHON* variables handed to python -I/-E, which<br>drop them; workflow env set and never read; a Docker ARG consumed after FROM<br>without re-declaration.

4 · CI conditions that cannot fire<br>An if: requiring an event the workflow's triggers never<br>deliver; schedules with no run on the record; golden-file assertions whose path<br>matches nothing.

Every verdict — VOID,<br>WARN, or an honest UNKNOWN —<br>carries its enumerated search set: what was searched, what was found, absent<br>conventional locations named as absent. A tool about unverified claims does not<br>get to make any.

What it cannot catch

The taxonomy this tool comes from has seven instance-types. voidguard v0<br>detects the shapes of four . It would not have caught the other three:

Semantic voids — a verdict typed nullable so “nothing” can be mistaken<br>for a value, or a field the code carries but nothing ever persists. These need<br>type-flow and data-flow analysis, not file-shape analysis.

Process voids — a human approval gate that a merge routed around while<br>every check was green. No scanner catches a decision that nobody waited for.

Anything requiring execution — voidguard never runs your code. A guard<br>that runs and is wrong is outside its question; it only asks whether a<br>guard could ever be observed to fail at all.

Where static analysis cannot decide, the verdict is UNKNOWN<br>with the reason — because a scanner that overclaims void guards is itself a void<br>guard.

Where it comes from

In one week, one repository turned up seven guards that were present,<br>plausible, and void — a core integrity test that had silently skipped in CI<br>since inception, a type gate that passed while checking nothing, an approval step<br>a merge walked straight past. Every one of them was green. voidguard is the<br>generalization of the sweep that found them.

→ The story: the skip-sweep that found seven

→ voidguard on PyPI

→ Source on GitHub