brainstorming

<anti_pattern_too_simple> Every project — including "simple" utilities, todo lists, config changes — goes through this loop. The design can be 3 sentences for trivial tasks, but it MUST exist and be approved. Skipping this is where unexamined assumptions cause the most wasted work. (Sole exemption: a user-requested trivial direct edit — typo/config one-liner — per the sumela-prompt DEVELOPMENT GATE condition (c).) </anti_pattern_too_simple>

1. PRE-FLIGHT CONTEXT (MANDATORY):

   • SECURITY STANDARD LOAD: Read .sumela/skills/secure-coding-standard/SKILL.md if not already in context — Step 4's per-option Security Impact analysis and the spec's Security Considerations section must reference the actual standard, not memory.
   • PHASE RULE SYNC: This skill activates the specification phase. Per .sumela/RULE_REGISTRY.md <phase_to_rule_matrix>, confirm every universal rule, every specification-phase rule, and every rule matching the active stack scope(s) and domain(s) is loaded — READ any missing rule file now. If the registry file is missing, tell the user to run setup — do not guess the matrix.

2. EXPLORE CONTEXT: Read relevant files, docs, and recent commits to understand the current state. Avoid scoping too broadly; decompose large requests into sub-projects.

   • DECOMPOSITION RULE: If the request describes multiple independent subsystems (e.g., "platform with chat + billing + analytics"), flag this immediately and decompose. Each sub-project gets its OWN spec → plan → implementation cycle; do NOT try to fit them into one spec.
   • SECOND BRAIN CHECK (MANDATORY): Before proposing any architecture, read wiki/_INDEX.md to locate relevant pages, then read wiki/architecture-decisions.md (existing AD records) and wiki/tech-debt-and-known-issues.md (open debt). Your proposals MUST NOT contradict existing approved decisions unless explicitly superseding them. This prevents the wiki's compounded knowledge from being ignored.

3. VISUAL COMPANION CHECK (RICH MENU): If the task requires UI/diagrams or complex state flows, present this choice clearly to the user: "This task involves visual/architectural complexities. How would you like to proceed?

   1. Use Visual Companion (Recommended): I will generate visual diagrams/UI previews in the browser. (Note: Token-intensive, but prevents design blind spots).
   2. Text-Only Mode: Let's stick to markdown and text descriptions. (Faster, best if you already have a clear visual in mind)." Wait for reply. If Option 1, consult ./visual-companion.md.

4. CLARIFY: Before asking any questions, first list your explicit assumptions:

   ASSUMPTIONS I'M MAKING:
   1. [e.g., This targets web, not native mobile]
   2. [e.g., Auth uses JWT, based on existing middleware]
   3. [e.g., PostgreSQL, based on existing ORM/migration config]
   → Correct me now or I'll proceed with these.
   

   Then ask clarifying questions ONE AT A TIME. Prefer multiple-choice. Focus on purpose, constraints, and security/data-privacy requirements (referencing the secure-coding-standard loaded in Step 0). Reframe vague requirements as measurable success criteria:

   • "Make it faster" → "API p95 < 200ms, LCP < 2.5s — are these the right targets?"
   • "Improve security" → "Specific threat: IDOR on resource X — is that the concern?" Confirm reframed criteria with the user before proceeding.

5. PROPOSE ARCHITECTURE (DEEP OPTIONS): Present 2-3 distinct architectural/design approaches. You MUST format your proposals using this deep-context structure and actively consider the secure-coding-standard:

   • Option A [Name]: [Brief 1-sentence description]
     • Pros: [What do we gain?]
     • Cons/Risks: [What are the trade-offs or technical debt?]
     • Security Impact: [How does this handle data? Any attack vectors mitigated or exposed?]
     • Best For: [When is this the right choice?]
   • Clearly state your expert recommendation at the end and wait for the user to select an approach.