Werkstatt-Reviewer: Fremd-Kritik ueber fremdblick.sh statt kaputter heavy-Delegation

Das in Haertung 1b eingefuehrte Fremd-Modell-Review delegierte per delegation.model
an heavy (gpt-oss) — das aber als Kritiker DOPPELT disqualifiziert ist: Hermes'
MINIMUM_CONTEXT_LENGTH=64000 screent den 32k-heavy als delegate_task-Ziel raus, UND
heavy (60 GB) stirbt beim Laden neben dem VL-30B-Warmset (Health-Check-Timeout).
Die Fremd-Pruefung konnte damit im Werkstatt-Alltag STILL ausfallen (Durchwink-Gefahr,
genau das, was 1b verhindern sollte).

- deploy/skills/wartung/SKILL.md Schritt 4: statt delegate_task nun
  `FREMDBLICK_MODE=code fremdblick.sh` (Qwen3-Coder-Next, 128k, anderes Modell als der
  Qwen3.6-Worker, laedt klein). REPRODUZIERT-ODER-ABGELEHNT bleibt (im Raster verankert),
  3-Wege-Urteil ABGELEHNT/FREIGABE-MIT-VORBEHALT/FREIGABE, Fallback bei Ausfall = UNGEPRUEFT.
- deploy/fremdblick.sh: FREMDBLICK_MODE=code (Code-Review-Raster + Coder-Next) neben dem
  Default prose-Raster (Dreaming, unveraendert).

E2E gegen die Box verifiziert: kaputter Patch (falsche Bedingung) -> ABGELEHNT mit
konkreter Reproduktion; sauberer Fix (Leerlisten-Guard) -> FREIGABE. Kritiker diskriminiert.

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

deploy/skills/wartung/SKILL.md

@@ -47,47 +47,47 @@ NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
      - 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.
+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.
 
-   **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."**
+   **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:
 
-   **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.
+   ```
+   printf '%s' "AUFTRAG (Bug-Beschreibung im Wortlaut):
+   <der Auftrag>
 
-   **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.
+   GIT-DIFF des Worktrees:
+   <git -C /tmp/wartung-<slug> diff origin/main>" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh
+   ```
 
-   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".
+   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 —