Glossar des Anwendungsbands

Zusammenfassende Liste der Begriffe des zweiten Bandes des Lehrbuchs. Definitionen werden hier dupliziert, damit in den Kapiteln keine Mehrdeutigkeiten entstehen. Wenn ein Begriff bereits im ersten Band eingeführt wurde, wird hier eine Produktionspräzisierung angegeben und ein Verweis auf das Kapitel des zweiten Bandes, in dem er wirkt.

Lesen Sie das Glossar nicht in Gänze vor Beginn des zweiten Bandes. Für den ersten Durchlauf genügt es, capstone/ und die zehn obligatorischen Artefakte des ersten Durchlaufs zu verstehen (vollständige Liste im README, Abschnitt „Обязательные артефакты первого прохода"). Öffnen Sie die übrigen Begriffe erst dann, wenn sie dabei helfen, eine bestimmte Datei auszufüllen oder ein runnable-Beispiel zu verstehen.

Die Leseregel ist einfach: Ein Dateiname oder YAML/JSON-Schlüssel kann auf Englisch bleiben, aber in der Erklärung wählen Sie eine deutsche Bedeutung. Beispielsweise ist judgment.md eine Datei mit einer Entscheidung zu einem Streit; tribunal ist eine Datei-Schiedsgerichtsbarkeit, nicht ein eigenständiges Produkt oder ein eingebauter Befehl von Qwen Code.

Die empfohlenen Hauptformen in Prosa, die standardmäßig zu verwenden sind (englischer Schlüssel – nur in Code-Blöcken und bei der ersten Erwähnung in Klammern):

• „stiller P0" – in 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-Gate (Spec CI)" – in Prosa; spec_gate – nur als Aufgabenname in .github/workflows/spec-ci.yml;
• „Datei-Schiedsgerichtsbarkeit" – in Prosa; tribunal – nur als Verzeichnisname examples/tribunal/ und seiner Skripte;
• „Notfallmodus" – in Prosa; „roter Knopf" – als kurzes Etikett; red_button, red_button_mttr_blindness – nur als Invariantennamen in YAML.

Übersetzungstabelle der Schlüsselbegriffe

Im zweiten Band verwenden wir in Prosa standardmäßig die deutsche Entsprechung eines Begriffs und geben bei der ersten Erwähnung im Kapitel den englischen Schlüssel in Klammern an, zum Beispiel: „Nachweisvermerk (evidence_ref)". Diese Tabelle ist ein Arbeitsnachschlagewerk: welche Begriffe übersetzt werden, welche als technische Namen auf Englisch bleiben, welche als zusammengesetzter deutsch-englischer Begriff leben. Die Klasse „technischer Name" bedeutet ein Identifikator in YAML/JSON, ein CLI-/Skript-Name, ein Statusname oder ein Konfigurationsschlüssel – er wird nicht verändert. Die Klasse „Begriff mit Doppelschreibung" – der Anglizismus wird als zusammengesetzter Prozessmarker verwendet; in Prosa wird die deutsche Entsprechung eingeführt, aber beide Schreibweisen sind zulässig. Die Klasse „Prosabegriff" – der Anglizismus wird vollständig eingedeutscht, im Haupttext bleibt nur die deutsche Form.

| judgment, judgment.md | Entscheidung zu einem Streit; Dateiname wird nicht verändert | Begriff mit Doppelschreibung | | precedent, precedents.md | Präzedenzfall; Dateiname wird nicht verändert | Begriff mit Doppelschreibung | | audit_trace_coverage | Audit-Trace-Abdeckung (Metrik, Schlüsselname wird beibehalten) | technischer Name | | shadow specs, shadow spec | Schattenspezifikationen; in Überschriften sind beide Schreibweisen zulässig | Begriff mit Doppelschreibung | | stress spec, stress-spec | Stress-Spezifikation | Prosabegriff | | guard metric, guard-метрика | Paarige Kontrollmetrik, Guard-Metrik | Begriff mit Doppelschreibung | | kill switch | Not-Aus-Schalter, Kill Switch | Begriff mit Doppelschreibung | | playbook | Playbook | Prosabegriff (Entlehnung) | | runbook | Runbook | Prosabegriff (Entlehnung) | | readiness gate, readiness | Bereitschafts-Gate, Bereitschaft; Modellpunktname wird beibehalten | Begriff mit Doppelschreibung | | rollback, rollback_condition | Rollback; Schlüssel rollback_condition wird beibehalten | Begriff mit Doppelschreibung | | dry run, dry-run | Probelauf | Prosabegriff | | webhook | Webhook | Prosabegriff (Entlehnung) | | auction | Auktion | Prosabegriff (Entlehnung) |

| tribunal | Datei-Schiedsgerichtsbarkeit für strittige Änderungen; technischer Name des Beispielverzeichnisses und seiner Skripte | technischer Name | | Verifier, Implementor, Safety, Coordinator | Verifizierer, Implementierer, Safety (stimmen ab), Koordinator (non-voting protocolist) – in Prosa; Rollennamen in YAML und Code bleiben englisch | Begriff mit Doppelschreibung | | immunity score | Immunitätsmetrik (Vektor) | Prosabegriff | | tier (low/mid/high, local-coder, frontier-reviewer) | Stufe (niedrig/mittel/hoch) in Prosa; Schlüssel und Rollennamen in YAML – ohne Übersetzung | Begriff mit Doppelschreibung | | mutation, mutation testing | Mutation, Mutationstest | Prosabegriff (Entlehnung) | | coverage, coverage-check | Abdeckung, Abdeckungsprüfung | Prosabegriff | | scope, scope-check, out-of-scope | Geltungsbereich, Geltungsbereichsprüfung, Geltungsbereichsüberschreitung | Prosabegriff | | failover | Failover, Ausweichumschaltung | Begriff mit Doppelschreibung | | blast radius | Wirkungsradius, Blast Radius | Begriff mit Doppelschreibung | | gate, spec gate | Gate, Spezifikations-Gate (Gate) | Begriff mit Doppelschreibung |

| manual_review_floor, manual_review_rate | Mindestanteil manueller Prüfung, Anteil manueller Prüfung; Schlüssel werden beibehalten | technischer Name | | genealogy, genealogy.md | Genealogie; Dateiname wird nicht verändert | Begriff mit Doppelschreibung | | ttl, time to live | Lebensdauer (ttl); Schlüssel wird beibehalten | technischer Name | | few-shot | Beispiel-Prompt, Few-Shot | Begriff mit Doppelschreibung | | scorebook | Bewertungsjournal (Scorebook); Dateiname wird nicht verändert | Begriff mit Doppelschreibung | | pre-approved actions | Vorab genehmigte Aktionen | Prosabegriff | | quarantine | Quarantäne | Prosabegriff | | ask_storm, stage_regress, phase_context_loss | Antipattern-Namen bleiben unverändert; bei erster Erwähnung im Kapitel wird ein kurzer deutscher Kommentar gegeben | technischer Name | | capstone, dossier | Abschlussprüfungs-Paket, Nachweispaket | Begriff mit Doppelschreibung |

Technische Namen, die unverändert bleiben und weder in Prosa noch in 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), CLI-Befehls- und Skriptnamen (qwen -p, python3 scripts/..., git, npm, rg), Custom-Command-Namen (/sdd:specify, /plan, /review), Status (Стандарт / Рекомендация / Фронтир), Blockmarker ([runnable], [project script]), Abkürzungen (MCP, CI, LLM, API, KPI, MTTR, SLO, SLA, SRE).

