## Main is red; this fixes it
`packages/engine/src/__tests__/census-baseline-corruption-guard.test.ts`
fails on `main`:
```
× the census fails readably on a corrupt baseline > still succeeds against the repo's real baseline
→ expected 'lifecycle-column-census: scanned 1960…' to contain 'every file matches its baseline exact…'
```
A conversion took `packages/core/src/task-store/moves.ts` from **2
column guards to 0** without re-recording the baseline. `--strict` then
reports `TIGHTENED` instead of the exact-match line the guard asserts.
## The whole diff
```diff
- "packages/core/src/task-store/moves.ts": 2,
```
One removed allowance. Nothing else moved.
## Why committing it is the prescribed workflow, not a workaround
The census says so itself when it tightens:
> The baseline file has been rewritten downward. **COMMIT IT** so the
allowance cannot be regrown into;
> in CI this write is discarded with the runner, which is why the gate
is green and not silent.
That discard is the reason this recurs: the tightening only ever
persists if a human commits the side-effect file, so a conversion PR
that does not re-record leaves `main` red for the next person. Leaving
the stale `2` in place would also keep an allowance open for guards to
regrow into, which is the ratchet's entire purpose.
**This cannot hide a regression.** `--strict` fails hard on a *rise*; it
only rewrites when counts **drop**. An exit-0 tighten means every change
was downward.
## Verification
- `census-baseline-corruption-guard.test.ts` — **3/3**
- `pnpm check:lifecycle-columns` — **exit 0**, "every file matches its
baseline exactly"
Not my change to `moves.ts` — found while running the full
`engine-default` project (736 files) looking for fallout from my own
merged fixes. That sweep also turned up a second red, fixed separately
in #2840.
No changeset: the baseline is internal tooling state, not published
behaviour.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
3a5058edd8