bug-hunt
Bug hunt
Most bugs wait until a user trips on them. A hunt goes looking first: it reads the code as a skeptic, keeps only the bugs it can make go red, and leaves each one where a human can act on it at a glance: fixed in a draft pull request with green checks, or an issue an agent could pick up. Run to the end on your own; anything for the human goes in the report.
Write the report in the user's active language, and pull requests and issues in the project's.
1. Scope
Hunt the area the user names; otherwise, the whole project. Split a scope larger than one reader can hold into lanes along owner boundaries, each read by a fresh read-only agent, and point each lane first at its strongest signals: suspected bugs garden filed, churn hot spots in history, fixes that came back, code merged without tests, skipped or intermittent tests, TODO and FIXME notes, and errors the project's logs expose. Every issue and pull request a hunt opens carries the bug-hunt label, created when the project lacks it, so earlier hunts show where they looked. State the scope and its lanes, and pin the revision.
2. Hunt
Read the code in scope, its callers, its tests, and its history; when defensive code or a strange shape needs its reason, trace it through the commits, pull requests, and issues that introduced it, and treat any reason no source from that time records as a guess. Ask what breaks it: which inputs, states, orderings, retries, and failures; which errors are swallowed; what the code assumes and never checks; where a test asserts less than its name claims. Where state interacts, enumerate the state space as strategic-programming defines it.
Record each suspect in a queue with the observed evidence, and change nothing yet.
Done when every file in scope has been read and every suspect has an evidence line.