32 lines
1.7 KiB
Markdown
32 lines
1.7 KiB
Markdown
# Ligalytics Staffeleinteilung - Memory
|
|
|
|
## Projekt-Setup
|
|
- **Docker-basiertes Backend**: PostgreSQL 16 + Django 6.0+ (docker-compose.yml mit health checks)
|
|
- **Frontend**: Next.js 16 mit React 19, TanStack Query für Server State
|
|
- **API-Pattern**: DRF mit @api_view Decorators (NICHT ViewSets!) - Function-based Views
|
|
- **Code Style**: Ruff (Python, 120 chars, single quotes), Prettier (TS/JS, 2 spaces)
|
|
|
|
## Wichtige Patterns
|
|
- **Makefile-Befehle**: Alle Django-Operationen über `make migrate`, `make test`, etc.
|
|
- **App-Struktur**: core (Club/Team/Stadium), scenarios (Competition/Scenario/Solution/Group), users
|
|
- **Dokumentation**: CLAUDE.md ist Source of Truth für Entwicklungs-Workflows
|
|
- **Docker Services**: db (PostgreSQL) + web (Django) mit Volume-Mount für Hot-Reload
|
|
|
|
## Häufige Operationen
|
|
- Backend-Tests einzelner Apps: `docker compose exec web python manage.py test apps.core`
|
|
- Spezifische Test-Datei: `docker compose exec web python manage.py test apps.scenarios.tests.test_views`
|
|
- API-Dokumentation: http://localhost:8000/api/docs/ (Swagger UI via drf-spectacular)
|
|
- Django Shell: `make shell` (im /server Verzeichnis)
|
|
|
|
## Zu vermeiden
|
|
- SQLite in Produktion (nur Development)
|
|
- ViewSets/Routers statt @api_view (Projekt-Standard ist Function-based Views)
|
|
- Generische Annahmen - immer CLAUDE.md und spezifische Dokumentation prüfen
|
|
- Breaking Changes ohne Dokumentations-Update
|
|
|
|
## Architektur-Kontext
|
|
- **DFB SPB2 Integration**: System ist Teil der "Spielbetrieb 2.0" Initiative
|
|
- **Datenfluss**: DFBnet (Hinweg) → Ligalytics Optimierung → DFBnet (Rückweg)
|
|
- **Optimierungs-Engine**: Mathematische Solver-Integration für Staffeleinteilung geplant
|
|
- **Business Domain**: Fußball-Ligaverwaltung mit Hard Constraints (Staffelgrößen, Vereinstrennung)
|