@ -104,6 +104,161 @@ High-level meta-rules that bundle related sub-rules for specific workflows.
- ** `meta_bug_diagnosis.mdc` ** - Bug investigation workflow bundling
- ** `meta_bug_fixing.mdc` ** - Bug fix implementation workflow bundling
- ** `meta_feature_implementation.mdc` ** - Feature implementation workflow bundling
- ** `meta_research.mdc` ** - Investigation and research workflow bundling
### **Workflow State Management**
The project uses a sophisticated workflow state management system to ensure systematic development processes and maintain code quality across all phases of development.
#### **Workflow State System**
The workflow state is managed through `.cursor/rules/.workflow_state.json` and enforces different modes with specific constraints. The system automatically tracks workflow progression and maintains a complete history of mode transitions.
**Available Modes**:
- ** `diagnosis` ** - Investigation and analysis phase (read-only)
- ** `fixing` ** - Implementation and bug fixing phase (full access)
- ** `planning` ** - Design and architecture phase (design only)
- ** `research` ** - Investigation and research phase (investigation only)
- ** `documentation` ** - Documentation writing phase (writing only)
**Mode Constraints**:
```json
{
"diagnosis": {
"mode": "read_only",
"forbidden": ["modify", "create", "build", "commit"],
"allowed": ["read", "search", "analyze", "document"]
},
"fixing": {
"mode": "implementation",
"forbidden": [],
"allowed": ["modify", "create", "build", "commit", "test"]
}
}
```
**Workflow History Tracking**:
The system automatically maintains a `workflowHistory` array that records all mode transitions and meta-rule invocations:
```json
{
"workflowHistory": [
{
"mode": "research",
"invoked": "meta_core_always_on.mdc",
"timestamp": "2025-08-25T02:14:37Z"
},
{
"mode": "diagnosis",
"invoked": "meta_bug_diagnosis.mdc",
"timestamp": "2025-08-25T02:14:37Z"
}
]
}
```
**History Entry Format**:
- ** `mode` **: The workflow mode that was activated
- ** `invoked` **: The specific meta-rule that triggered the mode change
- ** `timestamp` **: UTC timestamp when the mode transition occurred
**History Purpose**:
- **Workflow Continuity** : Track progression through development phases
- **Meta-Rule Usage** : Monitor which rules are invoked and when
- **Temporal Context** : Maintain chronological order of workflow changes
- **State Persistence** : Preserve workflow history across development sessions
- **Debugging Support** : Help diagnose workflow state issues
- **Process Analysis** : Understand development patterns and meta-rule effectiveness
#### **Commit Override System**
The workflow includes a flexible commit override mechanism that allows commits on demand while maintaining workflow integrity:
```json
{
"overrides": {
"commit": {
"allowed": true,
"requires_override": true,
"override_reason": "user_requested"
}
}
}
```
**Override Benefits**:
- ✅ **Investigation Commits** : Document findings during diagnosis phases
- ✅ **Work-in-Progress** : Commit partial solutions during complex investigations
- ✅ **Emergency Fixes** : Commit critical fixes without mode transitions
- ✅ **Flexible Workflow** : Maintain systematic approach while accommodating real needs
**Override Limitations**:
- ❌ **Does NOT bypass** : Version control rules, commit message standards, or security requirements
- ❌ **Does NOT bypass** : Code quality standards, testing requirements, or documentation requirements
#### **Workflow Enforcement**
The system automatically enforces workflow constraints through the core always-on rules:
**Before Every Interaction**:
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** : Blocks modification, creation, building, and commits
- **Fixing Mode** : Allows full implementation and testing capabilities
- **Planning Mode** : Focuses on design and architecture, blocks implementation
- **Research Mode** : Enables investigation and analysis, blocks modification
- **Documentation Mode** : Allows writing and editing, blocks implementation
#### **Workflow Transitions**
To change workflow modes, invoke the appropriate meta-rule:
```bash
# Switch to bug fixing mode
@meta_bug_fixing .mdc
# Switch to feature planning mode
@meta_feature_planning .mdc
# Switch to documentation mode
@meta_documentation .mdc
```
**Transition Requirements**:
- **Mode Changes** : Require explicit meta-rule invocation
- **State Updates** : Automatically update workflow state file
- **Constraint Enforcement** : Immediately apply new mode constraints
- **History Tracking** : Automatically maintained in `workflowHistory` array
- **Timestamp Recording** : Each transition recorded with UTC timestamp
#### **Integration with Development Process**
The workflow system integrates seamlessly with existing development practices:
**Version Control**:
- All commits must follow TimeSafari commit message standards
- Security audit checklists are enforced regardless of workflow mode
- Documentation updates are required for substantial changes
**Quality Assurance**:
- Code quality standards (PEP8, TypeScript, etc.) are always enforced
- Testing requirements apply to all implementation work
- Documentation standards are maintained across all phases
**Build System**:
- Build Architecture Guard protects critical build files
- Platform-specific build processes respect workflow constraints
- Asset generation follows established patterns
**Migration Context**:
- Database migration work respects investigation vs. implementation phases
- Component migration progress is tracked through workflow states
## Usage Guidelines
Matthew Raymer
2 weeks ago