Qwen imitierte aus dem Kontext den <voice>-TTS-Block, packte aber die GANZE
Antwort hinein -> Display strippt <voice> -> leere Bubble (nur TTS klang richtig).
Fix: (1) Local-Prompt verbietet <voice>/[FILE:]/<tool_call>/Markup explizit —
nur Plain-Text (wird angezeigt UND vorgelesen). (2) Sicherheitsnetz: Voice-Tags
aus lokalen Antworten strippen, falls das 8B es doch tut.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
web_search war versehentlich in META_TOOLS -> Claude bekam es zusaetzlich zu
seinen nativen WebSearch/WebFetch/Bash (redundant/verwirrend). Jetzt als
WEB_SEARCH_TOOL nur im lokalen Tool-Set (_build_local_tools). Claude nutzt
weiter seine eigene Suche + Voll-Seiten-WebFetch (wichtig fuer Pentest/Research);
SearXNG ist fuer das lokale Tier, das sonst keinen Netzzugriff haette.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pro Schalter ein kurzer Hilfetext (AN/AUS-Bedeutung, Testmodus-Warnung),
deutlichere Labels, Status-Zeile mit Ampel (⚪/🟡/🟢) + Hinweis auf aktuellen
B1a-Stand (lokal plaudert nur, Tools folgen in B1b).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wiederkehrender Identity-Bug: --system-prompt liefert die Persona korrekt (Proxy-
Test = "ICH BIN ARIA"), ABER ein einziger in der History gespeicherter Break
("ich bin nach wie vor Claude / die Persona ist erfunden") zieht bei schwachen
Folgeturns eine Kaskade nach sich — das Modell setzt seine eigene Ablehnung fort.
Das erste Cleanup verlangte "claude code" und liess deutsche Breaks durch.
Fix zweifach:
- prompts.py: looks_like_identity_break() — STARKE selbstreferenzielle Marker
(ich-bin-Claude / erfundene Persona / diese-Session-injiziert / nicht-real-in-
dieser). Bewusst NICHT das blosse "injizier"/"prompt injection" — das nutzt
ARIA in Pentest-Antworten legitim (verifiziert: 0 False Positives).
- agent.py: nach dem Claude-Loop Break-Check; bei Break Retry (Nondeterminismus
holt meist ARIA), sonst sichere ARIA-Fallback-Antwort — Break wird NIE
persistiert. Auch die lokale Fast-Lane eskaliert bei Break auf Claude.
- clean_poisoned_turns.py: auf denselben starken Matcher umgestellt (der breite
produzierte False Positives auf echte Security-Doku, im Dry-Run gesehen).
VM bereits bereinigt (je 2 Rest-Breaks aus conversation.jsonl + chat_backup).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gemessen: lokaler Call mit 12-Turn-Fenster ~2,6s statt ~0,8s. Im Hauptchat (bis
50 Turns) wuerde volles Fenster das Prefill aufblaehen und den Speed-Vorteil
auffressen. Lokales Tier ist fuer kurze Plauder-Turns — letzte 8 Turns reichen.
B1a end-to-end verifiziert: plaudern→lokal (~0,8s warm), Tool/hart→Claude,
localOnly erzwingt lokal; Config live gelesen, Default aus.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Button = remote start/stop = braucht Agent pro Host, aber dumme Variante:
gpu_placement.json als Single Source of Truth, Agent reconciled nur (Mensch =
Scheduler). Loest die Reboot-Falle (Laufzeit-Move vs statische Config). Deploy:
Code ueberall via git, Config entscheidet Platzierung. Nach B0/B1; Fallback =
COMPOSE_PROFILES manuell.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Semi-Auto-Controller verworfen (Host wechselt selten). Pin via Compose-Profiles
pro Host (.env COMPOSE_PROFILES), Verschiebe-Regel up-neu + rm-alt gegen
Reboot-Wiederauferstehung, GPU-Dashboard aus Heartbeats (read-only). Skaliert
auf Gamebox3/4x3060 ohne Orchestrator.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Idee Container-start/stop auf RVS-Hosts: billiger Teil (Registrierung/Heartbeat
-> Flotten-Sichtbarkeit + Router-Erreichbarkeit) lohnt bald; teurer Teil
(Agent+Controller+Placement = Mini-Nomad) erst bei groesserer Flotte, dann eher
Swarm/Nomad statt Eigenbau. Fuer 2 Gameboxen: statische Platzierung + llama-swap.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Roher VRAM ist nicht ueber RVS teilbar (Relay, nicht GPU-Bus). Echte Pfade:
mehr Karten/Box = VRAM-Pool (volles Arsenal), mehr GPU-Hosts = Modell-Server
ueber RVS (Cluster), llama-swap = geteilter Server im Host. Plus geplantes
Diagnostic-Info-Icon mit VRAM-Bedarf pro Ausbaustufe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Klargestellt: lokales Modell ist ueber ALLES im Bilde (kurze Awareness-Liste im
System-Prompt -> gezieltes Escalieren), darf aber nur den sicheren Satz
ausfuehren. Harte Grenze ist Kontext/VRAM (volles Schema ~15-20K Tokens passt
nicht in 8K, 32K-Kontext sprengt die geteilte 12GB-3060), nicht Misstrauen.
Claude im RZ mit 200K-1M Kontext kann sich das ganze Arsenal leisten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Brain → HTTP /internal/local-llm → Bridge → RVS → llm-adapter → llama.cpp,
1:1 nach dem FLUX-Roundtrip-Muster gebaut:
- Bridge: _pending_llm (requestId→Future), llm_response-Handler (setzt Future),
_local_llm() (sendet llm_request, wartet mit 30s-Timeout), HTTP-Route
POST /internal/local-llm ({messages, max_tokens?, temperature?, stop?}).
- Brain: local_llm.py mit local_llm_chat() — POSTet an die Bridge, gibt
{ok, content, model?, elapsedMs?} zurueck, wirft nie (Aufrufer eskaliert
bei ok=false auf Claude).
Provider-Kette bereits verifiziert (718ms). Als naechstes: Test brain→bridge→
gamebox end-to-end, dann B1 (Router-Heuristik + Escalation) und der
Diagnostic-Testchat/Status (B0.5).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Qwen3 hat Thinking default AN -> verbraet Tokens im <think>-Block, liefert bei
kleinem max_tokens leeren content und ist ~3x langsamer (2,2s statt 0,7s im
Test). ARIAs lokales Tier soll fixe Antworten geben, nicht grübeln (grübeln =
harter Turn = Claude). Adapter setzt daher chat_template_kwargs
{enable_thinking:false}; abschaltbar via LLM_DISABLE_THINKING=false.
Verifiziert end-to-end (RVS->Adapter->llama->Qwen3): "Hallo! Ich bin bereit."
in 718ms Round-trip RZ<->Gamebox@home.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Statt einer manuell abgelegten Datei zieht llama.cpp das Modell beim ersten
Start selbst von Hugging Face (-hf Qwen/Qwen3-8B-GGUF:Q4_K_M, offizielles
Repo verifiziert) und cached es unter xtts/models (persistent). Modell/Quant
via LLM_HF_REPO/LLM_HF_QUANT in der .env wechselbar, kein Code.
Diagnostic-Modellauswahl (on-demand laden/aktivieren mehrerer Modelle) als
Folge-Baustein B0.5 via llama-swap ins Plan-Doc aufgenommen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Plan B, Phase B0 (Provider): lokales Qwen3-8B auf der Gamebox, angebunden
per RVS wie f5tts/whisper (kein IP-Pflegen, nur URL+Token).
- xtts/llm-adapter/: RVS-Client (spiegelt whisper-bridge: TLS+ws-Fallback,
Reconnect-Backoff), nimmt llm_request, ruft llama.cpp /v1/chat/completions
lokal, antwortet llm_response (korreliert per requestId). Nicht-streamend
in B0; llm_partial fuer B2 reserviert.
- xtts/docker-compose.yml: neue Services `llama` (llama.cpp server-cuda,
GGUF via ./models, OpenAI-API auf :8081) + `llm-adapter`.
- rvs/server.js: ALLOWED_TYPES += llm_request/llm_response/llm_partial.
- GGUF (mehrere GB) via .gitignore aus dem Repo; xtts/models/ mit .gitkeep.
Topologie-Hinweis: Gamebox@home, ARIA@RZ -> Bounce ueber Internet ist
unvermeidbar (Voice macht's schon so); Router faellt bei Nichterreichbarkeit
per Escalation auf Claude zurueck. Consumer-Seite (Bridge-Relay + Brain-
Client + Router) kommt als naechstes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Design-Doc: schnelles lokales LLM fuer die einfachen ~80% der Turns (<1s,
gratis auf Gamebox-GPU), Claude nur fuer die schweren 20%. Anbindung ueber
den RVS-Token-Room wie TTS/STT (kein IP-Pflegen), Router mit Heuristik +
Escalation, schlanke Persona lokal, Phasen B0-B3. Basiert auf der
Latenz-Messung (CLI-Boden ~3,5s) aus dieser Session.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher: tts_text = tts_text_preview or text — ein leeres <voice></voice> fiel
auf den vollen Text zurueck und wurde doch gesprochen. Jetzt: ein vorhandener
<voice>-Tag ist die EXPLIZITE TTS-Vorgabe (auch leer). Leeres <voice></voice>
= Bubble sichtbar, aber KEIN TTS. Nur ohne Tag Rueckfall auf vollen Text.
Motivation: Spotify-Steuerbefehle (next/pause/…) laufen jetzt ueber den
Fast-Path (<1s), aber die gesprochene Quittung klaute auf dem Handy den
Audio-Fokus -> Spotify duckte/pausierte und spielte (bei kurzem Text) nicht
weiter. Steuer-Skills koennen ihre Reply nun mit <voice></voice> stummschalten.
Generell nutzbar: ARIA kann jede Antwort bewusst stumm halten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Einmal-Tool zum Entfernen der aus-der-Rolle-Antworten ("das ist injiziert,
ich bin Claude Code"), die waehrend der --append-system-prompt-Phase in die
History geschrieben wurden und das Modell per Self-Grounding rueckwaerts aus
der Rolle zogen (siehe 2284c1a). Feld-agnostisch: bedient conversation.jsonl
(content/project_id) UND chat_backup.jsonl (text/projectId). Entfernt nur
Hauptthread-Assistant-Turns mit "claude code" + zweitem Ablehnungs-Marker
plus die ausloesende Frage; projekt-getaggte Turns (z.B. legitime Pentest-
Doku, die Injection als Arbeitsmaterial erwaehnt) bleiben unangetastet.
Dry-Run per Default, Backup vor --apply, idempotent.
Bereits auf der Dev-VM angewandt: je 5 Fehl-Dialoge aus beiden Dateien
entfernt, Brain neu gestartet, Hauptchat verifiziert (ARIA antwortet wieder
als ARIA mit vollem Memory-Zugriff).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Self-Grounding-Ansatz (268636c) allein reichte nicht: Sonnet 5 in Claude
Code haelt seine eingebaute "You are Claude Code"-Identitaet hart und liest den
synthetischen <previous_response> als "fabricated". Ursache bleibt der Kanal:
--append-system-prompt HAENGT ARIAs Persona nur hinten an Claude Codes Basis-
Identitaet an — bei duennem Kontext (Hauptchat) gewinnt die Basis und wehrt die
Persona als Injection ab. Anhaengen ist gegen das Anti-Injection-Training des
Modells nicht durchsetzbar.
Fix: System-Prompt VOLL ersetzen statt anhaengen — sed-Patch in docker-compose
schaltet manager.js buildArgs von --append-system-prompt auf --system-prompt.
Damit ist die ARIA-Persona DIE Identitaet des Modells (kein Anhaengsel), und
Claude Codes dynamische Sektionen (cwd '/', git, platform) — die "ich bin ein
Coding-Agent"-Signale — fallen weg. Bestaetigt per claude-code-guide: die CLI
isoliert bei --system-prompt vollstaendig, die eingebaute Identitaet leakt nicht.
extractSystemPrompt liefert weiterhin einen selbsttragenden Prompt (Persona +
Anker + Memory + Skills + Tool-Block); er darf bei --system-prompt nie leer sein
(Brain schickt immer System-Message + Tools -> real nie leer). Der IDENTITY_SEED
aus 268636c bleibt als Defense-in-Depth drin. Kommentare in openai-to-cli.js,
routes.js, agent.py, prompts.py entsprechend nachgezogen.
Deploy: Proxy UND Brain neu (--force-recreate; routes.js/openai-to-cli.js werden
frisch in den Proxy-Container ge-cp't). Verifikation am Container:
docker exec aria-proxy sh -c 'grep -o "\-\-system-prompt" /usr/local/lib/*/claude-max-api-proxy/dist/subprocess/manager.js'
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Symptom: Im Hauptchat antwortete statt ARIA der Basis-Proxy-Claude ("I'm
Claude Code (Sonnet 5), I'm not adopting that persona") und flaggte GPS +
Tool-XML als Prompt-Injection. Im Projekt lief alles normal.
Ursache: Die Persona geht ueber --append-system-prompt zu — das HAENGT sie
nur hinten an Claude Codes eigene "You are Claude Code"-Basis-Identitaet an,
ersetzt sie nicht. Ob ARIA in der Rolle bleibt, entscheidet dann der
Konversations-Strom (stdin): reiche Projekt-Historie voller ARIA-
<previous_response>-Turns haelt die Rolle; der duenne Hauptchat-Verlauf
(bzw. der erste Turn eines neuen Projekts) nicht -> Basis-Identitaet gewinnt.
Der IDENTITY_ANCHOR (a0e8c23) ist inert, weil er im *angehaengten* Teil steht.
Fix: synthetischen ersten ARIA-Turn (IDENTITY_SEED) in ihrer eigenen Stimme
an den Anfang des Konversations-Stroms setzen. Das Modell setzt seine EIGENE
etablierte Stimme fort (Self-Grounding) — und weil es ein <previous_response>
ist und kein <system>-Tag, ist es kein Injection-Trigger. Rein ephemer, wird
nie in die Conversation persistiert. Gilt fuer alle Turns, deckt damit auch
die erste Frage eines frischen Projekts ab.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
handleModels liest die kuratierte Tier-Liste jetzt pro Request aus
/shared/config/models.json statt sie hart zu codieren. Neue Tier-Namen oder
angepasste Beschreibungen sind damit eine reine Datei-Aenderung — kein
Code-Edit, kein Proxy-Neubau, kein Neustart (Datei bearbeiten → im Diagnostic
„↻ Aktualisieren").
- Fehlt/kaputt die Datei: eingebaute Defaults greifen und werden einmalig als
models.json angelegt, damit es was zu editieren gibt.
- ids bleiben MODEL_MAP-kompatibel (extractModel), Validierung: nicht-leeres
Array mit String-id, sonst Fallback auf Defaults.
- UI-Hinweis auf den Dateipfad ergaenzt.
- Load/Seed-Logik simuliert verifiziert.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ARIA laeuft ueber das Claude-Max-Abo via CLI — waehlbar ist der Tier, nicht
eine feste Modellversion (die CLI nimmt automatisch das aktuelle Modell des
Tiers). Kein API-Key → keine echte Anthropic-Models-API; daher kuratierte Liste.
- proxy routes.js handleModels: kuratierte /v1/models mit tier/display_name/
description (ids bleiben MODEL_MAP-kompatibel: claude-sonnet-4/opus-4/haiku-4).
- diagnostic server.js: neuer GET /api/models-list — holt die Liste vom Proxy
(Frontend erreicht den Proxy nicht direkt).
- Frontend: Dropdown statt Freitext + „↻ Aktualisieren"-Button; markiert das
aktive brainModel (get_model), zeigt Beschreibung, „Setzen" schreibt brainModel
und weist auf Brain-Neustart hin. Freitext-Override bleibt unter „Erweitert".
Liste wird bei WS-Connect automatisch geladen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Changelog hing bei 0.0.0.5 (2026-03), Projekt lief bis 0.2.0.2 (2026-07).
Nachgetragen: [Unreleased] (Identitaets-Anker, Proxy-System-Prompt, kontext-
getaggte Activity + kontext-scoped Cancel, Diagnostic Datei-Zuordnung) und der
zusammenhaengende Projekte-/Multi-Threading-Epos (0.1.9.7–0.2.0.2). Luecke
0.0.0.6–0.1.9.6 bewusst nicht rueckwirkend nacherfasst (Hinweis im Header).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Beide Restpunkte teilen eine Verkabelung: die projectId fliesst jetzt bis zum
Proxy und zurueck in die agent_activity-Events.
Restpunkt 1 — per-Kontext Activity-Indikator:
- Brain: proxy_client.chat_full(project_id) → payload.aria_project_id;
agent.py gibt active_project_id mit.
- Proxy routes.js: liest aria_project_id, taggt Tool-/Stream-Hooks damit,
trackt Subprozesse pro Kontext.
- Bridge: _emit_activity(project_id) + payload.projectId; /internal/agent-activity
reicht projectId durch; send_to_core/_process_core_response taggen thinking/idle
mit dem Turn-Kontext.
- App: agentActivityByCtx-Map; „ARIA denkt"-Indikator zeigt nur den
fokussierten Kontext statt global zu flackern.
Restpunkt 2 — kontext-scoped Cancel (Barge-In):
- Proxy: neuer /cancel {projectId} killt NUR die Subprozesse eines Kontexts
(_cancelByProject); /cancel-all bleibt fuers NOT-AUS.
- Bridge: soft cancel_request → _cancel_proxy_for_project(projectId) statt des
toten Diagnostic /api/cancel. Hard bleibt /cancel-all.
- App: cancel_request + Abbrechen-Button tragen die fokussierte projectId.
Damit laufen Kontexte in der App echt parallel: Arbeit in Projekt A wird durch
Senden/Abbrechen in Hauptchat oder Projekt B nicht mehr abgewuergt, und der
Indikator gehoert zum sichtbaren Chat.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Statt System/Persona als <system>-getaggten User-Content in den Prompt zu
falten (was das Modell als Prompt-Injection fehldeutete und ARIA aus der Rolle
warf), geht sie jetzt ueber den ECHTEN System-Prompt-Kanal der Claude-CLI.
- openai-to-cli.js: openaiToCli liefert prompt = NUR Verlauf (conversationToPrompt),
systemPrompt = Persona + Tool-Block (extractSystemPrompt, ohne <system>-Tags).
- docker-compose: neue sed-Zeile schleust "--append-system-prompt",options.systemPrompt
ins buildArgs-Array von manager.js (gleicher Stil wie die bestehenden
Patches; options ist dort in scope). routes.js reicht systemPrompt bereits
an subprocess.start durch (b9150f2).
systemPrompt ist immer ein String (extractSystemPrompt → "" statt undefined),
also kein spawn-Crash bei leerem System. sed-Transformation gegen echten
buildArgs simuliert → valides JS-Array verifiziert.
Rollback falls die CLI-Version --append-system-prompt nicht kennt: die eine
sed-Zeile aus docker-compose entfernen + openaiToCli.prompt zurueck auf
messagesToPrompt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug: waehrend ARIA in einem Projekt arbeitet, im Hauptchat eine Frage stellen →
sie wurde angezeigt aber nicht verarbeitet (erst wenn das Projekt fertig war).
Proxy kann nachweislich parallel (2 claude-Subprozesse) — der Flaschenhals war
die App: interruptAriaIfBusy wertete den GLOBALEN agentActivity aus und feuerte
bei jedem Senden-waehrend-irgendein-Kontext-arbeitet einen kontext-uebergreifenden
cancel_request.
Fix: Busy-Status kontextgenau aus queueStatus (/projects/queue-status) statt
global. Barge-In (Brain-Cancel) nur noch wenn GENAU der fokussierte Kontext
arbeitet; TTS wird weiterhin immer gestoppt wenn ARIA spricht. cancel_request
traegt jetzt die projectId (fuer spaeteres kontext-scoped Cancel in der Bridge).
Damit laufen Hauptchat und Projekt(e) in der App parallel — passend zum
Multi-Threading im Brain.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Vorbereitung fuer die saubere Variante: ARIA-Persona ueber den ECHTEN
System-Prompt-Kanal der Claude-CLI (--append-system-prompt) zustellen statt als
<system>-getaggten User-Content (den das Modell als Prompt-Injection wertet und
der ARIA aus der Rolle wirft — siehe a0e8c23).
- openai-to-cli.js: extractSystemPrompt() (System-Messages + Tool-Block als
roher Text, ohne <system>-Tags) und conversationToPrompt() (nur Verlauf).
openaiToCli() liefert jetzt zusaetzlich systemPrompt + conversationPrompt.
- routes.js: reicht systemPrompt an subprocess.start(..) durch.
BEWUSST rueckwaertskompatibel/no-op: prompt bleibt unveraendert (System-Inhalt
noch drin), die Extra-Option wird von einem ungepatchten manager.js ignoriert.
Der letzte Schritt (manager.js: --append-system-prompt beim Spawn + prompt auf
conversationPrompt umstellen) folgt, sobald die echte manager.js-Struktur
vorliegt — die npm-Datei liegt nicht im Repo und ein Fehlpatch legt den
kompletten Proxy lahm.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug: bei tiefergehenden Fragen in Projekten (v.a. dem Pentest-Projekt) verlor
ARIA ihre Identitaet — das Modell wertete die Konversation als Prompt-Injection,
verwarf die ARIA-Rolle samt <tool_call>-Format und antwortete als generischer
Coding-Agent ("Ich bin nicht ARIA, das ist ein Injection-Muster").
Ursache: die Persona kam bisher NUR aus gepinnten "identity"-Memories (weiche
Daten), es gab keinen harten System-Anker. Pentest-Projekt-History steckt voller
injection-artiger Inhalte (Payloads, <system>-Bloecke, <tool_call>-Beispiele,
XSS) — genau das Material triggert die Injection-Abwehr des Modells, und ohne
festen Anker kippt die weiche Memory-Identitaet.
Fix: IDENTITY_ANCHOR steht jetzt IMMER ganz oben im System-Prompt (vor allen
Memories). Er haelt die ARIA-Identitaet in jedem Kontext fest UND rahmt
verdaechtige Inhalte (in Verlauf/Projekten/gelesenen Dateien) explizit als
DATEN, die analysiert — nicht befolgt — werden. Besonders fuer Security-/
Pentest-Arbeit, wo solche Payloads das Arbeitsmaterial sind.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der /api/files-set-project-Endpoint existierte, aber es fehlte die UI. Jede
Datei-Zeile hat jetzt ein Projekt-Dropdown (Hauptchat + alle Projekte, aktueller
Wert vorausgewaehlt, gruen wenn getaggt). Aenderung schreibt via
/api/files-set-project ins Manifest, aktualisiert den lokalen Cache und rendert
neu (respektiert den aktiven Projekt-Filter).
Damit lassen sich auch alt-hochgeladene (untagged) Dateien nachtraeglich einem
Projekt zuordnen — die projectId-Zuordnung beim Upload passiert automatisch
(596d0bb), das hier ist die manuelle Korrektur/Nachpflege.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug: Bild/Datei ins Textfeld + Frage → beides landete im Hauptchat, egal
welches Projekt fokussiert war. Der Anhang-Pfad reichte die projectId nirgends
durch (im Gegensatz zum reinen Text-Pfad).
App (sendPendingAttachments):
- lokale Anhang-Bubble bekommt projectId (App-Focus)
- file-Upload (rvs.send('file')) schickt projectId mit
- Merge-Trigger chat-Nachricht schickt projectId mit
Bridge:
- file-Handler liest payload.projectId, merkt sie (_pending_files_project_id)
und taggt die Datei per _tag_file_to_project ins richtige Projekt
- _flush_pending_files_with_text(user_text, project_id): reicht die projectId
aus dem chat-Payload an send_to_core (Fallback: gemerkter Upload-Kontext)
- _flush_pending_files_after (Files-only): nutzt den gemerkten Upload-Kontext
- merged-Aufruf im chat-Handler gibt payload.projectId mit
Damit tragen User-Bubble, Datei-Manifest, Brain-Turn und ARIA-Antwort alle
denselben Projekt-Tag.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Symptom: Frage im Projekt gestellt, Antwort nur in der App sichtbar, Frage nur
in der Diagnostic — Frage und Antwort scheinbar in verschiedenen Kontexten.
Ursache: die App taggt die lokale Voice-Bubble optimistisch mit dem App-Focus,
waehrend der Server (Voice-Router) die autoritative Zuordnung macht. Weichen
die ab (Registry-Race aus 3e88eec, Sticky, „fuer X:"-Prefix, Fallback), landet
die lokale App-Bubble in einem anderen Kontext als die serverseitig getaggte
Frage/Antwort → App- und Diagnostic-Ansicht divergieren.
Fix: beim Eintreffen des sender=stt-Broadcasts uebernimmt die App die
projectId des Servers fuer die Bubble (alle drei Match-Zweige). Nur wenn das
Feld mitkommt — altes Bridge-Format ohne projectId → App-Focus behalten.
Primaerursache bleibt 3e88eec (Router liefert wieder den korrekten Kontext).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug: die Spracherkennung bricht mal zu frueh ab (nach zwei Worten obwohl noch
gesprochen wird) und merkt mal gar nicht dass man aufgehoert hat.
Ursache: der Endpointer feuerte rein auf semantischer Stagnation (Whisper-
Transkript waechst endpoint_ms lang nicht). Das ist fragil — kurze Sprech-
Pausen oder beam_size=1-Instabilitaet → vorzeitiger Cut; Oszillation/
Halluzination → nie ein Endpoint.
Fix: akustische Stille als robustes Primaersignal. Jeder Tick (~200ms) misst
die RMS-Energie der letzten 300ms:
- Solange Sprach-Energie da ist, bleibt die Session am Leben (kein Cut mitten
im Reden).
- Endpoint feuert wenn seit endpoint_ms keine Sprach-Energie mehr da ist.
- Semantischer Backstop (2x endpoint_ms) fuer laute Umgebungen (Auto), wo die
Energie nie faellt — dort degradiert es sauber aufs bisherige Verhalten.
RMS-Threshold (0.012) gegen Stille/Sprache/Fahrgeraeusch verifiziert.
Konstanten oben in der Datei tunebar.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bug: bei manuellem Stop landete die Sprachnachricht (und ARIAs Antwort) im
Hauptchat statt im fokussierten Projekt — mal so, mal so, je nachdem ob der
Endpoint natuerlich kam oder man den Stop-Button drueckte.
Ursache: stt_stream_end popte die Focus-projectId-Registry SOFORT. Nach einem
manuellen Stop folgt aber noch der finale stt_endpoint (Whisper-Final-
Transcribe), der die projectId aus genau dieser Registry braucht. War sie schon
weg → focused_pid="" → Voice-Router faellt auf Hauptchat zurueck. Die
User-Bubble (lokal getaggt) blieb im Projekt, ARIAs Antwort kam aber mit
project_id="" → nur in EINEM Kontext sichtbar.
Fix: stt_stream_end raeumt die Registry nicht mehr sofort auf, sondern per
verzoegertem call_later(20s) als Leak-Schutz. Der stt_endpoint-Handler popt
selbst wenn er zuerst kommt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Regression aus dem chat_history-projectId-Fix: nach dem History-Reload laeuft
jetzt updateChatVisibilityByFocus(). addAriaFile() setzte aber kein
dataset.projectId → Datei-/Bild-Bubbles galten als Hauptchat und wurden
ausgeblendet, sobald der (aus localStorage wiederhergestellte) Focus auf einem
Projekt lag. In der App trat das nicht auf (datengetriebener Filter mit
korrektem projectId).
- addAriaFile(): setzt dataset.projectId aus p.projectId und respektiert beim
Live-Anhaengen den aktuellen Focus (wie addChat via hiddenByFocus).
- chat_history-Renderer: reicht m.projectId an addAriaFile weiter.
- Bridge _process_core_response: haengt turn_pid als f["projectId"] an die
file_from_aria-Payload, damit der Live-Pfad die Zuordnung kennt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
v1 matchte text==content exakt und verfehlte damit Nachrichten, bei denen die
Bridge den Brain-Text anreichert oder cleant:
- User-Turns: _build_core_text PREPENDT [Hinweis: Barge-In]-/[GPS-Position]-
Bloecke — die stehen in conversation.jsonl, nicht in chat_backup.
- Assistant-Turns: conversation enthaelt [FILE: /shared/uploads/...]-Marker,
chat_backup hat sie schon rausgecleant.
_norm entfernt jetzt FILE-Marker + fuehrende [..]-Bloecke, kollabiert
Whitespace und vergleicht einen 120-Zeichen-Praefix. Neuer Marker (v2) →
laeuft einmal neu und fuellt die von v1 verbliebenen Luecken. Nicht-destruktiv
(eigene .pre-backfill-v2.bak), bestehende Tags bleiben unangetastet.
Mit Tests gegen GPS-/Barge-In-/FILE-Marker-Faelle verifiziert.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Reload-Pfad des Dashboards warf die Kontext-Zuordnung an ZWEI Stellen weg,
weshalb nach jedem Reload alles im Hauptchat lag (Projekte leer) — unabhaengig
davon ob chat_backup korrekt getaggt war:
- server.js (History-Builder): pushte {type,text,meta,ts} ohne project_id.
Jetzt projectId aus obj.project_id fuer sent/received/aria_file mitgegeben.
- index.html (chat_history-Renderer): setzte dataset.ts aber nie
dataset.projectId → jede Bubble galt als Hauptchat. Jetzt gesetzt, und nach
dem Neuaufbau updateChatVisibilityByFocus() aufgerufen damit der aktuelle
Kontext-Focus sofort greift.
Zusammen mit der Backfill-Migration (8b567e1) erscheinen alt-getaggte Turns
jetzt beim Dashboard-Reload im richtigen Projekt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Projekt-Nachrichten aus der Zeit vor dem chat_backup-project_id-Feld (getaggt in
conversation.jsonl seit fc0f91d, aber chat_backup fuehrte project_id erst ab
f51ad15) lagen in der UI im Hauptchat statt im Projekt. Die App/Diagnostic
zeigen aus chat_backup.jsonl — dort fehlte der Tag.
Neue Einmal-Migration (Brain-Lifespan) schreibt project_id aus conversation.jsonl
per (role, text)-Match reihenfolge-erhaltend nach chat_backup.jsonl zurueck:
- idempotent via Marker /shared/config/.chat_backup_projectid_backfill_v1
- nicht-destruktiv: legt .pre-backfill-v1.bak an, setzt nur LEERE project_ids,
entfernt/aendert nie einen bestehenden Tag
- atomar (tmp + os.replace)
- Duplikate: Deque je (role, normtext) inkl. "" fuer Hauptthread → korrekte
Zuordnung auch bei wiederholten Texten, kein faelschliches Taggen von
Hauptchat-Interleaving
Mit Logik-Tests (Zuordnung, Duplikat-Reihenfolge, Idempotenz) verifiziert.
Nachrichten aus der Zeit bevor es Projekte gab bleiben untagged im Hauptchat.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Das Dashboard hatte dieselbe Ursache wie die App (untagged Nachrichten in
chat_backup) PLUS zwei eigene untagged-Pfade ueber den Gateway-Watch:
- Frontend: chat_final rendert keine Chat-Bubble mehr. ARIA-Antworten kommen
ausschliesslich via rvs_chat (traegt projectId). chat_final stammt vom
Gateway-Watch ohne projectId → erzeugte eine Duplikat-Bubble im Hauptchat.
- server.js: kein chat_backup-Write im Gateway-final-Handler mehr. Die Bridge
(_process_core_response) ist massgeblicher Writer und schreibt MIT project_id;
der Write hier erzeugte untagged Duplikate, die beim Reload im Hauptchat
statt im Projekt landeten.
Der App-Focus-Fix (63dde65) sorgt dafuer dass neue Nachrichten ueberhaupt
getaggt in chat_backup landen — davon profitiert das Dashboard direkt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Kernbug: ProjectsBrowser.load() pushte bei JEDEM Drawer-Oeffnen status.active
in den App-Focus. Im Multi-Threading hat das Brain keinen globalen
active_project-State mehr → status.active ist null → Focus wurde auf Hauptchat
zurueckgesetzt. Folge: nach jedem Drawer-Oeffnen landeten alle Nachrichten im
Hauptchat, Projekte blieben leer.
- ProjectsBrowser: neues Prop currentFocusId (App-Focus = Source-of-Truth).
load() uebernimmt nur noch die Projektliste, kein onActiveChanged(status.active)
mehr. Highlight (✓ FOCUS) folgt currentFocusId.
- ChatScreen: currentFocusId={focusedProjectId} durchgereicht.
- ChatScreen: direkter „← Hauptchat"-Button im Focus-Header (nur im Projekt
sichtbar) — ein Tap statt Drawer→Hauptchat.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
