Anwendungsteil 8. Datei-basierte Schlichtung strittiger Änderungen: Rollen, Urteile und Präzedenzfälle

Status: Frontier. Die datei-basierte Schlichtung Verifier/Implementor/Safety (stimmen ab) mit dem Protokoll des Koordinators und der Aufzeichnung in judgment.md (Entscheidung zum Streit) und precedents.md (Präzedenzfälle) ist eine Technik, die angewendet wird, aber in Qwen Code nicht eingebaut ist. Kompatibilität und Einschränkungen finden sich in appendix-b-qwen-code-compatibility.md.

Für den Lerndurchlauf genügt es, judgment.md aus dem ausführbaren Beispiel zu erhalten und zu verstehen, welche Beweise der Verifier akzeptiert. Die Rotation der Stufen, der externe Koordinator und die Modellmatrix gehören zum vollständigen Produktions-Track.

Die Abgrenzung zu Kapitel 4 ist folgende: Das LLM-Duell beantwortet die Frage „Wurde ein minimales Gegenbeispiel gefunden und womit wurde es geschlossen?“. Die datei-basierte Schlichtung beantwortet eine andere Frage: „Welches offizielle Urteil fällt die Rollengruppe, welche Beweise werden als zulässig anerkannt und welcher Präzedenzfall bleibt für zukünftige Streitigkeiten erhalten?“.

Die datei-basierte Schlichtung sucht nicht selbst nach allen Defekten. Sie nimmt die Ergebnisse anderer Mechanismen als Beweise an: das Gegenbeispiel aus dem Duell, den Spec-CI-Bericht, die Anti-Goodhart-Invariante, das Readiness-Gate oder den Eintrag zum Mutanten. Wenn kein Beweis in der Datei vorliegt, darf der Koordinator den Eindruck eines Agenten nicht in ein Urteil verwandeln.

Die Team-Review aus Teil 16 des ersten Bandes ist das Basisschema: ein menschlicher Reviewer prüft einen Pull Request anhand eines Beweispakets. Hier wird dasselbe Schema um eine Stufe angehoben. Statt einer einzelnen Person arbeiten die Rollen: Verifier, Implementor und Safety stimmen ab; der Coordinator führt das Protokoll und stimmt nicht ab. Statt Kommentaren im PR gibt es zwei Dateien: judgment.md (Logbuch der Streitentscheidungen) und precedents.md (Datenbank wiederkehrender Streitigkeiten). Die Grundlage ändert sich dabei nicht: Urteile werden mit den Fakten aus validation.md aus Teil 9 abgeglichen, und die Ergebnisse überarbeiten die Roadmap genauso wie bei der Umplanung aus Teil 10.

Vor dem Lesen

• Grundlage aus dem ersten Band: Teil 16 legt die Team-Review fest, Teil 10 zeigt die Umplanung nach Fakten.

• Lokaler Lernfall: autoscale_200pct, weil dafür bereits das Duell, die 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 Durchgangs: datei-basierte Schlichtung und judgment.md. Die Rollen (Verifier/Implementor/Safety + Coordinator als Protokollant) sind bereits in Teil 3 eingeführt worden – hier erhalten sie ihre verfahrenstechnische Ausgestaltung.
• Was zurückzustellen ist: die Modellmatrix, der externe Koordinator und die dauerhafte precedents.md-Datenbank.

Ziel

Sie lernen, eine datei-basierte Schlichtung einer strittigen Änderung durchzuführen. Dies ist eine kollektive Überprü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 Rotation der Rollen, Modelle und Strengemodi reproduzierbar geprüft wird.

Die Rotation der Rollen bedeutet, dieselbe Spezifikation mit verschiedenen Implementor/Verifier-Paaren auszuführen (lokaler oder starker Agent auf jeder Position). Sie ist nötig, damit das Urteil nicht von einem bestimmten Modell abhängt.

