Das Zugangsdaten-Formular war beim erneuten Oeffnen leer, obwohl der
Satellit alles gespeichert hatte.
Satellit:
- sat_creds_list mit ip liefert je Typ die Felder ohne Geheimnisse
(Benutzer, Port, SNMP-Version/v3-Stufe) und has_<feld> fuer Passwoerter;
mit reveal (nur zusammen mit ip) auch die Geheimnisse dieses Geraets.
- sat_creds_set behaelt ein gespeichertes Geheimnis, wenn das Feld nicht
mitgeschickt wird — Benutzer aendern, ohne das Passwort neu zu tippen.
Diagnostic-Server: Antworten mit Klartext (revealed) gehen nur an den
Browser, der gefragt hat, nicht an alle offenen Tabs.
Formular: Benutzer/Port/Version stehen beim Oeffnen drin, Passwoerter als
"•••••• gespeichert"; 👁 holt sie im Klartext bzw. schaltet um. Leeres
Passwortfeld = gespeichertes behalten. FritzBox: "Benutzer ermitteln"
(nur bei als FritzBox erkannten Geraeten) liest login_sid.lua?version=2 —
die Box nennt ihre Benutzer ohne Anmeldung; eingetragen wird der zuletzt
angemeldete.
Getestet: Satelliten-Logik per Unit-Test, Formular in headless Chromium
(Anzeige, Speichern ohne Passwort, Auge, Benutzer ermitteln).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Katalog: "Laden" heisst jetzt "Download + Laden", daneben "Nur downloaden":
das Modell kommt auf die Platte der Box (aus der Ziel-Karten-Auswahl), in
keine Karte. Liegt es schon dort, ein Hinweis statt Download.
llm-adapter: llm_provision_model mit downloadOnly → _download_only:
Dateiliste, Plattenpruefung, paralleler Download (strict: ohne Fallback auf
llama.cpp, jeder Fehler kommt als Grund zurueck), keine Karte, keine
Registry. Download-Fenster: "Heruntergeladen — liegt auf der Box".
Karten-Modellwahl: Haken "nur heruntergeladene" in der Liste, Standard an.
Zeigt nur, was schon auf dieser Box liegt; "— leer —" und die aktuelle
Auswahl bleiben immer sichtbar. Meldet die Box keine Platte (alter
Adapter), ist der Haken aus und gesperrt.
Getestet: download-only gegen HuggingFace (tiny-llamas) und mit falschem
Repo; Haken/Suche/Knoepfe in headless Chromium mit der echten Seite.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
llm-adapter:
- Paralleler Download: llama.cpp zieht ueber EINE Verbindung (oft 1-50 MB/s,
auch bei 1 Gbit). Die Box holt fehlende Dateien jetzt vorher selbst in
64-MB-Stuecken ueber LLM_DOWNLOAD_CONNECTIONS (Standard 8) Verbindungen,
prueft die sha256 und legt sie im HF-Cache-Layout ab, das llama.cpp selbst
benutzt (blobs/<sha256>, snapshots/<commit>/<datei>, refs/main). Die Karte
bleibt waehrenddessen beim alten Modell. Scheitert es, laedt llama.cpp wie
bisher selbst. Fortschritt zaehlt bei sparse-Dateien nur geschriebene Bytes.
- Abbrechen: llm_remove_model mit cancel=true (kein neuer Typ → RVS-Allow-List
unveraendert). Waehrend des Downloads: Stopp + halbe Datei weg, Karte
unveraendert. Waehrend llama.cpp laedt: wie ein Fehlschlag → Karte zurueck.
Laeuft nichts mehr, schliesst die Antwort den haengenden Eintrag.
- Loeschen: llm_remove_model mit deleteFiles=true entfernt das Repo aus dem
Cache — nicht, solange es auf einer Karte liegt oder geladen wird.
- worker_hello meldet "disk": freier Platz + heruntergeladene Modelle je Repo.
Diagnostic: Abbrechen-Knopf je laufendem Download; im Katalog "auf ki-box ·
18,6 GB" mit Loeschen-Knopf und eine Zeile mit dem freien Platz je Box.
Getestet gegen HuggingFace (ggml-org/tiny-llamas, 4 Verbindungen, 2-MB-
Stuecke: Layout + Pruefsumme + Abbruch) und Loeschen inkl. Sperren.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bei MoE-Modellen (z.B. Qwen3-Coder-30B-A3B: 18,6 GB, davon 16,35 GB
Experten) rechnet pro Wort nur ein kleiner Teil. llama.cpp kann die
Experten in den RAM legen (--cpu-moe / --n-cpu-moe N), der Rest bleibt auf
der Karte.
Adapter:
- Registry-Feld cpuMoe: 0 = Karte, -1 = alle Experten in den RAM,
N = die der ersten N Schichten; -2 beim Laden = automatisch aufteilen.
- Automatisch: liest nur den Kopf der GGUF bei HuggingFace (HTTP-Range,
Tensor-Verzeichnis), rechnet Experten je Schicht + KV-Cache gegen den
VRAM der Karte und legt so viele Experten auf die Karte wie passen
(12 GB/32k: 16 von 48 Schichten auf der Karte, 32 im RAM).
- Kontext-Auswahl: GB-Schaetzung fuer die Karte ohne ausgelagerte Experten;
slot meldet moe, cpuMoe, ramMB. KV-Rechnung als _kv_bytes() geteilt.
Diagnostic: MoE-Modell zu gross fuer die Karte → Rueckfrage "Experten
automatisch aufteilen?"; pro Karte Auswahl Experten: Karte / automatisch /
Arbeitsspeicher. Kontextwechsel rechnet die Aufteilung neu.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Was ARIA selbst im Proxy ausfuehrt (Bash/ssh, Read, Edit …), war nur live
sichtbar — ob sie fuer "auf Prod nachgesehen" wirklich nachgesehen hat (und
wo), liess sich hinterher nicht pruefen. Das Befehlslog gab es nur fuer die
Host-Agenten.
Proxy (proxy-patches/routes.js): start/tool_use/tool_result/end zusaetzlich
dauerhaft nach /shared/logs/aria-tools/<tag>.jsonl (30 Tage), Passwoerter,
Tokens, API-Keys, private Schluessel und Zugangsdaten in URLs geschwaerzt.
Diagnostic: 🔍 an jeder ARIA-Bubble → alle Werkzeug-Aufrufe zwischen Stefans
Frage und dieser Antwort (Befehl + Ausgabe). Hat sie nichts ausgefuehrt,
sagt das Fenster es deutlich (Stand kommt dann aus Verlauf/Gedaechtnis).
GET /api/aria-proof?ts=&project=.
Deploy: proxy --force-recreate (Patch wirkt nur beim Start), diagnostic --build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modell-Katalog → "🏆 Bestenlisten": Fenster mit laufend gepflegten
Ranglisten nach Kategorie (Allgemein, Programmieren, Bilder erzeugen,
Lokal/Community — Arena, Artificial Analysis, LiveBench, Aider, SWE-bench,
Vellum, r/LocalLLaMA, HF), darunter "Gerade im Trend auf HuggingFace" pro
Kategorie (Allgemein / Programmieren / Bilder verstehen): nur Repos mit
ladbarem GGUF, echte Groesse + Quantisierung, "passt / zu gross" gegen die
groesste LLM-Karte, standardmaessig nur bekannte Anbieter (Trend != gut).
"In Katalog" uebernimmt das Repo; geladen wird wie gewohnt im Katalog.
Server: GET /api/llm-discover (HF trendingScore, 30 min Cache),
POST /api/llm-catalog/add.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Einstellungen, zwischen Runtime-Konfiguration und App-Onboarding: alle
Verbindungen im Raum des konfigurierten Tokens — Art, Name, Details,
Adresse, verbunden seit, zuletzt aktiv.
RVS merkt sich pro Verbindung, wer sie ist: aus Nachrichten, die ohnehin
fliessen (sat_hello, host_hello, worker_hello, update_check der App,
llm_cluster_*), oder aus dem neuen client_hello (Bridge, Diagnostic, App
mit Geraetename). Adresse aus X-Forwarded-For hinter einem Reverse-Proxy.
room_clients_query liefert NUR den eigenen Raum; room_clients von Clients
wird nicht weitergereicht. Typen in der Allow-List ergaenzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Bridge schrieb beim Config-Broadcast den kompletten Payload ins Log,
inklusive huggingfaceToken. Jetzt werden Werte von Schluesseln wie token,
secret, passw, apikey, credential als *** ausgegeben (Zaehler wie maxTokens
bleiben sichtbar). Dasselbe fuer das Debug-Log der RVS-Nachrichten in der
Diagnostic.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1. "Die LLM-Box meldet noch keine Karten": die Box schickte die Karten-
Belegung, aber workerList() im Diagnostic-Server gibt nur eine feste
Feldliste an den Browser — slots stand nicht drauf. Meine UI-Tests haben
die Flotte direkt im Browser gesetzt und sind an genau dieser Stelle
vorbeigelaufen. Jetzt Ende-zu-Ende getestet: echter Diagnostic-Server +
RVS + Box-Meldung → Browser (per DevTools-Protokoll gelesen).
2. Lokales Modell sprang auf "Qwen3 8B" zurueck: die Auswahl wurde gespeichert,
aber die Seite behielt intern das alte Modell und stellte das Dropdown beim
naechsten Lebenszeichen der Box (10 s) darauf zurueck. Dazu wie gewuenscht
umgebaut: nur Modelle, die im Cluster geladen sind, jedes einmal, ohne
Karte. Ist das gewaehlte gerade nirgends geladen: "(offline)" — geht
automatisch weiter, sobald eine Box es hat. Nichts da: "kein Modell
verfuegbar". Waehrend die Auswahl offen ist, wird nicht umgebaut.
3. "Bereit", aber Karte leer: der llm-adapter meldet pro Karte den belegten
VRAM. Laeuft ein Modell "ready" und die Karte bleibt unter 400 MB, rechnet
llama.cpp auf der CPU (Treiber zu alt fuer das CUDA im Image) — das sagt
llama.cpp nicht nach aussen. Diagnostic zeigt es jetzt in Flotte,
LLM-Karten und Modell-Auswahl ("laeuft auf der CPU").
4. bootstrap.sh: der normale Lauf meldete "✓ Treiber aktiv", auch wenn er fuer
das LLM zu alt ist. Jetzt Warnung mit Version und dem Befehl
(--upgrade-driver), wenn das LLM-Profil aktiv ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Laden von unsloth/gemma-4-12B-it-qat-GGUF scheiterte mit "500": der Katalog
trug pauschal Q4_K_M ein, das Repo hat aber nur UD-Q4_K_XL. llama-server fand
die Datei nicht und beendete sich sofort; llama-swap reicht den Grund nicht
weiter ("upstream command exited prematurely"), es kam nur "500" an.
llm-adapter: fragt vor dem Laden die Dateiliste des Repos ab. Gibt es die
gewuenschte Quantisierung nicht, nimmt er die naechstbeste aus einer festen
Reihenfolge (Q4_K_M, UD-Q4_K_XL, Q4_K_XL, Q4_K_S, IQ4_XS, …) und sagt das im
Download-Fenster an. Kein ladbares GGUF im Repo → sofortige Absage, die Karte
bleibt unberuehrt. Bild-Projektor (mmproj), MTP-Zusatzdateien und imatrix
zaehlen nicht als Modell. Endet llama-server trotzdem sofort, nennt die
Meldung die haeufigsten Gruende statt nur "500".
Diagnostic: "Von HuggingFace aktualisieren" traegt pro HF-Repo die tatsaechlich
vorhandene Quantisierung und die echte Groesse ein (bisher 0 GB) — auch bei
schon vorhandenen HF-Eintraegen. Repos ohne ladbares Modell kommen nicht mehr
in den Katalog bzw. werden als "nicht ladbar" markiert. Katalog zeigt die
Quantisierung pro Modell.
Gemma 4 selbst: llama.cpp kann es seit Juni (#24077), der Stand auf der Box ist
vom 14.08. — es lag nur an der Datei.
Getestet gegen echte HF-Repos (Gemma → UD-Q4_K_XL 6,7 GB, Qwen/Mistral bleiben
Q4_K_M) in Adapter und Diagnostic identisch, und gegen llama-swap: Ausweichen
angesagt + geladen; Repo ohne GGUF → Absage ohne Download.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher konnte jeder Client per Modellname llama-swap zum Wechseln bringen —
ein Fremdprogramm haette ARIA das Modell unter den Fuessen weggetauscht.
Jetzt:
- Jede LLM-Karte einer Box (LLM_GPUS=1,2, alt LLM_GPU=1) haelt GENAU ein
Modell, dauerhaft. Welches, legt nur die Diagnostic fest. Karten, die nicht
fuers LLM vorgesehen sind, tauchen beim LLM nicht auf und werden als Ziel
abgelehnt.
- Clients (ARIA, Fremdprogramme ueber RVS, OpenHands ueber den OpenAI-Port)
sehen nur die geladenen Modelle und laden nie: Anfrage fuer ein anderes →
model_not_loaded mit Liste des Geladenen (RVS) bzw. HTTP 404 (OpenAI-Port).
Nichts wird verdraengt.
- Mehrere Clients koennen dasselbe Modell gleichzeitig nutzen.
llm-adapter: Belegung in /models/aria_slots.json. Die llama-swap-Config
enthaelt nur belegte Karten: pro Modell CUDA_VISIBLE_DEVICES=<Karte>, ttl 0,
groups.swap=false, hooks.on_startup.preload. Alles gegen llama-swap
ausprobiert (zwei Modelle gleichzeitig ready, keins verdraengt, Unbekanntes
404, env kommt beim jeweiligen llama-server an). llama-swap laeuft mit
--watch-config; die frueher aufgerufenen Reload-Endpunkte (/reload,
/api/config/reload) gibt es nicht (404). Neu: llm_unload_model (Karte leeren),
llm_models_request → llm_models (Erkundung, jede Box antwortet einzeln).
Fehlgeschlagenes Laden setzt die Karte auf ihr vorheriges Modell zurueck,
sonst risse jedes Neuladen die anderen Karten mit. Uebernahme: ohne
Belegungsdatei landet LLM_MODEL auf der ersten LLM-Karte.
Compose: llama-swap sieht alle Karten (NVIDIA_VISIBLE_DEVICES=all) und
zaehlt sie wie nvidia-smi (CUDA_DEVICE_ORDER=PCI_BUS_ID); das Pinnen pro
Modell macht der Adapter.
Bridge: uebernimmt models/slots auch aus worker_ping (nach "Entladen" sonst
30 s veraltet) und sagt sofort ab, wenn das Modell auf keiner Box liegt,
statt per Broadcast in den Timeout zu laufen.
Diagnostic: Flotte zeigt pro LLM-Karte Modell + Zustand + "Entladen";
Katalog waehlt eine Ziel-KARTE (leere vorausgewaehlt, Ersetzen mit
Rueckfrage); Download-Fenster nennt Karte und was ersetzt wird.
RVS: llm_unload_model, llm_models_request, llm_models freigegeben.
docs/LLM-SCHNITTSTELLE.md: Schnittstelle fuer Drittprogramme (RVS + OpenAI-
Port), Fehlercodes, Gleichzeitigkeit, Python-Beispiel.
Tests: 23 gegen llama-swap (Adapter direkt) + Ende-zu-Ende ueber den echten
RVS mit dem Adapter als Prozess: Laden per RVS mit Fortschritt, das
Doku-Beispiel unveraendert (nur Adresse) findet beide Karten und bekommt eine
Antwort, Absage/Schweigen wie dokumentiert, zwei Clients parallel.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Flotte listete "qwen3-4b, qwen3-8b" — das sind die Modelle, die die Box
fahren KANN (llama-swap /v1/models), nicht die geladenen. Ohne groups-Config
liegt immer nur eins in der Karte; ein anderes anzufragen entlaedt es
(gegen llama-swap ausprobiert: A laden, B anfragen → A unloaded).
Der Adapter fragt jetzt llama-swap /running und schickt das Ergebnis in jedem
worker_ping (10 s) und im worker_hello mit; nach einem Modellwechsel sofort.
None = llama-swap nicht erreichbar, [] = nichts geladen — die Anzeige
unterscheidet das ("geladen: ?" vs. "keins geladen").
Diagnostic: das geladene Modell gruen mit "● geladen", die anderen grau mit
Hinweis, dass sie beim ersten Aufruf laden und das geladene verdraengen.
"GPU void": die LLM-Zeile zeigt jetzt LLM_GPU (die Karte von llama-swap) statt
der NVIDIA_VISIBLE_DEVICES des Adapters, die mit der Modell-Karte nichts zu
tun hat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Eigentlicher Fehler zuerst: llm_provision_model/_result und llm_remove_model
standen nie in der RVS-Allow-List. Der RVS verwirft unbekannte Typen mit einem
stillen return — jeder Klick auf "Laden" im Modell-Katalog ist seit Stage D
(19.09.) an dieser Liste gestorben, die Box hat nie davon erfahren. Laden
liessen sich nur die Modelle aus der Basis-Config der Box.
Gefunden, weil grep rvs/server.js fuer eine Binaerdatei hielt und still
uebersprang: in Zeile 164 stand seit a7998bcd ein ECHTES Nullbyte im
Template-String statt eines Escapes. Node stoert das nicht, aber git zeigte
fuer jede Aenderung am RVS nur noch "Binary files differ". Jetzt \u0000 —
zur Laufzeit derselbe String.
Fortschritt: llama.cpp zieht das GGUF per -hf selbst und meldet nichts. Der
llm-adapter fragt vorab bei Hugging Face, welche Dateien (Groesse, sha256)
kommen, und misst genau diese im HF-Cache-Layout, das llama.cpp verwendet:
/models/models--org--repo/blobs/<sha256>.downloadInProgress (waechst)
/models/models--org--repo/blobs/<sha256> (fertig)
Layout gegen den echten llama.cpp-Server ausprobiert, nicht angenommen. Geht
auch bei gesplitteten Modellen und zwei Downloads gleichzeitig; Fallback fuer
aeltere Layouts ueber alle *.downloadInProgress. Phasen: queued → start →
download (%, MB/s, Restzeit) → load ("laedt in die Karte") → ready ("in Karte
N geladen", Name + VRAM aus nvidia-smi) bzw. error.
Mitgefixt: der Warmup wartete LLM_TIMEOUT_SEC (Default 60 s). Ein Modell mit
mehreren GB meldete deshalb "Fehler", waehrend llama-swap weiterlud. Jetzt
LLM_WARMUP_TIMEOUT_S (1900 s, ueber llama-swaps healthCheckTimeout).
Diagnostic: Knopf "⬇ Downloads" neben "Von HuggingFace aktualisieren" mit
Zaehler fuer laufende; "Laden" oeffnet das Fenster direkt. Der Server merkt
sich den Stand pro (Box, Modell), ein spaeter geoeffneter Tab sieht laufende
Downloads. Antwortet die Box nicht, steht nach 30 s eine Warnung da statt
nichts.
Compose (KI-Box): llm-adapter bekommt LLM_GPU (Karte fuer die Meldung) und
HF_TOKEN (Dateiliste gesperrter Repos).
Test: Fortschritt gegen einen echten llama.cpp-Download (Qwen2.5-0.5B Q8,
676 MB): Prozent steigend 0 → 91.6, dann load; zweiter Lauf aus dem Cache
direkt load mit cached=true.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
IMAP/SMTP mit SSL/TLS, STARTTLS oder unverschluesselt. Senden mit Text, HTML,
Anhaengen und eingebetteten Bildern (cid:), Antworten mit In-Reply-To. Lesen,
Suchen, Ordner anlegen (auch Unterordner), Mails verschieben.
Tools: email_status/send/list/read/folders/folder_create/move.
Whitelist als harte Grenze im Sendepfad, nicht im Prompt: alles, was nicht
drinsteht, ist gesperrt, leer = nirgendwohin. Jeder Empfaenger zaehlt (An, Cc,
Bcc), ein fremder blockiert die ganze Mail. Genau eine Schreibweise:
name@domain, '*' nur als *@domain, *@*.domain oder *@*. '*hacker-net.de' liest
sich, als passte es auf 'evilhacker-net.de' — solche Kurzformen lehnt das
Speichern mit Korrekturvorschlag ab. Verglichen wird die Domain als Ganzes.
Zugangsdaten sieht ARIA nie:
- liegen im Brain unter /data. NICHT in /shared — das ist in ARIAs Container
eingehaengt, /data nicht.
- keine Schnittstelle gibt das Passwort zurueck, nur password_set.
- Brain-Export laesst email_secret.json + email_admin.key aus (GNU- und
busybox-tar geprueft, der Diagnostic-Container ist Alpine).
- Anhangspfade nach realpath geprueft: ein Symlink in /shared/uploads auf die
Geheimnis-Datei wuerde sonst im Brain aufgeloest und verschickt.
- Konfiguration nur mit Admin-Schluessel (X-Aria-Admin, liegt in /data). Die
Diagnostic haengt ihn an, weist aber Anfragen aus ARIAs Container ab —
sonst koennte eine eingehende Mail sie per curl die Whitelist oeffnen lassen.
Grenze: ARIAs Container hat SSH auf die VM. Gegen einen gezielten Einbruch
schuetzt das nicht, nur dagegen, dass Zugangsdaten von selbst auftauchen.
Eingehende Mails sind fuer ARIA als Daten markiert, nicht als Anweisungen.
Diagnostic: Einstellungen → Integrationen → ARIA E-Mail, plus
"📬 Postfach oeffnen" — ARIAs ganzes Postfach in eigenem Fenster, Unterordner
eingerueckt, Posteingang + Gesendet oben. Nur lesend, markiert nichts als
gelesen. Mail-HTML in einem Rahmen ohne Skripte und ohne Nachladen von aussen
(kein Tracking-Pixel); eingebettete Bilder kommen als data: mit. Jede
gesendete Mail landet als Kopie in "Gesendet" — fehlt der Ordner, wird er
angelegt, statt die Kopie still zu verlieren.
Tests: 65 Einheitstests (Whitelist inkl. evilhacker-net.de, MIME-Aufbau,
Header-Injection, Symlink-Ausbruch, Geheimnis nie in Ausgaben) + 50 gegen einen
echten Mailserver (GreenMail): TLS-Login, Senden mit Anhang + Bild, Flags,
Suche mit Umlaut, Gesendet-Kopie, In-Reply-To, Ordner mit Umlaut, MOVE und
der Fallback ohne MOVE (der keine fremden geloeschten Mails mitreisst).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nach einem Sicherheitsfilter-Treffer fuhr ein Projekt still auf dem
Ausweich-Modell weiter, und nirgends war zu sehen, auf welchem. Zurueck ging
nur ueber "Liste leeren" im Filter-Panel, und das gleich fuer alle Chats.
Jetzt drei Ebenen (aria-brain/context_model.py):
Einstellung (brainModel) < pro Chat < Ausweich (Sicherheitsfilter)
- Pro Chat: Hauptchat und jedes Projekt koennen ein eigenes Modell haben, in
/shared/config/context_models.json. Bewusst kein Feld im Projekt-Manifest —
der Hauptchat ist kein Projekt und waere sonst aussen vor.
- "↩ zurueck" pro Chat: loescht nur die Filter-Vermerke DIESES Chats. Blockt
der Filter erneut, weicht das Brain eben wieder aus.
- Angezeigt wird, was wirklich laeuft: chat() gibt das Modell aus modelUsage
der CLI zurueck (aufgeloeste Version statt Alias) samt Grund; Brain → Bridge
→ chat_backup + Live-Payload → App und Diagnostic. Als Grundeinstellung
zaehlt das Modell, mit dem das Brain laeuft, nicht der Dateiwert — so faellt
ein ausstehender Neustart nach brainModel-Aenderung auf.
Diagnostic: 🧠-Auswahl neben "+ Projekt" fuer den fokussierten Chat, Modell im
Untertitel jeder Kontext-Karte, Modell statt "Claude" am Bubble-Badge (orange
mit ↪ bei Ausweich).
App: hinter der Quell-Anzeige (Einstellungen, Default aus — Kopfzeile bleibt
fuer Mama unveraendert) ein Modell-Chip in der Kopfzeile; Tippen oeffnet die
Auswahl fuer diesen Chat inkl. "Zurueck". Laeuft ueber den vorhandenen
brain_request-Kanal, also keine neuen RVS-Typen.
Tests: 47/47 (12 neue fuer die Aufloesungsreihenfolge gegen agent.chat()),
tsc ohne Fehler.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anthropics Filter ("safeguards flagged this message", Details: [cyber]) trifft
genau unsere Themen — Ports, Tunnel, Zugangsdaten. Bisher war danach der
Projekt-Chat tot, und zwar aus einem Grund, den man der Meldung nicht ansieht:
Der Filter meldet sich NICHT als HTTP-Fehler. Die CLI liefert ein voellig
normales Ergebnis mit is_error=true und dem Fehlertext im content — also dort,
wo sonst ARIAs Antwort steht. proxy_client.py warf das Flag weg, der Agent
konnte Fehler und Antwort nicht unterscheiden und schrieb den Text per
conversation.add("assistant", ...) in den Verlauf. Weil der Verlauf bei jedem
Turn mitgeht, scheiterte ab da JEDE weitere Frage an derselben Stelle.
Zwei Stufen dagegen (aria-brain/safeguard.py):
1. Modellwechsel. Der Filter haengt am Modell ("Opus 5's safeguards ..."),
Anthropic raet selbst zu "change your model". Derselbe Turn wird automatisch
mit dem Ausweich-Modell neu gefragt; laeuft der Rest des Turns (Tool-Schritte)
gleich mit darauf weiter. Der ausloesende Turn wird vermerkt, damit die
naechsten Turns nicht erst wieder gegen die Wand laufen. Der Vermerk
verfaellt von selbst, sobald der Turn aus dem Rolling Window gerollt ist —
nichts muss aufgeraeumt werden, und das Projekt faellt von allein aufs
Hauptmodell zurueck.
2. Quarantaene. Blockt auch das Ausweich-Modell, liegt es am Verlauf selbst.
Dann faellt der ausloesende Turn aus dem Prompt-Fenster. NICHT geloescht: er
bleibt in conversation.jsonl, steht mit Text in der Diagnostic und ist per
Klick zurueckholbar. Der rohe Fehlertext wird nie persistiert — ARIA sagt in
eigenen Worten, was passiert ist.
Der Zustand liegt in /data/safeguard.json, bewusst nicht in conversation.jsonl:
ein Markieren dort erzwaenge ein Rewrite, und das schreibt nur das In-Memory-
Window zurueck — alles schon Destillierte waere weg.
Erkennung bewusst zweistufig: mit is_error genuegt ein Marker, ohne muss der
Text mit "API Error" beginnen. Sonst wuerde eine Antwort, in der ARIA ueber den
Filter *spricht*, einen Modellwechsel ausloesen.
Mitgenommen:
- Das Memory-Destillat schickt denselben Verlauf nochmal durch und wurde
genauso blockiert — nur fiel es dort als "unparsbares JSON" auf und
wiederholte sich bei jedem Lauf. Weicht jetzt ebenfalls aus.
- clean_poisoned_turns.py raeumt die Altlasten: Fehlertexte, die vor diesem Fix
schon im Verlauf stehen. Neu auch in Projekten (dort sterben sie ja), mit dem
ausloesenden User-Turn desselben Kontexts, Dry-Run per Default.
- Diagnostic: Ausweich-Modell einstellbar (runtime.json, ohne Neustart, weil
safeguard.py erst im Ernstfall liest) und ein Panel, das zeigt was blockiert
wurde und ob es NOCH wirkt.
Tests: 35/35 fuer die Rettungskette gegen den echten agent.chat(), 16/16 fuer
das Aufraeum-Script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide hiessen bisher so, wie es in IHRER .env steht. Umbenennen hiess also: auf
den Rechner, Datei aendern, Dienst neu starten — beim Fire TV sogar neu
provisionieren. In der Oberflaeche gab es dafuer gar keinen Weg.
Jetzt ein ✎ pro Eintrag. Der Alias liegt zentral in
/shared/config/display_names.json ({"host": {...}, "satellite": {...}}) und
wirkt sofort fuer JEDEN schon ausgerollten Agenten, ohne ihn anzufassen.
Der entscheidende Teil ist die Rueckrichtung: die Bridge loest den Alias beim
ADRESSIEREN wieder auf (_resolve_host / _resolve_satellite). Ohne das haette man
etwas umbenennen koennen und es danach nicht mehr ansprechen — der Agent
vergleicht die Adresse gegen seine EIGENE Kennung und kennt den Alias nicht.
Angesprochen werden kann weiterhin alles: Alias, Eigenname oder technische ID.
Der Eigenname bleibt in der Liste klein daneben sichtbar, damit man den Bezug
zum Geraet nicht verliert. Leerer Name entfernt den Alias.
Diagnostic und Bridge teilen sich die Datei ueber /shared — kein neuer
Nachrichtentyp, keine Allow-List-Aenderung, eine Wahrheit.
Nebenbei behoben: _display_name_set legte fest "/shared/config" an, obwohl der
Dateipfad konfigurierbar ist. Damit scheiterte das Schreiben stillschweigend,
sobald der Pfad abwich. Verzeichnis wird jetzt aus dem Pfad abgeleitet.
17 Pruefungen: Aliasvergabe, Liste, Aufloesung in beide Richtungen,
Gross/Kleinschreibung, alter Name bleibt gueltig, anderer Agent unberuehrt,
beide Bereiche in einer Datei ohne sich zu stoeren, Entfernen, unbekanntes Ziel
wird nicht still umgebogen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Satellit laeuft auf einem ganz normalen Rechner — bei Stefan auf
duffy-desktop. Dort laufen typischerweise noch andere Dienste (FreeCAD-MCP,
Web-App, Dateiserver). Bisher war ausgerechnet dieser Rechner unsichtbar: man
findet sich nicht per mDNS/ARP selbst.
Er erscheint jetzt als normales Geraet — ansprechbar wie jedes andere, nur
zusaetzlich mit 🛰️ markiert und blau abgesetzt, damit klar ist, dass dort der
Satellit traegt. Abschaltbar ueber LIST_SELF=false, falls man den Traeger
bewusst heraushalten will.
Nebeneffekt, der ein echtes Problem loest: der eigene Rechner gilt damit als
"gefunden" und ist ohne Eintrag in TUNNEL_ALLOW tunnelbar. Genau der Fall, um
den es ging — der FreeCAD-MCP laeuft auf dem Satelliten-Host selbst.
Beim Zusammenfuehren bleibt die Markierung erhalten: findet mDNS denselben
Rechner nochmal, haette der Merge isSatellite sonst verschluckt. hostname kommt
aus demselben Grund mit in die erhaltenen Felder.
Dazu ein ✎-Knopf pro Geraet in der Diagnostic: Namen vergeben, damit ARIA
"duffy-desktop" ansprechen kann statt einer IP. Der Name haengt an der MAC und
ueberlebt einen DHCP-Wechsel.
8 Pruefungen: Selbst-Eintrag vollstaendig, Markierung ueberlebt den Merge,
mDNS-Infos bleiben erhalten, eigener Rechner ohne TUNNEL_ALLOW erlaubt, fremde
IP weiterhin blockiert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Proxy kopiert proxy-patches/*.js beim START ueber den npm-Code. Wer nach
einem git pull nur `restart` macht — oder neu startet, BEVOR der Pull durch ist
— laeuft still mit der alten Fassung weiter. Nichts deutet darauf hin: der
Container ist "Up", die Oberflaeche sieht normal aus, die Aenderung wirkt
einfach nicht.
Das hat heute zweimal Zeit gekostet: einmal wirkte ein Proxy-Fix nicht, einmal
blieb die Modell-Liste alt, obwohl der Code laengst gepullt war (Proxy
gestartet 08:51, Patches gepullt 09:28).
Die Einstellungen vergleichen jetzt die Zeitstempel der Quelldateien mit den
eingespielten und zeigen einen Hinweis samt fertigem Befehl — inklusive der
Angabe, welche Datei wann geaendert und wann eingespielt wurde. Toleranz 5s,
weil Quelle und Kopie beim Start kurz nacheinander entstehen. Ein Fehler beim
Pruefen loest bewusst KEINEN Alarm aus, sonst stuende dort eine Warnung, die
nichts ueber die Patches aussagt.
Dazu: der Datenschutz-Block sagt jetzt ausdruecklich, dass KEIN Neustart noetig
ist — die CLI liest ~/.claude/settings.json bei jedem Aufruf neu. Nur ein
gerade laufender Turn nutzt noch die alte Einstellung.
4 Pruefungen gegen den echten Container, in beide Richtungen: schweigt nach
frischem Start, erkennt eine veraltete Kopie samt Zeitstempeln, schweigt nach
Wiederherstellung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Kanaele, ueber die Claude Code zusaetzlich zur eigentlichen Anfrage Daten
verschickt — bisher nur per Hand in der docker-compose.yml abschaltbar, und
niemand konnte sehen, ob sie an sind:
DISABLE_ERROR_REPORTING Stacktraces an einen Fehler-Dienst. Bei Pro/Max ab
CLI 2.1.198 standardmaessig AN.
DISABLE_TELEMETRY Nutzungs-Metriken.
DISABLE_FEEDBACK_COMMAND /feedback sendet sonst die ganze Unterhaltung
inkl. Code — 5 Jahre Aufbewahrung.
Gesetzt wird in ~/.claude/settings.json unter "env". Die Datei ist in den
Proxy-Container gemountet, die Diagnostic erreicht sie ueber den vorhandenen
dockerExec — also kein Anfassen der docker-compose.yml und KEIN Neustart: die
CLI liest die Datei pro Aufruf.
Geprueft wird beides: was in settings.json steht UND was im Prozess wirklich
ankommt. Eine echte Container-Umgebungsvariable gewinnt gegen settings.json —
so ein Eintrag wird darum als "per docker-compose gesetzt" angezeigt und der
Haken gesperrt, statt eine Einstellung anzubieten, die nichts tut.
Geschrieben wird atomar (temp + mv) und nur der env-Block angefasst; bestehende
Einstellungen (tui, theme) bleiben. Sind alle drei abgewaehlt, verschwindet der
env-Block wieder ganz.
Der Hinweis im Panel sagt ausdruecklich, dass das NICHT die Trainings-
Einstellung ist — die steht im Anthropic-Konto und laesst sich hier nicht
umstellen. Link dorthin ist daneben.
12 Pruefungen gegen den echten Proxy-Container: lesen, setzen, Teilmengen,
JSON-Integritaet, Erhalt bestehender Werte, CLI laeuft damit, Abwaehlen raeumt
auf, Ausgangszustand wiederhergestellt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher liess sich nicht nachsehen, ob eine Modell-Einstellung ueberhaupt
greift. Der Proxy hat die Information sogar aktiv weggeworfen:
normalizeModelName() nahm den echten Namen aus modelUsage (z.B.
"claude-opus-5-5") und schrieb ihn auf "claude-opus-4" um. Das `model`-Feld
der Antwort log also — und damit war jede Ueberpruefung unmoeglich.
- normalizeModelName gibt den echten Namen durch. Im OpenAI-Protokoll soll
`model` das Modell nennen, das geantwortet HAT; ein erfundener Name ist
schlechter als keiner.
- Zusatzfelder aria_model / aria_error / aria_context_window / aria_max_output
aus modelUsage.canonicalModel. Noetig, weil die CLI bei einem unbekannten
Modell gar nicht bis zum Call kommt und ihre Begruendung einfach in den
Antworttext legt — ohne Flag waere ein Fehlschlag nicht von einer Antwort
zu unterscheiden.
- Knopf "🔬 Testen" neben Dropdown und Freitextfeld. Er schickt eine echte
Mini-Anfrage durch den GANZEN Weg (Diagnostic → Proxy → extractModel →
claude CLI → Anthropic).
Ausdruecklich NICHT gemacht: das Modell nach seiner eigenen Version fragen.
Darauf ist kein Verlass — Modelle kennen ihren Versionsstring oft nicht und
raten. Und den Dropdown-Wert zurueckzugeben waere sinnlos. Die Wahrheit kommt
aus modelUsage der CLI.
Vier unterscheidbare Ergebnisse:
Tier-Alias gruen — zeigt die aufgeloeste Version ("opus" → Opus 5.5)
exakte Version gruen — angefragt == geantwortet
nicht erkannt GELB — der Proxy hat still "opus" eingesetzt; warnt
ausdruecklich davor, die ID so zu setzen
ungueltig ROT — CLI-Begruendung im Klartext
Der gelbe Fall war wichtig: ein Name, der nicht wie ein Claude-Modell aussieht,
faellt auf "opus" zurueck und haette sonst als Erfolg gegolten — man setzt dann
eine ID, die nie benutzt wird, und merkt es nie.
Geprueft gegen ECHTE CLI-Ausgaben aus dem Proxy-Container (9 Faelle: Alias,
exakte Version, Tippfehler) plus 7 Faelle fuer die Anzeige-Logik. Nebenbefund:
`--model opus` loest derzeit auf claude-opus-5-5 auf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Fehler. Der zweite war der schlimmere.
1) Die Liste war handgepflegt und damit garantiert veraltet.
Sie kannte "Opus (aktuell: Opus 5)" — waehrend es laengst Opus 5.5,
Sonnet 5.5 und Fable 5.1 gab. Der Knopf "↻ Aktualisieren" las nur eine
lokale Datei neu und aktualisierte damit gar nichts.
Jetzt kommt die Liste aus Anthropics eigenem Modell-Katalog
(downloads.claude.ai/model-catalog/v1/catalog.json, Surface 'cc') —
dieselbe Quelle, aus der sich Claude Code selbst bedient. Oeffentlich,
ohne API-Key (die Models-API braucht einen; mit dem Max-Abo gibt es keinen).
6h-Cache plus Datei-Cache, der auch offline und bei abgelaufenem TTL
einspringt: eine etwas alte echte Liste ist besser als keine.
Die Tier-Aliase (opus/sonnet/haiku/fable) bleiben vorne und bleiben die
Empfehlung — sie folgen automatisch der neuesten Version. Darunter die
exakten Versionen, aeltere ausdruecklich als solche markiert.
2) Eine feste Version liess sich faktisch nicht waehlen.
extractModel() hatte eine MODEL_MAP und fiel fuer alles Unbekannte STILL
auf "opus" zurueck. Wer "claude-opus-5-5" setzte, bekam ohne jede Meldung
das Tier-Default. Schlimmer noch: claude-opus-5 und claude-fable-5 standen
selbst in der Map und wurden auf ihr Tier eingeschmolzen — eine bewusst
gewaehlte aeltere Version wurde also durch die neueste ersetzt.
Volle Modellnamen gehen jetzt unveraendert an die CLI. Die versteht sie
("--model: an alias for the latest model or a model's full name") und
meldet sich selbst klar, wenn sie einen Namen nicht kennt — ehrlicher als
ein stilles Downgrade. Nur echter Muell faellt noch auf "opus", und das
wird geloggt.
Nachgewiesen gegen den LIVE-Katalog und die echte CLI im Proxy-Container:
20 Pruefungen gruen, u.a. dass alle 12 gelieferten exakten Versionen den Proxy
unveraendert passieren. `claude --print --model claude-opus-5-5` antwortet.
Stefans aktive Einstellung ist der Alias "opus" — am laufenden Betrieb aendert
sich dadurch nichts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Dinge, die bisher nur im Code bzw. nur in der DB standen.
Anhang-Limit (Einstellungen → System & Wartung):
- Das Limit war eine Env-Variable mit 20 MB Default — zum Anheben musste man
die .env editieren und das Brain neu starten. Jetzt steht es in runtime.json
und das Brain liest es bei JEDEM Upload neu: Aenderung greift sofort.
- Reihenfolge: runtime.json > ENV > Default. Anders als beim OpenAI-Endpunkt
gewinnt hier NICHT die .env — dort erzwingt ein Docker-Port-Mapping das,
hier gibt es keinen solchen Zwang, und eine Einstellung die nichts tut waere
schlimmer als keine.
- Default von 20 auf 64 MB. Genau so viel holt die App auch auf ausdruecklichen
Tipp noch herunter (TAP_DL_MAX_BYTES); darueber warnt die UI, verbietet es
aber nicht — der Anhang liegt dann sauber auf dem Server, ist mobil nur nicht
mehr ladbar.
- Neuer Endpunkt GET /attachments/limit. Das fest eingetippte "max 20 MB pro
Datei" im HTML ist weg — es stimmte nach jeder Aenderung nicht mehr.
- Die Fehlermeldung nennt jetzt MB statt Bytes und sagt, wo die Einstellung ist.
Datum/Uhrzeit bei Gedanken:
- created_at/updated_at lagen schon immer in der DB und wurden ausgeliefert —
nur nie angezeigt. Jede Zeile zeigt jetzt "angelegt <Zeit>" und, falls
abweichend, "geaendert <Zeit>" plus ein relatives "(vor 3 Std)". Damit sieht
man auf den ersten Blick, was der letzte Eintrag war.
- Sortier-Dropdown: nach Typ gruppiert (wie bisher) oder nach Anlage/Aenderung
auf- und absteigend. Bei Zeit-Sortierung wird die Liste flach dargestellt —
man will sehen was zuletzt passiert ist, nicht in welche Schublade es gehoert.
- Zeitraum-Filter (🕒) mit von/bis, umschaltbar zwischen angelegt und geaendert,
plus Schnellwahl Heute / 7 / 30 Tage. Gilt auch fuer Such-Treffer, damit
"suche X, aber nur letzte Woche" geht. Zuklappen schaltet ihn aus, und das
✕-Zuruecksetzen raeumt ihn mit auf (sonst filtert er unsichtbar weiter).
Beides gegen den echten Code getestet: 7 Faelle fuers Limit (inkl. kaputter
runtime.json und einem 50-MB-PDF an beiden Grenzen), 10 fuer Sortierung und
Zeitraum.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
llama-swap ist bereits OpenAI-kompatibel, war aber nur im Compose-Netz erreichbar
(kein ports-Mapping). Jetzt nutzbar fuer OpenHands, Continue, Open WebUI & Co.
- compose: llama-swap veroeffentlicht 8080 als
${LLM_OPENAI_BIND:-127.0.0.1}:${LLM_OPENAI_PORT:-8081} — sicher per Default
(nur localhost), fuer LAN bewusst BIND=0.0.0.0 setzen.
- llm-adapter: API-Key wird in JEDEN llama-server-Befehl der generierten
llama-swap-Config eingehaengt (--api-key, shlex-gequotet). Quelle: .env
(Vorrang) sonst /models/openai_key.json (0600). Neuer Handler
llm_openai_config setzt ihn zur Laufzeit und lehnt bei .env-Vorrang ab.
worker_hello meldet Port/Bind/keySet/envLocked — den Key NIE (Broadcast!).
- Diagnostic: pro LLM-Box Endpunkt-Zeile mit Base-URL, Key-Status und Eingabe.
Bei .env-Vorrang ist das Feld schreibgeschuetzt (🔒). Warnung, wenn im LAN
offen ohne Key. Der PORT wird nur ANGEZEIGT: er ist ein Docker-Port-Mapping
und steht beim Container-Start fest — dafuer ist die .env zustaendig.
- rvs: llm_openai_config(_result) in ALLOWED_TYPES (sonst still verworfen).
- Neues Profil 'openhands' (COMPOSE_PROFILES=llm,openhands) mit Port/Bind/Modell
aus der .env, lokales LLM vorbelegt. Ohne Profil aendert sich nichts.
- .env.example + README: alle Variablen, Sicherheitshinweise (offener Endpunkt,
Docker-Socket bei OpenHands), curl-Test und wann der Key greift.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Statt sich durch die Fire-TV-Oberflaeche zu klicken (fehleranfaellig: ARIA ist am
Titel vorbeigescrollt und auf Home gelandet) spricht ARIA den Jellyfin-Server
direkt an: suchen -> Sitzung des Abspielgeraets finden -> abspielen.
- Diagnostic (Einstellungen > Integrationen): Jellyfin-Abschnitt mit MEHREREN
Servern (+-Button; eigener, vom Kumpel ...), einer davon Standard. Pro Server
Name/URL/API-Key + Test-Knopf (prueft /System/Info, meldet Name und Version).
Gespeichert in /shared/config/jellyfin.json mit Datei-Rechten 0600 (API-Keys).
- Brain: jellyfin_search / jellyfin_devices / jellyfin_play / jellyfin_control.
Serverwahl per Name oder Standard. 'resume' ist echt implementiert (liest
PlaybackPositionTicks und setzt startPositionTicks) statt nur zu existieren.
Fehlertexte sind handlungsleitend: 401 -> API-Key pruefen; kein Geraet -> die
Jellyfin-App muss offen sein, sonst erst host_app_launch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher stand im Namensfeld die technische Kennung aus der Netz-Erkennung
(F8FCE10B4E6C@AS-AFTKA[AirPlay]) — auch wenn das Geraet laengst 'Fire-TV
Schlafzimmer' heisst. Jetzt in dieser Reihenfolge:
1. Name, den der Agent auf DIESEM Geraet traegt — Zuordnung ueber die IP, die
der Agent neu in host_hello mitmeldet (localIp()); Server reicht sie durch.
2. zuletzt hier eingegebener Name (localStorage je Satellit+IP).
3. Name aus der Erkennung, aber nur wenn menschenlesbar — Seriennummern, IPs
und Kennungen mit @/[]/: werden verworfen (Feld bleibt leer).
Android-Version 0.0.1.5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1) 'adb shell' haengt seine Argumente zu EINER Kommandozeile zusammen, die auf
dem Geraet nochmal von der Shell zerlegt wird — '-e name Wohnzimmer Fire TV'
kam als 'Wohnzimmer' an, der Rest fiel weg. Alle Werte werden jetzt mit
shlex.quote gequotet.
2) Umbenennen erzeugt eine neue hostId, der alte Eintrag blieb fuer immer in der
Diagnostic stehen (nach 5 min nur rot, nie weg). Neuer ✕-Button je Agent
(host_forget) mit Rueckfrage; laeuft der Agent noch, meldet er sich von selbst
wieder — das Entfernen stoppt ihn also nicht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Am Fire TV gibt es keine Kamera (kein QR) und Host/Token mit der Fernbedienung
einzugeben ist eine Qual. Der Satellit hat aber ohnehin schon eine ADB-Verbindung
— darueber bekommt der Agent seine Zugangsdaten direkt.
- Android: MainActivity.applyProvisioning() liest Intent-Extras (host/port/tls/
token/name/control/reply_mode), speichert sie, startet den Dienst und zeigt
'Von ARIA eingerichtet' (Transparenz). Auch via onNewIntent.
- Satellit: adb.provision (am start mit Extras) und adb.status (installiert?
laeuft? welche Version?). adb.install richtet direkt mit ein, wenn rvs_host/
rvs_token mitkommen -> ein Klick = installieren + einrichten + online.
- Diagnostic: Checkbox 'Gleich einrichten' (default an) + 'Status pruefen'-Button.
Der RVS-Zugang wird SERVERSEITIG ergaenzt (params.provision) — das Token steht
nie im Browser-Formular.
- Allowlists (Code + .env.example) und README ergaenzt, inkl. Sicherheitshinweis.
Android-Version 0.0.1.1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Satellit kann Android-Geraete im LAN erkennen und die Agent-APK ausrollen,
statt sie von Hand aufs Geraet zu kopieren.
- satellite.py: adb.devices/connect/install/shell. _apk_fetch laedt die APK per
HTTP (gecached in /data/apk, sha256 optional) statt sie durchs RVS zu schicken —
der RVS ist ein BROADCAST-Relay (jede base64-APK ginge an alle Clients, und das
Satelliten-max_size liegt bei 8 MB). adb.install ist selbstheilend (connect ->
install -r) und uebersetzt die typischen Fehler in klare Ansagen (unauthorized,
Signatur-Mismatch, Speicher voll). Imports lokal in den Funktionen (Hausmuster).
- Discovery: mDNS-Typen _amzn-wplay/_adb-tls-connect/_androidtvremote2, _mdns_kind
-> firetv/android-adb/androidtv, plus _enrich_adb (TCP-Probe 5555) -> adbCapable.
- Dockerfile: adb; compose: HOME=/data (ADB-Key persistent, sonst fragt das Geraet
nach jedem Rebuild neu) + ANDROID_ADB_SERVER_PORT=5038 (Host-Kollision).
- .env.example: neue Aktionen + Warnung, dass die Allowlist den Code-Default
ueberschreibt (sonst lehnt ein bestehender Satellit adb.* ab).
- Brain: adb.* in der satellite_command-Beschreibung; WICHTIG Timeout 200s fuer
adb.*/ssh.exec — der Bridge-Default von 20s haette jede Installation abgewuergt.
- Diagnostic: sat_command (Browser->RVS) und sat_result (RVS->Browser) gab es
bisher GAR NICHT; beide ergaenzt. 📦-Button je ADB-faehigem Geraet + Rollout-
Modal mit Status/Log, ADB-Tag in der Geraeteliste.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Jede Host-Aktion wird als Historie-Eintrag festgehalten und in der Diagnostic
pro User-Nachricht gruppiert aufklappbar dargestellt (mit Screenshot-Thumbnails).
- Brain: trace_id+msg pro chat(); _dispatch_host als Wrapper um _dispatch_host_inner
emittiert je Aktion einen Eintrag an POST /internal/agent-history (Datei-Pfad aus
Screenshot-Text erkannt).
- Bridge: /internal/agent-history persistiert nach /shared/config/agent_history/
<hostId>.jsonl (Ringpuffer 200) + broadcastet agent_history; agent_history_query
-> agent_history_list.
- RVS: agent_history/_query/_list in ALLOWED_TYPES (sonst still verworfen).
- Diagnostic-Server: relay browser<->RVS + /uploads/<file> Bild-Endpoint (nur
/shared/uploads, kein Traversal).
- index.html: 'Historie'-Button je Host, Modal mit Akkordeon (Gruppe=Nachricht,
aufklappbar, Screenshot-Thumbs), Live-Refresh bei agent_history.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Raum-Monitor (haette uns die Nacht erspart): der RVS-Log kuerzt Tokens auf 8
Zeichen -> zwei verschiedene Tokens mit gleichem Prefix ergeben zwei Raeume,
die im Log IDENTISCH aussehen (Prefix-Kollision). Jetzt zeigt die Diagnostic
(Satelliten-Tab, Panel 'RVS-Raeume 🚪') alle Raeume mit token8 + laengerem
Fingerprint (sha256) + Token-Laenge + Client-Zahl, ★ = eigener Raum. >1 Raum =
Warnung 'Token-Mismatch'. Keine vollen Tokens (nur Fingerprint).
- rvs: rooms_query -> direkt rooms_info antworten (wie update_check); Typen in
ALLOWED_TYPES; sha256-Fingerprint via crypto.
- diagnostic: rooms_query durchreichen, rooms_info an Browser; Panel + Tabelle.
Dazu: Compute-Flotte-Ueberschrift bekommt statt 🖥️ ein Inline-SVG (Server mit
GPU-Karte, currentColor -> theme-aware).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnostic-Server trackt host_hello/host_ping (hosts-Map), broadcastet
host_update und beantwortet die host_list-Action. UI: neues Panel
"Host-Agenten" im Satelliten-Tab — zeigt Name/OS/Caps/online + ob
CONTROL_ENABLED. Reine Sichtbarkeit; Steuerung laeuft ueber ARIA.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Baut SNMP zur generellen Geraete-Auskunft aus und macht Zugangsdaten pro Geraet
hinterlegbar, damit der Satellit tiefer lesen kann.
Satellit:
- Verschluesselter Credential-Store (Fernet) pro IP im Bind-Volume ./data:
SNMP (community/v2c oder v3 user/auth/priv), HTTP-Basic, FritzBox-Login.
Neue Messages sat_creds_set/list/delete + *_result; Secrets werden NIE
zurueckgeliefert (list gibt nur Typen). snmp.*/http/fritzbox nutzen die
Creds automatisch (params haben Vorrang).
- snmp.ports: ifTable -> aktive/freie Ports, Linkspeed ('sind noch Ports frei').
- snmp.info: sysName/Descr + Entity-MIB Modell/Serial/Firmware (installierte
Version; Update-Check ist Hersteller-Sache, kein SNMP).
- fritzbox.info/hosts: TR-064 (SOAP+Digest) — Verbindung/Datenrate/externe IP
bzw. verbundene Geraete. Bewusst als Reader, weil TR-064 fuer on-the-fly
http.post zu fummelig ist.
- CONTROL_ALLOWLIST-Default + .env.example erweitert; data/ ge-gitignore-t.
RVS: sat_creds_* in ALLOWED_TYPES (sonst verworfen).
Diagnostic: pro entdecktem Geraet ein Schluessel-Button -> Modal (SNMP v2c/v3,
HTTP-Basic, FritzBox); Speichern/Loeschen via RVS an den Satelliten; gesetzte
Typen werden pro Geraet angezeigt (🔑 ✓). Server relayed die Cred-Messages.
Brain: satellite_command-Tool um snmp.ports/info + fritzbox.* erweitert; ARIA
muss keine Passwoerter mitgeben (Satellit nutzt den Store).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- diagnostic/server.js: die beiden Debug-Logs der ai-box-Fehlersuche entfernt
(roher RX-Dump jeder worker_*/sat_hello-Nachricht + 'worker_hello empfangen'
bei jedem 30s-Resend). Die Flotte laeuft, der Firehose kann weg.
- bridge/aria_bridge.py: /shared/logs/app.log (JSONL, wuchs unbegrenzt bei
jeder App-Log-Zeile) rotiert jetzt bei >5 MB auf die letzten 2000 Zeilen
(Muster wie metrics._maybe_rotate).
RVS selbst loggt nur Lifecycle (Connect/Disconnect) — kein Message-Firehose,
unveraendert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
qwen3-8b antwortete in ~13s (unter 15s) und kam durch; qwen3-4b lief in
"Timeout", obwohl kleiner. Ursache ist nicht die Modellgroesse, sondern der
KALTE Modell-Swap: beim ersten Wechsel entlaedt llama-swap das alte Modell
und laedt das neue GGUF frisch in den VRAM (+ erste Inferenz) — das dauert
laenger als die 15s, die sendToRVS_withResponse hart als Timeout hatte.
sendToRVS_withResponse nimmt jetzt ein optionales timeoutMs (Default 15s
unveraendert fuer Voice-List etc.); llm_test uebergibt 120s. Der Adapter
selbst deckt den Swap mit LLM_TIMEOUT_SEC=60 ab und meldet waehrenddessen
llm_status "loading".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Worker sendeten worker_hello nur EINMAL beim Connect. Startet das Diagnostic
oder die Bridge NACH der Box neu, verpassen sie das hello (RVS spielt es nicht
nach) und sehen nur noch worker_ping → die Box taucht nicht in der Compute-
Flotte auf. Der Satellit ist genau deshalb zuverlaessig sichtbar: er wiederholt
sat_hello periodisch.
- alle vier Worker (f5tts/whisper/voxtral/llm-adapter): worker_hello wird jetzt
zusaetzlich alle ~30s (jeder 3. Ping-Zyklus) wiederholt → ein neu gestartetes
Diagnostic/Bridge lernt die Box innerhalb von 30s, ohne Box-Neustart.
- diagnostic/server.js: Voice-Reconcile (f5tts) laeuft nur beim ERSTEN/erneuten
Auftauchen der Box, nicht bei jedem 30s-hello-Resend (sonst Push/Pull-Dauerlauf).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pro Box ein "Auslastung"-Button in der Compute-Flotte → Modal mit live
nvidia-smi (1s), Graphen (GPU-Auslastung + Tokens/Intervall) und Besen-Reset.
Historie liegt auf der Box, Diagnostic holt sie via RVS.
- node_stats.py (identisch in allen 4 Worker-Build-Contexts): Sampler alle 15s
(nvidia-smi + Token-Delta → Ringpuffer ~500 Punkte, persistent als JSON auf
der Box), Live-Stream (node_stats, 1s, Auto-Stop 300s), History-Request,
Reset. nvidia-smi via async subprocess, fail-safe ohne GPU.
- Worker-Wiring (f5tts/whisper/voxtral/llm-adapter): Import, Sampler-Task,
_stats.handle() nach dem targetInstance-Filter. llm-adapter zaehlt Tokens
(usage.total_tokens) → Token-Graph nur bei LLM-Boxen. Dockerfiles kopieren
node_stats.py.
- compose: llm-adapter bekommt runtime:nvidia + NVIDIA_VISIBLE_DEVICES=all +
DRIVER_CAPABILITIES=utility (nur nvidia-smi, KEIN VRAM/Compute).
- diagnostic/server.js: relay node_stats_* (Browser→Box) + forward (Box→Browser).
- diagnostic/index.html: Auslastung-Button pro Node (Ziel bevorzugt llm-Instanz),
Modal mit live nvidia-smi + Inline-SVG-Sparklines, Besen-Reset.
Reporter-Wahl bevorzugt die llm-Instanz (sieht alle GPUs + Tokens); GPU-Worker
sehen ihre gepinnte Karte. Gitignored Historie stoert git-Baum der Box nicht.
Deploy: diagnostic + GPU-Boxen neu bauen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ARIA nutzt lokale LLMs auf mehreren ai-boxen; jede Box (llama-swap) kann
mehrere Modelle fahren. Auswahl nach MODELL, Box wird automatisch gewaehlt.
- xtts/llm-adapter/adapter.py: fragt beim Connect llama-swap GET /v1/models ab
und meldet die Modell-Liste in worker_hello (models:[...]), Fallback [LLM_MODEL].
- bridge/aria_bridge.py: Worker-Registry speichert models[]; _pick_worker(service,
model=) beruecksichtigt nur Boxen, die das Modell fahren koennen (nachsichtig:
keine → None → Broadcast/Claude-Fallback); Round-Robin je service+model
verteilt mehrere Projekte auf mehrere Boxen; _local_llm reicht das Modell durch;
_worker_list traegt models[].
- diagnostic/server.js: workers-Map + workerList um models[] erweitert.
- diagnostic/index.html: Compute-Flotte zeigt bei llm die Modell-Liste; das
"Lokales Modell"-Dropdown wird LIVE aus den angemeldeten Boxen gebaut
(Vereinigung + kuratierte Namen aus local_models.json, "· N Box(en)"/"offline"),
darunter eine kompakte LLM-Box-Liste (Node→Modelle→Health). Speisung aus dem
vorhandenen worker_update-Broadcast.
Kein Brain-/App-Eingriff. Routing greift nur bei aktivem Lokal-Schalter.
Deploy: diagnostic + bridge + llm-Boxen neu bauen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stimmen lagen bisher nur pro Box (xtts/voices/). Jetzt haelt der Diagnostic-
Server sie zentral als /shared/voices/{name}.tar.gz und versorgt jede f5tts-Box
automatisch.
- diagnostic/server.js (Bibliothekar):
* zentraler Store + Helfer (list/read/write/delete tar.gz)
* reconcileVoices() beim worker_hello einer f5tts-Box: push fehlende zentrale
Stimmen (xtts_import_voice, targetInstance) + pull box-eigene, zentral
fehlende (xtts_export_voice) → seedet den Store aus der ersten Box
* autonome RVS-Listener: xtts_voice_saved → zentraler Ingest (auch App-Uploads);
xtts_voice_exported (nur eigene requestId) → in Store schreiben;
xtts_delete_voice → zentrale Kopie mitloeschen
* Delete-Action loescht zentrale Kopie direkt mit
- xtts/f5tts/bridge.py: worker_hello traegt jetzt voices:[names] (ohne
default_ref) fuer den Abgleich; handle_export_voice echot requestId zurueck
(Korrelation zentral vs. browser-initiiert)
Wiederverwendet den vorhandenen export/import-tar.gz-Transport + Stage-3-
targetInstance-Filter. Playback (preview_voice) und Lastrouting (freieste Box)
existierten bereits. Keine App-/aria-bridge-Aenderung.
Deploy: diagnostic + f5tts-Boxen neu bauen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rein terminologisch: die feste "Gamebox" ist konzeptuell zu beliebig vielen
AI-Boxen geworden (Multi-Node-Compute-Fleet). Wort-Sweep ueber Code-Kommentare,
Strings, README, docs, .env.example, CHANGELOG — keine Identifier/Keys betroffen
(Gamebox kam nirgends in Variablennamen vor). Casing erhalten: Gamebox→AI-Box,
gamebox→ai-box. NODE_NAME-Default gamebox→ai-box, Instanz-IDs f5tts@ai-box.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Datei-Uploads (Copy-Paste UND Datei-Picker) trugen im Diagnostic-Portal
den projectId des fokussierten Projekts nicht mit — anders als Text und
Zwischenrufe. Die Bridge las payload.projectId, bekam nichts und routete
die Datei-Bubble in den Hauptchat.
- index.html: sendDiagAttachments schickt projectId: focusedContextId
- server.js: send_file-Relay reicht projectId in die RVS-Payload weiter
Beide Upload-Wege laufen ueber handleDiagFileSelect → ein Fix deckt beide.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stefans Repro "nichts geht mehr" kam NICHT von den Marker/Guard-Aenderungen,
sondern von der Speaker-ID: die Bridge-Logs zeigten fast durchgehend
"stt_endpoint mit leerem Text — ignoriert (reason=speaker_mismatch)" — ein aus
einem kaputten Enroll (AAC-als-PCM) entstandener Muell-Fingerprint hat Stefans
EIGENE Stimme abgelehnt und damit die komplette STT lahmgelegt.
Fix: Speaker-ID-Gating ist jetzt ein expliziter Schalter, Default AUS. Bei aus
laeuft die Pruefung GAR NICHT (fail-open, alle Stimmen durch) — ein schlechter
Enroll kann nie wieder alles abwuergen. Damit ist Stefans Problem schon durch den
Voxtral-Rebuild geloest (kein Loeschen noetig, der Check greift einfach nicht).
- voxtral + whisper bridge: SPEAKER_ID_ENABLED (Default False, ENV VOICE_ID_ENABLED),
_check_speaker faellt bei aus sofort fail-open zurueck; config-Broadcast
voiceIdEnabled setzt es zur Laufzeit.
- diagnostic: Schalter "Nur meine Stimme" in der Voice-ID-Sektion (Default aus,
Hinweis: erst an wenn enrollt), broadcastet + persistiert voiceIdEnabled.
Reihenfolge lt. Stefan: erst Konversation sauber, dann Multi-Person/nur-ich.
Deploy: docker compose up -d --build voxtral-bridge; aria-diagnostic neu starten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der Button rief copyDiskCmd() → kopierte nur den docker-Befehl in die
Zwischenablage (ueber http scheitert navigator.clipboard oft still →
'keine Funktion'). Jetzt fuehrt runDiskCleanup() das Aufraeumen echt aus:
Server-seitig ueber die Docker-Daemon-API (Socket ist gemountet) —
/build/prune?all=true + /images/prune (dangling=false), ohne Volumes =
keine Daten weg. 'Aggressiv' (zusaetzlich Container+Volumes) als eigener
'Jetzt ausfuehren'-Button mit Warnung. Rueckmeldung: wieviel frei wurde;
Banner aktualisiert sich per periodischem disk_status.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Neben Senden ein 'Zwischenruf' (App: oranger Button, nur wenn ARIA im
aktiven Kontext arbeitet; Diagnostic: Buttons neben beiden Senden). Geht
NICHT in die Queue und bricht NICHT ab — die Nachricht wird in den
laufenden claude-Subprozess geschoben; er greift sie an der naechsten
Tool-Grenze auf.
Technik:
- proxy-patches/manager.js: claude laeuft jetzt im --input-format
stream-json-Modus, initialer Prompt als stream-json User-Message,
stdin bleibt OFFEN; sendMessage() schiebt weitere User-Messages nach;
bei 'result' wird stdin geschlossen (Turn endet sauber). Ersetzt die
bisherigen sed-Patches (jetzt volle Datei via cp, docker-compose.yml).
- proxy-patches/routes.js: Side-Channel POST /interject {projectId,text}
→ subprocess.sendMessage der Kontext-Subprozesse.
- rvs: 'interject' erlaubt. bridge: RVS interject → Proxy /interject.
- App/Diagnostic: Zwischenruf-Buttons + lokale '📣 Zwischenruf'-Bubble.
Empirisch verifiziert: mid-turn injizierte Message wird an der naechsten
Tool-Grenze aufgegriffen (nicht mitten in einem blockierenden Befehl).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der cancel_request-Handler rief openclaw doctor --fix auf dem Container
aria-core auf, den es im aktuellen Stack nicht mehr gibt → der laufende
claude-Subprozess wurde nie gekillt, ARIA lief weiter. Jetzt sendet er
RVS cancel_request{hard:true} → Bridge → Proxy /cancel-all killt den Run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Symptom: Satellit fand nur Docker-Container (192.168.65.x / 172.18.x) statt der
echten LAN-Geraete. Ursache ist kein Bug, sondern das Deployment-Netz: auf Docker
Desktop (Mac/Windows) ist network_mode:host das Docker-VM-NAT, nicht das echte LAN
— mDNS/SSDP erreichen die realen Geraete nicht.
- satellite.py: _net_context() ermittelt primary_ip + alle IPs und WARNT, wenn der
Satellit in einem Docker-/NAT-Netz laeuft (192.168.65.x oder 172.16-31.x). Netz-
Info wird in sat_hello + sat_devices mitgeschickt und beim Start geloggt.
- Diagnostic: zeigt Netz (primary_ip) pro Satellit + eine rote ⚠-Box mit der
Warnung, wenn er im falschen Netz sitzt.
- README/compose: klar dokumentiert, dass der Satellit im ECHTEN Ziel-LAN laufen
muss (Linux Docker Engine ODER nativ python satellite.py); Docker-Desktop-Falle.
py/node clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
