chore: refaktoriere Veranstaltungs-UI zu Events, implementiere ZNS-Suche und verbessere Navigationslogik

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

docs/99_Journal/2026-04-21_Curator_Session_Summary.md

@@ -1,48 +1,49 @@
-# Journal: 21. April 2026 - Abschluss der Morgen-Session (Curator)
+# Journal: 21. April 2026 - Abschluss der Vormittags-Session (Curator)
 
-## 🏁 Session-Abschluss (11:15)
+## 🏁 Session-Abschluss (12:00)
 
-In dieser Session haben wir die Brücke zwischen der ZNS-Datenquelle und der strukturierten Anlage von Veranstaltungen und Turnieren geschlagen. Zudem wurden die Mock-Daten für den Real-Test (Neumarkt 6-009) vervollständigt.
+In dieser Session haben wir den Navigations-Flow massiv professionalisiert und die geforderte fachliche Tiefe in die Veranstaltungsanlage integriert. Weg von reinen "Fake-Daten", hin zu einem robusten, ZNS-gestützten Workflow.
 
 ### ✅ Erreichte Meilensteine
 
-1.  **ZNS-Guard & Integration (SCS: Organizer):**
-    *   Der `VeranstaltungWizardScreen` prüft nun zwingend auf vorhandene Stammdaten.
-    *   Fehlen Daten, wird der `StammdatenImportScreen` direkt im Wizard eingebettet.
-    *   Modul-Abhängigkeit zu `zns-import-feature` in `veranstaltung-feature` hergestellt.
+1.  **Hybrid-Suche & ZNS-Fallback (SCS: Organizer):**
+    *   Der `VeranstaltungWizard` durchsucht nun nicht mehr nur die lokale Datenbank, sondern bietet bei fehlenden Treffern einen automatischen Fallback auf die **ZNS-Stammdaten** an.
+    *   Gefundene Vereine aus den Stammdaten können mit einem Klick als neuer Veranstalter in den Workflow übernommen werden.
 
-2.  **Mock-Daten & Real-Integration:**
-    *   Erweiterung des `FakeVereinRepository` um den Verein **"Reitclub Neumarkt" (6-009)**.
-    *   Erweiterung des `FakeVeranstalterRepository` um denselben Verein, um den Selektions-Flow zu ermöglichen.
-    *   Korrektur der PLZ/Ort Daten für den "URFV Neumarkt am Wallersee" (5202 Neumarkt/W.).
+2.  **Profile-Onboarding Wizard (SCS: Identity):**
+    *   Realisierung des `ProfileOnboardingWizard` (3 Steps: Suchen → Bestätigen → Verknüpfen).
+    *   Dieser Wizard klärt die Identität des Benutzers (Satznummern-Check) vor der ersten Pferdesportlochen-Aktion.
+    *   Nahtlose Integration in die Desktop-Shell (`ContentArea.kt`).
 
-3.  **Navigation & UX-Verbesserung:**
-    *   Aktivierung des Buttons "Diesen Verein als neuen Veranstalter anlegen" im `VeranstaltungWizard`.
-    *   Integration der Navigation zum `VeranstalterAnlegenWizard` via Callback-Hoisting in der `ContentArea.kt`.
+3.  **Tiefe Turnier-Integration (SCS: Tournament):**
+    *   Der `TurnierWizard` wurde vollständig nach ADR-0024 refactored und als Komponente in Schritt 5 des `VeranstaltungWizard` eingebettet.
+    *   Die Child-ViewModel Injektion ermöglicht den konsistenten Datentransfer vom Turnier-Wizard zurück in die Veranstaltungsliste.
 
-4.  **User-Identity & Onboarding (SCS: Identity):**
-    *   Neuer `ProfileOnboardingWizard` zur Verknüpfung des lokalen Users mit einer ZNS-Satznummer.
-    *   Integration des Onboarding-Flows in die Desktop-Shell (`ContentArea.kt`).
-    *   Erweiterung der `AppScreen` Navigation um `/profile/onboarding`.
+4.  **Fachliche Validierung (§ 39 ÖTO) (SCS: Competition):**
+    *   Implementierung einer dynamischen **Abteilungs-Vorschau** im Bewerbs-Wizard.
+    *   Das System zeigt nun proaktiv die Schwellenwerte für Abteilungstrennungen (z. B. ab 35 Nennungen in Klasse S) an, basierend auf der gewählten Klasse.
 
