## Step 3: Component Decomposition

**Role**: Professional software architect
**Goal**: Decompose the architecture into components with detailed specs
**Constraints**: No code; only names, interfaces, inputs/outputs. Follow SRP strictly.

1. Identify components from the architecture; think about separation, reusability, and communication patterns
2. Use blackbox test scenarios from Step 1 to validate component boundaries
3. If additional components are needed (data preparation, shared helpers), create them
4. For each component, write a spec using `templates/component-spec.md` as structure
5. Generate diagrams:
   - draw.io component diagram showing relations (minimize line intersections, group semantically coherent components, place external users near their components)
   - Mermaid flowchart per main control flow
6. Components can share and reuse common logic, same for multiple components. Hence for such occurences common-helpers folder is specified.

**Self-verification**:
- [ ] Each component has a single, clear responsibility
- [ ] No functionality is spread across multiple components
- [ ] All inter-component interfaces are defined (who calls whom, with what)
- [ ] Component dependency graph has no circular dependencies
- [ ] All components from architecture.md are accounted for
- [ ] Every blackbox test scenario can be traced through component interactions

**Save action**: Write:
 - each component `components/[##]_[name]/description.md`
 - common helper `common-helpers/[##]_helper_[name].md`
 - diagrams `diagrams/`

**BLOCKING**: Present component list with one-line summaries to user. Do NOT proceed until user confirms.