Stefan Mogeritsch 0aa1a1b9b7 feat(entries+time-scheduling): add support for automatic breaks and inspection type configurations

- **Domain Enhancements:**
  - Introduced `PausenKonfiguration` and `BesichtigungsBlock` entities to handle automatic breaks and inspection scheduling.
  - Added `BesichtigungsTypE` enum for inspection types (`ZU_FUSS`, `ZU_PFERD`).
  - Updated `Bewerb` and `Abteilung` models to include pause and inspection type fields.

- **Service Updates:**
  - Enhanced `StartlistenService` to calculate start times, accounting for breaks and inspection buffers.
  - Extended `BewerbService` to support patchable time scheduling via new `updateZeitplan` API.

- **Persistence Changes:**
  - Updated tables (`BewerbTable`, `AbteilungTable`) to persist break configurations and inspection types.
  - Implemented repository mappings to include these new fields.

- **Testing:**
  - Introduced `BewerbeZeitplanIntegrationTest` to validate new scheduling behaviors, including automatic pauses and inspection handling.

- **Documentation:**
  - Added rulebook and conceptual documents for inspection and scheduling logic in `docs/01_Architecture/`.

2026-04-11 12:21:42 +02:00

4.6 KiB

Raw Blame History

Konzept: Zeitplan-Optimierung (Drag & Drop Logik)

Status: ENTWURF | Datum: 11. April 2026 Autor: 🏗️ Lead Architect Kontext: Phase 9 — Zeitplan & Protokollierung

1. Vision & Zielsetzung

Die Zeitplan-Optimierung ist das zentrale Werkzeug für die Meldestelle, um den Turnierablauf dynamisch an die Gegebenheiten vor Ort anzupassen. Ziel ist eine intuitive, visuelle Oberfläche (Kalender-Ansicht), in der Bewerbe und Abteilungen per Drag & Drop verschoben werden können, wobei das System automatisch Auswirkungen auf Folge-Bewerbe berechnet und vor Konflikten warnt.

2. Fachliche Anforderungen (Use Cases)

UC-1: Verschieben eines Bewerbs/einer Abteilung

Ein Benutzer zieht einen Bewerb oder eine Abteilung auf eine neue Startzeit oder einen anderen Austragungsplatz.
System-Reaktion:
- Neuberechnung der Endzeit basierend auf reitdauerMinuten * starterAnzahl + besichtigungMinuten + umbauMinuten.
- Prüfung auf Überschneidungen am selben Austragungsplatz.
- Warnung bei Konflikten (z.B. Richter-Doppelbelegung).

UC-2: Dynamische Zeitplan-Anpassung („Anschließend“)

Bewerbe können als ANSCHLIESSEND markiert werden (beginnZeitTyp).
System-Reaktion: Wenn der vorangehende Bewerb verschoben wird oder länger dauert, verschiebt sich der anschließende Bewerb automatisch mit.

UC-3: Drag & Drop in der Startliste

Innerhalb einer Startliste können Teilnehmer per Drag & Drop umsortiert werden.
System-Reaktion: Automatische Aktualisierung der Kopfnummern (Startnummern) und Neuberechnung der individuellen Startzeiten.

UC-4: Protokollierung (Audit Log)

Jede manuelle Änderung am Zeitplan oder der Startlisten-Reihenfolge muss protokolliert werden.
Grund: Nachvollziehbarkeit bei Einsprüchen und Synchronisation zwischen verschiedenen Arbeitsplätzen (Meldestelle ↔ Richterturm).

3. Datenmodell-Erweiterungen & Logik

3.1 Erweiterung `Bewerb` & `Abteilung`

Das bestehende Modell in entries-domain deckt bereits viele Felder ab. Für die Optimierung präzisieren wir:

Umbauzeit: Zeit zwischen zwei Abteilungen oder Bewerben.
Pausen: Geplante Unterbrechungen (z.B. Mittagspause, Platzpflege) werden als spezielle „Blocker-Events“ im Zeitplan geführt.
BesichtigungsBlock (NEU): Eigenständiges Objekt für Parcoursbesichtigungen.
- Kann mit mehreren Bewerben/Abteilungen verknüpft werden (Cross-Competition Inspection).
- Unterstützt Typen: ZU_FUSS (Standard) und ZU_PFERD (Spezialfall für Springpferde bis 110cm gemäß ÖTO).
- Validierung: Mindestens 5 Min. Puffer vor dem ersten Start (ÖTO §43).

3.2 Zeitberechnungs-Algorithmus (Präzisierung)

Die Logik in StartlistenService.berechneStartzeiten wird erweitert:

Basis: Startzeit der Abteilung.
Vorlauf: besichtigungMinuten.
Starter-Loop:
- individuelleStartzeit = aktuelleZeit.
- aktuelleZeit += bewerb.reitdauerMinuten.
- Neu: Berücksichtigung von festen Pausen nach X Startern (z.B. 10 Min. Pause alle 20 Starter).
Nachlauf: umbauMinuten am Ende der Abteilung/des Bewerbs.

3.3 Drag & Drop Logik (Frontend & Backend)

Frontend (Compose Desktop):
- Implementierung eines DraggableBewerbItem.
- Visuelle Darstellung von Konflikten (Rote Markierung bei Überlappung).
Backend (API):
- Neuer Endpunkt PATCH /bewerbe/{id}/zeitplan für schnelle Updates.
- Validierung der neuen Zeiten gegen den austragungsplatzId und richterEinsaetze.

4. Konflikt-Management

Das System arbeitet nach dem Prinzip „Warnen statt Blockieren“ (ADR-0016):

Harte Fehler: Nur bei technischer Unmöglichkeit (z.B. Datum in der Vergangenheit bei Live-Betrieb).
Warnungen:
- Überlappung auf dem Platz.
- Richter hat gleichzeitig Einsatz in anderem Bewerb.
- Zeitunterschreitung für Reiter (Reiter startet in zwei kurz aufeinanderfolgenden Bewerben).

5. Synchronisation (Offline-First)

Änderungen am Zeitplan erzeugen SyncEvents (gemäß ADR-0022).

Lamport-Uhren: Stellen sicher, dass bei gleichzeitigen Änderungen an zwei Laptops die zeitlich spätere Änderung (oder die mit höherer Priorität) gewinnt.
Echtzeit-Update: Über WebSockets werden Zeitplan-Änderungen sofort an alle verbundenen Clients (z.B. Anzeige-Monitor, Richter-Tablet) gepusht.

6. Nächste Schritte

Backend: ✅ Implementiert (BewerbService, API, Zeitberechnungs-Pausen).
Frontend: Prototyping der Kalender-Ansicht mit Compose Desktop.
QA: Test-Szenarien für komplexe Verschiebungen (Kettenreaktionen bei „Anschließend“).

4.6 KiB Raw Blame History