docs: massive restructuring of documentation, development guides and agent playbooks

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

.ai/dist/gemini-system-prompt.md

@@ -0,0 +1,41 @@
+## 🚀 Identität & Arbeitsmodus (Chamäleon-Modus)
+Du bist ein hochqualifizierter KI-Assistent für das Softwareprojekt "Meldestelle" von Stefan.
+Ich weise dir in meinen Prompts Aufgaben zu. Nimm sofort die entsprechende Rolle an, beginne deine Antwort zwingend mit dem passenden Badge und passe dein Vokabular an:
+
+* 🏗️ **[Lead Architect]:** System-Design, Gradle-Build-Logik, Modulstruktur.
+* 📜 **[Rulebook Expert]:** Validiert Business-Rules gegen das ÖTO/FEI Regelwerk.
+* 👷 **[Backend Developer]:** Kotlin & Spring Boot Experte.
+* 🎨 **[Frontend Expert]:** KMP & Compose Desktop Spezialist.
+* 🐧 **[DevOps Engineer]:** Infrastruktur (Docker, CI/CD, Proxmox).
+
+**Arbeitsanweisung:** Bearbeite pro Antwort immer nur EINE fachliche Aufgabe.
+
+
+
+## 🏗️ Projekt-Strategie (Reality-Reset)
+1. **Desktop-First & Offline-First:** Das Primärziel ist eine autarke Compose Desktop App (KMP). Sie muss auf Turnieren ohne Internet funktionieren (lokale Persistenz).
+2. **Optionales Backend:** Ein Spring Boot Stack (PostgreSQL, Valkey, Keycloak) wird nur für Multi-Tenant-Verwaltung, Registrierung und P2P-Sync genutzt.
+3. **Domain-Driven Design (DDD):** Die absolute Business-Hierarchie lautet: Veranstaltung -> Turnier -> Bewerb/Abteilung.
+4. **Der System-Akteur:** Der primäre "Actor" in allen Use-Cases ist *nicht* der Veranstalter, sondern zwingend die Person, die die Meldestelle betreut (Actor = Meldestelle).
+
+
+
+## 🛠️ Der verbindliche Tech-Stack
+Generiere Code ausschließlich für diese exakten Versionen und Paradigmen:
+* **Frontend (KMP):** Kotlin 2.3.21, Compose Multiplatform 1.10.3, Ktor Client 3.4.1, SQLDelight.
+* **Backend:** Spring Boot 3.5.9 (JDK 25), Ktor Server (wo spezifiziert), Exposed 1.1.1.
+* **Infrastruktur:** Gitea (CI/CD), Docker, Pangolin Tunnel. (KEIN GitHub, KEIN Cloudflare).
+
+
+
+## 👁️ Anti-Halluzinations-Protokoll
+Du bist an strikte, evidenzbasierte Entwicklung gebunden:
+1. **Kein "Erledigt" ohne Beweis:** Ein Task ist erst abgeschlossen, wenn Test-Logs oder ein Build vorliegen.
+2. **Verifikation ausstehend:** Generierter, ungetesteter Code muss diesen Vermerk zwingend tragen.
+3. **Fakten-Check:** Wenn du den Code nicht im Kontext hast (z.B. eine spezifische Gradle-Datei), fordere sie aktiv vom User an, anstatt blind zu raten.
+
+
+
+## ⚙️ Provider-Spezifika (Google Gemini / Web-Meta-Modus)
+* Du agierst als "Gemini" über die Web-Oberfläche. Deine primäre Aufgabe ist die strategische Meta-Ebene, Architektur-Analyse, Review von CI/CD-Pipelines und das Sparring bei komplexen Refactoring-Plänen.
+* **Antwort-Stil:** Antworte prägnant, strukturiert und nutze das bereitgestellte Formatierungstoolkit (Markdown, klare Hierarchien, Code-Blöcke). Vermeide unnötige Floskeln und komm direkt auf den technischen Punkt.

.ai/dist/junie-system-prompt.md

@@ -0,0 +1,34 @@
+## 🚀 Identität & Arbeitsmodus (Chamäleon-Modus)
+Du bist ein hochqualifizierter KI-Assistent für das Softwareprojekt "Meldestelle" von Stefan.
+Ich weise dir in meinen Prompts Aufgaben zu. Nimm sofort die entsprechende Rolle an, beginne deine Antwort zwingend mit dem passenden Badge und passe dein Vokabular an:
+
+* 🏗️ **[Lead Architect]:** System-Design, Gradle-Build-Logik, Modulstruktur.
+* 📜 **[Rulebook Expert]:** Validiert Business-Rules gegen das ÖTO/FEI Regelwerk.
+* 👷 **[Backend Developer]:** Kotlin & Spring Boot Experte.
+* 🎨 **[Frontend Expert]:** KMP & Compose Desktop Spezialist.
+* 🐧 **[DevOps Engineer]:** Infrastruktur (Docker, CI/CD, Proxmox).
+
+**Arbeitsanweisung:** Bearbeite pro Antwort immer nur EINE fachliche Aufgabe.
+
+## 🏗️ Projekt-Strategie (Reality-Reset)
+1. **Desktop-First & Offline-First:** Das Primärziel ist eine autarke Compose Desktop App (KMP). Sie muss auf Turnieren ohne Internet funktionieren (lokale Persistenz).
+2. **Optionales Backend:** Ein Spring Boot Stack (PostgreSQL, Valkey, Keycloak) wird nur für Multi-Tenant-Verwaltung, Registrierung und P2P-Sync genutzt.
+3. **Domain-Driven Design (DDD):** Die absolute Business-Hierarchie lautet: Veranstaltung -> Turnier -> Bewerb/Abteilung.
+4. **Der System-Akteur:** Der primäre "Actor" in allen Use-Cases ist *nicht* der Veranstalter, sondern zwingend die Person, die die Meldestelle betreut (Actor = Meldestelle).
+
+## 🛠️ Der verbindliche Tech-Stack
+Generiere Code ausschließlich für diese exakten Versionen und Paradigmen:
+* **Frontend (KMP):** Kotlin 2.3.21, Compose Multiplatform 1.10.3, Ktor Client 3.4.1, SQLDelight.
+* **Backend:** Spring Boot 3.5.9 (JDK 25), Ktor Server (wo spezifiziert), Exposed 1.1.1.
+* **Infrastruktur:** Gitea (CI/CD), Docker, Pangolin Tunnel. (KEIN GitHub, KEIN Cloudflare).
+
+## 👁️ Anti-Halluzinations-Protokoll
+Du bist an strikte, evidenzbasierte Entwicklung gebunden:
+1. **Kein "Erledigt" ohne Beweis:** Ein Task ist erst abgeschlossen, wenn Test-Logs oder ein Build vorliegen.
+2. **Verifikation ausstehend:** Generierter, ungetesteter Code muss diesen Vermerk zwingend tragen.
+3. **Fakten-Check:** Wenn du den Code nicht im Kontext hast (z.B. eine spezifische Gradle-Datei), fordere sie aktiv vom User an, anstatt blind zu raten.
+
+## ⚙️ Provider-Spezifika (JetBrains Junie / IDE-Modus)
+* Dein Name ist "Junie". Du arbeitest als hochintegrierter KI-Assistent direkt innerhalb von IntelliJ IDEA.
+* **Kontext-Fokus:** Nutze die lokalen Projektdateien, Indizes und das Git-Log intensiv. Wenn Refactorings oder Code-Generierungen anstehen, achte penibel darauf, dass bestehende Datei-Imports (Kotlin-Packages) nicht zerschossen werden.
+* **Generierungs-Gate:** Halte dich strikt an die im Projekt hinterlegten Formatierungsregeln für Detekt und Ktlint.

.gitignore

@@ -56,3 +56,7 @@ desktop.ini
 docs/temp/
 docs/Bin/
 docs/_archive/
+
+# Conveyor
+conveyor.rootkey
+output/

AGENTS.md

@@ -3,7 +3,7 @@
 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 (Reality-Reset 28.04.2026)
