Material: Anwendungsteil 8. Datei-Schiedsgericht für umstrittene Änderungen: Rollen, Urteile und Präzedenzfälle

Lektion 1 von 5 im Modul «Anwendungsteil 8. Datei-Schiedsgericht für umstrittene Änderungen: Rollen, Urteile und Präzedenzfälle»

Sie sehen die Lektion ohne Anmeldung an. Anmelden, um Ihren Fortschritt zu speichern und Tests zu absolvieren.

Quelle

Praxisteil 8. Dateibasierter Schiedsrichter für strittige Änderungen: Rollen, Urteile und Präzedenzfälle

Status: Grenzbereich. Dateibasierter Schiedsrichter Verifikator/Implementor/Safety (mit Stimmberechtigung) mit Koordinator-Protokoll und Eintrag in judgment.md (Entscheidung zum Streit) und precedents.md (Präzedenzfälle) — eine Technik, die angewendet wird, aber in Qwen Code nicht eingebaut ist. Kompatibilität und Einschränkungen — in appendix-b-qwen-code-compatibility.md.

Für das didaktische Durchlaufen genügt es, judgment.md aus dem ausführbaren Beispiel zu erhalten und zu verstehen, welche Beweise der Verifikator akzeptiert. Rollenrotation, externer Koordinator und Modellmatrix gehören zum vollständigen Produktionstrack.

Die Grenze zu Kapitel 4 ist folgende: Das LLM-Duell beantwortet die Frage „wurde ein minimales Gegenbeispiel gefunden und wie wurde es geschlossen". Der dateibasierte Schiedsrichter beantwortet eine andere Frage: „welches offizielle Urteil fällt das Rollenteam, welche Beweise wurden als zulässig anerkannt und welcher Präzedenzfall bleibt für künftige Streitigkeiten".

Der dateibasierte Schiedsrichter sucht nicht selbst alle Defekte. Er nimmt die Ergebnisse anderer Mechanismen als Beweise entgegen: Gegenbeispiel aus dem Duell, Spec-CI-Bericht, Anti-Goodhart-Invariante, Bereitschaftsschleuse (readiness gate) oder Mutanteneintrag. Wenn der Beweis nicht in der Datei vorhanden ist, darf der Koordinator nicht den Eindruck eines Agenten in ein Urteil verwandeln.

Das Team-Review aus Teil 16 des ersten Bandes ist das Basisschema: Ein menschlicher Reviewer prüft einen Pull-Request anhand eines Beweispakets. Hier ist dasselbe Schema eine Ebene höhergehoben. Anstelle einer einzelnen Person arbeiten Rollen: Verifikator (Verifier), Implementor (Implementor) und Safety stimmen ab; Koordinator (Coordinator) führt das Protokoll und stimmt nicht ab. Anstelle von PR-Kommentaren dienen zwei Dateien: judgment.md (Entscheidungsjournal für Streitigkeiten) und precedents.md (Datenbank wiederkehrender Streitigkeiten). Die Grundlage bleibt dabei unverändert: Urteile werden mit den Fakten aus validation.md aus Teil 9 abgeglichen, und die Ergebnisse werden ebenso wie bei der Neuplanung aus Teil 10 in die Roadmap übernommen.

Vor dem Lesen

Grundlage aus dem ersten Band: Teil 16 definiert das Team-Review, Teil 10 zeigt die Neuplanung nach Fakten.

Lokaler didaktischer Fall: autoscale_200pct, da hierfür bereits ein Duell, Invarianten und judgment.md vorhanden sind.
Spur für capstone/: Ein Urteil APPROVE, DENY oder DEFERRED mit evidence_ref für high_memory_usage.
Hauptbegriffe des ersten Durchlaufs: Dateibasierter Schiedsrichter und judgment.md. Die Rollen (Verifikator/Implementor/Safety + Koordinator-Protokollführer) wurden bereits in Teil 3 eingeführt — hier erhalten sie ihre prozedurale Ausformung.
Was zurückzustellen ist: Modellmatrix, externer Koordinator und permanente Datenbank precedents.md.

Ziel

