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>
This commit is contained in:
Hitonabi
+28
-8
@@ -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,
|
||||
# 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)"
|
||||
|
||||
@@ -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 —
|
||||
|
||||
Reference in New Issue
Block a user