Defect
Something that does not behave as a requirement, a design record or an acceptance criterion says.
What it is
A defect is a gap between what was agreed and what the software does. It names the requirement, design record or criterion it breaks, how to reproduce it and how severe it is.
Why it matters
Tying a defect to a criterion settles the most common argument in software: bug or new request? If a criterion says so, it is a defect; if none does, it is a change and deserves a requirement.
What goes wrong without it
- Every complaint is called a bug, and change requests slip in as fixes.
- Fixes are not proven, so the same defect returns.
- Severity is decided by who shouts.
What it gives an AI agent
An agent fixing a defect needs the criterion it breaks, not just the symptom; otherwise it fixes the symptom. And a defect is closed with a test, so the agent has to prove the fix.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Rescheduling is broken sometimes. | A move 1 hour 59 minutes before the appointment is accepted; FR-5C0A71/AC2 says it must be refused. Severity: medium. |
How it relates to the rest
- Breaks an acceptance criterion, a requirement or a design record.
- Part of an epic, or of the solution's maintenance initiative; fixed like a story; proven by a test.
- Differs from a risk: a defect has happened; a risk might. See the comparison page.
In CorPole
- Type Defect (DEF). Workflow: New, Triage, Ready, In progress, Code review, Verification, Fixed.
- A defect with no parent goes to the solution's quarterly maintenance initiative; one raised under a piece of work follows that work's initiative.
- Agents report defects with
report_defect.