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.
		
		
		
		
		
			
		
			
				
					
					
						
							226 lines
						
					
					
						
							7.7 KiB
						
					
					
				
			
		
		
		
			
			
			
				
					
				
				
					
				
			
		
		
	
	
							226 lines
						
					
					
						
							7.7 KiB
						
					
					
				| # Meta-Rule: Feature Implementation | |
| 
 | |
| **Author**: Matthew Raymer | |
| **Date**: 2025-08-21 | |
| **Status**: 🎯 **ACTIVE** - Feature implementation workflow bundling | |
| 
 | |
| ## Purpose | |
| 
 | |
| This meta-rule bundles all the rules needed for building features with | |
| proper architecture and cross-platform support. Use this when implementing | |
| planned features or refactoring existing code. | |
| 
 | |
| ## Workflow Constraints | |
| 
 | |
| **This meta-rule enforces IMPLEMENTATION MODE for all bundled sub-rules:** | |
| 
 | |
| ```json | |
| { | |
|   "workflowMode": "implementation", | |
|   "constraints": { | |
|     "mode": "development", | |
|     "allowed": ["code", "build", "test", "refactor", "deploy"], | |
|     "required": "planning_complete_before_implementation" | |
|   } | |
| } | |
| ``` | |
| 
 | |
| **All bundled sub-rules automatically inherit these constraints.** | |
| 
 | |
| ## Workflow State Update | |
| 
 | |
| **When this meta-rule is invoked, update the workflow state file:** | |
| 
 | |
| ```json | |
| { | |
|   "currentMode": "implementation", | |
|   "lastInvoked": "meta_feature_implementation.mdc", | |
|   "timestamp": "2025-01-27T15:30:00Z", | |
|   "constraints": { | |
|     "mode": "development", | |
|     "allowed": ["code", "build", "test", "refactor", "deploy"], | |
|     "forbidden": [], | |
|     "required": "planning_complete_before_implementation" | |
|   } | |
| } | |
| ``` | |
| 
 | |
| **State File Location**: `.cursor/rules/.workflow_state.json` | |
| 
 | |
| **This enables the core always-on rule to enforce implementation mode constraints.** | |
| 
 | |
| ## When to Use | |
| 
 | |
| - **Feature Development**: Building new features from planning | |
| - **Code Refactoring**: Restructuring existing code for better architecture | |
| - **Platform Expansion**: Adding features to new platforms | |
| - **Service Implementation**: Building new services or components | |
| - **Integration Work**: Connecting features with existing systems | |
| - **Performance Optimization**: Improving feature performance | |
| 
 | |
| ## Bundled Rules | |
| 
 | |
| ### **Development Foundation** | |
| 
 | |
| - **`app/timesafari_development.mdc`** - TimeSafari-specific | |
|   development workflow and quality standards | |
| - **`development/software_development.mdc`** - Core development | |
|   principles and evidence requirements | |
| - **`development/type_safety_guide.mdc`** - Type-safe implementation | |
|   with proper error handling | |
| 
 | |
| ### **Architecture & Patterns** | |
| 
 | |
| - **`app/architectural_patterns.mdc`** - Design patterns and | |
|   architectural examples for features | |
| - **`app/architectural_examples.mdc`** - Implementation examples | |
|   and testing strategies | |
| - **`app/architectural_implementation.mdc`** - Implementation | |
|   guidelines and best practices | |
| 
 | |
| ### **Platform & Services** | |
| 
 | |
| - **`app/timesafari_platforms.mdc`** - Platform abstraction | |
|   patterns and platform-specific requirements | |
| - **`development/asset_configuration.mdc`** - Asset management | |
|   and build integration | |
| - **`development/logging_standards.mdc`** - Proper logging | |
|   implementation standards | |
| 
 | |
| ### **Quality & Validation** | |
| 
 | |
| - **`architecture/build_validation.mdc`** - Build system | |
|   validation and testing procedures | |
| - **`architecture/build_testing.mdc`** - Testing requirements | |
|   and feedback collection | |
| - **`development/complexity_assessment.mdc`** - Complexity | |
|   evaluation for implementation | |
| 
 | |
| ## Workflow Sequence | |
| 
 | |
| ### **Phase 1: Implementation Foundation (Start Here)** | |
| 
 | |
| 1. **Development Workflow** - Use `timesafari_development.mdc` for | |
|    development standards and workflow | |
| 2. **Type Safety** - Apply `type_safety_guide.mdc` for type-safe | |
|    implementation | |
| 3. **Architecture Patterns** - Use `architectural_patterns.mdc` for | |
|    design patterns | |
| 
 | |
| ### **Phase 2: Feature Development** | |
| 
 | |
