How a coding agent reproduces a bug report with Kane CLI

When a coding agent should reproduce a bug first

When a user, a ticket or an error report describes something that does not work in the browser. Reproduce it first, so you know the fix targets the real problem and you finish with a check that proves the fix works.

How to reproduce a bug and prove the fix

1. 1

   Rewrite the bug report as the expected behavior

   State what should happen, starting from the URL and ending with a check. Store the values you compare, so every run records them. Bug report: "Coupon SAVE10 does not reduce the total." Objective:

   textCopy

   Go to http://localhost:3000/cart, store the total as 'before', apply coupon SAVE10, store the total as 'after', then verify the stored after value is less than the stored before value

2. 2

   Run the bug reproduction before you change any code

   Use the same flags as when you verify a change, so the failing run and the run after the fix happen under the same conditions.

   bashCopy

   kane-cli run "Go to http://localhost:3000/cart, store the total as 'before', apply coupon SAVE10, store the total as 'after', then verify the stored after value is less than the stored before value" --agent --headless --timeout 180

3. 3

   Confirm the reproduction fails for the reported reason

   Expect exit code 1. The failing step's remark and the summary in run_end should describe the same problem as the report, and final_state shows the stored before and after totals. The failing step's failure.yaml in the evidence pack holds the error and the page state; treat its triage as a lead, not a verdict.

   • If the run passes (exit 0), the bug is not reproduced yet. Ask the user for the exact steps and the account or data they used, then adjust the objective. Kane CLI drives desktop Chrome, so a bug seen only in another browser or on mobile web needs a different tool.
   • If it exits 2, nothing ran. Fix sign-in, configuration, Chrome or the start URL first, then run the reproduction again.
   • If it exits 3, the run timed out or was cancelled. Raise --timeout or shorten the objective, then run it again.
4. 4

   Show the user the failing run's evidence pack

   Every run that starts seals an evidence pack with per-step screenshots, console logs and network logs. Kane CLI prints the pack path on stderr, and the pack sits under the evidence/ folder of run_end.session_dir. Start the viewer in the background:

   bashCopy

   kane-cli evidence serve <path-to-pack.evidence>

   It keeps serving until you stop it, from a local server on this machine that the hosted viewer reads, so nothing is uploaded. Give the user the viewer URL it prints, share the failing step's screenshot before you change code, and stop the server when they are done.

5. 5

   Fix the code, then rerun the reproduction unchanged

   Fix the code, not the check. After each fix, run the identical command and stop when it exits 0. Then tell the user what was wrong and share the passing run's test_url. Edit the objective only if the run failed because of how it was worded, for example it targeted the wrong element, and never remove the expected outcome to get a pass.

6. 6

   Keep the reproduction as a regression test

   Add --name <flow> to each rerun after the fix, starting with the first one, because a finished run cannot be named afterwards. When a run exits, Kane CLI writes .testmuai/tests/<flow>_test.md and its output-<flow>/ recordings. Keep the files from the run that passed, move both into the repo, commit them and run them in CI, so the bug shows up as a failing test if it comes back. See Save a verified run as a committed test and Gate a pull request in CI.