debuglisted

# Debug Symptom: `$ARGUMENTS` Empty means the failure described in the conversation so far. If there isn't one, ask for the exact error text or the failing command. One question. ## The rule No fix before the cause is known. "Try changing X and see" is not debugging; it's the thing that produces the second bug. If a fix is tempting before the cause is written down, that's the signal to slow down. ## Order 1. **Confirm the symptom.** Something observable: the full error text, the stack trace read bottom to top, the failing command and its exit code, the wrong value. Not the description of it. 2. **Reproduce.** Exact steps, smallest input, run it. If it can't be reproduced, that's the job now. Nothing gets fixed that can't be seen failing. 3. **Boring causes.** Is the code actually deployed and running, which version, which host. Environment and config. Stale cache or build. Changed input or data. Expired credential or certificate. Disk, memory, file descriptors. DNS. Each one is a check, not a thought. 4. **What changed.** `git log` since it last worked. Deploys, config, dependencies, data, traffic. Most bugs have a birthday. 5. **Find the working twin.** Similar code that works, in this codebase or the reference implementation. Read it whole. Diff the two. The difference is usually the bug. 6. **One hypothesis, written.** "The cause is X because Y. If true, Z will show it." Then the one check that confirms or kills it. Run it. Dead? Next hypothesis. Never two at once; t