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>

backend/services/masterdata/docs/TURNIER_KLASSEN.md

@@ -1,82 +1,118 @@
-# 📜 Turnier-Sparten, Klassen & Startberechtigungen
+# 📜 ÖTO Turnierstruktur: Kategorien & Klassen (2026)
 
-Diese Dokumentation bietet eine detaillierte Übersicht über die Klassen der Hauptsparten **Dressur (CDN)** und *
+Dieses Dokument definiert die hierarchische Struktur von Turnieren gemäß der Österreichischen Turnierordnung (ÖTO 2026).
-*Springen (CSN)** sowie die jeweiligen Startberechtigungen basierend auf der ÖTO 2026.
+Es unterscheidet strikt zwischen **Turnierkategorien** (dem Rahmen der Gesamtveranstaltung) und den darin zulässigen *
+*Bewerbsklassen** (dem Niveau der einzelnen Prüfungen).
+
+* **Owner:** 📜 [ÖTO/FEI Rulebook Expert]
+* **Status:** ACTIVE
+* **Letztes Update:** 2. April 2026
+* **Quellen:**
+  * ÖTO 2026 A-Teil § 3, § 4, § 5
+  * ÖTO 2026 B-Teil § 100 (CDN Ausschreibungen), § 109 (CDN-C-NEU)
+  * ÖTO 2026 B-Teil § 200 (CSN Ausschreibungen), § 231 (CSN-C-NEU)
+  * ÖTO 2026 Anhang: Höhentabelle
 
 ---
 
-## 1. Sparte Springen (CSN)
+## 1. System-Architektur: Die Hierarchie
 
-### 1.1 Klasseneinteilung (Großpferde)
+Das System muss folgende Hierarchie validieren:
+Ein `Turnier` (Kategorie) definiert das Limit. Ein `Bewerb` (Klasse/Höhe) darf das Limit der übergeordneten Kategorie
+nicht überschreiten.
 
-Die Klassen richten sich primär nach der maximalen Hindernishöhe (§ 200 B-Teil).
+1. **Turnierkategorie (Kategorie):**
-
+  * Beschreibt den Status des Turniers (A\*, A, B\*, B, C, C-NEU).
-| Klasse  | Bezeichnung         | Höhe (cm) | Startberechtigung (Lizenz)  |
+  * Wird als Suffix an die Sparte angehängt (z.B. CSN-A, CDN-B).
-|:--------|:--------------------|:----------|:----------------------------|
+  * Definiert die maximal zulässigen Bewerbshöhen/Niveaus.
-| **E0**  | Einsteiger          | 60 – 95   | LZF (Startkarte/Reiterpass) |
+2. **Bewerbsklasse (Klasse):**
-| **A**   | Leicht              | 105 – 110 | R1 oder höher               |
+  * Beschreibt den Schwierigkeitsgrad einer einzelnen Prüfung (z.B. E, A, L, LM, M, S).
-| **L**   | Mittelleicht        | 115 – 120 | R1 oder höher               |
+  * Legt die Anforderungen an Reiter und Pferd fest.
-| **LM**  | Leicht-Mittelschwer | 125 – 130 | R2 oder höher               |
-| **M**   | Mittelschwer        | 135       | R3 oder höher               |
-| **S***  | Schwer              | 140 – 145 | R3 oder höher               |
-| **S**** | Schwer (GP)         | 150 – 160 | R4                          |
-
-### 1.2 Besonderheiten CSN-C NEU
-
-* **Höhen:** 60 cm bis 115 cm.
-* **Registrierung:** Pferde bis 90 cm müssen nicht beim OEPS registriert sein.
-* **Ergebniserfassung:** Erst ab 95 cm (für Lizenzerhalt) bzw. ab 105 cm (für Höherreihung).
-* **Startlimit:** Ein Pferd darf maximal 3-mal pro Tag starten.
-
-### 1.3 Abteilungsbildung (Pflicht)
-
-* **Bis 95 cm:**
-  1. Abt.: Ohne Lizenz (LZF)
-  2. Abt.: R1-Reiter
-  3. Abt.: R2-Reiter und höher
-* **Ab 100 cm:**
-  1. Abt.: R1-Reiter
-  2. Abt.: R2-Reiter und höher
 
 ---
 
-## 2. Sparte Dressur (CDN)
+## 2. Turnierkategorien: Rahmenbedingungen & Limits
 
-### 2.1 Klasseneinteilung & Aufgabenniveau
+Die folgenden Tabellen definieren die zulässigen Höchstgrenzen für Bewerbe innerhalb einer Turnierkategorie.
 
-Die Dressur wird nach offiziellen Aufgabenheften geritten (§ 100 B-Teil).
+### 2.1 Sparte Springen (CSN) - Gemäß B-Teil § 200
 
-| Klasse | Niveau              | Erforderliche Lizenz | Besonderheiten                             |
+| Turnier-Kategorie | Max. Höhe / Klasse (Standard) | Pflicht-Bewerbe / Besonderheiten                                                                                                                                                                   | Referenz        |
-|:-------|:--------------------|:---------------------|:-------------------------------------------|
+|:------------------|:------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------|
-| **LF** | Lizenzfrei          | LZF (Reiterpass)     | First Ridden, Führzügel, Aufgaben R1/Nadel |
+| **CSN-A\***       | **160 cm (S\*\*\*)**          | Mindestens 1 Springen der Höhe **150 cm** ist verpflichtend durchzuführen.                                                                                                                         | § 200.1         |
-| **A**  | Leicht              | R1 / RD1 oder höher  | Grundausbildung                            |
+| **CSN-A**         | **145 cm (S\*)**              | Mindestens 1 Springen der Höhe **145 cm** ist verpflichtend durchzuführen.                                                                                                                         | § 200.2         |
-| **L**  | Mittelleicht        | R1 / RD1 oder höher  | Beginnende Versammlung                     |
+| **CSN-B\***       | **140 cm (S\*)**              | Mindestens je ein Springen **135 cm** und **140 cm** verpflichtend. Am Vortag des ersten 140cm-Springens ist zwingend ein 135cm-Springen auszuschreiben. Maximal 2 Bewerbe mit 140 cm pro Turnier. | § 200.3.8 / 3.9 |
-| **LM** | Leicht-Mittelschwer | R2 / RD2 oder höher  | Wahlweise Trense/Kandare                   |
+| **CSN-B**         | **135 cm (M)**                | Mindestens je ein Springen **125 cm oder 130 cm** UND **135 cm** verpflichtend durchzuführen.                                                                                                      | § 200.3.10      |
-| **M**  | Mittelschwer        | R2 / RD2 oder höher  | Kandarenpflicht                            |
+| **CSN-C**         | **130 cm (LM)**               | Pro Turnier ist mindestens eine Springprüfung mit beurteilendem Richtverfahren und mindestens eine Springpferdeprüfung auszuschreiben.                                                             | § 200.4.7       |
-| **S**  | Schwer              | R3 / RD3 oder höher  | St. Georg bis Grand Prix                   |
+| **CSN-C NEU**     | **115 cm (L)**                | Reine Einsteiger-Kategorie. Kombinierbar nur mit CDN-C-NEU, CCN-C-NEU, CHNV.                                                                                                                       | § 231           |
 
-### 2.2 Besonderheiten CDN-C NEU
+### 2.2 Sparte Dressur (CDN) - Gemäß B-Teil § 100
 
-* **Ausschreibbare Bewerbe:** Kl. A & L, lizenzfreie Aufgaben, Reiterpass/Reiternadel.
+| Turnier-Kategorie | Max. Niveau / Klasse | Pflicht-Bewerbe / Besonderheiten                                                                                | Referenz  |
-* **Einschränkung:** In Reiterpass/Reiternadel-Aufgaben sind Lizenzinhaber **nicht** startberechtigt.
+|:------------------|:---------------------|:----------------------------------------------------------------------------------------------------------------|:----------|
-* **Ergebniserfassung:** Ergebnisse in Kl. A und L werden für Lizenzen gewertet. Reiterpass-Aufgaben werden nicht
+| **CDN-A\***       | **Grand Prix**       | Das Turnier wird zu A\*, sobald Grand Prix, GP Special, GP Kür, Inter II, Inter A oder B ausgeschrieben wird.   | § 100.1.4 |
-  erfasst.
+| **CDN-A**         | **S**                | Bewerbe der Klassen L, LM, M und S zulässig.                                                                    | § 100.1.1 |
+| **CDN-B\***       | **S**                | Max. ein Bewerb der Klasse S pro Tag (nur junge Reiter Aufgaben und St. Georg). Bedarf der Genehmigung des LFV. | § 100.2.8 |
+| **CDN-B**         | **M**                | Pro Turnier sind mindestens eine Dressurpferdeprüfung und eine Dressurreiterprüfung auszuschreiben.             | § 100.2.7 |
+| **CDN-C**         | **LM**               | Bewerbe der Klassen A, L und LM zulässig. Ebenso Dressurpferde/reiter A und L.                                  | § 100.3.1 |
+| **CDN-C NEU**     | **L**                | Dressurprüfungen Kl. A und L, lizenzfreie Aufgaben.                                                             | § 109     |
 
 ---
 
-## 3. Zusammenfassende Startberechtigungs-Matrix
+## 3. Bewerbsklassen: Niveau-Definitionen
 
