meldestelle/docs/01_Architecture/MASTER_ROADMAP.md

type	status	owner	last_update
Roadmap	ACTIVE	Lead Architect	2026-04-21

MASTER ROADMAP: Meldestelle

🏗️ [Lead Architect] | 20. April 2026

Strategisches Ziel: Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP). Vollständige Self-Hosted Infrastruktur (Gitea, Pangolin, Zora). Datensouveränität, Offline-First, saubere Wissensbasis.

Produktfokus:

• 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):

• 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. Enums ÖTO-konform.
• Dokumentation: ✅ Konsolidiert. ÖTO-Regelwerk-Referenzen (Abteilungs-Schwellenwerte) dokumentiert.

---

Architektur-Übersicht: 6 Bounded Contexts (SCS)

Das System ist in 6 Self-Contained Systems (SCS) aufgeteilt, die fachlich voneinander getrennt sind und über definierte Schnittstellen kommunizieren.

SCS	Kontext	Priorität	Status
registration-context	Nennungs-Workflow (Herzstück)	P1	🔵 In Arbeit
actor-context	Reiter, Pferde, Funktionäre, ZNS	P1	🟡 MVP
competition-context	Bewerbe, Startlisten, Ergebnisse	P2	🔵 In Arbeit
event-management-context	Veranstaltung, Turnier, Ausschreibung	P2	🔵 In Arbeit
series-context	Cups, Serien, Meisterschaften	Phase 2+	🔵 In Arbeit
billing-context	Abrechnung, Kassa, Gebühren	P3	🔵 In Arbeit
identity-context	Auth, Rollen (Keycloak)	P3	🟡 MVP

Hinweis series-context: Ist Phase 2+, aber die Architektur ist von Anfang an vorbereitet. Cups/Serien/Meisterschaften benötigen eigene, konfigurierbare Reglements (kein Hard-Coding). Pluggable Berechnungsmodell und konfigurierbare Paar-Bindung (Reiter+Pferd vs. nur Reiter) erforderlich.

---

1. Abgeschlossene Phasen

PHASE 1: Documentation Cleanup ✅ ABGESCHLOSSEN

Ziel: Eine einzige, vertrauenswürdige Quelle der Wahrheit (SSOT) schaffen.

🧹 Agent: Curator

• Archivierung: Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach docs/_archive/ verschoben.
• Konsolidierung: Zora_System_Architektur.md als zentrale Infrastruktur-Doku etablieren.
• Struktur: docs/ Ordner aufräumen (unnötige Root-Files in Unterordner).
• Index: README.md im Root als Einstiegspunkt aktualisieren.

PHASE 2: Infrastructure Hardening ✅ ABGESCHLOSSEN

Ziel: Stabilisierung der neuen Self-Hosted Umgebung.

🐧 Agent: DevOps Engineer

• Keycloak Fix: Verbindungsprobleme innerhalb des Docker-Netzwerks behoben (Alias auth.mo-code.at).
• Backup Strategy: Automatisierte Backups für Gitea & Datenbanken auf Zora (config/scripts/backup.sh).
• Monitoring: Prometheus/Grafana Dashboard für Zora finalisiert (dc-ops.yaml).
• Deployment: Git-basiertes Deployment-Skript (config/scripts/deploy.sh) erstellt.

PHASE 3: Domain-Design & Ubiquitous Language ✅ ABGESCHLOSSEN

Ziel: Fachliche Grundlage für die Implementierung schaffen.

🏗️ Agent: Lead Architect

• DDD-Analyse: 6 Bounded Contexts (SCS-Architektur) definiert und priorisiert.
• Terminologie: Veranstaltung ≠ Turnier gemäß ÖTO § 2 Abs. 1 festgelegt (ADR).
• Design-Baseline: Vision_03 (Figma) als offizieller Design-Baseline festgelegt.
• Technologie: Desktop-First-Strategie mit KMP/Compose Desktop beschlossen.

