debuglisted

Investigate the issue: $ARGUMENTS Hard rule: do NOT write any fix until Phase 3 is reached and the user (or the evidence in Phase 2) has confirmed the root cause. ## Phase 1 - Evidence **why-not-mechanizable:** skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state). Gather, do not theorize. Save findings to `.claude/state/research/YYYY-MM-DD-debug-<short-slug>.md`. - If given a Sentry issue (short ID like `PROJECT-ABC`, numeric ID, or sentry.io URL), fetch the digest first via the `sentry-issue` skill: `~/.claude/skills/sentry-issue/scripts/sentry-issue.sh <id>`. Full payloads land in `/tmp/sentry-{issue,event}-<id>.json` for deeper `jq` queries. `(review-time: see section note)` - Reproduce locally if feasible. Capture exact error, stack trace, request ID, timestamp. `(review-time: see section note)` - Pull logs (Sentry, Cloud Run, container, browser console) for the affected window. `(review-time: see section note)` - `git log -p --since='2 weeks ago' -- <suspect-paths>` to surface recent changes that touched the code path. `(review-time: see section note)` - Confirm scope: how many users / requests / environments are affected. `(review-time: see section note)` - Check related state: env vars set on the deployed service, DB row state, feature flags, recent deploys. `(review-time: see section note)` If the user already supplied a hypothesis, treat it as a candidate but still gather evidence to confirm or reject