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/fremdblick.sh

@@ -6,13 +6,20 @@
 # und „exited prematurely" wirft). GLM lädt klein neben dem Warm-Set und antwortet zuverlässig.
 #
 # Nutzung:  echo "<Beobachtungen/Behauptungen je mit Beleg>" | fremdblick.sh
-#           printf '%s' "$text" | FREMDBLICK_MODEL=Qwen3-Coder-Next fremdblick.sh
+#           printf '%s' "$text" | FREMDBLICK_MODEL=Qwen3-Coder-Next FREMDBLICK_SYS="$raster" fremdblick.sh
+#
+# Env-Overrides:
+#   FREMDBLICK_MODE    'prose' (Default, Dreaming-Prosa-Raster) oder 'code' (Werkstatt-Code-Review).
+#                      'code' setzt Raster + Default-Modell (Qwen3-Coder-Next) + größeres Budget.
+#   FREMDBLICK_MODEL   Modell-ID (echte llama-swap-ID, kein Alias). Übersteuert den Mode-Default.
+#   FREMDBLICK_SYS     eigenes System-Raster (übersteuert das Mode-Raster).
+#   FREMDBLICK_MAXTOK  max_tokens (übersteuert den Mode-Default).
 set -uo pipefail
 
 # Achtung: llama-swap listet unter /v1/models die ECHTEN Modell-IDs, nicht die Gateway-Aliase
-# (kein "heavy"/"scout" hier). Default daher die reale ID GLM-4.6V-Flash.
+# (kein "heavy"/"scout" hier).
 ENDPOINT="${FREMDBLICK_ENDPOINT:-http://127.0.0.1:8080/v1/chat/completions}"
-MODEL="${FREMDBLICK_MODEL:-GLM-4.6V-Flash}"
+MODE="${FREMDBLICK_MODE:-prose}"
 SUBJECT="$(cat)"
 
 if [ -z "${SUBJECT// /}" ]; then
@@ -20,12 +27,25 @@ if [ -z "${SUBJECT// /}" ]; then
   exit 0
 fi
 
-SYS='Du bist ein KRITISCHER Zweitgutachter und ausdrücklich ein ANDERES Modell als der Autor. Prüfe jede vorgelegte Beobachtung/Behauptung streng: Trägt der genannte Beleg (Zahl / Session / Log-Zeile) die Behauptung wirklich, oder ist es ein Einzelfall bzw. ein Bauchgefühl mit Zahlen-Deko? Verwechselt der Autor Korrelation mit Ursache? Fehlt entscheidender Kontext? Falls ein Skill-Kandidat dabei ist: ist er wirklich WIEDERVERWENDBAR oder Einmal-Kram? Antworte kompakt auf Deutsch: pro Punkt ein Urteil TRAEGT / TRAEGT-NICHT / UNSICHER mit genau einem Satz Begruendung. Sei knapp und unbestechlich; nicke nichts aus Hoeflichkeit durch. Erfinde keine neuen Belege.'
+# Prosa-Raster (Dreaming): urteilt über Beobachtungen/Behauptungen. Default-Kritiker = GLM (Fremd-Vendor).
+PROSE_SYS='Du bist ein KRITISCHER Zweitgutachter und ausdrücklich ein ANDERES Modell als der Autor. Prüfe jede vorgelegte Beobachtung/Behauptung streng: Trägt der genannte Beleg (Zahl / Session / Log-Zeile) die Behauptung wirklich, oder ist es ein Einzelfall bzw. ein Bauchgefühl mit Zahlen-Deko? Verwechselt der Autor Korrelation mit Ursache? Fehlt entscheidender Kontext? Falls ein Skill-Kandidat dabei ist: ist er wirklich WIEDERVERWENDBAR oder Einmal-Kram? Antworte kompakt auf Deutsch: pro Punkt ein Urteil TRAEGT / TRAEGT-NICHT / UNSICHER mit genau einem Satz Begruendung. Sei knapp und unbestechlich; nicke nichts aus Hoeflichkeit durch. Erfinde keine neuen Belege.'
+# Code-Raster (Werkstatt): reproduziert den Fehlerfall aus der Bug-Beschreibung, statt dem Autor zu glauben.
+CODE_SYS='Du bist ein kritischer Code-Reviewer und ein ANDERES Modell als der Autor. Vertraue seiner Begruendung NICHT. Dir liegen ein Wartungs-AUFTRAG (Bug-Beschreibung) und ein git-Diff vor. Trenne klar: (A) KERNFRAGE: Behebt der Diff den im Auftrag KONKRET beschriebenen Fehlerfall? Leite die Eingabe SELBST aus der Bug-Beschreibung ab und belege einen Uebergang: Eingabe X -> VOR Patch: Y (Bug sichtbar) -> NACH Patch: Z. (B) RANDFAELLE: nenne offene Risiken/Randfaelle als Hinweis. URTEIL-Regel: ABGELEHNT NUR, wenn (A) nicht belegt behoben ist (Kern-Bug bleibt, ODER der Patch trifft die Auftrags-Absicht nicht, ODER er bricht den Normalfall). Ist der Kern-Fall belegt behoben und es bleiben nur Randfaelle: FREIGABE-MIT-VORBEHALT (Randfaelle auflisten). Ist alles sauber: FREIGABE. Ein blosses sieht-plausibel-aus OHNE reproduzierten Kern-Uebergang = ABGELEHNT. Beginne die Antwort mit der Zeile "URTEIL: <ABGELEHNT|FREIGABE-MIT-VORBEHALT|FREIGABE>". Antworte knapp auf Deutsch.'
 
