Make prompts more stuctured.

Separate tutorial.md for developers from commands for AI
WIP

.cursor/commands/1.research/1.1_research_assesment_acceptance_criteria.md

@@ -0,0 +1,33 @@
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Role
+  You are a professional software architect
+
+## Task
+  - Thorougly research in internet about the problem and how realistic these acceptance criteria are.
+  - Check how critical each criterion is. 
+  - Find out more acceptance criteria for this specific domain.
+  - Research the impact of each value in the acceptance criteria on the whole system quality. 
+  
+## Output format
+  Assess acceptable ranges for each value in each acceptance criterion in the state-of-the-art solutions, and propose corrections in the next table:
+   - Acceptance criterion name
+   - Our values
+   - Your researched criterion values
+   - Status: Is the criterion added by your research to our system, modified, or removed
+  
+  ### Assess the restrictions we've put on the system. Are they realistic? Should we add more strict restrictions, or vise versa, add more requirements in restrictions to use our system. Propose corrections in the next table:
+   - Restriction name
+   - Our values
+   - Your researched restriction values 
+   - Status: Is a restriction added by your research to our system, modified, or removed

.cursor/commands/1.research/1.2_research_problem.md

@@ -0,0 +1,32 @@
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Role
+  You are a professional software architect
+
+## Task
+  - Thorougly research in internet about the problem and all the possible ways to solve a problem, and split it to components.
+  - Then research all the possible ways to solve components, and find out the most efficient state-of-the-art solutions.
+ Be concise in formulating. The fewer words, the better, but do not miss any important details.
+
+## Output format
+    Produce the resulting solution draft in the next format:
+   - Short Product solution description. Brief component interaction diagram.
+   - Architecture solution that meets restrictions and acceptance criteria. 
+    For each component, analyze the best possible solutions, and form a comparison table. 
+    Each possible component solution would be a row, and has the next columns:
+     - Tools (library, platform) to solve component tasks
+     - Advantages of this solution. For example, LiteSAM AI feature is picked for UAV - Satellite matching finding, and it make its job perfectly in milliseconds timeframe. 
+     - Limitations of this solution. For example, LiteSAM AI feature matcher requires to work efficiently on RTX Gpus and since it is sparsed, the quality a bit lower than densed feature matcher.
+     - Requirements for this solution. For example, LiteSAM AI feature matcher requires that photos it comparing to be aligned by rotation with no more than 45 degree difference. This requires additional preparation step for pre-rotating either UAV either Satellite images in order to be aligned.
+     - How does it fit for the problem component that has to be solved, and the whole solution 
+   - Testing strategy. Research how to cover system with tests in order to meet all the acceptance criteria. Form a list of integration functional tests and non-functional tests.

.cursor/commands/1.research/1.3_solution_draft_assessment.md

