claude-vault/projects/ligalytics-staffeleinteilung/MEMORY.md

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)