reprolisted

# Repro A bug you can't reproduce is a rumor. Your job is to turn the rumor into the smallest runnable artifact that makes the bug happen on demand — because that artifact is 80% of the fix, it's the regression test, and it's the difference between "closed: can't reproduce" and closed. ## Phase 1 — Interrogate the report (and the code) Extract every concrete fact from the report: exact error text, the feature/action involved, timing ("sometimes", "after a while", "since the update"), environment hints. Then interrogate the codebase, which usually knows more than the reporter: - Search for the error message → the throwing site → walk backwards to every path that can reach it. - For each path, ask what *input or state* makes it fire. Each answer is a hypothesis. - Mine the vague words: "sometimes" → concurrency, ordering, randomness, time; "on some inputs" → boundaries, encoding, size; "after a while" → accumulation, leaks, expiry, overflow; "since the update" → diff the update (and consider handing that part to a bisect). Rank hypotheses by likelihood × ease of testing. ## Phase 2 — Hunt Build a harness that invokes the suspected code path *directly* — not the whole app — and try hypotheses in ranked order. Escalate only as needed: - Deterministic candidates first: boundary inputs, malformed data, empty/huge/unicode. - Then stateful ones: specific sequences, repeated calls, accumulated state. - Then nondeterministic ones: tight loops for races, controlled seeds for ran