Wo ein Begriff erstmals eingeführt wird

Die Karte hilft, schnell das Kapitel zu öffnen, in dem ein Begriff erstmals eine Arbeitsdefinition und einen Anwendungsszenario erhält. Metriken (silent_p0, audit_trace_coverage, manual_review_floor) und Gedächtnisschlüssel (shadow-scorebook.json, shadow-candidates.yaml, precedents.md, judgment.md) sind separat aufgeführt: Metriken messen das System, Gedächtnisschlüssel speichern 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 | | Gedächtnisschlüssel | .specify/memory/shadow-candidates.yaml, .specify/memory/shadow-scorebook.json | 6 | | Gedächtnisschlüssel | precedents.md, change_log | 3, 8 | | Mechanismus | Stress-Spezifikation, Mutationstest | 5 | | Mechanismus | Schattenspezifikation, Auktion, Scorebook | 6 | | Mechanismus | Spezifikations-Gate (Spec CI) | 7 | | Mechanismus | Stufen-Routing, local-coder, frontier-reviewer, Budget-Hüter | 9 | | Mechanismus | Paarige Kontrollmetrik, Anti-Goodhart, Notfallmodus | 10 |

| Mechanismus | Probelauf, Bereitschafts-Gate, evidence_ref | 11 |

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

