Topics / Engineering practice
When the same area breaks again, keep more than the patch.
Recurring defects often expose a missing shared assumption, requirement or verification obligation. Investigate the pattern instead of treating each failure as unrelated.
Group by cause, not by filename alone.
Two bugs in one module may have different causes. Two bugs in different services may share the same retry assumption. Compare violated promises, operating conditions and repair decisions before declaring a common defect class.
Illustrative example
Three fixes, one forgotten boundary
An API, a batch worker and a callback handler each allow an operation after its deadline. Separate patches add three local checks. The shared obligation is that expiry must be enforced at each consequential entry point. The class review should name those entry points and retain evidence for each.
Give class closure its own work.
| Level | What it can establish |
|---|---|
| Original witness passes | The demonstrated instance is fixed under the tested conditions |
| Regression retained | That witness can be checked again |
| Sibling review completed | Declared related cases were investigated |
| Class obligations satisfied | The scoped class claim has supporting evidence |
Do not infer the final row from the first. Keep unknown siblings and exceptions visible. A class definition that expands later may require additional investigation.
Keep the lesson available to agents.
Proof retains issues, defect records, hazards and requirements in the same graph. A later change can retrieve the prior failure mechanism and its evidence obligations. The benefit to test is less repeated investigation and fewer returns of the same declared class.
Start with a few closed incidents in one component. Look for a requirement that would have made each repair necessary before the incident happened.
Try it on your software
Bring three bugs that feel like the same bug.
We will distinguish shared causes from coincidence and identify a bounded class-level check.