# Defect report

## Summary

Describe the wrong behavior you can see. Don't guess at the root cause here.

[One sentence describing the wrong behavior you saw.]

## Impact

Keep "who is affected and how badly" separate from "how often it happens". Both facts set the priority.

- Affected user or system:
- Severity and reason:
- Frequency:

## Reproduction

Give another person a known starting point and exact steps that always give the same result. Keep the real result and the expected result separate.

1. Start from **[known state/version]**.
2. Do **[action]**.
3. See **[actual result]**.

Expected: **[expected result]**

## Smallest failing case

Shrinking the case removes things that don't matter. It also gives you a cheap regression test (a test that stops the bug from coming back).

[Give the input and the exact output, both with private details removed. Add the smallest command or test that shows the bug.]

## Acceptance criteria for the fix

This is the done checklist for the fix. Each item needs proof that the original failure is fixed and nothing nearby broke.

- [ ] The smallest failing case now passes.
- [ ] A regression test fails before the fix and passes after it.
- [ ] Related existing behavior still passes.
- [ ] You can explain the root cause and one likely way the bug could come back.

## Proof

Link the failure before the change to the exact fix and the passing result after it.

- Failing test/run:
- Fix commit:
- Green test/CI run:
- Release or follow-up:

---

## About this template

A defect report turns "it's broken" into steps anyone can repeat, and a checklist that says when the fix is done.

> **What this teaches:** I can turn "it's broken" into proof someone can repeat. I can say clearly who is affected. I can write a testable checklist for the fix.

Guess the smallest input or state that still shows the problem. Keep the real output separate from your explanation of the cause.

A defect is a bug. Use this template only after a week page names the exact GitHub Issue or file path for it. If no place was named first, stop and go back to the week page. Don't create an unnamed note. Save and reopen the assigned Issue or file before you dig into the bug.

**Explain it back:** Explain how to make the bug happen again and which proof points to the root cause. Then name one likely way the bug could come back.

**Delete this whole section once you have filled the document in.** What is left should read as a finished document on its own.