docs: add tournament files for Ebbs Tirol 2026

This commit is contained in:
2026-06-15 12:53:29 +02:00
parent 8816e8d297
commit e4988b4397
11 changed files with 371 additions and 0 deletions
@@ -0,0 +1,77 @@
# Struktur einer Turnier-Ausschreibung gemäß ÖTO
Diese Dokumentation beschreibt die notwendigen Felder und Sektionen einer offiziellen Ausschreibung für den
österreichischen Pferdesport (OEPS).
## 1. Allgemeine Turnierdaten (Header)
Dies entspricht im Wesentlichen dem **A-Satz** der ZNS-Schnittstelle.
* **Turniernummer:** Eindeutige vom OEPS vergebene Kennung (z.B. 25123).
* **Veranstalter:** Name des durchführenden Vereins und dessen Vereinsnummer.
* **Austragungsort:** Genaue Adresse der Reitanlage.
* **Datum:** Von-bis Datum des Turniers.
* **Turnierkategorie:** Einstufung (z.B. CSN-B, CDN-A, CCN-C).
* **Nennschluss:** Datum, bis zu dem reguläre Nennungen möglich sind.
## 2. Besondere Bestimmungen (Rechtlicher Rahmen)
* **Regelwerk:** Hinweis auf die gültige ÖTO (Österreichische Turnierordnung) und ggf. FEI-Regeln.
* **Haftungsausschluss:** Verweis auf die Haftungsbestimmungen der ÖTO.
* **Teilnahmeberechtigung:** Allgemeine Einschränkungen (z.B. nur für Mitglieder bestimmter Landesverbände oder geladene
Gäste).
## 3. Funktionäre (Offizielle)
Wichtig für die Zuweisung im **C-Satz**.
* **Turnierleiter:** Verantwortliche Person des Veranstalters.
* **Richterkollegium:** Liste der Richter inkl. deren Qualifikationen (z.B. "D-GP", "S").
* **Technischer Delegierter (TD):** (Vor allem bei Vielseitigkeit).
* **Parcourschef:** Verantwortlich für das Design der Hindernisse.
* **Turniertierarzt & Schmied:** Notwendige medizinische Versorgung.
## 4. Beschaffenheit der Anlage
Informationen, die Einfluss auf das **DressurPruefungSpezifika** oder **SpringenPruefungSpezifika** haben.
* **Austragungsplatz:** Maße (z.B. 20x60m), Bodenbelag (Sand, Gras).
* **Vorbereitungsplatz:** (Abreiteplatz) Maße und Bodenbelag.
## 5. Nennungen & Gebühren
Grundlage für den **Nennungs_Context**.
* **Nennweg:** Hinweis auf das ZNS (Zentrales Nennsystem).
* **Nenngebühr:** Grundgebühr pro Pferd/Reiter-Paar.
* **Startgebühr:** Gebühr pro einzelner Prüfung.
* **Boxen/Einstreu:** Kosten für fixe oder mobile Boxen, inkl. Erst-Einstreu.
* **Zusatzgebühren:** Stromanschluss, Camping, Nachnenngebühren.
## 6. Prüfungs-Programm (Bewerbe)
Dies ist das Herzstück und bildet den **B-Satz** ab. Jede Prüfung muss folgende Details aufweisen:
### Pflichtfelder pro Prüfung:
| Feld | Beschreibung | Beispiel |
|:-------------------|:--------------------------------------|:---------------------------------|
| **Bewerbsnummer** | Fortlaufende Nummer | 01, 02, ... |
| **Bezeichnung** | Name der Prüfung | Standardspringprüfung |
| **Klasse** | Schwierigkeitsgrad | E, A, L, LM, M, S |
| **Abteilungen** | Unterteilung nach Lizenzen | Abt. 1: R1 / Abt. 2: R2 u. höher |
| **Aufgabe** | (Nur Dressur) Spezifische ÖTO-Aufgabe | A2, L1, FEI Grand Prix |
| **Anforderungen** | Erforderliche Lizenzen/Alter | R1 oder höher |
| **Richtverfahren** | Verweis auf ÖTO-Paragraphen | § 218, § 204 |
| **Dotierung** | Preisgeld-Aufstellung | EUR 500,- (150/100/80/...) |
## 7. Stallungen & Unterbringung
* Anreise- und Abreisezeiten.
* Verfügbarkeit von Futter und Einstreu.
* Veterinäramtliche Bestimmungen (Impfschutz-Kontrolle gemäß ÖTO).
## 8. Vorläufige Zeiteinteilung
* Grober Ablaufplan (welcher Tag, welche Prüfungen).
* Hinweis auf die endgültige Zeiteinteilung (meist am Vorabend im Nennungs-System).
@@ -0,0 +1,77 @@
# Struktur einer Turnier-Ausschreibung gemäß ÖTO
Diese Dokumentation beschreibt die notwendigen Felder und Sektionen einer offiziellen Ausschreibung für den
österreichischen Pferdesport (OEPS).
## 1. Allgemeine Turnierdaten (Header)
Dies entspricht im Wesentlichen dem **A-Satz** der ZNS-Schnittstelle.
* **Turniernummer:** Eindeutige vom OEPS vergebene Kennung (z.B. 25123).
* **Veranstalter:** Name des durchführenden Vereins und dessen Vereinsnummer.
* **Austragungsort:** Genaue Adresse der Reitanlage.
* **Datum:** Von-bis Datum des Turniers.
* **Turnierkategorie:** Einstufung (z.B. CSN-B, CDN-A, CCN-C).
* **Nennschluss:** Datum, bis zu dem reguläre Nennungen möglich sind.
## 2. Besondere Bestimmungen (Rechtlicher Rahmen)
* **Regelwerk:** Hinweis auf die gültige ÖTO (Österreichische Turnierordnung) und ggf. FEI-Regeln.
* **Haftungsausschluss:** Verweis auf die Haftungsbestimmungen der ÖTO.
* **Teilnahmeberechtigung:** Allgemeine Einschränkungen (z.B. nur für Mitglieder bestimmter Landesverbände oder geladene
Gäste).
## 3. Funktionäre (Offizielle)
Wichtig für die Zuweisung im **C-Satz**.
* **Turnierleiter:** Verantwortliche Person des Veranstalters.
* **Richterkollegium:** Liste der Richter inkl. deren Qualifikationen (z.B. "D-GP", "S").
* **Technischer Delegierter (TD):** (Vor allem bei Vielseitigkeit).
* **Parcourschef:** Verantwortlich für das Design der Hindernisse.
* **Turniertierarzt & Schmied:** Notwendige medizinische Versorgung.
## 4. Beschaffenheit der Anlage
Informationen, die Einfluss auf das **DressurPruefungSpezifika** oder **SpringenPruefungSpezifika** haben.
* **Austragungsplatz:** Maße (z.B. 20x60m), Bodenbelag (Sand, Gras).
* **Vorbereitungsplatz:** (Abreiteplatz) Maße und Bodenbelag.
## 5. Nennungen & Gebühren
Grundlage für den **Nennungs_Context**.
* **Nennweg:** Hinweis auf das ZNS (Zentrales Nennsystem).
* **Nenngebühr:** Grundgebühr pro Pferd/Reiter-Paar.
* **Startgebühr:** Gebühr pro einzelner Prüfung.
* **Boxen/Einstreu:** Kosten für fixe oder mobile Boxen, inkl. Erst-Einstreu.
* **Zusatzgebühren:** Stromanschluss, Camping, Nachnenngebühren.
## 6. Prüfungs-Programm (Bewerbe)
Dies ist das Herzstück und bildet den **B-Satz** ab. Jede Prüfung muss folgende Details aufweisen:
### Pflichtfelder pro Prüfung:
| Feld | Beschreibung | Beispiel |
|:-------------------|:--------------------------------------|:---------------------------------|
| **Bewerbsnummer** | Fortlaufende Nummer | 01, 02, ... |
| **Bezeichnung** | Name der Prüfung | Standardspringprüfung |
| **Klasse** | Schwierigkeitsgrad | E, A, L, LM, M, S |
| **Abteilungen** | Unterteilung nach Lizenzen | Abt. 1: R1 / Abt. 2: R2 u. höher |
| **Aufgabe** | (Nur Dressur) Spezifische ÖTO-Aufgabe | A2, L1, FEI Grand Prix |
| **Anforderungen** | Erforderliche Lizenzen/Alter | R1 oder höher |
| **Richtverfahren** | Verweis auf ÖTO-Paragraphen | § 218, § 204 |
| **Dotierung** | Preisgeld-Aufstellung | EUR 500,- (150/100/80/...) |
## 7. Stallungen & Unterbringung
* Anreise- und Abreisezeiten.
* Verfügbarkeit von Futter und Einstreu.
* Veterinäramtliche Bestimmungen (Impfschutz-Kontrolle gemäß ÖTO).
## 8. Vorläufige Zeiteinteilung
* Grober Ablaufplan (welcher Tag, welche Prüfungen).
* Hinweis auf die endgültige Zeiteinteilung (meist am Vorabend im Nennungs-System).
@@ -0,0 +1,23 @@
# Curator Log: 2026-04-13 - Infrastructure & Multiplatform Stability
## 🏗️ Status Update
Die heutige Session konzentrierte sich auf die Wiederherstellung der Build-Stabilität für die Kotlin Multiplatform (KMP) Umgebung und die Behebung kritischer Infrastruktur-Probleme in der Docker-Landschaft.
### Infrastruktur & Docker-Fixes
- **Gateway Conflict:** Behebung des Port-Konflikts (8081), der den lokalen Start der `GatewayApplication` verhinderte (Docker-Container `meldestelle-gateway` gestoppt).
- **Billing Service Recovery:** Der `billing-service` befand sich in einer Restart-Schleife, da die `SPRING_APPLICATION_NAME` Umgebungsvariable fehlte. Dies führte zu einer ungültigen Consul-Registrierung (DNS-konforme Service-IDs erforderlich).
- **Docker Compose:** `dc-backend.yaml` aktualisiert, um `SPRING_APPLICATION_NAME` für den `billing-service` korrekt zu setzen.
### KMP & Build-Stabilisierung
- **Dependency Management:** Kritische Inkompatibilitäten zwischen JVM-only Modulen (`masterdata-infrastructure`, `platform-testing`) und Multiplatform-Modulen (`zns-parser`, `billing-domain`) behoben.
- **SourceSet Refactoring:** `entries-domain` auf KMP-Standardstruktur (`src/commonMain`) umgestellt, um die Verfügbarkeit von Domain-Modellen für das Web-Frontend (WasmJS) sicherzustellen.
- **WasmJs Support:** Fehlende `actual`-Implementierungen für `DatabaseDriverFactory` und `turnierFeatureModule` in WasmJs hinzugefügt, um den Full-Stack Build des Web-Frontends zu ermöglichen.
- **Transitive Dependencies:** `contracts:ping-api` nutzt nun `api` für `core-domain`, damit `Syncable` für alle Konsumenten (z.B. `ping-feature`) sichtbar ist.
## 🧹 Maintenance
- **Validation:** Erfolgreiche Ausführung der `NennungBillingIntegrationTest` (3/3 bestanden).
- **Compilation:** Alle relevanten Module (`entries-service`, `billing-service`, `meldestelle-web`) bauen nun fehlerfrei für ihre jeweiligen Zielplattformen (JVM, JS, WasmJs).
- **Orphan Cleanup:** Hinweis auf verwaiste Container (`meldestelle-scheduling-service`) in der Docker-Umgebung dokumentiert.
---
*Log erstellt am 13.04.2026 durch Junie (Curator Mode).*
@@ -0,0 +1,119 @@
---
type: Journal
status: COMPLETED
agent: 🧹 Curator & 🏗️ Lead Architect
date: 2026-04-18
---
# 📜 Session-Abschluss: Strategische Stabilisierung & Plug-and-Play Architektur
## 🎯 Zusammenfassung
In dieser Session wurde die "Kartenhaus-Instabilität" des Frontends adressiert und nachhaltig gelöst. Der Fokus lag auf
der Wiederherstellung und Absicherung der Kommunikation zwischen Desktop-App, Backend und Keycloak.
## ✅ Erreichte Meilensteine
### 1. Konnektivitäts-Diagnose (ConnectivityCheck)
- Der ehemalige "Sync"-Button wurde fachlich korrekt in **"Ping" (Konnektivitäts-Diagnose)** umbenannt.
- Ein dedizierter Diagnose-Screen ermöglicht nun den Test der Verbindung zum Backend, zur Datenbank und zum Keycloak (
Secure Ping).
- Das **Login-Gate** wurde so angepasst, dass technische Diagnose-Tools auch ohne vorherige Authentifizierung erreichbar
sind.
### 2. Plug-and-Play Architektur (ADR-0024)
- Einführung eines neuen Architektur-Standards für UI-Komponenten.
- **Isolierte Organismen:** Komponenten wie `AuthStatusCard` (Keycloak-Status) und `PingActionGroup` sind nun völlig
autark und können ohne Seiteneffekte überall in der App (Desktop, Web, Mobile) eingesetzt werden.
- **Strict State Hoisting:** UI-Logik wurde konsequent in ViewModels und Repositories ausgelagert, um die
UI-Komponenten "dumm" und damit stabil zu halten.
### 3. Domain-Driven Naming & Cleanup
- Umstellung technischer Screen-Namen auf fachliche Bezeichnungen (z.B. `Ping` -> `ConnectivityCheck`, `Onboarding` ->
`DeviceInitialization`).
- Radikale Bereinigung der Codebasis von Altlasten (ungenutzte Parameter, veraltete Icons, doppelte Navigationsobjekte).
### 4. Tastaturbedienung & Fokus-Management
- **UX-Fix:** Tab-Navigation und Enter-Taste funktionieren nun konsistent im gesamten `DeviceInitialization`-Workflow.
- **Robustes Fokus-Management:** Umstellung auf `LocalFocusManager.moveFocus(FocusDirection.Next)` für alle Felder, um
die systemweite Fokus-Kette zuverlässig abzubilden. Explizite `onKeyEvent` Workarounds für Compose Desktop sichern den
Fokus-Wechsel via ENTER-Taste auch in komplexen Layouts ab.
### 5. Korrekturen: Scrolling & ZNS-Funktionalität
- **Scrolling:** In allen Listen (z.B. Veranstaltungsverwaltung, Pferde, Reiter) wurde die `LazyColumn` mit
`Modifier.weight(1f)` und einer expliziten `VerticalScrollbar` ausgestattet. Dies behebt das Blockieren des Scrollens
und ermöglicht eine intuitive Desktop-Navigation.
- **ZNS-Import:** Unterstützung für `.zip` und `.dat` Dateien in allen Import-Dialogen (`pickZnsFile`) implementiert.
- **ZNS-Sync & Monitoring:** Detaillierte Terminal-Logs im `ZnsImportViewModel` (URL, HTTP-Status, Body, Exceptions)
hinzugefügt, um Diagnose bei Netzwerk- oder Backend-Problemen zu ermöglichen.
- **Automatischer Fokus-Start:** Beim Eintritt in neue Workflow-Schritte (z.B. Schritt 2: MASTER-Konfiguration) erhält
das erste Eingabefeld ("Gerätename") automatisch den Fokus.
- **Pfad-Wahl via Keyboard:** Im Backup-Verzeichnis-Feld öffnet die ENTER-Taste nun direkt den Datei-Dialog (
`JFileChooser`), was einen flüssigen Workflow ohne Griff zur Maus ermöglicht.
- **Rollenauswahl via Keyboard:** Auch im ersten Schritt (Netzwerk-Rolle) kann nun mittels TAB, Pfeiltasten und
Enter/Space navigiert und ausgewählt werden. Automatische Fokus-Weiterleitung zum "Weiter"-Button nach Rollenwahl.
- **Form-Submit via Enter:** In allen relevanten Feldern löst die Enter-Taste nun entweder den Wechsel zum nächsten Feld
oder die finale Bestätigung ("Abschließen") aus, sofern die Validierung erfolgreich ist.
- **Dropdown Keyboard-Support:** Das `MsEnumDropdown` wurde für Tastaturbedienung optimiert und lässt sich nun mittels
Enter-Taste öffnen/schließen. Zusätzliche Unterstützung für D-Pad (DirectionCenter).
- **Client-Management:** Im "Client hinzufügen"-Dialog wurde die Fokus-Kette vervollständigt, sodass neue Clients
effizient ohne Maus angelegt werden können.
### 5. Logging & Diagnose
- **Erweitertes Logging:** Das `DeviceInitializationViewModel` loggt nun alle Status-Übergänge und wichtigen Aktionen (
Rollenwahl, Client-Management, Abschluss) explizit.
- **Verifikation:** Für die Sichtbarkeit der Logs in der Desktop-Umgebung wird der Start via Terminal empfohlen:
`./gradlew :frontend:shells:meldestelle-desktop:run`.
### 6. Stammdaten-Import & Sync-Stabilität
- **Radikales Scrolling-Fix:** Der `StammdatenImportScreen` wurde so umgebaut, dass der gesamte Inhalt auf kleinen
Bildschirmen scrollbar ist (`verticalScroll`). Die Fehlerliste innerhalb des Screens hat eine eigene
`VerticalScrollbar` und eine maximale Höhe erhalten, um das Layout stabil zu halten.
- **Transparenter Cloud-Sync:** Einführung einer neuen Sektion für den direkten Daten-Sync vom OEPS-Server. Inklusive
Anzeige des Zeitpunkts der letzten erfolgreichen Synchronisation.
- **Deep-Logging & Diagnose:** Das `ZnsImportViewModel` wurde um detailliertes "Deep-Logging" erweitert. Es werden nun
URLs, HTTP-Statuscodes und Rohdaten (Body) im Terminal ausgegeben. Spezifische Fehlermeldungen für "Backend nicht
erreichbar", "401 Unauthorized" (Sicherheitsschlüssel prüfen) und "404 Not Found" helfen dem User bei der Selbsthilfe.
- **JSON-Härtung:** Zusätzliche `try-catch` Blöcke beim Decoding von Server-Antworten verhindern App-Crashes bei
unerwarteten Datenformaten.
### 7. Code-Hygiene & Modularisierung (Clean Code)
- **Radikale Modularisierung:** Die ehemals 2000 Zeilen starke `VeranstaltungScreens.kt` wurde in eine saubere,
fachliche Verzeichnisstruktur unterteilt:
- `VeranstaltungVerwaltung.kt`: Zentraler Screen der Veranstaltungsübersicht.
- `components/`: Wiederverwendbare UI-Elemente wie `TurnierCard` und `KpiCard`.
- `wizards/`: Spezialisierte Wizards für `VeranstalterAnlegen` und `TurnierAnlegen` zur Reduzierung der kognitiven
Last.
- `details/`: Fokusierte Profile und Detailansichten für Veranstaltungen.
- **Clean Code:** Beseitigung von Overload-Konflikten und Reduzierung der Dateigrößen auf ein wartbares Maß (< 400
Zeilen pro Datei).
- **Strukturierte Imports:** Bereinigung und Optimierung der Import-Listen zur Vermeidung von Namenskollisionen.
- **Build-Stabilität:** Behebung von `Unresolved reference` Fehlern in `DesktopMainLayout.kt` durch Korrektur der
Import-Pfade nach der Modularisierung und Behebung von Typ-Inferenz-Problemen in Navigations-Lambdas.
- **Modernisierung:** Umstellung auf `AutoMirrored` Icons in `VeranstaltungDetails.kt` zur Behebung von
Deprecation-Warnungen.
## 🛠️ Technische Details
- **ADR-0024:** Dokumentiert die neue Plug-and-Play Richtlinie.
- **Auth-Integration:** `AuthStatusCard` nutzt nun den `AuthTokenManager` via Koin-Injection.
- **Modernisierung:** Umstellung auf `AutoMirrored` Icons gemäß neuesten Material3-Standards.
## 🚀 Übergabe für die nächste Session
Die Basis ist nun blitzsauber und architektonisch gehärtet. Für die nächste Session sind folgende Themen vorbereitet:
- **Echtzeit-Synchronisation:** Aufbauend auf der stabilen Diagnose-Basis kann nun die fachliche Daten-Synchronisation (
Masterdata) angegangen werden.
- **Web-App Alignment:** Übertragung der Plug-and-Play Komponenten in die Web-App Shell.
- **SCS-Integration:** Implementierung weiterer Bounded Contexts unter Nutzung der neuen Komponenten-Struktur.
**Status:** Bereit für neue fachliche Herausforderungen. 🚀
Binary file not shown.