design-component

Read .arch/state.json first.

GATE CHECK:

• If current_phase is not components, STOP: "Cannot design components. Current phase is [phase]. Methodology must be accepted first."
• If phases.methodology.accepted is not true, STOP: "Phase 2 (Methodology) must be accepted first."
• If there is a current_component with status in_progress or awaiting_acceptance that is DIFFERENT from the requested component, STOP: "Component [current_component] is still pending. Accept or refine it before moving to another component. Use /status to check."

Read .arch/phase2-methodology.md and .arch/phase2-components-overview.md for context. Read .arch/org-context.md for team and technology constraints. Read any previously accepted components in .arch/components/ for consistency checking.

If $ARGUMENTS is empty, determine the next component in logical dependency order (foundational components first — databases, auth, core services before dependent services).

Detailed Component Design for: [Component Name]

1. Component Specification

• Name: [exact name]
• Role: [detailed description — what it does, what it owns]
• Bounded Context: [what data/logic belongs exclusively to this component]

2. Technology Recommendation

• Primary recommendation: [Technology vX.Y]
• Why: [Specific rationale tied to requirements AND org context]
• Alternative 1: [Technology] — [why not chosen]
• Alternative 2: [Technology] — [why not chosen]

If org-context lists a preferred technology, acknowledge it: "Your organization prefers [X]. I'm recommending [Y] instead because [reason]. If you'd prefer to stay with [X], here's what changes: [impact]."

3. Integration Specification

• Inputs: [what this component receives, from whom, what protocol, what format]
• Outputs: [what this component produces, for whom, what protocol, what format]
• API Contracts: [key endpoints/interfaces with request/response shapes]
• Data Formats: [JSON schemas, message formats, events published]