fix(standards): bring the one-renderer design to main, and fix a sticky-date bug it exposed - #295
Merged
Merged
Conversation
…ky-date bug it exposed Converges main onto the GT-633 reconciliation already on develop (#294), so the standards half of develop -> main stops being a design conflict: one renderer in `test/rule-corpus-triage.ts`, two callers — the spec pins it byte-for-byte, the capture script writes it and `--check`s it for the GT-630 chain and docs.yml. AND IT EXPOSED A REAL BUG IN THAT RECONCILIATION, which is why this is not a copy-paste. The driver decided sticky-vs-fresh `capturedOn` by comparing `JSON.stringify(previous.counts)` against a counts object rebuilt in KNOWN_CLASSES order, while the renderer emits them in CLASS_ORDER — a different order for the same six numbers. So "changed" was ALWAYS true and the date was rewritten on every run. That would have failed the GT-630 fixed-point replay on any day after a capture. It passed on develop only because both runs happened on the same date and stamped the same value — the precise shape of green this chain exists to distrust. It surfaced here because main's committed snapshot carries 2026-07-29: the first run rewrote it to 2026-07-30, the second run rewrote it back. The comparison is now order-insensitive, and observed: with the classification unchanged, `capturedOn` stays 2026-07-29 across runs and the replay is byte-identical. NOTE: develop still carries the buggy comparison. It is invisible there today and will bite tomorrow; it needs the same one-function fix, which is a follow-up against develop rather than something to smuggle into a main-targeted change. Numbers on this base are main's own, measured rather than copied: native-handler 154 (develop computes 151, having fewer handler closures landed), corpus 389, mapping 391 rows. Verified: capture --check faithful, replay byte-identical, build --check up to date (391 rules, 37 mapped), iso-5055-mapping guard 9/9, chain 5 links current and at a fixed point, core-domain jest 1446 passed / 128 suites, tsc --noEmit clean, 01/04/08 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
This was referenced Jul 30, 2026
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Converges
mainonto the GT-633 reconciliation already ondevelop(#294), so the standards half ofdevelop→mainstops being a design conflict. One renderer intest/rule-corpus-triage.ts, two callers: the spec pins it byte-for-byte, the capture script writes it and--checks it for the GT-630 chain anddocs.yml.It exposed a real bug in that reconciliation
The driver decided sticky-vs-fresh
capturedOnby comparingJSON.stringify(previous.counts)against a counts object rebuilt inKNOWN_CLASSESorder, while the renderer emits them inCLASS_ORDER— a different order for the same six numbers. So "changed" was always true and the date was rewritten on every run.That would have failed the GT-630 fixed-point replay on any day after a capture. It passed on
developonly because both runs happened on the same date and stamped the same value — the precise shape of green this chain exists to distrust. It surfaced here becausemain's committed snapshot carries2026-07-29: the first run rewrote it to2026-07-30, the second rewrote it back.The comparison is now order-insensitive, and observed: with the classification unchanged,
capturedOnstays2026-07-29across runs and the replay is byte-identical.Numbers are main's own, measured not copied
native-handler154 (develop computes 151, having fewer handler closures landed), corpus 389, mapping 391 rows.Verified
capture --checkfaithful · replay byte-identical ·build --checkup to date (391 rules, 37 mapped)iso-5055-mapping.test.mjs9/9 · chain guard 5 links current and at a fixed pointtsc --noEmitclean · 01/04/08 greenEvolith Core Quality Gates
01-validate-docs.mjsgreen.04-check-bilingual-parity.mjsgreen.Linked ADRs / Issues
Conventional Commits
🤖 Generated with Claude Code