mission-control-v2/docs/REVIEW_2026-07-02.md

Komplett-Review Mission Control 2 + Lucy — 02.07.2026

Methodik: IST-Zustand live erhoben (Box per SSH, lokaler Lucy-PC, Working Tree lucy-v2 inkl. uncommitted) — nicht aus Docs/Memory übernommen. SOLL-Zustand in 3 Recherche-Runden tagesaktuell (Stand 02.07.2026) ermittelt. Alle früheren Verdikte wurden neu auf den Prüfstand gestellt. Scope: alles außer Security.

---

1. Management-Summary

Bereich	Zustand	Kernaussage
LLM-Stack (Box)	✅ stark, 1 Bug	Vulkan-Pfad richtig, Qwen3.6+MTP läuft; aber chat-Lane kaputt (Autostart-Fund war Fehlalarm)
Lucy Voice-Latenz	🔴 3,5–5 s	2026-Ziel ist 0,5–0,8 s. Schuld sind STT (2,0 s) und VAD-Timer (0,9 s), nicht das LLM (TTFT 65 ms)
Lucy Avatar/App	✅ sehr ausgereift	VRMA-Mocap, Lippensync v2, MateEngine-Features komplett; Electron 10 Major-Versionen alt
Backend/Frontend-Code	🟡 solide	3 Monolithen, etwas DRY-Schuld, dist/ im Git; keine Rot-Flaggen
Ökosystem-Aktualität	🟡	Hermes 1 Release hinter (v0.18.0 vom 01.07.); pocket-tts, mem0, llama-swap, three-vrm aktuell
Verdikte	✅ alle bestätigt	Pocket TTS, Electron, Qwen3.6-Hirn, kein ZeroClaw, Mem0 — alle bestehen die Re-Prüfung

Die zwei größten Hebel:

1. STT-Tausch (faster-whisper medium → Parakeet-TDT 0.6B v3): ~2,0 s → ~0,2 s pro Äußerung
2. VAD-Tausch (RMS-Eigenbau → Silero VAD v6.2): Turn-Ende 900 → ~450 ms bei besserer Genauigkeit

Zusammen: Voice-to-Voice von ~3,5–5 s auf realistisch ≤1,2 s, ohne neue Hardware.

---

2. IST-Zustand (live verifiziert)

2.1 Box (192.168.178.151 — Strix Halo, gfx1151, 122 GB, Vulkan)

Komponente	Installiert	Aktuell (02.07.2026)	Bewertung
llama.cpp	b9843 (86b94708f)	b9859 (01.07.)	✅ nur ~16 Builds dahinter
llama-swap	v233 (29.06.)	v233	✅ aktuell
Hermes Agent	v0.17.0 (19.06.)	v0.18.0 (01.07.)	🟡 Update lohnt (3 P0 + 493 P1 gefixt)
mem0ai / chromadb	2.0.8 / 1.5.9	2.0.8	✅ aktuell
Kernel	7.0.0-27-generic	—	✅

Live-Modell-Lineup (/etc/llama-swap/config.yaml, live gelesen — der Repo-Snapshot deploy/llama-swap.config.yaml ist veraltet und zeigt noch gemma-4):

Alias	Modell	ctx	Besonderheiten
hermes (Brain)	Qwen3.6-35B-A3B (UD-Q4_K_M, MTP-GGUF)	65536	--spec-type draft-mtp --spec-draft-n-max 3 --parallel 1 -cram 16384, kein cache-reuse
heavy	Qwen3.5-122B-A10B	32768	cache-reuse 256, ttl 600
coder	Qwen3-Coder-Next	131072	cache-reuse 256, ttl 600
coder-lite	Qwen3-Coder-30B-A3B	131072	cache-reuse 256, ttl 300
vision	Qwen3-VL-8B	32768	mmproj, in brains
embed	Qwen3-Embedding-0.6B	8192	ttl 0, in brains
scout	GLM-4.6V-Flash	131072	mmproj, ttl 300

Gruppe brains (swap:false, persist:true) = embed + vision + Qwen3.6. Alle Modelle: -ngl 999 -fa on --no-mmap --jinja. Kein Modell nutzt KV-Cache-Quantisierung (alles F16).

Dienste live: llama-swap, hermes-gateway, hermes-terminal, hermes-webui, mem0-service, voice-service — alle running. Ports 7681/8080/8642/8650/8765/8787/9001 belegt.

2.2 🔴 Live-Bugs (selbst reproduziert)