Der praktische Gewinn ist einfach: Der Streit hört auf, ein Meinungsaustausch im Chat zu sein, und wird zu einer Beweiskette. Der Coordinator führt den Prozess. Der Implementor schlägt Änderungen vor. Der Verifier nimmt sie nach formalen Kriterien an oder lehnt sie ab. Die Safety-Rolle erhält ein Veto bei critical_risk. Das Ergebnis wird in den Projektartefakten festgehalten.

Dieser Ansatz führt die SDD-Logik fort: Die Spezifikation bleibt die Wahrheitsquelle für das Systemverhalten, nicht eine optionale Beschreibung der Absichten des Entwicklers (GitHub Spec Kit).

Die ingenieurmäßige Bezeichnung des Mechanismus lautet datei-basiertes Schlichtungsprotokoll für strittige Änderungen mit mehreren Rollen. Der Name tribunal bleibt ein technisches Etikett für das Verzeichnis des ausführbaren Beispiels, nicht ein eigenständiges Qwen-Code-Produkt.

Minimales Lernszenario

Lernfall

Derselbe autoscale_200pct, aber nun wird nicht nur ein Gegenbeispiel benötigt, sondern ein offizielles Protokoll: das Duell, Anti-Goodhart-Invarianten und das abschließende 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

1. cd book2/examples/tribunal. Erwartung: Sie befinden sich im Verzeichnis des ausführbaren Beispiels.
2. python3 scripts/run_duel.py --spec specs/autoscale_spec.yaml --cases cases/ --out out/duel.json. Erwartung: Das Duell hat die Urteile zu den Fällen aufgezeichnet.
3. python3 scripts/check_invariants.py --metrics metrics/validation_metrics.json --out out/invariants.json. Erwartung: Die Anti-Goodhart-Invarianten sind getrennt vom Duell geprüft.
4. python3 scripts/write_judgment.py --duel-out out/duel.json --invariants-out out/invariants.json --to out/judgment.md. Erwartung: Das abschließende Markdown-Protokoll ist erschienen.
5. Öffnen Sie out/judgment.md und übertragen Sie einen wiederkehrenden Konflikt nach 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 einem erneuten Streit tun muss. Ohne dies bleibt die datei-basierte Schlichtung ein Duell aus Kapitel 4.

Wie dies in capstone/ landet

Übertragen Sie nach capstone/judgment.md ein Urteil, den Grund, evidence_ref und den nächsten zu prüfenden Schritt. Wenn der Konflikt wiederkehrend ist, fügen Sie einen kurzen Präzedenz-Eintrag hinzu. Übertragen Sie nicht die gesamte out/duel.json, wenn sie sich durch einen Befehl aus dem ausführbaren Beispiel reproduzieren lässt.

Minimaler Auszug:

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"

Überprüfbare Spur

Speichern Sie judgment.md oder einen Auszug in precedents.md, wenn diese Teil des Lern-Beweispakets geworden sind. Lokale out/duel.json und out/invariants.json können außerhalb des Repos verbleiben, wenn sie sich durch einen Befehl reproduzieren lassen.

Schlüsselideen

Der Vertragsrahmen der Phasen der datei-basierten Schlichtung beginnt mit der Rolle des Koordinators. Er eröffnet die Sitzung, legt die Reihenfolge der Runden fest, führt die Warteschlange der Streitigkeiten und ist verantwortlich für das offizielle Protokoll in judgment.md. Das judgment.md selbst ist das Logbuch der Sitzungsentscheidungen: welche Runde stattgefunden hat, welche Differenz (diff) geprüft wurde, welche Beweise als ausreichend anerkannt wurden.

Der minimale Zyklus sieht so aus: Der Coordinator nimmt die Ausgangsspezifikation entgegen, zerlegt sie in prüfbare Dateien, weist die Rollen Implementor, Verifier und Safety für kritische Risiken zu und verbietet den Übergang zur nächsten Phase ohne Aufzeichnung des Ergebnisses der vorhergehenden. Die vollständige Rollencharta mit Stimmgewichten (vote_weight), Quorum und Veto-Bedingungen findet sich in Teil 3. Hier interessiert uns, wie diese Rollen um eine konkrete strittige Änderung herum arbeiten.

