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 · Explore the code
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 includes the command, the original failure, and the result after the fix. You can also inspect the regression test 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 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.