mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

chore: remove obsolete screens from meldestelle-desktop module
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Failing after 2m56s
Details
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Failing after 3m3s
Details
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Failing after 2m49s
Details
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Successful in 2m13s
Details

Browse Source 
- Deleted unused screens including `AdminUebersichtScreen`, `AktorScreens`, `StammdatenImportScreen`, `TurnierDetailScreen`, and supporting components such as `PlaceholderContent`.
- Cleaned up references and placeholders to streamline module structure.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
Stefan Mogeritsch
2026-03-26 15:08:38 +01:00
parent 1d393fdefe
commit c2b3b5889f
50 changed files with 5067 additions and 1016 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/06_Frontend/ARCHITECTURE_RULES.md
+163
View File
@@ -0,0 +1,163 @@
# Frontend-Architektur-Richtlinien
> **Status:** Verbindlich ab 26.03.2026
> **Zuständig:** 🏗️ Lead Architect
> **Zweck:** Verhindert Architektur-Drift und inkonsistente Schichtentrennung.
---
## Die 3 Schichten
```
frontend/
├── core/ ← Infrastruktur (plattformübergreifend, kein Business-Code)
├── features/ ← Fachliche Bausteine (je ein Bounded Context)
└── shells/ ← Ausführbare Apps (nur Verdrahtung, kein Fach-UI)
```
---
## Schicht 1: `core/`
### Aufgabe
Gemeinsame Infrastruktur, die von **allen** Features und Shells genutzt wird.
### Module
| Modul | Inhalt |
|-----------------|-----------------------------------------------------------------|
| `auth` | Login, Token-Management, OIDC/PKCE, `LoginScreen` |
| `design-system` | Farben, Typografie, gemeinsame UI-Komponenten, `SharedUiModels` |
| `domain` | Gemeinsame Domain-Modelle (plattformübergreifend) |
| `navigation` | `AppScreen`-Sealed-Class (einzige Wahrheit über alle Routen) |
| `network` | Ktor-Client, `NetworkConfig` |
| `local-db` | SQLDelight/Room-Setup, `DatabaseProvider` |
| `sync` | Offline-Sync-Infrastruktur |
### Regeln
- ✅ Darf importieren: externe Libraries, andere `core`-Module (keine Zyklen)
- ❌ Darf NICHT importieren: `features/*`, `shells/*`
- ❌ Kein Business-Code, keine fachlichen Screens
---
## Schicht 2: `features/`
### Aufgabe
Jedes Feature kapselt **einen Bounded Context** vollständig: Daten, Logik und UI.
### Pflicht-Struktur eines Feature-Moduls
```
features/<name>-feature/
└── src/
└── jvmMain/kotlin/at/mocode/<name>/feature/
├── data/ ← Repository, API-Client
├── domain/ ← Modelle, Use Cases
├── presentation/ ← ViewModel + Screen-Composables ← PFLICHT
└── di/ ← Koin-Module
```
### Vorhandene Features
| Feature | Bounded Context |
|-------------------------|-----------------------------------------------|
| `ping-feature` | Verbindungstest / Sync-Status |
| `nennung-feature` | Nennungs-Erfassung am Turnier |
| `zns-import-feature` | ZNS-Stammdaten-Import |
| `veranstalter-feature` | Veranstalter-Auswahl, -Detail, -Neuanlage |
| `veranstaltung-feature` | Veranstaltungs-Übersicht, -Detail, -Neuanlage |
| `turnier-feature` | Turnier-Detail, alle Tabs, Akteure |
### Regeln
- ✅ Darf importieren: `core/*`
- ❌ Darf NICHT importieren: andere `features/*`, `shells/*`
- ✅ **Jedes Feature MUSS seinen eigenen Screen in `presentation/` haben**
- ❌ Screen-Composables gehören NICHT in den Shell
---
## Schicht 3: `shells/`
### Aufgabe
Einstiegspunkt einer konkreten App. Verdrahtet Features und Core zu einer lauffähigen Anwendung.
### Erlaubter Inhalt im Shell
```
shells/<name>/
└── src/jvmMain/kotlin/at/mocode/desktop/
├── main.kt ← App-Einstiegspunkt, Koin-Init
├── DesktopApp.kt ← Root-Composable, Login-Gate
├── di/DesktopModule.kt ← Shell-spezifische DI
├── navigation/ ← Navigation-Port (optional)
└── screens/
├── layout/DesktopMainLayout.kt ← Navigation + Layout-Gerüst
└── preview/ScreenPreviews.kt ← @Preview-Funktionen (IDE-only)
```
### Regeln
- ✅ Darf importieren: `core/*`, `features/*`
- ✅ Darf enthalten: `main.kt`, `DesktopApp.kt`, DI-Verdrahtung, Layout, Previews
- ❌ Darf NICHT enthalten: fachliche Screen-Composables (gehören in Features)
- ❌ Darf NICHT enthalten: ViewModels, Repositories, Business-Logik
---
## Abhängigkeits-Diagramm
```
shells/meldestelle-desktop
├── core/auth
├── core/design-system
├── core/domain
├── core/navigation
├── core/network
├── core/local-db
├── core/sync
├── features/ping-feature
├── features/nennung-feature
├── features/zns-import-feature
├── features/veranstalter-feature
├── features/veranstaltung-feature
└── features/turnier-feature
features/* → core/* (nur)
core/* → (keine internen Abhängigkeiten außer erlaubte core-zu-core)
```
---
## Checkliste: Neues Feature anlegen
1. `frontend/features/<name>-feature/` Verzeichnis anlegen
2. `build.gradle.kts` nach Vorlage `nennung-feature` erstellen
3. Eintrag in `settings.gradle.kts` unter `// --- FEATURES ---` hinzufügen
4. Eintrag in `shells/meldestelle-desktop/build.gradle.kts` unter `// Feature-Module` hinzufügen
5. Screen in `presentation/` implementieren
6. DI-Modul in `di/` implementieren
7. DI-Modul in `shells/.../main.kt` registrieren
8. Route in `core/navigation/AppScreen.kt` eintragen
9. Navigation-Case in `shells/.../screens/layout/DesktopMainLayout.kt` eintragen
---
## Anti-Patterns (verboten)
| Anti-Pattern | Warum verboten |
|------------------------------------|------------------------------------------------------|
| Screen-Composable direkt im Shell | Verletzt Schichttrennung, nicht wiederverwendbar |
| Feature importiert anderes Feature | Erzeugt Kopplung, verhindert unabhängige Entwicklung |
| `core` importiert `features` | Zirkuläre Abhängigkeit |
| Shared-Modelle im Shell definieren | Gehören in `core/design-system` oder `core/domain` |
| ViewModel im Shell | Gehört ins Feature |
---
*Letzte Aktualisierung: 26.03.2026 — nach Architektur-Refactor (Screens aus Shell in Features verschoben)*
docs/06_Frontend/Navigation_Routing_Diagramm.md
+200
View File
@@ -0,0 +1,200 @@
---
type: Reference
status: ACTIVE
owner: Lead Architect
last_update: 2026-03-26
---
# Navigation & Routing Diagramm — Meldestelle Desktop
🏗️ **[Lead Architect]** | 26. März 2026
Dieses Dokument visualisiert alle Screens und Navigationsübergänge der Compose Desktop App.
Generiert aus: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/`
---
## 1. Übersicht: NavRail-Einstiegspunkte
Die linke Navigationsleiste (NavRail) bietet folgende Direkteinstiege:
| Icon | Label | Ziel-Screen | Status |
|------|-------------------|--------------------|-----------------------------|
| 📅 | Veranstaltungen | `Veranstaltungen` | ✅ Implementiert |
| 🏇 | Reiter | `Reiter` | ⬜ Placeholder |
| 🐴 | Pferde | `Pferde` | ⬜ Placeholder |
| 👤 | Funktionäre | `Funktionaere` | ⬜ Placeholder |
| 🏆 | Meisterschaften | `Meisterschaften` | ⬜ Placeholder |
| 🥇 | Cups | `Cups` | ⬜ Placeholder |
| 📥 | Stammdaten-Import | `StammdatenImport` | 🟡 UI fertig, Polling offen |
---
## 2. Vollständiges Navigationsfluss-Diagramm
```mermaid
flowchart TD
%% ─── App-Start & Auth ───────────────────────────────────────────
START([App Start]) --> LOGIN
LOGIN["🔐 Login\n/auth/login"]
LOGIN -->|"onSuccess (returnTo)"| VERANSTALTUNGEN
AUTH_GUARD{{"🛡️ Auth Guard\n(nicht eingeloggt?)"}}
AUTH_GUARD -->|"nicht authentifiziert"| LOGIN
%% ─── NavRail Top-Level ──────────────────────────────────────────
NAVRAIL(["🗂️ NavRail"])
NAVRAIL --> VERANSTALTUNGEN
NAVRAIL --> REITER
NAVRAIL --> PFERDE
NAVRAIL --> FUNKTIONAERE
NAVRAIL --> MEISTERSCHAFTEN
NAVRAIL --> CUPS
NAVRAIL --> STAMMDATEN_IMPORT
%% ─── Veranstaltungen-Flow ───────────────────────────────────────
VERANSTALTUNGEN["📅 Veranstaltungen\n(AdminUebersichtScreen)\n/veranstaltungen"]
VERANSTALTUNGEN -->|"+ Neue Veranstaltung"| VERANSTALTER_AUSWAHL
VERANSTALTUNGEN -->|"Veranstaltung öffnen (id)"| VERANSTALTUNG_DETAIL
VERANSTALTER_AUSWAHL["🏢 Veranstalter auswählen\n/veranstalter/auswahl"]
VERANSTALTER_AUSWAHL -->|"Zurück"| VERANSTALTUNGEN
VERANSTALTER_AUSWAHL -->|"Weiter (veranstalterId)"| VERANSTALTER_DETAIL
VERANSTALTER_DETAIL["🏢 Veranstalter Detail\n/veranstalter/{id}"]
VERANSTALTER_DETAIL -->|"Zurück"| VERANSTALTER_AUSWAHL
VERANSTALTER_DETAIL -->|"Veranstaltung öffnen (vId)"| VERANSTALTUNG_UEBERSICHT
VERANSTALTER_DETAIL -->|"Neue Veranstaltung gespeichert"| VERANSTALTER_DETAIL
VERANSTALTUNG_UEBERSICHT["📋 Veranstaltung Übersicht\n/veranstalter/{verId}/veranstaltung/{vId}"]
VERANSTALTUNG_UEBERSICHT -->|"Zurück"| VERANSTALTER_DETAIL
VERANSTALTUNG_UEBERSICHT -->|"Turnier öffnen (tId)"| TURNIER_DETAIL
VERANSTALTUNG_UEBERSICHT -->|"+ Neues Turnier"| TURNIER_NEU
VERANSTALTUNG_DETAIL["📄 Veranstaltung Detail\n/veranstaltung/{id}"]
VERANSTALTUNG_DETAIL -->|"Zurück"| VERANSTALTUNGEN
VERANSTALTUNG_DETAIL -->|"+ Neues Turnier"| TURNIER_NEU
VERANSTALTUNG_DETAIL -->|"Turnier öffnen (tId)"| TURNIER_DETAIL
VERANSTALTUNG_NEU["➕ Neue Veranstaltung\n/veranstaltung/neu"]
VERANSTALTUNG_NEU -->|"Zurück"| VERANSTALTUNGEN
VERANSTALTUNG_NEU -->|"Speichern"| VERANSTALTUNGEN
TURNIER_DETAIL["🏟️ Turnier Detail\n/veranstaltung/{vId}/turnier/{tId}\n(inkl. Nennungs-Tab ⭐)"]
TURNIER_DETAIL -->|"Zurück"| VERANSTALTUNG_DETAIL
TURNIER_NEU["➕ Neues Turnier\n/veranstaltung/{vId}/turnier/neu"]
TURNIER_NEU -->|"Zurück"| VERANSTALTUNG_DETAIL
TURNIER_NEU -->|"Speichern"| VERANSTALTUNG_DETAIL
%% ─── Stammdaten-Import ──────────────────────────────────────────
STAMMDATEN_IMPORT["📥 Stammdaten Import\n/stammdaten/import\n(ZNS ZIP-Import)"]
%% ─── Placeholder Screens ────────────────────────────────────────
REITER["🏇 Reiter\n/reiter\n⬜ Placeholder"]
PFERDE["🐴 Pferde\n/pferde\n⬜ Placeholder"]
FUNKTIONAERE["👤 Funktionäre\n/funktionaere\n⬜ Placeholder"]
MEISTERSCHAFTEN["🏆 Meisterschaften\n/meisterschaften\n⬜ Placeholder"]
CUPS["🥇 Cups\n/cups\n⬜ Placeholder"]
%% ─── Logout ─────────────────────────────────────────────────────
LOGOUT(["🚪 Logout"])
LOGOUT -->|"Token löschen"| LOGIN
%% ─── Styling ────────────────────────────────────────────────────
style LOGIN fill:#f0a500,color:#000
style AUTH_GUARD fill:#e74c3c,color:#fff
style VERANSTALTUNGEN fill:#2ecc71,color:#000
style TURNIER_DETAIL fill:#3498db,color:#fff
style STAMMDATEN_IMPORT fill:#9b59b6,color:#fff
style REITER fill:#bdc3c7,color:#555
style PFERDE fill:#bdc3c7,color:#555
style FUNKTIONAERE fill:#bdc3c7,color:#555
style MEISTERSCHAFTEN fill:#bdc3c7,color:#555
style CUPS fill:#bdc3c7,color:#555
```
---
## 3. Screens nach Status
### ✅ Vollständig implementiert
| Screen | Route | Komponente |
|-----------------------------|---------------------------------------------|-----------------------------------------|
| Login | `/auth/login` | `LoginScreen` |
| Veranstaltungen (Übersicht) | `/veranstaltungen` | `AdminUebersichtScreen` |
| Veranstalter Auswahl | `/veranstalter/auswahl` | `VeranstalterAuswahlScreen` |
| Veranstalter Detail | `/veranstalter/{id}` | `VeranstalterDetailScreen` |
| Veranstaltung Übersicht | `/veranstalter/{verId}/veranstaltung/{vId}` | `VeranstaltungUebersichtScreen` |
| Veranstaltung Detail | `/veranstaltung/{id}` | `VeranstaltungDetailScreen` |
| Veranstaltung Neu | `/veranstaltung/neu` | `VeranstaltungNeuScreen` |
| Turnier Detail | `/veranstaltung/{vId}/turnier/{tId}` | `TurnierDetailScreen` + `NennungsMaske` |
| Turnier Neu | `/veranstaltung/{vId}/turnier/neu` | `TurnierNeuScreen` |
### 🟡 Teilweise implementiert
| Screen | Route | Offen |
|-------------------|----------------------|------------------------------------------------|
| Stammdaten Import | `/stammdaten/import` | Status-Polling zum Backend fehlt (ZNS Phase 3) |
### ⬜ Placeholder (NavRail sichtbar, Screen leer)
| Screen | Route |
|-----------------|--------------------|
| Reiter | `/reiter` |
| Pferde | `/pferde` |
| Funktionäre | `/funktionaere` |
| Meisterschaften | `/meisterschaften` |
| Cups | `/cups` |
### 🗑️ Definiert aber nicht in Desktop-Navigation eingebunden
| Screen | Route | Hinweis |
|------------------|----------------------|---------------------------------|
| Landing | `/` | Web-App Relikt |
| Home | `/home` | Web-App Relikt |
| Dashboard | `/dashboard` | Web-App Relikt |
| Ping | `/ping` | Dev/Health-Check |
| Profile | `/profile` | Web-App Relikt |
| OrganizerProfile | `/organizer/profile` | Web-App Relikt |
| AuthCallback | `/auth/callback` | Web-App Relikt (OAuth Redirect) |
| Nennung | `/nennung` | Web-App Relikt |
| CreateTournament | `/tournament/create` | Web-App Relikt |
---
## 4. Wichtige Hinweise
### Auth Guard
Jeder Screen (außer `Login`) ist durch den Auth Guard geschützt:
```
if (!authState.isAuthenticated && currentScreen !is AppScreen.Login) {
nav.navigateToScreen(AppScreen.Login(returnTo = AppScreen.Veranstaltungen))
}
```
### Web-App Relikte im AppScreen
Es existieren 9 Screens (`Landing`, `Home`, `Dashboard`, `Ping`, `Profile`, `OrganizerProfile`,
`AuthCallback`, `Nennung`, `CreateTournament`), die aus der alten Web-App stammen und in der
Desktop-App nicht gerendert werden. → **Offene Entscheidung:** Bereinigen oder für zukünftige
Web-App-Phase behalten? Siehe ADR-Bedarf.
### Nennungs-Tab ⭐
Der `TurnierDetailScreen` enthält den wichtigsten fachlichen Screen: die `NennungsMaske`
(Bewerbe-Tab). Dies ist das Herzstück des `registration-context`.
---
## 5. Referenzen
- Quellcode: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/DesktopApp.kt`
- Quellcode: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/DesktopMainLayout.kt`
- Quellcode: `frontend/core/src/commonMain/kotlin/at/mocode/frontend/core/navigation/AppScreen.kt`
- ZNS-Importer Roadmap: `docs/01_Architecture/Roadmap_ZNS_Importer.md`
- Figma Design-Baseline: Vision_03 (ADR Session Log 2026-03-24)
docs/99_Journal/2026-03-26_Session_Log_Architektur_Refactor.md
+77
View File
@@ -0,0 +1,77 @@
# Session Log: Frontend-Architektur-Refactor
**Datum:** 26.03.2026
**Agent:** 🏗️ Lead Architect
**Dauer:** ~1 Session
**Trigger:** Inkonsistente Schichttrennung — fachliche Screens lagen im Shell statt in Features
---
## Problem
Die Desktop-App hatte alle Screen-Composables direkt im Shell-Modul (`meldestelle-desktop/screens/`).
Das verletzt das Shell-Feature-Core-Pattern:
- Shell enthielt Fachlogik (Veranstalter, Veranstaltung, Turnier, ZNS)
- `zns-import-feature` war gespalten: ViewModel im Feature, Screen im Shell
- `SharedUiModels` (Enums, Badges) lagen im Shell statt in `core/design-system`
---
## Durchgeführte Änderungen
### Neue Feature-Module
| Modul | Inhalt |
|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|
| `frontend/features/veranstalter-feature` | VeranstalterAuswahlScreen, VeranstalterDetailScreen, VeranstalterNeuScreen |
| `frontend/features/veranstaltung-feature` | AdminUebersichtScreen, VeranstaltungenScreen, VeranstaltungDetailScreen, VeranstaltungNeuScreen, VeranstaltungUebersichtScreen |
| `frontend/features/turnier-feature` | TurnierDetailScreen, TurnierNeuScreen, alle 8 Turnier-Tabs, AktorScreens |
### Verschobene Dateien
| Von | Nach |
|----------------------------------------------------|----------------------------------------------------|
| `shells/.../screens/zns/StammdatenImportScreen.kt` | `features/zns-import-feature/.../presentation/` |
| `shells/.../screens/shared/SharedUiModels.kt` | `core/design-system/.../models/` |
| `shells/.../screens/shared/PlaceholderContent.kt` | `core/design-system/.../models/` |
| `shells/.../screens/veranstalter/*.kt` | `features/veranstalter-feature/.../presentation/` |
| `shells/.../screens/veranstaltung/*.kt` | `features/veranstaltung-feature/.../presentation/` |
| `shells/.../screens/turnier/*.kt` | `features/turnier-feature/.../presentation/` |
| `shells/.../screens/aktor/AktorScreens.kt` | `features/turnier-feature/.../presentation/` |
### Konfiguration
- `settings.gradle.kts`: 3 neue Feature-Module eingetragen
- `shells/meldestelle-desktop/build.gradle.kts`: 3 neue Feature-Abhängigkeiten
- `shells/.../DesktopMainLayout.kt`: Imports auf neue Feature-Packages umgestellt
- `shells/.../ScreenPreviews.kt`: Imports auf neue Feature-Packages umgestellt
### Shell nach Refactor
Der Shell enthält jetzt nur noch:
- `main.kt` — Koin-Init, Window
- `DesktopApp.kt` — Root-Composable, Login-Gate
- `di/DesktopModule.kt` — Shell-DI
- `navigation/DesktopNavigationPort.kt` — Navigation-Port
- `screens/layout/DesktopMainLayout.kt` — Layout + Navigation
- `screens/preview/ScreenPreviews.kt` — IDE-Previews
### Neue Dokumentation
- `docs/06_Frontend/ARCHITECTURE_RULES.md` — verbindliche Architektur-Richtlinien mit Checkliste und Anti-Patterns
---
## Offene Punkte
- Gradle-Sync erforderlich, damit Typesafe-Accessors für neue Module generiert werden
- `ArchitectureTest` (falls vorhanden) sollte die neuen Schichtgrenzen prüfen
---
## Lessons Learned
Architektur-Regeln müssen **schriftlich und verbindlich** festgehalten werden, bevor Code geschrieben wird.
Die `ARCHITECTURE_RULES.md` ist ab sofort Pflichtlektüre für jeden Agenten vor dem ersten Commit.
docs/99_Journal/2026-03-26_Session_Log_Figma_Konformitaet.md
+114
View File
@@ -0,0 +1,114 @@
---
type: Journal
status: ACTIVE
owner: Frontend Expert + UI/UX Designer
last_update: 2026-03-26
---
# Session Log: Desktop-App Figma-Konformität (Vision_03)
🎨 **[Frontend Expert]** / 🖌️ **[UI/UX Designer]** / 🧹 **[Curator]** | 26. März 2026
## Kontext
Ziel: Desktop-App an Figma Vision_03 (22 Screenshots) angleichen.
Styling hat keine Priorität — Struktur, Layout und Inhalte stehen im Vordergrund.
---
## Analyse: Figma Vision_03 (22 Screenshots)
| Screenshot | Screen / Tab | Status |
|----------------|--------------------------------|---------------------|
| 01, 04, 05 | TurnierDetail > NENNUNGEN | Struktur vorhanden |
| 02 | TurnierDetail > ERGEBNISLISTEN | Struktur vorhanden |
| 03 | TurnierDetail > STARTLISTEN | Struktur vorhanden |
| 06 | TurnierDetail > ABRECHNUNG | ✅ Neu implementiert |
| 07, 08 | TurnierDetail > ARTIKEL | ✅ Neu implementiert |
| 09, 10, 11, 12 | TurnierDetail > BEWERBE | Struktur vorhanden |
| 13, 14 | TurnierDetail > ORGANISATION | ✅ Neu implementiert |
| 15, 16 | TurnierDetail > STAMMDATEN | ✅ Neu implementiert |
| 17 | VeranstaltungUebersichtScreen | ✅ Überarbeitet |
| 18, 19 | VeranstalterDetailScreen | ✅ Neu implementiert |
| 20, 22 | VeranstalterAuswahlScreen | ✅ Neu implementiert |
| 21 | Neuer Veranstalter (Formular) | ⬜ TODO |
---
## Erledigte Änderungen
### 1. ✅ SharedUiModels.kt (NEU)
- Gemeinsame Enums: `LoginStatus`, `VeranstaltungStatus`
- Gemeinsame Composable: `LoginStatusBadge`
- Eliminiert Duplikate aus 3 Dateien
### 2. ✅ VeranstalterAuswahlScreen.kt (ÜBERARBEITET)
- OEPS-Nummer, Ansprechpartner, E-Mail, Login-Status-Badge
- "+ Neuer Veranstalter"-Button
- Hinweis-Box (blau)
- Abbrechen / "Weiter zum Veranstalter"-Buttons unten
### 3. ✅ VeranstalterDetailScreen.kt (ÜBERARBEITET)
- Avatar-Circle (Initialen)
- OEPS-Nummer, Kontaktdetails-Grid (Ansprechpartner, E-Mail, Telefon, Adresse, Login-Status, Mitglied-seit)
- "Profil bearbeiten"-Button
- Suchfeld + Status-Filter-Chips (Alle/Vorbereitung/Live/Abgeschlossen)
- Veranstaltungs-Liste mit Statistiken (Nennungen, Bewerbe, Letzte Aktivität)
### 4. ✅ VeranstaltungUebersichtScreen.kt (ÜBERARBEITET)
- "VERANSTALTUNG - ÜBERSICHT"-Tab-Header
- Turnier-Nummer als echte ZNS-Nummer (26128, 26129, ...)
- Buttons: Öffnen / Import / Export / USB
### 5. ✅ TurnierStammdatenTab.kt (NEU)
- Turnier-Konfiguration: Nr., Typ (OTO/FEI), ZNS-Import via Internet/USB, Sprache
- Sparten-Checkboxen (Dressur, Springen), Klassen (C/B/A), Kategorien, Datum
- Turnier-Beschreibung: Titel, Sub-Titel
- Sponsoren-Sektion
### 6. ✅ TurnierOrganisationTab.kt (NEU)
- Funktionäre & Offizielle: Turnierleiter, Turnierbeauftragter, Technischer Delegierter, Parcourschef
- Support-Team: Tierarzt, Schmied, Steward
- Richterkollegium: dynamische Liste (Name, Qualifikation-Dropdown, Funktion-Dropdown, Löschen)
- Austragungsplätze: dynamische Liste (Sparte, Größe, Bezeichnung, Löschen)
### 7. ✅ TurnierArtikelTab.kt (NEU)
- Nennungs- und Startgebühren: Nenngebühr, Startgebühr, Sporteuro, Nachnennungsgebühr, Nennungstausch
- Stallungen & Boxen: Box/Tag, Einstreu, Paddock
- Zusatzgebühren: dynamische Liste (Bezeichnung, Betrag, Pflicht-Checkbox)
- Hinweis-Box zur Preisliste
### 8. ✅ TurnierAbrechnungTab.kt (NEU)
- Sub-Tabs: BUCHUNGEN | OFFENE POSTEN | RECHNUNG
- Rechte Sidebar: AUSWAHL | VERKAUF | BUCHUNGEN | ADRESSEN
- Buchungstabelle: Buchungstext, Soll, Haben, Saldo (rot bei offen), Buchen/Rechnung-Checkboxen
- Sidebar: Reiter/Pferd-Suche, Buchen-Betrag, Direkt-Drucken, Zahlungsart (BAR/Scheck/Bankomat/Kreditkarte)
---
## Offene Punkte (TODO)
| Prio | Thema | Aufwand |
|-------|------------------------------------------------------|---------|
| 🟡 P1 | "Neuer Veranstalter"-Formular (Screenshot 21) | Klein |
| 🟡 P1 | BEWERBE-Tab: echte Datentabelle + Bewerb-Formular | Mittel |
| 🟡 P1 | NENNUNGEN-Tab: Pferd+Reiter-Suche + Bewerbsübersicht | Mittel |
| 🟡 P2 | STARTLISTEN-Tab: Bewerbs-Tabs + Sortierung/Zeit | Mittel |
| 🟡 P2 | ERGEBNISLISTEN-Tab: Bewerbs-Tabs + Platzierung | Mittel |
| 🟢 P3 | Styling: Farben, Fonts, Abstände gemäß Figma | Klein |
---
## Referenzen
- Figma Screenshots: `docs/06_Frontend/FIGMA/Vision_03/Screenshots/`
- Quellcode: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/`
- Routing-Diagramm: `docs/06_Frontend/Navigation_Routing_Diagramm.md`
docs/99_Journal/2026-03-26_Session_Log_Figma_Konformitaet_Teil2.md
+54
View File
@@ -0,0 +1,54 @@
# Session Log – Figma-Konformität Teil 2
**Datum:** 26.03.2026
**Agent:** 🎨 Frontend Expert + 🏗️ Lead Architect (Junie)
**Dauer:** ~1h
---
## Ziel
Offene Punkte aus Session "Figma-Konformität Teil 1" abarbeiten:
- "Neuer Veranstalter"-Formular (Screenshot 21)
- BEWERBE-Tab: echte Datentabelle + alle 4 Detail-Panel Sub-Tabs
- NENNUNGEN-Tab: Pferd+Reiter-Suche + Nennungs-Tabelle + Verkauf/Buchungen
- STARTLISTEN-Tab: Bewerbs-Tabs + Sortierung & Zeit-Panel
- ERGEBNISLISTEN-Tab: Bewerbs-Tabs + Platzierung & Geldpreis-Panel
---
## Umgesetzte Änderungen
### Neue Dateien
| Datei | Inhalt |
|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|
| `VeranstalterNeuScreen.kt` | Formular gemäß Screenshot 21: Info-Banner, Vereinsdaten, Kontaktdaten, Adresse, Footer-Buttons mit Validierung |
| `TurnierBewerbeTab.kt` | Vollständige BEWERBE-Implementierung: Datentabelle (12 Spalten), 4 Sub-Tabs (Bewerb/Bewertung/Geldpreise/Ort/Zeit) mit echten Feldern |
| `TurnierNennungenTab.kt` | NENNUNGEN: Pferd+Reiter-Suche, Nennungs-Tabelle mit Status-Badges, Verkauf/Buchungen, Bewerbsübersicht |
| `TurnierStartlistenTab.kt` | STARTLISTEN: Bewerbs-Tabs, Starter-Tabelle, Sortierungs-Optionen, Zeiten-Panel |
| `TurnierErgebnislistenTab.kt` | ERGEBNISLISTEN: Bewerbs-Tabs, Ergebnis-Tabelle, Platzierung & Geldpreis-Panel |
### Geänderte Dateien
| Datei | Änderung |
|--------------------------------|----------------------------------------------------------------------------|
| `AppScreen.kt` | `VeranstalterNeu` als neuer Screen hinzugefügt |
| `VeranstalterAuswahlScreen.kt` | `onNeuerVeranstalter`-Parameter + Button verdrahtet |
| `DesktopMainLayout.kt` | VeranstalterNeu-Screen registriert + Breadcrumb-Eintrag |
| `TurnierDetailScreen.kt` | Placeholder-Implementierungen entfernt, Verweis auf dedizierte Tab-Dateien |
---
## Qualitätssicherung
- Lint-Check auf alle 9 geänderten/neuen Dateien: **keine Fehler**
---
## Offene Punkte (Phase 4/5)
- Echte Daten aus Backend laden (alle Tabs zeigen noch Placeholder-Daten)
- ZNS-Frontend-Integration (Status-Polling) noch offen
- Web-App-Strategie (ADR-0017) noch nicht entschieden
docs/99_Journal/2026-03-26_Session_Log_Screens_Reorganisation.md
+49
View File
@@ -0,0 +1,49 @@
# Session Log: Screens-Reorganisation
**Datum:** 2026-03-26
**Agent:** 🎨 Frontend Expert (Junie)
**Scope:** `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/`
---
## Ziel
Ordnung in das `screens/`-Paket bringen: 24 Flat-Dateien in logische Unterordner aufteilen für bessere Übersicht und
Wartbarkeit.
## Neue Paketstruktur
```
screens/
├── shared/ → SharedUiModels.kt, PlaceholderContent.kt
├── layout/ → DesktopMainLayout.kt
├── veranstalter/ → VeranstalterAuswahlScreen.kt, VeranstalterDetailScreen.kt, VeranstalterNeuScreen.kt
├── veranstaltung/ → AdminUebersichtScreen.kt, VeranstaltungenScreen.kt, VeranstaltungDetailScreen.kt,
│ VeranstaltungNeuScreen.kt, VeranstaltungUebersichtScreen.kt
├── turnier/ → TurnierDetailScreen.kt, TurnierNeuScreen.kt,
│ TurnierStammdatenTab.kt, TurnierOrganisationTab.kt, TurnierBewerbeTab.kt,
│ TurnierArtikelTab.kt, TurnierAbrechnungTab.kt, TurnierNennungenTab.kt,
│ TurnierStartlistenTab.kt, TurnierErgebnislistenTab.kt
├── zns/ → StammdatenImportScreen.kt
├── aktor/ → AktorScreens.kt
└── preview/ → ScreenPreviews.kt
```
## Durchgeführte Änderungen
| Datei | Änderung |
|--------------------------------------------------|--------------------------------------------------------------------------------------|
| Alle 24 Dateien | Package-Deklaration auf neues Sub-Package angepasst |
| `layout/DesktopMainLayout.kt` | Imports für alle Screen-Packages ergänzt |
| `preview/ScreenPreviews.kt` | Imports für alle Screen- und Tab-Composables ergänzt |
| `veranstalter/VeranstalterAuswahlScreen.kt` | Import `shared.LoginStatus`, `shared.LoginStatusBadge` |
| `veranstalter/VeranstalterDetailScreen.kt` | Import `shared.LoginStatus`, `shared.LoginStatusBadge`, `shared.VeranstaltungStatus` |
| `veranstaltung/AdminUebersichtScreen.kt` | Import `shared.VeranstaltungStatus` |
| `veranstaltung/VeranstaltungUebersichtScreen.kt` | Import `shared.VeranstaltungStatus` |
| `DesktopApp.kt` | Import von `screens.DesktopMainLayout` → `screens.layout.DesktopMainLayout` |
## Verifikation
- Lint-Check auf alle kritischen Dateien: ✅ keine Fehler
- Alte Flat-Dateien gelöscht
- `screens/`-Root enthält nur noch die 8 Unterordner
docs/99_Journal/2026-03-26_Session_Log_Struktur_Sprint.md
+78
View File
@@ -0,0 +1,78 @@
---
type: Journal
status: ACTIVE
owner: Lead Architect
last_update: 2026-03-26
---
# Session Log: Struktur-Sprint & Orientierung
🏗️ **[Lead Architect]** / 🧹 **[Curator]** | 26. März 2026
## Kontext
Nach intensiver Phase-4-Arbeit fehlte der Überblick. Ziel dieser Session: Orientierung
wiederherstellen, offene Baustellen priorisieren, zwei konkrete Aufgaben abarbeiten.
---
## Erledigte Aufgaben
### 1. ✅ Routing-Diagramm erstellt
- **Artefakt:** `docs/06_Frontend/Navigation_Routing_Diagramm.md`
- Vollständiges Mermaid-Flowchart aller Screens und Navigationsübergänge
- Screen-Status-Tabellen (✅ implementiert / 🟡 teilweise / ⬜ Placeholder / 🗑️ Relikt)
- **Fund:** 9 Web-App-Relikte im `AppScreen` (siehe offene Entscheidung unten)
### 2. ✅ CI/CD Gradle-Version synchronisiert
- **Datei:** `.gitea/workflows/docker-publish.yaml`
- `GRADLE_VERSION` von `9.3.1` auf `9.4.0` korrigiert (synchron mit `gradle-wrapper.properties`)
- `paths:`-Whitelist war bereits korrekt — Doku-Änderungen triggern die Pipeline nicht
---
## Priorisierte Backlog-Übersicht (Stand 26.03.2026)
| Prio | Thema | Agent | Status |
|-------|--------------------------------------------|--------------------------------|----------------------|
| 🔴 P1 | Desktop-App: Figma-Konformität (Vision_03) | 🎨 Frontend Expert + 🖌️ UI/UX | ⬜ Offen |
| 🔴 P1 | ZNS-Importer Phase 3: Status-Polling | 🎨 Frontend Expert | ⬜ Offen |
| 🟡 P2 | Web-App-Strategie: ADR erforderlich | 🏗️ Lead Architect | ⬜ Entscheidung offen |
| 🟡 P2 | Docker & Datenbanken aufräumen | 🐧 DevOps Engineer | ⬜ Offen |
| 🟢 P3 | CI/CD weiter optimieren | 🐧 DevOps Engineer | ✅ Teilweise erledigt |
---
## Offene Entscheidung: Web-App-Strategie
Im `AppScreen` existieren 9 Screens, die aus der alten Web-App stammen und in der
Desktop-App nicht gerendert werden:
`Landing`, `Home`, `Dashboard`, `Ping`, `Profile`, `OrganizerProfile`,
`AuthCallback`, `Nennung`, `CreateTournament`
**Optionen:**
- **A) Bereinigen:** Relikte aus `AppScreen` entfernen → sauberer Code, weniger Verwirrung
- **B) Behalten:** Für zukünftige Web-App-Phase (Phase 7) aufheben → kein Aufwand jetzt
- **C) Web-App wieder aufbauen:** `meldestelle-portal` reaktivieren → ADR + Planung nötig
→ **ADR-0017 erforderlich**, sobald Entscheidung getroffen.
---
## Nächste empfohlene Schritte
1. **Web-App-Entscheidung** treffen (Option A/B/C) → ADR-0017
2. **Desktop-App Figma-Delta** aufnehmen: Figma Vision_03 vs. aktueller Compose-Code
3. **ZNS Phase 3** abschließen: Status-Polling im `StammdatenImportScreen`
4. **Docker/DB** Ist-Zustand prüfen
---
## Referenzen
- Routing-Diagramm: `docs/06_Frontend/Navigation_Routing_Diagramm.md`
- CI/CD Pipeline: `.gitea/workflows/docker-publish.yaml`
- MASTER_ROADMAP: `docs/01_Architecture/MASTER_ROADMAP.md`