bug-report-forensicslisted

# Bug Report Forensics A bug report is not a message. It is an **argument** that (a) something is wrong, (b) here is proof, (c) here is the cheapest path to see it again, and (d) here is what it costs. Reports that skip any of the four generate a round trip, and a round trip costs more than the report did. Your job is to produce a report where **the developer's first action is to fix, not to ask.** ## Before writing anything: three gates Run these in order. Failing a gate changes the output, so do not skip ahead. **Gate 1 — Is it a bug?** Something can be unexpected without being wrong. Ask which oracle is violated: a written requirement, a documented API contract, a consistent pattern elsewhere in the product, a standard (HTTP, WCAG, ISO date), a user's reasonable expectation, or the product's own prior behaviour. If you cannot name an oracle, this is a *question* or a *change request*, and it must be labelled as one. Say so plainly rather than filing it as a defect. **Gate 2 — Is it already known?** Search the tracker for the error string, the endpoint, the screen name, and the symptom in the reporter's own words. A duplicate filed as new fragments the history of a defect and delays the fix. If a related ticket exists, decide: is this the same defect (comment there), or a different defect with a shared root cause (file new, link with "related to")? **Gate 3 — Is the reproduction minimal?** See the next section. An unminimized repro is the single most common reason a