B1 — MC2-Backend ohne Autostart FEHLALARM (korrigiert 02.07., nachverifiziert). :9001 läuft als User-Unit mission-control-2.service (~/.config/systemd/user/, enabled, Linger=yes → reboot-fest). Die erste SSH-Prüfung sah User-Units nicht (fehlendes XDG_RUNTIME_DIR). Einziger echter Fund: Die stale v1-System-Unit mission-control.service (disabled, /opt/mission-control:9000) liegt noch in /etc/systemd/system und stiftet Verwirrung → bei Gelegenheit mit sudo entfernen (kosmetisch, kein Risiko).

B2 — chat-Lane kaputt (live reproduziert).

POST /v1/chat/completions {"model":"chat",...}
→ {"error":"no router for requested model","src":"llama-swap"}

Die Routing-Policy routet chat → fast ↔ heavy, aber llama-swap kennt den Alias fast nicht mehr (Qwen3.6 hat nur noch den Alias hermes). Lucy ist nicht betroffen (sie geht über den Hermes-Agenten :8642), aber jeder Client der chat-Lane bekommt Fehler. Fix: fast als zweiten Alias eintragen oder Policy auf hermes umstellen.

B3 — Config-Drift. deploy/llama-swap.config.yaml ist untracked UND veraltet (gemma-4-Ära). Zusätzlich fehlen im Install-Template backend/config.py:33 die Produktions-Tunings (cache-reuse, parallel, MTP) → neu installierte Modelle driften von der Box-Realität weg.

2.3 Gemessene Latenzkette Lucy

Quelle: /api/voice/metrics (live) + eigener TTFT-Test gegen llama-swap.

Stufe	Messwert	Anteil am Problem
VAD-Turn-Ende	900 ms Fix-Timer (RMS-Eigenbau, useVAD.ts)	groß
STT (faster-whisper medium int8, Box-CPU)	avg 2.046 ms · p50 2.092 ms · p95 2.529 ms (n=13)	dominant
LLM TTFT (Qwen3.6 warm, direkt :8080)	65 ms (24 Tokens in 334 ms)	✅ kein Problem
TTS erster Ton (pocket, RTF 0,44 + LEAD_IN 0,35 s)	~0,5–1 s für den ersten Satz	mittel
Voice-to-Voice gesamt	~3,5–5 s	Ziel 2026: 0,5–0,8 s

Fazit: Das teuerste Glied ist NICHT das LLM. STT + VAD-Timer fressen zusammen ~3 s. Genau dort setzt die Roadmap an.

2.4 Lokaler PC (RX 9070 XT / RDNA4)

• Lucy-App zum Prüfzeitpunkt nicht gestartet (kein Electron-Prozess, :8130 frei)
• ptts-venv: pocket-tts 2.1.0 (= neueste Version), torch 2.12.1+cpu (bewusst CPU), onnxruntime 1.27.0, fastapi 0.138.1
• GPU-Treiber 32.0.31021.5001
• client/lucy-tts/ (3 GB): Produktions-TTS mit Stimmen-Wächter (F0-Floor 160 Hz, MFCC-Fingerprint ≥0,94, Best-of-N), Phase A+B des TTS-Plans abgeschlossen (beste Config: 4 Worker × 2 Threads, RTF 0,44)
• client/lucy-f5/ (5,3 GB): F5-TTS-ONNX/DirectML-Experiment — Phase C/D (Finalentscheid pocket vs. F5) offen
• Lucy-Desktop: Electron 33 (aktuell: 43 vom 30.06. — 2 Jahre Chromium-Rückstand), three-vrm 3.4/animation 3.5.4 (≈ aktuell), TS strict

2.5 Code-Qualität (3 Explore-Agents über das ganze Repo)

Backend (4.889 LOC, 11 Router / 28 Services): insgesamt sauber, Multi-Sidecar-Architektur durchdacht. Findings:

• C1: Install-Template ohne Produktions-Tunings (backend/config.py:33) → Drift
• C2: _describe_images() blockiert den Voice-Chat bis 120 s synchron (backend/routers/voice.py)
• C3: Thinking-Deaktivierung 3× dupliziert (voice.py, gateway.py, mem0_service/app.py) — DRY
• C4: Junk-Fact-Regex im Mem0-Sidecar hartcodiert (Wartungspunkt)
• Dead Code: backend/services/pricing.py, vermutlich token_stats.py
• Uncommitted Änderungen (voice.py No-Think, connect.py IDE-only-coding, mc2-memory-Guards, Mem0-Junk-Guard, voice_service install.sh) sind alle konsistent und sinnvoll — nur eben nicht committet

