diff --git a/.ai/dist/gemini-system-prompt.md b/.ai/dist/gemini-system-prompt.md new file mode 100644 index 00000000..309073fe --- /dev/null +++ b/.ai/dist/gemini-system-prompt.md @@ -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. diff --git a/.ai/dist/junie-system-prompt.md b/.ai/dist/junie-system-prompt.md new file mode 100644 index 00000000..d0f9156d --- /dev/null +++ b/.ai/dist/junie-system-prompt.md @@ -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. diff --git a/docs/03_Development/Frontend/FIGMA/Vision_02/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md b/docs/03_Development/Frontend/FIGMA/Vision_02/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md new file mode 100644 index 00000000..ddf63f71 --- /dev/null +++ b/docs/03_Development/Frontend/FIGMA/Vision_02/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md @@ -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). diff --git a/docs/03_Development/Frontend/FIGMA/Vision_03/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md b/docs/03_Development/Frontend/FIGMA/Vision_03/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md new file mode 100644 index 00000000..ddf63f71 --- /dev/null +++ b/docs/03_Development/Frontend/FIGMA/Vision_03/src/imports/Struktur_Turnier-Ausschreibung-gemäß-OETO.md @@ -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). diff --git a/docs/05_Governance/Agents/Logs/2026-04-13_Infrastruktur_Stabilität_Curator_Log.md b/docs/05_Governance/Agents/Logs/2026-04-13_Infrastruktur_Stabilität_Curator_Log.md new file mode 100644 index 00000000..127a5b14 --- /dev/null +++ b/docs/05_Governance/Agents/Logs/2026-04-13_Infrastruktur_Stabilität_Curator_Log.md @@ -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).* diff --git a/docs/05_Governance/Journal/_archive/2026-04-18_Übergabe_Stabilisierung_Diagnose_Architektur.md b/docs/05_Governance/Journal/_archive/2026-04-18_Übergabe_Stabilisierung_Diagnose_Architektur.md new file mode 100644 index 00000000..803ec03d --- /dev/null +++ b/docs/05_Governance/Journal/_archive/2026-04-18_Übergabe_Stabilisierung_Diagnose_Architektur.md @@ -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. 🚀 diff --git a/docs/Turniere-2026/Ebbs-Tirol/26460.pdf b/docs/Turniere-2026/Ebbs-Tirol/26460.pdf new file mode 100644 index 00000000..fd42a978 Binary files /dev/null and b/docs/Turniere-2026/Ebbs-Tirol/26460.pdf differ diff --git a/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaft Haflinger 2026.pdf b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaft Haflinger 2026.pdf new file mode 100644 index 00000000..073509fd Binary files /dev/null and b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaft Haflinger 2026.pdf differ diff --git a/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaften Pony 2026.pdf b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaften Pony 2026.pdf new file mode 100644 index 00000000..7373cc80 Binary files /dev/null and b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Mannschaftsmeisterschaften Pony 2026.pdf differ diff --git a/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaft Haflinger Dressur 2026.pdf b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaft Haflinger Dressur 2026.pdf new file mode 100644 index 00000000..d26491a3 Binary files /dev/null and b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaft Haflinger Dressur 2026.pdf differ diff --git a/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaften Pony Dressur und Springen 2026.pdf b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaften Pony Dressur und Springen 2026.pdf new file mode 100644 index 00000000..b24d90f2 Binary files /dev/null and b/docs/Turniere-2026/Ebbs-Tirol/Tiroler Meisterschaften Pony Dressur und Springen 2026.pdf differ