azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-04-23 01:46:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

prompt fine tuning

Browse Source
This commit is contained in:
Oleksandr Bezdieniezhnykh
2025-11-22 15:20:02 +02:00
parent d49520bb71
commit bda8531d9e
4 changed files with 407 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/_metodology/01_research_phase.md
+51 -21
View File
@@ -40,19 +40,32 @@
- Samples of the input data
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
```
The problem is described in `problem_description.md`.
- System should process data samples in the attached files (if any). They are for reference only.
- Restrictions for the input data are stated in `restrictions.md`.
- Acceptance criteria for the output of the system are stated in `acceptance_criteria.md`.
## The problem
`problem_description.md`.
You are a professional software architect. Your task is 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:
## 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:
### 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
@@ -79,18 +92,23 @@ The problem is described here:
`acceptance_criteria.md`
You are a professional software architect. Your task is to research all the possible ways to solve a problem, possibly split it to subproblems and research all the possible ways to solve subproblems respectfully, and find out most efficient state-of-the-art solutions.
Produce the resulting solution draft in the next format:
- Short Product solution description. Brief component interaction diagram.
- Architecture approach that meets restrictions and acceptance criteria. For each component, analyze the best possible approaches to solve, and form a table comprising all approaches. Each new approach would be a row, and has the next columns:
- Tools (library, platform) to solve component tasks
- Advantages of this approach
- Limitations of this approach
- Requirements for this approach
- How does it fit for the problem component that has to be solved, and the whole solution
- Testing strategy. Research the best approaches to cover all the acceptance criteria. Form a list of integration functional tests and non-functional tests.
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.
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`
@@ -116,13 +134,25 @@ Read carefully about the problem:
`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.
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.
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`