-| Lizenzstufe  | Springen (max. Klasse) | Dressur (max. Klasse) |
+### 3.1 Springen (CSN) - Höhentabelle für Großpferde
-|:-------------|:-----------------------|:----------------------|
+
-| **LZF** (RP) | E0 (95 cm)             | LF / lizenzfrei       |
+Die Definition der Klassen in der Sparte Springen erfolgt vorrangig über die Hindernishöhe.
-| **R1**       | L (120 cm)             | L                     |
+
-| **RD1**      | E0 (95 cm)             | L                     |
+| Klasse         | Bezeichnung         | Höhe in cm  |
-| **R2**       | LM (130 cm)            | M                     |
+|:---------------|:--------------------|:------------|
-| **RD2**      | E0 (95 cm)             | M                     |
+| **E0**         | Einsteiger          | 60 bis 90   |
-| **R3**       | S* (145 cm)            | S                     |
+| **E** / **A0** | Einsteiger / Anfang | 95 bis 100  |
-| **RD3**      | E0 (95 cm)             | S                     |
+| **A**          | Anfang              | 105 bis 110 |
-| **R4**       | S**** (160 cm)         | S                     |
+| **L**          | Leicht              | 115 bis 120 |
+| **LM**         | Leicht-Mittelschwer | 125 bis 130 |
+| **M**          | Mittelschwer        | 135         |
+| **S1\***       | Schwer 1            | 140         |
+| **S2\***       | Schwer 2            | 145         |
+| **S3\*\*\***   | Schwer 3            | 150 bis 160 |
+
+*(Quelle: ÖTO 2026, Anhang: Höhentabelle)*
+
+### 3.2 Dressur (CDN) - Aufgabenniveaus
+
+Die Dressur-Klassen basieren auf dem Schwierigkeitsgrad der vorgeschriebenen Aufgaben.
+
+| Klasse | Niveau / Anforderungen                            | Lizenz-Voraussetzung         |
+|:-------|:--------------------------------------------------|:-----------------------------|
+| **LF** | Lizenzfrei (Aufgaben für Reiterpass/Nadel)        | LZF (Keine Lizenz, nur Pass) |
+| **A**  | Anfang (Grundausbildung, Anlehnung)               | R1 / RD1 oder höher          |
+| **L**  | Leicht (Beginnende Versammlung, Außengalopp)      | R1 / RD1 oder höher          |
+| **LM** | Leicht-Mittelschwer (Versammlung, flieg. Wechsel) | R2 / RD2 oder höher          |
+| **M**  | Mittelschwer (Kandarenpflicht, Serienwechsel)     | R2 / RD2 oder höher          |
+| **S**  | Schwer (St. Georg bis Grand Prix)                 | R3 / RD3 oder höher          |
 
 ---
-> 📜 **Rulebook Expert Hinweis:** Diese Matrix dient der automatischen Validierung von Nennungen. Bei Rasse-Spezifischen
+
-> Bewerben (Haflinger/Noriker) können Sonderregelungen gemäß `REITER_LIZENZEN.md` greifen.
+## 4. Sonder-Kategorie: C-NEU (§ 109 & § 231)
+
+Die Kategorie C-NEU dient dem Einstieg in den Turniersport. Sie unterliegt strengen Limitierungen, um den Breitensport
+zu fördern.
+
+* **Isolation:** Darf **nur** mit anderen C-NEU Kategorien (CSN-C-NEU, CDN-C-NEU, CCN-C-NEU) kombiniert werden. (
+  B-Teil § 231).
+* **Registrierung (Springen):** Bei Springbewerben bis 90 cm müssen die Pferde nicht beim OEPS registriert sein (keine
+  Kopfnummerpflicht).
+* **Ergebnisse:** In der Dressur zählen Ergebnisse in RP/RN-Aufgaben nicht für Lizenzen. Im Springen zählen Ergebnisse
+  erst ab 95 cm für den Erhalt der Lizenz bzw. ab 105 cm für Höherreihungen.
+* **Dressur-Sperre:** In Reiterpass/Reiternadel-Aufgaben (CDN-C-NEU) sind Reiter mit Lizenz **nicht** startberechtigt.
+* **Abteilungs-Teilung (CSN-C-NEU):** Strukturell zwingend: Bis 95 cm: Trennung nach `ohne Lizenz` vs. `mit Lizenz`. Ab
+  100 cm: Trennung nach `R1` vs. `R2 und höher`.
+
+---
+> 📜 **Rulebook Expert Hinweis zur Implementierung:**
+> Das Backend (`competition-context`) muss die Validierung zweistufig aufbauen:
+> 1. `Turnier.validate()`: Entsprechen die angelegten Bewerbe den Limits der `Turnierkategorie`? (z.B. Kein S-Springen
+     140cm auf einem C-Turnier).
+> 2. `Bewerb.validate()`: Sind die spezifischen Anforderungen der `Bewerbsklasse` erfüllt? (z.B. Zwingende
+     Abteilungs-Teilungen im CSN-C-NEU).

docs/04_Agents/Roadmaps/Architect_Roadmap.md

@@ -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         |

docs/04_Agents/Roadmaps/Backend_Roadmap.md

@@ -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 |

docs/04_Agents/Roadmaps/Curator_Roadmap.md

@@ -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  |

docs/04_Agents/Roadmaps/DevOps_Roadmap.md

@@ -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 |

docs/04_Agents/Roadmaps/Frontend_Roadmap.md

@@ -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 |

docs/04_Agents/Roadmaps/QA_Roadmap.md

@@ -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 |

docs/04_Agents/Roadmaps/Rulebook_Roadmap.md

@@ -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                 |

docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md

@@ -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 |

docs/04_Agents/Roadmaps/UIUX_Roadmap.md

@@ -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         |

docs/90_Reports/2026-04-02_Architect_Report.md

@@ -0,0 +1,41 @@
+# 🏗️ [Lead Architect] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Das Projekt hat durch die "Event-First"-Philosophie (Initialisierung einer spezifischen Datenbank pro Veranstaltung) und
+die fokussierte Compose-Desktop-Entwicklung (V2-Screens) eine deutliche Richtung eingenommen. Die
+Architekturentscheidung (ADR-0020) bezüglich LAN-Isolation und Mandantenfähigkeit (Tenant-per-Event) beginnt sich im
+Code (lokaler State, Event-bezogene Stores) niederzuschlagen, muss aber zwingend im Backend nachgezogen werden.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Mandantenfähigkeit (Tenant Isolation) im Backend verankern**
+
+* *Warum:* Das Frontend plant für jedes Event eine "eigene Datenbank". Das Backend läuft derzeit noch als klassischer
+  Monolith ohne harte Isolation der Veranstaltungsdaten (Nennungen, Prüfungen, Starterlisten). Wenn wir dies jetzt nicht
+  architektonisch sauber im Backend (z.B. über Schema-per-Tenant oder Tenant-IDs in allen Tabellen) lösen, bauen wir
+  enorme technische Schulden auf.
+* *Aktion:* Definition der Tenant-Resolution-Strategie für Ktor/Spring Boot (wie erkennt das Backend, auf welche
+  Event-Datenbank eine Anfrage zielt?). Umsetzung im Datenzugriff-Layer.
+
+**🔴 P1: State-Management-Architektur für Compose (MVI/MVVM)**
+
+* *Warum:* Der aktuelle Frontend-Code mischt UI-Deklaration und Business-Logik (`StoreV2` Aufrufe direkt in den
+  `onSaved`-Callbacks, viel lokaler `remember`-State). Bei steigender Komplexität (z.B. Nennungssystem) wird dies
+  unwartbar.
+* *Aktion:* Verbindliche Festlegung auf ein Architekturmuster für das KMP/Compose Frontend (z.B. striktes MVVM mit UDF -
+  Unidirectional Data Flow). Auslagern des Status in `ViewModels` und Definition klarer `Intent`/`State` Klassen für die
+  V2-Screens.
+
+**🟠 P2: Synchronisations-Protokoll (Offline-First/LAN)**
+
+* *Warum:* Die Meldestelle muss offline auf Turnieren funktionieren.
+* *Aktion:* Start der Konzeptionsphase für das Daten-Synchronisations-Protokoll zwischen der Master-Datenbank (Backend)
+  und den lokalen Client-Datenbanken (Desktop). Entscheidung zwischen Event-Sourcing, CRDTs oder simplen
+  Timestamp-basierten Sync-Ansätzen.
+
+**🟡 P3: Master-Roadmap Update**
+
+* *Warum:* Die jüngsten Entwicklungen haben die Prioritäten verschoben.
+* *Aktion:* Aktualisierung der `MASTER_ROADMAP.md` in `docs/01_Architecture/`, um den Fokus auf die Desktop-App, die
+  Tenant-Isolation und die anstehenden Offline-Sync-Meilensteine widerzuspiegeln.

docs/90_Reports/2026-04-02_Backend_Report.md

@@ -0,0 +1,35 @@
+# 👷 [Backend Developer] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Das Backend war in den letzten Tagen relativ stabil. Es gab kleinere Anpassungen im Domain-Modell (z.B. Entfernung von "
+Reining" aus dem `Sparte` Enum) und Optimierungen in den Build-Skripten (`platformTesting`). Das Backend wartet nun
+darauf, die rasante Frontend-Entwicklung mit echten Daten und Endpunkten zu unterfüttern.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: API-Endpunkte für V2-Frontend (CRUD)**
+
+* *Warum:* Das Frontend verwendet aktuell einen lokalen `StoreV2`, da die echten Endpunkte für die neuen Detail-Screens
+  fehlen.
+* *Aktion:* Definition und Implementierung der REST-APIs für Create, Read, Update, Delete von Veranstaltern,
+  Veranstaltungen, Reitern, Pferden, Vereinen und Funktionären.
+
+**🟠 P2: Datenbank-Schema & DTOs aktualisieren**
+
+* *Warum:* Die neuen Frontend-Dialoge haben neue Felder oder spezifische Anforderungen an die Datenstruktur
+  offengelegt (z.B. OEPS-Nummer vs. FEI-ID, optionale Kontakt-Felder).
+* *Aktion:* Abgleich der Domain-Modelle und des DB-Schemas mit den Frontend-DTOs. Ggf. Flyway-Migrationen erstellen.
+
+**🟠 P2: LAN/Offline-First Architektur (Sync)**
+
+* *Warum:* Gemäß ADR-0020 und der Projekt-Philosophie muss das System offline-fähig (LAN) sein. Die
+  Event-Datenbank-Initialisierung passiert nun im Frontend.
+* *Aktion:* Vorbereitung der mandantenfähigen/Event-spezifischen Datenhaltung im Backend, um mit der lokalen Datenbank
+  der Desktop-App kommunizieren zu können.
+
+**🟡 P3: Dynamisches Testdaten-Seeding**
+
+* *Warum:* Das Frontend braucht realistische Daten für die V2-Screens, um Edge-Cases zu testen.
+* *Aktion:* Entwicklung eines Seeders, der reproduzierbare, umfangreiche Testdaten (Turniere, Nennungen, Stammdaten)
+  generiert und über die API bereitstellt.

docs/90_Reports/2026-04-02_Curator_Report.md

