chore: entferne AuthApiClient, AuthTokenManager und DeviceInitializationConfig.jvm, da diese nicht mehr benötigt werden

docs/temp/GEMMA-4_2026-04-16.md

@@ -0,0 +1,37 @@
+👷 **[Frontend Expert]**
+
+**Verstanden. Ich nehme die Herausforderung an.**
+
+Ich werde diesen Scan als **"Audit-Phase"** behandeln. Mein Ziel ist es, nicht nur ein Chaos-Dokument zu erstellen, sondern eine **"Architektur-Anleitung"**, die als Single Source of Truth für die zukünftige Entwicklung dient.
+
+Hier ist mein Schlachtplan für die nächsten Schritte:
+
+### 1. Der Scan (Aktueller Schritt)
+Ich führe den Scan durch, um die Struktur jedes einzelnen Moduls zu erfassen. Ich werde die Pfade so mappen, dass ich genau sehe:
+*   **Modul-Name** (z.B. `features:login`)
+*   **Vorhandene Source-Sets** (`commonMain`, `jvmMain`, `wasmJsMain`)
+*   **Status** (Ist es ein "Standard-Modul" oder ein "Sonderfall"?)
+
+### 2. Die Analyse (Die "Chaos-Matrix")
+Aus den Rohdaten erstelle ich die **Chaos-Matrix**. Diese wird folgende Fragen beantworten:
+*   Welche Module folgen bereits einem Muster?
+*   Wo sind die "Inseln der Wildnis" (Module ohne jegliche Struktur)?
+*   Welche Abhängigkeiten (Gradle-Module) sind von der Struktur-Anpassung betroffen?
+
+### 3. Die Architektur-Anleitung (Das Endprodukt)
+Dies ist das Dokument, das Sie am Ende erhalten. Es wird kein bloßes Problem-Dokument sein, sondern ein **Blueprint**. Es wird enthalten:
+*   **Die "Golden Rule" der Modul-Struktur:** Die definierte Standard-Struktur für jedes neue Modul.
+*   **Die "Migration-Matrix":** Eine Liste aller existierenden Module mit der Anweisung: *"Modul X muss von Struktur A nach Struktur B migriert werden"*.
+*   **Das "Pattern-Library" Dokument:**
+  *   Wie ein `feature`-Modul aufgebaut sein muss (mit `commonMain` und `jvmMain`).
+  *   Wie ein `library`-Modul aufgebaut sein muss (rein `commonMain`).
+  *   Wie ein `platform`-Modul aufgebaut sein muss (z.B. für Android oder Desktop-spezifische Erweiterungen).
+*   **Die "Definition of Done" (DoD) für neue Module:** Eine Checkliste, die ein Entwickler abhaken muss, bevor ein Modul als "fertig" gilt.
+
+---
+
+**Ich starte jetzt den Scan.**
+
+*(Ich werde nach Abschluss des Scans und der Erstellung der Matrix sofort mit der Analyse beginnen.)*
+
+`[Status: Running Structural Scan...]

docs/temp/MODULE_ARCH_BLUEPRINT.md

@@ -0,0 +1,55 @@
+# 🏗️ Module Architecture Blueprint
+
+Dieses Dokument definiert die Architektur-Standards für das Projekt, um eine konsistente, skalierbare und wartbare Modulstruktur zu gewährleisten.
+
+## 🎯 Kernziel
+Etablierung einer klaren Trennung zwischen Geschäftslogik (Common) und Plattform-spezifischer Darstellung (JVM/Web), um die Wiederverwendbarkeit und Testbarkeit zu maximieren.
+
+---
+
+## 📂 Modultypen (Module Archetypes)
+
+Jedes Modul im Projekt muss einer der folgenden drei Kategorien zugeordnet werden:
+
+### 1. Core Modules (Type: `CORE`)
+*   **Zweck:** Rein geschäftliche Logik, Domain-Modelle, Use-Cases.
+*   **Struktur:** Ausschließlich `commonMain`. Keine Abhängigkeiten zu Plattform-spezifischen APIs.
+*   **Regel:** Darf keine Kenntnis über die UI oder Plattform-spezifische Frameworks haben.
+
+### 2. Feature Modules (Type: `FEATURE`)
+*   **Zweck:** Implementierung einer spezifischen Benutzerfunktion (z.B. "Login", "Registration").
+*   **Struktur:** `commonMain` (Logik) + `jvmMain` / `jsMain` (UI/Integration).
+*   **Regel:** Nutzt `CORE`-Module. Darf nur über definierte Schnittstellen mit anderen `FEATURE`-Modulen kommunizieren.
+
+### 3. Infrastructure/Adapter Modules (Type: `ADAPTER`)
+*   **Zweck:** Implementierung von Schnittstellen (z.B. API-Clients, Datenbank-Treiber, Bluetooth-Adapter).
+*   **Struktur:** Implementiert `expect`-Deklarationen aus `CORE` oder `FEATURE` mittels `actual`-Implementierungen.
+*   **Regel:** Versteckt die Komplexität der Plattform hinter einer saubbar definierten API.
+
+---
+
+## 🛠️ Strukturregeln (The Golden Rules)
+
+### 📏 Rule 1: Dependency Direction
+Abhängigkeiten dürfen **nur nach unten** fließen:
+`FEATURE` $\rightarrow$ `CORE` $\rightarrow$ `ADAPTER` (Interfaces)
+`FEATURE` $\rightarrow$ `ADAPTER` (Implementations)
+
+**Verboten:** Ein `CORE`-Modul darf niemals ein `FEATURE`-Modul referenzieren.
+
+### 🔄 Rule 2: The Expect/Actual Pattern
+Um Plattform-spezifischen Code in `commonMain` nutzbar zu machen, ist das `expect/actual`-Pattern zwingend:
+1.  **Define** `expect class/function` in `commonMain`.
+2.  **Implement** `actual class/function` in `jvmMain` (Desktop) und `jsMain` (Web).
+
+### 📦 Rule 3: Encapsulation
+Module müssen ihre internen Implementierungen verbergen. Nur Klassen und Funktionen, die explizit für die Nutzung durch andere Module markiert sind (z.B. via `internal` Modifier), dürfen exportiert werden.
+
+---
+
+## 🚀 Deployment & Build
+*   **Build System:** Gradle.
+*   **Multiplatform:** Kotlin Multiplatform (KMP).
+*   **CI/CD Check:** Bei jedem Pull-Request wird die Einhardung der Abhängigkeitsrichtung durch ein Dependency-Analysis-Plugin geprüft.
+
+---

docs/temp/MODULE_STRUCTURE_BLUEPRINT.md

@@ -0,0 +1,49 @@
+# 🏗️ Modul-Struktur-Blueprint (Standard-Topologie)
+
+**Status:** ARCHITECTURAL STANDARD  
+**Ziel:** Elimination von strukturellen Inkonsistenheiten (Kraut & Rüben)  
+**Prinzip:** Plug-and-Play Multiplatform-Komponenten
+
+## 1. Die Modul-Klassifizierung (The Taxonomy)
+
+Jedes Modul im Projekt **muss** einer der folgenden drei Klassen zugeordnet werden. Es gibt keine "unidentifizierten" Module mehr.
+
+### 🟢 Klasse A: `CORE_LIBRARY`
+*   **Zweck:** Reine Geschäftslogik, Datenmodelle, Hilfsfunktionen (Utils).
+*   **Anforderung:** Besteht **ausschließlich** aus `src/commonMain`.
+*   **Einsatz:** Keine Plattform-spezifischen Abhängigkeiten erlaubt.
+*   **Beispiel:** `:core:database`, `:core:network-models`.
+
+### 🔵 Klasse B: `UI_COMPONENT` (Der Standard)
+*   **Zweck:** Visuelle Features, Screens, interaktive Elemente.
+*   **Anforderung:** **Zwingende** Struktur:
+  *   `src/commonMain` (Logik & Interface)
+  *   `src/jvmMain` (Desktop-spezifische UI-Erweiterungen/Render-Strategie)
+  *   `src/wasmJsMain` (Web-spezifische Render-Strategie)
+*   **Einsatz:** Das Standard-Modul für alle "Plug-and-Play" Features.
+*   **Beispiel:** `:features:auth`, `:features:import`, `:features:settings`.
+
+### 🟡 Klasse C: `PLATFORM_ADAPTER`
+*   **Zweck:** Tiefe Integration von Hardware-APIs oder Plattform-spezifischem Code.
+*   **Anforderung:** Enthält hochgradig spezialisierten Code für eine einzige Plattform.
+*   **Beispiel:** `:platform:android-biometrics`.
+
+---
+
+## 2. Design-Regeln (The Golden Rules)
+
+1.  **The "Expect/Actual" Rule:** `expect`-Deklarationen gehören immer in den `commonMain`-Source-Set. `actual`-Implementierungen werden strikt in den jeweiligen Plattform-Source-Sets (`jvmMain`, `wasmJsMain`, etc.) platziert.
+2.  **The Dependency Rule:** Ein `commonMain`-Modul darf niemals eine Abhängigkeit zu einem Modul haben, das nur in `jvmMain` existiert. Abhängigkeiten müssen immer "nach unten" (zu `common`) oder "horizontal" (zu anderen `common`-Modulen) verlaufen.
+3.  **The Consistency Rule:** Ein Modul darf niemals "unvollständig" sein. Wenn ein Modul ein `jvmMain` hat, muss es auch ein `wasmJsMain` (oder zumindest die Infrastruktur dafür) vorbereitet haben, um die Plugin-Architektur nicht zu brechen.
+
+---
+
+## 3. Implementierungs-Checkliste (Migration Guide)
+
+Wenn du ein neues Modul erstellst oder ein altes migrierst:
+
+- [ ] Identifiziere die Klasse (A, B oder C).
+- [ ] Erstelle die Verzeichnisstruktur gemäß der Klasse.
+- [ ] Überprüfe die `build.gradle.kts` auf korrekte Source-Set-Konfiguration.
+- [ ] Sicherstellen, dass alle `expect`-Funktionen durch `actual`-Implementierungen in allen Ziel-Plattformen abgedeckt sind.
+- [ ] Teste die Kompilierung für alle Ziel-Plattformen (`./gradlew check`).