eff7e339af
- Remove legacy rule files (documentation.mdc, general_development.mdc, etc.) - Implement new meta-rule system with core, app, and feature categories - Add meta-rule files for different workflows (bug diagnosis, feature planning, etc.) - Create organized directory structure: core/, app/, features/, database/, etc. - Add comprehensive README.md for rules documentation - Establish new rule architecture with always-on and workflow-specific rules This restructuring improves rule organization, enables better workflow management, and provides clearer separation of concerns for different development tasks.
215 lines
7.2 KiB
Plaintext
215 lines
7.2 KiB
Plaintext
# 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
|