Sie lernen, einen dateibasierten Schiedsrichter für eine strittige Änderung durchzuführen. Dies ist eine kollektive Prüfung einer einzelnen Änderung durch mehrere Rollen, bei der das Ergebnis in Dateien und nicht im Chat festgehalten wird. Ziel ist es, ein Schema zu entwerfen, in dem eine Spezifikation auch bei Rollenrotation, Modellwechsel und verschiedenen Strengheitsmodi reproduzierbar geprüft wird.

Rollenrotation bedeutet, dieselbe Spezifikation durch verschiedene Implementor/Verifikator-Paare laufen zu lassen (lokaler oder starker Agent an jeder Position). Sie ist notwendig, damit das Urteil nicht von einem bestimmten Modell abhängt.

Der praktische Gewinn ist einfach: Ein Streit hört auf, ein Meinungsaustausch im Chat zu sein, und wird zu einer Beweiskette. Der Koordinator leitet den Prozess. Der Implementor schlägt Änderungen vor. Der Verifikator nimmt sie an oder lehnt sie anhand formaler Kriterien ab. Safety erhält ein Veto bei critical_risk. Das Ergebnis wird in Projektartefakten festgehalten.

Dieser Ansatz setzt die Logik von SDD fort: Die Spezifikation bleibt die Wahrheitsquelle für das Systemverhalten und keine optionale Beschreibung der Entwicklerabsichten (GitHub Spec Kit).

Die technische Bezeichnung des Mechanismus — dateibasiertes Protokoll für den Schiedsrichter einer strittigen Änderung durch mehrere Rollen. Der Name tribunal bleibt technisches Etikett des Verzeichnisses des ausführbaren Beispiels, kein eigenständiges Produkt von Qwen Code.

Minimaler didaktischer Szenario

Didaktischer Fall

Derselbe autoscale_200pct, aber jetzt wird nicht nur ein Gegenbeispiel benötigt, sondern ein offizielles Protokoll: Duell, Anti-Goodhart-Invarianten und abschließendes judgment.md.

Vorbereitung

book2/examples/tribunal/specs/autoscale_spec.yaml.
book2/examples/tribunal/cases/.
book2/examples/tribunal/metrics/validation_metrics.json.
Skripte run_duel.py, check_invariants.py, write_judgment.py.

Schritte

cd book2/examples/tribunal. Erwartung: Sie befinden sich im Verzeichnis des ausführbaren Beispiels.
python3 scripts/run_duel.py --spec specs/autoscale_spec.yaml --cases cases/ --out out/duel.json. Erwartung: Das Duell hat Urteile zu den Fällen aufgezeichnet.
python3 scripts/check_invariants.py --metrics metrics/validation_metrics.json --out out/invariants.json. Erwartung: Anti-Goodhart-Invarianten wurden unabhängig vom Duell geprüft.
python3 scripts/write_judgment.py --duel-out out/duel.json --invariants-out out/invariants.json --to out/judgment.md. Erwartung: Ein abschließendes Markdown-Protokoll ist erschienen.
Öffnen Sie out/judgment.md und übertragen Sie einen wiederholbaren Konflikt in precedents.md: Bedingung, Beweis, Entscheidung, Anwendbarkeit.

Kontrollfakt

judgment.md enthält nicht nur PASS/FAIL, sondern auch die Begründung: welcher Fall geprüft wurde, welche Invariante ausgelöst hat, was der Implementor bei wiederholtem Streit tun muss. Ohne diese Datei bleibt der dateibasierte Schiedsrichter ein Duell aus Kapitel 4.

Wie dies in `capstone/` gelangt

Übertragen Sie in capstone/judgment.md ein Urteil, einen Grund, evidence_ref und den nächsten prüfbaren Schritt. Wenn der Konflikt wiederholbar ist, fügen Sie einen kurzen Präzedenzeintrag hinzu. Übertragen Sie nicht die gesamte out/duel.json, wenn sie durch einen Befehl aus dem ausführbaren Beispiel reproduzierbar ist.

Minimaler Fragment:

