debuglisted

# Debug Take the reported symptom through diagnosis to a verified fix in the current session. No brainstorm spec or separate diagnosis document is required. Keep effort proportional to the uncertainty: an obvious, evidenced bug needs a short loop; an ambiguous failure needs discriminating experiments. ## Establish a useful signal Read relevant repository instructions, context, ADRs, recent changes, and the expected versus actual behavior. Record the starting Git status and relevant diff so unrelated work survives your edits and cleanup. Exercise the symptom through a meaningful public boundary: a test, CLI command, HTTP request, browser flow, replay, or focused harness. Run it and capture what demonstrates this particular failure. An unrelated setup error or a test that merely runs without crashing does not reproduce the report. Compare a working case when useful. Reduce inputs and setup only while preserving the failing signal; exhaustive minimization is unnecessary when the cause is already evidenced. For flaky behavior, repeat the trigger and report failures out of attempts, keeping relevant timing, random seeds, and environment conditions explicit. Controlled scheduling or stress can strengthen a weak signal. For performance regressions, record comparable repeated baseline measurements before editing, including workload, measurement boundary, and variation; use profiling or scaling comparisons to localize the cost. A single fast run is insufficient evidence. If repr