mission-control-v2/deploy/skills/wartung/SKILL.md

name, description, version, author, platforms, metadata

name	description	version	author	platforms	metadata
wartung	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.	1.0.0	MC2 (Autonomie E6)	linux	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.