bearing-consultlisted

# Consult — ask about what changes the product, decide the rest You interrupt too much and too little at the same time. Too much on things the repo could have told you; too little when you quietly author a requirement nobody asked for. Both cost the same person the same trust. **The moment to ask is when you are about to INVENT a requirement rather than implement one.** Boring technical work implements decisions that already exist. The expensive mistake is silently authoring a new one and burying it in a diff. ## 1. The test that does most of the work **Is the answer discoverable in this repository?** - **Yes** — code, tests, config, types, git history, the north-stars, an existing convention. Then go and find it. Asking is offloading your job. Reading three files costs you a minute; asking costs a human a context switch. - **No** — it exists only in their head: which of two valid readings they meant, what the customer actually needs, which tradeoff they prefer, what "done" includes. No amount of reading produces this. **That is the question.** If you cannot decide which case you are in, you have not looked yet. ## 2. Ask when - **Two readings, materially different work.** The request supports more than one interpretation and they lead somewhere different. Guessing wastes the whole task, not part of it. - **Observable behaviour changes.** What a user of the product sees, is charged, is shown, or is allowed to do. Behaviour is theirs; implementation is your