+## 🚀 Strategische Ausrichtung (Reality-Reset 15.06.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.
@@ -17,21 +17,21 @@ abgeschlossene Phasen ohne entsprechende Implementierung sind untersagt.
 Jede Agenten-Antwort **muss** mit dem entsprechenden Badge beginnen, um den Kontext und die Verantwortlichkeit zu klären.
 
 *   **🏗️ [Lead Architect]**: Hüter der **MASTER_ROADMAP**. Verantwortlich für System-Design, Build-Logik (Gradle), Modulstruktur und ADRs.
-    *   [Playbook](docs/04_Agents/Playbooks/Architect.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/Architect.md)
 *   **📜 [Rulebook Expert]**: Wächter über **ÖTO & FEI**. Validiert Business-Rules gegen das offizielle Pferdesport-Regelwerk.
-    *   [Playbook](docs/04_Agents/Playbooks/RulebookExpert.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/RulebookExpert.md)
 *   **👷 [Backend Developer]**: Kotlin & Spring Boot Experte. Fokus auf DDD, Persistenz (Postgres) und **Delta-Sync APIs**.
-    *   [Playbook](docs/04_Agents/Playbooks/BackendDeveloper.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/BackendDeveloper.md)
 *   **🎨 [Frontend Expert]**: KMP & Compose Desktop Spezialist. Implementiert State-Management und High-Performance UI.
-    *   [Playbook](docs/04_Agents/Playbooks/FrontendExpert.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/FrontendExpert.md)
 *   **🖌️ [UI/UX Designer]**: "Toolsmith" für High-Density Enterprise-UIs. Fokus auf Tastatur-Bedienbarkeit und Effizienz.
-    *   [Playbook](docs/04_Agents/Playbooks/UIUXDesigner.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/UIUXDesigner.md)
 *   **🐧 [DevOps Engineer]**: Infrastruktur-Automatisierung (Docker, Gitea-Actions). Fokus auf Stabilität und lokale Dev-Umgebung.
-    *   [Playbook](docs/04_Agents/Playbooks/DevOpsEngineer.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/DevOpsEngineer.md)
 *   **🧐 [QA Specialist]**: Test-Stratege (Shift-Left). Fokus auf Unit-, Integration- und Edge-Case-Tests (Testing Pyramid).
-    *   [Playbook](docs/04_Agents/Playbooks/QASpecialist.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/QASpecialist.md)
 *   **🧹 [Curator]**: Wissens-Management & Dokumentations-Check (ADR, Reference, Journal). Beendet jede Session.
-    *   [Playbook](docs/04_Agents/Playbooks/Curator.md)
+    *   [Playbook](docs/05_Governance/Agents/Playbooks/Curator.md)
 
 ## 2. Der "Meldestelle"-Workflow
 1.  **Kontext-Check:** Lies immer zuerst die `MASTER_ROADMAP` in `docs/01_Architecture/`.

README.md

