defect-huntinglisted

# 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 *re