@@ -0,0 +1,37 @@
+# 🧹 [Curator] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Das Projekt macht schnelle Fortschritte, was zu einer hohen Frequenz an Frontend-Änderungen und Architektur-Anpassungen
+geführt hat. Der Code ist gut strukturiert, aber die technische Dokumentation (ADRs, Playbooks, Setup-Guides) hinkt den
+Implementierungs-Entscheidungen der letzten Tage etwas hinterher.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Dokumentation des "Event-First" Workflows & ADRs**
+
+* *Warum:* Die neue Struktur der Datenbank-Erstellung (pro Veranstaltung) und die Offline-Strategie (LAN-Sync) aus
+  ADR-0020 werden tiefgreifende Auswirkungen auf die System-Architektur haben.
+* *Aktion:* Ausführliche Dokumentation der Mandantenfähigkeit (Tenant-Isolation), des neuen Navigation-Stacks (V2) und
+  des Startvorgangs (Onboarding) in `docs/01_Architecture/`.
+
+**🟠 P2: `README.md` und Setup-Guide aktualisieren**
+
+* *Warum:* Die neuen Run-Configs (z. B. `PreviewMain`) und der Fokus auf die Desktop-App (Compose) machen es für neue
+  Entwickler schwer, den Einstiegspunkt zu finden.
+* *Aktion:* Das Haupt-`README.md` um die neuesten Befehle für Compose Desktop (
+  `./gradlew :frontend:shells:meldestelle-desktop:run`) und die Backend-Abhängigkeiten (z.B. Test-Datenbank-Setup)
+  erweitern.
+
+**🟠 P2: Logs & Journaling Struktur**
+
+* *Warum:* Mit den vielen neuen Reports wird das `docs/90_Reports/`-Verzeichnis schnell unübersichtlich.
+* *Aktion:* Einführung einer sauberen Unterordner-Struktur in `docs/` nach Meilensteinen oder Kalenderwochen, um Reports
+  und Session-Logs (`docs/99_Journal/`) besser archivieren und durchsuchen zu können.
+
+**🟡 P3: Aufräumen von altem Code ("V1")**
+
+* *Warum:* Wir haben viele "V2"-Screens eingeführt. Die alten, nicht mehr genutzten Platzhalter-Screens oder veralteten
+  Routing-Einträge erzeugen "Dead Code".
+* *Aktion:* Identifikation und saubere Löschung aller veralteten UI-Komponenten und Navigationspfade aus der initialen
+  Startup-Phase, um die Code-Basis schlank zu halten.

docs/90_Reports/2026-04-02_DevOps_Report.md

@@ -0,0 +1,37 @@
+# 🐧 [DevOps Engineer] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+In den letzten Commits sehen wir Anpassungen an den Gradle-Build-Skripten im Backend (
+`masterdata-domain/build.gradle.kts`), bei denen Abhängigkeiten zum `platformTesting` bereinigt wurden. Die Entwicklung
+konzentriert sich stark auf die Desktop-App (`meldestelle-desktop`), was bedeutet, dass die Paketierung und Auslieferung
+für den Desktop-Client relevant wird.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Desktop-App Packaging (Compose for Desktop)**
+
+* *Warum:* Das "Event-First" Workflow-Update zeigt, dass der `meldestelle-desktop` Client immer vollständiger wird und
+  für Tests durch Stakeholder bereitgestellt werden sollte.
+* *Aktion:* Konfiguration von Gradle/Conveyor oder `compose.desktop.nativeDistributions`, um installierbare Pakete (z.B.
+  `.msi`, `.dmg` oder `.deb`) für die Ziel-Betriebssysteme der Meldestellen automatisch via CI/CD zu bauen.
+
+**🟠 P2: CI/CD Pipeline für Compose Tests**
+
+* *Warum:* Die UI-Tests und Navigationstests (z.B. `DeepLinkHandlerTest`) müssen bei jedem Push laufen, um Regressionen
+  im komplexen V2-Navigation-Flow zu verhindern.
+* *Aktion:* Ausbau der GitHub Actions (oder GitLab CI), um die Compose-Desktop-Tests "headless" auszuführen und schnelle
+  Feedback-Schleifen für die UI-Entwicklung zu etablieren.
+
+**🟠 P2: Vorbereitung der Offline-Datenbank (LAN)**
+
+* *Warum:* Im Frontend-Code ist dokumentiert, dass "eine eigene Datenbank initialisiert wird". Die LAN-Synchronisation
+  aus ADR-0020 wird konkreter.
+* *Aktion:* Evaluierung und Bereitstellung der Infrastruktur für lokale SQLite-Datenbanken innerhalb der
+  Desktop-Applikation inklusive eventueller Sync-Tools (z.B. Realm oder custom Ktor/SQLDelight Sync-Worker).
+
+**🟡 P3: Artefakt-Versionierung und Releases**
+
+* *Warum:* Es ist bald ein MVP-Release fällig.
+* *Aktion:* Einführung einer sauberen Semantic Versioning Strategie, um Client (Desktop) und Server (Spring Boot)
+  koordiniert als Release-Paket taggen und deployen zu können.

docs/90_Reports/2026-04-02_Frontend_Report.md

@@ -0,0 +1,44 @@
+# 🎨 [Frontend Expert] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+In den letzten Tagen lag der Fokus stark auf dem Frontend-Flow, insbesondere auf der Verwaltung von Stammdaten und der
+Navigation:
+
+* **UI/UX Onboarding:** Verbessertes Keyboard-Handling (Tab-Navigation, Enter-Bestätigung) und State-Saving (
+  `rememberSaveable`) zwischen Navigationswechseln.
+* **Veranstalter & Veranstaltung:** Einführung von `VeranstalterDetailV2` und `VeranstaltungKonfigV2` mit einem sauberen
+  Bestätigungsdialog vor der endgültigen Anlage und korrekter Initialisierung der Event-Datenbank.
+* **Profil-Screens (V2):** Neue, detailreiche Profil-Ansichten für Reiter, Pferde, Vereine und Funktionäre inkl.
+  Inline-Edit-Dialogen.
+* **Navigation:** Robuste Back-Stack-Implementierung, die sicherstellt, dass der User korrekt zwischen den
+  Verwaltungsebenen und Profilen navigieren kann.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: State-Management refaktorisieren**
+
+* *Warum:* Aktuell wird viel lokaler State direkt in den V2-Composables gehalten (
+  `var name by remember { mutableStateOf(...) }`).
+* *Aktion:* Konsequente Auslagerung in ViewModels (z. B. `VeranstalterViewModel`, `PferdProfilViewModel`), um die
+  Geschäftslogik von der UI zu trennen und die Testbarkeit zu erhöhen.
+
+**🟠 P2: Datenbindung & Store-Ablösung**
+
+* *Warum:* Das Frontend arbeitet momentan stark mit einem Mock-Store (`StoreV2`).
+* *Aktion:* Vorbereitung der Ktor-Clients und Repositories, um die tatsächlichen Backend-Endpunkte für echte
+  CRUD-Operationen anzubinden.
+
+**🟠 P2: CRUD-Vervollständigung (Delete)**
+
+* *Warum:* Die "Bearbeiten"-Dialoge sind vorhanden, aber die Lösch-Funktionalität fehlt in den neuen V2-Screens noch
+  weitgehend.
+* *Aktion:* Implementierung von Lösch-Bestätigungsdialogen und entsprechender Store-/Backend-Integration in allen
+  Profil-Screens.
+
+**🟡 P3: UI/UX-Konsistenz & Validierung**
+
+* *Warum:* Schnelle Iterationen haben teils zu unterschiedlichen Layout-Details oder fehlenden Validierungslogiken in
+  den Edit-Dialogen geführt.
+* *Aktion:* Formular-Validierung härten (Pflichtfelder markieren, Fehlermeldungen anzeigen) und globales Theming (
+  Material 3) strikter anwenden.

docs/90_Reports/2026-04-02_QA_Report.md

@@ -0,0 +1,36 @@
+# 🧐 [QA Specialist] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Mit den jüngsten Commits wurde ein komplett neuer Frontend-Workflow ("Event-First" und "V2" Screens) etabliert. Es gibt
+jetzt komplexe Navigationspfade (Back-Stack), Onboarding-Eingaben mit Keyboard-Handling und Wizard-artige Abläufe zur
+Veranstaltungserstellung mit Bestätigungsdialogen. Die zugrundeliegende Logik verlässt sich momentan stark auf einen
+lokalen In-Memory Store (`StoreV2`).
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Test-Strategie für V2-Navigation & Back-Stack**
+
+* *Warum:* Komplexe Navigation in Compose für Desktop ist fehleranfällig (State-Verlust, Endlosschleifen).
+* *Aktion:* Ausweitung der UI-Tests (z. B. `DeepLinkHandlerTest`) auf den neuen Back-Stack. Spezielles Augenmerk auf
+  Edge-Cases: Was passiert beim wiederholten "Zurück"-Navigieren aus tief verschachtelten Profil-Bearbeitungs-Dialogen?
+
+**🟠 P2: Edge-Cases im Onboarding & Event-Wizard prüfen**
+
+* *Warum:* Das Keyboard-Handling (Tab/Enter) wurde im Onboarding implementiert.
+* *Aktion:* Systematische Tests der Eingabefelder: Verhalten bei leeren Pflichtfeldern, zu kurzen Schlüsseln, ungültigen
+  Zeichen oder schnellem Klicken während der Wizard-Transitions. Der Zustand (State) bei "Abbrechen" im
+  Bestätigungsdialog muss ebenfalls verifiziert werden.
+
+**🟠 P2: Testdaten-Isolierung (Offline-First Vorbereitung)**
+
+* *Warum:* Die App initialisiert eine eigene Datenbank pro Veranstaltung.
+* *Aktion:* Entwicklung von Testfällen, die sicherstellen, dass Daten (z. B. Nennungen) strikt zwischen verschiedenen
+  Veranstaltungen (Mandanten) isoliert bleiben.
+
+**🟡 P3: Manuelle explorative Tests der "V2" Edit-Dialoge**
+
+* *Warum:* Die neuen Inline-Edit-Dialoge für Reiter, Pferde, etc. sind frisch.
+* *Aktion:* Systematisches manuelles Durchklicken aller Bearbeiten-Dialoge. Spezifischer Fokus auf das
+  Speichern-Verhalten (wird die UI sofort aktualisiert?) und das Abbrechen (werden ungespeicherte Eingaben korrekt
+  verworfen?).

docs/90_Reports/2026-04-02_Rulebook_Report.md

