/bug-fix-protocol

name: bug-fix-protocol
description: Use when fixing a reported bug end to end. Enforces a disciplined sequence — reproduce, write a failing test, fix minimally, verify, prevent recurrence — and blocks the common failure mode of patching symptoms.
metadata:
  category: development
  version: 1.0.0
  tags: [bugfix, testing, root-cause, process]

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.