brainstorminglisted

# Brainstorming: from idea to approved design The goal is an understanding the user can recognize and correct, and approval of it before any implementation. <HARD-GATE> Do not write product code, scaffold, install dependencies or invoke an implementation skill until the selected path's approval is given. Read-only exploration is allowed. An approval covers only the stage you actually presented. </HARD-GATE> ## 1. Classify, out loud Say which path you are taking so the user can override it: "This looks bounded, so I'll propose a short design here." - **Spike**: a feasibility question. Present the question and the probe in 2–3 sentences, get a nod, investigate cheaply, and report a recommendation. Anything you built is throwaway. - **Bounded**: a well-scoped change to a flow that already exists in this repo. If there is no existing flow to read, it is not bounded. - **Architectural**: a new project or subsystem, or a change to interfaces other code depends on. When in doubt, take the heavier path. Hidden complexity found mid-task moves you up a path, never down. ## 2. Understand 1. Explore context first: relevant files, CLAUDE.md, docs, recent commits. 2. If the request contains several independent subsystems, say so and decompose it before refining any one of them. Write the decomposition to `docs/specs/YYYY-MM-DD-<project>-roadmap.md`: - pieces, one line each: goal and boundaries, as `- [ ]` checkboxes; - order and dependencies; - contracts between pieces (AP