synthetic-id-collision-rebaselisted

Fix the "I claimed cat7-7bg, they claimed cat7-7bg, theirs merged first" failure mode when rebasing a PR after parallel sessions land mid-flight. Use when: (1) rebasing a stale PR onto current main produces a conflict in an append-only register file (tracker entries, ADR `NNNN-` prefixes, migration filenames, OpenAPI operationIds, error codes, lessons.md `## N.` numbering), (2) BOTH your branch and a freshly-merged branch added an entry under THE SAME synthetic ID — the collision is namespace, not just text, (3) plain "accept both sides" yields two rows with identical IDs that violate the file's invariant, (4) multiple Claude Code sessions share a working tree and each picked "next free letter" from their local view of the file. Prescribes a reroll workflow: scan ALL taken IDs in current main, pick truly-next-free, replay only your entry under the new ID, regenerate any derived artifacts (site, indexes), force-push. Also covers the variant where git splits the conflict boundary mid-argument-list of a multi-li
wan-huiyan/agent-traffic-control · ★ 2 · AI & Automation · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Synthetic ID Collision During Multi-Session PR Rebase ## Problem You opened a PR that adds an entry to an append-only register — `Item("cat7-7bg", ...)` in a roadmap tracker, `0017-foo.md` ADR, `V025__add_index.sql` migration, `## 144. ...` in `lessons.md`, `errcode: "E_QUOTA"` in an error catalog. You picked the ID by reading the file and grabbing the next free slot. Meanwhile, a parallel session — or a co-author, or your own work in another worktree — also picked the same ID. **Their PR merged first.** Now your PR is `mergeable: CONFLICTING / DIRTY`, and even after reading their version, the conflict isn't really about content alignment — it's that **the synthetic ID itself is taken**. A 3-way merge that "accepts both sides" produces two rows with identical IDs, which violates the file's primary key. This is a particularly nasty failure because: 1. The conflict resolution `--theirs` keeps their entry under the ID you wanted; your work is silently dropped. 2. The conflict resolution `--ours` overwrites their already-merged entry; your work shows up under their ID, blowing away their data. 3. The naive "merge both" appends two `cat7-7bg` rows; tooling that keys on the ID picks the first, hides the second. ## Context / Trigger Conditions All four hold: 1. Your PR is conflicting after a mid-flight merge from another branch (often: another Claude Code session sharing the same working tree). 2. The conflicting file is an **append-only register** keyed by a synthetic ID, w