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

2025-09-11 23:51:00 +02:00
parent b9206de1a0
commit 83fb444196
6 changed files with 177 additions and 530 deletions
--- 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