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
 | |
| 
 |