Verbindung zum Glossar des ersten Bandes

Dieses Glossar ergänzt und ersetzt nicht das Glossar des ersten Bandes. Grundbegriffe des 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 aufgelegt:

• validation.md des ersten Bandes enthält Zulassungsfakten zum Merge; im zweiten Band wird es um Failing-Cases des Duells, Anti-Goodhart-Prüfungen, Drift-Felder und Trace-Einträge ergänzt.
• QWEN.md des ersten Bandes speichert den dauerhaften Agentenkontext; 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 constitution.md-Abschnitt mit immutable_principles, mutable_rules und governance_protocol erweitert.

Wenn ein Begriff aus diesem Glossar unbekannt erscheint, beginnen Sie mit der Grunddefinition im ersten Band und lesen dann die Produktionspräzisierung hier.

Lehrprojekt AgentClinic

Produktionsszenarien des Anwendungsbands entfalten sich gedanklich am Lehrprojekt AgentClinic aus dem ersten Band: TypeScript, Hono, serverseitiges JSX, SQLite, Vitest. Python bezieht sich auf die runnable-Beispiele des zweiten Bandes: das sind kleine stdlib-Skripte für lokale Prüfungen, nicht der Stack der Hauptanwendung. Domänenentitäten – Agenten-Patienten, Krankheiten, Therapien, Termine, Bewertungen, Feedback – sind in Anhang B des ersten Bandes beschrieben. Die Entsprechung zwischen Lehrprojekt-Code und Produktionsvorfällen ist in der Tabelle des Anhangs A des Anwendungsbands festgehalten.

Bildhafte Bezeichnungen

In den Kapiteln werden manchmal bildhafte Bezeichnungen verwendet. Sie dienen als Hilfsetiketten, nicht als Hauptbezeichnung des Prozesses. Die ingenieurwissenschaftlichen Entsprechungen sind:

• Spezifikationswiederherstellung – Wiederherstellung von Anforderungen aus Legacy-Code, Logs, Vorfällen und Entscheidungsgeschichte; „Spezifikations-Nekromantie" ist nur als Hilfsetikett zulässig.
• Vergiftete Spezifikation – absichtlich defekte Lehrspezifikation mit einem kontrollierten Fehler.
• Validatoren-Impfung – Mutationstest (mutation testing) für Spezifikationen und Prüfungen.
• Auktion der Schattenspezifikationen (shadow specs) – Bewertung und Rangfolge informeller Heuristiken vor der Aufnahme in den Arbeitskontext.
• Datei-Schiedsgerichtsbarkeit für strittige Änderungen – siehe unten Abschnitt „Datei-Schiedsgerichtsbarkeit"; tribunal in Datei- und Verzeichnisnamen bleibt technisches Etikett des Beispiels.
• Stufen-Routing der Modelle – Verteilung von Aufgaben zwischen Modellen unterschiedlicher Kosten und Qualität.
• Ködermetriken – KPIs, die leicht zulasten des Systems optimiert werden können; ingenieurwissenschaftlicher Schutz – paarige Kontrollmetriken (guard metrics).
• Notfallmodus (red button) – formales Sicherheits-Gate vor gefährlichen Aktionen: Deployment, Rollback, Migration oder Auto-Remediation; „roter Knopf" – umgangssprachliches Etikett.

Agentenrollen

Verifizierer (Verifier) – Agent oder Sitzung, dessen einzige Aufgabe darin besteht, Verletzungen von Invarianten, Verträgen und Fakten zu suchen. Hat kein Recht, Code zu schreiben oder Artefakte zu ändern, fällt nur das Urteil approve / reject / abstain mit Begründung. Details in Teil 4 und Teil 8.

Implementierer (Implementor) – Agent, der einen Plan im Auto-Edit-Modus nach genehmigter Spezifikation ausführt. Im Datei-Schiedsgerichtsverfahren stimmt er über die Anwendbarkeit einer Änderung im Playbook ab, hat aber kein Recht, das Urteil des Verifizierers oder der Safety-Rolle zu umgehen.

