From 854393ce5f4868e220a9eacf3cd0bf77d1f39e9a Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 4 Jul 2026 17:00:32 +0200 Subject: [PATCH] Werkstatt-Reviewer: Fremd-Kritik ueber fremdblick.sh statt kaputter heavy-Delegation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- deploy/fremdblick.sh | 36 +++++++++++++---- deploy/skills/wartung/SKILL.md | 74 +++++++++++++++++----------------- 2 files changed, 65 insertions(+), 45 deletions(-) diff --git a/deploy/fremdblick.sh b/deploy/fremdblick.sh index 1a4d552..bfff6f5 100644 --- a/deploy/fremdblick.sh +++ b/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 "" | 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: ". Antworte knapp auf Deutsch.' -# max_tokens großzügig: GLM ist ein Reasoning-Modell und verbraucht Tokens im reasoning_content, -# bevor es die eigentliche Antwort in content schreibt — zu knapp = leeres content (finish=length). -RESP="$(jq -n --arg m "$MODEL" --arg s "$SYS" --arg u "$SUBJECT" \ - '{model:$m, temperature:0.2, max_tokens:2200, messages:[{role:"system",content:$s},{role:"user",content:$u}]}' \ +if [ "$MODE" = "code" ]; then + MODEL="${FREMDBLICK_MODEL:-Qwen3-Coder-Next}" + MAXTOK="${FREMDBLICK_MAXTOK:-1600}" + 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)" diff --git a/deploy/skills/wartung/SKILL.md b/deploy/skills/wartung/SKILL.md index 0fbd1f0..3f05b6a 100644 --- a/deploy/skills/wartung/SKILL.md +++ b/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 -- ` 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): + - **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: + 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: `. (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: ` + 2–4 Zeilen Was/Warum), dann **Branch zu Gitea pushen:** `git push origin wartung/` (die Box hat einen eigenen scoped Token, seit 02.07. hinterlegt). Push fehlgeschlagen? Nicht schlimm —