chore: update .cursor rules for workflow state
This commit is contained in:
@@ -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_diagnosis.mdc`** - Bug investigation workflow bundling
|
||||||
- **`meta_bug_fixing.mdc`** - Bug fix implementation workflow bundling
|
- **`meta_bug_fixing.mdc`** - Bug fix implementation workflow bundling
|
||||||
- **`meta_feature_implementation.mdc`** - Feature 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
|
## Usage Guidelines
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user