Blind Tribunal

Blind Tribunal

Effort: heavy — acht Juroren, eine Linse pro Kopf, nach Stufe an die günstigste ausreichende Modellfamilie geroutet, jede Runde auf frischen Umschlägen neu einberufen, bis sie einstimmig sind; investier das in autonome Änderungen, die ohne menschliches Review landen. Beseitigt: entgleiste Landungen, die nichts bewacht außer dem eigenen Wort des Builders.

Die Bewertungsschleife, mit der der Mensch weggehen kann, ohne dass der Agent entgleist. Ein Panel aus Juroren prüft die Änderung blind, mit entfernter Autorschaft. Jeder Befund wird ein neuer fehlschlagender Test. Die Schleife läuft, bis jeder Juror passt. Nichts landet allein auf das Wort des Builders.

Wann einsetzen

• Vor dem Landen jeder autonomen Änderung, die kein Mensch reviewen wird.
• Jede Änderung mit großem Explosionsradius: sicherheitsnah, datenberührend, autoritätsnah.
• Wenn ein Grader nicht reicht und du unabhängige Linsen auf demselben Artefakt willst.

Die Sitze

Acht Juroren, eine Linse pro Kopf. Jeder ist ein Modell aus einer ANDEREN Familie als der Builder (gleicher Hersteller = gleiche Familie). Ein Juror, der alles prüfen soll, prüft nichts richtig.

Routing-Stufen (die günstigste ausreichende Route zuerst): Deep State → größter Kontext und tiefstes Reasoning, idealerweise durch einen Harness, der das Repo LIEST (nie schreibt); schnell-strukturell → erst eine freie lokale GPU, FUSIONIERT mit einem billigen Cloud-Verifizierer, der denselben Prompt beurteilt: die Linse besteht nur, wenn beide bestehen; ohne Cloud bleibt das lokale Urteil, markiert UNVERIFIED, nie stillschweigend „verifiziert"; und das lokale Modell muss das GANZE Artefakt sehen (num_ctx auf den Prompt dimensionieren — Ollamas Default 4096 kürzt stillschweigend — und vor dem Senden ablehnen, was nicht passt); der Verifizierer stammt nie aus der Familie des Primärsitzes, und ein UNVERIFIED-Sitz ist ein Halt (nie Einstimmigkeit); Harness-Juroren laufen read-only, und jede Einberufung trägt eine run_id und schreibt ihre Zusammenfassung zuletzt; danach die Cloud-Modelle mit niedriger Latenz; Operator-Sicherheit → dein stärkster Coder mit Sicherheits-Grounding; Generalist → ein großer, zuverlässiger Generalist. Jede Leiter endet auf einer lokalen Überlebens-Sprosse.

Solo-Rig. Wenn nur eine Modellfamilie verfügbar ist, degradiere EXPLIZIT: Ein frischer Kontext oder eine frische Session, die die Konversation des Autors nie gesehen hat, agiert als blinder Grader, oder der Mensch prüft den geschwärzten Umschlag. Der Bericht muss das geschwächte Gate benennen — „same-family-blind bewertet, nicht cross-family" — und nie still so tun, als hätte das Cross-Family-Gate gehalten.

Der Builder wird deklariert, und der Ausschluss ist strukturell

„Andere Familie als der Builder" war eine Regel, die sich Juroren merken sollten. Im eigenen Test des Tribunals führte den Operator-Sicherheitssitz genau das Modell an, das den Kandidaten gebaut hatte, und nichts hat es erfasst oder ausgeschlossen: Der Autor hat zwei Runden lang seine eigene Arbeit benotet. Also:

• Einberufen mit benanntem Builder (--builder <modell-oder-familie>). Der Lauf trägt builder_family. Jede Sprosse dieser Familie wird laut abgelehnt, vor jedem Versand, auf jeder Leiter. Eine Linse ohne Sprosse HÄLT — fällt nie auf den Builder zurück.
• Gleicher Anbieter = gleiche Familie. Eine Deklaration schließt den ganzen Anbieter aus.
• Beweise es auf der lebenden Leiter, nicht im Test: Die Routing-Tabelle muss zeigen, dass seine Sitze an eine andere Familie gefallen sind. Sonst ist der Ausschluss Dekoration.

Der Umschlag

Juroren sehen nie das Repo, den Builder oder die Konversation. Sie sehen einen Umschlag:

