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): 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 "<Projekt> — Etappe <n>: <was>" --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.
• Realitäts-Check zuerst (12.07.2026): Existiert das schon? Selbst-Steckbrief (~/.hermes/state/selbst-steckbrief.md) und Live-System LESEN, bevor du baust. Stellt sich der Auftrag als schon erledigt/überflüssig heraus → ehrlich melden und abbrechen, KEINEN Branch liefern.
• 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): mkdir -p ~/.hermes/worktrees && cd ~/mission-control-v2 && git fetch origin && git worktree add ~/.hermes/worktrees/wartung-<slug> -b wartung/<slug> origin/main (Worktrees NIE unter /tmp — ueberlebt keinen Reboot, Review-Befund 15.07.)

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. 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):
   <der Auftrag>
   
   GIT-DIFF des Worktrees:
   <git -C ~/.hermes/worktrees/wartung-<slug> 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: <ABGELEHNT | FREIGABE-MIT-VORBEHALT | FREIGABE>. (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: <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 ~/.hermes/worktrees/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.