Glossar des angewandten Bandes

Konsolidierte Liste der Begriffe des zweiten Bandes des Lehrbuchs. Die Definitionen werden hier dupliziert, damit in den Kapiteln keine Widersprüche entstehen. Wenn ein Begriff bereits im ersten Band eingeführt wurde, wird hier eine Produktionspräzisierung und ein Verweis auf das Kapitel im zweiten Band gegeben, in dem er zur Anwendung kommt.

Lesen Sie das Glossar nicht vollständig, bevor Sie mit dem zweiten Band beginnen. Für die erste Durchsicht reicht es aus, capstone/ und die zehn obligatorischen Artefakte des ersten Durchlaufs zu verstehen (die vollständige Liste finden Sie im README, Abschnitt „Obligatorische Artefakte des ersten Durchlaufs"). Die übrigen Begriffe schlagen Sie nach, wenn sie Ihnen helfen, eine bestimmte Datei auszufüllen oder ein ausführbares Beispiel zu verstehen.

Die Leseregel ist einfach: Den Dateinamen oder YAML/JSON-Schlüssel können Sie auf Englisch belassen, aber in der Erklärung wählen Sie eine deutsche Bedeutung. Zum Beispiel ist judgment.md eine Datei für die Streitentscheidung; tribunal ist ein Datei-Schiedsverfahren und kein eigenständiges Produkt oder eingebauter Qwen-Code-Befehl.

Die wichtigsten Formen in der Prosa, die standardmäßig verwendet werden sollten (der englische Schlüssel nur in Codeblöcken und bei der ersten Erwähnung in Klammern):

• „stiller P0" — in der Prosa; silent_p0, silent_p0_cap, silent_p0_ratio — überall im Code, in YAML/JSON-Schlüsseln, Befehlen und Metrik-Beschriftungen;
• „Spec CI" oder „Spezifikations-Gateway (Spec CI)" — in der Prosa; spec_gate — nur als Aufgabenname in .github/workflows/spec-ci.yml;
• „Datei-Schiedsverfahren" — in der Prosa; tribunal — nur als Verzeichnisname examples/tribunal/ und für dessen Skripte;
• „Notfallmodus" — in der Prosa; „roter Knopf" — als kurze Bezeichnung; red_button, red_button_mttr_blindness — nur als Namen von Invarianten in YAML.

Übersetzungstabelle der Schlüsselbegriffe

In der Prosa des zweiten Bandes verwenden wir standardmäßig das deutsche Äquivalent des Begriffs und geben bei der ersten Erwähnung in einem Kapitel den englischen Schlüssel in Klammern an, zum Beispiel: „Evidenzvermerk (evidence_ref)". Diese Tabelle ist ein Arbeitsnachschlagewerk: welche Begriffe übersetzt werden, welche als technische Namen auf Englisch bleiben, welche als zusammengesetzter deutsch-englischer Begriff existieren. Wenn ein Kapitel nur die deutsche Variante verwendet, können Sie hierher zurückkehren und nachprüfen, was dahinter steht.

Die Klasse „technischer Name" bedeutet einen Bezeichner in YAML/JSON, einen CLI-/Skriptnamen, einen Statusnamen oder einen Konfigurationsschlüssel — diesen fassen wir nicht an. Die Klasse „Begriff mit doppelter Schreibweise" — ein Anglizismus wird als zusammengesetzter Prozessmarker verwendet; in der Prosa führen wir das deutsche Äquivalent ein, lassen aber beide Schreibweisen zu. Die Klasse „Prosabgriff" — der Anglizismus wird vollständig eingedeutscht, im Haupttext bleibt nur die deutsche Form.

| judgment, judgment.md | Streitentscheidung; Dateinamen nicht ändern | Begriff mit doppelter Schreibweise | | precedent, precedents.md | Präzedenzfall; Dateinamen nicht ändern | Begriff mit doppelter Schreibweise | | audit_trace_coverage | Audit-Trace-Abdeckung (Metrik, Schlüsselname beibehalten) | technischer Name | | shadow specs, shadow spec | Schattenspezifikationen; in Überschriften beide Schreibweisen zulässig | Begriff mit doppelter Schreibweise | | stress spec, stress-spec | Stresstest-Spezifikation | Prosabgriff | | guard metric, guard-метрика | gepaarte Gegenmetrik, Guard-Metrik | Begriff mit doppelter Schreibweise | | kill switch | Notausschalter, Kill Switch | Begriff mit doppelter Schreibweise | | playbook | Playbook | Prosabgriff (Lehnwort) | | runbook | Runbook | Prosabgriff (Lehnwort) | | readiness gate, readiness | Bereitschafts-Gateway, Bereitschaft; Modellpunktname beibehalten | Begriff mit doppelter Schreibweise | | rollback, rollback_condition | Rollback; Schlüssel rollback_condition beibehalten | Begriff mit doppelter Schreibweise | | dry run, dry-run | Probelauf | Prosabgriff | | webhook | Webhook | Prosabgriff (Lehnwort) | | auction | Auktion | Prosabgriff (Lehnwort) |

| tribunal | Datei-Schiedsverfahren für strittige Änderungen; technischer Name des Verzeichnisses und der Beispielskripte | technischer Name | | Verifier, Implementor, Safety, Coordinator | Verifier, Implementor, Safety (stimmen ab), Koordinator (non-voting protocolist) — in der Prosa; Rollennamen in YAML und im Code bleiben englisch | Begriff mit doppelter Schreibweise | | immunity score | Immunitätsmetrik (Vektor) | Prosabgriff | | tier (low/mid/high, local-coder, frontier-reviewer) | Stufe (niedrig/mittel/hoch) in der Prosa; Schlüssel und Rollennamen in YAML — ohne Übersetzung | Begriff mit doppelter Schreibweise | | mutation, mutation testing | Mutation, Mutationstests | Prosabgriff (Lehnwort) | | coverage, coverage-check | Abdeckung, Abdeckungsprüfung | Prosabgriff | | scope, scope-check, out-of-scope | Geltungsbereich, Bereichsprüfung, Bereichsüberschreitung | Prosabgriff | | failover | Failover, Ausfallumschaltung | Begriff mit doppelter Schreibweise | | blast radius | Auswirkungsradius, Blast Radius | Begriff mit doppelter Schreibweise | | gate, spec gate | Gateway, Spezifikations-Gateway (gate) | Begriff mit doppelter Schreibweise |

| manual_review_floor, manual_review_rate | Mindestanteil manueller Prüfung, Anteil manueller Prüfung; Schlüssel beibehalten | technischer Name | | genealogy, genealogy.md | Genealogie; Dateinamen nicht ändern | Begriff mit doppelter Schreibweise | | ttl, time to live | Lebenszeit (ttl); Schlüssel beibehalten | technischer Name | | few-shot | Beispielhinweis, Few-Shot | Begriff mit doppelter Schreibweise | | scorebook | Bewertungsjournal (scorebook); Dateinamen nicht ändern | Begriff mit doppelter Schreibweise | | pre-approved actions | vorab genehmigte Aktionen | Prosabgriff | | quarantine | Quarantäne | Prosabgriff | | ask_storm, stage_regress, phase_context_loss | Namen der Antimuster unverändert beibehalten; bei erster Erwähnung im Kapitel kurzen deutschen Kommentar geben | technischer Name | | capstone, dossier | Abschluss-Prüfungspaket, Evidenzpaket | Begriff mit doppelter Schreibweise |

Technische Namen, die unverändert bleiben und weder in der Prosa noch in den Tabellen übersetzt werden: YAML/JSON-Schlüssel (immutable_principles, mutable_rules, governance_protocol, incident_type, pipeline_phase, permitted_actions, max_scope, rollback_condition, decision_hash, parent_version, change_log, audit_trace, prompt_hash, decision_source, next_guard und ähnliche), Dateinamen (QWEN.md, requirements.md, plan.md, validation.md, mission.md, tech-stack.md, roadmap.md, constitution.md, judgment.md, precedents.md, genealogy.md), Namen von CLI-Befehlen und Skripten (qwen -p, python3 scripts/..., git, npm, rg), Namen von Custom Commands (/sdd:specify, /plan, /review), Statusangaben (Стандарт / Рекомендация / Фронтир), Block-Markierungen ([runnable], [project script]), Abkürzungen (MCP, CI, LLM, API, KPI, MTTR, SLO, SLA, SRE).

Wo der Begriff erstmals eingeführt wird

Die Karte hilft, schnell das Kapitel zu öffnen, in dem ein Begriff erstmals eine Arbeitsdefinition und ein Anwendungsszenario erhält. Metriken (silent_p0, audit_trace_coverage, manual_review_floor) und Speicherschlüssel (shadow-scorebook.json, shadow-candidates.yaml, precedents.md, judgment.md) sind getrennt aufgeführt: Metriken messen das System, Speicherschlüssel bewahren seine Geschichte.

| Metrik | strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms | 5 | | Metrik | mttr_gain, early_signal, coverage, false_escalation | 6 | | Metrik | token_health_min, failover_to_frontier, degraded_queue | 9 | | Metrik | silent_p0, manual_review_floor, audit_trace_coverage | 10 | | Speicherschlüssel | .specify/memory/shadow-candidates.yaml, .specify/memory/shadow-scorebook.json | 6 | | Speicherschlüssel | precedents.md, change_log | 3, 8 | | Mechanismus | Stresstest-Spezifikation, Mutationstests | 5 | | Mechanismus | Schattenspezifikation, Auktion, Scorebook | 6 | | Mechanismus | Spezifikations-Gateway (Spec CI) | 7 | | Mechanismus | Stufen-Routing, local-coder, frontier-reviewer, Budgetverwalter | 9 | | Mechanismus | gepaarte Gegenmetrik, Anti-Goodhart, Notfallmodus | 10 |

| Mechanismus | Dry-Run, Readiness Gate, evidence_ref | 11 |

Wenn ein Begriff in mehreren Teilen vorkommt, ist in der Spalte derjenige angegeben, in dem er eine Arbeitsdefinition und ein ausführbares Szenario erhält. Produktionspräzisierungen und Verknüpfungen zwischen Begriffen sind in Teil 12 und Teil 13 behandelt.

Bezug zum Glossar des ersten Bandes

Dieses Glossar ergänzt, ersetzt jedoch nicht das Glossar des ersten Bandes. Die Grundbegriffe von SDD — QWEN.md, mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md, Qwen-Code-Fähigkeiten, MCP, ACP, EARS, Given/When/Then — sind dort definiert und werden hier nicht wiederholt.

Produktionspräzisierungen werden auf diese Grundbegriffe angewendet:

• validation.md aus dem ersten Band enthält Fakten für die Merge-Freigabe; im zweiten Band wird es um fehlschlagende Fälle aus dem Duell, Anti-Goodhart-Prüfungen, Drift-Felder und Trace-Einträge ergänzt.
• QWEN.md aus dem ersten Band speichert den permanenten Agenten-Kontext; im zweiten Band wird es zum Ort für Few-Shot-Beispiele aus der Schattenspezifikations-Auktion mit Überprüfungsfrist.

• Die Konstitution des ersten Bandes fixiert mission.md + tech-stack.md + roadmap.md; im zweiten Band wird sie um einen expliziten Abschnitt constitution.md mit immutable_principles, mutable_rules und governance_protocol erweitert.

Wenn Ihnen ein Begriff aus diesem Glossar unbekannt vorkommt, beginnen Sie mit der Basisdefinition im ersten Band und lesen Sie anschließend die Produktionspräzisierung hier.

Lernprojekt AgentClinic

Die Produktionsszenarien des angewandten Bandes werden gedanklich auf dem Lernprojekt AgentClinic aus dem ersten Band entfaltet: TypeScript, Hono, serverseitiges JSX, SQLite, Vitest. Python bezieht sich auf die ausführbaren Beispiele des zweiten Bandes: kleine Stdlib-Skripte für lokale Prüfungen, nicht der Stack der Hauptanwendung. Die Domänenentitäten — Agenten-Patienten, Beschwerden, Therapien, Termine, Bewertungen, Feedback — sind in Anhang B des ersten Bandes beschrieben. Die Entsprechung zwischen Lerncode und Produktionsvorfällen ist in der Tabelle in Anhang A des angewandten Bandes festgehalten.

Bildhafte Bezeichnungen

In den Kapiteln werden gelegentlich bildhafte Bezeichnungen verwendet. Sie dienen als Hilfsbezeichnungen, nicht als Hauptbezeichnungen des Prozesses. Die technischen Entsprechungen sind folgende:

• Wiederherstellung von Spezifikationen — Wiederherstellung von Anforderungen aus Legacy-Code, Logs, Vorfällen und der Entscheidungshistorie; „Spec-Nekromantie" ist nur als Hilfsbezeichnung zulässig.
• Vergiftete Spezifikation — absichtlich defekte Übungsspezifikation mit einem kontrollierten Fehler.
• Impfung der Validatoren — Mutationstests für Spezifikationen und Prüfungen.
• Auktion der Schattenspezifikationen (shadow specs) — Bewertung und Rangfolge inoffizieller Heuristiken vor der Aufnahme in den Arbeitskontext.
• Datei-Schiedsverfahren für strittige Änderungen — siehe unten den Abschnitt „Datei-Schiedsverfahren"; tribunal in Datei- und Verzeichnisnamen bleibt eine technische Hilfsbezeichnung des Beispiels.
• Stufen-Routing von Modellen — Verteilung von Aufgaben zwischen Modellen unterschiedlicher Kosten und Qualität.
• Köder-Metriken — KPIs, die sich leicht auf Kosten des Systems optimieren lassen; die technische Verteidigung sind gepaarte Gegenmetriken (Guard Metrics).
• Notfallmodus (red button) — formelles Sicherheits-Gateway vor einer gefährlichen Aktion: Deployment, Rollback, Migration oder Auto-Remediation; „roter Knopf" ist eine umgangssprachliche Bezeichnung.

Agentenrollen

Verifier — Agent oder Sitzung, dessen einzige Aufgabe es ist, Verstöße gegen Invarianten, Verträge und Fakten zu suchen. Darf keinen Code schreiben oder Artefakte ändern, sondern gibt nur das Urteil approve / reject / abstain mit Begründung ab. Details in Teil 4 und Teil 8.

Implementor — Agent, der den Plan im Auto-Edit-Modus nach genehmigter Spezifikation ausführt. Im Datei-Schiedsverfahren stimmt er über die Anwendbarkeit der Korrektur im Playbook ab, darf jedoch das Urteil des Verifier oder der Safety-Rolle nicht umgehen.

Koordinator (Coordinator) — Rolle (Person, CI-Job oder externer Orchestrator), die die endgültige Entscheidung auf Grundlage der Ergebnisse des Datei-Schiedsverfahrens trifft, den Präzedenzfall festhält und judgment.md veröffentlicht. Stimmt nicht gleichberechtigt mit Verifier, Implementor und Safety ab; ist für das Verfahren verantwortlich, nicht für den Inhalt.

Safety — separate Rolle im governance_protocol, die den Auswirkungsradius, Datenschutz, Sicherung der Backups und Rollback-Bedingungen prüft. Hat Veto bei critical_risk: Selbst bei zwei approve von Verifier und Implementor wird die Korrektur abgelehnt. Details in Teil 3.

**Modellstufe (tier, local-coder / frontier-reviewer)** — Modellstufe im Stufen-Routing. local-coder — kostengünstiges lokales Modell zur Codegenerierung und für Entwürfe; frontier-reviewer — teures Frontier-Modell, das nur für kritische Reviews, strittige Urteile und Prüfungen des roten Knopfes verwendet wird. Details in Teil 9.

Budgetverwalter (budget keeper) — externer Dienst oder Skript, der das tägliche Token-Kontingent nach Stufen überwacht und Aufrufe an Frontier-Modelle bei Überschreitung des Limits blockiert. Qwen Code selbst verwaltet das Budget nicht.

Spezifikationen und Artefakte

Schattenspezifikation (shadow spec) — Spezifikation für nicht formalisierbare Nuancen: Tonfall, unausgesprochene Prioritäten, historische Entscheidungen, die nicht in der Hauptdatei requirements.md gelandet sind. Wird separat gespeichert, gewinnt in der Auktion auf Grundlage des Bewertungsjournals (Scorebook) und ersetzt nicht die Hauptspezifikation. Details in Teil 6.

Bewertungsjournal (scorebook) — Bewertungsjournal der Schattenspezifikationen: Formel, Gewichtungen, Budget, Schwellenwerte und Komponenten mttr_gain, early_signal, coverage, false_escalation für jeden Kandidaten. Datei vom Typ .specify/memory/shadow-scorebook.json; wird durch einen Auktionslauf erstellt oder aktualisiert.

Vergiftete Spezifikation (poisoned spec) — Übungsspezifikation, in die bewusst ein Fehler eingebaut wurde: Eskalationszyklus, Prioritätenkonflikt oder versteckte Bereichsüberschreitung (hidden out-of-scope). Wird zum Training des Verifier und der Validatoren verwendet. Details in Teil 2.

Versteckte Bereichsüberschreitung (hidden out-of-scope) — Aktion, die die Spezifikation formal nicht verbietet, aber auch nicht beschreibt, und die der Agent „beiläufig" ausführen würde. Beispiel: Die Spezifikation bittet um die Änderung der Alarm-Routing, der Agent ändert zusätzlich die SLA-Richtlinie. Schutz — expliziter Abschnitt „Außerhalb des Geltungsbereichs" und Spec-CI-Gateway.

Override-Regel — veränderbare Norm in constitution.md, die dem Agenten erlaubt, in einem engen Kontext vom Standardverhalten abzuweichen: für einen bestimmten incident_type, in einer bestimmten pipeline_phase, mit begrenztem max_scope und obligatorischer ttl. Ohne diese Einschränkungen beginnt die Regel, mit den Invarianten zu konkurrieren.

Immutable principle — Regel im Abschnitt immutable_principles von constitution.md, die nicht automatisch deaktiviert werden kann: Verbot des Neustarts der Produktions-DB ohne Backup, des Löschens von Sicherungen, des Bypasses in sicherheitskritischen Namespaces. Wird nur durch ein ausdrückliches Team-Referendum geändert, nicht durch Agentenabstimmung.

Mutable rule — Regel im Abschnitt mutable_rules von constitution.md mit obligatorischen Feldern incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition. Entwickelt sich durch Referendum weiter, wenn unvorhergesehene Vorfälle auftreten.

**proposal.md** — separate Korrekturdatei für constitution.md, die als Vertragsänderung des Risikos durchläuft. Enthält version, parent_version, Begründung, Änderungen in mutable_rules, erwartete Wirkung und rollback_condition. Vorlage — [examples/templates/proposal.md](examples/templates/proposal.md); Referendumsverfahren — in Teil 3.

**precedents.md** — Journal der Präzedenzfälle des Datei-Schiedsverfahrens: Jeder gelöste Konflikt wird als Eintrag case_ref, verletzte Regel, endgültiges Urteil und Verweis auf judgment.md festgehalten. Dient als kürzester Weg zur Lösung wiederkehrender Streitigkeiten; Format — in Teil 8.

**genealogy.md** — Provenienz der wiederhergestellten Spezifikation: für jede Anforderung — Quellenliste, Konfidenzniveau (confirmed, inferred, hypothesis) und offene Frage. Wird bei der Wiederherstellung der Spezifikation aus dem geerbten Kontext erstellt; Details in Teil 1.

Spezifikations-Gateway (spec gate) — CI-Prüfung, die den Merge blockiert, wenn die Spezifikation nicht durch den Plan abgedeckt ist, der Plan — durch Aufgaben, oder die Aufgaben — durch Fakten in validation.md. Konkretes Beispiel — spec_gate in Teil 7.

Abschluss-Paket (capstone dossier) — Dateiensammlung aus Teil 13, die den vollständigen Produktions-SDD-Pfad zu einem Vorfall zeigt: Herkunft der Anforderung, vergifteter Defekt, Korrektur, Konstitution, Prüfung, Urteil, Budget, Anti-Goodhart-Begrenzer, Readiness und Antimuster-Audit.

Immunitätsmetriken und Goodhart-Schutz

Immunitätsmetrik (immunity score) — Vektor von Validatorbewertungen, keine einzelne aggregierte Zahl. Besteht aus drei Komponenten: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms. Wird als Gateway des Validator-Kreislaufs bei Mutationstests von Spezifikationen verwendet.

**strict_reject_rate** — Anteil der entarteten Fälle (Mutanten), die strikt im erwarteten Given/When/Then-Schritt abgelehnt werden. Ein Anstieg dieser Metrik bei gleichzeitigem Abfall von depth_of_diagnostics bedeutet, dass der Validator strenger, aber „blinder" geworden ist.

**depth_of_diagnostics** — nützliche Erklärungstiefe vor dem Fehlschlag: wie viele Trace-Schritte der Validator durchlaufen hat, bevor er das Urteil zurückgibt. Tiefe 1 bedeutet „abgelehnt", Tiefe 3+ bedeutet „abgelehnt, weil Feld X in Schritt Y die Regel Z verletzt".

**recovery_time_p95_ms** — p95 der Zeit (in Millisekunden), die der Validator benötigt, um ein stabiles Urteil und einen diagnostischen Pfad nach einer Spezifikationsänderung zurückzugeben. Das Überschreiten des Schwellenwerts (z. B. 1200ms) provoziert Umgehungspraktiken und verlangsamt CI.

**silent_p0** — Anteil der Vorfälle der Stufe P0, die die Automatisierung ohne menschliche Bestätigung und ohne Eintrag im Audit Trail durchlaufen haben. Anti-Goodhart-Metrik: Wenn MTTR fällt und silent_p0 steigt, beschleunigt sich die Auto-Remediation auf Kosten versteckter Risiken. Details in Teil 10.

**manual_review_floor** — Mindestanteil der Entscheidungen, die zwingend ein menschliches Review durchlaufen müssen, selbst wenn die Automatisierung formal funktioniert. Schutz vor einseitiger Optimierung: verbietet dem Agenten, den Menschen vollständig aus dem Kreislauf zu verdrängen.

**audit_trace_coverage** — Anteil der Agentenaktionen, für die eine vollständige Evidenzkette gespeichert ist: Eingabe-Payload, Spezifikationsversion, Konstitutionsversion, Abstimmungsprotokoll, decision_hash. Zielwert — 100%; ein Abfall blockiert Merge und roten Knopf.

Anti-Goodhart — allgemeine Entwurfstechnik für Metriken gepaart mit Gegengiften. Jeder Zielmetrik (MTTR, edge_drift) wird eine Wächtermetrik (silent_p0, manual_review_floor, audit_trace_coverage) zugeordnet, und das CI-Gateway wird nur bei gleichzeitiger Erfüllung beider durchlaufen.

Mutationen und Stresstests

Mutationsoperator — Funktion, die eine korrekte Spezifikation nimmt und genau einen Fehler einer bekannten Klasse einbaut. Jeder Mutation wird eine mutation_id, ein erwarteter expected_failure und ein halt_before-Schritt zugewiesen. Details in Teil 5.

Nullify — Operator, der ein obligatorisches Feld auf null setzt (service_id, owner, timestamp). Erwarteter Fehlschlag — EMPTY_REQUIRED_FIELD vor der SLA-Berechnung.

FutureTime — Operator, der response_timestamp in die Zukunft setzt oder eine negative Reaktionsverzögerung erzeugt. Erwartete Codes — INVALID_TIME_ANCHOR, NEGATIVE_RESPONSE_LAG, STALE_INCIDENT_WINDOW.

EscalationCycle — Operator, der dem Eskalations-Routing-Graph eine Rückwärtskante hinzufügt (traffic_sre → edge_oncall bei bereits vorhandener edge_oncall → traffic_sre). Erwarteter Fehlschlag — CYCLE_ESCALATION mit minimalem Zyklus in der Diagnose.

RecursiveDependency — Operator, der eine indirekte Rekursion zwischen berechneten Feldern erzeugt: owner hängt von priority ab, priority — von blast_radius, blast_radius — wieder von owner. Erwarteter Fehlschlag — RECURSION_LIMIT mit Feldkette. Im ausführbaren Beispiel examples/stress-mutator/ nicht implementiert — als zukünftige Erweiterung in Teil 5 beschrieben.

PriorityContradiction — Operator, bei dem eine Regel P1 auf P2 herabstuft und eine andere P2 ohne tie_breaker auf P1 zurückführt. Erwarteter Fehlschlag — PRIORITY_REVERSAL; Schutz — Konfliktlösungsrichtlinie, nicht der Routing-Graph.

Datei-Schiedsverfahren

**Datei-Schiedsverfahren für strittige Änderungen (tribunal in Beispielnamen)** — Verfahren der kollegialen Entscheidung über strittige Korrekturen oder Vorfälle: Verifier, Implementor und Safety stimmen nach einem festen Protokoll ab, der Koordinator erstellt judgment.md. Kein eingebauter Qwen-Code-Befehl; wird als Kombination aus /review, Skripten und Regeln implementiert.

Präzedenzfall (precedent) — Eintrag in precedents.md über einen wiederkehrenden Konflikttyp und die angenommene Lösung. Dient als Tie-Breaker latest_matching_precedent im governance_protocol und senkt die Kosten des nächsten Schiedsverfahrens.

**Streitentscheidung (judgment.md)** — Endergebnis des Datei-Schiedsverfahrens: Abstimmungsprotokoll, decision_hash, Verweise auf Spezifikation, Konstitution und Vorfall, aktive ttl und rollback_condition. Wird im Repository als unveränderliche Spur gespeichert.

Genealogie (genealogy) — Kette parent_version → version im change_log der Konstitution und im Journal der Entscheidungen. Ermöglicht die Rekonstruktion, warum der Agent zum Zeitpunkt des Vorfalls zur konkreten Aktion berechtigt war, und erlaubt die nachträgliche Neuberechnung der Entscheidung.

Ausführungskontrolle

Notfallmodus (red button) — formelles Gateway vor einer potenziell gefährlichen Aktion in der Produktion: Rollback, Migration, Massenkonfigurations-Update. Im umgangssprachlichen Text kann er als „roter Knopf" bezeichnet werden, aber in den Artefakten halten Sie die Aktivierungsbedingungen fest. Wird nur ausgelöst, wenn alle Anti-Goodhart-Metriken erfüllt sind; Beispiel aus Teil 10 — red_button = BLOCKED (MTTR=4:50, silent_p0=18%, manual_review_rate=12%).

Auswirkungsradius (blast radius) — maximal mögliche Wirkungszone einer einzelnen Agentenaktion: Anzahl der Knoten, Namespaces, Benutzer, Datenvolumen. Wird in mutable_rules als max_scope angegeben und vom Gateway vor der Ausführung geprüft.

Lebenszeit (TTL) — Lebenszeit einer Mutable-Regel oder einer vorübergehenden Ausnahme (Override). Ohne ttl wird die Korrektur unbefristet und wird zu einem verborgenen Teil der Invariante.

Rollback-Bedingung (rollback condition) — Bedingung für die Aufhebung einer Mutable-Regel: Anstieg wiederkehrender Vorfälle, Veto von Safety, Überschreitung des silent_p0-Schwellenwerts. Muss automatisch prüfbar sein und nicht nur als Textformulierung bestehen.

Evidenzbasis

Beweiskette (evidence chain) — strukturierte Kette von Artefakten, die an die Agentenentscheidung gebunden ist: Eingabe-Payload, Spezifikationsversion, aktive Konstitutionsregeln, Abstimmungsprotokoll des Schiedsverfahrens, Diff der angewendeten Änderung, Nachbedingungsprüfungen. Mindestanforderung für Produktions-SDD.

Provenienz (provenance) — Herkunft einer strittigen Anforderung oder Regel: Autor, Quelle (Ticket, Vorfall, regulatorisches Dokument), Datum, Unsicherheitsgrad. Ermöglicht die Unterscheidung zwischen „so hat das Team es vereinbart" und „die Anforderung kam aus dem Audit".

Replay — erneutes Durchspielen historischer Vorfälle durch den aktuellen Validator und die aktuelle Konstitution. Wird als Gateway in Goodhart-Metriken verwendet: Eine neue Version darf die Urteile zu bereits analysierten Fällen nicht verschlechtern. Details in Teil 10.

Drift — Abweichung zwischen Spezifikation, Implementierung und dem, was der Agent tatsächlich in der Produktion tut. Im angewandten Band werden drei Arten unterschieden: spec_drift (Spezifikation ist veraltet), code_drift (Implementierung ist vom Plan abgewichen), edge_drift (Validator reagiert anders auf Grenzfälle).

Prozess-Antimuster

**ask_storm** — Zustand, in dem der Agent in einer Schleife Klärungsfragen stellt, statt anzuhalten. Kontrollzeile aus Teil 2: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. Anzeichen für eine vergiftete oder innerlich widersprüchliche Spezifikation.

**stage_regress** — Rückschritt auf eine frühere Phase des SDD-Zyklus ohne erkennbaren Grund: implement geht zurück zu plan, plan geht zurück zu specify. Wird durch die Bindung jeder Phase an Fakten in validation.md und feste Übergangskriterien geheilt.

**phase_context_loss** — Verlust des Kontexts zwischen den Phasen: specify hat eine Entscheidung festgehalten, plan hat sie nicht geerbt, implement arbeitet nach dem Entwurf. Schutz — explizite Verweise @specs/... und ein Project-Skill, der die Vererbung zwischen den Phasen prüft.

Externe SDD-Frameworks

GitHub Spec Kit — offenes Framework mit dem Standardzyklus /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement. Wird im zweiten Band als Referenz für Spec CI und Spec Gate verwendet.

AWS Kiro — IDE mit eigenem SDD-Modell: Specs (requirements.md + design.md + tasks.md), Steering-Dateien, Agent-Hooks. Zuordnung zum Lehrbuch — in Anhang A des ersten Bandes.