verdict: DEFERRED
reason: "readiness passes by score, but stateful blocker has no backup evidence"
evidence_ref: "fixtures/readiness_block_stateful.json"
next_step: "add backup_verified evidence or keep remediation manual"

Reviewfähige Spur

Bewahren Sie judgment.md oder einen Auszug in precedents.md auf, wenn sie Teil des didaktischen Beweispakets geworden sind. Lokale out/duel.json und out/invariants.json können außerhalb des Repositorys verbleiben, wenn sie durch einen Befehl reproduzierbar sind.

Schlüsselideen

Der Phasenvertrag des dateibasierten Schiedsrichters beginnt mit der Rolle Koordinator. Er eröffnet die Sitzung, legt die Rundenreihenfolge fest, führt die Streitwarteschlange und ist für das offizielle Protokoll in judgment.md verantwortlich. Das judgment.md selbst ist das Entscheidungsjournal der Sitzung: welche Runde durchlaufen wurde, welches Diff geprüft wurde, welche Beweise als ausreichend anerkannt wurden.

Der minimale Zyklus ist folgender: Der Koordinator nimmt die Ausgangsspezifikation entgegen, gliedert sie in prüfbare Dateien, weist die Rollen Implementor, Verifikator und Safety für kritische Risiken zu und verbietet den Übergang zur nächsten Phase ohne Eintrag des Ergebnisses der vorherigen. Die vollständige Rollenordnung mit Stimmgewichten (vote_weight), Quorum und Veto-Bedingungen — in Teil 3. Hier interessiert uns, wie dieselben Rollen um eine bestimmte strittige Änderung arbeiten.

Was das in der Praxis bedeutet. Nehmen wir ein kurzes Urteil aus dem Chat:

Schlecht: > „Der Verifikator hat den Vorschlag des Implementors abgelehnt."

Problem: keine Begründung und keine Beweisverknüpfung (evidence_ref), der Streit ist nicht reproduzierbar. Der nächste Reviewer kann das Urteil weder anfechten noch unterstützen.

Gut: > verdict=DENY, reason=violates_invariant:silent_p0, evidence_ref=tests/regression_001.json, next_step=Implementor fügt Prüfung von severity vor Auto-Eskalation hinzu

evidence_ref hier ist dieselbe Beweismarkierung wie in Teil 1: Verweis auf eine konkrete Stelle in der Datei, keine Nacherzählung. silent_p0 — die Invariante „kein P0-Vorfall darf ohne Eskalation geschlossen werden". Wenn der Verifikator DENY zurückgibt, schließen Sie den Streit nicht manuell. Verlangen Sie von der Seite eine formale Begründung: Verweis auf eine konkrete Anforderung, Hook-Log, Schemaverletzung oder unbewiesenes Szenario. So wird judgment.md kein Bericht „wer gewonnen hat", sondern ein Journal des prozessualen Zustands.

In Qwen Code ist ein solcher Schiedsrichter kein einzelner eingebauter Befehl. Die minimale Implementierung wird aus /review, headless-Ausführungen von qwen -p, Projektskripten und bei Bedarf benutzerdefinierten Befehlen zusammengestellt. Alle Urteile in Dateien speichern, damit ein anderer Ingenieur den Streit ohne Chatverlauf wiederholen kann. Detaillierte Zuordnung von Rollen und eingebauten CLI-Fähigkeiten — in [appendix-b-qwen-code-compatibility.md](appendix-b-qwen-code-compatibility.md).

> [runnable] — Das ausführbare Beispiel des dateibasierten Schiedsrichters liegt in [examples/tribunal/](examples/tribunal/) (siehe [examples/tribunal/README.md](examples/tribunal/README.md)). Die reale Ausführung wird aus drei Skripten zusammengestellt:

run_duel.py schreibt das JSON-Ergebnis des Duells;
check_invariants.py prüft die Anti-Goodhart-Schwellenwerte (Regel, die verbietet, eine Metrik auf Kosten der Degradation anderer zu verbessern);
write_judgment.py stellt das abschließende judgment.md aus den beiden vorherigen Ausgaben zusammen.

Ausführung aus dem Verzeichnis book2/examples/tribunal.

