defect-hunting

Defect hunting

Mined from a real remediation programme where twelve screen-by-screen review rounds found nothing new, and one round organised differently found dozens of live defects. Every one of these rules is paid for.

The sentence that generates all four:

Verify the thing that has to be true, not the thing you changed.

Filtering the list is not filtering the parser. Capping the severity is not capping its renderer. Matching the token is not matching the value. Mutating the file is not confirming the mutation landed.

---

1. Audit the data's entry points, not the screens

A review organised by screen structurally cannot find these, because in every case the audited surface was correct and the bug was in the second path to the same data — usually another file, often another module:

What was reviewed	Where the defect actually was
Add-form validation	the edit path, which validated nothing
the dashboard alert banner	the detail screen the banner opens — they disagreed
the growth-target reader	the writer, which destroyed data
the photo picker's success branch	its cancel branch, which wiped the existing photo
the purchase flow	the still-loading entitlement state, which paywalled a paying customer
sync's happy path	the RECONCILE_FAILED branch

The question that does the work

"What is the second way this value gets written?"

And its siblings: what is the second way it gets read? What happens on cancel? On failure? On restore? On import? On sync? On each remaining enum case?

Procedure

Before approving any change that touches persisted or user-visible state:

1. Name the data the change touches — the field, the row, the preference, the entitlement.
2. Enumerate every writer. grep the field name across the whole repo, not the module — prefer ast-grep where the language has one available, same reasoning as §1b: text search false-negatives on a renamed reference or a match sitting inside a comment or string. Create, edit, import, sync, restore, migration, reset-to-default, and every failure branch.
3. Enumerate every reader, same way.
4. Show the invariant holding on each one. A validation that one producer applies and another walks around is not a validation.
5. If you cannot enumerate them, say so — do not approve on the strength of the path you read.