Frontend (React 18/Vite 6/Tailwind 4/TanStack 5):

• Voice-Umzug in die Desktop-App sauber (keine toten Imports/Nav-Reste) ✅
• UI-Rework (roleMeta/Health/Expert/WarmSet) vollständig; coder_lite↔coder-lite via ALIAS gelöst
• F1: Cockpit.tsx (990 Z) + SystemDrawer.tsx (934 Z) Monolithen
• F2: 🟡 frontend/dist/-Asset-Stand auf lucy-v2 inkonsistent (alte gelöscht, neue untracked) — dist-im-Git selbst ist Absicht (Box hat kein Node), avatar.vrm ist via .gitignore korrekt draußen
• F4: keine globale Error Boundary
• MC3-Prototyp (frontend/src/mc3/) non-destruktiv hinter #mc3, untracked

Lucy-Desktop:

• L1: useVoiceAgent.ts (377 Z) monolithisch (SSE, Chunking, Tools, Perf, Vision in einem Hook)
• L2: kein Retry/Backoff beim TTS-Warmup (Crash → 2-min-Spinner)
• L3: VAD = reines RMS mit 900-ms-Stille-Regel
• L4: Echo-Schutz = 450-ms-Cooldown-Workaround (kein echtes Barge-in)
• Neues voice-core/-Adapter-Layer (STT/TTS austauschbar) ist die richtige Architektur ✅
• H1: ~23 Dateien uncommitted, darunter die neue voice-core-Architektur → Verlustrisiko

---

3. SOLL-Zustand (Recherche, Stand 02.07.2026)

3.1 Voice-Latenz — der Stand der Technik

• 2026-Zielmarke: 500–800 ms voice-to-voice; Grundprinzip: Streaming auf jeder Stufe (STT-Partials sparen 200–400 ms, TTS startet auf Teiltext, VAD+Turn-Taking-Budget 150–300 ms) — Latenz-Guide, Latenz-Budget-Design
• STT: Parakeet-TDT 0.6B v3 — 25 EU-Sprachen inkl. Deutsch, 6,32 % WER (besser als Whisper large-v3 mit 7,44 %), extrem schnell auch auf CPU, keine Silence-Halluzination. Deploy-Wege: onnx-asr (unterstützt CPU und DirectML → 9070 XT), fertige OpenAI-kompatible FastAPI-Wrapper. Kyutais Streaming-STT mit eingebautem semantic VAD (delayed-streams-modeling) wäre architektonisch ideal, ist aber nur EN/FR → für Deutsch raus.
• VAD: Silero VAD v6 (v6.2, ONNX): −16 % Fehler auf Noisy-Data vs. v5 — klar besser als der RMS-Eigenbau; erlaubt kürzeres Endpointing (~450 ms) bei weniger Fehlstarts.
• Semantische Turn-Detection: Smart Turn V2 (leichtgewichtig), Easy Turn (akustisch+linguistisch, 4 Turn-States, open source).
• TTS: pocket-tts 2.1.0 ist Stand der Technik für CPU-Realtime (kyutai). Challenger (CosyVoice2-0.5B, Chatterbox-Turbo) bieten keinen klaren Vorteil. → Einziger offener Entscheid bleibt das hauseigene F5-Experiment (Phase C/D).

3.2 Box maximieren

