docs(gaps): register GT-639 — the same gap gets fixed twice, because nothing shows work in flight

[beyondnetPeru]

On 2026-07-30 the same work was done twice, three separate times, by sessions that could not see each other.

#	duplicated work	where
1	GT-633 fixed twice — a standalone capture script and an independent in-spec renderer. Both correct, both recapturing the same numbers. Two generators for one artifact is GT-633's own defect one level up, so a third session spent a full reconciliation (#294–#297) collapsing them.	#276 on main, #279 on develop
2	The evidence guard's parser fixed twice — "stop the evidence guard blaming the evidence for two parser defects" vs "the ratchet was stuck by two bugs in itself"	d1ea72a3 on main, 5acb29ed on develop
3	A GT id allocated twice, forcing a renumber	behind #298 / GT-638

The cost is not the merge conflict

It is the duplicated work that happened before anyone reached the conflict, plus the reconciliation it then required — and that reconciliation introduced a defect of its own: an order-sensitive comparison that rewrote the capture date on every run, invisible for a day because both runs stamped the same date. Three duplications, one repair session, one new bug.

Why the board cannot see it

A row carries a status but not who is working it or where. Two sessions can both read GT-633 · PENDING and both start, correctly. 08-validate-tracking validates within one working tree by construction and cannot know another branch exists.

This is not a missing convention

The single-driver rule for gap waves is already established practice. What is missing is any mechanism that makes it observable, so on a busy day it degrades silently and nobody learns until the merge. That is why the criteria ask for a claim derived from open pull requests rather than for the rule to be written down again.

Distinct from GT-638, and the row says so: that one is allocating a name twice, this one is doing the work twice. Same coordination gap; the id collision is its cheapest symptom.

The id for this row was allocated by union across main and develop, per GT-638.

Verified

08-validate-tracking · 01-validate-docs (1491 files) · 04-check-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/636 → 596/637, pending 22 → 23.

Evolith Core Quality Gates

• Bilingual Parity: row and catalog entry in EN and ES.
• Validation Scripts: 01-validate-docs.mjs green.
• Bilingual Validation: 04-check-bilingual-parity.mjs green.
• Agnosticism: documentation only.

Linked ADRs / Issues

• Link to Issue: GT-639; sibling of GT-638; observed across fix(standards): make the evaluability guard read Core, and capture the snapshot it guards #276, fix(standards): generate the evaluability capture and make its guard read Core #279, release: align main — the CLI and MCP resolve the SDK that carries the security wave, 1.2.2 (GT-634) #284, fix(standards): one renderer, two callers — reconcile the two GT-633 implementations #294–docs(gaps): register GT-638 — the board has no id allocator #298

Conventional Commits

• Commit follows Conventional Commits.

---

🤖 Generated with Claude Code

[chatgpt-codex-connector]

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

[github-actions]

📊 Bilingual Coverage Impact

PR Changes

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

Repository Coverage

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

✅ Good: All EN changes have ES counterparts.

---

Generated by GitHub Actions