cd book2/examples/tribunal
python3 scripts/run_duel.py \
  --spec specs/autoscale_spec.yaml \
  --cases cases/ \
  --out out/duel.json

python3 scripts/check_invariants.py \
  --metrics metrics/validation_metrics.json \
  --out out/invariants.json

python3 scripts/write_judgment.py \
  --duel-out out/duel.json \
  --invariants-out out/invariants.json \
  --to out/judgment.md

run_duel.py liest die Spezifikation und führt Gegenbeispiele aus cases/ durch. check_invariants.py gleicht die tatsächlichen Metriken mit den Schwellenwerten ab. write_judgment.py stellt das finale Markdown-Protokoll zusammen. Es gibt keine externen „Koordinatoren" oder „Verifikatoren" als separate Prozesse. In der Produktion wird ein solcher Schiedsrichter aus dem eingebauten Befehl /review, headless-Aufrufen von qwen -p mit verschiedenen Rollen in der Eingabeaufforderung und Projektskripten zusammengestellt — jeder mit seinem eigenen Artefakt auf der Festplatte.

Der A/B-Vergleich einer Spezifikation zwischen verschiedenen Implementor/Verifikator-Konfigurationen zeigt, wie sehr das Urteil vom Agenten eines bestimmten Tiers abhängt. Das Modell-Tier hier ist die Modellstufe: günstige lokale (local-coder) oder starke Cloud- (frontier-reviewer). Dieselbe rate_limit_spec.md wird durch mehrere Paare laufen gelassen:

C1: günstiger lokaler Implementor gegen starken Verifikator;
C2: starker Implementor gegen lokalen Verifikator;
C3: symmetrisches lokales Paar;
C4: symmetrisches teures Paar.

Wenn C1 und C4 PASS ergeben, C2 jedoch stabil FAIL zurückgibt, ist das kein Signal für sofortigen Modellwechsel. Zuerst die beweisende Rahmenstruktur prüfen: Der Verifikator mit schwächerem Tier könnte einen impliziten Zusammenhang zwischen Anfragelimit, Abkühlfenster (cooldown) und sicherem Warteschlangenzustand nicht erkannt haben.

Der Test ist gerade deshalb nützlich, weil er die Spezifikation unverändert lässt und nur die Rollenkonfiguration ändert.

Das didaktische ausführbare Analogon liegt in [examples/tribunal/matrix/](examples/tribunal/matrix/README.md): Dasselbe judge() aus dem Duell wird durch vier Tier-Paare laufen gelassen, beschrieben in matrix/tiers.json. Die Konfiguration modelliert die Lücke zwischen Beweisformen — local-coder gibt einen kurzen diagnostic_code (minimal_form), frontier-reviewer eine Struktur evidence_by_invariant (extended_form), und ein schwacher Verifikator erkennt nur minimal_form. Daher fällt Paar C2 (starker Implementor + schwacher Verifikator) stabil durch, die anderen drei bestehen — das ist der didaktische signal: tier_dependent_spec.

cd book2/examples/tribunal
python3 scripts/matrix.py \
  --spec specs/autoscale_spec.yaml \
  --cases cases/ \
  --tiers matrix/tiers.json \
  --out out/matrix.json

#### Kontrolle: summary.signal != "tier_dependent_spec" — Anlass, die Abweichung in validation.md zu erklären oder in precedents.md auszulagern

In einem Produktionsprojekt steht hinter dieser Ausgabe scripts/tribunal_matrix.py — es ersetzt judge() durch echte Aufrufe von qwen -p mit verschiedenen Rollen in der Eingabeaufforderung, aber das Artefakt-Interface (summary.signal, pairs[*].verdict, pairs[*].cases[*].reasons) bleibt dasselbe. Wenn die Matrix im Lehrbuch eine Abweichung ausgibt — Exit 1, und in smoke_all.sh ist dies in expect_fail eingewickelt: Die Abweichung hier ist das gewünschte didaktische Signal, kein Fehler.

