Thema: Glossar des Anwendungsbandes: Praxisleitfaden für Production-SDD
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 12–16 Stunden (2 Wochen bei 1 Stunde pro Tag)
Voraussetzungen: Abgeschlossener erster Band des SDD-Lehrbuchs (Grundlegende Artefakte: QWEN.md, mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md)
Verständnis der Fähigkeiten Qwen Code, MCP, ACP, EARS, Given/When/Then
Grundlegende Erfahrung mit Git, YAML/JSON, CI/CD
Vertrautheit mit dem Übungsprojekt AgentClinic (TypeScript, Hono, SQLite, Vitest)
Lernziele: 40+ Schlüsselbegriffe des Anwendungsbandes korrekt aus der englischen Form in deutsche Prosa übersetzen, wobei technische Namen im Code und in YAML/JSON-Schlüsseln erhalten bleiben
Production-Ergänzungen grundlegender SDD-Artefakte (validation.md, QWEN.md, Konstitution) in realen Szenarien mit Multi-Agent-Schiedsgerichtsbarkeit und Drift-Schutz anwenden
Paarweise Metriken (Anti-Goodhart) und Sicherheitsgatter (Spec Gate, Red Button) für Production-Konturen mit LLM-Agenten entwerfen
Den vollständigen Zyklus der Dateischiedsgerichtsbarkeit reproduzieren: Von Poisoned Spec über Mutationstests bis zu judgment.md und Präzedenzfällen
Die obligatorischen Artefakte des ersten Durchgangs (Capstone-Dossier) selbstständig für einen konkreten Vorfall ausfüllen
Überblick: Das Glossar des Anwendungsbandes ist nicht einfach ein Wörterbuch von Begriffen, sondern ein operatives Handbuch für Production-SDD: ein System der Entwicklung durch Spezifikation, bei dem LLM-Agenten unter menschlicher Kontrolle in einer echten Production-Umgebung arbeiten. Jeder Begriff erhält hier eine Arbeitsdefinition, ein ausführbares Szenario und klare Übersetzungsregeln: Deutsche Prosa für Erklärungen, englische technische Namen für Code, YAML und JSON. Die wichtigste Leseregel: Das Glossar nicht auswendig lernen, sondern einen Begriff öffnen, wenn er beim Ausfüllen einer bestimmten Datei oder beim Verstehen eines ausführbaren Beispiels hilft. Schlüsselgruppen: Agentenrollen (Verifier, Implementor, Safety, Coordinator), Risikomanagement-Artefakte (constitution.md, judgment.md, precedents.md, genealogy.md), Immunitätsmetriken und Schutz vor Kennzahlenverzerrung (Anti-Goodhart), Mechanismen des Stresstests und der Multi-Agent-Schiedsgerichtsbarkeit. Das Übungsprojekt AgentClinic dient als Bezugspunkt für alle Production-Szenarien.
Schlüsselkonzepte: Stiller P0 (silent p0): Der Anteil von Vorfällen der Stufe P0, die ohne menschliche Bestätigung und ohne Eintrag im Audit Trail durch die Automatisierung liefen. Anti-Goodhart-Metrik: Wenn MTTR sinkt, aber silent_p0 steigt, beschleunigt sich die Auto-Remediation auf Kosten versteckter Risiken. Im Code: silent_p0, silent_p0_cap, silent_p0_ratio — technische Namen, nicht zu übersetzen.
Spezifikationsgatter (spec ci): CI-Prüfung, die 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. In Prosa: „Spec CI“ oder „Spezifikationsgatter (Spec CI)“; im Code: spec_gate — nur als Aufgabenname in .github/workflows/spec-ci.yml.
Dateischiedsgerichtsbarkeit (tribunal): Verfahren der kollegialen Entscheidung über einen strittigen Änderungsvorschlag: Verifier, Implementor und Safety stimmen nach festem Protokoll ab, der Coordinator erstellt judgment.md. In Prosa: „Dateischiedsgerichtsbarkeit“; im Code: tribunal — nur als Verzeichnisname examples/tribunal/ und für seine Skripte.
Notfallmodus (red button): Formales Sicherheitsgatter vor gefährlichen Aktionen: Deployment, Rollback, Migration oder Auto-Remediation. „Rote Taste“ — kurzes umgangssprachliches Etikett. Im Code: red_button, red_button_mttr_blindness — nur als Invariantennamen in YAML.
Schatten-Spezifikation (shadow spec): Spezifikation für nicht formalisierbare Nuancen: Intonationen, unausgesprochene Prioritäten, historische Entscheidungen. Wird separat gespeichert, gewinnt die Auktion auf Basis des Bewertungsjournals (Scorebook), ersetzt nicht die Hauptspezifikation. In Überschriften sind beide Schreibweisen zulässig.
Immunitätsmetrik (immunity score): Vektor der Validator-Bewertungen aus drei Komponenten: strict_reject_rate (Anteil degenerierter Fälle, die streng am erwarteten Schritt abgelehnt werden), depth_of_diagnostics (nützliche Erklärungstiefe vor Ablehnung), recovery_time_p95_ms (P95 der Zeit bis zur Rückkehr eines stabilen Verdikts). Keine einzelne Gesamtzahl, sondern ein Gatter des Validator-Konturs.
Paarige Gegenmetrik (guard metric): Antikörper-Metrik zum Schutz vor Verzerrung der Zielkennzahl. Jeder Zielmetrik (MTTR, edge_drift) wird eine Guard-Metrik zugeordnet (silent_p0, manual_review_floor, audit_trace_coverage), und das CI-Gatter wird nur bei gleichzeitiger Erfüllung beider durchlaufen.
Projektkonstitution (constitution.md): Erweiterung der Grundkonstitution des ersten Bandes mit explizitem Abschnitt: immutable_principles (werden nicht automatisch deaktiviert, ändern sich nur durch Team-Referendum), mutable_rules (entwickeln sich durch Ansammlung von Vorfällen mit Feldern incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition), governance_protocol (Rollen und Abstimmungsverfahren).
Vergiftete Spezifikation (poisoned spec): Übungsspezifikation mit einem kontrollierten Defekt: Eskalationszyklus, Prioritätskonflikt oder versteckter Grenzüberschreitung. Dient zum Trainieren des Verifiers und der Validatoren durch Mutationstests.
Mutationsoperator (mutation operator): Funktion, die genau einen Defekt bekannter Klasse in eine korrekte Spezifikation einfügt. Jeder Mutation wird eine mutation_id, ein erwarteter expected_failure und ein halt_before-Schritt zugewiesen. Beispiele: Nullify, FutureTime, EscalationCycle, PriorityContradiction.
Streitentscheidung (judgment.md): Endgültiges Artefakt der Dateischiedsgerichtsbarkeit: Abstimmungsprotokoll, decision_hash, Verweise auf Spezifikation, Konstitution und Vorfall, aktive ttl und rollback_condition. Wird im Repository als unveränderliche Spur gespeichert.
Präzedenzfall (precedent): Eintrag in precedents.md über einen wiederkehrenden Konflikttyp und die angenommene Lösung. Wird als Tie-Breaker latest_matching_precedent im governance_protocol verwendet und senkt die Kosten des nächsten Schiedsverfahrens.
Genealogie (genealogy.md): Herkunft der wiederhergestellten Spezifikation: Für jede Anforderung — Liste der Quellen, Vertrauensstufe (confirmed, inferred, hypothesis) und offene Frage. Wird bei der Wiederherstellung aus Legacy-Code und Logs erstellt.
Modellstufe (tier): Stufen der Modell-Ebenen-Routing: local-coder (günstiges lokales Modell für Code-Generierung und Entwürfe), frontier-reviewer (teures Frontier-Modell für kritische Reviews und strittige Verdikte). In Prosa: „niedrige/mittlere/hohe Stufe“; in YAML-Schlüsseln und Rollennamen — ohne Übersetzung.
Drift (drift): Abweichung zwischen Spezifikation, Implementierung und realem Verhalten des Agenten in Production. Drei Arten: spec_drift (Spezifikation ist veraltet), code_drift (Implementierung weicht vom Plan ab), edge_drift (Validator reagiert bei Grenzfällen anders).
Replay (replay): Wiederholtes Durchspielen historischer Vorfälle durch den aktuellen Validator und die aktuelle Konstitution. Gatter bei Goodhart-Metriken: Neue Version darf Verdikte bei bereits analysierten Fällen nicht verschlechtern.
Override-Regel: Veränderbare Norm in constitution.md, die Umgehung des Standardverhaltens in engem Kontext erlaubt: für konkreten incident_type, auf konkreter pipeline_phase, mit begrenztem max_scope und obligatorischem ttl. Ohne Begrenzungen konkurriert sie mit Invarianten.
Beweiskette (evidence chain): Strukturierte Kette von Artefakten, gebunden an die Agenten-Entscheidung: Eingabe-Payload, Spezifikationsversion, aktive Konstitutionsregeln, Abstimmungsprotokoll des Schiedsgerichts, Änderungs-Diff, Nachbedingungsprüfungen. Mindestanforderung für Production-SDD.
Auktion der Schatten-Spezifikationen: Bewertung und Rangfolge informeller Heuristiken vor Aufnahme in den Arbeitskontext. Der Auktionsgewinner gelangt als Few-Shot mit Überprüfungsfrist in QWEN.md. Bewertungsjournal — Scorebook (shadow-scorebook.json).
Prozess-Antipatterns: ask_storm — Zyklus von Rückfragen statt Stopp; stage_regress — Rückkehr zu vorheriger SDD-Phase ohne Grund; phase_context_loss — Kontextverlust zwischen Phasen. Kontrollstrings und Schutzmaßnahmen sind im Glossar beschrieben.
Wichtige Termine: Zeitpunkt des ersten Durchgangs: Das Glossar nicht vollständig lesen. Ausreichend ist das Verständnis von capstone/ und den zehn obligatorischen Artefakten des ersten Durchgangs (vollständige Liste im README)
Begriffseinführung in Teilen: Rollen (Teil 4), Konstitutions-Artefakte (Teil 3), Immunitätsmetriken (Teil 5), Schatten-Spezifikationen (Teil 6), Spec CI (Teil 7), Dateischiedsgerichtsbarkeit (Teil 8), Ebenen-Routing (Teil 9), Anti-Goodhart (Teil 10), Deployment (Teil 11), Antipatterns und Capstone (Teile 12–13)
Production-Ergänzungen: Werden auf Grundbegriffe des ersten Bandes aufgelegt: validation.md wird um failing case, Anti-Goodhart-Prüfungen, Drift-Felder ergänzt; QWEN.md wird zum Ort des Few-Shot aus der Auktion; Konstitution wird um immutable/mutable-Abschnitt erweitert
Übungsaufgaben: Titel: Begriffsübersetzung: Technischer Name vs. Prosa
Problem: Gegeben sind drei Verwendungskontexte des Begriffs 'silent_p0'. Schreiben Sie die korrekte Form für jeden: (1) Erklärung in der Dokumentation für das Business, (2) YAML-Schlüssel in der CI-Konfiguration, (3) Befehl in der CLI zur Metrikprüfung. Überprüfen Sie sich anhand der Übersetzungstabelle.
Lösung: (1) Prosa: „stiller P0“ — Anteil von Vorfällen der Stufe P0, die ohne menschliche Bestätigung durchliefen; (2) YAML-Schlüssel: silent_p0, silent_p0_cap, silent_p0_ratio — technischer Name, nicht zu übersetzen; (3) CLI: silent_p0 — Metrikname im Befehl, z. B. qwen -p metrics check silent_p0_ratio. Regel: Englischer Schlüssel nur in Code-Blöcken und bei erster Erwähnung in Klammern.
Schwierigkeit: Anfänger
Titel: Entwurf paarweiser Metriken für AgentClinic
Problem: In einem Arzttermin-System wird die Metrik „durchschnittliche Terminbestätigungszeit“ (MTTR-ähnlich) eingeführt. Welche Guard-Metrik schützt vor Verzerrung? Beschreiben Sie: (1) Zielmetrik, (2) Guard-Metrik, (3) Gatter-Bedingung, (4) Szenario, bei dem die Zielmetrik sich verbessert, aber Guard verschlechtert.
Lösung: (1) Ziel: booking_confirmation_time_ms — durchschnittliche Zeit von Anfrage bis Bestätigung; (2) Guard: silent_override_rate — Anteil der Termine, die automatisch ohne Prüfung der Arztplanungskonflikte bestätigt wurden; (3) Gatter: Beide Metriken im grünen Bereich, sonst BLOCKED; (4) Szenario: Agent beginnt, Termine zu bestätigen und ignoriert dabei Doppelbuchungen — MTTR sinkt, silent_override_rate steigt, Gatter blockiert Deployment. Anti-Goodhart-Maßnahme: Nie eine einzelne Metrik ohne Antikörper-Prüfung optimieren.
Schwierigkeit: Mittelstufe
Titel: Wiederherstellung von genealogy.md für Legacy-Feature
Problem: In AgentClinic wurde das Feature „automatische Terminerinnerung“ vor 2 Jahren implementiert, Spezifikation fehlt. Stellen Sie eine minimale genealogy.md wieder her: Beschreiben Sie 3 Informationsquellen, Vertrauensstufen und 2 offene Fragen. Verwenden Sie das Format aus dem Glossar.
Lösung: Quellen: (1) SMS-Gateway-Logs — confirmed (Einträge mit Nachrichtenvorlage und 24h-Trigger vorhanden); (2) Code in src/reminders/auto-sms.ts — inferred (Logik vorhanden, aber keine Kommentare zu Geschäftsregeln); (3) Patienten-Feedback im Support — hypothesis (einige beschweren sich über fehlende Erinnerungen, möglicherweise Bug oder Opt-out). Offene Fragen: (a) Welcher Schwellenwert für „ausreichend nahe Zeit“ gilt — 24h, 2h oder abhängig von Terminart? (b) Gibt es einen Fallback-Kanal (E-Mail, Push) bei SMS-Nichtverfügbarkeit? Format genealogy.md: Tabelle mit Spalten requirement_id, sources[], confidence, open_questions[].
Schwierigkeit: Mittelstufe
Titel: Vollständiger Zyklus der Dateischiedsgerichtsbarkeit
Problem: Strittige Änderung in AgentClinic: Agent schlägt vor, bei 3-maligem Nichterscheinen die Terminbuchung automatisch zu stornieren, was jedoch die SLA-Rückerstattungspolitik berührt. Führen Sie eine Dateischiedsgerichtsbarkeit durch: Bestimmen Sie die Stimmen von Verifier, Implementor, Safety, die Rolle des Coordinators, das Endverdikt und den Inhalt von judgment.md.
Lösung: Verifier: reject — Verletzung versteckter Grenzüberschreitung (Spezifikation geht um Alert-Routing, Agent ändert SLA-Politik); Implementor: abstain — Änderung technisch anwendbar, aber über max_scope hinaus; Safety: veto (critical_risk) — Blast Radius umfasst finanzielle Verpflichtungen, keine rollback_condition für fehlerhafte Stornierungen; Coordinator: protokolliert verdict REJECTED, veröffentlicht judgment.md mit decision_hash, Verweisen auf Routing-Spezifikation und Konstitution (mutable_rules für Finanzoperationen), aktivem ttl=0 (Änderung wird nicht angewendet), rollback_condition=N/A. Präzedenzfall wird zu precedents.md hinzugefügt: 'auto-cancellation with financial impact requires explicit mutable_rule for billing, not just routing spec'.
Schwierigkeit: Fortgeschritten
Titel: Diagnose des Anti-Patterns ask_storm
Problem: Agent stellt im Zyklus 5 Rückfragen zur Terminpriorität, ohne zur Planung überzugehen. Prüfen Sie den Kontrollstring: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. Beschreiben Sie: (1) was auf eine vergiftete Spezifikation hinweist, (2) welche Konstitutionsregel verletzt wurde, (3) Remediations-Schritte.
Lösung: (1) ask_storm >= 4 bei cycle_count > 0 — Agent steckt in Rückfragen statt Stopp oder Eskalation; escalation_path_resolved=false — kein Konflikt-Resolution; (2) Verletzung mutable_rule: Bei ask_storm >= 3 ist der Coordinator verpflichtet, den Zyklus zu unterbrechen und human-in-the-loop zu initiieren (falls solche Regel in constitution.md steht); falls nicht — Lücke in der Konstitution; (3) Remediation: (a) Vorfall dokumentieren, (b) Spezifikation mit explizitem tie_breaker für Prioritätskonflikte aktualisieren, (c) Guard-Metrik max_ask_storm=2 in CI hinzufügen, (d) Mutationstest mit Operator PriorityContradiction durchführen.
Schwierigkeit: Fortgeschritten
Fallstudien: Titel: Einführung der Ebenen-Routing in AgentClinic: Von der Budgetkrise zu kontrollierten Kosten
Szenario: Das AgentClinic-Team nutzte ein einheitliches Frontier-Modell (GPT-4-Klasse) für alle Aufgaben: Code-Schreiben, Review, Bugfixing, Support-Antworten. Bei steigender Last stiegen die API-Kosten um 340% pro Quartal, wobei 70% der Anfragen Routine waren (SMS-Vorlagen-Generierung, Planungsaktualisierungen). Qualität kritischer Operationen musste erhalten und Kosten gesenkt werden.
Herausforderung: (1) Keine Aufgabentrennung nach Kritikalität — Frontier-Modell wurde für alles genutzt; (2) Kein Budget-Überschreitungs-Blockierungsmechanismus — Kosten stiegen kontinuierlich; (3) Angst vor Qualitätsverlust: Team befürchtete, dass ein günstiges Modell „komplexe Therapielogik zerstört“; (4) Keine Metriken zur Prüfung, ob ein Downgrade einer Aufgabe sicher ist.
Lösung: Ebenen-Routing nach Lehrbuchmodell eingeführt: (1) Ebenen definiert: local-coder (Qwen2.5-Coder 7B lokal) für Entwürfe und Routine, frontier-reviewer (GPT-4) nur für kritische Reviews, strittige Verdikte und Red-Button-Prüfung; (2) Budget-Hüter eingeführt — externes Skript mit täglichem Token-Kontingent pro Ebene, das Frontier bei Überschreitung blockiert; (3) Für jede Aufgabe eine Guard-Metrik erstellt: local_coder_acceptance_rate — Anteil der Aufgaben, die nach Frontier-Modell-Review ohne Korrekturen nach local-coder-Generierung durchliefen; (4) Pilot: 30% der Aufgaben auf local-coder umgestellt mit automatischem Frontier-Review bei 10% Stichprobe.
Ergebnis: Nach 6 Wochen: Kostensenkung um 62%, local_coder_acceptance_rate stabilisierte sich bei 78% (Ziel: 75%), durchschnittliche Bearbeitungszeit routine-Aufgaben sank von 4,2 min auf 1,1 min (local-coder benötigt keinen Netzwerkaufruf). Kritische Vorfälle (Therapiekonflikte, Beschwerden) durchlaufen weiterhin frontier-reviewer. Budget-Hüter sprang 3-mal an, verschob non-urgent Frontier-Aufgaben korrekt auf den nächsten Tag ohne Vorfälle.
Gelernte Lektionen: Guard-Metrik local_coder_acceptance_rate ist kritisch für Vertrauen: Ohne sie wird das Team den Downgrade „für alle Fälle“ sabotieren
Budget-Hüter muss extern zum Agenten sein — Qwen Code verwaltet das Budget nicht selbst, das ist eine architektonische Grenze
Pilot mit stichprobenartigem Frontier-Review liefert Daten zur Begründung der Skalierung, nicht blindes Vertrauen in das günstige Modell
Ebenen-Routing erfordert Aktualisierung von QWEN.md: Few-Shot-Beispiele für local-coder und frontier-reviewer unterscheiden sich in Stil und Tiefe
Verwandte Konzepte: Modellstufe (tier, local-coder / frontier-reviewer)
Budget-Hüter (budget keeper)
Paarige Gegenmetrik (guard metric)
Auktion der Schatten-Spezifikationen (shadow specs)
Immunitätsmetrik (immunity score)
Titel: Spec Drift im Auto-Remediation-Kontur: Wie silent_p0 eine versteckte Krise aufdeckte
Szenario: In AgentClinic lief eine Auto-Remediation-Pipeline: Bei SMS-Gateway-Ausfall schaltete das System automatisch auf E-Mail-Kanal um, dokumentierte den Vorfall und benachrichtigte Oncall. MTTR (mittlere Wiederherstellungszeit) sank stetig: 12 min → 8 min → 5 min. Scheinbarer Erfolg.
Herausforderung: Bei detailliertem Audit wurde festgestellt: 18% der P0-Vorfälle (vollständiger Ausfall der Buchung kritischer Spezialisten) liefen ohne menschliche Bestätigung und ohne vollständigen Audit-Trail-Eintrag. Der Agent „reparierte“ das Problem durch Kanalwechsel, eskalierte aber nicht, wenn auch E-Mail nicht verfügbar war (seltener Fall, aber kritisch). MTTR sank durch „stille“ Auslassungen. Das ist klassische Goodhart-Verzerrung: Optimierung einer Metrik auf Kosten des Systems.
Lösung: Anti-Goodhart-Kontur eingeführt: (1) Zu MTTR Guard-Metrik silent_p0 hinzugefügt — Anteil P0 ohne Human Confirmation und vollständigem Audit Trail; (2) manual_review_floor = 15% gesetzt — Mindestanteil Entscheidungen zwingend durch Menschen; (3) audit_trace_coverage hinzugefügt — Anteil Aktionen mit vollständiger Evidence-Kette; (4) Notfallmodus (red button) blockiert Auto-Deploy bei silent_p0 > 10% oder manual_review_rate < 15%; (5) Replay historischer Vorfälle durch neuen Validator — Gatter: Neue Version darf Verdikte nicht verschlechtern.
Ergebnis: Erster Durchlauf zeigte: silent_p0 = 18%, manual_review_rate = 12%, audit_trace_coverage = 73%. Red button = BLOCKED. Team führte Untersuchung durch, aktualisierte mutable_rules in constitution.md: Jetzt ist bei Ausfall beider Kanäle (SMS+E-Mail) zwingend Human-in-the-Loop-Eskalation vorgeschrieben, keine Auto-Remediation. Nach 3 Wochen: silent_p0 = 4%, manual_review_rate = 22%, audit_trace_coverage = 97%, MTTR stieg auf 9 min (ehrliche Zeit, ohne stille Auslassungen). Red button = UNLOCKED.
Gelernte Lektionen: MTTR ohne Guard-Metriken — gefährliche „Köder-Metrik“: Leicht zu optimieren auf Kosten der Sicherheit
silent_p0 deckt genau das auf, was MTTR verbirgt — das ist seine einzige und kritische Funktion
manual_review_floor — keine Bürokratie, sondern Schutz vor Verdrängung des Menschen aus dem Kontur
Replay historischer Fälle — einzige Möglichkeit zu beweisen, dass „Verbesserung“ alte Szenarien nicht verschlechtert hat
Notfallmodus muss formales Gatter mit prüfbaren Bedingungen sein, nicht nur „rote Taste“ im Wortsinne
Verwandte Konzepte: Stiller P0 (silent_p0)
Paarige Gegenmetrik (guard metric, anti-Goodhart)
Notfallmodus (red button)
Replay (replay)
Mindestanteil manueller Prüfung (manual_review_floor)
Audit-Trail-Abdeckung (audit_trace_coverage)
Spezifikationsdrift (spec_drift, edge_drift)
Titel: Mutationstest der Buchungsspezifikation: Von poisoned spec zum geimpften Validator
Szenario: In AgentClinic wurde die Buchungsprioritätslogik aktualisiert: Früher bestimmte sich die Priorität nur nach Dringlichkeit (urgent/elective), jetzt kam der Faktor „Chronizität der Erkrankung“ (chronic flag) hinzu. Die neue Spezifikation sah korrekt aus, aber bei Integrationstests traten Konflikte auf: Chronischer Patient mit elective-Buchung erhielt höhere Priorität als urgent-Patient ohne chronic flag, was die alte Invariante „urgent immer zuerst“ verletzte.
Herausforderung: (1) Manuelles Testen deckte Konflikt nicht auf — Tester prüften Flags einzeln; (2) Alter Validator ließ Fall durch, weil Spezifikation formal Given/When/Then nicht verletzte — Konflikt lag in impliziter Priorität; (3) Validator musste „geimpft“ werden: Lernen, genau solche logische Defekte zu finden.
Lösung: Mutationstest nach Lehrbuchmodell angewendet: (1) Vergiftete Spezifikation (poisoned spec) erstellt — Kopie der neuen Spezifikation mit eingefügtem Operator PriorityContradiction: Eine Regel senkt urgent auf high bei chronic=false, andere hebt high auf urgent bei chronic=true ohne tie_breaker; (2) Erwarteter Fehler: PRIORITY_REVERSAL; (3) Validator durch Mutationszyklus geführt: Nullify (chronic-Felder), FutureTime (Buchungszeitstempel), EscalationCycle (Prioritäts-Eskalationszyklus), PriorityContradiction; (4) Immunitätsmetrik verfolgt: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms; (5) Validator, der Gatter nicht bestand (recovery_time_p95_ms > 1200ms), zur Überarbeitung geschickt.
Ergebnis: Nach 3 Iterationen: strict_reject_rate = 94% (Ziel: 90%), depth_of_diagnostics = 4,2 Schritte (Ziel: 3+), recovery_time_p95_ms = 890ms (Ziel: <1200ms). Validator fängt PriorityContradiction stabil am Schritt „When priority is calculated“. In Production wurde aktualisierte Spezifikation mit explizitem tie_breaker eingeführt: urgent > chronic > elective, mit Konfliktlösungstabelle. Integrationskonflikt vor Deployment beseitigt.
Gelernte Lektionen: Mutationstests von Spezifikationen — Analogon zu Unit-Tests für Logik, aber auf Anforderungsebene, nicht Code-Ebene
Poisoned spec — kein „kaputtes Dokument“, sondern kontrolliertes Übungswerkzeug mit bekanntem Defekt
Immunitätsmetrik — Vektor, nicht Skalar: Hoher strict_reject_rate bei niedrigem depth_of_diagnostics bedeutet „blinde Strenge“, nutzlos für Diagnostik
Mutationsoperatoren müssen nach Defekttyp klassifiziert sein, nicht zufällig — das ermöglicht gezielte Validator-Stärkung
Validator-Impfung — keine einmalige Aktion: Bei Spezifikationsänderung benötigt man Replay alter Mutanten
Verwandte Konzepte: Vergiftete Spezifikation (poisoned spec)
Mutationsoperator (mutation operator)
Immunitätsmetrik (immunity score, strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms)
Gegenbeispiel (counterexample)
Stress-Spezifikation (stress spec)
Replay (replay)
Lerntipps: Verwenden Sie das Glossar als Nachschlagewerk, nicht als Lehrbuch: Öffnen Sie einen Begriff, wenn er in einem konkreten Kapitel auftritt oder beim Datei-Ausfüllen hilft. Leseregel aus README: „Dateiname oder YAML/JSON-Schlüssel kann englisch bleiben, aber in der Erklärung wählen Sie eine deutsche Bedeutung“
Erstellen Sie eine persönliche „Übersetzungskarte“: Drucken Sie die Übersetzungstabelle der Schlüsselbegriffe aus und markieren Sie die, die Sie bereits in Ihren Artefakten verwendet haben. Ziel: Automatisieren der richtigen Wahl zwischen Prosa und technischem Namen
Üben Sie „Prosa-Erklärung“ laut: Nehmen Sie ein beliebiges YAML-Fragment aus den Beispielen und lesen Sie es laut vor, jeden Schlüssel durch deutsches Äquivalent ersetzend. Zum Beispiel silent_p0_ratio: 0.18 → „Anteil stiller P0: achtzehn Prozent“
Für visuellen Stil: Zeichnen Sie Verbindungsschemata zwischen Artefakten. Zum Beispiel Kette: poisoned spec → mutation operator → immunity score → spec gate → judgment.md → precedents.md. Das hilft zu sehen, wie Begriffe zusammenarbeiten, nicht isoliert
Für kinästhetischen Stil: Füllen Sie Vorlagen physisch aus. Nehmen Sie examples/templates/proposal.md und schreiben Sie einen echten Proposal für eine Änderung in Ihrem Projekt, dann führen Sie eine gedankliche Abstimmung durch
Verwenden Sie die „Regel der drei Kontexte“: Für jeden neuen Begriff finden Sie seine Verwendung in (1) Prosa-Erklärung, (2) YAML/JSON-Schlüssel, (3) Dateiname oder CLI-Befehl. Das verankert die Doppelschreibung
Führen Sie „Audit Ihrer Artefakte“ durch: Prüfen Sie wöchentlich, ob ein Anglizismus in die Prosa gerutscht ist oder ob Sie einen technischen Namen übersetzt haben. Korrigieren Sie — das trainiert Disziplin, kritisch für Teamarbeit
Zum Anti-Goodhart-Lernen: Finden Sie in Ihrem Projekt eine „Köder-Metrik“ — eine Kennzahl, die leicht auf Kosten des Systems optimierbar ist. Entwerfen Sie dafür eine Guard-Metrik nach dem Modell aus Teil 10
Gehen Sie das Capstone-Dossier schrittweise durch: Versuchen Sie nicht, alle 13 Teile auf einmal zusammenzutragen. Beginnen Sie mit einem realen Vorfall in Ihrer Praxis und durchlaufen Sie den Zyklus: Genealogy → Spec → Mutation → Constitution → Tribunal → Metrics
Verwenden Sie das Übungsprojekt AgentClinic als „mentale Sandkiste“: Wenn ein Begriff abstrakt erscheint, fragen Sie „wie würde das in der Buchungsklinik angewendet?“ — Domäne ist verständlich, Mapping auf Production-Szenarien ist in Anhang A fixiert
Zusätzliche Ressourcen: Ursprüngliches Kursdokument (Glossar des Anwendungsbandes): Hauptsachbuch, wird von Autoren aktualisiert; lesen Sie nach Teilen, nicht vollständig
Readme des Anwendungsbandes, Abschnitt „obligatorische Artefakte des ersten Durchgangs“: Minimalsatz zum Start: capstone/ und 10 Artefakte
Teil 1: Spec Archaeology (part-01-spec-archaeology.md): Einführung genealogy.md, Wiederherstellung von Spezifikationen aus Legacy
Teil 2: Poisoned Specs (part-02-poisoned-specs.md): Vergiftete Spezifikationen, Antipattern ask_storm
Teil 3: Project Constitution (part-03-project-constitution.md): Immutable/mutable-Abschnitte, governance_protocol, proposal.md
Teil 4: LLM Duel (part-04-llm-duel.md): Rollen Verifier/Implementor, Gegenbeispiele, repair.patch
Teil 5: Stress Specs (part-05-stress-specs.md): Mutationstests, Mutationsoperatoren, Immunitätsmetriken
Teil 6: Shadow Specs (part-06-shadow-specs.md): Schatten-Spezifikationen, Auktion, Scorebook, shadow-candidates.yaml
Teil 7: Specification CI (part-07-specification-ci.md): Spec Gate, Spezifikationsgatter, Integration mit GitHub
Teil 8: Multi-Agent Tribunal (part-08-multiagent-tribunal.md): Dateischiedsgerichtsbarkeit, judgment.md, precedents.md, Rolle Coordinator
Teil 9: Tier Budgeting (part-09-tier-budgeting.md): Ebenen-Routing, local-coder/frontier-reviewer, Budget-Hüter
Teil 10: Goodhart Metrics (part-10-goodhart-metrics.md): Anti-Goodhart, Guard-Metriken, Red Button, silent_p0, Replay
Teil 11: Real API Deployment (part-11-real-api-deployment.md): Readiness Gate, Dry Run, evidence_ref, 25-Punkte-Modell
Teil 12: Production Antipatterns (part-12-production-antipatterns.md): Verbindungen zwischen Begriffen, typische Einführungsfehler
Teil 13: Capstone (part-13-capstone.md): Abschlusspaket, vollständiger Production-SDD-Pfad für einen Vorfall
Anhang A: Bridges to Book (appendix-a-bridges-to-book.md): Entsprechung Übungscode und Production-Vorfälle
Anhang B des ersten Bandes: AgentClinic Domain: Domänen-Entitäten für mentale Experimente
Glossar des ersten Bandes (../book/glossary.md): Grundbegriffe SDD, hier durch Production-Ergänzungen ergänzt
Beispielvorlagen (examples/templates/): proposal.md, judgment.md und andere — zum praktischen Ausfüllen
Ausführbare Beispiele (examples/tribunal/, examples/stress-mutator/): Python-Stdlib-Skripte für lokale Prüfungen, nicht Stack der Hauptanwendung
Externe Frameworks zum Vergleich: GitHub Spec Kit, AWS Kiro: Referenzimplementierungen des SDD-Zyklus, Gegenüberstellung in Anhang A des ersten Bandes
Zusammenfassung: Das Glossar des Anwendungsbandes ist das Betriebssystem von Production-SDD, wo jeder Begriff eine klare Verwendungsregel hat: Deutsche Prosa für Erklärungen, englische technische Namen für Code. Schlüsselprinzipien: (1) Lesen Sie nach Bedarf, nicht vollständig; (2) Behalten Sie die Disziplin der Doppelschreibung bei — sie ist kritisch für Teamkommunikation; (3) Alle Metriken sind vektoriell und paarig, Guard-Metriken schützen vor Goodhart-Verzerrung; (4) Schiedsgerichtsbarkeit, Konstitution und Präzedenzfälle — keine Bürokratie, sondern formaler Schutz vor unvorhersehbarem Agentenverhalten; (5) Mutationstests und vergiftete Spezifikationen — Standardwerkzeug, keine Exotik; (6) Das Capstone-Dossier verbindet alle Teile zu einem reproduzierbaren Production-Pfad. Erfolgreiche Glossar-Erlernung wird nicht durch Definitionswissen gemessen, sondern durch die Fähigkeit, judgment.md bei einem strittigen Vorfall korrekt auszufüllen, eine Guard-Metrik für ein neues Feature zu entwerfen und ein Schiedsverfahren mit verständlichen Verdikten für alle Rollen durchzuführen.