admin/labFusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements

Browse Source
This commit is contained in:
glenn schrooyen
2025-09-11 23:51:00 +02:00
parent b9206de1a0
commit 83fb444196
6 changed files with 177 additions and 530 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
.cursor/rules/api-standards.mdc
View File

@@ -6,26 +6,30 @@ alwaysApply: false
# API Standards # 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 - All endpoints MUST have OpenAPI documentation
- Include request/response schemas - Include request/response schemas
- Provide example requests and responses - Provide example requests and responses
- Document error responses - Document error responses
- Include authentication requirements - Include authentication requirements
### Documentation Tags
- Use consistent tags for endpoint grouping
- Provide clear descriptions
- Include parameter documentation
- Document response codes
## Error Handling ## Error Handling
Use consistent error response format:
### Consistent Error Responses
```javascript ```javascript
// Standard error response format
{ {
"error": "Error type", "error": "Error type",
"message": "User-friendly message", "message": "User-friendly message",
@@ -34,63 +38,24 @@ alwaysApply: false
} }
``` ```
### HTTP Status Codes ## HTTP Status Codes
- 200: Success - 200: Success, 201: Created
- 201: Created - 400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found
- 400: Bad Request - 500: Internal Server Error, 503: Service Unavailable
- 401: Unauthorized
- 403: Forbidden
- 404: Not Found
- 500: Internal Server Error
- 503: Service Unavailable
## Service-Specific Standards ## Service-Specific Standards
- **Java Spring Boot**: Constructor injection, proper validation, REST conventions
### Java Spring Boot - **Python FastAPI**: Pydantic models, async/await, dependency injection
- Use constructor injection - **Node.js Express**: Middleware usage, error handling, health checks
- 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
## Validation ## Validation
### Input Validation
- Validate all inputs - Validate all inputs
- Sanitize user data - Sanitize user data
- Use appropriate data types - Use appropriate data types
- Implement rate limiting - Implement rate limiting
### Response Validation
- Validate response schemas
- Use consistent data formats
- Implement proper error handling
- Document response structures
## Performance ## Performance
### API Performance
- Use pagination for large datasets - Use pagination for large datasets
- Implement response compression - Implement response compression
- Use appropriate HTTP methods - Use appropriate HTTP methods
- Optimize response sizes - Optimize response sizes
### Caching
- Implement appropriate caching
- Use Redis for distributed caching
- Cache frequently accessed data
- Implement cache invalidation

114
.cursor/rules/code-quality.mdc
View File

