product-apps-decomposition

# Product → Apps Decomposition > **Style:** Mode-B-lite. Generic guidance always; **steers to the product breakdown when `docs/<app>/product.md` defines one** (generic-with-enhancement, not pure no-op — E3). ## Purpose Encode the "a product is composed of focused apps" model: breaking a product into smaller, focused apps (vs one monolith) improves reliability (one app's failure can't sink the rest) and token economy (the LLM loads only the relevant app's context). Apps talk via internal API; complexity per app stays low. ## When to invoke - Planning a new product/app and deciding scope/structure. - Operator says "should this be one app or several", "how do I split this product". - `docs/<app>/product.md` exists with an apps breakdown (steer to it). ## Do not invoke when - Single-file edits / bug fixes. - App-internal component/folder structure (that's implementation detail, not product decomposition). ## Required inputs | Input | Where it lives | If missing | |---|---|---| | Product breakdown (optional) | `docs/<app>/product.md` | give generic guidance; do not invent a breakdown | | Reliability/scale needs | operator / North Star | ask if scope-critical (FR-19) | ## Procedure 1. **If `docs/<app>/product.md` defines an apps breakdown → read and steer to it.** Otherwise give generic guidance (do not fabricate a specific breakdown). 2. **Score the boundary** with § Split decision below — signals vs costs, both columns honestly; the worked CRM example shows the shape o...