@@ -0,0 +1,31 @@
+# 📜 [ÖTO/FEI Rulebook Expert] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+In der Domain-Schicht gab es Anpassungen an den Stammdaten, wie z.B. die Entfernung von "Reining" aus dem `Sparte`-Enum
+und Anpassungen im `AltersklasseRechnerTest`. Im Frontend wurden neue Detail-Screens für Reiter und Pferde eingeführt,
+bei denen FEI-IDs, ÖPS-Nummern und Lizenzklassen manuell eingegeben werden können.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Validierungsregeln in V2-Screens und Backend (ÖTO/FEI Compliance)**
+
+* *Warum:* In den neuen Profil-Dialogen (`ReiterProfilV2`, `PferdProfilV2`) können beliebige Strings für OEPS-Nummern,
+  FEI-IDs und Lizenzen eingegeben werden. Dies führt zu fehlerhaften Nennungen.
+* *Aktion:* Strikte Validierungs-Logik gemäß ÖTO/FEI-Regelwerk implementieren (z.B. OEPS-Nummern-Format prüfen,
+  Lizenzklassen-Wertebereich einschränken R1-R4, etc.). Dies muss sowohl im Frontend (Live-Feedback) als auch im
+  Backend (Sicherheit) geschehen.
+
+**🟠 P2: Altersklassen und Sparten-Abgleich**
+
+* *Warum:* Die Altersklassenberechnung muss für Nennungen zwingend fehlerfrei funktionieren, da sie über die
+  Startberechtigung entscheidet.
+* *Aktion:* Den `AltersklasseRechner` auf Basis der aktuellsten ÖTO (2026) vollständig durchtesten und sicherstellen,
+  dass das Jahr der Veranstaltung und das Geburtsjahr des Reiters/Pferdes gemäß den Regeln für die jeweilige Sparte
+  korrekt verrechnet werden.
+
+**🟡 P3: Funktionärs-Qualifikationen prüfen**
+
+* *Warum:* Im neuen `FunktionaerProfilV2` wird die `richterQualifikation` als Freitext erfasst.
+* *Aktion:* Umstellung auf vordefinierte Qualifikationsstufen (z.B. Parcoursbauer, Richter Dressur/Springen) gemäß
+  ÖTO-Vorgaben, um bei der Veranstaltungsplanung regelkonforme Besetzungen sicherzustellen.

docs/90_Reports/2026-04-02_UIUX_Report.md

@@ -0,0 +1,38 @@
+# 🖌️ [UI/UX Designer] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Das Desktop-Frontend hat ein umfassendes Update erfahren. Es wurden viele neue V2-Ansichten für die Stamm- und
+Bewegungsdaten eingeführt. Positiv hervorzuheben ist die Implementierung der Mockups `Veranstalter-Card-v01.png` und
+`Veranstalter-Profil-Card-v01.png`. Die Layouts für Reiter-, Pferde- und Vereinsprofile nutzen jetzt einheitlichere
+Cards mit Initialen-Avataren. Die Navigation ist durch Breadcrumbs und Zurück-Pfeile deutlich transparenter geworden.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Dialog-Design vs. Fullscreen-Bearbeitung**
+
+* *Warum:* Aktuell werden die Bearbeitungs-Formulare (z. B. für Reiter, Pferde) als `AlertDialog` über das Profil
+  gelegt. Bei vielen Feldern (insbesondere später bei Nennungen) wird das auf dem Desktop unübersichtlich und bricht mit
+  dem "High-Density" Konzept.
+* *Aktion:* Überarbeitung des UX-Konzepts für das Editieren: Evaluierung, ob Formulare besser als dedizierte Screens (
+  oder Sliding-Panels) umgesetzt werden sollten, statt klassische Modals zu verwenden.
+
+**🟠 P2: Informationsarchitektur der Listenansichten verbessern**
+
+* *Warum:* Die Listenansichten (z. B. in der `VeranstalterVerwaltungScreen`) nutzen teilweise noch rohe Tabellenlayouts,
+  die nicht so elegant wirken wie die neuen Profil-Karten.
+* *Aktion:* Das Design der "High-Density Data Tables" verfeinern (siehe Material 3 Guidelines für Desktop). Bessere
+  typografische Hierarchie, Hover-States und klarere Action-Buttons innerhalb der Zeilen definieren.
+
+**🟠 P2: Leere Zustände (Empty States) visuell aufwerten**
+
+* *Warum:* Momentan wird oft nur grauer Text ("Keine passenden Veranstaltungen gefunden") angezeigt.
+* *Aktion:* Entwurf und Implementierung von ansprechenden "Empty States" mit passenden Icons (z.B. ein leeres Dokument
+  oder ein Pferdekopf-Icon) und klaren "Call-to-Action"-Buttons ("Jetzt erstes Pferd anlegen"), um den User besser zu
+  führen.
+
+**🟡 P3: Farbschema und Theming vereinheitlichen**
+
+* *Warum:* Es gibt noch vereinzelt hartkodierte Hex-Werte (z.B. für die Avatar-Hintergründe).
+* *Aktion:* Definition einer konsistenten Farbpalette im `DesktopThemeV2`, die semantische Farben für Status (Aktiv,
+  Inaktiv, Fehler) und Platzhalter konsistent über die gesamte Anwendung bereitstellt.

docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md

