fix: aktualisiere Logs und dokumentiere Workflow-Änderungen

Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
chore: entferne überflüssigen Abschnitt aus README
2026-05-06 23:03:30 +02:00 · 2026-05-06 22:40:01 +02:00 · 2026-05-06 22:37:04 +02:00 · 2026-05-06 22:29:17 +02:00 · 2026-05-06 22:24:15 +02:00 · 2026-05-06 21:36:28 +02:00
307 changed files with 5649 additions and 7487 deletions
@@ -0,0 +1,56 @@
+name: Feature Build — Windows MSI (via Conveyor)
+on:
+  workflow_dispatch: # Nur noch manueller Start möglich, da ARM64-Runner inkompatibel
+  # push:
+  #   branches: [ "feature/*" ] # Deaktiviert wegen ARM64 Exec Format Error
+
+jobs:
+  package-windows:
+    name: 📦 Windows .msi Packaging
+    # Desktop-CI ist nun via Conveyor auf Linux möglich
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup JDK 21 (Temurin)
+        uses: actions/setup-java@v4
+        with:
+          distribution: 'temurin'
+          java-version: '21'
+          cache: gradle
+
+      - name: Gradle Build (Uber-JAR)
+        run: |
+          ./gradlew :frontend:shells:meldestelle-desktop:jvmJar --no-daemon
+          ls -lh frontend/shells/meldestelle-desktop/build/libs/
+
+      - name: Setup Conveyor
+        run: |
+          # Conveyor-Installation via Debian-Paket (stabiler in CI)
+          sudo apt-get update && sudo apt-get install -y curl
+          # Wir nutzen die offizielle Empfehlung für Debian-basierte Systeme
+          curl -L https://conveyor.hydraulic.dev/install.sh -o install-conveyor.sh
+          # Validierung: Wenn es kein Shell-Skript ist (sondern HTML), abbrechen
+          if grep -q "<!DOCTYPE HTML" install-conveyor.sh; then
+            echo "Fehler: Download-URL lieferte HTML statt Skript. Nutze npm-Fallback."
+            npm install -g @hydraulic/conveyor
+          else
+            chmod +x install-conveyor.sh
+            ./install-conveyor.sh
+          fi
+          echo "$HOME/.conveyor/bin" >> $GITHUB_PATH
+
+      - name: Windows .msi mit Conveyor bauen
+        run: |
+          # HINWEIS: Erfordert aktuell einen x64-Linux-Runner.
+          # Schlägt auf ARM64 (Zora) mit 'Exec format error' fehl.
+          CONVEYOR_BIN=$(which conveyor || echo "$HOME/.conveyor/bin/conveyor")
+          $CONVEYOR_BIN make windows-msi
+
+      - name: .msi Artefakt hochladen
+        uses: actions/upload-artifact@v4
+        with:
+          name: meldestelle-windows-feature-build
+          path: output/*.msi
+          if-no-files-found: error
@@ -3,12 +3,15 @@
 Dieses Dokument definiert die Zusammenarbeit zwischen dem User (Owner) und den spezialisierten KI-Agenten.
 Es dient als zentraler **System-Prompt-Erweiterung** für neue Chat-Sessions.

-## 🚀 Strategische Ausrichtung
+## 🚀 Strategische Ausrichtung (Reality-Reset 28.04.2026)

 Das Projekt **"Meldestelle"** entwickelt eine ÖTO/FEI-konforme, offline-fähige Turnier-Software.
 1. **Desktop-First:** Primäres Ziel ist die Compose Desktop App (KMP). UX & Performance sind auf Profis optimiert.
-2. **Offline-First:** Das System muss autark (ohne Internet) funktionieren. Sync-Logik ist Kernbestandteil.
-3. **Domain-Driven:** 6 Bounded Contexts (SCS) bilden den fachlichen Rahmen.
+2. **Offline-First:** Das System muss autark (ohne Internet) funktionieren.
+3. **Domain-Driven:** Die Hierarchie **Veranstaltung -> Turnier -> Bewerb/Abteilung** ist das absolute Fundament.
+
+**WICHTIG:** Alle Agenten arbeiten ab sofort nur noch auf Basis von verifiziertem Code. "Halluzinationen" über
+abgeschlossene Phasen ohne entsprechende Implementierung sind untersagt.

 ## 1. Protokoll & Rollen-Badges
 Jede Agenten-Antwort **muss** mit dem entsprechenden Badge beginnen, um den Kontext und die Verantwortlichkeit zu klären.
@@ -37,7 +40,9 @@ Jede Agenten-Antwort **muss** mit dem entsprechenden Badge beginnen, um den Kont
 4.  **Doku-as-Code:** Änderungen an Code/Architektur müssen sofort in `docs/` (ADR/Reference) reflektiert werden.
 5.  **Session-Abschluss:** Jede Session endet mit einem Eintrag durch den **Curator** (Journal oder Artefakt).

-## 3. Projekt-Philosophie
-*   **Information Density over White Space:** Wir bauen ein Profi-Werkzeug, kein Spielzeug.
-*   **Speed over Animation:** Reaktionsgeschwindigkeit der UI hat höchste Priorität.
-*   **Offline-Authentizität:** Lokale Daten sind die "Source of Truth" für den User; der Server ist das Backup/Sync-Target.
+## 🚫 Anti-Halluzinations-Protokoll (WICHTIG)
+Um Fehlentscheidungen und falsche Status-Meldungen zu verhindern, gelten ab sofort folgende Regeln:
+1. **Kein "Erledigt" ohne Beweis:** Ein Task darf erst dann als abgeschlossen markiert werden, wenn ein Test-Log, ein erfolgreicher Build oder eine explizite Bestätigung des Users vorliegt.
+2. **Status "Verifikation ausstehend":** Code, der geschrieben, aber nicht auf Hardware getestet wurde, muss zwingend diesen Zusatz tragen.
+3. **Fakten-Check vor Abschluss:** Vor dem Senden der `submit`-Meldung muss der Agent prüfen: "Habe ich das wirklich laufen sehen oder nehme ich es nur an?"
+4. **Fehler-Eingeständnis:** Bei Entdeckung einer Halluzination ist sofort der User zu informieren und der Status in allen Dokumenten (Roadmap, Journal) zu korrigieren.
@@ -17,218 +17,19 @@ Versionierung folgt [Semantic Versioning](https://semver.org/lang/de/).

 ### Hinzugefügt

- **Onboarding & Desktop-UX - 15.04.2026:**
-  - **Desktop-App:** Dynamisierung der Statusanzeigen im App-Footer ("Cloud synchronisiert" & "Verbunden").
-  - **Connectivity-Tracking:** Implementierung des `ConnectivityTracker` (KMP) zur Echtzeit-Überwachung der API-Gateway
-    Erreichbarkeit.
-  - **LAN-Erkennung:** Integration des `NetworkDiscoveryService` (mDNS) im Footer zur Anzeige aktiver Instanzen im
-    lokalen Netzwerk.
-  - **Onboarding:** Datenfluss vom `SettingsManager` bis in den Footer finalisiert (Anzeige des echten Gerätenamens).
- **Online-Nennung & Integration - 15.04.2026:**
-  - **Backend (Mail-Service):** Finalisierung des `MailController` für Web-Nennungen inkl. SMTP-Versand via World4You.
-  - **Frontend (Desktop):** `NennungsEingangScreen` an Live-Daten vom `mail-service` angebunden.
-  - **Repository:** `NennungRemoteRepository` (KMP) um `holeNennungen()` erweitert.
- **Billing & ÖTO - 15.04.2026:**
-  - **Sportförderbeitrag:** Automatische Buchung von 1,00 EUR (§16 ÖTO) bei jeder Nennung im `entries-service`
-    implementiert.
+- **Basis-Infrastruktur & Domain-Definition:**
+  - DDD-Modelle für `Veranstaltung`, `Turnier`, `Bewerb` und `Abteilung` gemäß ÖTO definiert.
+  - ZNS-Parser Prototyp für Dateiformate (VEREIN01, LIZENZ01, PFERD01, RICHT01).
+  - Plan-B Mail-Service (Spring Boot) für Nennungs-Versand via World4You.
+  - Desktop-App Skelett mit Navigation und UI-Hüllen (Compose Desktop).

-### Behoben
+### Reality-Reset (28.04.2026)

- **Frontend (Desktop):** Behebung von Kompilierungsfehlern in `ScreenPreviews.kt` durch Implementierung der fehlenden 
-  `getStats()` Methode in den `MasterdataRepository`-Mocks.
- **Identity-Modul:** Umstellung auf `kotlin.time.Instant` zur Vermeidung von Deprecation-Warnungen und Behebung von
-  Persistenz-Konflikten im `ExposedDeviceRepository`.
- **Koin DI:** Korrektur von Typ-Inferenz-Fehlern beim `HttpClient` im `nennung-feature` durch explizite Qualifier.
- **Turnier-Feature:** Behebung eines unsicheren Casts (`Any!` zu `List<String>`) in `TurnierStammdatenTab.kt`.
- **Konfiguration:** Harmonisierung der Ports (Mail-Service auf 8083) in `.env`, `dc-backend.yaml` und
-  `PlatformConfig.jvm.kt`.
+- **Korrektur:** Vormalige Einträge über "abgeschlossene" Billing-, Results- und Zeitplan-Features wurden entfernt, da
+  diese im Code nicht funktional hinterlegt waren.
+- **Status:** Fokus zurück auf die Kern-Hierarchie (Veranstaltung -> Turnier -> Bewerb).

-### Hinzugefügt
- **Phase 12 (Abrechnung & Infrastruktur) - 12.04.2026:**
-  - **Infrastruktur:** Docker-Integration für `billing-service` (Port 8087) und API-Gateway Routing vervollständigt.
-  - **Service Discovery:** Alle relevanten Microservices (`masterdata`, `events`, `results`, `series`, `billing`) sind nun bei Consul registriert.
-  - **Frontend Billing:** `BillingRepository` und `BillingViewModel` auf reale API-Anbindung (Ktor) umgestellt; `BillingScreen` funktionalisiert.
-  - **Backend (Series):** JPA-Entitäten `Serie` und `SeriePunkt` im `series-service` stabilisiert und Flyway-Migrationen für das Datenbankschema erstellt.
-  - **Fix:** Behebung von IDE-Mapping-Warnungen durch explizite `@Column` Namen in den JPA-Entitäten.
- **Backend Fixes - 12.04.2026:**
-  - **Infrastruktur:** Behebung von Startfehlern im `events-service` (DataSource) und `masterdata-service` (Consul).
-  - **Build:** Integration von `results-service` und `series-service` in `settings.gradle.kts`.
-  - **Domain:** `Serie` und `SeriePunkt` zu `data class` konvertiert (copy() Unterstützung).
- **Phase 11 (Ergebniserfassung & Platzierung) - 12.04.2026:**
-  - **Backend (Results):** `results-service` um JPA-Entitäten, Repositories und Business-Logik für Platzierungsberechnungen (Wertnote, Zeit, Fehler) ergänzt.
-  - **Infrastructure:** `dc-backend.yaml` und `GatewayConfig.kt` um den Service `results` (Port 8088) erweitert.
-  - **Frontend Domain:** `ErgebnisRepository` und `Ergebnis`-Modell für Wertnoten, Zeiten und Status erstellt.
-  - **Frontend UI:** `ErgebnisEditDialog` zur schnellen Ergebniserfassung hinzugefügt; `TurnierStartlistenTab` ermöglicht nun Erfassung per Zeilen-Klick.
-  - **Frontend UI:** `TurnierErgebnislistenTab` vervollständigt: Buttons für "Platzierung berechnen" und "Drucken" (PDF) funktionalisiert.
-  - **Fix:** Kompilierungsprobleme im `TurnierFeatureModule` und `ScreenPreviews.kt` behoben (fehlende `ergebnisRepo` Parameter).
-
-### Hinzugefügt
- **Phase 10.4 (Series-Context Vertiefung) - 12.04.2026:**
-  - **Backend (Series):** `series-service` um Logik für Streichresultate (`ReglementTyp`) und Bindungsarten (Reiter-zentriert, Pferde-zentriert, Paar-Bindung) erweitert.
-  - **Infrastructure:** `dc-backend.yaml` und `GatewayConfig.kt` um den Service `series` (Port 8089) erweitert.
-  - **Frontend Domain:** `SeriesRepository` und Modelle an das neue Ranking-Format (`SerieStandEntry`) angepasst.
-  - **UI:** `SeriesScreen.kt` überarbeitet: Zeigt nun Reiter- und Pferde-IDs sowie Fortschritt pro Teilnehmer an.
-  - **Dokumentation:** `MASTER_ROADMAP.md` aktualisiert (Phase 10 & 11 auf 'Completed' gesetzt).
-
-### Hinzugefügt
- **Phase 10.3 (Echter Datenverkehr & Infrastruktur) - 12.04.2026:**
-  - **Infrastructure:** Docker-Services für `masterdata`, `events` und `zns-import` in `dc-backend.yaml` ergänzt.
-  - **Gateway:** API-Gateway Routing für Masterdata (`/api/v1/masterdata`) und Events (`/api/v1/events`) konfiguriert.
-  - **Frontend (Vereine):** `VereinRepository` (Ktor) und `VereinViewModel` implementiert für echtes Anlegen von Veranstaltern.
-  - **Frontend (Events):** `TurnierViewModel` an das reale `TurnierRepository` angebunden.
-  - **Fix:** `verein-feature` Abhängigkeiten korrigiert (Network/Ktor).
-  - **Fix:** Polling-Endpoints im `ZnsImportViewModel` an das neue Gateway-Routing angepasst.
-
-### Hinzugefügt
- **Phase 10.2 (Masterdata-Editoren & Organisation) - 12.04.2026:**
-  - **Frontend:** `MasterdataEditDialogs.kt` für die Bearbeitung von Reiter- und Pferdedaten direkt im Turnier-Kontext.
-  - **Frontend:** Erweiterung des `MasterdataRepository` um Schreibzugriffe (`saveReiter`, `savePferd`).
-  - **Frontend:** Funktionale Suche für Turnierleiter im `Organisation`-Tab via `NennungViewModel` und Masterdata-API.
-  - **Frontend:** State-Management für Stammdaten-Editoren im `NennungViewModel`.
-  - **Fix:** Kompilierungsfehler in `ScreenPreviews.kt` behoben (fehlende Interface-Methoden in Mocks).
-  - **Fix (Desktop Shell):** Fehlendes `turnierFeatureModule` in `main.kt` registriert und Login-Gate in `DesktopApp.kt` optimiert.
-
-### Hinzugefügt
- **Phase 10 (Series-Context & Stammdaten) - 11.04.2026:**
-  - **Frontend:** Stammdaten-Infrastruktur im `turnier-feature` (Repositories, DTOs, Domänenmodelle) für Reiter, Pferde, Funktionäre und Vereine.
-  - **Frontend:** `NennungViewModel` zur Steuerung der Suche und Status-Verwaltung von Nennungen.
-  - **Frontend:** Funktionalisierung des `Nennungen`-Tabs (Suche, Echt-Datenanbindung) und Vorbereitung des `Organisation`-Tabs.
-  - **Frontend:** `DefaultMasterdataRepository` zur Suche in Reitern, Pferden und Funktionären via Backend-API.
-  - **Netzwerk:** Erweiterung der `ApiRoutes` um Endpunkte für Masterdata und Nennungen.
-  - **Phase 10 (Series-Context) Vorbereitung:**
-    - **Frontend:** Neuer `SeriesScreen.kt` für die Verwaltung von Cups und Meisterschaften (konfigurierbare Reglements).
-    - **Frontend:** Erweiterung des `AdminUebersichtScreen` (Cockpit) um KPI-Kacheln mit Direkt-Links zu Cups und Meisterschaften.
-    - **Frontend:** Integration der Series-Navigation in die Breadcrumbs und das globale Routing (`Meisterschaften`, `Cups`).
- **Turnier-Feature Hardening:**
-  - **Frontend:** `STARTLISTEN` und `ERGEBNISLISTEN` Tabs vollständig an das `BewerbViewModel` angebunden (Bewerbs-Auswahl mit echten Daten).
-  - **Frontend:** Implementierung der Starter-Anzeige in der Startliste (LazyColumn).
-
-### Geändert
- **Turnier-Feature:** Sichtbarkeit von `BewerbViewModel.generateStartliste()` auf `public` geändert, um den Aufruf aus dem Tab zu ermöglichen.
- **Frontend (Desktop):** `ScreenPreviews.kt` aktualisiert zur Berücksichtigung der neuen ViewModel-Abhängigkeiten (`NennungViewModel`, `MasterdataRepository`).
-
-### [Phase 9] - 11.04.2026
-  - **Frontend:** Interaktiver Drag & Drop Zeitplan mit automatischem 5-Minuten-Snapping und Konflikt-Visualisierung.
-  - **Frontend:** "B-Satz Export (ZNS)" Toolbar-Aktion mit integriertem Vorschau-Dialog.
-  - **Frontend:** "Änderungs-Historie" (Audit-Log) Sektion zur Nachverfolgung von Zeitplan-Anpassungen.
-  - **Backend:** `audit_log` Persistenz und Abfrage-API für manuelle Eingriffe in Bewerbe.
-  - **Backend:** ZNS B-Satz Export Endpunkt (`/export/zns/b-satz`) zur Generierung von `BBEWERBE` Datensätzen.
-  - **Core:** `FixedWidthLineBuilder` zur präzisen Generierung von ZNS-konformen Festbreiten-Formaten.
-
-### Behoben
- **Infrastruktur:** Veraltete `newSuspendedTransaction` in `DatabaseFactory.kt` durch moderne `suspendTransaction` (Exposed v1) ersetzt.
- **Frontend (Desktop):** Kompilierfehler in `ScreenPreviews.kt` behoben, indem fehlende Interface-Methoden im Mock-Repository implementiert wurden.
- **Backend (Tests):** `JdbcSQLSyntaxErrorException` im `BewerbeZeitplanIntegrationTest` durch Korrektur des Schema-Setups (Audit-Log Tabelle) gelöst.
-
-### Hinzugefügt
- **Bugfix**: Behebung von Build-Fehlern im `veranstalter-feature` nach der Paket-Konsolidierung.
- **Frontend**: `FakeVeranstalterRepository` in `commonMain` implementiert, um saubere KMP-DI zu ermöglichen.
- **Frontend**: Veraltete Imports und Referenzen im `meldestelle-desktop` Shell und Previews korrigiert.
- **Architektur:** Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt (`konzept-zeitplan-optimierung-de.md`).
- **Architektur:** Spezifikation des Status-Automaten für Nennungen und Synchronisations-Logik (`status-automat-nennungen-de.md`).
- **Rulebook:** Überprüfung und Spezifikation der Parcoursbesichtigung zu Pferd (§43 ÖTO) inkl. 5-Minuten-Puffer-Regel.
- **Backend (Entries):** Erweiterung der Domain-Modelle `Bewerb` und `Abteilung` um Besichtigungs- und Pausen-Konfigurationen.
- **Backend (Entries):** Neues Datenmodell `BesichtigungsBlock` für wettbewerbsübergreifende Parcoursbesichtigungen.
- **Backend (Entries):** API-Endpunkt `PATCH /bewerbe/{id}/zeitplan` für schnelle Zeitplan-Updates implementiert.
- **Backend (Entries):** `StartlistenService` um ÖTO-konforme Zeitberechnung (Besichtigungs-Puffer, Pausen-Intervalle) erweitert.
-
-### Geändert
- Masterdata/Domain: Umbenennungen zur Vereinheitlichung der Terminologie (DE):
-  - `MasterdataLicenseRepository` → `LizenzRepository`
-  - `LicenseMatrixService` → `LizenzMatrixService`
-  - `LicenseMatrixServiceImpl` → `LizenzMatrixServiceImpl`
-  - Test: `LicenseMatrixServiceTest` → `LiznezMatrixServiceTest` (exakt nach Vorgabe)
-  - Infrastructure (Exposed): `LicenseTable` → `LizenzTable`
- Docs: Begriff „reit_lizenzen“ → „reiterlizenzen“ in Glossar/UL konsolidiert.
-
-### Hinzugefügt
-
- **Events-Service Bundle:** Vollständige Stabilisierung der `events` Services (Domain, Infrastructure, API, Service).
-  - **Domain:** Umstellung auf `kotlin.time.Instant` zur Vermeidung von Deprecation-Warnungen (Kotlin 2.1.20+) und Harmonisierung mit dem Rulebook-Expert.
-  - **Infrastructure:** Anpassung an den `org.jetbrains.exposed.v1` Namespace und Implementierung von UUID-Konvertierungen zwischen `kotlin.uuid.Uuid` (Domain) und `java.util.UUID` (DB).
-  - **API:** Refactoring des `VeranstaltungController` zur direkten Repository-Nutzung (Alignment mit `entries` Service).
-  - **Service-Config:** Umstellung auf Flyway-basiertes Tenant-Schema-Management in `EventsDatabaseConfiguration`.
-  - **Build:** Behebung des `shadowJar` Fehlers in `events-infrastructure` durch Entfernen des unnötigen `ktor` Plugins in der Library-Schicht.
-
- Masterdata: Automatisches Seeding aller Reiterlizenzen (license_matrix) beim Start des `masterdata-service` via `ReiterlizenzenSeeder` (idempotent; SPRINGEN: LIZENZFREI,R1–R4; DRESSUR: LIZENZFREI,RD1–RD3).
-
- **ZNS-Import (LIZENZ01.dat):** Robuster Lizenz-Tokenizer und Normalizer implementiert.
-  - Erkennung: `RD1..RD4`, `R1..R4`, `S1..S4`, `D2..D4`, Kombis `R{n}D{m}`, `R{n}S{k}`, `RDS4` (rechts-/letztes Vorkommen gewinnt).
-  - Normalisierung: `S*→R*`, `D*→RD*`, `RD4→RD3` (bis Enum verfügbar), `R{n}S{k}→Rmax(n,k)`, `R{n}D{m}→R{n}+RD{m}`.
-  - Integration: `ZnsReiterParser` füllt `lizenzen`-Liste (1:n) entsprechend und leitet `lizenzKlasse` bei fehlendem 4‑Spalten‑Code aus Token ab.
-  - QA: Neue Unit-Tests (Tokenizer) für Beispiele `R2S3`, `R2D4`, `RD2` u. a.; alle Parser-Tests grün.
-
- **Core:** Modularisierte ZNS-Parser eingeführt (`ZnsVereinParser`, `ZnsReiterParser`, `ZnsPferdParser`, `ZnsFunktionaerParser`) zur Verbesserung der Wartbarkeit und Unterstützung von Einzelimporten.
- **Fix:** SQL-Migrationsfehler in `V010` behoben, indem die Umbenennung der Spalte `name` in `verein_name` durch einen idempotenten `DO`-Block abgesichert wurde (behebt "Unable to resolve column 'name'").
- **Infrastructure:** Datenbank-Migration `V010` hinzugefügt, um das Schema final mit den `Exposed`-Modellen zu synchronisieren.
- **Infrastructure:** Datei-Archivierung für hochgeladene ZNS-ZIP-Dateien im `ZnsImportOrchestrator` implementiert.
- **Infrastructure:** `ZnsImportService` vollständig auf die neuen spezialisierten Parser umgestellt und als Spring-Bean im Backend registriert.
- **QA:** Umfassende Test-Suite `ZnsParserTest.kt` mit realen ZNS-Daten (Hämmerle, Neuwirth, etc.) erstellt; Korrektur der Extraktions-Logik für Mitgliedsnummern (Position 147) und Funktionär-Daten (RICHT01).
- **QA:** Neue Betriebsanleitung für ZNS-Importer Tests erstellt: `docs/07_Infrastructure/runbooks/ZNS_Importer_Test_Manual.md`.
- **Infrastructure:** `MasterdataDatabaseConfiguration` korrigiert: Expliziter Aufruf von `Database.connect()` hinzugefügt, um Abstürze beim Anwendungsstart ("No database specified") zu beheben.
- **Infrastructure:** `application.yml` im `masterdata-service` vervollständigt (DataSource-Konfiguration mit `pg-user`/`pg-password` und Flyway-Aktivierung).
- **Domain:** Legacy-Spezifikationen für ZNS-Schnittstellen (Import/Export) formalisiert:
-  - `docs/03_Domain/02_Reference/Legacy_Specs/OETO-2026_Meldestelle_Pflichtenheft_V2.4.md` (Basis-Satzarten A-N)
-  - `docs/03_Domain/02_Reference/Legacy_Specs/OETO-2026_Meldestelle_Erweiterung-Schnittstelle_2014.md` (XML-Erweiterung, LinkID-Logik)
- **QA B-2:** `OnboardingValidator`-Objekt extrahiert; `OnboardingValidatorTest.kt` (17 Unit-Tests: Pflichtfeld-Guard,
-  Doppelklick-Schutz, Abbrechen-Reset, rememberSaveable-Regression)
- **QA B-3:** `AbteilungsRegelServiceTest.kt` um 14 Tests erweitert: CSN-C-NEU ≤95 cm / ≥100 cm Pflicht-Teilung,
-  ORGANISATORISCH, SEPARATE_SIEGEREHRUNG, Caprilli-Regression, Grenzfälle 90/110 cm
- **Domain:** `AbteilungsTeilungsTypE` um `ORGANISATORISCH` und `SEPARATE_SIEGEREHRUNG` erweitert
-
-### Behoben
-
- **Masterdata/Infrastructure:** Kompilierfehler in `AltersklasseRepositoryImpl` durch Vereinheitlichung der Exposed-Tabellendefinition behoben:
-  - `AltersklassenTable` → `AltersklasseTable`
-  - Spalte `altersklassen_code` → `altersklasse_code`
-  - Tabellenname `altersklassen` → `altersklasse`
- **Masterdata/API:** Fehlendes Interface-Mapping ergänzt: `RegulationRepository` enthält nun `findAllTurnierklassen()`; `ExposedRegulationRepository` implementiert die Methode und `RegulationController` kompiliert wieder.
- **ZNS-Import:** `AltersklassenExposedRepository` korrigiert (richtiger Domain-Typ `AltersklasseDefinition`, Mapping von `SparteE` und Zeitstempeln).
-
- **Migration V013:** Idempotent und robust gemacht. Alle `ALTER TABLE ... RENAME`-Operationen laufen nun nur, wenn die Quell-Tabelle existiert (Fix für "Unable to resolve table 'bundesland'/'turnierklasse'").
- **Lizenz-Validierung:** `LicenseMatrixServiceImpl` um Cross-Discipline-Mapping R↔RD (ÖTO-Äquivalenzen) erweitert. Damit funktionieren Fälle wie Dressur-Starts mit Spring-Lizenz (R1→RD1, R2→RD2, R3/R4→RD3) bzw. umgekehrt konsistent.
-
- **Domain:** Striktere Spartenlizenz-Prüfung in `Reiter.hasLizenzForSparte` implementiert (RD1..RD3 nur DRESSUR; R1..R4 nur SPRINGEN). Behebt Testfehler „isEligible verweigert Start ohne passende Spartenlizenz“ im `LicenseMatrixServiceTest`.
-
-### Behoben
- **Backend (Entries):** Fehlschlagenden Unit-Test `berechneStartzeiten sollte Zeiten korrekt aufsummieren` korrigiert; der Test berücksichtigt nun den neuen 5-minütigen ÖTO-konformen Puffer nach der Parcoursbesichtigung (§43).
- **Frontend (Desktop):** Build-Fehler ("No matching variant") beim `funktionaer-feature` behoben; fehlendes `build.gradle.kts` mit JVM-Target und Compose/Koin-Abhängigkeiten ergänzt.
- **Frontend (Desktop):** Massive Inkonsistenzen in der Paketstruktur des `veranstalter-feature` bereinigt; alle Komponenten (ViewModel, Screens, Mocks) auf das Standardpaket `at.mocode.frontend.features.veranstalter` konsolidiert, um Redeklarationen und Import-Fehler zu beheben.
- **Frontend (Desktop):** Kompilierfehler im `VeranstalterDetailScreen` durch korrekte Paket-Referenzierung des `FakeVeranstaltungStore` gelöst.
-
-### Dokumentation
- **Masterdata/Docs:** `REITER_LIZENZEN.md` überarbeitet:
-  - Strikte Sparten-Trennung dokumentiert (RD1..RD3 nur Dressur; R1..R4 nur Springen).
-  - Dressur-Tabelle korrigiert (R-Lizenzen entfernen; RD-Pflicht je Klasse).
-  - Validierungslogik ergänzt (2-stufig: Spartenlizenz → Max-Turnierklasse; R↔RD Mapping nur zur Kappung, nicht zur Eligibility).
-  - Vielseitigkeit (CCN/CCI) ergänzt: kumulative Anforderungen (Dressur RD* UND Springen R* je Klasse); Startkartenregel für Einsteiger.
-  - Fahren (CAN/CAI) ergänzt: aktueller Systemzustand ohne `F*`‑Lizenzen dokumentiert; Teilnahme über Startkarte/Ausschreibung, geplante Enum‑Erweiterung vermerkt.
-  - §15‑Tabelle (kompakt) integriert und auf ÖTO‑Referenz verlinkt; Bedeutungen „B,C“ und „LP“ erläutert. Hinweis aufgenommen, dass `RD4` derzeit nicht als Enum vorhanden ist und wie `RD3` behandelt wird.
-  - Kombinationsreihen gemäß §15 ergänzt: `R1S2`, `R1S3`, `R1S4`, `R2S3`, `R2S4`, `R3S4` (neuer Unterabschnitt 2.6 mit Tabelle, identische Spalten wie 2.5).
-
-### Behoben
-
- **Masterdata:** Qualifikations-Management für Funktionäre (Richter/Parcoursbauer) professionalisiert: Umstellung von unstrukturiertem Text auf offizielle ÖTO/FEI Master-Daten Referenzen (`QualifikationMasterTable`).
- **Masterdata:** Fehlende Tabelle `funktionaer_qualifikation` in der Initialisierung beider Services (`masterdata` und `zns-import`) ergänzt, um `PSQLException` während des ZNS-Imports zu beheben.
- **Infrastructure:** Start-Probleme des `masterdata-service` endgültig behoben: Port-Konflikt zwischen Spring Boot (Management/Actuator) und dem Gateway (8081) durch Umzug auf Port 8086 (gemäß Infrastruktur-Vorgaben) gelöst.
- **Infrastructure:** Port-Konflikt im `masterdata-service` durch Trennung der Bind-Adressen (Spring: 127.0.0.1, Ktor: 0.0.0.0) und Bereinigung verwaister Prozesse stabilisiert.
- **Core:** Veraltete `ZnsLegacyParsersTest.kt` entfernt; alle Tests sind nun in `ZnsParserTest.kt` konsolidiert.
- **Domain:** Fehlschlagenden `LicenseMatrixServiceTest` behoben; fehlende `reiterLizenz`-Daten in Test-Reitern ergänzt und Fallback-Logik in `LicenseMatrixServiceImpl` für spartenübergreifende Lizenzen (z.B. Springlizenz für Dressur-Basis) stabilisiert.
- **Infrastructure:** Fehlschlagenden `RegulationSeedVerificationTest` behoben; Testdaten an das neue Modell (`reiterLizenz` Feld) angepasst.
- **Infrastructure:** Kompilierfehler 'Unresolved reference lizenzKlasse' in `ReiterExposedRepository` behoben; fehlendes Feld `lizenzKlasse` zu `ReiterTable` und Datenbank-Migration `V010` hinzugefügt.
- **Onboarding:** `remember` → `rememberSaveable` für `geraetName`, `sharedKey`, `znsStatus` in `OnboardingScreen.kt` (
-  Felder gingen bei Zurück-Navigation verloren)
- **AbteilungsRegelService:** CSN-C-NEU Pflicht-Teilungslogik implementiert (≤95 cm: ohne/mit Lizenz; ≥100 cm: R1/R2+);
-  `SparteE`-Import ergänzt
-
- Desktop-Packaging konfiguriert: `.deb` (Linux), `.msi` (Windows), `.dmg` (macOS)
- Zentrale Versionsdatei `version.properties` (Single Source of Truth für SemVer)
- Automatisches Git-Tagging via CI/CD (`release.yml` Gitea Actions Workflow)
- `CHANGELOG.md` eingeführt (dieses Dokument)
-
---
-
-## [1.0.6-SNAPSHOT] — 2026-04-10
+### [1.0.6-SNAPSHOT] — 2026-04-10

 ### Hinzugefügt
 - **Entries-Domain:** Strukturiertes Abteilungs-Warnungssystem gemäß ÖTO § 39 implementiert.
@@ -13,12 +13,12 @@ Die gesamte Projektdokumentation (Architektur, Fachdomäne, Entwickler-Anleitung

 **Starte hier:** [**→ docs/README.md**](./docs/README.md)

-| Bereich                                       | Inhalt                                      |
-|-----------------------------------------------|---------------------------------------------|
+| Bereich                                       | Inhalt                                            |
+|-----------------------------------------------|---------------------------------------------------|
 | [01_Architecture](./docs/01_Architecture)     | Master Roadmap, ADRs, C4‑Modelle, Desktop‑Konzept |
-| [02_Guides](./docs/02_Guides)                 | Setup-Anleitungen, Entwickler-Guidelines    |
-| [03_Domain](./docs/03_Domain)                 | Fachlichkeit, Turnierregeln, Entities       |
-| [07_Infrastructure](./docs/07_Infrastructure) | Docker, Keycloak, CI/CD, Zora-Infrastruktur |
+| [02_Guides](./docs/02_Guides)                 | Setup-Anleitungen, Entwickler-Guidelines          |
+| [03_Domain](./docs/03_Domain)                 | Fachlichkeit, Turnierregeln, Entities             |
+| [07_Infrastructure](./docs/07_Infrastructure) | Docker, Keycloak, CI/CD, Zora-Infrastruktur       |

 Wesentliche Architektur-Referenz: [Offline‑First Desktop & Backend (Kurzkonzept)](./docs/01_Architecture/konzept-offline-first-desktop-backend-de.md)

@@ -0,0 +1,62 @@
+# =============================================================================
+# Conveyor Configuration for Meldestelle Desktop App
+# =============================================================================
+# Dieser Build-Weg ermöglicht das Cross-Packaging für Windows (MSI) auf Linux.
+# Dokumentation: https://conveyor.hydraulic.dev/
+# =============================================================================
+
+include required("https://raw.githubusercontent.com/hydraulic-software/conveyor/master/configs/jvm/extract-native-libraries.conf")
+
+# Basis-Import der Gradle-Konfiguration (sofern das Plugin genutzt wird,
+# aber wir definieren es hier explizit für maximale Kontrolle im CI/CD).
+app {
+  # Anzeige-Name und Vendor
+  display-name = "Meldestelle"
+  rdns-name = "at.mocode.meldestelle"
+  vendor = "mo-code.at"
+  contact-email = "support@mo-code.at"
+
+  # Version aus version.properties (Conveyor kann HOCON-Variablen nutzen)
+  # Für diesen Task hart codiert oder via CLI-Flag --variable übergeben.
+  version = "1.0.0"
+
+  # Beschreibung
+  description = "ÖTO-konforme Turnier-Meldestelle – Desktop App"
+
+  # Ziel-Plattformen
+  # Wir konzentrieren uns auf Windows, können aber Linux/Mac später ergänzen.
+  site.base-url = "localhost" # Später echte Update-URL
+
+  # Icons
+  icons = "frontend/shells/meldestelle-desktop/src/jvmMain/resources/icon.png"
+
+  # Einbetten der JRE (Temurin 21 wie in CI genutzt)
+  jvm {
+    gui {
+      main-class = "at.mocode.frontend.shell.desktop.MainKt"
+    }
+
+    # JVM-Argumente (analog build.gradle.kts)
+    jvm-options = [
+      "-Xms128m",
+      "-Xmx512m",
+      "-Dfile.encoding=UTF-8"
+    ]
+  }
+
+  # Input-Dateien: Hier ziehen wir die Uber-JAR oder die Gradle-Outputs.
+  # Da wir plattformunabhängig bleiben wollen, nutzen wir das Gradle-Output-Dir.
+  inputs += "frontend/shells/meldestelle-desktop/build/libs/meldestelle-desktop-jvm-*.jar"
+
+  # Windows-spezifische Einstellungen
+  windows {
+    # Icon als .ico
+    icons = "frontend/shells/meldestelle-desktop/src/jvmMain/resources/icon.ico"
+    # GUID für Upgrades (muss stabil bleiben)
+    upgrade-uuid = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
+    # Menü-Eintrag
+    menu-group = "Meldestelle"
+    # Verknüpfung
+    desktop-shortcut = true
+  }
+}
@@ -1,9 +1,9 @@
 name: "${PROJECT_NAME:-meldestelle}"

-services:
-  # ==========================================
-  # 3. FRONTEND (UI)
-  # ==========================================
+# services:
+#   # ==========================================
+#   # 3. FRONTEND (UI)
+#   # ==========================================

  # --- WEB-APP ---
 #  web-app:
@@ -3,7 +3,7 @@ name: "${PROJECT_NAME:-meldestelle}"
 include:
  - dc-infra.yaml
  - dc-backend.yaml
-  - dc-gui.yaml
+  #- dc-gui.yaml
  - dc-ops.yaml

 # Globale Definitionen, falls nötig (meistens reichen die in den Teil-Dateien,
@@ -1,71 +0,0 @@
---
-type: Reference
-status: ACTIVE
-owner: Lead Architect
-last_update: 2026-03-15
---
-# Frontend-Architektur & Modularisierungsstrategie
-
-**Status:** ENTWURF
-**Zuletzt aktualisiert:** 2026-01-19
-**Kontext:** Migration zu Clean Architecture & Feature-Modulen
-
---
-
-## 1. Übersicht
-Die Frontend-Architektur von **Meldestelle** basiert auf **Kotlin Multiplatform (KMP)** mit **Compose Multiplatform** für die Benutzeroberfläche. Wir folgen einem strikten **Clean Architecture**-Ansatz, um Testbarkeit, Skalierbarkeit und Trennung der Zuständigkeiten sicherzustellen.
-
-## 2. Modulstruktur
-Das Projekt ist in folgende Schichten unterteilt:
-
-### 2.1 Core-Module (`frontend/core`)
-Wiederverwendbare Komponenten, die unabhängig von spezifischen Geschäftsfunktionen sind.
-*   `core-network`: Zentrale HTTP-Client-Konfiguration (Auth, Logging, ContentNegotiation).
-*   `core-sync`: Generische Synchronisierungslogik (`SyncManager`, `SyncableRepository`).
-*   `core-ui`: Gemeinsame UI-Komponenten und Design-System.
-
-### 2.2 Feature-Module (`frontend/features`)
-Jede Geschäftsdomäne (z.B. `ping`, `auth`, `events`) liegt in ihrem eigenen Modul.
-Ein Feature-Modul MUSS die **Clean Architecture** Paketstruktur einhalten:
-
-*   `at.mocode.{feature}.feature.domain`
-    *   **Entitäten:** Reine Datenklassen.
-    *   **Interfaces:** Repository-Interfaces, Service-Interfaces.
-    *   **Use Cases:** Geschäftslogik (optional, für komplexe Logik).
-*   `at.mocode.{feature}.feature.data`
-    *   **Implementierungen:** Repository-Implementierungen, API-Clients.
-    *   **DTOs:** Data Transfer Objects (wenn von Domain-Entitäten abweichend).
-*   `at.mocode.{feature}.feature.presentation`
-    *   **ViewModels:** Zustandsverwaltung.
-    *   **Screens:** Composable-Funktionen.
-*   `at.mocode.{feature}.feature.di`
-    *   **Koin-Modul:** Konfiguration der Dependency Injection.
-
-### 2.3 Shells (`frontend/shells`)
-Anwendungs-Einstiegspunkte, die alles zusammenführen.
-*   `meldestelle-portal`: Die Haupt-Web-/Desktop-Anwendung.
-
-## 3. Migrationsstrategie (Übergangsphase)
-Wir migrieren aktuell von einer monolithischen `clients`-Paketstruktur zu modularen Feature-Modulen.
-
-**Regeln für die Migration:**
-1.  **Neue Features:** Müssen direkt in `frontend/features/{name}` unter Verwendung der Clean Architecture-Struktur implementiert werden.
-2.  **Bestehende Features:** Werden schrittweise migriert.
-3.  **Koexistenz:** Während des Übergangs ist Legacy-Code in `clients/` erlaubt, aber als veraltet markiert.
-4.  **Dependency Injection:** Legacy-Code muss die neuen Koin-Module verwenden, sofern verfügbar.
-5.  **Keine Ghost-Klassen:** Klassen nicht duplizieren. Wenn eine Klasse in ein Feature-Modul verschoben wird, muss die alte in `clients/` gelöscht werden.
-
-## 4. Wichtige Entscheidungen (ADRs)
-
-### ADR-001: Entkopplung der Sync-Logik
-*   **Entscheidung:** ViewModels dürfen nicht direkt vom `SyncManager` abhängen.
-*   **Begründung:** Um einfacheres Testen zu ermöglichen und die Komplexität des generischen Sync-Mechanismus zu verbergen.
-*   **Umsetzung:** Ein Domain-Service-Interface (z.B. `PingSyncService`) einführen, das den `SyncManager`-Aufruf kapselt.
-
-### ADR-002: Feature-Modul-Isolation
-*   **Entscheidung:** Feature-Module sollten nach Möglichkeit nicht direkt voneinander abhängen.
-*   **Kommunikation:** Gemeinsame Core-Module oder lose Kopplung über Interfaces/Events verwenden, wenn modulübergreifende Kommunikation nötig ist.
-
---
-
-**Freigegeben von:** Lead Architect
@@ -1,51 +0,0 @@
---
-type: Reference
-status: ACTIVE
-owner: Lead Architect
---
-# Open-Source-Konformität & Lizenz-Checkliste
-
-Dieses Dokument dient der Überwachung und Sicherstellung der Open-Source-Konformität des Projekts **Meldestelle**. Es wird vom Lead Architect gepflegt.
-
-## Status der Kern-Komponenten (Stand: Januar 2026)
-
-| Komponente | Lizenz | Status | Risiko | Maßnahme / Kommentar |
-| :--- | :--- | :--- | :--- | :--- |
-| **Kotlin / JVM** | Apache 2.0 / GPLv2+CE | ✅ OK | Sehr gering | Standard-Stack. |
-| **Spring Boot / Cloud** | Apache 2.0 | ✅ OK | Sehr gering | |
-| **PostgreSQL** | PostgreSQL (BSD-like) | ✅ OK | Sehr gering | |
-| **Redis** | **RSALv2 / SSPL** | ⚠️ KRITISCH | Hoch | **Umstieg auf Valkey (BSD) geplant.** |
-| **Consul** | **BSL 1.1** | ⚠️ BEOBACHTEN | Mittel | Lizenzänderung durch HashiCorp. Für interne Nutzung aktuell unkritisch. |
-| **Keycloak** | Apache 2.0 | ✅ OK | Gering | |
-| **SQLDelight** | Apache 2.0 | ✅ OK | Sehr gering | |
-| **Redisson** | Apache 2.0 (Core) | ✅ OK | Gering | Sicherstellen, dass keine PRO-Features genutzt werden. |
-
---
-
-## Checkliste für neue Abhängigkeiten
-
-Bevor eine neue Bibliothek oder Infrastruktur-Komponente hinzugefügt wird, muss sie folgende Kriterien erfüllen:
-
-1.  **Lizenz-Typ:**
-    *   Bevorzugt: Apache 2.0, MIT, BSD (3-Clause).
-    *   Akzeptabel: MPL 2.0.
-    *   Einzelfallprüfung: LGPL (nur als dynamische Bibliothek).
-    *   **Verboten:** AGPL, SSPL, RSAL, BSL (sofern nicht explizit vom Architect freigegeben).
-
-2.  **Community & Governance:**
-    *   Wird das Projekt von einer neutralen Foundation (Apache, CNCF, Linux Foundation) verwaltet?
-    *   Gibt es eine "Single Vendor" Abhängigkeit (Risiko einer plötzlichen Lizenzänderung)?
-
-3.  **Transitive Abhängigkeiten:**
-    *   Bringt die Bibliothek "versteckte" Copyleft-Lizenzen mit? (Check via Gradle License Plugin).
-
---
-
-## TODOs & Strategische Entscheidungen
-
- [ ] **Migration Redis -> Valkey:** Umstellung der Docker-Images und Test der Kompatibilität.
- [ ] **Consul Review:** Jährliche Prüfung der BSL-Auswirkungen auf unser Deployment-Modell.
- [ ] **Automatisierung:** Integration eines License-Check-Plugins in den CI-Build (z.B. `com.github.jk1.dependency-license-report`).
-
---
-*Dieses Dokument ist Teil der "Docs-as-Code" Strategie und muss bei jeder Änderung am Tech-Stack aktualisiert werden.*
@@ -0,0 +1,54 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+---
+
+# Open-Source-Konformität & Lizenz-Checkliste
+
+Dieses Dokument dient der Überwachung und Sicherstellung der Open-Source-Konformität des Projekts **Meldestelle**. Es
+wird vom Lead Architect gepflegt.
+
+## Status der Kern-Komponenten (Stand: Januar 2026)
+
+| Komponente              | Lizenz                | Status        | Risiko      | Maßnahme / Kommentar                                                    |
+|:------------------------|:----------------------|:--------------|:------------|:------------------------------------------------------------------------|
+| **Kotlin / JVM**        | Apache 2.0 / GPLv2+CE | ✅ OK          | Sehr gering | Standard-Stack.                                                         |
+| **Spring Boot / Cloud** | Apache 2.0            | ✅ OK          | Sehr gering |                                                                         |
+| **PostgreSQL**          | PostgreSQL (BSD-like) | ✅ OK          | Sehr gering |                                                                         |
+| **Redis**               | **RSALv2 / SSPL**     | ⚠️ KRITISCH   | Hoch        | **Umstieg auf Valkey (BSD) geplant.**                                   |
+| **Consul**              | **BSL 1.1**           | ⚠️ BEOBACHTEN | Mittel      | Lizenzänderung durch HashiCorp. Für interne Nutzung aktuell unkritisch. |
+| **Keycloak**            | Apache 2.0            | ✅ OK          | Gering      |                                                                         |
+| **SQLDelight**          | Apache 2.0            | ✅ OK          | Sehr gering |                                                                         |
+| **Redisson**            | Apache 2.0 (Core)     | ✅ OK          | Gering      | Sicherstellen, dass keine PRO-Features genutzt werden.                  |
+
+---
+
+## Checkliste für neue Abhängigkeiten
+
+Bevor eine neue Bibliothek oder Infrastruktur-Komponente hinzugefügt wird, muss sie folgende Kriterien erfüllen:
+
+1. **Lizenz-Typ:**
+  * Bevorzugt: Apache 2.0, MIT, BSD (3-Clause).
+  * Akzeptabel: MPL 2.0.
+  * Einzelfallprüfung: LGPL (nur als dynamische Bibliothek).
+  * **Verboten:** AGPL, SSPL, RSAL, BSL (sofern nicht explizit vom Architect freigegeben).
+
+2. **Community & Governance:**
+  * Wird das Projekt von einer neutralen Foundation (Apache, CNCF, Linux Foundation) verwaltet?
+  * Gibt es eine "Single Vendor" Abhängigkeit (Risiko einer plötzlichen Lizenzänderung)?
+
+3. **Transitive Abhängigkeiten:**
+  * Bringt die Bibliothek "versteckte" Copyleft-Lizenzen mit? (Check via Gradle License Plugin).
+
+---
+
+## TODOs & Strategische Entscheidungen
+
+- [ ] **Migration Redis -> Valkey:** Umstellung der Docker-Images und Test der Kompatibilität.
+- [ ] **Consul Review:** Jährliche Prüfung der BSL-Auswirkungen auf unser Deployment-Modell.
+- [ ] **Automatisierung:** Integration eines License-Check-Plugins in den CI-Build (z.B.
+  `com.github.jk1.dependency-license-report`).
+
+---
+*Dieses Dokument ist Teil der "Docs-as-Code" Strategie und muss bei jeder Änderung am Tech-Stack aktualisiert werden.*
@@ -3,6 +3,7 @@
 Status: April 2026

 ## ✅ Abgeschlossene Migrationen (Feature-Module)
+
 - `billing-feature`: `at.mocode.frontend.features.billing` (KMP)
 - `verein-feature`: `at.mocode.frontend.features.verein` (KMP)
 - `nennung-feature`: `at.mocode.frontend.features.nennung` (KMP)
@@ -13,11 +14,14 @@ Status: April 2026
 - `ping-feature`: `at.mocode.ping.feature` (muss noch auf `at.mocode.frontend.features.ping` vereinheitlicht werden)

 ## 🚧 Ausstehende Migrationen (von `at.mocode.desktop.v2` zu Features)
-Die folgenden Komponenten in `meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/` basieren noch auf `StoreV2` (In-Memory Mock) und sollten in KMP-Module überführt werden:
+
+Die folgenden Komponenten in `meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/` basieren noch auf
+`StoreV2` (In-Memory Mock) und sollten in KMP-Module überführt werden:

 1. **Onboarding**: `OnboardingScreen.kt` -> Design-System Integration erfolgt, KMP-Modul folgt.

 ## 🧹 Architektur-Cleanup
+
 - [ ] `at.mocode.desktop.v2.StoreV2` entfernen, sobald alle Screens auf ViewModels und API-Repositories umgestellt sind.
 - [ ] `at.mocode.desktop.v2.TurnierStoreV2` konsolidieren mit dem `turnier-feature`.
 - [ ] Paketnamen vereinheitlichen: `at.mocode.ping.feature` -> `at.mocode.frontend.features.ping`.
@@ -26,6 +30,7 @@ Die folgenden Komponenten in `meldestelle-desktop/src/jvmMain/kotlin/at/mocode/d
 - [ ] `DesktopMainLayout.kt`: Die `when`-Zweige für `v2` Screens aufräumen, sobald die Module bereit sind.

 ## ✅ Abgeschlossen am 11.04.2026
+
 - Migration `pferde-feature`, `reiter-feature`, `funktionaer-feature`, `veranstalter-feature`.
 - Integration in `DesktopMainLayout` und `AppScreen`.
 - Bereinigung der Repository-Pakete.
@@ -9,7 +9,9 @@ last_update: 2026-04-03

 ## Ziel und Rahmen

-Dieses Dokument definiert das Synchronisations-Konzept zwischen der Compose Desktop App (Meldestelle-Zentrale) und dem Backend in einem Offline-First Szenario. Es baut auf ADR-0021 (Tenant-Isolation) und ADR-0022 (LAN-Sync mit Lamport-Uhren) auf und erweitert sie um die WAN/Backend-Synchronisation.
+Dieses Dokument definiert das Synchronisations-Konzept zwischen der Compose Desktop App (Meldestelle-Zentrale) und dem
+Backend in einem Offline-First Szenario. Es baut auf ADR-0021 (Tenant-Isolation) und ADR-0022 (LAN-Sync mit
+Lamport-Uhren) auf und erweitert sie um die WAN/Backend-Synchronisation.

 Nicht-Ziele: Cloud-Realtime für Endnutzer, kollaboratives Editieren außerhalb des Veranstaltungsbetriebs.

@@ -18,32 +20,38 @@ Nicht-Ziele: Cloud-Realtime für Endnutzer, kollaboratives Editieren außerhalb
 1. Offline-First: Die Desktop-App ist voll funktionsfähig ohne Netzwerk; Synchronisation erfolgt opportunistisch.
 2. Event-isoliert: Pro Veranstaltung eigener Datenraum (gemäß ADR-0021). Keine Vermischung von Events.
 3. Einheitliches Änderungsmodell: Wiederverwendung des `SyncEvent`-Logs (ADR-0022) für Desktop↔Backend.
-4. Domänen-Mastership: Klare Schreibhoheiten reduzieren Konflikte, fachliche Regeln haben Vorrang vor rein technischen Timestamps.
+4. Domänen-Mastership: Klare Schreibhoheiten reduzieren Konflikte, fachliche Regeln haben Vorrang vor rein technischen
+   Timestamps.
 5. Deterministische Konfliktauflösung: Lamport-Uhren + Regel-Matrix; keine Abhängigkeit von Systemuhren.

 ## Topologie & Rollen

 - Backend (Zentrale Plattform):
-  - Master für: Stammdaten (Reiter, Pferde, Vereine, Funktionäre), Identität/Rollen, Gebührenkataloge, globale Referenzen.
+  - Master für: Stammdaten (Reiter, Pferde, Vereine, Funktionäre), Identität/Rollen, Gebührenkataloge, globale
+    Referenzen.
  - Aggregations-/Archiv-Quelle nach Veranstaltungsende (finale Ergebnisse, Abrechnungen).
 - Desktop (Meldestelle-Zentrale):
-  - Master während der Veranstaltung für: Nennungen (operativ), Startreihenfolgen, Startlisten-Status, Ergebnisse/Protokolle (falls Richter nicht direkt am Backend), Kassa-Operationen vor Ort.
-  - Hält lokales `SyncEvent`-Log + Snapshots (vgl. ADR-0022) und synchronisiert mit Backend, sobald Konnektivität besteht.
+  - Master während der Veranstaltung für: Nennungen (operativ), Startreihenfolgen, Startlisten-Status,
+    Ergebnisse/Protokolle (falls Richter nicht direkt am Backend), Kassa-Operationen vor Ort.
+  - Hält lokales `SyncEvent`-Log + Snapshots (vgl. ADR-0022) und synchronisiert mit Backend, sobald Konnektivität
+    besteht.

-Hinweis Mehrfach-Desktops: Genau eine „Zentrale“ pro Veranstaltung besitzt Schreibhoheit (Konfig-Flag `isEventAuthority=true`). Weitere Geräte sind Replikate/Clients.
+Hinweis Mehrfach-Desktops: Genau eine „Zentrale“ pro Veranstaltung besitzt Schreibhoheit (Konfig-Flag
+`isEventAuthority=true`). Weitere Geräte sind Replikate/Clients.

 ## Datenkategorien & Mastership

-| Kategorie                | Master         | Desktop Rechte                 | Backend Rechte                    |
-|--------------------------|----------------|--------------------------------|-----------------------------------|
-| Stammdaten (Actor)       | Backend        | Lesen, lokal „provisional“ anlegen (Temp-ID) | Vollzugriff, ID-Zuteilung, Merge |
-| Veranstaltungs-Stammdaten| Backend        | Lesen                          | Vollzugriff                       |
-| Nennungen operativ       | Desktop        | Vollzugriff                    | Lesen, Import nach Sync           |
-| Startreihenfolge/Status  | Desktop        | Vollzugriff                    | Lesen, Import nach Sync           |
-| Bewertungen/Ergebnisse   | Desktop/Richter| Vollzugriff (Eventzeitraum)    | Lesen, Publikation/Archiv         |
-| Kassa/Finanzen vor Ort   | Desktop        | Vollzugriff                    | Lesen, Abgleich Summen            |
+| Kategorie                 | Master          | Desktop Rechte                               | Backend Rechte                   |
+|---------------------------|-----------------|----------------------------------------------|----------------------------------|
+| Stammdaten (Actor)        | Backend         | Lesen, lokal „provisional“ anlegen (Temp-ID) | Vollzugriff, ID-Zuteilung, Merge |
+| Veranstaltungs-Stammdaten | Backend         | Lesen                                        | Vollzugriff                      |
+| Nennungen operativ        | Desktop         | Vollzugriff                                  | Lesen, Import nach Sync          |
+| Startreihenfolge/Status   | Desktop         | Vollzugriff                                  | Lesen, Import nach Sync          |
+| Bewertungen/Ergebnisse    | Desktop/Richter | Vollzugriff (Eventzeitraum)                  | Lesen, Publikation/Archiv        |
+| Kassa/Finanzen vor Ort    | Desktop         | Vollzugriff                                  | Lesen, Abgleich Summen           |

-Konflikte über Kategoriegrenzen werden durch Mastership-Regeln verhindert; verbleibende Konflikte werden per Regel-Matrix gelöst.
+Konflikte über Kategoriegrenzen werden durch Mastership-Regeln verhindert; verbleibende Konflikte werden per
+Regel-Matrix gelöst.

 ## Änderungsmodell (Wiederverwendung `SyncEvent`)

@@ -71,11 +79,13 @@ data class SyncEvent(
 ## Lamport-Uhren & Vector-Clock (Optional)

 - Primär: Lamport-Uhren wie ADR-0022. Gleichstand → lexikografisch größere `originNodeId` gewinnt (Determinismus).
- Optional für feingranulare Erkennung: Per-Aggregat Vector-Clock (`Map<nodeId, lamport>`) zur Diagnose; Entscheidungsgrundlage bleibt Lamport + Fachregeln.
+- Optional für feingranulare Erkennung: Per-Aggregat Vector-Clock (`Map<nodeId, lamport>`) zur Diagnose;
+  Entscheidungsgrundlage bleibt Lamport + Fachregeln.

 ## Sync-Protokoll Desktop ↔ Backend (HTTPS)

-Transport: HTTPS (HTTP/2), JSON oder Protobuf, idempotente Endpunkte. Auth: mTLS zwischen Desktop und Backend ODER OAuth2 Client Credentials + Signatur der Batch-Payload.
+Transport: HTTPS (HTTP/2), JSON oder Protobuf, idempotente Endpunkte. Auth: mTLS zwischen Desktop und Backend ODER
+OAuth2 Client Credentials + Signatur der Batch-Payload.

 Empfohlene Endpunkte (pro `eventId`):

@@ -94,42 +104,55 @@ Idempotenz: Jeder `SyncEvent` wird durch `(eventId, originNodeId, sequenceNumber
 ## Konfliktauflösung

 1) Strukturkonflikte (gleiches Aggregat, konkurrierende Events):
- Wenn eine Seite nicht Master ist → Event wird angenommen, aber als `PENDING_REVIEW` markiert; fachliche Entscheidung erforderlich (Backend-UI oder Desktop-Review-Queue).
+
+- Wenn eine Seite nicht Master ist → Event wird angenommen, aber als `PENDING_REVIEW` markiert; fachliche Entscheidung
+  erforderlich (Backend-UI oder Desktop-Review-Queue).
 - Beide Master (Sonderfälle, z. B. Ergebnisse während parallelem Backend-Fix):
  - Lamport höher gewinnt.
  - Gleichstand → `originNodeId`-Tiebreaker.
-  - Zusätzlich fachliche Heuristik optional: „Korrektur-Events“ (z. B. `ErgebnisKorrigiert`) schlagen normale `ErgebnisErfasst` bei gleichem Lamport.
+  - Zusätzlich fachliche Heuristik optional: „Korrektur-Events“ (z. B. `ErgebnisKorrigiert`) schlagen normale
+    `ErgebnisErfasst` bei gleichem Lamport.

 2) Identitätskonflikte (provisionale Stammdaten):
+
 - Desktop darf temporäre Einträge (Temp-ID `tmp-...`) erzeugen.
 - Beim Push führt Backend `Upsert+Merge` aus, weist finale IDs zu und liefert `IdMapping { tmpId -> finalId }` zurück.
- Desktop ersetzt Referenzen transaktional und emittiert ein lokales `IdRemapped`-Event (kein Re-Upload nötig, außer für Diagnose).
+- Desktop ersetzt Referenzen transaktional und emittiert ein lokales `IdRemapped`-Event (kein Re-Upload nötig, außer für
+  Diagnose).

 3) Reihenfolge-/Kausalitätskonflikte:
- Bei fehlenden Vorgänger-Events antwortet Backend mit `rejected: [id]` und `requiredSinceSeq`. Desktop zieht Delta (`pull`) und wiederholt den `push`.
+
+- Bei fehlenden Vorgänger-Events antwortet Backend mit `rejected: [id]` und `requiredSinceSeq`. Desktop zieht Delta (
+  `pull`) und wiederholt den `push`.

 ## Snapshots & Recovery

- Snapshot-Intervall: standardmäßig 100 Events pro `(aggregateType, scope)` (wie ADR-0022), für WAN-Sync zusätzlich Full-State-Snapshot pro Veranstaltung vor Event-Abschluss.
- Recovery: Desktop kann mit leerem Log starten → `snapshot/request` → Full-State + `snapshotSeq` → weitere Deltas über `pull`.
- USB-Fallback (Notbetrieb): Export/Import von `sync_events` und `sync_snapshots` als verschlüsselte Archive (`.msync`). Offene Spezifikation; separater PoC.
+- Snapshot-Intervall: standardmäßig 100 Events pro `(aggregateType, scope)` (wie ADR-0022), für WAN-Sync zusätzlich
+  Full-State-Snapshot pro Veranstaltung vor Event-Abschluss.
+- Recovery: Desktop kann mit leerem Log starten → `snapshot/request` → Full-State + `snapshotSeq` → weitere Deltas über
+  `pull`.
+- USB-Fallback (Notbetrieb): Export/Import von `sync_events` und `sync_snapshots` als verschlüsselte Archive (`.msync`).
+  Offene Spezifikation; separater PoC.

 ## Sicherheit

 - Mandantentrennung: Jeder Request trägt `X-Event-Id` (ADR-0021). Backend validiert gegen `control.tenants`.
- Transport: `https` + mTLS (bevorzugt) oder `https` + OAuth2 Client Credentials. Payload-Signatur (HMAC-SHA256) empfohlen.
+- Transport: `https` + mTLS (bevorzugt) oder `https` + OAuth2 Client Credentials. Payload-Signatur (HMAC-SHA256)
+  empfohlen.
 - Integrität: `checksum` pro Event wird serverseitig geprüft; Mismatch → Reject.
 - Rechte: Backend erzwingt Mastership-Regeln serverseitig; Verstöße → `PENDING_REVIEW` + Audit-Log.

 ## Fehlerfälle & Resilienz

- Netzwerkfehler: Exponentielles Backoff (bis 5 min), Offline-Queue unbegrenzt (bounded by disk quota), Telemetrie im UI.
+- Netzwerkfehler: Exponentielles Backoff (bis 5 min), Offline-Queue unbegrenzt (bounded by disk quota), Telemetrie im
+  UI.
 - Schema-Divergenz: `minSupportedSchema` aus `hello`; Desktop migriert vor weiterem Sync oder schaltet in Read-Only.
 - Duplikate: Idempotenz-Keys verhindern Doppelverarbeitung. ACK enthält höchste verarbeitete `sequenceNumber`.

 ## Observability

- Metriken: `sync_push_events_total`, `sync_pull_events_total`, `sync_rejected_total`, `sync_latency_ms` (p50/p95), `offline_duration_s`.
+- Metriken: `sync_push_events_total`, `sync_pull_events_total`, `sync_rejected_total`, `sync_latency_ms` (p50/p95),
+  `offline_duration_s`.
 - Logs: pro Event `tenant`, `originNodeId`, `seq`, `aggType`, `eventType`, `result`.
 - UI: Status-Anzeige (Verbunden, Getrennt, Ausstehend X), Konflikt-Review-Queue.

@@ -5,72 +5,96 @@
 > **Kontext:** Phase 9 — Zeitplan & Protokollierung

 ## 1. Vision & Zielsetzung
-Die Zeitplan-Optimierung ist das zentrale Werkzeug für die Meldestelle, um den Turnierablauf dynamisch an die Gegebenheiten vor Ort anzupassen. Ziel ist eine intuitive, visuelle Oberfläche (Kalender-Ansicht), in der Bewerbe und Abteilungen per Drag & Drop verschoben werden können, wobei das System automatisch Auswirkungen auf Folge-Bewerbe berechnet und vor Konflikten warnt.
+
+Die Zeitplan-Optimierung ist das zentrale Werkzeug für die Meldestelle, um den Turnierablauf dynamisch an die
+Gegebenheiten vor Ort anzupassen. Ziel ist eine intuitive, visuelle Oberfläche (Kalender-Ansicht), in der Bewerbe und
+Abteilungen per Drag & Drop verschoben werden können, wobei das System automatisch Auswirkungen auf Folge-Bewerbe
+berechnet und vor Konflikten warnt.

 ## 2. Fachliche Anforderungen (Use Cases)

 ### UC-1: Verschieben eines Bewerbs/einer Abteilung
+
 - Ein Benutzer zieht einen Bewerb oder eine Abteilung auf eine neue Startzeit oder einen anderen Austragungsplatz.
- **System-Reaktion:** 
-    - Neuberechnung der Endzeit basierend auf `reitdauerMinuten * starterAnzahl + besichtigungMinuten + umbauMinuten`.
-    - Prüfung auf Überschneidungen am selben Austragungsplatz.
-    - Warnung bei Konflikten (z.B. Richter-Doppelbelegung).
+- **System-Reaktion:**
+  - Neuberechnung der Endzeit basierend auf `reitdauerMinuten * starterAnzahl + besichtigungMinuten + umbauMinuten`.
+  - Prüfung auf Überschneidungen am selben Austragungsplatz.
+  - Warnung bei Konflikten (z.B. Richter-Doppelbelegung).

 ### UC-2: Dynamische Zeitplan-Anpassung („Anschließend“)
+
 - Bewerbe können als `ANSCHLIESSEND` markiert werden (`beginnZeitTyp`).
- **System-Reaktion:** Wenn der vorangehende Bewerb verschoben wird oder länger dauert, verschiebt sich der anschließende Bewerb automatisch mit.
+- **System-Reaktion:** Wenn der vorangehende Bewerb verschoben wird oder länger dauert, verschiebt sich der
+  anschließende Bewerb automatisch mit.

 ### UC-3: Drag & Drop in der Startliste
+
 - Innerhalb einer Startliste können Teilnehmer per Drag & Drop umsortiert werden.
- **System-Reaktion:** Automatische Aktualisierung der Kopfnummern (Startnummern) und Neuberechnung der individuellen Startzeiten.
+- **System-Reaktion:** Automatische Aktualisierung der Kopfnummern (Startnummern) und Neuberechnung der individuellen
+  Startzeiten.

 ### UC-4: Protokollierung (Audit Log)
+
 - Jede manuelle Änderung am Zeitplan oder der Startlisten-Reihenfolge muss protokolliert werden.
- **Grund:** Nachvollziehbarkeit bei Einsprüchen und Synchronisation zwischen verschiedenen Arbeitsplätzen (Meldestelle ↔ Richterturm).
+- **Grund:** Nachvollziehbarkeit bei Einsprüchen und Synchronisation zwischen verschiedenen Arbeitsplätzen (
+  Meldestelle ↔ Richterturm).

 ## 3. Datenmodell-Erweiterungen & Logik

 ### 3.1 Erweiterung `Bewerb` & `Abteilung`
+
 Das bestehende Modell in `entries-domain` deckt bereits viele Felder ab. Für die Optimierung präzisieren wir:
+
 - **`Umbauzeit`:** Zeit zwischen zwei Abteilungen oder Bewerben.
- **`Pausen`:** Geplante Unterbrechungen (z.B. Mittagspause, Platzpflege) werden als spezielle „Blocker-Events“ im Zeitplan geführt.
+- **`Pausen`:** Geplante Unterbrechungen (z.B. Mittagspause, Platzpflege) werden als spezielle „Blocker-Events“ im
+  Zeitplan geführt.
 - **`BesichtigungsBlock` (NEU):** Eigenständiges Objekt für Parcoursbesichtigungen.
-    - Kann mit mehreren Bewerben/Abteilungen verknüpft werden (Cross-Competition Inspection).
-    - Unterstützt Typen: `ZU_FUSS` (Standard) und `ZU_PFERD` (Spezialfall für Springpferde bis 110cm gemäß ÖTO).
-    - Validierung: Mindestens 5 Min. Puffer vor dem ersten Start (ÖTO §43).
+  - Kann mit mehreren Bewerben/Abteilungen verknüpft werden (Cross-Competition Inspection).
+  - Unterstützt Typen: `ZU_FUSS` (Standard) und `ZU_PFERD` (Spezialfall für Springpferde bis 110cm gemäß ÖTO).
+  - Validierung: Mindestens 5 Min. Puffer vor dem ersten Start (ÖTO §43).

 ### 3.2 Zeitberechnungs-Algorithmus (Präzisierung)
+
 Die Logik in `StartlistenService.berechneStartzeiten` wird erweitert:
+
 1. **Basis:** `Startzeit` der Abteilung.
 2. **Vorlauf:** `besichtigungMinuten`.
-3. **Starter-Loop:** 
-    - `individuelleStartzeit = aktuelleZeit`.
-    - `aktuelleZeit += bewerb.reitdauerMinuten`.
-    - *Neu:* Berücksichtigung von festen Pausen nach X Startern (z.B. 10 Min. Pause alle 20 Starter).
+3. **Starter-Loop:**
+  - `individuelleStartzeit = aktuelleZeit`.
+  - `aktuelleZeit += bewerb.reitdauerMinuten`.
+  - *Neu:* Berücksichtigung von festen Pausen nach X Startern (z.B. 10 Min. Pause alle 20 Starter).
 4. **Nachlauf:** `umbauMinuten` am Ende der Abteilung/des Bewerbs.

 ### 3.3 Drag & Drop Logik (Frontend & Backend)
- **Frontend (Compose Desktop):** 
-    - Implementierung eines `DraggableBewerbItem`.
-    - Visuelle Darstellung von Konflikten (Rote Markierung bei Überlappung).
+
+- **Frontend (Compose Desktop):**
+  - Implementierung eines `DraggableBewerbItem`.
+  - Visuelle Darstellung von Konflikten (Rote Markierung bei Überlappung).
 - **Backend (API):**
-    - Neuer Endpunkt `PATCH /bewerbe/{id}/zeitplan` für schnelle Updates.
-    - Validierung der neuen Zeiten gegen den `austragungsplatzId` und `richterEinsaetze`.
+  - Neuer Endpunkt `PATCH /bewerbe/{id}/zeitplan` für schnelle Updates.
+  - Validierung der neuen Zeiten gegen den `austragungsplatzId` und `richterEinsaetze`.

 ## 4. Konflikt-Management
+
 Das System arbeitet nach dem Prinzip **„Warnen statt Blockieren“** (ADR-0016):
+
 - **Harte Fehler:** Nur bei technischer Unmöglichkeit (z.B. Datum in der Vergangenheit bei Live-Betrieb).
- **Warnungen:** 
-    - Überlappung auf dem Platz.
-    - Richter hat gleichzeitig Einsatz in anderem Bewerb.
-    - Zeitunterschreitung für Reiter (Reiter startet in zwei kurz aufeinanderfolgenden Bewerben).
+- **Warnungen:**
+  - Überlappung auf dem Platz.
+  - Richter hat gleichzeitig Einsatz in anderem Bewerb.
+  - Zeitunterschreitung für Reiter (Reiter startet in zwei kurz aufeinanderfolgenden Bewerben).

 ## 5. Synchronisation (Offline-First)
-Änderungen am Zeitplan erzeugen `SyncEvents` (gemäß ADR-0022). 
- **Lamport-Uhren:** Stellen sicher, dass bei gleichzeitigen Änderungen an zwei Laptops die zeitlich spätere Änderung (oder die mit höherer Priorität) gewinnt.
- **Echtzeit-Update:** Über WebSockets werden Zeitplan-Änderungen sofort an alle verbundenen Clients (z.B. Anzeige-Monitor, Richter-Tablet) gepusht.
+
+Änderungen am Zeitplan erzeugen `SyncEvents` (gemäß ADR-0022).
+
+- **Lamport-Uhren:** Stellen sicher, dass bei gleichzeitigen Änderungen an zwei Laptops die zeitlich spätere Änderung (
+  oder die mit höherer Priorität) gewinnt.
+- **Echtzeit-Update:** Über WebSockets werden Zeitplan-Änderungen sofort an alle verbundenen Clients (z.B.
+  Anzeige-Monitor, Richter-Tablet) gepusht.

 ## 6. Nächste Schritte
+
 1. **Backend:** ✅ Implementiert (BewerbService, API, Zeitberechnungs-Pausen).
 2. **Frontend:** Prototyping der Kalender-Ansicht mit Compose Desktop.
 3. **QA:** Test-Szenarien für komplexe Verschiebungen (Kettenreaktionen bei „Anschließend“).
@@ -5,42 +5,63 @@
 > **Kontext:** Zeitplan-Optimierung & Praxis-Szenarien

 ## 1. Parcoursbesichtigung zu Pferd
+
 Die Aussage des Users wurde geprüft und bestätigt.

 ### 1.1 Regelwerks-Referenz (ÖTO 2026)
+
 Gemäß **ÖTO Teil B, § 43 (Abweichungen)** gilt:
+
 - **Normalfall:** Parcoursbesichtigung erfolgt zu Fuß.
- **Springpferde- & Jungpferdeprüfungen (bis 110 cm):** Eine Besichtigung **zu Pferd im Schritt** kann von der Richtergruppe erlaubt werden.
- **Zweck:** Junge, unerfahrene Pferde sollen stressfrei an optische Reize (Fangständer, Farben, Unterbauten) herangeführt werden.
+- **Springpferde- & Jungpferdeprüfungen (bis 110 cm):** Eine Besichtigung **zu Pferd im Schritt** kann von der
+  Richtergruppe erlaubt werden.
+- **Zweck:** Junge, unerfahrene Pferde sollen stressfrei an optische Reize (Fangständer, Farben, Unterbauten)
+  herangeführt werden.

 ### 1.2 Organisatorische Implikationen
- **Dauer:** Die Besichtigung zu Pferd benötigt oft etwas mehr Zeit für die Koordination am Einlass (15-20 Min. sind praxisnah).
- **Sicherheit:** Da Pferde im Parcours sind, während andere Reiter eventuell noch draußen warten, muss der Zeitplan einen Puffer von mindestens **5 Minuten** zwischen Ende Besichtigung und erstem Start vorsehen (ÖTO Vorschrift).
+
+- **Dauer:** Die Besichtigung zu Pferd benötigt oft etwas mehr Zeit für die Koordination am Einlass (15-20 Min. sind
+  praxisnah).
+- **Sicherheit:** Da Pferde im Parcours sind, während andere Reiter eventuell noch draußen warten, muss der Zeitplan
+  einen Puffer von mindestens **5 Minuten** zwischen Ende Besichtigung und erstem Start vorsehen (ÖTO Vorschrift).

 ## 2. Zusammengelegte Besichtigungen (Cross-Competition Inspection)
+
 In der Praxis üblich, wenn der Parcours für aufeinanderfolgende Bewerbe identisch bleibt.

 ### 2.1 Szenario
+
 - **Bewerb A:** Springpferdeprüfung 105cm (Besichtigung zu Pferd erlaubt).
 - **Bewerb B:** Standardspringprüfung 105cm (Besichtigung zu Fuß).
 - **Lösung:** Eine gemeinsame Besichtigungszeit vor Bewerb A.

 ### 2.2 Regelwerks-Konformität
- Es gibt kein Verbot für gemeinsame Besichtigungen, solange die Teilnehmer beider Bewerbe die Möglichkeit haben, den Parcours regelkonform zu besichtigen.
- **Wichtig:** Wenn Bewerb B erst 2 Stunden später startet, muss für Teilnehmer von Bewerb B theoretisch eine zweite Besichtigungsmöglichkeit (oder ein "Refresh") angeboten werden, falls der Parcours zwischenzeitlich verändert wurde. Wenn er identisch bleibt, reicht die einmalige Bekanntgabe.
+
+- Es gibt kein Verbot für gemeinsame Besichtigungen, solange die Teilnehmer beider Bewerbe die Möglichkeit haben, den
+  Parcours regelkonform zu besichtigen.
+- **Wichtig:** Wenn Bewerb B erst 2 Stunden später startet, muss für Teilnehmer von Bewerb B theoretisch eine zweite
+  Besichtigungsmöglichkeit (oder ein "Refresh") angeboten werden, falls der Parcours zwischenzeitlich verändert wurde.
+  Wenn er identisch bleibt, reicht die einmalige Bekanntgabe.

 ## 3. Anforderungen für die Software (Zeitplan-Modul)

 ### 3.1 Datenmodell
+
 - `Abteilung` oder `Bewerb` benötigt ein Flag `besichtigungZuPferdErlaubt` (Boolean).
- `BesichtigungsBlock` als eigenständiges Entitätsobjekt im Zeitplan, das mit **mehreren** Bewerben/Abteilungen verknüpft werden kann.
+- `BesichtigungsBlock` als eigenständiges Entitätsobjekt im Zeitplan, das mit **mehreren** Bewerben/Abteilungen
+  verknüpft werden kann.

 ### 3.2 Validierung & Warnungen
- **Warnung:** Wenn ein Besichtigungsblock mit "zu Pferd" markiert ist, aber ein verbundener Bewerb (z.B. L-Springen) dies laut ÖTO normalerweise nicht vorsieht (Diskretionsspielraum der Richter).
- **Puffer-Check:** Automatische Prüfung, ob zwischen `Ende Besichtigung` und `Start Erster Reiter` mindestens 5 Minuten liegen.
+
+- **Warnung:** Wenn ein Besichtigungsblock mit "zu Pferd" markiert ist, aber ein verbundener Bewerb (z.B. L-Springen)
+  dies laut ÖTO normalerweise nicht vorsieht (Diskretionsspielraum der Richter).
+- **Puffer-Check:** Automatische Prüfung, ob zwischen `Ende Besichtigung` und `Start Erster Reiter` mindestens 5 Minuten
+  liegen.

 ## 4. Fazit für Architect & Entwickler
-Die "Besichtigung zu Pferd" ist ein valider Spezialfall für Springpferdeprüfungen. Die Software muss erlauben, Besichtigungszeiten flexibel vor einen oder mehrere Bewerbe zu lagern und den Typ (Fuß/Pferd) zu kennzeichnen.
+
+Die "Besichtigung zu Pferd" ist ein valider Spezialfall für Springpferdeprüfungen. Die Software muss erlauben,
+Besichtigungszeiten flexibel vor einen oder mehrere Bewerbe zu lagern und den Typ (Fuß/Pferd) zu kennzeichnen.

 ---
 *Geprüft durch den 📜 ÖTO/FEI Rulebook Expert am 11.04.2026*
@@ -0,0 +1,62 @@
+# 🤖 Konzept: Status-Automat für Nennungen & Zeitplan-Synchronisation
+
+Dieses Dokument spezifiziert die Logik des Status-Automaten für Nennungen (Sprint C-1) und dessen Auswirkungen auf den
+dynamischen Zeitplan.
+
+## 1. Status-Definitionen (NennStatusE)
+
+Basierend auf `core-domain/Enums.kt`:
+
+| Status             | Bedeutung                                         | Auswirkung auf Zeitplan                                 |
+|:-------------------|:--------------------------------------------------|:--------------------------------------------------------|
+| `EINGEGANGEN`      | Nennung wurde erstellt (Initialzustand)           | Belegt Zeitslot (basierend auf `reitdauerMinuten`)      |
+| `BESTAETIGT`       | Meldestelle hat Nennung geprüft                   | Belegt Zeitslot                                         |
+| `NACHNENNUNG`      | Nennung nach Nennschluss                          | Belegt Zeitslot (ggf. am Ende der Liste)                |
+| `TRANSFERIERT`     | Nennung wurde auf anderes Paar übertragen         | **Inaktiv** (Original-Eintrag wird durch neuen ersetzt) |
+| `ZURUECKGEZOGEN`   | Reiter hat abgemeldet (vor Startlistenerstellung) | **Inaktiv** (Slot wird frei)                            |
+| `GESTARTET`        | Paar ist in die Prüfung eingeritten               | Startzeitpunkt fixiert, Folgestarts ggf. anpassen       |
+| `NICHT_ANGETRETEN` | Paar ist zum Startzeitpunkt nicht erschienen      | **Zeitslot verfällt** oder Folgestarts rücken nach      |
+
+## 2. Status-Übergänge & Validierung
+
+### 2.1 Gültige Übergänge (Beispiele)
+
+- `EINGEGANGEN` -> `BESTAETIGT` (Normalfall)
+- `EINGEGANGEN` -> `ZURUECKGEZOGEN` (Abmeldung)
+- `BESTAETIGT` -> `TRANSFERIERT` (Reitertausch)
+- `BESTAETIGT` -> `GESTARTET` (Während des Turniers)
+
+### 2.2 Side-Effects (Side-Effect-Engine)
+
+Wenn sich der Status einer Nennung ändert, müssen folgende Systeme informiert werden:
+
+1. **Billing-Service:** Bei `ZURUECKGEZOGEN` ggf. Stornogebühren prüfen. Bei `TRANSFERIERT` Guthaben übertragen.
+2. **Startlisten-Service:** Bei `ZURUECKGEZOGEN` nach Veröffentlichung der Startliste -> Eintrag als
+   `istGestrichen = true` markieren.
+3. **Zeitplan-Optimierung:** Bei `NICHT_ANGETRETEN` -> Alle folgenden Startzeiten rücken um `reitdauerMinuten` nach
+   vorne (sofern im Kalender-Modus "Dynamisch" aktiv ist).
+
+## 3. Dynamische Zeitplan-Anpassung (C-1 Extension)
+
+Der `StartlistenService` muss eine Methode `aktualisiereZeitplanNachStatusAenderung` erhalten:
+
+- **Szenario A (Nicht angetreten):** Wenn Nennung X `NICHT_ANGETRETEN` wird, rücken alle folgenden Nennungen in der
+  Abteilung nach vorne.
+- **Szenario B (Verspätung):** Wenn Nennung X `GESTARTET` wird, aber 2 Minuten später als geplant, verschieben sich alle
+  Folgetermine um +2 Minuten (Kettenreaktion).
+
+### Puffer-Regel (ÖTO-Konformität)
+
+- Eine dynamische Verschiebung nach *vorne* darf nie dazu führen, dass ein Reiter vor seiner ursprünglich kommunizierten
+  Startzeit (oder einem definierten Puffer-Zeitraum von z.B. 15 Minuten) starten muss, ohne dass dies explizit bestätigt
+  wurde.
+
+## 4. Implementierungs-Leitfaden für Backend (C-1)
+
+1. Erweiterung von `NennungUseCases.statusAendern` um Aufrufe der Side-Effect-Handler.
+2. Implementierung des `NennungStatusListener` in `entries-service`.
+3. Anbindung an den `StartlistenService` zur Zeitre-Kalkulation.
+
+---
+**Status:** Entwurf (Lead Architect)
+**Datum:** 11. April 2026
@@ -2,12 +2,12 @@
 type: Roadmap
 status: ACTIVE
 owner: Lead Architect
-last_update: 2026-04-21
+last_update: 2026-05-06
 ---

 # MASTER ROADMAP: Meldestelle

-🏗️ **[Lead Architect]** | 20. April 2026
+🏗️ **[Lead Architect]** | 30. April 2026

 **Strategisches Ziel:**
 Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
@@ -17,7 +17,7 @@ Vollständige Self-Hosted Infrastruktur (Gitea, Pangolin, Zora). Datensouveräni
 - Desktop-App ist der primäre Client (Compose Desktop, KMP) — „Desktop-First“ gilt für UX und Architektur.
 - Offline-First Betrieb mit lokaler Persistenz und opportunistischer Synchronisation.

-**Aktueller technischer Stand (30.03.2026):**
+**Aktueller technischer Stand (30.04.2026):**
 *   **Infrastruktur:** ✅ "Zora" (MS-R1, ARM64) ist live. Gitea & Registry laufen.
 *   **Networking:** ✅ Pangolin Tunnel ersetzt Cloudflare.
 *   **CI/CD:** ✅ Gitea Actions mit ARM64-Runner (VM 102) aktiv. Docker-Publish Pipeline grün.
@@ -51,403 +51,127 @@ und über definierte Schnittstellen kommunizieren.

 ---

-## 1. Abgeschlossene Phasen
+## 1. Abgeschlossene Phasen (Verifiziert)

-### PHASE 1: Documentation Cleanup ✅ ABGESCHLOSSEN
-*Ziel: Eine einzige, vertrauenswürdige Quelle der Wahrheit (SSOT) schaffen.*
+### PHASE 1: Domain-Design & Ubiquitous Language ✅

-#### 🧹 Agent: Curator
-*   [x] **Archivierung:** Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach `docs/_archive/` verschoben.
-*   [x] **Konsolidierung:** `Zora_System_Architektur.md` als zentrale Infrastruktur-Doku etablieren.
-*   [x] **Struktur:** `docs/` Ordner aufräumen (unnötige Root-Files in Unterordner).
-*   [x] **Index:** `README.md` im Root als Einstiegspunkt aktualisieren.
+*Status: Fachliche Grundlage vorhanden.*

-### PHASE 2: Infrastructure Hardening ✅ ABGESCHLOSSEN
-*Ziel: Stabilisierung der neuen Self-Hosted Umgebung.*
+*   [x] **DDD-Analyse:** 6 Bounded Contexts (SCS-Architektur) definiert.
+*   [x] **Terminologie:** `Veranstaltung` ≠ `Turnier` gemäß ÖTO § 2 Abs. 1 festgelegt.
+*   [x] **Ubiquitous Language:** Offizielle Domänen-Terminologie erstellt.

-#### 🐧 Agent: DevOps Engineer
+### PHASE 2: Infrastruktur & ZNS-Importer (Prototyp) ✅

-*   [x] **Keycloak Fix:** Verbindungsprobleme innerhalb des Docker-Netzwerks behoben (Alias `auth.mo-code.at`).
-*   [x] **Backup Strategy:** Automatisierte Backups für Gitea & Datenbanken auf Zora (`config/scripts/backup.sh`).
-*   [x] **Monitoring:** Prometheus/Grafana Dashboard für Zora finalisiert (`dc-ops.yaml`).
-*   [x] **Deployment:** Git-basiertes Deployment-Skript (`config/scripts/deploy.sh`) erstellt.
+*Status: Grundgerüst steht, Performance-Probleme bekannt.*

-### PHASE 3: Domain-Design & Ubiquitous Language ✅ ABGESCHLOSSEN
-
-*Ziel: Fachliche Grundlage für die Implementierung schaffen.*
-
-#### 🏗️ Agent: Lead Architect
-
-*   [x] **DDD-Analyse:** 6 Bounded Contexts (SCS-Architektur) definiert und priorisiert.
-*   [x] **Terminologie:** `Veranstaltung` ≠ `Turnier` gemäß ÖTO § 2 Abs. 1 festgelegt (ADR).
-*   [x] **Design-Baseline:** Vision_03 (Figma) als offizieller Design-Baseline festgelegt.
-*   [x] **Technologie:** Desktop-First-Strategie mit KMP/Compose Desktop beschlossen.
-
-#### 📜 Agent: ÖTO/FEI Rulebook Expert
-
-*   [x] **Ubiquitous Language:** Offizielle Domänen-Terminologie mit ÖTO-Referenzen erstellt.
-*   [x] **Abteilungs-Schwellenwerte:** Alle Trennungs-Schwellenwerte (§ 39 + spartenspezifisch) dokumentiert.
-    → `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
-
-#### 👷 Agent: Backend Developer
-
-*   [x] **Enums:** `SparteE`, `TurnierkategorieE`, `VeranstaltungsTypE`, `LizenzKlasseE`, `NennungsStatusE`,
-    `StartwunschE` – ÖTO-konform.
-*   [x] **Domain-Modelle:** `DomReiter` (actor-context), `DomNennung`, `DomNennungsTransfer` (registration-context).
-*   [x] **Modul:** `entries-domain` als KMP-Modul aufgesetzt und in `settings.gradle.kts` registriert.
+*   [x] **ZNS-Parser:** Grundsätzliche Fähigkeit zum Parsen von ZNS-Daten (Reiter, Pferde, Vereine, Funktionäre).
+*   [x] **UI-Gerüst:** Navigation und Dialog-Hüllen in Compose Desktop vorhanden.
+*   [x] **Plan-B:** Rudimentärer Mail-Service für Nennungs-Versand (funktional).

 ---

-## 2. Aktuelle Phase
+## 2. Der neue Weg: Fachliche Realität (Roadmap 2026)

-### PHASE 4: MVP-Implementierung ✅ ABGESCHLOSSEN
+Fokus: Physische Implementierung der Turnier-Hierarchie und technisches Onboarding.

-*Ziel: Lauffähiger MVP für `registration-context` und `actor-context` (P1-Contexts).*
+### MEILENSTEIN 0: Technische Geräte-Initialisierung (Prio 1) 🚧 IN ARBEIT (STABILISIERUNG)

-#### 🧐 Agent: QA Specialist
+*Ziel: Ein stabiles, offline-fähiges technisches Fundament für die Desktop-App.*

-*   [x] **Actor Context Stabilization:** Funktionär-Datenmodell (Richter/Parcoursbauer) auf professionelle Master-Daten-Referenzierung umgestellt und mit Reiter-Daten verknüpft (Import-Idempotenz via `satzNummer`). Redundante Kontakt-/Adressdaten entfernt. Alle ZNS-Import-Tests (9/9) stabilisiert und verwaiste Parser-Reste entfernt.
-*   [x] **Masterdata Standardization:** Bereinigung und Standardisierung der Masterdaten-Tabellen (Mehrzahl-Konvention: `bundeslaender`, `funktionaers_qualifikationen`, `reit_lizenzen`, `turnier_klassen`).
-*   [x] **ÖTO Data Seeding:** Umfassende Seeder für Funktionärs-Qualifikationen, Turnierklassen und Turnier-Sparten gemäß ÖTO implementiert. Einführung der Tabelle `turnier_sparten`.
-*   [x] **ZNS-Import Optimization:** Automatische Verknüpfung von Funktionären mit Reitern (Reihenfolge: VEREIN -> LIZENZ -> PFERDE -> RICHT). `ZnsImportService` für sequentielle Imports in Tests gehärtet.
-*   [x] **Service Stability:** Port-Konflikt des `masterdata-service` (Spring Management Port 8081 vs. Gateway) durch Umzug auf Port 8086 und explizite Bind-Adressen (Spring: 127.0.0.1, Ktor: 0.0.0.0) dauerhaft gelöst.
-*   [x] **Documentation:** `CHANGELOG.md` aktualisiert und Port-Konfiguration in `application.yml` dokumentiert.
-    → Note: `IdempotencyApiIntegrationTest` bleibt vorerst @Disabled, da das Hochfahren des Spring-Contexts in der
-    Testumgebung blockiert (unabhängig vom Plugin).
-    → Task: Integration-Test Umgebung (Port-Binding/Server-Lifecycle) für `masterdata-service` untersuchen.
+*   [x] **App-Icons (PNG/ICO):** Implementiert (Fix für Build-Fehler).
+*   [x] **Docker-Fix:** "services must be a mapping" behoben (dc-gui.yaml).
+*   [x] **Chat-Funktion (Desktop):** MVP implementiert (Navigation & UI).
+*   [x] **Geführte Discovery ("Zero-Config"):** Master-Namen statt IPs, "Wait-State" für Clients.
+*   [x] **Native FileDialogs:** Stabile Pfad-Auswahl für Plan-USB auf allen Systemen.
+*   [x] **Handshake-Feedback:** Visuelle Signalisierung des Verbindungsstatus (Grün/Rot).
+*   [x] **Client-Konfiguration:** Master kann nun Clients in der UI hinzufügen und bearbeiten.
+*   [x] **Master-UX:** Konfiguration beim Start nicht mehr zwangsgesperrt.
+*   [x] **Cross-Packaging (Conveyor):** Windows-Build auf Linux-CI ermöglicht (x64-Abhängigkeit identifiziert).
+*   [ ] **PoC Verifikation:** 🔴 **BLOCKIERT** (Log 483: ARM64-Runner inkompatibel mit Conveyor-Binary; Workflow auf
+    manuell gesetzt).

-#### 🏗️ Agent: Lead Architect
+### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT

-*   [x] **ADRs vervollständigen:** Bounded Context Mapping und Context Map dokumentieren.
-    → `docs/01_Architecture/adr/0014-bounded-context-mapping-de.md`
-    → `docs/01_Architecture/adr/0015-context-map-de.md`
-*   [x] **API-Design:** Schnittstellen zwischen den Contexts definieren (Anti-Corruption Layer).
-    → `docs/01_Architecture/adr/0016-api-design-acl-de.md`
-*   [x] **ÖTO-Validation-Seeds:** Seed-Daten für Lizenz-Matrix und Altersklassen finalisiert (V008).
+*Ziel: Veranstaltung -> Turnier -> Bewerb/Abteilung physisch anlegen und speichern.*

-#### 👷 Agent: Backend Developer
+*   [ ] **Persistenz-Layer:** Implementierung der lokalen Speicherung für alle Ebenen der Hierarchie.
+*   [ ] **Turnier-Wizard (Echt):** Umstellung des Wizards von `println`-Dummies auf echte Datenbank-Transaktionen.
+*   [ ] **Validierung:** Sicherstellen, dass Pflichtfelder (Turniernummer, Sparte) korrekt erfasst werden.

-*   [x] **ZNS-Importer:** Support für Richter-Import (RICHT01.DAT) und Reiter-Refactoring (LIZENZ01.DAT) vervollständigt. ✓
-*   [x] **Masterdata:** Qualifikations-System und Personen-Referenzen (Vereine, Bundesländer, Nationen) stabilisiert (Consul & MasterdataSeeder). ✓
-*   [x] **Infrastruktur:** Service-Discovery (Consul) für alle Microservices (incl. Masterdata) aktiviert.
-*   [x] **Infrastruktur:** Bean-Definitionen und Dependency-Injection im `zns-import-service` bereinigt.
-*   [x] **Database:** Initialisierung der Funktionärs-Tabellen stabilisiert (PSQLException Fix).
-*   [x] **`actor-context`:** Domain-Modelle für `Pferd`, `Funktionaer`, `Verein` implementiert.
-*   [x] **`registration-context`:** `DomBewerb`, `DomAbteilung`, `DomStartliste` implementiert.
-*   [x] **`event-management-context`:** `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert.
-*   [x] **Persistenz:** Repository-Interfaces und erste DB-Migrationen (Flyway/Liquibase).
-*   [x] **API:** REST-Endpunkte für Nennungs-Workflow (Kern-Use-Cases).
-*   [x] **Infrastruktur-Stabilisierung:** Kompilierfehler in `masterdata-infrastructure` behoben.
-*   [x] **Identity-Schnittstellen:** Endpunkte für ZNS-Linking über `identity-service` bereitgestellt.
+### MEILENSTEIN 2: ZNS-Performance & Daten-Qualität (Prio 2)

-#### 🎨 Agent: Frontend Expert
+*Ziel: Import der ZNS.zip in < 2 Minuten statt 30+ Minuten.*

-*   [x] **KMP/Compose Desktop:** Projektstruktur aufgesetzt (`frontend/shells/meldestelle-desktop`).
-*   [x] **Navigation:** Sidebar-Navigation gemäß Vision_03 implementiert (Veranstaltungen, Reiter, Pferde, Funktionäre,
-    Meisterschaften, Cups).
-*   [x] **Nennungs-Screen:** `TurnierDetailScreen` integriert `NennungsMaske` aus `nennung-feature` (Bewerbe-Tab ⭐).
+*   [ ] **Batch-Processing:** Umstellung des `ZnsImportService` auf Batch-Inserts (JDBC/Exposed).
+*   [ ] **Fortschritts-Anzeige:** Reale Rückmeldung über den Import-Status in der UI.

-#### 📜 Agent: ÖTO/FEI Rulebook Expert
+### MEILENSTEIN 3: Richtverfahren & Bewerbs-Konfiguration (Prio 3)

-*   [x] **Voltigieren (CVN):** Abteilungs-Trennungsregeln aus B-Teil § 400 ff. ausgewertet (offene Frage #3 teilweise
-    geklärt).
-    → B IV enthält keine eigenen Regeln – verweist auf OEPS-Reglement CVN. § 39 Abs. 1 gilt nicht für CVN. § 39 Abs.
-    2 (> 80 Starter) gilt als Fallback.
-    → `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` (Abschnitt 2.6)
-*   [x] **Fahren (CAN):** Starter-Schwellenwerte jenseits der Reitertreffen-Regel geklärt (offene Frage #4 teilweise
-    geklärt).
-    → B VII enthält keine eigenen Regeln – verweist auf OEPS-Reglement „Turnierordnung für Gespanne". § 39 Abs. 1 gilt
-    nicht für CAN. § 39 Abs. 2 (> 80 Starter) gilt als Fallback. Einzige gesicherte Lizenzregel: § 850 Abs. 9 (F1+ bei
-    Fahrertreffen).
-    → `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` (Abschnitt 2.5)
-*   [x] **Warn-Logik:** Spezifikation der `competition-context` Warn-Logik für Abteilungs-Schwellenwerte.
-    → `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md`
+*Ziel: Bewerbe mit fachlich korrekten Regeln (ÖTO) anlegen.*

-#### 🧹 Agent: Curator & Lead Architect (ZNS-Importer)
-
-*   [x] **ZNS-Importer (MVP) – Phase 1 & 2:** `core:zns-parser` (KMP), `ZnsLegacyParsers` (alle 4 Dateitypen, CP850),
-    `ZnsImportService` (Orchestrator, ZIP in-memory, Upsert), Unit-Tests grün.
-    → Detaillierte Planung: `docs/01_Architecture/Roadmap_ZNS_Importer.md`
-  *   [x] Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul)
-  *   [x] Domain-Mapping & Upsert in DB (Phase 2)
-  *   [x] REST-API & Job-Management (Phase 1 – Controller/Job-Registry)
-  *   [x] Frontend-Integration mit File-Picker & Status-Polling (Phase 3)
+*   [ ] **Richtverfahren-Engine:** Validierungslogik für verschiedene Richtverfahren (Fehler/Zeit, Wertnoten).
+*   [ ] **Abteilungs-Logik:** Automatische Teilungsvorschläge gemäß ÖTO § 39.

 ---

-## 3. Initiative: Wizard-Orchestrator & Offline-Drafts (Q2/Q3 2026)
+## 3. Zukünftige Module (Status: Geplant / Vision)

-🏗️ Verantwortlich: Lead Architect · 🎨 Frontend · 🖌️ UI/UX · 👷 Backend · 🧐 QA · 🧹 Curator
+*Diese Module existieren derzeit nur als Konzepte oder leere Hüllen.*

-Ziel: Konsolidierung aller „Wizards“ auf ein deklaratives Orchestrierungs-Framework (Graph + Guards + Effects), vereinheitlichte Validierung und Offline-Draft-Fähigkeit inkl. Delta‑Sync. Desktop-first, tastaturbedienbar, testbar.
-
-### 3.1 Kernbausteine
- Orchestrator Runtime & DSL: `StepId`, `WizardContext`, `WizardState`, `Guard`, `Transition`, `StepEffects`.
- WizardScaffold: Breadcrumb, Kontext-Chips, Footer mit Hotkeys (Enter/Shift+Enter/Alt+S), Fehler-Summary.
- DraftStore: Autosave pro Step (`onLeave`), Resume, `flowVersion`, Konfliktanzeige.
- DevTools: strukturierte Transition-Logs, Graph-Export (DOT/PlantUML).
-
-Referenzen/Dokumente:
- ADR‑0025: Wizard-Orchestrator (State‑Machine, DSL, Guards, Effects) → `docs/01_Architecture/adr/0025-wizard-orchestrator-de.md`
- ADR‑0026: Step-Validation-Policy (sync vs. async, Fehlersichtbarkeit, Hotkeys) → `docs/01_Architecture/adr/0026-validation-policy-de.md`
- ADR‑0027: Draft-Domain & Delta‑Sync (Versionierung, Konfliktlösung, Idempotenz) → `docs/01_Architecture/adr/0027-draft-domain-and-delta-sync-de.md`
- Reference: Wizard‑DSL README (Beispiel-Flow Event) → `docs/01_Architecture/Reference/Wizard-DSL-README.md`
-
-### 3.2 Migrationsstrategie (Strangler)
-1) Parallelbetrieb: Neuer Orchestrator in `frontend/core/wizard`; bestehende VMs delegieren schrittweise.
-2) Inkrement 1: Event‑Flow – zunächst 2 Steps (ZNS_CHECK, VERANSTALTER_SELECTION), dann alle 6 Steps.
-3) Feature‑Flag `WizardRuntimeEnabled` für risikoarmen Rollout.
-
-### 3.3 Phasenplanung (Auszug)
- Phase 1 (Core & Tooling, 2–3 Wochen): Runtime/DSL, DevLogs, Graph‑Export, Scaffold‑MVP, Unit‑Tests.
- Phase 2 (Event‑Flow, 2–3 Wochen): `EventStep/Acc/Guards`, Flow‑DSL, VM‑Delegation, Validierung, Autosave/Resume.
- Phase 3 (Backend, 2–4 Wochen): Draft-/Validate‑APIs, Offline‑Queue, Delta‑Sync für Turniere.
- Phase 4 (Skalierung, 6–10 Wochen, parallel): Weitere Flows je Bounded Context.
- Phase 5–7 (2–3 + 1–2 + 1–2 Wochen): UX‑Härtung, Observability/Rollout‑Gates, Stabilisierung & Abschaltung Altlogik.
-
-Grobe Gesamtdauer: 17–29 Wochen je nach Parallelisierung.
-
-### 3.4 Akzeptanzkriterien (DoD Initiative)
- Alle priorisierten Flows laufen über Orchestrator; Next/Back/History deterministisch; Graph‑Export aktuell.
- DraftStore produktiv; Resume deterministisch; Delta‑Sync idempotent; Konflikte nicht‑blockierend sichtbar.
- Validierungs‑Policy konsistent; Tastatur‑Bedienung vollständig; Performance‑Gates eingehalten.
- ADR‑0025/0026/0027 veröffentlicht; Wizard‑DSL‑Reference vorhanden; CI grün; Metriken/Alerts aktiv.
-
-### 3.5 10‑Tage‑Startplan
- Tag 1–2: Runtime/DSL‑Skelett, Scaffold‑MVP, Feature‑Flag, README Skeleton.
- Tag 3: EventStep/Acc/Guards, EventFlow (2 Steps), VM‑Delegation minimal.
- Tag 4: Tests Runtime/Guards, Graph‑Export, Dev‑Logs.
- Tag 5–6: META_DATA/ANSPRECHPERSON migrieren, Validierungs‑API, Fehler‑Summary.
- Tag 7: DraftStore lokal (Autosave/Resume), Property‑Test Resume.
- Tag 8: TURNIER_ANLAGE einbetten, Sync via `onComplete`.
- Tag 9: SUMMARY + Finalisierung, Offload in Offline‑Queue (Stub).
- Tag 10: ADR‑0025/0026/0027 Review+Merge; Journal‑Eintrag.
-
-Journal: `docs/99_Journal/2026-04-21_Wizard-Orchestrator_Roadmap_Anchoring.md`
+* **Nennungs-Management:** Erfassung von Nennungen gegen den ZNS-Datenbestand.
+* **Zeitplan:** Dynamische Zeitplanung (Drag & Drop).
+* **Ergebnisse:** Erfassung von Wertungen und Platzierungsberechnung.
+* **Abrechnung:** Vollständiger `billing-context`.

 ---

-## 3. Aktuelle Phase
+## 4. Archiv der fiktiven Meilensteine (Reality-Check am 28.04.2026)

-### Progress Checkpoint – 2026-04-21 (Wizard-Orchestrator Initiative)
+*Die folgenden Einträge wurden in früheren Sitzungen als "Abgeschlossen" markiert, entsprachen aber nicht dem realen
+Code-Stand.*

- Core/DSL: angelegt in `frontend/core/wizard` (Runtime, DSL), erste Tests grün.
- UI: `WizardScaffold` (MVP) + Hotkeys-Wrapper (Enter/Shift+Enter/Alt+S) vorhanden.
- Feature-Integration: Veranstaltungs-Wizard hinter Flag teilweise delegiert.
- Drafts: In‑Memory DraftStore (Autosave/Resume Hooks) angebunden.
- DI: Koin-Parameterübergabe für `EventWizardViewModel` vereinheitlicht.
- Flag: `WizardRuntimeEnabled = false` (Standard AUS; Dev-Verprobung manuell).
+<details>
+<summary>Frühere (fiktive) Meilensteine anzeigen</summary>

-Nächste Schritte (Kurz): Tests für `needsContactPerson` (beide Zweige), VM‑Delegation für weitere Steps, Footer‑Fehler‑Summary, persistenter DraftStore, Dev‑Overlay.
+### PHASE 4: MVP-Implementierung (Früherer Status: Abgeschlossen)

-### PHASE 5: P2-Contexts & Integration ✅ ABGESCHLOSSEN
+*   [ ] ZNS-Import Optimierung (Batching) -> In MEILENSTEIN 2 verschoben.
+*   [ ] `event-management-context` Implementierung -> In MEILENSTEIN 1 verschoben.

-*Ziel: `competition-context` und `event-management-context` implementieren.*
+### PHASE 5-13 (Früherer Status: Abgeschlossen/In Arbeit)

-*   [x] **`competition-context`:** Bewerbe, Startlisten, Ergebnisse, Abteilungs-Warn-Logik.
-*   [x] **`event-management-context`:** Veranstaltungs- und Turnier-Verwaltung, Ausschreibungs-Generator.
-*   [x] **ZNS-Integration:** Schnittstelle zum Zentralen Nennungs-System (A-Satz / B-Satz).
-*   [x] **Offline-Sync:** Offline-First-Strategie für Desktop-App implementieren.
+*   [ ] `competition-context` (Bewerbe, Startlisten) -> Fachlogik fehlt weitgehend.
+*   [ ] `billing-context` (Abrechnung) -> Nur Infrastruktur-Hülle vorhanden.
+*   [ ] `results-service` -> Geschäftslogik fehlt.

-### PHASE 6: P3-Contexts & Billing ✅ ABGESCHLOSSEN
-
-*Ziel: `billing-context` und `identity-context` implementieren.*
-
-*   [x] **`billing-context`:** Gebührenberechnung, Kassa, Abrechnung.
-*   [x] **`identity-context`:** Rollen-Modell (TBA, Veranstalter, Richter etc.) mit Keycloak.
-*   [x] **Reporting:** Startlisten- und Ergebnislisten-Druck (PDF).
+</details>

 ---

-## 4. Geplante Phasen
-
-### PHASE 7: Desktop-Vernetzung & Zentrale Verwaltung ✅ ABGESCHLOSSEN
-
-*Ziel: LAN-Kommunikation Vorbereitung und Etablierung der "Veranstaltung-Verwaltung" als zentrale Schaltstelle.*
-
-*   [x] **Zentrale Verwaltung:** Etablierung der `Veranstaltung-Verwaltung` (Zentrale) als administratives Cockpit.
-*   [x] **Navigation:** Implementierung eines Back-Stack-Systems für intelligente "Zurück"-Navigation.
-*   [x] **Domänen-Synchronisation:** Anpassung der Frontend-Stores an die Backend-Masterdata-Modelle (Reiter, Pferde,
-    Vereine, Funktionäre).
-*   [x] **ZNS-Integration (Frontend):** ZNS-Importer in die Zentrale integriert; Konzept "Globaler Pool -> Lokale
-    Synchronisation" gefestigt.
-*   [x] **Terminologie:** UI-weit Umstellung von "Event" auf "Veranstaltung" (ÖTO-konform).
-*   [x] **Konzept:** LAN-Discovery (mDNS) und Echtzeit-Sync (WebSockets) entworfen.
-*   [x] **ADR:** ADR-0020 (Lokale Netzwerk-Kommunikation) erstellt.
-
-### PHASE 8: Bewerbe-Management & Startlisten ✅ ABGESCHLOSSEN
-
-*Ziel: Fachliche Tiefe in den Turnieren (Import, Generierung, Zeitberechnung).*
-
-*   [x] **Konzept/ADR:** LAN‑Sync (ADR‑0022) und Offline‑First Desktop↔Backend Konzept definiert und verlinkt.
-*   [x] **Bewerbe-Import:** Implementierung der Merge-Logik (ZNS-XML -> BewerbUiModel). ✓
-*   [x] **Startlisten-Automatisierung:** Generierung und Zeitberechnung (Pausen, Umbauzeiten). ✓
-*   [x] **Discovery:** Implementierung des mDNS-Service (JmDNS) für die Geräte-Suche. ✓
-*   [x] **Transport:** Aufbau der WebSocket-Infrastruktur für P2P-Sync (Ktor WebSockets, SyncManager). ✓
-*   [x] **Offline-First Desktop↔Backend:** Umsetzung gemäß Konzept „Offline-First Synchronisation (Desktop ↔ Backend)“ → `docs/01_Architecture/konzept-offline-first-desktop-backend-de.md`. ✓
-*   [x] **Regelwerks-Validierung:** Implementierung des strukturierten Abteilungs-Warnungssystems gemäß ÖTO § 39 inkl. UI-Integration. ✓
-
-### PHASE 9: Zeitplan-Optimierung & Protokollierung ✅ ABGESCHLOSSEN
-
-*Ziel: Dynamische Zeitplan-Anpassungen, Protokollierung von Änderungen und Export-Funktionen.*
-
-*   [x] **Billing-Service:** Initialisierung, Teilnehmer-Konten & Buchungs-Logik (v1). ✓
-*   [x] **Entries-Integration:** Automatische Buchung von Nenngeldern bei Nennungs-Abgabe. ✓
-*   [x] **ZNS-Importer:** Hardening & Integrationstests für Funktionärs-Updates. ✓
-*   [x] **Konzept:** Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt. ✓
-*   [x] **Konzept:** Status-Automat für Nennungen & Zeitplan-Synchronisation spezifiziert. ✓
-*   [x] **Frontend-Standardisierung:** `nennung-feature` refactored und in Desktop-Shell integriert. ✓
-*   [x] **Rulebook-Check:** ÖTO §43 "Parcoursbesichtigung zu Pferd" eingearbeitet. ✓
-*   [x] **Feature-Migration:** Pferde-, Reiter-, Funktionärs- und Veranstalter-Module vollständig auf KMP umgestellt. ✓
-*   [x] **Cleanup:** `FRONTEND_CLEANUP_TODO.md` für Migration von `v2` Screens weitestgehend abgeschlossen. ✓
-*   [x] **Zeitplan:** Dynamische Verschiebung von Bewerben (Drag & Drop im Kalender). ✓
-*   [x] **Protokoll:** Implementierung eines Event-Logs für manuelle Eingriffe in Startlisten (Audit-Log). ✓
-*   [x] **Export:** Startlisten-Export für ZNS (XML-B-Satz). ✓
-
-### PHASE 10: Series-Context & Stammdaten ✅ ABGESCHLOSSEN
-
-*Ziel: Stammdaten-Integration (Reiter, Pferde, Funktionäre) und Series-Context (Cups).*
-
-*   [x] **Frontend-Integration:** Stammdaten-Infrastruktur (Repositories, ViewModels) für Reiter, Pferde, Funktionäre und Vereine im `turnier-feature` implementiert. ✓
-*   [x] **Nennungs-Management:** Funktionalisierung des Nennungs-Tabs mit Echt-Datenanbindung und Suche. ✓
-*   [x] **`series-context`:** Pluggable Berechnungsmodell (Streichresultate, Alles zählt), konfigurierbare Paar-Bindung (Reiter+Pferd vs. Einzelwertung) implementiert. ✓
-*   [x] **Backend-Integration:** `series-service` als Microservice mit JPA-Persistenz, Flyway-Migrationen und Gateway-Routing vervollständigt. ✓
-
-## 4. Geplante Phasen
-
-### PHASE 11: Ergebniserfassung & Platzierung ✅ ABGESCHLOSSEN
-
-*Ziel: Vollständige Ergebniserfassung und automatisierte Platzierungsberechnung.*
-
-*   [x] **Backend (Results):** Implementierung der Geschäftslogik für Wertnoten, Zeitfehler und ÖTO-konforme Platzierungen. ✓
-*   [x] **Backend-Infrastruktur:** `results-service` in Docker-Compose und API-Gateway integriert; Service-Discovery via Consul aktiviert. ✓
-*   [x] **Frontend UI:** `ErgebnisEditDialog` zur schnellen Ergebniserfassung und `TurnierErgebnislistenTab` zur Anzeige realer Ergebnisse. ✓
-*   [x] **PDF-Export:** Generierung von PDF-Ergebnislisten (Bewerbe und Serien). ✓
-
-### PHASE 12: Abrechnung & Billing 🔵 IN ARBEIT
-
-*Ziel: Vollständige Kassa-Funktionalität und Turnier-Abrechnung.*
-
-*   [x] **Backend-Infrastruktur:** `billing-service` initialisiert, Docker-Integration und Gateway-Routing (Port 8087) konfiguriert. ✓
-*   [x] **Frontend-Anbindung:** `BillingRepository` (Ktor) und `BillingViewModel` auf reale API-Kommunikation umgestellt. ✓
-*   [x] **Buchungs-Logik:** Implementierung von Soll/Haben-Buchungen (Startgebühren, Nenngelder, Boxen). ✓
-*   [x] **Offene Posten:** Liste aller unbezahlten Beträge pro Teilnehmer/Pferd. ✓
-*   [x] **Rechnungserstellung:** Generierung von PDF-Rechnungen und Zahlungsbestätigungen. ✓
-*   [x] **Kassa-Management:** Tagesabschluss, Storno-Logik und verschiedene Zahlungsarten. ✓
-
---
-
-## 4. Geplante Phasen
-
-### PHASE 13: Frontend-Modernisierung & Cleanup ✅ ABGESCHLOSSEN (20. April 2026)
-*Ziel: Finalisierung der Turnier-Daten, Rückübermittlung an den OEPS und architektonische Bereinigung.*
-
-*   [x] **"V2"-Bereinigung:** Vollständige Eliminierung aller "V2"-Suffixe in Dateinamen und Symbolen (z.B. `TurnierWizardV2`, `VeranstalterAuswahlV2`). ✓ (20. April 2026)
-*   [x] **Plug-and-Play (Turnier):** Umstellung des `turnier-feature` auf ADR-0024. Entfernung von Reflection-Zugriffen auf die Shell und Einführung von ViewModel-Hoisting. ✓ (20. April 2026)
-*   [x] **Plug-and-Play (Veranstalter):** Umstellung des `veranstalter-feature` auf ADR-0024. Einführung des `VeranstalterDetailViewModel` und Konsolidierung der Screens in der Desktop-Shell. ✓ (20. April 2026)
-*   [x] **Device-Setup ("Lock-and-Edit"):** Einführung eines Review-Modus mit Konfigurations-Sperre, Drucker-Integration und Maskierung des SharedKeys. ✓ (20. April 2026)
-*   [x] **Veranstaltungs-Wizard:** Implementierung eines 6-stufigen Profi-Workflows mit Sticky Preview-Card (WYSIWYG), ZNS-Guard und OEPS-Satznummer-Mapping. ✓ (20. April 2026)
-*   [x] **Code-Hygiene:** Beseitigung von Code-Smells, redundanten Validierungen und ungenutzten Parametern in den zentralen Frontend-Modulen. ✓ (20. April 2026)
-*   [x] **Connectivity-Diagnose:** Stabiles Diagnose-Tool für Backend-, DB- und Auth-Verbindung in der Desktop-App. ✓ (18. April 2026)
-*   [x] **WASM-Transition:** Projektweite Umstellung auf JVM (Desktop) und wasmJs (Web). Eliminierung von `js(IR)`. ✓ (18. April 2026)
-*   [x] **Geräte-Initialisierung:** Refactoring des Onboarding-Prozesses in das Plug-and-Play Modul `device-initialization`. ✓ (18. April 2026)
-*   [ ] **XML-Export:** Vollständiger B-Satz Export (inkl. Ergebnisse und Platzierungen).
-*   [ ] **ZNS-Portal:** Upload-Integration in das OEPS-ZNS.
-*   [ ] **Archivierung:** Langzeit-Archivierung abgeschlossener Turniere.
-
---
-
-## 5. Wichtige Architektur-Entscheidungen (ADRs)
-
-| #  | Entscheidung                                                 | Status | Dokument                     |
-|----|--------------------------------------------------------------|--------|------------------------------|
-| 1  | Vision_03 = Design-Baseline                                  | ✅      | Session Log 2026-03-24       |
-| 2  | Desktop-First mit KMP/Compose Desktop                        | ✅      | ADR-0009                     |
-| 3  | `Veranstaltung` ≠ `Turnier` (ÖTO § 2 Abs. 1)                 | ✅      | Ubiquitous Language          |
-| 4  | 6 Bounded Contexts als SCS-Architektur                       | ✅      | Session Log 2026-03-24       |
-| 5  | `series-context` ist Phase 2+ (Architektur vorbereitet)      | ✅      | Session Log 2026-03-24       |
-| 6  | Cups/Serien benötigen konfigurierbare Reglements             | ✅      | Session Log 2026-03-24       |
-| 7  | Warn-Logik statt harter Fehler (Override-Event)              | ✅      | Abteilungs-Schwellenwerte.md |
-| 8  | 6 Bounded Contexts: Mapping & Aggregate Roots                | ✅      | ADR-0014                     |
-| 9  | Context Map: Integration Patterns & ACL-Strategie            | ✅      | ADR-0015                     |
-| 10 | API-Design & ACL: Ports, DTOs, REST-Endpunkte, Domain Events | ✅      | ADR-0016                     |
-| 11 | Masterdata: Importer-Einbettung als Worker                   | ✅      | ADR-0017                     |
-| 12 | Masterdata: Rule-Versionierung (Regulation-as-Data)          | ✅      | ADR-0018                     |
-| 13 | Masterdata: API-Schichten (REST vs. Ingestion)               | ✅      | ADR-0019                     |
-| 14 | Lokale Netzwerk-Kommunikation und Daten-Isolierung           | ✅      | ADR-0020                     |
-| 15 | Masterdata: Observability & Operations                       | ✅      | masterdata-ops.md, CHANGELOG |
-| 16 | Tenant-Resolution: Schema-per-Tenant                         | ✅      | ADR-0021                     |
-| 17 | LAN-Sync-Protokoll (Lamport-Uhren, Event-Sourcing Light)     | ✅      | ADR-0022                     |
-| 18 | Domain-Naming: Kein `Dom`-Präfix für Entitäten               | ✅      | ADR-0023                     |
-| 19 | Plug-and-Play Architektur für UI-Komponenten                 | ✅      | ADR-0024                     |
-
---

 ## 5. Wichtige Referenzen

-| Dokument                  | Pfad                                                                                         |
-|---------------------------|----------------------------------------------------------------------------------------------|
-| Ubiquitous Language       | `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`                                          |
-| Abteilungs-Schwellenwerte | `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`          |
-| Warn-Logik-Spezifikation  | `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
-| Session Log (DDD)         | `docs/99_Journal/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md`                          |
-| Infrastruktur             | `docs/07_Infrastructure/Zora_System_Architektur.md`                                          |
-| Deployment Guide          | `docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md`                                 |
-| Backup Guide              | `docs/07_Infrastructure/Guides/Setup_Backup_Zora.md`                                         |
-| CI/CD                     | `.gitea/workflows/docker-publish.yaml`                                                       |
-| Agent Playbooks           | `docs/04_Agents/Playbooks/`                                                                  |
-| ADR-Verzeichnis           | `docs/01_Architecture/adr/`                                                                  |
-| ZNS-Importer Roadmap      | `docs/01_Architecture/Roadmap_ZNS_Importer.md`                                               |
-| Masterdata Roadmap        | `backend/services/masterdata/docs/ROADMAP.md`                                                |
-| Masterdata Changelog      | `backend/services/masterdata/docs/CHANGELOG.md`                                              |
-| Masterdata Operations     | `backend/services/masterdata/docs/runbooks/masterdata-ops.md`                                |
-| Zeitplan-Optimierung      | `docs/01_Architecture/konzept-zeitplan-optimierung-de.md`                                   |
-| Parcoursbesichtigung-Rulebook | `docs/01_Architecture/rulebook-check-parcoursbesichtigung-de.md`                       |
-| Status-Automat-Nennungen  | `docs/01_Architecture/status-automat-nennungen-de.md`                                       |
-
-
---
-
-## 3. Zukünftige Phase (April 2026)
-
-### PHASE 5: Web-App & Neumarkt-Vorbereitung 🔵 IN ARBEIT (Start 13. April 2026)
-
-*Ziel: Fertigstellung der Web-App für Online-Nennungen und Vorbereitung des Neumarkt-Turniers (24. April).*
-
-#### 🎨 Agent: Frontend Expert
-*   [x] **Web-App Shell:** Modul `frontend:shells:meldestelle-web` (Compose WasmJS) initialisiert.
-*   [x] **UI-Komponenten:** `VeranstaltungsCard` und `TurnierCard` für Web implementiert (mit PDF- & Nenn-Button).
-*   [x] **Workflow:** `NennungWebFormular` Prototyp erstellt (mit simuliertem Mail-Versand).
-
-#### 👷 Agent: Backend Developer
-*   [x] **Daten-Seeding:** Desktop-Stores mit echten Daten für Neumarkt (April 2026) vorbefüllt.
-*   [ ] **Mail-Service:** Integration eines E-Mail-Dienstes für eingehende Nennungen.
-
-#### 🧐 Agent: QA Specialist
-*   [x] **Verifikation:** Desktop-Screens (Veranstalter, Turnier, Bewerbe) mit echten Daten geprüft.
-*   [ ] **End-to-End Test:** Online-Nennung (Web) -> E-Mail -> Desktop-Verarbeitung.
-
---
-
-### PHASE 5: Desktop-Zentrale & Synchronisation 🔵 IN ARBEIT
-
-*Ziel: Ein einsatzbereiter Desktop-Client für das Neumarkt-Turnier.*
-
-#### 🎨 Agent: Frontend Expert
-
-*   [x] **Onboarding UI:** Implementierung des Onboarding-Screens (Name, Key, Backup, Rolle, Sync, Drucker) mit
-    validierten Eingaben.
-*   [x] **Navigation:** Navigations-Rail mit Hover-Tooltips und dedizierten Icons für "Setup" und "Sync".
-*   [x] **Settings:** Persistente Speicherung der Onboarding-Daten in `settings.json`.
-
-#### 👷 Agent: Backend Developer
-
-*   [x] **Device Management:** Domain-Modell (`Device`), Tabelle (`identity_devices`) und Repository zur
-    Geräteverwaltung implementiert.
-*   [x] **Security Key Auth:** Implementierung des `DeviceSecurityFilter` zur Authentifizierung via `X-Security-Key`
-    Header.
-*   [x] **Onboarding API:** REST-Endpunkte zur Registrierung und Abfrage von Desktop-Instanzen erstellt.
-
-#### 🧹 Agent: Curator
-
-*   [x] **Dokumentation:** Erstellung der Architektur-Doku für das Onboarding-Backend.
+| Dokument                      | Pfad                                                                                         |
+|-------------------------------|----------------------------------------------------------------------------------------------|
+| Ubiquitous Language           | `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`                                          |
+| Abteilungs-Schwellenwerte     | `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`          |
+| Warn-Logik-Spezifikation      | `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
+| Session Log (DDD)             | `docs/99_Journal/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md`                          |
+| Infrastruktur                 | `docs/07_Infrastructure/Zora_System_Architektur.md`                                          |
+| Deployment Guide              | `docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md`                                 |
+| Backup Guide                  | `docs/07_Infrastructure/Guides/Setup_Backup_Zora.md`                                         |
+| CI/CD                         | `.gitea/workflows/docker-publish.yaml`                                                       |
+| Agent Playbooks               | `docs/04_Agents/Playbooks/`                                                                  |
+| ADR-Verzeichnis               | `docs/01_Architecture/adr/`                                                                  |
+| ADR-0025: Plan-USB            | `docs/01_Architecture/adr/0025-plan-usb-offline-integritaet.md`                              |
+| ADR-0026: Lizenzierung        | `docs/01_Architecture/adr/0026-offline-lizenzierung-pay-per-event.md`                        |
+| ADR-0027: Discovery           | `docs/01_Architecture/adr/0027-netzwerk-discovery-interface-binding.md`                      |
+| Docker-Fix: dc-gui.yaml       | `dc-gui.yaml`                                                                                |
+| ZNS-Importer Roadmap          | `docs/01_Architecture/Roadmaps/Roadmap_ZNS_Importer.md`                                      |
+| Masterdata Roadmap            | `backend/services/masterdata/docs/ROADMAP.md`                                                |
+| Masterdata Changelog          | `backend/services/masterdata/docs/CHANGELOG.md`                                              |
+| Masterdata Operations         | `backend/services/masterdata/docs/runbooks/masterdata-ops.md`                                |
+| Zeitplan-Optimierung          | `docs/01_Architecture/Concepts/konzept-zeitplan-optimierung-de.md`                           |
+| Parcoursbesichtigung-Rulebook | `docs/01_Architecture/Concepts/rulebook-check-parcoursbesichtigung-de.md`                    |
+| Status-Automat-Nennungen      | `docs/01_Architecture/Concepts/status-automat-nennungen-de.md`                               |
@@ -1,358 +0,0 @@
---
-type: Reference
-status: ACTIVE
-owner: Lead Architect
-date: 2026-03-07
---
-# Meldestelle — Tech-Stack Zusammenfassung
-
-> **Zweck:** Vollständige Referenz des eingesetzten Tech-Stacks im Projekt "Meldestelle".
-> Dient als Basis für Recherchen zu Self-Hosted AI (Codegenerierung, RAG, Agenten).
-> **Stand:** 07. März 2026
-
---
-
-## 1. Überblick
-
-Das Projekt "Meldestelle" ist eine **Kotlin-first, Cloud-native Microservices-Plattform** für die Verwaltung von Reitsport-Meldungen (FEI / ÖTO). Es kombiniert ein **Kotlin Multiplatform (KMP) Frontend** mit einem **Spring Boot Microservices Backend** auf einer vollständig self-hosted Infrastruktur.
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  Frontend (KMP)          │  Backend (Spring Boot / Kotlin JVM)  │
-│  Kotlin 2.3 / Compose    │  Java 25 / Spring Boot 3.5.9         │
-│  JS + WASM (geplant)     │  Microservices + API-Gateway          │
-├─────────────────────────────────────────────────────────────────┤
-│  Infrastruktur (Self-Hosted auf Zora / Proxmox)                 │
-│  Keycloak · Consul · Valkey · PostgreSQL · Zipkin               │
-│  Prometheus · Grafana · Caddy · Pangolin-Tunnel                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
---
-
-## 2. Sprachen & Laufzeiten
-
-| Komponente        | Sprache / Runtime        | Version     |
-|:------------------|:-------------------------|:------------|
-| Backend           | Kotlin (JVM)             | 2.3.0       |
-| Frontend          | Kotlin (KMP / JS)        | 2.3.0       |
-| JVM               | Java (Eclipse Temurin)   | 25 (EA)     |
-| Build             | Gradle (Kotlin DSL)      | 9.3.1       |
-| Plattform         | ARM64 (AArch64)          | Linux       |
-
---
-
-## 3. Frontend — Kotlin Multiplatform (KMP)
-
-### 3.1 Core-Framework
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Kotlin Multiplatform          | 2.3.0     | Cross-Platform-Basis (JS + WASM)   |
-| Compose Multiplatform         | 1.10.0    | UI-Framework (Deklarativ)          |
-| Compose Hot Reload            | 1.0.0     | Live-Reload im Dev-Modus           |
-| Koin (DI)                     | 4.1.1     | Dependency Injection               |
-| Koin Compose                  | 4.1.1     | DI-Integration für Compose         |
-| Ktor Client                   | 3.4.0     | HTTP-Client (Multiplatform)        |
-| Kotlin Serialization          | 2.3.0     | JSON-Serialisierung                |
-
-### 3.2 Persistenz (Offline-First)
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| SQLDelight                    | 2.2.1     | Cross-Platform SQL-Datenbank       |
-| SQLite (WASM)                 | 3.51.1    | SQLite für Browser/WASM            |
-| SQLite (Native)               | 2.6.2     | SQLite für JVM/Desktop             |
-
-### 3.3 Build-Targets
-
-| Target        | Status      | Anmerkung                          |
-|:--------------|:------------|:-----------------------------------|
-| KotlinJS      | ✅ Aktiv    | Primäres Build-Target              |
-| WASM          | ⏳ Geplant  | Warten auf Alpha-Version           |
-| Desktop (JVM) | ⚙️ Möglich  | uiDesktop 1.7.0 vorhanden          |
-
-### 3.4 Modul-Struktur
-
-```
-frontend/
-├── core/
-│   ├── core-network/          # Ktor HTTP-Client, Auth-Interceptor
-│   ├── core-ui/               # Design-System, Tokens, Komponenten
-│   ├── core-domain/           # Shared Domain-Models
-│   └── core-data/             # Repository-Interfaces
-├── features/
-│   ├── ping-feature/          # ✅ Blueprint: MVVM + Repository + DI + Tests
-│   └── members-feature/       # ⏳ Auskommentiert (nächste Phase)
-└── shells/
-    └── meldestelle-portal/    # Web-App Shell (Caddy-served)
-```
-
---
-
-## 4. Backend — Spring Boot Microservices
-
-### 4.1 Core-Framework
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Spring Boot                   | 3.5.9     | Microservices-Framework            |
-| Spring Cloud                  | 2025.0.1  | Service Discovery, Config          |
-| Spring Security (OAuth2)      | (Boot)    | JWT-Validierung, Resource Server   |
-| Spring Data JPA               | (Boot)    | ORM-Layer                          |
-| Spring Data Valkey            | 0.2.0     | Cache-Integration (Valkey/Redis)   |
-| Spring WebFlux                | (Boot)    | Reaktive API (Gateway)             |
-| Kotlin Coroutines             | 2.3.0     | Async/Non-blocking                 |
-
-### 4.2 Persistenz
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| PostgreSQL Driver             | 42.7.8    | JDBC-Treiber                       |
-| Exposed (JetBrains)           | 1.0.0     | Kotlin-native SQL DSL              |
-| Flyway                        | 11.19.1   | Datenbank-Migrationen              |
-| HikariCP                      | 7.0.2     | Connection Pool                    |
-
-> **Strategie (ADR-001):** Hybrid — JPA für einfache CRUD-Entities, Exposed für komplexe Queries und Domain-Logik.
-
-### 4.3 Caching & Messaging
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Lettuce                       | 6.6.0     | Valkey/Redis-Client (reaktiv)      |
-| Redisson                      | 4.0.0     | Distributed Locks, Pub/Sub         |
-| Caffeine                      | 3.2.3     | In-Memory Cache (L1)               |
-| Reactor Kafka                 | 1.3.23    | Kafka-Client (Phase 3 / Outbox)    |
-
-### 4.4 Observability & Tracing
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Micrometer                    | 1.16.1    | Metriken (Prometheus-Export)       |
-| Micrometer Tracing            | 1.6.1     | Distributed Tracing                |
-| Zipkin Reporter               | 3.5.1     | Trace-Export zu Zipkin             |
-| Logback                       | 1.5.25    | Logging                            |
-
-### 4.5 Security
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Keycloak Admin Client         | 26.0.7    | Keycloak-API-Integration           |
-| Spring Security OAuth2        | (Boot)    | JWT Resource Server                |
-| Jackson (Kotlin)              | 3.0.3     | JSON-Serialisierung                |
-
-### 4.6 API & Dokumentation
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| Springdoc OpenAPI             | 3.0.0     | Swagger / OpenAPI 3.1              |
-| Jakarta Annotation            | 3.0.0     | Jakarta EE Annotations             |
-
-### 4.7 Modul-Struktur
-
-```
-backend/
-├── infrastructure/
-│   ├── gateway/               # ✅ API-Gateway (Spring Cloud Gateway)
-│   ├── security/              # ✅ Zentrales OAuth2/JWT-Modul (DRY)
-│   ├── cache/
-│   │   ├── cache-api/         # Interface-Abstraktion
-│   │   └── valkey-impl/       # Valkey-Implementierung
-│   ├── event-store/
-│   │   ├── event-store-api/   # Interface-Abstraktion
-│   │   └── valkey-impl/       # Valkey-Implementierung
-│   ├── persistence/           # Hybrid JPA + Exposed
-│   └── messaging/             # Kafka (Phase 3 / Outbox-Pattern)
-└── services/
-    ├── ping/                  # ✅ Deployed — Test/Blueprint-Service
-    ├── entries/               # ⚙️ Registriert, noch nicht deployed
-    ├── events/                # 👻 Ghost Service (nicht registriert)
-    ├── horses/                # 👻 Ghost Service (nicht registriert)
-    ├── masterdata/            # 👻 Ghost Service (nicht registriert)
-    ├── registry/              # 👻 Ghost Service (nicht registriert)
-    ├── results/               # 👻 Ghost Service (nicht registriert)
-    └── scheduling/            # 👻 Ghost Service (nicht registriert)
-```
-
---
-
-## 5. Infrastruktur-Services (Docker)
-
-### 5.1 Laufende Services
-
-| Service        | Image / Version           | Port(s)       | Zweck                        |
-|:---------------|:--------------------------|:--------------|:-----------------------------|
-| PostgreSQL      | postgres:16-alpine        | 5432          | Primäre Datenbank            |
-| Keycloak        | keycloak:26.4 (custom)    | 8180, 9000    | IAM / OAuth2 / OIDC          |
-| Valkey          | valkey:8-alpine           | 6379          | Cache + Event-Store          |
-| Consul          | consul:1.21               | 8500, 8600    | Service Discovery + Config   |
-| Zipkin          | openzipkin/zipkin:3.5     | 9411          | Distributed Tracing          |
-| Prometheus      | prom/prometheus:v3.4      | 9090          | Metriken-Sammlung            |
-| Grafana         | grafana/grafana:11.6      | 3000          | Dashboards / Visualisierung  |
-| Caddy           | caddy:2.10-alpine         | 4000          | Web-App Serving (Frontend)   |
-| API-Gateway     | (custom Spring Boot)      | 8081          | Zentraler Eintrittspunkt     |
-| Ping-Service    | (custom Spring Boot)      | 8082          | Test/Blueprint-Service       |
-
-### 5.2 CI/CD & DevOps
-
-| Tool            | Version / Details         | Zweck                        |
-|:----------------|:--------------------------|:-----------------------------|
-| Gitea           | Self-Hosted (CT 101)      | Git-Repository + Registry    |
-| Gitea Actions   | (Runner VM 102)           | CI/CD-Pipeline               |
-| Docker Buildx   | ARM64 (linux/arm64)       | Multi-Arch Image Build       |
-| Pangolin        | Self-Hosted Tunnel        | Reverse Proxy / Extern-Zugang|
-
-### 5.3 Netzwerk & Routing
-
-| Subdomain              | Intern (Zora)       | Zweck                    |
-|:-----------------------|:--------------------|:-------------------------|
-| `git.mo-code.at`       | `10.0.0.22:3000`    | Gitea                    |
-| `api.mo-code.at`       | `10.0.0.50:8081`    | API-Gateway              |
-| `auth.mo-code.at`      | `10.0.0.50:8180`    | Keycloak                 |
-| `app.mo-code.at`       | `10.0.0.50:4000`    | Web-App                  |
-| `photos.mo-code.at`    | `10.0.0.24:2283`    | Immich (Fotos)           |
-
---
-
-## 6. Code-Qualität & Build-Tools
-
-| Tool              | Version   | Zweck                              |
-|:------------------|:----------|:-----------------------------------|
-| Detekt            | 1.23.6    | Kotlin Static Analysis             |
-| ktlint            | 12.1.1    | Kotlin Code Formatter              |
-| ArchUnit          | 1.4.1     | Architektur-Tests (Layer-Regeln)   |
-| Dokka             | 2.1.0     | API-Dokumentation (KDoc)           |
-| Ben-Manes Versions| 0.51.0    | Dependency-Update-Check            |
-| KSP               | 2.3.4     | Kotlin Symbol Processing           |
-
-### Build-Konfiguration
-
-```properties
-# gradle.properties
-org.gradle.parallel=true
-org.gradle.caching=true
-org.gradle.workers.max=8
-org.gradle.configuration-cache=false   # wegen JS-Test Serialisierungsproblem
-org.gradle.dependency.verification=strict
-```
-
---
-
-## 7. Test-Stack
-
-| Bibliothek                    | Version   | Zweck                              |
-|:------------------------------|:----------|:-----------------------------------|
-| JUnit Jupiter                 | 5.11.3    | Unit-Tests                         |
-| JUnit Platform                | 1.11.3    | Test-Runner                        |
-| MockK                         | 1.14.7    | Kotlin Mocking                     |
-| AssertJ                       | 3.27.7    | Fluent Assertions                  |
-| Testcontainers                | 2.0.3     | Integration-Tests (Docker)         |
-| Testcontainers Keycloak       | 4.0.1     | Keycloak-Integration-Tests         |
-| Testcontainers PostgreSQL     | 1.21.4    | DB-Integration-Tests               |
-| Testcontainers Kafka          | 1.21.4    | Kafka-Integration-Tests            |
-| ArchUnit                      | 1.4.1     | Architektur-Compliance-Tests       |
-
---
-
-## 8. Architektur-Prinzipien (ADRs)
-
-| ADR   | Entscheidung                                      | Status   |
-|:------|:--------------------------------------------------|:---------|
-| 0001  | Modulare Architektur (DDD, Clean Architecture)    | ✅ Aktiv |
-| 0003  | Microservices-Architektur                         | ✅ Aktiv |
-| 0004  | Event-Driven Communication (Kafka Phase 3)        | ✅ Aktiv |
-| 001   | Backend-Infrastruktur: Hybrid JPA+Exposed, Valkey | ✅ Aktiv |
-| 0013  | Tech-Stack-Stabilisierung 2026 (Versionen)        | ✅ Aktiv |
-
-**Kern-Prinzipien:**
- **Offline-First:** SQLDelight als Cross-Platform-DB, Sync-Mechanismus
- **Docs-as-Code:** `/docs` als Single Source of Truth
- **DRY-Infrastruktur:** Shared Security/Cache/EventStore-Module
- **ARM64-Native:** Alle Images für `linux/arm64` gebaut
-
---
-
-## 9. Relevanz für Self-Hosted AI
-
-### 9.1 Welche AI-Aufgaben entstehen im Projekt?
-
-| Aufgabe                          | Häufigkeit | Komplexität |
-|:---------------------------------|:-----------|:------------|
-| Kotlin/Spring Boot Code-Completion| Täglich    | Mittel      |
-| Compose Multiplatform UI-Code    | Täglich    | Mittel      |
-| SQL / Exposed DSL Queries        | Häufig     | Mittel      |
-| Gradle Kotlin DSL Build-Skripte  | Gelegentlich| Niedrig    |
-| Docker / YAML Konfigurationen    | Gelegentlich| Niedrig    |
-| Architektur-Entscheidungen (ADR) | Selten     | Hoch        |
-| Fachlogik FEI/ÖTO Regelwerk      | Selten     | Sehr hoch   |
-
-### 9.2 Anforderungen an das AI-Modell
-
-```
-MUSS:
-✅ Kotlin (JVM + Multiplatform) — sehr gute Unterstützung
-✅ Spring Boot / Spring Cloud — sehr gute Unterstützung
-✅ Compose Multiplatform — gute Unterstützung (neuere Modelle)
-✅ SQL / PostgreSQL — sehr gute Unterstützung
-✅ Docker / YAML — sehr gute Unterstützung
-✅ Deutsch (Fachsprache Reitsport) — für RAG-Dokumente
-
-NICE-TO-HAVE:
-⭐ Gradle Kotlin DSL
-⭐ Keycloak / OAuth2 / OIDC
-⭐ Microservices-Architektur-Patterns
-```
-
-### 9.3 Empfohlene Modelle für diesen Stack
-
-| Modell                  | Größe  | Stärke                              | RAM-Bedarf |
-|:------------------------|:-------|:------------------------------------|:-----------|
-| `qwen2.5-coder:14b`     | 14B    | Code (Kotlin, Java, SQL) — Top      | ~10 GB     |
-| `deepseek-coder-v2:16b` | 16B    | Code-Completion, Refactoring        | ~12 GB     |
-| `llama3.1:8b`           | 8B     | Allgemein + Deutsch, schnell        | ~6 GB      |
-| `qwen2.5:32b`           | 32B    | Architektur, Planung, Fachlogik     | ~22 GB     |
-| `codellama:13b`         | 13B    | Code-Completion (IntelliJ-Plugin)   | ~9 GB      |
-
-> **Empfehlung für Zora (64 GB RAM):**
-> - **Primär:** `qwen2.5-coder:14b` — bester Kotlin/Spring-Support
-> - **Sekundär:** `qwen2.5:32b` — für Architektur und Fachlogik
-> - **IntelliJ-Integration:** `codellama:13b` oder `qwen2.5-coder:14b`
-
-### 9.4 RAG-Dokumente (Priorität)
-
-Folgende Projekt-Dokumente sind besonders wertvoll als RAG-Kontext:
-
-```
-Hohe Priorität:
-├── docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md
-├── docs/01_Architecture/adr/           (alle ADRs)
-├── docs/04_Agents/Playbooks/           (Agenten-Rollen)
-├── gradle/libs.versions.toml           (Versions-SSoT)
-└── docs/07_Infrastructure/             (Infrastruktur-Referenz)
-
-Mittlere Priorität:
-├── docs/05_Backend/                    (Backend-Guides)
-├── docs/06_Frontend/                   (Frontend-Guides)
-└── docs/03_Domain/                     (Fachlogik-Konzepte)
-```
-
---
-
-## 10. Zusammenfassung
-
-```
-TECH-STACK KOMPLEXITÄT
-──────────────────────────────────────────────────────
-Sprachen:        Kotlin (JVM + KMP/JS)
-Build:           Gradle 9.3.1 + Kotlin DSL + libs.versions.toml
-Frontend:        Compose Multiplatform 1.10 + SQLDelight 2.2 + Koin 4.1
-Backend:         Spring Boot 3.5.9 + Spring Cloud 2025.0.1
-Persistenz:      PostgreSQL 16 + Exposed 1.0 + Flyway 11 + HikariCP 7
-Cache:           Valkey 8 + Lettuce 6.6 + Caffeine 3.2
-Security:        Keycloak 26.4 + Spring Security OAuth2 + JWT
-Observability:   Micrometer 1.16 + Zipkin 3.5 + Prometheus + Grafana 11.6
-Service Mesh:    Consul 1.21 + Spring Cloud Gateway
-Messaging:       Kafka (Phase 3) + Reactor Kafka 1.3
-CI/CD:           Gitea Actions + Docker Buildx (ARM64)
-Hosting:         Proxmox VE 8.4 + Docker Compose + Pangolin-Tunnel
-```
@@ -3,22 +3,26 @@
 ## 🏗️ [Lead Architect] | 14. April 2026

 Dieses Dokument beschreibt die Umsetzung der Online-Nennung für das Turnier in Neumarkt (24. April 2026).
-Ziel ist ein schlankes Web-Formular, das strukturierte E-Mails an den `Mail-Service` sendet, welcher diese verarbeitet und in der Desktop-Zentrale zur manuellen Übernahme bereitstellt.
+Ziel ist ein schlankes Web-Formular, das strukturierte E-Mails an den `Mail-Service` sendet, welcher diese verarbeitet
+und in der Desktop-Zentrale zur manuellen Übernahme bereitstellt.

 ---

 ### Phase 1: E-Mail-Infrastruktur (Vorbereitung) ✅
+
 *   [x] Definition des Adress-Schemas: `meldestelle-[Turnier-Nr]@mo-code.at`.
 *   [x] Konfiguration der World4You SMTP/IMAP Zugangsdaten.
 *   [x] Mailpit Integration für lokale Tests (bereits in `dc-ops.yaml`).

 ### Phase 2: Das Web-Formular (WasmJS Frontend) ✅
+
 *   [x] **Basis-UI:** Erstellung des Formulars gemäß Spezifikation (Reiter, Pferd, Lizenz, Bewerbe).
 *   [x] **Validierung:** Implementierung der Pflichtfeld-Prüfung (Buttonsperre bis alles ok).
 *   [x] **Mail-Versand:** Integration des API-Calls an das Backend (`mail-service`), um die Nennung zu speichern.
 *   [x] **DSGVO:** Checkbox und Hinweistext eingebaut.

 ### Phase 3: Mail-Service (Backend-Verarbeitung) 🏗️
+
 *   [x] **Endpoint:** POST-Endpunkt für direkte Nennungen aus dem Web-Formular implementiert.
 *   [ ] **Polling:** Implementierung des IMAP-Pollers (imap.world4you.com).
 *   [ ] **Parsing:** Extraktion der Turnier-Nummer aus dem `To`-Header und Mapping auf das Datenbank-Schema (Tenant).
@@ -26,12 +30,14 @@ Ziel ist ein schlankes Web-Formular, das strukturierte E-Mails an den `Mail-Serv
 *   [x] **Persistence:** Speichern der eingegangenen "Nennungs-Mails" in einer temporären Tabelle.

 ### Phase 4: Desktop-Zentrale Integration ✅
+
 *   [x] **UI-Tab:** Neuer Reiter "Online-Eingang" in der Turnierverwaltung (`TurnierDetailScreen`).
 *   [x] **Vorschau:** Anzeige der eingegangenen Nennungen mit Details (`OnlineNennungEingangTabContent`).
 *   [x] **Übernahme:** "Übernehmen"-Button, der Reiter/Pferd in die Nennung vorausfüllt (`NennungViewModel`).
 *   [ ] **Abschluss:** Manueller "Bestätigen"-Button zum Versenden der finalen Bestätigungsmail.

 ### Phase 5: End-to-End Test & Deployment 🚀 (Deadline: 21.04.2026)
+
 *   [ ] Test-Nennung über Web-Formular (Mailpit).
 *   [ ] Verifikation der Schema-Zuordnung im Backend.
 *   [ ] Live-Test mit `online-nennen@mo-code.at`.
@@ -40,6 +46,7 @@ Ziel ist ein schlankes Web-Formular, das strukturierte E-Mails an den `Mail-Serv
 ---

 ### Meilensteine
+
 1. **16.04.:** Web-Formular ist funktionsfähig (Senden möglich).
 2. **18.04.:** Mail-Service verarbeitet Mails und sendet Auto-Antworten.
 3. **20.04.:** Desktop-UI zur Übernahme ist fertig.
@@ -10,7 +10,9 @@ last_update: 2026-03-25
 10. **🏗️ [Lead Architect]** | 5. April 2026

 **Kontext:**
-Der ZNS-Importer wurde für die Verarbeitung der Datei `RICHT01.dat` optimiert. Es wurde klargestellt, dass Richter (SatzID 'X') und Parcoursbauer (SatzID 'Y') gemeinsam in dieser Datei geliefert werden. Eine separate `PARCO01.dat` existiert nicht.
+Der ZNS-Importer wurde für die Verarbeitung der Datei `RICHT01.dat` optimiert. Es wurde klargestellt, dass Richter (
+SatzID 'X') und Parcoursbauer (SatzID 'Y') gemeinsam in dieser Datei geliefert werden. Eine separate `PARCO01.dat`
+existiert nicht.
 Um den `registration-context` und `actor-context` unter realistischen Bedingungen testen zu können, benötigen wir echte
 Stammdaten (Reiter, Pferde, Vereine, Funktionäre). Diese Daten werden vom ÖPS (Österreichischer Pferdesportverband) in
 Form einer `ZNS.zip` bereitgestellt.
@@ -51,7 +53,8 @@ gesteuert wird und die Daten persistent im Backend (`actor-context`) ablegt.
  * ZIP-Entpackung in-memory implementiert (`ZnsImportService`).
 *   [x] **Legacy-Parser (CP850 Fixed-Width):**
  * `ZnsLegacyParsers` in `core:zns-parser` (KMP-Modul) implementiert.
-  * Alle 4 Dateitypen (VEREIN01, LIZENZ01, PFERDE01, RICHT01) bytegenau gemappt. RICHT01 verarbeitet Richter ('X') und Parcoursbauer ('Y'). ✅
+  * Alle 4 Dateitypen (VEREIN01, LIZENZ01, PFERDE01, RICHT01) bytegenau gemappt. RICHT01 verarbeitet Richter ('X') und
+    Parcoursbauer ('Y'). ✅

 ### Phase 2: Domain-Mapping & Persistenz (👷 Backend Developer)

@@ -0,0 +1,89 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+last_update: 2026-03-15
+---
+
+# Frontend-Architektur & Modularisierungsstrategie
+
+**Status:** ENTWURF
+**Zuletzt aktualisiert:** 2026-01-19
+**Kontext:** Migration zu Clean Architecture & Feature-Modulen
+
+---
+
+## 1. Übersicht
+
+Die Frontend-Architektur von **Meldestelle** basiert auf **Kotlin Multiplatform (KMP)** mit **Compose Multiplatform**
+für die Benutzeroberfläche. Wir folgen einem strikten **Clean Architecture**-Ansatz, um Testbarkeit, Skalierbarkeit und
+Trennung der Zuständigkeiten sicherzustellen.
+
+## 2. Modulstruktur
+
+Das Projekt ist in folgende Schichten unterteilt:
+
+### 2.1 Core-Module (`frontend/core`)
+
+Wiederverwendbare Komponenten, die unabhängig von spezifischen Geschäftsfunktionen sind.
+
+* `core-network`: Zentrale HTTP-Client-Konfiguration (Auth, Logging, ContentNegotiation).
+* `core-sync`: Generische Synchronisierungslogik (`SyncManager`, `SyncableRepository`).
+* `core-ui`: Gemeinsame UI-Komponenten und Design-System.
+
+### 2.2 Feature-Module (`frontend/features`)
+
+Jede Geschäftsdomäne (z.B. `ping`, `auth`, `events`) liegt in ihrem eigenen Modul.
+Ein Feature-Modul MUSS die **Clean Architecture** Paketstruktur einhalten:
+
+* `at.mocode.{feature}.feature.domain`
+  * **Entitäten:** Reine Datenklassen.
+  * **Interfaces:** Repository-Interfaces, Service-Interfaces.
+  * **Use Cases:** Geschäftslogik (optional, für komplexe Logik).
+* `at.mocode.{feature}.feature.data`
+  * **Implementierungen:** Repository-Implementierungen, API-Clients.
+  * **DTOs:** Data Transfer Objects (wenn von Domain-Entitäten abweichend).
+* `at.mocode.{feature}.feature.presentation`
+  * **ViewModels:** Zustandsverwaltung.
+  * **Screens:** Composable-Funktionen.
+* `at.mocode.{feature}.feature.di`
+  * **Koin-Modul:** Konfiguration der Dependency Injection.
+
+### 2.3 Shells (`frontend/shells`)
+
+Anwendungs-Einstiegspunkte, die alles zusammenführen.
+
+* `meldestelle-portal`: Die Haupt-Web-/Desktop-Anwendung.
+
+## 3. Migrationsstrategie (Übergangsphase)
+
+Wir migrieren aktuell von einer monolithischen `clients`-Paketstruktur zu modularen Feature-Modulen.
+
+**Regeln für die Migration:**
+
+1. **Neue Features:** Müssen direkt in `frontend/features/{name}` unter Verwendung der Clean Architecture-Struktur
+   implementiert werden.
+2. **Bestehende Features:** Werden schrittweise migriert.
+3. **Koexistenz:** Während des Übergangs ist Legacy-Code in `clients/` erlaubt, aber als veraltet markiert.
+4. **Dependency Injection:** Legacy-Code muss die neuen Koin-Module verwenden, sofern verfügbar.
+5. **Keine Ghost-Klassen:** Klassen nicht duplizieren. Wenn eine Klasse in ein Feature-Modul verschoben wird, muss die
+   alte in `clients/` gelöscht werden.
+
+## 4. Wichtige Entscheidungen (ADRs)
+
+### ADR-001: Entkopplung der Sync-Logik
+
+* **Entscheidung:** ViewModels dürfen nicht direkt vom `SyncManager` abhängen.
+* **Begründung:** Um einfacheres Testen zu ermöglichen und die Komplexität des generischen Sync-Mechanismus zu
+  verbergen.
+* **Umsetzung:** Ein Domain-Service-Interface (z.B. `PingSyncService`) einführen, das den `SyncManager`-Aufruf kapselt.
+
+### ADR-002: Feature-Modul-Isolation
+
+* **Entscheidung:** Feature-Module sollten nach Möglichkeit nicht direkt voneinander abhängen.
+* **Kommunikation:** Gemeinsame Core-Module oder lose Kopplung über Interfaces/Events verwenden, wenn modulübergreifende
+  Kommunikation nötig ist.
+
+---
+
+**Freigegeben von:** Lead Architect
@@ -3,11 +3,15 @@ type: Reference
 status: ACTIVE
 owner: Lead Architect
 ---
+
 # Architektur: Das Platform-Modul

 ## Überblick

-Das **Platform-Modul** ist das Rückgrat der Build-Infrastruktur des Meldestelle-Projekts. Seine alleinige Aufgabe ist die zentrale Verwaltung und Bereitstellung von Abhängigkeiten und deren Versionen. Dies stellt sicher, dass alle Module im gesamten Projekt dieselben Bibliotheksversionen verwenden, was Inkonsistenzen ("JAR Hell") verhindert und die Wartbarkeit drastisch verbessert.
+Das **Platform-Modul** ist das Rückgrat der Build-Infrastruktur des Meldestelle-Projekts. Seine alleinige Aufgabe ist
+die zentrale Verwaltung und Bereitstellung von Abhängigkeiten und deren Versionen. Dies stellt sicher, dass alle Module
+im gesamten Projekt dieselben Bibliotheksversionen verwenden, was Inkonsistenzen ("JAR Hell") verhindert und die
+Wartbarkeit drastisch verbessert.

 Das Modul agiert als eine interne "Single Source of Truth" für alle externen Bibliotheken.

@@ -24,19 +28,23 @@ platform/

 ### `platform-bom`

-Dies ist das wichtigste Modul der Plattform. Es ist als "Bill of Materials" (BOM) konfiguriert und nutzt das `java-platform`-Plugin von Gradle.
+Dies ist das wichtigste Modul der Plattform. Es ist als "Bill of Materials" (BOM) konfiguriert und nutzt das
+`java-platform`-Plugin von Gradle.

-* **Zweck:** Definiert eine umfassende Liste von Abhängigkeiten und deren exakten, geprüften Versionen. Es importiert auch andere wichtige BOMs (z.B. von Spring Boot und Kotlin).
-* **Funktionsweise:** Andere Module importieren diese BOM mit `platform(projects.platform.platformBom)`. Gradle sorgt dann dafür, dass alle transitiven und deklarierten Abhängigkeiten den in der BOM festgelegten Versionen entsprechen.
+* **Zweck:** Definiert eine umfassende Liste von Abhängigkeiten und deren exakten, geprüften Versionen. Es importiert
+  auch andere wichtige BOMs (z.B. von Spring Boot und Kotlin).
+* **Funktionsweise:** Andere Module importieren diese BOM mit `platform(projects.platform.platformBom)`. Gradle sorgt
+  dann dafür, dass alle transitiven und deklarierten Abhängigkeiten den in der BOM festgelegten Versionen entsprechen.
 * **Vorteil:** Absolute Versionskontrolle über das gesamte Projekt.

 ### `platform-dependencies`

 Ein einfaches "Sammelmodul", das die am häufigsten benötigten Laufzeit-Abhängigkeiten bündelt.

-* **Zweck:** Vereinfacht die `build.gradle.kts`-Dateien der Service-Module. Anstatt 5-6 einzelne `kotlinx`- und Logging-Bibliotheken hinzuzufügen, genügt eine einzige Abhängigkeit zu diesem Modul.
+* **Zweck:** Vereinfacht die `build.gradle.kts`-Dateien der Service-Module. Anstatt 5-6 einzelne `kotlinx`- und
+  Logging-Bibliotheken hinzuzufügen, genügt eine einzige Abhängigkeit zu diesem Modul.
 * **Verwendung:**
-
+  
    ```kotlin
    // In einem Service-Modul
    dependencies {
@@ -48,9 +56,10 @@ Ein einfaches "Sammelmodul", das die am häufigsten benötigten Laufzeit-Abhäng

 Analog zu `platform-dependencies`, aber speziell für Test-Bibliotheken.

-* **Zweck:** Stellt ein konsistentes Set an Test-Frameworks (JUnit 5, MockK, AssertJ) und Werkzeugen (Testcontainers) für alle Module bereit.
+* **Zweck:** Stellt ein konsistentes Set an Test-Frameworks (JUnit 5, MockK, AssertJ) und Werkzeugen (Testcontainers)
+  für alle Module bereit.
 * **Verwendung:**
-
+  
    ```kotlin
    // In einem Service-Modul
    dependencies {
@@ -58,4 +67,5 @@ Analog zu `platform-dependencies`, aber speziell für Test-Bibliotheken.
    }
    ```

-* **Optimierung:** Dieses Modul nutzt die in `libs.versions.toml` definierten `[bundles]`, um die Build-Datei extrem kurz und lesbar zu halten.
+* **Optimierung:** Dieses Modul nutzt die in `libs.versions.toml` definierten `[bundles]`, um die Build-Datei extrem
+  kurz und lesbar zu halten.
@@ -0,0 +1,362 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+date: 2026-03-07
+---
+
+# Meldestelle — Tech-Stack Zusammenfassung
+
+> **Zweck:** Vollständige Referenz des eingesetzten Tech-Stacks im Projekt "Meldestelle".
+> Dient als Basis für Recherchen zu Self-Hosted AI (Codegenerierung, RAG, Agenten).
+> **Stand:** 07. März 2026
+
+---
+
+## 1. Überblick
+
+Das Projekt "Meldestelle" ist eine **Kotlin-first, Cloud-native Microservices-Plattform** für die Verwaltung von
+Reitsport-Meldungen (FEI / ÖTO). Es kombiniert ein **Kotlin Multiplatform (KMP) Frontend** mit einem **Spring Boot
+Microservices Backend** auf einer vollständig self-hosted Infrastruktur.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│  Frontend (KMP)          │  Backend (Spring Boot / Kotlin JVM)  │
+│  Kotlin 2.3 / Compose    │  Java 25 / Spring Boot 3.5.9         │
+│  JS + WASM (geplant)     │  Microservices + API-Gateway          │
+├─────────────────────────────────────────────────────────────────┤
+│  Infrastruktur (Self-Hosted auf Zora / Proxmox)                 │
+│  Keycloak · Consul · Valkey · PostgreSQL · Zipkin               │
+│  Prometheus · Grafana · Caddy · Pangolin-Tunnel                 │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 2. Sprachen & Laufzeiten
+
+| Komponente | Sprache / Runtime      | Version |
+|:-----------|:-----------------------|:--------|
+| Backend    | Kotlin (JVM)           | 2.3.0   |
+| Frontend   | Kotlin (KMP / JS)      | 2.3.0   |
+| JVM        | Java (Eclipse Temurin) | 25 (EA) |
+| Build      | Gradle (Kotlin DSL)    | 9.3.1   |
+| Plattform  | ARM64 (AArch64)        | Linux   |
+
+---
+
+## 3. Frontend — Kotlin Multiplatform (KMP)
+
+### 3.1 Core-Framework
+
+| Bibliothek            | Version | Zweck                            |
+|:----------------------|:--------|:---------------------------------|
+| Kotlin Multiplatform  | 2.3.0   | Cross-Platform-Basis (JS + WASM) |
+| Compose Multiplatform | 1.10.0  | UI-Framework (Deklarativ)        |
+| Compose Hot Reload    | 1.0.0   | Live-Reload im Dev-Modus         |
+| Koin (DI)             | 4.1.1   | Dependency Injection             |
+| Koin Compose          | 4.1.1   | DI-Integration für Compose       |
+| Ktor Client           | 3.4.0   | HTTP-Client (Multiplatform)      |
+| Kotlin Serialization  | 2.3.0   | JSON-Serialisierung              |
+
+### 3.2 Persistenz (Offline-First)
+
+| Bibliothek      | Version | Zweck                        |
+|:----------------|:--------|:-----------------------------|
+| SQLDelight      | 2.2.1   | Cross-Platform SQL-Datenbank |
+| SQLite (WASM)   | 3.51.1  | SQLite für Browser/WASM      |
+| SQLite (Native) | 2.6.2   | SQLite für JVM/Desktop       |
+
+### 3.3 Build-Targets
+
+| Target        | Status     | Anmerkung                 |
+|:--------------|:-----------|:--------------------------|
+| KotlinJS      | ✅ Aktiv    | Primäres Build-Target     |
+| WASM          | ⏳ Geplant  | Warten auf Alpha-Version  |
+| Desktop (JVM) | ⚙️ Möglich | uiDesktop 1.7.0 vorhanden |
+
+### 3.4 Modul-Struktur
+
+```
+frontend/
+├── core/
+│   ├── core-network/          # Ktor HTTP-Client, Auth-Interceptor
+│   ├── core-ui/               # Design-System, Tokens, Komponenten
+│   ├── core-domain/           # Shared Domain-Models
+│   └── core-data/             # Repository-Interfaces
+├── features/
+│   ├── ping-feature/          # ✅ Blueprint: MVVM + Repository + DI + Tests
+│   └── members-feature/       # ⏳ Auskommentiert (nächste Phase)
+└── shells/
+    └── meldestelle-portal/    # Web-App Shell (Caddy-served)
+```
+
+---
+
+## 4. Backend — Spring Boot Microservices
+
+### 4.1 Core-Framework
+
+| Bibliothek               | Version  | Zweck                            |
+|:-------------------------|:---------|:---------------------------------|
+| Spring Boot              | 3.5.9    | Microservices-Framework          |
+| Spring Cloud             | 2025.0.1 | Service Discovery, Config        |
+| Spring Security (OAuth2) | (Boot)   | JWT-Validierung, Resource Server |
+| Spring Data JPA          | (Boot)   | ORM-Layer                        |
+| Spring Data Valkey       | 0.2.0    | Cache-Integration (Valkey/Redis) |
+| Spring WebFlux           | (Boot)   | Reaktive API (Gateway)           |
+| Kotlin Coroutines        | 2.3.0    | Async/Non-blocking               |
+
+### 4.2 Persistenz
+
+| Bibliothek          | Version | Zweck                 |
+|:--------------------|:--------|:----------------------|
+| PostgreSQL Driver   | 42.7.8  | JDBC-Treiber          |
+| Exposed (JetBrains) | 1.0.0   | Kotlin-native SQL DSL |
+| Flyway              | 11.19.1 | Datenbank-Migrationen |
+| HikariCP            | 7.0.2   | Connection Pool       |
+
+> **Strategie (ADR-001):** Hybrid — JPA für einfache CRUD-Entities, Exposed für komplexe Queries und Domain-Logik.
+
+### 4.3 Caching & Messaging
+
+| Bibliothek    | Version | Zweck                           |
+|:--------------|:--------|:--------------------------------|
+| Lettuce       | 6.6.0   | Valkey/Redis-Client (reaktiv)   |
+| Redisson      | 4.0.0   | Distributed Locks, Pub/Sub      |
+| Caffeine      | 3.2.3   | In-Memory Cache (L1)            |
+| Reactor Kafka | 1.3.23  | Kafka-Client (Phase 3 / Outbox) |
+
+### 4.4 Observability & Tracing
+
+| Bibliothek         | Version | Zweck                        |
+|:-------------------|:--------|:-----------------------------|
+| Micrometer         | 1.16.1  | Metriken (Prometheus-Export) |
+| Micrometer Tracing | 1.6.1   | Distributed Tracing          |
+| Zipkin Reporter    | 3.5.1   | Trace-Export zu Zipkin       |
+| Logback            | 1.5.25  | Logging                      |
+
+### 4.5 Security
+
+| Bibliothek             | Version | Zweck                    |
+|:-----------------------|:--------|:-------------------------|
+| Keycloak Admin Client  | 26.0.7  | Keycloak-API-Integration |
+| Spring Security OAuth2 | (Boot)  | JWT Resource Server      |
+| Jackson (Kotlin)       | 3.0.3   | JSON-Serialisierung      |
+
+### 4.6 API & Dokumentation
+
+| Bibliothek         | Version | Zweck                  |
+|:-------------------|:--------|:-----------------------|
+| Springdoc OpenAPI  | 3.0.0   | Swagger / OpenAPI 3.1  |
+| Jakarta Annotation | 3.0.0   | Jakarta EE Annotations |
+
+### 4.7 Modul-Struktur
+
+```
+backend/
+├── infrastructure/
+│   ├── gateway/               # ✅ API-Gateway (Spring Cloud Gateway)
+│   ├── security/              # ✅ Zentrales OAuth2/JWT-Modul (DRY)
+│   ├── cache/
+│   │   ├── cache-api/         # Interface-Abstraktion
+│   │   └── valkey-impl/       # Valkey-Implementierung
+│   ├── event-store/
+│   │   ├── event-store-api/   # Interface-Abstraktion
+│   │   └── valkey-impl/       # Valkey-Implementierung
+│   ├── persistence/           # Hybrid JPA + Exposed
+│   └── messaging/             # Kafka (Phase 3 / Outbox-Pattern)
+└── services/
+    ├── ping/                  # ✅ Deployed — Test/Blueprint-Service
+    ├── entries/               # ⚙️ Registriert, noch nicht deployed
+    ├── events/                # 👻 Ghost Service (nicht registriert)
+    ├── horses/                # 👻 Ghost Service (nicht registriert)
+    ├── masterdata/            # 👻 Ghost Service (nicht registriert)
+    ├── registry/              # 👻 Ghost Service (nicht registriert)
+    ├── results/               # 👻 Ghost Service (nicht registriert)
+    └── scheduling/            # 👻 Ghost Service (nicht registriert)
+```
+
+---
+
+## 5. Infrastruktur-Services (Docker)
+
+### 5.1 Laufende Services
+
+| Service      | Image / Version        | Port(s)    | Zweck                       |
+|:-------------|:-----------------------|:-----------|:----------------------------|
+| PostgreSQL   | postgres:16-alpine     | 5432       | Primäre Datenbank           |
+| Keycloak     | keycloak:26.4 (custom) | 8180, 9000 | IAM / OAuth2 / OIDC         |
+| Valkey       | valkey:8-alpine        | 6379       | Cache + Event-Store         |
+| Consul       | consul:1.21            | 8500, 8600 | Service Discovery + Config  |
+| Zipkin       | openzipkin/zipkin:3.5  | 9411       | Distributed Tracing         |
+| Prometheus   | prom/prometheus:v3.4   | 9090       | Metriken-Sammlung           |
+| Grafana      | grafana/grafana:11.6   | 3000       | Dashboards / Visualisierung |
+| Caddy        | caddy:2.10-alpine      | 4000       | Web-App Serving (Frontend)  |
+| API-Gateway  | (custom Spring Boot)   | 8081       | Zentraler Eintrittspunkt    |
+| Ping-Service | (custom Spring Boot)   | 8082       | Test/Blueprint-Service      |
+
+### 5.2 CI/CD & DevOps
+
+| Tool          | Version / Details    | Zweck                         |
+|:--------------|:---------------------|:------------------------------|
+| Gitea         | Self-Hosted (CT 101) | Git-Repository + Registry     |
+| Gitea Actions | (Runner VM 102)      | CI/CD-Pipeline                |
+| Docker Buildx | ARM64 (linux/arm64)  | Multi-Arch Image Build        |
+| Pangolin      | Self-Hosted Tunnel   | Reverse Proxy / Extern-Zugang |
+
+### 5.3 Netzwerk & Routing
+
+| Subdomain           | Intern (Zora)    | Zweck          |
+|:--------------------|:-----------------|:---------------|
+| `git.mo-code.at`    | `10.0.0.22:3000` | Gitea          |
+| `api.mo-code.at`    | `10.0.0.50:8081` | API-Gateway    |
+| `auth.mo-code.at`   | `10.0.0.50:8180` | Keycloak       |
+| `app.mo-code.at`    | `10.0.0.50:4000` | Web-App        |
+| `photos.mo-code.at` | `10.0.0.24:2283` | Immich (Fotos) |
+
+---
+
+## 6. Code-Qualität & Build-Tools
+
+| Tool               | Version | Zweck                            |
+|:-------------------|:--------|:---------------------------------|
+| Detekt             | 1.23.6  | Kotlin Static Analysis           |
+| ktlint             | 12.1.1  | Kotlin Code Formatter            |
+| ArchUnit           | 1.4.1   | Architektur-Tests (Layer-Regeln) |
+| Dokka              | 2.1.0   | API-Dokumentation (KDoc)         |
+| Ben-Manes Versions | 0.51.0  | Dependency-Update-Check          |
+| KSP                | 2.3.4   | Kotlin Symbol Processing         |
+
+### Build-Konfiguration
+
+```properties
+# gradle.properties
+org.gradle.parallel=true
+org.gradle.caching=true
+org.gradle.workers.max=8
+org.gradle.configuration-cache=false   # wegen JS-Test Serialisierungsproblem
+org.gradle.dependency.verification=strict
+```
+
+---
+
+## 7. Test-Stack
+
+| Bibliothek                | Version | Zweck                        |
+|:--------------------------|:--------|:-----------------------------|
+| JUnit Jupiter             | 5.11.3  | Unit-Tests                   |
+| JUnit Platform            | 1.11.3  | Test-Runner                  |
+| MockK                     | 1.14.7  | Kotlin Mocking               |
+| AssertJ                   | 3.27.7  | Fluent Assertions            |
+| Testcontainers            | 2.0.3   | Integration-Tests (Docker)   |
+| Testcontainers Keycloak   | 4.0.1   | Keycloak-Integration-Tests   |
+| Testcontainers PostgreSQL | 1.21.4  | DB-Integration-Tests         |
+| Testcontainers Kafka      | 1.21.4  | Kafka-Integration-Tests      |
+| ArchUnit                  | 1.4.1   | Architektur-Compliance-Tests |
+
+---
+
+## 8. Architektur-Prinzipien (ADRs)
+
+| ADR  | Entscheidung                                      | Status  |
+|:-----|:--------------------------------------------------|:--------|
+| 0001 | Modulare Architektur (DDD, Clean Architecture)    | ✅ Aktiv |
+| 0003 | Microservices-Architektur                         | ✅ Aktiv |
+| 0004 | Event-Driven Communication (Kafka Phase 3)        | ✅ Aktiv |
+| 001  | Backend-Infrastruktur: Hybrid JPA+Exposed, Valkey | ✅ Aktiv |
+| 0013 | Tech-Stack-Stabilisierung 2026 (Versionen)        | ✅ Aktiv |
+
+**Kern-Prinzipien:**
+
+- **Offline-First:** SQLDelight als Cross-Platform-DB, Sync-Mechanismus
+- **Docs-as-Code:** `/docs` als Single Source of Truth
+- **DRY-Infrastruktur:** Shared Security/Cache/EventStore-Module
+- **ARM64-Native:** Alle Images für `linux/arm64` gebaut
+
+---
+
+## 9. Relevanz für Self-Hosted AI
+
+### 9.1 Welche AI-Aufgaben entstehen im Projekt?
+
+| Aufgabe                            | Häufigkeit   | Komplexität |
+|:-----------------------------------|:-------------|:------------|
+| Kotlin/Spring Boot Code-Completion | Täglich      | Mittel      |
+| Compose Multiplatform UI-Code      | Täglich      | Mittel      |
+| SQL / Exposed DSL Queries          | Häufig       | Mittel      |
+| Gradle Kotlin DSL Build-Skripte    | Gelegentlich | Niedrig     |
+| Docker / YAML Konfigurationen      | Gelegentlich | Niedrig     |
+| Architektur-Entscheidungen (ADR)   | Selten       | Hoch        |
+| Fachlogik FEI/ÖTO Regelwerk        | Selten       | Sehr hoch   |
+
+### 9.2 Anforderungen an das AI-Modell
+
+```
+MUSS:
+✅ Kotlin (JVM + Multiplatform) — sehr gute Unterstützung
+✅ Spring Boot / Spring Cloud — sehr gute Unterstützung
+✅ Compose Multiplatform — gute Unterstützung (neuere Modelle)
+✅ SQL / PostgreSQL — sehr gute Unterstützung
+✅ Docker / YAML — sehr gute Unterstützung
+✅ Deutsch (Fachsprache Reitsport) — für RAG-Dokumente
+
+NICE-TO-HAVE:
+⭐ Gradle Kotlin DSL
+⭐ Keycloak / OAuth2 / OIDC
+⭐ Microservices-Architektur-Patterns
+```
+
+### 9.3 Empfohlene Modelle für diesen Stack
+
+| Modell                  | Größe | Stärke                            | RAM-Bedarf |
+|:------------------------|:------|:----------------------------------|:-----------|
+| `qwen2.5-coder:14b`     | 14B   | Code (Kotlin, Java, SQL) — Top    | ~10 GB     |
+| `deepseek-coder-v2:16b` | 16B   | Code-Completion, Refactoring      | ~12 GB     |
+| `llama3.1:8b`           | 8B    | Allgemein + Deutsch, schnell      | ~6 GB      |
+| `qwen2.5:32b`           | 32B   | Architektur, Planung, Fachlogik   | ~22 GB     |
+| `codellama:13b`         | 13B   | Code-Completion (IntelliJ-Plugin) | ~9 GB      |
+
+> **Empfehlung für Zora (64 GB RAM):**
+> - **Primär:** `qwen2.5-coder:14b` — bester Kotlin/Spring-Support
+> - **Sekundär:** `qwen2.5:32b` — für Architektur und Fachlogik
+> - **IntelliJ-Integration:** `codellama:13b` oder `qwen2.5-coder:14b`
+
+### 9.4 RAG-Dokumente (Priorität)
+
+Folgende Projekt-Dokumente sind besonders wertvoll als RAG-Kontext:
+
+```
+Hohe Priorität:
+├── docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md
+├── docs/01_Architecture/adr/           (alle ADRs)
+├── docs/04_Agents/Playbooks/           (Agenten-Rollen)
+├── gradle/libs.versions.toml           (Versions-SSoT)
+└── docs/07_Infrastructure/             (Infrastruktur-Referenz)
+
+Mittlere Priorität:
+├── docs/05_Backend/                    (Backend-Guides)
+├── docs/06_Frontend/                   (Frontend-Guides)
+└── docs/03_Domain/                     (Fachlogik-Konzepte)
+```
+
+---
+
+## 10. Zusammenfassung
+
+```
+TECH-STACK KOMPLEXITÄT
+──────────────────────────────────────────────────────
+Sprachen:        Kotlin (JVM + KMP/JS)
+Build:           Gradle 9.3.1 + Kotlin DSL + libs.versions.toml
+Frontend:        Compose Multiplatform 1.10 + SQLDelight 2.2 + Koin 4.1
+Backend:         Spring Boot 3.5.9 + Spring Cloud 2025.0.1
+Persistenz:      PostgreSQL 16 + Exposed 1.0 + Flyway 11 + HikariCP 7
+Cache:           Valkey 8 + Lettuce 6.6 + Caffeine 3.2
+Security:        Keycloak 26.4 + Spring Security OAuth2 + JWT
+Observability:   Micrometer 1.16 + Zipkin 3.5 + Prometheus + Grafana 11.6
+Service Mesh:    Consul 1.21 + Spring Cloud Gateway
+Messaging:       Kafka (Phase 3) + Reactor Kafka 1.3
+CI/CD:           Gitea Actions + Docker Buildx (ARM64)
+Hosting:         Proxmox VE 8.4 + Docker Compose + Pangolin-Tunnel
+```
@@ -10,23 +10,27 @@ Cups/Serien.
 ## 1) Fokus-Themen und Deliverables (heute Nacht)

 1. Reporting & Output (Vorbereitung)
-  - [Owner] Vorlagen sammeln/übermitteln: Startlisten, Ergebnislisten (PDF/Scan/Excel)
-  - [Owner] Spring-Protokolle: Inhalte/Felder definieren (Fehler, Zeit, Stechen)
-  - [Owner] Dressur-Protokolle: Vorlage für personalisierten Ausdruck (Kopfzeile Reiter/Pferd)
-  - [Arch/BE] Technik-Entscheidung PDF: KMP-Library vs. Server-Side Rendering (ADR-Entwurf)
-  - [FE] UI-Draft „Druckvorschau“ in V2-Screens: Platzhalter mit Beispiel-Daten
+
+- [Owner] Vorlagen sammeln/übermitteln: Startlisten, Ergebnislisten (PDF/Scan/Excel)
+- [Owner] Spring-Protokolle: Inhalte/Felder definieren (Fehler, Zeit, Stechen)
+- [Owner] Dressur-Protokolle: Vorlage für personalisierten Ausdruck (Kopfzeile Reiter/Pferd)
+- [Arch/BE] Technik-Entscheidung PDF: KMP-Library vs. Server-Side Rendering (ADR-Entwurf)
+- [FE] UI-Draft „Druckvorschau“ in V2-Screens: Platzhalter mit Beispiel-Daten

 2. Events/Turniere (Backend-Readiness für Neumarkt)
-  - [BE] DB-Migrationen finalisieren: `turniere`, `ausschreibungen` (Flyway)
-  - [BE] Seed-Datensatz „Veranstaltung Neumarkt 2026“ (+ 1–2 Turniere)
-  - [BE] Repositories prüfen und Test-Cases anlegen (Roundtrip CRUD)
+
+- [BE] DB-Migrationen finalisieren: `turniere`, `ausschreibungen` (Flyway)
+- [BE] Seed-Datensatz „Veranstaltung Neumarkt 2026“ (+ 1–2 Turniere)
+- [BE] Repositories prüfen und Test-Cases anlegen (Roundtrip CRUD)

 3. Identity & Profil (Verifikation)
-  - [QA] E2E-Check „ZNS-Link“: Login → Profile → Satznummer verknüpfen → Refresh
-  - [FE] Validation/UX-Polish im `profile-feature`
+
+- [QA] E2E-Check „ZNS-Link“: Login → Profile → Satznummer verknüpfen → Refresh
+- [FE] Validation/UX-Polish im `profile-feature`

 4. Live-Ergebnisse – Vision (Input sammeln)
-  - [Owner] Skizze/Mock für mobile Web-Ansicht (Zuschauer): Bewerb → Abteilungen → Live-Board
+
+- [Owner] Skizze/Mock für mobile Web-Ansicht (Zuschauer): Bewerb → Abteilungen → Live-Board

 ---

@@ -0,0 +1,22 @@
+# ADR-0025: "Plan-USB" & Offline-Datenintegrität
+
+## Status
+In Prüfung (Wartet auf PoC)
+
+## Kontext
+Im professionellen Turniersport ist eine stabile Netzwerkverbindung (LAN/WLAN) nicht immer garantiert. Ein Ausfall des Netzwerks darf den laufenden Betrieb (Ergebniserfassung, Meldestelle) nicht blockieren. Zudem müssen sensible Reiter- und Pferdedaten (DSGVO) auch auf physischen Datenträgern geschützt sein.
+
+## Entscheidung
+Wir führen die "Plan-USB" Strategie als primären Fallback und parallelen Sicherungsmechanismus ein.
+
+1. **Permanenter Delta-Export:** Der Master-PC schreibt kontinuierlich verschlüsselte Delta-Pakete (JSON-basiert) in ein definiertes Backup-Verzeichnis. Dies ist bereits in der UI als Pfad-Option vorbereitet.
+2. **Verschlüsselung:** Alle Daten auf dem USB-Stick werden mit dem `Shared Key` (AES-256) verschlüsselt. Der Benutzer legt diesen Schlüssel einmalig während der Initialisierung fest.
+3. **Datenintegrität:** Pakete werden signiert, um Manipulationen durch Texteditoren zu verhindern.
+4. **Sync-Vorschau:** Die UI bietet eine visuelle Bestätigung ("Sync-Dashboard"), welche Daten zuletzt erfolgreich auf den Stick geschrieben wurden. (Umgesetzt im UI-Design der Initialisierung).
+5. **Manueller Not-Import:** Clients erhalten eine Funktion, um Delta-Pakete manuell von einem Stick einzulesen und eigene Ergebnisse dorthin zurückzuschreiben.
+
+## Konsequenzen
+- Erhöhte Komplexität in der Sync-Logik (Hybrid-Modus: Netzwerk + Datei).
+- Benutzer muss initial einen `Shared Key` festlegen.
+- Rechtliche Absicherung bei Verlust von Hardware durch Verschlüsselung.
+- Maximale Ausfallsicherheit: Das Turnier kann rein via USB-Stick ("Turnschuh-Netzwerk") zu Ende geführt werden.
@@ -0,0 +1,23 @@
+# ADR-0026: Offline-Lizenzierung ("Pay-per-Event")
+
+## Status
+Vorgeschlagen
+
+## Kontext
+Die Software wird als Service pro Veranstaltung lizenziert. Da die App primär offline betrieben wird (Meldestelle am Turnierplatz), kann keine permanente Online-Verbindung zur Lizenzprüfung vorausgesetzt werden.
+
+## Entscheidung
+Wir implementieren ein ticketbasiertes Offline-Lizenzmodell.
+
+1. **Online-Erwerb:** Der Veranstalter kauft ein "Event-Ticket" über das zentrale Web-Backend.
+2. **Lizenz-Datei:** Das Backend generiert eine digital signierte Lizenz-Datei (`.mlic`). Diese enthält:
+   - Veranstalter-Identität (OEPS-Nummer).
+   - Gültigkeitszeitraum (Von-Bis).
+   - Event-Typ (z.B. CSN-B*).
+3. **Offline-Aktivierung:** Im `EventWizard` der Desktop-App wird die Lizenz-Datei hochgeladen. Die App validiert die Signatur gegen unseren Public-Key (völlig offline).
+4. **Hardware-Fingerprint:** Die Lizenz wird beim ersten Import an die Hardware-ID des Master-PCs gebunden, um unkontrollierte Vervielfältigung zu verhindern.
+
+## Konsequenzen
+- Benutzer muss einmalig (vor dem Turnier) Internetzugang haben, um die Lizenzdatei herunterzuladen.
+- Keine Abhängigkeit von Server-Verfügbarkeit während des Turniers.
+- Sicherer Schutz unseres Geschäftsmodells ohne Gängelung des ehrlichen Nutzers.
@@ -0,0 +1,33 @@
+# ADR-0027: Netzwerk-Discovery & Interface-Binding
+
+## Status
+
+Akzeptiert & Implementiert (05.05.2026)
+
+## Kontext
+
+Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das
+Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (mDNS) wählen ohne explizite Konfiguration
+oft ein Interface, das für die anderen Teilnehmer nicht erreichbar ist (Bridging-Probleme zwischen LAN und WLAN). Zudem
+blockieren einige Router Multicast-Pakete zwischen WLAN und LAN-Segmenten.
+
+## Entscheidung
+
+Wir führen ein robustes, mehrstufiges Netzwerk-Management für die Initialisierung ein:
+
+1. **Multi-Interface Broadcast:** Der Master registriert seinen Dienst proaktiv auf **allen** verfügbaren
+   Netzwerk-Interfaces (IPv4). Dies erhöht die Chance massiv, dass Clients in verschiedenen Segmenten (WLAN/LAN) den
+   Master finden.
+2. **Interface-Selektion:** Der Benutzer kann weiterhin ein bevorzugtes Interface wählen. Die Master-Info-Card zeigt die
+   Erreichbarkeit transparent an.
+3. **Manueller IP-Fallback:** Wenn mDNS fehlschlägt, kann die IP des Masters manuell eingegeben werden. Dies ist der "
+   Ultima-Ratio"-Weg für restriktive Netzwerke.
+4. **Konnektivitäts-Check (Chat & Self-Test):** Nach dem Handshake wird ein Modal geöffnet, das einen automatischen
+   Ping-Pong Test durchführt und einen Test-Chat bietet. Dies verifiziert die reale Datenübertragung (Serialisierung,
+   WebSockets) noch vor Abschluss des Setups.
+
+## Konsequenzen
+
+- Deutlich höhere Stabilität in heterogenen Netzwerkumgebungen.
+- Transparenteres Feedback für den Anwender bei Verbindungsproblemen.
+- Der Chat dient als "Connectivity-Proof" für das Support-Personal vor Ort.
@@ -1,51 +0,0 @@
-# 🤖 Konzept: Status-Automat für Nennungen & Zeitplan-Synchronisation
-
-Dieses Dokument spezifiziert die Logik des Status-Automaten für Nennungen (Sprint C-1) und dessen Auswirkungen auf den dynamischen Zeitplan.
-
-## 1. Status-Definitionen (NennStatusE)
-
-Basierend auf `core-domain/Enums.kt`:
-
-| Status | Bedeutung | Auswirkung auf Zeitplan |
-| :--- | :--- | :--- |
-| `EINGEGANGEN` | Nennung wurde erstellt (Initialzustand) | Belegt Zeitslot (basierend auf `reitdauerMinuten`) |
-| `BESTAETIGT` | Meldestelle hat Nennung geprüft | Belegt Zeitslot |
-| `NACHNENNUNG` | Nennung nach Nennschluss | Belegt Zeitslot (ggf. am Ende der Liste) |
-| `TRANSFERIERT` | Nennung wurde auf anderes Paar übertragen | **Inaktiv** (Original-Eintrag wird durch neuen ersetzt) |
-| `ZURUECKGEZOGEN`| Reiter hat abgemeldet (vor Startlistenerstellung) | **Inaktiv** (Slot wird frei) |
-| `GESTARTET` | Paar ist in die Prüfung eingeritten | Startzeitpunkt fixiert, Folgestarts ggf. anpassen |
-| `NICHT_ANGETRETEN`| Paar ist zum Startzeitpunkt nicht erschienen | **Zeitslot verfällt** oder Folgestarts rücken nach |
-
-## 2. Status-Übergänge & Validierung
-
-### 2.1 Gültige Übergänge (Beispiele)
- `EINGEGANGEN` -> `BESTAETIGT` (Normalfall)
- `EINGEGANGEN` -> `ZURUECKGEZOGEN` (Abmeldung)
- `BESTAETIGT` -> `TRANSFERIERT` (Reitertausch)
- `BESTAETIGT` -> `GESTARTET` (Während des Turniers)
-
-### 2.2 Side-Effects (Side-Effect-Engine)
-Wenn sich der Status einer Nennung ändert, müssen folgende Systeme informiert werden:
-1. **Billing-Service:** Bei `ZURUECKGEZOGEN` ggf. Stornogebühren prüfen. Bei `TRANSFERIERT` Guthaben übertragen.
-2. **Startlisten-Service:** Bei `ZURUECKGEZOGEN` nach Veröffentlichung der Startliste -> Eintrag als `istGestrichen = true` markieren.
-3. **Zeitplan-Optimierung:** Bei `NICHT_ANGETRETEN` -> Alle folgenden Startzeiten rücken um `reitdauerMinuten` nach vorne (sofern im Kalender-Modus "Dynamisch" aktiv ist).
-
-## 3. Dynamische Zeitplan-Anpassung (C-1 Extension)
-
-Der `StartlistenService` muss eine Methode `aktualisiereZeitplanNachStatusAenderung` erhalten:
-
- **Szenario A (Nicht angetreten):** Wenn Nennung X `NICHT_ANGETRETEN` wird, rücken alle folgenden Nennungen in der Abteilung nach vorne.
- **Szenario B (Verspätung):** Wenn Nennung X `GESTARTET` wird, aber 2 Minuten später als geplant, verschieben sich alle Folgetermine um +2 Minuten (Kettenreaktion).
-
-### Puffer-Regel (ÖTO-Konformität)
- Eine dynamische Verschiebung nach *vorne* darf nie dazu führen, dass ein Reiter vor seiner ursprünglich kommunizierten Startzeit (oder einem definierten Puffer-Zeitraum von z.B. 15 Minuten) starten muss, ohne dass dies explizit bestätigt wurde.
-
-## 4. Implementierungs-Leitfaden für Backend (C-1)
-
-1. Erweiterung von `NennungUseCases.statusAendern` um Aufrufe der Side-Effect-Handler.
-2. Implementierung des `NennungStatusListener` in `entries-service`.
-3. Anbindung an den `StartlistenService` zur Zeitre-Kalkulation.
-
---
-**Status:** Entwurf (Lead Architect)
-**Datum:** 11. April 2026
@@ -1,14 +1,14 @@
 # CSN-C NEU / CSNP-C NEU NEUMARKT/M.

-**Turnier-Nr.: 26128** | **Datum: 25. April 2026** 
+**Turnier-Nr.: 26128** | **Datum: 25. April 2026**

 ## Allgemeine Informationen

-* **Veranstalter:** Union Reit- u. Fahrverein Neumarkt/M. (6-009) 
-* **Ort:** Reitanlage Stroblmair, 4212 Neumarkt 
-* **Kontakt:** Ursula Stroblmair, Brandstetterweg 2, 4212 Neumarkt 
+* **Veranstalter:** Union Reit- u. Fahrverein Neumarkt/M. (6-009)
+* **Ort:** Reitanlage Stroblmair, 4212 Neumarkt
+* **Kontakt:** Ursula Stroblmair, Brandstetterweg 2, 4212 Neumarkt
  * **Tel.:** 0664 1832381
-  * **E-Mail:** reit-stall@gmx.at 
+  * **E-Mail:** reit-stall@gmx.at
 * **Nennungsschluss:** 24.04.2026, 19:00 Uhr
 * **Online-Nennung:** Ab Mittwoch, 22.04.
  auf [www.ihremeldestelle.at](http://www.ihremeldestelle.at)
@@ -17,17 +17,17 @@
 ## Technische Details

 * **Austragungsplatz:** 45 x 65 m (Sand/Vlies)
-* **Vorbereitungsplatz:** 20 x 40 m Halle (Sand/Vlies) 
-* **Warmreiten:** Draußen (20 x 60 m Sand/Vlies) möglich 
-* **Boxen:** Keine Einstallung möglich 
+* **Vorbereitungsplatz:** 20 x 40 m Halle (Sand/Vlies)
+* **Warmreiten:** Draußen (20 x 60 m Sand/Vlies) möglich
+* **Boxen:** Keine Einstallung möglich

 ## Funktionäre

 * **Turnierleiter:** Ursula Stroblmair
 * **Turnierbeauftragter:** Rudi Kreupl
-* **Richter:** Rudi Kreupl, Helmut Riedler 
-* **Parcoursbauchef:** Kurt Reitetschlägerr 
-* **Tierarzt:** Dr. Sabine Ötschmaier 
+* **Richter:** Rudi Kreupl, Helmut Riedler
+* **Parcoursbauchef:** Kurt Reitetschlägerr
+* **Tierarzt:** Dr. Sabine Ötschmaier

 ---

@@ -36,8 +36,8 @@
 * **Kosten:** Startgeld € 15,- pro Bewerb. Kein Nenngeld, kein Sporteuro.
 * **Teilnahmebedingungen:**
  * Für Springprüfungen bis 95 cm: Mitgliedschaft OEPS-Verein und Reiterpass erforderlich.
-  * Pferde bis 90 cm müssen **nicht** beim OEPS registriert sein. 
-  * Pferdepass mit gültigem Impfschutz (§ 11 OTO) ist vorzulegen. 
+  * Pferde bis 90 cm müssen **nicht** beim OEPS registriert sein.
+  * Pferdepass mit gültigem Impfschutz (§ 11 OTO) ist vorzulegen.
  * Haftpflichtversicherung für jedes Pferd ist Pflicht.
 * **Startregelung:**
  * Ein Pferd darf maximal 3x pro Tag starten.
@@ -0,0 +1,37 @@
+🏗️ **[Lead Architect]**
+Datum: 30. April 2026
+
+# 🧪 POC-Anleitung: Zero-Config Initialisierung
+
+Dieses Dokument beschreibt die Schritte für den technischen Hardware-POC der "Meldestelle" Desktop-App.
+
+## 1. Bauen der App
+Führen Sie auf Ihrem Entwicklungsrechner aus:
+```bash
+./gradlew :frontend:shells:meldestelle-desktop:createDistributable
+```
+Kopieren Sie den Ordner `frontend/shells/meldestelle-desktop/build/compose/binaries/main/app` auf einen USB-Stick.
+
+## 2. Test am Master-PC (PC-1)
+1. Starten Sie die App vom Stick.
+2. Wählen Sie die Rolle **Master (Host)**.
+3. Vergeben Sie einen Namen (z.B. "Meldestelle-Zentrale").
+4. Geben Sie den **Sicherheitsschlüssel** (Demo: `1234`) ein.
+5. Wählen Sie den USB-Pfad für **Plan-USB** aus (Native FileDialog öffnet sich).
+6. Klicken Sie auf "Initialisierung abschließen".
+
+## 3. Test am Client-PC (PC-2)
+1. Starten Sie die App auf dem zweiten PC im selben LAN.
+2. Wählen Sie die Rolle **Client**.
+3. **Wait-State:** Sie sollten nun die Meldung "Suche nach der Meldestelle..." sehen.
+4. Sobald der Master aktiv ist, erscheint er in der Liste.
+5. Klicken Sie auf den Master-Eintrag.
+6. Geben Sie denselben Sicherheitsschlüssel (`1234`) ein.
+7. Klicken Sie auf **"Jetzt verbinden"**.
+8. **Verifikation:** Bei Erfolg erscheint ein grüner Haken und die Meldung "Verbunden mit Meldestelle-Zentrale".
+
+## 4. Erfolgskriterien
+- [ ] Master wird vom Client automatisch gefunden (mDNS).
+- [ ] Client kann sich per Klick verbinden.
+- [ ] Native Dateidialoge sind lesbar und stabil.
+- [ ] Handshake-Feedback (Grün/Rot) funktioniert.
@@ -11,6 +11,7 @@ Dieser Ordner ist archiviert. Historische Betriebs-/Infra-Screenshots wurden nac
 `docs/80_Assets/exports/ops/archive/` verschoben.

 Neue Screens bitte gemäß Docs-as-Code in folgenden Bereichen ablegen:
+
 - UI-/Produkt-Screens: `docs/80_Assets/frontend/screens/<Modul>/...`
 - Figma-Exports: `docs/80_Assets/frontend/figma/<vision>/<bereich>/...`
 - Ops-/Infra-Exports: `docs/80_Assets/exports/ops/<topic>/...`
@@ -1,60 +0,0 @@
---
-type: Report
-status: ACTIVE
-owner: Backend Developer
-last_update: 2026-02-01
---
-
-# Abschlussbericht: Backend Hardening & Infrastructure (Ping-Service)
-
-## 1. Management Summary
-Der **Ping-Service** wurde erfolgreich als technischer Blueprint ("Tracer Bullet") gehärtet. Er erfüllt nun alle Anforderungen der **Phase 1 (Backend Hardening)** der Q1 Roadmap.
-Die Infrastruktur wurde modernisiert (Valkey 9.0), und die Testabdeckung wurde durch echte Integrationstests (Testcontainers) auf ein Enterprise-Niveau gehoben.
-
-Der Service ist **Production Ready** und dient ab sofort als Vorlage für alle fachlichen Microservices.
-
-## 2. Durchgeführte Maßnahmen
-
-### 🛡️ Security & Resilience
-*   **OAuth2 Resource Server:** Implementiert und konfiguriert (`GlobalSecurityConfig`). Tokens vom Keycloak werden validiert.
-*   **RBAC:** Endpunkte wie `/ping/secure` sind durch Rollen geschützt (`@PreAuthorize`).
-*   **CircuitBreaker:** Resilience4j sichert DB-Zugriffe ab (`@CircuitBreaker`). Fallback-Methoden ("Degraded Mode") sind aktiv.
-
-### 🏗️ Infrastructure Upgrade
-*   **Valkey Migration:** Erfolgreiche Migration von Redis (proprietär) auf **Valkey 9.0** (Open Source) in `docker-compose` und Environment-Configs.
-    *   Images: `valkey/valkey:9.0`
-    *   Kompatibilität: Vollständig gegeben (Drop-In Replacement).
-
-### 🧪 Quality Assurance (Testing)
-*   **Integrationstests:** Implementierung von `PingRepositoryTest` mit **Testcontainers** (Postgres).
-    *   Prüft Flyway-Migrationen (`V1`, `V2`).
-    *   Prüft JPA-Mapping und UUIDv7-Persistenz gegen eine echte Datenbank.
-*   **Test-Isolierung:** Lösung komplexer Spring-Kontext-Probleme (`BeanDefinitionOverrideException`) durch:
-    *   Einführung einer isolierten `TestPersistenceConfig` für Repository-Tests.
-    *   Nutzung von `@TestConfiguration` in Controller-Tests.
-    *   Entfernung des hinderlichen `@Profile("!test")` im `PingRepositoryAdapter`.
-
-### 📊 Observability
-*   **Actuator:** Health, Info, Metrics und Prometheus-Endpunkte sind exponiert.
-*   **Tracing:** Zipkin-Integration vorbereitet via `monitoring-client`.
-
-## 3. Technische Details & Learnings
-
-### Problem: Spring Context Pollution
-Während der Implementierung der Integrationstests kam es zu Konflikten zwischen den Bean-Definitionen verschiedener Tests (`BeanDefinitionOverrideException`).
-**Lösung:**
-Strikte Trennung der Kontexte. `PingRepositoryTest` lädt nun **nicht** mehr die gesamte `PingServiceApplication`, sondern nur eine minimale `TestPersistenceConfig`, die gezielt nur das Persistence-Layer scannt. Dies beschleunigt die Tests und verhindert Seiteneffekte durch Controller oder Security-Configs.
-
-### Problem: Profile-Exclusion
-Der `PingRepositoryAdapter` war mit `@Profile("!test")` annotiert. Dies verhinderte, dass Integrationstests (die im `test`-Profil laufen) den echten Adapter nutzen konnten.
-**Lösung:**
-Annotation entfernt. In Unit-Tests wird der Adapter ohnehin durch Mocks ersetzt, daher ist die Exclusion unnötig und schädlich für Integrationstests.
-
-## 4. Nächste Schritte (Handover an Frontend)
-Der Backend-Stack ist stabil. Der Frontend-Expert kann nun die Integration (Phase 2) abschließen:
-1.  Login gegen Keycloak.
-2.  Aufruf von `/ping/secure` mit Bearer-Token.
-3.  Test des Delta-Syncs (`/ping/sync`).
-
---
-*Gez. Senior Backend Developer*
@@ -1,59 +0,0 @@
---
-type: Report
-status: ACTIVE
-owner: Frontend Expert
-title: Frontend Cleanup & Architecture Status Report
-date: 2026-02-01
-author: Frontend Expert & Curator
-tags: [frontend, architecture, cleanup, kmp, compose]
---
-
-# 🧹 Frontend Cleanup & Architecture Status Report
-
-## 1. Executive Summary
-Dieses Dokument fasst die umfangreichen Aufräum- und Refactoring-Arbeiten am Frontend ("Meldestelle Portal") zusammen. Ziel war es, technischen Ballast ("Dead Code") zu entfernen, die Architektur zu vereinheitlichen (MVVM + Clean Architecture) und die Kompilierbarkeit über alle Plattformen (JVM/Desktop & JS/Web) sicherzustellen.
-
-**Ergebnis:** Der Build ist erfolgreich (`BUILD SUCCESSFUL`). Das Frontend ist nun schlank, wartbar und bereit für die Feature-Entwicklung.
-
-## 2. Durchgeführte Maßnahmen
-
-### 2.1. Entfernung von "Dead Code"
-*   **`frontend/shared` gelöscht:** Dieses Modul enthielt einen kompletten, ungenutzten Redux-Stack (`AppStore`, `AppAction`, etc.), der im Widerspruch zur genutzten MVVM-Architektur stand.
-*   **Legacy-Komponenten entfernt:** Veraltete UI-Komponenten (z.B. `NotificationCard.kt`) und doppelte Navigations-Konzepte wurden bereinigt.
-
-### 2.2. Architektur-Konsolidierung
-*   **MVVM als Standard:** Die Anwendung folgt nun strikt dem MVVM-Muster mit Kotlin Coroutines (`StateFlow`) und Koin für Dependency Injection.
-*   **Clean Architecture:** Das `ping-feature` dient als Referenz-Implementierung mit klarer Trennung von `Presentation`, `Domain` und `Data` Layer.
-*   **Navigation:** Zentralisierung der Navigation auf `AppScreen` (Sealed Class) im Core-Modul.
-
-### 2.3. Build & Plattform-Support
-*   **Koin-Initialisierung:** Korrektur der Koin-Start-Logik für JVM (`startKoin` statt `initKoin`) und JS (`startKoin` im `main.kt`).
-*   **Gradle-Konfiguration:** Bereinigung der `build.gradle.kts` Dateien und Entfernung von Abhängigkeiten zu gelöschten Modulen.
-*   **Web-Support:** Sicherstellung, dass die Web-Version (Kotlin/JS) fehlerfrei baut und die Datenbank (SQLDelight Wasm) korrekt initialisiert.
-
-## 3. Modul-Status (Ist-Zustand)
-
-| Modul | Status | Beschreibung |
-| :--- | :--- | :--- |
-| **`core/navigation`** | ✅ Grün | Zentrale Routen (`AppScreen`, `Routes`), DeepLink-Handling. Sauber. |
-| **`core/design-system`** | ✅ Grün | UI-Komponenten (`AppTheme`, `Buttons`, `Inputs`). Modern (Material 3). |
-| **`core/auth`** | ✅ Grün | Login-Logik, Token-Manager, API-Client. Funktional. |
-| **`core/network`** | ✅ Grün | Zentraler `HttpClient` mit Auth-Interceptor. |
-| **`core/sync`** | ✅ Grün | Generischer `SyncManager` für Offline-First. |
-| **`core/local-db`** | ✅ Grün | SQLDelight Setup für JVM & Web. |
-| **`features/ping`** | ✅ Grün | **Blueprint-Feature**. Zeigt Best Practices (Sync, UI, DI). |
-| **`shells/portal`** | ✅ Grün | Einstiegspunkt (`MainApp`). Verbindet alle Module. |
-
-## 4. Offene Punkte & Nächste Schritte
-
-Obwohl der technische Zustand nun exzellent ist, gibt es logische nächste Schritte für die Produktentwicklung:
-
-1.  **Feature-Rollout:** Implementierung des `members-feature` (Mitglieder) basierend auf dem `ping-feature` Blueprint.
-2.  **Testing:** Etablierung von Unit-Tests für die Core-Logik (Auth, Sync) und UI-Tests für kritische Flows.
-3.  **Backend-Alignment:** Sicherstellung, dass die Backend-Services (Registry) die erwarteten Sync-Endpunkte bereitstellen.
-
-## 5. Fazit
-Das Frontend-Fundament ist stabil. Die "technischen Schulden" aus der Experimentierphase (Redux vs. MVVM) sind getilgt. Das Team kann sich nun voll auf die Implementierung der fachlichen Anforderungen konzentrieren.
-
---
-*Gez. Frontend Expert & Curator*
@@ -1,34 +0,0 @@
---
-type: Report
-status: ACTIVE
-owner: Curator
-date: 2026-02-01
-author: Curator
---
-
-# Report: Fix Sync Type Mismatch (String vs Long)
-
-## 1. Problembeschreibung
-Es wurde eine kritische Inkonsistenz im Delta-Sync-Mechanismus zwischen Frontend und Backend festgestellt.
-*   **Frontend:** Der generische `SyncManager` nutzte einen String-Cursor (UUIDv7), was zu einem Typ-Fehler führte.
-*   **Backend:** Der `PingController` erwartete strikt einen `Long` (Timestamp) für den Parameter `lastSyncTimestamp`.
-
-## 2. Durchgeführte Maßnahmen
-### 2.1 Backend (`ping-service`)
-*   **Parameter-Umbenennung:** Der Parameter im `PingController` wurde von `lastSyncTimestamp` zu `since` umbenannt, um der Konvention des Frontend-SyncManagers zu entsprechen.
-*   **Tests:** Unit- und Integrationstests (`PingControllerTest`) wurden aktualisiert.
-
-### 2.2 Frontend (`meldestelle-portal`)
-*   **Repository-Anpassung:** `PingEventRepositoryImpl` holt nun explizit den `last_modified` Timestamp aus der Datenbank (via neuer SQL-Query `selectLatestPingEventTimestamp`).
-*   **Typ-Konvertierung:** Der Timestamp wird als String an den `SyncManager` übergeben, der ihn als URL-Parameter anhängt. Spring Boot konvertiert diesen String automatisch zurück in einen `Long`.
-
-### 2.3 Contracts (`ping-api`)
-*   Das Interface `PingApi` wurde aktualisiert: `syncPings(since: Long)`.
-
-## 3. Ergebnis
-*   Die Typ-Sicherheit ist hergestellt.
-*   Tests im Backend laufen erfolgreich durch.
-*   Der Sync-Mechanismus ist nun robust und bereit für den produktiven Einsatz.
-
-## 4. Status
-✅ **RESOLVED**
@@ -1,52 +0,0 @@
---
-type: Report
-status: ARCHIVED
-author: Senior Backend Developer
-date: 2026-01-17
-context: Phase 3 - Sync Implementation
---
-
-# Backend Status Report: Phase 3 (Sync) abgeschlossen
-
-**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
-
---
-
-## 1. Zusammenfassung
-Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
-
-**Wichtigste Errungenschaften:**
-*   **Delta-Sync API:** Implementierung von `/ping/sync` basierend auf Zeitstempeln.
-*   **Contract-Update:** Synchronisierung der API-Definitionen zwischen Backend und Frontend (`:contracts:ping-api`).
-*   **Testing:** Vollständige Testabdeckung für die neuen Sync-Endpunkte.
-
---
-
-## 2. Technische Details
-
-### A. Sync-Strategie
-*   **Mechanismus:** Zeitstempel-basierter Delta-Sync.
-*   **API:** `GET /ping/sync?lastSyncTimestamp={epochMillis}`
-*   **Response:** Liste von `PingEvent` (ID, Message, LastModified).
-*   **Vorteil:** Clients laden nur geänderte Daten, was Bandbreite spart und Offline-Fähigkeit unterstützt.
-
-### B. Implementierung
-*   **Domain:** Erweiterung des `PingUseCase` um `getPingsSince(timestamp: Long)`.
-*   **Persistence:** Effiziente JPA-Query `findByCreatedAtAfter` auf dem `timestamp`-Index.
-*   **Security:** Der Sync-Endpunkt ist aktuell `public` (analog zu anderen Ping-Endpunkten), kann aber bei Bedarf geschützt werden.
-
-### C. Frontend-Kompatibilität
-*   Die Frontend-Clients (`PingApiClient`, `PingApiKoinClient`) wurden aktualisiert, um den neuen Endpunkt zu unterstützen.
-*   Test-Doubles im Frontend wurden angepasst, um die Build-Integrität zu wahren.
-
---
-
-## 3. Offene Punkte & Nächste Schritte
-
-*   **Frontend Integration:** Der Frontend-Expert muss nun die Logik implementieren, um den `lastSyncTimestamp` lokal zu speichern und den Sync-Prozess zu steuern.
-*   **Konfliktlösung:** Aktuell ist der Sync unidirektional (Server -> Client). Für bidirektionalen Sync (Client -> Server) müssen noch Strategien (z.B. "Last Write Wins") definiert werden.
-
---
-
-## 4. Fazit
-Das Backend ist bereit für Offline-First-Szenarien. Die Delta-Sync-Schnittstelle ist performant und einfach zu konsumieren.
@@ -6,10 +6,10 @@ date: 2026-01-31
 tags: [e2e, smoke, docker, migration, ktor-3.4.0, exposed-1.0.0]
 ---

-
 # E2E Smoke – Migration Exposed 1.0.0 & Ktor 3.4.0

 ## Einrichtung
+
 - Compose: docker compose --profile all up --build -d
 - Services (Auszug):
  - api-gateway (8080/actuator, 8080/api via Proxy)
@@ -20,17 +20,22 @@ tags: [e2e, smoke, docker, migration, ktor-3.4.0, exposed-1.0.0]
 - Versionen (Platform/Catalog): ktor=3.4.0, exposed=1.0.0

 ## Checks & Ergebnisse
+
 - Gateway Health: 200 OK (readiness/live, Prometheus)
 - Ping-Service Health/Prometheus: 200 OK stabil
 - Web-App Health: 200 OK (Fallback-Assets aktiv, Favicon bereitgestellt)
 - Desktop-App: Xvfb/XFCE/x11vnc/noVNC aktiv, Zugriff via http://localhost:6080/

 ## Beobachtbarkeit
+
 - Prometheus-Metriken erreichbar (Gateway/Ping)
 - Logs ohne kritische Fehler im Happy Path

 ## Probleme & Hinweise
- Frontend KMP/JS-Build schlägt in Builder aktuell fehl (fehlende JS-Implementierungen in Auth/Ping-Data). Nginx liefert Fallback-Assets aus; Favicon hinzugefügt, um 404 zu vermeiden.
+
+- Frontend KMP/JS-Build schlägt in Builder aktuell fehl (fehlende JS-Implementierungen in Auth/Ping-Data). Nginx liefert
+  Fallback-Assets aus; Favicon hinzugefügt, um 404 zu vermeiden.

 ## Entscheidung
+
 - Empfehlung: Go für Phase 4 (FE „web“-Target Migration & Build-Fix; Dokumente finalisieren)
@@ -0,0 +1,79 @@
+---
+type: Report
+status: ACTIVE
+owner: Backend Developer
+last_update: 2026-02-01
+---
+
+# Abschlussbericht: Backend Hardening & Infrastructure (Ping-Service)
+
+## 1. Management Summary
+
+Der **Ping-Service** wurde erfolgreich als technischer Blueprint ("Tracer Bullet") gehärtet. Er erfüllt nun alle
+Anforderungen der **Phase 1 (Backend Hardening)** der Q1 Roadmap.
+Die Infrastruktur wurde modernisiert (Valkey 9.0), und die Testabdeckung wurde durch echte Integrationstests (
+Testcontainers) auf ein Enterprise-Niveau gehoben.
+
+Der Service ist **Production Ready** und dient ab sofort als Vorlage für alle fachlichen Microservices.
+
+## 2. Durchgeführte Maßnahmen
+
+### 🛡️ Security & Resilience
+
+* **OAuth2 Resource Server:** Implementiert und konfiguriert (`GlobalSecurityConfig`). Tokens vom Keycloak werden
+  validiert.
+* **RBAC:** Endpunkte wie `/ping/secure` sind durch Rollen geschützt (`@PreAuthorize`).
+* **CircuitBreaker:** Resilience4j sichert DB-Zugriffe ab (`@CircuitBreaker`). Fallback-Methoden ("Degraded Mode") sind
+  aktiv.
+
+### 🏗️ Infrastructure Upgrade
+
+* **Valkey Migration:** Erfolgreiche Migration von Redis (proprietär) auf **Valkey 9.0** (Open Source) in
+  `docker-compose` und Environment-Configs.
+  * Images: `valkey/valkey:9.0`
+  * Kompatibilität: Vollständig gegeben (Drop-In Replacement).
+
+### 🧪 Quality Assurance (Testing)
+
+* **Integrationstests:** Implementierung von `PingRepositoryTest` mit **Testcontainers** (Postgres).
+  * Prüft Flyway-Migrationen (`V1`, `V2`).
+  * Prüft JPA-Mapping und UUIDv7-Persistenz gegen eine echte Datenbank.
+* **Test-Isolierung:** Lösung komplexer Spring-Kontext-Probleme (`BeanDefinitionOverrideException`) durch:
+  * Einführung einer isolierten `TestPersistenceConfig` für Repository-Tests.
+  * Nutzung von `@TestConfiguration` in Controller-Tests.
+  * Entfernung des hinderlichen `@Profile("!test")` im `PingRepositoryAdapter`.
+
+### 📊 Observability
+
+* **Actuator:** Health, Info, Metrics und Prometheus-Endpunkte sind exponiert.
+* **Tracing:** Zipkin-Integration vorbereitet via `monitoring-client`.
+
+## 3. Technische Details & Learnings
+
+### Problem: Spring Context Pollution
+
+Während der Implementierung der Integrationstests kam es zu Konflikten zwischen den Bean-Definitionen verschiedener
+Tests (`BeanDefinitionOverrideException`).
+**Lösung:**
+Strikte Trennung der Kontexte. `PingRepositoryTest` lädt nun **nicht** mehr die gesamte `PingServiceApplication`,
+sondern nur eine minimale `TestPersistenceConfig`, die gezielt nur das Persistence-Layer scannt. Dies beschleunigt die
+Tests und verhindert Seiteneffekte durch Controller oder Security-Configs.
+
+### Problem: Profile-Exclusion
+
+Der `PingRepositoryAdapter` war mit `@Profile("!test")` annotiert. Dies verhinderte, dass Integrationstests (die im
+`test`-Profil laufen) den echten Adapter nutzen konnten.
+**Lösung:**
+Annotation entfernt. In Unit-Tests wird der Adapter ohnehin durch Mocks ersetzt, daher ist die Exclusion unnötig und
+schädlich für Integrationstests.
+
+## 4. Nächste Schritte (Handover an Frontend)
+
+Der Backend-Stack ist stabil. Der Frontend-Expert kann nun die Integration (Phase 2) abschließen:
+
+1. Login gegen Keycloak.
+2. Aufruf von `/ping/secure` mit Bearer-Token.
+3. Test des Delta-Syncs (`/ping/sync`).
+
+---
+*Gez. Senior Backend Developer*
@@ -0,0 +1,76 @@
+---
+type: Report
+status: ACTIVE
+owner: Frontend Expert
+title: Frontend Cleanup & Architecture Status Report
+date: 2026-02-01
+author: Frontend Expert & Curator
+tags: [frontend, architecture, cleanup, kmp, compose]
+---
+
+# 🧹 Frontend Cleanup & Architecture Status Report
+
+## 1. Executive Summary
+
+Dieses Dokument fasst die umfangreichen Aufräum- und Refactoring-Arbeiten am Frontend ("Meldestelle Portal") zusammen.
+Ziel war es, technischen Ballast ("Dead Code") zu entfernen, die Architektur zu vereinheitlichen (MVVM + Clean
+Architecture) und die Kompilierbarkeit über alle Plattformen (JVM/Desktop & JS/Web) sicherzustellen.
+
+**Ergebnis:** Der Build ist erfolgreich (`BUILD SUCCESSFUL`). Das Frontend ist nun schlank, wartbar und bereit für die
+Feature-Entwicklung.
+
+## 2. Durchgeführte Maßnahmen
+
+### 2.1. Entfernung von "Dead Code"
+
+* **`frontend/shared` gelöscht:** Dieses Modul enthielt einen kompletten, ungenutzten Redux-Stack (`AppStore`,
+  `AppAction`, etc.), der im Widerspruch zur genutzten MVVM-Architektur stand.
+* **Legacy-Komponenten entfernt:** Veraltete UI-Komponenten (z.B. `NotificationCard.kt`) und doppelte
+  Navigations-Konzepte wurden bereinigt.
+
+### 2.2. Architektur-Konsolidierung
+
+* **MVVM als Standard:** Die Anwendung folgt nun strikt dem MVVM-Muster mit Kotlin Coroutines (`StateFlow`) und Koin für
+  Dependency Injection.
+* **Clean Architecture:** Das `ping-feature` dient als Referenz-Implementierung mit klarer Trennung von `Presentation`,
+  `Domain` und `Data` Layer.
+* **Navigation:** Zentralisierung der Navigation auf `AppScreen` (Sealed Class) im Core-Modul.
+
+### 2.3. Build & Plattform-Support
+
+* **Koin-Initialisierung:** Korrektur der Koin-Start-Logik für JVM (`startKoin` statt `initKoin`) und JS (`startKoin` im
+  `main.kt`).
+* **Gradle-Konfiguration:** Bereinigung der `build.gradle.kts` Dateien und Entfernung von Abhängigkeiten zu gelöschten
+  Modulen.
+* **Web-Support:** Sicherstellung, dass die Web-Version (Kotlin/JS) fehlerfrei baut und die Datenbank (SQLDelight Wasm)
+  korrekt initialisiert.
+
+## 3. Modul-Status (Ist-Zustand)
+
+| Modul                    | Status | Beschreibung                                                           |
+|:-------------------------|:-------|:-----------------------------------------------------------------------|
+| **`core/navigation`**    | ✅ Grün | Zentrale Routen (`AppScreen`, `Routes`), DeepLink-Handling. Sauber.    |
+| **`core/design-system`** | ✅ Grün | UI-Komponenten (`AppTheme`, `Buttons`, `Inputs`). Modern (Material 3). |
+| **`core/auth`**          | ✅ Grün | Login-Logik, Token-Manager, API-Client. Funktional.                    |
+| **`core/network`**       | ✅ Grün | Zentraler `HttpClient` mit Auth-Interceptor.                           |
+| **`core/sync`**          | ✅ Grün | Generischer `SyncManager` für Offline-First.                           |
+| **`core/local-db`**      | ✅ Grün | SQLDelight Setup für JVM & Web.                                        |
+| **`features/ping`**      | ✅ Grün | **Blueprint-Feature**. Zeigt Best Practices (Sync, UI, DI).            |
+| **`shells/portal`**      | ✅ Grün | Einstiegspunkt (`MainApp`). Verbindet alle Module.                     |
+
+## 4. Offene Punkte & Nächste Schritte
+
+Obwohl der technische Zustand nun exzellent ist, gibt es logische nächste Schritte für die Produktentwicklung:
+
+1. **Feature-Rollout:** Implementierung des `members-feature` (Mitglieder) basierend auf dem `ping-feature` Blueprint.
+2. **Testing:** Etablierung von Unit-Tests für die Core-Logik (Auth, Sync) und UI-Tests für kritische Flows.
+3. **Backend-Alignment:** Sicherstellung, dass die Backend-Services (Registry) die erwarteten Sync-Endpunkte
+   bereitstellen.
+
+## 5. Fazit
+
+Das Frontend-Fundament ist stabil. Die "technischen Schulden" aus der Experimentierphase (Redux vs. MVVM) sind getilgt.
+Das Team kann sich nun voll auf die Implementierung der fachlichen Anforderungen konzentrieren.
+
+---
+*Gez. Frontend Expert & Curator*
@@ -0,0 +1,45 @@
+---
+type: Report
+status: ACTIVE
+owner: Curator
+date: 2026-02-01
+author: Curator
+---
+
+# Report: Fix Sync Type Mismatch (String vs Long)
+
+## 1. Problembeschreibung
+
+Es wurde eine kritische Inkonsistenz im Delta-Sync-Mechanismus zwischen Frontend und Backend festgestellt.
+
+* **Frontend:** Der generische `SyncManager` nutzte einen String-Cursor (UUIDv7), was zu einem Typ-Fehler führte.
+* **Backend:** Der `PingController` erwartete strikt einen `Long` (Timestamp) für den Parameter `lastSyncTimestamp`.
+
+## 2. Durchgeführte Maßnahmen
+
+### 2.1 Backend (`ping-service`)
+
+* **Parameter-Umbenennung:** Der Parameter im `PingController` wurde von `lastSyncTimestamp` zu `since` umbenannt, um
+  der Konvention des Frontend-SyncManagers zu entsprechen.
+* **Tests:** Unit- und Integrationstests (`PingControllerTest`) wurden aktualisiert.
+
+### 2.2 Frontend (`meldestelle-portal`)
+
+* **Repository-Anpassung:** `PingEventRepositoryImpl` holt nun explizit den `last_modified` Timestamp aus der
+  Datenbank (via neuer SQL-Query `selectLatestPingEventTimestamp`).
+* **Typ-Konvertierung:** Der Timestamp wird als String an den `SyncManager` übergeben, der ihn als URL-Parameter
+  anhängt. Spring Boot konvertiert diesen String automatisch zurück in einen `Long`.
+
+### 2.3 Contracts (`ping-api`)
+
+* Das Interface `PingApi` wurde aktualisiert: `syncPings(since: Long)`.
+
+## 3. Ergebnis
+
+* Die Typ-Sicherheit ist hergestellt.
+* Tests im Backend laufen erfolgreich durch.
+* Der Sync-Mechanismus ist nun robust und bereit für den produktiven Einsatz.
+
+## 4. Status
+
+✅ **RESOLVED**
@@ -0,0 +1,65 @@
+---
+type: Report
+status: ARCHIVED
+author: Senior Backend Developer
+date: 2026-01-17
+context: Phase 3 - Sync Implementation
+---
+
+# Backend Status Report: Phase 3 (Sync) abgeschlossen
+
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current
+status.
+
+---
+
+## 1. Zusammenfassung
+
+Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um
+Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
+
+**Wichtigste Errungenschaften:**
+
+* **Delta-Sync API:** Implementierung von `/ping/sync` basierend auf Zeitstempeln.
+* **Contract-Update:** Synchronisierung der API-Definitionen zwischen Backend und Frontend (`:contracts:ping-api`).
+* **Testing:** Vollständige Testabdeckung für die neuen Sync-Endpunkte.
+
+---
+
+## 2. Technische Details
+
+### A. Sync-Strategie
+
+* **Mechanismus:** Zeitstempel-basierter Delta-Sync.
+* **API:** `GET /ping/sync?lastSyncTimestamp={epochMillis}`
+* **Response:** Liste von `PingEvent` (ID, Message, LastModified).
+* **Vorteil:** Clients laden nur geänderte Daten, was Bandbreite spart und Offline-Fähigkeit unterstützt.
+
+### B. Implementierung
+
+* **Domain:** Erweiterung des `PingUseCase` um `getPingsSince(timestamp: Long)`.
+* **Persistence:** Effiziente JPA-Query `findByCreatedAtAfter` auf dem `timestamp`-Index.
+* **Security:** Der Sync-Endpunkt ist aktuell `public` (analog zu anderen Ping-Endpunkten), kann aber bei Bedarf
+  geschützt werden.
+
+### C. Frontend-Kompatibilität
+
+* Die Frontend-Clients (`PingApiClient`, `PingApiKoinClient`) wurden aktualisiert, um den neuen Endpunkt zu
+  unterstützen.
+* Test-Doubles im Frontend wurden angepasst, um die Build-Integrität zu wahren.
+
+---
+
+## 3. Offene Punkte & Nächste Schritte
+
+* **Frontend Integration:** Der Frontend-Expert muss nun die Logik implementieren, um den `lastSyncTimestamp` lokal zu
+  speichern und den Sync-Prozess zu steuern.
+* **Konfliktlösung:** Aktuell ist der Sync unidirektional (Server -> Client). Für bidirektionalen Sync (Client ->
+  Server) müssen noch Strategien (z.B. "Last Write Wins") definiert werden.
+
+---
+
+## 4. Fazit
+
+Das Backend ist bereit für Offline-First-Szenarien. Die Delta-Sync-Schnittstelle ist performant und einfach zu
+konsumieren.
@@ -8,13 +8,15 @@ context: Phase 1-3 (Backend Ready)

 # Infrastructure Status Report: "Tracer Bullet" Readiness

-**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current
+status.

 ---

 **Datum:** 20. Jänner 2026
 **Autor:** DevOps & Infrastructure Engineer (Updated by Backend Developer)
-**Ziel:** Bestätigung der Einsatzbereitschaft der lokalen Entwicklungsumgebung für Phase 1 (Backend Hardening) und Phase 3 (Sync).
+**Ziel:** Bestätigung der Einsatzbereitschaft der lokalen Entwicklungsumgebung für Phase 1 (Backend Hardening) und Phase
+3 (Sync).

 ## 1. Executive Summary

@@ -36,23 +38,27 @@ Die Integrationstests des `ping-service` gegen die Docker-Umgebung waren erfolgr
 ## 3. Durchgeführte Maßnahmen (DevOps)

 ### 3.1. Keycloak Stabilisierung
-*   Umstellung auf offizielles Image `quay.io/keycloak/keycloak:26.4` (start-dev).
-*   Realm-Import via `--import-realm` erfolgreich.
+
+* Umstellung auf offizielles Image `quay.io/keycloak/keycloak:26.4` (start-dev).
+* Realm-Import via `--import-realm` erfolgreich.

 ### 3.2. Datenbank Initialisierung
-*   Init-Skripte gehärtet.
-*   Sauberer State durch Reset garantiert.
+
+* Init-Skripte gehärtet.
+* Sauberer State durch Reset garantiert.

 ### 3.3. Konfigurations-Bereinigung
-*   `base-application.yaml` bereinigt und Flyway aktiviert.
+
+* `base-application.yaml` bereinigt und Flyway aktiviert.

 ## 4. Backend Feedback (Phase 1 & 3 Abschluss)

 Der **Senior Backend Developer** bestätigt:

-1.  **Connectivity:** Der `ping-service` verbindet sich erfolgreich mit Postgres, Keycloak und Consul.
-2.  **Security:** Die Token-Validierung (Issuer: `http://keycloak:8080/...`) funktioniert im Docker-Netzwerk einwandfrei.
-3.  **Sync:** Die Performance der DB für den Delta-Sync (`/ping/sync`) ist auch bei lokalen Tests sehr gut (Index-Nutzung bestätigt).
+1. **Connectivity:** Der `ping-service` verbindet sich erfolgreich mit Postgres, Keycloak und Consul.
+2. **Security:** Die Token-Validierung (Issuer: `http://keycloak:8080/...`) funktioniert im Docker-Netzwerk einwandfrei.
+3. **Sync:** Die Performance der DB für den Delta-Sync (`/ping/sync`) ist auch bei lokalen Tests sehr gut (Index-Nutzung
+   bestätigt).

 **Status:** Der `ping-service` ist vollständig implementiert (inkl. Hardening & Sync) und bereit für das Frontend.

@@ -8,7 +8,8 @@ tags: [backend, ping-service, task]

 # Arbeitsauftrag: Implementierung des `ping-service` (Tracer Bullet)

-**ARCHIVED:** This is the original task description. The implementation has evolved. Please refer to `docs/05_Backend/Services/PingService_Reference.md`.
+**ARCHIVED:** This is the original task description. The implementation has evolved. Please refer to
+`docs/05_Backend/Services/PingService_Reference.md`.

 ---

@@ -58,6 +59,7 @@ JVM-spezifischen Abhängigkeiten** enthalten, um die KMP-Kompatibilität für da
  ```text
  PingResponse.kt
  ```
+
  ```text
  package de.meldestelle.api.ping
  
@@ -71,12 +73,13 @@ JVM-spezifischen Abhängigkeiten** enthalten, um die KMP-Kompatibilität für da
  ```

 3. Service-Implementierung in :ping-service
-   
+
 Implementiere die Spring Boot Anwendung.

 - **`PingController.kt`:**
- - **`GET /api/ping`:** Ein öffentlicher Endpunkt, der eine `PingResponse("Pong", "anonymous")` zurückgibt.
- - **`GET /api/ping/secure`:** Ein durch Spring Security geschützter Endpunkt. Er soll den `preferred_username` aus dem `Jwt` Principal extrahieren und in der `PingResponse` zurückgeben.
+- **`GET /api/ping`:** Ein öffentlicher Endpunkt, der eine `PingResponse("Pong", "anonymous")` zurückgibt.
+- **`GET /api/ping/secure`:** Ein durch Spring Security geschützter Endpunkt. Er soll den `preferred_username` aus dem
+  `Jwt` Principal extrahieren und in der `PingResponse` zurückgeben.

 Hier ist ein Implementierungsvorschlag für den Controller:

@@ -108,7 +111,7 @@ Erstelle die `application.yml` für den Service. Sie muss die Anwendung für uns
 - **Service Discovery:** Registrierung bei Consul.
 - **Security:** Konfiguration als Resource Server, der JWTs vom `issuer-uri` unseres Keycloak-Containers validiert.
 - **Observability:** Actuator-Endpunkte (`health`, `info`, `prometheus`) freigeben und Tracing aktivieren.
-
+  
  ```yaml
  # in backend/services/ping/ping-service/src/main/resources/application.yml
  
@@ -150,7 +153,7 @@ Erstelle die `application.yml` für den Service. Sie muss die Anwendung für uns
    pattern:
      level: "%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]"
  ```
-  
+
 5. **Build-Konfiguration(`build.gradle.kts`)

 Achte auf die korrekte und saubere Definition der Abhängigkeiten.
@@ -172,7 +175,7 @@ Achte auf die korrekte und saubere Definition der Abhängigkeiten.
        }
    }
  ```
-  
+
 - `ping-service/build.gradle.kts`
  ```text
      plugins {
@@ -202,14 +205,17 @@ Achte auf die korrekte und saubere Definition der Abhängigkeiten.
        testImplementation(libs.bundles.test.spring)
    }
  ```
-  
+
 ## Definition of Done:

 Der Auftrag gilt als erledigt, wenn:
+
 1. Die Anwendung erfolgreich startet und sich im Consul UI als `UP` registriert.
-2. Ein `GET`-Request auf `http//localhost:8081/api/ping` (über das Gateway) den Status `200 OK` und die `{"message":"Pong", "principal":"anonymous"}` zurückgibt.
+2. Ein `GET`-Request auf `http//localhost:8081/api/ping` (über das Gateway) den Status `200 OK` und die
+   `{"message":"Pong", "principal":"anonymous"}` zurückgibt.
 3. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` ohne Token den Status `401 Unauthorized` zurückgibt.
-4. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` mit einem gültigen Keycloak-Token deb Status `200 OK` und eine Antwort mit dem korrekten Benutzernamen zurückgibt.
+4. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` mit einem gültigen Keycloak-Token deb Status `200 OK`
+   und eine Antwort mit dem korrekten Benutzernamen zurückgibt.
 5. Die Requests in der Zipkin UI als Trace sichtbar sind.

 Bei Fragen zur Konfiguration oder zur Architektur stehe ich dir zur Verfügung.
@@ -1,24 +0,0 @@
-# Session Log: Behebung Flyway Migrations-Fehler im Ping-Service
-**Datum:** 2026-04-03
-**Agent:** Backend Developer / Curator
-
-## Problembeschreibung
-Der `ping-service` ließ sich via Docker nicht starten und warf eine `FlywayMigrateException` mit der Ursache `ERROR: relation "ping" does not exist`. 
-Die Log-Analyse zeigte, dass die Datenbankmigration `V2__seed_data.sql` fehlgeschlagen ist, weil die vorausgehende Migration `V1__init_ping.sql` (in der die Tabelle `ping` erstellt wird) offensichtlich nicht ausgeführt wurde.
-
-## Ursachenanalyse
-Die `application.yaml` des `ping-service` enthielt die Konfiguration `baseline-on-migrate: true`. Wenn mehrere Services (z. B. `masterdata-service`, `ping-service` etc.) dieselbe PostgreSQL-Datenbank (`pg-meldestelle-db`) und standardmäßig das Schema `public` nutzen, teilen sie sich ohne weitere Konfiguration die gleiche Flyway-Historientabelle (`flyway_schema_history`).
-
-Wenn ein anderer Service bereits Migrationen ausgeführt oder die Datenbank initialisiert hatte, setzte Flyway für den `ping-service` eine Baseline mit Version `1`. Infolgedessen ignorierte Flyway die Datei `V1__init_ping.sql` und versuchte direkt, `V2__seed_data.sql` auszuführen. Dies führte zum Scheitern der Migration, da die notwendige Struktur aus `V1` fehlte.
-
-## Lösung
-1.  **Isolierung der Flyway-Historientabelle:** In der `application.yaml` des `ping-service` wurde die Property `spring.flyway.table: flyway_schema_history_ping` hinzugefügt. Dadurch verwaltet der `ping-service` seinen eigenen Migrationsstatus unabhängig von anderen Services in der gleichen Datenbank.
-2.  **Anpassung der Baseline-Version:** Es wurde explizit `spring.flyway.baseline-version: "0"` konfiguriert, um sicherzustellen, dass V1-Skripte stets als Teil der Historie betrachtet werden, selbst falls Flyway in einer nicht leeren Datenbank ansetzt.
-
-## Geänderte Dateien
-*   `/mocode/Meldestelle/backend/services/ping/ping-service/src/main/resources/application.yaml`
-*   `/mocode/Meldestelle/docs/05_Backend/Services/PingService_Reference.md` (Dokumentation aktualisiert)
-
-## Nächste Schritte
-*   Die Infrastruktur sollte nun stabil hochfahren. (Ggf. Ping Service im Docker Stack neustarten).
-*   Diese Best Practice (spezifische `flyway.table` pro Service) sollte zukünftig auch bei anderen Microservices angewandt werden, die sich dasselbe DB-Schema teilen, um Konflikte zu vermeiden.
@@ -1,52 +0,0 @@
---
-type: Journal
-status: ACTIVE
-owner: Curator
-last_update: 2026-04-10
---
-# Journal Entry: 2026-04-10 - Billing Service Setup & ZNS Importer Hardening
-
-## 👷 [Backend Developer] / 🏗️ [Lead Architect] / 🧹 [Curator]
-
-### Zusammenfassung der Session
-In dieser Session wurde das Fundament für den Kassa-Service (`billing-context`) gelegt und die Robustheit des ZNS-Importers durch zusätzliche Integrationstests für Funktionäre gesteigert.
-
-### Wichtigste Ergebnisse
-1.  **Billing Service Initialisierung & API:**
-    *   `billing-service` Modul erstellt, konfiguriert und mit `core-domain` (Serialisierung) verknüpft.
-    *   Exposed-Tabellendefinitionen (v1) für `TeilnehmerKonto` und `Buchung` implementiert.
-    *   `BillingController` mit REST-Endpunkten für Konten, Buchungen und Historie erstellt.
-    *   `TeilnehmerKontoService` um API-Methoden (`getKontoById`, `getKonto`, `getBuchungsHistorie`, `buche`) erweitert.
-    *   Integrationstests (`TeilnehmerKontoServiceTest`) erfolgreich mit H2-In-Memory-DB durchgeführt.
-    *   **OpenAPI-Dokumentation:** `documentation.yaml` für `billing-service` erstellt und CRUD-Endpunkte für Konten und Buchungen dokumentiert.
-2.  **Entries-Integration (Neu):**
-    *   Automatische Buchung von Nenngeld und Nachnenngebühren bei Einreichung einer Nennung implementiert.
-    *   Erweiterung der `Bewerb`-Entität um Finanzfelder (`nenngeld_cent`, `nachnenngebuehr_cent`).
-    *   Neue Flyway-Migration `V8__add_bewerb_financial_fields.sql` im `entries-service` hinzugefügt.
-    *   `NennungUseCases` nutzt nun den `TeilnehmerKontoService` zur automatischen Belastung der Teilnehmerkonten (negativer Saldo).
-    *   `EntriesServiceApplication` scannt nun auch `at.mocode.billing` Pakete für die Cross-Context Integration.
-3.  **ZNS-Importer Hardening:**
-    *   Erweiterung von `ZnsImportServiceTest` um Tests für mehrfache Qualifikationen und die Update-Strategie (Delete+Insert) bei Funktionären (`RICHT01.dat`).
-    *   Alle 11 Integrationstests sind erfolgreich durchgelaufen.
-4.  **Kompilations-Fixes (Billing):**
-    *   `billing-service` auf korrekte Exposed DSL Syntax (`selectAll().where { ... }`) umgestellt.
-    *   Explizite `transaction { ... }` Blöcke in `TeilnehmerKontoService` eingeführt.
-    *   Typ-Konsistenz für `Instant` (kotlin.time) in `billing-domain` zur Übereinstimmung mit `core-domain` hergestellt.
-
-### Betroffene Dateien
- `backend/services/billing/` (Neuer SCS-Kontext)
- `backend/infrastructure/zns-importer/src/test/kotlin/at/mocode/zns/importer/ZnsImportServiceTest.kt`
-
-### Nächste Schritte
- [x] Integration des Billing-Services in den `entries-context` (automatische Buchung bei Nennung).
- [x] Fix von Kompilationsfehlern und Test-Regressionen (H2/Exposed Kompatibilität).
- UI-Anbindung im Frontend für Kontenübersicht und manuelle Buchungen.
- Erweiterung der Abrechnungs-Logik (z.B. Rechnungserstellung als PDF).
-
-### Technische Details & Fixes
- **Exposed / H2:** `TIMESTAMPTZ` in Flyway-Migrationen auf `TIMESTAMP WITH TIME ZONE` umgestellt, um H2-Kompatibilität in Integrationstests zu gewährleisten.
- **Multi-Tenancy:** `ExposedTenantTransactions` unterstützt nun sowohl PostgreSQL (`SET search_path`) als auch H2 (`SET SCHEMA`).
- **Billing Config:** `BillingDatabaseConfiguration` ist nun robust gegen fehlende JDBC-URLs (wichtig für modularisierte Tests).
-
---
-*Co-authored-by: Junie <junie@jetbrains.com>*
@@ -1,26 +0,0 @@
---
-type: Journal
-status: ACTIVE
-owner: DevOps Engineer
-last_update: 2026-04-14
---
-
-# Session Log: Fix Kotlin Wasm JS Compilation OOM
-
-## Problem
-Die Kompilierung des Moduls `:frontend:features:billing-feature` für `wasmJs` schlug mit einem `java.lang.OutOfMemoryError: GC overhead limit exceeded` fehl.
-
-Ursache war die Verwendung von `material-icons-extended` in Kombination mit den bisherigen JVM-Speichereinstellungen (6GB). Da `material-icons-extended` tausende generierte Icon-Dateien enthält, stößt der Kotlin/Wasm-Compiler bei der IR-Lowering-Phase an seine Grenzen.
-
-## Lösung
-1. **Speichererhöhung:** Die JVM-Heap-Einstellungen in `gradle.properties` wurden von 6GB auf 8GB erhöht.
-   - `kotlin.daemon.jvmargs` wurde auf `-Xmx8g` gesetzt.
-   - `org.gradle.jvmargs` wurde auf `-Xmx8g` gesetzt, wobei die Optionen für den Kotlin-Daemon (`-Dkotlin.daemon.jvm.options`) auf `-Xmx6g` erhöht wurden.
-2. **Verifizierung:** Die Kompilierung von `:frontend:features:billing-feature:compileProductionLibraryKotlinWasmJs` wurde nach einem Daemon-Restart erfolgreich durchgeführt.
-
-## Betroffene Dateien
- `gradle.properties`: Erhöhung der Speicherlimits.
- `frontend/features/billing-feature/build.gradle.kts`: (Kurzzeitig getestet ohne `materialIconsExtended`, aber wieder aktiviert, da Icons daraus benötigt werden).
-
-## Handover
- Zukünftig sollte bei weiteren OOM-Problemen im Wasm-Bereich geprüft werden, ob `material-icons-extended` durch eine selektive Icon-Einbindung (z.B. als Ressourcen) ersetzt werden kann, um den Compiler zu entlasten.
@@ -1,41 +0,0 @@
---
-type: Journal
-status: ACTIVE
-owner: DevOps Engineer
-last_update: 2026-04-14
---
-
-# Session Log: Finalize and Enable Entries Isolation Integration Test
-
-## Problem
-Der Test `EntriesIsolationIntegrationTest` im Modul `:backend:services:entries:entries-service` war deaktiviert (`@Disabled`). Er hatte Probleme mit der Daten-Isolierung zwischen verschiedenen Tenants, wenn Exposed mit mehreren Schemas und PostgreSQL-Containern verwendet wurde.
-
-Zusätzlich gab es IDE-Warnungen bezüglich nicht auflösbarer Symbole in SQL-Strings, redundantem `runBlocking` und ungenutzten Variablen.
-
-## Lösung
-1. **Test-Bereinigung:**
-   - Entfernung der `@Disabled` Annotation.
-   - Behebung der `runBlocking` Redundanz durch Verwendung von `runBlocking` auf Test-Methoden-Ebene.
-   - Entfernung ungenutzter Variablen (`saved`).
-   - Bereitstellung einer `@TestConfiguration` mit einem Mock `JwtDecoder`, um ApplicationContext-Ladefehler durch Security-Abhängigkeiten zu vermeiden.
-
-2. **Schema-Isolierung fixiert:**
-   - Umstellung der Tabellen-Erstellung im `setup` auf JDBC, um zu verhindern, dass Exposed's `Table`-Singletons frühzeitig an ein falsches Schema gebunden werden.
-   - Sicherstellung, dass `tenantTransaction` den `search_path` in PostgreSQL korrekt setzt.
-   - Explizite Verwendung von `SET search_path` innerhalb der Transaktionen im Isolationstest, um Leaks zu vermeiden.
-   - Verifizierung der Isolation: Schreibzugriffe in `event_a` landen nun nachweislich nicht mehr in `event_b`.
-
-3. **Verifizierung & Cleanup:**
-   - Alle 10 Tests im Modul (inkl. der neu aktivierten Isolation-Tests) laufen erfolgreich durch.
-   - IDE-Warnungen in `EntriesIsolationIntegrationTest` und `JdbcTenantRegistryTest` wurden durch `@Suppress("SqlResolve")`, Verwendung von String-Konstanten/Interpolation (`$CONTROL_SCHEMA`) und Entfernung ungenutzter Code-Fragmente (`nennungRepository`, `random()`, `registerDataSource`) behoben.
-   - Typos wie "testdb" -> "test_db" und "Produktions" -> "Production" wurden korrigiert.
-   - Behebung von IDE-Warnungen in `NennungBillingIntegrationTest`, `BewerbeZeitplanIntegrationTest` und `DomainHierarchyMigrationTest` durch Entfernung ungenutzter Variablen (`result`), Ersetzen von Umlauten in Funktionsnamen/Strings durch ASCII-Zeichen und Verwendung von Konstanten für Schema-Namen (`TEST_SCHEMA`).
-   - Fehlende Spring-Konfigurations-Metadaten für `multitenancy.*` wurden in `additional-spring-configuration-metadata.json` ergänzt.
-
-## Betroffene Dateien
- `backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/EntriesIsolationIntegrationTest.kt`: Reaktiviert und repariert.
- `backend/services/entries/entries-service/src/test/kotlin/at/mocode/entries/service/tenant/JdbcTenantRegistryTest.kt`: Bereinigt und optimiert.
- `backend/services/entries/entries-service/src/main/resources/META-INF/additional-spring-configuration-metadata.json`: Metadaten ergänzt.
-
-## Handover
- Der `EntriesIsolationIntegrationTest` dient nun als Referenz für Multi-Tenancy Tests mit echten PostgreSQL-Containern. Bei weiteren Tests dieser Art sollte auf das Exposed-Schema-Caching geachtet werden.
@@ -1,27 +0,0 @@
---
-type: Journal
-status: ACTIVE
-owner: DevOps Engineer
-last_update: 2026-04-14
---
-
-# Session Log: Fix Entries Service Integration Tests (EOFException / PostgreSQL Connection)
-
-## Problem
-Die Integrationstests im Modul `:backend:services:entries:entries-service` (`BewerbeZeitplanIntegrationTest`, `NennungBillingIntegrationTest`) schlugen mit einer `FlywaySqlUnableToConnectToDbException` (verursacht durch `PSQLException: EOFException`) fehl.
-
-Ursache war das Fehlen einer `application-test.yaml`. Dadurch wurden die Standardwerte aus `application.yaml` geladen, welche eine aktive PostgreSQL-Instanz auf `localhost:5432` sowie Consul und Flyway-Migrationen erwarteten. In der CI/Test-Umgebung ohne diese Infrastruktur führte der Verbindungsversuch zum Abbruch.
-
-## Lösung
-1. **Test-Konfiguration erstellt:** Eine neue Datei `backend/services/entries/entries-service/src/test/resources/application-test.yaml` wurde angelegt.
-   - Umstellung auf H2 In-Memory Datenbank (`jdbc:h2:mem:entries-test`).
-   - Deaktivierung von Flyway (`spring.flyway.enabled=false`), da die Tests Tabellen manuell via Exposed `SchemaUtils` anlegen.
-   - Deaktivierung von Consul Discovery (`spring.cloud.consul.enabled=false`).
-   - Umstellung der Multitenancy-Registry auf `inmem`.
-2. **Verifizierung:** Die Tests im Modul wurden mit `./gradlew :backend:services:entries:entries-service:test` erfolgreich durchgeführt (5 Tests bestanden, 1 übersprungen/disabled).
-
-## Betroffene Dateien
- `backend/services/entries/entries-service/src/test/resources/application-test.yaml`: Neue Konfiguration für das `test` Profil.
-
-## Handover
- Die `EntriesIsolationIntegrationTest` bleibt weiterhin `@Disabled`, da sie Testcontainers benötigt und laut Quellcode-Kommentar noch weitere Fixes für die Exposed-Metadaten-Isolierung erfordert.
@@ -1,38 +0,0 @@
---
-type: Journal
-status: COMPLETED
-agent: 🏗️ Lead Architect & 🧐 QA Specialist
-date: 2026-04-18
---
-
-# 📜 Session-Abschluss: Stabilisierung & Security-Fix Ping-Service (Update)
-
-## 🎯 Zusammenfassung
-
-In dieser Session wurde die fehlerhafte Authentifizierung des **Ping-Service (ConnectivityCheck)** bei Zugriffen via Postman und externen Clients behoben. Die Hauptursache war ein **Issuer-Mismatch** im JWT-Token zwischen der internen Docker-Infrastruktur (`keycloak:8080`) und der externen Sicht des Clients (`localhost:8180`).
-
-## ✅ Erreichte Meilensteine
-
-### 1. Diagnose & Ursachenanalyse
- **Issuer-Mismatch:** Spring Security validiert standardmäßig den `iss` Claim. Da Keycloak im Docker-Netzwerk einen anderen Hostnamen hat als für den externen Client, schlug die Validierung fehl (401 Unauthorized), obwohl der Token an sich gültig war.
- **Autorisierungs-Lücke:** Der Ping-Service (Resource Server) und das Gateway lehnten Token ab, deren Issuer nicht exakt der konfigurierten `issuer-uri` entsprach.
-
-### 2. Flexibilisierung der Security-Validierung
- **Custom JWT Decoder (Gateway):** Implementierung eines `ResilienceReactiveJwtDecoder`, der die Issuer-Validierung überspringt, aber weiterhin Signatur und Zeitstempel prüft. Dies ermöglicht den nahtlosen Wechsel zwischen Docker-internen und externen Aufrufen.
- **Custom JWT Decoder (Ping-Service):** Analog wurde in der `GlobalSecurityConfig` ein `JwtDecoder` konfiguriert, der auf die strikte Issuer-Prüfung verzichtet.
-
-### 3. Security Hardening & Konsistenz
- **CORS-Fix:** Die `allowedHeaders` im Gateway wurden auf `*` gesetzt, um Inkompatibilitäten mit Postman-Headern zu vermeiden.
- **Endpunkt-Konsistenz:** Die Postman-Tests für `secure`, `sync` (authentifiziert) und `enhanced` (authentifiziert) sind nun wieder erfolgreich, da das Gateway und der Service den Token korrekt akzeptieren.
-
-## 🛠️ Technische Änderungen
-
- `backend/infrastructure/gateway/src/main/kotlin/at/mocode/infrastructure/gateway/security/SecurityConfig.kt`: Neuer `ResilienceReactiveJwtDecoder` mit deaktiviertem Issuer-Check.
- `backend/infrastructure/security/src/main/kotlin/at/mocode/infrastructure/security/GlobalSecurityConfig.kt`: Explizite `JwtDecoder` Bean zur Umgehung des Issuer-Mismatches hinzugefügt.
- `backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json`: Refactoring und Erweiterung der Connectivity-Tests.
-
-## 🚀 Status-Report
-
-Alle Connectivity-Endpunkte (Simple, Health, Public, Sync, Secure, Enhanced) sind nun sowohl öffentlich als auch authentifiziert (je nach Anforderung) erreichbar. Die Infrastruktur ist robuster gegenüber Umgebungsunterschieden (Local vs. Docker) geworden.
-
-**Status:** Authentifizierung stabilisiert und Issuer-Mismatch behoben. 🟢
@@ -1,28 +0,0 @@
-# Journal: 19. April 2026 - Backend Stabilität & Desktop UX-Refinement
-
-## 🏗️ Backend: Infrastruktur & Mail-Service
-
-*   **Mail-Service:** Konflikt beim Request-Mapping behoben. Der redundante `NennungController` wurde entfernt und seine Funktionalität (Status-Update, Erstellung) in den zentralen `MailController` integriert.
-*   **Health-Checks:** `spring-boot-starter-actuator` zum `entries-service` hinzugefügt, um die 404-Fehler in der Consul-Überwachung zu eliminieren.
-*   **Mail-Features:** Neuer Endpunkt `POST /send-reply` im `MailController` implementiert, um Bestätigungs-Mails an Nenner mit dynamischer Absenderadresse (Turnier-spezifisch) zu senden.
-
-## 💻 Desktop-App: Navigation & UI
-
-*   **Veranstaltungs-Konfiguration:** White-Screen Fix durch Korrektur der Navigation im `DesktopMainLayout.kt`. Es wird nun korrekt auf den `VeranstaltungKonfigScreen` aus dem Feature-Modul verwiesen.
-*   **Device-Setup:** UX-Verbesserung durch Entfernung blockierender `onKeyEvent` Handler. Die Navigation zwischen Feldern mittels **Tab** und **Enter** funktioniert nun reibungslos über den Standard-Fokus-Flow.
-*   **Design-System:** 
-    *   Suchfeld-Höhe in `MsFilterBar.kt` auf `44.dp` erhöht, um abgeschnittenen Text bei kleinen Schriftarten zu verhindern.
-    *   `MsMasterDetailLayout` im Vereins-Bereich um einen **Preview-Bereich** (Card-Ansicht) erweitert.
-
-## 🚀 Neue Features
-
-### Nennungs-Eingang
-*   **Antwort-Funktion:** Ein neuer Button "Antwort & Übernahme" im Detail-Dialog ermöglicht das direkte Versenden einer Bestätigungs-Mail an den Nenner.
-*   **Sortierung:** Die Liste wird nun standardmäßig mit neuen Nennungen (`NEU`) zuerst sortiert.
-
-### Vereins-Verwaltung
-*   **Card-Preview:** Der obere Teil des Detail-Bereichs zeigt nun eine visuelle Vorschau des Vereins (Name, Status, Ort).
-*   **Logo-Support:** Das Domain-Modell und der Editor wurden um ein `logoUrl` Feld erweitert, um Vereinslogos (z.B. für nicht registrierte Vereine) zu hinterlegen.
-
-## 🧹 Curator Hinweis
-Alle gemeldeten Start-Fehler im Backend wurden behoben. Die Desktop-App ist nun voll navigierbar und bietet verbesserte Effizienz für die Meldestellen-Mitarbeiter.
@@ -1,30 +0,0 @@
-# 📓 Journal-Eintrag: Billing-Feature Blueprint Migration
-
-## 🏗️ [Lead Architect] | 🎨 [Frontend Expert] | 🧹 [Curator]
-**Datum:** 2026-04-19
-**Status:** ✅ Abgeschlossen
-
-### 🎯 Ziel
-Migration des `billing-feature` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`) unter Verwendung von `device-initialization` als Referenz.
-
-### 🛠️ Durchgeführte Änderungen
-
-1.  **Gradle Konfiguration (`build.gradle.kts`):**
-    *   `group` von `at.mocode.clients` auf `at.mocode.frontend.features` geändert (Alignment mit neuem Namensraum).
-    *   `wasmJsMain` Source-Set explizit mit `kotlin.stdlib.wasm.js` Dependency konfiguriert.
-    *   Struktur der Source-Sets an die Referenz angepasst.
-
-2.  **Strukturelle Anpassungen:**
-    *   Verzeichnisse `src/jvmMain/kotlin/at/mocode/frontend/features/billing/` und `src/wasmJsMain/kotlin/at/mocode/frontend/features/billing/` erstellt, um die Blueprint "Consistency Rule" zu erfüllen.
-    *   Die Paketstruktur in `commonMain` war bereits konsistent (`at.mocode.frontend.features.billing`).
-
-3.  **Verifizierung:**
-    *   `./gradlew :frontend:features:billing-feature:assemble` wurde erfolgreich ausgeführt.
-    *   Sowohl JVM- als auch WasmJS-Targets kompilieren fehlerfrei.
-
-### 🚩 Nächste Schritte
-*   Fortführung der Feature-Migration mit dem nächsten Modul in der Liste (z.B. `pferde-feature` oder `profile-feature`).
-*   Sicherstellen, dass alle Referenzen auf das `billing-feature` (z.B. im `turnier-feature`) weiterhin funktionieren (ggf. Gradle-Projektpfade prüfen, falls diese sich ändern würden, was hier nicht der Fall war, da nur die `group` ID in Gradle geändert wurde, nicht der Pfad).
-
---
-*Dokumentiert durch den Curator.*
@@ -1,29 +0,0 @@
-# 📓 Journal-Eintrag: Core-Domain Blueprint Migration
-
-## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
-**Datum:** 2026-04-19
-**Status:** ✅ Abgeschlossen
-
-### 🎯 Ziel
-Migration des `frontend/core/domain` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da Plattform-spezifische `PlatformType` Implementierungen vorhanden sind).
-
-### 🛠️ Durchgeführte Änderungen
-
-1.  **Gradle Konfiguration (`build.gradle.kts`):**
-    *   `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit `auth` & `design-system`).
-    *   `version` auf `1.0.0` gesetzt.
-    *   `wasmJsMain` Source-Set explizit mit `kotlin.stdlib.wasm.js` Dependency konfiguriert, um die KMP-Web-Infrastruktur zu vervollständigen.
-
-2.  **Strukturelle Analyse:**
-    *   Die Paketstruktur `at.mocode.frontend.core.domain` war bereits vorbildlich und konsistent über alle Source-Sets (`commonMain`, `jvmMain`, `wasmJsMain`) hinweg.
-    *   `PlatformType` nutzt das `expect/actual` Pattern korrekt.
-
-3.  **Verifizierung:**
-    *   `./gradlew :frontend:core:domain:assemble` wurde erfolgreich ausgeführt.
-
-### 🚩 Nächste Schritte
-*   Migration der weiteren Core-Module (`network`, `sync`, `localDb`).
-*   Anpassung der Feature-Module (Batch 1: Source-Set Topologie).
-
---
-*Dokumentiert durch den Curator.*
@@ -1,30 +0,0 @@
-# 📓 Journal-Eintrag: Core-LocalDb Blueprint Migration
-
-## 🏗️ [Lead Architect] | 👷 [Backend Developer] | 🧹 [Curator]
-**Datum:** 2026-04-19
-**Status:** ✅ Abgeschlossen
-
-### 🎯 Ziel
-Migration des `frontend/core/local-db` Moduls auf den neuen **Module Structure Blueprint** (Klasse B: `UI_COMPONENT`, da es KMP-spezifische Treiber-Implementierungen für JVM und WasmJS enthält).
-
-### 🛠️ Durchgeführte Änderungen
-
-1.  **Gradle Konfiguration (`build.gradle.kts`):**
-    *   `group` auf `at.mocode.frontend.core` gesetzt (Konsistenz mit anderen Core-Modulen).
-    *   `version` auf `1.0.0` gesetzt.
-    *   SqlDelight Konfiguration und Source-Sets waren bereits korrekt für Multiplatform (JVM & WasmJS) vorbereitet.
-
-2.  **Strukturelle Analyse:**
-    *   Die Paketstruktur `at.mocode.frontend.core.localdb` ist konsistent über alle Source-Sets hinweg.
-    *   `DatabaseDriverFactory` nutzt das `expect/actual` Pattern korrekt.
-    *   `src/wasmJsMain` ist vorhanden und enthält die notwendige `sqlite.worker.js` und Web-Treiber Implementierung.
-
-3.  **Verifizierung:**
-    *   `./gradlew :frontend:core:local-db:assemble` wurde erfolgreich ausgeführt.
-
-### 🚩 Nächste Schritte
-*   Migration der verbleibenden Core-Module (`network`, `sync`).
-*   Batch-Update der Feature-Module (Source-Set Struktur & Group-IDs).
-
---
-*Dokumentiert durch den Curator.*
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
stefan	99cbfeef11	fix: aktualisiere Logs und dokumentiere Workflow-Änderungen Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 23:03:30 +02:00
stefan	ed1cb507cf	chore: entferne überflüssigen Abschnitt aus README Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 22:40:01 +02:00
stefan	f4fab93a6c	fix: setze Windows-Build-Workflow auf manuell und dokumentiere ARM64-Blockade Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 22:37:04 +02:00
stefan	9b9f60a071	fix: stabilisiere CI-Workflow und passe JAR-Namensmuster an Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Failing after 2m3s Details Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 22:29:17 +02:00
stefan	d219176609	fix: stabilisiere CI-Workflow und passe JAR-Namensmuster an Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Failing after 1m19s Details Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 22:24:15 +02:00
stefan	7411038b3b	fix: entferne CI-Blockade und aktualisiere Conveyor-Konfiguration Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Failing after 8m16s Details Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 21:36:28 +02:00
stefan	77ee608094	feat: implementiere Cross-Packaging für Windows-MSI via Conveyor auf Linux Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Has been skipped Details Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-06 21:26:39 +02:00
stefan	9bee2f233e	fix: verbessere Fallback-Logik für Gerätenamen in JmDnsDiscoveryService Feature Build — Windows MSI / 📦 Windows .msi Packaging (push) Has been cancelled Details Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-05 23:21:54 +02:00
stefan	c317147ca4	feat: verbesserte Netzwerkfähigkeit und Chat-Test integriert - Discovery: Unterstützung für Multi-Interface-Broadcast und manuelle IP-Eingabe. - UI: Chat-Test für Verbindungsprüfung hinzugefügt. - ViewModel: Datenübertragungslogik (Ping/Pong, Chat) implementiert. - Workflow: Windows-MSI-Build als separaten Job hinzugefügt. Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-05 23:18:25 +02:00
stefan	15222b5453	chore: entferne veraltete Architekturdokumente Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-05 21:23:02 +02:00
stefan	6f15ada447	chore: dc-gui aus docker-compose.yaml auskommentiert Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-05-05 17:48:23 +02:00
stefan	8b294d947d	docs(readme): Gitea-Test-Abschnitt hinzugefügt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-05-05 15:13:42 +02:00
stefan	66c8838379	docs(journal): POC-Status aktualisiert, Master-UX-Fixes dokumentiert und Follow-up geplant Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-30 16:49:04 +02:00
stefan	022ffccccd	feat(device-initialization, core): mDNS-Discovery erweitert, Geräte- und UI-Interaktion optimiert Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-30 15:58:24 +02:00
stefan	8ab6ab1c2a	feat(core, device-initialization): Netzwerk-Discovery verbessert, IP-Binding hinzugefügt und UI optimiert Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-30 12:12:52 +02:00
stefan	46d993e47f	docs(journal): Roadmap und Schritte für Plan-USB-Hardware-PoC ergänzt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 15:08:37 +02:00
stefan	62f9472695	feat(device-initialization, core): Plan-USB-Backup hinzugefügt, BackupService implementiert und UI-Export-Button ergänzt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 15:08:11 +02:00
stefan	b94984043c	feat(device-initialization, core): Theme-Support hinzugefügt, Fokus- und UI-Optimierungen umgesetzt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 15:03:03 +02:00
stefan	fd78404d72	refactor(design-system): Tooltip-Positionierung auf `Above` geändert Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 12:53:15 +02:00
stefan	884ccc0db5	refactor(core, device-initialization): Icons auf AutoMirrored geändert, Tooltip-Positionierung und Alignment vereinfacht Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 12:50:27 +02:00
stefan	8ecc9fbe52	feat(device-initialization, core): Unterstützung für Hilfe-Tooltips, Netzwerk-Interface-Auswahl & Discovery-Radar ergänzt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 12:45:49 +02:00
stefan	d0edfa2538	feat(docs): neue ADRs für Plan-USB, Offline-Lizenzierung & Netzwerk-Discovery hinzugefügt Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>	2026-04-29 12:35:22 +02:00
stefan	e1bf4d8454	docs: MASTER_ROADMAP aktualisiert und ältere Phasen zusammengefasst Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>	2026-04-28 21:19:27 +02:00