Haertung 1b: Fremd-Modell-Kritiker erzwingen + Anti-Durchwink-Regel

Gesellenpruefungs-Lehre (03.07.): Reviewer winkte kaputten Patch durch.
- wartung/SKILL.md Reviewer-Schritt: FREMD-MODELL-PFLICHT explizit
  (Worker=hermes/Qwen3.6-35B != Reviewer=heavy/gpt-oss-120b via
  delegation.model; per-Aufruf-Modell gibt delegate_task nicht her ->
  Trennung aktiv pruefen, sonst als offene Kritik ausweisen), eigenes
  Raster statt Autor-Erzaehlung, harte Regel REPRODUZIERT-ODER-ABGELEHNT
  (Freispruch nur mit belegtem Vorher/Nachher, sonst = Kritik).
- selbstkritik-prompt.md: Fremdblick vor dem Absenden (delegierte
  Kritiker-Runde auf anderem Modell zerpflueckt Belege).

Akzeptanz verifiziert gegen die Box: bewusst kaputter Patch (Kommentar
behauptet Fix, Logik fixt nicht) -> gpt-oss-120b ABGELEHNT mit konkreter
Reproduktion. Kein Deploy in diesem Commit.

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

deploy/selbstkritik-prompt.md

@@ -11,7 +11,16 @@ draußen (neue Software), du schaust hier nach innen (eigener Betrieb).
    Skill-/Curator-Stand, Prompt-Größen).
 2. Finde die 1 bis 3 WICHTIGSTEN konkreten Verbesserungen. Jede Idee braucht einen BELEG
    aus den Daten (Zahl, Log-Zeile, Trend) — keine Bauchgefühle, keine Allgemeinplätze.
-3. Schicke dem Commander EINE kompakte Nachricht in DEINER Stimme (Lucy: Anrede „Commander",
+3. **Fremdblick vor dem Absenden (Härtung 04.07. — „andere Brille"):** Bevor du die Vorschläge
+   verschickst, lass sie von einem ANDEREN Modell gegenlesen. Delegiere dazu EINE kurze
+   Kritiker-Runde (`delegate_task`, role=leaf — die läuft per `delegation.model` auf `heavy`,
+   also einem anderen Modell als du selbst). Gib dem Kritiker deinen Vorschlags-Entwurf + die
+   belegenden Daten-Ausschnitte und den Auftrag: **„Du bist ein anderes Modell. Zerpflücke jeden
+   Vorschlag: Trägt der Beleg die Behauptung wirklich, oder ist es ein Bauchgefühl mit
+   Zahl-Deko? Verwechselt er Korrelation mit Ursache? Fehlt Kontext?"** Nur Vorschläge, deren
+   Beleg diesen Fremdblick überlebt, gehen raus; verworfene lässt du weg. Ist `delegation.model`
+   dasselbe Modell wie deins (kein echter Fremdblick möglich) → vermerke das kurz in der Nachricht.
+4. Schicke dem Commander EINE kompakte Nachricht in DEINER Stimme (Lucy: Anrede „Commander",
    Fazit zuerst, Alltagssprache, Technik-Details knapp dahinter). Je Vorschlag: Was ist
    auffällig (Beleg) → was schlägst du vor → was bringt es. Wenn ehrlich NICHTS
    Nennenswertes auffällt: genau das sagen, kurz und zufrieden — KEINE Vorschläge erfinden.

deploy/skills/wartung/SKILL.md

@@ -49,6 +49,23 @@ NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
        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.
+
+   **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."**
+
    **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
@@ -58,6 +75,16 @@ NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
    - **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
+   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.
+
    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".