--- 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- -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. **Reviewer-Subagent** (frischer Kontext, Worker/Reviewer-Muster): `delegate_task` mit role=leaf. Gib ihm den AUFTRAG im Wortlaut + `git diff` des Worktrees. **FREMD-MODELL-PFLICHT (Härtung 04.07.):** Der Reviewer MUSS auf einem ANDEREN Modell laufen als der Worker, der den Patch 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. Aktueller Aufbau: Worker = `hermes` (Qwen3.6-35B, Default der Wartungs-Cron), Reviewer-Subagent = `heavy` (gpt-oss-120b) über `delegation.model` in `~/.hermes/config.yaml`. Ein per-Aufruf-Modell gibt `delegate_task` NICHT her — die Trennung hängt allein an dieser Config. **Prüfe die Trennung aktiv:** Läuft der Werkstatt-Worker ausnahmsweise selbst auf `heavy` (oder ist `delegation.model` auf denselben Wert wie der Worker gesetzt), dann sind Worker und Reviewer DASSELBE Modell → die Fremd-Prüfung ist wertlos. In dem Fall NICHT still weitermachen: im Telegram-Vorschlag „⚠ Reviewer = Worker-Modell, Fremd-Prüfung nicht gegeben" ausweisen und das als offene Kritik behandeln (nicht als Freigabe). Sag dem Reviewer im Auftrag ausdrücklich: **„Du bist ein anderes Modell als der Autor. Vertraue seiner Begründung NICHT — leite den Fehlerfall selbst aus der ursprünglichen Bug-Beschreibung ab und prüfe unabhängig."** **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? - **Eigenes Raster, nicht die Erzählung des Autors abnicken:** Der Reviewer baut den fehlschlagenden Fall SELBST aus der Bug-Beschreibung, statt die Testfälle des Autors zu übernehmen. Er argumentiert von der Eingabe her, nicht vom Diff her. **REPRODUZIERT-ODER-ABGELEHNT (harte Regel):** Ein Freispruch ist nur gültig, wenn der Reviewer den konkreten Übergang belegt — „Eingabe X → VOR Patch: Y (Bug sichtbar) → NACH Patch: Z (behoben)". Ein „sieht gut aus / keine Nebenwirkungen" OHNE diesen reproduzierten Vorher/Nachher-Beleg zählt NICHT als Freigabe, sondern als offene Kritik (Branch bleibt liegen, im Vorschlag ehrlich vermerken). So kann ein Durchwinken gar nicht erst passieren. 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: ` + 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.