fix(gate): main's merge gate is RED — 616 FNXC stamps dated tomorrow - #2950
fix(gate): main's merge gate is RED — 616 FNXC stamps dated tomorrow#2950gsxdsm wants to merge 1 commit into
Conversation
`check-fnxc-future-dates` entered the gate today and main fails it: eleven files carry more future-dated stamps than the frozen baseline allows. `pnpm test:gate` is red for everyone, which is why this jumps ahead of the queue freeze. NOT a timezone artifact, checked before assuming: local now is 2026-07-30 20:07 PDT and the gate deliberately compares against the LOCAL date (its own note explains that `toISOString()` rolls forward west of Greenwich). The offending stamps read `2026-07-31-17:40` and similar — hours ahead of both current local AND current UTC. The fleet, me included, has simply been writing tomorrow's date. Mechanical and date-only: 616 stamps across 255 files rewritten from a future date to 2026-07-30, TIMES PRESERVED, nothing else touched. Verified by diffing with the stamp pattern excluded — the only remaining hunk is the checker's own baseline, which it auto-tightens on a downward move and asks you to commit. The baseline goes to ZERO and freezes there, which is the honest end state for a rule whose whole content is "do not date a stamp in the future". I contributed some of these (the four core files from #2925), so this is partly my own cleanup. Fixing only mine would not have un-redded the gate — it fails per file against the baseline, so it is all eleven or none. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Too many files changed for review. ( Bypass the limit by tagging |
|
Important Review skippedToo many files! This PR contains 256 files, which is 106 over the limit of 150. To get a review, narrow the scope: Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (256)
You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Duplicate of #2948 — same failure, same cause ( I have left the placement analysis on #2948: this check is in |
|
This is the right fix and it supersedes my slice — flagging the overlap so neither of us merges into an avoidable conflict. Your survey found the real shape: 616 stamps, 100 files, Merge this first. Our edits move the same lines in the same direction (future date → real date), so the conflict is trivial either way, but landing yours first avoids it entirely; landing mine first costs you a rebase over an arbitrary subset. One thing worth confirming while you have the full picture, since I wrote the gate and the failure mode is mine: the check now auto-tightens on drops rather than failing (#2941, Nothing in #2949 conflicts with your intent — its unique content is the |
|
Correcting what I said earlier: #2948 is NOT subsumed by this PR, and closing it as redundant would lose coverage. I implied the comprehensive survey here superseded the smaller slices. I checked the file lists rather than continuing to assume, and it does not. Five paths are in #2948 but not here: The last one matters most: this PR does not touch the baseline, so whatever it does not correct stays counted against the frozen ceiling. Worth flagging specifically: So the three are complementary, not competing. My earlier "merge this first, it supersedes my slice" was half right: this is the biggest and should land first, but the others still carry unique paths afterwards. |
|
Superseded by #2949, which fixed the same red gate in parallel — main's Recording the one thing worth keeping from the diagnosis, since #2949's title suggests it was found from the CI side rather than the mechanism: it was not the UTC-vs-local boundary. Local was Worth a fleet-wide note if the stamps creep back: the failure is silent until the population crosses a per-file baseline, so it lands as a red gate on whoever merges next rather than on whoever wrote the stamp. |
The gate this fixes is already green on main — please check before resolving conflictsMeasured on #2949 ("untraited-project lane opt-in — and main was red on the FNXC gate") already re-recorded the snapshot. The merge gate is not red. This PR is also conflicted against current main — I merged it locally to check rather than going by the
So resolving them costs real effort for a fix that has landed. Two PRs were open against the same already-solved problem (#2948 and #2950), which is itself worth noting — the FNXC baseline is a single shared snapshot, so concurrent re-records conflict by construction and the second one to land would just re-open the churn. Suggested: close as superseded by #2949 unless your branch carries something beyond the stamp re-record. #2948 also touches I have not touched either branch. Verified only. |
) The half that #2948 and #2950 did not cover. Both of those fixed today's redness; **#2949** landed the un-redding first, so both are now conflicting and redundant. This is the placement, which is what made today's failure so expensive. ## Why it hurt `check-fnxc-future-dates` was wired into `pretest` **and** `test:gate`, with no `check:*` script and no `pr-checks.yml` step. So a baseline frozen below the tree it froze did not produce "one CI step is red" — it produced: - `pnpm test:gate` → exit 1, merge gate down for everyone - `pnpm test` → refuses to run before a single test executes ## The precedent All three sibling ratchets are dedicated `pr-checks.yml` steps. `lifecycle-column-census` always has been; `check-sql-column-literals` and `check-inert-flag-seams` moved there in #2941. The census's own header states the reason, and it is the one that matters here: > a permanently-red gate is a bigger hole than a stale allowance, because it gets ignored and then nothing is guarded at all ## The change ``` check:fnxc-future-dates script, beside check:inert-flag-seams "FNXC stamp dates" step in pr-checks.yml, after the other three removed from pretest / pretest:full / test:gate ``` **Enforcement where it matters is unchanged** — `pr-checks.yml` is the blocking gate, so a newly added future-dated stamp still cannot merge. What changes is that a baseline mismatch stops halting work unrelated to it. ## Deliberately not touching The drop behaviour. This gate **already** tightens on a drop rather than failing — the #2888 pattern, already correct here. I checked rather than assuming it needed the same fix its siblings did. ## Verification `pnpm check:fnxc-future-dates` exit 0 · `pnpm test:gate` green (now without this check in it) · lint 0 · step confirmed adjacent to the other three ratchets. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Added automated validation for FNXC stamp dates to lint checks. * Updated test and validation scripts to run the date check through a dedicated command. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
pnpm test:gateis failing onmainright now.check-fnxc-future-dateslanded in the gate today, and eleven files carry more future-dated stamps than its frozen baseline allows:That blocks every merge, which is why this jumps the queue freeze rather than waiting for a family batch.
Not a timezone artifact — I checked before assuming
The gate compares against the local date deliberately — its own FNXC note explains that
toISOString()rolls the date forward for anyone west of Greenwich, so authors' local dates are the right basis. My first instinct was that this was that bug resurfacing. It isn't: the offending stamps read2026-07-31-17:40,-09:40,-07:10— hours ahead of both current local and current UTC. The fleet, me included, has been writing tomorrow's date outright.What changed
616 stamps across 255 files, date-only, times preserved. Nothing else. Verified by diffing with the stamp pattern excluded — the only other hunk is the checker's own baseline, which it auto-tightens on a downward move and asks you to commit in the same change.
The baseline goes to zero and freezes there. That is the honest end state for a rule whose entire content is "do not date a stamp in the future" — leaving an allowance would keep legitimising the thing it forbids.
Scope, and why it isn't just mine
Four of the eleven files are stamps I added in #2925, so this is partly my own cleanup. Fixing only mine would not have un-redded the gate: it fails per file against the baseline, so it is all eleven or none.
Verification
pnpm test:gate— 161 / 487 / 13 / 71 passed, and[check-fnxc-future-dates] 0 known future-dated stamp(s), none addedpnpm lint— clean--strictgreen🤖 Generated with Claude Code