parallel-pr-template-fork-duplicates-moved-sectionlisted

Diagnose silent semantic duplication after two parallel PRs ship. Use when: (1) one PR (the **mover**) relocates a section/component/block from template X to template Y (X loses it, Y gains it), (2) a sibling PR (the **forker**), authored against pre-mover main, creates / promotes / copies template Z from the OLD version of X (when X still contained the section), (3) both PRs squash-merge without textual conflict because they touch different files, (4) after both deploy, the section appears on BOTH the mover's destination Y AND on the forker's route Z. Symptom is user-visible: "I see this radar / card / nav block in two places, why?" Root cause is structural — git's textual 3-way merge can't see that file Z ⊆ pre-mover-X. Fix: hand-delete the section from one location (usually the forker's), update tests if any asserted on the duplicate render. Prevention: when the mover merges first, rebase the forker BEFORE squash and audit any moved sections; or add a cross-route uniqueness test (`grep -c "<section-id>"` a
wan-huiyan/agent-traffic-control · ★ 2 · Data & Documents · score 79

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

# Parallel-PR Template Fork Duplicates Moved Section ## Problem Two PRs ship within hours of each other. Neither shows a textual merge conflict. Both pass tests. Both deploy cleanly. After deploy, a user reports "this section is appearing in two places now — that's wrong, right?" The mechanism is structural, not textual: - **PR #A (mover)**: relocates a `<section>...</section>` from template `X.html` to template `Y.html`. `X` loses the block; `Y` gains it. - **PR #B (forker)**: promotes / copies / forks `X.html` into a new template `Z.html` (e.g., the route is moving up in the IA, or the page is being split). The fork is literal — `Z.html` was authored as a near-copy of `X.html` *as it existed before the mover landed*. - The two PRs touch *different files* on disk. Squash-merge is "clean" by git's textual measure: `X` lost a block (mover), `Y` gained it (mover), `Z` was added (forker). No 3-way merge conflict. - Reality: `Z` was forked from a snapshot of `X` that *still contained* the section. So after both ship, the block lives in BOTH `Y` and `Z`. The user sees the duplication immediately. Code review on each PR in isolation wouldn't have caught it — each diff was correct against its own base. ## Trigger conditions ALL of these are typically true: 1. Two PRs merged to main within a short window (hours / a day), authored independently. 2. One PR's diff includes lines that look like "move section from X to Y" — classic markers: deletion in one temp