--- type: Roadmap status: ACTIVE owner: Lead Architect last_update: 2026-04-20 --- # 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 * [x] **Archivierung:** Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach `docs/_archive/` verschoben. * [x] **Konsolidierung:** `Zora_System_Architektur.md` als zentrale Infrastruktur-Doku etablieren. * [x] **Struktur:** `docs/` Ordner aufrĂ€umen (unnötige Root-Files in Unterordner). * [x] **Index:** `README.md` im Root als Einstiegspunkt aktualisieren. ### PHASE 2: Infrastructure Hardening ✅ ABGESCHLOSSEN *Ziel: Stabilisierung der neuen Self-Hosted Umgebung.* #### 🐧 Agent: DevOps Engineer * [x] **Keycloak Fix:** Verbindungsprobleme innerhalb des Docker-Netzwerks behoben (Alias `auth.mo-code.at`). * [x] **Backup Strategy:** Automatisierte Backups fĂŒr Gitea & Datenbanken auf Zora (`config/scripts/backup.sh`). * [x] **Monitoring:** Prometheus/Grafana Dashboard fĂŒr Zora finalisiert (`dc-ops.yaml`). * [x] **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 * [x] **DDD-Analyse:** 6 Bounded Contexts (SCS-Architektur) definiert und priorisiert. * [x] **Terminologie:** `Veranstaltung` ≠ `Turnier` gemĂ€ĂŸ ÖTO § 2 Abs. 1 festgelegt (ADR). * [x] **Design-Baseline:** Vision_03 (Figma) als offizieller Design-Baseline festgelegt. * [x] **Technologie:** Desktop-First-Strategie mit KMP/Compose Desktop beschlossen. #### 📜 Agent: ÖTO/FEI Rulebook Expert * [x] **Ubiquitous Language:** Offizielle DomĂ€nen-Terminologie mit ÖTO-Referenzen erstellt. * [x] **Abteilungs-Schwellenwerte:** Alle Trennungs-Schwellenwerte (§ 39 + spartenspezifisch) dokumentiert. → `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` #### đŸ‘· Agent: Backend Developer * [x] **Enums:** `SparteE`, `TurnierkategorieE`, `VeranstaltungsTypE`, `LizenzKlasseE`, `NennungsStatusE`, `StartwunschE` – ÖTO-konform. * [x] **Domain-Modelle:** `DomReiter` (actor-context), `DomNennung`, `DomNennungsTransfer` (registration-context). * [x] **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 * [x] **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. * [x] **Masterdata Standardization:** Bereinigung und Standardisierung der Masterdaten-Tabellen (Mehrzahl-Konvention: `bundeslaender`, `funktionaers_qualifikationen`, `reit_lizenzen`, `turnier_klassen`). * [x] **ÖTO Data Seeding:** Umfassende Seeder fĂŒr FunktionĂ€rs-Qualifikationen, Turnierklassen und Turnier-Sparten gemĂ€ĂŸ ÖTO implementiert. EinfĂŒhrung der Tabelle `turnier_sparten`. * [x] **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. * [x] **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. * [x] **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 * [x] **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` * [x] **API-Design:** Schnittstellen zwischen den Contexts definieren (Anti-Corruption Layer). → `docs/01_Architecture/adr/0016-api-design-acl-de.md` * [x] **ÖTO-Validation-Seeds:** Seed-Daten fĂŒr Lizenz-Matrix und Altersklassen finalisiert (V008). #### đŸ‘· Agent: Backend Developer * [x] **ZNS-Importer:** Support fĂŒr Richter-Import (RICHT01.DAT) und Reiter-Refactoring (LIZENZ01.DAT) vervollstĂ€ndigt. ✓ * [x] **Masterdata:** Qualifikations-System und Personen-Referenzen (Vereine, BundeslĂ€nder, Nationen) stabilisiert (Consul & MasterdataSeeder). ✓ * [x] **Infrastruktur:** Service-Discovery (Consul) fĂŒr alle Microservices (incl. Masterdata) aktiviert. * [x] **Infrastruktur:** Bean-Definitionen und Dependency-Injection im `zns-import-service` bereinigt. * [x] **Database:** Initialisierung der FunktionĂ€rs-Tabellen stabilisiert (PSQLException Fix). * [x] **`actor-context`:** Domain-Modelle fĂŒr `Pferd`, `Funktionaer`, `Verein` implementiert. * [x] **`registration-context`:** `DomBewerb`, `DomAbteilung`, `DomStartliste` implementiert. * [x] **`event-management-context`:** `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert. * [x] **Persistenz:** Repository-Interfaces und erste DB-Migrationen (Flyway/Liquibase). * [x] **API:** REST-Endpunkte fĂŒr Nennungs-Workflow (Kern-Use-Cases). * [x] **Infrastruktur-Stabilisierung:** Kompilierfehler in `masterdata-infrastructure` behoben. * [x] **Identity-Schnittstellen:** Endpunkte fĂŒr ZNS-Linking ĂŒber `identity-service` bereitgestellt. #### 🎹 Agent: Frontend Expert * [x] **KMP/Compose Desktop:** Projektstruktur aufgesetzt (`frontend/shells/meldestelle-desktop`). * [x] **Navigation:** Sidebar-Navigation gemĂ€ĂŸ Vision_03 implementiert (Veranstaltungen, Reiter, Pferde, FunktionĂ€re, Meisterschaften, Cups). * [x] **Nennungs-Screen:** `TurnierDetailScreen` integriert `NennungsMaske` aus `nennung-feature` (Bewerbe-Tab ⭐). #### 📜 Agent: ÖTO/FEI Rulebook Expert * [x] **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) * [x] **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) * [x] **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) * [x] **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` * [x] Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul) * [x] Domain-Mapping & Upsert in DB (Phase 2) * [x] REST-API & Job-Management (Phase 1 – Controller/Job-Registry) * [x] 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.* * [x] **`competition-context`:** Bewerbe, Startlisten, Ergebnisse, Abteilungs-Warn-Logik. * [x] **`event-management-context`:** Veranstaltungs- und Turnier-Verwaltung, Ausschreibungs-Generator. * [x] **ZNS-Integration:** Schnittstelle zum Zentralen Nennungs-System (A-Satz / B-Satz). * [x] **Offline-Sync:** Offline-First-Strategie fĂŒr Desktop-App implementieren. ### PHASE 6: P3-Contexts & Billing ✅ ABGESCHLOSSEN *Ziel: `billing-context` und `identity-context` implementieren.* * [x] **`billing-context`:** GebĂŒhrenberechnung, Kassa, Abrechnung. * [x] **`identity-context`:** Rollen-Modell (TBA, Veranstalter, Richter etc.) mit Keycloak. * [x] **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.* * [x] **Zentrale Verwaltung:** Etablierung der `Veranstaltung-Verwaltung` (Zentrale) als administratives Cockpit. * [x] **Navigation:** Implementierung eines Back-Stack-Systems fĂŒr intelligente "ZurĂŒck"-Navigation. * [x] **DomĂ€nen-Synchronisation:** Anpassung der Frontend-Stores an die Backend-Masterdata-Modelle (Reiter, Pferde, Vereine, FunktionĂ€re). * [x] **ZNS-Integration (Frontend):** ZNS-Importer in die Zentrale integriert; Konzept "Globaler Pool -> Lokale Synchronisation" gefestigt. * [x] **Terminologie:** UI-weit Umstellung von "Event" auf "Veranstaltung" (ÖTO-konform). * [x] **Konzept:** LAN-Discovery (mDNS) und Echtzeit-Sync (WebSockets) entworfen. * [x] **ADR:** ADR-0020 (Lokale Netzwerk-Kommunikation) erstellt. ### PHASE 8: Bewerbe-Management & Startlisten ✅ ABGESCHLOSSEN *Ziel: Fachliche Tiefe in den Turnieren (Import, Generierung, Zeitberechnung).* * [x] **Konzept/ADR:** LAN‑Sync (ADR‑0022) und Offline‑First Desktop↔Backend Konzept definiert und verlinkt. * [x] **Bewerbe-Import:** Implementierung der Merge-Logik (ZNS-XML -> BewerbUiModel). ✓ * [x] **Startlisten-Automatisierung:** Generierung und Zeitberechnung (Pausen, Umbauzeiten). ✓ * [x] **Discovery:** Implementierung des mDNS-Service (JmDNS) fĂŒr die GerĂ€te-Suche. ✓ * [x] **Transport:** Aufbau der WebSocket-Infrastruktur fĂŒr P2P-Sync (Ktor WebSockets, SyncManager). ✓ * [x] **Offline-First Desktop↔Backend:** Umsetzung gemĂ€ĂŸ Konzept „Offline-First Synchronisation (Desktop ↔ Backend)“ → `docs/01_Architecture/konzept-offline-first-desktop-backend-de.md`. ✓ * [x] **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.* * [x] **Billing-Service:** Initialisierung, Teilnehmer-Konten & Buchungs-Logik (v1). ✓ * [x] **Entries-Integration:** Automatische Buchung von Nenngeldern bei Nennungs-Abgabe. ✓ * [x] **ZNS-Importer:** Hardening & Integrationstests fĂŒr FunktionĂ€rs-Updates. ✓ * [x] **Konzept:** Fachliches Konzept fĂŒr Zeitplan-Optimierung (Drag & Drop) erstellt. ✓ * [x] **Konzept:** Status-Automat fĂŒr Nennungen & Zeitplan-Synchronisation spezifiziert. ✓ * [x] **Frontend-Standardisierung:** `nennung-feature` refactored und in Desktop-Shell integriert. ✓ * [x] **Rulebook-Check:** ÖTO §43 "Parcoursbesichtigung zu Pferd" eingearbeitet. ✓ * [x] **Feature-Migration:** Pferde-, Reiter-, FunktionĂ€rs- und Veranstalter-Module vollstĂ€ndig auf KMP umgestellt. ✓ * [x] **Cleanup:** `FRONTEND_CLEANUP_TODO.md` fĂŒr Migration von `v2` Screens weitestgehend abgeschlossen. ✓ * [x] **Zeitplan:** Dynamische Verschiebung von Bewerben (Drag & Drop im Kalender). ✓ * [x] **Protokoll:** Implementierung eines Event-Logs fĂŒr manuelle Eingriffe in Startlisten (Audit-Log). ✓ * [x] **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).* * [x] **Frontend-Integration:** Stammdaten-Infrastruktur (Repositories, ViewModels) fĂŒr Reiter, Pferde, FunktionĂ€re und Vereine im `turnier-feature` implementiert. ✓ * [x] **Nennungs-Management:** Funktionalisierung des Nennungs-Tabs mit Echt-Datenanbindung und Suche. ✓ * [x] **`series-context`:** Pluggable Berechnungsmodell (Streichresultate, Alles zĂ€hlt), konfigurierbare Paar-Bindung (Reiter+Pferd vs. Einzelwertung) implementiert. ✓ * [x] **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.* * [x] **Backend (Results):** Implementierung der GeschĂ€ftslogik fĂŒr Wertnoten, Zeitfehler und ÖTO-konforme Platzierungen. ✓ * [x] **Backend-Infrastruktur:** `results-service` in Docker-Compose und API-Gateway integriert; Service-Discovery via Consul aktiviert. ✓ * [x] **Frontend UI:** `ErgebnisEditDialog` zur schnellen Ergebniserfassung und `TurnierErgebnislistenTab` zur Anzeige realer Ergebnisse. ✓ * [x] **PDF-Export:** Generierung von PDF-Ergebnislisten (Bewerbe und Serien). ✓ ### PHASE 12: Abrechnung & Billing đŸ”” IN ARBEIT *Ziel: VollstĂ€ndige Kassa-FunktionalitĂ€t und Turnier-Abrechnung.* * [x] **Backend-Infrastruktur:** `billing-service` initialisiert, Docker-Integration und Gateway-Routing (Port 8087) konfiguriert. ✓ * [x] **Frontend-Anbindung:** `BillingRepository` (Ktor) und `BillingViewModel` auf reale API-Kommunikation umgestellt. ✓ * [x] **Buchungs-Logik:** Implementierung von Soll/Haben-Buchungen (StartgebĂŒhren, Nenngelder, Boxen). ✓ * [x] **Offene Posten:** Liste aller unbezahlten BetrĂ€ge pro Teilnehmer/Pferd. ✓ * [x] **Rechnungserstellung:** Generierung von PDF-Rechnungen und ZahlungsbestĂ€tigungen. ✓ * [x] **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.* * [x] **"V2"-Bereinigung:** VollstĂ€ndige Eliminierung aller "V2"-Suffixe in Dateinamen und Symbolen (z.B. `TurnierWizardV2`, `VeranstalterAuswahlV2`). ✓ (20. April 2026) * [x] **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) * [x] **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) * [x] **Device-Setup ("Lock-and-Edit"):** EinfĂŒhrung eines Review-Modus mit Konfigurations-Sperre, Drucker-Integration und Maskierung des SharedKeys. ✓ (20. April 2026) * [x] **Veranstaltungs-Wizard:** Implementierung eines 6-stufigen Profi-Workflows mit Sticky Preview-Card (WYSIWYG), ZNS-Guard und OEPS-Satznummer-Mapping. ✓ (20. April 2026) * [x] **Code-Hygiene:** Beseitigung von Code-Smells, redundanten Validierungen und ungenutzten Parametern in den zentralen Frontend-Modulen. ✓ (20. April 2026) * [x] **Connectivity-Diagnose:** Stabiles Diagnose-Tool fĂŒr Backend-, DB- und Auth-Verbindung in der Desktop-App. ✓ (18. April 2026) * [x] **WASM-Transition:** Projektweite Umstellung auf JVM (Desktop) und wasmJs (Web). Eliminierung von `js(IR)`. ✓ (18. April 2026) * [x] **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 * [x] **Web-App Shell:** Modul `frontend:shells:meldestelle-web` (Compose WasmJS) initialisiert. * [x] **UI-Komponenten:** `VeranstaltungsCard` und `TurnierCard` fĂŒr Web implementiert (mit PDF- & Nenn-Button). * [x] **Workflow:** `NennungWebFormular` Prototyp erstellt (mit simuliertem Mail-Versand). #### đŸ‘· Agent: Backend Developer * [x] **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 * [x] **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 * [x] **Onboarding UI:** Implementierung des Onboarding-Screens (Name, Key, Backup, Rolle, Sync, Drucker) mit validierten Eingaben. * [x] **Navigation:** Navigations-Rail mit Hover-Tooltips und dedizierten Icons fĂŒr "Setup" und "Sync". * [x] **Settings:** Persistente Speicherung der Onboarding-Daten in `settings.json`. #### đŸ‘· Agent: Backend Developer * [x] **Device Management:** Domain-Modell (`Device`), Tabelle (`identity_devices`) und Repository zur GerĂ€teverwaltung implementiert. * [x] **Security Key Auth:** Implementierung des `DeviceSecurityFilter` zur Authentifizierung via `X-Security-Key` Header. * [x] **Onboarding API:** REST-Endpunkte zur Registrierung und Abfrage von Desktop-Instanzen erstellt. #### đŸ§č Agent: Curator * [x] **Dokumentation:** Erstellung der Architektur-Doku fĂŒr das Onboarding-Backend.