organize structure for .roo and for ai in general

rework rulels

_ai/commands/2.planning/2.10_plan_components.md

@@ -0,0 +1,82 @@
+# 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`
+ - Security approach: `@_docs/00_problem/security_approach.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
+
+### Components Decomposition
+
+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. API Reference. Create a table for each 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
+    3. 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.
+        - **Error Handling:** Define error handling strategy for this component.
+    4. Tests
+        - Integration tests for the component if needed.
+        - Non-functional tests for the component if needed.
+    5. Extensions and Helpers
+        - Store Extensions and Helpers to support functionality across multiple components to a separate folder `_docs/02_components/helpers`.
+    6. Caveats & Edge Cases
+      - Known limitations
+      - Potential race conditions
+      - Potential performance bottlenecks.
+
+### Dependency Graph
+ - Create component dependency graph showing implementation order
+ - Identify which components can be implemented in parallel
+
+### API Contracts
+ - Define interfaces/contracts between components
+ - Specify data formats exchanged
+
+### Logging Strategy
+ - Define global logging approach for the system
+ - Log levels, format, storage
+
+For the whole system make these diagrams and store them to `_docs/02_components`:
+
+### Logic & Architecture
+    - Generate draw.io components diagrams shows relations between components.
+        - Make sure lines are not intersect each other, or at least try to minimize intersections.
+        - Group the semantically coherent components into the groups
+        - Leave enough space for the nice alignment of the components boxes
+        - Put external users of the system closer to those components' blocks they are using
+
+    - Generate a Mermaid Flowchart diagrams for each of the main control flows
+        - Create multiple flows system can operate, and generate a flowchart diagram per each flow
+        - Flows can relate to each other
+
+## Notes
+ - Strongly follow Single Responsibility Principle during creation of components.
+ - Follow dumb code - smart data principle. Do not overcomplicate
+ - Components should be semantically coherent. 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.