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.
		
		
		
		
		
			
		
			
				
					
					
						
							288 lines
						
					
					
						
							9.1 KiB
						
					
					
				
			
		
		
		
			
			
			
				
					
				
				
					
				
			
		
		
	
	
							288 lines
						
					
					
						
							9.1 KiB
						
					
					
				
								# Meta-Rule: Bug Diagnosis Workflow
							 | 
						|
								
							 | 
						|
								**Author**: Matthew Raymer
							 | 
						|
								**Date**: August 24, 2025
							 | 
						|
								**Status**: 🎯 **ACTIVE** - Core workflow for all bug investigation
							 | 
						|
								
							 | 
						|
								## Purpose
							 | 
						|
								
							 | 
						|
								This meta-rule defines the systematic approach for investigating and diagnosing
							 | 
						|
								bugs, defects, and unexpected behaviors in the TimeSafari application. It ensures
							 | 
						|
								consistent, thorough, and efficient problem-solving workflows.
							 | 
						|
								
							 | 
						|
								## Workflow Constraints
							 | 
						|
								
							 | 
						|
								**This meta-rule enforces DIAGNOSIS MODE for all bundled sub-rules:**
							 | 
						|
								
							 | 
						|
								```json
							 | 
						|
								{
							 | 
						|
								  "workflowMode": "diagnosis",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "read_only",
							 | 
						|
								    "forbidden": ["modify", "create", "build", "commit"],
							 | 
						|
								    "required": "complete_investigation_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": "diagnosis",
							 | 
						|
								  "lastInvoked": "meta_bug_diagnosis.mdc",
							 | 
						|
								  "timestamp": "2025-01-27T15:30:00Z",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "read_only",
							 | 
						|
								    "forbidden": ["modify", "create", "build", "commit"],
							 | 
						|
								    "allowed": ["read", "search", "analyze", "document"],
							 | 
						|
								    "required": "complete_investigation_before_fixing"
							 | 
						|
								  }
							 | 
						|
								}
							 | 
						|
								```
							 | 
						|
								
							 | 
						|
								**State File Location**: `.cursor/rules/.workflow_state.json`
							 | 
						|
								
							 | 
						|
								**This enables the core always-on rule to enforce diagnosis mode constraints.**
							 | 
						|
								
							 | 
						|
								## When to Use
							 | 
						|
								
							 | 
						|
								**ALWAYS** - Apply this workflow to every bug investigation, regardless of
							 | 
						|
								severity or complexity. This ensures systematic problem-solving and prevents
							 | 
						|
								common investigation pitfalls.
							 | 
						|
								
							 | 
						|
								## Bundled Rules
							 | 
						|
								
							 | 
						|
								### **Investigation Foundation**
							 | 
						|
								
							 | 
						|
								- **`development/research_diagnostic.mdc`** - Research and investigation methodologies
							 | 
						|
								- **`development/logging_standards.mdc`** - Logging and debugging best practices
							 | 
						|
								- **`development/type_safety_guide.mdc`** - Type safety and error prevention
							 | 
						|
								
							 | 
						|
								### **Development Workflow**
							 | 
						|
								
							 | 
						|
								- **`workflow/version_control.mdc`** - Version control during investigation
							 | 
						|
								- **`development/software_development.mdc`** - Development best practices
							 | 
						|
								
							 | 
						|
								## Critical Development Constraints
							 | 
						|
								
							 | 
						|
								### **🚫 NEVER Use Build Commands During Diagnosis**
							 | 
						|
								
							 | 
						|
								**Critical Rule**: Never use `npm run build:web` or similar build commands during bug diagnosis
							 | 
						|
								
							 | 
						|
								- **Reason**: These commands block the chat and prevent effective troubleshooting
							 | 
						|
								- **Impact**: Blocks user interaction, prevents real-time problem solving
							 | 
						|
								- **Alternative**: Use safe, fast commands for investigation
							 | 
						|
								- **When to use build**: Only after diagnosis is complete and fixes are ready for testing
							 | 
						|
								
							 | 
						|
								### **Safe Diagnosis Commands**
							 | 
						|
								
							 | 
						|
								✅ **Safe to use during diagnosis:**
							 | 
						|
								- `npm run lint-fix` - Syntax and style checking
							 | 
						|
								- `npm run type-check` - TypeScript validation (if available)
							 | 
						|
								- `git status` - Version control status
							 | 
						|
								- `ls` / `dir` - File listing
							 | 
						|
								- `cat` / `read_file` - File content inspection
							 | 
						|
								- `grep_search` - Text pattern searching
							 | 
						|
								
							 | 
						|
								❌ **Never use during diagnosis:**
							 | 
						|
								- `npm run build:web` - Blocks chat
							 | 
						|
								- `npm run build:electron` - Blocks chat  
							 | 
						|
								- `npm run build:capacitor` - Blocks chat
							 | 
						|
								- Any long-running build processes
							 | 
						|
								
							 | 
						|
								## Investigation Workflow
							 | 
						|
								
							 | 
						|
								### **Phase 1: Problem Definition**
							 | 
						|
								
							 | 
						|
								1. **Gather Evidence**
							 | 
						|
								   - Error messages and stack traces
							 | 
						|
								   - User-reported symptoms
							 | 
						|
								   - System logs and timestamps
							 | 
						|
								   - Reproduction steps
							 | 
						|
								
							 | 
						|
								2. **Context Analysis**
							 | 
						|
								   - When did the problem start?
							 | 
						|
								   - What changed recently?
							 | 
						|
								   - Which platform/environment?
							 | 
						|
								   - User actions leading to the issue
							 | 
						|
								
							 | 
						|
								### **Phase 2: Systematic Investigation**
							 | 
						|
								
							 | 
						|
								1. **Code Inspection**
							 | 
						|
								   - Relevant file examination
							 | 
						|
								   - Import and dependency analysis
							 | 
						|
								   - Syntax and type checking
							 | 
						|
								   - Logic flow analysis
							 | 
						|
								
							 | 
						|
								2. **Environment Analysis**
							 | 
						|
								   - Platform-specific considerations
							 | 
						|
								   - Configuration and settings
							 | 
						|
								   - Database and storage state
							 | 
						|
								   - Network and API connectivity
							 | 
						|
								
							 | 
						|
								### **Phase 3: Root Cause Identification**
							 | 
						|
								
							 | 
						|
								1. **Pattern Recognition**
							 | 
						|
								   - Similar issues in codebase
							 | 
						|
								   - Common failure modes
							 | 
						|
								   - Platform-specific behaviors
							 | 
						|
								   - Recent changes impact
							 | 
						|
								
							 | 
						|
								2. **Hypothesis Testing**
							 | 
						|
								   - Targeted code changes
							 | 
						|
								   - Configuration modifications
							 | 
						|
								   - Environment adjustments
							 | 
						|
								   - Systematic elimination
							 | 
						|
								
							 | 
						|
								## Investigation Techniques
							 | 
						|
								
							 | 
						|
								### **Safe Code Analysis**
							 | 
						|
								
							 | 
						|
								- **File Reading**: Use `read_file` tool for targeted inspection
							 | 
						|
								- **Pattern Searching**: Use `grep_search` for code patterns
							 | 
						|
								- **Semantic Search**: Use `codebase_search` for related functionality
							 | 
						|
								- **Import Tracing**: Follow dependency chains systematically
							 | 
						|
								
							 | 
						|
								### **Error Analysis**
							 | 
						|
								
							 | 
						|
								- **Stack Trace Analysis**: Identify error origin and propagation
							 | 
						|
								- **Log Correlation**: Match errors with system events
							 | 
						|
								- **Timeline Reconstruction**: Build sequence of events
							 | 
						|
								- **Context Preservation**: Maintain investigation state
							 | 
						|
								
							 | 
						|
								### **Platform Considerations**
							 | 
						|
								
							 | 
						|
								- **Web Platform**: Browser-specific behaviors and limitations
							 | 
						|
								- **Electron Platform**: Desktop app considerations
							 | 
						|
								- **Capacitor Platform**: Mobile app behaviors
							 | 
						|
								- **Cross-Platform**: Shared vs. platform-specific code
							 | 
						|
								
							 | 
						|
								## Evidence Collection Standards
							 | 
						|
								
							 | 
						|
								### **Timestamps**
							 | 
						|
								
							 | 
						|
								- **UTC Format**: All timestamps in UTC for consistency
							 | 
						|
								- **Precision**: Include milliseconds for precise correlation
							 | 
						|
								- **Context**: Include relevant system state information
							 | 
						|
								- **Correlation**: Link events across different components
							 | 
						|
								
							 | 
						|
								### **Error Context**
							 | 
						|
								
							 | 
						|
								- **Full Error Objects**: Capture complete error information
							 | 
						|
								- **Stack Traces**: Preserve call stack for analysis
							 | 
						|
								- **User Actions**: Document steps leading to error
							 | 
						|
								- **System State**: Capture relevant configuration and state
							 | 
						|
								
							 | 
						|
								### **Reproduction Steps**
							 | 
						|
								
							 | 
						|
								- **Clear Sequence**: Step-by-step reproduction instructions
							 | 
						|
								- **Environment Details**: Platform, version, configuration
							 | 
						|
								- **Data Requirements**: Required data or state
							 | 
						|
								- **Expected vs. Actual**: Clear behavior comparison
							 | 
						|
								
							 | 
						|
								## Investigation Documentation
							 | 
						|
								
							 | 
						|
								### **Problem Summary**
							 | 
						|
								
							 | 
						|
								- **Issue Description**: Clear, concise problem statement
							 | 
						|
								- **Impact Assessment**: Severity and user impact
							 | 
						|
								- **Scope Definition**: Affected components and users
							 | 
						|
								- **Priority Level**: Based on impact and frequency
							 | 
						|
								
							 | 
						|
								### **Investigation Log**
							 | 
						|
								
							 | 
						|
								- **Timeline**: Chronological investigation steps
							 | 
						|
								- **Evidence**: Collected information and findings
							 | 
						|
								- **Hypotheses**: Tested theories and results
							 | 
						|
								- **Conclusions**: Root cause identification
							 | 
						|
								
							 | 
						|
								### **Solution Requirements**
							 | 
						|
								
							 | 
						|
								- **Fix Description**: Required changes and approach
							 | 
						|
								- **Testing Strategy**: Validation and verification steps
							 | 
						|
								- **Rollback Plan**: Reversion strategy if needed
							 | 
						|
								- **Prevention Measures**: Future issue prevention
							 | 
						|
								
							 | 
						|
								## Quality Standards
							 | 
						|
								
							 | 
						|
								### **Investigation Completeness**
							 | 
						|
								
							 | 
						|
								- **Evidence Sufficiency**: Adequate information for root cause
							 | 
						|
								- **Alternative Theories**: Considered and eliminated
							 | 
						|
								- **Platform Coverage**: All relevant platforms investigated
							 | 
						|
								- **Edge Cases**: Unusual scenarios considered
							 | 
						|
								
							 | 
						|
								### **Documentation Quality**
							 | 
						|
								
							 | 
						|
								- **Clear Communication**: Understandable to all stakeholders
							 | 
						|
								- **Technical Accuracy**: Precise technical details
							 | 
						|
								- **Actionable Insights**: Clear next steps and recommendations
							 | 
						|
								- **Knowledge Transfer**: Lessons learned for future reference
							 | 
						|
								
							 | 
						|
								## Common Pitfalls
							 | 
						|
								
							 | 
						|
								### **Investigation Mistakes**
							 | 
						|
								
							 | 
						|
								- **Jumping to Solutions**: Implementing fixes before understanding
							 | 
						|
								- **Insufficient Evidence**: Making assumptions without data
							 | 
						|
								- **Platform Blindness**: Ignoring platform-specific behaviors
							 | 
						|
								- **Scope Creep**: Expanding investigation beyond original problem
							 | 
						|
								
							 | 
						|
								### **Communication Issues**
							 | 
						|
								
							 | 
						|
								- **Technical Jargon**: Using unclear terminology
							 | 
						|
								- **Missing Context**: Insufficient background information
							 | 
						|
								- **Unclear Recommendations**: Vague or ambiguous next steps
							 | 
						|
								- **Poor Documentation**: Incomplete or unclear investigation records
							 | 
						|
								
							 | 
						|
								## Success Criteria
							 | 
						|
								
							 | 
						|
								- [ ] **Problem clearly defined** with sufficient evidence
							 | 
						|
								- [ ] **Root cause identified** through systematic investigation
							 | 
						|
								- [ ] **Solution approach determined** with clear requirements
							 | 
						|
								- [ ] **Documentation complete** for knowledge transfer
							 | 
						|
								- [ ] **No chat-blocking commands** used during investigation
							 | 
						|
								- [ ] **Platform considerations** properly addressed
							 | 
						|
								- [ ] **Timeline and context** properly documented
							 | 
						|
								
							 | 
						|
								## Integration with Other Meta-Rules
							 | 
						|
								
							 | 
						|
								### **Bug Fixing**
							 | 
						|
								
							 | 
						|
								- **Investigation Results**: Provide foundation for fix implementation
							 | 
						|
								- **Solution Requirements**: Define what needs to be built
							 | 
						|
								- **Testing Strategy**: Inform validation approach
							 | 
						|
								- **Documentation**: Support implementation guidance
							 | 
						|
								
							 | 
						|
								### **Feature Planning**
							 | 
						|
								
							 | 
						|
								- **Root Cause Analysis**: Identify systemic issues
							 | 
						|
								- **Prevention Measures**: Plan future issue avoidance
							 | 
						|
								- **Architecture Improvements**: Identify structural enhancements
							 | 
						|
								- **Process Refinements**: Improve development workflows
							 | 
						|
								
							 | 
						|
								### **Research and Documentation**
							 | 
						|
								
							 | 
						|
								- **Knowledge Base**: Contribute to troubleshooting guides
							 | 
						|
								- **Pattern Recognition**: Identify common failure modes
							 | 
						|
								- **Best Practices**: Develop investigation methodologies
							 | 
						|
								- **Team Training**: Improve investigation capabilities
							 | 
						|
								
							 | 
						|
								---
							 | 
						|
								
							 | 
						|
								**See also**:
							 | 
						|
								
							 | 
						|
								- `.cursor/rules/meta_bug_fixing.mdc` for implementing fixes
							 | 
						|
								- `.cursor/rules/meta_feature_planning.mdc` for planning improvements
							 | 
						|
								- `.cursor/rules/meta_documentation.mdc` for documentation standards
							 | 
						|
								
							 | 
						|
								**Status**: Active meta-rule for bug diagnosis
							 | 
						|
								**Priority**: High
							 | 
						|
								**Estimated Effort**: Ongoing reference
							 | 
						|
								**Dependencies**: All bundled sub-rules
							 | 
						|
								**Stakeholders**: Development team, QA team, DevOps team
							 | 
						|
								
							 |