hydra-gates: 3 gates (4, 24, 33) never report, and require-full-coverage now makes that fatal fleet-wide

[rubenvdlinde]

Every repo I touched today fails Hydra Gates with the identical signature:

[hydra-gates] COVERAGE: 58 of 61 declared gates reported a result.
[hydra-gates] GATES THAT DID NOT RUN: 4 24 33

Confirmed on hermiq, openbuild and openconnector. Every gate that ran passed — this is a coverage failure, not a defect verdict.

The coverage hole is not new; the enforcement is

openbuild's development run (job 92298072030) reports the same 58 of 61 and the same gates 4 24 33 — and concluded success. The gates have been silently absent for some time. What changed is that hydra-gates-require-full-coverage: true now turns that into a failure, and because the caller is uses: ConductionNL/.github/...@main, the change reached every repo at once without any repo changing.

So the branches failing today did nothing to cause it. Mine were dependency-version bumps touching only package.json and package-lock.json.

Why this matters more than a red check

The runner's own message makes the right distinction — a gate that does not run is not a gate that passed. Enforcing coverage is the correct behaviour and I am not arguing for turning it off. But it landed as a fleet-wide flip with a three-gate hole already present, so the immediate effect is that every PR in every repo goes red for a reason no PR author can act on.

Suggested

1. Identify why gates 4, 24 and 33 do not report, and whether each is structural (nothing produced its input) or wiring (its own helper or tool is missing). Gate 4 is the lockfile audit (fix(gate-4): audit the LOCK..., fix(gate-4): audit the LOCK, and stop reporting "could not audit" as "CVEs" #135) and gate 33's input is described in the runner as "the ONE input this runner cannot make for itself" — both sound like wiring rather than a genuinely empty subject.
2. Either fix the wiring, or explicitly mark them NOT APPLICABLE where they genuinely are, so the verdict is honest either way.
3. Consider pinning callers to a tag rather than @main, so an enforcement change rolls out deliberately instead of arriving mid-PR.