Vorher: Diagnostic's setMode sendete einen faked chat mit der
Aktivierungsphrase ('ARIA, Hangar-Modus') — das wurde erst in
_process_core_response auf dem ARIA-Antwort-Text detected, war
unzuverlaessig und nutzte nicht den sauberen mode-Message-Path.
Nachher: sauberer set_mode-Pfad mit Live-Sync.
diagnostic/server.js:
- Neue action 'set_mode' → sendet type=mode an RVS direkt
- RVS-Message-Handler: type=mode Broadcast von Bridge wird an
Browser-Clients durchgereicht
diagnostic/index.html:
- setMode() nutzt jetzt action=set_mode (keine Phrase mehr)
- updateModeUI separat — wird bei Broadcast auch aufgerufen
- Mode-Broadcast vom Server syncs UI live (andere Diagnostic/App
hat gewechselt → unser UI aktualisiert sofort)
- Button data-mode + MODE_LABELS auf kanonische IDs umgestellt
(nicht_stoeren, fluester statt dnd, whisper)
bridge/modes.py:
- canonical_id() liefert die IDs die App + Diagnostic kennen
(nicht_stoeren, fluester, ...) — damit Broadcast-ID zur UI-ID passt
bridge/aria_bridge.py:
- _broadcast_current_mode nutzt canonical_id statt enum.name.lower()
Flow jetzt:
Diagnostic wechselt Mode → set_mode → Bridge → persist + broadcast
→ alle Apps + alle Diagnostic-Browser-Tabs aktualisieren sofort
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bug: App ModeSelector sendet rvs.send('mode', { mode: 'normal' })
mit ID, Bridge's detect_mode_switch() sucht aber nach Aktivierungs-
phrasen wie 'aria, normal-modus' → kein Match → Modus-Wechsel
wurde ignoriert, TTS-Verhalten blieb auf NORMAL haengen.
Fix:
- modes.py: mode_from_id() mappt IDs zu Mode-Enum
('normal', 'dnd', 'nicht_stoeren', 'fluester', 'whisper',
'hangar', 'gaming' — flexibel)
- aria_bridge.py: mode-Handler versucht erst ID-Mapping, dann
Phrasen-Erkennung als Fallback
- Unbekannte Modi werden geloggt
- Bestaetigung wird an alle Clients zurueckgesendet damit App-UI
synchron bleibt
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
duffyduck