## A policy with nothing enforcing it
AGENTS.md states the deletion ratchet plainly:
> A quarantined test is **DELETED after 14 days** (`quarantinedAt` + 2
weeks) unless rescued.
Nothing enforced it, and it failed in two independent ways:
1. **`check:quarantine-ledger` omitted `--strict`.** The script only
exits non-zero with that flag (`check-quarantine-ledger.mjs:197`:
`return args.strict && (summary.expired > 0 || summary.near > 0) ? 1 :
0`). Without it, it is a report that always exits 0.
2. **No workflow ran it.** I audited all 12 `check:*` scripts against
`pr-checks.yml` and `full-suite.yml`: this is the only one appearing in
neither.
Either alone would have made it toothless. Together, a quarantined test
could sit past its deletion date indefinitely with every gate green.
## This exact shape is already documented in the file I edited
The comment above the lifecycle-column ratchet in `pr-checks.yml` says:
> `pnpm census:lifecycle-columns` (no `--strict`) and nothing ran it, so
three PRs lowered counts without re-recording and left allowances the
deleted guards could return through while this gate stayed green.
Script supports enforcement → package script omits the flag → no
workflow runs it. Same three steps, different ratchet. That precedent is
why I went looking.
## What changed
- `check:quarantine-ledger` now passes `--strict`
- wired into `pr-checks.yml` beside its siblings
It fires **5 days before** the deadline, not after, so the response is
still delete-or-rescue rather than an overdue entry. That window is the
script author's design; I did not invent it.
## Mutation evidence
Against a temp ledger, real one restored after:
| Ledger state | Result |
|---|---|
| today (1 entry, 13 days remaining) | exit 0 |
| entry inside the 5-day near window | **exit 1** |
| entry 6 days past deadline | **exit 1**, reports `EXPIRED (6 days
overdue)` |
| real ledger restored | exit 0 |
Without `--strict` all four exit 0 — which is the state on `main`.
## Honest note on what this will do
This is a **deadline ratchet**: it fires on a timer by design. The
current entry (`useTasks-hydration-freshness.test.ts`, deadline
2026-08-13) will trip it on **2026-08-08** unless someone deletes or
rescues it first. That is the intended behaviour and the whole point —
AGENTS.md is explicit that rescue "requires evidence the test catches
real regressions plus a root-cause fix — not stabilization passes." A
gate that never fires enforces nothing.
## Census before / after
```
before: COLUMN guards (the backlog): 13
after: COLUMN guards (the backlog): 13
```
Unchanged — this touches no lifecycle guard. It is gate wiring.
## Verification
`test:gate` exit 0 · `check:quarantine-ledger --strict` exit 0 on the
real ledger · both failure arms mutation-verified · ledger file restored
byte-for-byte.
bc37185026