Dritter Netzausfall (18:41-18:46, ~4,5 min) selbst erholt ohne Logout;
8. Start mit verschluesselter DB sauber, Beobachtung laeuft weiter.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Mit zwei echten Test-Accounts (zwei GUI-Instanzen via PYRAMID_PROFILE_DIR)
durchgeklickt: Beitreten, Teilnehmerliste, bidirektionaler Screenshare,
Live-Qualitaetswechsel (Full HD 60fps), sauberes Verlassen.
- rooms_list.dart: Voice-Channel in der normalen Raumliste war per Klick
nicht beitretbar (oeffnete nur Chat) -> _toggleVoiceChannel wie Space-Liste.
- livekit_call_manager.dart: _callGeneration entwertet laufenden connect
bei Auflegen/Wechsel (keine Geisterverbindung mit offenem Mikro);
Fehlerpfade setzen error sichtbar statt still zu verschwinden.
- rooms_panel_core.dart: raeumt activeVoiceRoomIdProvider auf, wenn der
Voice-Service inaktiv wird, + Fehler-SnackBar.
- test/live_call_setup_test.dart: gegateter Setup-Helfer fuer den Testraum.
UNGETESTET: echtes 2-Peer-Audio, Netz-Abbruch mitten im Call.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Nach docs/STREAMING_60FPS.md: neue Presets 720p/1080p mit 60 FPS und
hoher Bitrate (5/8 Mbit/s), Preset-Aufloesung+FPS werden jetzt bis in
die Capture-Constraints durchgereicht (vorher blieb der LiveKit-Default
1080p/15 aktiv), 60-FPS-Presets publishen ohne Simulcast mit
DegradationPreference.maintainFramerate (unter Last Aufloesung statt
Frames opfern). contentHint 'motion' ist in flutter_webrtc 1.4.1 aus
Dart nicht setzbar (geprueft) - im Code dokumentiert.
4 neue Vertragstests fuer die Preset-Tabellen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neuer gegateter Test (PYRAMID_LIVE_TEST=1, Windows): echter Login als
pyramidtest1, Byte-Pruefung der Platte (kein SQLite-Header, Token +
Nachricht nicht im Klartext, Positiv-Kontrolle in Klartext-DB),
Neustart aus verschluesselter DB, Logout/Re-Login, Migration einer
Klartext-DB mit echter eingeloggter Session. Zugangsdaten bleiben
ausserhalb des Repos.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DB, auth_log und Media-Cache laufen jetzt ueber appSupportDir(); nur auf
Desktop und nur wenn PYRAMID_PROFILE_DIR gesetzt ist, landet alles in einem
eigenen Profilverzeichnis - fuer Autopilot-Testlogins parallel zur echten
Session. Ohne Variable exakt das bisherige Verhalten. secure_storage/
shared_preferences bewusst nicht umgeleitet (Begruendung im Dateikopf).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Nagelt den dokumentierten Vertrag der M2-Fassade (d22f9c2) fest, damit
bestehende Nutzer-Einstellungen (Utas Geraet) bei weiteren Umbauten der
Call-Schicht nachweislich erhalten bleiben.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Der erste Befund beruhte auf einem durch head-limit abgeschnittenen grep;
message_media.dart (am wenigsten geprueft laut PC_TESTPLAN 3) nutzt den
Cache ebenfalls, inkl. statischem Wrapper ohne ref-Zugang.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Repo-weit verifiziert: einzige Fundstelle war die Definition selbst -
der Pilot hat die Call-Provider ersatzlos in die Module verlegt
(callSignalingProvider/voiceChannelProvider), dieser StateProvider
blieb ungenutzt zurueck. analyze sauber, 29 Tests gruen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- CallSignalingService/callSignalingProvider und VoiceChannelService/
voiceChannelProvider als einzige oeffentliche Schnittstellen
- voip_manager.dart / livekit_call_manager.dart in ihre Module verschoben,
Logik unangetastet (nur Klassen-Koepfe, @override, Imports, Provider-Namen)
- Alle Konsumenten entkoppelt; Kompositions-Punkt matrix_client.dart als
dokumentierte Ausnahme. analyze sauber, 29 Tests gruen, Windows-Start ok.
Call-Klick-/Geraetetest steht aus (PROGRESS.md)
Der (x)-Eintrag (Review von 66bf54b, kein Befund) lag fertig geschrieben,
aber uncommitted im Arbeitsbaum – die Session wurde vor ihrem
Protokoll-Commit abgebrochen. Inhalt in dieser Session gegengeprüft
(66bf54b-Diff, keine lib/-Änderungen seit 925aafb, A/B-Frage überall
geschlossen) und unverändert übernommen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Threading-Umstellung aus (p) hatte eine Nebenlaeufigkeits-Race in den
Admin-Routen erzeugt: conduit.toml Read-Modify-Write + docker restart und
der send_admin-Readback-nach-sleep waren seit multithreaded race-faehig.
ADMIN_LOCK serialisiert NUR die Admin-Mutationen; die oeffentlichen Routen
(livekit-token, e2ee-diagnostics) laufen zuerst und bleiben nebenlaeufig,
der Slow-Loris-Schutz aus (p) bleibt erhalten. Headless verifiziert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bernd Steckmeister