You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
175 lines
6.3 KiB
175 lines
6.3 KiB
# Meta-Rule: Bug Fixing
|
|
|
|
**Author**: Matthew Raymer
|
|
**Date**: 2025-08-21
|
|
**Status**: 🎯 **ACTIVE** - Bug fix implementation workflow bundling
|
|
|
|
## Purpose
|
|
|
|
This meta-rule bundles all the rules needed for implementing bug fixes
|
|
with proper testing and validation. Use this after diagnosis when
|
|
implementing the actual fix.
|
|
|
|
## When to Use
|
|
|
|
- **Post-Diagnosis**: After root cause is identified and fix is planned
|
|
- **Fix Implementation**: When coding the actual bug fix
|
|
- **Testing & Validation**: When testing the fix works correctly
|
|
- **Code Review**: When reviewing the fix implementation
|
|
- **Deployment**: When preparing the fix for deployment
|
|
- **Documentation**: When documenting the fix and lessons learned
|
|
|
|
## Bundled Rules
|
|
|
|
### **Implementation Standards**
|
|
|
|
- **`development/software_development.mdc`** - Core development
|
|
principles, evidence requirements, and testing strategy
|
|
- **`development/type_safety_guide.mdc`** - Type-safe implementation
|
|
with proper error handling and type guards
|
|
- **`development/logging_migration.mdc`** - Proper logging
|
|
implementation and migration from console.* calls
|
|
|
|
### **Code Quality & Review**
|
|
|
|
- **`development/historical_comment_management.mdc`** - Code quality
|
|
standards and comment transformation rules
|
|
- **`development/historical_comment_patterns.mdc`** - Specific
|
|
patterns for transforming historical comments
|
|
- **`development/complexity_assessment.mdc`** - Complexity evaluation
|
|
for fix implementation
|
|
|
|
### **Platform & Testing**
|
|
|
|
- **`app/timesafari_development.mdc`** - TimeSafari-specific
|
|
development workflow and testing requirements
|
|
- **`app/timesafari_platforms.mdc`** - Platform-specific testing
|
|
and validation requirements
|
|
- **`architecture/build_validation.mdc`** - Build system validation
|
|
and testing procedures
|
|
|
|
## Workflow Sequence
|
|
|
|
### **Phase 1: Fix Implementation (Start Here)**
|
|
|
|
1. **Development Standards** - Apply `software_development.mdc` for
|
|
core implementation principles
|
|
2. **Type Safety** - Use `type_safety_guide.mdc` for type-safe
|
|
implementation
|
|
3. **Logging Implementation** - Apply `logging_migration.mdc` for
|
|
proper logging
|
|
|
|
### **Phase 2: Quality & Review**
|
|
|
|
1. **Code Quality** - Use `historical_comment_management.mdc` for
|
|
code quality standards
|
|
2. **Complexity Assessment** - Apply `complexity_assessment.mdc` to
|
|
evaluate fix complexity
|
|
3. **Code Review** - Follow review standards from bundled rules
|
|
|
|
### **Phase 3: Testing & Validation**
|
|
|
|
1. **Platform Testing** - Use `timesafari_platforms.mdc` for
|
|
platform-specific testing
|
|
2. **Build Validation** - Apply `build_validation.mdc` for build
|
|
system compliance
|
|
3. **Final Validation** - Verify fix works across all platforms
|
|
|
|
## Success Criteria
|
|
|
|
- [ ] **Fix implemented** following development standards
|
|
- [ ] **Type safety maintained** with proper error handling
|
|
- [ ] **Logging properly implemented** with component context
|
|
- [ ] **Code quality standards met** with clean, maintainable code
|
|
- [ ] **Testing completed** across all target platforms
|
|
- [ ] **Build validation passed** with no build system issues
|
|
- [ ] **Code review completed** with all feedback addressed
|
|
- [ ] **Documentation updated** with fix details and lessons learned
|
|
|
|
## Common Pitfalls
|
|
|
|
- **Don't skip type safety** - leads to runtime errors
|
|
- **Don't ignore logging** - makes future debugging harder
|
|
- **Don't skip platform testing** - misses platform-specific issues
|
|
- **Don't ignore code quality** - creates technical debt
|
|
- **Don't skip build validation** - can break build system
|
|
- **Don't forget documentation** - loses fix context for future
|
|
|
|
## Integration Points
|
|
|
|
### **With Other Meta-Rules**
|
|
|
|
- **Bug Diagnosis**: Investigation results drive fix implementation
|
|
- **Feature Implementation**: Fix patterns inform future development
|
|
- **Feature Planning**: Fix complexity informs future planning
|
|
|
|
### **With Development Workflow**
|
|
|
|
- Fix implementation follows development standards
|
|
- Testing strategy ensures fix quality
|
|
- Code review maintains code quality
|
|
|
|
## Feedback & Improvement
|
|
|
|
### **Sub-Rule Ratings (1-5 scale)**
|
|
|
|
- **Development Standards**: ___/5 - Comments: _______________
|
|
- **Type Safety**: ___/5 - Comments: _______________
|
|
- **Logging Migration**: ___/5 - Comments: _______________
|
|
- **Code Quality**: ___/5 - Comments: _______________
|
|
- **Platform Testing**: ___/5 - Comments: _______________
|
|
|
|
### **Workflow Feedback**
|
|
|
|
- **Implementation Clarity**: How clear was the implementation guidance?
|
|
- **Testing Coverage**: Were testing requirements sufficient or excessive?
|
|
- **Process Effectiveness**: How well did the workflow work for you?
|
|
|
|
### **Sub-Rule Improvements**
|
|
|
|
- **Clarity Issues**: Which rules were unclear or confusing?
|
|
- **Missing Examples**: What examples would make rules more useful?
|
|
- **Integration Problems**: Do any rules conflict or overlap?
|
|
|
|
### **Overall Experience**
|
|
|
|
- **Time Saved**: How much time did this meta-rule save you?
|
|
- **Quality Improvement**: Did following these rules improve your fix?
|
|
- **Recommendation**: Would you recommend this meta-rule to others?
|
|
|
|
## Model Implementation Checklist
|
|
|
|
### Before Bug Fixing
|
|
|
|
- [ ] **Root Cause Understood**: Confirm root cause is clearly identified
|
|
- [ ] **Fix Strategy Planned**: Plan implementation approach and testing
|
|
- [ ] **Platform Impact Assessed**: Understand impact across all platforms
|
|
- [ ] **Testing Strategy Planned**: Plan testing approach for the fix
|
|
|
|
### During Bug Fixing
|
|
|
|
- [ ] **Rule Application**: Apply bundled rules in recommended sequence
|
|
- [ ] **Implementation**: Implement fix following development standards
|
|
- [ ] **Testing**: Test fix across all target platforms
|
|
- [ ] **Documentation**: Document implementation details and decisions
|
|
|
|
### After Bug Fixing
|
|
|
|
- [ ] **Validation**: Verify fix meets all success criteria
|
|
- [ ] **Code Review**: Complete code review with team
|
|
- [ ] **Deployment**: Deploy fix following deployment procedures
|
|
- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
|
|
|
|
---
|
|
|
|
**See also**:
|
|
|
|
- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation workflow
|
|
- `.cursor/rules/meta_feature_implementation.mdc` for implementation patterns
|
|
- `.cursor/rules/meta_feature_planning.mdc` for planning future work
|
|
|
|
**Status**: Active meta-rule for bug fixing
|
|
**Priority**: High
|
|
**Estimated Effort**: Ongoing reference
|
|
**Dependencies**: All bundled sub-rules
|
|
**Stakeholders**: Development team, QA team, DevOps team
|
|
|