-# max_tokens großzügig: GLM ist ein Reasoning-Modell und verbraucht Tokens im reasoning_content,
+if [ "$MODE" = "code" ]; then
-# bevor es die eigentliche Antwort in content schreibt — zu knapp = leeres content (finish=length).
+  MODEL="${FREMDBLICK_MODEL:-Qwen3-Coder-Next}"
-RESP="$(jq -n --arg m "$MODEL" --arg s "$SYS" --arg u "$SUBJECT" \
+  MAXTOK="${FREMDBLICK_MAXTOK:-1600}"
-  '{model:$m, temperature:0.2, max_tokens:2200, messages:[{role:"system",content:$s},{role:"user",content:$u}]}' \
+  SYS="${FREMDBLICK_SYS:-$CODE_SYS}"
+else
+  MODEL="${FREMDBLICK_MODEL:-GLM-4.6V-Flash}"
+  MAXTOK="${FREMDBLICK_MAXTOK:-2200}"
+  SYS="${FREMDBLICK_SYS:-$PROSE_SYS}"
+fi
+
+# max_tokens großzügig: Reasoning-Modelle (GLM) verbrauchen Tokens im reasoning_content, bevor sie
+# die eigentliche Antwort in content schreiben — zu knapp = leeres content (finish=length).
+RESP="$(jq -n --arg m "$MODEL" --arg s "$SYS" --arg u "$SUBJECT" --argjson t "$MAXTOK" \
+  '{model:$m, temperature:0.2, max_tokens:$t, messages:[{role:"system",content:$s},{role:"user",content:$u}]}' \
   | curl -s --max-time 240 "$ENDPOINT" -H 'Content-Type: application/json' -d @- 2>/dev/null)"
 
 OUT="$(printf '%s' "$RESP" | jq -r '.choices[0].message.content // empty' 2>/dev/null)"

deploy/skills/wartung/SKILL.md

@@ -47,46 +47,46 @@ 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
+4. **Fremd-Modell-Review über `fremdblick.sh`** (Härtung 04.07., korrigiert 04.07.). Der Patch
-   role=leaf. Gib ihm den AUFTRAG im Wortlaut + `git diff` des Worktrees.
+   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
+   **NICHT `delegate_task` benutzen.** `delegate_task` läuft über `delegation.model` (= `heavy`
-   laufen als der Worker, der den Patch geschrieben hat. Grund: „Ein Agent, der seine eigenen
+   / gpt-oss), und heavy ist als Kritiker DOPPELT disqualifiziert: (a) Hermes screent Delegations-
-   Hausaufgaben benotet, stimmt sich meistens selbst zu" — genau das ist am 03.07. passiert.
+   Ziele gegen `MINIMUM_CONTEXT_LENGTH=64000`, heavy hat nur 32k → fällt raus; (b) heavy (60 GB)
-   Zwei verschiedene Modelle teilen NICHT dieselben blinden Flecken. Aktueller Aufbau:
+   stirbt beim Laden neben dem VL-30B-Warm-Set (Health-Check-Timeout). Die Fremd-Prüfung würde
-   Worker = `hermes` (Qwen3.6-35B, Default der Wartungs-Cron), Reviewer-Subagent = `heavy`
+   dann still ausfallen. Stattdessen den bereitgestellten Ein-Schuss-Kritiker nutzen:
-   (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
+   printf '%s' "AUFTRAG (Bug-Beschreibung im Wortlaut):
-     Beispiel-Eingabe, die den beschriebenen Bug AUSLÖST, und spiele den geänderten Code
+   <der Auftrag>
-     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
+   GIT-DIFF des Worktrees:
-   Reviewer den konkreten Übergang belegt — „Eingabe X → VOR Patch: Y (Bug sichtbar) → NACH
+   <git -C /tmp/wartung-<slug> diff origin/main>" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh
-   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.
+   Das läuft auf `Qwen3-Coder-Next` (128k, code-stark, anderes Modell als der Qwen3.6-Worker,
-   Schreibe das Reviewer-Urteil im Telegram-Vorschlag KONKRET aus („durchgespielt mit Eingabe X →
+   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