One-line baseline tightening, produced by the gate's own auto-tighten
path.
`check-fnxc-future-dates` deliberately auto-tightens rather than failing
on a drop, because its population moves with the calendar and a drop has
**no author** — the counterpart asymmetry to
`check-inert-sync-lane-conversions`, where a drop *does* have an author
and must fail. Any gate run regenerates this; `main`'s committed
baseline had simply not caught up.
**Why this isn't churn:** left loose, the baseline permits 4 future
stamps in a file that now has 3. That slack silently absorbs one genuine
future-dated stamp — precisely the failure this gate exists to catch,
and one the fleet hit four times in a single day (`scheduler.ts`, a
scheduler PG test, `task-update.ts` twice by different authors), each a
real time on the wrong day that passed locally and reddened `main` for
everyone else.
Verified: both `check-fnxc-future-dates` and
`check-inert-sync-lane-conversions` green on the tightened baseline.
No changeset: tooling baseline, no published-package surface.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
8d393422ac