| 1. **Platform Services** - Apply `timesafari_platforms.mdc` for | |
|    platform abstraction | |
| 2. **Implementation Examples** - Use `architectural_examples.mdc` | |
|    for implementation guidance | |
| 3. **Asset Configuration** - Apply `asset_configuration.mdc` for | |
|    asset management | |
| 
 | |
| ### **Phase 3: Quality & Testing** | |
| 
 | |
| 1. **Logging Implementation** - Use `logging_standards.mdc` for | |
|    proper logging | |
| 2. **Build Validation** - Apply `build_validation.mdc` for build | |
|    system compliance | |
| 3. **Testing & Feedback** - Use `build_testing.mdc` for testing | |
|    requirements | |
| 
 | |
| ## Success Criteria | |
| 
 | |
| - [ ] **Feature implemented** following development standards | |
| - [ ] **Type safety maintained** with proper error handling | |
| - [ ] **Architecture patterns applied** consistently | |
| - [ ] **Platform abstraction implemented** correctly | |
| - [ ] **Logging properly implemented** with component context | |
| - [ ] **Assets configured** and integrated with build system | |
| - [ ] **Build validation passed** with no build system issues | |
| - [ ] **Testing completed** across all target platforms | |
| - [ ] **Code review completed** with all feedback addressed | |
| 
 | |
| ## Common Pitfalls | |
| 
 | |
| - **Don't skip architecture patterns** - leads to inconsistent design | |
| - **Don't ignore platform abstraction** - creates platform-specific code | |
| - **Don't skip type safety** - leads to runtime errors | |
| - **Don't ignore logging** - makes future debugging harder | |
| - **Don't skip build validation** - can break build system | |
| - **Don't forget asset configuration** - leads to missing assets | |
| 
 | |
| ## Integration Points | |
| 
 | |
| ### **With Other Meta-Rules** | |
| 
 | |
| - **Feature Planning**: Planning outputs drive implementation approach | |
| - **Bug Fixing**: Implementation patterns inform fix strategies | |
| - **Bug Diagnosis**: Implementation insights help with investigation | |
| 
 | |
| ### **With Development Workflow** | |
| 
 | |
| - Implementation follows development standards | |
| - Architecture decisions drive implementation approach | |
| - Platform requirements inform testing strategy | |
| 
 | |
| ## Feedback & Improvement | |
| 
 | |
| ### **Sub-Rule Ratings (1-5 scale)** | |
| 
 | |
| - **Development Workflow**: ___/5 - Comments: _______________ | |
| - **Type Safety**: ___/5 - Comments: _______________ | |
| - **Architecture Patterns**: ___/5 - Comments: _______________ | |
| - **Platform Services**: ___/5 - Comments: _______________ | |
| - **Build Validation**: ___/5 - Comments: _______________ | |
| 
 | |
| ### **Workflow Feedback** | |
| 
 | |
| - **Implementation Clarity**: How clear was the implementation guidance? | |
| - **Pattern Effectiveness**: How well did architecture patterns work? | |
| - **Platform Coverage**: How well did platform guidance cover your needs? | |
| 
 | |
| ### **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 implementation? | |
| - **Recommendation**: Would you recommend this meta-rule to others? | |
| 
 | |
| ## Model Implementation Checklist | |
| 
 | |
| ### Before Feature Implementation | |
| 
 | |
| - [ ] **Planning Review**: Review feature planning and requirements | |
| - [ ] **Architecture Planning**: Plan architecture and design patterns | |
| - [ ] **Platform Analysis**: Understand platform-specific requirements | |
| - [ ] **Testing Strategy**: Plan testing approach for the feature | |
| 
 | |
| ### During Feature Implementation | |
| 
 | |
| - [ ] **Rule Application**: Apply bundled rules in recommended sequence | |
| - [ ] **Implementation**: Implement feature following development standards | |
| - [ ] **Testing**: Test feature across all target platforms | |
| - [ ] **Documentation**: Document implementation details and decisions | |
| 
 | |
| ### After Feature Implementation | |
| 
 | |
| - [ ] **Validation**: Verify feature meets all success criteria | |
| - [ ] **Code Review**: Complete code review with team | |
| - [ ] **Testing**: Complete comprehensive testing across platforms | |
| - [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness | |
| 
 | |
| --- | |
| 
 | |
| **See also**: | |
| 
 | |
| - `.cursor/rules/meta_feature_planning.mdc` for planning workflow | |
| - `.cursor/rules/meta_bug_fixing.mdc` for fix implementation patterns | |
| - `.cursor/rules/meta_bug_diagnosis.mdc` for investigation insights | |
| 
 | |
| **Status**: Active meta-rule for feature implementation | |
| **Priority**: High | |
| **Estimated Effort**: Ongoing reference | |
| **Dependencies**: All bundled sub-rules | |
| **Stakeholders**: Development team, Architecture team, QA team
 | |
| 
 |