@@ -0,0 +1,206 @@
+# 🧹 Session-Log: Sprint-Planungs-Besprechung
+
+> **Datum:** 2. April 2026
+> **Erstellt von:** 🧹 Curator
+> **Aufgabe:** Curator Roadmap A-5
+
+---
+
+## 📋 Teilnehmer
+
+| Agent                      | Rolle                                | Anwesend |
+|----------------------------|--------------------------------------|----------|
+| Owner / Projekt-Owner      | Fach-Experte, Auftraggeber           | ✅        |
+| 🏗️ Lead Architect         | Strategie, ADRs, Domänen-Modell      | ✅        |
+| 👷 Backend Developer       | Spring Boot, Kotlin, SQL, API        | ✅        |
+| 🎨 Frontend Expert         | KMP, Compose Desktop, ViewModels     | ✅        |
+| 🐧 DevOps Engineer         | Docker, CI/CD, Packaging             | ✅        |
+| 🧐 QA Specialist           | Tests, Edge-Cases, Qualität          | ✅        |
+| 📜 ÖTO/FEI Rulebook Expert | Regelwerk, Validierung, Compliance   | ✅        |
+| 🖌️ UI/UX Designer         | Wireframes, Design-System, Usability | ✅        |
+| 🧹 Curator                 | Dokumentation, Logs, Aufräumen       | ✅        |
+
+---
+
+## 🎯 Ziele der Besprechung
+
+1. Übersicht über den aktuellen Projektstand verschaffen
+2. Strategie für die nächsten Entwicklungsschritte besprechen
+3. Individuelle Arbeitsaufträge für jeden Entwickler ausarbeiten
+4. Genaue Reihenfolge der nächsten Entwicklungsschritte festlegen
+
+---
+
+## 📊 Besprochene Themen & Beschlüsse
+
+### 1. Domänen-Modell präzisiert
+
+**Beschluss:** Die Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` wurde offiziell festgelegt.
+
+```
+Veranstalter
+  └── Veranstaltung  (interne ID, Tenant-Grenze / eigene Datenbank)
+        └── Turnier  (OEPS-Turniernummer, z.B. 26128)
+              └── Bewerb / Prüfung  (z.B. Bewerb 3 "Stilspringen 90cm")
+                    └── Abteilung(en)  ← KLEINSTE EINHEIT
+                          ├── eigene Startliste
+                          ├── eigene Ergebnisliste
+                          └── eigene Siegerehrung (je nach Typ)
+```
+
+**Wichtig:** Eine `Veranstaltung` kann mehrere `Turniere` enthalten (Beispiel Neumarkt 2026: zwei OEPS-Turniere mit je
+eigener Turniernummer unter einer gemeinsamen Veranstaltung).
+
+**Abteilungs-Typen:**
+
+- `SEPARATE_SIEGEREHRUNG` — Abteilung mit eigenständiger Siegerehrung (z.B. Lizenz-Trennung im CSN-C-NEU)
+- `ORGANISATORISCH` — Rein organisatorische Aufteilung, Ergebnisse werden zur Gesamtrangliste zusammengeführt
+
+---
+
+### 2. Veranstaltungs-Kassa Konzept
+
+**Beschluss:** Die Veranstaltungs-Kassa ermöglicht turnier-übergreifende Saldoansicht mit einem Zahlvorgang aber
+separaten Rechnungen je Turnier.
+
+```
+VERANSTALTUNGS-KASSA
+  ├── TeilnehmerKonto (Reiter × Pferd, pro Veranstaltung)
+  │     ├── Saldo aus Turnier #1
+  │     └── Saldo aus Turnier #2
+  │           Gesamt-Offener-Betrag
+  └── Zahlvorgang (1× Kassagang)
+        ├── Rechnung Turnier #1  → OEPS-Meldung Turnier-Nr. X
+        └── Rechnung Turnier #2  → OEPS-Meldung Turnier-Nr. Y
+```
+
+**Begründung:** OEPS-Pflicht — jedes Turnier mit eigener Turniernummer muss separat gemeldet werden.
+
+---
+
+### 3. Neue Domänen-Begriffe (für `Ubiquitous_Language.md`)
+
+| Begriff                  | Definition                                                                                                  |
+|--------------------------|-------------------------------------------------------------------------------------------------------------|
+| **Abteilung**            | Kleinste ausführbare Einheit eines Bewerbs. Hat eigene Startliste, Ergebnisse und ggf. eigene Siegerehrung. |
+| **TeilnehmerKonto**      | Aggregiertes Konto eines Teilnehmers auf Veranstaltungsebene über mehrere Turniere.                         |
+| **Veranstaltungs-Kassa** | Kassa-Ansicht auf Veranstaltungsebene mit Turnier-übergreifendem Saldo.                                     |
+| **TurnierKassa**         | Kassa für ein einzelnes Turnier (separate OEPS-Abrechnung).                                                 |
+| **Zahlvorgang**          | Ein Kassagang — kann mehrere Rechnungen (je Turnier) umfassen.                                              |
+| `SEPARATE_SIEGEREHRUNG`  | Abteilungs-Typ mit eigenständiger Siegerehrung.                                                             |
+| `ORGANISATORISCH`        | Abteilungs-Typ mit zusammengeführter Gesamtrangliste.                                                       |
+
+---
+
+### 4. Abteilungs-Zwangsteilung im CSN-C-NEU
+
+**Beschluss:** Das System muss beim Anlegen eines Bewerbs im CSN-C-NEU automatisch die korrekten Abteilungen vorschlagen
+bzw. erzwingen.
+
+| Kategorie     | Höhe      | Pflicht-Teilung              |
+|---------------|-----------|------------------------------|
+| **CSN-C-NEU** | bis 95 cm | `ohne Lizenz` ↔ `mit Lizenz` |
+| **CSN-C-NEU** | ab 100 cm | `R1` ↔ `R2 und höher`        |
+
+---
+
+### 5. Strategie: 3 Säulen des nächsten Sprints
+
+```
+SÄULE 1: FUNDAMENT         SÄULE 2: VERBINDUNG        SÄULE 3: QUALITÄT
+─────────────────────      ──────────────────────      ─────────────────────
+ViewModel-Architektur  →   CRUD-APIs Backend       →   ÖTO-Validierung
+Tenant-Isolation       →   Frontend-Anbindung      →   Tests & QA
+Dokumentation (ADR)    →   Desktop-Packaging       →   UI/UX Konsistenz
+```
+
+**Reihenfolge:** Säule 1 → Säule 2 → Säule 3 (jede Säule blockt die nächste)
+
+---
+
+### 6. Sprint-Planung
+
+#### 🔴 Sprint A — Sofort (diese Woche)
+
+| #   | Wer           | Aufgabe                                                                                           |
+|-----|---------------|---------------------------------------------------------------------------------------------------|
+| A-1 | 🏗️ Architect | **ADR-0021**: Tenant-Resolution-Strategie (Schema-per-Tenant vs. Tenant-ID) → **BLOCKER für A-3** |
+| A-2 | 🎨 Frontend   | ViewModel-Architektur (MVVM/UDF) definieren + `VeranstalterViewModel` als Referenz                |
+| A-3 | 👷 Backend    | Tenant-Isolation im Datenzugriffs-Layer (nach ADR-0021)                                           |
+| A-4 | 🧹 Curator    | `Ubiquitous_Language.md`, Event-First-Workflow, Navigation-V2, Tenant-Konzept dokumentieren       |
+| A-5 | 📜 Rulebook   | Validierungsregeln für OEPS-Nr., FEI-ID, Lizenzklassen + Abteilungs-Zwangsteilung spezifizieren   |
+| A-6 | 🖌️ UI/UX     | Design-Inventur: V2-Screens katalogisieren, Inkonsistenzen dokumentieren                          |
+
+#### 🟠 Sprint B — Nächste Woche
+
+| #   | Wer         | Aufgabe                                                               |
+|-----|-------------|-----------------------------------------------------------------------|
+| B-1 | 👷 Backend  | CRUD-Endpunkte für alle Stammdaten-Entitäten                          |
+| B-2 | 🎨 Frontend | Alle V2-ViewModels + Ktor-Client-Repositories                         |
+| B-3 | 📜 + 🎨     | Validierungslogik als Live-Feedback in V2-Edit-Dialogen               |
+| B-4 | 📜 + 👷     | Validierungslogik serverseitig absichern                              |
+| B-5 | 🖌️ UI/UX   | Wireframes: Editier-Formulare, Bewerb+Abteilung, Veranstaltungs-Kassa |
+| B-6 | 🧐 QA       | Test-Suite: Navigation/Back-Stack + Onboarding-Edge-Cases             |
+| B-7 | 🐧 DevOps   | CI/CD Pipeline für Compose-Desktop-Tests (headless)                   |
+
+#### 🟡 Sprint C — In 2 Wochen
+
+| #   | Wer           | Aufgabe                                                           |
+|-----|---------------|-------------------------------------------------------------------|
+| C-1 | 🐧 DevOps     | Desktop-App Packaging (.msi / .deb / .dmg)                        |
+| C-2 | 🏗️ Architect | Sync-Protokoll-Konzept (Event-Sourcing vs. CRDT vs. Timestamp)    |
+| C-3 | 👷 Backend    | Testdaten-Seeder                                                  |
+| C-4 | 🧐 QA         | Mandanten-Isolations-Testfälle                                    |
+| C-5 | 🖌️ UI/UX     | Wireframes implementieren + Empty States                          |
+| C-6 | 📜 Rulebook   | AltersklasseRechner testen + Funktionärs-Qualifikationen als Enum |
+| C-7 | 🧹 Curator    | README + Setup-Guide + Docs-Struktur + V1-Bereinigung             |
+| C-8 | 🏗️ Architect | MASTER_ROADMAP aktualisieren                                      |
+| C-9 | 🐧 DevOps     | Semantic Versioning + Release-Strategie                           |
+
+---
+
+## ⏸️ Zurückgestellte Themen
+
+> Explizit vom Owner auf "später" verschoben — keine Priorität in Sprint A–C.
+
+| Thema                                                       | Begründung                                                            |
+|-------------------------------------------------------------|-----------------------------------------------------------------------|
+| ⏸️ **USB-Stick Fallback bei LAN-Ausfall**                   | Konzept bekannt, aber aktuell kein Sprint-Slot — separate Besprechung |
+| ⏸️ **Web-App Präsentation (Veranstaltungs-/Turnier-Seite)** | Separate Besprechung erforderlich                                     |
+| ⏸️ **Nenn-System (Web-Formular)**                           | Separate Besprechung erforderlich                                     |
+| ⏸️ **Live-Ergebnisse (Web-App)**                            | Separate Besprechung erforderlich                                     |
+
+---
+
+## 📌 Erstellte Artefakte
+
+| Datei                                                      | Beschreibung                                    |
+|------------------------------------------------------------|-------------------------------------------------|
+| `docs/04_Agents/Roadmaps/Architect_Roadmap.md`             | Sprint-Roadmap für 🏗️ Lead Architect           |
+| `docs/04_Agents/Roadmaps/Backend_Roadmap.md`               | Sprint-Roadmap für 👷 Backend Developer         |
+| `docs/04_Agents/Roadmaps/Frontend_Roadmap.md`              | Sprint-Roadmap für 🎨 Frontend Expert           |
+| `docs/04_Agents/Roadmaps/DevOps_Roadmap.md`                | Sprint-Roadmap für 🐧 DevOps Engineer           |
+| `docs/04_Agents/Roadmaps/QA_Roadmap.md`                    | Sprint-Roadmap für 🧐 QA Specialist             |
+| `docs/04_Agents/Roadmaps/Rulebook_Roadmap.md`              | Sprint-Roadmap für 📜 Rulebook Expert           |
+| `docs/04_Agents/Roadmaps/UIUX_Roadmap.md`                  | Sprint-Roadmap für 🖌️ UI/UX Designer           |
+| `docs/04_Agents/Roadmaps/Curator_Roadmap.md`               | Sprint-Roadmap für 🧹 Curator                   |
+| `docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md`        | Entwickler-übergreifende Ausführungsreihenfolge |
+| `docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md` | **Dieses Dokument**                             |
+
+---
+
+## ✅ Offizielle Beschlüsse
+
+1. **ADR-0021 (Tenant-Resolution)** wird sofort vom Architect erstellt — kritischer Blocker.
+2. **ViewModel-Architektur** wird vor neuen Features eingeführt — kein neuer Code ohne ViewModel.
+3. **Kein neues Feature ohne ÖTO-Validierung** — Rulebook Expert gibt Spezifikation vor.
+4. **Mock-Store (`StoreV2`) ist temporär** — Ablösung durch echtes Backend in Sprint B.
+5. **MASTER_ROADMAP** wird am Ende von Sprint C durch den Architect aktualisiert.
+6. **`Abteilung`** ist die kleinste ausführbare Einheit — alle Entwickler müssen dies sofort in ihre Arbeiten einfließen
+   lassen.
+7. **Fokus liegt auf der Desktop-App** (Sprint A+B). Web-App kommt danach (Sprint C+D).
+
+---
+
+> 🏁 **Besprechung offiziell beendet um ca. 14:30 Uhr, 2. April 2026.**
+> Sprint A beginnt sofort.

docs/99_Journal/2026-04-02_Session_Log.md

@@ -0,0 +1,32 @@
+# 🧹 [Curator] Session Log - 2. April 2026
+
+## Zusammenfassung
+
+Der User forderte basierend auf den massiven Frontend-Änderungen der letzten Tage einen Statusbericht und priorisierte
+nächste Schritte von fast allen Agenten an (`🎨 [Frontend Expert]`, `👷 [Backend Developer]`,
+`📜 [ÖTO/FEI Rulebook Expert]`, `🐧 [DevOps Engineer]`, `🧐 [QA Specialist]`, `🖌️ [UI/UX Designer]`, `🧹 [Curator]`).
+
+## Aktionen
+
+* Analyse der Git-Historie und des Commits `d3d80f69` (Neue V2-Screens, Onboarding-Verbesserungen, Bestätigungsdialoge).
+* Erstellung und Speicherung detaillierter Reports in `docs/90_Reports/`:
+  * `2026-04-02_Frontend_Report.md`
+  * `2026-04-02_Backend_Report.md`
+  * `2026-04-02_Rulebook_Report.md`
+  * `2026-04-02_DevOps_Report.md`
+  * `2026-04-02_QA_Report.md`
+  * `2026-04-02_UIUX_Report.md`
+  * `2026-04-02_Curator_Report.md`
+
+## Nächste Schritte (Übergreifend)
+
+1. **Frontend/UI:** Fokus auf State-Management (ViewModels statt lokaler UI-State), Vorbereitung der API-Anbindung und
+   Überarbeitung der UX für die Edit-Dialoge.
+2. **Backend:** Bereitstellung der benötigten CRUD-Endpunkte für die neuen V2-Screens und Abgleich der
+   DTOs/Datenbank-Schemas.
+3. **QA/Rulebook:** Strikte Validierungsregeln implementieren und den komplexen Back-Stack (Navigation) durch
+   automatisierte und manuelle Tests absichern.
+4. **DevOps/Architektur:** Dokumentation der Offline-Architektur (Tenant-Isolation/LAN-Sync) vervollständigen und die
+   CI/CD-Pipeline für Compose-Desktop-Pakete vorbereiten.
+5. **Clean-Up:** Alte "V1"-Screens und ungenutzte Platzhalter entfernen und die Ordnerstruktur für Dokumente und Reports
+   aufräumen.

docs/temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md

@@ -0,0 +1,135 @@
+🏗️ **[Lead Architect]** — Domänen-Korrektur & USB-Fallback-Präzisierung | 2. April 2026
+
+---
+
+### ✅ Domänen-Korrektur wird übernommen: Die vollständige Hierarchie
+
+Danke für die wichtige Korrektur. Das Domänen-Modell wird entsprechend präzisiert:
+
+```
+Veranstaltung  (interne ID, Tenant-Grenze)
+  └── Turnier  (OEPS-Turniernummer, z.B. 26128)
+        └── Prüfung / Bewerb  (z.B. Bewerb 3 "90cm Stilspringen")
+              └── Abteilung(en)  ← KLEINSTE EINHEIT
+                    ├── eigene Startliste
+                    ├── eigene Ergebnisliste
+                    └── eigene Siegerehrung
+```
+
+**Das bedeutet konkret:**  
+Ein Bewerb (z.B. "Springprüfung 90cm") kann in **mehrere Abteilungen** aufgeteilt werden — entweder wegen zu vieler
+Starter (Teilungs-Abteilung) oder weil es regelkonform zwingend ist (z.B. im CSN-C-NEU: `ohne Lizenz` vs. `mit Lizenz`).
+
+Die `Abteilung` ist die Einheit, die:
+
+- eine **Startnummern-Vergabe** hat
+- eine **Startliste** hat (wird an den Richter-Turm übergeben)
+- ein **Ergebnis** hat (kommt vom Richter-Turm zurück)
+- eine **Siegerehrung** bekommt
+
+---
+
+### 🔧 USB-Fallback Konzept: Korrigiert auf Abteilungs-Ebene
+
+Das USB-Export/Import-Protokoll aus der letzten Besprechung wird auf die korrekte kleinste Einheit angepasst:
+
+#### Korrigiertes Dateiformat
+
+```json
+{
+  "meldestelle_export": {
+    "version": "1.0",
+    "veranstaltung_id": "NM-2026",
+    "turnier_nr": "26128",
+    "bewerb_nr": 3,
+    "bewerb_bezeichnung": "Stilspringen 90cm",
+    "abteilung_nr": 1,
+    "abteilung_bezeichnung": "ohne Lizenz",
+    "exportiert_am": "2026-04-25T10:15:00",
+    "exportiert_von": "MELDESTELLE",
+    "typ": "STARTLISTE",
+    "checksum": "sha256:...",
+    "daten": {
+      ...
+    }
+  }
+}
+```
+
+#### Korrigierter Export-/Import-Flow
+
+```
+MELDESTELLE (Desktop)                      RICHTER-TURM (Desktop)
+──────────────────────                     ──────────────────────
+Bewerb 3 hat 2 Abteilungen:
+  [Export Startliste Abt. 1]  ──USB──►  [Import → Richter startet Abt. 1]
+  [Export Startliste Abt. 2]  ──USB──►  [Import → Richter startet Abt. 2]
+  
+                              ◄──USB──  [Export Ergebnis Abt. 1]
+                              ◄──USB──  [Export Ergebnis Abt. 2]
+[Import Ergebnis Abt. 1]
+[Import Ergebnis Abt. 2]
+  └── Gesamtrangliste Bewerb 3
+        (aus beiden Abteilungen, je nach Prüfungstyp)
+```
+
+#### Wichtige Regel für zusammengeführte Ergebnisse
+
+Nach dem Import beider Abteilungsergebnisse entscheidet der **Prüfungstyp**, ob:
+
+- **Separate Siegerehrung** pro Abteilung (z.B. CSN-C-NEU: `ohne Lizenz` und `mit Lizenz` werden getrennt geehrt), *
+  *oder**
+- **Gesamtrangliste** aus allen Abteilungen (bei rein organisatorischer Teilung wegen Starter-Anzahl)
+
+Diese Unterscheidung muss beim Anlegen der Abteilung gesetzt werden (
+`abteilung_typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`).
+
+---
+
+### 📄 TURNIER_KLASSEN.md Update — Konsequenzen für das System
+
+Das aktualisierte Dokument bestätigt und formalisiert die **zwingende Abteilungs-Teilung** im C-NEU-Bereich:
+
+| Kategorie     | Höhe      | Pflicht-Teilung                                  |
+|---------------|-----------|--------------------------------------------------|
+| **CSN-C-NEU** | bis 95 cm | Abteilung `ohne Lizenz` ↔ Abteilung `mit Lizenz` |
+| **CSN-C-NEU** | ab 100 cm | Abteilung `R1` ↔ Abteilung `R2 und höher`        |
+
+Das ist kein optionales Feature — das System **muss** beim Anlegen eines Bewerbs im CSN-C-NEU automatisch die korrekten
+Abteilungen vorschlagen bzw. erzwingen.
+
+**Arbeitsauftrag daraus (ergänzt zu Sprint A-5):**
+
+| #    | Wer         | Aufgabe                                                                                                                    |
+|------|-------------|----------------------------------------------------------------------------------------------------------------------------|
+| A-5a | 📜 Rulebook | Vollständige Liste aller zwingenden Abteilungs-Teilungsregeln aus ÖTO 2026 spezifizieren (C-NEU bereits bekannt, weitere?) |
+| A-5b | 👷 Backend  | `Abteilung`-Entität ins Schema aufnehmen (FK: `bewerb_id`, Felder: `nr`, `bezeichnung`, `typ`, `siegerehrung_separat`)     |
+| A-5c | 🎨 Frontend | Beim Anlegen eines Bewerbs: Abteilungs-Logik als Teil des Bewerb-Dialogs (Vorschlag + Pflicht-Validierung)                 |
+
+---
+
+### 📌 Aktualisierte Domänen-Begriffe für `Ubiquitous_Language.md`
+
+Folgende Begriffe müssen ergänzt werden (Auftrag an 🧹 Curator):
+
+| Begriff                 | Definition                                                                                                                                 |
+|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|
+| **Abteilung**           | Kleinste ausführbare Einheit eines Bewerbs/einer Prüfung. Hat eine eigene Startliste, eigene Ergebnisse und ggf. eine eigene Siegerehrung. |
+| `SEPARATE_SIEGEREHRUNG` | Abteilungs-Typ: Die Abteilung hat eine eigenständige Siegerehrung (z.B. bei Lizenz-Trennung im C-NEU).                                     |
+| `ORGANISATORISCH`       | Abteilungs-Typ: Rein organisatorische Aufteilung wegen Starter-Anzahl. Ergebnisse werden in einer Gesamtrangliste zusammengeführt.         |
+
+---
+
+### 🎯 Scope-Bestätigung
+
+| Thema                                   | Status                                    |
+|-----------------------------------------|-------------------------------------------|
+| USB-Fallback (korrigiert auf Abteilung) | ✅ Konzept präzisiert — weiter in Sprint B |
+| Web-App Präsentation-Hierarchie         | ⏸️ Separate Besprechung später            |
+| Nenn-System Web-Formular                | ⏸️ Separate Besprechung später            |
+| Live-Ergebnisse Web-App                 | ⏸️ Separate Besprechung später            |
+| **Fokus jetzt**                         | 🖥️ Desktop-App (Sprint A + B)            |
+
+> ⚠️ **Wichtiger Hinweis für alle Entwickler:** Die `Abteilung` als eigenständige Domänen-Entität muss **sofort** in
+> alle laufenden Arbeiten einfließen — besonders in das Backend-Schema (A-3) und das ViewModel-Design (A-2). Wer
+> Startlisten oder Ergebnisse ohne Abteilungs-Bezug modelliert, baut falsch.

docs/temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md

@@ -0,0 +1,26 @@
+Meldestelle Besprechung!
+
+Wir berufen diese Besprechung ein, um die nächsten Entwicklungsschritte zu besprechen.
+Es liegen aktuellen Reports aller Entwickler von diesem Projekt vor.
+Jeder Entwickler hat in seinem Report Empfehlungen priorisiert.
+
+docs/90_Reports/2026-04-02_Architect_Report.md
+docs/90_Reports/2026-04-02_Backend_Report.md
+docs/90_Reports/2026-04-02_Curator_Report.md
+docs/90_Reports/2026-04-02_DevOps_Report.md
+docs/90_Reports/2026-04-02_Frontend_Report.md
+docs/90_Reports/2026-04-02_QA_Report.md
+docs/90_Reports/2026-04-02_Rulebook_Report.md
+docs/90_Reports/2026-04-02_UIUX_Report.md
+
+In dieser Besprechung wollen wir
+
+- Übersicht bekommen
+- Strategie besprechen
+- Arbeitsaufträge für jeden Entwickler ausarbeiten
+- genaue Reihenfolge der nächsten Entwicklungsschritte festlegen
+
+Am Ende dieser Besprechung, soll jeder Entwickler genau wissen was er wann machen soll.
+Wir wollen alle an einem Strang ziehen.
+
+Sind alle Entwickler anwesend und vorbereitet?

docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md

@@ -0,0 +1,167 @@
+🏗️ **[Lead Architect]** — Besprechungsprotokoll | Meldestelle-Biest | 2. April 2026
+
+---
+
+### 📋 Anwesenheit & Vorbereitung
+
+| Agent                | Anwesend | Report vorliegend |
+|----------------------|----------|-------------------|
+| 🏗️ Lead Architect   | ✅        | ✅                 |
+| 👷 Backend Developer | ✅        | ✅                 |
+| 🎨 Frontend Expert   | ✅        | ✅                 |
+| 🐧 DevOps Engineer   | ✅        | ✅                 |
+| 🧐 QA Specialist     | ✅        | ✅                 |
+| 📜 Rulebook Expert   | ✅        | ✅                 |
+| 🖌️ UI/UX Designer   | ✅        | ✅                 |
+| 🧹 Curator           | ✅        | ✅                 |
+
+**Alle Entwickler sind anwesend und haben ihre Reports eingereicht. Die Besprechung kann beginnen.**
+
+---
+
+### 📊 Übersicht: Wo stehen wir?
+
+Das Projekt hat in den letzten Tagen starken Momentum im **Frontend** (V2-Screens, Event-First-Workflow, Navigation mit
+Back-Stack) aufgebaut. Die Desktop-App nimmt konkrete Form an. Gleichzeitig haben sich **drei kritische Schulden**
+aufgebaut, die jetzt adressiert werden müssen, bevor wir weiter bauen:
+
+1. **Frontend-Architektur-Schulden:** Business-Logik liegt direkt in den Composables (`StoreV2`-Aufrufe, lokaler
+   `remember`-State). Ohne ViewModel-Refactoring wird der Code bald unwartbar.
+2. **Backend fehlt als Fundament:** Das Frontend läuft auf einem Mock-Store. Echte CRUD-Endpunkte und Tenant-Isolation
+   fehlen vollständig.
+3. **Validierung ist ein Sicherheitsloch:** FEI-IDs, OEPS-Nummern und Lizenzklassen können aktuell als beliebige Strings
+   gespeichert werden — das verletzt ÖTO/FEI-Compliance.
+
+**Kernaussage der Besprechung:** Wir müssen jetzt das Fundament stärken, bevor wir neue Features bauen.
+
+---
+
+### 🎯 Strategie: Die 3 Säulen des nächsten Sprints
+
+```
+SÄULE 1: FUNDAMENT         SÄULE 2: VERBINDUNG        SÄULE 3: QUALITÄT
+─────────────────────      ──────────────────────      ─────────────────────
+ViewModel-Architektur  →   CRUD-APIs Backend       →   ÖTO-Validierung
+Tenant-Isolation       →   Frontend-Anbindung      →   Tests & QA
+Dokumentation (ADR)    →   Desktop-Packaging       →   UI/UX Konsistenz
+```
+
+Wir arbeiten **in dieser Reihenfolge** — Säule 1 blockiert Säule 2, Säule 2 blockiert Säule 3.
+
+---
+
+### 📅 Reihenfolge der nächsten Entwicklungsschritte
+
+#### 🔴 Sprint A — Sofort (diese Woche)
+
+**Ziel: Das Fundament stabilisieren, damit alle anderen aufbauen können.**
+
+| #   | Wer           | Aufgabe                                                                                                                  |
+|-----|---------------|--------------------------------------------------------------------------------------------------------------------------|
+| A-1 | 🏗️ Architect | Tenant-Resolution-Strategie entscheiden (Schema-per-Tenant vs. Tenant-ID in allen Tabellen) — **Ergebnis: ADR-0021**     |
+| A-2 | 🎨 Frontend   | ViewModel-Architektur definieren und `VeranstalterViewModel` als Referenz-Implementierung (MVVM/UDF) umsetzen            |
+| A-3 | 👷 Backend    | Tenant-Isolation im Datenzugriffs-Layer implementieren auf Basis von ADR-0021                                            |
+| A-4 | 🧹 Curator    | `docs/01_Architecture/` mit Event-First-Workflow, Navigation-V2 und Tenant-Konzept dokumentieren                         |
+| A-5 | 📜 Rulebook   | Validierungsregeln für OEPS-Nummern, FEI-IDs und Lizenzklassen (R1–R4) schriftlich spezifizieren — als Grundlage für A-6 |
+
+> ⚠️ **A-1 (ADR-0021) ist ein Blocker für A-3!** Der Architect liefert zuerst.
+
+---
+
+#### 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+**Ziel: Frontend und Backend verbinden, Validierung implementieren.**
+
+| #   | Wer                       | Aufgabe                                                                                                                                |
+|-----|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------|
+| B-1 | 👷 Backend                | CRUD-Endpunkte für Veranstalter, Veranstaltungen, Reiter, Pferde, Vereine, Funktionäre implementieren                                  |
+| B-2 | 🎨 Frontend               | ViewModels für alle V2-Screens umsetzen (`PferdProfilViewModel`, etc.) und Ktor-Clients/Repositories für Backend-Anbindung vorbereiten |
+| B-3 | 📜 Rulebook + 🎨 Frontend | Validierungslogik aus Sprint A-5 als Live-Feedback in V2-Edit-Dialogen implementieren                                                  |
+| B-4 | 📜 Rulebook + 👷 Backend  | Dieselbe Validierungslogik serverseitig absichern                                                                                      |
+| B-5 | 🖌️ UI/UX                 | UX-Konzept für Editier-Formulare überarbeiten: AlertDialog vs. dedizierter Screen / Sliding-Panel — **Ergebnis: Wireframes**           |
+| B-6 | 🧐 QA                     | Test-Suite für V2-Navigation und Back-Stack aufbauen; Edge-Cases für Onboarding/Wizard (leere Felder, schnelles Klicken, Abbrechen)    |
+| B-7 | 🐧 DevOps                 | CI/CD Pipeline für Compose-Desktop-Tests headless konfigurieren (GitHub/Gitea Actions)                                                 |
+
+---
+
+#### 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+**Ziel: Ausliefern, offline-fähig machen, aufräumen.**
+
+| #   | Wer           | Aufgabe                                                                                                                 |
+|-----|---------------|-------------------------------------------------------------------------------------------------------------------------|
+| C-1 | 🐧 DevOps     | Desktop-App-Packaging konfigurieren (`.msi` / `.deb` / `.dmg`) via `compose.desktop.nativeDistributions`                |
+| C-2 | 🏗️ Architect | Synchronisations-Protokoll-Konzeption starten (Event-Sourcing vs. CRDT vs. Timestamp-Sync)                              |
+| C-3 | 👷 Backend    | Testdaten-Seeder implementieren (reproduzierbare Turnier-, Nennungs- und Stammdaten)                                    |
+| C-4 | 🧐 QA         | Testfälle für Mandanten-Isolation (Daten strikt zwischen Veranstaltungen getrennt)                                      |
+| C-5 | 🖌️ UI/UX     | Wireframes aus B-5 implementieren; Empty States für alle Listenansichten designen und umsetzen                          |
+| C-6 | 📜 Rulebook   | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Funktionärs-Qualifikationen auf Enum umstellen                 |
+| C-7 | 🧹 Curator    | `README.md` und Setup-Guide aktualisieren; Unterordner-Struktur für `docs/` einführen; V1-Code-Bereinigung koordinieren |
+| C-8 | 🏗️ Architect | `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine)                          |
+| C-9 | 🐧 DevOps     | Semantic Versioning Strategie einführen; koordiniertes Release-Tagging Client + Server                                  |
+
+---
+
+### 📌 Individuelle Arbeitsaufträge (Zusammenfassung)
+
+#### 🏗️ Lead Architect
+
+1. **[A-1, sofort]** ADR-0021 schreiben: Tenant-Resolution-Strategie entscheiden
+2. **[C-2]** Sync-Protokoll-Konzept starten
+3. **[C-8]** MASTER_ROADMAP aktualisieren
+
+#### 👷 Backend Developer
+
+1. **[A-3, nach ADR-0021]** Tenant-Isolation im Datenzugriffs-Layer
+2. **[B-1]** CRUD-APIs für alle Stammdaten-Entitäten
+3. **[B-4]** ÖTO-Validierung serverseitig absichern
+4. **[C-3]** Testdaten-Seeder
+
+#### 🎨 Frontend Expert
+
+1. **[A-2, sofort]** ViewModel-Referenz-Implementierung (`VeranstalterViewModel`, MVVM/UDF)
+2. **[B-2]** Alle V2-ViewModels + Ktor-Client-Repositories
+3. **[B-3]** Validierungs-Live-Feedback in Edit-Dialogen
+
+#### 🐧 DevOps Engineer
+
+1. **[B-7]** CI/CD für Compose Desktop Tests (headless)
+2. **[C-1]** Desktop-App Packaging (Distributionen)
+3. **[C-9]** Semantic Versioning + Release-Strategie
+
+#### 🧐 QA Specialist
+
+1. **[B-6, parallel zu Sprint B]** Test-Suite Navigation/Back-Stack + Onboarding-Edge-Cases
+2. **[C-4]** Mandanten-Isolations-Testfälle
+
+#### 📜 ÖTO/FEI Rulebook Expert
+
+1. **[A-5, sofort]** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenzklassen)
+2. **[B-3/B-4]** Implementierung der Validierung Frontend + Backend begleiten
+3. **[C-6]** AltersklasseRechner vollständig testen; Funktionärs-Qualifikationen als Enum
+
+#### 🖌️ UI/UX Designer
+
+1. **[B-5]** Wireframes: Dialog vs. Fullscreen-Edit entscheiden
+2. **[C-5]** Wireframes implementieren + Empty States designen und umsetzen
+
+#### 🧹 Curator
+
+1. **[A-4, sofort]** Event-First-Workflow + Navigation-V2 + Tenant-Konzept dokumentieren
+2. **[C-7]** README + Setup-Guide + Docs-Struktur + V1-Code-Bereinigung koordinieren
+
+---
+
+### ✅ Beschlüsse dieser Besprechung
+
+1. **ADR-0021 (Tenant-Resolution)** wird sofort vom Architect erstellt — es ist der wichtigste Blocker.
+2. **ViewModel-Architektur** wird vor neuen Features eingeführt — kein weiterer Code ohne ViewModel.
+3. **Kein neues Feature ohne ÖTO-Validierung** — Rulebook Expert gibt die Spezifikation vor, Backend + Frontend setzen
+   sie gemeinsam um.
+4. **Mock-Store (`StoreV2`) ist temporär** — Ziel von Sprint B ist die vollständige Ablösung durch echte
+   Backend-Anbindung.
+5. **MASTER_ROADMAP** wird am Ende von Sprint C durch den Architect aktualisiert.
+
+---
+
+> 🏁 **Alle Entwickler wissen, was sie wann zu tun haben. Wir ziehen an einem Strang. Sprint A beginnt jetzt.**

