# 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)