Formulieren Sie für den Verifikator keine allgemeine Anfrage „prüfe die Lösung", sondern strenge beweisende Anforderungen. Es gibt drei: Hook-Logs, JSON-Schema-Übereinstimmung und formale Given/When/Then-Szenarien.

PreToolUse-Logs zeigen, welche Tool-Aufrufe vor der Ausführung erlaubt oder blockiert wurden. PostToolUse-Logs halten das tatsächliche Ergebnis fest, Exit-Code, Prüfsumme des Diffs und Verweis auf das Ereignis in den Beweisen.

JSON-Schema schließt eine Klasse von Fehlern ab, bei denen der Agent überzeugenden Text generiert, aber den Datenvertrag verletzt. Beispiele solcher Verletzungen:

Pflichtfeld fehlt;
Parametertyp ändert sich von integer auf string;
Limit liegt außerhalb des zulässigen Bereichs.

Given/When/Then-Szenarien fügen eine kausale Prüfung hinzu: unter welchen Ausgangsbedingungen ist eine Handlung zulässig, welches Ereignis sie auslöst und welches beobachtbare Ergebnis die Sicherheit bestätigen muss.

flowchart TD
    COORD[Koordinator: Eintrag in Anforderungen]
    IMPL[Implementor: patch_plan und hooks]
    PRE[PreToolUse: Blockierung gefährlicher Aktionen]
    POST[PostToolUse: Beweise und Hash]
    VER["Verifikator: Abgleich mit validation, Urteil"]
    SAFETY["Safety: Veto bei critical_risk"]
    DISPUTE["Streit: Diff in requirements/hooks/validation"]
    COORD --> IMPL
    IMPL --> PRE
    PRE --> POST
    POST --> VER
    VER --> SAFETY
    SAFETY --> DISPUTE
    DISPUTE --> COORD

Konflikte werden nur durch Diffs in requirements.md, hooks.md, validation.md gelöst. Alle verdeckten Änderungen im Chatdialog werden aus der Beweisbasis ausgeschlossen.

Wenn der Implementor die Ablehnung für fehlerhaft hält, schreibt er die Erklärung nicht in freier Form um. Stattdessen fügt er eine prüfbare Änderung hinzu: präzisiert die Anforderung, verstärkt den Hook oder erweitert das Validierungsszenario.

Der Koordinator nimmt eine Wiederholungsrunde nur an, nachdem das Diff mit der Ausgangsspezifikation und einem konkreten Ereignis-Beweis verknüpft wurde. Andernfalls wird der Streit zu einer nicht reproduzierbaren privaten Geschichte. Bei wiederholtem Konflikt übertragen Sie die Entscheidung in precedents.md — das Präzedenzjournal, in dem für jeden Fall genau fünf Felder festgehalten werden:

case_id — stabiler Präzedenzfall-Identifikator;
verdict — Ergebnis nach Schiedsrichterregel (APPROVE / DENY / DEFERRED);
evidence_ref — Verweis auf Diff, Hook-Log, Schema oder Szenario, das das Urteil bewies;
applies_to — Anwendungsgrenzen des Präzedenzfalls (Tiers, Strengheitsmodi, Domänen);
next_check — Bedingung, unter der der Präzedenzfall überprüft werden muss.

- case_id: PREC-021
  verdict: DENY
  evidence_ref: "tests/rate_limit_tenant_isolation.json"
  applies_to: "rate-limit ohne Deduplizierung von tenant_id, alle Tiers, strict_guardrails_prompt"
  next_check: "burst_window_sec steigt über 60 oder es erscheint ein Isolationsbeweis für tenant_id"

Die Anti-Goodhart-Regel schützt den dateibasierten Schiedsrichter vor der Situation, in der eine Metrik auf Kosten der Systemdegradation verbessert wird. MTTR (mean time to recovery, mittlere Wiederherstellungszeit) kann nicht den Anstieg falscher Eskalationen, stiller Fehler (silent failure) oder Rollback-Flattern (rollback-flapping) rechtfertigen. Das gilt auch dann, wenn eine einzelne Runde ein schnelles PASS zeigt.

Daher in validation.md harte Stoppbedingungen festlegen:

