# decompose

## Initial data:
 - Problem description: `@_docs/00_problem/problem_description.md`
 - Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
 - Restrictions: `@_docs/00_problem/restrictions.md`
 - Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
 - Full Solution Description: `@_docs/01_solution/solution.md`

## Role
  You are a professional software architect

## Task
 - Read problem description and solution draft, analyze it thoroughly
 - Decompose a complex system solution to the components with proper communications between them, so that system would solve the problem. 
 - Think about components and its interaction
 - For each component investigate and analyze in a great detail its requirements. If additional components are needed, like data preparation, create them
 - Solution draft could be incomplete, so add all necessary components to meet acceptance criteria and restrictions
 - When you've got full understanding of how exactly each component will interact with each other, create components

## Output Format
Store description of each component to the file `_docs/02_components/[##]_[component_name]/[##]._component_[component_name].md` with the next structure:
    1. High-level overview
        - **Purpose:** A concise summary of what this component does and its role in the larger system.
        - **Architectural Pattern:** Identify the design patterns used (e.g., Singleton, Observer, Factory).
    2. Logic & Architecture
        - **Control Flow Diagram:**
        - Generate a `graph TD` or `sequenceDiagram` in Mermaid syntax.
        - Generate draw.io components diagram shows relations between components. 
    3. API Reference. Create a table for eac function or method with the next columns:
        - Name
        - Description
        - Input
        - Output
        - Description of input and output data in case if it is not obvious
        - Test cases which could be for the method
    4. Implementation Details
        - **Algorithmic Complexity:** Analyze Time (Big O) and Space complexity for critical methods.
        - **State Management:** Explain how this component handles state (local vs. global).
        - **Dependencies:** List key external libraries and their purpose here.
    5. Tests
        - Integration tests for the component if needed.
        - Non-functional tests for the component if needed.
    6. Extensions and Helpers
        - Store Extensions and Helpers to support functionality across multiple components to a separate folder `_docs/02_components/helpers`.
    7. Caveats & Edge Cases
      - Known limitations
      - Potential race conditions
      - Potential performance bottlenecks.

## Notes
 - Strongly follow Single Responsibility Principle during creation of components.
 - Follow dumb code - smart data principle. Do not overcomplicate
 - Components should be semantically coherents. Do not spread similar functionality across multiple components
 - Do not put any code yet, only names, input and output.
 - Ask as many questions as possible to clarify all uncertainties.