Werkstatt haerten (0k): Reviewer muss Fehlerfall nachstellen, Gate prueft Live-Checkout

Zwei Befunde aus der Gesellenpruefung (03.07.):
- Reviewer-Subagent war zu milde -> Skill fordert jetzt: konkreten Fehlerfall
  nachstellen + aktiv nach Versagen suchen, Urteil konkret ausschreiben.
- "Live unberuehrt" war nur curl-geprueft -> Gate verlangt jetzt zusaetzlich
  git status --porcelain -uno == leer im Live-Checkout.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/skills/wartung/SKILL.md

@@ -37,12 +37,30 @@ NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
    - 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-Check: `curl -sf http://127.0.0.1:9001/api/health` (muss grün bleiben — beweist,
+   - **Live-Checkout unberührt (PFLICHT, zwei Beweise):**
-     dass du die Live-Instanz nicht angefasst hast).
+     - `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. Seine Fragen:
+   role=leaf. Gib ihm den AUFTRAG im Wortlaut + `git diff` des Worktrees.
-   Erfüllt der Diff den Auftrag? Minimal-invasiv? Risiken/Nebenwirkungen? —
+   **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 —