Die Vorschlags-Inbox (routers/services auftragsbuch, AuftragsbuchView, /auftraege, Cockpit- Kachel + Handlungsbedarf-Eintrag, deploy/auftrag-annehmen.sh, lucy-annahme.sh, bagatell- annahme.sh, docs/AUFTRAGSBUCH.md) war seit 02.08.2026 ungenutzt: Kanban-Tools seit 21.08. aus, v3-Umbau lief ueber Branch -> Ampel -> Merge -> deploy.sh, PC-Executor-IP in Box und Config veraltet. Doku behauptete den Karten-Weg trotzdem als Standard. Jetzt: - Cockpit: Kachel "Ideen" (offen/haengend) statt "Auftragsbuch"; Handlungsbedarf zeigt haengende Ideen und springt in die Ideen-Ansicht. - Guide/Schaubild: Kreislauf Idee -> Ideen-Queue -> IDE am PC -> Ampel -> DEIN Merge -> Live. - events.py: kein Auftragsbuch-Fingerprint mehr; config.py: PC_EXECUTOR_URL-Default auf .22. - Skills/Skripte: selbst-inventur ohne Karten-Abschnitt, morning-report nennt offene Branches, konzept-fliessband verweist auf die Ideen-Ansicht. - Doku: STACK "Deploy & Pipeline" = Branch -> Ampel -> User-Merge -> deploy.sh (einziger Weg), GRENZEN/ARBEITSWEISE/FALLEN/README/BEDIENUNG/RUNBOOK/GEMINI_BRIEFING/gitea-workflow angepasst, ZIELBILD Punkt 9, OFFENE-FAEDEN + RAPHAEL.md: erledigt. - Bewusst geblieben: werkstatt-SOUL/projektstart-SOUL (Werkstatt-Persona, eigener Faden), Chronik-Kategorie "auftragsbuch" fuer historische Eintraege. Auf der Box bereits erledigt (Hand): mc2-bagatell.timer deaktiviert + Units archiviert, PC-Executor-URL in ~/.hermes/config.yaml auf .22. Baut auf wartung/lucy-stimme-proxy-raphael auf (Proxy /api/lucy/stimme/*). Gates: eslint 0 Fehler, vitest 59/59, tsc + vite build gruen, frontend/dist committet, py_compile gruen. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.9 KiB
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 | Branch auf Gitea ansehen → Ampel grün? → selbst auf main mergen → deploy.sh |
Box tot / Weboberfläche weg?
- 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:9001aufrufen. - Immer noch tot → per SSH (PC, PowerShell):
ssh hitonabi@192.168.178.151dann: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). - 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.batdoppelklicken. - 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:
- Notfall: Die Box ist kaputt UND die Schritte unter „Box tot?" (oben) haben nicht geholfen — oder Lucy/Telegram melden wiederholt „KRITISCH".
- 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