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.
		
		
		
		
		
			
		
			
				
					
					
						
							214 lines
						
					
					
						
							7.2 KiB
						
					
					
				
			
		
		
		
			
			
			
				
					
				
				
					
				
			
		
		
	
	
							214 lines
						
					
					
						
							7.2 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.
							 | 
						|
								
							 | 
						|
								## Workflow Constraints
							 | 
						|
								
							 | 
						|
								**This meta-rule enforces FIXING MODE for all bundled sub-rules:**
							 | 
						|
								
							 | 
						|
								```json
							 | 
						|
								{
							 | 
						|
								  "workflowMode": "fixing",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "implementation",
							 | 
						|
								    "allowed": ["modify", "create", "build", "test", "commit"],
							 | 
						|
								    "required": "diagnosis_complete_before_fixing"
							 | 
						|
								  }
							 | 
						|
								}
							 | 
						|
								```
							 | 
						|
								
							 | 
						|
								**All bundled sub-rules automatically inherit these constraints.**
							 | 
						|
								
							 | 
						|
								## Workflow State Update
							 | 
						|
								
							 | 
						|
								**When this meta-rule is invoked, update the workflow state file:**
							 | 
						|
								
							 | 
						|
								```json
							 | 
						|
								{
							 | 
						|
								  "currentMode": "fixing",
							 | 
						|
								  "lastInvoked": "meta_bug_fixing.mdc",
							 | 
						|
								  "timestamp": "2025-01-27T15:30:00Z",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "implementation",
							 | 
						|
								    "allowed": ["modify", "create", "build", "test", "commit"],
							 | 
						|
								    "forbidden": [],
							 | 
						|
								    "required": "diagnosis_complete_before_fixing"
							 | 
						|
								  }
							 | 
						|
								}
							 | 
						|
								```
							 | 
						|
								
							 | 
						|
								**State File Location**: `.cursor/rules/.workflow_state.json`
							 | 
						|
								
							 | 
						|
								**This enables the core always-on rule to enforce fixing mode constraints.**
							 | 
						|
								
							 | 
						|
								## 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
							 | 
						|
								
							 |