docs(gaps): register GT-638 — the board has no id allocator - #298
Merged
Conversation
A gap id is chosen by reading the highest `GT-*` on whichever branch you are on, and nothing contrasts that with any other branch. Two parallel sessions therefore allocate the same number and one finds out at merge time. IT ALREADY HAPPENED, which is why this is a row and not a note. `8449af3d` on develop reads "renumber the ratchet fix GT-634 -> GT-637, ID collision with develop": that row and GT-634 on main took the same id within hours, from sessions that could not see each other. The renumber is manual and LOSSY, and that costs more than the clash. An id lives in the board row, the catalog anchor, the closure-evidence record, cross-references from other rows in both languages, commit messages and PR bodies — and only the first three are mechanically checkable. `08-validate-tracking` cannot help by construction: it validates within one working tree, and branches are outside its world. Nor is it an isolated slip. In the 2026-07-30 develop -> main merge the same convergent-duplication pattern appears three times: GT-633 was fixed twice by two sessions, the evidence guard's parser was fixed twice, and this id was allocated twice. A merge does not fix that. THE ID FOR THIS ROW was allocated by taking the UNION of ids across main and develop rather than the maximum on one — main was at 635, develop already had 636 and 637 — which is exactly the workaround the fix should make unnecessary. Doing it any other way would have reproduced the defect while registering it. Registered PENDING, P2/S, with criteria that ask for a check at PR time naming both users of a colliding id, and a negative fixture OBSERVED red rather than declared able to fail. Verified: 08-validate-tracking (636 gaps, 612/612 EN/ES sections, 578 closure records), 01-validate-docs (1491 files), 04 bilingual parity, 41 at 38 dead on a clean checkout against a budget of 40, 46 chain current and at a fixed point. Counters 596/635 -> 596/636, pending 21 -> 22. 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 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.
A gap id is chosen by reading the highest
GT-*on whichever branch you are on, and nothing contrasts that with any other branch. Two parallel sessions therefore allocate the same number, and one finds out at merge time.It already happened
8449af3dondevelopreads "renumber the ratchet fix GT-634 -> GT-637, ID collision with develop". That row andGT-634onmaintook the same id within hours, from sessions that could not see each other.The renumber is manual and lossy, and that costs more than the clash. An id lives in the board row, the catalog anchor, the closure-evidence record, cross-references from other rows in both languages, commit messages and PR bodies — and only the first three are mechanically checkable.
08-validate-trackingcannot help by construction: it validates within one working tree, and branches are outside its world.Not an isolated slip
In the 2026-07-30
develop→mainmerge the same convergent-duplication pattern appears three times: GT-633 fixed twice by two sessions, the evidence guard's parser fixed twice, and this id allocated twice. A merge does not fix that.The id for this row
Allocated by taking the union of ids across
mainanddeveloprather than the maximum on one —mainwas at 635,developalready had 636 and 637. That is exactly the workaround the fix should make unnecessary; doing it any other way would have reproduced the defect while registering it.Verified
08-validate-tracking(636 gaps, 612/612 EN/ES sections, 578 closure records) ·01-validate-docs(1491 files) ·04-check-bilingual-parity·41at 38 dead on a clean checkout against a budget of 40 ·46chain current and at a fixed point. Counters 596/635 → 596/636, pending 21 → 22.Evolith Core Quality Gates
01-validate-docs.mjsgreen.04-check-bilingual-parity.mjsgreen.Linked ADRs / Issues
Conventional Commits
🤖 Generated with Claude Code