StefanMoCoAt
85282ea7b4
Some checks failed
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
113 lines
5.7 KiB
Markdown
113 lines
5.7 KiB
Markdown
# 🎨 [Frontend Expert] — Schritt-für-Schritt Roadmap
|
||
|
||
> **Stand:** 2. April 2026
|
||
> **Rolle:** KMP, Compose Desktop, State-Management, MVVM/UDF, Backend-Anbindung
|
||
|
||
---
|
||
|
||
## 🔴 Sprint A — Sofort (diese Woche)
|
||
|
||
- [x] **A-1** | ViewModel-Architektur definieren und Referenz-Implementierung umsetzen
|
||
- [x] MVVM mit UDF (Unidirectional Data Flow) als verbindliches Muster festlegen
|
||
- [x] `Intent`- und `State`-Klassen-Struktur definieren (Vorlage für alle anderen ViewModels)
|
||
- [x] `VeranstalterViewModel` als vollständige Referenz-Implementierung umsetzen
|
||
- [x] `State`-Klasse definieren
|
||
- [x] `Intent`-Klasse (Sealed Class) definieren
|
||
- [x] Business-Logik aus Composables herausziehen (keine `StoreV2`-Aufrufe mehr direkt in `onSaved`)
|
||
- [x] Lokalen `remember`-State durch ViewModel-State ersetzen
|
||
- [x] Ergebnis als Muster-Dokument in `docs/06_Frontend/` ablegen
|
||
|
||
Referenzen:
|
||
- docs/06_Frontend/MVVM_UDF_Pattern.md (Regeln, Vorlage, Referenz-Code)
|
||
- frontend/features/veranstalter-feature/src/commonMain/.../VeranstalterViewModel.kt
|
||
- frontend/features/veranstalter-feature/src/jvmMain/.../DefaultVeranstalterRepository.kt
|
||
- frontend/features/veranstalter-feature/src/jvmMain/.../VeranstalterAuswahlScreen.kt (nutzt ViewModel/Intents)
|
||
|
||
- [x] **A-2** | Abteilungs-Logik im Bewerb-Dialog berücksichtigen
|
||
- [x] Dialog enthält Abteilungs-Auswahl als Teil des „Bewerb anlegen“-Flows (im selben Modal)
|
||
- [x] CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung mit 4 Abteilungen:
|
||
- [x] Ohne Lizenz · R1
|
||
- [x] Ohne Lizenz · R2+
|
||
- [x] Mit Lizenz · R1
|
||
- [x] Mit Lizenz · R2+
|
||
- [x] Beim Auto-Vorschlag Default-Setzung des Abteilungs-Typs auf `SEPARATE_SIEGEREHRUNG`
|
||
- [x] Manuelle Umschaltung des Abteilungs-Typs möglich: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH`
|
||
- [x] UX: Bei erkanntem Typ „CSN-C-NEU“ wird ein AssistChip „Pflicht-Teilung vorgeschlagen“ angezeigt
|
||
|
||
Akzeptanzkriterien:
|
||
- [x] Der „Bewerb anlegen“-Dialog zeigt ein Eingabefeld „Bewerbs-Typ“ und eine Auswahl für den Abteilungs-Typ (zwei Chips)
|
||
- [x] Bei Eingabe „CSN-C-NEU“ wird automatisch die oben definierte 4er-Teilung in der Abteilungs-Liste angezeigt
|
||
- [x] Die Auto-Teilung kann angezeigt werden, ohne dass der Dialog neu geöffnet werden muss (Live-Reaktion auf Eingabe)
|
||
- [x] Der gesetzte Abteilungs-Typ ist im State sichtbar und wird vom Dialog korrekt reflektiert
|
||
- [x] Kein Vorschlag für andere Typen; Liste bleibt leer bis manuell hinzugefügt/implementiert (aktuell out-of-scope)
|
||
|
||
Referenzen (konkret):
|
||
- frontend/features/turnier-feature/src/commonMain/kotlin/at/mocode/turnier/feature/presentation/BewerbAnlegenViewModel.kt
|
||
- `BewerbAnlegenState`, `BewerbAnlegenIntent`, `applySuggestion()` (Auto-Vorschlag + Default-AbteilungsTyp)
|
||
- frontend/features/turnier-feature/src/jvmMain/kotlin/at/mocode/turnier/feature/presentation/TurnierBewerbeTab.kt
|
||
- `BewerbAnlegenDialog(...)`: Eingabe „Bewerbs-Typ“, AssistChip, Auswahl Abteilungs-Typ, Anzeige der vorgeschlagenen Abteilungen
|
||
|
||
---
|
||
|
||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||
|
||
- [ ] **B-1** | ViewModels für alle V3-Screens umsetzen
|
||
- [ ] `TurnierViewModel`
|
||
- [ ] `BewerbViewModel` (inkl. Abteilungs-Logik)
|
||
- [ ] `PferdProfilViewModel`
|
||
- [ ] `ReiterProfilViewModel`
|
||
- [ ] `VereinsViewModel`
|
||
- [ ] `FunktionaerViewModel`
|
||
- [ ] `AbteilungViewModel` (Startliste, Ergebnisse)
|
||
|
||
- [ ] **B-2** | Ktor-Clients und Repositories für Backend-Anbindung vorbereiten
|
||
- [ ] Ktor-HTTP-Client konfigurieren (BaseURL, Auth-Header, Timeout)
|
||
- [ ] Repository-Interface je Entität definieren (ermöglicht späteres Austauschen von Mock → Real)
|
||
- [ ] `VeranstalterRepository` mit echtem Backend-Client implementieren
|
||
- [ ] `TurnierRepository` implementieren
|
||
- [ ] `BewerbRepository` implementieren
|
||
- [ ] `AbteilungRepository` implementieren
|
||
- [ ] `StoreV2` schrittweise durch echte Repositories ersetzen
|
||
|
||
- [ ] **B-3** | Validierungs-Live-Feedback in Edit-Dialogen
|
||
- [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) als Basis nutzen
|
||
- [ ] OEPS-Nummer: Inline-Validierung beim Tippen
|
||
- [ ] FEI-ID: Inline-Validierung beim Tippen
|
||
- [ ] Lizenzklasse × Bewerbs-Klasse: Warnung wenn nicht erlaubt
|
||
- [ ] Altersklasse Pferd: Warnung wenn nicht kompatibel
|
||
|
||
- [ ] **B-4** | Kassa-Screen: Veranstaltungs-Kassa implementieren
|
||
- [ ] Gesamt-Saldo-Ansicht (Salden aus allen Turnieren der Veranstaltung)
|
||
- [ ] Turnier-übergreifender Zahlvorgang (eine Zahlung, mehrere Rechnungen)
|
||
- [ ] Rechnungsvorschau je Turnier
|
||
|
||
---
|
||
|
||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||
|
||
- [ ] **C-1** | Mock-Store (`StoreV2`) vollständig ablösen
|
||
- [ ] Alle verbleibenden `StoreV2`-Referenzen durch echte Repositories ersetzen
|
||
- [ ] `StoreV2` nach vollständiger Ablösung entfernen oder als `@Deprecated` markieren
|
||
|
||
- [ ] **C-2** | LAN-Sync-UI vorbereiten (nach ADR von Architect)
|
||
- [ ] Verbindungsstatus-Anzeige (Online/Offline/LAN)
|
||
- [ ] Sync-Trigger manuell und automatisch
|
||
|
||
> ⏸️ **USB-Stick Fallback (Export/Import UI)** — Separate Besprechung zu einem späteren Zeitpunkt
|
||
|
||
---
|
||
|
||
## 📌 Abhängigkeiten
|
||
|
||
| Warte auf | Von wem |
|
||
|----------------------------------|--------------------|
|
||
| Domänen-Modell final (Abteilung) | 🏗️ Architect |
|
||
| CRUD-Endpunkte | 👷 Backend |
|
||
| Validierungs-Spezifikation | 📜 Rulebook Expert |
|
||
| Wireframes Edit-Formulare | 🖌️ UI/UX Designer |
|
||
|
||
| Meine Aufgabe | Ermöglicht wem |
|
||
|--------------------------|-----------------------------------------------|
|
||
| ViewModel-Referenz (A-1) | Alle anderen ViewModels folgen diesem Muster |
|
||
| Ktor-Repositories (B-2) | Ablösung von StoreV2, echte Daten im Frontend |
|