Cline rules

1# 🏗️ System Patterns
2 
3## Architecture Overview
4The clinerules system uses a modular directory structure to organize rules and guidelines for Cline to follow when working with projects, incorporating the SPARC methodology for structured development.
5 
6## SPARC Workflow Integration
7The system integrates the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) methodology:
8 
9```mermaid
10flowchart TD
11    S[Specification] --> P[Pseudocode]
12    P --> A[Architecture]
13    A --> R[Refinement]
14    R --> C[Completion]
15    
16    S --> S1[Define requirements]
17    S --> S2[Identify constraints]
18    S --> S3[Set acceptance criteria]
19    
20    P --> P1[Develop high-level logic]
21    P --> P2[Identify core functions]
22    P --> P3[Create TDD anchors]
23    
24    A --> A1[Design components]
25    A --> A2[Define interfaces]
26    A --> A3[Establish boundaries]
27    
28    R --> R1[Implement with TDD]
29    R --> R2[Debug and optimize]
30    R --> R3[Refactor for maintainability]
31    
32    C --> C1[Integrate components]
33    C --> C2[Document thoroughly]
34    C --> C3[Verify against criteria]
35```
36 
37```mermaid
38flowchart TD
39    A[.clinerules/] --> B[Core Rule Files]
40    A --> C[Memory Bank Files]
41    A --> D[Subdirectories]
42    
43    B --> B1[💻_01-coding.md]
44    B --> B2[📚_02-documentation.md]
45    B --> B3[🏃_current-sprint.md]
46    B --> B4[📖_README.md]
47    
48    C --> C1[🧠_memory-bank.md]
49    C --> C2[📋_projectbrief.md]
50    C --> C3[🔍_productContext.md]
51    C --> C4[🔄_activeContext.md]
52    C --> C5[🏗️_systemPatterns.md]
53    C --> C6[⚙️_techContext.md]
54    C --> C7[📊_progress.md]
55    
56    D --> D1[rules/]
57    D --> D2[rules-code/]
58    D --> D3[tests/]
59    
60    D1 --> D1A[🧭_general_guidelines.md]
61    D2 --> D2A[👨‍💻_code_guidelines.md]
62    D3 --> D3A[🧪_testing_guidelines.md]
63    
64    E[clinerules-bank/] --> E1[clients/]
65    E --> E2[frameworks/]
66    E --> E3[project-types/]
67    E --> E4[orchestration/]
68    E --> E5[docs/]
69    E --> E6[manage-rules.sh]
70    E --> E7[README.md]
71```
72 
73## Key Components
74 
75### Component 1: Core Rule Files
76- **Purpose**: Provide foundational guidelines that apply to all projects
77- **Responsibilities**: Define coding standards, documentation requirements, and current sprint focus
78- **Interfaces**: Read by Cline directly from the `.clinerules/` directory
79- **Implementation Details**: Markdown files with clear sections and bullet points
80 
81### Component 2: Memory Bank Files
82- **Purpose**: Provide persistent memory between Cline sessions
83- **Responsibilities**: Store project context, technical details, and current status
84- **Interfaces**: Read by Cline at the start of each session
85- **Implementation Details**: Markdown files with emoji prefixes for visual distinction
86 
87### Component 3: Subdirectories
88- **Purpose**: Organize rules by category
89- **Responsibilities**: Separate general guidelines, code-specific rules, and testing guidelines
90- **Interfaces**: Files within subdirectories are read by Cline
91- **Implementation Details**: Directory structure with descriptive names
92 
93### Component 4: Rule Bank
94- **Purpose**: Store additional rule sets that can be activated as needed
95- **Responsibilities**: Provide context-specific rules for different clients, frameworks, and project types
96- **Interfaces**: Files are copied to the `.clinerules/` directory when activated
97- **Implementation Details**: Organized directory structure with categorized rule files
98 
99### Component 5: Rule Management Script
100- **Purpose**: Manage the activation and deactivation of rules
101- **Responsibilities**: List available rules, activate/deactivate rules, backup/restore rules
102- **Interfaces**: Command-line interface for users
103- **Implementation Details**: Bash script with clear commands and feedback
104 
105## Design Patterns
106 
107### Pattern 1: Modular Organization
108- **Usage**: Throughout the system for organizing rules
109- **Implementation**: Directory structure with logical categories
110- **Benefits**: Easier maintenance, contextual activation, reduced noise
111 
112### Pattern 2: Memory Bank
113- **Usage**: For persistent context between sessions
114- **Implementation**: Emoji-prefixed files with structured content
115- **Benefits**: Ensures Cline maintains context across interactions
116 
117### Pattern 3: Rule Activation
118- **Usage**: For selectively applying rules
119- **Implementation**: Copy files from bank to active directory
120- **Benefits**: Contextual application of rules, reduced cognitive load
121 
122## Data Flow
123 
124```mermaid
125sequenceDiagram
126    participant User
127    participant Script as manage-rules.sh
128    participant Bank as clinerules-bank/
129    participant Active as .clinerules/
130    participant Cline
131    
132    User->>Script: List available rules
133    Script->>Bank: Read rule files
134    Bank-->>Script: Return file list
135    Script-->>User: Display available rules
136    
137    User->>Script: Activate rule
138    Script->>Bank: Get rule file
139    Bank-->>Script: Return file content
140    Script->>Active: Copy file
141    Script-->>User: Confirm activation
142    
143    User->>Cline: Start interaction
144    Cline->>Active: Read all rule files
145    Active-->>Cline: Return rule content
146    Cline-->>User: Apply rules in responses
147```
148 
149## Critical Paths
150 
1511. **Rule Activation Path**: User → Script → Bank → Active → Cline
152   - Critical for ensuring the right rules are applied
153   - Potential failure points: file system permissions, emoji handling
154 
1552. **Memory Bank Reading Path**: User → Cline → Memory Bank Files
156   - Critical for maintaining context between sessions
157   - Potential failure points: missing files, incomplete information
158 
159## Error Handling Strategy
160 
161- File system errors are reported with clear error messages
162- Missing files trigger appropriate warnings
163- User confirmation is required for destructive operations
164- Backup functionality allows for recovery from errors
165 
166## Performance Considerations
167 
168- Rule files are kept small and focused to minimize processing time
169- Directory structure is shallow to reduce traversal time
170- Memory bank files use a consistent structure for efficient parsing
171 
172## Security Model
173 
174- No sensitive information should be stored in rule files
175- Script operations are limited to the `.clinerules/` and `clinerules-bank/` directories
176- User confirmation is required for potentially destructive operations
177 
178## Integration Points
179 
180- Cline reads rules from the `.clinerules/` directory
181- The management script interacts with both the bank and active directories
182- Future integration with Cline UI for visual rule management
183 
184## Technical Debt
185 
186- Emoji file naming might cause issues in some file systems
187- Script error handling could be more robust
188- No versioning system for rule files yet
189