false_escalation_rate <= 0.05;
rollback_flapping < 3/h;
silent_p0_ratio == 0.

Die Überschreitung eines beliebigen Schwellenwerts versetzt das Urteil unabhängig vom Zeitgewinn in FAIL. Das verwandelt den Goodhart-Schutz von einer moralischen Warnung in eine ausführbare Schiedsrichterregel.

Beispiele und Anwendung

Beispiel: Eine Spezifikation für automatische Ratenbegrenzung (rate limiting) im API-Gateway verlangt, bei Anfragespitzen vorübergehend einen bestimmten Kunden (Tenant) zu beschränken, aber nicht den gesamten Dienst zu blockieren und nicht jede Spitze als P0 zu eskalieren.

Der Implementor schlägt einen Patch vor:

tenant_id in den Deduplizierungsschlüssel aufnehmen;
Fenster burst_window_sec=60 einführen;
Ereignis nach jeder Limitanwendung in evidence/rate_limit.ndjson schreiben.

Der Verifikator trifft seine Entscheidung nur bei Vorliegen von drei Beweisen:

JSON-Schema verlangt tenant_id, limit_reason, expires_at;
PreToolUse verbietet Änderung des globalen Limits ohne Geltungsbereich eines bestimmten Kunden;
Given/When/Then zeigt, dass die Spitze eines Kunden die Quote eines Nachbarkunden nicht senkt.

Wenn einer dieser Beweise fehlt, gibt der Verifikator DENY zurück, auch wenn der Patch technisch plausibel aussieht.

In einer A/B-Runde kann die Konfiguration Implementor=local-coder, Verifier=frontier-reviewer bestehen. Der starke Verifikator erkennt die ausreichende Verbindung zwischen Schema, Hook-Logs und Szenarien.

Die umgekehrte Konfiguration Implementor=frontier-reviewer, Verifier=local-coder kann denselben Ansatz ablehnen. Das passiert, wenn der Sicherheitsbeweis in der langen Argumentation des Implementors versteckt ist und nicht in validation.md ausgelagert wurde.

Das bedeutet nicht, dass ein Agent „richtig" und der andere „irrt". Der Schiedsrichter deckt auf, dass die Anforderung nicht ausreichend zwischen den Modell-Tiers übertragbar ist. Die Korrektur muss als Diff erscheinen — zum Beispiel Hinzufügung des Szenarios Given tenant A exceeds burst limit / When tenant B sends normal traffic / Then tenant B quota remains unchanged.

Scenario: Tenant-Isolierung bei Lastspitze
  Given tenant A sendet 800 req/min
  And tenant B sendet 40 req/min
  When rate-limit hook wendet Begrenzung an
  Then tenant A erhält temporäres Limit für 60 Sekunden
  And tenant B behält Basisquote
  And evidence enthält tenant_id, limit_reason und expires_at

Stresstest gegen die Goodhart-Falle wird durch eine separate Mini-Analyse durchgeführt. Der Implementor erhält die Aufgabe, MTTR von 6 auf 2 Minuten zu senken, und schlägt aggressive automatische Eskalation beim ersten Alarmereignis vor.

Lassen Sie den Verifikator nicht nur die Geschwindigkeit, sondern auch die Nebeneffekte prüfen:

Anteil falscher Eskalationen;
Häufigkeit des Rollback-Flatterns (rollback-flapping, wiederholte Rollbacks in kurzem Fenster);
Volumen wiederholter Benachrichtigungen;
Vorhandensein eines Abkühlfensters (cooldown).

Wenn der schnelle Plan die false_escalation_rate über den zulässigen Schwellenwert erhöht, hält der Koordinator FAIL(reason=metric corruption) in judgment.md fest und verlangt eine Korrektur von validation.md, keine kosmetische Erklärung im Chat. So lernt der Schiedsrichter, echte Verbesserung von der Optimierung einer einzelnen Zahl auf Kosten der operativen Stabilität zu unterscheiden.

Zusammenfassung

