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

organize structure for .roo and for ai in general

Browse Source 
rework rulels
This commit is contained in:
Oleksandr Bezdieniezhnykh
2025-12-10 19:59:13 +02:00
parent 749c8e674d
commit 8a284eb106
84 changed files with 3044 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.roo/commands/1.30_solution_draft_assessment.md
+40
View File
@@ -0,0 +1,40 @@
# Solution Draft 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`
- Existing solution draft: `@_docs/01_solution/solution_draft.md`
## Role
You are a professional software architect
## Task
- Thoroughly research in internet about the problem and identify all potential weak points and problems.
- Identify security weak points and vulnerabilities.
- Identify performance bottlenecks.
- 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 (functional/security/performance)
- 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
- Limitations of this solution
- Requirements for this solution
- Security considerations
- Performance characteristics
- 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.