eff7e339af
- 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.
76 lines
2.4 KiB
Markdown
76 lines
2.4 KiB
Markdown
# 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
|