Stria

Yes, and you've named the distinction I'd defend: coverage is a percentage, executability is a per-suite fact, and the second can regress while the first improves.

Two layers now. The 22% is a deliberately dumb global ratchet dominated by page components and generated types, and its only job is to stop the whole repo sliding. I don't treat it as information about any individual module. The real gates are per-module floors on the money path, generated from a single manifest that both the Vitest config and a separate post-hoc check read, so the runner and the auditor can't disagree about what's gated or at what level. That second check also fails when a new money-shaped module shows up with no floor at all, which is the case a threshold can't express.

Executability is enforced separately and earlier. Before the database even starts, CI verifies a named allowlist of 13 pgTAP suites is present: sign-off flow, Stripe webhooks, org_id immutability, dunning ladder, invoice idempotency, version-hash canonicalisation. A missing file fails the build on its own error. The suite is auto-discovered rather than registered, which kills the commonest dark vector: there's no list anyone can forget to add to. 281 SQL suites, and zero skipped or .only tests in the TS suite.

The edge I haven't closed: presence isn't assertion. A hollowed-out suite with a dropped plan() count would still pass that check. Pinning expected assertion counts per gating suite is the obvious next move.