chore: entferne veraltete Architekturdokumente

Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
2026-05-05 21:22:46 +02:00
parent 6f15ada447
commit 15222b5453
258 changed files with 3388 additions and 6533 deletions
@@ -0,0 +1,66 @@
+# 🧹 [Curator] Session-Log – ZNS-Validierung & UI-Fixes
+
+Datum: 2026-04-21 · Kontext: Desktop-First, Offline-First · Initiative: Masterdata-Validierung & ZNS-Importer
+
+## Zusammenfassung
+
+In dieser Session wurde die Brücke zwischen der Wizard-Runtime und dem ZNS-Importer geschlagen. Wir haben die
+Validierungs-Logik für Stammdaten professionalisiert und einen kritischen UI-Bug im Login-Flow behoben.
+
+## Erreichte Ergebnisse
+
+- **UI-Fix (Frontend):**
+  - Behebung des "Anmelden"-Buttons im `ConnectivityCheck`-Screen. Der Callback wurde in der `ContentArea.kt` korrekt an
+    das `PingScreen` durchgereicht.
+- **Validierungs-Logik (Lead Architect & Rulebook Expert):**
+  - Erhöhung der Guard-Präzision in `DemoEventFlow`: Der `hasZns`-Guard prüft nun nicht mehr nur auf die reine Existenz
+    von Daten, sondern auch auf das Vorhandensein eines gültigen Import-Datums (`lastImport`).
+- **Wizard-Integration (Frontend):**
+  - `EventWizardViewModel`: Einführung von `reEvaluateCurrentStep()`, um den Wizard-Status reaktiv auf Daten-Eingaben
+    und Stammdaten-Updates zu aktualisieren.
+  - Automatischer Step-Forward: Sobald neue Stammdaten erkannt werden (z. B. nach einem ZNS-Import), springt der Wizard
+    automatisch zum nächsten Schritt.
+  - `EventWizardScreen`: Der eingebettete `StammdatenImportScreen` nutzt nun `reEvaluateCurrentStep()`, um einen
+    nahtlosen Übergang nach dem Import zu ermöglichen.
+- **Stabilität:**
+  - Erfolgreiche Kompilierung des Desktop-Shell-Moduls (`:frontend:shells:meldestelle-desktop`).
+  - Wizard-Unit-Tests (JVM/Common) sind vollständig grün (10/10).
+- **Fehlerbehebung (QA):**
+  - Korrektur von `WizardRuntimeJvmTest.selection_goes_to_ansprechperson_when_guard_true_by_default`, der aufgrund
+    unvollständiger Testdaten (fehlendes `ORG-` Präfix) fehlschlug.
+
+## Verifikation
+
+- **Gradle:** `./gradlew :frontend:shells:meldestelle-desktop:compileKotlinJvm` läuft fehlerfrei durch.
+- **Logic:** Reaktivität des ViewModels durch Einbindung von `reEvaluateCurrentStep()` in alle relevanten
+  State-Änderungen sichergestellt.
+
+## Nächste Schritte
+
+1. Implementierung der "Veranstalter-Validierung" gegen den lokalen Store im zweiten Wizard-Schritt (Prüfung der
+   OEBS-Nummer).
+2. Vorbereitung der Delta-Sync-Logik für den Abgleich mit der Cloud.
+3. Optimierung der ZNS-Importer-Performance für große Datensätze.
+
+🏗️ [Lead Architect] | 👷 [Backend Developer] | 🎨 [Frontend Expert] | 🧹 [Curator]
+
+## Repository-Strategie & Veranstalter-Validierung
+
+Um die Veranstalter-Wahl im Wizard robust zu gestalten, nutzen wir eine zweistufige Repository-Strategie:
+
+1. **`VereinRepository` (Lokal):** Primäre Quelle für bereits bekannte oder manuell angelegte Vereine. Wenn ein Verein
+   hier gefunden wird, gilt er als "validiert" für den Wizard.
+2. **`MasterdataRepository` / `ZnsImportProvider` (Global/Remote):** Fallback-Quelle. Falls die OEPS-Nummer lokal
+   unbekannt ist, wird in den (offline verfügbaren) ZNS-Stammdaten gesucht. Ein Fund hier führt zur Übernahme der Daten
+   in den lokalen Kontext.
+
+### Wizard-Guards
+
+- **`hasZns`:** Stellt sicher, dass überhaupt Stammdaten vorhanden sind (Initial-Check).
+- **`hasSelectedVeranstalter`:** Verhindert das Voranschreiten im Wizard, solange kein gültiger Veranstalter (lokale ID)
+  ausgewählt wurde.
+- **`needsContactPerson`:** Dynamische Weiche; erzwingt die manuelle Eingabe einer Ansprechperson, wenn der
+  Veranstalter-Datensatz unvollständig ist (z.B. neue ZNS-Importe ohne hinterlegte Kontaktperson).
+
+Diese Strategie sichert die Datenqualität beim Erstellen neuer Veranstaltungen, während sie dem User maximale
+Flexibilität (Import vs. Neuanlage) bietet.