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>
122 lines
6.7 KiB
Bash
122 lines
6.7 KiB
Bash
#!/usr/bin/env bash
|
|
# Post-Update-Check nach einem Hermes-Agent-Update: laeuft unser "Gehirn" noch?
|
|
# Exit 0 = alles ok, sonst 1 -> der Job wird im UI rot, damit ein kaputtes Gehirn auffaellt.
|
|
#
|
|
# WICHTIG (27.08.2026) - VIER TOTE CHECKS ENTFERNT: bis hierher prueften die ersten Bloecke
|
|
# den abgeloesten Gedaechtnis-Sidecar (:8765), MC2s /api/memory und das zugehoerige
|
|
# Hermes-Plugin. Alle drei fielen am 07.08. weg (docs/wissen/VERDIKTE.md) - die Checks KONNTEN nicht
|
|
# mehr gruen werden. Folge: jedes Hermes-Update endete rot und wurde von autoupdate.sh
|
|
# zurueckgerollt. Kein Ersatz-Check auf Hermes native Gedaechtnis, weil es dafuer keinen
|
|
# nachgemessenen Endpunkt gibt - geraten waere eine Fassade. Der Tool-Smoke weiter unten
|
|
# laeuft ohnehin durch den ECHTEN Agenten und faengt ein kaputtes Gehirn.
|
|
set -uo pipefail
|
|
|
|
MC_URL="${MC_URL:-http://127.0.0.1:9001}"
|
|
HERMES="${HERMES_HOME:-$HOME/.hermes}"
|
|
fail=0
|
|
|
|
echo "=== Hermes Post-Update: Gehirn-Check ==="
|
|
|
|
# --- Hermes-Runtime-Patch-Traeger (20.07.2026): ein Update setzt den Quellbaum ---
|
|
# --- zurueck → unsere Fixes (needs_input-wartet, Startreife-Gate, Orphan-Guard, ---
|
|
# --- Kontext-Vererbung, Etappen-Kette) hier RE-eintragen. Exit 10 = etwas neu ---
|
|
# --- angewandt → Gateway neu laden; Exit 1 = ein Patch passt nicht mehr → ROT. ---
|
|
PATCH_APPLY="${MC2_SRC:-$HOME/mission-control-v2}/deploy/hermes-patches/apply.py"
|
|
if [ -f "$PATCH_APPLY" ]; then
|
|
python3 "$PATCH_APPLY" >/dev/null 2>&1; _prc=$?
|
|
if [ "$_prc" -eq 10 ]; then
|
|
systemctl --user try-restart hermes-gateway >/dev/null 2>&1 || true
|
|
echo "PASS · Hermes-Runtime-Patches nach Update RE-angewandt (Gateway neu geladen)"
|
|
elif [ "$_prc" -eq 0 ]; then
|
|
echo "PASS · Hermes-Runtime-Patches unveraendert vorhanden"
|
|
else
|
|
echo "FAIL · Hermes-Runtime-Patches: ein Patch passt nicht mehr zum aktualisierten Quellcode — pruefen"; fail=1
|
|
fi
|
|
else
|
|
echo "WARN · hermes-patches/apply.py nicht gefunden ($PATCH_APPLY)"
|
|
fi
|
|
|
|
# --- Config-Drift-Wächter (Lehre aus v0.18, 02.07.2026): Hermes fällt bei unbekannten ---
|
|
# --- Config-Werten STILL auf Defaults zurück (approvals.mode 'auto' -> manual -> alle ---
|
|
# --- Tools hingen in pending_approval). Solche Warnungen müssen den Job ROT machen. ---
|
|
if journalctl --user -u hermes-gateway --since "-3 minutes" --no-pager -o cat 2>/dev/null \
|
|
| grep -iE "Unknown [a-z._]+ '|deprecated .*(setting|option|config)|defaulting to|invalid config" \
|
|
| grep -v "check_fn" | head -5 | tee /tmp/hermes-config-warnings.txt | grep -q .; then
|
|
echo "FAIL · Config-Warnungen nach Update (siehe oben) — Config an neue Version anpassen!"; fail=1
|
|
else
|
|
echo "PASS · keine Config-Drift-Warnungen im Gateway-Log"
|
|
fi
|
|
|
|
# --- Tool-Smoke: ein harmloser terminal-Befehl durch den echten Agenten. Fängt kaputte ---
|
|
# --- Approval-/Tool-Ketten (Antwort muss kommen und darf nicht in pending_approval hängen). ---
|
|
API_KEY="$(grep -E '^API_SERVER_KEY=' "$HERMES/.env" 2>/dev/null | cut -d= -f2- | tr -d '"' | tr -d "'")"
|
|
if [ -n "$API_KEY" ]; then
|
|
# Mit Retry — GENAU wie der Voice-Smoke darunter, und aus demselben Grund: direkt nach
|
|
# einem Update ist das Modell kalt. Ein Kaltstart kostet ~20-30 s Laden PLUS ~37 s
|
|
# Prefill für Hermes' ~70-KB-Systemprompt (33 Tool-Schemas) — zusammen mit zwei
|
|
# Inferenz-Runden sprengt das die 90 s des ersten Versuchs. Warm gemessen: 12 s.
|
|
# Ein Versuch allein war ein Fehlalarm-Generator (live erlebt 25.07., Job faf1137a).
|
|
TOOL_RESP=""
|
|
for try in 1 2 3; do
|
|
TOOL_RESP=$(curl -sf -m 120 -X POST "http://127.0.0.1:8642/v1/chat/completions" \
|
|
-H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
|
|
-H "X-Hermes-Session-Id: postcheck-tool-smoke-$try" \
|
|
-d '{"model":"hermes","stream":false,"messages":[{"role":"user","content":"Führe im Terminal exakt den Befehl echo postcheck-ok aus und gib mir nur dessen Ausgabe zurück."}]}' 2>/dev/null)
|
|
echo "$TOOL_RESP" | grep -qi "postcheck-ok" && break
|
|
[ "$try" -lt 3 ] && sleep 10
|
|
done
|
|
if echo "$TOOL_RESP" | grep -qi "postcheck-ok"; then
|
|
echo "PASS · Tool-Smoke (terminal via Agent) liefert Ergebnis (Versuch $try)"
|
|
elif echo "$TOOL_RESP" | grep -qi "pending_approval"; then
|
|
echo "FAIL · Tool-Smoke hängt in pending_approval (approvals.mode prüfen!)"; fail=1
|
|
else
|
|
echo "FAIL · Tool-Smoke ohne verwertbares Ergebnis: $(echo "$TOOL_RESP" | head -c 200)"; fail=1
|
|
fi
|
|
else
|
|
echo "SKIP · Tool-Smoke (kein API_SERVER_KEY in $HERMES/.env gefunden)"
|
|
fi
|
|
|
|
# --- Voice-Smoke: Lucys Sprech-Pfad streamt. Mit Retry: direkt nach dem Gateway-Neustart ---
|
|
# --- zahlt der erste Turn den Session-Kaltstart (Prefill) — ein Versuch wäre ein Fehlalarm. ---
|
|
# WICHTIG: Subshell OHNE pipefail — `head -c 50` schließt die Pipe früh, curl endet mit 23
|
|
# (SIGPIPE) und pipefail würde den bestandenen Check als FAIL werten (live diagnostiziert).
|
|
voice_ok=0
|
|
for try in 1 2 3; do
|
|
if ( set +o pipefail; curl -sf -m 45 -N -X POST "$MC_URL/api/voice/chat" -H "Content-Type: application/json" \
|
|
-d '{"text":"Sag nur ok.","session_id":"postcheck-voice-smoke"}' 2>/dev/null | head -c 50 | grep -q "data:" ); then
|
|
voice_ok=1; break
|
|
fi
|
|
sleep 8
|
|
done
|
|
if [ "$voice_ok" -eq 1 ]; then
|
|
echo "PASS · Voice-Smoke (Lucys /api/voice/chat streamt, Versuch $try)"
|
|
else
|
|
echo "FAIL · Voice-Smoke: /api/voice/chat streamt nicht (3 Versuche)"; fail=1
|
|
fi
|
|
|
|
# --- Browser-Tool: agent-browser überlebt das Update? (Vorfall 15./16.07.2026: das ---
|
|
# --- npm ci des Updates bog ~/.local/bin/agent-browser per postinstall auf ---
|
|
# --- node_modules/ um und löschte das Paket im selben Lauf → toter Link, jedes ---
|
|
# --- „Website öffnen" starb still als „Failed to open".) Heilung direkt hier, denn ---
|
|
# --- genau NACH einem Update entsteht der Bruch; try-restart räumt den ---
|
|
# --- „nicht installiert"-Cache, den browser_tool pro Prozess hält. ---
|
|
export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"
|
|
AB_LINK="$HOME/.local/bin/agent-browser"
|
|
AB_GOOD="$HOME/.local/lib/node_modules/agent-browser/bin/agent-browser-linux-x64"
|
|
if "$AB_LINK" --version >/dev/null 2>&1; then
|
|
echo "PASS · Browser-Tool (agent-browser erreichbar)"
|
|
elif [ -x "$AB_GOOD" ] && "$AB_GOOD" --version >/dev/null 2>&1 \
|
|
&& ln -sfn "$AB_GOOD" "$AB_LINK" && "$AB_LINK" --version >/dev/null 2>&1; then
|
|
systemctl --user try-restart hermes-gateway hermes-builtin-ui >/dev/null 2>&1 || true
|
|
echo "GEHEILT · Browser-Tool: toter agent-browser-Link nach Update neu gesetzt (Dienste neu gestartet)"
|
|
else
|
|
echo "FAIL · Browser-Tool: agent-browser nicht lauffähig (npm install -g agent-browser && agent-browser install --with-deps)"; fail=1
|
|
fi
|
|
|
|
if [ "$fail" -eq 0 ]; then
|
|
echo "=== GEHIRN OK ✓ ==="
|
|
else
|
|
echo "=== GEHIRN-CHECK FEHLGESCHLAGEN — bitte prüfen ==="
|
|
fi
|
|
exit "$fail"
|