From f3fd4510344c9ff8b5611dc4abc117f4cb5dbbee Mon Sep 17 00:00:00 2001 From: Bernd Steckmeister Date: Fri, 3 Jul 2026 10:25:10 +0200 Subject: [PATCH] docs: M2-Ist-Analyse der Architektur dokumentieren MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++ ROADMAP.md | 9 ++++-- 2 files changed, 90 insertions(+), 3 deletions(-) diff --git a/PROGRESS.md b/PROGRESS.md index 8fe5c21..69c4193 100644 --- a/PROGRESS.md +++ b/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:** diff --git a/ROADMAP.md b/ROADMAP.md index 786ea74..e16cfc5 100644 --- a/ROADMAP.md +++ b/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 - `livekit_call_manager.dart`, `voip_manager.dart`, `voice_channel.dart`?, State-Management - uneinheitlich?, Gott-Dateien?, tote Widgets?) → als Refactoring-Plan in PROGRESS.md +- [x] Ist-Analyse geschrieben (PROGRESS.md 2026-07-03): Gott-Datei `settings_modal.dart` + (5541 Zeilen/50+ Klassen), Call-Schicht ohne gemeinsame Fassade (4 Module + 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