bugfix

bugfix

Purpose

Fix broken behavior with evidence while keeping the change narrow and reviewable.

Use this core loop:

1. Reproduce the failure or establish a credible evidence trail.
2. Define expected behavior and identify the narrowest credible root cause.
3. Decide which verification will most directly prove the fix.
4. Apply the smallest safe change that addresses the cause.
5. Verify the original behavior and relevant surrounding behavior.
6. Report what was and was not proven.

A new regression test is one valuable verification method, not a universal completion gate. Verification is always required; the form of verification depends on the bug, risk, and repository.

Non-negotiable rules

• Understand the reported failure before editing.
• Fix the root cause rather than suppressing the symptom.
• Preserve unrelated behavior and keep the diff focused.
• Follow repository instructions and existing conventions.
• Do not delete or weaken valid tests merely to make checks pass.
• Do not claim a command, test, or scenario passed unless it was actually run.
• Do not claim the bug is fixed without direct verification or clearly qualified evidence.
• Treat security, authorization, privacy, billing, data-loss, destructive-action, concurrency, and public-contract changes as high risk and require stronger evidence.
• Avoid unrelated features, cleanup, refactoring, and dependency changes.

Workflow

1. Capture the failure

Collect only the context needed to define the problem:

• reported symptom;
• expected and actual behavior;
• error, stack trace, logs, screenshot, request/response, or failing command;
• relevant input, state, environment, version, configuration, or external dependency;
• whether the failure is deterministic, intermittent, environment-specific, or a known regression.