📜 Agent: ÖTO/FEI Rulebook Expert

• Ubiquitous Language: Offizielle Domänen-Terminologie mit ÖTO-Referenzen erstellt.
• Abteilungs-Schwellenwerte: Alle Trennungs-Schwellenwerte (§ 39 + spartenspezifisch) dokumentiert. → docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md

👷 Agent: Backend Developer

• Enums: SparteE, TurnierkategorieE, VeranstaltungsTypE, LizenzKlasseE, NennungsStatusE, StartwunschE – ÖTO-konform.
• Domain-Modelle: DomReiter (actor-context), DomNennung, DomNennungsTransfer (registration-context).
• Modul: entries-domain als KMP-Modul aufgesetzt und in settings.gradle.kts registriert.

---

2. Aktuelle Phase

PHASE 4: MVP-Implementierung ✅ ABGESCHLOSSEN

Ziel: Lauffähiger MVP für registration-context und actor-context (P1-Contexts).

🧐 Agent: QA Specialist

• 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.
• Masterdata Standardization: Bereinigung und Standardisierung der Masterdaten-Tabellen (Mehrzahl-Konvention: bundeslaender, funktionaers_qualifikationen, reit_lizenzen, turnier_klassen).
• ÖTO Data Seeding: Umfassende Seeder für Funktionärs-Qualifikationen, Turnierklassen und Turnier-Sparten gemäß ÖTO implementiert. Einführung der Tabelle turnier_sparten.
• 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.
• 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.
• 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.

🏗️ Agent: Lead Architect

• 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
• API-Design: Schnittstellen zwischen den Contexts definieren (Anti-Corruption Layer). → docs/01_Architecture/adr/0016-api-design-acl-de.md
• ÖTO-Validation-Seeds: Seed-Daten für Lizenz-Matrix und Altersklassen finalisiert (V008).

👷 Agent: Backend Developer

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

🎨 Agent: Frontend Expert

• KMP/Compose Desktop: Projektstruktur aufgesetzt (frontend/shells/meldestelle-desktop).
• Navigation: Sidebar-Navigation gemäß Vision_03 implementiert (Veranstaltungen, Reiter, Pferde, Funktionäre, Meisterschaften, Cups).
• Nennungs-Screen: TurnierDetailScreen integriert NennungsMaske aus nennung-feature (Bewerbe-Tab ⭐).

📜 Agent: ÖTO/FEI Rulebook Expert

• 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)
• 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)
• 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

🧹 Agent: Curator & Lead Architect (ZNS-Importer)

• 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
• Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul)
• Domain-Mapping & Upsert in DB (Phase 2)
• REST-API & Job-Management (Phase 1 – Controller/Job-Registry)
• Frontend-Integration mit File-Picker & Status-Polling (Phase 3)

---

3. Initiative: Wizard-Orchestrator & Offline-Drafts (Q2/Q3 2026)

🏗️ Verantwortlich: Lead Architect · 🎨 Frontend · 🖌️ UI/UX · 👷 Backend · 🧐 QA · 🧹 Curator

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

---

3. Aktuelle Phase

PHASE 5: P2-Contexts & Integration ✅ ABGESCHLOSSEN

Ziel: competition-context und event-management-context implementieren.

• competition-context: Bewerbe, Startlisten, Ergebnisse, Abteilungs-Warn-Logik.
• event-management-context: Veranstaltungs- und Turnier-Verwaltung, Ausschreibungs-Generator.
• ZNS-Integration: Schnittstelle zum Zentralen Nennungs-System (A-Satz / B-Satz).
• Offline-Sync: Offline-First-Strategie für Desktop-App implementieren.

PHASE 6: P3-Contexts & Billing ✅ ABGESCHLOSSEN

Ziel: billing-context und identity-context implementieren.

• billing-context: Gebührenberechnung, Kassa, Abrechnung.
• identity-context: Rollen-Modell (TBA, Veranstalter, Richter etc.) mit Keycloak.
• Reporting: Startlisten- und Ergebnislisten-Druck (PDF).

