123 lines
4.9 KiB
Plaintext
123 lines
4.9 KiB
Plaintext
|
---
|
||
|
|
description: AI-generated code review checklist and quality assurance guidelines
|
||
|
|
globs:
|
||
|
|
alwaysApply: false
|
||
|
|
---
|
||
|
|
|
||
|
|
# Rule: Code Review and Quality Assurance
|
||
|
|
|
||
|
|
## Goal
|
||
|
|
Establish systematic review processes for AI-generated code to maintain quality, security, and maintainability standards.
|
||
|
|
|
||
|
|
## AI Code Review Checklist
|
||
|
|
|
||
|
|
### Pre-Implementation Review
|
||
|
|
Before accepting any AI-generated code:
|
||
|
|
|
||
|
|
1. **Understand the Code**
|
||
|
|
- [ ] Can you explain what the code does in your own words?
|
||
|
|
- [ ] Do you understand each function and its purpose?
|
||
|
|
- [ ] Are there any "magic" values or unexplained logic?
|
||
|
|
- [ ] Does the code solve the actual problem stated?
|
||
|
|
|
||
|
|
2. **Architecture Alignment**
|
||
|
|
- [ ] Does the code follow established project patterns?
|
||
|
|
- [ ] Is it consistent with existing data structures?
|
||
|
|
- [ ] Does it integrate cleanly with existing components?
|
||
|
|
- [ ] Are new dependencies justified and necessary?
|
||
|
|
|
||
|
|
3. **Code Quality**
|
||
|
|
- [ ] Are functions smaller than 50 lines?
|
||
|
|
- [ ] Are files smaller than 250 lines?
|
||
|
|
- [ ] Are variable and function names descriptive?
|
||
|
|
- [ ] Is the code DRY (Don't Repeat Yourself)?
|
||
|
|
|
||
|
|
### Security Review
|
||
|
|
- [ ] **Input Validation**: All user inputs are validated and sanitized
|
||
|
|
- [ ] **Authentication**: Proper authentication checks are in place
|
||
|
|
- [ ] **Authorization**: Access controls are implemented correctly
|
||
|
|
- [ ] **Data Protection**: Sensitive data is handled securely
|
||
|
|
- [ ] **SQL Injection**: Database queries use parameterized statements
|
||
|
|
- [ ] **XSS Prevention**: Output is properly escaped
|
||
|
|
- [ ] **Error Handling**: Errors don't leak sensitive information
|
||
|
|
|
||
|
|
### Integration Review
|
||
|
|
- [ ] **Existing Functionality**: New code doesn't break existing features
|
||
|
|
- [ ] **Data Consistency**: Database changes maintain referential integrity
|
||
|
|
- [ ] **API Compatibility**: Changes don't break existing API contracts
|
||
|
|
- [ ] **Performance Impact**: New code doesn't introduce performance bottlenecks
|
||
|
|
- [ ] **Testing Coverage**: Appropriate tests are included
|
||
|
|
|
||
|
|
## Review Process
|
||
|
|
|
||
|
|
### Step 1: Initial Code Analysis
|
||
|
|
1. **Read through the entire generated code** before running it
|
||
|
|
2. **Identify patterns** that don't match existing codebase
|
||
|
|
3. **Check dependencies** - are new packages really needed?
|
||
|
|
4. **Verify logic flow** - does the algorithm make sense?
|
||
|
|
|
||
|
|
### Step 2: Security and Error Handling Review
|
||
|
|
1. **Trace data flow** from input to output
|
||
|
|
2. **Identify potential failure points** and verify error handling
|
||
|
|
3. **Check for security vulnerabilities** using the security checklist
|
||
|
|
4. **Verify proper logging** and monitoring implementation
|
||
|
|
|
||
|
|
### Step 3: Integration Testing
|
||
|
|
1. **Test with existing code** to ensure compatibility
|
||
|
|
2. **Run existing test suite** to verify no regressions
|
||
|
|
3. **Test edge cases** and error conditions
|
||
|
|
4. **Verify performance** under realistic conditions
|
||
|
|
|
||
|
|
## Common AI Code Issues to Watch For
|
||
|
|
|
||
|
|
### Overcomplication Patterns
|
||
|
|
- **Unnecessary abstractions**: AI creating complex patterns for simple tasks
|
||
|
|
- **Over-engineering**: Solutions that are more complex than needed
|
||
|
|
- **Redundant code**: AI recreating existing functionality
|
||
|
|
- **Inappropriate design patterns**: Using patterns that don't fit the use case
|
||
|
|
|
||
|
|
### Context Loss Indicators
|
||
|
|
- **Inconsistent naming**: Different conventions from existing code
|
||
|
|
- **Wrong data structures**: Using different patterns than established
|
||
|
|
- **Ignored existing functions**: Reimplementing existing functionality
|
||
|
|
- **Architectural misalignment**: Code that doesn't fit the overall design
|
||
|
|
|
||
|
|
### Technical Debt Indicators
|
||
|
|
- **Magic numbers**: Hardcoded values without explanation
|
||
|
|
- **Poor error messages**: Generic or unhelpful error handling
|
||
|
|
- **Missing documentation**: Code without adequate comments
|
||
|
|
- **Tight coupling**: Components that are too interdependent
|
||
|
|
|
||
|
|
## Quality Gates
|
||
|
|
|
||
|
|
### Mandatory Reviews
|
||
|
|
All AI-generated code must pass these gates before acceptance:
|
||
|
|
|
||
|
|
1. **Security Review**: No security vulnerabilities detected
|
||
|
|
2. **Integration Review**: Integrates cleanly with existing code
|
||
|
|
3. **Performance Review**: Meets performance requirements
|
||
|
|
4. **Maintainability Review**: Code can be easily modified by team members
|
||
|
|
5. **Documentation Review**: Adequate documentation is provided
|
||
|
|
|
||
|
|
### Acceptance Criteria
|
||
|
|
- [ ] Code is understandable by any team member
|
||
|
|
- [ ] Integration requires minimal changes to existing code
|
||
|
|
- [ ] Security review passes all checks
|
||
|
|
- [ ] Performance meets established benchmarks
|
||
|
|
- [ ] Documentation is complete and accurate
|
||
|
|
|
||
|
|
## Rejection Criteria
|
||
|
|
Reject AI-generated code if:
|
||
|
|
- Security vulnerabilities are present
|
||
|
|
- Code is too complex for the problem being solved
|
||
|
|
- Integration requires major refactoring of existing code
|
||
|
|
- Code duplicates existing functionality without justification
|
||
|
|
- Documentation is missing or inadequate
|
||
|
|
|
||
|
|
## Review Documentation
|
||
|
|
For each review, document:
|
||
|
|
- Issues found and how they were resolved
|
||
|
|
- Performance impact assessment
|
||
|
|
- Security concerns and mitigations
|
||
|
|
- Integration challenges and solutions
|
||
|
|
- Recommendations for future similar tasks
|