decomposing-worklisted

# Decomposing Work Converts a confirmed ARCHITECTURE.md into a persistent roadmap of implementation chunks — the decomposition discipline that determines whether developer-agents succeed. **Position:** architecting-software (ARCHITECTURE.md) → decomposing-work (ROADMAP.md structure) → enriching-roadmap (acceptance criteria, pattern references) → developer-agent. **Inputs:** a confirmed ARCHITECTURE.md and human confirmation to proceed — do not begin autonomously. If the architecture is ambiguous (missing component boundaries, implicit interfaces, unclear data ownership), flag specific gaps to the human before producing chunks. Inferred boundaries produce misaligned briefs. **Output:** `ROADMAP.md` in the project root — header block, global Definition of Done, chunks grouped by phase, per the Templates section. Present the draft as "proposed" and write the final file only after the human confirms. **Not covered:** architecture design, enrichment, orchestration, implementation. ## Workflow ### Step 1: Read the Architecture Read ARCHITECTURE.md fully and extract four labelled lists: - **Components** — named services, modules, packages, domains - **Integration surfaces** — every API, event contract, shared schema, or data-model interface between components - **Foundational infrastructure** — what must exist before any feature (project scaffold, CI/CD, database setup, auth skeleton, shared types, logging wiring) - **Cross-cutting concerns** — logging, error handling, obse