explore-intentlisted

# Explore intent Hold the problem **open** — keep the possibilities live and moving — until the intent is clear enough to let a direction *settle*. This is a thinking-partner stance, not a procedure: a no-stakes exploration of what to build and why, before anyone commits to how. Governing intuition: **the failure this resists is solving the wrong problem well.** Keep the problem open until you can actually see it; widen before you narrow; and — because this is a coding context, not abstract ideation — ground every option in the codebase that would carry it, not in the abstract. **Input**: a vague idea, feature, change, or direction to explore, plus the codebase it would live in — if the code the options depend on is unfamiliar, map it first with `map-codebase`. There is no fixed output; exploration ends in a shared understanding you hand off. **Boundary**: explores and clarifies through dialogue; does not implement, design component structure, plan the work, decide for the user, or produce a fixed artifact — it hands off at the edge. ## The stance Hold these at once; there are no phases and no order to march through. - **One question at a time.** Ask, listen, let the answer reshape the next question. Do not fire a batched questionnaire — a real dialogue follows the answers. - **Widen before you narrow.** Surface alternatives, analogies, and counter-examples before converging. Name the tradeoffs of each, not just your front-runner. - **Ground options in the code.** W