Bug Fixing Loop
Reproduce a bug, fix the smallest cause, and verify with a regression test.
What this Loop Engineering template does
Reproduce the reported bug, fix the smallest root cause, and prove it with a regression test.
Start by reproducing the bug. Write a failing regression test first, then fix until it passes.
When to use it
When not to use it
Validation checks
Boundaries & stop rule
Copy the loop prompt
/goal Reproduce the reported bug, fix the smallest root cause, and prove it with a regression test.Task type: Bug FixTarget tool: Claude CodeWork toward this goal until all validation checks pass or the stop rule is reached.Design hypothesis:This bug fixing loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.Smallest useful run:Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.Loop cycle:1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.Context:Start by reproducing the bug. Write a failing regression test first, then fix until it passes.Validation:Bug is reproduced before fixRegression test fails before fix and passes after fixFull relevant test suite passesValidation evidence:Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.Independent checker:Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.Boundaries:Do not rewrite unrelated modulesDo not hide errorsDo not change expected behavior without documenting whyStop rule:Stop when the regression test passes and the suite is green, or after 5 failed attempts.Maximum iterations: 6Budget:Example only: stop before exceeding the agreed per-run token budget.Human approval:Required before merge, deploy, delete, purchase, or external communication.Fallback:If the root cause is unclear, summarize the reproduction, hypotheses tried, and recommended next step.Loop Validation Log:- Hypothesis: This bug fixing loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.- Smallest useful run: Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.- Expected evidence: Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.- Actual evidence: [fill in after the run]- Passed? [yes / no / partial]- Feedback: After the run, note what the loop learned, what failed, and what should change before the next pass.- Next step: [stop / adjust the loop / run the next pass]Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.
Failure modes to watch
Review receipt
This is a bounded review exercise for the template, not a claim about a production deployment.
Scenario
A saved budget estimate resets its output-token value when the browser back button restores the calculator page.
Baseline evidence
The reviewer records the browser steps, entered values, expected restored state, actual reset value, and a failing state-restoration test before touching the calculator logic.
Validation result
The regression test fails against the prior state, passes after the focused hydration fix, and the calculator produces unchanged totals for fresh visits and direct URL loads.
Shortcut rejected
Removing browser restoration support or forcing a full reload hides the symptom while degrading navigation, so neither is accepted as a bug fix.
Human gate
A person checks the restored interaction in a real browser and confirms that retaining entered values is the intended privacy and usability behavior before release.
Loop Engineering FAQ
A test that fails before the fix and passes after proves the bug was real and the fix addresses it — not just that the code changed.