docs(commands): add timebox and fresh-sources rules to brainstorm

Three audit fixes. Phase 1 gains a "Timebox the dialogue" rule, since one-question-at-a-time can run long: aim for the one-sentence restatement in roughly five to eight questions, then move to Phase 2 and park the rest as open questions. Phase 2 gains "Ground high-stakes claims in fresh sources" — check load-bearing claims about markets, regulations, tools, vendors, or current APIs against a current source, and mark what you couldn't verify as an assumption. The design-doc skeleton gains an Assumptions section that separates researched facts (with their source) from assumptions to confirm before building.

1 files changed, 7 insertions, 0 deletions

diff --git a/.claude/commands/brainstorm.md b/.claude/commands/brainstorm.md
index b22196d..c2b57e6 100644
--- a/.claude/commands/brainstorm.md
+++ b/.claude/commands/brainstorm.md
@@ -36,6 +36,7 @@ Dialogue, not interrogation. Before the first question, read the project context
 - **Prefer multiple choice.** Easier to answer, faster to skim, surfaces the option space for free.
 - **Open-ended when the option space is too large to enumerate.** Then refine with follow-ups.
 - **Focus the first questions on purpose, not mechanism.** Mechanism comes in phase 2.
+- **Timebox the dialogue.** One-question-at-a-time sharpens the idea, it isn't an open-ended interview. Aim to reach the one-sentence restatement in roughly five to eight questions. Once you have enough to state the idea back, move to Phase 2 even with some topics unresolved — park the rest as open questions rather than stretching the dialogue for completeness.
 
 **Topics to cover (not a script — skip what's already clear):**
 
@@ -72,6 +73,8 @@ Why tail samples matter: most teams converge on the first conventional option. T
 - What's being traded away
 - What becomes an open decision for `arch-decide` later
 
+**Ground high-stakes claims in fresh sources.** A consequential design rests on claims about the world — what a market does, what a regulation requires, what a tool, vendor, or current API supports. Those age and are easy to misremember. Check anything load-bearing against a current source before it shapes the recommendation, and mark what you couldn't verify as an assumption rather than a fact. An unchecked "X can't do Y" that turns out wrong can steer the whole design off a cliff.
+
 ### Phase 3 — Present the Design
 
 Once a direction is chosen, describe it in **200-300 word chunks**. After each chunk, ask "does this look right so far?" Never dump a wall of design prose — the user skims walls.
@@ -107,6 +110,10 @@ One paragraph. What, who, why now.
 
 Bullet list of what this explicitly does not address. Prevents scope creep.
 
+## Assumptions
+
+The load-bearing claims this design rests on, each marked as a **researched fact** (with its source) or an **assumption** (unverified, to confirm before building). Keeps a reader from mistaking a guess about a market, regulation, tool, vendor, or API for a checked fact.
+
 ## Approaches Considered
 
 ### Recommended: <name>