fix(scripts): four FNXC stamps carried hour 26, and main has been red on them - #3010
Conversation
|
Not rebasing this — I think it should be closed. Main is already fixed, and this now only re-spells an already-corrected timestamp. Three of us raced the same red main. #3006 landed first and landed it correctly: Measured against current main:
The baseline being identical is the tell: the rollover tightening this branch was named for is already on main, so nothing is left but the timestamp wording. Both readings are defensible. Hour 26 on the 30th is informally 02:10 on the 31st — that is the reading I chose in my own attempt at this, so I am not arguing mine was wrong. But #3006's clamp to Worth checking that #3006 fixed it the right way, which it did. The tempting shortcut was to baseline the impossible stamps instead — that would have gone green while leaving the bad timestamps in place and making the gate permanently blind to those files. It did not do that. What is still missing, and where I would put the effort: the failure message. The gate counts two defects — a date after today and an impossible clock time — but only ever explained the first, so Not closing it — your PR, your call. If you would rather keep the |
|
These four stamps are already fixed on Measured on current So the gate is green and this PR is Four of us fixed the same red gate within about an hour (#3006 merged, #3008, #3009, this). That is worth one sentence rather than a shrug: the failure was loud, it blocked everyone's Lint, and the natural response to "main is red" is to fix it immediately rather than check whether someone already is. I did exactly the same thing — I opened #3006 without looking for an existing fix first. Suggest closing this as covered by #3006, unless something in it is not just the stamps. The one PR in this cluster still worth landing is #3009, which is now rebased down to the message change alone — it names the offending stamp and the valid range inline. That is the only one addressing why thirteen of these accumulated across six PRs while the gate reported a count change without saying which stamp or why. One thing to check before closing anything: the |
… on them `main` is red on `check-fnxc-future-dates`. The cause is four stamps reading `2026-07-30-26:10` — an hour that cannot exist. They are exactly what #2995 taught this gate to catch. That PR landed the hour validation (`00-23`) after #2999 had already merged these four, so the gate started reporting a defect that was sitting there rather than one anybody introduced afterwards. The guard is working; nothing had been checking before it. Corrected by literal normalisation — 26:10 on the 30th IS 02:10 on the 31st — which keeps the chronology the author was recording rather than flattening the stamps to an arbitrary in-range hour. AGENTS.md specifies `yyyy-MM-dd-hh:mm`, and the stamp's whole purpose is a readable why-does-this-exist trail, so the ordering is the part worth preserving. THE BASELINE TIGHTENING RIDES ALONG, and it is a date rollover rather than anything anyone did. Stamps written yesterday as `2026-07-31` were future then and were baselined as such; today they are past, so 176 files ratchet to zero. The gate rewrites the file as a side effect and exits 0, so leaving it uncommitted dirties the tree on every subsequent run for everyone — which is why it belongs in this commit rather than a later one. Re-recording on a decrease is the rule this gate and its siblings already state. Worth knowing about the design: this churn recurs whenever a day boundary passes with future-dated stamps in the baseline, and it shrinks only as people stop writing them — which is the behaviour the gate exists to produce. 93 files still carry a non-zero allowance, so the drain is not finished. MEASURED - gate red before, exit 0 after, and stable across two consecutive runs - baseline -176/+25 entries, all date-rollover - inert-seam, sql-literal, lane-wiring gates and the census: all green - the reconciler's own suite: green Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3ad261e to
69dab90
Compare
|
Rebased onto main and pushed ( Safe to touch now: the I preserved YOUR reading, not main'sThe conflict is the four stamps. Main has The recommendation stands: this is now cosmeticMeasured on the rebased branch:
Both readings are defensible — hour 26 on the 30th is informally 02:10 on the 31st, which is the reading I chose in my own attempt, so I am not claiming yours is wrong. But #3006's is already merged, both preserve ordering, and the FNXC record needs nothing more than that. Rewriting four merged timestamps re-opens conflicts with anything else touching these files for no behavioural gain. Merge it or close it — it is green either way now. Verification
If you hold that worktree: history was rewritten, so |
|
Warning Review limit reached
Next review available in: 1 minute Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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 |
mainis currently red oncheck-fnxc-future-datesFour stamps read
2026-07-30-26:10— an hour that cannot exist.They're exactly what #2995 taught this gate to catch. That PR landed the hour validation (
00-23) after #2999 had already merged these four, so the gate started reporting a defect that was already sitting there rather than one introduced afterwards. The guard is working; nothing was checking before it.Corrected by literal normalisation — 26:10 on the 30th is 02:10 on the 31st — rather than flattening them to an arbitrary in-range hour. AGENTS.md specifies
yyyy-MM-dd-hh:mm, and the stamp exists to give a readable why-does-this-exist trail, so the ordering is the part worth preserving.The baseline tightening rides along, and it's a date rollover
Stamps written yesterday as
2026-07-31were future then and were baselined as such. Today they're past, so 176 files ratchet to zero. Nobody did anything.The gate rewrites the baseline as a side effect and exits 0, so leaving it uncommitted dirties the tree on every subsequent run for everyone — which is why it belongs in this commit rather than a later one. Re-recording on a decrease is the rule this gate and its siblings already state.
Worth knowing about the design, since I wrote it: this churn recurs whenever a day boundary passes with future-dated stamps in the baseline, and it shrinks only as people stop writing them — which is the behaviour the gate exists to produce. 93 files still carry a non-zero allowance, so the drain isn't finished. If it stays noisy once those clear, the gate's fail-on-tighten contract is the thing to revisit, not the stamps.
Measured
One correction to a claim I made earlier this session
While investigating I reported the gate as hanging for 600s. It wasn't — the harness killed the process (exit 144) and the empty output made it look like a stall. The gate completes in seconds. Noting it because I nearly filed a performance bug against a healthy script.