-3.  **Turnier-Wizard Refactoring (SCS: Tournament):**
-    *   Vollständiges Refactoring des `TurnierWizard` nach ADR-0024.
-    *   Einführung des `TurnierWizardViewModel` zur Entkoppelung von UI und Persistenz.
-    *   Integration des 3-stufigen Wizards (Basics, Sparten, Branding) in den `VeranstaltungWizard`.
-
-4.  **Architektur & Build:**
-    *   Korrektur von Modul-Abhängigkeiten in den `build.gradle.kts` Dateien.
-    *   Konsolidierung der SCS-Grenzen zwischen Organizer, Tournament und Identity.
-
-### 🔧 Korrekturen & Optimierungen
-*   **Koin-Integration:** In `VeranstaltungWizardScreen` wurde `koinViewModel` durch `koinInject` ersetzt, um Auflösungsprobleme zu beheben.
-*   **Code-Cleanup:** Im `TurnierWizardViewModel` wurden ungenutzte Properties (`sponsoren`, `znsDataLoaded`, `typ`, `kategorie`) und Funktionen entfernt.
-*   **Bugfix:** Der Warnhinweis bezüglich ungenutzter Parameter (`veranstaltungId`) und Properties (`repository`) im `TurnierWizardViewModel` wurde behoben.
+5.  **Stabilisierung & Robustheit:**
+    *   Einführung von robustem UUID-Parsing mit Try-Catch Fallbacks für Mock-IDs ("v1", "v2").
+    *   Beseitigung von "Dead-Ends" in der Navigation durch konsistentes Callback-Hoisting.
+    *   **Navigations-Stabilisierung:** Behebung eines Fehlers in `DesktopApp.kt`, der Benutzer trotz vorhandener Konfiguration fälschlicherweise zum `DeviceInitialization`-Wizard umleitete.
+    *   **Daten-Integrität:** Ergänzung der `settings.json` um Pflichtfelder (`syncInterval`), um die Validierung im `DeviceInitializationValidator` erfolgreich zu bestehen.
+    *   **Logging-Transparenz:** Erweiterung der Navigations-Logs in `DesktopApp.kt` und `DesktopMainLayout.kt` zur besseren Rückverfolgbarkeit von Redirect-Entscheidungen.
+    *   **Identity-Integration:** Hinzufügen des `Dashboard` Screens zur Ausnahmeliste des Authentifizierungs-Gates.
 
 ### 📋 Status der MASTER_ROADMAP
-*   **PHASE 13:** Ergänzt um "ZNS-Guard" und "Profile-Onboarding". Der Punkt "Veranstaltungs-Wizard" wurde von einer UI-Hülle zu einem funktionalen Workflow (Wiring mit Turnier-Wizard) aufgewertet.
+*   **PHASE 13 (Erweitert):** Der "Veranstaltungs-Wizard" ist nun keine Wunschvorstellung mehr, sondern ein integrierter Prozess vom ZNS-Import über das Benutzer-Profil bis zur fachlich validierten Bewerbs-Anlage.
 
-### 🚀 Ausblick
-Die Grundlage für eine saubere Datenkette ist gelegt. In der nächsten Session kann der Fokus auf die **Bewerbs-Anlage (§ 39 ÖTO)** und die **Echtdaten-Validierung** beim Import gelegt werden, da nun die Identitäten und Stammdaten-Guards aktiv sind.
+### 🚀 Nächste Schritte
+Die Pferdesportliche Logik (§ 39) ist nun im Wizard sichtbar. Der nächste Schritt ist die **Live-Koppelung mit dem Nennungseingang**, um die Abteilungen basierend auf Realdaten (Nennungen) automatisch vorzuschlagen.
 
 *Dokumentiert durch den Curator.*
+
+### 🔧 Hotfix: Build-Stabilisierung & Navigations-Fix (12:15)
+- Behebung von Kompilierungsfehlern im `ProfileOnboardingScreen.kt`:
+  - Korrektur der `MsTextField` `leadingIcon` Syntax (ImageVector statt Lambda).
+  - Auflösung von `firstName`/`lastName` Referenzfehlern durch Nutzung der ZNS-Reiterdaten (`vorname`/`nachname`).
+- **Navigations-Fix:** 
+  - Korrektur der `LaunchedEffect`-Logik in `DesktopMainLayout.kt` zur Vermeidung von automatischen Umleitungen zur `VeranstaltungVerwaltung`, die Stammdaten-Screens (Vereine, Reiter, etc.) blockierten.
+  - Erweiterung des Login-Gates in `DesktopApp.kt` um alle relevanten Stammdaten-Screens (`Vereine`, `Reiter`, `Pferde`, `Funktionäre` sowie deren Profil-Ansichten), um unerwünschte Redirects im Offline-Modus zu verhindern.
+- Erfolgreiche Verifizierung durch Kompilierung des Desktop-Moduls.