Skip to content

fix(standards): the sticky capture date was rewritten on every run - #296

Merged
beyondnetPeru merged 1 commit into
developfrom
fix/sticky-capturedon-develop
Jul 30, 2026
Merged

fix(standards): the sticky capture date was rewritten on every run#296
beyondnetPeru merged 1 commit into
developfrom
fix/sticky-capturedon-develop

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Ports to develop the bug found while bringing the same design to main (#295).

classificationChanged compared JSON.stringify(previous.counts) against a counts object rebuilt in KNOWN_CLASSES order, while the renderer emits them in CLASS_ORDERa different order for the same six numbers. So it always reported "changed", capturedOn was refreshed on every run, and the GT-630 fixed-point replay would have failed on any day after a capture.

Why it was invisible here

The reconciliation (#294) landed and was verified on the same day the snapshot was captured, so both runs stamped 2026-07-30 and the bytes matched. A green that depends on the date not having changed is exactly the kind this chain exists to distrust. It surfaced on main only because that branch's committed snapshot carried 2026-07-29, so the two runs disagreed out loud.

Observed both ways, not declared

Forcing the committed date to 2026-07-28 and running the capture with the classification unchanged:

capturedOn after the run
without the fix 2026-07-30 — drift
with the fix 2026-07-28 — sticky, as designed

Verified after restoring the committed snapshot

--check passes · the replay is byte-identical · derived-artifact chain reports 5 links current and at a fixed point · ISO/IEC 5055 mapping guard 9/9. Only the script changed.

Evolith Core Quality Gates

  • Bilingual Parity: no bilingual document changed.
  • Validation Scripts: unaffected — no Markdown under reference/ touched.
  • Bilingual Validation: as above.
  • Agnosticism: no new technology dependency.

Linked ADRs / Issues

  • Link to Issue: GT-633 / GT-630 (the fixed-point property this restores)

Conventional Commits

  • Commit follows Conventional Commits.

🤖 Generated with Claude Code

Ports to develop the bug found while bringing the same design to main (#295).

`classificationChanged` compared `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 it always reported
"changed", `capturedOn` was refreshed on every run, and the GT-630 fixed-point
replay would have failed on any day after a capture.

WHY IT WAS INVISIBLE HERE. The reconciliation (#294) landed and was verified on
the same day the snapshot was captured, so both runs stamped 2026-07-30 and the
bytes matched. A green that depends on the date being unchanged is exactly the
kind this chain exists to distrust. It surfaced on main only because that branch's
committed snapshot carried 2026-07-29, so the two runs disagreed out loud.

OBSERVED BOTH WAYS rather than declared, by forcing the committed date to
2026-07-28 and running the capture with the classification unchanged:

  without the fix -> capturedOn becomes 2026-07-30   (drift)
  with the fix    -> capturedOn stays   2026-07-28   (sticky, as designed)

Verified after restoring the committed snapshot: `--check` passes, the replay is
byte-identical, the derived-artifact chain reports 5 links current and at a fixed
point, and the ISO/IEC 5055 mapping guard is 9/9. Only the script changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@beyondnetPeru
beyondnetPeru requested a review from a team as a code owner July 30, 2026 14:40
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 6
  • New EN files needing ES translation: 3

Repository Coverage

Metric Value
Total EN files 524
Total ES files 498
Paired files 0
Coverage 0%

⚠️ Action required: 3 new EN file(s) added without ES counterparts.

To create skeletons:

node .harness/scripts/generate-es-skeleton.mjs <file.md>

Generated by GitHub Actions

@beyondnetPeru
beyondnetPeru merged commit 745274d into develop Jul 30, 2026
33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant