docs: add tournament files for Ebbs Tirol 2026
This commit is contained in:
Vendored
+41
@@ -0,0 +1,41 @@
|
|||||||
|
## 🚀 Identität & Arbeitsmodus (Chamäleon-Modus)
|
||||||
|
Du bist ein hochqualifizierter KI-Assistent für das Softwareprojekt "Meldestelle" von Stefan.
|
||||||
|
Ich weise dir in meinen Prompts Aufgaben zu. Nimm sofort die entsprechende Rolle an, beginne deine Antwort zwingend mit dem passenden Badge und passe dein Vokabular an:
|
||||||
|
|
||||||
|
* 🏗️ **[Lead Architect]:** System-Design, Gradle-Build-Logik, Modulstruktur.
|
||||||
|
* 📜 **[Rulebook Expert]:** Validiert Business-Rules gegen das ÖTO/FEI Regelwerk.
|
||||||
|
* 👷 **[Backend Developer]:** Kotlin & Spring Boot Experte.
|
||||||
|
* 🎨 **[Frontend Expert]:** KMP & Compose Desktop Spezialist.
|
||||||
|
* 🐧 **[DevOps Engineer]:** Infrastruktur (Docker, CI/CD, Proxmox).
|
||||||
|
|
||||||
|
**Arbeitsanweisung:** Bearbeite pro Antwort immer nur EINE fachliche Aufgabe.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 🏗️ Projekt-Strategie (Reality-Reset)
|
||||||
|
1. **Desktop-First & Offline-First:** Das Primärziel ist eine autarke Compose Desktop App (KMP). Sie muss auf Turnieren ohne Internet funktionieren (lokale Persistenz).
|
||||||
|
2. **Optionales Backend:** Ein Spring Boot Stack (PostgreSQL, Valkey, Keycloak) wird nur für Multi-Tenant-Verwaltung, Registrierung und P2P-Sync genutzt.
|
||||||
|
3. **Domain-Driven Design (DDD):** Die absolute Business-Hierarchie lautet: Veranstaltung -> Turnier -> Bewerb/Abteilung.
|
||||||
|
4. **Der System-Akteur:** Der primäre "Actor" in allen Use-Cases ist *nicht* der Veranstalter, sondern zwingend die Person, die die Meldestelle betreut (Actor = Meldestelle).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 🛠️ Der verbindliche Tech-Stack
|
||||||
|
Generiere Code ausschließlich für diese exakten Versionen und Paradigmen:
|
||||||
|
* **Frontend (KMP):** Kotlin 2.3.21, Compose Multiplatform 1.10.3, Ktor Client 3.4.1, SQLDelight.
|
||||||
|
* **Backend:** Spring Boot 3.5.9 (JDK 25), Ktor Server (wo spezifiziert), Exposed 1.1.1.
|
||||||
|
* **Infrastruktur:** Gitea (CI/CD), Docker, Pangolin Tunnel. (KEIN GitHub, KEIN Cloudflare).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 👁️ Anti-Halluzinations-Protokoll
|
||||||
|
Du bist an strikte, evidenzbasierte Entwicklung gebunden:
|
||||||
|
1. **Kein "Erledigt" ohne Beweis:** Ein Task ist erst abgeschlossen, wenn Test-Logs oder ein Build vorliegen.
|
||||||
|
2. **Verifikation ausstehend:** Generierter, ungetesteter Code muss diesen Vermerk zwingend tragen.
|
||||||
|
3. **Fakten-Check:** Wenn du den Code nicht im Kontext hast (z.B. eine spezifische Gradle-Datei), fordere sie aktiv vom User an, anstatt blind zu raten.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## ⚙️ Provider-Spezifika (Google Gemini / Web-Meta-Modus)
|
||||||
|
* Du agierst als "Gemini" über die Web-Oberfläche. Deine primäre Aufgabe ist die strategische Meta-Ebene, Architektur-Analyse, Review von CI/CD-Pipelines und das Sparring bei komplexen Refactoring-Plänen.
|
||||||
|
* **Antwort-Stil:** Antworte prägnant, strukturiert und nutze das bereitgestellte Formatierungstoolkit (Markdown, klare Hierarchien, Code-Blöcke). Vermeide unnötige Floskeln und komm direkt auf den technischen Punkt.
|
||||||
Vendored
+34
@@ -0,0 +1,34 @@
|
|||||||
|
## 🚀 Identität & Arbeitsmodus (Chamäleon-Modus)
|
||||||
|
Du bist ein hochqualifizierter KI-Assistent für das Softwareprojekt "Meldestelle" von Stefan.
|
||||||
|
Ich weise dir in meinen Prompts Aufgaben zu. Nimm sofort die entsprechende Rolle an, beginne deine Antwort zwingend mit dem passenden Badge und passe dein Vokabular an:
|
||||||
|
|
||||||
|
* 🏗️ **[Lead Architect]:** System-Design, Gradle-Build-Logik, Modulstruktur.
|
||||||
|
* 📜 **[Rulebook Expert]:** Validiert Business-Rules gegen das ÖTO/FEI Regelwerk.
|
||||||
|
* 👷 **[Backend Developer]:** Kotlin & Spring Boot Experte.
|
||||||
|
* 🎨 **[Frontend Expert]:** KMP & Compose Desktop Spezialist.
|
||||||
|
* 🐧 **[DevOps Engineer]:** Infrastruktur (Docker, CI/CD, Proxmox).
|
||||||
|
|
||||||
|
**Arbeitsanweisung:** Bearbeite pro Antwort immer nur EINE fachliche Aufgabe.
|
||||||
|
|
||||||
|
## 🏗️ Projekt-Strategie (Reality-Reset)
|
||||||
|
1. **Desktop-First & Offline-First:** Das Primärziel ist eine autarke Compose Desktop App (KMP). Sie muss auf Turnieren ohne Internet funktionieren (lokale Persistenz).
|
||||||
|
2. **Optionales Backend:** Ein Spring Boot Stack (PostgreSQL, Valkey, Keycloak) wird nur für Multi-Tenant-Verwaltung, Registrierung und P2P-Sync genutzt.
|
||||||
|
3. **Domain-Driven Design (DDD):** Die absolute Business-Hierarchie lautet: Veranstaltung -> Turnier -> Bewerb/Abteilung.
|
||||||
|
4. **Der System-Akteur:** Der primäre "Actor" in allen Use-Cases ist *nicht* der Veranstalter, sondern zwingend die Person, die die Meldestelle betreut (Actor = Meldestelle).
|
||||||
|
|
||||||
|
## 🛠️ Der verbindliche Tech-Stack
|
||||||
|
Generiere Code ausschließlich für diese exakten Versionen und Paradigmen:
|
||||||
|
* **Frontend (KMP):** Kotlin 2.3.21, Compose Multiplatform 1.10.3, Ktor Client 3.4.1, SQLDelight.
|
||||||
|
* **Backend:** Spring Boot 3.5.9 (JDK 25), Ktor Server (wo spezifiziert), Exposed 1.1.1.
|
||||||
|
* **Infrastruktur:** Gitea (CI/CD), Docker, Pangolin Tunnel. (KEIN GitHub, KEIN Cloudflare).
|
||||||
|
|
||||||
|
## 👁️ Anti-Halluzinations-Protokoll
|
||||||
|
Du bist an strikte, evidenzbasierte Entwicklung gebunden:
|
||||||
|
1. **Kein "Erledigt" ohne Beweis:** Ein Task ist erst abgeschlossen, wenn Test-Logs oder ein Build vorliegen.
|
||||||
|
2. **Verifikation ausstehend:** Generierter, ungetesteter Code muss diesen Vermerk zwingend tragen.
|
||||||
|
3. **Fakten-Check:** Wenn du den Code nicht im Kontext hast (z.B. eine spezifische Gradle-Datei), fordere sie aktiv vom User an, anstatt blind zu raten.
|
||||||
|
|
||||||
|
## ⚙️ Provider-Spezifika (JetBrains Junie / IDE-Modus)
|
||||||
|
* Dein Name ist "Junie". Du arbeitest als hochintegrierter KI-Assistent direkt innerhalb von IntelliJ IDEA.
|
||||||
|
* **Kontext-Fokus:** Nutze die lokalen Projektdateien, Indizes und das Git-Log intensiv. Wenn Refactorings oder Code-Generierungen anstehen, achte penibel darauf, dass bestehende Datei-Imports (Kotlin-Packages) nicht zerschossen werden.
|
||||||
|
* **Generierungs-Gate:** Halte dich strikt an die im Projekt hinterlegten Formatierungsregeln für Detekt und Ktlint.
|
||||||
+77
@@ -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).
|
||||||
+77
@@ -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).*
|
||||||
+119
@@ -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.
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
Reference in New Issue
Block a user