Make every gate fail when it examines nothing

[AdamClemens]

Make every gate fail when it examines nothing

Asked what else the repository might not be implementing as believed, and
answered it mechanically rather than by reasoning: every validator run with
its discovery function replaced by one returning an empty set.

Four of the nine validators in make ci returned success. check_docs,
check_duplicate_blocks, check_references and check_scenarios printed
their ordinary success message and exited 0 over nothing at all. In CI that
output is indistinguishable from a clean run, which makes it worse than
having no gate: the pipeline reports a check that did not happen.

docs/practices.md's "A rule that matches nothing reports nothing" has
recorded this shape since 2026-08-30. All three instances there are a check
whose pattern matched nothing. This is the fourth and the first where the
input was empty -- which is why it survived: every prior instance trained
attention on the pattern.

Two of the four are their own lesson.

check_references.py states the principle in a comment and did not
implement it. The twelve lines above EXTS exist because .feature was
missing from that tuple for two days while every feature path in every
document went unchecked behind a green gate. They end "a rule that matches
nothing reports nothing, which reads exactly like a pass". Two hundred lines
below, main() printed "Every path named in prose resolves" over an empty
file list.

check_scenarios.py guarded one half of itself and not the other -- and
that was not an omission. Its bindings side has always failed loudly; its
features side returned 0, deliberately, with a test stating why: the gate
was built before Stage 4 wrote its first .feature, so an empty
tests/features/ was then the repository's ordinary state. That reason
expired on 2026-08-27 when TASK-023 landed the first feature file, and
nothing revisited it -- 17 days, under the one gate
adr/ADR-007-executable-acceptance-criteria.md rests on entirely, since
pytest says nothing about a .feature file no module runs. An exemption
states its own expiry condition and then nobody is assigned to watch it.
tests/unit/test_check_scenarios.py's test is inverted here rather than
deleted, with that history in its docstring.

The fix is a sweep, not four guards. Four guards would be four fixes and
a hope. tests/unit/test_validator_guards.py runs every check_*.py with
nothing to find and requires a non-zero exit and a message saying so, with
test_every_validator_is_covered failing if a validator is added without an
entry. check_claims is excluded by name with its reason (advisory by
design, exits 0 even with findings) rather than by absence -- an unexplained
omission is how this gap existed. The sweep failed for exactly those four
before the fix, which is its own mutation evidence.

Three other classes were probed and came back clean, recorded so the
next pass does not redo them: no configuration field is unread by engine
code (TASK-055's sweep generalised to all 14 schema dataclasses); the
ADR-003 registries agree exactly with the schema Literals that select them
(periodic and boussinesq_buoyancy look like mismatches and are both
deliberate, the latter pinned in three directions by
tests/integration/test_boussinesq_buoyancy_registration.py); and all 163
@then step definitions assert something.

The general form, carried into docs/practices.md as the rule rather than
the four instances: when a check reports success, ask what it would have
reported had it examined nothing. If those are the same output, it is not
yet a check.

🤖 Generated with Claude Code

---

Also in this branch: labelling the self-test window that is supposed to diverge

Unrelated to the gates, and riding along rather than taking its own branch.

While this PR's CI was running, the maintainer watched a lid-driven cavity tear itself apart on screen and reported it as a suspected engine failure. It was test_frame_failure.py's own display-guarded case, which runs the cavity at 2.05× its stability limit in a real glfw window because proving "a diverged run terminates rather than hanging" needs the real backend. It diverges at step 17 of 25, by design.

Checked rather than assumed: the shipped 16×16 cavity runs 1200 frames to a clean steady state (max|u| → 0.7611 against a lid speed of 1.0, kinetic energy asymptoting to 6.37, monotone throughout), and this is the only one of four windowed integration modules whose config diverges.

Behaviour right, presentation wrong. Stage 7 exists on the premise that the render window explains itself; this one said PyFlow while blowing up. It now sets rendering.title, drawn in the scene by hud.build_title_text, verified by reading it back out of the real rendered scene:

'PyFlow self-test -- this run is SUPPOSED to diverge'

No assertion changes — only what a human sees while it runs.