# A ₹50 checkout bug taught me what a coding agent should report back > Source: > Published: 2026-11-06 15:17:54+00:00 Five tests passed. Then I entered `SAVE10` on a ₹1,000 cart and watched the shipping line change from **Free** to **₹50**. The coupon had done its job. It took ₹100 off the item. But the checkout used the discounted amount to decide whether I still qualified for free shipping. My total came to ₹950. It should have been ₹900. I deliberately put that bug in a small Node.js app for the Flip the Switch Hackathon. I wanted to see whether someone who spotted a wrong total could report it in team chat, ask a coding agent for evidence, and decide for themselves whether the repair worked. I called the workflow **ReproRoom**. [Watch the demo](https://youtu.be/XqM5f-dg35M) · [Explore the code](https://github.com/aditya052003/ReproRoom) I set up a private Mattermost room called `reproroom`. In Switch Console, I connected a local Codex agent, `repro-agent`, to the room and gave it access to the checkout repository. I played the reporter and the reviewer. My report specified one item, one coupon, and two numbers: **I expected ₹900. I got ₹950.** I asked the agent to create a repair branch and run a regression test *before* touching the shipping calculation. That order mattered. The five baseline tests already passed. If the agent edited the code first and handed me a green test afterward, I’d still have to ask whether the test could catch the original bug. The first run gave me an answer I could check. Checkout amounts were stored in integer paise: | | Shipping | Total | |---|---|---| | Expected | 0 paise | 90,000 paise | | Observed before the fix | 5,000 paise | 95,000 paise | The focused test failed. The ₹5,000-paise difference in the total came entirely from shipping. The business rule was simple: a cart qualifies for free shipping when its **original item subtotal** reaches ₹1,000. The baseline compared the threshold against ₹900 after the coupon. The repair compared it against the original ₹1,000 instead. Fixing the reported cart was only half the job. A change from “greater than” to “greater than or equal to” can decide who pays for shipping. Here’s what I wanted the tests to establish: | Original subtotal | Correct shipping, with or without `SAVE10` | |---|---| | ₹999.99 | ₹50 | | ₹1,000.00 | Free | | ₹1,000.01 | Free | At repair commit `658f2a9`, the previously failing test passed. The full suite reported **10 passed, 0 failed**. The [repair report](https://github.com/aditya052003/ReproRoom/blob/fix/checkout-free-shipping-eligibility/REPAIR_REPORT.md) includes the command, the original failure, and the result after the fix. You can also [inspect the regression test](https://github.com/aditya052003/ReproRoom/blob/fix/checkout-free-shipping-eligibility/test/checkout.test.js) directly. One awkward moment changed how I’d design this workflow. I posted the repair request in the room, but I couldn’t tell whether the agent had picked it up. I opened a direct chat to check. I wanted to avoid giving the same agent a second repair job while the first might still be running. A small improvement would have helped: put **Received**, **Working**, or **Needs attention** under the original request, with a link to the run. When you’re waiting on a teammate, “Did you get this?” is a different question from “Have you fixed it?” The part I’d keep was the review. Back in `reproroom`, I asked the agent to verify the exact repair commit, rerun the suite, and report which thresholds it covered. I could then do my part without reading a Git diff: open the browser, enter `SAVE10`, and check the shipping line. This time it said **Free**, and the total was **₹900**. I recorded my acceptance in the room. The repair stayed on its branch, with merge and deployment subject to separate approval. The [README](https://github.com/aditya052003/ReproRoom#readme) explains how to set up the room and run both versions locally. To see the failure, use baseline `abd68ed`. To see the repair, use `658f2a9`. Keep the quantity at one and use the same coupon both times. If you build a similar workflow, start with one bug whose outcome the reporter can verify independently. For my demo, the best acceptance check was the simplest one: the person who saw ₹950 could repeat the same checkout and see ₹900.