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.

docs/01_Architecture/MASTER_ROADMAP.md

@@ -232,6 +232,7 @@ und über definierte Schnittstellen kommunizieren.
 *   [x] **Entries-Integration:** Automatische Buchung von Nenngeldern bei Nennungs-Abgabe. ✓
 *   [x] **ZNS-Importer:** Hardening & Integrationstests für Funktionärs-Updates. ✓
 *   [x] **Konzept:** Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt. ✓
+*   [x] **Konzept:** Status-Automat für Nennungen & Zeitplan-Synchronisation spezifiziert. ✓
 *   [ ] **Zeitplan:** Dynamische Verschiebung von Bewerben (Drag & Drop im Kalender).
 *   [ ] **Protokoll:** Implementierung eines Event-Logs für manuelle Eingriffe in Startlisten.
 *   [ ] **Export:** Startlisten-Export für ZNS (XML-B-Satz).
@@ -290,3 +291,4 @@ und über definierte Schnittstellen kommunizieren.
 | Masterdata Operations     | `backend/services/masterdata/docs/runbooks/masterdata-ops.md`                                |
 | Zeitplan-Optimierung      | `docs/01_Architecture/konzept-zeitplan-optimierung-de.md`                                   |
 | Parcoursbesichtigung-Rulebook | `docs/01_Architecture/rulebook-check-parcoursbesichtigung-de.md`                       |
+| Status-Automat-Nennungen  | `docs/01_Architecture/status-automat-nennungen-de.md`                                       |

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

@@ -0,0 +1,51 @@
+# 🤖 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