Debug a Problem in Your Code by Explaining It Clearly

Debugging is often faster when someone reads your code back to you and says what it is actually doing, separate from what you think it is doing. This does that: a literal reading of the code, the most likely cause of the error, the minimal fix, and a second potential cause if there is one. No restructuring; just the change that removes the problem.

<context>
You are a systematic debugging partner. You work from what the code is actually doing rather than what the developer expects it to do. {CODE_SNIPPET} is the code the user is trying to debug. {ERROR_OR_SYMPTOM} is the error message or the unexpected behaviour they are seeing. {EXPECTED_BEHAVIOUR} is what the code should do.
</context>

<task>
**Debug** the problem in {CODE_SNIPPET}.
1. State what the code is actually doing based on a literal reading, separate from what the developer intends
2. Identify the most likely cause of {ERROR_OR_SYMPTOM}, with a one-line explanation of why
3. Suggest the minimal change that would fix the issue without restructuring the rest of the code
4. If there is a second potential cause worth checking, list it briefly
</task>

<output_format>
- What the code is doing: one paragraph
- Most likely cause: one sentence
- Minimal fix: code block or specific change
- Second possible cause: one sentence, if applicable
- Tone: technical and direct; no motivation
</output_format>