Autonomie E6+DoD6: Werkstatt-Skill (wartung) + RUNBOOK

- deploy/skills/wartung/SKILL.md: Selbstwartungs-Kreislauf (Worktree -> Patch ->
  Reviewer-Subagent -> Gate -> Telegram-Merge-Vorschlag); Leitplanken hart codiert
  (nie main/merge/deploy/Security-Config); deploy.sh installiert nach ~/.hermes/skills/
- Box hat bewusst KEINE Gitea-Push-Rechte (Token = offener User-Entscheid) -> v1 endet
  beim Merge-Vorschlag mit lokalem Branch
- docs/RUNBOOK.md: 1 Seite Mensch-Anleitung (Telegram-Meldungen, Box tot, Pins,
  einmalige sudo-Session, Automatik-Fahrplan)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-07-02 20:29:19 +02:00
parent dd947298d0
commit ab8d651efc
3 changed files with 119 additions and 0 deletions
+3
View File
@@ -66,6 +66,9 @@ cp "$SRC/deploy/mc2-autoupdate.timer" "$HOME/.config/systemd/user/mc2-autoupdate
# Cron-Job selbst wird EINMALIG registriert (hermes cron create, siehe docs/RUNBOOK.md). # Cron-Job selbst wird EINMALIG registriert (hermes cron create, siehe docs/RUNBOOK.md).
mkdir -p "$HOME/.hermes/scripts" mkdir -p "$HOME/.hermes/scripts"
cp "$SRC/deploy/radar-feed.sh" "$HOME/.hermes/scripts/radar-feed.sh" cp "$SRC/deploy/radar-feed.sh" "$HOME/.hermes/scripts/radar-feed.sh"
# Werkstatt-Skill (Autonomie E6): Selbstwartungs-Kreislauf für Hermes.
mkdir -p "$HOME/.hermes/skills/wartung"
cp "$SRC/deploy/skills/wartung/SKILL.md" "$HOME/.hermes/skills/wartung/SKILL.md"
systemctl --user daemon-reload systemctl --user daemon-reload
systemctl --user enable mission-control-2 >/dev/null 2>&1 || true systemctl --user enable mission-control-2 >/dev/null 2>&1 || true
systemctl --user enable hermes-terminal >/dev/null 2>&1 || true systemctl --user enable hermes-terminal >/dev/null 2>&1 || true
+57
View File
@@ -0,0 +1,57 @@
---
name: wartung
description: "Werkstatt-Kreislauf der AI-Box: einen KLEINEN Wartungsauftrag (Config-Migration, Dependency-Bump, Ein-/Zwei-Datei-Patch) eigenständig umsetzen — Branch im Box-Checkout, Patch, separater Reviewer-Subagent, Gate, Telegram-Merge-Vorschlag. Merge/Deploy NIE selbst."
version: 1.0.0
author: MC2 (Autonomie E6)
platforms: [linux]
metadata:
hermes:
tags: [wartung, werkstatt, maintenance, mc2]
---
# Werkstatt — Selbstwartungs-Kreislauf der Box
Nutze diesen Skill, wenn ein kleiner, klar umrissener Wartungsauftrag für das MC2-Repo
(`~/mission-control-v2`) vorliegt — vom Evolution-Radar oder direkt vom User.
**Scope-Check zuerst:** Klein = Config-Schlüssel-Migration, Dependency-Bump (Lockfile),
Patch in 12 Dateien. Alles Größere (Architektur, mehrere Module, neue Features):
NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
## Leitplanken (nicht verhandelbar)
- NIEMALS auf `main` committen. NIEMALS mergen. NIEMALS deployen oder Dienste neu starten.
- Security-Config ist TABU: keine Tokens, approvals, ufw, sudoers anfassen.
- Die Live-Instanz (`~/mission-control-v2`) bleibt unberührt — gearbeitet wird NUR im Worktree.
- Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der User.
- Gate rot oder Reviewer dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschönigen.
## Ablauf
1. **Worktree anlegen** (Slug = kurzer Kebab-Case-Name des Auftrags):
`cd ~/mission-control-v2 && git fetch origin && git worktree add /tmp/wartung-<slug> -b wartung/<slug> origin/main`
2. **Patch** nur im Worktree. Minimal-invasiv, Stil der umgebenden Datei übernehmen
(deutsche Kommentare, bestehende Muster).
3. **Selbst-Gate** (was zutrifft):
- Python geändert → `python3 -m py_compile <dateien>`
- Shell geändert → `bash -n <dateien>`
- Frontend (`frontend/src/...`) geändert → auf der Box gibt es KEIN Node. Im Vorschlag
ausweisen: „Gate eingeschränkt: tsc/Build läuft erst beim Merge auf dem PC."
- Live-Check: `curl -sf http://127.0.0.1:9001/api/health` (muss grün bleiben — beweist,
dass du die Live-Instanz nicht angefasst hast).
4. **Reviewer-Subagent** (frischer Kontext, Worker/Reviewer-Muster): `delegate_task` mit
role=leaf. Gib ihm den AUFTRAG im Wortlaut + `git diff` des Worktrees. Seine Fragen:
Erfüllt der Diff den Auftrag? Minimal-invasiv? Risiken/Nebenwirkungen? —
Bei berechtigter Kritik: nachbessern (max. 2 Runden), sonst Kritik in den Vorschlag schreiben.
5. **Commit im Worktree:** Message `Werkstatt: <Auftrag kurz>` + 24 Zeilen Was/Warum.
6. **Telegram-Vorschlag** über `bash ~/mission-control-v2/deploy/notify.sh -s "[Werkstatt]" "<text>"`:
Auftrag · geänderte Dateien · Kern des Diffs (25 Zeilen) · Gate-Ergebnis · Reviewer-Urteil ·
Branch-Name · Frage „merge oder verwerfen?"
7. **Nichts löschen:** Worktree + Branch bleiben liegen, bis der User entschieden hat.
## Nach dem User-Entscheid (kommt als neuer Auftrag)
- „verwerfen" → `git worktree remove /tmp/wartung-<slug> --force && git branch -D wartung/<slug>`
- „merge" → heute merged/deployt der PC (die Box hat bewusst keine Gitea-Push-Rechte;
eigener Token = offener User-Entscheid). Sobald der Token existiert: Branch pushen
und den PC-Schritt melden statt ausführen.
+59
View File
@@ -0,0 +1,59 @@
# 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] … merge oder verwerfen?" | Box hat einen Fix vorbereitet | mit „merge" oder „verwerfen" antworten |
## 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)
- **Täglich 03:30** Backup · **So 04:30** Auto-Update (Router→Engine→Hermes) mit Rollback+Pin
- **Monatlich 1., 09:00** Evolution-Radar-Report auf Telegram
## 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
## Einmalige sudo-Session (steht noch aus — schaltet Engine/Router-Auto-Update frei)
ssh hitonabi@192.168.178.151
sudo install -m 0440 -o root -g root ~/mission-control-v2/deploy/sudoers-mc2-autonomie /etc/sudoers.d/mc2-autonomie && sudo visudo -c
sudo apt-get install -y unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl disable --now mission-control.service # alte v1-Leiche entfernen
Bis dahin meldet der So-Lauf Engine/Router-Updates nur („wartet — sudo-Freischaltung fehlt").
## 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