Bei kurzem TLS-Fehler beim ersten Connect (z.B. Caddy noch im ACME-
Setup) wechselte die Bridge auf den ws://-Fallback und blieb dort
permanent kleben. Jeder spaetere Reconnect-Versuch landete dann auf
plain ws:// gegen den TLS-only Caddy-Endpoint → HTTP 400 → erneut
Connection lost → endlos.
Fix: Bei jeder ConnectionClosed/Refused/InvalidMessage-Exception wird
using_fallback=False und current_url=self.rvs_url (= primary wss://)
zurueckgesetzt. Bridge probiert bei jedem Reconnect zuerst primary,
faellt nur einmal pro Connect-Cycle auf ws:// zurueck. Sobald TLS
verfuegbar ist, ist sie auf wss:// stabil.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
OAuth-Provider (Spotify, Dropbox, ...) verlangen HTTPS fuer non-localhost
Redirect-URIs. Bisher lief der RVS direkt auf einem TCP-Port ohne TLS —
Spotify hat den Callback abgewiesen.
Loesung: Caddy im selben Compose-Stack davor. Holt automatisch ein
Let's Encrypt-Zertifikat fuer PUBLIC_URL (HTTP-01 ueber Port 80),
terminiert TLS auf 443 und routet alles inkl. WebSocket-Upgrades an
den internen RVS-Container (Port 3000).
- rvs/docker-compose.yml: caddy-Service hinzu (image caddy:latest,
command 'caddy reverse-proxy --from ${PUBLIC_URL} --to rvs:3000'),
rvs-Service verliert ports-Block (nur intern via aria-rvs-net),
data-Volumes fuer Caddy-ACME-State (persistent, Rate-Limit-Schutz).
- rvs/.env.example neu: dokumentiert PUBLIC_URL + DNS/Port-
Voraussetzungen.
- rvs/.gitignore neu: .env + data/ (sonst landen die Zertifikate
versehentlich im Repo).
- README RVS-Sektion: Setup-Schritte mit Caddy + Hinweis wie man's
auskommentiert wenn ein eigener Reverse-Proxy davor steht.
Wer schon einen TLS-Terminator hat (nginx/Traefik): caddy-Service in
der Compose auskommentieren, rvs wieder einen ports-Block geben.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ARIA hat jetzt das META-Tool oauth_register_provider. Wenn Stefan einen
Service nutzen will, der nicht in den (auf Spotify reduzierten) Defaults
ist, kann sie auth_url/token_url/scopes/client_auth selbst eintragen —
ARIA kennt typische OAuth-Endpunkte (Dropbox, Discord, Notion, Slack,
Zoom, Trello, LinkedIn, Reddit, Twitch) aus ihrem Training. Sie traegt
NUR die URLs ein, client_id/secret bleiben Stefans Job (Diagnostic /
App-UI) — bewusste Trennung damit Credentials nicht im Chat-Verlauf
landen.
DEFAULT_PROVIDERS auf Spotify reduziert — Rest war aktuell ungenutzt
und macht den Code unnoetig "groß". ARIA registriert on-demand.
Diagnostic-UI:
- Custom-Provider zeigen auth_url/token_url/scopes als sichtbare Felder
- Defaults verstecken die Felder hinter "Default-URLs ueberschreiben
(advanced)" damit man die Spotify-URLs nicht versehentlich loescht
- "+ Custom OAuth-Provider hinzufuegen" Button mit Prompts fuer
Name/URLs/Scopes
- 🗑-Icon bei Custom-Services (Service komplett entfernen)
App-UI (neu fuer unterwegs):
- Settings → Sektion 🔑 "OAuth-Apps" zwischen Skills und Protokoll
- OAuthBrowser-Komponente analog zu Trigger/Skill-Browser:
Liste mit Status, Tap → Edit-Modal mit client_id/secret +
Advanced-Toggle fuer URLs. "Autorisieren ↗" oeffnet System-Browser
via Linking.openURL, redirected zur RVS-Callback-Page,
Status-Refresh nach 8s.
- "+ Custom"-Button → Full-Screen-Modal fuer Service-Anlage.
- brainApi um listOAuthServices/getOAuthApps/saveOAuthApp/
deleteOAuthApp/authorizeOAuth/revokeOAuth erweitert.
Workflow ist jetzt: "verbinde mich mit Dropbox" → ARIA registriert
Provider → "trag client_id/secret in Settings ein" → Stefan macht das
in App oder Diagnostic → "Autorisieren ↗" → fertig.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
App-Bugs:
- Trigger-Liste war leer: brainApi.listTriggers() cast'te {triggers: [...]}
direkt als Array, t.sort() warf — TriggerBrowser blieb leer. Fix: unwrap.
- GPS-Tracking startete erst bei SettingsScreen-Mount, nicht beim App-Boot.
Wenn Stefan direkt in den Chat ging, blieb GPS aus. Fix: restoreFromStorage()
in App.tsx useEffect.
- Text in Chat-Bubbles nicht markierbar / kein Copy-Mechanismus: Bubble jetzt
Pressable mit onLongPress + neues ⎘-Icon in Status-Row → openBubbleActions().
Alert-Menu mit "Ganzen Text teilen" + pro extrahierte URL/Mail/Tel eine
eigene Option. Share.share() — keine neuen Native-Deps noetig.
Brain — Skill-Mgmt:
- ARIA legte beim Skill-Umbau neue Versionen mit Suffix an (Skill-Friedhof),
weil sie kein Update/Delete-Tool kannte. Zwei neue META_TOOLS in agent.py:
skill_update (kann entry_code, readme, pip_packages, args, description,
active patchen — venv wird bei pip_packages-Aenderung rebuilt) + skill_delete.
- skills.py update_skill um entry_code/readme/pip_packages erweitert,
venv-Rebuild bei pip-Aenderung.
Bridge — Voice-Speed persistent:
- _next_speed_override war pro-Request-Override ohne Persistenz. Bei
Diagnostic-Chats / Trigger-Replies ohne vorherigen App-Chat fiel der Speed
auf 1.0 zurueck, ebenso nach Bridge-Restart. Jetzt: _persistent_xtts_speed
aus voice_config.json (xttsSpeed), wird nach jedem App-chat mit speed
autopersistiert. TTS-Generation faellt zurueck: per-Request > persistent > 1.0.
App — Feature 6:
- SkillBrowser.tsx: Liste aller Skills, Toggle aktiv/inaktiv, Detail-Modal
mit Args-Inputs, Ausfuehren mit Live-stdout/stderr, Logs der letzten 20
Runs, Loeschen. Settings-Sektion "Skills" (🛠️) zwischen Trigger und
Protokoll. brainApi.listSkills/getSkill/runSkill/updateSkill/deleteSkill/
getSkillLogs ergaenzt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bridge hat seit 5+h still gehangen — Container Up, asyncio idle im
selectors.select(), TCP-Verbindung zum RVS ESTABLISHED, aber keine
Events mehr verarbeitet. Klassischer Fall: NAT-Tabelle/Firewall hat
die TCP-Verbindung still gekillt (kein RST), Linux-Kernel mit Default-
Keepalive (2h idle) hat's nicht gemerkt, und der ws.ping()-Future hat
im Limbo gehangen ohne Exception zu werfen.
Schicht 1 — TCP-Keepalive aufm Socket:
SO_KEEPALIVE=1, TCP_KEEPIDLE=30s, TCP_KEEPINTVL=10s, TCP_KEEPCNT=3.
Halb-tote Verbindungen werden in ~1 min mit ECONNRESET sichtbar statt
nach 2h. Loest 80% der Faelle direkt.
Schicht 2 — Asyncio-Watchdog (_rvs_heartbeat_watchdog):
Separate Coroutine parallel zu _rvs_heartbeat. Letzterer markiert
_last_heartbeat_ok nach jedem erfolgreichen pong. Watchdog checkt
alle 20s: > 60s stale → ws.close() + transport.close() als Notausgang.
Schuetzt gegen ws.ping()-Limbo.
Schicht 3 — File-Based Liveness Thread:
Separater OS-Thread (NICHT asyncio) — immun gegen asyncio-Hangs.
Schreibt /shared/health/bridge_alive periodisch. Wenn
_last_heartbeat_ok > 180s stale: os._exit(1), Docker restart_policy
uebernimmt. Last-Resort wenn Schichten 1+2 versagen.
Plus: chat_history-Render nach Reload bezog nur #chat-box, nicht
#chat-box-fs (Vollbild). Wer im FS-Modus reloaded hat sah eine leere
Box statt der History. Jetzt rendert der Handler in beide Boxen
(gleicher Pattern wie addChat / addAriaFile).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sentence-transformers zieht torch als Dependency, und der Default-Wheel
auf x86_64-linux ist die CUDA-Variante mit allen NVIDIA-Libs
(nvidia-cudnn, nvidia-cublas, cuda-toolkit, triton, ...). ~5 GB pro
Build-Layer, frisst die 22-GB-VM auf.
Fix: torch CPU-Wheel explizit zuerst installieren. Damit ist die
torch-Dependency erfuellt wenn sentence-transformers spaeter kommt,
und die CUDA-Libs werden nie gezogen.
Brain laeuft eh komplett auf CPU (MiniLM-Embeddings ~120 MB), GPU-Bloat
war reine Disk-Verschwendung.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bisher musste Stefan bei OAuth-Flows manuell den Auth-Code aus der
Browser-URL kopieren (redirect_uri war localhost). Jetzt: RVS hat einen
HTTP-Listener auf demselben Port wie der WebSocket, Provider redirecten
nach Auth zu https://{RVS_HOST}/oauth/callback/{service}, RVS broadcastet,
aria-bridge forwarded, Brain matched state + tauscht code gegen Token.
Token-Refresh laeuft automatisch.
- rvs/server.js: hybrid http.createServer + WebSocketServer{noServer}.
Route GET /oauth/callback/{service}, broadcast oauth_callback an alle
Raeume, schoene Dark-Mode-HTML-Antwort an den Browser (Auto-Close 4s).
- bridge/aria_bridge.py: empfaengt oauth_callback, POSTet an Brain
/internal/oauth-callback.
- aria-brain/oauth.py: neuer Manager. Pending-Store mit state+TTL,
Token-Exchange (Basic-Auth oder Body je nach Provider), persistente
Speicherung in /shared/config/oauth_tokens.json (mode 0600),
Token-Refresh wenn <60s Restzeit. Vordefinierte Configs fuer Spotify,
Google, GitHub, Strava, Microsoft.
- aria-brain/agent.py: META-Tools oauth_authorize / oauth_get_token /
oauth_revoke.
- aria-brain/prompts.py: System-Prompt-Block zeigt ARIA die feste
Callback-URL als Quelle der Wahrheit + aktuelle Service-States.
- aria-brain/main.py: HTTP-Endpoints /oauth/services, /oauth/apps,
/oauth/authorize, /oauth/{service}/revoke, /internal/oauth-callback.
- diagnostic: neue Section "OAuth-Apps". Pro Service Karte mit Status,
client_id + client_secret (Passwort-Toggle), Speichern + Autorisieren-
Buttons. Authorize oeffnet Provider-Auth in neuem Tab.
- docker-compose.yml: brain-env um RVS_HOST + RVS_PORT_PUBLIC + RVS_TLS
ergaenzt (Brain braucht die Werte zum Bau der Callback-URL).
- .env.example: RVS_PORT_PUBLIC + Brain-Timeout-Vars (PROXY_TIMEOUT_SEC
+ Connect/Write/Pool) dokumentiert.
- README.md: OAuth-Pipeline + ARIA-Live-Mirror in Diagnostic-Section,
OAuth-Apps in Einstellungen-Tab erwaehnt.
- issue.md: OAuth-Pipeline + Brain-Timeout-Fix als erledigt dokumentiert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Brain timed bei langen Pentests nach exakt 20:00 min raus, obwohl ARIAs
Subprozess fleissig weiterarbeitete und der Live-View alles zeigte.
Root-Cause: proxy_client.py hatte einen 1200s httpx.Client-Timeout —
genau der Wert, den wir vor 5 Tagen am Proxy auf 24h hochgezogen hatten.
Schicht uebersehen.
- docker-compose.yml: PROXY_TIMEOUT_SEC=86400 als brain-env.
- proxy_client.py: httpx.Timeout split (connect=10, read=86400, write=30,
pool=10). Toter Proxy wird in 10s erkannt, lange ARIA-Sessions duerfen
24h laufen.
- routes.js handleNonStreamingResponse: res.on("close") + isComplete-Flag.
Brain-Disconnect killt jetzt den Subprozess statt ihn verwaisen zu lassen.
- agent.py chat(): try/except — bei Exception nach dem User-Turn wird ein
Assistant-Error-Marker geschrieben, damit Conversation user->assistant
konsistent bleibt (kein Tool-Call-Loop-Fail in Folge-Calls).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pentests u.ae. brauchen oft >20min — der bisherige 20-min Hard-Cutoff
in claude-max-api-proxy's subprocess/manager.js killte den Subprocess
mitten in der Arbeit, egal wie aktiv ARIA gerade war.
Loesung:
- Hard-Timeout via sed auf 24h hochgesetzt (Last-Resort gegen wirklich
haengende Subprozesse).
- Eigener Idle-Watchdog in routes.js: Subprocess wird gekillt erst wenn
ueber ARIA_IDLE_TIMEOUT_MS (Default 20min) keine message/content_delta
Events ankommen. Jede Aktivitaet resettet den Timer.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Der claude-max-api-proxy Subprocess-Manager emittiert nur 'message',
'assistant', 'content_delta', 'result', 'error', 'close', 'raw' —
KEIN 'user'. tool_result-Blocks landen daher ausschliesslich im
generischen 'message'-Event mit type==='user'. Filter darauf statt
auf einen Event-Namen der nicht existiert, sonst kam in der ARIA-Live-
View nichts an.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
transformers 4.50+ registriert in integrations/moe.py einen torch.library
.custom_op mit String-Forward-References als Type-Annotations. Torch 2.4's
infer_schema kann diese nicht aufloesen ("Parameter input has unsupported
type torch.Tensor"), erst 2.5+ macht typing.get_type_hints() draus.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Aktuelles transformers schaltet PyTorch ab wenn < 2.4
("Disabling PyTorch because PyTorch >= 2.4 is required, found 2.3.1").
Ohne PyTorch laed diffusers das FLUX-Modell nicht. torchvision wird
zusaetzlich von CLIPImageProcessor/SiglipImageProcessor gebraucht.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Passwort-Feld in der FLUX-Section, mit Show/Hide-Toggle und kurzem
Hinweis-Link zu den HuggingFace-Schritten (Lizenz-Agree + Token-Erzeugung).
Wert wird in voice_config.json persistiert und per config-Broadcast an
die flux-bridge gepusht; dort vor jedem from_pretrained als HF_TOKEN +
HUGGING_FACE_HUB_TOKEN env gesetzt.
HF_TOKEN aus .env.example + docker-compose.yml entfernt. Auch FLUX_MODEL
aus compose raus — Default-Modell kommt jetzt komplett aus Diagnostic.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stand vorher in der Sprachausgabe-Card — falscher Ort, weil
Bildgenerierung eigene Domaene ist. Neue settings-section zwischen
Sprachausgabe und Whisper.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Diagnostic-Einstellungen fuer FLUX:
- Default-Modell (dev | schnell) — wird via RVS gepusht, flux-bridge
hot-swappt die Pipeline aus dem HF-Cache (~15-30s)
- Raw-Keyword (Default 'flux') — Pipe-Modus, Brain leitet Stefans Text
1:1 als prompt durch, kein Rewriting/Beautify
- Switch-Keyword (Default 'fix') — zwingt das ANDERE Modell als Default
Brain-Tool flux_generate um model + raw erweitert, System-Prompt-Block
mit den aktuellen Diagnostic-Settings + Whisper-Toleranz-Hinweis.
Kein eager Bootstrap-Load: flux-bridge wartet auf config oder ersten
Request. Bei erstem HF-Download zeigt Banner "laedt erstmalig runter"
mit Pfeil-Icon, Toast in der App wenn fertig.
FLUX_MODEL aus der .env entfernt (Steuerung jetzt komplett ueber
Diagnostic). HF_TOKEN-Kommentar erklaert warum trotz lokaler Inference
noetig (HF Gate-Mechanismus fuer FLUX.1-dev).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Eigener Compose-Stack im /flux Verzeichnis (kann auf separater Maschine
laufen). aria-bridge routet flux_request via RVS, ARIA referenziert das
fertige PNG im Reply mit [FILE: ...]-Marker. Brain-Tool flux_generate
mit Caps fuer steps/dimension.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom (aus Bridge-Log): bei chat_history_request triggert die App
file_request fuer alle fehlenden Anhaenge. Bei einem 40 MB MP4 wird das
base64-encoded ~53 MB, ueberschreitet das RVS-maxPayload (50 MB).
Server droppt mit Code 1009 'message too big', Bridge crasht im cleanup
mit AttributeError 'NoneType has no call_soon' (websockets-Lib-Bug bei
nested context-manager-cleanup nach abgerissener Verbindung).
Drei Layer:
(1) RVS-Server: maxPayload 50 → 100 MB — deckt ~70 MB binaer ab nach
base64-inflate. Comment im server.js erklaert den Hintergrund.
(2) Bridge: max_size 50 → 100 MB synchron zum Server. PLUS pre-check
im file_request-Handler — Dateien > 70 MB werden mit Fehler-Response
abgewiesen statt blind base64-zu-encoden und die WS zu killen.
Limit knapp unter Server-Limit damit Bridge proaktiv blockiert.
(3) App: file_response-Handler liest 'error'-Feld aus dem Payload und
zeigt nen Toast 'Datei X: Datei zu gross fuer Transfer (40 MB,
Limit 70 MB)'. Statt einfach zu schweigen oder endlos zu retryen.
Crash bei websockets-cleanup ist ein Lib-Bug (NoneType.call_soon) —
nicht direkt fixbar, aber tritt jetzt nicht mehr auf weil Bridge proaktiv
die zu grossen Files ablehnt und die WS nicht mehr abreisst.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bridge fuegt User-Texten Praefixe in eckigen Klammern hinzu damit Brain
Kontext hat — z.B. '[Stefans aktuelle GPS-Position: 53.0, 8.5. Nutze die
nur wenn ...]' oder '[Hinweis: Stefan hat dich gerade unterbrochen...]'.
Die landeten via chat_backup auch in der App-Bubble — Stefan sieht jeden
Hint mit, hat nichts in der UI verloren.
Fix: App-side stripSystemHints() filtert aufeinanderfolgende `[...]`-
Bloecke am Textanfang inkl. Trennleerzeichen. Wird in renderMessage
angewendet, default an (Hints versteckt). Toggle in Settings →
Allgemein → 'Chat-Bubbles' kehrt's um falls Debug gewuenscht.
Brain bekommt weiterhin den vollen Text — Bridge-Side unveraendert.
Live-Toggle: Settings setzt aria_show_hints in AsyncStorage, ChatScreen
re-liest alle 2s (gleicher Mechanismus wie tts_enabled etc.).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Diagnostic loggte konstant '[gateway] Nicht verbunden — kann nicht senden'
weil die UI bei jedem Send-Klick noch versuchte ueber den OpenClaw-
Gateway-Pfad zu schicken. Den gibt's seit Monaten nicht mehr — alles
laeuft via Diagnostic → RVS → Bridge → Brain (HTTP).
server.js:
- sendToGateway() loggt nichts mehr (No-Op, returnt false)
- sendToRVS() raeumt den 'gateway + RVS dual'-Pfad weg, geht direkt
ueber RVS
- 'test_gateway'-Action vom Client wird umgeleitet auf RVS damit alte
Browser-Sessions noch funktionieren
index.html:
- 'Gateway senden'-Buttons (Chat-Test + Vollbild) entfernt, 'Via RVS
senden' umbenannt zu 'Senden'
- Gateway-Tab im Log-Viewer raus, mapSourceToTab leitet evtl. Reste
in den server-Tab um
- testGateway() + testGatewayFS() JS-Funktionen entfernt
- btn-gw-Disable-Logik raus
connectGateway/handleGatewayMessage/gatewayWs/state.gateway im server.js
bleiben als deprecated stehen — kein aktiver Code zugreift mehr drauf,
aber rauswerfen wuerde viele Diffs erzeugen ohne Nutzen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: App bekommt im minimierten oder display-gesperrten Zustand
nicht mit ob ein Anruf angefangen oder beendet wurde — TTS spricht
weiter waehrend Telefon klingelt, oder bleibt stumm nach Auflegen.
Zwei Ursachen:
1) Kotlin: TelephonyCallback war auf reactApplicationContext.mainExecutor
registriert. Wenn die Activity pausiert ist (display aus, App im
Hintergrund), wird der mainExecutor verzoegert oder gar nicht
abgearbeitet — Call-State-Events kommen nicht durch.
Fix: eigener Executors.newSingleThreadExecutor() — laeuft unabhaengig
vom UI-Thread solange der App-Prozess lebt (Foreground-Service
garantiert das).
2) TS: TelephonyManager-Listener kann nach laengerer Hintergrund-Zeit
verloren gehen (React-Bridge-Context recreated nach Resume).
Fix: neue refresh()-Methode in phoneCallService, AppState-Resume
ruft sie auf — wenn telephonyAttached=false ist, wird der Native-
Listener neu attached.
Plus: Status-Property telephonyAttached macht in Logs sichtbar ob
Pfad 1 (TelephonyManager) wirklich greift. Pfad 2 (AudioFocus fuer
VoIP) war nie betroffen, der laeuft komplett im Native-Code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: Ohr aktiv, App im Hintergrund (jetzt mit Foreground-Service
permanent lebendig), nach laengerer Zeit oeffnet Stefan die App und sie
nimmt schon auf — angeblich Wake-Word getriggert. War aber TV/Husten/
sonstige Hintergrund-Geraeusche waehrend Stefan nicht da war.
Mit dem neuen Hintergrund-Modus laeuft openWakeWord jetzt permanent und
faengt jedes False-Positive im Hintergrund auf. Ohne dieser Fall war
das nicht moeglich weil die JS-Engine pausiert war.
Fix: Heuristik beim AppState-Resume in ChatScreen.tsx
- backgroundDauer wird gemerkt (lastBackgroundAt vs Resume-Zeit)
- Wenn >30s im Hintergrund UND state='conversing' UND letzter Wake-
Trigger juenger als 15s: false-positive — Aufnahme abbrechen + zurueck
zu armed
- Resume-Cooldown 1500 → 3000 ms (Audio-Spikes beim AppState-Switch
haben gelegentlich nach 1.5s noch nicht verklungen)
Neue Methoden:
- wakeword.ts: lastTriggerAt-Tracking + discardIfFreshlyTriggered(maxAge)
- audio.ts: cancelRecording() — bricht recorder ab ohne Result zu
emittieren, loescht die Audio-Datei
Setzt voraus dass Stefan nicht laenger als 30s im Hintergrund mit ARIA
spricht ueber Wake-Word. Falls doch: bei Resume waere die Aufnahme weg
und er muesste nochmal triggern.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bisher pausierte Android nach ~30s im Hintergrund die JS-Engine.
WebSocket schlief ein, Trigger-Replies vom Brain kamen nicht durch,
Timer-Erinnerungen feuerten in der App nicht obwohl im Brain
ausgeloest. Nach laengerer Hintergrund-Pause warf Android den
Prozess ganz raus → beim Wiedereroeffnen Cold-Start, sah aus wie Crash.
Loesung: Foreground-Service mit persistenter Notification — die ist
ohnehin schon da fuer TTS/Mic-Aktivitaet (`AriaPlaybackService`).
Wir erweitern das Slot-System um einen `background`-Slot der dauerhaft
aktiv ist (Settings-Toggle, default an). Notification zeigt "ARIA aktiv
— Hintergrund-Modus" wenn nichts spezifisches laeuft, escaliert zu
"ARIA spricht/hoert" bei TTS/Mic. Tap → App.
Drei Dateien:
- services/backgroundAudio.ts: 'background' als 4. Slot (niedrigste
Prio, Fallback-Notification). Bestehende tts/rec/wake unveraendert.
- App.tsx: beim Start `acquireBackgroundAudio('background')` aufrufen
wenn Settings nicht explizit deaktiviert. Plus POST_NOTIFICATIONS-
Permission-Request (Android 13+).
- screens/SettingsScreen.tsx: neuer Toggle in Allgemein-Section.
Plus Hinweis auf Android-Akku-Optimierung-Whitelist falls trotzdem
was klemmt (manche Hersteller-ROMs killen aggressiv).
AndroidManifest unveraendert — foregroundServiceType="mediaPlayback|
microphone" deckt unseren Use-Case ab (ARIA spielt regelmaessig TTS
ab, was den Type rechtfertigt). Service stoppt sich selbst wenn alle
Slots leer sind, das passiert nur wenn der User in Settings den
Hintergrund-Modus deaktiviert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
(1) Gedanken-Stream Modal: vorheriger Fix mit onStartShouldSetResponder
war falsch — der View wurde komplett zum Responder, die FlatList drin
bekam null Touch-Events. Jetzt: outer View ohne Touch-Handling, ein
separates TouchableOpacity-Element oberhalb des Sheets nur fuer den
Tap-Outside-Close. Sheet-View ist plain View → FlatList scrollt frei.
(2) Such-Sprung praeziser: drei Verbesserungen
- MAX_SCROLL_RETRIES 3 → 6: bei weiten Spruengen (Bubble #150 von
Position 0) braucht FlatList mehrere Iterationen bis die Items in
der Naehe gemessen sind
- Pre-Scroll-Offset: Fallback fuer unmeasured Items ist jetzt der
dynamische Mittel der bisher gemessenen Items (statt Pauschal-150).
Beim Cold-Start sind nur die untersten 10 gemessen, aber deren
Mittel ist immer noch eine bessere Schaetzung
- Render-Pause nach Pre-Scroll 200 → 350 ms: bei weiten Spruengen
braucht FlatList Zeit die Items zu mounten und onLayout zu feuern
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
App-Inbox-Modal:
- ScrollView der Top-Section ('Aus diesem Chat') nestedScrollEnabled=true
- MemoryBrowser darunter in einen flex:1-Wrapper gepackt damit er den
verbleibenden Platz bekommt — ohne den hat seine FlatList intern
null Hoehe gehabt und Scroll-Gestures verschluckt.
Diagnostic Trigger-Tab:
- ✎ Bearbeiten-Knopf pro Zeile (neben Aktivieren/Deaktivieren/Loeschen)
- Modal hat jetzt einen Edit-Modus: Type+Name disabled, Save-Button
zeigt 'Speichern', Modal-Title 'Trigger bearbeiten — <name>'
- Fuer Timer im Edit-Modus ein zusaetzliches Feld 'Feuert am (ISO, UTC)'
damit man den absoluten Zeitpunkt direkt aendern kann (statt 'in X
Minuten ab jetzt' das nur fuer Create Sinn macht)
- saveTrigger() unterscheidet jetzt zwischen Create-Modus (POST
/triggers/timer|watcher) und Edit-Modus (PATCH /triggers/{name})
- openTriggerEdit(name) fuellt das Modal mit Werten aus dem Cache
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Settings hatte zwei Probleme:
1) Gedächtnis-Liste scrollte nur runter, nicht hoch. Klassisches Android
nested-Scroll-Problem: aeussere ScrollView + innere FlatList mit
fixer height:600 = nur eine Richtung wird respektiert.
Fix: outer ScrollView mit scrollEnabled=false wenn die Section eine
eigene voll-hoch-scrollende Sub-Liste hat (memory/triggers). Plus
dynamische Hoehe via useWindowDimensions (winHeight - 220 statt
hardcoded 600) damit MemoryBrowser sauber den verfuegbaren Platz
nutzt.
2) Trigger waren bisher nur via Diagnostic-Tab editierbar — keine App-
side CRUD. Stefan wollte das.
Neu: TriggerBrowser-Komponente (analog MemoryBrowser-Struktur)
- Liste aller Trigger mit Filter (alle/aktive/inaktive)
- Toggle aktiv/inaktiv via Switch direkt in der Zeile
- Tap oeffnet TriggerEditModal (Nachricht/Condition/fires_at/intervals
editieren, Loeschen-Knopf mit Confirm)
- "+ Neu"-Knopf oeffnet TriggerNewModal mit Type-Switch (Watcher/Timer),
Watcher zeigt Hinweis auf verfuegbare Funktionen + Variablen
- Live Reload-Button, Meta-Info (fire_count, last_fired_at, ...)
brainApi um Trigger-Endpoints erweitert: listTriggers, getTrigger,
createTimer, createWatcher, updateTrigger (patch), deleteTrigger,
getTriggerConditions, getTriggerLogs. Plus Trigger-Type-Definition.
Settings-Liste hat eine neue Section "⏰ Trigger" zwischen Gedaechtnis
und Protokoll.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
(1) Such-Treffer jetzt neueste zuerst (analog WhatsApp/Telegram). User
ist visuell unten, der erste Sprung landet meist im Viewport ohne
weiten Pre-Scroll (= weniger Cold-Start-Fail-Risiko). „Naechster"
geht in die Vergangenheit. Plus Pre-Scroll-Wartezeit 80→200 ms damit
FlatList beim ersten Versuch wirklich Zeit zum Rendern hat.
(2) SettingsScreen Ueber-Text: `—` wurde literal gerendert weil
JSX-Text-Knoten keine JS-String-Escapes interpretieren. Fix:
`{'—'}` als JS-Expression-Block.
(3) GPS-Tracking sendete nach der initialen Position nichts mehr wenn
der User stationaer war — `distanceFilter: 30` blockiert
watchPosition-Updates ohne Bewegung. Nach 5 min (NEAR_MAX_AGE_SEC)
verwirft das Brain die Position als veraltet → near()-Watcher feuern
nie. Stefan's DRK-Trigger waren so chronisch tot.
Fix: zusaetzlich zum watchPosition laeuft ein setInterval(60s)
Heartbeat der die zuletzt empfangene Position erneut sendet. Kein
extra GPS-Wakeup — akkufreundlich. Damit bleibt der Brain-State
frisch auch bei stationaerem User; near() funktioniert sobald der
User tatsaechlich im Radius ist.
Anmerkung zu Stefan's konkretem Test: er war 1.5–2 km von den DRK-
Triggern entfernt (Radius je 300 m) — selbst mit frischen GPS-Updates
haetten die nicht gefeuert. Der Heartbeat-Fix ist trotzdem noetig
damit Trigger ueberhaupt eine Chance haben wenn er tatsaechlich dort
vorbeifaehrt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: Suche nach 'cessna' sprang zur Oberhausen-Bubble (~15 Bubbles
daneben), egal welcher Versuch.
Zwei Ursachen:
1) searchMatchIds suchte in `messages` (alle Bubbles inkl. Memory/Skill/
Trigger-Spezial-Bubbles), aber gescrollt wird in `invertedMessages`
die diese filtert. Wenn 'cessna' nur in einer Memory-Bubble vorkam,
war die ID in searchMatchIds aber nicht in invertedMessages →
findIndex=-1 → kein Scroll, Pre-Scroll-Offset von voriger Aktion
blieb sichtbar. Fix: searchMatchIds aus chatVisibleMessages.
2) AVG_BUBBLE_HEIGHT=150 als Pauschalschaetzung war zu grob — Voice-
Bubbles sind ~70 px, lange ARIA-Antworten 400+. Pre-Scroll-Offset
landete bei langen Listen weit daneben. Fix: itemHeights-Ref-Map
wird per onLayout in renderMessage gefuettert. Pre-Scroll summiert
echte gemessene Hoehen (Fallback AVG fuer noch nicht gerenderte) —
beim zweiten Such-Versuch lernt der Cache, beim ersten klappt's
schon besser als mit dem Pauschalwert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: Suchbegriff direkt nach App-Start eingegeben → springt an
falsche Stelle. Erst beim zweiten Versuch funktioniert es.
Ursache: FlatList rendert per Default nur 10 Items initial.
info.averageItemLength im onScrollToIndexFailed basiert nur auf diesen
10 — bei einem Suchtreffer auf Bubble 150 ist die Schaetzung katastrophal
falsch. Beim zweiten Versuch ist die FlatList „warm gelaufen" und mehr
Items sind gemessen → Schaetzung passt besser.
Drei kombinierte Fixes:
1) Pre-Scroll: vor dem scrollToIndex erst grob mit AVG_BUBBLE_HEIGHT=150
per scrollToOffset(idx*150) in die Naehe springen. FlatList rendert
die Bubbles in der Naehe, dann praezise nachsetzen nach 80ms.
2) initialNumToRender=30 (Default 10) — mehr Items beim Mount gemessen.
3) windowSize=41 (Default 21) — mehr Items im Speicher gehalten, weniger
Layout-Holes beim Weit-Scroll.
Kosten: minimal hoehere Mount-Zeit. Bei 300+ Bubbles im Backup macht
sich der UX-Gewinn lohnt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: Suche zeigt Treffer, springt aber permanent zwischen Bubbles
hin und her in Endlosschleife.
Zwei Ursachen, beide angeschlossen:
1) agent_activity-Handler rief setMessages mit prev.map() — auch wenn
keine sending-Bubble da war. Das erzeugte trotzdem ein neues Array
bei jedem Tool-Event (5-10x pro Brain-Call). invertedMessages neu →
FlatList-Layouts invalidiert mitten in einer aktiven Scroll-Sequenz.
Fix: prev.some() vor map() — wenn nichts zu aendern ist, prev
unveraendert returnen (reference-stable, kein Re-Render).
2) onScrollToIndexFailed retried unbegrenzt. Jeder failed Retry rief
den Handler erneut auf → neuer setTimeout → neuer Versuch → fail →
loop. Vorher waren cascading 3 Retries, dann auf 1 reduziert um
den 3-9-27-Cascade zu fixen, aber EIN ungebremster Retry-Schluss
pro fail bleibt eine Endlos-Schleife wenn Layouts nie stabil
werden. Fix: harter Counter (MAX_SCROLL_RETRIES = 3). Counter wird
bei jedem neuen Search-Hit via clearPendingScrollRetry resettet.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Der innere TouchableOpacity (eigentlich nur da um Tap-Propagation an
das aeussere close-on-tap-outside-Wrapper zu blocken) hat alle Touch-
Events konsumiert — FlatList bekam nichts ab, kein Scroll moeglich.
Fix: inner durch View ersetzen, mit onStartShouldSetResponder=true
plus onResponderTerminationRequest=false. Das blockt die Propagation
ohne Scrolls der Children zu verschlucken.
Close-on-Tap-outside funktioniert weiter (aeusseres TouchableOpacity
bleibt), das X im Header schliesst auch, Hardware-Back ebenfalls.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: ARIA bearbeitet die Nachricht (im Gedanken-Stream sichtbar),
aber unter der User-Bubble bleibt die Sanduhr stehen und nach ~90 s
springt sie auf ⚠ failed. ARIA-Antwort kommt trotzdem irgendwann durch
— die Bubble war also nie weg, nur visuell schief.
Wurzel: chat_ack vom Bridge kam offenbar in manchen Faellen nicht
verlaesslich an. ACK-Timer (30 s × 3 Retries) lief durch → 'failed'.
Fix: agent_activity = thinking/tool/assistant ist impliziter Beweis,
dass das Brain die Nachricht bekommen und angefangen hat zu arbeiten.
Beim ersten non-idle Event:
- alle laufenden ACK-Timer cancelen
- alle 'sending'-User-Bubbles auf 'sent' (✓) setzen
ARIA-Reply markiert dann wie gehabt 'delivered' (✓✓). Damit kann keine
Bubble mehr auf failed gehen waehrend Brain noch laeuft.
Plus: ACK_TIMEOUT_MS 30 → 60 s als Backup-Reserve fuer den Fall dass
weder ACK noch agent_activity ankommt (sehr unwahrscheinlich, aber
billig).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
duffyduck