Bug fix protocol

Bug Fix Protocol

Purpose

Turn a bug report into a merged fix without introducing a second bug. The protocol is deliberately rigid: it exists to prevent the two most common failures — fixing the symptom, and fixing the cause without proving it.

When to Use

• Any reported defect with a reproducible symptom.
• A regression discovered in CI or production.
• A hotfix under time pressure — especially then.

Capabilities

• Reproduction and minimization.
• Root-cause isolation (see the debugging skill for the search method).
• Minimal, targeted fixes with regression tests.
• Blast-radius assessment for the same class of defect elsewhere.

Inputs

• The bug report: expected behavior, observed behavior, environment, steps.
• Access to logs, traces, or a failing build.
• The severity and whether a rollback is available.

Outputs

• A failing test that captures the bug.
• The smallest change that makes it pass.
• A note on where else this defect class could occur.

Workflow

1. Reproduce before reading code. If you cannot reproduce it, the report is incomplete — go back for the missing detail. Do not guess.
2. Write the failing test. In the real test suite, at the right level. It must fail for the right reason, with a clear message.
3. Find the cause. Not the line where it crashed — the decision that made the crash possible.
4. Fix minimally. Change only what is required. Refactoring belongs in a separate commit.
5. Verify. New test passes; full suite passes; reproduce the original scenario manually and confirm it is gone.
6. Look for siblings. Grep for the same pattern elsewhere. A bug found once is usually present three times.
7. Close the loop. State in the PR: what broke, why, what changed, and what now prevents it.

Best Practices

• If you cannot write a test that fails before the fix, you have not understood the bug.
• Under time pressure, mitigate first (rollback, feature flag, rate limit), then fix properly. Do not ship a rushed fix to production and call it done.
• Never "fix" a flaky test by retrying it. Flakiness is a real defect in the test or the code.
• Do not widen a try/except to make an error go away. That hides the next bug too.
• Record the root cause in the issue, not just the fix. The next person will search for the symptom.

Examples

PR description that closes the loop:

## What broke
Users on annual plans were charged twice when upgrading mid-cycle.

## Why
`ProrationCalculator` issued the invoice before checking whether the
subscription already had a pending invoice for the same period. Under
concurrent upgrade requests, both passed the check.

## Fix
Added a unique constraint on (subscription_id, period_start) and made
invoice creation idempotent on that key. The second request now returns
the existing invoice rather than creating one.

## Prevention
Regression test `test_concurrent_upgrade_creates_one_invoice` runs two
upgrades in parallel and asserts a single invoice. Audited the other
three call sites of `issue_invoice` — `RenewalJob` had the same gap and
is fixed in the same commit.

Notes

• Idempotency keys on write endpoints prevent an entire class of duplicate-side-effect bugs. If the bug was a duplicate charge, message, or record, this is usually the real fix.
• If a bug is reported and cannot be reproduced after honest effort, close it as such and say what you tried. Leaving it open forever is not diligence.