docs/temp/2026-04-02_Besprechung/Okay,_alle_Entwickler_haben_Ihre_Aufgabe.md

@@ -0,0 +1,42 @@
+🏗️ **[Lead Architect]** — Besprechungsabschluss | 2. April 2026
+
+---
+
+### Abschlussfrage an alle Entwickler
+
+Die Frage geht in die Runde — und hier die Rückmeldungen:
+
+| Agent                | Status                                                          | Offene Fragen |
+|----------------------|-----------------------------------------------------------------|---------------|
+| 🏗️ Lead Architect   | ✅ Klar — starte sofort mit ADR-0021                             | Keine         |
+| 👷 Backend Developer | ✅ Klar — warte auf ADR-0021, dann Schema                        | Keine         |
+| 🎨 Frontend Expert   | ✅ Klar — starte ViewModel-Architektur parallel                  | Keine         |
+| 🐧 DevOps Engineer   | ✅ Klar — CI/CD headless ist Sprint B Aufgabe                    | Keine         |
+| 🧐 QA Specialist     | ✅ Klar — Test-Strategie-Dokument und Navigation-Tests starten   | Keine         |
+| 📜 Rulebook Expert   | ✅ Klar — Validierungsregeln-Spezifikation beginnt sofort        | Keine         |
+| 🖌️ UI/UX Designer   | ✅ Klar — Design-Inventur der V2-Screens als erster Schritt      | Keine         |
+| 🧹 Curator           | ✅ Klar — `Ubiquitous_Language.md` und Session-Log sind Sprint A | Keine         |
+
+**Alle Entwickler sind informiert. Keine offenen Fragen.**
+
+---
+
+### 🏁 Besprechung offiziell beendet
+
+**Erstellt in dieser Besprechung:**
+
+- ✅ Strategischer Sprint-Plan (A → B → C) mit klaren Verantwortlichkeiten
+- ✅ 8 individuelle Schritt-für-Schritt Roadmaps (`docs/04_Agents/Roadmaps/`)
+- ✅ Entwickler-übergreifende Ausführungsreihenfolge (`SPRINT_EXECUTION_ORDER.md`)
+- ✅ Domänen-Modell präzisiert (`Veranstaltung → Turnier → Bewerb → Abteilung`)
+- ✅ Veranstaltungs-Kassa-Konzept ausgearbeitet (Multi-Turnier-Saldo, 1 Zahlung, 2 Rechnungen)
+- ✅ Zurückgestellte Themen dokumentiert (⏸️ USB-Fallback, Web-App, Nenn-System, Live-Ergebnisse)
+
+**Der nächste Schritt liegt beim Architect:** `ADR-0021` — Tenant-Resolution-Strategie.
+
+> 🎯 **Wir ziehen an einem Strang. Sprint A beginnt jetzt.**
+
+---
+
+*🧹 Curator-Hinweis: Session-Log dieser Besprechung bitte unter `docs/99_Journal/`
+als `2026-04-02_Besprechung_Sprint-Planung.md` ablegen — das ist Aufgabe A-5 in der Curator Roadmap.*

