From 83fb4441969b38220e1a49e3788325bf6eae5a1f Mon Sep 17 00:00:00 2001 From: glenn schrooyen Date: Thu, 11 Sep 2025 23:51:00 +0200 Subject: [PATCH] Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements --- .cursor/rules/api-standards.mdc | 81 +++------ .cursor/rules/code-quality.mdc | 114 +++---------- .cursor/rules/documentation-standards.mdc | 88 +++------- .cursor/rules/frontend-standards.mdc | 109 +++--------- .cursor/rules/project-structure.mdc | 120 ++++--------- AGENTS.md | 195 ++++++---------------- 6 files changed, 177 insertions(+), 530 deletions(-) diff --git a/.cursor/rules/api-standards.mdc b/.cursor/rules/api-standards.mdc index a307183..6a3a396 100644 --- a/.cursor/rules/api-standards.mdc +++ b/.cursor/rules/api-standards.mdc @@ -6,26 +6,30 @@ alwaysApply: false # API Standards -## API Documentation +When working with service files, follow these standards: -### OpenAPI Requirements +## Service Documentation +Each service MUST have comprehensive documentation: +- **API Gateway**: @services/api-gateway/README.md and @services/api-gateway/CLEAN_CODE.md +- **Service Adapters**: @services/service-adapters/README.md and @services/service-adapters/CLEAN_CODE.md +- **API Docs**: @services/api-docs/README.md and @services/api-docs/CLEAN_CODE.md + +## Clean Code Implementation +Apply the principles detailed in each service's CLEAN_CODE.md: +- **Java Spring Boot**: Follow @services/api-gateway/CLEAN_CODE.md +- **Python FastAPI**: Follow @services/service-adapters/CLEAN_CODE.md +- **Node.js Express**: Follow @services/api-docs/CLEAN_CODE.md + +## API Documentation - All endpoints MUST have OpenAPI documentation - Include request/response schemas - Provide example requests and responses - Document error responses - Include authentication requirements -### Documentation Tags -- Use consistent tags for endpoint grouping -- Provide clear descriptions -- Include parameter documentation -- Document response codes - ## Error Handling - -### Consistent Error Responses +Use consistent error response format: ```javascript -// Standard error response format { "error": "Error type", "message": "User-friendly message", @@ -34,63 +38,24 @@ alwaysApply: false } ``` -### HTTP Status Codes -- 200: Success -- 201: Created -- 400: Bad Request -- 401: Unauthorized -- 403: Forbidden -- 404: Not Found -- 500: Internal Server Error -- 503: Service Unavailable +## HTTP Status Codes +- 200: Success, 201: Created +- 400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found +- 500: Internal Server Error, 503: Service Unavailable ## Service-Specific Standards - -### Java Spring Boot -- Use constructor injection -- Implement proper validation -- Use appropriate annotations -- Follow REST conventions -- Implement global exception handling - -### Python FastAPI -- Use Pydantic models -- Implement async/await -- Use dependency injection -- Follow OpenAPI standards -- Implement proper error handling - -### Node.js Express -- Use middleware appropriately -- Implement proper error handling -- Use async/await patterns -- Follow REST conventions -- Implement health checks +- **Java Spring Boot**: Constructor injection, proper validation, REST conventions +- **Python FastAPI**: Pydantic models, async/await, dependency injection +- **Node.js Express**: Middleware usage, error handling, health checks ## Validation - -### Input Validation - Validate all inputs - Sanitize user data - Use appropriate data types - Implement rate limiting -### Response Validation -- Validate response schemas -- Use consistent data formats -- Implement proper error handling -- Document response structures - ## Performance - -### API Performance - Use pagination for large datasets - Implement response compression - Use appropriate HTTP methods -- Optimize response sizes - -### Caching -- Implement appropriate caching -- Use Redis for distributed caching -- Cache frequently accessed data -- Implement cache invalidation \ No newline at end of file +- Optimize response sizes \ No newline at end of file diff --git a/.cursor/rules/code-quality.mdc b/.cursor/rules/code-quality.mdc index 7ecb4a5..de4fc1b 100644 --- a/.cursor/rules/code-quality.mdc +++ b/.cursor/rules/code-quality.mdc @@ -6,69 +6,41 @@ alwaysApply: true # Code Quality Standards +When working with code files, follow these standards: + +## Clean Code Documentation +Apply the principles detailed in the comprehensive clean code guides: +- **Project Overview**: @CLEAN_CODE.md +- **API Gateway**: @services/api-gateway/CLEAN_CODE.md +- **Service Adapters**: @services/service-adapters/CLEAN_CODE.md +- **API Docs**: @services/api-docs/CLEAN_CODE.md +- **Frontend**: @frontend/CLEAN_CODE.md + ## Clean Code Principles - -### Single Responsibility Principle (SRP) -- Each class/component has one clear purpose -- Each function/method does one thing -- Clear separation of concerns -- Minimal coupling between components - -### Open/Closed Principle (OCP) -- Open for extension, closed for modification -- Use interfaces and abstractions -- Plugin architecture where appropriate -- Configuration-driven behavior - -### Dependency Inversion Principle (DIP) -- Depend on abstractions, not concretions -- Use dependency injection -- Interface-based design -- Inversion of control - -### Interface Segregation Principle (ISP) -- Small, focused interfaces -- Clients should not depend on unused methods -- Specific-purpose modules -- Clear API boundaries +Follow SOLID principles as detailed in @CLEAN_CODE.md: +- **Single Responsibility Principle (SRP)**: Each class/component has one clear purpose +- **Open/Closed Principle (OCP)**: Open for extension, closed for modification +- **Dependency Inversion Principle (DIP)**: Depend on abstractions, not concretions +- **Interface Segregation Principle (ISP)**: Small, focused interfaces ## Naming Conventions - -### Java (Spring Boot) -- Classes: PascalCase (e.g., `DashboardController`) -- Methods: camelCase (e.g., `getAllDashboards`) -- Variables: camelCase (e.g., `dashboardRepository`) -- Constants: UPPER_SNAKE_CASE (e.g., `API_VERSION`) - -### Python (FastAPI) -- Classes: PascalCase (e.g., `ServiceStatus`) -- Functions: snake_case (e.g., `get_home_assistant_entities`) -- Variables: snake_case (e.g., `service_config`) -- Constants: UPPER_SNAKE_CASE (e.g., `SERVICES`) - -### JavaScript/TypeScript (Node.js, React) -- Classes: PascalCase (e.g., `DashboardComponent`) -- Functions: camelCase (e.g., `fetchServiceSpec`) -- Variables: camelCase (e.g., `serviceStatus`) -- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`) +- **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants +- **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants +- **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE constants ## Function Design - -### Small, Focused Functions - Maximum 20-30 lines per function - Single level of abstraction - Clear, descriptive names - Single responsibility -### Error Handling +## Error Handling - Consistent error responses - Proper exception handling - User-friendly error messages - Logging for debugging ## Code Review Checklist - -### Before Merging - [ ] All new code follows naming conventions - [ ] Error handling is implemented - [ ] Input validation is present @@ -76,49 +48,13 @@ alwaysApply: true - [ ] Tests are written and passing - [ ] Clean code principles are followed -### Documentation Review -- [ ] README files are comprehensive -- [ ] Clean code documentation is complete -- [ ] Project structure is updated -- [ ] Progress tracking is current -- [ ] Links are working and relevant - ## Testing Requirements - -### Unit Tests -- Test business logic -- Test error conditions -- Test edge cases -- Maintain high coverage - -### Integration Tests -- Test API endpoints -- Test service interactions -- Test error scenarios -- Test configuration - -### End-to-End Tests -- Test critical user flows -- Test service integration -- Test error recovery -- Test performance +- **Unit Tests**: Test business logic, error conditions, edge cases +- **Integration Tests**: Test API endpoints, service interactions +- **End-to-End Tests**: Test critical user flows, service integration ## Performance Guidelines - -### Database Optimization -- Use appropriate indexes -- Implement connection pooling -- Use lazy loading where appropriate -- Optimize queries - -### Caching -- Implement appropriate caching -- Use Redis for distributed caching -- Cache frequently accessed data -- Implement cache invalidation - -### Resource Management -- Proper cleanup of resources -- Memory leak prevention -- Connection pooling +- Database optimization with appropriate indexes +- Implement caching strategies +- Proper resource management - Efficient algorithms \ No newline at end of file diff --git a/.cursor/rules/documentation-standards.mdc b/.cursor/rules/documentation-standards.mdc index f92332c..5897c41 100644 --- a/.cursor/rules/documentation-standards.mdc +++ b/.cursor/rules/documentation-standards.mdc @@ -6,76 +6,26 @@ alwaysApply: true # Documentation Standards -## README Requirements -Every service and major component MUST have a comprehensive README.md file that includes: +When working with documentation files, follow these standards: -### Service README Requirements -- **Service Overview**: Purpose, port, and main functionality -- **Architecture**: Key components and their responsibilities -- **Features**: Core capabilities and integrations -- **API Endpoints**: Available endpoints with descriptions -- **Configuration**: Environment variables and settings -- **Development**: Setup, running, and testing instructions -- **Dependencies**: Required packages and versions -- **Clean Code**: Reference to CLEAN_CODE.md file +## Required Documentation Files +- **Main README**: @README.md +- **Project Structure**: @docs/structure.txt +- **Progress Tracking**: @docs/progress.md +- **Clean Code Guide**: @CLEAN_CODE.md -### Frontend README Requirements -- **Component Structure**: Directory organization and component hierarchy -- **Development Setup**: Installation and running instructions -- **Architecture**: Clean code principles and patterns -- **API Integration**: Service communication and error handling -- **Offline Mode**: Resilience features and fallback behavior -- **Testing**: Unit and integration testing guidelines +## Service Documentation +Each service MUST have: +- **README.md**: Service overview, setup, and usage +- **CLEAN_CODE.md**: Clean code implementation details -## Documentation Folder Structure -The `docs/` folder MUST contain: +## Frontend Documentation +- **README.md**: @frontend/README.md +- **Clean Code**: @frontend/CLEAN_CODE.md +- **Resilience**: @frontend/RESILIENCE.md -### Required Files -- **specs.md**: Project specifications and requirements -- **structure.txt**: Complete project directory structure -- **progress.md**: Development progress and completed tasks -- **FRONTEND_REFACTORING.md**: Frontend clean code refactoring summary - -### Documentation Updates -- Update `structure.txt` when adding new files or directories -- Update `progress.md` when completing tasks or milestones -- Update service-specific READMEs when modifying functionality -- Update main README.md when adding new features or services - -## Clean Code Documentation -Every service MUST have a CLEAN_CODE.md file that includes: - -### Required Sections -- **Architecture Overview**: Service structure and organization -- **Clean Code Principles**: SRP, OCP, DIP, ISP applications -- **Code Quality Improvements**: Before/after examples -- **Best Practices**: Technology-specific guidelines -- **Performance Optimizations**: Caching, async operations, etc. -- **Testing Strategy**: Unit, integration, and E2E testing -- **Code Review Checklist**: Quality assurance guidelines -- **Future Improvements**: Enhancement roadmap - -## Documentation Quality Checklist - -### README Quality -- [ ] Clear service overview and purpose -- [ ] Complete setup and running instructions -- [ ] API endpoint documentation -- [ ] Configuration examples -- [ ] Development guidelines -- [ ] Links to related documentation - -### Clean Code Documentation -- [ ] Architecture overview included -- [ ] Clean code principles explained -- [ ] Code examples provided -- [ ] Best practices documented -- [ ] Testing strategies outlined -- [ ] Future improvements listed - -### Project Documentation -- [ ] Structure.txt is up to date -- [ ] Progress.md reflects current status -- [ ] All services have README files -- [ ] All services have CLEAN_CODE.md files -- [ ] Main README.md is comprehensive \ No newline at end of file +## Documentation Updates +- Update @docs/structure.txt when adding new files +- Update @docs/progress.md when completing tasks +- Update service READMEs when modifying functionality +- Keep all documentation current and comprehensive \ No newline at end of file diff --git a/.cursor/rules/frontend-standards.mdc b/.cursor/rules/frontend-standards.mdc index 22f6735..3499aec 100644 --- a/.cursor/rules/frontend-standards.mdc +++ b/.cursor/rules/frontend-standards.mdc @@ -6,99 +6,44 @@ alwaysApply: false # Frontend Standards -## Component Design +When working with frontend files, follow these standards: -### React Components -- Single responsibility per component -- Props validation with PropTypes -- Error boundary protection -- Reusable and composable design -- Maximum 50 lines per component file +## Documentation References +- **Frontend README**: @frontend/README.md +- **Clean Code Guide**: @frontend/CLEAN_CODE.md +- **Resilience Features**: @frontend/RESILIENCE.md -### Component Structure -``` -src/ -├── components/ -│ ├── common/ # Reusable UI components -│ ├── dashboard/ # Dashboard-specific components -│ └── [main components] # Main application components -├── hooks/ # Custom React hooks -├── services/ # API and external services -├── utils/ # Utility functions -└── constants/ # Configuration constants -``` +## Component Structure +Follow the structure defined in @frontend/README.md: +- **Common Components**: @frontend/src/components/common/ +- **Dashboard Components**: @frontend/src/components/dashboard/ +- **Custom Hooks**: @frontend/src/hooks/ +- **API Services**: @frontend/src/services/ +- **Utilities**: @frontend/src/utils/ +- **Constants**: @frontend/src/constants/ + +## Clean Code Principles +Apply the principles detailed in @frontend/CLEAN_CODE.md: +- Single Responsibility Principle +- Component Composition +- Error Handling with Error Boundaries +- Performance Optimization ## Naming Conventions - -### JavaScript/TypeScript - Classes: PascalCase (e.g., `DashboardComponent`) - Functions: camelCase (e.g., `fetchServiceSpec`) - Variables: camelCase (e.g., `serviceStatus`) - Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`) -### File Organization +## File Organization - Component files: PascalCase (e.g., `Dashboard.js`) - Hook files: camelCase with 'use' prefix (e.g., `useServiceStatus.js`) - Utility files: camelCase (e.g., `errorHandling.js`) - Constant files: camelCase (e.g., `index.js`) -## Clean Code Principles - -### Single Responsibility Principle (SRP) -- Each component has one clear purpose -- `SystemStatsCards` only handles system statistics display -- `ServiceStatusList` only manages service status display -- `StatusIcon` only renders status icons - -### Don't Repeat Yourself (DRY) -- Centralized status icon logic in `StatusIcon` component -- Reusable loading component in `LoadingSpinner` -- Centralized error handling in `utils/errorHandling.js` -- All constants extracted to `constants/index.js` - -### Component Composition -- Large components broken into smaller, focused components -- Clear prop interfaces with PropTypes validation -- Easy to test and maintain - -## Error Handling - -### Error Boundaries -- `ErrorBoundary` component for graceful error recovery -- Development-friendly error details -- User-friendly error messages - -### Offline Mode -- Service status monitoring -- Fallback data when services unavailable -- Automatic retry mechanisms -- Clear status indicators - -## Performance - -### Component Optimization -- Smaller components = better React optimization -- Reduced re-renders through focused components -- Memoization opportunities for pure components - -### Code Splitting Ready -- Modular structure supports code splitting -- Easy to lazy load dashboard components -- Clear separation enables tree shaking - -## Testing - -### Testable Components -- Pure functions in utils -- Isolated component logic -- Clear prop interfaces -- Mockable dependencies - -### Test Structure -```javascript -describe('SystemStatsCards', () => { - it('renders CPU usage correctly', () => { - // Test focused component - }); -}); -``` \ No newline at end of file +## Component Design +- Single responsibility per component +- Maximum 50 lines per component file +- Props validation with PropTypes +- Error boundary protection +- Reusable and composable design \ No newline at end of file diff --git a/.cursor/rules/project-structure.mdc b/.cursor/rules/project-structure.mdc index 5c133ca..17230f1 100644 --- a/.cursor/rules/project-structure.mdc +++ b/.cursor/rules/project-structure.mdc @@ -6,105 +6,51 @@ alwaysApply: true # Project Structure Standards -## Directory Organization +When working with any files, follow these structure standards: -### Service Structure -``` -services/[service-name]/ -├── src/ # Source code -├── tests/ # Test files -├── docs/ # Service-specific documentation -├── README.md # Service documentation -├── CLEAN_CODE.md # Clean code implementation -├── package.json/pom.xml # Dependencies -└── Dockerfile # Container configuration -``` - -### Frontend Structure -``` -frontend/ -├── src/ -│ ├── components/ # React components -│ │ ├── common/ # Reusable components -│ │ └── dashboard/ # Dashboard-specific components -│ ├── hooks/ # Custom hooks -│ ├── services/ # API services -│ ├── utils/ # Utility functions -│ ├── constants/ # Configuration constants -│ └── [app files] # Main application files -├── public/ # Static assets -├── README.md # Frontend documentation -├── CLEAN_CODE.md # Clean code implementation -├── RESILIENCE.md # Offline mode features -└── package.json # Dependencies -``` - -## File Naming - -### Service Files -- Source files: Follow language conventions -- Documentation: README.md, CLEAN_CODE.md -- Configuration: package.json, pom.xml, requirements.txt -- Docker: Dockerfile, Dockerfile.dev - -### Frontend Files -- Components: PascalCase (e.g., `Dashboard.js`) -- Hooks: camelCase with 'use' prefix (e.g., `useServiceStatus.js`) -- Utilities: camelCase (e.g., `errorHandling.js`) -- Constants: camelCase (e.g., `index.js`) +## Project Structure Reference +Follow the complete project structure defined in @docs/structure.txt ## Documentation Structure +- **Main README**: @README.md +- **Project Structure**: @docs/structure.txt +- **Progress Tracking**: @docs/progress.md +- **Clean Code Guide**: @CLEAN_CODE.md -### Required Documentation -- **README.md**: Service overview and setup -- **CLEAN_CODE.md**: Clean code implementation -- **Progress tracking**: In docs/progress.md -- **Structure updates**: In docs/structure.txt +## Service Structure +Each service MUST follow the structure defined in @docs/structure.txt: +- **API Gateway**: @services/api-gateway/ with README.md and CLEAN_CODE.md +- **Service Adapters**: @services/service-adapters/ with README.md and CLEAN_CODE.md +- **API Docs**: @services/api-docs/ with README.md and CLEAN_CODE.md -### Documentation Updates -- Update when adding new files or directories -- Update when completing tasks or milestones -- Update when modifying functionality -- Update when adding new features or services +## Frontend Structure +Follow the structure defined in @frontend/README.md: +- **Components**: @frontend/src/components/ +- **Hooks**: @frontend/src/hooks/ +- **Services**: @frontend/src/services/ +- **Utils**: @frontend/src/utils/ +- **Constants**: @frontend/src/constants/ + +## File Naming Conventions +- **Service Files**: Follow language conventions (Java, Python, Node.js) +- **Frontend Files**: PascalCase components, camelCase functions +- **Documentation**: README.md, CLEAN_CODE.md, RESILIENCE.md + +## Documentation Updates +- Update @docs/structure.txt when adding new files +- Update @docs/progress.md when completing tasks +- Update service READMEs when modifying functionality +- Keep all documentation current and comprehensive ## Configuration Files - -### Environment Configuration - Use .env files for environment variables - Provide .env.example templates -- Document all required variables -- Use consistent naming conventions - -### Docker Configuration -- Multi-stage builds for production +- Multi-stage Docker builds for production - Development-specific Dockerfiles -- Health checks in containers -- Proper base image selection - -## Git Structure - -### Branching Strategy -- main: Production-ready code -- develop: Integration branch -- feature/*: Feature development -- hotfix/*: Critical fixes - -### Commit Messages -- Use conventional commit format -- Include scope when relevant -- Provide clear descriptions -- Reference issues when applicable ## Quality Gates - -### Pre-commit Checks -- Code formatting -- Linting -- Type checking -- Test execution - -### Pre-merge Checks +- Code formatting and linting +- Type checking and test execution - Code review approval -- Test coverage requirements - Documentation updates - Security scans \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index f5e957e..a2ed4b5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -3,163 +3,68 @@ ## Project Overview LabFusion is a unified dashboard and integration hub for homelab services, built with a polyglot microservices architecture using Java Spring Boot, Python FastAPI, Node.js Express, and React. +## Documentation References +- **Main README**: @README.md +- **Project Structure**: @docs/structure.txt +- **Progress Tracking**: @docs/progress.md +- **Clean Code Guide**: @CLEAN_CODE.md + +## Service Documentation +Each service has comprehensive documentation: +- **API Gateway**: @services/api-gateway/README.md and @services/api-gateway/CLEAN_CODE.md +- **Service Adapters**: @services/service-adapters/README.md and @services/service-adapters/CLEAN_CODE.md +- **API Docs**: @services/api-docs/README.md and @services/api-docs/CLEAN_CODE.md + +## Frontend Documentation +- **Frontend README**: @frontend/README.md +- **Clean Code Guide**: @frontend/CLEAN_CODE.md +- **Resilience Features**: @frontend/RESILIENCE.md + ## Code Style - -### Naming Conventions -- **Java**: PascalCase for classes, camelCase for methods, UPPER_SNAKE_CASE for constants -- **Python**: PascalCase for classes, snake_case for functions, UPPER_SNAKE_CASE for constants -- **JavaScript/TypeScript**: PascalCase for classes, camelCase for functions, UPPER_SNAKE_CASE for constants - -### Component Design -- Single responsibility per component -- Maximum 50 lines per component file -- Props validation with PropTypes -- Error boundary protection -- Reusable and composable design +Follow the naming conventions and standards defined in @CLEAN_CODE.md: +- **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants +- **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants +- **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE constants ## Architecture +Follow the architecture patterns detailed in each service's CLEAN_CODE.md: +- **Service Structure**: Repository pattern, dependency injection, clear separation of concerns +- **Frontend Structure**: Functional components, custom hooks, error boundaries, component composition -### Service Structure -- Follow the repository pattern -- Keep business logic in service layers -- Use dependency injection -- Implement proper error handling -- Clear separation of concerns - -### Frontend Structure -- Use functional components in React -- Implement custom hooks for state logic -- Use error boundaries for error handling -- Follow component composition patterns -- Centralize constants and utilities - -## Documentation Requirements - -### README Files -Every service MUST have a comprehensive README.md that includes: -- Service overview and purpose -- Architecture and key components -- Features and capabilities -- API endpoints with descriptions -- Configuration and environment variables -- Development setup and running instructions -- Dependencies and versions -- Reference to CLEAN_CODE.md - -### Clean Code Documentation -Every service MUST have a CLEAN_CODE.md that includes: -- Architecture overview -- Clean code principles applied -- Code quality improvements -- Best practices and guidelines -- Performance optimizations -- Testing strategies -- Code review checklist -- Future improvements - -### Project Documentation -- Update docs/structure.txt when adding files -- Update docs/progress.md when completing tasks -- Update service READMEs when modifying functionality -- Update main README.md when adding features +## Clean Code Principles +Apply the SOLID principles detailed in @CLEAN_CODE.md: +- Single Responsibility Principle +- Open/Closed Principle +- Dependency Inversion Principle +- Interface Segregation Principle ## API Standards - -### OpenAPI Documentation -- All endpoints MUST have OpenAPI documentation -- Include request/response schemas -- Provide example requests and responses -- Document error responses -- Include authentication requirements - -### Error Handling -- Use consistent error response format -- Implement proper HTTP status codes -- Provide user-friendly error messages -- Log errors for debugging - -### Validation -- Validate all inputs -- Use appropriate data types -- Implement rate limiting -- Sanitize user data +Follow the API standards defined in each service's documentation: +- OpenAPI documentation for all endpoints +- Consistent error response format +- Proper HTTP status codes +- Input validation and sanitization ## Testing - -### Unit Tests -- Test business logic -- Test error conditions -- Test edge cases -- Maintain high coverage - -### Integration Tests -- Test API endpoints -- Test service interactions -- Test error scenarios -- Test configuration - -### End-to-End Tests -- Test critical user flows -- Test service integration -- Test error recovery -- Test performance +Follow the testing strategies outlined in each service's CLEAN_CODE.md: +- Unit tests for business logic +- Integration tests for API endpoints +- End-to-end tests for critical flows ## Quality Assurance - -### Code Review Checklist -- [ ] Naming conventions followed -- [ ] Error handling implemented -- [ ] Input validation present -- [ ] Documentation updated -- [ ] Tests written and passing -- [ ] Clean code principles followed - -### Documentation Review -- [ ] README files comprehensive -- [ ] Clean code documentation complete -- [ ] Project structure updated -- [ ] Progress tracking current -- [ ] Links working and relevant +Use the code review checklists from @CLEAN_CODE.md: +- Naming conventions followed +- Error handling implemented +- Documentation updated +- Tests written and passing +- Clean code principles followed ## Performance - -### Database Optimization -- Use appropriate indexes -- Implement connection pooling -- Use lazy loading where appropriate -- Optimize queries - -### Caching -- Implement appropriate caching -- Use Redis for distributed caching -- Cache frequently accessed data -- Implement cache invalidation - -### API Performance -- Use pagination for large datasets -- Implement response compression -- Use appropriate HTTP methods -- Optimize response sizes - -## Security - -### Input Validation -- Validate all inputs -- Sanitize user data -- Use appropriate data types -- Implement rate limiting - -### Error Handling -- Don't expose sensitive information -- Log errors appropriately -- Use consistent error responses -- Implement proper status codes - -### Authentication -- Implement proper authentication -- Use secure token handling -- Implement authorization checks -- Follow security best practices +Follow the performance guidelines from @CLEAN_CODE.md: +- Database optimization +- Caching strategies +- Resource management +- API performance optimization ## When Working on This Project