docs(reports): add comprehensive status and recommendation reports for key roles

- Created and saved detailed reports for Frontend, Backend, UI/UX, Architecture, DevOps, QA, Rulebook, and Curation in `docs/90_Reports/`.
- Included prioritized action items, challenges, and next steps across disciplines.
- Addressed documentation gaps and organized steps for improving workflow consistency and validation across the stack.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

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_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.