48 lines
2.2 KiB
Plaintext
48 lines
2.2 KiB
Plaintext
# TimeTracker Project Rules (v2)
|
|
0. GENERAL
|
|
DONT OVERENGINEER.
|
|
USE IN LINE REPLACEMENTS IF POSSIBLE.
|
|
SOLVE TASKS AS FAST AS POSSIBLE. EACH REQUEST COSTS THE USER MONEY.
|
|
1. ARCHITECTURE
|
|
- Multi-tenancy enforced via company_id in all DB queries
|
|
2. CODING PRACTICES
|
|
- Type safety enforced (Go 1.21+ generics, TypeScript strict mode)
|
|
- Domain types must match across backend (Go) and frontend (TypeScript)
|
|
- All database access through repository interfaces
|
|
- API handlers must use DTOs for input/output
|
|
- Use tygo to generate TypeScript types after modifying Go types
|
|
3. SECURITY
|
|
- JWT authentication required for all API endpoints
|
|
- RBAC implemented in middleware/auth.go
|
|
- Input validation using github.com/go-playground/validator
|
|
- No raw SQL - use GORM query builder
|
|
4. DOCUMENTATION
|
|
- Architecture decisions recorded in docu/ARCHITECTURE.md
|
|
- Type relationships documented in docu/domain_types.md
|
|
5. TESTING
|
|
- 80%+ test coverage for domain logic
|
|
- Integration tests for API endpoints
|
|
- Model tests in backend/cmd/modeltest
|
|
6. FRONTEND
|
|
- Next.js App Router pattern required
|
|
8. DEVELOPMENT WORKFLOW
|
|
- Makefile commands are only available in the backend folder
|
|
- Common make commands:
|
|
- make generate: Run code generation (tygo, swagger, etc.)
|
|
- make test: Run all tests
|
|
- make build: Build the application
|
|
- make run: Start the development server
|
|
9. CUSTOM RULES
|
|
- Add custom rules to .clinerules if:
|
|
- Unexpected behavior is encountered
|
|
- Specific conditions require warnings
|
|
- New patterns emerge that need documentation
|
|
- DO NOT FIX UNUSED IMPORTS - this is the job of the linter
|
|
10.Implement a REST API update handling in Go using Gin that ensures the following behavior:
|
|
- The update request is received as JSON.
|
|
- If a field is present in the JSON and set to null, the corresponding value in the database should be removed.
|
|
- If a field is missing in the JSON, it should not be modified.
|
|
- If a field is present in the JSON and not null, it should be updated.
|
|
- Use either a struct or a map to handle the JSON data.
|
|
- Ensure the update logic is robust and does not unintentionally remove or overwrite fields.
|
|
- Optional: Handle error cases like invalid JSON and return appropriate HTTP status codes. |