HitonabiandClaude Opus 5
84dc34c0a3
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>
65 lines
2.9 KiB
Bash
65 lines
2.9 KiB
Bash
#!/bin/bash
|
|
set -e
|
|
|
|
echo "Starte MC2 Deployment..."
|
|
|
|
# 1. Neuesten Code holen
|
|
git pull origin main
|
|
|
|
|
|
# 2. Abhängigkeiten prüfen (falls sich was geändert hat)
|
|
echo "Aktualisiere Python Abhängigkeiten..."
|
|
backend/.venv/bin/pip install -r backend/requirements.txt
|
|
|
|
# 3. Llama-Swap Konfiguration prüfen und synchronisieren
|
|
#
|
|
# ‼️ ACHTUNG (27.08.2026): /etc/llama-swap/config.yaml ist die LEBENDE Wahrheit — MC2
|
|
# schreibt sie selbst (backend/services/llamaswap.py::write_config), sobald jemand über
|
|
# die Oberfläche ein Modell hinzufügt oder eine Rolle ändert. deploy/llama-swap.config.yaml
|
|
# ist nur ein Abzug und hinkt regelmäßig hinterher (aktuell fehlt ihm z. B. der
|
|
# `kritiker`/Devstral-Eintrag, den STACK.md und der Modell-Katalog voraussetzen).
|
|
# Bis hierher wurde die Live-Datei kommentarlos mit dem Abzug überschrieben — alles per
|
|
# UI Hinzugefügte war nach jedem Deploy weg. Jetzt: erst sichern, dann kopieren, und die
|
|
# Abweichung sichtbar machen. MC_DEPLOY_SKIP_SWAP_CONFIG=1 überspringt den Schritt ganz.
|
|
if ! cmp -s deploy/llama-swap.config.yaml /etc/llama-swap/config.yaml; then
|
|
if [ "${MC_DEPLOY_SKIP_SWAP_CONFIG:-0}" = "1" ]; then
|
|
echo "Llama-Swap Konfiguration weicht ab — uebersprungen (MC_DEPLOY_SKIP_SWAP_CONFIG=1)."
|
|
else
|
|
SWAP_BAK="/etc/llama-swap/config.yaml.bak-$(date +%Y%m%d-%H%M%S)"
|
|
echo "Llama-Swap Konfiguration hat sich geändert."
|
|
echo " Abweichung (live -> Repo-Abzug):"
|
|
diff -u /etc/llama-swap/config.yaml deploy/llama-swap.config.yaml | head -40 || true
|
|
echo " Sichere die laufende Datei nach $SWAP_BAK"
|
|
# NOPASSWD für llama-swap Neustart ist vorausgesetzt (siehe AGENTS.md)
|
|
sudo cp /etc/llama-swap/config.yaml "$SWAP_BAK"
|
|
sudo cp deploy/llama-swap.config.yaml /etc/llama-swap/config.yaml
|
|
sudo systemctl restart llama-swap
|
|
echo " Rueckweg bei Verlust: sudo cp $SWAP_BAK /etc/llama-swap/config.yaml"
|
|
fi
|
|
fi
|
|
|
|
# 4. Systemd Units neu laden (falls sich .service Dateien geändert haben)
|
|
systemctl --user daemon-reload
|
|
|
|
# 4.5 Hermes Skills synchronisieren
|
|
echo "Synchronisiere Hermes Skills..."
|
|
mkdir -p ~/.hermes/skills
|
|
# Kopiere alle Skills aus dem Repo, ersetze - durch _ in den Ordnernamen für Hermes Kompatibilität
|
|
for skill_dir in deploy/skills/*; do
|
|
if [ -d "$skill_dir" ]; then
|
|
skill_name=$(basename "$skill_dir" | tr '-' '_')
|
|
mkdir -p ~/.hermes/skills/"$skill_name"
|
|
cp -r "$skill_dir"/* ~/.hermes/skills/"$skill_name"/
|
|
fi
|
|
done
|
|
|
|
# 5. Dienste neu starten
|
|
# ‼️ mc2-steward gehoert hier dazu: er laeuft aus DEMSELBEN Checkout (backend/steward.py).
|
|
# Ohne ihn lief der Waechter-Prozess nach jedem Deploy mit dem alten Code weiter — der
|
|
# Neustart wurde 27.08.2026 nachgetragen. `--user restart` auf einer nicht installierten
|
|
# Unit ist folgenlos, darum ohne Vorabpruefung.
|
|
echo "Starte Backend neu..."
|
|
systemctl --user restart mc2-gateway.service mission-control-2.service mc2-steward.service
|
|
|
|
echo "✅ Deployment erfolgreich abgeschlossen!"
|