Was dies praktisch bedeutet. Nehmen wir ein kurzes Urteil aus dem Chat:

Schlecht: > „Der Verifier hat den Vorschlag des Implementors abgelehnt.“

Problem: Es gibt keine Begründung und keine Beweis-Referenz (evidence_ref), der Streit ist nicht reproduzierbar. Ein nächster Reviewer wird das Urteil weder anfechten noch unterstützen können.

Gut: > verdict=DENY, reason=violates_invariant:silent_p0, evidence_ref=tests/regression_001.json, next_step=Der Implementor fügt eine Severity-Prüfung vor der automatischen Eskalation hinzu

evidence_ref ist hier dieselbe Beweis-Markierung wie in Teil 1: ein Verweis auf eine konkrete Stelle in einer Datei, keine Nacherzählung. silent_p0 ist die Invariante „Kein P0-Vorfall darf ohne Eskalation geschlossen werden“. Wenn der Verifier DENY zurückgibt, schließen Sie den Streit nicht manuell. Verlangen Sie von der Seite eine formale Begründung: Verweis auf eine konkrete Anforderung, ein Hook-Log, einen Schema-Verstoß oder ein unbewiesenes Szenario. So wird judgment.md nicht zum Bericht „Wer hat gewonnen“, sondern zum Logbuch des Verfahrensstands.

In Qwen Code ist eine solche Schlichtung kein einzelner eingebauter Befehl. Die minimale Implementierung wird aus /review, Headless-Aufrufen von qwen -p, Projektskripten und bei Bedarf benutzerdefinierten Befehlen zusammengesetzt. Speichern Sie alle Urteile in Dateien, damit ein anderer Ingenieur den Streit ohne Chat-Verlauf wiederholen kann. Die ausführliche Zuordnung von Rollen und eingebauten CLI-Fähigkeiten findet sich in [appendix-b-qwen-code-compatibility.md](appendix-b-qwen-code-compatibility.md).

> [runnable] — Das ausführbare Beispiel der datei-basierten Schlichtung liegt in [examples/tribunal/](examples/tribunal/) (siehe [examples/tribunal/README.md](examples/tribunal/README.md)). Ein realer Lauf wird aus drei Skripten zusammengesetzt:

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

Aus dem Verzeichnis book2/examples/tribunal ausführen.

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 die Gegenbeispiele aus cases/ durch. check_invariants.py gleicht die tatsächlichen Metriken mit den Schwellen ab. write_judgment.py setzt das abschließende Markdown-Protokoll zusammen. Es gibt keine externen „Koordinatoren“ oder „Verifier“ als eigenständige Prozesse. In der Produktion wird eine solche Schlichtung aus dem eingebauten Befehl /review, Headless-Aufrufen von qwen -p mit verschiedenen Rollen im Prompt und Projektskripten zusammengesetzt – jeder mit seinem eigenen Artefakt auf der Festplatte.

Der A/B-Vergleich ein und derselben Spezifikation zwischen verschiedenen Implementor/Verifier-Konfigurationen zeigt, wie stark das Urteil vom Agenten der jeweiligen Stufe abhängt. Die Modellstufe (tier) ist hier das Modellniveau: günstiges lokales (local-coder) oder starkes Cloud-Modell (frontier-reviewer). Dieselbe rate_limit_spec.md wird durch mehrere Paare ausgeführt:

• C1: günstiger lokaler Implementor gegen starker Verifier;
• C2: starker Implementor gegen lokaler Verifier;
• C3: symmetrisches lokales Paar;
• C4: symmetrisches teures Paar.

Wenn C1 und C4 PASS ergeben und C2 stabil FAIL zurückgibt, ist dies kein Signal für einen sofortigen Modellwechsel. Prüfen Sie zuerst den Beweisrahmen: Der Verifier mit der schwächeren Stufe hat möglicherweise die implizite Verbindung zwischen Anfragelimit, Abkühlfenster (cooldown) und sicherem Warteschlangenzustand nicht erkannt.

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