docs/temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md

@@ -0,0 +1,128 @@
+🏗️ **[Lead Architect]** — Antwort auf Domänen-Fragen des Projekt-Owners | 2. April 2026
+
+---
+
+### 1. Ist die Hierarchie korrekt verstanden? Fast — aber wir müssen das Domain-Modell schärfen.
+
+Dein Verständnis ist **im Kern richtig**, aber die aktuelle `Ubiquitous_Language.md` hat hier noch eine **Unschärfe**,
+die wir jetzt klären müssen:
+
+**Aktuelles Modell (wie dokumentiert):**
+
+```
+Veranstalter
+  └── Veranstaltung  (interne ID, selbst vergeben)
+        ├── Typ: Turnier | Reitertreffen | ...
+        └── [wenn Typ = Turnier]
+              └── Turniernummer (OEPS-vergeben, eindeutig)
+```
+
+Das aktuelle Modell impliziert **1 Veranstaltung = 1 Turnier** (eine Turniernummer je Veranstaltung).
+
+**Das Neumarkt-Szenario bricht dieses Modell auf:**
+Neumarkt ist **eine organisatorische Veranstaltung** (selber Veranstalter, selbes Gelände, selber Zeitraum), aber
+besteht aus **zwei offiziellen OEPS-Turnieren** mit je eigener Turniernummer.
+
+**Korrekte Hierarchie (erweitert):**
+
+```
+Veranstalter  (OEPS-Mitgliedsverein, z.B. URV Neumarkt)
+  └── Veranstaltung  (interne ID, z.B. "NM-2026")
+        │   ← Tenant-Grenze (eigene Datenbank, ADR-0020)
+        │   ← Örtlich & zeitlich begrenzt
+        │
+        ├── Turnier #1  (OEPS-Turniernummer: 26128, CSN-C NEU)
+        │     ├── Bewerbe (1–14)
+        │     └── Turnier-Kassa
+        │
+        └── Turnier #2  (OEPS-Turniernummer: 26129 o.ä., z.B. CSNP-C NEU)
+              ├── Bewerbe (1–N)
+              └── Turnier-Kassa
+```
+
+**Antwort auf deine Frage:** ✅ **Ja, genau so.** Die `Veranstaltung` ist unser interner Überbegriff mit selbst
+vergebener ID und ist gleichzeitig die Tenant-Grenze (eine Datenbank). Innerhalb dieser Veranstaltung gibt es eine oder
+mehrere pferdesportliche Veranstaltungen — aktuell vom Typ `Turnier` — jede mit ihrer vom Verband (OEPS/FEI) vergebenen
+Turniernummer. **Diese Unterscheidung muss noch in die `Ubiquitous_Language.md` und in das Datenbankschema einfließen
+** (das ist ein Arbeitsauftrag für den Curator + Backend).
+
+---
+
+### 2. Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo: Umsetzbar?
+
+✅ **Ja, das ist absolut umsetzbar — und architektonisch sauber lösbar.**
+
+#### Das Konzept: Drei Ebenen der Kassa
+
+```
+VERANSTALTUNGS-KASSA  (Aggregations-Ebene)
+  ├── TeilnehmerKonto (Reiter × Pferd, pro Veranstaltung)
+  │     ├── Saldo aus Turnier #1   (z.B. –€ 75,-)
+  │     └── Saldo aus Turnier #2   (z.B. –€ 45,-)
+  │           Gesamt-Offener-Betrag: –€ 120,-
+  │
+  └── Zahlvorgang  (1× Kassagang am Ende der Veranstaltung)
+        ├── Rechnung Turnier #1  (€ 75,-) → OEPS-Meldung Turnier 26128
+        └── Rechnung Turnier #2  (€ 45,-) → OEPS-Meldung Turnier 26129
+```
+
+#### Wie das funktioniert (Ablauf Neumarkt):
+
+| Schritt                                                        | Was passiert                                           |
+|----------------------------------------------------------------|--------------------------------------------------------|
+| Teilnehmer meldet sich für Bewerbe in **Turnier 1**            | Forderung wird `TurnierKassa #1` verbucht              |
+| Derselbe Teilnehmer meldet sich für Bewerbe in **Turnier 2**   | Forderung wird `TurnierKassa #2` verbucht              |
+| Teilnehmer kommt **einmal** zur Kassa (Ende der Veranstaltung) | System zeigt Gesamt-Saldo aus beiden Turnieren         |
+| Kassier nimmt **eine Zahlung** entgegen                        | `Zahlvorgang` wird auf `Veranstaltungs-Ebene` gebucht  |
+| System generiert **zwei separate Rechnungen**                  | Je eine pro Turnier (für OEPS-Abrechnung notwendig)    |
+| Turnier-Kassenabschluss                                        | Jede `TurnierKassa` schließt separat ab (OEPS-konform) |
+
+#### Warum zwei separate Rechnungen notwendig sind:
+
+Das ist nicht nur ein Komfort-Feature — es ist eine **OEPS-Pflicht**. Jedes Turnier mit eigener Turniernummer muss
+separat an den Verband gemeldet werden. Die Startgelder und Nenngelder sind je Turniernummer nachvollziehbar zu belegen.
+Eine gemeinsame Rechnung über beide Turniere würde die ZNS-Meldung erschweren.
+
+---
+
+### 3. Statistiken: Separat und aggregiert
+
+Selbe Logik, selbe Lösung:
+
+| Ansicht                            | Quelle                                             |
+|------------------------------------|----------------------------------------------------|
+| **Statistik Turnier #1**           | Nur Daten aus `Turnier.id = 26128`                 |
+| **Statistik Turnier #2**           | Nur Daten aus `Turnier.id = 26129`                 |
+| **Statistik Veranstaltung gesamt** | Aggregation über alle Turniere der `Veranstaltung` |
+
+Das ist eine reine Abfrage-/Reporting-Frage. Da die `Veranstaltung` die Tenant-Grenze ist (alle Daten in einer
+Datenbank), sind sowohl turnierspezifische als auch veranstaltungsweite Auswertungen mit einfachen SQL-Abfragen
+realisierbar — keine aufwendige Cross-Tenant-Kommunikation nötig.
+
+---
+
+### 📌 Was das für unsere Arbeitsaufträge bedeutet
+
+Deine Fragen zeigen eine **wichtige Lücke** im bisherigen Plan, die wir jetzt schließen müssen:
+
+| Priorität                    | Wer           | Aufgabe                                                                                                                     |
+|------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------|
+| 🔴 **Sofort (vor ADR-0021)** | 🏗️ Architect | Domänen-Modell präzisieren: `Veranstaltung` 1:N `Turnier` explizit festlegen. `Ubiquitous_Language.md` anpassen.            |
+| 🔴 **Sprint A**              | 👷 Backend    | Datenbankschema: `veranstaltungen` Tabelle + `turniere` Tabelle (mit FK auf Veranstaltung, Turniernummer als OEPS-vergeben) |
+| 🟠 **Sprint B**              | 👷 Backend    | `teilnehmer_konto` auf Veranstaltungs-Ebene; `zahlvorgang` mit Multi-Turnier-Aufteilung; Rechnungs-Generierung pro Turnier  |
+| 🟠 **Sprint B**              | 🎨 Frontend   | UI für Veranstaltungs-Kassa: Gesamtsaldo-Ansicht + Zahlvorgang + Rechnungsvorschau je Turnier                               |
+| 🟡 **Sprint C**              | 🧐 QA         | Testfälle: Teilnehmer an 2 Turnieren → 1 Zahlung → 2 korrekte Rechnungen                                                    |
+
+> ⚠️ **Wichtig:** Der Begriff `TeilnehmerKonto` auf Veranstaltungsebene (über mehrere Turniere) ist **neu** und muss in
+> die `Ubiquitous_Language.md` aufgenommen werden. Das ist ein Auftrag für Curator + Rulebook Expert gemeinsam.
+
+---
+
+### ✅ Kurz-Zusammenfassung für den Owner
+
+1. **Ja** — `Veranstaltung` (interne ID, Tenant-Grenze) enthält ein oder mehrere `Turnier` (mit OEPS-Turniernummer). Das
+   Modell muss noch formal so dokumentiert werden.
+2. **Ja** — Eine `Veranstaltungs-Kassa` mit Turnier-übergreifendem Saldo, einem Zahlvorgang, aber zwei separaten
+   Rechnungen ist architektonisch sauber umsetzbar und ist sogar die richtige Lösung für die OEPS-konforme Abrechnung.
+3. **Ja** — Statistiken können auf beiden Ebenen (per Turnier und gesamt per Veranstaltung) ausgewertet werden, ohne
+   Mehraufwand, da alle Daten im selben Tenant (Datenbank) liegen.