• Ganze aktuelle Dateien für jede Datei, die die Änderung berührt hat, plus ihre Testdateien. Nie nackte Diff-Hunks — ein Hunk versteckt den umgebenden Contract und provoziert falsche Befunde.
• Der Review-Contract: die Absicht der Änderung in einer Zeile, und die Pass-Kriterien.
• Null Autorschaft. Keine Namen, keine Modell-IDs, keine Commit-Autoren, keine Chat-History. Sickert Identität durch, schlägt der Umschlag-Bau laut fehl — nie unverblindet bewerten.
• Keine Prosa über das alte Verhalten. Zu beschreiben, was der Code „früher tat", pflanzt Phantom-Defekte. Die Dateien sprechen für sich.

Das Urteil

Striktes, maschinenlesbares JSON, ein Objekt, keine Prosa:

{"verdict": "pass" | "refuse",
 "findings": [{"severity": "blocker|major|minor|info",
               "claim": "...", "evidence": "..."}]}

• Ein Pass, der einen [blocker]- oder [major]-Befund listet, ist kein Pass. Widersprüchlich; fällt geschlossen auf refuse, mit der Schwere benannt.
• Ein Urteil für eine andere Linse als die besetzte ist eine abgelehnte Sprosse, kein Urteil: mit beiden Linsen vermerkt, der Gang geht zur nächsten Sprosse; nur wenn alle daneben antworten, hält die Linse. Nie ein Pass.
• Das Ausgabeverzeichnis wird besessen, bevor es gefegt wird. Das Organ stempelt (stamp) ein beanspruchtes Verzeichnis; eines mit diesen Dateiformen OHNE Stempel wird abgelehnt — Dateien und Abhilfe benannt, nichts gelöscht. Ein Verzeichnis nur mit fremden Dateien war nie in Gefahr und wird nicht blockiert.
• Eine explodierende Linse verwirft nie die schon bezahlten Urteile. Jeder Sitzfehler wird pro Linse erfasst; Urteile und Zusammenfassung werden VOR dem Fehler geschrieben.
• Der Mutationsbeweis nennt eine überschriebene Datei (changed_paths).
• Alles, was das Organ schreibt, ist nur für den Eigentümer lesbar (0600).
• Ein übergelaufenes lokales Modell entlädt nur sein LETZTER Halter. Zwei Linsen können eine Karte teilen; die erste fertige zieht der anderen nicht mitten im Aufruf das Modell weg.
• Eine Sprosse, die das Artefakt nicht fassen kann, wird vor dem Aufruf übersprungen, Grund vermerkt; eine Kapazitätsablehnung ist ein TYP und der Gang geht weiter — nie ein Halt.
• Ein Juror, der SCHLECHT geantwortet hat — Müll, kein JSON, Verweigerungstext — zählt als refuse; ein Juror, der NIE geantwortet hat (Transportfehler, unerreichbar), ist ein hold: neu besetzen via fleet-ladder, nie ein stiller Pass. Ein Schuss pro antwortendem Juror pro Runde — keine Retries.
• Ein nackter Pass mit null Befunden und ohne Evidenz ist eine informationsarme Stimme. Sie zählt, aber nie als einziger Beweis — zwei nackte Passes überstimmen keinen detaillierten Refuse. Ein starker Pass benennt, was er geprüft hat.

Die Schleife

1. Rot zuerst: committe den fehlschlagenden Contract-Test, BEVOR der Fix gebaut wird, und halte diesen Commit fest. Der Builder darf den Test nicht anfassen (red-first).
2. Baue bis grün.
3. Baue den Umschlag aus den AKTUELLEN Dateien.
4. Besetze die acht Juroren, nach Stufe, — andere Familien als der Builder (fleet-ladder klärt, was live ist).
5. Jeder Juror verifiziert auch, statt nur zu lesen: Die neuen Tests bestehen; die Regressions-Suite ist nicht schlechter als die Baseline; und ein Fake-Green-Check — ein Test, der fehlschlagen SOLLTE (der Bug wieder eingebaut), schlägt wirklich fehl. Ein Fake Green ist ein Refuse.
6. Bei jedem Refuse: JEDER Befund — Blocker, Major und Minor — wird ein NEUER fehlschlagender Test, der aus dem echten Grund des Befunds fehlschlägt. Behebe ihn. Baue den Umschlag über den überarbeiteten Dateien neu. Berufe ALLE Juroren neu ein. Ein Urteil über veraltete Dateien ist kein Urteil.
7. Lande nur bei einstimmigem Pass. Minor-Befunde aus der letzten Runde werden auch geschlossen, nie vertagt — „Blocker gefixt, Minors später“ ist genau das Leck, das dieser Skill stopfen soll. Ein Befund endet GEFIXT oder mit dokumentierter Evidenz widerlegt, nie geparkt.

Die Fußzeile nennt die Linse, eine abgelehnte Sprosse behält ihre Worte, und der Boden ist drei Sprossen tief

