| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 13 | 6 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 3 | 0% |
What each file covers
Sections
0 shared · 13 only in A · 6 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
- + 🏃 Current Sprint Guidelines
- + SPARC Implementation Focus
- + Focus Areas
- + Code Review Criteria
- + Technical Debt
- + Documentation
Commands
neither file has anySection tags
0 shared · 2 only in A · 3 only in B- − code-style
- − architecture
- + testing-strategy
- + git-pr
- + 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/🏃_current-sprint.md
@@ +1 @@
1# 🏃 Current Sprint Guidelines
2
3## SPARC Implementation Focus
4
5- Apply SPARC methodology to all new development tasks
6- Break down complex features into SPARC workflow phases
7- Use subtasks for each SPARC phase when appropriate
8- Ensure all code follows SPARC modular architecture principles
9
10## Focus Areas
11
12- Prioritize bug fixes for the user authentication system
13- Implement new features for the reporting dashboard
14- Improve test coverage for core modules
15- Refactor the data processing pipeline for better performance
16- Ensure all files remain under 500 lines with clear modular boundaries
17
18## Code Review Criteria
19
20- All new code must have corresponding tests
21- Performance impact must be documented for any changes to critical paths
22- Security implications must be reviewed for authentication-related changes
23- UI changes must be tested on all supported browsers
24- Verify no environment variables or secrets are hardcoded
25- Confirm proper error handling in all code paths
26- Check that functions follow single responsibility principle
27
28## Technical Debt
29
30- Identify and document technical debt as you encounter it
31- Allocate time for addressing critical technical debt items
32- Refactor code that doesn't meet our current standards when modifying it
33- Split files exceeding 500 lines into logical modules
34
35## Documentation
36
37- Update API documentation for any changed endpoints
38- Document any new configuration options
39- Update the developer setup guide with new dependencies
40- Auto-document each feature with clear examples
41- Include SPARC phase documentation for complex features
42
@@ −1 +1 @@
1−# 🔄 Active Context
1+# 🏃 Current Sprint Guidelines
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 Implementation Focus
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+- Apply SPARC methodology to all new development tasks
6+- Break down complex features into SPARC workflow phases
7+- Use subtasks for each SPARC phase when appropriate
8+- Ensure all code follows SPARC modular architecture principles
129
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
10+## Focus Areas
1811
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
12+- Prioritize bug fixes for the user authentication system
13+- Implement new features for the reporting dashboard
14+- Improve test coverage for core modules
15+- Refactor the data processing pipeline for better performance
16+- Ensure all files remain under 500 lines with clear modular boundaries
2417
25−## Key Patterns & Preferences
18+## Code Review Criteria
2619
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
20+- All new code must have corresponding tests
21+- Performance impact must be documented for any changes to critical paths
22+- Security implications must be reviewed for authentication-related changes
23+- UI changes must be tested on all supported browsers
24+- Verify no environment variables or secrets are hardcoded
25+- Confirm proper error handling in all code paths
26+- Check that functions follow single responsibility principle
3227
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
28+## Technical Debt
3829
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
30+- Identify and document technical debt as you encounter it
31+- Allocate time for addressing critical technical debt items
32+- Refactor code that doesn't meet our current standards when modifying it
33+- Split files exceeding 500 lines into logical modules
4334
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
35+## Documentation
4936
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
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
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.
37+- Update API documentation for any changed endpoints
38+- Document any new configuration options
39+- Update the developer setup guide with new dependencies
40+- Auto-document each feature with clear examples
41+- Include SPARC phase documentation for complex features
6442
