## This is the cause of four main reds today, not a fifth instance of
them
I have now fixed the census baseline on `main` three times (#2814, plus
a withdrawn branch, plus watching #2811 and #2844 do the same). Rather
than do it a fourth time, here is why it keeps happening.
`census-baseline-corruption-guard` asserted:
```ts
expect(result).toContain("every file matches its baseline exactly");
```
That demands the **committed baseline be byte-in-step with the tree at
all times**.
**It is not, by design.** A conversion PR that removes guards leaves the
tree holding *fewer* than the baseline allows, and the CLI treats that
as the good case — it tightens the pin and exits 0. Measured directly:
```
simulated drop → EXIT ON DROP: 0
"The baseline file has been rewritten downward. COMMIT IT …
in CI this write is discarded with the runner, which is why the gate is green and not silent."
```
So the ratchet was already happy while this test went red. Every
conversion that did not *also* re-record the baseline turned `main` red
for a condition that was never a defect.
That is the mechanism behind **#2783's markers, #2837's query split and
two more** — plus three collisions between workers racing to re-record
the same file (#2811/#2814, #2844, and a branch of mine I deleted rather
than open as a duplicate).
## The fix matches the guard's own stated intent
Its comment says: *"a guard that always fails is no guard"* — its job is
to prove the **corruption** diagnosis does not false-positive on a
healthy file. **A tightened baseline is healthy.** So it now asserts
what that needs:
- the run **succeeds** — `execFileSync` throws on a non-zero exit, so a
**rise still fails before any assertion runs**; a rise is real debt and
must stay loud
- the corruption diagnosis is **absent**
- the outcome is one of the two healthy shapes the CLI can report
## Measured discrimination — all four cases
| scenario | before | after |
|---|---|---|
| **drop** (legitimate conversion) | ❌ 1 failed — *the false red* | ✅ 3
passed |
| **rise** (real debt) | ❌ fails | ❌ **still fails** |
| **corrupt JSON** | ❌ fails | ❌ still fails (case unchanged) |
| **unreadable file** | ❌ fails | ❌ still fails (case unchanged) |
Only *"somebody converted guards and has not re-recorded the pin yet"*
stops being a red.
## Scope
Engine **11022 passed / 0 failed** · gate **732 green** · lint clean.
Test-only.
**Does not change** the CLI, the ratchet, or what `--strict` reports.
Re-recording the baseline on a drop is still the right thing to do — it
just stops being an emergency that reddens main and blocks everyone else
while three people race to fix it.
The baseline file is restored byte-clean after every simulation above
(`git diff` verified).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Tests**
- Expanded baseline validation coverage to detect unreadable or invalid
baseline data.
- Added support for both exact baseline matches and successfully
tightened baselines.
- Improved health checks for baseline verification outcomes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
b9785ec10f