@@ -20,7 +20,7 @@ Die gesamte Projektdokumentation (Architektur, Fachdomäne, Entwickler-Anleitung
 | [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)
+Wesentliche Architektur-Referenz: [Offline‑First Desktop & Backend (Kurzkonzept)](./docs/01_Architecture/Concepts/konzept-offline-first-desktop-backend-de.md)
 
 ---
 
@@ -113,3 +113,9 @@ Beiträge sind willkommen. Bitte lies zunächst die Entwickler-Guides unter [`do
 ## 📜 Lizenz
 
 Dieses Projekt steht unter der [MIT License](LICENSE).
+
+---
+
+## Test
+
+Das ist der 2. Versuch über Remote zu Committen 

backend/infrastructure/cache/valkey-cache/src/test/kotlin/at/mocode/infrastructure/cache/valkey/ValkeyDistributedCachePerformanceTest.kt

@@ -8,7 +8,7 @@ import io.valkey.springframework.data.valkey.core.ValkeyTemplate
 import io.valkey.springframework.data.valkey.serializer.StringValkeySerializer
 import kotlinx.coroutines.joinAll
 import kotlinx.coroutines.launch
-import kotlinx.coroutines.test.runTest
+import kotlinx.coroutines.runBlocking
 import org.junit.jupiter.api.BeforeEach
 import org.junit.jupiter.api.Test
 import org.testcontainers.containers.GenericContainer
@@ -70,7 +70,7 @@ class ValkeyDistributedCachePerformanceTest {
   }
 
   @Test
-  fun `test cache performance with high concurrent access`() = runTest {
+  fun `test cache performance with high concurrent access`() = runBlocking {
     logger.info { "Starting concurrent access test" }
     val numberOfCoroutines = 100
     val operationsPerCoroutine = 50

backend/infrastructure/gateway/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/infrastructure/zns-importer/src/main/kotlin/at/mocode/zns/importer/ZnsImportService.kt

@@ -2,6 +2,7 @@
 
 package at.mocode.zns.importer
 
+import at.mocode.core.domain.model.ReiterLizenz
 import at.mocode.masterdata.domain.repository.*
 import at.mocode.zns.parser.ZnsFunktionaerParser
 import at.mocode.zns.parser.ZnsPferdParser

backend/services/billing/billing-service/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/entries/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/events/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/mail/Dockerfile

@@ -4,8 +4,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/masterdata/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/masterdata/masterdata-domain/src/commonMain/kotlin/at/mocode/masterdata/domain/model/Reiter.kt

@@ -3,6 +3,7 @@
 package at.mocode.masterdata.domain.model
 
 import at.mocode.core.domain.model.DatenQuelleE
+import at.mocode.core.domain.model.ReiterLizenz
 import at.mocode.core.domain.model.ReiterLizenzKlasseE
 import at.mocode.core.domain.serialization.InstantSerializer
 import at.mocode.core.domain.serialization.LocalDateSerializer
@@ -14,16 +15,6 @@ import kotlin.time.Clock
 import kotlin.time.Instant
 import kotlin.uuid.Uuid
 
-@Serializable
-data class ReiterLizenz(
-  @Serializable(with = UuidSerializer::class)
-  val lizenzId: Uuid = Uuid.random(),
-  val lizenzTyp: String, // STARTKARTE, REITERLIZENZ, FAHRLIZENZ
-  val kuerzel: String,
-  @Serializable(with = LocalDateSerializer::class)
-  val gueltigBis: LocalDate? = null
-)
-
 /**
  * Domain model representing a rider (Reiter) in the actor-context.
  *

backend/services/masterdata/masterdata-infrastructure/src/main/kotlin/at/mocode/masterdata/infrastructure/persistence/reiter/ReiterExposedRepository.kt

@@ -4,10 +4,10 @@ package at.mocode.masterdata.infrastructure.persistence.reiter
 
 import at.mocode.core.domain.model.DatenQuelleE
 import at.mocode.core.domain.model.ReiterAltersKlasseE
+import at.mocode.core.domain.model.ReiterLizenz
 import at.mocode.core.domain.model.ReiterLizenzKlasseE
 import at.mocode.core.utils.database.DatabaseFactory
 import at.mocode.masterdata.domain.model.Reiter
-import at.mocode.masterdata.domain.model.ReiterLizenz
 import at.mocode.masterdata.domain.repository.ReiterRepository
 import org.jetbrains.exposed.v1.core.ResultRow
 import org.jetbrains.exposed.v1.core.and

backend/services/ping/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/results/results-service/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/scheduling/scheduling-service/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/series/series-service/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

backend/services/zns-import/Dockerfile

@@ -5,8 +5,8 @@
 # ===================================================================
 
 # === CENTRALIZED BUILD ARGUMENTS ===
-ARG GRADLE_VERSION=9.4.1
-ARG JAVA_VERSION=25
+ARG GRADLE_VERSION=9.5.0
+ARG JAVA_VERSION=25.0.2
 ARG BUILD_DATE
 ARG VERSION=1.0.0-SNAPSHOT
 

build.gradle.kts

@@ -38,7 +38,7 @@ plugins {
 // ###                  ALLPROJECTS CONFIGURATION                 ###
 // ##################################################################
 
-val isWasmEnabled = findProperty("enableWasm")?.toString()?.toBoolean() ?: false
+val isWasmEnabled: Boolean = findProperty("enableWasm")?.toString()?.toBoolean() ?: false
 
 // ---------------------------------------------------------------
 // Zentrale Versionierung — liest version.properties (SemVer)
@@ -47,10 +47,10 @@ val versionProps =
   java.util.Properties().also { props ->
     rootProject.file("version.properties").inputStream().use { props.load(it) }
   }
-val vMajor = versionProps.getProperty("VERSION_MAJOR", "1")
-val vMinor = versionProps.getProperty("VERSION_MINOR", "0")
-val vPatch = versionProps.getProperty("VERSION_PATCH", "0")
-val vQualifier = versionProps.getProperty("VERSION_QUALIFIER", "").trim()
+val vMajor: String = versionProps.getProperty("VERSION_MAJOR", "1")
+val vMinor: String = versionProps.getProperty("VERSION_MINOR", "0")
+val vPatch: String = versionProps.getProperty("VERSION_PATCH", "0")
+val vQualifier: String = versionProps.getProperty("VERSION_QUALIFIER", "").trim()
 val semVer = if (vQualifier.isBlank()) "$vMajor.$vMinor.$vPatch" else "$vMajor.$vMinor.$vPatch-$vQualifier"
 
 allprojects {
@@ -90,7 +90,7 @@ subprojects {
     jvmArgs("--add-opens=java.base/java.nio=ALL-UNNAMED")
     // Suppress ByteBuddy/Mockito dynamic agent loading warnings (Java 21+)
     jvmArgs("-XX:+EnableDynamicAgentLoading")
-    // Increase test JVM memory with a stable configuration
+    jvmArgs("--enable-native-access=ALL-UNNAMED")
     minHeapSize = "512m"
     maxHeapSize = "2g"
     // Parallel test execution for better performance
@@ -113,7 +113,7 @@ subprojects {
   // (A) Source map configuration is handled via `gradle.properties` (global Kotlin/JS settings)
   // to avoid compiler-flag incompatibilities across toolchains.
 
-  // (B) Conditional Wasm/JS Target handling based on `enableWasm` property
+  // (B) Conditional Wasm/JS Target handling based on the ` enableWasm ` property
   // This significantly reduces build times during Desktop development.
   // Flag is defined at the beginning of the script.
 
@@ -166,6 +166,7 @@ subprojects {
       jvmArgs("-Xshare:auto", "-Djdk.instrument.traceUsage=false")
       jvmArgs("--add-opens=java.base/java.nio=ALL-UNNAMED")
       jvmArgs("-XX:+EnableDynamicAgentLoading")
+      jvmArgs("--enable-native-access=ALL-UNNAMED")
       maxHeapSize = "2g"
       dependsOn("testClasses")
     }
@@ -175,20 +176,30 @@ subprojects {
   // Applies to all Exec-based tasks (covers Yarn/NPM invocations used by Kotlin JS plugin)
   tasks.withType<Exec>().configureEach {
     // Merge existing NODE_OPTIONS with --no-deprecation
-    val current = (environment["NODE_OPTIONS"] as String?) ?: System.getenv("NODE_OPTIONS")
-    val merged = if (current.isNullOrBlank()) "--no-deprecation" else "$current --no-deprecation"
+    val current: String? = (environment["NODE_OPTIONS"] as String?) ?: System.getenv("NODE_OPTIONS")
+    val merged: String = if (current.isNullOrBlank()) "--no-deprecation" else "$current --no-deprecation"
     environment("NODE_OPTIONS", merged)
     // Also set the legacy switch to silence warnings entirely
     environment("NODE_NO_WARNINGS", "1")
     // Set a Chrome binary path to avoid snap permission issues
-    environment("CHROME_BIN", "/usr/bin/google-chrome-stable")
-    environment("CHROMIUM_BIN", "/usr/bin/chromium")
-    environment("PUPPETEER_EXECUTABLE_PATH", "/usr/bin/chromium")
+    if (System.getProperty("os.name").contains("Linux", ignoreCase = true)) {
+      environment("CHROME_BIN", "/usr/bin/google-chrome-stable")
+      environment("CHROMIUM_BIN", "/usr/bin/chromium")
+      environment("PUPPETEER_EXECUTABLE_PATH", "/usr/bin/chromium")
+    }
   }
 
   // ------------------------------
   // Detekt & Ktlint default setup
   // ------------------------------
+  // PERFORMANCE: Deaktiviert standardmäßig in jedem Build, nur explizit ausführen
+  tasks.withType<Detekt>().configureEach {
+    enabled = project.hasProperty("runStaticAnalysis")
+  }
+  tasks.matching { it.name == "ktlintCheck" }.configureEach {
+    enabled = project.hasProperty("runStaticAnalysis")
+  }
+
   plugins.withId("io.gitlab.arturbosch.detekt") {
     extensions.configure(DetektExtension::class.java) {
       buildUponDefaultConfig = true
@@ -267,7 +278,6 @@ tasks.register("checkBundleBudget") {
     }
 
     shells.forEach { shell ->
-      val key = shell.path.trimStart(':').replace(':', '/') // or use a colon form for budgets keys below
       val colonKey = shell.path.trimStart(':').replace('/', ':').trim() // ensure ":a:b:c"
       // Budgets are keyed by a Gradle path with colons but without leading colon in config for readability
       val budgetKeyCandidates =
@@ -362,8 +372,8 @@ tasks.register("staticAnalysis") {
 
 // Apply Dokka (V2) automatically to Kotlin subprojects
 subprojects {
-  plugins.withId("org.jetbrains.kotlin.jvm") { apply(plugin = "org.jetbrains.dokka") }
-  plugins.withId("org.jetbrains.kotlin.multiplatform") { apply(plugin = "org.jetbrains.dokka") }
+  plugins.withId("org.jetbrains.kotlin.jvm") { pluginManager.apply("org.jetbrains.dokka") }
+  plugins.withId("org.jetbrains.kotlin.multiplatform") { pluginManager.apply("org.jetbrains.dokka") }
 }
 
 // Aggregate tasks to build multi-module docs in Markdown (GFM) and HTML
@@ -372,27 +382,36 @@ val dokkaAll =
   tasks.register("dokkaAll") {
     group = "documentation"
     description = "Builds Dokka (V2) for all modules and aggregates outputs under build/dokka/all"
-    // Trigger Dokka generation in all subprojects that have the Dokka plugin
-    dependsOn(
+    // PERFORMANCE: Nur ausführen wenn explizit gefordert
+    enabled = project.hasProperty("runDokka")
+
+    // Capture required values for configuration cache
+    val rootBuildDir = layout.buildDirectory.get().asFile
+    val subprojectData =
       subprojects
         .filter { it.plugins.hasPlugin("org.jetbrains.dokka") }
-        .map { "${it.path}:dokkaGenerate" },
-    )
+        .map { p ->
+          Triple(p.path, p.name, p.layout.buildDirectory.get().asFile)
+        }
+
+    // Trigger Dokka generation in all subprojects that have the Dokka plugin
+    dependsOn(subprojectData.map { "${it.first}:dokkaGenerate" })
+
     doLast {
-      val dest = layout.buildDirectory.dir("dokka/all").get().asFile
+      val dest = File(rootBuildDir, "dokka/all")
       if (dest.exists()) dest.deleteRecursively()
       dest.mkdirs()
 
       val modules = mutableListOf<Pair<String, String>>()
 
-      subprojects.filter { it.plugins.hasPlugin("org.jetbrains.dokka") }.forEach { p ->
+      subprojectData.forEach { (pPath, pName, pBuildDir) ->
         // Dokka V2 writes into build/dokka/html
-        val outHtml = p.layout.buildDirectory.dir("dokka/html").get().asFile
+        val outHtml = File(pBuildDir, "dokka/html")
         if (outHtml.exists()) {
-          val modulePath = p.path.trimStart(':').replace(':', '/')
+          val modulePath = pPath.trimStart(':').replace(':', '/')
           val targetDir = File(dest, modulePath)
           outHtml.copyRecursively(targetDir, overwrite = true)
-          modules.add(p.name to modulePath)
+          modules.add(pName to modulePath)
         }
       }
 
@@ -451,17 +470,19 @@ tasks.register("docs") {
 // Apply Node warning suppression on root project Exec tasks as well
 // Ensures aggregated Kotlin/JS tasks created at root (e.g., kotlinNpmInstall) inherit the env
 tasks.withType<Exec>().configureEach {
-  val current = (environment["NODE_OPTIONS"] as String?) ?: System.getenv("NODE_OPTIONS")
-  val merged = if (current.isNullOrBlank()) "--no-deprecation" else "$current --no-deprecation"
+  val current: String? = (environment["NODE_OPTIONS"] as String?) ?: System.getenv("NODE_OPTIONS")
+  val merged: String = if (current.isNullOrBlank()) "--no-deprecation" else "$current --no-deprecation"
   environment("NODE_OPTIONS", merged)
   environment("NODE_NO_WARNINGS", "1")
   // Set a Chrome binary path to avoid snap permission issues
-  environment("CHROME_BIN", "/usr/bin/google-chrome-stable")
-  environment("CHROMIUM_BIN", "/usr/bin/chromium")
-  environment("PUPPETEER_EXECUTABLE_PATH", "/usr/bin/chromium")
+  if (System.getProperty("os.name").contains("Linux", ignoreCase = true)) {
+    environment("CHROME_BIN", "/usr/bin/google-chrome-stable")
+    environment("CHROMIUM_BIN", "/usr/bin/chromium")
+    environment("PUPPETEER_EXECUTABLE_PATH", "/usr/bin/chromium")
+  }
 }
 
 tasks.wrapper {
-  gradleVersion = "9.4.1"
+  gradleVersion = "9.5.0"
   distributionType = Wrapper.DistributionType.BIN
 }

conveyor.conf

@@ -1,62 +1,46 @@
-# =============================================================================
-# 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("/stdlib/jdk/21/amazon.conf")
 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 = "1.0.1"
+  description = "ÖTO-konforme Turnier-Meldestelle – Profi Desktop App"
 
-  # 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"
+  # Ziel-Plattformen: Windows und Linux
+  machines = [ windows.amd64, linux.amd64.glibc ]
 
-  # Beschreibung
-  description = "ÖTO-konforme Turnier-Meldestelle – Desktop App"
+  site.base-url = "localhost"
   
-  # 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 werden im Ordner gesucht
   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"
+      "-Xms256m",
+      "-Xmx1024m",
+      "-Dfile.encoding=UTF-8",
+      "--enable-native-access=ALL-UNNAMED"
     ]
   }
 
-  # 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"
+  # JARs aus dem Gradle-Build
+  inputs += "frontend/shells/meldestelle-desktop/build/libs/*.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
   }
+
+  linux {
+      debian.control.depends = "libasound2, libgl1-mesa-glx, libx11-6"
+  }
 }
+
+conveyor.compatibility-level = 22

core/core-domain/src/commonMain/kotlin/at/mocode/core/domain/model/Lizenz.kt

@@ -0,0 +1,19 @@
+@file:OptIn(kotlin.uuid.ExperimentalUuidApi::class)
+
+package at.mocode.core.domain.model
+
+import at.mocode.core.domain.serialization.LocalDateSerializer
+import at.mocode.core.domain.serialization.UuidSerializer
+import kotlinx.datetime.LocalDate
+import kotlinx.serialization.Serializable
+import kotlin.uuid.Uuid
+
+@Serializable
+data class ReiterLizenz(
+  @Serializable(with = UuidSerializer::class)
+  val lizenzId: Uuid = Uuid.random(),
+  val lizenzTyp: String, // STARTKARTE, REITERLIZENZ, FAHRLIZENZ
+  val kuerzel: String,
+  @Serializable(with = LocalDateSerializer::class)
+  val gueltigBis: LocalDate? = null
+)

core/zns-parser/src/commonMain/kotlin/at/mocode/zns/parser/ZnsReiterParser.kt

@@ -1,10 +1,10 @@
 package at.mocode.zns.parser
 
 import at.mocode.core.domain.model.DatenQuelleE
+import at.mocode.core.domain.model.ReiterLizenz
 import at.mocode.core.domain.model.ReiterLizenzKlasseE
 import at.mocode.core.utils.parser.FixedWidthLineReader
 import at.mocode.masterdata.domain.model.Reiter
-import at.mocode.masterdata.domain.model.ReiterLizenz
 import kotlin.uuid.ExperimentalUuidApi
 import kotlin.uuid.Uuid
 

dc-backend.yaml

@@ -12,8 +12,8 @@ services:
       context: .
       dockerfile: backend/infrastructure/gateway/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -102,8 +102,8 @@ services:
       context: .
       dockerfile: backend/services/ping/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -179,8 +179,8 @@ services:
       context: .
       dockerfile: backend/services/masterdata/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -256,8 +256,8 @@ services:
       context: .
       dockerfile: backend/services/events/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -331,8 +331,8 @@ services:
       context: .
       dockerfile: backend/services/zns-import/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -407,8 +407,8 @@ services:
       context: .
       dockerfile: backend/services/results/results-service/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -482,8 +482,8 @@ services:
       context: .
       dockerfile: backend/services/billing/billing-service/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -555,8 +555,8 @@ services:
       context: .
       dockerfile: backend/services/mail/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -627,8 +627,8 @@ services:
       context: .
       dockerfile: backend/services/scheduling/scheduling-service/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:
@@ -700,8 +700,8 @@ services:
       context: .
       dockerfile: backend/services/series/series-service/Dockerfile
       args:
-        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.4.1}"
-        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25}"
+        GRADLE_VERSION: "${DOCKER_GRADLE_VERSION:-9.5.0}"
+        JAVA_VERSION: "${DOCKER_JAVA_VERSION:-25.0.2}"
         VERSION: "${DOCKER_VERSION:-1.0.0-SNAPSHOT}"
         BUILD_DATE: "${DOCKER_BUILD_DATE}"
     labels:

docs/01_Architecture/MASTER_ROADMAP.md

@@ -2,12 +2,12 @@
 type: Roadmap
 status: ACTIVE
 owner: Lead Architect
-last_update: 2026-05-06
+last_update: 2026-06-15
 ---
 
 # MASTER ROADMAP: Meldestelle
 
-🏗️ **[Lead Architect]** | 30. April 2026
+🏗️ **[Lead Architect]** | 15. Juni 2026
 
 **Strategisches Ziel:**
 Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
@@ -17,16 +17,16 @@ 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.04.2026):**
+**Aktueller technischer Stand (15.06.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.
 * **Code-Basis:** ✅ Backend (Java 25 / Spring Boot / Kotlin), Frontend (KMP/Compose Desktop).
 * **Domain-Design:** ✅ 6 Bounded Contexts (SCS-Architektur) definiert. Ubiquitous Language erstellt.
-* **Domain-Modelle:** ✅ `Reiter`, `DomNennung`, `DomNennungsTransfer`, `Pferd`, `Funktionaer`, `Verein`,
-  `DomBewerb`, `DomAbteilung`, `DomStartliste`, `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert.
+* **Domain-Modelle:** ✅ `Reiter`, `Nennung`, `NennungsTransfer`, `Pferd`, `Funktionaer`, `Verein`,
+  `Bewerb`, `Abteilung`, `DomStartliste`, `Veranstaltung`, `Turnier`, `Ausschreibung` implementiert.
   Enums ÖTO-konform.
-* **Dokumentation:** ✅ Konsolidiert. ÖTO-Regelwerk-Referenzen (Abteilungs-Schwellenwerte) dokumentiert.
+* **Dokumentation:** 🧹 Sanierung abgeschlossen (5-Säulen-Struktur). Reality-Reset durchgeführt.
 
 ---
 
@@ -88,6 +88,7 @@ Fokus: Physische Implementierung der Turnier-Hierarchie und technisches Onboardi
 *   [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).
+*   [x] **Build-Performance:** WASM standardmäßig deaktiviert, um Desktop-Build-Zeiten zu reduzieren (11.05.2026).
 *   [ ] **PoC Verifikation:** 🔴 **BLOCKIERT** (Log 483: ARM64-Runner inkompatibel mit Conveyor-Binary; Workflow auf
     manuell gesetzt).
 
@@ -154,15 +155,15 @@ Code-Stand.*
 
 | 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`                                         |
+| Ubiquitous Language           | `docs/02_Domain/01_Glossary/Ubiquitous_Language.md`                                          |
+| Abteilungs-Schwellenwerte     | `docs/02_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`          |
+| Warn-Logik-Spezifikation      | `docs/02_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
+| Session Log (DDD)             | `docs/05_Governance/Journal/_archive/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md`      |
+| Infrastruktur                 | `docs/04_Operations/Infrastructure/Zora_System_Architektur.md`                               |
+| Deployment Guide              | `docs/04_Operations/Infrastructure/Guides/Setup_Git_Deployment_Zora.md`                      |
+| Backup Guide                  | `docs/04_Operations/Infrastructure/Guides/Setup_Backup_Zora.md`                              |
 | CI/CD                         | `.gitea/workflows/docker-publish.yaml`                                                       |
-| Agent Playbooks               | `docs/04_Agents/Playbooks/`                                                                  |
+| Agent Playbooks               | `docs/05_Governance/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`                        |

docs/01_Architecture/Reference/Engineering_Moderner_Frontend-Architekturen_01-2026.md

@@ -5,23 +5,23 @@ owner: Lead Architect
 date: 2026-02-02
 ---
 
-# Engineering Moderner Frontend-Architekturen: Kotlin 2.3.0, Compose Multiplatform 1.10.0 und Gradle 9.0 für Modulare Monolithen
+# Engineering Moderner Frontend-Architekturen: Kotlin 2.3.21, Compose Multiplatform 1.10.0 und Gradle 9.5.0 für Modulare Monolithen
 
 Der architektonische Übergang zu modularen Monolithen bietet Unternehmen die Möglichkeit, die Komplexität von
 Microservices zu reduzieren und gleichzeitig eine klare Trennung der Domänenlogik beizubehalten. In Kombination mit
 Kotlin Multiplatform (KMP) für Single Page Applications (SPAs) lässt sich Geschäftslogik effizient über den gesamten
-Stack teilen. Die Einführung von Kotlin 2.3.0, Compose Multiplatform 1.10.0 und Gradle 9.0 stellt dabei neue Best
+Stack teilen. Die Einführung von Kotlin 2.3.21, Compose Multiplatform 1.10.0 und Gradle 9.5.0 stellt dabei neue Best
 Practices für Build-Performance und Deployment auf.
 
 ## 1. Gradle 9.x Optimierung in der CI/CD
 
-Gradle 9.0 führt signifikante Änderungen ein, die speziell für große Multi-Modul-Projekte wie modulare Monolithen
+Gradle 9.5.0 führt signifikante Änderungen ein, die speziell für große Multi-Modul-Projekte wie modulare Monolithen
 optimiert sind.
 
-- **Configuration Cache als Standard:** In Gradle 9.0 ist der Configuration Cache der bevorzugte Ausführungsmodus. Durch
+- **Configuration Cache als Standard:** In Gradle 9.5.0 ist der Configuration Cache der bevorzugte Ausführungsmodus. Durch
   das Caching des Task-Graphen werden nachfolgende Builds erheblich beschleunigt, da die Konfigurationsphase
   übersprungen wird.
-- **Kotlin DSL Script Compilation Avoidance:** Durch den Einsatz von ABI-Fingerprinting erkennt Gradle 9.0, ob
+- **Kotlin DSL Script Compilation Avoidance:** Durch den Einsatz von ABI-Fingerprinting erkennt Gradle 9.5.0, ob
   Änderungen an `.kts`-Dateien die Build-Logik tatsächlich beeinflussen. Nicht-relevante Änderungen (wie Kommentare)
   führen nicht mehr zur Neukompilierung, was die Konfigurationszeit um bis zu 60 % reduzieren kann.
 - **Parallel Configuration Store and Load:** Gradle 8.11 und 9.0 unterstützen das parallele Laden und Speichern von
@@ -74,14 +74,14 @@ Die Wahl des Webservers beeinflusst das Routing und die Performance der Compose
 
 | Komponente	   | Empfehlung                          | 	Vorteil                                               |
 |---------------|-------------------------------------|--------------------------------------------------------|
-| Build-Tool    | 	Gradle 9.0 mit Configuration Cache | Extreme Verkürzung der Konfigurationsphase             |
+| Build-Tool    | 	Gradle 9.5.0 mit Configuration Cache | Extreme Verkürzung der Konfigurationsphase             |
 | CI Caching    | 	Remote Cache Action (Proxy)        | Wiederverwendung von Task-Outputs auf frischen Runnern |
 | Konfiguration | 	Runtime config.json Fetch          | Ein Docker-Image für alle Umgebungen (Dev/Prod)        |
 | Webserver     | 	Caddy oder Nginx                   | Optimiertes SPA-Routing und Web Cache Support          |
 
 ## Fazit
 
-Die Kombination aus Gradle 9.0 und Kotlin 2.3.0 ermöglicht hocheffiziente Build-Pipelines für modulare Monolithen. Durch
+Die Kombination aus Gradle 9.5.0 und Kotlin 2.3.21 ermöglicht hocheffiziente Build-Pipelines für modulare Monolithen. Durch
 den Einsatz von Multi-Stage Docker-Builds und dem `config.json`-Fetch-Muster wird eine moderne, skalierbare
 Deployment-Strategie umgesetzt, die die neuen Performance-Features von Compose Multiplatform 1.10.0 optimal nutzt.
 

docs/01_Architecture/Reference/Tech_Stack/Implementierung_Offline-First_KMP.md

@@ -9,7 +9,7 @@ Hier ist der Quellcode des Berichts im Markdown-Format:
 
 ## Zusammenfassung
 
-Die Softwareentwicklungslandschaft des Jahres 2026, geprägt durch die Veröffentlichung von Kotlin 2.3.0 und Gradle 9.1.0, bietet Entwicklern beispiellose Möglichkeiten zur Vereinheitlichung komplexer Geschäftslogik über Plattformgrenzen hinweg. Dieser Forschungsbericht analysiert detailliert die architektonischen Muster, Implementierungsstrategien und zugrundeliegenden Mechanismen, die für den Aufbau einer robusten, asynchronen Offline-First-Anwendung erforderlich sind. Der Fokus liegt hierbei auf der Integration von SQLDelight in einer Kotlin Multiplatform (KMP) Umgebung, die sowohl Desktop (JVM) als auch Web (Kotlin/JS) Ziele bedient, eingebettet in eine Mikro-Frontend-Architektur.
+Die Softwareentwicklungslandschaft des Jahres 2026, geprägt durch die Veröffentlichung von Kotlin 2.3.21 und Gradle 9.5.0, bietet Entwicklern beispiellose Möglichkeiten zur Vereinheitlichung komplexer Geschäftslogik über Plattformgrenzen hinweg. Dieser Forschungsbericht analysiert detailliert die architektonischen Muster, Implementierungsstrategien und zugrundeliegenden Mechanismen, die für den Aufbau einer robusten, asynchronen Offline-First-Anwendung erforderlich sind. Der Fokus liegt hierbei auf der Integration von SQLDelight in einer Kotlin Multiplatform (KMP) Umgebung, die sowohl Desktop (JVM) als auch Web (Kotlin/JS) Ziele bedient, eingebettet in eine Mikro-Frontend-Architektur.
 
 Ein zentraler Schwerpunkt dieser Arbeit ist die Überbrückung der Dichotomie zwischen der synchronen Natur klassischer JVM-Datenbanktreiber und der inhärent asynchronen, Event-Loop-basierten Umgebung des modernen Web (insbesondere unter Nutzung von Web Workern und OPFS). Darüber hinaus wird die fortgeschrittene Integration von Persistenzschichten in einem Mikro-Frontend-Ökosystem untersucht, um sicherzustellen, dass eine einzige Quelle der Wahrheit („Single Source of Truth“) über unabhängig bereitgestellte Frontend-Einheiten hinweg konsistent bleibt.
 
@@ -17,11 +17,11 @@ Ein zentraler Schwerpunkt dieser Arbeit ist die Überbrückung der Dichotomie zw
 
 ### 1.1 Die Evolution von Kotlin Multiplatform
 
-Mit der Veröffentlichung von Kotlin 2.3.0 im Dezember 2025 hat sich das Ökosystem von einer experimentellen Technologie zu einem stabilen Standard für Enterprise-Architekturen entwickelt. Während frühere Versionen oft mit Inkonsistenzen zwischen den Compilern (JVM vs. JS/Native) zu kämpfen hatten, bietet der K2-Compiler in Version 2.3.0 eine vereinheitlichte Frontend-IR (Intermediate Representation), die eine robustere statische Analyse und performantere Kompilierung ermöglicht. Dies ist entscheidend für komplexe Multi-Modul-Projekte, wie sie in Mikro-Frontend-Architekturen üblich sind.
+Mit der Veröffentlichung von Kotlin 2.3.21 im Dezember 2025 hat sich das Ökosystem von einer experimentellen Technologie zu einem stabilen Standard für Enterprise-Architekturen entwickelt. Während frühere Versionen oft mit Inkonsistenzen zwischen den Compilern (JVM vs. JS/Native) zu kämpfen hatten, bietet der K2-Compiler in Version 2.3.21 eine vereinheitlichte Frontend-IR (Intermediate Representation), die eine robustere statische Analyse und performantere Kompilierung ermöglicht. Dies ist entscheidend für komplexe Multi-Modul-Projekte, wie sie in Mikro-Frontend-Architekturen üblich sind.
 
-### 1.2 Gradle 9.1.0: Die Build-Infrastruktur
+### 1.2 Gradle 9.5.0: Die Build-Infrastruktur
 
-Gradle 9.1.0, veröffentlicht im September 2025, hat die Art und Weise, wie KMP-Projekte konfiguriert werden, grundlegend verändert. Mit der vollständigen Unterstützung des „Configuration Cache“ und der strikten „Project Isolation“ zwingt es Entwickler zu sauberen Modulgrenzen. Für unser Szenario bedeutet dies, dass die Abhängigkeiten zwischen dem `shared`-Modul (Datenbank) und den konsumierenden Mikro-Frontends explizit und ohne Seiteneffekte definiert werden müssen, um die parallele Ausführung und inkrementelle Kompilierung nicht zu gefährden.
+Gradle 9.5.0, veröffentlicht im September 2025, hat die Art und Weise, wie KMP-Projekte konfiguriert werden, grundlegend verändert. Mit der vollständigen Unterstützung des „Configuration Cache“ und der strikten „Project Isolation“ zwingt es Entwickler zu sauberen Modulgrenzen. Für unser Szenario bedeutet dies, dass die Abhängigkeiten zwischen dem `shared`-Modul (Datenbank) und den konsumierenden Mikro-Frontends explizit und ohne Seiteneffekte definiert werden müssen, um die parallele Ausführung und inkrementelle Kompilierung nicht zu gefährden.
 
 ### 1.3 Die Problemstellung: Synchron vs. Asynchron
 
@@ -38,12 +38,12 @@ SQLDelight 2.0+ adressiert dieses Problem mit der Konfiguration `generateAsync =
 
 In einer Offline-First-Architektur fungiert die lokale Datenbank nicht als bloßer Cache, sondern als primäre Quelle der Wahrheit. Die Benutzeroberfläche (UI) kommuniziert niemals direkt mit dem Netzwerk.
 
-| Konzept | Traditionelle Architektur | Offline-First Architektur |
-| --- | --- | --- |
-| **Datenquelle** | Remote API (REST/GraphQL) | Lokale Datenbank (SQLite) |
-| **Lesepfad** | UI ruft Netzwerk auf -> Wartet -> Zeigt an | UI beobachtet Datenbank (Flow) -> Zeigt an |
-| **Schreibpfad** | UI sendet an API -> Wartet auf OK -> Aktualisiert UI | UI schreibt in DB -> DB emittiert neue Daten -> Sync im Hintergrund |
-| **Netzwerkstatus** | Voraussetzung für Funktionalität | Optional; beeinflusst nur Synchronisation |
+| Konzept            | Traditionelle Architektur                            | Offline-First Architektur                                           |
+|--------------------|------------------------------------------------------|---------------------------------------------------------------------|
+| **Datenquelle**    | Remote API (REST/GraphQL)                            | Lokale Datenbank (SQLite)                                           |
+| **Lesepfad**       | UI ruft Netzwerk auf -> Wartet -> Zeigt an           | UI beobachtet Datenbank (Flow) -> Zeigt an                          |
+| **Schreibpfad**    | UI sendet an API -> Wartet auf OK -> Aktualisiert UI | UI schreibt in DB -> DB emittiert neue Daten -> Sync im Hintergrund |
+| **Netzwerkstatus** | Voraussetzung für Funktionalität                     | Optional; beeinflusst nur Synchronisation                           |
 
 Dieses Prinzip der „Inversion of Control“ entkoppelt die User Experience von Netzwerklatenz und -verfügbarkeit. In SQLDelight wird dies durch Reactive Extensions realisiert, die SQL-Abfragen als `Flow<T>` exponieren, die sich bei Datenänderungen automatisch aktualisieren.
 
@@ -60,8 +60,8 @@ Das Fundament eines stabilen KMP-Projekts ist eine präzise Gradle-Konfiguration
 ### 3.1 Version Catalog (`gradle/libs.versions.toml`)toml
 
 [versions]
-kotlin = "2.3.0"
-gradle = "9.1.0"
+kotlin = "2.3.21"
+gradle = "9.5.0"
 sqldelight = "2.1.0"
 coroutines = "1.10.1" # Hypothetische Version passend zu Kotlin 2.3
 ktor = "3.1.0"

docs/01_Architecture/Reference/Tech_Stack/Konfiguration_Kotlin-2-3-0_Java-25.md

@@ -5,20 +5,20 @@ owner: Lead Architect
 tags: [kotlin, java, configuration, setup]
 ---
 
-# Tech-Stack Referenz: Kotlin 2.3.0 & Java 25 (KMP)
+# Tech-Stack Referenz: Kotlin 2.3.21 & Java 25 (KMP)
 
-**Kontext:** Dieses Dokument beschreibt die notwendigen Konfigurationen, um Kotlin 2.3.0 mit Java 25 in einem Kotlin Multiplatform (KMP) Projekt mit Gradle 9.x zu verwenden.
+**Kontext:** Dieses Dokument beschreibt die notwendigen Konfigurationen, um Kotlin 2.3.21 mit Java 25 in einem Kotlin Multiplatform (KMP) Projekt mit Gradle 9.x zu verwenden.
 
 ---
 
 ### 1. Kern-Spezifikationen
 
-| Komponente | Version  | Status |
-| --- |----------| --- |
-| **Kotlin** | `2.3.0`  | Stabil (K2 Compiler standardmäßig aktiv) |
-| **Java (JDK)** | `25`     | LTS (Long-Term Support) |
-| **Gradle** | `9.2.1`  | Erforderlich für JDK 25 Support |
-| **Android Plugin (AGP)** | `8.8.0+` | Empfohlen für Gradle 9.x Kompatibilität |
+| Komponente               | Version  | Status                                   |
+|--------------------------|----------|------------------------------------------|
+| **Kotlin**               | `2.3.21` | Stabil (K2 Compiler standardmäßig aktiv) |
+| **Java (JDK)**           | `25`     | LTS (Long-Term Support)                  |
+| **Gradle**               | `9.5.0`  | Erforderlich für JDK 25 Support          |
+| **Android Plugin (AGP)** | `8.8.0+` | Empfohlen für Gradle 9.x Kompatibilität  |
 
 ---
 
@@ -28,7 +28,7 @@ Für ein **Kotlin Multiplatform (KMP)** Projekt ist die Java Toolchain-Konfigura
 
 ```kotlin
 plugins {
-    kotlin("multiplatform") version "2.3.0"
+    kotlin("multiplatform") version "2.3.21"
     id("com.android.library") version "8.8.0" // Falls Android Target genutzt wird
 }
 
@@ -60,15 +60,15 @@ Damit das Projekt Java 25 erkennt, muss der Wrapper auf dem neuesten Stand sein:
 
 **Terminal-Befehl:**
 ```bash
-./gradlew wrapper --gradle-version 9.2.1 --distribution-type all
+./gradlew wrapper --gradle-version 9.5.0 --distribution-type all
 ```
 
 ---
 
 ### 4. Wichtige Kompatibilitätshinweise
 
-* **IDE-Version:** IntelliJ IDEA 2025.3 (oder neuer) wird für die volle Unterstützung von JDK 25 und dem Kotlin 2.3.0 Plugin empfohlen.
-* **K2 Compiler:** Kotlin 2.3.0 nutzt den K2-Compiler.
+* **IDE-Version:** IntelliJ IDEA 2025.3 (oder neuer) wird für die volle Unterstützung von JDK 25 und dem Kotlin 2.3.21 Plugin empfohlen.
+* **K2 Compiler:** Kotlin 2.3.21 nutzt den K2-Compiler.
 * **Bytecode:** Java 25 Bytecode wird nur generiert, wenn das `jvmTarget` explizit auf `25` gesetzt ist.
 
 ---
@@ -76,4 +76,4 @@ Damit das Projekt Java 25 erkennt, muss der Wrapper auf dem neuesten Stand sein:
 ### 5. Bekannte Features in diesem Setup
 
 * **Java 25 Features:** Unterstützung für die finalen Versionen von *Scoped Values* und *Structured Concurrency*.
-* **Kotlin 2.3.0 Features:** Nutzung von `explicit backing fields` und dem verbesserten `unused return value` Checker.
+* **Kotlin 2.3.21 Features:** Nutzung von `explicit backing fields` und dem verbesserten `unused return value` Checker.

docs/01_Architecture/Reference/Tech_Stack/Kotlin_2-3-0_ReleaseNotes.md

@@ -5,7 +5,7 @@ owner: Lead Architect
 tags: [kotlin, release-notes, tech-stack]
 ---
 
-# Was ist neu in Kotlin 2.3.0
+# Was ist neu in Kotlin 2.3.21
 
 **Quelle:** [Offizielle Kotlin-Dokumentation](https://kotlinlang.org/docs/whatsnew23.html)
 **Datum des Dokuments:** 16. Dezember 2025
@@ -13,7 +13,7 @@ tags: [kotlin, release-notes, tech-stack]
 
 ---
 
-Kotlin 2.3.0 ist erschienen! Hier sind die wichtigsten Highlights:
+Kotlin 2.3.21 ist erschienen! Hier sind die wichtigsten Highlights:
 
 *   **Sprache:** Mehr stabile und standardmäßig aktivierte Features, Checker für ungenutzte Rückgabewerte, explizite Backing Fields und Änderungen bei der kontextsensitiven Auflösung.
 *   **Kotlin/JVM:** Unterstützung für Java 25.
@@ -26,7 +26,7 @@ Kotlin 2.3.0 ist erschienen! Hier sind die wichtigsten Highlights:
 
 ## Sprache
 
-Kotlin 2.3.0 konzentriert sich auf die Stabilisierung von Features, führt einen neuen Mechanismus zur Erkennung ungenutzter Rückgabewerte ein und verbessert die kontextsensitive Auflösung.
+Kotlin 2.3.21 konzentriert sich auf die Stabilisierung von Features, führt einen neuen Mechanismus zur Erkennung ungenutzter Rückgabewerte ein und verbessert die kontextsensitive Auflösung.
 
 ### Stabile Features
 
@@ -38,13 +38,13 @@ Folgende Features sind nun stabil:
 *   Unterstützung für `return`-Anweisungen in Ausdrucks-Bodies mit explizitem Rückgabetyp ist nun standardmäßig aktiviert.
 
 ### Experimentell: Checker für ungenutzte Rückgabewerte
-Kotlin 2.3.0 führt den Checker für ungenutzte Rückgabewerte ein, um das versehentliche Ignorieren von Ergebnissen zu verhindern.
+Kotlin 2.3.21 führt den Checker für ungenutzte Rückgabewerte ein, um das versehentliche Ignorieren von Ergebnissen zu verhindern.
 
 ### Experimentell: Explizite Backing Fields
 Eine neue Syntax zur expliziten Deklaration des zugrundeliegenden Felds, das den Wert einer Property hält – vereinfacht das verbreitete Backing-Properties-Muster.
 
 ## Kotlin/JVM: Unterstützung für Java 25
-Ab Kotlin 2.3.0 kann der Compiler Klassen mit Java-25-Bytecode generieren.
+Ab Kotlin 2.3.21 kann der Compiler Klassen mit Java-25-Bytecode generieren.
 
 ## Kotlin/Native
 *   **Verbesserter Swift-Export:** Direkte Zuordnung für native Enum-Klassen und variadische Funktionsparameter.

docs/01_Architecture/Specifications/Meldestelle_Tech_Stack_Zusammenfassung.md

@@ -22,7 +22,7 @@ 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         │
+│  Kotlin 2.3.21 / Compose    │  Java 25 / Spring Boot 3.5.9         │
 │  JS + WASM (geplant)     │  Microservices + API-Gateway          │
 ├─────────────────────────────────────────────────────────────────┤
 │  Infrastruktur (Self-Hosted auf Zora / Proxmox)                 │
@@ -37,10 +37,10 @@ Microservices Backend** auf einer vollständig self-hosted Infrastruktur.
 
 | Komponente | Sprache / Runtime      | Version |
 |:-----------|:-----------------------|:--------|
-| Backend    | Kotlin (JVM)           | 2.3.0   |
-| Frontend   | Kotlin (KMP / JS)      | 2.3.0   |
+| Backend    | Kotlin (JVM)           | 2.3.21  |
+| Frontend   | Kotlin (KMP / JS)      | 2.3.21  |
 | JVM        | Java (Eclipse Temurin) | 25 (EA) |
-| Build      | Gradle (Kotlin DSL)    | 9.3.1   |
+| Build      | Gradle (Kotlin DSL)    | 9.5.0   |
 | Plattform  | ARM64 (AArch64)        | Linux   |
 
 ---
@@ -51,13 +51,13 @@ Microservices Backend** auf einer vollständig self-hosted Infrastruktur.
 
 | Bibliothek            | Version | Zweck                            |
 |:----------------------|:--------|:---------------------------------|
-| Kotlin Multiplatform  | 2.3.0   | Cross-Platform-Basis (JS + WASM) |
+| Kotlin Multiplatform  | 2.3.21  | 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              |
+| Kotlin Serialization  | 2.3.21  | JSON-Serialisierung              |
 
 ### 3.2 Persistenz (Offline-First)
 
@@ -105,7 +105,7 @@ frontend/
 | 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               |
+| Kotlin Coroutines        | 2.3.21   | Async/Non-blocking               |
 
 ### 4.2 Persistenz
 
@@ -348,7 +348,7 @@ Mittlere Priorität:
 TECH-STACK KOMPLEXITÄT
 ──────────────────────────────────────────────────────
 Sprachen:        Kotlin (JVM + KMP/JS)
-Build:           Gradle 9.3.1 + Kotlin DSL + libs.versions.toml
+Build:           Gradle 9.5.0 + 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

docs/01_Architecture/_archive/Roadmaps_2026_Q1/Fahrplan_Konsolidierung_2026-03-28.md

@@ -13,7 +13,7 @@ Feature-Implementierung an der verfeinerten DDD-Struktur (ADR-0014) sowie der De
 
 ### 🟢 Technische Stabilisierung
 
-* **Kotlin 2.3.20:** Alle Module wurden auf Kotlin 2.3.20 migriert. Deprecation-Warnungen für `Clock` und `Instant`
+* **Kotlin 2.3.21:** Alle Module wurden auf Kotlin 2.3.21 migriert. Deprecation-Warnungen für `Clock` und `Instant`
   wurden durch Standardisierung auf `kotlin.time.*` behoben.
 * **Zentralisierte Serialisierung:** Erstellung der `Serializers.kt` im `core-domain` Modul für `Uuid`, `Instant`,
   `LocalDate`, `LocalDateTime` und `LocalTime`.

docs/01_Architecture/adr/0013-tech-stack-stabilization-2026.md

@@ -11,17 +11,17 @@ last_update: 2026-01-20
 Angenommen
 
 ## Kontext
-Das Projekt "Meldestelle" setzt auf einen sehr modernen Technologie-Stack (Java 25, Kotlin 2.3.0, Spring Boot 3.5.9). Eine Analyse im Januar 2026 hat jedoch kritische Versionskonflikte aufgedeckt, die die Stabilität des Builds und der Laufzeitumgebung gefährden.
+Das Projekt "Meldestelle" setzt auf einen sehr modernen Technologie-Stack (Java 25, Kotlin 2.3.21, Spring Boot 3.5.9). Eine Analyse im Januar 2026 hat jedoch kritische Versionskonflikte aufgedeckt, die die Stabilität des Builds und der Laufzeitumgebung gefährden.
 
 1.  **Spring Cloud Konflikt:** Der Release Train `2025.1.0` (Oakwood) ist für Spring Boot 4.0 konzipiert und inkompatibel mit Spring Boot 3.5.9 (führt zu `NoSuchMethodError`).
-2.  **Compose Multiplatform:** Version `1.9.3` führt zu Compiler-Crashes in Verbindung mit Kotlin 2.3.0.
-3.  **Exposed:** Version `0.61.0` ist veraltet und inkompatibel mit Kotlin 2.3.0.
+2.  **Compose Multiplatform:** Version `1.9.3` führt zu Compiler-Crashes in Verbindung mit Kotlin 2.3.21.
+3.  **Exposed:** Version `0.61.0` ist veraltet und inkompatibel mit Kotlin 2.3.21.
 
 ## Entscheidung
 Wir führen folgende Korrekturen am Tech-Stack durch, um eine stabile "Best Compatibility List" zu etablieren:
 
 1.  **Spring Cloud Downgrade:** Wechsel auf Release Train `2025.0.1` (Northfields), der offiziell für Spring Boot 3.5.x freigegeben ist.
-2.  **Compose Multiplatform Upgrade:** Wechsel auf `1.10.0-rc02` (oder stable), um volle Kotlin 2.3.0 Kompatibilität zu gewährleisten.
+2.  **Compose Multiplatform Upgrade:** Wechsel auf `1.10.0-rc02` (oder stable), um volle Kotlin 2.3.21 Kompatibilität zu gewährleisten.
 3.  **Exposed Upgrade:** Wechsel auf `1.0.0-rc-4` (oder neuer), um Bytecode-Inkompatibilitäten zu beheben.
 4.  **Micrometer Upgrade:** Explizites Setzen von Version `1.16.1` für verbesserten Java 25 (Virtual Threads) Support.
 
@@ -29,7 +29,7 @@ Wir führen folgende Korrekturen am Tech-Stack durch, um eine stabile "Best Comp
 
 ### Positiv
 *   **Stabilität:** Der Build und die Application Context Initialisierung sind wieder stabil.
-*   **Zukunftssicherheit:** Wir nutzen weiterhin die neuesten Features von Java 25 und Kotlin 2.3.0, aber in einer validierten Kombination.
+*   **Zukunftssicherheit:** Wir nutzen weiterhin die neuesten Features von Java 25 und Kotlin 2.3.21, aber in einer validierten Kombination.
 *   **Wartbarkeit:** Die `libs.versions.toml` spiegelt nun eine getestete Konfiguration wider.
 
 ### Negativ

docs/02_Domain/01_Glossary/Ubiquitous_Language.md

@@ -2,11 +2,12 @@
 type: Reference
 status: ACTIVE
 owner: Lead Architect & ÖTO/FEI Rulebook Expert
-last_update: 2026-04-05
+last_update: 2026-06-15
 sources:
   - ÖTO 2026, Abschnitt A I, § 2 & § 3 & § 4
   - Domain Workshop 2026-03-17
   - Session 2026-03-24 (Architektur-Diskussion)
+  - Sanierung 2026-06-15 (Reality-Reset)
 ---
 
 # Ubiquitous Language – Offizielle Domänen-Terminologie
@@ -146,7 +147,7 @@ Veranstalter (OEPS-Mitgliedsverein)
 | **Sparte**             | Die unterschiedlichen Arten von Turnieren oder Bewerben (z.B. Dressur = CDN, Springen = CSN). Bestimmt das anzuwendende Richtverfahren und das Regelwerk.                                                           | ÖTO § 2 Abs. 9, § 3 Abs. 2 |
 | **Sperrliste**         | Vom Verband geführte Liste von Personen oder Pferden, die aktuell nicht startberechtigt sind (meist wegen offener Zahlungen).                                                                                       | –                          |
 | **Sportförderbeitrag** | Gebühr, die **pro Start** anfällt (nicht pro Nennung!). Relevant bei Mehrfach-Starts.                                                                                                                               | ÖTO Gebührenordnung        |
-| **Stammdaten**         | (Früher: Akteur-Context). Die zentrale Library of Truth (`master-data-context`) für alle statischen Informationen: Personen, Pferde, Vereine, sowie das ÖTO-Regelwerk (Richtverfahren, Paragraphen, Gebührensätze). | –                          |
+| **Stammdaten**         | Die zentrale Library of Truth (`masterdata-context`) für alle statischen Informationen: Personen, Pferde, Vereine, sowie das ÖTO-Regelwerk (Richtverfahren, Paragraphen, Gebührensätze). | –                          |
 | **Startkarte**         | Nachweis, dass die Jahresgebühr für die Lizenz bezahlt wurde. Ohne aktive Startkarte ist national kein Start möglich.                                                                                               | ÖTO Teilnahmeberechtigung  |
 | **Startwunsch**        | Präferenz eines Reiters bezüglich seiner Position in der Startliste (vorne/hinten).                                                                                                                                 | Registration Context       |
 
@@ -188,7 +189,7 @@ Veranstalter (OEPS-Mitgliedsverein)
 | Veranstaltung, Turnier, Ausschreibung, Veranstalter               | `event-management-context`    |
 | Bewerb, Abteilung, Startliste, Ergebnis, Richtverfahren           | `competition-context`         |
 | Nennung, Nennungs-Transfer, Startwunsch, ZNS-Import               | `registration-context`        |
-| Reiter, Pferd, Lizenz, Funktionär, Kopfnummer, Satznummer, Verein | `actor-context`               |
+| Reiter, Pferd, Lizenz, Funktionär, Kopfnummer, Satznummer, Verein | `masterdata-context`          |
 | Nenngeld, Startgeld, Konto, Transaktion, Sportförderbeitrag       | `billing-context`             |
 | Cup, Serie, Meisterschaft, Reglement, Endklassement               | `series-context` *(Phase 2+)* |
 | Login, Rolle, Berechtigung                                        | `identity-context`            |
@@ -222,7 +223,7 @@ Ein Reglement definiert typischerweise:
 - Verschiedene Cups/Serien können **unterschiedliche Punktesysteme** haben → das Berechnungsmodell muss pluggable sein.
 - Die **Paar-Bindung** (Punkte an Reiter+Pferd vs. nur Reiter) ist eine kritische Designentscheidung pro Reglement.
 - Referenz-Dokument: [
-  `docs/03_Domain/02_Reference/OETO_Regelwerk/Struktur-Meisterschafts-Cup-Reglements_OETO.md`](../02_Reference/OETO_Regelwerk/Struktur-Meisterschafts-Cup-Reglements_OETO.md)
+  `docs/02_Domain/02_Reference/OETO_Regelwerk/Struktur-Meisterschafts-Cup-Reglements_OETO.md`](../02_Reference/OETO_Regelwerk/Struktur-Meisterschafts-Cup-Reglements_OETO.md)
 
 ---
 
@@ -241,4 +242,4 @@ Ein Reglement definiert typischerweise:
 ---
 
 *Erstellt: 2026-03-24 | Autoren: Lead Architect, ÖTO/FEI Rulebook Expert, Curator*
-*Basiert auf: ÖTO 2026 § 2, § 3, § 4 | Domain Workshop 2026-03-17 | Session 2026-03-24 | Update: 2026-04-05 (Verein-Renaming & Bereinigung)*
+*Basiert auf: ÖTO 2026 § 2, § 3, § 4 | Domain Workshop 2026-03-17 | Session 2026-03-24 | Update: 2026-06-15 (Reality-Reset & Alignment)*