Stefan Mogeritsch
84128432e3
- 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.
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# 🤖 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
|