| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 5 | 38 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 0 | 7 | 13% |
What each file covers
Sections
0 shared · 5 only in A · 38 only in B- − 📚 Documentation Requirements
- − SPARC Documentation Principles
- − Code Documentation
- − Project Documentation
- − Comments
- + ⚙️ 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
1 shared · 0 only in A · 7 only in B- + setup
- + test
- + testing-strategy
- + security
- + dependencies
- + performance
- + agent-behaviour
- docs
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/⚙️_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−# 📚 Documentation Requirements
1+# ⚙️ Technical Context
22
3−## SPARC Documentation Principles
3+## SPARC Development Methodology
44
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
5+The project follows the SPARC methodology for structured development:
106
11−## Code Documentation
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
1212
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
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
2020
21−## Project Documentation
21+## Technology Stack
2222
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
23+### Frontend
24+- [Frontend framework/library]
25+- [UI component library]
26+- [State management solution]
27+- [CSS approach/framework]
28+- [Build tools]
3029
31−## Comments
30+### Backend
31+- [Backend language/framework]
32+- [API architecture]
33+- [Database technology]
34+- [Authentication system]
35+- [Caching strategy]
3236
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
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
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]
38162
