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.

CHANGELOG.md

@@ -15,6 +15,15 @@ Versionierung folgt [Semantic Versioning](https://semver.org/lang/de/).
 
 ## [Unreleased]
 
+### Hinzugefügt
+- **Architektur:** Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt (`konzept-zeitplan-optimierung-de.md`).
+- **Architektur:** Spezifikation des Status-Automaten für Nennungen und Synchronisations-Logik (`status-automat-nennungen-de.md`).
+- **Rulebook:** Überprüfung und Spezifikation der Parcoursbesichtigung zu Pferd (§43 ÖTO) inkl. 5-Minuten-Puffer-Regel.
+- **Backend (Entries):** Erweiterung der Domain-Modelle `Bewerb` und `Abteilung` um Besichtigungs- und Pausen-Konfigurationen.
+- **Backend (Entries):** Neues Datenmodell `BesichtigungsBlock` für wettbewerbsübergreifende Parcoursbesichtigungen.
+- **Backend (Entries):** API-Endpunkt `PATCH /bewerbe/{id}/zeitplan` für schnelle Zeitplan-Updates implementiert.
+- **Backend (Entries):** `StartlistenService` um ÖTO-konforme Zeitberechnung (Besichtigungs-Puffer, Pausen-Intervalle) erweitert.
+
 ### Geändert
 - Masterdata/Domain: Umbenennungen zur Vereinheitlichung der Terminologie (DE):
   - `MasterdataLicenseRepository` → `LizenzRepository`

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

docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md

@@ -16,7 +16,7 @@
 | 📜 Rulebook   | ✅ Abgeschlossen  | ✅ B-2 abgeschlossen                      | 🟡 In Arbeit       | Parcoursbesichtigung-Rulebook Check                   |
 | 🐧 DevOps     | ✅ Abgeschlossen  | ✅ Abgeschlossen                          | ✅ C-1/C-2 fertig  | C-3 Produktions-Deployment                            |
 | 🧐 QA         | ✅ Abgeschlossen  | ✅ B-1/B-3 fertig                         | ⬜ Nicht gestartet | B-2 Onboarding-Tests                                  |
-| 🖌️ UI/UX     | ✅ Abgeschlossen  | 🔴 B-1/B-4 offen                         | ⬜ Nicht gestartet | B-4 Wireframes für Kassa-Screen                       |
+| 🖌️ UI/UX     | ✅ Abgeschlossen  | ✅ B-1/B-4 fertig                         | ⬜ Nicht gestartet | C-1 Wireframes in Compose umsetzen    |
 | 🧹 Curator    | ✅ Abgeschlossen  | ✅ B-1/B-2 fertig                         | ⬜ Nicht gestartet | Session-Dokumentation & Changelog                     |
 
 ---
@@ -27,7 +27,6 @@ Diese Aufgaben blockieren andere Agenten und müssen zuerst erledigt werden:
 
 | Priorität | Agent         | Aufgabe                                       | Blockiert                                         |
 |-----------|---------------|-----------------------------------------------|---------------------------------------------------|
-| 🔴 P1     | 🖌️ UI/UX     | B-4: Wireframes für Kassa-Screen              | 🎨 Frontend: B-4 Kassa-Screen                     |
 | 🔴 P1     | 🎨 Frontend   | B-2: StoreV2-Ablösung                         | 🧐 QA: B-4 ViewModel-Tests                        |
 
 ---
@@ -73,7 +72,8 @@ Diese Aufgaben blockieren andere Agenten und müssen zuerst erledigt werden:
 ### 🖌️ UI/UX Designer
 
 1. ✅ **B-1** Entscheidung Editier-Formulare
-2. 🔴 **B-4** Wireframes für Kassa-Screen (Veranstaltungs-Kassa)
+2. ✅ **B-3** Wireframes für Kassa-Screen (Veranstaltungs-Kassa)
+3. ✅ **B-4** Empty States Spezifikation
 
 ### 🧹 Curator