@@ -0,0 +1,41 @@
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Existing solution draft:
+ `@docs/01_solution/solution_draft.md`
+  
+## Role
+  You are a professional software architect
+
+## Task
+  - Thorougly research in internet about the problem and identify all potential weak points and problems.
+  - Address these problems and find out ways to solve them.
+  - Based on your findings, form a new solution draft in the same format.
+  
+## Output format
+  - Put here all new findings, what was updated, replaced, or removed from the previous solution in the next table:
+   - Old component solution
+   - Weak point
+   - Solution (component's new solution)  
+  
+  - Form the new solution draft. In the updated report, do not put "new" marks, do not compare to the previous solution draft, just make a new solution as if from scratch. Put it in the next format:
+   - Short Product solution description. Brief component interaction diagram.
+   - Architecture solution that meets restrictions and acceptance criteria. 
+    For each component, analyze the best possible solutions, and form a comparison table. 
+    Each possible component solution would be a row, and has the next columns:
+     - Tools (library, platform) to solve component tasks
+     - Advantages of this solution. For example, LiteSAM AI feature is picked for UAV - Satellite matching finding, and it make its job perfectly in milliseconds timeframe. 
+     - Limitations of this solution. For example, LiteSAM AI feature matcher requires to work efficiently on RTX Gpus and since it is sparsed, the quality a bit lower than densed feature matcher.
+     - Requirements for this solution. For example, LiteSAM AI feature matcher requires that photos it comparing to be aligned by rotation with no more than 45 degree difference. This requires additional preparation step for pre-rotating either UAV either Satellite images in order to be aligned.
+     - How does it fit for the problem component that has to be solved, and the whole solution 
+   - Testing strategy. Research how to cover system with tests in order to meet all the acceptance criteria. Form a list of integration functional tests and non-functional tests.
+   

.cursor/commands/2.planning/2.1_gen_components.md

@@ -0,0 +1,46 @@
+# decompose
+
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Existing solution:
+ `@docs/01_solution/solution_draft.md`
+
+## Role
+  You are a professional software architect
+
+## Task
+ - 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
+ - Think about possible requirements needed for complete full interaction flow.
+ - When you've got full understanding of how exactly each component will interact with each other
+
+## Output
+ - When all the uncertainties would be cleared by user, store description of each component to the file `docs/02_components/[##]_[component_name]/[component_name]_spec.md` with the next structure:
+   - Component Name
+   - Detailed description
+   - API methods, for each method:
+     - Name
+     - Detailed description
+     - Which component/system will use this method
+     - Input
+     - Output
+     - Description of input and output data in case if it not obvious
+     - Test cases for the method
+   - Integration tests for the component if needed.
+   - Non-functional tests for the component if needed.
+ - Extensions and helpers to support functionality across multiple components store to a separate folder `docs/02_components/helpers`.
+ - Generate draw.io components diagram shows relations between components. 
+
+## Notes
+ Do not put any code yet, only names, input and output.
+ Ask as many questions as possible to clarify all uncertainties.

.cursor/commands/2.planning/2.2_gen_epics.md

@@ -0,0 +1,24 @@
+# generate Jira Epics
+
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Existing solution:
+ `@docs/01_solution/solution_draft.md`
+
+## Role
+  You are a professional product manager
+
+## Task
+  - Generate Jira Epics from the Components
+  - 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 Jira Epic numbers corresponding to each component.

.cursor/commands/2.planning/2.3_gen_tests.md

@@ -0,0 +1,37 @@
+# generate Tests
+
+## The problem description
+ `@docs/00_problem/problem_description.md`.
+
+## Data samples
+  Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
+
+## Restrictions for the input data
+   `@docs/00_problem/restrictions.md.md`.
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Existing solution:
+ `@docs/01_solution/solution_draft.md`
+
+## Role
+  You are a professional Quality Assurance Engineer
+
+## Task
+ - Compose tests according to the test strategy
+ - Cover all the the criteria with tests specs
+
+## Output
+ - Store all tests specs to the files `docs/03_tests/[##]_[test_name]_spec.md` with the next structure for each test file:
+   - Summary
+   - Detailed description
+   - Preconditions for tests
+   - Steps:
+     - Step1 - Expected result1
+     - Step2 - Expected result2  
+     ...
+     - StepN - Expected resultN
+
+## Notes
+  Do not put any code yet. Ask as many questions as needed.

.cursor/commands/2.planning/2.4_gen_features.md

@@ -0,0 +1,31 @@
+# generate Features for the provided component spec
+
+## Input parameter
+ --component @component_spec.md
+
+## Existing solution:
+ `@docs/01_solution/solution_draft.md`
+
+## Acceptance criteria for the output of the system:
+ `@docs/00_problem/acceptance_criteria.md`.  
+
+## Role
+  You are a professional software architect
+
+## Task
+ Decompose component_spec to the features. If component is simple enough, make only 1 feature, if complex - separate per features.
+Feature can contain 0 or more APIs.
+
+## Output
+ In a component's folder create feature specs `[##]_[feature_name]_feature.md` with the next structure:  
+  - Name
+  - Description
+  - Component APIs it implements if any
+  - External tools and service it uses for implementation if any
+  - Internal methods and its purposes
+  - Unit tests
+  - Integration tests
+
+## Notes
+  Do NOT generate any code yet, only brief explanations what should be done.  
+  Ask as many questions as needed.

.cursor/commands/gen_components.md

@@ -1,28 +0,0 @@
-# decompose
- The problem description is here: `@docs/00_problem/problem_description`.
- It has these restrictions: `@docs/00_problem/restrictions.md`.
- It should meet these acceptance criteria: `@docs/00_problem/acceptance_criteria.md`
- 
-Here is a proposed solution to the problem: `@docs/01_solution/solution.md`.
- 
-You are a professional software architect. Your task is a correct decomposition complex system to the components with proper communications between them, so that system would solve the problem. 
- Think about components and its interaction, think about possible requirements needed for complete full interaction flow. When you've got full understanding of how exactly each component will interact with each other
- Ask as many questions as possible to clarify all uncertainties.
- Then, when all the uncertainties would be cleared by user, store description of each component to the file `docs/02_components/[##]_[component_name]/[component_name]_spec.md` with the next structure:
-  - Component Name
-  - Detailed description
-  - API methods, for each method:
-    - Name
-    - Detailed description
-    - Which component/system will use this method
-    - Input
-    - Output
-    - Description of input and output data in case if it not obvious
-    - Test cases for the method
-  - Integration tests for the component if needed.
-  - Non-functional tests for the component if needed. 
- Also, it is possible that some additional helpers or extensions needed to support functionality for multiple components, state them in a separate folder 
- `docs/02_components/helpers`.
-
- Generate draw.io components diagram shows relations between components. 
- Do not put any code yet, only names, input and output.

.cursor/commands/gen_epics.md

@@ -1,8 +0,0 @@
-# generate Jira Epics
-
-Read the solution spec `@docs/01_solution/solution.md`
-Read description of all the components in the folder `@docs/02_components` - go to each folder and read /[component_name]/spec.md
-Read the acceptance criteria from `@docs/00_initial/acceptance_criteria.md`
-  - Generate Jira Epics from the Components
-  - 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 Jira Epic numbers corresponding to each component.

.cursor/commands/gen_tests.md

@@ -1,14 +0,0 @@
-# generate Tests
-
-Read the `@docs/01_solution/solution.md` and `@docs/00_problem/acceptance_criteria.md` and compose tests according to test strategy to cover all the criteria and store them to the files
-  `docs/03_tests/[##]_[test_name]_spec.md` with the next structure for each test file:
-   - Summary
-   - Detailed description
-   - Preconditions for tests
-   - Steps:
-     - Step1 - Expected result1
-     - Step2 - Expected result2  
-     ...
-     - StepN - Expected resultN
-   
-   Do not put any code yet. Ask as many questions as needed.