Stefan Mogeritsch 84128432e3 docs(architecture): add specification for status automaton and time schedule synchronization logic

- Added conceptual documentation detailing the status automaton for handling entry states and its integration with dynamic time schedule adjustments (`status-automat-nennungen-de.md`).
- Updated master roadmap with the completion of the status automaton concept.
- Extended changelog to reflect the addition of the specified architecture document.

2026-04-11 12:28:14 +02:00

2.9 KiB

Raw Blame History

🤖 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:

Billing-Service: Bei ZURUECKGEZOGEN ggf. Stornogebühren prüfen. Bei TRANSFERIERT Guthaben übertragen.
Startlisten-Service: Bei ZURUECKGEZOGEN nach Veröffentlichung der Startliste -> Eintrag als istGestrichen = true markieren.
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)

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

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

2.9 KiB Raw Blame History