mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 07:06:38 +00:00
review of all AI-dev system #01
add refactoring phase complete implementation phase fix wrong links and file names
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,26 @@
|
||||
# Pull Request Template
|
||||
|
||||
## Description
|
||||
Brief description of changes.
|
||||
|
||||
## Related Issue
|
||||
Jira ticket: [AZ-XXX](link)
|
||||
|
||||
## Type of Change
|
||||
- [ ] Bug fix
|
||||
- [ ] New feature
|
||||
- [ ] Refactoring
|
||||
- [ ] Documentation
|
||||
|
||||
## Checklist
|
||||
- [ ] Code follows project conventions
|
||||
- [ ] Self-review completed
|
||||
- [ ] Tests added/updated
|
||||
- [ ] All tests pass
|
||||
- [ ] Documentation updated (if needed)
|
||||
|
||||
## Testing
|
||||
How to test these changes.
|
||||
|
||||
## Screenshots (if applicable)
|
||||
|
||||
@@ -1,9 +1,12 @@
|
||||
# Building Block: Dashboard Export to Excel
|
||||
|
||||
## Problem / Goal
|
||||
Users need to export the dashboard data they’re currently viewing into Excel for offline analysis and sharing.
|
||||
|
||||
##
|
||||
|
||||
## Outcome
|
||||
Export dashboard data functionality. Expo
|
||||
## Problem / Goal
|
||||
Users need to export the dashboard data they're currently viewing into Excel for offline analysis and sharing.
|
||||
|
||||
## Architecture Notes (optional)
|
||||
Use existing data fetching layer. Add Excel generation service. Export button in dashboard toolbar triggers download.
|
||||
|
||||
## Outcome
|
||||
- One-click export of filtered dashboard data to Excel file
|
||||
- File includes timestamp and current filter context
|
||||
- Supports up to 10,000 records
|
||||
|
||||
@@ -1,4 +1,27 @@
|
||||
# Iterative Implementation phase
|
||||
# Iterative Implementation Phase
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Jira MCP
|
||||
Add Jira MCP to the list in IDE:
|
||||
```
|
||||
"Jira-MCP-Server": {
|
||||
"url": "https://mcp.atlassian.com/v1/sse"
|
||||
}
|
||||
```
|
||||
|
||||
### Context7 MCP
|
||||
Add context7 MCP to the list in IDE:
|
||||
```
|
||||
"context7": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@upstash/context7-mcp"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## 10 **🧑💻 Developers**: Form a building block
|
||||
|
||||
@@ -13,16 +36,23 @@
|
||||
How it should be implemented. Which subsystem to use, short explanation of the 3-5 lines.
|
||||
|
||||
## Outcome
|
||||
What we waht to achieve
|
||||
What we want to achieve from the building block
|
||||
```
|
||||
### Example
|
||||
`_docs/iterative/building_blocks/01-dashboard-export-example.md`
|
||||
|
||||
|
||||
## 20. **🤖AI agent**: Generate Feature Specification
|
||||
### Execute `/gen_feature_spec`
|
||||
|
||||
## 30. **🤖AI agent**: Generate Jira ticket
|
||||
### Execute `/gen_jira_task`
|
||||
|
||||
## 30. **🤖AI agent**: Generate Jira ticket and branch
|
||||
### Execute `/gen_jira_task_and_branch`
|
||||
|
||||
This will:
|
||||
- Create Jira task under specified epic
|
||||
- Create git branch from dev (e.g., `az-122-progressive-search-system`)
|
||||
|
||||
|
||||
## 40. **🤖📋AI plan**: Generate Plan
|
||||
### Execute
|
||||
@@ -30,10 +60,22 @@
|
||||
Example:
|
||||
generate plan for `@_docs/iterative/feature_specs/01-dashboard-export-example.md`
|
||||
|
||||
|
||||
## 50. **🧑💻 Developer**: Save the plan
|
||||
Save the generated plan to `@_docs/iterative/plans`.
|
||||
(First, save with built-in mechanism to .cursor folder, then move to this folder `@_docs/iterative/plans`)
|
||||
|
||||
|
||||
## 60. Build from the plan
|
||||
|
||||
## Check build and tests are successful.
|
||||
|
||||
## 65. **🤖📋AI plan**: Code Review
|
||||
### Execute
|
||||
Use Cursor's built-in review feature or manual review.
|
||||
|
||||
### Verify
|
||||
- All issues addressed
|
||||
- Code quality standards met
|
||||
|
||||
|
||||
## 70. Check build and tests are successful.
|
||||
|
||||
@@ -1,14 +1,15 @@
|
||||
# 1 Research Phase
|
||||
|
||||
|
||||
## **🧑💻 Developers**: 1.0 Problem statement
|
||||
## 1.01 **🧑💻 Developers**: 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
|
||||
- `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 criteria
|
||||
- `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.
|
||||
- `security_approach.md`: Security requirements and constraints for the system.
|
||||
|
||||
### Example:
|
||||
- `problem_description.md`
|
||||
@@ -28,32 +29,64 @@
|
||||
- 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 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.
|
||||
- UAV should fly for minimum of 500 meters with missing internal Satellite maps and the drifting error should be no more than 50 meters.
|
||||
- `security_approach.md`
|
||||
- System runs on embedded platform (Jetson Orin Nano) with secure boot
|
||||
- Communication with ground station encrypted via AES-256
|
||||
- No remote API access during flight - fully autonomous
|
||||
- Firmware signing required for updates
|
||||
|
||||
|
||||
## 1.1 **✨AI Research**: Restrictions and Acceptance Criteria assesment
|
||||
## 1.05 **🧑💻 Developers**: Git Init
|
||||
### Initialize Repository
|
||||
```bash
|
||||
git init
|
||||
git add .
|
||||
git commit -m "Initial: problem statement and input data"
|
||||
```
|
||||
|
||||
### Branching Strategy
|
||||
- `main`: Documentation and stable releases
|
||||
- `stage`: Planning phase artifacts
|
||||
- `dev`: Implementation code
|
||||
|
||||
After research phase completion, all docs stay on `main`.
|
||||
Before planning phase, create `stage` branch.
|
||||
Before implementation phase, create `dev` branch from `stage`.
|
||||
After integration tests pass, merge `dev` → `stage` → `main`.
|
||||
|
||||
|
||||
## 1.10 **✨AI Research**: Restrictions and Acceptance Criteria assessment
|
||||
|
||||
### Execute `/1.research/1.1_research_assesment_acceptance_criteria`
|
||||
### Execute `/1.research/1.10_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`
|
||||
- `security_approach.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
- Revise the result, discuss it
|
||||
- Overwrite `acceptance_criteria.md` and `restrictions.md`
|
||||
|
||||
### Commit
|
||||
```bash
|
||||
git add _docs/00_problem/
|
||||
git commit -m "Research: acceptance criteria and restrictions assessed"
|
||||
```
|
||||
|
||||
|
||||
## 1.2 **🤖✨AI Research**: Research the problem in great detail
|
||||
## 1.20 **🤖✨AI Research**: Research the problem in great detail
|
||||
|
||||
### Execute `/1.research/1.2_research_problem`
|
||||
### Execute `/1.research/1.20_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`
|
||||
- `security_approach.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
@@ -63,13 +96,14 @@
|
||||
- Store it to the `_docs/01_solution/solution_draft.md`
|
||||
|
||||
|
||||
## 1.3 **🤖✨AI Research**: Solution draft assessment
|
||||
## 1.30 **🤖✨AI Research**: Solution draft assessment
|
||||
|
||||
### Execute `/1.research/1.3_solution_draft_assessment`
|
||||
### Execute `/1.research/1.30_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`
|
||||
- `security_approach.md`
|
||||
- Samples of the input data
|
||||
|
||||
### Revise
|
||||
@@ -78,18 +112,40 @@
|
||||
### 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
|
||||
- Repeat the process 1.30 from the beginning
|
||||
|
||||
When the next solution wouldn't differ much from the previous one, or become actually worse, store the last draft as `_docs/01_solution/solution.md`
|
||||
|
||||
|
||||
## 1.40 **🤖✨AI Research**: Security Research
|
||||
|
||||
### Execute `/1.research/1.40_security_research`
|
||||
|
||||
### Revise
|
||||
- Review security approach against solution architecture
|
||||
- Update `security_approach.md` with specific requirements per component
|
||||
|
||||
### Commit
|
||||
```bash
|
||||
git add _docs/
|
||||
git commit -m "Research: solution and security finalized"
|
||||
```
|
||||
|
||||
|
||||
# 2. Planning phase
|
||||
|
||||
> **Note**: If implementation reveals architectural issues, return to Planning phase to revise components.
|
||||
|
||||
|
||||
## 2.05 **🧑💻 Developers**: Create stage branch
|
||||
```bash
|
||||
git checkout -b stage
|
||||
```
|
||||
|
||||
|
||||
## 2.10 **🤖📋AI plan**: Generate components
|
||||
|
||||
### Execute `/2.planning/2.10_gen_components`
|
||||
### Execute `/2.planning/2.10_plan_components`
|
||||
|
||||
### Revise
|
||||
- Revise the plan, answer questions, put detailed descriptions
|
||||
@@ -99,12 +155,21 @@
|
||||
- Save plan to `_docs/02_components/00_decomposition_plan.md`
|
||||
|
||||
|
||||
## 2.15 **🤖📋AI plan**: Components assesment
|
||||
## 2.15 **🤖📋AI plan**: Components assessment
|
||||
|
||||
### Execute `/2.planning/2.15_components_assesment`
|
||||
### Execute `/2.planning/2.15_plan_asses_components`
|
||||
|
||||
### Revise
|
||||
- Clarify the proposals and ask to fix found issues
|
||||
|
||||
|
||||
## 2.17 **🤖📋AI plan**: Security Check
|
||||
|
||||
### Execute `/2.planning/2.17_plan_security_check`
|
||||
|
||||
### Revise
|
||||
- Review security considerations for each component
|
||||
- Ensure security requirements from 1.40 are addressed
|
||||
|
||||
|
||||
## 2.20 **🤖AI agent**: Generate Jira Epics
|
||||
@@ -123,7 +188,7 @@
|
||||
- Make sure epics are coherent and make sense
|
||||
|
||||
|
||||
## 2.30 **🤖📋AI plan**: Generate tests
|
||||
## 2.30 **🤖📋AI plan**: Generate tests
|
||||
|
||||
### Execute `/2.planning/2.30_plan_tests`
|
||||
|
||||
@@ -141,14 +206,26 @@
|
||||
- Revise the features, answer questions, put detailed descriptions
|
||||
- Make sure features are coherent and make sense
|
||||
|
||||
### Commit
|
||||
```bash
|
||||
git add _docs/
|
||||
git commit -m "Planning: components, tests, and features defined"
|
||||
```
|
||||
|
||||
|
||||
|
||||
# 3. Implementation phase
|
||||
|
||||
|
||||
## 3.05 **🤖📋AI plan**: Initial structure
|
||||
### Jira MCP
|
||||
Add context7 MCP to the list in IDE:
|
||||
|
||||
### Create dev branch
|
||||
```bash
|
||||
git checkout -b dev
|
||||
```
|
||||
|
||||
### Context7 MCP
|
||||
Add context7 MCP to the list in IDE:
|
||||
```
|
||||
"context7": {
|
||||
"command": "npx",
|
||||
@@ -194,11 +271,41 @@
|
||||
### Revise Code
|
||||
- Read the code and check that everything is ok
|
||||
|
||||
|
||||
## 3.20 **🤖📋AI plan**: Integration tests and solution checks
|
||||
|
||||
### Execute `/3.implementation/3.20_implement_tests`
|
||||
## 3.20 **🤖📋AI plan**: Code Review
|
||||
|
||||
### Execute `/3.implementation/3.20_implement_code_review`
|
||||
|
||||
Can also use Cursor's built-in review feature.
|
||||
|
||||
### Revise
|
||||
- Address all found issues
|
||||
- Ensure code quality standards are met
|
||||
|
||||
|
||||
## 3.30 **🤖📋AI plan**: CI/CD Setup
|
||||
|
||||
### Execute `/3.implementation/3.30_implement_cicd`
|
||||
|
||||
### Revise
|
||||
- Review pipeline configuration
|
||||
- Ensure all stages are properly configured
|
||||
|
||||
|
||||
## 3.40 **🤖📋AI plan**: Integration tests and solution checks
|
||||
|
||||
### Execute `/3.implementation/3.40_implement_tests`
|
||||
|
||||
### Revise
|
||||
- Revise the plan, answer questions, put detailed descriptions
|
||||
- Make sure tests are coherent and make sense
|
||||
|
||||
### Merge after tests pass
|
||||
```bash
|
||||
git checkout stage
|
||||
git merge dev
|
||||
git checkout main
|
||||
git merge stage
|
||||
git push origin main
|
||||
```
|
||||
|
||||
@@ -0,0 +1,113 @@
|
||||
# Refactoring Existing Project
|
||||
|
||||
This tutorial guides through analyzing, documenting, and refactoring an existing codebase.
|
||||
|
||||
|
||||
## 4.05 **🧑💻 Developers**: User Input
|
||||
|
||||
### Define Goals
|
||||
Create in `_docs/00_problem`:
|
||||
- `problem_description.md`: What system currently does + what you want to change/improve
|
||||
- `acceptance_criteria.md`: Success criteria for the refactoring
|
||||
- `security_approach.md`: Security requirements (if applicable)
|
||||
|
||||
|
||||
## 4.10 **🤖📋AI plan**: Build Documentation from Code
|
||||
|
||||
### Execute `/4.refactoring/4.10_documentation`
|
||||
|
||||
### Revise
|
||||
- Review generated component docs
|
||||
- Verify accuracy against actual code behavior
|
||||
|
||||
|
||||
## 4.20 **🤖📋AI plan**: Form Solution with Flows
|
||||
|
||||
### Execute `/4.refactoring/4.20_form_solution_flows`
|
||||
|
||||
### Revise
|
||||
- Review solution description
|
||||
- Verify flow diagrams match actual system behavior
|
||||
- Store to `_docs/01_solution/solution.md`
|
||||
|
||||
|
||||
## 4.30 **🤖✨AI Research**: Deep Research of Approaches
|
||||
|
||||
### Execute `/4.refactoring/4.30_deep_research`
|
||||
|
||||
### Revise
|
||||
- Review suggested improvements
|
||||
- Prioritize changes based on impact vs effort
|
||||
|
||||
|
||||
## 4.35 **🤖✨AI Research**: Solution Assessment with Codebase
|
||||
|
||||
### Execute `/4.refactoring/4.35_solution_assessment`
|
||||
|
||||
### Revise
|
||||
- Review weak points identified in current implementation
|
||||
- Decide which to address
|
||||
|
||||
|
||||
## 4.40 **🤖📋AI plan**: Integration Tests Description
|
||||
|
||||
### Execute `/4.refactoring/4.40_tests_description`
|
||||
|
||||
### Revise
|
||||
- Ensure tests cover critical functionality
|
||||
- Add edge cases
|
||||
|
||||
|
||||
## 4.50 **🤖📋AI plan**: Implement Tests
|
||||
|
||||
### Execute `/4.refactoring/4.50_implement_tests`
|
||||
|
||||
### Verify
|
||||
- All tests pass on current codebase
|
||||
- Tests serve as safety net for refactoring
|
||||
|
||||
|
||||
## 4.60 **🤖📋AI plan**: Analyze Coupling
|
||||
|
||||
### Execute `/4.refactoring/4.60_analyze_coupling`
|
||||
|
||||
### Revise
|
||||
- Review coupling analysis
|
||||
- Prioritize decoupling strategy
|
||||
|
||||
|
||||
## 4.70 **🤖📋AI plan**: Execute Decoupling
|
||||
|
||||
### Execute `/4.refactoring/4.70_execute_decoupling`
|
||||
|
||||
### Verify
|
||||
- Run integration tests after each change
|
||||
- All tests must pass before proceeding
|
||||
|
||||
|
||||
## 4.80 **🤖📋AI plan**: Technical Debt
|
||||
|
||||
### Execute `/4.refactoring/4.80_technical_debt`
|
||||
|
||||
### Revise
|
||||
- Review debt items
|
||||
- Prioritize by impact
|
||||
|
||||
|
||||
## 4.90 **🤖📋AI plan**: Performance Optimization
|
||||
|
||||
### Execute `/4.refactoring/4.90_performance`
|
||||
|
||||
### Verify
|
||||
- Benchmark before/after
|
||||
- Run tests to ensure no regressions
|
||||
|
||||
|
||||
## 4.95 **🤖📋AI plan**: Security Review
|
||||
|
||||
### Execute `/4.refactoring/4.95_security`
|
||||
|
||||
### Verify
|
||||
- Address identified vulnerabilities
|
||||
- Run security tests if applicable
|
||||
|
||||
Reference in New Issue
Block a user