review of all AI-dev system #01

add refactoring phase complete implementation phase fix wrong links and file names
2026-04-23 08:26:37 +00:00 · 2025-12-09 12:11:29 +02:00
parent d5c036e6f7
commit 73cbe43397
35 changed files with 1215 additions and 206 deletions
@@ -1,10 +1,11 @@
-# decompose
+# 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
@@ -19,38 +20,63 @@
 - 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. 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:
+    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
-    4. Implementation Details
+    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.
-    5. Tests
+        - **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.
-    6. Extensions and Helpers
+    5. 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
+    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 coherents. Do not spread similar functionality across multiple components
+ - 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.
+ - Ask as many questions as possible to clarify all uncertainties.
@@ -1,10 +1,11 @@
-# component assesment
+# Component Assessment

 ## 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
@@ -12,14 +13,18 @@

 ## Task
    - Read carefully all the documents above
-    - check all the components @02_components how coherent they are
+    - Check all the components @02_components how coherent they are
    - Follow interaction logic and flows, try to find some potential problems there
    - Try to find some missing interaction or circular dependencies
    - Check all the components follows Single Responsibility Principle
    - Check all the follows dumb code - smart data principle. So that resulting code shouldn't be overcomplicated
+    - Check for security vulnerabilities in component design
+    - Check for performance bottlenecks
+    - Verify API contracts are consistent across components

 ## Output
    Form a list of problems with fixes in the next format:
    - Component
+    - Problem type (Architectural/Security/Performance/API)
    - Problem, reason
-    - Fix or potential fixes
+    - Fix or potential fixes
@@ -0,0 +1,36 @@
+# Security Check
+
+## Initial data:
+ - Problem description: `@_docs/00_problem/problem_description.md`
+ - Restrictions: `@_docs/00_problem/restrictions.md`
+ - Security approach: `@_docs/00_problem/security_approach.md`
+ - Full Solution Description: `@_docs/01_solution/solution.md`
+ - Components: `@_docs/02_components`
+
+## Role
+  You are a security architect
+
+## Task
+ - Review each component against security requirements
+ - Identify security gaps in component design
+ - Verify security controls are properly distributed across components
+ - Check for common vulnerabilities (injection, auth bypass, data leaks)
+
+## Output
+  ### Security Assessment per Component
+   For each component:
+   - Component name
+   - Security gaps found
+   - Required security controls
+   - Priority (High/Medium/Low)
+
+  ### Cross-Component Security
+   - Authentication flow assessment
+   - Authorization gaps
+   - Data flow security (encryption in transit/at rest)
+   - Logging for security events
+
+  ### Recommendations
+   - Required changes before implementation
+   - Security helpers/components to add
+
@@ -1,4 +1,4 @@
-# generate Jira Epics
+# Generate Jira Epics

 ## Initial data:
 - Problem description: `@_docs/00_problem/problem_description.md`
@@ -6,12 +6,15 @@
 - Restrictions: `@_docs/00_problem/restrictions.md`
 - Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
 - Full Solution Description: `@_docs/01_solution/solution.md`
+ - Components: `@_docs/02_components`

 ## Role
  You are a world class product manager

 ## Task
-  - Generate Jira Epics from the Components Using Jira MCP
+  - Generate Jira Epics from the Components using Jira MCP
+  - Order epics by dependency (which must be done first)
+  - Include rough effort estimation per epic
  - Ensure each epic has clear goal and acceptance criteria, verify it with acceptance criteria
  - Generate draw.io components diagram based on previous diagram shows relations between components and current Jira Epic number, corresponding to each component.

@@ -29,17 +32,20 @@
 - Assumptions
  - System design specifics, input material quality, data structures, network availability etc
 - Dependencies
+  - Other epics that must be completed first
  - Other components, services, hardware, environments, certificates, data sources etc.
+ - Effort Estimation
+  - T-shirt size (S/M/L/XL) or story points range
 - Users / Consumers
  - Internal, External, Systems, Short list of the key use cases.
 - Requirements
  - Functional - API expectations, events, data handling, idempotency, retry behavior etc
