mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2b3e2d8c1b
meldestelle/docs/04_Agents/Roadmaps/Frontend_Roadmap.md

5.7 KiB
Raw Blame History

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

  • A-1 | ViewModel-Architektur definieren und Referenz-Implementierung umsetzen

    • MVVM mit UDF (Unidirectional Data Flow) als verbindliches Muster festlegen
    • Intent- und State-Klassen-Struktur definieren (Vorlage für alle anderen ViewModels)
    • VeranstalterViewModel als vollständige Referenz-Implementierung umsetzen
      • State-Klasse definieren
      • Intent-Klasse (Sealed Class) definieren
      • Business-Logik aus Composables herausziehen (keine StoreV2-Aufrufe mehr direkt in onSaved)
      • Lokalen remember-State durch ViewModel-State ersetzen
    • 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)

  • A-2 | Abteilungs-Logik im Bewerb-Dialog berücksichtigen

    • Dialog enthält Abteilungs-Auswahl als Teil des „Bewerb anlegen“-Flows (im selben Modal)
    • CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung mit 4 Abteilungen:
      • Ohne Lizenz · R1
      • Ohne Lizenz · R2+
      • Mit Lizenz · R1
      • Mit Lizenz · R2+
    • Beim Auto-Vorschlag Default-Setzung des Abteilungs-Typs auf SEPARATE_SIEGEREHRUNG
    • Manuelle Umschaltung des Abteilungs-Typs möglich: SEPARATE_SIEGEREHRUNG oder ORGANISATORISCH
    • UX: Bei erkanntem Typ „CSN-C-NEU“ wird ein AssistChip „Pflicht-Teilung vorgeschlagen“ angezeigt

    Akzeptanzkriterien:

    • Der „Bewerb anlegen“-Dialog zeigt ein Eingabefeld „Bewerbs-Typ“ und eine Auswahl für den Abteilungs-Typ (zwei Chips)
    • Bei Eingabe „CSN-C-NEU“ wird automatisch die oben definierte 4er-Teilung in der Abteilungs-Liste angezeigt
    • Die Auto-Teilung kann angezeigt werden, ohne dass der Dialog neu geöffnet werden muss (Live-Reaktion auf Eingabe)
    • Der gesetzte Abteilungs-Typ ist im State sichtbar und wird vom Dialog korrekt reflektiert
    • 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 via Dialog-VM)
    • 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