Browse Source

feat: implement enhanced workflow state system with commit override capability

- Add commit override mechanism to workflow state constraints
- Enhance meta_bug_diagnosis.mdc with comprehensive investigation workflow
- Implement workflow state enforcement across all meta-rules
- Add always_on_rules.mdc for core rule bundling
- Update all meta-rules to support workflow state management
- Maintain version control standards while providing workflow flexibility

Security: No code execution changes, workflow rule updates only
Migration: Workflow infrastructure enhancement, no database changes
Testing: Manual validation of workflow state constraints
Documentation: Comprehensive workflow documentation and examples

Closes: Workflow state rigidity issue
Enables: Commits on demand during investigation phases
pull/170/head
Matthew Raymer 1 day ago
parent
commit
a85b508f44
  1. 192
      .cursor/rules/always_on_rules.mdc
  2. 340
      .cursor/rules/meta_bug_diagnosis.mdc
  3. 39
      .cursor/rules/meta_bug_fixing.mdc
  4. 115
      .cursor/rules/meta_core_always_on.mdc
  5. 38
      .cursor/rules/meta_documentation.mdc
  6. 39
      .cursor/rules/meta_feature_implementation.mdc
  7. 38
      .cursor/rules/meta_feature_planning.mdc
  8. 38
      .cursor/rules/meta_research.mdc

192
.cursor/rules/always_on_rules.mdc