---

4. Geplante Phasen

PHASE 7: Desktop-Vernetzung & Zentrale Verwaltung ✅ ABGESCHLOSSEN

Ziel: LAN-Kommunikation Vorbereitung und Etablierung der "Veranstaltung-Verwaltung" als zentrale Schaltstelle.

• Zentrale Verwaltung: Etablierung der Veranstaltung-Verwaltung (Zentrale) als administratives Cockpit.
• Navigation: Implementierung eines Back-Stack-Systems für intelligente "Zurück"-Navigation.
• Domänen-Synchronisation: Anpassung der Frontend-Stores an die Backend-Masterdata-Modelle (Reiter, Pferde, Vereine, Funktionäre).
• ZNS-Integration (Frontend): ZNS-Importer in die Zentrale integriert; Konzept "Globaler Pool -> Lokale Synchronisation" gefestigt.
• Terminologie: UI-weit Umstellung von "Event" auf "Veranstaltung" (ÖTO-konform).
• Konzept: LAN-Discovery (mDNS) und Echtzeit-Sync (WebSockets) entworfen.
• ADR: ADR-0020 (Lokale Netzwerk-Kommunikation) erstellt.

PHASE 8: Bewerbe-Management & Startlisten ✅ ABGESCHLOSSEN

Ziel: Fachliche Tiefe in den Turnieren (Import, Generierung, Zeitberechnung).

• Konzept/ADR: LAN‑Sync (ADR‑0022) und Offline‑First Desktop↔Backend Konzept definiert und verlinkt.
• Bewerbe-Import: Implementierung der Merge-Logik (ZNS-XML -> BewerbUiModel). ✓
• Startlisten-Automatisierung: Generierung und Zeitberechnung (Pausen, Umbauzeiten). ✓
• Discovery: Implementierung des mDNS-Service (JmDNS) für die Geräte-Suche. ✓
• Transport: Aufbau der WebSocket-Infrastruktur für P2P-Sync (Ktor WebSockets, SyncManager). ✓
• Offline-First Desktop↔Backend: Umsetzung gemäß Konzept „Offline-First Synchronisation (Desktop ↔ Backend)“ → docs/01_Architecture/konzept-offline-first-desktop-backend-de.md. ✓
• 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.

• Billing-Service: Initialisierung, Teilnehmer-Konten & Buchungs-Logik (v1). ✓
• Entries-Integration: Automatische Buchung von Nenngeldern bei Nennungs-Abgabe. ✓
• ZNS-Importer: Hardening & Integrationstests für Funktionärs-Updates. ✓
• Konzept: Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt. ✓
• Konzept: Status-Automat für Nennungen & Zeitplan-Synchronisation spezifiziert. ✓
• Frontend-Standardisierung: nennung-feature refactored und in Desktop-Shell integriert. ✓
• Rulebook-Check: ÖTO §43 "Parcoursbesichtigung zu Pferd" eingearbeitet. ✓
• Feature-Migration: Pferde-, Reiter-, Funktionärs- und Veranstalter-Module vollständig auf KMP umgestellt. ✓
• Cleanup: FRONTEND_CLEANUP_TODO.md für Migration von v2 Screens weitestgehend abgeschlossen. ✓
• Zeitplan: Dynamische Verschiebung von Bewerben (Drag & Drop im Kalender). ✓
• Protokoll: Implementierung eines Event-Logs für manuelle Eingriffe in Startlisten (Audit-Log). ✓
• 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).

• Frontend-Integration: Stammdaten-Infrastruktur (Repositories, ViewModels) für Reiter, Pferde, Funktionäre und Vereine im turnier-feature implementiert. ✓
• Nennungs-Management: Funktionalisierung des Nennungs-Tabs mit Echt-Datenanbindung und Suche. ✓
• series-context: Pluggable Berechnungsmodell (Streichresultate, Alles zählt), konfigurierbare Paar-Bindung (Reiter+Pferd vs. Einzelwertung) implementiert. ✓
• 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.

