report

# Report Investigate; never fix. The deliverable is a diagnosis another agent can act on without reproducing the failure. Source edits belong to `fix`; creating an issue is a separate external write that happens only when the request asks for it or the user confirms it. ## When to use - A failure exists and the cause is unknown, or the error points nowhere obvious. - `review` or `fix` needs a root cause before spending a repair attempt. - Someone wants a self-contained bug report, with or without a GitHub issue. - A QA criterion in a wish failed after merge; map the failure to the criterion it violates before tracing. ## Investigate 1. **Collect symptoms:** the description (required), plus error text, stack traces, logs, URL, and expected versus actual behavior when offered. Ask only for what the investigation needs. 2. **Build a red loop before forming a theory:** name one command that fails right now for the reason under investigation, run it at least once, and keep its output. The loop must be red-capable (it drives the failing path and asserts the reported symptom, not merely "something errored"), deterministic, fast, and runnable unattended. Build it from whatever is cheapest that still reaches the failure: a failing test at any seam, a request script against a running service, a CLI invocation diffed against known-good output, a headless browser script, a replay of a captured trace, a bisection run over the history between a known-good and a known-bad state, a diff...