mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 09:16:38 +00:00
Make prompts more stuctured.
Separate tutorial.md for developers from commands for AI WIP
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -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
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
+30
-24
@@ -1,10 +1,11 @@
|
||||
Read carefully about the problem:
|
||||
## The problem description
|
||||
We have a lot of images taken from a wing-type UAV using a camera with at least Full HD resolution. Resolution of each photo could be up to 6200*4100 for the whole flight, but for other flights, it could be FullHD. Photos are taken and named consecutively within 100 meters of each other.
|
||||
We know only the starting GPS coordinates. We need to determine the GPS of the centers of each image. And also the coordinates of the center of any object in these photos. We can use an external satellite provider for ground checks on the existing photos
|
||||
|
||||
We have a lot of images taken from a wing-type UAV using a camera with at least Full HD resolution. Resolution of each photo could be up to 6200*4100 for the whole flight, but for other flights, it could be FullHD
|
||||
Photos are taken and named consecutively within 100 meters of each other.
|
||||
We know only the starting GPS coordinates. We need to determine the GPS of the centers of each image. And also the coordinates of the center of any object in these photos. We can use an external satellite provider for ground checks on the existing photos
|
||||
## Data samples
|
||||
Are in attachments: images and csv
|
||||
|
||||
System has next restrictions and conditions:
|
||||
## Restrictions for the input data
|
||||
- Photos are taken by only airplane type UAVs.
|
||||
- Photos are taken by the camera pointing downwards and fixed, but it is not autostabilized.
|
||||
- The flying range is restricted by the eastern and southern parts of Ukraine (To the left of the Dnipro River)
|
||||
@@ -17,7 +18,7 @@ We know only the starting GPS coordinates. We need to determine the GPS of the c
|
||||
- During the flight, UAVs can make sharp turns, so that the next photo may be absolutely different from the previous one (no same objects), but it is rather an exception than the rule
|
||||
- Processing is done on a stationary computer or laptop with NVidia GPU at least RTX2060, better 3070. (For the UAV solution Jetson Orin Nano would be used, but that is out of scope.)
|
||||
|
||||
Output of the system should address next acceptance criteria:
|
||||
## Acceptance criteria for the output of the system:
|
||||
- The system should find out the GPS of centers of 80% of the photos from the flight within an error of no more than 50 meters in comparison to the real GPS
|
||||
|
||||
- The system should find out the GPS of centers of 60% of the photos from the flight within an error of no more than 20 meters in comparison to the real GPS
|
||||
@@ -40,7 +41,7 @@ We know only the starting GPS coordinates. We need to determine the GPS of the c
|
||||
|
||||
- The whole system should work as a background service. The interaction should be done by zeromq. Sevice should be up and running and awaiting for the initial input message. On the input message processing should started, and immediately after the first results system should provide them to the client
|
||||
|
||||
Here is a solution draft:
|
||||
## Existing solution draft:
|
||||
|
||||
# **ASTRAL-Next: A Resilient, GNSS-Denied Geo-Localization Architecture for Wing-Type UAVs in Complex Semantic Environments**
|
||||
|
||||
@@ -325,32 +326,37 @@ We know only the starting GPS coordinates. We need to determine the GPS of the c
|
||||
* Test_Performance: Run Test_Long_Route on min-spec RTX 2060. ASSERT average_time(Pose_N^{Est} output) < 5.0s (AC-7).
|
||||
* Test_MRE: ASSERT TOH.final_MRE < 1.0 (AC-10).
|
||||
|
||||
You are a professional software architect. Your task is to identify all potential weak points and problems. Address them and find out ways to solve them. Based on your findings, form a new solution draft in the same format.
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
If your finding requires a complete reorganization of the flow and different components, state it.
|
||||
Put all the findings regarding what was weak and poor at the beginning of the report. Put here all new findings, what was updated, replaced, or removed from the previous solution.
|
||||
## 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.
|
||||
|
||||
Then form a new solution design without referencing the previous system.
|
||||
Remove Poor and Very Poor component choices from the component analysis tables, but leave Good and Excellent ones.
|
||||
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
|
||||
## 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)
|
||||
|
||||
Produce the new solution draft in the next format:
|
||||
- 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
|
||||
- Limitations of this solution
|
||||
- Requirements for this solution
|
||||
- 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.
|
||||
|
||||
Also, investigate these ideas:
|
||||
- A Cross-View Geo-Localization Algorithm Using UAV Image
|
||||
https://www.mdpi.com/1424-8220/24/12/3719
|
||||
- Exploring the best way for UAV visual localization under Low-altitude Multi-view Observation condition
|
||||
https://arxiv.org/pdf/2503.10692
|
||||
and find out more like this.
|
||||
|
||||
Assess them and try to either integrate or replace some of the components in the current solution draft
|
||||
## Additional sources
|
||||
- A Cross-View Geo-Localization Algorithm Using UAV Image
|
||||
https://www.mdpi.com/1424-8220/24/12/3719
|
||||
- Exploring the best way for UAV visual localization under Low-altitude Multi-view Observation condition
|
||||
https://arxiv.org/pdf/2503.10692
|
||||
- find out more like this.
|
||||
Assess them and try to either integrate or replace some of the components in the current solution draft
|
||||
@@ -1,158 +0,0 @@
|
||||
# 1. Research phase
|
||||
|
||||
|
||||
## 1.1 **👨💻Developers**: Problem statement
|
||||
Discuss the problem and create in the `docs/00_problem` next files and folders:
|
||||
- `problem_description.md`: Our problem to solve with the end result we want to achieve.
|
||||
- `input_data`: Put to this folder all the necessary input data and expected results for the further tests. Analyze very thoroughly input data and form system's restrictions and acceptance ctiteria
|
||||
- `restrictions.md`: Restrictions we have in real world in the -dashed list format.
|
||||
- `acceptance_criteria.md`: Acceptance criteria for the solution in the -dashed list format.
|
||||
The most important part, determines how good the system should be.
|
||||
|
||||
### Example:
|
||||
- `problem_description.md`
|
||||
We have wing type UAV (airplane). It should fly autonomously to predetermined GPS destination. During the flight it is relying on the signal form GPS module.
|
||||
But when adversary jam or spoof GPS, then UAV either don't know where to fly, or fly to the wrong direction.
|
||||
So, we need to achieve that UAV can fly correctly to the destination without GPS or when GPS is spoofed. We can use the camera pointing downward and other sensor data like altitude, available form the flight controller. Airplane is running Ardupliot.
|
||||
- `input_data`
|
||||
- orthophoto images from the UAV for the analysis
|
||||
- list of expected GPS for the centers for each picture in csv format: picture name, lat, lon
|
||||
- video from the UAV for the analysis
|
||||
- list of expected GPS for the centers of video per timeframe in csv format: timestamp, lat, lon for each 1-2 seconds
|
||||
- ...
|
||||
- `restrictions.md`
|
||||
- We're limiting our solution to airplane type UAVs.
|
||||
- Additional weight it could take is under 1 kg.
|
||||
- The whole system should cost under $2000.
|
||||
- The flying range is restricted by eastern and southern part of Ukraine. And so on.
|
||||
- `acceptance_criteria.md`
|
||||
- UAV should fly without GPS for at least 30 km in the sunshine weather.
|
||||
- UAV shoulf fly with maximum mistake no more than 40 meters from the real GPS
|
||||
- UAV should fly correctly with little foggy weather with maximum mistake no more than 100 meters from the real GPS
|
||||
- UAV should fly for minimum of 500 meters with missing inernal Satellite maps and the drifting error should be no more than 50 meters.
|
||||
|
||||
|
||||
## 1.2 **✨AI Research**: Restrictions and Acceptance Criteria assesment
|
||||
Put to the research context:
|
||||
- `problem_description.md`
|
||||
- `restrictions.md`
|
||||
- `acceptance_criteria.md`
|
||||
- Samples of the input data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
## The problem
|
||||
`problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
look to the attached files (if any). They are for reference only.
|
||||
|
||||
## Restrictions for the input data
|
||||
`restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`acceptance_criteria.md`.
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task: to check 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.
|
||||
|
||||
### 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
|
||||
```
|
||||
**👨💻Developers**: Revise the result, discuss them and overwrite `acceptance_criteria.md` and `restrictions.md`
|
||||
|
||||
|
||||
## 1.3 **✨AI Research**: Research the problem in great detail
|
||||
Replace md files with actual data
|
||||
Put to the research context samples of the input data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
The problem is described here:
|
||||
|
||||
`problem_description.md`
|
||||
|
||||
The system should process data samples in the attached files (if any). They are for reference only.
|
||||
The system has next restrictions and conditions:
|
||||
|
||||
`restrictions.md`
|
||||
|
||||
- Output of our system should meet these acceptance criteria:
|
||||
|
||||
`acceptance_criteria.md`
|
||||
|
||||
You are a professional software architect.
|
||||
Your task is to research 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 most efficient state-of-the-art solutions.
|
||||
|
||||
Be concise in formulating. The fewer words, the better, but do not miss any important details.
|
||||
|
||||
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
|
||||
- Limitations of this solution
|
||||
- Requirements for this solution
|
||||
- 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.
|
||||
```
|
||||
**👨💻Developer**: Revise the result from AI. Research the problem as well, and add/modify/remove some solution details in the draft.
|
||||
Store it to the `docs/01_solution/solution_draft.md`
|
||||
|
||||
|
||||
## 1.4 **✨AI Research**: Solution draft assessment
|
||||
Replace md files with actual data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
Read carefully about the problem:
|
||||
|
||||
`problem_description.md`
|
||||
|
||||
System has next restrictions and conditions:
|
||||
|
||||
`restrictions.md`
|
||||
|
||||
Output of the system should address next acceptance criteria:
|
||||
|
||||
`acceptance_criteria.md`
|
||||
|
||||
Here is a solution draft:
|
||||
|
||||
`solution_draft.md`
|
||||
|
||||
You are a professional software architect. Your task is to identify all potential weak points and problems. Address them and find out ways to solve them. Based on your findings, form a new solution draft in the same format.
|
||||
|
||||
If your finding requires a complete reorganization of the flow and different components, state it.
|
||||
Put all the findings regarding what was weak and poor at the beginning of the report. Put here all new findings, what was updated, replaced, or removed from the previous solution.
|
||||
|
||||
Then form a new solution design without referencing the previous system.
|
||||
Remove Poor and Very Poor component choices from the component analysis tables, but leave Good and Excellent ones.
|
||||
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
|
||||
|
||||
Produce the new 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
|
||||
- Limitations of this solution
|
||||
- Requirements for this solution
|
||||
- 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.
|
||||
```
|
||||
**👨💻Developer**: Research by yourself as well - how to solve additional problems which AI figured out, and add them to the result. Rename previous `solution_draft.md` to `xx_solution_draft.md`. And then store the result draft to the `docs/01_solution/solution_draft.md`, and repeat the process. When the next solution wouldn't differ much from the previous one, store the last draft as `docs/01_solution/solution.md`
|
||||
@@ -1,5 +0,0 @@
|
||||
# 2. Planning phase
|
||||
|
||||
## 2.1 **🤖📋AI plan** /gen_components
|
||||
## 2.2 **🤖📋AI plan** /gen_tests
|
||||
## 2.3 **🤖📋AI plan** /gen_epics
|
||||
@@ -1,43 +0,0 @@
|
||||
# 3. Development phase
|
||||
|
||||
## 3.1 **🤖📋AI plan**: Component Decomposition
|
||||
For each component in `docs/02_components` do next:
|
||||
```
|
||||
Decompose `@docs/02_components/[##]_[component_name]/spec.md` to the features. If component is simple enough, make only 1 feature, if complex - separate per features. Feature can contain 0 or more APIs. Create `docs/02_components/[##]_[component_name]/[##]_[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
|
||||
|
||||
Do NOT generate any code yet, only brief explanations what should be done.
|
||||
Ask as many questions as needed.
|
||||
```
|
||||
**👨💻Developer**: Answer the questions AI asked, put as many details as possible
|
||||
|
||||
## 3.2 **🤖AI agent**: Feature implementation
|
||||
For each component in `docs/02_components/[##]_[component_name]/` folder do next:
|
||||
```
|
||||
Read component description `@docs/02_components/[##]_[component_name]/spec.md`.
|
||||
Read all features in the folder `@docs/02_components/[##]_[component_name]`. For each feature do next:
|
||||
- Implement it
|
||||
- Make sure feature is connected and communicated properly with other features and existing code
|
||||
- Create unit tests from the Test cases description, run it and make sure the result is a success
|
||||
- Create integration test for the feature, run and make sure the result is a success
|
||||
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
|
||||
```
|
||||
|
||||
## 3.3 **🤖AI agent**: Solution composition and integration tests
|
||||
```
|
||||
Read all the files here `docs/03_tests/` and for each file write down tests and run it.
|
||||
Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
Fix all problems if tests failed until we got a successful result.
|
||||
In case if one or more tests was failed due to missing data from user or API or other system, ask it from developer.
|
||||
Repeat test cycle until no failed tests.
|
||||
```
|
||||
@@ -0,0 +1,151 @@
|
||||
# 1 Research Phase
|
||||
|
||||
## 1.0 Problem statement
|
||||
### Discuss
|
||||
Discuss the problem and create in the `docs/00_problem` next files and folders:
|
||||
- `problem_description.md`: Our problem to solve with the end result we want to achieve.
|
||||
- `input_data`: Put to this folder all the necessary input data and expected results for the further tests. Analyze very thoroughly input data and form system's restrictions and acceptance ctiteria
|
||||
- `restrictions.md`: Restrictions we have in real world in the -dashed list format.
|
||||
- `acceptance_criteria.md`: Acceptance criteria for the solution in the -dashed list format.
|
||||
The most important part, determines how good the system should be.
|
||||
|
||||
### Example:
|
||||
- `problem_description.md`
|
||||
We have wing type UAV (airplane). It should fly autonomously to predetermined GPS destination. During the flight it is relying on the signal form GPS module.
|
||||
But when adversary jam or spoof GPS, then UAV either don't know where to fly, or fly to the wrong direction.
|
||||
So, we need to achieve that UAV can fly correctly to the destination without GPS or when GPS is spoofed. We can use the camera pointing downward and other sensor data like altitude, available form the flight controller. Airplane is running Ardupliot.
|
||||
- `input_data`
|
||||
- orthophoto images from the UAV for the analysis
|
||||
- list of expected GPS for the centers for each picture in csv format: picture name, lat, lon
|
||||
- video from the UAV for the analysis
|
||||
- list of expected GPS for the centers of video per timeframe in csv format: timestamp, lat, lon for each 1-2 seconds
|
||||
- ...
|
||||
- `restrictions.md`
|
||||
- We're limiting our solution to airplane type UAVs.
|
||||
- Additional weight it could take is under 1 kg.
|
||||
- The whole system should cost under $2000.
|
||||
- The flying range is restricted by eastern and southern part of Ukraine. And so on.
|
||||
- `acceptance_criteria.md`
|
||||
- UAV should fly without GPS for at least 30 km in the sunshine weather.
|
||||
- UAV shoulf fly with maximum mistake no more than 40 meters from the real GPS
|
||||
- UAV should fly correctly with little foggy weather with maximum mistake no more than 100 meters from the real GPS
|
||||
- UAV should fly for minimum of 500 meters with missing inernal Satellite maps and the drifting error should be no more than 50 meters.
|
||||
|
||||
|
||||
## 1.1 **✨AI Research**: Restrictions and Acceptance Criteria assesment
|
||||
|
||||
### Execute `/1.research/1.1_research_assesment_acceptance_criteria`
|
||||
In case of external DeepResearch (Gemini, DeepSeek, or other), copypaste command's text and put to the research context:
|
||||
- `problem_description.md`
|
||||
- `restrictions.md`
|
||||
- `acceptance_criteria.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
- Revise the result, discuss it
|
||||
- Overwrite `acceptance_criteria.md` and `restrictions.md`
|
||||
|
||||
|
||||
## 1.2 **✨AI Research**: Research the problem in great detail
|
||||
|
||||
### Execute `/1.research/1.2_research_problem`
|
||||
In case of external DeepResearch (Gemini, DeepSeek, or other), copypaste command's text and put to the research context:
|
||||
- `problem_description.md`
|
||||
- `restrictions.md`
|
||||
- `acceptance_criteria.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
- Revise the result from AI.
|
||||
- Research the problem as well
|
||||
- Add/modify/remove some solution details in the draft. (Also with AI)
|
||||
- Store it to the `docs/01_solution/solution_draft.md`
|
||||
|
||||
|
||||
## 1.3 **✨AI Research**: Solution draft assessment
|
||||
|
||||
### Execute `/1.research/1.3_solution_draft_assessment`
|
||||
In case of external DeepResearch (Gemini, DeepSeek, or other), copypaste command's text and put to the research context:
|
||||
- `problem_description.md`
|
||||
- `restrictions.md`
|
||||
- `acceptance_criteria.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
- Research by yourself as well - how to solve additional problems which AI figured out, and add them to the result.
|
||||
|
||||
### Iterate
|
||||
- Rename previous `solution_draft.md` to `{xx}_solution_draft.md`. Start {xx} from 01
|
||||
- Store the new revised result draft to the `docs/01_solution/solution_draft.md`
|
||||
- Repeat the process 1.3 from the beginning
|
||||
|
||||
When the next solution wouldn't differ much from the previous one, store the last draft as `docs/01_solution/solution.md`
|
||||
|
||||
|
||||
|
||||
# 2. Planning phase
|
||||
|
||||
## 2.1 **🤖📋AI plan**: Generate components
|
||||
|
||||
### Execute `/gen_components`
|
||||
|
||||
### Revise
|
||||
- Revise the plan, answer questions, put detailed descriptions
|
||||
- Make sure stored components are coherent and make sense
|
||||
|
||||
|
||||
## 2.2 **🤖📋AI plan**: Generate tests
|
||||
|
||||
### Execute `/gen_tests`
|
||||
|
||||
### Revise
|
||||
- Revise the tests, answer questions, put detailed descriptions
|
||||
- Make sure stored tests are coherent and make sense
|
||||
|
||||
## 2.3 **🤖📋AI plan**: Generate Jira Epics
|
||||
|
||||
### Execute `/gen_epics`
|
||||
|
||||
### Revise
|
||||
- Revise the epics, answer questions, put detailed descriptions
|
||||
- Make sure epics are coherent and make sense
|
||||
|
||||
## 2.4 **🤖📋AI plan**: Component Decomposition To Features
|
||||
### Execute
|
||||
For each component in `docs/02_components` run
|
||||
`/gen_features --component @docs/02_components/[##]_[component_name]/[component_name]_spec.md`
|
||||
|
||||
### Revise
|
||||
- Revise the features, answer questions, put detailed descriptions
|
||||
- Make sure features are coherent and make sense
|
||||
|
||||
|
||||
|
||||
# 3. Development phase
|
||||
|
||||
## 3.1 **🤖AI agent**: Feature implementation
|
||||
For each component in `docs/02_components/[##]_[component_name]/` folder do next:
|
||||
```
|
||||
Read component description `@docs/02_components/[##]_[component_name]/spec.md`.
|
||||
Read all features in the folder `@docs/02_components/[##]_[component_name]`. For each feature do next:
|
||||
- Implement it
|
||||
- Make sure feature is connected and communicated properly with other features and existing code
|
||||
- Create unit tests from the Test cases description, run it and make sure the result is a success
|
||||
- Create integration test for the feature, run and make sure the result is a success
|
||||
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
|
||||
```
|
||||
|
||||
## 3.2 **🤖AI agent**: Solution composition and integration tests
|
||||
```
|
||||
Read all the files here `docs/03_tests/` and for each file write down tests and run it.
|
||||
Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
Fix all problems if tests failed until we got a successful result.
|
||||
In case if one or more tests was failed due to missing data from user or API or other system, ask it from developer.
|
||||
Repeat test cycle until no failed tests.
|
||||
```
|
||||
|
||||
# 4. Refactoring phase
|
||||
Reference in New Issue
Block a user