| name | bug-reproduction |
| description | Reproduce a reported customer issue from exact environment, inputs, account state, sequence, and evidence so engineering receives a bounded defect instead of an anecdote. |
Support Bug Reproduction
Use when a support case may represent a product defect that needs engineering investigation.
Procedure
- Capture the reported symptom, expected behavior, user impact, timestamps, account/workspace, platform, version, and any request or error identifiers already available.
- Separate what the customer observed from assumptions about root cause.
- Reproduce in the safest representative environment using the smallest sequence that preserves the failure.
- Vary one dimension at a time to isolate prerequisites such as account state, permissions, data shape, device, network, version, or feature configuration.
- Collect relevant logs, screenshots, traces, responses, or state while minimizing sensitive customer data.
- Determine whether the issue is reproducible, intermittent, environment-specific, already fixed, expected behavior, or still unconfirmed.
- Write a handoff containing exact steps, expected vs actual behavior, environment, frequency, impact, evidence, and the smallest known boundary of the problem.
- Re-test the same reproduction after a proposed fix when support is asked to validate it.
Decision rules
- Do not diagnose from the ticket title alone.
- Never alter customer data destructively just to reproduce a defect.
- One failed reproduction does not disprove an intermittent report.
- Root-cause ownership transfers to the relevant engineering specialist once the defect is bounded.
Quality gate
The escalation is engineering-ready when another specialist can reproduce or meaningfully investigate the issue from the packet, customer-sensitive material is minimized, observed facts are separated from inference, and impact and environment are explicit.
