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