refactor(desktop, core): Onboarding zu DeviceInitialization umbenannt, Navigation und Screens angepasst

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-18 11:10:01 +02:00
parent 315517f03f
commit 7bbb991e69
24 changed files with 742 additions and 222 deletions
@@ -0,0 +1,47 @@
+# ADR-0024: Plug-and-Play Komponenten-Architektur für Multiplattform-Stabilität
+
+## Status
+
+Akzeptiert
+
+## Kontext
+
+Das Projekt "Meldestelle" strebt eine Multiplattform-Anwendung (KMP) für Desktop, Web und Mobile an. Jüngste
+Stabilitätsprobleme im Frontend (der "Kartenhaus-Effekt") wurden durch eng gekoppelte UI-Komponenten und Screens
+verursacht. Änderungen in einem Bereich (z.B. Routing) führten zu Zusammenbrüchen in nicht verwandten Features.
+
+## Entscheidung
+
+Wir führen eine "Plug-and-Play"-Architektur für alle Frontend-Komponenten ein. Diese Strategie stellt sicher, dass
+Komponenten in sich geschlossen, wiederverwendbar und unabhängig von ihrer Platzierung in der UI-Hierarchie sind.
+
+### 1. Atomic Design Ebenen
+
+- **Atome/Moleküle (`core:design-system`)**: Zustandlose, rein visuelle Elemente (z.B. `MsButton`, `MsCard`).
+- **Plug-and-Play Organismen (`features:*` oder `core:auth`)**: Fachlich orientierte Komponenten (z.B. `AuthStatusCard`,
+  `PingActionGroup`). Sie MÜSSEN ein ViewModel-Interface oder ein UI-State-Objekt verwenden.
+- **Templates/Screens**: Layout-orientierte Kompositionen von Organismen. Keine direkte Logik-Implementierung.
+
+### 2. Striktes State Hoisting
+
+- Komponenten erhalten ihren Zustand über ein ViewModel oder ein State-Objekt, das als Parameter übergeben wird.
+- Sie geben Ereignisse über Lambdas zurück (z.B. `onLoginClick: () -> Unit`).
+- Sie dürfen NICHT direkt innerhalb des Composables auf globale Singletons oder Koin zugreifen.
+
+### 3. Modulare Granularität
+
+- Features werden in kleine, testbare Einheiten zerlegt (z.B. `PingConsole`, `PingControls`).
+- Komponenten befinden sich in `commonMain`, um die Multiplattform-Verfügbarkeit sicherzustellen.
+
+## Konsequenzen
+
+- **Positiv**: Erhöhte Stabilität, höhere Wiederverwendbarkeit über Plattformen hinweg, einfacheres Testing, schnellere
+  UI-Experimente.
+- **Negativ**: Geringfügiger Overhead bei der Definition von Interfaces und State-Objekten für kleine Komponenten.
+- **Risiko**: Over-Engineering einfacher Views. (Gegenmaßnahme: "Gesunder Menschenverstand" bei trivialen
+  1-Zeilen-Labels).
+
+## Einhaltung
+
+- Jede neue Feature-Implementierung MUSS gegen dieses ADR geprüft werden.
+- Bestehende Screens SOLLTEN im Zuge der Wartung in dieses Muster refactored werden.