meldestelle/docs/01_Architecture/MASTER_ROADMAP.md

type, status, owner, last_update

type	status	owner	last_update
Roadmap	ACTIVE	Lead Architect	2026-05-06

MASTER ROADMAP: Meldestelle

🏗️ [Lead Architect] | 30. 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.04.2026):

• Infrastruktur: ✅ "Zora" (MS-R1, ARM64) ist live. Gitea & Registry laufen.
• Networking: ✅ Pangolin Tunnel ersetzt Cloudflare.
• CI/CD: ✅ Gitea Actions mit ARM64-Runner (VM 102) aktiv. Docker-Publish Pipeline grün.
• 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 (Verifiziert)

PHASE 1: Domain-Design & Ubiquitous Language ✅

Status: Fachliche Grundlage vorhanden.

• DDD-Analyse: 6 Bounded Contexts (SCS-Architektur) definiert.
• Terminologie: Veranstaltung ≠ Turnier gemäß ÖTO § 2 Abs. 1 festgelegt.
• Ubiquitous Language: Offizielle Domänen-Terminologie erstellt.

PHASE 2: Infrastruktur & ZNS-Importer (Prototyp) ✅

Status: Grundgerüst steht, Performance-Probleme bekannt.

• ZNS-Parser: Grundsätzliche Fähigkeit zum Parsen von ZNS-Daten (Reiter, Pferde, Vereine, Funktionäre).
• UI-Gerüst: Navigation und Dialog-Hüllen in Compose Desktop vorhanden.
• Plan-B: Rudimentärer Mail-Service für Nennungs-Versand (funktional).

---

2. Der neue Weg: Fachliche Realität (Roadmap 2026)

Fokus: Physische Implementierung der Turnier-Hierarchie und technisches Onboarding.

MEILENSTEIN 0: Technische Geräte-Initialisierung (Prio 1) 🚧 IN ARBEIT (STABILISIERUNG)

Ziel: Ein stabiles, offline-fähiges technisches Fundament für die Desktop-App.

• App-Icons (PNG/ICO): Implementiert (Fix für Build-Fehler).
• Docker-Fix: "services must be a mapping" behoben (dc-gui.yaml).
• Chat-Funktion (Desktop): MVP implementiert (Navigation & UI).
• Geführte Discovery ("Zero-Config"): Master-Namen statt IPs, "Wait-State" für Clients.
• Native FileDialogs: Stabile Pfad-Auswahl für Plan-USB auf allen Systemen.
• Handshake-Feedback: Visuelle Signalisierung des Verbindungsstatus (Grün/Rot).
• Client-Konfiguration: Master kann nun Clients in der UI hinzufügen und bearbeiten.
• Master-UX: Konfiguration beim Start nicht mehr zwangsgesperrt.
• Cross-Packaging (Conveyor): Windows-Build auf Linux-CI ermöglicht (x64-Abhängigkeit identifiziert).
• 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).

MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT

Ziel: Veranstaltung -> Turnier -> Bewerb/Abteilung physisch anlegen und speichern.

• Persistenz-Layer: Implementierung der lokalen Speicherung für alle Ebenen der Hierarchie.
• Turnier-Wizard (Echt): Umstellung des Wizards von println-Dummies auf echte Datenbank-Transaktionen.
• Validierung: Sicherstellen, dass Pflichtfelder (Turniernummer, Sparte) korrekt erfasst werden.

MEILENSTEIN 2: ZNS-Performance & Daten-Qualität (Prio 2)

Ziel: Import der ZNS.zip in < 2 Minuten statt 30+ Minuten.

• Batch-Processing: Umstellung des ZnsImportService auf Batch-Inserts (JDBC/Exposed).
• Fortschritts-Anzeige: Reale Rückmeldung über den Import-Status in der UI.

MEILENSTEIN 3: Richtverfahren & Bewerbs-Konfiguration (Prio 3)

Ziel: Bewerbe mit fachlich korrekten Regeln (ÖTO) anlegen.

• Richtverfahren-Engine: Validierungslogik für verschiedene Richtverfahren (Fehler/Zeit, Wertnoten).
• Abteilungs-Logik: Automatische Teilungsvorschläge gemäß ÖTO § 39.

---

3. Zukünftige Module (Status: Geplant / Vision)

Diese Module existieren derzeit nur als Konzepte oder leere Hüllen.

• Nennungs-Management: Erfassung von Nennungen gegen den ZNS-Datenbestand.
• Zeitplan: Dynamische Zeitplanung (Drag & Drop).
• Ergebnisse: Erfassung von Wertungen und Platzierungsberechnung.
• Abrechnung: Vollständiger billing-context.

---

4. Archiv der fiktiven Meilensteine (Reality-Check am 28.04.2026)

Die folgenden Einträge wurden in früheren Sitzungen als "Abgeschlossen" markiert, entsprachen aber nicht dem realen Code-Stand.

Frühere (fiktive) Meilensteine anzeigen

PHASE 4: MVP-Implementierung (Früherer Status: Abgeschlossen)

• ZNS-Import Optimierung (Batching) -> In MEILENSTEIN 2 verschoben.
• event-management-context Implementierung -> In MEILENSTEIN 1 verschoben.

PHASE 5-13 (Früherer Status: Abgeschlossen/In Arbeit)

• competition-context (Bewerbe, Startlisten) -> Fachlogik fehlt weitgehend.
• billing-context (Abrechnung) -> Nur Infrastruktur-Hülle vorhanden.
• results-service -> Geschäftslogik fehlt.

---

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/
ADR-0025: Plan-USB	docs/01_Architecture/adr/0025-plan-usb-offline-integritaet.md
ADR-0026: Lizenzierung	docs/01_Architecture/adr/0026-offline-lizenzierung-pay-per-event.md
ADR-0027: Discovery	docs/01_Architecture/adr/0027-netzwerk-discovery-interface-binding.md
Docker-Fix: dc-gui.yaml	dc-gui.yaml
ZNS-Importer Roadmap	docs/01_Architecture/Roadmaps/Roadmap_ZNS_Importer.md
Masterdata Roadmap	backend/services/masterdata/docs/ROADMAP.md
Masterdata Changelog	backend/services/masterdata/docs/CHANGELOG.md
Masterdata Operations	backend/services/masterdata/docs/runbooks/masterdata-ops.md
Zeitplan-Optimierung	docs/01_Architecture/Concepts/konzept-zeitplan-optimierung-de.md
Parcoursbesichtigung-Rulebook	docs/01_Architecture/Concepts/rulebook-check-parcoursbesichtigung-de.md
Status-Automat-Nennungen	docs/01_Architecture/Concepts/status-automat-nennungen-de.md