bc60c6fefc
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>
86 lines
4.9 KiB
Markdown
86 lines
4.9 KiB
Markdown
# 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). 2–3 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
|