refactor(design-system): consolidate components and standardize naming with Ms prefix

- Removed redundant files: `AppFooter`, `AppHeader`, `AppScaffold`, `LoadingIndicator`, `MeldestelleButton`, `MeldestelleTextField`, `DashboardCard`. - Introduced `MsFooter`, `MsHeader`, `MsScaffold`, `MsLoadingIndicator`, `MsButton`, `MsTextField`, `MsCard` with standardized implementation and naming. - Updated references in `profile-feature` and `ping-feature` to use the new components. - Aligned with roadmap goals for a consistent, reusable, and high-density design system. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-03-31 10:07:10 +02:00
parent 5065febca2
commit c20899752a
11 changed files with 96 additions and 73 deletions
@@ -0,0 +1,64 @@
+# Frontend-Komponenten Roadmap: Meldestelle-Biest
+
+🏗️ **[Lead Architect]** | 31. März 2026
+
+Diese Roadmap definiert den Weg von der aktuellen Prototypen-Phase hin zu einer professionellen, konsistenten und
+performanten Desktop-App. Wir setzen auf einen komponentengetriebenen Ansatz (High-Density UI), um die komplexe
+Datenverwaltung der Turniermeldestelle effizient abzubilden.
+
+---
+
+## Phase 1: Cleanup & Konsolidierung (Das Fundament) ✅ [IN ARBEIT]
+
+Bevor wir neue Features bauen, räumen wir die bestehenden Entwürfe auf, um Redundanzen zu vermeiden.
+
+*   [ ] **Design-System Refactoring:**
+  *   [ ] `Buttons.kt` (DenseButton) in `MeldestelleButton.kt` (MsButton) überführen.
+  *   [ ] Einheitliches Naming: Alle Basis-Komponenten erhalten das Präfix `Ms` (z.B. `MsButton.kt`, `MsTextField.kt`).
+  *   [ ] Redundante Placeholder-Dateien entfernen oder in `core/design-system/models/` bündeln.
+*   [ ] **Theme-Check:**
+  *   [ ] Sicherstellen, dass alle Farben aus `AppColors` kommen und nicht hart codiert sind.
+  *   [ ] Typografie-Skalen für High-Density optimieren (LabelSmall für Tabellen).
+
+## Phase 2: Daten-Visualisierungs-Komponenten (Das Herzstück) 🔵 [GEPLANT]
+
+Turniermanagement bedeutet Arbeit mit Listen. Wir benötigen mächtige, aber kompakte Anzeige-Komponenten.
+
+*   [ ] **`MsDataTable`:**
+  *   [ ] KMP-kompatible Tabelle mit Sticky Header.
+  *   [ ] Sortier- und Filter-Logik (in-memory & API-driven).
+  *   [ ] Zeilen-Selektion (Einzel/Mehrfach) und Kontextmenüs.
+*   [ ] **`MsStatusBadge`:**
+  *   [ ] Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
+  *   [ ] Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
+*   [ ] **`MsFilterBar`:**
+  *   [ ] Suchfeld mit Debounce.
+  *   [ ] Filter-Chips für schnelle Status-Wechsel.
+
+## Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ⚪ [ZUKUNFT]
+
+Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.
+
+*   [ ] **`MsEnumDropdown`:** Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
+*   [ ] **`MsValidationWrapper`:** Konsistente Anzeige von Fehlern (z.B. "Lizenz für diese Klasse nicht ausreichend").
+*   [ ] **`MsSearchableSelect`:** Für die Verknüpfung von Reitern/Pferden (Autocomplete).
+
+## Phase 4: Layout-Patterns & Navigation ⚪ [ZUKUNFT]
+
+Hier bringen wir alles zusammen, bevor das finale Routing implementiert wird.
+
+*   [ ] **`MsMasterDetailLayout`:** Standard-Layout für alle Stammdaten-Screens.
+*   [ ] **`MsActionToolbar`:** Einheitliche Platzierung von Hauptaktionen (Neu, Speichern, Drucken).
+*   [ ] **`MsDialogShell`:** Standardisierter Rahmen für Modale und Bestätigungsdialoge.
+
+---
+
+## Erfolgs-Metriken
+
+* **Wiederverwendbarkeit:** > 80% der UI besteht aus `Ms`-Komponenten.
+* **Density:** Alle relevanten Daten eines Reiters/Pferdes sind ohne Scrollen in der Detailansicht sichtbar.
+* **Performance:** `MsDataTable` rendert 500+ Zeilen flüssig auf ARM64 (Zora/Mac/Linux).
+
+---
+🧹 **[Curator]** | 2026-03-31
+*Dieses Dokument dient als Single Source of Truth für die Frontend-Entwicklung.*