duplicate-sweep

# Sweep duplicates Two issues for one bug means two people investigate it and neither sees the other's findings. The goal is one issue per underlying problem, holding everything anyone learned. ## 1. Search the way reporters write, not the way you think The same bug gets filed as "export is broken", "CSV download 500s", and "can't get my data out". No shared vocabulary. Run several searches — the error string, the feature name, the user-facing verb — and pool the results rather than trusting one query. Include closed issues. A closed one is not evidence the bug came back — triage closes far more issues than fixes do. Treat it as a regression only when the issue records a fix that shipped or was reopened; otherwise it is just another report of the same open problem. ## 2. Same symptom is not the same bug Group only when the underlying cause is plausibly identical. Two issues that both say "page is slow" are the same report only if they are slow for the same reason; merging them buries whichever one nobody reproduced. When you are unsure, link them as related and say why rather than merging. An incorrect merge loses an issue silently, and nobody goes looking for what they think is already tracked. ## 3. Pick the survivor deliberately Not simply the oldest. Prefer the one with the best reproduction, then the most discussion, then the earliest. If the oldest is a one-line report and a later one has steps, logs, and three participants, the later one survives. ## 4. Confi...