| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 13 | 20 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 2 | 0 | 4 | 33% |
What each file covers
Sections
0 shared · 13 only in A · 20 only in B- − 🔄 Active Context
- − Current Focus
- − Recent Changes
- − Current Challenges
- − Active Decisions
- − Key Patterns & Preferences
- − Code Patterns
- − Architectural Decisions
- − Team Preferences
- − Learnings & Insights
- − Next Steps
- − Open Questions
- − Notes
- + 🏗️ 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
2 shared · 0 only in A · 4 only in B- + security
- + ui
- + performance
- + agent-behaviour
- code-style
- architecture
Line diff
ruvnet/rUv-dev · .clinerules/🔄_activeContext.md
@@ −1 @@
1# 🔄 Active Context
2
3## Current Focus
4The current focus is on integrating the SPARC methodology into the `.clinerules/` folder structure. This includes updating core rule files, enhancing the memory bank system, and ensuring the system supports structured development workflows through the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) approach.
5
6## Recent Changes
7- Integrated SPARC methodology principles into core rule files
8- Enhanced coding standards with SPARC-based modular development guidelines
9- Updated system patterns documentation to reflect SPARC workflow
10- Created visual workflow diagrams for SPARC methodology integration
11- Maintained the existing directory structure while enhancing content
12
13## Current Challenges
14- Ensuring emoji file names work correctly across different file systems
15- Making sure the rule management script is user-friendly and intuitive
16- Balancing comprehensiveness with simplicity in the rule files
17- Ensuring the memory bank system provides sufficient context without overwhelming users
18
19## Active Decisions
20- Using emoji prefixes for memory bank files to make them visually distinct
21- Organizing rules into logical categories (general, code-specific, testing)
22- Using a bash script for rule management rather than a more complex solution
23- Keeping core rule files separate from context-specific rules in the bank
24
25## Key Patterns & Preferences
26
27### Code Patterns
28- Markdown formatting for all rule files
29- Consistent section headings across similar rule files
30- Bullet points for individual rules within sections
31- Descriptive file names that reflect content
32
33### Architectural Decisions
34- Directory-based approach rather than a single file
35- Separation of core rules from context-specific rules
36- Memory bank system for persistent context
37- Command-line tool for rule management
38
39### Team Preferences
40- Preference for clarity and simplicity in rule descriptions
41- Focus on practical, actionable guidelines rather than abstract principles
42- Emphasis on flexibility and contextual activation
43
44## Learnings & Insights
45- The directory structure approach provides much more flexibility than a single file
46- Emoji prefixes make memory bank files more visually distinct and memorable
47- Separating rules by context allows for more focused guidance
48- The management script makes it easier to activate and deactivate rules as needed
49
50## Next Steps
511. Test the rule management script with different rule combinations
522. Expand the rule bank with additional context-specific rule sets
533. Develop integration with the Cline UI for visual rule management
544. Create rule templates for common project types
555. Implement rule versioning and change tracking
56
57## Open Questions
58- How can we best handle rule conflicts when multiple rule files are activated?
59- What's the optimal balance between comprehensive rules and keeping things simple?
60- How can we measure the effectiveness of the new approach compared to the old one?
61
62## Notes
63The current implementation focuses on the core functionality. Future enhancements will include more sophisticated rule management, integration with the Cline UI, and additional rule templates for common project types.
64
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−# 🔄 Active Context
1+# 🏗️ System Patterns
22
3−## Current Focus
4−The current focus is on integrating the SPARC methodology into the `.clinerules/` folder structure. This includes updating core rule files, enhancing the memory bank system, and ensuring the system supports structured development workflows through the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) approach.
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.
55
6−## Recent Changes
7−- Integrated SPARC methodology principles into core rule files
8−- Enhanced coding standards with SPARC-based modular development guidelines
9−- Updated system patterns documentation to reflect SPARC workflow
10−- Created visual workflow diagrams for SPARC methodology integration
11−- Maintained the existing directory structure while enhancing content
6+## SPARC Workflow Integration
7+The system integrates the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) methodology:
128
13−## Current Challenges
14−- Ensuring emoji file names work correctly across different file systems
15−- Making sure the rule management script is user-friendly and intuitive
16−- Balancing comprehensiveness with simplicity in the rule files
17−- Ensuring the memory bank system provides sufficient context without overwhelming users
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+```
1836
19−## Active Decisions
20−- Using emoji prefixes for memory bank files to make them visually distinct
21−- Organizing rules into logical categories (general, code-specific, testing)
22−- Using a bash script for rule management rather than a more complex solution
23−- Keeping core rule files separate from context-specific rules in the bank
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+```
2472
25−## Key Patterns & Preferences
73+## Key Components
2674
27−### Code Patterns
28−- Markdown formatting for all rule files
29−- Consistent section headings across similar rule files
30−- Bullet points for individual rules within sections
31−- Descriptive file names that reflect content
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
3280
33−### Architectural Decisions
34−- Directory-based approach rather than a single file
35−- Separation of core rules from context-specific rules
36−- Memory bank system for persistent context
37−- Command-line tool for rule management
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
3886
39−### Team Preferences
40−- Preference for clarity and simplicity in rule descriptions
41−- Focus on practical, actionable guidelines rather than abstract principles
42−- Emphasis on flexibility and contextual activation
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
4392
44−## Learnings & Insights
45−- The directory structure approach provides much more flexibility than a single file
46−- Emoji prefixes make memory bank files more visually distinct and memorable
47−- Separating rules by context allows for more focused guidance
48−- The management script makes it easier to activate and deactivate rules as needed
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
4998
50−## Next Steps
51−1. Test the rule management script with different rule combinations
52−2. Expand the rule bank with additional context-specific rule sets
53−3. Develop integration with the Cline UI for visual rule management
54−4. Create rule templates for common project types
55−5. Implement rule versioning and change tracking
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
56104
57−## Open Questions
58−- How can we best handle rule conflicts when multiple rule files are activated?
59−- What's the optimal balance between comprehensive rules and keeping things simple?
60−- How can we measure the effectiveness of the new approach compared to the old one?
105+## Design Patterns
61106
62−## Notes
63−The current implementation focuses on the core functionality. Future enhancements will include more sophisticated rule management, integration with the Cline UI, and additional rule templates for common project types.
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
64189
