architecture-ideationlisted

# Architecture Ideation ## Activation Contract Use this skill to ideate an architecture-level refactor with the user: target styles (e.g. modular monolith, hexagonal), module boundaries, and architecture-scoped design patterns. Do not use it for class/method-level refactors — route those to `/refactor-plan`. ## Hard Rules - Question-driven: run the interview through `native-question-ux`, one focused round at a time, grounded in the verified current state (from `architecture-state`). - Always present 2-3 candidate target architectures with explicit trade-offs and a recommendation — never a single take-it-or-leave-it answer. For monoliths, modular monolith is the default first candidate; microservices must earn their operational cost. - Every proposed pattern passes `design-patterns-pragmatic` and `kiss-yagni` gates: it must resolve a named force in evidence, not decorate the design. - Ideation is plan-only: no code edits. ## Ideation Flow 1. **Current state in**: start from the `architecture-state` output (style, modules, gaps). Missing state = establish it first. 2. **Bounded contexts**: slice the domain with `domain-modeling`; candidate module boundaries come from the domain, not the folder layout. 3. **Candidates**: draft 2-3 target architectures. For each: the shape, what it fixes (tied to gap IDs), migration cost, and the first reversible step. 4. **Question rounds**: converge with the user on candidate, boundaries, and migration appetite (big-bang is never offered