# Bug Triage

## Purpose

Frame a defect clearly before or during debugging so the team understands impact, reproduction, suspected scope, and next actions.

## When to use

- A bug report arrives with incomplete detail
- A failing test or regression needs initial framing
- Multiple issues compete for attention and severity matters
- You need a reliable reproduction path before deeper debugging

## Inputs to gather

- Reported symptoms, expected behavior, and actual behavior
- Reproduction steps, environment, and frequency
- User impact, severity, and likely affected surfaces
- Recent changes, logs, or tests that may be related

## How to work

- Turn vague symptoms into a concrete problem statement.
- Reproduce the issue when possible and tighten the reproduction steps.
- Separate confirmed facts from assumptions.
- Estimate impact and likely blast radius before diving into fixes.
- Identify the next best debugging step if root cause is not yet known.

## Output expectations

- Clear bug statement and reproduction status
- Impact and severity assessment
- Suspected scope or likely component area
- Recommended next debugging or fix step

## Quality checklist

- The issue is described in observable terms rather than guesses.
- Reproduction details are specific enough to be reused.
- Impact is clear enough to prioritize intelligently.
- Unknowns are named instead of hidden.

## Handoff notes

- Record environment details and whether the issue is deterministic, intermittent, or unconfirmed.
- Pair with debugging workflow once the problem is framed well enough to investigate deeply.