docs: M2-Ist-Analyse der Architektur dokumentieren

Gott-Dateien, unsauber verteilte Call-Schicht, fehlende Storage-Fassade
und tote/duplizierte Code-Stellen per Code-Lektüre kartiert; 8 Modul-
Kandidaten für den nächsten Roadmap-Punkt festgehalten.

PROGRESS.md

@@ -13,6 +13,90 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M2: Ist-Analyse der Architektur geschrieben
+
+**Erledigt:** M1 hat aktuell keinen auf dem Pi bearbeitbaren Punkt mehr offen
+(SQLCipher wartet auf Bernds Priorisierung, Härtetest braucht GUI/PC – siehe
+Fragen an Bernd unten und Eintrag 2026-07-03 „3 schon vorhanden, 1 echte
+Lücke"). Deshalb mit M2 weitergemacht, erster Punkt: Ist-Analyse. Per
+Code-Lektüre (Zeilenzahlen, Import-Graph, grep) folgende Schwachstellen
+gefunden:
+
+- **Gott-Dateien:** `widgets/settings_modal.dart` mit 5541 Zeilen / 50+ Klassen
+  bündelt mindestens 8 unabhängige Bereiche (Profil, Benachrichtigungen,
+  Voice/TURN, E2EE-Verifizierung inkl. SAS/QR, Sessions, Account, Erscheinungsbild,
+  Updates). Weitere große Dateien: `message_group.dart` (2780), `rooms_panel.dart`
+  (2555), `space_admin_dialog.dart` (2278), `chat_view.dart` (2116),
+  `document_viewer.dart` (1773), `voice_channel.dart` (1123), `app_shell.dart` (1073).
+- **Call-Schicht unsauber verteilt statt hinter einer Schnittstelle:**
+  `core/voip_manager.dart` (Matrix-VoIP-Signalisierung), `core/livekit_call_manager.dart`
+  (LiveKit-Transport), `features/call/voice_channel.dart` + `mini_call_widget.dart`
+  (UI) – aber `chat_view.dart`, `matrix_client.dart`, `settings_modal.dart` greifen
+  alle DIREKT auf die Manager zu statt über eine gemeinsame Call-Fassade. Vier
+  verschiedene Module importieren `voice_channel.dart` direkt.
+  Genau das Gegenteil des „austauschbare Bausteine"-Ziels aus CLAUDE.md.
+- **State-Management gemischt:** 2 zentrale `ChangeNotifier`-Singletons
+  (`voip_manager.dart`, `livekit_call_manager.dart`) statt Riverpod-`Notifier`,
+  eingebunden über `app_state.dart` (`callStateProvider`, `voipStateProvider`).
+  Migration sinnvoll, aber riskant wegen breiter Call-Sites und enger
+  SDK-Callback-Kopplung (LiveKit-`Room`-Events, Matrix-`WebRTCDelegate`) – sollte
+  zusammen mit der Call-Fassade angegangen werden, nicht isoliert.
+- **`core/` ist nicht rein generisch:** importiert Feature-Code direkt
+  (`app.dart`/`router.dart` → `features/auth/*`, `matrix_client.dart` instanziiert
+  `PyramidVoipManager` direkt, `app_state.dart` importiert `rooms_provider.dart`
+  augenscheinlich ungenutzt – vermutlich Altlast). `app_state.dart` selbst ist ein
+  Sammelbecken für Theme-, Call-, Voice-, Share-Target- und Spaces-Provider aus
+  praktisch allen Features – zentraler Kopplungspunkt, der jedem Modulschnitt
+  im Weg steht.
+- **Keine gemeinsame Storage-Schnittstelle:** `SharedPreferences.getInstance()`
+  wird an 12 Stellen direkt aufgerufen, obwohl `core/settings_prefs.dart` bereits
+  eine `StateNotifier`-Abstraktion (`BoolPref`, `StringSetPref`) anbietet – wird
+  meist umgangen. `sqflite` wird zusätzlich unabhängig in `background_push.dart`
+  nochmal geöffnet (eigene DB-Instanz fürs Background-Isolate). `media_cache.dart`
+  ist dagegen sauber gekapselt – gutes Vorbild für die anderen Speicherzugriffe.
+- **Toter Code bestätigt:** `features/chat/message_bubble.dart` (178 Zeilen,
+  Klasse `MessageBubble`) wird nirgends instanziiert – von `message_group.dart`
+  abgelöst, kann beim Refactoring entfernt werden.
+- **Duplikate:** `_formatTime`/`_formatDate` unabhängig implementiert in
+  `pinned_messages_panel.dart:206`, `message_group.dart:322` UND `:475` (zwei Mal
+  im selben File!), sowie im toten `message_bubble.dart:80/165`.
+
+**Modul-Kandidaten für den nächsten Punkt („Modul-Schnitt definieren"):**
+1. `call_signaling` (Matrix-VoIP) – `core/voip_manager.dart`
+2. `call_transport` (LiveKit) – `core/livekit_call_manager.dart`
+3. `call_ui` (nur UI, konsumiert 1+2 über Interface) – `features/call/*`
+4. `settings/*` aufsplitten: profile, encryption_verification, sessions,
+   notifications, appearance, account – aus `widgets/settings_modal.dart`
+5. `verification` als eigenständiges Feature (SAS/QR/Recovery-Key), nicht
+   Teil von Settings – wiederverwendbar (z. B. künftig beim Login)
+6. `storage` – gemeinsame Fassade, `settings_prefs.dart` als Pflichtzugang
+   statt 12 Direktzugriffsstellen
+7. `app_state.dart` auflösen in feature-lokale Provider-Dateien
+8. `chat_timeline` – `message_group.dart` + `pinned_messages_panel.dart`,
+   dabei toten Code (`message_bubble.dart`) entfernen, `_formatTime`/`_formatDate`
+   in `chat/format_utils.dart` zusammenführen
+
+**Offen/Nächster Schritt:** M2, zweiter Punkt – „Modul-Schnitt definieren":
+aus der obigen Kandidatenliste konkrete Modul-Interfaces (Dart-Abstract-Classes
+o. ä.) entwerfen, dann EIN Modul zuerst umbauen (Vorschlag: `call_*`, da am
+klarsten abgegrenzt und am dringendsten laut CLAUDE.md-Leitprinzip) als Pilot,
+bevor der Rest folgt. Kein Codeumbau in diesem Schritt, nur Schnittstellen-Design.
+
+**Stolperfallen:** Keine – reine Lesearbeit, kein Risiko für Bestandsdaten.
+Analyse wurde von einem Explore-Subagent erstellt und stichprobenartig
+plausibilisiert (Zeilenzahlen/Imports selbst nachgezählt), nicht jede
+Einzelbehauptung im Detail nachverifiziert.
+
+**Fragen an Bernd:**
+- SQLCipher-Priorität weiterhin offen (siehe Eintrag „3 schon vorhanden, 1 echte
+  Lücke" weiter unten) – blockiert nicht, aber ohne Antwort bleibt der M1-Punkt
+  bis zum nächsten PC-Praxistest liegen.
+- Für M2: Soll ich die Call-Schicht als erstes Pilot-Modul umbauen (mein
+  Vorschlag oben), oder hast du eine andere Präferenz (z. B. erst die
+  `settings_modal.dart` aufsplitten, weil die am unübersichtlichsten ist)?
+
+---
+
 ## 2026-07-03 – M1: Restliche Punkte geprüft – 3 schon vorhanden, 1 echte Lücke gefunden
 
 **Erledigt:**

ROADMAP.md

@@ -59,9 +59,12 @@ Ziel: gleiche Funktionen, saubere **modulare** Struktur – als Fundament für a
 Leitprinzip (Bernd): austauschbare Bausteine – jedes Modul muss sich komplett neu schreiben
 lassen, ohne dass andere Module angefasst werden müssen.
 
-- [ ] Ist-Analyse schreiben: Architektur-Schwächen auflisten (Call-Logik verteilt auf
+- [x] Ist-Analyse geschrieben (PROGRESS.md 2026-07-03): Gott-Datei `settings_modal.dart`
-      `livekit_call_manager.dart`, `voip_manager.dart`, `voice_channel.dart`?, State-Management
+      (5541 Zeilen/50+ Klassen), Call-Schicht ohne gemeinsame Fassade (4 Module
-      uneinheitlich?, Gott-Dateien?, tote Widgets?) → als Refactoring-Plan in PROGRESS.md
+      importieren `voice_channel.dart` direkt), `app_state.dart` als Kopplungspunkt
+      aller Features, keine gemeinsame Storage-Schnittstelle (12 direkte
+      `SharedPreferences`-Zugriffe), toter Code (`message_bubble.dart`) + Duplikate
+      (`_formatTime`/`_formatDate` 3-fach). 8 Modul-Kandidaten dokumentiert.
 - [ ] Modul-Schnitt definieren: Module (auth, chat, rooms, calls, streaming, push, storage, …)
       mit je einer schmalen öffentlichen Schnittstelle; Abhängigkeiten nur über Interfaces,
       keine Quer-Importe zwischen Feature-Modulen