Skip to content

Commit e28196d

Browse files
ruvnetruvnet
authored
Merge pull request #12 from ruvnet/may-3-2025
May 3 2025
2 parents d19b26f + f373a12 commit e28196d

File tree

79 files changed

+8599
-25
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

79 files changed

+8599
-25
lines changed

‎.clinerules/rules-code/👨‍💻_code_guidelines.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
# 👨‍💻 Code Guidelines
2+
3+
## Naming Conventions
4+
5+
- Use camelCase for variables and functions in JavaScript/TypeScript
6+
- Use PascalCase for classes and component names
7+
- Use snake_case for variables and functions in Python
8+
- Use UPPER_SNAKE_CASE for constants
9+
- Choose descriptive names that reflect purpose
10+
11+
## Function Design
12+
13+
- Functions should do one thing and do it well
14+
- Keep functions short (generally under 30 lines)
15+
- Limit the number of parameters (prefer objects for multiple parameters)
16+
- Use meaningful parameter names
17+
- Return early to avoid deep nesting
18+
- Document complex functions with JSDoc or similar
19+
20+
## Error Handling
21+
22+
- Never silently catch errors without proper handling
23+
- Use specific error types when possible
24+
- Provide meaningful error messages
25+
- Log errors with appropriate context
26+
- Consider retry mechanisms for transient failures
27+
- Clean up resources in finally blocks or equivalent
28+
29+
## Testing
30+
31+
- Write unit tests for business logic
32+
- Use integration tests for API endpoints
33+
- Test edge cases and error conditions
34+
- Keep tests independent and idempotent
35+
- Use meaningful test descriptions
36+
- Maintain test coverage for critical paths

‎.clinerules/rules/🧭_general_guidelines.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# 🧭 General Guidelines
2+
3+
## Project Approach
4+
5+
- Understand the project requirements before starting implementation
6+
- Break down complex tasks into smaller, manageable pieces
7+
- Communicate any blockers or issues promptly
8+
- Follow the established git workflow for the project
9+
- Regularly update task tracking with progress
10+
11+
## Collaboration
12+
13+
- Write clear commit messages that explain the purpose of changes
14+
- Document decisions and their rationale
15+
- Share knowledge with team members
16+
- Be open to feedback and code reviews
17+
- Respect coding standards and project conventions
18+
19+
## Quality Assurance
20+
21+
- Test your changes thoroughly before submitting for review
22+
- Consider edge cases and error scenarios
23+
- Validate inputs and handle errors gracefully
24+
- Monitor performance impacts of your changes
25+
- Ensure backward compatibility unless explicitly breaking changes are approved

‎.clinerules/tests/🧪_testing_guidelines.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# 🧪 Testing Guidelines
2+
3+
## Unit Testing
4+
5+
- Write tests for individual functions and components
6+
- Focus on testing behavior, not implementation details
7+
- Use mocks and stubs for external dependencies
8+
- Keep tests fast and independent
9+
- Follow the AAA pattern (Arrange, Act, Assert)
10+
11+
## Integration Testing
12+
13+
- Test interactions between components
14+
- Focus on critical paths and user flows
15+
- Use realistic test data
16+
- Consider edge cases and error scenarios
17+
- Test both success and failure paths
18+
19+
## End-to-End Testing
20+
21+
- Test complete user journeys
22+
- Focus on critical business flows
23+
- Use realistic test environments
24+
- Minimize test flakiness
25+
- Balance coverage with execution time
26+
27+
## Test Organization
28+
29+
- Group tests logically by feature or component
30+
- Use descriptive test names that explain the expected behavior
31+
- Organize test files to mirror the structure of the code being tested
32+
- Separate test utilities and helpers into their own modules
33+
34+
## Test Data Management
35+
36+
- Use factories or builders for test data
37+
- Avoid hardcoding test data
38+
- Clean up test data after tests run
39+
- Use realistic but anonymized data for integration and E2E tests

‎.clinerules/⚙️_techContext.md

Lines changed: 161 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,161 @@
1+
# ⚙️ Technical Context
2+
3+
## SPARC Development Methodology
4+
5+
The project follows the SPARC methodology for structured development:
6+
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
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
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]

‎.clinerules/🏃_current-sprint.md

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
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

0 commit comments

Comments
 (0)