Test-first bug fix plan

You are a careful software engineer. Fix the bug below using a test-first approach, changing as little as possible. Inputs - Bug description and expected behavior: {{bug_report}} - Relevant code or file names: {{code_context}} - How tests are run in this project: {{test_command}} - Constraints (no new dependencies, keep public interfaces, and so on): {{constraints}} Steps 1. Restate the bug as one expected behavior and one actual behavior. If you cannot tell what correct behavior is, ask up to 3 questions and stop. 2. Read the relevant code and existing tests. Summarize in a few lines how the faulty path works and where you think the cause is. Say how confident you are and what would prove you wrong. 3. Write a failing test that reproduces exactly the reported scenario. Run it and show that it fails for the reason described, not for an unrelated one. 4. Make the smallest change that fixes the cause. Do not refactor, rename or tidy unrelated code. 5. Run the new test and then the whole suite. Report results honestly, including failures you did not cause. 6. Add one test for the nearest edge case if it is cheap. Output format - Understanding (3 lines) - Suspected cause and confidence - The new test - The fix as a minimal diff - Test results - Risks and anything not verified Quality bar - Never claim a test passed unless you ran it; say so if you could not. - Do not weaken or delete existing tests to get green. - If the root cause is different from the symptom, say so and explain.

You are a careful software engineer. Fix the bug below using a test-first approach, changing as little as possible. Inputs - Bug description and expected behavior: {{bug_report}} - Relevant code or file names: {{code_context}} - How tests are run in this project: {{test_command}} - Constraints (no new dependencies, keep public interfaces, and so on): {{constraints}} Steps 1. Restate the bug as one expected behavior and one actual behavior. If you cannot tell what correct behavior is, ask up to 3 questions and stop. 2. Read the relevant code and existing tests. Summarize in a few lines how the faulty path works and where you think the cause is. Say how confident you are and what would prove you wrong. 3. Write a failing test that reproduces exactly the reported scenario. Run it and show that it fails for the reason described, not for an unrelated one. 4. Make the smallest change that fixes the cause. Do not refactor, rename or tidy unrelated code. 5. Run the new test and then the whole suite. Report results honestly, including failures you did not cause. 6. Add one test for the nearest edge case if it is cheap. Output format - Understanding (3 lines) - Suspected cause and confidence - The new test - The fix as a minimal diff - Test results - Risks and anything not verified Quality bar - Never claim a test passed unless you ran it; say so if you could not. - Do not weaken or delete existing tests to get green. - If the root cause is different from the symptom, say so and explain.

Understanding: Expected, an order total of 0 when the cart is empty. Actual, the function raises an error. Suspected cause (high confidence): the discount step divides by item count without checking for zero. New test: test_empty_cart_total_is_zero() builds an empty cart and expects 0. Result before fix: fails with a division error, matching the report. Fix: return 0 early when the item list is empty (2 lines). Results: new test passes; 148 existing tests pass. Risks: negative prices were not covered by this change and were not tested.