• Vulkan/RADV bleibt der schnellste Pfad auf Strix Halo (schlägt ROCm/HIP bei pp und tg) — die Box ist richtig aufgestellt (llm-tracker Strix-Halo, Strix-Halo-Guide). ROCm 7.2/RDNA4 betrifft nur den lokalen PC.
• Host-Memory-Prompt-Cache: --cache-ram + Prefix-Restore bringt bis 93 % TTFT-Reduktion bei Agent-Workloads mit wachsender Session (llama.cpp #20574). -cram 16384 ist gesetzt; das Zusammenspiel mit dem (am hermes-Alias entfernten) --cache-reuse gehört gebencht.
• KV-Cache-Quantisierung ungenutzt: -ctk/-ctv q8_0 halbiert den KV-Bedarf (relevant bei coder@131k, hermes@65k) bei praktisch verlustfreier Qualität; TurboQuant (3-bit, near-lossless ab 13B) steht vor der Integration — beobachten.
• „MoE Speculative Trap": Ein aktueller Strix-Halo-Deep-Dive zu exakt Qwen3.6-35B-A3B zeigt: Spec-Verify kann bei sparsem MoE pro Verify-Pass fast alle 35B Gewichte anfassen — in seinem Setup war ohne Draft (parallel=1, KV Q8_0) 43,1 t/s vs. 17,7 t/s. Das widerspricht der eigenen Box-Messung (+35 % MIT MTP). Konsequenz: beide Betriebsarten benchen, auch bei vollem Kontext (Decode-Drop bis 64 % dokumentiert).
• llama-swap-Features ungenutzt: capabilities (v225), -config-dir-Fragmente (v230), Swap-Matrix/Groups V2 (Releases).
• Modell-Landschaft 128 GB für heavy-Kandidaten: gpt-oss-120B, Mistral Small 4 (119B-A6B), Llama 4 Scout — nur mit Bench-Gate.

3.3 Ökosystem

• Hermes v0.18.0 „Judgment" (01.07.): 3 P0 + 493 P1 gefixt, Background-Fan-out für Subagents, /learn-Skills, Memory-Graph in der Desktop-App (Releases). Plugin-API: sync_turn() bekommt optional messages (voller Turn-Kontext inkl. Tool-Calls); Legacy-Signatur bleibt → mc2-memory ist update-kompatibel und kann später Tool-Ergebnisse mitlernen (Memory-Provider-Doku).
• Mem0 v3-Algorithmus (Migration): Single-Pass-Extraktion (~2× schneller), Hybrid-Retrieval (semantisch + BM25 + Entity-Graph, ohne externe Graph-DB), +20 LoCoMo / +26 LongMemEval. 2.0.8 installiert, custom_instructions schon migriert → Status final verifizieren.
• Electron 43 (30.06.), Chromium 150 / Node 24 — Lucy ist auf 33.
• Vision: Qwen3-VL ist aktuelle Generation ✅; Qwen3-VL-30B-A3B (MoE, 3B aktiv, top auf GUI-Benchmarks) wäre der Upgrade-Kandidat für die Bildschirm-Sicht.
• Lokaler GPU-Klon: AMD Lemonade (llama.cpp-Vulkan + whisper.cpp + Kokoro, OpenAI-kompatibel, RDNA4-Support) als fertiger Unterbau; llama.cpp-Vulkan ist der verlässlichste 9070-XT-Pfad.

3.4 Verdikte — Ergebnis der Re-Prüfung

Verdikt	Ergebnis	Begründung
Pocket TTS bleibt	✅ bestätigt	2.1.0 aktuell, RTF 0,44 optimiert, Wächter-System; Challenger ohne klaren Vorteil. F5-Entscheid (Phase C/D) bleibt als einziger offener Punkt
Electron bleibt (nicht Tauri)	✅ bestätigt	Alle nativen Features implementiert; aber Major-Update 33→43 einplanen
Qwen3.6 als Lucy-Hirn	✅ live bestätigt	Läuft mit MTP, TTFT 65 ms; gemma-4 ist komplett raus
ZeroClaw bleibt tot	✅ bestätigt	Kein neuer Anlass
Mem0 als Memory-Layer	✅ bestätigt (neu geprüft)	Zep/Hindsight benchen höher, sind aber schwerer/teils closed; Mem0: beste Integration, v3-Algo, deployt

---

4. Roadmap (Aufwand/Nutzen, Voice-Speed-first)

P0 — Live-Bugs & Betriebssicherheit (Stunden)

#	Maßnahme	Nutzen
1	Autostart fixen erledigt als Fehlalarm — User-Unit mission-control-2 mit Linger ist reboot-fest; nur stale v1-Unit bei Gelegenheit löschen (sudo)	Klarheit
2	chat-Lane fixen (fast-Alias ergänzen oder Policy auf hermes)	Live-Bug, alle chat-Clients betroffen
3	Box-Config → Repo syncen + deploy/ versionieren; Template-Drift C1 fixen	Quelle der Wahrheit
4	Hermes v0.17.0 → v0.18.0 + Health-Brain-Check	496 Upstream-Fixes
5	Commit-Hygiene (voice-core, MC3, Lucy-Fixes); frontend/dist/ in .gitignore	Verlustrisiko weg

P1 — Voice-Latenz: 3,5–5 s → Ziel ≤1,2 s (Tage)

#	Maßnahme	Erwartung
6	STT-Tausch: Parakeet-TDT 0.6B v3 statt faster-whisper medium. Variante A: Box-CPU (onnx-asr im voice_service); Variante B: lokal 9070 XT (DirectML). A/B: Deutsch-WER + Latenz	~2,0 s → ~0,2 s
7	VAD-Tausch: Silero VAD v6.2 (ONNX) statt RMS in useVAD.ts; Endpointing 900 → ~450 ms	−450 ms
8	TTS-TTFA: LEAD_IN 0,35 s prüfen, Erster-Satz-kurz-Regel messen (lucy_perf)	−100–300 ms
9	Brain-Bench-Matrix am hermes-Alias: MTP n-max 3↔4↔ohne (Speculative-Trap-These) × ±KV Q8_0 × cache-reuse/cram × -b/-ub — bei Kurz- UND Voll-Kontext	Bestes Setup evidenzbasiert
10	voice_metrics ausbauen: VAD→STT→Agent→First-Audio je Turn	Messbarkeit
10b	KV Q8_0 für coder@131k/heavy erwägen	Warm-Set-Reserve

P2 — Lucy v2 Kern & Code-Gesundheit (1–2 Wochen)

#	Maßnahme
11	Semantische Turn-Detection (Smart Turn V2 / Easy Turn) auf Parakeet aufsetzen; Barge-in-Vorstufe statt 450-ms-Cooldown
12	F5-TTS Phase C/D abschließen → Finalentscheid pocket vs. F5 (Benchmark-Gate)
13	useVoiceAgent-Refactor in Hooks + TTS-Retry/Backoff; Electron 33→43
14	Backend C2 (Vision async) + C3 (DRY) + Dead Code; Frontend Cockpit/SystemDrawer-Split + globale Error Boundary

P3 — Strategisch (nach Signal)

#	Maßnahme
15	Mem0-v3-Status final verifizieren; Junk-Regex durch v3-Retrieval entschärfen; mc2-memory auf sync_turn(messages) heben
16	MC3-Vollbau; llama-swap-Features (capabilities, config-dir, Swap-Matrix)
17	heavy-Bench: Qwen3.5-122B vs. gpt-oss-120B / Mistral Small 4; Vision-Upgrade Qwen3-VL-30B-A3B für Bildschirm-Sicht
18	Lokaler GPU-Klon: AMD Lemonade auf der 9070 XT evaluieren

---

5. Findings-Katalog (Referenz)

ID	Schwere	Fund	Ort
B1	⚪ (Fehlalarm)	:9001 läuft als User-Unit mit Linger — reboot-fest; nur stale v1-Unit als Kosmetik-Rest	Box, /etc/systemd/system/mission-control.service (v1)
B2	🔴	chat-Lane → fast-Alias existiert nicht mehr	Box, Routing-Policy ↔ /etc/llama-swap/config.yaml
B3	🟡	deploy/llama-swap.config.yaml untracked + veraltet	Repo
C1	🟡	Install-Template ohne Produktions-Tunings	backend/config.py:33
C2	🟡	Vision-Beschreibung blockiert Chat bis 120 s	backend/routers/voice.py
C3	🟢	Thinking-Disable 3× dupliziert	voice.py / gateway.py / mem0_service/app.py
C4	🟢	Junk-Fact-Regex hartcodiert	mem0_service/app.py
C5	⚪ (Fehlalarm)	pricing.py + token_stats.py sind IN BENUTZUNG (system.py /token_stats-Endpoint, gateway_stream) — kein Dead Code	backend/services/
F1	🟡	Monolithen 990/934 Z	frontend/src/views/models/Cockpit.tsx, components/SystemDrawer.tsx
F2	🟡 (korrigiert)	dist/ im Git ist ABSICHT (Box hat kein Node, deploy = git reset --hard; s. deploy/build.sh) — echter Fund war nur der inkonsistente Asset-Stand auf lucy-v2 (behoben durch Rebuild+Commit). Build-on-Box/CI wäre P3-Option	frontend/dist/
F4	🟢	Keine globale Error Boundary	frontend/src/App.tsx
L1	🟡	useVoiceAgent monolithisch (377 Z)	client/lucy-desktop/.../lib/voice/useVoiceAgent.ts
L2	🟡	Kein TTS-Warmup-Retry	ebd. + main/index.ts
L3	🔴	RMS-VAD mit 900-ms-Timer	client/lucy-desktop/.../lib/voice/useVAD.ts
L4	🟡	Echo-Cooldown statt Barge-in	ebd.
H1	🟡	~23 Dateien uncommitted (inkl. voice-core, MC3)	lucy-v2 Working Tree

---

6. Nachtrag: P0/P1-Umsetzung (02.07.2026)

P0 komplett: chat-Lane gefixt (fast-Alias), Hermes v0.18.0 (Postcheck grün), Config versioniert, Template-Drift behoben, Git aufgeräumt. B1 war Fehlalarm (s.o.).

P1-6 STT: Parakeet-TDT 0.6B v3 (onnx-asr, int8, Box-CPU) als Default — A/B gemessen: 0,45 s vs. 2,44 s (whisper-medium) bei identischem Transkript. Live deployt, auch via :9001 verifiziert.

P1-7 VAD: Silero v5 (vad-web 0.0.30) statt RMS — Endpointing 900→450 ms, WAV direkt (kein Opus-Umweg mehr). Build + Asset-Auslieferung verifiziert; Mikro-Test beim User.

P1-9 Brain-Bench-Matrix (Qwen3.6-35B-A3B, separater Port, Vulkan, je ~100 Gen-Token):

Config	tg kurz	tg tief (15k)	Draft-Akzeptanz kurz
MTP n-max 3, KV f16 (live)	78,6 t/s	— (Probe-EOS)	55 %
MTP n-max 4	63,7	100,9*	39 %
ohne Spec	62,4	— (Probe-EOS)	—
MTP n-max 3 + KV Q8_0	78,6	83,7	56 %
ohne Spec + KV Q8_0	62,1	57,0	—

*repetitiver Test-Text → unrealistisch hohe Draft-Akzeptanz (95 %); die Kurz-Spalte ist maßgeblich.

Bench-Verdikte: (1) MTP n-max 3 bestätigt (+26 % vs. ohne Spec — die „MoE Speculative Trap" gilt auf diesem Vulkan/parallel-1-Setup NICHT; der Artikel testete ROCm + parallel 4). (2) n-max 4 lohnt nicht (Akzeptanz fällt auf 39 %). (3) KV Q8_0 ist gratis (identische t/s) und halbiert den KV-Speicher → für hermes in deploy/llama-swap.config.yaml übernommen; Live-Schaltung braucht User-Freigabe. Für coder/heavy vorher cache-reuse×KV-Quant-Verträglichkeit testen (Context-Shift mit quantisiertem KV ist in llama.cpp historisch heikel).

P1-10: chat_first_content-Metrik in voice.py — misst die echte Hirn-Latenz (Agent-Overhead + LLM-TTFT bis zum ersten Inhalts-Token) statt nur des SSE-Starts.

P2-Nachtrag (02.07.):

• Profiling: Folge-Turns 1,3 s, NEUE Sessions 5,6–12 s (Session-Prefill System-Prompt+Tools ~4–5k Tok). Mem0-Search unschuldig (18 ms). Aber: Die Mem0-Lern-Extraktion (~2,4 s je Turn, gleiche Qwen3.6-Instanz) blockiert bei --parallel 1 den nächsten Voice-Turn in der Queue → Fix vorbereitet: --parallel 2 -c 131072 + KV Q8_0 (2×65k-Slots, speicherneutral zu 1×65k f16). Live-Schaltung = User (deploy/llama-swap.config.yaml ist fertig).
• C2 gefixt: Bildschirm-Sicht läuft jetzt IM Stream (SSE startet sofort, hermes.vision.progress-Event → Lucy kann Warte-Ansage sprechen); Vision-Timeout 120→45 s (MC_VISION_TIMEOUT).
• C3 bewertet: nur 2 Backend-Stellen mit unterschiedlicher Gating-Logik (dritte im separaten Mem0-venv) → kein Shared-Helper erzwungen, Pattern dokumentiert.
• C5 war Fehlalarm (s. Findings-Tabelle).
• L2 gefixt: TTS-Warm-Gate mit Retry/Backoff + sichtbarer Fehlermeldung (vorher: nach 120 s stumm „ready" ohne Stimme).

---

Erhoben am 02.07.2026 durch Claude Code (Live-SSH auf Box, lokale PC-Prüfung, 3 Codebase-Agents, 3 Web-Recherche-Runden). Messwerte: /api/voice/metrics (n=13 STT, n=18 chat_ttfb), TTFT-Direktmessung llama-swap :8080.