docs(roadmaps): add sprint execution order and detailed role-specific roadmaps

- Added `SPRINT_EXECUTION_ORDER.md` to define the cross-role sprint step sequence. - Created individual roadmaps for Architect, Backend, Frontend, DevOps, Rulebook, QA, UI/UX, and Curator. - Captured developer responsibilities, dependencies, and timelines for Sprints A–C. - Aligned sprint planning documentation with session log agreements. - Provided structured documentation in `docs/04_Agents/Roadmaps/`. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-02 14:35:40 +02:00
parent 1a695df60b
commit 7e16b3f318
15 changed files with 1588 additions and 0 deletions
@@ -0,0 +1,57 @@
+# 🏗️ [Lead Architect] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Strategie, Architektur-Entscheidungen (ADRs), Domänen-Modell, Master-Roadmap
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | ADR-0021 schreiben: Tenant-Resolution-Strategie
+  - [ ] Optionen analysieren: Schema-per-Tenant vs. Tenant-ID in allen Tabellen
+  - [ ] Entscheidung treffen und begründen
+  - [ ] ADR-0021 in `docs/01_Architecture/ADRs/` ablegen
+  - [ ] Backend Developer informieren (A-3 ist Blocker)
+
+- [ ] **A-2** | Domänen-Modell formal präzisieren
+  - [ ] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` als offizielles Modell festschreiben
+  - [ ] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier) ins Modell aufnehmen
+  - [ ] Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo modellieren
+  - [ ] Abteilungs-Typen `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` ins Modell aufnehmen
+  - [ ] Curator beauftragen: `Ubiquitous_Language.md` aktualisieren
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | ADR für LAN-Sync-Protokoll schreiben
+  - [ ] Optionen analysieren: Event-Sourcing vs. CRDT vs. Timestamp-Sync
+  - [ ] Entscheidung für Meldestelle ↔ Richter-Turm Sync treffen
+  - [ ] ADR in `docs/01_Architecture/ADRs/` ablegen
+
+> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Synchronisations-Protokoll-Konzeption starten
+  - [ ] Offline-First-Konzept für Desktop ↔ Backend ausarbeiten
+  - [ ] Conflict-Resolution-Strategie definieren (was passiert bei gleichzeitigen Änderungen?)
+  - [ ] Ergebnis als Konzept-Dokument in `docs/01_Architecture/` ablegen
+
+- [ ] **C-2** | MASTER_ROADMAP aktualisieren
+  - [ ] Desktop-App-Fokus eintragen
+  - [ ] Tenant-Isolation-Meilensteine eintragen
+  - [ ] Offline-Sync-Meilensteine eintragen
+  - [ ] Sprint A/B/C Ergebnisse als "erledigt" markieren
+
+---
+
+## 📌 Abhängigkeiten
+
+| Meine Aufgabe        | Blockiert wen                                            |
+|----------------------|----------------------------------------------------------|
+| ADR-0021 (A-1)       | 👷 Backend: Tenant-Isolation (Backend Sprint A)          |
+| Domänen-Modell (A-2) | 👷 Backend: Schema-Design; 🎨 Frontend: ViewModel-Design |
+| LAN-Sync ADR (B-1)   | 🎨 Frontend: Sync-UI; 👷 Backend: Sync-Endpunkte         |
@@ -0,0 +1,96 @@
+# 👷 [Backend Developer] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Spring Boot / Ktor, Kotlin, SQL, API-Design, Datenbankschema, Services
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+> ⚠️ **Warten auf ADR-0021 vom Architect** bevor A-1 beginnt!
+
+- [ ] **A-1** | Tenant-Isolation im Datenzugriffs-Layer implementieren
+  - [ ] ADR-0021 (Architect) lesen und Strategie übernehmen
+  - [ ] Tenant-Resolution-Mechanismus implementieren (wie erkennt das Backend die Ziel-Datenbank?)
+  - [ ] Alle Datenzugriffe mit Tenant-Kontext absichern
+  - [ ] Sicherstellen: Kein Cross-Tenant-Datenzugriff möglich
+
+- [ ] **A-2** | Datenbankschema: Domänen-Hierarchie umsetzen
+  - [ ] Tabelle `veranstaltungen` anlegen (interne ID, Tenant-Grenze)
+  - [ ] Tabelle `turniere` anlegen (FK → `veranstaltung_id`, OEPS-Turniernummer als eigenes Feld)
+  - [ ] Tabelle `bewerbe` anlegen (FK → `turnier_id`, Klasse, Höhe, Bezeichnung)
+  - [ ] Tabelle `abteilungen` anlegen (FK → `bewerb_id`, `nr`, `bezeichnung`,
+    `typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`)
+  - [ ] Tabelle `teilnehmer_konten` anlegen (FK → `veranstaltung_id`, aggregiert Salden über Turniere)
+  - [ ] Tabelle `turnier_kassa` anlegen (FK → `turnier_id`, separate Kassa pro Turnier)
+  - [ ] Migrations-Skript schreiben und testen
+
+- [ ] **A-3** | Validierungs-Grundlage: Turnierkategorie-Limits
+  - [ ] `Turnier.validate()`: Bewerbs-Klassen gegen Limits der Turnierkategorie prüfen (z.B. kein S-Springen auf
+    C-Turnier)
+  - [ ] Voraussetzung: Spezifikation von 📜 Rulebook Expert (A-5) abwarten
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | CRUD-Endpunkte für alle Stammdaten-Entitäten
+  - [ ] `POST/GET/PUT/DELETE /veranstaltungen`
+  - [ ] `POST/GET/PUT/DELETE /turniere` (inkl. Status-Feld: `DRAFT | PUBLISHED`)
+  - [ ] `POST/GET/PUT/DELETE /bewerbe`
+  - [ ] `POST/GET/PUT/DELETE /abteilungen`
+  - [ ] `POST/GET/PUT/DELETE /reiter`
+  - [ ] `POST/GET/PUT/DELETE /pferde`
+  - [ ] `POST/GET/PUT/DELETE /vereine`
+  - [ ] `POST/GET/PUT/DELETE /funktionaere`
+
+- [ ] **B-2** | Kassa-Service implementieren
+  - [ ] `TeilnehmerKonto`-Service: Saldo aus mehreren Turnieren aggregieren
+  - [ ] `Zahlvorgang`-Service: Eine Zahlung auf Veranstaltungs-Ebene buchen
+  - [ ] Rechnungs-Generierung: Separate Rechnung je Turnier aus einem Zahlvorgang
+  - [ ] Endpunkte: `GET /veranstaltungen/{id}/kassa/saldo`, `POST /veranstaltungen/{id}/zahlvorgaenge`
+
+- [ ] **B-3** | ÖTO-Validierung serverseitig absichern
+  - [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) umsetzen
+  - [ ] OEPS-Nummern-Format validieren
+  - [ ] FEI-ID-Format validieren
+  - [ ] Lizenzklassen-Validierung (R1–R4, LZF)
+  - [ ] Altersklassen-Kompatibilität Pferd × Bewerb validieren
+  - [ ] Abteilungs-Zwangsteilung im CSN-C-NEU durchsetzen (Bewerb ≤95cm: ohne/mit Lizenz; ≥100cm: R1/R2+)
+
+- [ ] **B-4** | Nennungs-Service (Grundstruktur)
+  - [ ] Tabelle `nennungen` anlegen (FK → `abteilung_id`, Status: `NEU | GEPRÜFT | BESTÄTIGT | ABGELEHNT`)
+  - [ ] `POST /turniere/{id}/nennungen` — Nennungs-Eingang vom Web-Formular
+  - [ ] `GET /turniere/{id}/nennungen` — Postfach für Desktop-App (Meldestelle)
+  - [ ] `PATCH /nennungen/{id}/status` — Bestätigen / Ablehnen
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Testdaten-Seeder implementieren
+  - [ ] Reproduzierbare Veranstaltung mit 2 Turnieren (Neumarkt-Szenario)
+  - [ ] Bewerbe mit korrekten Abteilungen (inkl. CSN-C-NEU Pflicht-Teilung)
+  - [ ] Reiter, Pferde, Vereine als Stammdaten
+  - [ ] Nennungen in verschiedenen Status-Stufen
+  - [ ] Seeder via Gradle-Task ausführbar
+
+- [ ] **C-2** | Statistik-Endpunkte
+  - [ ] `GET /turniere/{id}/statistiken` — Statistiken pro Turnier
+  - [ ] `GET /veranstaltungen/{id}/statistiken` — Aggregierte Statistiken über alle Turniere
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf                                      | Von wem            |
+|------------------------------------------------|--------------------|
+| ADR-0021 (Tenant-Strategie)                    | 🏗️ Architect      |
+| Validierungs-Spezifikation (OEPS, FEI, Lizenz) | 📜 Rulebook Expert |
+| Domänen-Modell final                           | 🏗️ Architect      |
+
+| Meine Aufgabe          | Ermöglicht wem                 |
+|------------------------|--------------------------------|
+| CRUD-Endpunkte (B-1)   | 🎨 Frontend: Backend-Anbindung |
+| Kassa-Service (B-2)    | 🎨 Frontend: Kassa-Screen      |
+| Nennungs-Service (B-4) | 🎨 Frontend: Nennungs-Postfach |
@@ -0,0 +1,96 @@
+# 🧹 [Curator] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Dokumentation, Session-Logs, Reports, Aufräumen, Wissens-Management
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect)
+  - [ ] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` eintragen
+  - [ ] `Abteilung` als eigenständigen Begriff definieren (kleinste ausführbare Einheit)
+  - [ ] `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` als Abteilungs-Typen definieren
+  - [ ] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier-Aggregation) eintragen
+  - [ ] `Veranstaltungs-Kassa` und `TurnierKassa` als separate Begriffe definieren
+  - [ ] `Zahlvorgang` (eine Zahlung, mehrere Rechnungen) definieren
+
+- [ ] **A-2** | Event-First-Workflow dokumentieren
+  - [ ] Ablauf: Veranstaltung anlegen → Turnier anlegen → Bewerbe anlegen → Abteilungen → Startliste
+  - [ ] Dokument in `docs/01_Architecture/` oder `docs/02_Guides/` ablegen
+
+- [ ] **A-3** | Navigation-V2 dokumentieren
+  - [ ] Aktuellen Screen-Baum und Back-Stack-Verhalten beschreiben
+  - [ ] Dokument in `docs/06_Frontend/` ablegen
+
+- [ ] **A-4** | Tenant-Konzept dokumentieren (nach ADR-0021 vom Architect)
+  - [ ] ADR-0021 in `docs/01_Architecture/ADRs/` verlinken
+  - [ ] Konzept "eine Veranstaltung = eine Datenbank (Tenant)" in Laien-Sprache erklären
+  - [ ] Auswirkungen auf Schema, API und Frontend zusammenfassen
+
+- [ ] **A-5** | Session-Log für heutige Besprechung (2. April 2026) erstellen
+  - [ ] Alle Beschlüsse der Meldestelle-Besprechung eintragen
+  - [ ] Domänen-Korrekturen (Abteilung, Kassa, Veranstaltungs-Hierarchie) festhalten
+  - [ ] Zurückgestellte Themen (USB-Fallback, Web-App, Nenn-System) als ⏸️ markieren
+  - [ ] Log in `docs/99_Journal/` ablegen
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | Roadmaps-Verzeichnis pflegen
+  - [ ] Alle 8 Roadmap-Dateien in `docs/04_Agents/Roadmaps/` auf Vollständigkeit prüfen
+  - [ ] Abgeschlossene Aufgaben in den Roadmaps als `[x]` markieren (nach Rückmeldung der Teams)
+
+- [ ] **B-2** | `docs/05_Backend/` aktualisieren
+  - [ ] Neues Datenbankschema (Tabellen: veranstaltungen, turniere, bewerbe, abteilungen) dokumentieren
+  - [ ] API-Endpunkte-Übersicht aktualisieren sobald Backend Sprint B abgeschlossen
+
+- [ ] **B-3** | `docs/06_Frontend/` aktualisieren
+  - [ ] ViewModel-Architektur-Muster (MVVM/UDF) dokumentieren (nach Frontend Sprint A)
+  - [ ] Verweis auf `VeranstalterViewModel` als Referenz-Implementierung
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | `README.md` aktualisieren
+  - [ ] Desktop-App als primären Fokus hervorheben
+  - [ ] Schnellstart-Anleitung für lokale Entwicklungsumgebung prüfen und aktualisieren
+  - [ ] Veraltete Abschnitte (V1-Referenzen) entfernen oder als deprecated markieren
+
+- [ ] **C-2** | Setup-Guide aktualisieren
+  - [ ] Schritt-für-Schritt-Anleitung: Projekt klonen → Docker starten → Desktop-App starten
+  - [ ] Voraussetzungen (JDK, Gradle, Docker) mit genauen Versionen dokumentieren
+  - [ ] Dokument in `docs/02_Guides/` ablegen
+
+- [ ] **C-3** | Unterordner-Struktur in `docs/` einführen (falls erforderlich)
+  - [ ] Aktuelle Struktur analysieren: Gibt es überladene Verzeichnisse?
+  - [ ] Vorschlag für saubere Unterordner-Struktur erstellen
+  - [ ] Mit Architect abstimmen und umsetzen
+
+- [ ] **C-4** | V1-Code-Bereinigung koordinieren
+  - [ ] Alle V1-Dateien und -Module identifizieren (gemeinsam mit Frontend + Backend)
+  - [ ] Bereinigungsplan erstellen: Was kann gelöscht werden, was muss migriert werden?
+  - [ ] Bereinigung koordinieren und dokumentieren
+
+- [ ] **C-5** | Reports-Verzeichnis pflegen
+  - [ ] Nach Sprint A, B, C: Kurzberichte von allen Entwicklern einsammeln
+  - [ ] In `docs/90_Reports/` archivieren
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf                   | Von wem                 |
+|-----------------------------|-------------------------|
+| ADR-0021 (Tenant-Strategie) | 🏗️ Architect — für A-4 |
+| Domänen-Modell final        | 🏗️ Architect — für A-1 |
+| ViewModel-Referenz          | 🎨 Frontend — für B-3   |
+| Neues DB-Schema             | 👷 Backend — für B-2    |
+
+| Meine Aufgabe                  | Ermöglicht wem                                    |
+|--------------------------------|---------------------------------------------------|
+| `Ubiquitous_Language.md` (A-1) | Alle: gemeinsames Vokabular, kein Missverständnis |
+| Session-Log (A-5)              | Alle: Nachvollziehbarkeit der Beschlüsse          |
+| README + Setup-Guide (C-1/C-2) | Neue Entwickler: sofortiger Einstieg ins Projekt  |
@@ -0,0 +1,74 @@
+# 🐧 [DevOps Engineer] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | Docker-Compose-Setup auf aktuellen Stand bringen
+  - [ ] Alle Services (Backend, DB, Infra) in `docker-compose.yaml` / `dc-*.yaml` prüfen
+  - [ ] Sicherstellen: Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
+  - [ ] Healthchecks für alle Services definieren
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | CI/CD Pipeline für Compose Desktop Tests (headless)
+  - [ ] GitHub Actions / Gitea Actions Workflow anlegen
+  - [ ] Headless-Umgebung für Compose Desktop Tests konfigurieren (Xvfb oder virtueller Framebuffer)
+  - [ ] Gradle-Task für Desktop-Tests in Pipeline integrieren
+  - [ ] Build-Artefakte (JAR / native Binaries) als Pipeline-Ausgabe speichern
+  - [ ] Fehlgeschlagene Tests als Build-Blocker konfigurieren
+
+- [ ] **B-2** | Gradle-Build-Optimierungen
+  - [ ] Build-Cache aktivieren und prüfen
+  - [ ] Parallele Modul-Builds konfigurieren
+  - [ ] Gradle-Wrapper-Version auf aktuellen Stand bringen
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Desktop-App Packaging konfigurieren
+  - [ ] `compose.desktop.nativeDistributions` in `build.gradle.kts` konfigurieren
+  - [ ] Windows: `.msi`-Installer bauen
+  - [ ] Linux: `.deb`-Paket bauen
+  - [ ] macOS: `.dmg`-Image bauen (falls erforderlich)
+  - [ ] App-Icon und Metadaten (Name, Version, Publisher) eintragen
+  - [ ] Testinstallation auf Ziel-Betriebssystem durchführen
+
+- [ ] **C-2** | Semantic Versioning einführen
+  - [ ] Versionierungsschema definieren: `MAJOR.MINOR.PATCH`
+  - [ ] Gemeinsame Versions-Quelle für Client (Frontend) und Server (Backend) festlegen
+  - [ ] Git-Tagging-Strategie definieren (`v1.0.0`, `v1.0.0-backend`, etc.)
+  - [ ] Release-Tagging in CI/CD-Pipeline integrieren
+  - [ ] `CHANGELOG.md` Vorlage anlegen
+
+- [ ] **C-3** | Produktions-Deployment vorbereiten
+  - [ ] Reverse-Proxy-Konfiguration (Nginx / Traefik) für Backend prüfen
+  - [ ] HTTPS-Zertifikat-Management dokumentieren
+  - [ ] Backup-Strategie für Produktionsdatenbanken definieren
+
+---
+
+## ⏸️ Zurückgestellt
+
+> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt
+> ⏸️ **Web-App Deployment** — Wird erst nach Desktop-App (Sprint A+B) gestartet
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf               | Von wem          |
+|-------------------------|------------------|
+| Headless-Test-Strategie | 🧐 QA Specialist |
+
+| Meine Aufgabe             | Ermöglicht wem                         |
+|---------------------------|----------------------------------------|
+| CI/CD Pipeline (B-1)      | 🧐 QA: Automatisierte Test-Ausführung  |
+| Desktop-Packaging (C-1)   | Alle: Auslieferbare Desktop-App        |
+| Semantic Versioning (C-2) | Alle: Koordiniertes Release-Management |
@@ -0,0 +1,87 @@
+# 🎨 [Frontend Expert] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** KMP, Compose Desktop, State-Management, MVVM/UDF, Backend-Anbindung
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | ViewModel-Architektur definieren und Referenz-Implementierung umsetzen
+  - [ ] MVVM mit UDF (Unidirectional Data Flow) als verbindliches Muster festlegen
+  - [ ] `Intent`- und `State`-Klassen-Struktur definieren (Vorlage für alle anderen ViewModels)
+  - [ ] `VeranstalterViewModel` als vollständige Referenz-Implementierung umsetzen
+    - [ ] `State`-Klasse definieren
+    - [ ] `Intent`-Klasse (Sealed Class) definieren
+    - [ ] Business-Logik aus Composables herausziehen (keine `StoreV2`-Aufrufe mehr direkt in `onSaved`)
+    - [ ] Lokalen `remember`-State durch ViewModel-State ersetzen
+  - [ ] Ergebnis als Muster-Dokument in `docs/06_Frontend/` ablegen
+
+- [ ] **A-2** | Abteilungs-Logik im Bewerb-Dialog berücksichtigen
+  - [ ] Beim Anlegen eines Bewerbs: Abteilungs-Auswahl als Teil des Dialogs
+  - [ ] CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung (ohne/mit Lizenz; R1/R2+)
+  - [ ] Abteilungs-Typ setzen: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH`
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | ViewModels für alle V2-Screens umsetzen
+  - [ ] `TurnierViewModel`
+  - [ ] `BewerbViewModel` (inkl. Abteilungs-Logik)
+  - [ ] `PferdProfilViewModel`
+  - [ ] `ReiterProfilViewModel`
+  - [ ] `VereinsViewModel`
+  - [ ] `FunktionaerViewModel`
+  - [ ] `AbteilungViewModel` (Startliste, Ergebnisse)
+
+- [ ] **B-2** | Ktor-Clients und Repositories für Backend-Anbindung vorbereiten
+  - [ ] Ktor-HTTP-Client konfigurieren (BaseURL, Auth-Header, Timeout)
+  - [ ] Repository-Interface je Entität definieren (ermöglicht späteres Austauschen von Mock → Real)
+  - [ ] `VeranstalterRepository` mit echtem Backend-Client implementieren
+  - [ ] `TurnierRepository` implementieren
+  - [ ] `BewerbRepository` implementieren
+  - [ ] `AbteilungRepository` implementieren
+  - [ ] `StoreV2` schrittweise durch echte Repositories ersetzen
+
+- [ ] **B-3** | Validierungs-Live-Feedback in Edit-Dialogen
+  - [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) als Basis nutzen
+  - [ ] OEPS-Nummer: Inline-Validierung beim Tippen
+  - [ ] FEI-ID: Inline-Validierung beim Tippen
+  - [ ] Lizenzklasse × Bewerbs-Klasse: Warnung wenn nicht erlaubt
+  - [ ] Altersklasse Pferd: Warnung wenn nicht kompatibel
+
+- [ ] **B-4** | Kassa-Screen: Veranstaltungs-Kassa implementieren
+  - [ ] Gesamt-Saldo-Ansicht (Salden aus allen Turnieren der Veranstaltung)
+  - [ ] Turnier-übergreifender Zahlvorgang (eine Zahlung, mehrere Rechnungen)
+  - [ ] Rechnungsvorschau je Turnier
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Mock-Store (`StoreV2`) vollständig ablösen
+  - [ ] Alle verbleibenden `StoreV2`-Referenzen durch echte Repositories ersetzen
+  - [ ] `StoreV2` nach vollständiger Ablösung entfernen oder als `@Deprecated` markieren
+
+- [ ] **C-2** | LAN-Sync-UI vorbereiten (nach ADR von Architect)
+  - [ ] Verbindungsstatus-Anzeige (Online/Offline/LAN)
+  - [ ] Sync-Trigger manuell und automatisch
+
+> ⏸️ **USB-Stick Fallback (Export/Import UI)** — Separate Besprechung zu einem späteren Zeitpunkt
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf                        | Von wem            |
+|----------------------------------|--------------------|
+| Domänen-Modell final (Abteilung) | 🏗️ Architect      |
+| CRUD-Endpunkte                   | 👷 Backend         |
+| Validierungs-Spezifikation       | 📜 Rulebook Expert |
+| Wireframes Edit-Formulare        | 🖌️ UI/UX Designer |
+
+| Meine Aufgabe            | Ermöglicht wem                                |
+|--------------------------|-----------------------------------------------|
+| ViewModel-Referenz (A-1) | Alle anderen ViewModels folgen diesem Muster  |
+| Ktor-Repositories (B-2)  | Ablösung von StoreV2, echte Daten im Frontend |
@@ -0,0 +1,88 @@
+# 🧐 [QA Specialist] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Test-Strategie, Edge-Cases, Regressions-Tests, Qualitätssicherung
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | Test-Strategie für Desktop-App definieren
+  - [ ] Testpyramide für Compose Desktop festlegen (Unit / Integration / UI-Tests)
+  - [ ] Tooling entscheiden: `kotlin.test`, Compose UI Test, Mockk
+  - [ ] Test-Konventionen dokumentieren (Namensschema, Ordnerstruktur, Arrange-Act-Assert)
+  - [ ] Dokument in `docs/06_Frontend/` oder `docs/07_Infrastructure/` ablegen
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | Test-Suite: V2-Navigation und Back-Stack
+  - [ ] Navigations-Flows für alle V2-Screens abdecken (vorwärts + zurück)
+  - [ ] Back-Stack-Verhalten testen (korrekter Zustand nach Zurück-Navigation)
+  - [ ] Deep-Link / direkter Screen-Aufruf testen (falls implementiert)
+
+- [ ] **B-2** | Test-Suite: Onboarding-Wizard Edge-Cases
+  - [ ] Leere Pflichtfelder → Button bleibt deaktiviert
+  - [ ] Schnelles wiederholtes Klicken auf „Weiter" / „Speichern" → kein doppelter Submit
+  - [ ] Abbrechen mitten im Wizard → kein inkonsistenter Zustand
+  - [ ] Ungültige Eingaben (z.B. falsches OEPS-Nummern-Format) → Fehlermeldung sichtbar
+
+- [ ] **B-3** | Test-Suite: Abteilungs-Logik
+  - [ ] CSN-C-NEU Bewerb ≤95cm: Pflicht-Teilung `ohne Lizenz` / `mit Lizenz` wird erzwungen
+  - [ ] CSN-C-NEU Bewerb ≥100cm: Pflicht-Teilung `R1` / `R2+` wird erzwungen
+  - [ ] Organisatorische Abteilung: Gesamtrangliste wird korrekt zusammengeführt
+  - [ ] Separate Siegerehrung: Abteilungen werden nicht zusammengeführt
+
+- [ ] **B-4** | Test-Suite: ViewModel-Verhalten (nach Frontend Sprint A)
+  - [ ] State-Initialisierung korrekt
+  - [ ] Intent → State-Transition für alle definierten Intents
+  - [ ] Fehler-State bei Backend-Fehler korrekt gesetzt
+  - [ ] Loading-State während asynchroner Operationen
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Test-Suite: Mandanten-Isolation
+  - [ ] Veranstaltung A kann keine Daten von Veranstaltung B lesen
+  - [ ] Veranstaltung A kann keine Daten in Veranstaltung B schreiben
+  - [ ] Turnier-übergreifender Kassa-Zugriff nur innerhalb derselben Veranstaltung möglich
+
+- [ ] **C-2** | Test-Suite: Kassa und Zahlvorgang
+  - [ ] Teilnehmer an 2 Turnieren → 1 Zahlvorgang → 2 korrekte separate Rechnungen
+  - [ ] Saldo-Berechnung korrekt (Summe aus beiden Turnier-Kassas)
+  - [ ] Bereits bezahlte Beträge werden nicht doppelt verrechnet
+
+- [ ] **C-3** | Test-Suite: ÖTO-Validierung (nach Rulebook Sprint A-5)
+  - [ ] OEPS-Nummer: Gültige und ungültige Formate testen
+  - [ ] FEI-ID: Gültige und ungültige Formate testen
+  - [ ] Lizenzklasse × Bewerbs-Klasse: Alle erlaubten und verbotenen Kombinationen
+  - [ ] Altersklasse Pferd × Bewerb: Grenzfälle (genau im Grenzjahr)
+
+- [ ] **C-4** | Regressions-Test-Suite aufbauen
+  - [ ] Kritische User-Flows als automatisierte Tests abdecken
+  - [ ] Tests in CI/CD-Pipeline integrieren (gemeinsam mit 🐧 DevOps)
+
+---
+
+## ⏸️ Zurückgestellt
+
+> ⏸️ **USB-Stick Fallback Tests** — Separate Besprechung zu einem späteren Zeitpunkt
+> ⏸️ **Nennungs-Workflow End-to-End Test (Web → Backend → Desktop)** — Nach Web-App Besprechung
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf                          | Von wem            |
+|------------------------------------|--------------------|
+| ViewModel-Referenz-Implementierung | 🎨 Frontend        |
+| Validierungs-Spezifikation         | 📜 Rulebook Expert |
+| CI/CD Pipeline (headless)          | 🐧 DevOps          |
+| Testdaten-Seeder                   | 👷 Backend         |
+
+| Meine Aufgabe        | Ermöglicht wem                                  |
+|----------------------|-------------------------------------------------|
+| Test-Strategie (A-1) | 🐧 DevOps: korrekte Pipeline-Konfiguration      |
+| Alle Test-Suites     | Alle: Vertrauen in Codequalität und Korrektheit |
@@ -0,0 +1,88 @@
+# 📜 [ÖTO/FEI Rulebook Expert] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, ÖTO/FEI Compliance
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | Validierungsregeln schriftlich spezifizieren — Grundlage für alle anderen Teams
+  - [ ] **OEPS-Mitgliedsnummer**
+    - [ ] Gültiges Format definieren (Länge, erlaubte Zeichen, Präfixe)
+    - [ ] Ungültige Beispiele dokumentieren
+  - [ ] **FEI-ID**
+    - [ ] Gültiges Format definieren
+    - [ ] Wann ist FEI-ID Pflicht? (Turnierkategorie-abhängig)
+    - [ ] Ungültige Beispiele dokumentieren
+  - [ ] **Lizenzklassen (R1–R4, RD1–RD3, LZF)**
+    - [ ] Vollständige Liste aller gültigen Lizenzklassen
+    - [ ] Welche Lizenz erlaubt welche Bewerbsklasse? (Zuordnungstabelle Springen + Dressur)
+  - [ ] **Altersklassen Pferd**
+    - [ ] Mindestalter je Bewerbsklasse / Höhe (Springen + Dressur)
+    - [ ] Berechnungsregel: Stichtag für Pferdealter (1. Jänner des Geburtsjahres)
+  - [ ] Ergebnis als Dokument `docs/03_Domain/02_Reference/Validierungsregeln.md` ablegen
+
+- [ ] **A-2** | Abteilungs-Zwangsteilungsregeln vollständig spezifizieren
+  - [ ] CSN-C-NEU: Bewerb ≤95cm → `ohne Lizenz` | `mit Lizenz` (§ 231 ÖTO)
+  - [ ] CSN-C-NEU: Bewerb ≥100cm → `R1` | `R2 und höher` (§ 231 ÖTO)
+  - [ ] Gibt es weitere Pflicht-Teilungsregeln in anderen Kategorien? (CDN, CCN prüfen)
+  - [ ] Ergebnis in `TURNIER_KLASSEN.md` ergänzen
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | Validierungs-Implementierung Frontend begleiten
+  - [ ] Spezifikation aus Sprint A-1 an 🎨 Frontend übergeben
+  - [ ] Implementierung prüfen: Entspricht die Live-Validierung den Regelwerks-Anforderungen?
+  - [ ] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit prüfen
+
+- [ ] **B-2** | Validierungs-Implementierung Backend begleiten
+  - [ ] Spezifikation aus Sprint A-1 an 👷 Backend übergeben
+  - [ ] Serverseitige Validierung prüfen: Werden alle Regeln korrekt durchgesetzt?
+  - [ ] Grenzfälle definieren und an 🧐 QA weitergeben
+
+- [ ] **B-3** | Bewerbs-Typen und Bewertungslogik dokumentieren
+  - [ ] Stilspringen: Berechnungsformel Grundnote − Abzüge dokumentieren (§ 204 ÖTO)
+  - [ ] Dressurreiterprüfung: Bewertungskriterien dokumentieren (§ 103 ÖTO)
+  - [ ] Reihungsregeln bei Punktgleichheit dokumentieren
+  - [ ] Ergebnis: `REITER_PRUEFUNGEN.md` aktualisieren / vervollständigen
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen
+  - [ ] Alle Altersklassen-Grenzen aus dem Regelwerk extrahieren
+  - [ ] Testfälle für Grenzjahre definieren (z.B. Pferd born Jan vs. Dez)
+  - [ ] Testfälle an 🧐 QA übergeben
+
+- [ ] **C-2** | Funktionärs-Qualifikationen als Enum spezifizieren
+  - [ ] Alle Funktionärs-Typen auflisten (Richter, Parcourschef, Veterinär, etc.)
+  - [ ] Qualifikationsstufen je Typ definieren (z.B. Richter: Regional, National, International)
+  - [ ] Zuordnung: Welche Qualifikation ist für welche Turnierkategorie Pflicht?
+  - [ ] Ergebnis als Enum-Vorlage für 👷 Backend bereitstellen
+
+- [ ] **C-3** | ZNS-Export-Compliance prüfen
+  - [ ] ZNS-Dateiformat auf Aktualität (ÖTO 2026) prüfen
+  - [ ] Prüfungsart-Codes (`DR`, `ST`, etc.) im `zns-parser` validieren
+  - [ ] Fehlende oder veraltete Codes identifizieren und dokumentieren
+
+---
+
+## ⏸️ Zurückgestellt
+
+> ⏸️ **Nenn-Formular Validierungsregeln (Lizenz × Klasse × Alter für Web-Formular)** — Nach Web-App Besprechung
+
+---
+
+## 📌 Abhängigkeiten
+
+| Meine Aufgabe                         | Blockiert / Ermöglicht wen                       |
+|---------------------------------------|--------------------------------------------------|
+| Validierungs-Spezifikation (A-1)      | 👷 Backend: serverseitige Validierung (Blocker)  |
+| Validierungs-Spezifikation (A-1)      | 🎨 Frontend: Live-Feedback in Dialogen (Blocker) |
+| Validierungs-Spezifikation (A-1)      | 🧐 QA: Testfälle für Validierung                 |
+| Abteilungs-Zwangsteilungsregeln (A-2) | 👷 Backend: `Bewerb.validate()` (Blocker)        |
+| Funktionärs-Qualifikationen (C-2)     | 👷 Backend: Enum-Implementierung                 |
@@ -0,0 +1,214 @@
+# 🗓️ Sprint Execution Order — Entwickler-übergreifende Reihenfolge
+
+> **Stand:** 2. April 2026
+> **Autor:** 🏗️ Lead Architect
+> **Zweck:** Verbindliche, entwickler-übergreifende Ausführungsreihenfolge aller Sprint-Schritte.
+> Dieses Dokument ist die **Single Source of Truth** für „Wer macht was, in welcher Reihenfolge".
+
+---
+
+## 📐 Legende
+
+| Symbol | Bedeutung                                                      |
+|--------|----------------------------------------------------------------|
+| 🔴     | Blocker — muss abgeschlossen sein bevor Folgeschritte beginnen |
+| 🟡     | Kann parallel gestartet werden, sobald Voraussetzung erfüllt   |
+| 🟢     | Kann sofort und unabhängig gestartet werden                    |
+| ⏳      | Wartet auf eine andere Aufgabe                                 |
+| ✅      | Abgeschlossen                                                  |
+| ⏸️     | Zurückgestellt — separate Besprechung                          |
+| `→`    | „ermöglicht" / „blockiert"                                     |
+
+---
+
+## 🔴 PHASE 1 — Fundament legen (Woche 1, Sprint A)
+
+> **Ziel:** Alle Grundlagen schaffen, auf denen alle anderen aufbauen.
+> Diese Phase darf nicht übersprungen werden — sie blockiert fast alles andere.
+
+### Schritt 1 — Startet sofort, gleichzeitig (Tag 1)
+
+| Priorität | Wer           | Aufgabe                                                                                    | Ergebnis / Ermöglicht                           |
+|-----------|---------------|--------------------------------------------------------------------------------------------|-------------------------------------------------|
+| 🔴        | 🏗️ Architect | **A-1** ADR-0021 schreiben: Tenant-Resolution-Strategie                                    | → Freischalten von Schritt 2 (Backend A-1)      |
+| 🔴        | 🏗️ Architect | **A-2** Domänen-Modell formal präzisieren (`Veranstaltung → Turnier → Bewerb → Abteilung`) | → Freischalten von Backend A-2 und Frontend A-2 |
+| 🔴        | 📜 Rulebook   | **A-1** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenz, Alter)         | → Freischalten von Backend A-3, Frontend B-3    |
+| 🔴        | 📜 Rulebook   | **A-2** Abteilungs-Zwangsteilungsregeln vollständig spezifizieren (CSN-C-NEU)              | → Freischalten von Backend A-3, Frontend A-2    |
+| 🟢        | 🧐 QA         | **A-1** Test-Strategie für Desktop-App definieren (Testpyramide, Tooling, Konventionen)    | → Grundlage für alle QA-Schritte                |
+| 🟢        | 🐧 DevOps     | **A-1** Docker-Compose-Setup auf aktuellen Stand bringen                                   | → Stabile lokale Dev-Umgebung für alle          |
+| 🟢        | 🧹 Curator    | **A-5** Session-Log für heutige Besprechung erstellen                                      | → Nachvollziehbarkeit der Beschlüsse            |
+
+---
+
+### Schritt 2 — Startet sobald Schritt 1 (Architect A-1 + A-2) abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                                                         | Ergebnis / Ermöglicht                                                 |
+|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
+| 🔴        | 👷 Backend  | **A-1** Tenant-Isolation im Datenzugriffs-Layer implementieren (basiert auf ADR-0021)                                           | → Sichere Tenant-Grenze; Grundlage für alle weiteren Backend-Schritte |
+| 🔴        | 👷 Backend  | **A-2** Datenbankschema umsetzen: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` | → Freischalten von Backend B-1, B-2                                   |
+| 🟡        | 🎨 Frontend | **A-1** ViewModel-Architektur definieren + `VeranstalterViewModel` als Referenz-Implementierung umsetzen (MVVM/UDF)             | → Muster für alle anderen ViewModels                                  |
+| 🟡        | 🧹 Curator  | **A-1** `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect)                                              | → Gemeinsames Vokabular für alle Teams                                |
+| 🟡        | 🧹 Curator  | **A-2** Event-First-Workflow dokumentieren                                                                                      | → Onboarding neuer Entwickler                                         |
+
+---
+
+### Schritt 3 — Startet sobald Schritt 2 (Backend A-2 + Rulebook A-1/A-2) abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                           | Ergebnis / Ermöglicht                      |
+|-----------|-------------|---------------------------------------------------------------------------------------------------|--------------------------------------------|
+| 🔴        | 👷 Backend  | **A-3** Turnierkategorie-Limits validieren (`Turnier.validate()`, `Bewerb.validate()`)            | → ÖTO-konforme Dateneingabe gesichert      |
+| 🟡        | 🎨 Frontend | **A-2** Abteilungs-Logik im Bewerb-Dialog (CSN-C-NEU Pflicht-Teilung als Vorschlag + Validierung) | → Korrekte Abteilungsanlage durch Benutzer |
+| 🟡        | 🧹 Curator  | **A-3** Navigation-V2 dokumentieren (Screen-Baum, Back-Stack)                                     | →                                          |
+| 🟡        | 🧹 Curator  | **A-4** Tenant-Konzept dokumentieren (nach ADR-0021)                                              | →                                          |
+
+---
+
+## 🟠 PHASE 2 — Verbinden & Implementieren (Woche 2, Sprint B)
+
+> **Ziel:** Frontend und Backend verbinden. Validierungslogik aktiv. Kassa-Service lauffähig.
+> **Voraussetzung:** Phase 1 vollständig abgeschlossen.
+
+### Schritt 4 — Startet parallel, sobald Phase 1 abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                                                                                       | Ergebnis / Ermöglicht                            |
+|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
+| 🔴        | 👷 Backend  | **B-1** CRUD-Endpunkte für alle Stammdaten-Entitäten (`veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `reiter`, `pferde`, `vereine`, `funktionaere`) | → Freischalten von Frontend B-2                  |
+| 🟡        | 🎨 Frontend | **B-1** ViewModels für alle V2-Screens umsetzen (`TurnierViewModel`, `BewerbViewModel`, `PferdProfilViewModel`, etc.)                                         | → Echte Datenbindung in allen Screens            |
+| 🟡        | 🖌️ UI/UX   | **B-1** Wireframes: Edit-Formulare (AlertDialog vs. dedizierter Screen / Sliding-Panel)                                                                       | → Grundlage für Frontend-Umsetzung der Formulare |
+| 🟡        | 🖌️ UI/UX   | **B-2** Wireframes: Bewerb + Abteilung anlegen (Abteilungs-Auswahl inkl. Pflicht-Felder)                                                                      | →                                                |
+| 🟡        | 🖌️ UI/UX   | **B-3** Wireframes: Kassa-Screen (Gesamt-Saldo + Zahlvorgang + Rechnungsvorschau)                                                                             | →                                                |
+| 🟡        | 🐧 DevOps   | **B-1** CI/CD Pipeline für Compose Desktop Tests headless konfigurieren                                                                                       | → Automatisierte Qualitätssicherung              |
+| 🟡        | 🐧 DevOps   | **B-2** Gradle-Build-Optimierungen (Cache, parallele Builds, Wrapper-Update)                                                                                  | → Schnellere Build-Zeiten für alle               |
+
+---
+
+### Schritt 5 — Startet sobald Backend B-1 (CRUD-Endpunkte) abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                    | Ergebnis / Ermöglicht                                        |
+|-----------|-------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------|
+| 🔴        | 🎨 Frontend | **B-2** Ktor-Clients + Repositories für Backend-Anbindung; `StoreV2` schrittweise ersetzen | → Echte Daten statt Mock; Freischalten von Frontend B-3, B-4 |
+| 🟡        | 🧹 Curator  | **B-1** Roadmaps-Verzeichnis pflegen (abgeschlossene Tasks markieren)                      | → Transparenz über Fortschritt                               |
+| 🟡        | 🧹 Curator  | **B-2** `docs/05_Backend/` aktualisieren (neues DB-Schema, API-Endpunkte-Übersicht)        | →                                                            |
+
+---
+
+### Schritt 6 — Startet sobald Schritt 5 (Frontend B-2) abgeschlossen ist UND Rulebook A-1 vorliegt
+
+| Priorität | Wer         | Aufgabe                                                                                                        | Ergebnis / Ermöglicht                          |
+|-----------|-------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------|
+| 🔴        | 👷 Backend  | **B-3** ÖTO-Validierung serverseitig absichern (OEPS, FEI-ID, Lizenz, Altersklassen, Abteilungs-Zwangsteilung) | → Daten-Integrität auf Server-Ebene gesichert  |
+| 🟡        | 🎨 Frontend | **B-3** Validierungs-Live-Feedback in Edit-Dialogen (OEPS, FEI-ID, Lizenz × Klasse, Altersklasse)              | → Benutzer sieht Fehler sofort                 |
+| 🟡        | 📜 Rulebook | **B-1** Validierungs-Implementierung Frontend begleiten + prüfen                                               | → Qualitätssicherung der Regelwerks-Compliance |
+| 🟡        | 📜 Rulebook | **B-2** Validierungs-Implementierung Backend begleiten + prüfen                                                | →                                              |
+| 🟡        | 🧐 QA       | **B-1** Test-Suite: V2-Navigation und Back-Stack                                                               | →                                              |
+| 🟡        | 🧐 QA       | **B-2** Test-Suite: Onboarding-Wizard Edge-Cases                                                               | →                                              |
+| 🟡        | 🧐 QA       | **B-3** Test-Suite: Abteilungs-Logik (CSN-C-NEU Pflicht-Teilungen)                                             | →                                              |
+
+---
+
+### Schritt 7 — Startet sobald Backend B-1 + B-3 abgeschlossen sind
+
+| Priorität | Wer         | Aufgabe                                                                                                   | Ergebnis / Ermöglicht                                    |
+|-----------|-------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
+| 🔴        | 👷 Backend  | **B-2** Kassa-Service implementieren (`TeilnehmerKonto`, `Zahlvorgang`, Rechnungs-Generierung je Turnier) | → Freischalten von Frontend B-4                          |
+| 🟡        | 👷 Backend  | **B-4** Nennungs-Service (Grundstruktur: Eingang, Status-Workflow, Postfach-Endpunkt)                     | → Freischalten von Frontend-Nennungs-Postfach (Sprint C) |
+| 🟡        | 🧐 QA       | **B-4** Test-Suite: ViewModel-Verhalten (State-Initialisierung, Intent → Transition, Error-State)         | →                                                        |
+| 🟡        | 📜 Rulebook | **B-3** Bewerbs-Typen und Bewertungslogik dokumentieren (Stilspringen, Dressurreiter, Reihungsregeln)     | →                                                        |
+
+---
+
+### Schritt 8 — Startet sobald Backend B-2 (Kassa-Service) + UI/UX Wireframes abgeschlossen sind
+
+| Priorität | Wer         | Aufgabe                                                                                                       | Ergebnis / Ermöglicht                         |
+|-----------|-------------|---------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
+| 🟡        | 🎨 Frontend | **B-4** Kassa-Screen: Gesamt-Saldo-Ansicht, Zahlvorgang, Rechnungsvorschau je Turnier                         | → Vollständige Kassa-Funktion für Meldestelle |
+| 🟡        | 🧹 Curator  | **B-3** `docs/06_Frontend/` aktualisieren (ViewModel-Architektur-Muster, Verweis auf `VeranstalterViewModel`) | →                                             |
+
+---
+
+## 🟡 PHASE 3 — Ausliefern & Aufräumen (Woche 3–4, Sprint C)
+
+> **Ziel:** Stabilisieren, testen, ausliefern, dokumentieren.
+> **Voraussetzung:** Phase 2 vollständig abgeschlossen.
+
+### Schritt 9 — Startet parallel sobald Phase 2 abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                                  | Ergebnis / Ermöglicht                      |
+|-----------|-------------|----------------------------------------------------------------------------------------------------------|--------------------------------------------|
+| 🟡        | 🎨 Frontend | **C-1** `StoreV2` vollständig ablösen und entfernen / als `@Deprecated` markieren                        | → Saubere Architektur, kein Tech-Debt mehr |
+| 🟡        | 👷 Backend  | **C-1** Testdaten-Seeder implementieren (Neumarkt-Szenario: 2 Turniere, Bewerbe, Abteilungen, Nennungen) | → Reproduzierbare Testbasis für QA         |
+| 🟡        | 🧐 QA       | **C-1** Test-Suite: Mandanten-Isolation (Veranstaltung A kann keine Daten von B lesen/schreiben)         | →                                          |
+| 🟡        | 🧐 QA       | **C-2** Test-Suite: Kassa und Zahlvorgang (1 Zahlung → 2 korrekte Rechnungen)                            | →                                          |
+| 🟡        | 📜 Rulebook | **C-1** `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Testfälle an QA übergeben               | →                                          |
+| 🟡        | 🐧 DevOps   | **C-1** Desktop-App Packaging (`.msi`, `.deb`, `.dmg`)                                                   | → Auslieferbare Desktop-App                |
+| 🟡        | 🖌️ UI/UX   | **C-1** Wireframes aus Sprint B implementieren (Edit-Formulare + Sliding-Panel)                          | →                                          |
+| 🟡        | 🖌️ UI/UX   | **C-2** Empty States für alle Listenansichten designen und umsetzen                                      | →                                          |
+| 🟡        | 🧹 Curator  | **C-1** `README.md` aktualisieren (Desktop-App Fokus, Schnellstart, V1-Referenzen entfernen)             | →                                          |
+| 🟡        | 🧹 Curator  | **C-2** Setup-Guide aktualisieren (`docs/02_Guides/`)                                                    | →                                          |
+
+---
+
+### Schritt 10 — Startet sobald Schritt 9 abgeschlossen ist
+
+| Priorität | Wer         | Aufgabe                                                                                                 | Ergebnis / Ermöglicht |
+|-----------|-------------|---------------------------------------------------------------------------------------------------------|-----------------------|
+| 🟡        | 🧐 QA       | **C-3** Test-Suite: ÖTO-Validierung (alle OEPS/FEI-ID/Lizenz-Kombinationen)                             | →                     |
+| 🟡        | 👷 Backend  | **C-2** Statistik-Endpunkte (`GET /turniere/{id}/statistiken`, `GET /veranstaltungen/{id}/statistiken`) | →                     |
+| 🟡        | 📜 Rulebook | **C-2** Funktionärs-Qualifikationen auf Enum umstellen                                                  | →                     |
+| 🟡        | 🐧 DevOps   | **C-2** Semantic Versioning einführen + Release-Tagging in CI/CD                                        | →                     |
+| 🟡        | 🧹 Curator  | **C-3** Unterordner-Struktur in `docs/` einführen (nach Abstimmung mit Architect)                       | →                     |
+| 🟡        | 🧹 Curator  | **C-4** V1-Code-Bereinigung koordinieren (gemeinsam mit Frontend + Backend)                             | →                     |
+
+---
+
+### Schritt 11 — Abschluss Sprint C (nach Schritt 10)
+
+| Priorität | Wer           | Aufgabe                                                                                                | Ergebnis / Ermöglicht               |
+|-----------|---------------|--------------------------------------------------------------------------------------------------------|-------------------------------------|
+| 🟡        | 🏗️ Architect | **C-1** Synchronisations-Protokoll-Konzeption starten (Offline-First Desktop ↔ Backend)                | → Grundlage für LAN-Sync (Sprint D) |
+| 🟡        | 🏗️ Architect | **C-2** `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine) | → Aktueller Überblick für alle      |
+| 🟡        | 🐧 DevOps     | **C-3** Produktions-Deployment vorbereiten                                                             | →                                   |
+| 🟡        | 🧹 Curator    | **C-5** Reports-Verzeichnis pflegen (Kurzberichte Sprint A, B, C einsammeln + archivieren)             | →                                   |
+
+---
+
+## ⏸️ Zurückgestellte Themen (eigene Besprechungen)
+
+| Thema                                                    | Status                  | Notiz                                                            |
+|----------------------------------------------------------|-------------------------|------------------------------------------------------------------|
+| USB-Stick Fallback (Export/Import bei LAN-Ausfall)       | ⏸️ Separate Besprechung | Konzept liegt vor (JSON + Versionierung + Checksum)              |
+| Web-App Präsentation (Veranstaltung → Turnier → Inhalte) | ⏸️ Separate Besprechung | Hierarchie noch nicht final besprochen                           |
+| Nenn-System (Web-Formular, dynamisch aus Turnier-Daten)  | ⏸️ Separate Besprechung | Konzept liegt vor, Priorisierung nach Desktop-App-Fertigstellung |
+| Live-Ergebnisse Web-App (SSE/WebSocket)                  | ⏸️ Separate Besprechung | Konzept liegt vor, nach Nenn-System                              |
+
+---
+
+## 🔗 Kritischer Pfad (Blocker-Kette)
+
+Das ist die längste abhängige Kette — Verzögerung hier verzögert alles:
+
+```
+🏗️ ADR-0021
+    └─→ 👷 Tenant-Isolation (Backend A-1)
+          └─→ 👷 DB-Schema (Backend A-2)
+                └─→ 👷 CRUD-Endpunkte (Backend B-1)
+                      └─→ 🎨 Ktor-Repositories (Frontend B-2)
+                            └─→ 🎨 Live-Validierung (Frontend B-3)
+                                  └─→ 🎨 Kassa-Screen (Frontend B-4)
+                                        └─→ 🧐 Kassa-Tests (QA C-2)
+
+📜 Validierungs-Spezifikation (Rulebook A-1)
+    └─→ 👷 ÖTO-Validierung Backend (Backend B-3)
+    └─→ 🎨 Live-Validierung Frontend (Frontend B-3)
+          └─→ 🧐 Validierungs-Tests (QA C-3)
+```
+
+---
+
+## 📊 Gesamtübersicht: Wer ist wann aktiv?
+
+| Phase / Woche            | 🏗️ Architect                | 👷 Backend                            | 🎨 Frontend                                              | 📜 Rulebook                          | 🐧 DevOps             | 🧐 QA                              | 🖌️ UI/UX                         | 🧹 Curator                          |
+|--------------------------|------------------------------|---------------------------------------|----------------------------------------------------------|--------------------------------------|-----------------------|------------------------------------|-----------------------------------|-------------------------------------|
+| **Woche 1 (Sprint A)**   | ADR-0021, Domänen-Modell     | ⏳ (wartet auf ADR)                    | ViewModel-Referenz                                       | Validierungsregeln, Abteilungsregeln | Docker-Setup          | Test-Strategie                     | (Start Wireframes)                | Session-Log, Ubiquitous_Language    |
+| **Woche 2 (Sprint B)**   | LAN-Sync ADR                 | CRUD-APIs, Kassa-Service, Validierung | ViewModels, Repositories, Live-Validierung, Kassa-Screen | Implementierung begleiten            | CI/CD, Gradle         | Navigation-Tests, Abteilungs-Tests | Wireframes                        | Docs aktualisieren                  |
+| **Woche 3–4 (Sprint C)** | Sync-Konzept, Roadmap-Update | Seeder, Statistiken                   | StoreV2-Ablösung                                         | AltersklasseRechner, Enums           | Packaging, Versioning | Isolation-Tests, Kassa-Tests       | Empty States, Wireframes umsetzen | README, Setup-Guide, V1-Bereinigung |
@@ -0,0 +1,84 @@
+# 🖌️ [UI/UX Designer] — Schritt-für-Schritt Roadmap
+
+> **Stand:** 2. April 2026
+> **Rolle:** High-Density Design, Wireframes, Usability, Compose Desktop UX
+
+---
+
+## 🔴 Sprint A — Sofort (diese Woche)
+
+- [ ] **A-1** | Design-Inventur: Bestehende V2-Screens analysieren
+  - [ ] Alle vorhandenen V2-Screens katalogisieren (Screenshots in `docs/ScreenShots/`)
+  - [ ] Inkonsistenzen in Spacing, Typografie und Farbgebung identifizieren
+  - [ ] Offene UX-Probleme und fehlende Empty States dokumentieren
+  - [ ] Ergebnis als kurze Issue-Liste für Sprint B vorbereiten
+
+---
+
+## 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+- [ ] **B-1** | Wireframes: Editier-Formulare (AlertDialog vs. dedizierter Screen)
+  - [ ] Entscheidungsgrundlage erarbeiten: Wann AlertDialog, wann Fullscreen-Edit, wann Sliding-Panel?
+  - [ ] Kriterien definieren: Anzahl der Felder, Komplexität, Kontext-Erhalt
+  - [ ] Wireframes für beide Varianten erstellen (am Beispiel Reiter-Edit und Pferd-Edit)
+  - [ ] Entscheidung treffen und als Design-Richtlinie dokumentieren
+  - [ ] Ergebnis in `docs/06_Frontend/` ablegen
+
+- [ ] **B-2** | Wireframes: Bewerb anlegen mit Abteilungs-Logik
+  - [ ] Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung
+  - [ ] CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge
+  - [ ] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestalten
+
+- [ ] **B-3** | Wireframes: Veranstaltungs-Kassa
+  - [ ] Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren
+  - [ ] Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar
+  - [ ] Rechnungsvorschau: Zwei separate Rechnungen je Turnier nebeneinander oder als Tab
+
+- [ ] **B-4** | Empty States für alle Listenansichten
+  - [ ] Liste aller Screens mit möglichen leeren Zuständen erstellen
+  - [ ] Illustrations-Konzept oder Icon + Text für Empty States definieren
+  - [ ] Konsistente Vorlage für alle Empty States umsetzen
+
+---
+
+## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+- [ ] **C-1** | Wireframes aus Sprint B implementieren
+  - [ ] Editier-Dialog / Fullscreen-Edit gemäß Entscheidung aus B-1 in Compose umsetzen
+  - [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik gemäß B-2 umsetzen
+  - [ ] Kassa-Screen gemäß B-3 umsetzen
+
+- [ ] **C-2** | Design-System konsolidieren
+  - [ ] Farb-Palette in `MaterialTheme` / `Theme.kt` vereinheitlichen
+  - [ ] Typografie-Skala definieren (Überschriften, Body, Labels, Captions)
+  - [ ] Wiederverwendbare Komponenten identifizieren und als Composables extrahieren
+    (z.B. `MeldestelleCard`, `SectionHeader`, `StatusBadge`)
+
+- [ ] **C-3** | Abteilungs-Ansicht: Startliste und Ergebnisliste
+  - [ ] Wireframe: Startliste einer Abteilung (Startnummer, Reiter, Pferd, Verein)
+  - [ ] Wireframe: Ergebnisliste einer Abteilung (Platz, Reiter, Pferd, Ergebnis)
+  - [ ] Wireframe: Gesamtrangliste Bewerb (organisatorische Abteilungen zusammengeführt)
+  - [ ] Wireframe: Separate Siegerehrungsliste (CSN-C-NEU, getrennt nach Lizenzklasse)
+
+---
+
+## ⏸️ Zurückgestellt
+
+> ⏸️ **Web-App Präsentation (Veranstaltungs-Seite, Turnier-Seite)** — Separate Besprechung zu einem späteren Zeitpunkt
+> ⏸️ **Nenn-Formular (Web)** — Separate Besprechung zu einem späteren Zeitpunkt
+> ⏸️ **Live-Ergebnis-Seite (Web)** — Separate Besprechung zu einem späteren Zeitpunkt
+
+---
+
+## 📌 Abhängigkeiten
+
+| Warte auf                                   | Von wem       |
+|---------------------------------------------|---------------|
+| Domänen-Modell final (Abteilung, Kassa)     | 🏗️ Architect |
+| ViewModel-Struktur (welche States gibt es?) | 🎨 Frontend   |
+
+| Meine Aufgabe                      | Ermöglicht wem                                |
+|------------------------------------|-----------------------------------------------|
+| Wireframes Editier-Formulare (B-1) | 🎨 Frontend: Implementierung der Edit-Dialoge |
+| Wireframes Kassa (B-3)             | 🎨 Frontend: Kassa-Screen-Implementierung     |
+| Design-System (C-2)                | Alle: konsistentes UI ohne Nacharbeit         |