| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 5 | 20 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 1 | 6 | 0% |
What each file covers
Sections
0 shared · 5 only in A · 20 only in B- − 📚 Documentation Requirements
- − SPARC Documentation Principles
- − Code Documentation
- − Project Documentation
- − Comments
- + 🏗️ System Patterns
- + Architecture Overview
- + SPARC Workflow Integration
- + Key Components
- + Component 1: Core Rule Files
- + Component 2: Memory Bank Files
- + Component 3: Subdirectories
- + Component 4: Rule Bank
- + Component 5: Rule Management Script
- + Design Patterns
- + Pattern 1: Modular Organization
- + Pattern 2: Memory Bank
- + Pattern 3: Rule Activation
- + Data Flow
- + Critical Paths
- + Error Handling Strategy
- + Performance Considerations
- + Security Model
- + Integration Points
- + Technical Debt
Commands
neither file has anySection tags
0 shared · 1 only in A · 6 only in B- − docs
- + code-style
- + architecture
- + security
- + ui
- + performance
- + agent-behaviour
Line diff
ruvnet/rUv-dev · .clinerules/📚_02-documentation.md
@@ −1 @@
1# 📚 Documentation Requirements
2
3## SPARC Documentation Principles
4
5- **Specification**: Document requirements, constraints, and acceptance criteria
6- **Pseudocode**: Document high-level logic and core functions before implementation
7- **Architecture**: Document component relationships, interfaces, and boundaries
8- **Refinement**: Document optimization decisions and refactoring rationale
9- **Completion**: Verify documentation against implementation and acceptance criteria
10
11## Code Documentation
12
13- Document public APIs with clear descriptions of parameters, return values, and exceptions
14- Include examples where appropriate
15- Keep documentation up-to-date with code changes
16- Document complex algorithms or business logic
17- Add TODO comments for incomplete features or known issues
18- Auto-document every feature with clear purpose and usage examples
19- Document environment variable requirements without hardcoding values
20
21## Project Documentation
22
23- Maintain a clear README with project overview, setup instructions, and usage examples
24- Document architecture decisions and system design
25- Keep a changelog of significant changes
26- Document environment requirements and dependencies
27- Include troubleshooting guides for common issues
28- Document modular structure and component relationships
29- Include diagrams for complex workflows and architectures
30
31## Comments
32
33- Use comments to explain "why" rather than "what" when the code isn't self-explanatory
34- Keep comments concise and relevant
35- Update comments when the corresponding code changes
36- Use standardized comment formats for documentation generation tools if applicable
37- Document security considerations and validation requirements
38
ruvnet/rUv-dev · .clinerules/🏗️_systemPatterns.md
@@ +1 @@
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
@@ −1 +1 @@
1−# 📚 Documentation Requirements
1+# 🏗️ System Patterns
22
3−## SPARC Documentation Principles
3+## Architecture Overview
4+The 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.
45
5−- **Specification**: Document requirements, constraints, and acceptance criteria
6−- **Pseudocode**: Document high-level logic and core functions before implementation
7−- **Architecture**: Document component relationships, interfaces, and boundaries
8−- **Refinement**: Document optimization decisions and refactoring rationale
9−- **Completion**: Verify documentation against implementation and acceptance criteria
6+## SPARC Workflow Integration
7+The system integrates the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) methodology:
108
11−## Code Documentation
9+```mermaid
10+flowchart 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+```
1236
13−- Document public APIs with clear descriptions of parameters, return values, and exceptions
14−- Include examples where appropriate
15−- Keep documentation up-to-date with code changes
16−- Document complex algorithms or business logic
17−- Add TODO comments for incomplete features or known issues
18−- Auto-document every feature with clear purpose and usage examples
19−- Document environment variable requirements without hardcoding values
37+```mermaid
38+flowchart 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+```
2072
21−## Project Documentation
73+## Key Components
2274
23−- Maintain a clear README with project overview, setup instructions, and usage examples
24−- Document architecture decisions and system design
25−- Keep a changelog of significant changes
26−- Document environment requirements and dependencies
27−- Include troubleshooting guides for common issues
28−- Document modular structure and component relationships
29−- Include diagrams for complex workflows and architectures
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
3080
31−## Comments
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
3286
33−- Use comments to explain "why" rather than "what" when the code isn't self-explanatory
34−- Keep comments concise and relevant
35−- Update comments when the corresponding code changes
36−- Use standardized comment formats for documentation generation tools if applicable
37−- Document security considerations and validation requirements
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
125+sequenceDiagram
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+
151+1. **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+
155+2. **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
38189
