mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-23 03:16:35 +00:00
organize structure for .roo and for ai in general
rework rulels
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,73 @@
|
||||
# Create Initial Structure
|
||||
|
||||
## 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`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components with Features specifications: `@_docs/02_components`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task
|
||||
- Read carefully all the component specs and features in the components folder: `@_docs/02_components`
|
||||
- Investigate in internet what are the best way and tools to implement components and its features
|
||||
- Make a plan for the creating initial structure:
|
||||
- DTOs
|
||||
- component's interfaces
|
||||
- empty implementations
|
||||
- helpers - empty implementations or interfaces
|
||||
- Add .gitignore appropriate for the project's language/framework
|
||||
- Add .env.example with required environment variables
|
||||
- Configure CI/CD pipeline with full stages:
|
||||
- Build stage
|
||||
- Lint/Static analysis stage
|
||||
- Unit tests stage
|
||||
- Integration tests stage
|
||||
- Security scan stage (SAST/dependency check)
|
||||
- Deploy to staging stage (triggered on merge to stage branch)
|
||||
- Define environment strategy based on `@_docs/00_templates/environment_strategy.md`:
|
||||
- Development environment configuration
|
||||
- Staging environment configuration
|
||||
- Production environment configuration (if applicable)
|
||||
- Add database migration setup if applicable
|
||||
- Add README.md, describe the project by @_docs/01_solution/solution.md
|
||||
- Create a separate folder for the integration tests (not a separate repo)
|
||||
- Configure branch protection rules recommendations
|
||||
|
||||
## Example
|
||||
The structure should roughly looks like this:
|
||||
- .gitignore
|
||||
- .env.example
|
||||
- .github/workflows/ (or .gitlab-ci.yml)
|
||||
- api
|
||||
- components
|
||||
- component1_folder
|
||||
- component2_folder
|
||||
- ...
|
||||
- db
|
||||
- migrations/
|
||||
- helpers
|
||||
- models
|
||||
- tests
|
||||
- unit_test1_project1_folder
|
||||
- unit_test2_project2_folder
|
||||
...
|
||||
- integration_tests_folder
|
||||
- test data
|
||||
- test01_file
|
||||
- test02_file
|
||||
...
|
||||
|
||||
Also it is possible that some semantically coherent components (or 1 big component) would be in its own project or project folder
|
||||
Could be common layer or project consisting of all the interfaces (for C# or Java), or each interface in each component's folder (python) - depending on the language common conventions
|
||||
|
||||
## Notes
|
||||
- Follow SOLID principles
|
||||
- Follow KISS principle. Dumb code - smart data.
|
||||
- Follow DRY principles, but do not overcomplicate things, if code repeats sometimes, it is ok if that would be simpler
|
||||
- Follow conventions and rules of the project's programming language
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
@@ -0,0 +1,35 @@
|
||||
# Implement Component and Features by Spec
|
||||
|
||||
## Input parameter
|
||||
component_folder
|
||||
|
||||
## 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`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully initial data and component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
|
||||
- Read carefully all the component features in the component_folder: `@_docs/02_components/[##]_[component_name]/[##].[##]_feature_[feature_name]`
|
||||
- Investigate in internet what are the best way and tools to implement component and its features
|
||||
- During the investigation it is possible that found solutions required architecturally reorganization of the features. It is ok, propose that and if user agrees, include reorganization in the build feature plan. Also it is possible that interface could be changed or even removed or added new one. It is ok.
|
||||
- Analyze the existing codebase and get full context for the component's implementation
|
||||
- Make sure each feature is connected and communicated properly with other features and existing code
|
||||
- If component has dependency on another one, create temporary mock for the dependency
|
||||
- For each feature:
|
||||
- Implement the feature
|
||||
- Implement error handling per defined strategy
|
||||
- Implement logging per defined strategy
|
||||
- Implement all unit tests from the Test cases description, add checks test results to the plan steps
|
||||
- Implement all integration tests for the feature, add check test results to the plan steps. Analyze existing tests, and decide whether to create new one or add to existing
|
||||
- Add to the implementation plan description of all component's integration tests, add check test results to the plan steps
|
||||
- After component is complete, replace mocks with real implementations (mock cleanup)
|
||||
|
||||
## Notes
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
@@ -0,0 +1,39 @@
|
||||
# Code Review
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`.
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
||||
- Security approach: `@_docs/00_problem/security_approach.md`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
|
||||
## Role
|
||||
You are a senior software engineer performing code review
|
||||
|
||||
## Task
|
||||
- Review implemented code against component specifications
|
||||
- Check code quality: readability, maintainability, SOLID principles
|
||||
- Check error handling consistency
|
||||
- Check logging implementation
|
||||
- Check security requirements are met
|
||||
- Check test coverage is adequate
|
||||
- Identify code smells and technical debt
|
||||
|
||||
## Output
|
||||
### Issues Found
|
||||
For each issue:
|
||||
- File/Location
|
||||
- Issue type (Bug/Security/Performance/Style/Debt)
|
||||
- Description
|
||||
- Suggested fix
|
||||
- Priority (High/Medium/Low)
|
||||
|
||||
### Summary
|
||||
- Total issues by type
|
||||
- Blocking issues that must be fixed
|
||||
- Recommended improvements
|
||||
|
||||
## Notes
|
||||
- Can also use Cursor's built-in review feature
|
||||
- Focus on critical issues first
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# CI/CD Pipeline Validation & Enhancement
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Environment Strategy: `@_docs/00_templates/environment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a DevOps engineer
|
||||
|
||||
## Task
|
||||
- Review existing CI/CD pipeline configuration
|
||||
- Validate all stages are working correctly
|
||||
- Optimize pipeline performance (parallelization, caching)
|
||||
- Ensure test coverage gates are enforced
|
||||
- Verify security scanning is properly configured
|
||||
- Add missing quality gates
|
||||
|
||||
## Checklist
|
||||
|
||||
### Pipeline Health
|
||||
- [ ] All stages execute successfully
|
||||
- [ ] Build time is acceptable (<10 min for most projects)
|
||||
- [ ] Caching is properly configured (dependencies, build artifacts)
|
||||
- [ ] Parallel execution where possible
|
||||
|
||||
### Quality Gates
|
||||
- [ ] Code coverage threshold enforced (minimum 75%)
|
||||
- [ ] Linting errors block merge
|
||||
- [ ] Security vulnerabilities block merge (critical/high)
|
||||
- [ ] All tests must pass
|
||||
|
||||
### Environment Deployments
|
||||
- [ ] Staging deployment works on merge to stage branch
|
||||
- [ ] Environment variables properly configured per environment
|
||||
- [ ] Secrets are securely managed (not in code)
|
||||
- [ ] Rollback procedure documented
|
||||
|
||||
### Monitoring
|
||||
- [ ] Build notifications configured (Slack, email, etc.)
|
||||
- [ ] Failed build alerts
|
||||
- [ ] Deployment success/failure notifications
|
||||
|
||||
## Output
|
||||
|
||||
### Pipeline Status Report
|
||||
- Current pipeline configuration summary
|
||||
- Issues found and fixes applied
|
||||
- Performance metrics (build times)
|
||||
|
||||
### Recommended Improvements
|
||||
- Short-term improvements
|
||||
- Long-term optimizations
|
||||
|
||||
### Quality Gate Configuration
|
||||
- Thresholds configured
|
||||
- Enforcement rules
|
||||
|
||||
## Notes
|
||||
- Do not break existing functionality
|
||||
- Test changes in separate branch first
|
||||
- Document any manual steps required
|
||||
@@ -0,0 +1,72 @@
|
||||
# Deployment Strategy Planning
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Environment Strategy: `@_docs/00_templates/environment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a DevOps/Platform engineer
|
||||
|
||||
## Task
|
||||
- Define deployment strategy for each environment
|
||||
- Plan deployment procedures and automation
|
||||
- Define rollback procedures
|
||||
- Establish deployment verification steps
|
||||
- Document manual intervention points
|
||||
|
||||
## Output
|
||||
|
||||
### Deployment Architecture
|
||||
- Infrastructure diagram (where components run)
|
||||
- Network topology
|
||||
- Load balancing strategy
|
||||
- Container/VM configuration
|
||||
|
||||
### Deployment Procedures
|
||||
|
||||
#### Staging Deployment
|
||||
- Trigger conditions
|
||||
- Pre-deployment checks
|
||||
- Deployment steps
|
||||
- Post-deployment verification
|
||||
- Smoke tests to run
|
||||
|
||||
#### Production Deployment
|
||||
- Approval workflow
|
||||
- Deployment window
|
||||
- Pre-deployment checks
|
||||
- Deployment steps (blue-green, rolling, canary)
|
||||
- Post-deployment verification
|
||||
- Smoke tests to run
|
||||
|
||||
### Rollback Procedures
|
||||
- Rollback trigger criteria
|
||||
- Rollback steps per environment
|
||||
- Data rollback considerations
|
||||
- Communication plan during rollback
|
||||
|
||||
### Health Checks
|
||||
- Liveness probe configuration
|
||||
- Readiness probe configuration
|
||||
- Custom health endpoints
|
||||
|
||||
### Deployment Checklist
|
||||
- [ ] All tests pass in CI
|
||||
- [ ] Security scan clean
|
||||
- [ ] Database migrations reviewed
|
||||
- [ ] Feature flags configured
|
||||
- [ ] Monitoring alerts configured
|
||||
- [ ] Rollback plan documented
|
||||
- [ ] Stakeholders notified
|
||||
|
||||
Store output to `_docs/02_components/deployment_strategy.md`
|
||||
|
||||
## Notes
|
||||
- Prefer automated deployments over manual
|
||||
- Zero-downtime deployments for production
|
||||
- Always have a rollback plan
|
||||
- Ask questions about infrastructure constraints
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
# Implement Tests by Spec
|
||||
|
||||
## 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`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Tests specifications: `@_docs/02_tests`
|
||||
|
||||
## Role
|
||||
You are a professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully all the initial data and understand whole system goals
|
||||
- Check that a separate folder for tests is existing (should be generated by @3.05_implement_initial_structure.md)
|
||||
- Set up Docker environment for testing:
|
||||
- Create docker-compose.yml for test environment
|
||||
- Configure test database container
|
||||
- Configure application container
|
||||
- For each test description:
|
||||
- Prepare all the data necessary for testing, or check it is already exists
|
||||
- Check existing integration tests and if a similar test is already exists, update it
|
||||
- Implement the test by specification
|
||||
- Implement test data management:
|
||||
- Setup fixtures/factories
|
||||
- Teardown/cleanup procedures
|
||||
- Run system and integration tests in docker containers
|
||||
- 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, iteratively fixing found bugs. Ask user for an additional information if something new appears
|
||||
- Ensure tests run in CI pipeline
|
||||
- Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
## Notes
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
|
||||
@@ -0,0 +1,123 @@
|
||||
# Observability Planning
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Deployment Strategy: `@_docs/02_components/deployment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a Site Reliability Engineer (SRE)
|
||||
|
||||
## Task
|
||||
- Define logging strategy across all components
|
||||
- Plan metrics collection and dashboards
|
||||
- Design distributed tracing (if applicable)
|
||||
- Establish alerting rules
|
||||
- Document incident response procedures
|
||||
|
||||
## Output
|
||||
|
||||
### Logging Strategy
|
||||
|
||||
#### Log Levels
|
||||
| Level | Usage | Example |
|
||||
|-------|-------|---------|
|
||||
| ERROR | Exceptions, failures requiring attention | Database connection failed |
|
||||
| WARN | Potential issues, degraded performance | Retry attempt 2/3 |
|
||||
| INFO | Significant business events | User registered, Order placed |
|
||||
| DEBUG | Detailed diagnostic information | Request payload, Query params |
|
||||
|
||||
#### Log Format
|
||||
```json
|
||||
{
|
||||
"timestamp": "ISO8601",
|
||||
"level": "INFO",
|
||||
"service": "service-name",
|
||||
"correlation_id": "uuid",
|
||||
"message": "Event description",
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
#### Log Storage
|
||||
- Development: Console/file
|
||||
- Staging: Centralized (ELK, CloudWatch, etc.)
|
||||
- Production: Centralized with retention policy
|
||||
|
||||
### Metrics
|
||||
|
||||
#### System Metrics
|
||||
- CPU usage
|
||||
- Memory usage
|
||||
- Disk I/O
|
||||
- Network I/O
|
||||
|
||||
#### Application Metrics
|
||||
| Metric | Type | Description |
|
||||
|--------|------|-------------|
|
||||
| request_count | Counter | Total requests |
|
||||
| request_duration | Histogram | Response time |
|
||||
| error_count | Counter | Failed requests |
|
||||
| active_connections | Gauge | Current connections |
|
||||
|
||||
#### Business Metrics
|
||||
- [Define based on acceptance criteria]
|
||||
|
||||
### Distributed Tracing
|
||||
|
||||
#### Trace Context
|
||||
- Correlation ID propagation
|
||||
- Span naming conventions
|
||||
- Sampling strategy
|
||||
|
||||
#### Integration Points
|
||||
- HTTP headers
|
||||
- Message queue metadata
|
||||
- Database query tagging
|
||||
|
||||
### Alerting
|
||||
|
||||
#### Alert Categories
|
||||
| Severity | Response Time | Examples |
|
||||
|----------|---------------|----------|
|
||||
| Critical | 5 min | Service down, Data loss |
|
||||
| High | 30 min | High error rate, Performance degradation |
|
||||
| Medium | 4 hours | Elevated latency, Disk usage high |
|
||||
| Low | Next business day | Non-critical warnings |
|
||||
|
||||
#### Alert Rules
|
||||
```yaml
|
||||
alerts:
|
||||
- name: high_error_rate
|
||||
condition: error_rate > 5%
|
||||
duration: 5m
|
||||
severity: high
|
||||
|
||||
- name: service_down
|
||||
condition: health_check_failed
|
||||
duration: 1m
|
||||
severity: critical
|
||||
```
|
||||
|
||||
### Dashboards
|
||||
|
||||
#### Operations Dashboard
|
||||
- Service health status
|
||||
- Request rate and error rate
|
||||
- Response time percentiles
|
||||
- Resource utilization
|
||||
|
||||
#### Business Dashboard
|
||||
- Key business metrics
|
||||
- User activity
|
||||
- Transaction volumes
|
||||
|
||||
Store output to `_docs/02_components/observability_plan.md`
|
||||
|
||||
## Notes
|
||||
- Follow the principle: "If it's not monitored, it's not in production"
|
||||
- Balance verbosity with cost
|
||||
- Ensure PII is not logged
|
||||
- Plan for log rotation and retention
|
||||
|
||||
Reference in New Issue
Block a user