meldestelle/docs/01_Architecture/Concepts/status-automat-nennungen-de.md

🤖 Konzept: Status-Automat für Nennungen & Zeitplan-Synchronisation

Dieses Dokument spezifiziert die Logik des Status-Automaten für Nennungen (Sprint C-1) und dessen Auswirkungen auf den dynamischen Zeitplan.

1. Status-Definitionen (NennStatusE)

Basierend auf core-domain/Enums.kt:

Status	Bedeutung	Auswirkung auf Zeitplan
EINGEGANGEN	Nennung wurde erstellt (Initialzustand)	Belegt Zeitslot (basierend auf reitdauerMinuten)
BESTAETIGT	Meldestelle hat Nennung geprüft	Belegt Zeitslot
NACHNENNUNG	Nennung nach Nennschluss	Belegt Zeitslot (ggf. am Ende der Liste)
TRANSFERIERT	Nennung wurde auf anderes Paar übertragen	Inaktiv (Original-Eintrag wird durch neuen ersetzt)
ZURUECKGEZOGEN	Reiter hat abgemeldet (vor Startlistenerstellung)	Inaktiv (Slot wird frei)
GESTARTET	Paar ist in die Prüfung eingeritten	Startzeitpunkt fixiert, Folgestarts ggf. anpassen
NICHT_ANGETRETEN	Paar ist zum Startzeitpunkt nicht erschienen	Zeitslot verfällt oder Folgestarts rücken nach

2. Status-Übergänge & Validierung

2.1 Gültige Übergänge (Beispiele)

• EINGEGANGEN -> BESTAETIGT (Normalfall)
• EINGEGANGEN -> ZURUECKGEZOGEN (Abmeldung)
• BESTAETIGT -> TRANSFERIERT (Reitertausch)
• BESTAETIGT -> GESTARTET (Während des Turniers)

2.2 Side-Effects (Side-Effect-Engine)

Wenn sich der Status einer Nennung ändert, müssen folgende Systeme informiert werden:

1. Billing-Service: Bei ZURUECKGEZOGEN ggf. Stornogebühren prüfen. Bei TRANSFERIERT Guthaben übertragen.
2. Startlisten-Service: Bei ZURUECKGEZOGEN nach Veröffentlichung der Startliste -> Eintrag als istGestrichen = true markieren.
3. Zeitplan-Optimierung: Bei NICHT_ANGETRETEN -> Alle folgenden Startzeiten rücken um reitdauerMinuten nach vorne (sofern im Kalender-Modus "Dynamisch" aktiv ist).

3. Dynamische Zeitplan-Anpassung (C-1 Extension)

Der StartlistenService muss eine Methode aktualisiereZeitplanNachStatusAenderung erhalten:

• Szenario A (Nicht angetreten): Wenn Nennung X NICHT_ANGETRETEN wird, rücken alle folgenden Nennungen in der Abteilung nach vorne.
• Szenario B (Verspätung): Wenn Nennung X GESTARTET wird, aber 2 Minuten später als geplant, verschieben sich alle Folgetermine um +2 Minuten (Kettenreaktion).

Puffer-Regel (ÖTO-Konformität)

• Eine dynamische Verschiebung nach vorne darf nie dazu führen, dass ein Reiter vor seiner ursprünglich kommunizierten Startzeit (oder einem definierten Puffer-Zeitraum von z.B. 15 Minuten) starten muss, ohne dass dies explizit bestätigt wurde.

4. Implementierungs-Leitfaden für Backend (C-1)

1. Erweiterung von NennungUseCases.statusAendern um Aufrufe der Side-Effect-Handler.
2. Implementierung des NennungStatusListener in entries-service.
3. Anbindung an den StartlistenService zur Zeitre-Kalkulation.

---

Status: Entwurf (Lead Architect) Datum: 11. April 2026