Das Lern-Pendant zum Runnable findet sich in [examples/tribunal/matrix/](examples/tribunal/matrix/README.md): derselbe judge() aus dem Duett wird durch die vier Stufenpaare aus matrix/tiers.json geschickt. Die Konfiguration modelliert die Kluft zwischen Beweisformen – local-coder liefert einen kurzen diagnostic_code (minimal_form), frontier-reviewer eine Struktur evidence_by_invariant (extended_form), und ein schwacher Verifier erkennt nur minimal_form. Daher fällt das Paar C2 (starker Implementor + schwacher Verifier) stabil aus, die anderen drei bestehen – genau dies ist das Lernsignal 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 einzutragen

In einem Produktionsprojekt steht hinter dieser Ausgabe scripts/tribunal_matrix.py – es ersetzt judge() durch reale Aufrufe von qwen -p mit verschiedenen Rollen im Prompt, aber die Artefakt-Schnittstelle (summary.signal, pairs[*].verdict, pairs[*].cases[*].reasons) bleibt dieselbe. Wenn die Matrix im Lehrbuch eine Abweichung zeigt, ist der Exit-Code 1, und in smoke_all.sh ist dies in expect_fail eingewickelt: Die Abweichung ist hier das gezielte Lernsignal, kein Fehler.

Formulieren Sie für den Verifier keine allgemeine Anfrage „prüfe die Lösung“, sondern strenge Beweisanforderungen. Es gibt drei davon: Hook-Logs, Konformität mit JSON Schema und formale Szenarien Given/When/Then.

PreToolUse-Logs zeigen, welche Werkzeugaufrufe vor der Ausführung erlaubt oder blockiert wurden. PostToolUse-Logs halten das tatsächliche Ergebnis, den Exit-Code, die Prüfsumme der Differenz (diff) und den Verweis auf das Ereignis in den Beweisen fest.

JSON Schema schließt eine Klasse von Fehlern, bei denen der Agent überzeugenden Text erzeugt, aber den Datenvertrag verletzt. Beispiele für solche Verstöße:

• ein Pflichtfeld fehlt;
• der Parametertyp wechselt von integer zu string;
• das Limit wird außerhalb des zulässigen Bereichs gesetzt.

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