-  - Non-functional -Availability, latency, throughput, scalability, processing limits, data retention etc
-  - Security/Compliance - Authentication, encryption, secrets, logging, SOC2/ISO is applicable
+  - Non-functional - Availability, latency, throughput, scalability, processing limits, data retention etc
+  - Security/Compliance - Authentication, encryption, secrets, logging, SOC2/ISO if applicable
 - Design & Architecture (links)
-  - High-level diagram link , Data flow, sequence diagrams, schemas etc
+  - High-level diagram link, Data flow, sequence diagrams, schemas etc
 - Definition of Done (Epic-level)
-  - Feature list  per epic scope
+  - Feature list per epic scope
  - Automated tests (unit/integration/e2e) + minimum coverage threshold met
  - Runbooks if applicable
  - Documentation updated
@@ -57,6 +63,5 @@
   - Tasks
   - Technical enablers
  
-  ## Notes
-   - Be as much concise as possible in formulating epics. The less words with the same meaning - the better epic is.
-  
+## Notes
+ - Be as much concise as possible in formulating epics. The less words with the same meaning - the better epic is.
@@ -1,10 +1,11 @@
-# generate Tests
+# Generate Tests

 ## 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
@@ -12,10 +13,11 @@

 ## Task
 - Compose tests according to the test strategy
- - Cover all the the criteria with tests specs
+ - Cover all the criteria with tests specs
+ - Minimum coverage target: 75%

 ## Output
- Store all tests specs to the files `_docs/03_tests/[##]_[test_name]_spec.md`
+ Store all tests specs to the files `_docs/02_tests/[##]_[test_name]_spec.md`
 Types and structures of tests:

 - Integration tests
@@ -24,8 +26,20 @@
   - Input data for this specific test scenario
   - Expected result
   - Maximum expected time to get result
+
+ - Performance tests
+   - Summary
+   - Load/stress scenario description
+   - Expected throughput/latency
+   - Resource limits
+
+ - Security tests
+   - Summary
+   - Attack vector being tested
+   - Expected behavior
+   - Pass/Fail criteria
 
- - Acceptance tests:
+ - Acceptance tests
   - Summary
   - Detailed description
   - Preconditions for tests
@@ -35,6 +49,11 @@
     ...
     - StepN - Expected resultN

+ - Test Data Management
+   - Required test data
+   - Setup/Teardown procedures
+   - Data isolation strategy
+
 ## Notes
  - Do not put any code yet
-  - Ask as many questions as needed.
+  - Ask as many questions as needed.
@@ -1,9 +1,12 @@
-# generate Features for the provided component spec
+# Generate Features for the provided component spec

 ## Input parameters
 - component_spec.md. Required. Do NOT proceed if it is NOT provided!
 - parent Jira Epic in the format AZ-###. Required. Do NOT proceed if it is NOT provided!

+## Prerequisites
+ - Jira Epics must be created first (step 2.20)
+
 ## 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
@@ -20,15 +23,18 @@
 - Split to the many features only if it necessary and would be easier to implement
 - Do not create features of other components, create *only* features of this exact component
 - Each feature should be atomic, could contain 0 API, or list of semantically connected APIs
- - After splitting asses yourself
+ - After splitting assess yourself
+ - Add complexity points estimation (1, 2, 3, 5, 8) per feature
+ - Note feature dependencies (some features may be independent)
 - Use `@gen_feature_spec.md` as a complete guidance how to generate feature spec
- - Generate Jira tasks per each feature using this spec `@gen_jira_task.md` usint Jira MCP.
+ - Generate Jira tasks per each feature using this spec `@gen_jira_task_and_branch.md` using Jira MCP.

 ## Output
 - The file name of the feature specs should follow this format: `[component's number ##].[feature's number ##]_feature_[feature_name].md`.
 - The structure of the feature spec should follow this spec `@gen_feature_spec.md`
- - The structure of the Jira task should follow this spec: `@gen_jira_task.md`
+ - The structure of the Jira task should follow this spec: `@gen_jira_task_and_branch.md`
+ - Include dependency notes (which features can be done in parallel)

 ## Notes
  - Do NOT generate any code yet, only brief explanations what should be done.  
-  - Ask as many questions as needed.
+  - Ask as many questions as needed.