• Backend (Results): Implementierung der Geschäftslogik für Wertnoten, Zeitfehler und ÖTO-konforme Platzierungen. ✓
• Backend-Infrastruktur: results-service in Docker-Compose und API-Gateway integriert; Service-Discovery via Consul aktiviert. ✓
• Frontend UI: ErgebnisEditDialog zur schnellen Ergebniserfassung und TurnierErgebnislistenTab zur Anzeige realer Ergebnisse. ✓
• PDF-Export: Generierung von PDF-Ergebnislisten (Bewerbe und Serien). ✓

PHASE 12: Abrechnung & Billing 🔵 IN ARBEIT

Ziel: Vollständige Kassa-Funktionalität und Turnier-Abrechnung.

• Backend-Infrastruktur: billing-service initialisiert, Docker-Integration und Gateway-Routing (Port 8087) konfiguriert. ✓
• Frontend-Anbindung: BillingRepository (Ktor) und BillingViewModel auf reale API-Kommunikation umgestellt. ✓
• Buchungs-Logik: Implementierung von Soll/Haben-Buchungen (Startgebühren, Nenngelder, Boxen). ✓
• Offene Posten: Liste aller unbezahlten Beträge pro Teilnehmer/Pferd. ✓
• Rechnungserstellung: Generierung von PDF-Rechnungen und Zahlungsbestätigungen. ✓
• 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.

• "V2"-Bereinigung: Vollständige Eliminierung aller "V2"-Suffixe in Dateinamen und Symbolen (z.B. TurnierWizardV2, VeranstalterAuswahlV2). ✓ (20. April 2026)
• 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)
• 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)
• Device-Setup ("Lock-and-Edit"): Einführung eines Review-Modus mit Konfigurations-Sperre, Drucker-Integration und Maskierung des SharedKeys. ✓ (20. April 2026)
• Veranstaltungs-Wizard: Implementierung eines 6-stufigen Profi-Workflows mit Sticky Preview-Card (WYSIWYG), ZNS-Guard und OEPS-Satznummer-Mapping. ✓ (20. April 2026)
• Code-Hygiene: Beseitigung von Code-Smells, redundanten Validierungen und ungenutzten Parametern in den zentralen Frontend-Modulen. ✓ (20. April 2026)
• Connectivity-Diagnose: Stabiles Diagnose-Tool für Backend-, DB- und Auth-Verbindung in der Desktop-App. ✓ (18. April 2026)
• WASM-Transition: Projektweite Umstellung auf JVM (Desktop) und wasmJs (Web). Eliminierung von js(IR). ✓ (18. April 2026)
• 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

• Web-App Shell: Modul frontend:shells:meldestelle-web (Compose WasmJS) initialisiert.
• UI-Komponenten: VeranstaltungsCard und TurnierCard für Web implementiert (mit PDF- & Nenn-Button).
• Workflow: NennungWebFormular Prototyp erstellt (mit simuliertem Mail-Versand).

👷 Agent: Backend Developer

• 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

• 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

• Onboarding UI: Implementierung des Onboarding-Screens (Name, Key, Backup, Rolle, Sync, Drucker) mit validierten Eingaben.
• Navigation: Navigations-Rail mit Hover-Tooltips und dedizierten Icons für "Setup" und "Sync".
• Settings: Persistente Speicherung der Onboarding-Daten in settings.json.

👷 Agent: Backend Developer

• Device Management: Domain-Modell (Device), Tabelle (identity_devices) und Repository zur Geräteverwaltung implementiert.
• Security Key Auth: Implementierung des DeviceSecurityFilter zur Authentifizierung via X-Security-Key Header.
• Onboarding API: REST-Endpunkte zur Registrierung und Abfrage von Desktop-Instanzen erstellt.

🧹 Agent: Curator

• Dokumentation: Erstellung der Architektur-Doku für das Onboarding-Backend.