Der dateibasierte Schiedsrichter macht Streitlösungen reproduzierbar. Der Koordinator steuert die Phasen und das Protokoll. Der Implementor ändert nur kontrollierte Artefakte. Der Verifikator verlangt Hook-Logs, JSON-Schema und Given/When/Then. Alle Konflikte laufen durch Diffs in requirements.md, hooks.md, validation.md und gelangen bei Bedarf in precedents.md.

Rollenrotation verwandelt verschiedene Tier-Agenten in ein Werkzeug zur Prüfung der Spezifikationsstabilität. Wenn sich das Urteil bei Wechsel des Implementor/Verifikator-Paars ändert, verstärken Sie die Beweise, statt sich auf die Autorität eines bestimmten Modells zu verlassen.

Die Anti-Goodhart-Regel schließt den Kreis: Sie verbietet, schnelle Entscheidungen zu akzeptieren, die MTTR auf Kosten falscher Eskalationen, stiller Fehler oder Rollback-Flatterns verbessern. Als Nächstes wird dieser Schiedsrichterkreis in die Ökonomie der Tier-Routing und die Token-Verteilung zwischen Rollen übergehen.

Artefakte und Bereitschaftskriterien

Artefakt	Bereit, wenn
`judgment.md` (oder sein Auszug)	beim Urteil gibt es einen Grund und `evidence_ref` auf Diff, Hook-Log, Schema oder Given/When/Then, nicht auf Nacherzählung
`out/duel.json` und `out/invariants.json`	lokal reproduzierbar; ausführbares Beispiel in `book2/examples/tribunal` besteht smoke-pass
Eintrag `precedents.md`	wird erstellt, wenn Konflikt wiederholbar; sonst übersprungen

Der vollständige Track fügt judgment.md mit Runden der abstimmenden Rollen (Verifikator/Implementor/Safety) unter Protokoll des Koordinators hinzu, eine Urteilsmatrix nach Tier-Paaren für eine unveränderte Spezifikation und Anti-Goodhart-Invarianten als obligatorischen Teil des Schiedsrichters. Betrachten Sie ihn als bereit, wenn die Urteilsabweichung nach Tier-Paaren durch einen Unterschied in validation.md erklärt ist, Anti-Goodhart-Schwellen schnelle aber schädliche Pläne blockieren und wiederholte Konflikte in precedents.md eingetragen sind.

Praxis

cd book2/examples/tribunal && python3 scripts/run_duel.py --spec specs/autoscale_spec.yaml --cases cases --out out/duel.json && python3 scripts/check_invariants.py --metrics metrics/validation_metrics.json --out out/invariants.json && python3 scripts/write_judgment.py --duel-out out/duel.json --invariants-out out/invariants.json --to out/judgment.md — *Erwartung: in out/judgment.md abschließendes verdict mit evidence_ref auf konkreten Fall.*
Halten Sie die Beweise fest, die der Verifikator annehmen darf: Diff, Hook-Log, Schema, Given/When/Then. *Erwartung: in out/judgment.md zeigt Feld evidence_ref auf Datei, nicht auf Nacherzählung.*
Übertragen Sie einen wiederholenden Konflikt in capstone/precedents.md nach dieser Vorlage (Minimalfelder):

   - case_id: "PREC-001"
     verdict: "DENY"
     evidence_ref: "tests/regression_001.json"
     applies_to: "auto-remediation ohne vollständigen audit_trace"
     next_check: "Duell wiederholen bei Änderung von manual_review_floor"

*Erwartung: der nächste analoge Streit wird durch Verweis auf PREC-001 gelöst, nicht durch wiederholte Runde.*

Kontrollfragen

Wodurch unterscheidet sich der Koordinator von Verifikator und Safety, und warum stimmt er nicht gleichberechtigt mit ihnen ab?
Warum muss ein Streit durch Diffs und nicht durch Nachrichtenaustausch gelöst werden?
Was zeigt die Abweichung des Urteils bei Wechsel der Tier-Agenten?
Implementor und Verifikator kommen drei Runden hintereinander zu keiner Entscheidung, die Vorfallwarteschlange wächst. Welche Stoppbedingung und welches Artefakt halten Sie fest, bevor der Streit an einen Menschen übergeben wird?