flowchart TD
    COORD[Coordinator: Eintrag in Anforderungen]
    IMPL[Implementor: patch_plan und Hooks]
    PRE[PreToolUse: Blockieren gefährlicher Aktionen]
    POST[PostToolUse: Beweise und Hash]
    VER["Verifier: 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

Der Konflikt wird ausschließlich über Diffs in requirements.md, hooks.md, validation.md gelöst. Versteckte Änderungen im Chat-Dialog sind von der Beweisgrundlage 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 Coordinator nimmt eine erneute Runde nur an, nachdem die Differenz mit der Ausgangsspezifikation und einem konkreten Beweis-Ereignis verknüpft ist. Andernfalls wird der Streit zu einer nicht reproduzierbaren privaten Geschichte. Bei einem wiederkehrenden Konflikt übertragen Sie die Entscheidung in precedents.md – das Präzedenz-Logbuch, in dem für jeden Fall genau fünf Felder festgehalten werden:

• case_id – stabiler Identifikator des Präzedenzfalls;
• verdict – Ergebnis nach der Schlichtungsregel (APPROVE / DENY / DEFERRED);
• evidence_ref – Verweis auf die Differenz, das Hook-Log, das Schema oder das Szenario, das das Urteil bewiesen hat;
• applies_to – Grenzen der Anwendbarkeit des Präzedenzfalls (Stufen, Strengemodi, 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 tenant_id-Deduplizierung, alle Stufen, strict_guardrails_prompt"
  next_check: "burst_window_sec wird über 60 angehoben oder es erscheint ein Beweis für tenant_id-Isolation"

Die Anti-Goodhart-Regel schützt die datei-basierte Schlichtung vor Situationen, in denen eine Metrik auf Kosten der Systemverschlechterung verbessert wird. MTTR (mean time to recovery, mittlere Wiederherstellungszeit) kann einen Anstieg falscher Eskalationen, stiller Ausfälle (silent failure) oder von Rollback-Flapping nicht rechtfertigen. Dies gilt auch dann, wenn eine einzelne Runde ein schnelles PASS zeigt.

Legen Sie daher in validation.md strenge Stopp-Bedingungen fest:

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

Eine Überschreitung einer beliebigen Schwelle überführt das Urteil unabhängig vom Zeitgewinn in FAIL. Dies verwandelt den Goodhart-Schutz von einer moralischen Warnung in eine ausführbare Schlichtungsregel.

Beispiele und Anwendung

Beispiel: Die Spezifikation für automatisches Rate-Limiting im API-Gateway verlangt, bei einem Anfragesturm einen bestimmten Mandanten (tenant) vorübergehend zu beschränken, aber nicht den gesamten Dienst zu blockieren und nicht jeden Burst als P0 zu eskalieren.

Der Implementor schlägt einen Patch vor:

• tenant_id zum Deduplizierungsschlüssel hinzufügen;
• ein Fenster burst_window_sec=60 einführen;
• nach jeder Limit-Anwendung ein Ereignis in evidence/rate_limit.ndjson schreiben.

Der Verifier entscheidet nur, wenn drei Beweise vorliegen:

• JSON Schema verlangt tenant_id, limit_reason, expires_at;
• PreToolUse verbietet die Änderung des globalen Limits ohne Geltungsbereich des konkreten Mandanten;
• Given/When/Then zeigt, dass ein Burst eines Mandanten das Kontingent eines benachbarten Mandanten nicht senkt.

Fehlt einer dieser Beweise, gibt der Verifier DENY zurück, auch wenn der Patch technisch plausibel erscheint.

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

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

Dies bedeutet nicht, dass ein Agent „recht hat“ und der andere „irrt“. Die Schlichtung zeigt, dass die Anforderung zwischen den Modellstufen nicht ausreichend übertragbar ist. Die Korrektur muss als Differenz (diff) erscheinen – z. B. die Ergänzung des Szenarios Given tenant A exceeds burst limit / When tenant B sends normal traffic / Then tenant B quota remains unchanged.

Szenario: Mandantenisolation bei Lastburst
  Given Mandant A sendet 800 req/min
  And Mandant B sendet 40 req/min
  When der Rate-Limit-Hook die Beschränkung anwendet
  Then erhält Mandant A ein zeitweises Limit für 60 Sekunden
  And Mandant B behält sein Basiskontingent
  And evidence enthält tenant_id, limit_reason und expires_at

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

Zwingen Sie den Verifier, nicht nur die Geschwindigkeit, sondern auch die Nebenwirkungen zu prüfen:

• Anteil falscher Eskalationen;
• Häufigkeit von Rollback-Flapping (wiederholte Rollbacks in einem kurzen Zeitfenster);
• Volumen wiederholter Benachrichtigungen;
• Vorhandensein eines Abkühlfensters (cooldown).

Wenn der schnelle Plan false_escalation_rate über die zulässige Schwelle anhebt, hält der Coordinator FAIL(reason=metric corruption) in judgment.md fest und verlangt eine Änderung in validation.md, nicht eine kosmetische Erklärung im Chat. So lernt die Schlichtung, eine echte Verbesserung von der Optimierung einer einzelnen Zahl auf Kosten der Betriebsstabilität zu unterscheiden.

Zusammenfassung

Die datei-basierte Schlichtung macht die Streitbeilegung reproduzierbar. Der Coordinator steuert die Phasen und das Protokoll. Der Implementor ändert ausschließlich kontrollierte Artefakte. Der Verifier verlangt Hook-Logs, JSON Schema und Given/When/Then. Alle Konflikte laufen über Diffs in requirements.md, hooks.md, validation.md und landen bei Bedarf in precedents.md.

Die Rotation der Rollen verwandelt Stufenagenten unterschiedlicher Stärke in ein Werkzeug zur Prüfung der Spezifikationsrobustheit. Wenn sich das Urteil beim Wechsel des Implementor/Verifier-Paares ändert, verstärken Sie die Beweise, anstatt sich auf die Autorität eines bestimmten Modells zu verlassen.

Die Anti-Goodhart-Regel schließt den Kreis: Sie verbietet schnelle Entscheidungen, die MTTR auf Kosten falscher Eskalationen, stiller Ausfälle oder von Rollback-Flapping verbessern. Im nächsten Schritt geht dieser Schlichtungskreis in die Ökonomie der Stufen-Routing und der Token-Verteilung zwischen den Rollen über.

Decision trace statt verborgener Argumentation

Die Schlichtung benötigt nicht den vollständigen Gedankengang des Modells. Sie braucht ein reproduzierbares Entscheidungsprotokoll: welche Fakten extrahiert wurden, welche Red Flags geprüft wurden, welche Policy angewendet wurde und welches Urteil sich ergeben hat. Daher wird eine strittige Schlussfolgerung als phasenweiser decision_trace formuliert, nicht als freier Text „das Modell hat nachgedacht“.

Minimale Struktur:

case_id: "JDG-001"
facts:
  - "readiness_block_audit.json liefert score=22/25"
  - "audit_trace_coverage=0.7"
checks:
  - rule: "auto mode requires audit_trace_coverage=1.0"
    status: "fail"
  - rule: "score >= 23"
    status: "fail"
policy_outcome: "deny_auto_mode"
verdict: "DENY"
evidence_ref: "fixtures/readiness_block_audit.json"
customer_safe_summary: "Automatikmodus blockiert bis zum vollständigen audit_trace"
internal_note: "Process evidence korrigieren, dann Readiness wiederholen"

Ein solcher Trace kann einem anderen Verifier oder einer Safety-Rolle ohne Chat-Verlauf übergeben werden. Wenn sich das Urteil ändert, vergleicht das Team die Felder facts, checks und policy_outcome, anstatt über den Erklärungsstil zu streiten.

Artefakte und Fertigkeitskriterien

Der vollständige Track fügt judgment.md mit Abstimmungsrunden der stimmberechtigten Rollen (Verifier/Implementor/Safety) unter dem Protokoll des Koordinators, eine Urteilsmatrix nach Stufenpaaren für eine unveränderte Spezifikation und Anti-Goodhart-Invarianten als obligatorischen Teil der Schlichtung hinzu. Betrachten Sie ihn als fertig, wenn die Urteilsabweichung zwischen den Stufenpaaren durch Unterschiede in validation.md erklärt ist, die Anti-Goodhart-Schwellen einen schnellen, aber schädlichen Plan blockieren und wiederkehrende Konflikte in precedents.md eingetragen sind.

Praxis

1. 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 das abschließende verdict mit evidence_ref auf einen konkreten Fall.*
2. Halten Sie die Beweise fest, die der Verifier annehmen darf: Differenz, Hook-Log, Schema, Given/When/Then. *Erwartung: in out/judgment.md verweist das Feld evidence_ref auf eine Datei, nicht auf eine Nacherzählung.*

1. Übertragen Sie einen wiederkehrenden Konflikt in capstone/precedents.md anhand dieser Vorlage (Mindestfelder):

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

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

Kontrollfragen

1. Wodurch unterscheidet sich der Coordinator vom Verifier und von Safety, und warum stimmt er nicht gleichberechtigt mit ihnen ab?
2. Warum muss ein Streit durch Diffs gelöst werden, nicht durch Hin-und-her-Schreiben?
3. Was zeigt eine Urteilsabweichung beim Wechsel der Stufenagenten?
4. Implementor und Verifier finden drei Runden lang keine Lösung, die Vorfall-Warteschlange wächst. Welche Stopp-Bedingung und welches Artefakt halten Sie fest, bevor Sie den Streit an einen Menschen übergeben?