# 🎨 [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 |