refactor: restructure cursor rules with new meta-rule architecture
- 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.
This commit is contained in:
75
.cursor/rules/architecture/README.md
Normal file
75
.cursor/rules/architecture/README.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Architecture Rules Directory
|
||||
|
||||
**Author**: Matthew Raymer
|
||||
**Date**: 2025-08-20
|
||||
**Status**: 🎯 **ACTIVE** - Architecture protection guidelines
|
||||
|
||||
## Overview
|
||||
|
||||
This directory contains MDC (Model Directive Configuration) rules that protect
|
||||
critical architectural components of the TimeSafari project. These rules ensure
|
||||
that changes to system architecture follow proper review, testing, and
|
||||
documentation procedures.
|
||||
|
||||
## Available Rules
|
||||
|
||||
### Build Architecture Guard (`build_architecture_guard.mdc`)
|
||||
|
||||
Protects the multi-platform build system including:
|
||||
|
||||
- Vite configuration files
|
||||
- Build scripts and automation
|
||||
- Platform-specific configurations (iOS, Android, Electron, Web)
|
||||
- Docker and deployment infrastructure
|
||||
- CI/CD pipeline components
|
||||
|
||||
**When to use**: Any time you're modifying build scripts, configuration files,
|
||||
or deployment processes.
|
||||
|
||||
**Authorization levels**:
|
||||
|
||||
- **Level 1**: Minor changes (review required)
|
||||
- **Level 2**: Moderate changes (testing required)
|
||||
- **Level 3**: Major changes (ADR required)
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
### For Developers
|
||||
|
||||
1. **Check the rule**: Before making architectural changes, review the relevant
|
||||
rule
|
||||
2. **Follow the process**: Use the appropriate authorization level
|
||||
3. **Complete validation**: Run through the required checklist
|
||||
4. **Update documentation**: Keep BUILDING.md and related docs current
|
||||
|
||||
### For Reviewers
|
||||
|
||||
1. **Verify authorization**: Ensure changes match the required level
|
||||
2. **Check testing**: Confirm appropriate testing has been completed
|
||||
3. **Validate documentation**: Ensure BUILDING.md reflects changes
|
||||
4. **Assess risk**: Consider impact on other platforms and systems
|
||||
|
||||
## Integration with Other Rules
|
||||
|
||||
- **Version Control**: Works with `workflow/version_control.mdc`
|
||||
- **Research & Diagnostic**: Supports `research_diagnostic.mdc` for
|
||||
investigations
|
||||
- **Software Development**: Aligns with development best practices
|
||||
- **Markdown Automation**: Integrates with `docs/markdown-automation.mdc` for
|
||||
consistent documentation formatting
|
||||
|
||||
## Emergency Procedures
|
||||
|
||||
If architectural changes cause system failures:
|
||||
|
||||
1. **Immediate rollback** to last known working state
|
||||
2. **Document the failure** with full error details
|
||||
3. **Investigate root cause** using diagnostic workflows
|
||||
4. **Update procedures** to prevent future failures
|
||||
|
||||
---
|
||||
|
||||
**Status**: Active architecture protection
|
||||
**Priority**: Critical
|
||||
**Maintainer**: Development team
|
||||
**Next Review**: 2025-09-20
|
||||
Reference in New Issue
Block a user