@ -0,0 +1,192 @@
# Meta-Rule: Core Always-On Rules
**Author**: Matthew Raymer
**Date**: 2025-08-21
**Status**: 🎯 **ACTIVE** - Core rules for every prompt
## Purpose
This meta-rule bundles the core rules that should be applied to **every single
prompt** because they define fundamental behaviors, principles, and context
that are essential for all AI interactions.
## When to Use
**ALWAYS** - These rules apply to every single prompt, regardless of the task
or context. They form the foundation for all AI assistant behavior.
## Bundled Rules
### **Core Human Competence Principles**
- **`core/base_context.mdc`** - Human competence first principles, interaction
guidelines, and output contract requirements
- **`core/less_complex.mdc`** - Minimalist solution principle and complexity
guidelines
### **Time & Context Standards**
- **`development/time.mdc`** - Time handling principles and UTC standards
- **`development/time_examples.mdc`** - Practical time implementation examples
- **`development/time_implementation.mdc`** - Detailed time implementation
guidelines
### **Version Control & Process**
- **`workflow/version_control.mdc`** - Version control principles and commit
guidelines
- **`workflow/commit_messages.mdc`** - Commit message format and conventions
### **Application Context**
- **`app/timesafari.mdc`** - Core TimeSafari application context and
development principles
- **`app/timesafari_development.mdc`** - TimeSafari-specific development
workflow and quality standards
## Why These Rules Are Always-On
### **Base Context**
- **Human Competence First**: Every interaction must increase human competence
- **Output Contract**: All responses must follow the required structure
- **Competence Hooks**: Learning and collaboration must be built into every response
### **Time Standards**
- **UTC Consistency**: All timestamps must use UTC for system operations
- **Evidence Collection**: Time context is essential for debugging and investigation
- **Cross-Platform**: Time handling affects all platforms and features
### **Version Control**
- **Commit Standards**: Every code change must follow commit message conventions
- **Process Consistency**: Version control affects all development work
- **Team Collaboration**: Commit standards enable effective team communication
### **Application Context**
- **Platform Awareness**: Every task must consider web/mobile/desktop platforms
- **Architecture Principles**: All work must follow TimeSafari patterns
- **Development Standards**: Quality and testing requirements apply to all work
## Application Priority
### **Primary (Apply First)**
1. **Base Context** - Human competence and output contract
2. **Time Standards** - UTC and timestamp requirements
3. **Application Context** - TimeSafari principles and platforms
### **Secondary (Apply as Needed)**
1. **Version Control** - When making code changes
2. **Complexity Guidelines** - When evaluating solution approaches
## Integration with Other Meta-Rules
### **Feature Planning**
- Base context ensures human competence focus
- Time standards inform planning and estimation
- Application context drives platform considerations
### **Bug Diagnosis**
- Base context ensures systematic investigation
- Time standards enable proper evidence collection
- Application context provides system understanding
### **Bug Fixing**
- Base context ensures quality implementation
- Time standards maintain logging consistency
- Application context guides testing strategy
### **Feature Implementation**
- Base context ensures proper development approach
- Time standards maintain system consistency
- Application context drives architecture decisions
## Success Criteria
- [ ] **Base context applied** to every single prompt
- [ ] **Time standards followed** for all timestamps and logging
- [ ] **Version control standards** applied to all code changes
- [ ] **Application context considered** for all platform work
- [ ] **Human competence focus** maintained in all interactions
- [ ] **Output contract structure** followed in all responses
## Common Pitfalls
- **Don't skip base context** - loses human competence focus
- **Don't ignore time standards** - creates inconsistent timestamps
- **Don't forget application context** - misses platform considerations
- **Don't skip version control** - creates inconsistent commit history
- **Don't lose competence focus** - reduces learning value
## Feedback & Improvement
### **Rule Effectiveness Ratings (1-5 scale)**
- **Base Context**: ___/5 - Comments: _______________
- **Time Standards**: ___/5 - Comments: _______________
- **Version Control**: ___/5 - Comments: _______________
- **Application Context**: ___/5 - Comments: _______________
### **Always-On Effectiveness**
- **Consistency**: Are these rules applied consistently across all prompts?
- **Value**: Do these rules add value to every interaction?
- **Overhead**: Are these rules too burdensome for simple tasks?
### **Integration Feedback**
- **With Other Meta-Rules**: How well do these integrate with workflow rules?
- **Context Switching**: Do these rules help or hinder context switching?
- **Learning Curve**: Are these rules easy for new users to understand?
### **Overall Experience**
- **Quality Improvement**: Do these rules improve response quality?
- **Efficiency**: Do these rules make interactions more efficient?
- **Recommendation**: Would you recommend keeping these always-on?
## Model Implementation Checklist
### Before Every Prompt
- [ ] **Base Context**: Ensure human competence principles are active
- [ ] **Time Standards**: Verify UTC and timestamp requirements are clear
- [ ] **Application Context**: Confirm TimeSafari context is loaded
- [ ] **Version Control**: Prepare commit standards if code changes are needed
### During Response Creation
- [ ] **Output Contract**: Follow required response structure
- [ ] **Competence Hooks**: Include learning and collaboration elements
- [ ] **Time Consistency**: Apply UTC standards for all time references
- [ ] **Platform Awareness**: Consider all target platforms
### After Response Creation
- [ ] **Validation**: Verify all always-on rules were applied
- [ ] **Quality Check**: Ensure response meets competence standards
- [ ] **Context Review**: Confirm application context was properly considered
- [ ] **Feedback Collection**: Note any issues with always-on application
---
**See also**:
- `.cursor/rules/meta_feature_planning.mdc` for workflow-specific rules
- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation workflows
- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation
- `.cursor/rules/meta_feature_implementation.mdc` for feature development
**Status**: Active core always-on meta-rule
**Priority**: Critical (applies to every prompt)
**Estimated Effort**: Ongoing reference
**Dependencies**: All bundled sub-rules
**Stakeholders**: All AI interactions, Development team

340
.cursor/rules/meta_bug_diagnosis.mdc

