session-brainstormlisted

# Session Brainstorm Turn an idea into a decision the user has approved, before anything is built. Open with one sentence saying what you are about to do and what it will produce. ## Rules 1. **Nothing is implemented until the user has approved a design.** This holds for a two-sentence change as much as for a subsystem. The size of the design scales with the task; the approval does not. 2. **One question per message.** Prefer multiple choice when the options are known. Let each answer shape the next question. 3. **Options come with a recommendation.** Present two or three approaches with their trade-offs and say which one you recommend and why. 4. **Classify out loud.** Say which path the request is on, so the user can override it. 5. **Nothing leaves this skill without a captured work item.** Every path that continues past a spike allocates identity first, through `/session-add-task`, which writes the record with the runtime. Capture is not permission: the item lands in `captured`, `select` refuses it by name, and the user's approval of the design is what makes it acceptable — not the fact that a record now exists. ## Three paths Classify the request before the first question, and say the classification. - **Spike.** A feasibility question: "can we", "is it possible", "quick and dirty is fine". The output is an answer, not code to keep. Say what you will try in two or three sentences, get a nod, find out as cheaply as correctness allows, an