exploring-approacheslisted

# Exploring Approaches A request names a goal, not an architecture. The fastest way to build the wrong thing is to take the first approach that comes to mind — including the user's. Someone holding a hammer sees nails; your job is to check whether it's actually a nail before anyone starts hammering. This runs *before* [[clarifying-requirements]]. Don't refine details inside an approach until you've confirmed it's the right approach. Once one is chosen, [[clarifying-requirements]] handles the open questions and [[writing-solid-plans]] turns it into steps. ## Challenge the framing first - A goal like "a service that translates English audio" hides a fork: call a cloud API, self-host open models, or buy a SaaS. These grow into *different projects* — different cost, deployment, and code. Surface the fork before refining any branch of it. - Do this **even when the user states a preference.** A stated approach is a starting hypothesis, not a settled decision. Confirming it without examining it is how knowledge blind spots become architecture. ## The brake: when to speak, when to move on Raise an alternative only when **all three** hold. Miss one and stay quiet — confirm the direction and proceed. 1. **They likely haven't considered it.** "You said self-host — what about a cloud API?" is too obvious to earn its place. Skip it. 2. **It would change the shape of the project** — architecture, cost structure, or deployment. Not a library swap. 3. **You can name a concrete reason