Koordinator (Coordinator) – Rolle (Mensch, CI-Job oder externer Orchestrator), die die finale Entscheidung auf Basis der Ergebnisse des Datei-Schiedsgerichts trifft, den Präzedenzfall fixiert und judgment.md veröffentlicht. Stimmt nicht gleichberechtigt mit Verifizierer, Implementierer und Safety ab; ist für das Verfahren und nicht für den Inhalt verantwortlich.

Safety – separate Rolle im governance_protocol, die Wirkungsradius, Privatsphäre, Backupschutz und Rollback-Bedingungen prüft. Hat Veto bei critical_risk: selbst bei zwei approve von Verifier und Implementor wird die Änderung abgelehnt. Details in Teil 3.

**Modellstufe (tier, local-coder / frontier-reviewer)** – Modellniveau im Stufen-Routing. local-coder – preiswertes lokales Modell für Code-Generierung und Entwürfe; frontier-reviewer – teures Frontier-Modell, das nur bei kritischen Reviews, strittigen Urteilen und Prüfungen des roten Knopfs verwendet wird. Details in Teil 9.

Budget-Hüter (budget keeper) – externer Dienst oder Skript, das die tägliche Token-Quote pro Stufe überwacht und Zugriffe auf Frontier-Modelle bei Limitüberschreitung blockiert. Qwen Code verwaltet das Budget nicht selbst.

Spezifikationen und Artefakte

Schattenspezifikation (shadow spec) – Spezifikation für nicht formalisierbare Nuancen: Intonation, unausgesprochene Prioritäten, historische Entscheidungen, die nicht in das Haupt-requirements.md gelangt sind. Wird separat gespeichert, gewinnt in einer Auktion auf Basis des Bewertungsjournals (Scorebook), 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 der Form .specify/memory/shadow-scorebook.json; wird durch einen Auktionslauf erstellt oder aktualisiert.

Vergiftete Spezifikation (poisoned spec) – Lehrspezifikation, in die bewusst ein Fehler eingefügt wurde: Eskalationszyklus, Prioritätskonflikt oder versteckte Geltungsbereichsüberschreitung (hidden out-of-scope). Dient zum Training des Verifizierers und der Validatoren. Details in Teil 2.

Versteckte Geltungsbereichsüberschreitung (hidden out-of-scope) – Aktion, die die Spezifikation formal nicht verbietet, aber auch nicht beschreibt, und die der Agent „nebenbei" ausführt. Beispiel: Die Spezifikation bittet um Änderung einer Alert-Route, der Agent ändert zusätzlich die SLA-Richtlinie. Schutz – expliziter Abschnitt „Außerhalb des Geltungsbereichs" und Spezifikations-Gate Spec CI.

Override-Regel – veränderbare Norm in constitution.md, die einem Agenten erlaubt, das Standardverhalten in einem engen Kontext zu umgehen: für einen bestimmten incident_type, in einer bestimmten pipeline_phase, mit begrenztem max_scope und obligatorischem ttl. Ohne diese Begrenzungen konkurriert die Regel mit den Invarianten.

Immutable principle – Regel im Abschnitt immutable_principles von constitution.md, die nicht automatisch deaktiviert werden kann: Verbot des Neustarts der Produktionsdatenbank ohne Backup, Verbot der Löschung von Backups, Verbot des Bypass in sicherheitskritischen Namespaces. Änderbar nur durch explizites Team-Referendum, 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 bei Ansammlung unvorhergesehener Vorfälle.

**proposal.md** – separate Änderungsdatei für constitution.md, die als Risikovertragsänderung verlä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** – Präzedenzfall-Journal des Datei-Schiedsgerichts: Jede erlaubte Meinungsverschiedenheit wird als Eintrag mit case_ref, verletzter Regel, endgültigem 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 – Liste der Quellen, Konfidenzniveau (confirmed, inferred, hypothesis) und offene Frage. Wird bei der Spezifikationswiederherstellung aus dem übernommenen Kontext erstellt; Details in Teil 1.

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

Abschlussprüfungs-Paket (capstone dossier) – Dateiensatz aus Teil 13, der den vollständigen Produktions-SDD-Pfad für einen Vorfall zeigt: Anforderungsherkunft, vergifteter Defekt, Reparatur, Konstitution, Prüfung, Urteil, Budget, Anti-Goodhart-Begrenzer, Readiness und Audit der Antipatterns.