@@ -6,69 +6,41 @@ alwaysApply: true
# Code Quality Standards # 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 ## Clean Code Principles
Follow SOLID principles as detailed in @CLEAN_CODE.md:
### Single Responsibility Principle (SRP) - **Single Responsibility Principle (SRP)**: Each class/component has one clear purpose
- Each class/component has one clear purpose - **Open/Closed Principle (OCP)**: Open for extension, closed for modification
- Each function/method does one thing - **Dependency Inversion Principle (DIP)**: Depend on abstractions, not concretions
- Clear separation of concerns - **Interface Segregation Principle (ISP)**: Small, focused interfaces
- 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
## Naming Conventions ## Naming Conventions
- **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants
### Java (Spring Boot) - **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants
- Classes: PascalCase (e.g., `DashboardController`) - **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE constants
- 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`)
## Function Design ## Function Design
### Small, Focused Functions
- Maximum 20-30 lines per function - Maximum 20-30 lines per function
- Single level of abstraction - Single level of abstraction
- Clear, descriptive names - Clear, descriptive names
- Single responsibility - Single responsibility
### Error Handling ## Error Handling
- Consistent error responses - Consistent error responses
- Proper exception handling - Proper exception handling
- User-friendly error messages - User-friendly error messages
- Logging for debugging - Logging for debugging
## Code Review Checklist ## Code Review Checklist
### Before Merging
- [ ] All new code follows naming conventions - [ ] All new code follows naming conventions
- [ ] Error handling is implemented - [ ] Error handling is implemented
- [ ] Input validation is present - [ ] Input validation is present
@@ -76,49 +48,13 @@ alwaysApply: true
- [ ] Tests are written and passing - [ ] Tests are written and passing
- [ ] Clean code principles are followed - [ ] 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 ## Testing Requirements
- **Unit Tests**: Test business logic, error conditions, edge cases
### Unit Tests - **Integration Tests**: Test API endpoints, service interactions
- Test business logic - **End-to-End Tests**: Test critical user flows, service integration
- 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
## Performance Guidelines ## Performance Guidelines
- Database optimization with appropriate indexes
### Database Optimization - Implement caching strategies
- Use appropriate indexes - Proper resource management
- 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
- Efficient algorithms - Efficient algorithms

88
.cursor/rules/documentation-standards.mdc
View File

@@ -6,76 +6,26 @@ alwaysApply: true
# Documentation Standards # Documentation Standards
## README Requirements When working with documentation files, follow these standards:
Every service and major component MUST have a comprehensive README.md file that includes:
### Service README Requirements ## Required Documentation Files
- **Service Overview**: Purpose, port, and main functionality - **Main README**: @README.md
- **Architecture**: Key components and their responsibilities - **Project Structure**: @docs/structure.txt
- **Features**: Core capabilities and integrations - **Progress Tracking**: @docs/progress.md
- **API Endpoints**: Available endpoints with descriptions - **Clean Code Guide**: @CLEAN_CODE.md
- **Configuration**: Environment variables and settings
- **Development**: Setup, running, and testing instructions
- **Dependencies**: Required packages and versions
- **Clean Code**: Reference to CLEAN_CODE.md file
### Frontend README Requirements ## Service Documentation
- **Component Structure**: Directory organization and component hierarchy Each service MUST have:
- **Development Setup**: Installation and running instructions - **README.md**: Service overview, setup, and usage
- **Architecture**: Clean code principles and patterns - **CLEAN_CODE.md**: Clean code implementation details
- **API Integration**: Service communication and error handling
- **Offline Mode**: Resilience features and fallback behavior
- **Testing**: Unit and integration testing guidelines
## Documentation Folder Structure ## Frontend Documentation
The `docs/` folder MUST contain: - **README.md**: @frontend/README.md
- **Clean Code**: @frontend/CLEAN_CODE.md
- **Resilience**: @frontend/RESILIENCE.md
### Required Files ## Documentation Updates
- **specs.md**: Project specifications and requirements - Update @docs/structure.txt when adding new files
- **structure.txt**: Complete project directory structure - Update @docs/progress.md when completing tasks
- **progress.md**: Development progress and completed tasks - Update service READMEs when modifying functionality
- **FRONTEND_REFACTORING.md**: Frontend clean code refactoring summary - Keep all documentation current and comprehensive
### 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

109
.cursor/rules/frontend-standards.mdc
View File

@@ -6,99 +6,44 @@ alwaysApply: false
# Frontend Standards # Frontend Standards
## Component Design When working with frontend files, follow these standards:
### React Components ## Documentation References
- Single responsibility per component - **Frontend README**: @frontend/README.md
- Props validation with PropTypes - **Clean Code Guide**: @frontend/CLEAN_CODE.md
- Error boundary protection - **Resilience Features**: @frontend/RESILIENCE.md
- Reusable and composable design
- Maximum 50 lines per component file
### Component Structure ## Component Structure
``` Follow the structure defined in @frontend/README.md:
src/ - **Common Components**: @frontend/src/components/common/
├── components/ - **Dashboard Components**: @frontend/src/components/dashboard/
│ ├── common/ # Reusable UI components - **Custom Hooks**: @frontend/src/hooks/
│ ├── dashboard/ # Dashboard-specific components - **API Services**: @frontend/src/services/
│ └── [main components] # Main application components - **Utilities**: @frontend/src/utils/
├── hooks/ # Custom React hooks - **Constants**: @frontend/src/constants/
├── services/ # API and external services
├── utils/ # Utility functions ## Clean Code Principles
└── constants/ # Configuration constants Apply the principles detailed in @frontend/CLEAN_CODE.md:
``` - Single Responsibility Principle
- Component Composition
- Error Handling with Error Boundaries
- Performance Optimization
## Naming Conventions ## Naming Conventions
### JavaScript/TypeScript
- Classes: PascalCase (e.g., `DashboardComponent`) - Classes: PascalCase (e.g., `DashboardComponent`)
- Functions: camelCase (e.g., `fetchServiceSpec`) - Functions: camelCase (e.g., `fetchServiceSpec`)
- Variables: camelCase (e.g., `serviceStatus`) - Variables: camelCase (e.g., `serviceStatus`)
- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`) - Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`)
### File Organization ## File Organization
- Component files: PascalCase (e.g., `Dashboard.js`) - Component files: PascalCase (e.g., `Dashboard.js`)
- Hook files: camelCase with 'use' prefix (e.g., `useServiceStatus.js`) - Hook files: camelCase with 'use' prefix (e.g., `useServiceStatus.js`)
- Utility files: camelCase (e.g., `errorHandling.js`) - Utility files: camelCase (e.g., `errorHandling.js`)
- Constant files: camelCase (e.g., `index.js`) - Constant files: camelCase (e.g., `index.js`)
## Clean Code Principles ## Component Design
- Single responsibility per component
### Single Responsibility Principle (SRP) - Maximum 50 lines per component file
- Each component has one clear purpose - Props validation with PropTypes
- `SystemStatsCards` only handles system statistics display - Error boundary protection
- `ServiceStatusList` only manages service status display - Reusable and composable design
- `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
});
});
```

120
.cursor/rules/project-structure.mdc
View File

@@ -6,105 +6,51 @@ alwaysApply: true
# Project Structure Standards # Project Structure Standards
## Directory Organization When working with any files, follow these structure standards:
### Service Structure ## Project Structure Reference
``` Follow the complete project structure defined in @docs/structure.txt
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`)
## Documentation Structure ## Documentation Structure
- **Main README**: @README.md
- **Project Structure**: @docs/structure.txt
- **Progress Tracking**: @docs/progress.md
- **Clean Code Guide**: @CLEAN_CODE.md
### Required Documentation ## Service Structure
- **README.md**: Service overview and setup Each service MUST follow the structure defined in @docs/structure.txt:
- **CLEAN_CODE.md**: Clean code implementation - **API Gateway**: @services/api-gateway/ with README.md and CLEAN_CODE.md
- **Progress tracking**: In docs/progress.md - **Service Adapters**: @services/service-adapters/ with README.md and CLEAN_CODE.md
- **Structure updates**: In docs/structure.txt - **API Docs**: @services/api-docs/ with README.md and CLEAN_CODE.md
### Documentation Updates ## Frontend Structure
- Update when adding new files or directories Follow the structure defined in @frontend/README.md:
- Update when completing tasks or milestones - **Components**: @frontend/src/components/
- Update when modifying functionality - **Hooks**: @frontend/src/hooks/
- Update when adding new features or services - **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 ## Configuration Files
### Environment Configuration
- Use .env files for environment variables - Use .env files for environment variables
- Provide .env.example templates - Provide .env.example templates
- Document all required variables - Multi-stage Docker builds for production
- Use consistent naming conventions
### Docker Configuration
- Multi-stage builds for production
- Development-specific Dockerfiles - 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 ## Quality Gates
- Code formatting and linting
### Pre-commit Checks - Type checking and test execution
- Code formatting
- Linting
- Type checking
- Test execution
### Pre-merge Checks
- Code review approval - Code review approval
- Test coverage requirements
- Documentation updates - Documentation updates
- Security scans - Security scans

195
AGENTS.md
View File

@@ -3,163 +3,68 @@
## Project Overview ## 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. 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 ## Code Style
Follow the naming conventions and standards defined in @CLEAN_CODE.md:
### Naming Conventions - **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants
- **Java**: PascalCase for classes, camelCase for methods, UPPER_SNAKE_CASE for constants - **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants
- **Python**: PascalCase for classes, snake_case for functions, UPPER_SNAKE_CASE for constants - **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE 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
## Architecture ## 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 ## Clean Code Principles
- Follow the repository pattern Apply the SOLID principles detailed in @CLEAN_CODE.md:
- Keep business logic in service layers - Single Responsibility Principle
- Use dependency injection - Open/Closed Principle
- Implement proper error handling - Dependency Inversion Principle
- Clear separation of concerns - Interface Segregation Principle
### 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
## API Standards ## API Standards
Follow the API standards defined in each service's documentation:
### OpenAPI Documentation - OpenAPI documentation for all endpoints
- All endpoints MUST have OpenAPI documentation - Consistent error response format
- Include request/response schemas - Proper HTTP status codes
- Provide example requests and responses - Input validation and sanitization
- 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
## Testing ## Testing
Follow the testing strategies outlined in each service's CLEAN_CODE.md:
### Unit Tests - Unit tests for business logic
- Test business logic - Integration tests for API endpoints
- Test error conditions - End-to-end tests for critical flows
- 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
## Quality Assurance ## Quality Assurance
Use the code review checklists from @CLEAN_CODE.md:
### Code Review Checklist - Naming conventions followed
- [ ] Naming conventions followed - Error handling implemented
- [ ] Error handling implemented - Documentation updated
- [ ] Input validation present - Tests written and passing
- [ ] Documentation updated - Clean code principles followed
- [ ] 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
## Performance ## Performance
Follow the performance guidelines from @CLEAN_CODE.md:
### Database Optimization - Database optimization
- Use appropriate indexes - Caching strategies
- Implement connection pooling - Resource management
- Use lazy loading where appropriate - API performance optimization
- 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
## When Working on This Project ## When Working on This Project