build: Update Gradle Wrapper to v9.6.0

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.

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/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/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

build.gradle.kts

@@ -182,9 +182,11 @@ subprojects {
     // 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")
+    }
   }
 
   // ------------------------------
@@ -473,9 +475,11 @@ tasks.withType<Exec>().configureEach {
   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 {

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
 

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.
 
 ---
 
@@ -155,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/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)*