Immunitätsmetriken und Goodhart-Schutz

Immunitätsmetrik (immunity score) – Vektor der Validatoren-Bewertungen, keine einzelne Gesamtzahl. Besteht aus drei Komponenten: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms. Dient als Gate des Validatoren-Konturs beim Mutationstest von Spezifikationen.

**strict_reject_rate** – Anteil der degenerierten Fälle (Mutanten), die streng am erwarteten Given/When/Then-Schritt abgelehnt werden. Steigt diese Metrik bei sinkendem depth_of_diagnostics, bedeutet das, dass der Validator strenger, aber „blinder" geworden ist.

**depth_of_diagnostics** – Nützliche Erklärungstiefe vor der Ablehnung: Wie viele Tracing-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 Regel Z verletzt".

**recovery_time_p95_ms** – p95 der Zeit (in Millisekunden), in der der Validator nach Spezifikationsänderung ein stabiles Urteil und einen diagnostischen Pfad zurückgibt. Überschreitung des Schwellenwerts (z. B. 1200ms) provoziert Umgehungspraktiken und bremst die CI aus.

**silent_p0** – Anteil der P0-Vorfälle, die ohne menschliche Bestätigung und ohne Eintrag im Audit Trail durch die Automatisierung gelaufen sind. Anti-Goodhart-Metrik: Wenn MTTR sinkt und silent_p0 steigt, beschleunigt sich die Auto-Remediation zulasten versteckter Risiken. Details in Teil 10.

**manual_review_floor** – Mindestanteil der Entscheidungen, die zwingend menschliches Review durchlaufen, auch wenn die Automatisierung formal damit zurechtkommt. Schutz gegen Einseitigkeitsoptimierung: Verbietet dem Agenten, den Menschen vollständig aus dem Kontur zu „verdrängen".

**audit_trace_coverage** – Anteil der Agenten-Aktionen, für die die vollständige Evidence-Kette gespeichert ist: Eingabe-Payload, Spezifikationsversion, Konstitutionsversion, Vote-Log, decision_hash. Zielwert – 100%; Rückgang blockiert Merge und roten Knopf.

Anti-Goodhart (Anti-Goodhart) – Allgemeines Verfahren des Metrik-Designs in Paarung mit Antikörpern. Jeder Zielmetrik (MTTR, edge_drift) wird eine Wächtermetrik (silent_p0, manual_review_floor, audit_trace_coverage) zugeordnet, und das CI-Gate wird nur bei gleichzeitiger Erfüllung beider passiert.

Mutationen und Stresstests

Mutationsoperator (mutation operator) – Funktion, die eine korrekte Spezifikation nimmt und genau einen Fehler einer bekannten Klasse einfügt. Jeder Mutation wird eine mutation_id, ein erwarteter expected_failure und ein halt_before-Schritt zugewiesen. Details in Teil 5.

Nullify – Operator, der ein Pflichtfeld (service_id, owner, timestamp) leert. Erwartete Ablehnung – 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 im Eskalationsrouten-Graphen eine Rückwärtskante hinzufügt (traffic_sre → edge_oncall bei bereits existierendem edge_oncall → traffic_sre). Erwartete Ablehnung – CYCLE_ESCALATION mit minimalem Zyklus in der Diagnose.

RecursiveDependency – Operator, der indirekte Rekursion zwischen berechneten Feldern erzeugt: owner hängt von priority ab, priority von blast_radius, blast_radius wiederum von owner. Erwartete Ablehnung – RECURSION_LIMIT mit Feldkette. Im runnable-Beispiel examples/stress-mutator/ nicht implementiert – als zukünftige Erweiterung in Teil 5 beschrieben.

PriorityContradiction – Operator, bei dem eine Regel P1 auf P2 herabsetzt, während eine andere P2 ohne tie_breaker zurück auf P1 bringt. Erwartete Ablehnung – PRIORITY_REVERSAL; Schutz durch Konfliktlösungspolitik, nicht durch den Routen-Graphen.

Datei-Schiedsgerichtsbarkeit

