Systemaudit vom 27.08.2026. Alle Befunde gemessen, nicht vermutet.
VIER STILLE DEFEKTE
1. mc2-steward startete seit Wochen nicht (live: 207.609 Neustarts).
steward.py importierte services.memory, das beim Mem0-Ausbau geloescht
wurde -> ImportError bei jedem Start. Re-Warm- und Health-Waechter
waren damit tot.
2. Jedes Hermes-Update wurde automatisch zurueckgerollt.
hermes-postcheck.sh prueft vier Dinge, die es seit dem 07.08. nicht mehr
gibt (Sidecar :8765, /api/memory, memory.provider, mc2-memory-Plugin).
Die Checks konnten nicht gruen werden -> autoupdate.sh wertete jedes
Update als rot und rollte es zurueck. Checks ersatzlos entfernt; der
Tool-Smoke laeuft ohnehin durch den echten Agenten.
3. 7 von 12 Skills waren per Knopfdruck nicht startbar.
deploy.sh kopiert Skills mit tr '-' '_' nach ~/.hermes/skills/,
routers/skills.py gab Hermes aber den Ordnernamen MIT Bindestrich.
Der Knopf meldete Erfolg, ausgefuehrt wurde nichts. Neu: _hermes_name().
4. deploy.sh warf bei jedem Deploy die Live-Modellkonfiguration weg.
MC2 schreibt /etc/llama-swap/config.yaml selbst; die Repo-Datei ist nur
ein Abzug (ihm fehlt u.a. kritiker/Devstral). Jetzt: erst sichern, Diff
zeigen, dann kopieren. MC_DEPLOY_SKIP_SWAP_CONFIG=1 ueberspringt.
MEM0-AUSBAU VOLLENDET (Kriterium 3: 17 -> 0 Dateien)
- mem0_service/, mcp/mcp_memory.py und hermes/plugins/mc2-memory entfernt;
das Plugin schickte bei JEDEM Turn zwei 404-Requests an tote Routen.
- MEMORY_DB/MEM0_SERVICE_URL, _mem0_reachable(), MC_MEMORY_DB und
MC_MEM_DEDUPE_ENABLED aus Config/Router/Unit entfernt.
- mem0_ms war strukturell tot (park("retrieve") wird nirgends mehr
aufgerufen) -> aus Backend, API-Typ und Latenzkarte entfernt.
- Verbinden-Tab: tote Gedaechtnis-MCP-Leitung raus, Status-Kachel bleibt.
- AGENTS.md beschrieb Mem0 noch als aktiv - korrigiert.
GATEWAY-ROBUSTHEIT
- _proxy gab bei ungueltigen Payloads HTTP 500 (gemessen 5/5: Rohtext,
leerer Body, JSON-Liste, JSON-String, null) -> jetzt 5/5 HTTP 400.
- Bild-Weiche ohne Deckel: 10 Bilder x 2 Versuche x 240 s hielten den
Client bis zu 80 min. Neu: MC_CODER_IMAGE_MAX (4), Rueckfall auf die
Vision-Umleitung.
- /v1/models: nicht-JSON von der Engine gab 500 -> jetzt 502.
UNITS UND DEPLOY
- mc2-steward.service, dessen warmset-Drop-in und voice-service.service
fehlten im Repo, obwohl maintenance.py und stack-postcheck.sh sie
voraussetzen. 1:1 von der laufenden Box uebernommen.
- deploy.sh startete mc2-steward nie neu; restore.sh liess mc2-gateway und
mc2-steward mit alter Config weiterlaufen. Beide ergaenzt.
FRONTEND
- useEigenleben rief /api/eigenleben - existiert im Backend nicht und wurde
nirgends genutzt. Samt Typen entfernt.
- Anleitung beschrieb einen Gedaechtnis-Tab, den es nicht gibt.
- Abgeglichen: alle uebrigen 63 Frontend-Aufrufe treffen echte Routen, alle
5 SSE-Invalidation-Keys sind gemappt, keine ungefangenen Promises.
Gates: compileall gruen - ruff "All checks passed" - tsc gruen - vite build
gruen (dist aktualisiert) - Importe app/steward/gateway_app gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Nachsehen wegen einer haengenden Gitea-Karte im Steward-Log gefunden:
600 vergebliche warmup.sh-Laeufe in 24 h, alle 90 Sekunden. Aelteste Meldung
dieser Art: 15.07.2026 — also elf Tage, nicht erst seit dem Umbau.
Ursache: Der Reranker steckt in der ko-residenten Gruppe `brains` und gilt dem
Waechter damit als warm-pflichtig. Er antwortet aber NUR auf /v1/rerank — und
genau diesen Endpunkt kannte warmup.sh nicht. Das Modell konnte also nie warm
werden, der Waechter sah es ewig als "fehlend" und rief alle 90 s ein Skript auf,
das daran nichts aendern konnte. Mit Devstral in derselben Gruppe habe ich die
Falle vorgestern verdoppelt.
Zwei Korrekturen:
1. warmup.sh waermt jetzt auch Reranker (MC_WARMUP_RERANK, Default "reranker").
2. warmer.py bekommt MC_WARMSET als Override der Gruppen-Ableitung. Ko-Residenz
("duerfen gleichzeitig liegen") und Warm-Pflicht ("muessen immer liegen") sind
zwei verschiedene Aussagen; die Gruppe kann nur die erste ausdruecken. Seit
Coder (TTL 90 min) und Kritiker (TTL 30 min) in `brains` liegen, haette der
Waechter sonst gegen ihre TTLs gearbeitet und nachts 62 GB wieder hochgeladen.
Steward bekommt MC_WARMSET = embed + reranker + hermes (Drop-in auf der Box).
Falle dabei, live erlebt: systemd trennt `Environment=` an Leerzeichen — ohne
Anfuehrungszeichen kam nur das erste Modell an und das Warm-Ziel war still zu
klein. Der erste Fix sah deshalb erfolgreich aus (Schleife weg), war aber nur
eine kaputte Messung. Jetzt gequotet und im Prozess-Environ geprueft.
Belegt: alle drei Ziel-Modelle warm, 0 vergebliche Ausloesungen des neuen
Prozesses, Coder geladen aber korrekt kein Warm-Ziel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid 07.07.: 'Gehirn + Embedding reichen komplett aus' — die Augen
(VL-30B, ~19 GB) werden nur gebraucht, wenn Lucy auf dem Desktop an ist oder
die IDE-Lane sie ruft. Warm-Set = nur noch Qwen3.6 + embed; damit passt der
60-GB-Chef-Gutachter (gpt-oss) wieder neben das Hirn.
- llama-swap.config.yaml: VL-30B aus brains raus, ttl 0 -> 900 (15 min
Nachlauf); Kommentare entstaubt. AUSSERDEM Template<->Live-Drift beendet:
Template hatte coder-lite wiederbelebt (live seit 05.07. entfernt) und
KV q4_k (lief NIE live) — beides auf Live-Wahrheit (q8_0, kein coder-lite)
zurueckgesetzt; Qualitaet vor ein paar GB, RAM-Engpass ist mit der Diaet weg.
- warmup.sh: Default 'fast vision' -> 'fast' (Root-Kopie unter
/usr/local/bin braucht spaeter einmal sudo cp — bis dahin waermt ein
llama-swap-Restart vision einmalig, ttl 900 raeumt es wieder ab)
- warmer.py: Docstring auf neues Warm-Set angepasst
- Lucy-Seite (eigenes Repo): App waermt die Augen beim Start + alle 10 min,
solange sie laeuft — Augen-Lebenszyklus == Lucy-Lebenszyklus
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Gemessen 03.07.: erster User-Call nach Modell-Reload 37 s (Prefill des
~70-KB-Hermes-Prompts, 50 KB davon Tool-Schemas), mit warmem Prompt-Cache
~6 s. warmup.sh schickt nach dem Modell-Laden einen Wegwerf-Turn an den
api_server (:8642, wartet auf /health) — der -cram-Cache ist damit gefuellt,
bevor der User zum ersten Mal fragt. Strukturelle Prompt-Diaet = Faden 7.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Nutzer-Fund (Screenshots 03.07.): drei UI-Diskrepanzen im Modell-Manager.
1) Augen (VL-8B) hatten ttl 300 + fehlten im Warmup — standen also entgegen
dem UI-Versprechen NICHT immer bereit. Jetzt ttl 0 (Box live + Snapshot)
und Warmup-Default "fast vision".
2) Warn-Text beschrieb das alte Verdraengungs-Verhalten (seit persistent-Fix
falsch) — jetzt: Set bleibt geladen, bei Ueberlauf scheitert das grosse
Modell. 3) "Reserviert" als Vorsichts-Schaetzung/Obergrenze gekennzeichnet
(68,8 GB Schaetzer vs. 25 GB real — Schaetzer-Umbau ist eigener Faden).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Das Embedding-Modell (Alias `embed`, fuer Mem0/Gedaechtnis) ist zwar brains-Member
(persist), aber Pingen von `fast` laedt die anderen Gruppenmitglieder NICHT mit —
es blieb kalt bis zur ersten /v1/embeddings-Anfrage.
- warmup.sh: waermt jetzt zusaetzlich die Embedding-Modelle ueber /v1/embeddings
(anderer Endpunkt als chat), gesteuert via MC_WARMUP_EMBED (default "embed").
- stack-postcheck.sh: prueft nach jedem Update zusaetzlich, dass das Embedding-Modell
laedt und einen Vektor liefert (sonst ist Mem0/Gedaechtnis betroffen) -> Job rot.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Nach dem Hirn-Wechsel auf fast (Qwen3.6) zeigte der Wächter noch auf "hermes"
(Hermes-4-14B) -> er haette das aus dem Warm-Set entfernte Modell wieder geladen.
warmer._brain_model() liest jetzt Hermes' model.default (Fallback fast); Startup-Warmup
BRAINS default "fast". Passt sich kuenftigen Hirn-Wechseln automatisch an.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Engine-Cutover ROCm/HIP -> Vulkan/RADV (gfx1151): +12-22% tg auf MoE (llama-bench
verifiziert, fast 53->65 t/s). ROCm-Build bleibt als Rollback unter /opt/llamacpp.
- Backend: vocab-aware Speculative Decoding. services/gguf_meta.py liest den
Tokenizer-Fingerprint (model/pre/n_vocab) direkt aus dem GGUF-Header (ohne Modell-Load);
register_model + migrate_config haengen nur VOCAB-KOMPATIBLE Drafts an (inkl. --spec-type,
das in dieser llama.cpp-Generation noetig ist). Neue Endpoints /api/models/drafts + /{id}/draft.
- Frontend: idiotensichere Spec-Draft-UI (SpecDraftModal) - nur kompatible Drafts waehlbar,
inkompatible gesperrt mit Begruendung; SPEC/SPEC?-Badge nach echtem Aktiv-Status; Rolle in AddModel.
- maintenance.py: Engine-Update-Quelle -> ggml-org/llama.cpp (Build-Nummer-Vergleich),
ENGINE_PATH=/opt/llamacpp-vulkan.
- Startup-Warmup der brains (deploy/warmup.sh, self-detaching ExecStartPost) + deploy/provision-engine.sh.
- Cleanup: tote LiteLLM gateway/config.yaml + alle Referenzen (config.py/backup.py/backup.sh) entfernt;
README + docs/memory aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
