mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 11:16:37 +00:00
141 lines
3.4 KiB
Markdown
141 lines
3.4 KiB
Markdown
# Quality Gates
|
|
|
|
Quality gates are checkpoints that must pass before proceeding to the next phase.
|
|
|
|
---
|
|
|
|
## Kickstart Tutorial Quality Gates
|
|
|
|
### Gate 1: Research Complete (after 1.40)
|
|
Before proceeding to Planning phase:
|
|
- [ ] Problem description is clear and complete
|
|
- [ ] Acceptance criteria are measurable and testable
|
|
- [ ] Restrictions are documented
|
|
- [ ] Security requirements defined
|
|
- [ ] Solution draft reviewed and finalized
|
|
- [ ] Tech stack evaluated and selected
|
|
|
|
### Gate 2: Planning Complete (after 2.40)
|
|
Before proceeding to Implementation phase:
|
|
- [ ] All components defined with clear boundaries
|
|
- [ ] Data model designed and reviewed
|
|
- [ ] API contracts defined
|
|
- [ ] Test specifications created
|
|
- [ ] Jira epics/tasks created
|
|
- [ ] Effort estimated
|
|
- [ ] Risks identified and mitigated
|
|
|
|
### Gate 3: Implementation Complete (after 3.40)
|
|
Before merging to main:
|
|
- [ ] All components implemented
|
|
- [ ] Code coverage >= 75%
|
|
- [ ] All tests pass (unit, integration)
|
|
- [ ] Code review approved
|
|
- [ ] Security scan passed
|
|
- [ ] CI/CD pipeline green
|
|
- [ ] Deployment tested on staging
|
|
- [ ] Documentation complete
|
|
|
|
---
|
|
|
|
## Iterative Tutorial Quality Gates
|
|
|
|
### Gate 1: Spec Ready (after step 20)
|
|
Before creating Jira task:
|
|
- [ ] Building block clearly defines problem/goal
|
|
- [ ] Feature spec has measurable acceptance criteria
|
|
- [ ] Dependencies identified
|
|
- [ ] Complexity estimated
|
|
|
|
### Gate 2: Implementation Ready (after step 50)
|
|
Before starting development:
|
|
- [ ] Plan reviewed and approved
|
|
- [ ] Test strategy defined
|
|
- [ ] Dependencies available or mocked
|
|
|
|
### Gate 3: Merge Ready (after step 70)
|
|
Before creating PR:
|
|
- [ ] All acceptance criteria met
|
|
- [ ] Tests pass locally
|
|
- [ ] Definition of Done checklist completed
|
|
- [ ] No unresolved TODOs in code
|
|
|
|
---
|
|
|
|
## Refactoring Tutorial Quality Gates
|
|
|
|
### Gate 1: Safety Net Ready (after 4.50)
|
|
Before starting refactoring:
|
|
- [ ] Baseline metrics captured
|
|
- [ ] Current behavior documented
|
|
- [ ] Integration tests pass (>= 75% coverage)
|
|
- [ ] Feature parity checklist created
|
|
|
|
### Gate 2: Refactoring Safe (after each 4.70 cycle)
|
|
After each refactoring step:
|
|
- [ ] All existing tests still pass
|
|
- [ ] No functionality lost (feature parity check)
|
|
- [ ] Performance not degraded (compare to baseline)
|
|
|
|
### Gate 3: Refactoring Complete (after 4.95)
|
|
Before declaring refactoring done:
|
|
- [ ] All tests pass
|
|
- [ ] Performance improved or maintained
|
|
- [ ] Security review passed
|
|
- [ ] Technical debt reduced
|
|
- [ ] Documentation updated
|
|
|
|
---
|
|
|
|
## Automated Gate Checks
|
|
|
|
### CI Pipeline Gates
|
|
```yaml
|
|
gates:
|
|
build:
|
|
- compilation_success: true
|
|
|
|
quality:
|
|
- lint_errors: 0
|
|
- code_coverage: ">= 75%"
|
|
- code_smells: "< 10 new"
|
|
|
|
security:
|
|
- critical_vulnerabilities: 0
|
|
- high_vulnerabilities: 0
|
|
|
|
tests:
|
|
- unit_tests_pass: true
|
|
- integration_tests_pass: true
|
|
```
|
|
|
|
### Manual Gate Checks
|
|
Some gates require human verification:
|
|
- Architecture review
|
|
- Security review
|
|
- UX review (for UI changes)
|
|
- Stakeholder sign-off
|
|
|
|
---
|
|
|
|
## Gate Failure Handling
|
|
|
|
When a gate fails:
|
|
1. **Stop** - Do not proceed to next phase
|
|
2. **Identify** - Determine which checks failed
|
|
3. **Fix** - Address the failures
|
|
4. **Re-verify** - Run gate checks again
|
|
5. **Document** - If exception needed, get approval and document reason
|
|
|
|
---
|
|
|
|
## Exception Process
|
|
|
|
If a gate must be bypassed:
|
|
1. Document the reason
|
|
2. Get tech lead approval
|
|
3. Create follow-up task to address
|
|
4. Set deadline for resolution
|
|
5. Add to risk register
|
|
|