--- 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): NICHT pauschal ablehnen, sondern den **Etappen-Weg** gehen (Großbau-Entscheid 10.07.2026): einen Etappen-Plan in den Vorschlag schreiben (jede Etappe für sich lauffähig + annehmbar) und NUR Etappe 1 als eigenen Vorschlags-Branch bauen; Folge-Etappen als neue Aufgaben in die Ideen-Queue (`hermes kanban create " — Etappe : " --triage`). NIE auf unangenommene Branches aufbauen — erst wenn die Vor-Etappe in main ist, kommt die nächste. ## 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. - **Hermes-first (10.07.2026):** Bevor du NEUE Infrastruktur baust oder vorschlägst (Skript, Dienst, Tool, Cron), prüfe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte schauen (`~/wissens-vault/eigenbau-landkarte.md`: Eigenbauten ↔ nativ, Verdikte), notfalls `bash -lc 'hermes --help'`. Den Prüf-Befund in den Vorschlag schreiben („nativ vorhanden: nein/ja, weil …"). Weniger Eigenkreationen = weniger Wartungsberg. - 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- -b wartung/ 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 ` - Shell geändert → `bash -n ` - 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 -- ` zurücknehmen (deine Arbeit liegt ja sicher im Worktree/Branch) und im Vorschlag ehrlich erwähnen. 4. **Fremd-Modell-Review über `fremdblick.sh`** (Härtung 04.07., korrigiert 04.07.). Der Patch muss von einem ANDEREN Modell gegengelesen werden als dem, das ihn geschrieben hat. Grund: „Ein Agent, der seine eigenen Hausaufgaben benotet, stimmt sich meistens selbst zu" — genau das ist am 03.07. passiert. Zwei verschiedene Modelle teilen NICHT dieselben blinden Flecken. **NICHT `delegate_task` benutzen.** `delegate_task` läuft über `delegation.model` (= `heavy` / gpt-oss), und heavy ist als Kritiker DOPPELT disqualifiziert: (a) Hermes screent Delegations- Ziele gegen `MINIMUM_CONTEXT_LENGTH=64000`, heavy hat nur 32k → fällt raus; (b) heavy (60 GB) stirbt beim Laden neben dem VL-30B-Warm-Set (Health-Check-Timeout). Die Fremd-Prüfung würde dann still ausfallen. Stattdessen den bereitgestellten Ein-Schuss-Kritiker nutzen: ``` printf '%s' "AUFTRAG (Bug-Beschreibung im Wortlaut): GIT-DIFF des Worktrees: diff origin/main>" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh ``` Das läuft auf `Qwen3-Coder-Next` (128k, code-stark, anderes Modell als der Qwen3.6-Worker, lädt klein neben dem Warm-Set) mit einem Code-Review-Raster. **Warte auf die Ausgabe.** Der Kritiker leitet den Fehlerfall SELBST aus der Bug-Beschreibung ab (glaubt dem Autor nicht), spielt den geänderten Code durch und beginnt mit `URTEIL: `. (E2E geprüft 04.07.: kaputter Patch → ABGELEHNT mit Reproduktion; sauberer Fix → FREIGABE.) **REPRODUZIERT-ODER-ABGELEHNT (harte Regel, im Raster verankert):** Eine Freigabe ist nur gültig, wenn der Kritiker den konkreten Übergang belegt — „Eingabe X → VOR Patch: Y (Bug sichtbar) → NACH Patch: Z (behoben)". Ein „sieht gut aus" OHNE diesen Vorher/Nachher-Beleg = ABGELEHNT. So kann ein Durchwinken gar nicht erst passieren. **Umgang mit dem Urteil:** - `ABGELEHNT` oder `FREIGABE-MIT-VORBEHALT` mit berechtigter Kritik → nachbessern (max. 2 Runden), dann erneut prüfen. Bleibt es kritisch: die Kritik in den Vorschlag schreiben, Branch bleibt liegen, Entscheidung dem Commander. - `FREMDBLICK FEHLGESCHLAGEN`/`ABGESCHNITTEN` → einmal wiederholen; klappt es nicht, im Vorschlag ehrlich „⚠ Fremd-Review fiel aus — Patch UNGEPRÜFT" vermerken (NICHT als Freigabe behandeln). Der Ein-Schuss-Kritiker hand-simuliert (führt keinen Code aus) — für kleine 1–2-Datei-Patches reicht das zusammen mit dem Selbst-Gate (py_compile/bash -n) aus Schritt 3. - Schreibe das Urteil im Telegram-Vorschlag KONKRET aus („durchgespielt mit Eingabe X → Ergebnis Y"), nicht nur „Reviewer: ok". 5. **Commit im Worktree** (Message `Werkstatt: ` + 2–4 Zeilen Was/Warum), dann **Branch zu Gitea pushen:** `git push origin wartung/` (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]" ""`: 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- --force && git branch -D wartung/` (+ Remote-Branch löschen, falls gepusht: `git push origin --delete wartung/`) - „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.