| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 13 | 38 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 8 | 0% |
What each file covers
Sections
0 shared · 13 only in A · 38 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
- + ⚙️ Technical Context
- + SPARC Development Methodology
- + Technical Requirements
- + Technology Stack
- + Frontend
- + Backend
- + Infrastructure
- + Development Environment
- + Required Tools
- + Setup Instructions
- + Setup commands
- + Local Development Workflow
- + External Dependencies
- + APIs
- + Third-party Services
- + Libraries and Frameworks
- + Technical Constraints
- + Performance Requirements
- + Security Requirements
- + Compatibility Requirements
- + Technical Debt
- + Known Issues
- + Planned Refactoring
- + Testing Strategy
- + SPARC Testing Approach
- + Unit Testing
- + Integration Testing
- + End-to-End Testing
- + Deployment Process
- + Environments
- + Deployment Steps
- + Rollback Procedure
- + Monitoring and Observability
- + Key Metrics
- + Alerting
- + Documentation Resources
- + Internal Documentation
- + External Documentation
Commands
neither file has anySection tags
0 shared · 2 only in A · 8 only in B- − code-style
- − architecture
- + setup
- + test
- + testing-strategy
- + security
- + dependencies
- + performance
- + agent-behaviour
- + docs
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/⚙️_techContext.md
@@ +1 @@
1# ⚙️ Technical Context
2
3## SPARC Development Methodology
4
5The project follows the SPARC methodology for structured development:
6
71. **Specification**: Define requirements, constraints, and acceptance criteria
82. **Pseudocode**: Develop high-level logic with TDD anchors
93. **Architecture**: Design modular components with clear interfaces
104. **Refinement**: Implement with TDD, debugging, and optimization
115. **Completion**: Integrate, document, test, and verify against criteria
12
13### Technical Requirements
14- Files must not exceed 500 lines
15- Functions must follow single responsibility principle
16- No hardcoded environment variables or secrets
17- All code must include proper error handling
18- Modular architecture with clear component boundaries
19- Comprehensive test coverage for critical functionality
20
21## Technology Stack
22
23### Frontend
24- [Frontend framework/library]
25- [UI component library]
26- [State management solution]
27- [CSS approach/framework]
28- [Build tools]
29
30### Backend
31- [Backend language/framework]
32- [API architecture]
33- [Database technology]
34- [Authentication system]
35- [Caching strategy]
36
37### Infrastructure
38- [Hosting platform]
39- [CI/CD pipeline]
40- [Containerization]
41- [Monitoring tools]
42- [Logging system]
43
44## Development Environment
45
46### Required Tools
47- [Tool 1 and version]
48- [Tool 2 and version]
49- [Tool 3 and version]
50
51### Setup Instructions
52```bash
53# Setup commands
54```
55
56### Local Development Workflow
571. [Step 1]
582. [Step 2]
593. [Step 3]
60
61## External Dependencies
62
63### APIs
64- [API 1]: [Purpose and usage]
65- [API 2]: [Purpose and usage]
66
67### Third-party Services
68- [Service 1]: [Purpose and integration details]
69- [Service 2]: [Purpose and integration details]
70
71### Libraries and Frameworks
72- [Library 1]: [Purpose and usage]
73- [Library 2]: [Purpose and usage]
74
75## Technical Constraints
76
77### Performance Requirements
78- [Requirement 1]
79- [Requirement 2]
80
81### Security Requirements
82- No hardcoded secrets, credentials, or environment variables
83- All user inputs must be validated and sanitized
84- Proper error handling to prevent information leakage
85- Secure coding practices following OWASP guidelines
86- Regular security audits of dependencies
87
88### Compatibility Requirements
89- [Requirement 1]
90- [Requirement 2]
91
92## Technical Debt
93
94### Known Issues
95- [Issue 1]: [Impact and potential resolution]
96- [Issue 2]: [Impact and potential resolution]
97
98### Planned Refactoring
99- [Refactoring 1]: [Reason and approach]
100- [Refactoring 2]: [Reason and approach]
101
102## Testing Strategy
103
104### SPARC Testing Approach
105- Test-Driven Development (TDD) for all new features
106- Tests written during Pseudocode phase before implementation
107- Comprehensive test coverage for critical functionality
108- Automated testing integrated into CI/CD pipeline
109
110### Unit Testing
111- Test individual components in isolation
112- Mock dependencies for pure unit testing
113- Aim for >80% code coverage on critical paths
114- Focus on edge cases and error handling
115
116### Integration Testing
117- Test component interactions and interfaces
118- Verify correct data flow between modules
119- Test API contracts and boundaries
120- Ensure proper error propagation
121
122### End-to-End Testing
123- [Framework and approach]
124- [Critical user flows to test]
125
126## Deployment Process
127
128### Environments
129- Development: [Details]
130- Staging: [Details]
131- Production: [Details]
132
133### Deployment Steps
1341. [Step 1]
1352. [Step 2]
1363. [Step 3]
137
138### Rollback Procedure
1391. [Step 1]
1402. [Step 2]
1413. [Step 3]
142
143## Monitoring and Observability
144
145### Key Metrics
146- [Metric 1]: [What it measures and thresholds]
147- [Metric 2]: [What it measures and thresholds]
148
149### Alerting
150- [Alert 1]: [Trigger conditions and response]
151- [Alert 2]: [Trigger conditions and response]
152
153## Documentation Resources
154
155### Internal Documentation
156- [Link or location 1]: [Description]
157- [Link or location 2]: [Description]
158
159### External Documentation
160- [Link 1]: [Description]
161- [Link 2]: [Description]
162
@@ −1 +1 @@
1−# 🔄 Active Context
1+# ⚙️ Technical Context
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+## SPARC Development Methodology
54
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
5+The project follows the SPARC methodology for structured development:
126
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
7+1. **Specification**: Define requirements, constraints, and acceptance criteria
8+2. **Pseudocode**: Develop high-level logic with TDD anchors
9+3. **Architecture**: Design modular components with clear interfaces
10+4. **Refinement**: Implement with TDD, debugging, and optimization
11+5. **Completion**: Integrate, document, test, and verify against criteria
1812
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
13+### Technical Requirements
14+- Files must not exceed 500 lines
15+- Functions must follow single responsibility principle
16+- No hardcoded environment variables or secrets
17+- All code must include proper error handling
18+- Modular architecture with clear component boundaries
19+- Comprehensive test coverage for critical functionality
2420
25−## Key Patterns & Preferences
21+## Technology Stack
2622
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
23+### Frontend
24+- [Frontend framework/library]
25+- [UI component library]
26+- [State management solution]
27+- [CSS approach/framework]
28+- [Build tools]
3229
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
30+### Backend
31+- [Backend language/framework]
32+- [API architecture]
33+- [Database technology]
34+- [Authentication system]
35+- [Caching strategy]
3836
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
37+### Infrastructure
38+- [Hosting platform]
39+- [CI/CD pipeline]
40+- [Containerization]
41+- [Monitoring tools]
42+- [Logging system]
4343
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
44+## Development Environment
4945
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
46+### Required Tools
47+- [Tool 1 and version]
48+- [Tool 2 and version]
49+- [Tool 3 and version]
5650
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?
51+### Setup Instructions
52+```bash
53+# Setup commands
54+```
6155
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.
56+### Local Development Workflow
57+1. [Step 1]
58+2. [Step 2]
59+3. [Step 3]
60+
61+## External Dependencies
62+
63+### APIs
64+- [API 1]: [Purpose and usage]
65+- [API 2]: [Purpose and usage]
66+
67+### Third-party Services
68+- [Service 1]: [Purpose and integration details]
69+- [Service 2]: [Purpose and integration details]
70+
71+### Libraries and Frameworks
72+- [Library 1]: [Purpose and usage]
73+- [Library 2]: [Purpose and usage]
74+
75+## Technical Constraints
76+
77+### Performance Requirements
78+- [Requirement 1]
79+- [Requirement 2]
80+
81+### Security Requirements
82+- No hardcoded secrets, credentials, or environment variables
83+- All user inputs must be validated and sanitized
84+- Proper error handling to prevent information leakage
85+- Secure coding practices following OWASP guidelines
86+- Regular security audits of dependencies
87+
88+### Compatibility Requirements
89+- [Requirement 1]
90+- [Requirement 2]
91+
92+## Technical Debt
93+
94+### Known Issues
95+- [Issue 1]: [Impact and potential resolution]
96+- [Issue 2]: [Impact and potential resolution]
97+
98+### Planned Refactoring
99+- [Refactoring 1]: [Reason and approach]
100+- [Refactoring 2]: [Reason and approach]
101+
102+## Testing Strategy
103+
104+### SPARC Testing Approach
105+- Test-Driven Development (TDD) for all new features
106+- Tests written during Pseudocode phase before implementation
107+- Comprehensive test coverage for critical functionality
108+- Automated testing integrated into CI/CD pipeline
109+
110+### Unit Testing
111+- Test individual components in isolation
112+- Mock dependencies for pure unit testing
113+- Aim for >80% code coverage on critical paths
114+- Focus on edge cases and error handling
115+
116+### Integration Testing
117+- Test component interactions and interfaces
118+- Verify correct data flow between modules
119+- Test API contracts and boundaries
120+- Ensure proper error propagation
121+
122+### End-to-End Testing
123+- [Framework and approach]
124+- [Critical user flows to test]
125+
126+## Deployment Process
127+
128+### Environments
129+- Development: [Details]
130+- Staging: [Details]
131+- Production: [Details]
132+
133+### Deployment Steps
134+1. [Step 1]
135+2. [Step 2]
136+3. [Step 3]
137+
138+### Rollback Procedure
139+1. [Step 1]
140+2. [Step 2]
141+3. [Step 3]
142+
143+## Monitoring and Observability
144+
145+### Key Metrics
146+- [Metric 1]: [What it measures and thresholds]
147+- [Metric 2]: [What it measures and thresholds]
148+
149+### Alerting
150+- [Alert 1]: [Trigger conditions and response]
151+- [Alert 2]: [Trigger conditions and response]
152+
153+## Documentation Resources
154+
155+### Internal Documentation
156+- [Link or location 1]: [Description]
157+- [Link or location 2]: [Description]
158+
159+### External Documentation
160+- [Link 1]: [Description]
161+- [Link 2]: [Description]
64162
