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>

deploy/skills/wartung/SKILL.md

@@ -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 1–2 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>` + 2–4 Zeilen Was/Warum.
+6. **Telegram-Vorschlag** über `bash ~/mission-control-v2/deploy/notify.sh -s "[Werkstatt]" "<text>"`:
+   Auftrag · geänderte Dateien · Kern des Diffs (2–5 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.