component-planninglisted

# Component Planning ## Purpose Produce an executable graph of cohesive Components and tasks rather than a flat T1/T2/T3 list. ## Trigger Run when architecture or detailed design must become bounded implementation work, especially for multi-module, parallel, or integration-sensitive changes. ## Inputs - Validated Requirements, models, architecture, ADRs, Project Constraints, and target. - Existing code/Component inventory, Workflow Level, risks, and delivery constraints. - Known APIs, schemas, integration points, and current Component states. ## Prerequisites - Resolve material architecture and product choices first. - Ensure enough design exists to define boundaries without inventing upstream intent. ## Procedure 1. Decompose `System → Subsystem → Module → Component → Task` only to the depth needed for the target. 2. Give each Component a single cohesive responsibility, clear boundary, owner capability, inputs, outputs, and DoD. 3. Apply Contract First at every cross-Component boundary: specify Input, Output, Data Structure, Behavior, Error, Boundary, Protocol, version, and compatibility expectations. 4. Build the Component Graph and Task Graph with directional dependencies. 5. Identify integration points, consumer/provider relationships, shared data, and cross-cutting risks. 6. Mark tasks `READY` only when required Artifacts and Contracts are sufficiently valid. 7. Identify parallel work only where Contracts are stable and write scopes do not overlap. 8. Assign Co