**Datei-Schiedsgerichtsbarkeit für strittige Änderungen (tribunal in Beispielnamen)** – Verfahren der kollegialen Entscheidung über eine strittige Änderung oder einen Vorfall: Verifizierer, Implementierer und Safety stimmen nach festem Protokoll ab, Koordinator erstellt judgment.md. Kein eingebauter Befehl von Qwen Code; 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 latest_matching_precedent-Tie-Breaker im governance_protocol und senkt die Kosten des nächsten Schiedsverfahrens.

**Entscheidung zu einem Streit (judgment.md)** – Endergebnis des Datei-Schiedsgerichts: Vote-Journal, 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 Entscheidungsjournal. Ermöglicht die Rekonstruktion, warum der Agent im Vorfallszeitpunkt berechtigt war zu einer bestimmten Aktion, und eine nachträgliche Neuberechnung der Entscheidung.

Ausführungskontrolle

Notfallmodus (red button) – formales Gate vor potenziell gefährlichen Aktionen in der Produktion: Rollback, Migration, Massenkonfigurationsupdate. Im Gespräch kann er „roter Knopf" genannt werden, aber in Artefakten sind die Aktivierungsbedingungen des Modus festzuhalten. Schlägt nur bei Erfüllung aller Anti-Goodhart-Metriken zu; Beispiel aus Teil 10 – red_button = BLOCKED (MTTR=4:50, silent_p0=18%, manual_review_rate=12%).

Wirkungsradius (blast radius) – maximal mögliche Wirkungszone einer Agenten-Aktion: Anzahl der Knoten, Namespaces, Benutzer, Datenvolumen. Wird in mutable_rules als max_scope angegeben und vom Gate vor Ausführung geprüft.

Lebensdauer (TTL) – Lebensdauer einer mutable-Regel oder einer temporären Ausnahme (Override). Ohne ttl wird die Änderung unbefristet und verwandelt sich in einen versteckten Teil der Invariante.

Rollback-Bedingung (rollback condition) – Bedingung für den Widerruf einer mutable-Regel: Anstieg wiederholter Vorfälle, Veto von Safety, Überschreitung des silent_p0-Schwellenwerts. Muss automatisch prüfbar sein, nicht als Textformulierung verbleiben.

Beweisbasis

Nachweiskette (evidence chain) – Strukturierte Kette von Artefakten, die an eine Agenten-Entscheidung gebunden ist: Eingabe-Payload, Spezifikationsversion, aktive Konstitutionsregeln, Abstimmungsjournal des Schiedsgerichts, Diff der angewandten Änderung, Post-Condition-Prüfungen. Mindestanforderung für Produktions-SDD.

Provenienz (provenance) – Herkunft eines strittigen Anforderungs oder einer Regel: Autor, Quelle (Ticket, Vorfall, Regulatorisches Dokument), Datum, Unsicherheitsgrad. Ermöglicht die Unterscheidung zwischen „das Team hat sich so geeinigt" und „die Anforderung kam aus dem Audit".

Replay – Wiederholtes Durchspielen historischer Vorfälle durch den aktuellen Validator und die aktuelle Konstitution. Dient als Gate in Goodhart-Metriken: Eine neue Version darf die Urteile bei bereits analysierten Fällen nicht verschlechtern. Details in Teil 10.

Drift – Abweichung zwischen Spezifikation, Implementierung und dem, was der Agent in der Produktion tatsächlich tut. Im Anwendungsband 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-Antipatterns

**ask_storm** – Zustand, in dem der Agent im Zyklus klärende Fragen stellt, anstatt zu stoppen. Kontrollzeichenkette aus Teil 2: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. Anzeichen einer vergifteten oder innerlich widersprüchlichen Spezifikation.

**stage_regress** – Rückkehr zu einer vorherigen Phase des SDD-Zyklus ohne offensichtlichen Grund: implement kehrt zu plan zurück, plan zu specify. Wird durch Bindung jeder Phase an Fakten in validation.md und feste Übergangskriterien geheilt.

**phase_context_loss** – Kontextverlust zwischen Phasen: specify hat eine Entscheidung fixiert, plan hat sie nicht übernommen, implement handelt nach einem Entwurf. Schutz – explizite Verweise @specs/... und project skill, der die Vererbung zwischen Phasen prüft.

Externe SDD-Frameworks

GitHub Spec Kit – Open-Source-Framework mit 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, Agenten-Hooks. Die Gegenüberstellung mit dem Lehrbuch findet sich in Anhang A des ersten Bandes.