Runde 4 hielt zwei Linsen mit null Ablehnungen, und jedes Glied stand im Protokoll. Drei Gesetze kamen heraus:

• Nenne die Antwortform neben der Antwort. Die Protokoll-Fußzeile trägt den wörtlichen Linsennamen ("lens": "defect"), nie den Platzhalter <your lens>. Ein Juror, der die Linse aus 350 KB Abstand erinnern sollte, in einem Artefakt, das alle acht Linsen nennt, antwortete dreimal in zwei Runden mit der falschen Linse. Fülle den Platzhalter beim Rendern.
• Eine abgelehnte Sprosse hinterlässt ihre Worte im Protokoll. Eine Antwort mit falscher Linse oder ein annulliertes Urteil trägt ein begrenztes raw_tail am abgelehnten Eintrag, damit die nächste Runde die Ursache liest statt sie zu erraten.
• Zwei Cloud-Sprossen sind kein Boden. Jede Stufe hält mindestens drei Sprossen ohne deklarierte context_tokens (sie tragen ein 120k-Token-Artefakt) vor ihrem lokalen Ende. Eine falsche Linse plus eine Annullierung dürfen nie eine Linse aufhalten.
• Ein strukturiertes Urteil teilt sein Budget nie mit dem Nachdenken. Ein Reasoning-Modell, das um ein nacktes JSON-Urteil gebeten wurde, verbrauchte sein ganzes Budget von 65536 Tokens mit Nachdenken über ein 131k-Token-Artefakt und gab nichts aus (finish_reason=length); die Zeitgrenze der Rolle tötete dann die nächste Sprosse mitten im Lauf. Jede Cloud-Sprosse, die ein JSON-Objekt-Urteil verlangt, läuft mit abgeschaltetem Reasoning-Kanal (reasoning_effort: none), und die Prüfer-Leiter hält dahinter eine dritte Familie über schlichtes HTTP.
• Nichts anderes schreibt in das Repo des Tribunals, während es tagt. Die Statusdatei eines gleichzeitigen Bewerters im Checkout änderte Bytes unter einem Sitz, und das Organ annullierte dieses Urteil ehrlich: es kann eine Änderung nicht zuordnen. Serialisiere Schreiber, oder tage auf einem separaten Worktree desselben Commits.

Harte Regeln — eine gebrochen, und die Bewertung ist nichtig

• Der Builder bewertet nie die eigene Arbeit: nicht dieselbe Instanz, nicht dieselbe Familie.
• Ein Juror-Refuse ist nur so gut wie der Umschlag. Bevor du aus einem Befund einen Test schreibst, prüfe den Befund gegen die tatsächlichen Dateien. Ein Befund über Code, den der Umschlag nie enthielt, heißt: den Umschlag fixen, nicht den Code.
• Miss Konvergenz an NEUEN Befunden pro Runde, nicht an der Rohsumme. Neue Befunde zwei Runden in Folge flach oder steigend: stoppen und an den Menschen eskalieren. Nie stur weitermahlen.
• Schwäche oder editiere die fehlschlagenden Tests nie, um einen Pass zu erreichen. Juroren verifizieren, dass die Testdateien seit dem Rot-Commit unverändert sind.
• Ein Überlebender ist eine Behauptung; ein grüner Beweis ist eine Behauptung. Jeden gemeldeten Mutanten von Hand neu laufen lassen, im isolierten Baum, mit einer Obergrenze, die die Last überlebt. Ein Timeout ist kein Überlebender; ein Sammelfehler ist kein Kill. Jeder Urteilspfad muss INVALID sagen können, und ein Harness, dessen mutationsfreie Baseline nicht sauber grün ist, verweigert jedes Urteil.
• Ein einstimmiger Pass öffnet das Tor; er ist nicht das Ziel. Lande, dann beweise die Fähigkeit live auf der echten Oberfläche. Grün ohne Live-Beweis ist nicht fertig.

Passt gut zu

• red-first — der fehlschlagende Contract, committet bevor der Builder läuft.
• sniper-testing — echte Nebeneffekte, begrenzte Läufe, kein Mock-Theater.
• seam-engineering — die Klasse fixen, Geschwister durchkämmen, einen Guard landen.
• repair-loop — die Bauschleife, die dieses Tribunal bewertet.
• blind-eval — das leichtere Keep-or-Revert-Gate, wenn die Frage Geschmack ist, nicht Defekte.

Gerüst-Credit: Matt Pocock, grill-me / grilling (mattpocock/skills, MIT). Das Design des blinden, adversarialen Cross-Family-Tribunals ist BACKS AIOS.