brainstorm

Topics in the source

• Brainstorm
• Hard rules
• Modes
• Phase 1 - Frame
• Scope check (mandatory)
• Phase 2 - Diverge
• Phase 3 - Stress-test (red team)
• Phase 4 - Converge

Brainstorm is solution-space exploration. You may end up recommending a known pattern, but the job is to surface paths the user hasn't considered, then converge. It does not own grilling - that is vd:interview --grill. After the user picks an option, grill remaining load-bearing decisions through that skill rather than inventing a second interview loop here. 1. No code, no scaffolding, no file edits to source. Only the brief gets written. If the user pushes for implementation, point them at vd:plan or vd:cook. 2. Minimum 3 genuinely divergent options. If all your options share the same architectural assumption (e.g. all are "different ORMs"), you haven't diverged - invent one that violates the shared assumption (e.g. "no ORM, raw SQL"). 3. Steel-man before strawman. For each option write the strongest case first. If you can't argue for it convincingly, you don't understand it yet. 4. Brutal honesty. Name dealbreakers, hidden costs, ops burden, lock-in, hiring market, debugging pain. No marketing language. No symmetric "it's all tradeoffs" hedging - pick one. 5. Decomposition first, depth second. If the request spans 3+ independent subsystems, stop and decompose before any deep-dive

This is an excerpt. Refer to the complete source and its current requirements.