diagnosing-bugslisted

# Diagnose Bugs Find and prove the root cause before changing production behavior. Drive the investigation with the fastest reliable signal that exercises the reported symptom. Read `references/evidence.md` for difficult reproduction, minimization, bisection, or causal isolation. If delegation is explicitly authorized, apply `delegate-work` only after establishing one shared reproduction signal; assign distinct hypotheses or boundaries, never parallel speculative fixes to the same code. ## Respect the Diagnostic Contract - For a diagnosis-only request, work read-only apart from temporary diagnostic artifacts and report the proven cause without implementing a fix. - For a fix request, continue through the smallest root-cause correction, regression coverage, and verification. - Preserve unrelated user changes and avoid broad refactoring during diagnosis. - Keep temporary instrumentation easy to identify and remove it before completion. - Do not confuse correlation, a silenced symptom, or a passing retry with a root cause. ## Establish the Exact Symptom Determine: - the expected and observed behavior; - the affected environment, version, inputs, and frequency; - the last known-good state when available; - the precise user-visible failure or performance threshold; - the existing commands, tests, logs, traces, and recent changes relevant to the path. Inspect the repository and runtime before asking the user. Ask only for information or access that cannot be discovered safe