## The immediate hole
Main's baseline allowed **27** guards in
`packages/engine/src/scheduler.ts` while the tree has **26**. A
re-introduced guard there would have kept `check:lifecycle-columns`
green.
This is the merge-order collision I flagged on #2693: **#2690 and #2693
each converted a different `scheduler.ts` site and each recorded 28 →
27.** After both merged the true count is 26, and neither re-recorded
it. Predicted in #2693's body; this is the cleanup.
## The more important finding: `--strict` reports the stale allowance
and exits 0
```
$ node scripts/lifecycle-column-census.mjs --strict
packages/engine/src/scheduler.ts: allows 27, tree has 26
$ echo $?
0
```
So the required check is **green while the hole is open** — the script
detects the condition and does not enforce it. That is precisely the
failure mode its own message warns about:
> *"A stale allowance is a hole: those guards can be reintroduced later
and this check stays green."*
**I did not flip it.** Making `--strict` fail is a CI-policy change that
would block every PR until each stale baseline is re-recorded — and that
exact situation just blocked the queue (three PRs, #2673/#2674/#2676,
raced to un-red this check). Reversible-by-me stops short of "block
everyone's merges", so it is flagged for an owner with the reproduction
above.
Related, and worth knowing before anyone debugs a dirty tree:
**`--strict` writes the baseline as a side effect of the check.** A
plain verification run mutates
`scripts/lib/lifecycle-column-census-baseline.json`. That is how this
re-record was produced, and it is why an earlier PR of mine had to
revert an unintended baseline edit.
## What is in the diff
Re-recorded from the tree and verified against the live census before
committing:
| | baseline | tree |
|---|---:|---:|
| `column` total | 693 | **692** |
| `in-progress` | 136 | **135** |
| `scheduler.ts` | 27 | **26** |
| `deliberate` | 17 | **20** |
**The `deliberate` movement is not mine.** `RoutineEditor.tsx`,
`ScheduleForm.tsx` and `ScheduleStepsEditor.tsx` each carry a real
`DELIBERATE-LITERAL` marker in the tree (verified by grep, not inferred
from the diff), and three `deliberateByFile` keys gain their `triage`
scope. Those came from merged PRs that likewise did not re-record. This
commit records the tree's actual state; it does not endorse those
markers, and anyone auditing the deliberate list should look at those
three rather than assume they were reviewed here.
`--strict` now reports *"every file matches its baseline exactly"*.
## Verification
Baseline-only change — no source, no tests. `--strict` clean; census
reads COLUMN 692 · ROLE 5 · STATUS 186 · DELIBERATE 20 · QUERY 83.
03443297db