coding-reconlisted

# Coding Recon ## Overview Gather only evidence that can change the target, approach, constraints, or verification. ## When to Use Use Recon when unclear ownership, contracts, precedent, callers, or root causes could change the implementation. Skip Recon when the exact location and edit are known, the change is fully local, and no material contract is uncertain. ## Recon Loop ### 1. Frame one uncertainty State one decision-changing question. Do not start with a list of files to read. ### 2. Choose the cheapest discriminating observation | Question | Start with | | --- | --- | | Where is behavior owned? | Symbol/reference search, then implementation and callers | | What contract applies? | Types, tests, public interfaces, relevant configuration | | What precedent exists? | One nearby implementation and its tests | | Which root cause fits? | Competing hypotheses and a separating diagnostic | Before each tool action, know its question and possible decision impact. Use history only when intent matters. Broaden only when targeted evidence fails. ### 3. Update the hypothesis Classify each uncertainty as resolved, narrowed, or contradicted. Revise the likely target or approach, then choose the next material uncertainty. Evidence contains only facts observed in code, tests, configuration, or history. Otherwise write exactly `Evidence: none collected`; move everything else to `Open uncertainty`. For bugs, use `hypotheses → discriminating evidence → root cause`, not `err