mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-22 22:56:35 +00:00
organize structure for .roo and for ai in general
rework rulels
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,36 @@
|
||||
# Research Acceptance Criteria
|
||||
|
||||
## 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`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task
|
||||
- Thoroughly 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.
|
||||
- Verify your findings with authoritative sources (official docs, papers, benchmarks).
|
||||
- Consider cost/budget implications of each criterion.
|
||||
- Consider timeline implications - how long would it take to meet each criterion.
|
||||
|
||||
## 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
|
||||
- Cost/Timeline impact
|
||||
- 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 vice versa, add more requirements in restrictions to use our system. Propose corrections in the next table:
|
||||
- Restriction name
|
||||
- Our values
|
||||
- Your researched restriction values
|
||||
- Cost/Timeline impact
|
||||
- Status: Is a restriction added by your research to our system, modified, or removed
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Research Problem
|
||||
|
||||
## 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`
|
||||
|
||||
## Role
|
||||
You are a professional researcher and software architect
|
||||
|
||||
## Task
|
||||
- Research existing/competitor solutions for similar problems.
|
||||
- Thoroughly 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.
|
||||
- Verify that suggested tools/libraries actually exist and work as described.
|
||||
- Include security considerations in each component analysis.
|
||||
- Provide rough cost estimates for proposed 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.
|
||||
- Existing/competitor solutions analysis (if any).
|
||||
- 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
|
||||
- Estimated cost
|
||||
- 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,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.
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
# Tech Stack Selection
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Security approach: `@_docs/00_problem/security_approach.md`
|
||||
- Solution draft: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a software architect evaluating technology choices
|
||||
|
||||
## Task
|
||||
- Evaluate technology options against requirements
|
||||
- Consider team expertise and learning curve
|
||||
- Assess long-term maintainability
|
||||
- Document selection rationale
|
||||
|
||||
## Output
|
||||
|
||||
### Requirements Analysis
|
||||
|
||||
#### Functional Requirements
|
||||
| Requirement | Tech Implications |
|
||||
|-------------|-------------------|
|
||||
| [From acceptance criteria] | |
|
||||
|
||||
#### Non-Functional Requirements
|
||||
| Requirement | Tech Implications |
|
||||
|-------------|-------------------|
|
||||
| Performance | |
|
||||
| Scalability | |
|
||||
| Security | |
|
||||
| Maintainability | |
|
||||
|
||||
#### Constraints
|
||||
| Constraint | Impact on Tech Choice |
|
||||
|------------|----------------------|
|
||||
| [From restrictions] | |
|
||||
|
||||
### Technology Evaluation
|
||||
|
||||
#### Programming Language
|
||||
|
||||
| Option | Pros | Cons | Score (1-5) |
|
||||
|--------|------|------|-------------|
|
||||
| | | | |
|
||||
|
||||
**Selection**: [Language]
|
||||
**Rationale**: [Why this choice]
|
||||
|
||||
#### Framework
|
||||
|
||||
| Option | Pros | Cons | Score (1-5) |
|
||||
|--------|------|------|-------------|
|
||||
| | | | |
|
||||
|
||||
**Selection**: [Framework]
|
||||
**Rationale**: [Why this choice]
|
||||
|
||||
#### Database
|
||||
|
||||
| Option | Pros | Cons | Score (1-5) |
|
||||
|--------|------|------|-------------|
|
||||
| | | | |
|
||||
|
||||
**Selection**: [Database]
|
||||
**Rationale**: [Why this choice]
|
||||
|
||||
#### Infrastructure/Hosting
|
||||
|
||||
| Option | Pros | Cons | Score (1-5) |
|
||||
|--------|------|------|-------------|
|
||||
| | | | |
|
||||
|
||||
**Selection**: [Platform]
|
||||
**Rationale**: [Why this choice]
|
||||
|
||||
#### Key Libraries/Dependencies
|
||||
|
||||
| Category | Library | Version | Purpose | Alternatives Considered |
|
||||
|----------|---------|---------|---------|------------------------|
|
||||
| | | | | |
|
||||
|
||||
### Evaluation Criteria
|
||||
|
||||
Rate each technology option against these criteria:
|
||||
1. **Fitness for purpose**: Does it meet functional requirements?
|
||||
2. **Performance**: Can it meet performance requirements?
|
||||
3. **Security**: Does it have good security track record?
|
||||
4. **Maturity**: Is it stable and well-maintained?
|
||||
5. **Community**: Active community and documentation?
|
||||
6. **Team expertise**: Does team have experience?
|
||||
7. **Cost**: Licensing, hosting, operational costs?
|
||||
8. **Scalability**: Can it grow with the project?
|
||||
|
||||
### Technology Stack Summary
|
||||
|
||||
```
|
||||
Language: [Language] [Version]
|
||||
Framework: [Framework] [Version]
|
||||
Database: [Database] [Version]
|
||||
Cache: [Cache solution]
|
||||
Message Queue: [If applicable]
|
||||
CI/CD: [Platform]
|
||||
Hosting: [Platform]
|
||||
Monitoring: [Tools]
|
||||
```
|
||||
|
||||
### Risk Assessment
|
||||
|
||||
| Technology | Risk | Mitigation |
|
||||
|------------|------|------------|
|
||||
| | | |
|
||||
|
||||
### Learning Requirements
|
||||
|
||||
| Technology | Team Familiarity | Training Needed |
|
||||
|------------|-----------------|-----------------|
|
||||
| | High/Med/Low | Yes/No |
|
||||
|
||||
### Decision Record
|
||||
|
||||
**Decision**: [Summary of tech stack]
|
||||
**Date**: [YYYY-MM-DD]
|
||||
**Participants**: [Who was involved]
|
||||
**Status**: Approved / Pending Review
|
||||
|
||||
Store output to `_docs/01_solution/tech_stack.md`
|
||||
|
||||
## Notes
|
||||
- Avoid over-engineering - choose simplest solution that meets requirements
|
||||
- Consider total cost of ownership, not just initial development
|
||||
- Prefer proven technologies over cutting-edge unless required
|
||||
- Document trade-offs for future reference
|
||||
- Ask questions about team expertise and constraints
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Security Research
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Security approach: `@_docs/00_problem/security_approach.md`
|
||||
- Solution: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a security architect
|
||||
|
||||
## Task
|
||||
- Review solution architecture against security requirements from `security_approach.md`
|
||||
- Identify attack vectors and threat model for the system
|
||||
- Define security requirements per component
|
||||
- Propose security controls and mitigations
|
||||
|
||||
## Output format
|
||||
### Threat Model
|
||||
- Asset inventory (what needs protection)
|
||||
- Threat actors (who might attack)
|
||||
- Attack vectors (how they might attack)
|
||||
|
||||
### Security Requirements per Component
|
||||
For each component:
|
||||
- Component name
|
||||
- Security requirements
|
||||
- Proposed controls
|
||||
- Risk level (High/Medium/Low)
|
||||
|
||||
### Security Controls Summary
|
||||
- Authentication/Authorization approach
|
||||
- Data protection (encryption, integrity)
|
||||
- Secure communication
|
||||
- Logging and monitoring requirements
|
||||
|
||||
Reference in New Issue
Block a user