@ -1,169 +1,285 @@
# Meta-Rule: Bug Diagnosis
# Meta-Rule: Bug Diagnosis Workflow
**Author**: Matthew Raymer
**Date**: 2025-08-21
**Status**: 🎯 **ACTIVE** - Bug investigation workflow bundling
**Date**: August 24, 2025
**Status**: 🎯 **ACTIVE** - Core workflow for all bug investigation
## Purpose
This meta-rule bundles all the rules needed for systematic bug investigation
and root cause analysis. Use this when bugs are reported, performance
issues occur, or unexpected behavior happens.
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
- **Bug Reports**: Investigating reported bugs or issues
- **Performance Issues**: Diagnosing slow performance or bottlenecks
- **Unexpected Behavior**: Understanding why code behaves unexpectedly
- **Production Issues**: Investigating issues in live environments
- **Test Failures**: Understanding why tests are failing
- **Integration Problems**: Diagnosing issues between components
**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 Process**
### **Investigation Foundation**
- **`development/research_diagnostic.mdc`** - Systematic investigation
workflow with evidence collection and analysis
- **`development/investigation_report_example.mdc`** - Investigation
documentation templates and examples
- **`core/harbor_pilot_universal.mdc`** - Technical guide creation
for complex investigations
- **`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
### **Evidence Collection**
### **Development Workflow**
- **`development/logging_standards.mdc`** - Logging implementation
standards for debugging and evidence collection
- **`development/time.mdc`** - Timestamp requirements and time
handling standards for evidence
- **`development/time_examples.mdc`** - Practical examples of
proper time handling in investigations
- **`workflow/version_control.mdc`** - Version control during investigation
- **`development/software_development.mdc`** - Development best practices
### **Technical Context**
## Critical Development Constraints
- **`app/timesafari.mdc`** - Core application context and
architecture for understanding the system
- **`app/timesafari_platforms.mdc`** - Platform-specific
considerations and constraints
### **🚫 NEVER Use Build Commands During Diagnosis**
## Workflow Sequence
**Critical Rule**: Never use `npm run build:web` or similar build commands during bug diagnosis
### **Phase 1: Initial Investigation (Start Here)**
- **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
1. **Research Diagnostic** - Use `research_diagnostic.mdc` for
systematic investigation approach
2. **Evidence Collection** - Apply `logging_standards.mdc` and
`time.mdc` for proper evidence gathering
3. **Context Understanding** - Review `timesafari.mdc` for
application context
### **Safe Diagnosis Commands**
### **Phase 2: Deep Investigation**
✅ **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
1. **Platform Analysis** - Check `timesafari_platforms.mdc` for
platform-specific issues
2. **Technical Guide Creation** - Use `harbor_pilot_universal.mdc`
for complex investigation documentation
3. **Evidence Analysis** - Apply `time_examples.mdc` for proper
timestamp handling
❌ **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
### **Phase 3: Documentation & Reporting**
## Investigation Workflow
1. **Investigation Report** - Use `investigation_report_example.mdc`
for comprehensive documentation
2. **Root Cause Analysis** - Synthesize findings into actionable
insights
### **Phase 1: Problem Definition**
## Success Criteria
1. **Gather Evidence**
- Error messages and stack traces
- User-reported symptoms
- System logs and timestamps
- Reproduction steps
- [ ] **Root cause identified** with supporting evidence
- [ ] **Evidence properly collected** with timestamps and context
- [ ] **Investigation documented** using appropriate templates
- [ ] **Platform factors considered** in diagnosis
- [ ] **Reproduction steps documented** for verification
- [ ] **Impact assessment completed** with scope defined
- [ ] **Next steps identified** for resolution
2. **Context Analysis**
- When did the problem start?
- What changed recently?
- Which platform/environment?
- User actions leading to the issue
## Common Pitfalls
### **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**
- **Don't skip evidence collection** - leads to speculation
- **Don't ignore platform differences** - misses platform-specific issues
- **Don't skip documentation** - loses investigation insights
- **Don't assume root cause** - verify with evidence
- **Don't ignore time context** - misses temporal factors
- **Don't skip reproduction steps** - makes verification impossible
- **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
## Integration Points
### **Error Analysis**
### **With Other Meta-Rules**
- **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
- **Feature Planning**: Use complexity assessment for investigation planning
- **Bug Fixing**: Investigation results feed directly into fix implementation
- **Feature Implementation**: Investigation insights inform future development
### **Platform Considerations**
### **With Development Workflow**
- **Web Platform**: Browser-specific behaviors and limitations
- **Electron Platform**: Desktop app considerations
- **Capacitor Platform**: Mobile app behaviors
- **Cross-Platform**: Shared vs. platform-specific code
- Investigation findings inform testing strategy
- Root cause analysis drives preventive measures
- Evidence collection improves logging standards
## Evidence Collection Standards
## Feedback & Improvement
### **Timestamps**
### **Sub-Rule Ratings (1-5 scale)**
- **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
- **Research Diagnostic**: ___/5 - Comments: _______________
- **Investigation Report**: ___/5 - Comments: _______________
- **Technical Guide Creation**: ___/5 - Comments: _______________
- **Logging Standards**: ___/5 - Comments: _______________
- **Time Standards**: ___/5 - Comments: _______________
### **Error Context**
### **Workflow Feedback**
- **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
- **Investigation Effectiveness**: How well did the process help find root cause?
- **Missing Steps**: What investigation steps should be added?
- **Process Gaps**: Where did the workflow break down?
### **Reproduction Steps**
### **Sub-Rule Improvements**
- **Clear Sequence**: Step-by-step reproduction instructions
- **Environment Details**: Platform, version, configuration
- **Data Requirements**: Required data or state
- **Expected vs. Actual**: Clear behavior comparison
- **Clarity Issues**: Which rules were unclear or confusing?
- **Missing Examples**: What examples would make rules more useful?
- **Template Improvements**: How could investigation templates be better?
## Investigation Documentation
### **Overall Experience**
### **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
- **Time Saved**: How much time did this meta-rule save you?
- **Quality Improvement**: Did following these rules improve your investigation?
- **Recommendation**: Would you recommend this meta-rule to others?
- [ ] **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
## Model Implementation Checklist
## Integration with Other Meta-Rules
### Before Bug Investigation
### **Bug Fixing**
- [ ] **Problem Definition**: Clearly define what needs to be investigated
- [ ] **Scope Definition**: Determine investigation scope and boundaries
- [ ] **Evidence Planning**: Plan evidence collection strategy
- [ ] **Stakeholder Identification**: Identify who needs to be involved
- **Investigation Results**: Provide foundation for fix implementation
- **Solution Requirements**: Define what needs to be built
- **Testing Strategy**: Inform validation approach
- **Documentation**: Support implementation guidance
### During Bug Investigation
### **Feature Planning**
- [ ] **Rule Application**: Apply bundled rules in recommended sequence
- [ ] **Evidence Collection**: Collect evidence systematically with timestamps
- [ ] **Documentation**: Document investigation process and findings
- [ ] **Validation**: Verify findings with reproduction steps
- **Root Cause Analysis**: Identify systemic issues
- **Prevention Measures**: Plan future issue avoidance
- **Architecture Improvements**: Identify structural enhancements
- **Process Refinements**: Improve development workflows
### After Bug Investigation
### **Research and Documentation**
- [ ] **Report Creation**: Create comprehensive investigation report
- [ ] **Root Cause Analysis**: Document root cause with evidence
- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
- [ ] **Process Improvement**: Identify improvements for future investigations
- **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_feature_planning.mdc` for planning investigation work
- `.cursor/rules/meta_bug_fixing.mdc` for implementing fixes
- `.cursor/rules/meta_feature_implementation.mdc` for preventive measures
- `.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

39
.cursor/rules/meta_bug_fixing.mdc

@ -10,6 +10,45 @@ 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

115
.cursor/rules/meta_core_always_on.mdc

@ -14,6 +14,109 @@ This meta-rule bundles the core rules that should be applied to **every single
prompt** because they define fundamental behaviors, principles, and context
that are essential for all AI interactions.
## Workflow Constraints
**This meta-rule enforces ALWAYS-ON MODE for all bundled sub-rules:**
```json
{
"workflowMode": "always_on",
"constraints": {
"mode": "foundation",
"alwaysApplied": true,
"required": "applied_to_every_prompt"
}
}
```
**All bundled sub-rules automatically inherit these constraints.**
## Workflow State Enforcement
**This meta-rule enforces current workflow mode constraints for all interactions:**
### **Current Workflow State**
```json
{
"workflowState": {
"currentMode": "diagnosis|fixing|planning|research|documentation",
"constraints": {
"mode": "read_only|implementation|design_only|investigation|writing_only",
"allowed": ["array", "of", "allowed", "actions"],
"forbidden": ["array", "of", "forbidden", "actions"]
}
}
}
```
### **Constraint Enforcement Rules**
**Before responding to any user request, enforce current mode constraints:**
1. **Read current workflow state** from `.cursor/rules/.workflow_state.json`
2. **Identify current mode** and its constraints
3. **Validate user request** against current mode constraints
4. **Enforce constraints** before generating response
5. **Guide model behavior** based on current mode
### **Mode-Specific Enforcement**
**Diagnosis Mode (read_only):**
- ❌ **Forbidden**: File modification, code creation, build commands, git commits
- ✅ **Allowed**: File reading, code analysis, investigation, documentation
- **Response**: Guide user toward investigation and analysis, not implementation
**Fixing Mode (implementation):**
- ✅ **Allowed**: File modification, code creation, build commands, testing, git commits
- ❌ **Forbidden**: None (full implementation mode)
- **Response**: Proceed with implementation and testing
**Planning Mode (design_only):**
- ❌ **Forbidden**: Implementation, coding, building, deployment
- ✅ **Allowed**: Analysis, design, estimation, documentation, architecture
- **Response**: Focus on planning and design, not implementation
**Research Mode (investigation):**
- ❌ **Forbidden**: File modification, implementation, deployment
- ✅ **Allowed**: Investigation, analysis, research, documentation
- **Response**: Focus on investigation and analysis
**Documentation Mode (writing_only):**
- ❌ **Forbidden**: Implementation, coding, building, deployment
- ✅ **Allowed**: Writing, editing, formatting, structuring, reviewing
- **Response**: Focus on documentation creation and improvement
### **Constraint Violation Response**
**If user request violates current mode constraints:**
```
❌ **WORKFLOW CONSTRAINT VIOLATION**
**Current Mode**: [MODE_NAME]
**Requested Action**: [ACTION]
**Constraint Violation**: [DESCRIPTION]
**What You Can Do Instead**:
- [LIST OF ALLOWED ALTERNATIVES]
**To Enable This Action**: Invoke @meta_[appropriate_mode].mdc
```
### **Mode Transition Guidance**
**When user needs to change modes, provide clear guidance:**
```
🔄 **MODE TRANSITION REQUIRED**
**Current Mode**: [CURRENT_MODE]
**Required Mode**: [REQUIRED_MODE]
**Action**: Invoke @meta_[required_mode].mdc
**This will enable**: [DESCRIPTION OF NEW CAPABILITIES]
```
## When to Use
**ALWAYS** - These rules apply to every single prompt, regardless of the task
@ -165,6 +268,8 @@ or context. They form the foundation for all AI assistant behavior.
- [ ] **Time Standards**: Verify UTC and timestamp requirements are clear
- [ ] **Application Context**: Confirm TimeSafari context is loaded
- [ ] **Version Control**: Prepare commit standards if code changes are needed
- [ ] **Workflow State**: Read current mode constraints from state file
- [ ] **Constraint Validation**: Validate user request against current mode
### During Response Creation
@ -172,6 +277,8 @@ or context. They form the foundation for all AI assistant behavior.
- [ ] **Competence Hooks**: Include learning and collaboration elements
- [ ] **Time Consistency**: Apply UTC standards for all time references
- [ ] **Platform Awareness**: Consider all target platforms
- [ ] **Mode Enforcement**: Apply current mode constraints to response
- [ ] **Constraint Violations**: Block forbidden actions and guide alternatives
### After Response Creation
@ -179,6 +286,8 @@ or context. They form the foundation for all AI assistant behavior.
- [ ] **Quality Check**: Ensure response meets competence standards
- [ ] **Context Review**: Confirm application context was properly considered
- [ ] **Feedback Collection**: Note any issues with always-on application
- [ ] **Mode Compliance**: Verify response stayed within current mode constraints
- [ ] **Transition Guidance**: Provide clear guidance for mode changes if needed
---
@ -194,3 +303,9 @@ or context. They form the foundation for all AI assistant behavior.
**Estimated Effort**: Ongoing reference
**Dependencies**: All bundled sub-rules
**Stakeholders**: All AI interactions, Development team
**Dependencies**: All bundled sub-rules
**Stakeholders**: All AI interactions, Development team
**Dependencies**: All bundled sub-rules
**Stakeholders**: All AI interactions, Development team

38
.cursor/rules/meta_documentation.mdc

@ -10,6 +10,44 @@ This meta-rule bundles documentation-related rules to create comprehensive,
educational documentation that increases human competence rather than just
providing technical descriptions.
## Workflow Constraints
**This meta-rule enforces DOCUMENTATION MODE for all bundled sub-rules:**
```json
{
"workflowMode": "documentation",
"constraints": {
"mode": "writing_only",
"allowed": ["write", "edit", "format", "structure", "review"],
"forbidden": ["implement", "code", "build", "deploy"]
}
}
```
**All bundled sub-rules automatically inherit these constraints.**
## Workflow State Update
**When this meta-rule is invoked, update the workflow state file:**
```json
{
"currentMode": "documentation",
"lastInvoked": "meta_documentation.mdc",
"timestamp": "2025-01-27T15:30:00Z",
"constraints": {
"mode": "writing_only",
"allowed": ["write", "edit", "format", "structure", "review"],
"forbidden": ["implement", "code", "build", "deploy"]
}
}
```
**State File Location**: `.cursor/rules/.workflow_state.json`
**This enables the core always-on rule to enforce documentation mode constraints.**
## When to Use
**Use this meta-rule when**:

39
.cursor/rules/meta_feature_implementation.mdc

@ -10,6 +10,45 @@ 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

38
.cursor/rules/meta_feature_planning.mdc

@ -10,6 +10,44 @@ This meta-rule bundles all the rules needed for comprehensive feature planning
across all platforms. Use this when starting any new feature development,
planning sprints, or estimating work effort.
## Workflow Constraints
**This meta-rule enforces PLANNING MODE for all bundled sub-rules:**
```json
{
"workflowMode": "planning",
"constraints": {
"mode": "design_only",
"allowed": ["analyze", "plan", "design", "estimate", "document"],
"forbidden": ["implement", "code", "build", "test", "deploy"]
}
}
```
**All bundled sub-rules automatically inherit these constraints.**
## Workflow State Update
**When this meta-rule is invoked, update the workflow state file:**
```json
{
"currentMode": "planning",
"lastInvoked": "meta_feature_planning.mdc",
"timestamp": "2025-01-27T15:30:00Z",
"constraints": {
"mode": "design_only",
"allowed": ["analyze", "plan", "design", "estimate", "document"],
"forbidden": ["implement", "code", "build", "test", "deploy"]
}
}
```
**State File Location**: `.cursor/rules/.workflow_state.json`
**This enables the core always-on rule to enforce planning mode constraints.**
## When to Use
- **New Feature Development**: Planning features from concept to implementation

38
.cursor/rules/meta_research.mdc

@ -11,6 +11,44 @@ systematic investigation, analysis, evidence collection, or research tasks. It p
a comprehensive framework for thorough, methodical research workflows that produce
actionable insights and evidence-based conclusions.
## Workflow Constraints
**This meta-rule enforces RESEARCH MODE for all bundled sub-rules:**
```json
{
"workflowMode": "research",
"constraints": {
"mode": "investigation",
"allowed": ["read", "search", "analyze", "plan"],
"forbidden": ["modify", "create", "build", "commit"]
}
}
```
**All bundled sub-rules automatically inherit these constraints.**
## Workflow State Update
**When this meta-rule is invoked, update the workflow state file:**
```json
{
"currentMode": "research",
"lastInvoked": "meta_research.mdc",
"timestamp": "2025-01-27T15:30:00Z",
"constraints": {
"mode": "investigation",
"allowed": ["read", "search", "analyze", "plan"],
"forbidden": ["modify", "create", "build", "commit"]
}
}
```
**State File Location**: `.cursor/rules/.workflow_state.json`
**This enables the core always-on rule to enforce research mode constraints.**
## When to Use
**RESEARCH TASKS** - Apply this meta-rule when:

Loading…
Cancel
Save