Files
mission-control-v2/docs/RUNBOOK.md
Hitonabi bc60c6fefc Betriebs-Luecken: Restore-Probe, Venv-Audit, Disk-Waechter, PC-Watch
Scope-Entscheid 17.07.: MC2 bleibt Box-Zentrale (KEINE Homelab-Zentrale) -
Infra-Radar (Proxmox/PBS/QNAP/Gitea) geht als eigenes Projekt an Lucys Queue.
- restore-probe.sh (Cron 1. d. M. 06:40, no-agent): stellt WIRKLICH wieder her -
  PBS-Canary aus hermes.pxar (selektiv via --pattern, sudo-frei ueber die
  User-Unit-Zugaenge) + Tarball-Probe + Frische-Check <36h; Erstlauf-Fallbacks
  (llamaswap.pxar / Kern-Datei) bis der Canary in den Sicherungen ankommt.
- venv-audit.sh (Cron 2. d. M. 06:40, no-agent): pip outdated + pip-audit-CVEs
  fuer mem0-/voice-venv ueber eigenes Audit-venv; Funde -> Kanban-Karte je Monat,
  Update bleibt Commander-Entscheid.
- self-smoke: Disk-Waechter (Check 7, Schwelle 85%, nennt die groessten Brocken).
- Trend-Radar-Watchlist: neue Typen github_release_major + pypi; Eintraege
  electron-major (PC-Shell auf 33!) und pocket-tts (PyPI-Versionswatch).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 16:50:48 +02:00

4.9 KiB
Raw Permalink Blame History

RUNBOOK — Die Box in 1 Seite (für Menschen, ohne KI-Hilfe)

Grundsatz: Die Box wartet sich selbst. Du bekommst Telegram-Nachrichten und antwortest höchstens „mach". Dieses Blatt ist NUR für den Fall, dass etwas klemmt.

Was die Telegram-Meldungen bedeuten

Meldung Bedeutung Dein Handgriff
„… aktualisiert … grün" Update eingespielt, alles geprüft keiner
„… zurückgerollt … GEPINNT" Update war schlecht, alte Version läuft wieder keiner (läuft stabil weiter)
„KRITISCH: …" Update UND Rollback kaputt siehe „Box tot?" unten
🛰️ Evolution-Radar …" monatlicher Chancen-Report lesen; bei Interesse „mach" antworten
„[Werkstatt] … Vorschlag liegt bereit" Box hat einen Fix vorbereitet im Web-UI → Auftragsbuch → Karte ansehen → „Annehmen" oder „Ablehnen" klicken

Box tot / Weboberfläche weg?

  1. Strom/Netz prüfen, dann Box einmal neu starten (Power-Knopf). Alles startet von selbst (systemd, reboot-fest). 23 Minuten warten, dann http://192.168.178.151:9001 aufrufen.
  2. Immer noch tot → per SSH (PC, PowerShell): ssh hitonabi@192.168.178.151 dann: bash ~/mission-control-v2/deploy/restore.sh (nimmt automatisch das letzte Backup, liegt in /srv/models/mc2-backups/, 14 Tage Vorrat, täglich 03:30 Uhr).
  3. Totalschaden (neue Platte/Hardware) → docs/DISASTER_RECOVERY.md (Bootstrap von Null).

Lucy (am PC)

  • Start: Desktop-Verknüpfung „Lucy" (startet den eingefrorenen Produktiv-Build).
  • Hängt? F:\Coding Stuff\lucy\lucy-desktop\Lucy-Neustart.bat doppelklicken.
  • Lucy ist EINGEFROREN — Änderungen macht nur die Werkstatt (Telegram-Vorschlag abwarten).

Automatik-Fahrplan (läuft ohne dich)

  • Nachts: 03:15 Traum (Wissens-Vault) · 03:30 Backup · 03:50 PBS-Backup · 04:30 Chef-Gutachter (Morgenlage) · 07:15 Selbsttest · 08:00 Daily-Briefing
  • So 04:30 Auto-Update (Router→Engine→Hermes) mit Rollback+Pin-Fangnetz (dein Ok 10.07.; manuell geht's jederzeit über den Wartungs-Drawer)
  • Mo 05:15 Release-Radar (Hermes-Neuerungen) · Monatlich 1., 09:00 Monats-Review (Evolution-Radar + Selbstkritik) auf Telegram
  • Sa 05:15 Trend-Radar (misst alle Modelle, vergleicht neue Engine-Builds, sucht bessere Modell-Kandidaten; beobachtet auch Electron/pocket-tts für den PC) · So 01:00 Prüfstand (testet gefundene Kandidaten nachts mit echten Aufgaben durch — das Ergebnis kommt als Karte, DU entscheidest über Wechsel)
  • Monatlich 1., 06:40 Restore-Probe (stellt eine Datei WIRKLICH aus PBS + Tarball wieder her — meldet laut, falls ein Backup nicht zurückkommt) · Monatlich 2., 06:40 Venv-Audit (prüft die Python-Nebendienste auf bekannte Sicherheitslücken → Karte)

Pinnwand: eine Ebene ist „GEPINNT" — was heißt das?

Ein Update hat den Selbsttest gerissen; die Box bleibt bewusst auf der alten Version. Das ist ein STABILER Dauerzustand, kein Fehler. Pin ansehen / lösen (per SSH):

cat /srv/models/mc2-pins.json
jq 'del(.hermes)' /srv/models/mc2-pins.json > /tmp/p && mv /tmp/p /srv/models/mc2-pins.json
# (statt .hermes: .engine oder .swap) — nächster So-Lauf versucht das Update erneut

Wann Gemini rufen (der Notfall- und Review-Partner)

Seit dem Claude-Abo-Ende ist Gemini (in der Antigravity-App am PC) dein externer Helfer. Du brauchst ihn NUR in zwei Fällen — den Alltag macht die Box selbst:

  1. Notfall: Die Box ist kaputt UND die Schritte unter „Box tot?" (oben) haben nicht geholfen — oder Lucy/Telegram melden wiederholt „KRITISCH".
  2. Außen-Review: Du willst einen Fremd-Blick auf die Arbeit der Box (z. B. alle paar Monate oder vor einem großen Umbau).

So rufst du ihn: Antigravity öffnen → Projektordner F:\Coding Stuff\mission-control-2 → als erste Nachricht schreiben: „Lies docs/GEMINI_BRIEFING.md und dann [dein Problem]." Für ein Review stattdessen: „Lies docs/GEMINI_BRIEFING.md und führe das Review aus docs/ANTIGRAVITY_REVIEW.md durch."

Grenzen (stehen auch in seinem Briefing): Gemini schlägt vor, DU klickst/entscheidest. Er darf Security-Sachen nur melden, nie ändern. Wenn er etwas über die Box behauptet, darf er es nur nach echtem Test behaupten — im Zweifel nachfragen „hast du das gemessen?".

Einmalige sudo-Session — erledigt (02.07.2026)

Sudo-Freischaltung für Engine/Router-Updates, unattended-upgrades und v1-Aufräumen sind durch (/etc/sudoers.d/mc2-autonomie liegt). Nichts mehr zu tun.

Nützliche Handgriffe (SSH)

curl -s http://127.0.0.1:9001/api/health          # Gesamtzustand (brain ready?)
bash ~/mission-control-v2/deploy/autoupdate.sh    # Update-Lauf sofort statt Sonntag
bash ~/mission-control-v2/deploy/notify.sh "test" # Meldeweg testen (muss auf Telegram ankommen)
tail ~/mc2-notify.log                             # was wurde zuletzt gemeldet