---
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-Checkout unberührt (PFLICHT, zwei Beweise):**
     - `git -C ~/mission-control-v2 status --porcelain -uno` **muss LEER sein** — kein einziges
       geändertes/staged Tracked-File im Live-Checkout. (Nur so ist bewiesen, dass du wirklich
       ausschließlich im Worktree gearbeitet hast; ein grüner Health-curl allein reicht NICHT,
       weil der laufende Dienst den alten Code im Speicher hält und eine schmutzige Datei auf
       der Platte nicht bemerkt — genau diese Lücke ist am 03.07. aufgefallen.)
     - `curl -sf http://127.0.0.1:9001/api/health` muss grün bleiben.
     - Ist der `git status` NICHT leer: du hast die Leitplanke verletzt → die fremden Änderungen
       im Live-Checkout mit `git -C ~/mission-control-v2 checkout -- <datei>` zurücknehmen (deine
       Arbeit liegt ja sicher im Worktree/Branch) und im Vorschlag ehrlich erwähnen.
4. **Reviewer-Subagent** (frischer Kontext, Worker/Reviewer-Muster): `delegate_task` mit
   role=leaf. Gib ihm den AUFTRAG im Wortlaut + `git diff` des Worktrees.
   **Kernauftrag an den Reviewer (nicht „sieht plausibel aus", sondern BEWEISEN):**
   - **Stelle den konkreten Fehlerfall aus dem Auftrag nach.** Nimm eine realistische
     Beispiel-Eingabe, die den beschriebenen Bug AUSLÖST, und spiele den geänderten Code
     Schritt für Schritt (oder als kleiner Test) durch: Behebt der Diff DIESEN Fall wirklich?
     (Am 03.07. hat ein Reviewer einen Patch durchgewunken, der den eigentlichen Fehlerfall
     gar nicht traf — genau das darf nicht mehr passieren.)
   - **Suche aktiv nach dem Fall, in dem der Patch versagt** (Randfälle, leere/kurze Eingaben,
     andere Formate). Findest du einen → Kritik.
   - Erst danach die Standardfragen: Minimal-invasiv? Nur der beauftragte Scope? Nebenwirkungen?
   Bei berechtigter Kritik: nachbessern (max. 2 Runden), sonst Kritik in den Vorschlag schreiben.
   Schreibe das Reviewer-Urteil im Telegram-Vorschlag KONKRET aus („durchgespielt mit Eingabe X →
   Ergebnis Y"), nicht nur „Reviewer: ok".
5. **Commit im Worktree** (Message `Werkstatt: <Auftrag kurz>` + 2–4 Zeilen Was/Warum),
   dann **Branch zu Gitea pushen:** `git push origin wartung/<slug>` (die Box hat einen
   eigenen scoped Token, seit 02.07. hinterlegt). Push fehlgeschlagen? Nicht schlimm —
   Branch bleibt lokal, im Vorschlag erwähnen.
6. **Telegram-Vorschlag** über `bash ~/mission-control-v2/deploy/notify.sh -s "[Werkstatt]" "<text>"`:
   In LUCYS Stimme an den Commander (nicht als anonymer Job): erst 1–2 Sätze, was gemacht wurde
   und was er jetzt entscheiden soll — dann knapp: geänderte Dateien · Kern des Diffs ·
   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>`
  (+ Remote-Branch löschen, falls gepusht: `git push origin --delete wartung/<slug>`)
- „merge" → das Mergen nach main + Deploy macht der PC/Claude (Frontend-Builds gibt es
  nur dort). Du pushst NIE nach main — auch nicht mit Token.