meldestelle/docs/01_Architecture/MASTER_ROADMAP.md

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

MASTER ROADMAP: Meldestelle-Biest

🏗️ [Lead Architect] | 11. 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	✅ Fertig
actor-context	Reiter, Pferde, Funktionäre, ZNS	P1	✅ Fertig
competition-context	Bewerbe, Startlisten, Ergebnisse	P2	✅ Fertig
event-management-context	Veranstaltung, Turnier, Ausschreibung	P2	✅ Fertig
series-context	Cups, Serien, Meisterschaften	Phase 2+	✅ Fertig
billing-context	Abrechnung, Kassa, Gebühren	P3	🔵 In Arbeit
identity-context	Auth, Rollen (Keycloak)	P3	✅ Fertig

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. 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: Export & ZNS-Rückmeldung

Ziel: Finalisierung der Turnier-Daten und Rückübermittlung an den OEPS.

• Mail-Service Integration: Online-Nennungen via REST/Mail empfangen und persistieren. ✓ (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

---

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.

---