Thema: Praxisband. Production SDD für Qwen Code CLI
Schwierigkeitsgrad: Mittel
Geschätzte Studienzeit: 40-60 Stunden (erster Durchgang), 80-120 Stunden (mit vollständigem Track und praktischer Prüfung)
Voraussetzungen: Abschluss des ersten Bandes des Lehrbuchs (book/) — Basiszyklus SDD auf AgentClinic
Verständnis der Struktur von requirements.md, plan.md, validation.md, QWEN.md
Arbeit mit Feature-Grenzen, negativen Anforderungen und Faktenprüfung
Grundlegende Kommandozeilen- und Bash-Scripting-Fähigkeiten
Erfahrung mit LLM-Tools (wünschenswert Qwen Code CLI)
Verständnis der Grundlagen von CI/CD und Produktionsinfrastruktur
Lernziele: Nach Abschluss des Studiums wird der Studierende in der Lage sein, eine Spezifikation aus Legacy-Code wiederherzustellen und die Provenienz in genealogy.md für einen Produktionsfall zu dokumentieren
Der Studierende wird in der Lage sein, Spezifikationsdefekte zu diagnostizieren, ein poisoned/fixed-Paar zu erstellen und ein constitution.md mit immutable- und mutable-Regeln zu verfassen
Der Studierende wird in der Lage sein, Ergebnisse von LLM-Duellen, Mutationstests und Spec CI auszuführen und zu interpretieren, wobei Kontrollfakten in validation.md festgehalten werden
Der Studierende wird in der Lage sein, eine Schattenspezifikation anzunehmen oder abzulehnen, das Budgetrisiko der Modellstufe zu bewerten und ein judgment.md mit evidence_ref zu verfassen
Der Studierende wird in der Lage sein, ein abschließendes Paket capstone/README.md zusammenzustellen, es auf Antipatterns zu prüfen und drei Risiken in der Form blocker/owner/next_check vorzubereiten
Überblick: Der Praxisband des Lehrbuchs überträgt den Basiszyklus SDD (Specification-Driven Development) aus dem ersten Band in Produktionsszenarien. Während der erste Band Konstitution, Feature-Spezifikation, Plan, überprüfbare Fakten, Implementierung, Review und Neuplanung auf der AgentClinic-Plattform lehrte, arbeitet der zweite Band mit Legacy-Spuren, Validatoren, Multi-Agenten-Prüfungen, Spec CI, Metriken, Modellbudgets und eingeschränkter Auto-Remediation. Die Hauptregel: Der erste Durchgang muss eine einzige kleine überprüfbare Spur in capstone/ hinterlassen, nicht einen Überblick über die gesamte Terminologie vermitteln. Der Hauptprüfungsfall ist high_memory_usage; die übrigen Fälle (autoscale_200pct, node_not_ready, appointment_latency, cdn_error_budget_burn) dienen der Demonstration spezifischer Mechanismen mit anschließender Übertragung des Prinzips in den Hauptfall in einer Zeile.
Schlüsselkonzepte: Agentclinic-production: Erweiterung des Basis-AgentClinic für Produktionsszenarien: Arbeit mit bestehendem Code statt Greenfield-Entwicklung. Erfordert Wiederherstellung von Anforderungen aus Legacy, nicht Neuschreibung.
Genealogy.md: Provenienz-Artefakt: Woher eine Anforderung stammt. Dokumentiert Quelle (Post-Mortem, Ticket, Interview), Unsicherheitsgrad und Transformationskette vom Rohsignal zur Spezifikation.
Poisoned-spec.md / fixed-spec.md: Paar von Diagnoseartefakten für Spezifikationsdefekte. Poisoned — Spezifikation mit verstecktem Defekt (Widerspruch, implizite Annahme, Prioritätskonflikt); fixed — korrigierte Version mit expliziter Begründung.
Constitution.md: Projektverfassung: Regeln, die Agentenhandlungen einschränken. Immutable-Regeln — unveränderlich ohne Referendum (z.B. 'Produktionskonfiguration in Arbeitsstunden nicht ändern'). Mutable-Regeln — mit ttl und rollback_condition, können sich mit Anhäufung von Präzedenzfällen anpassen.
Llm-Duell (verifier vs implementor): Multi-Agenten-Prüfung formaler Behauptungen. Der Verifikator sucht nach Gegenbeispielen für Then-Behauptungen der Spezifikation; der Implementor verteidigt. Ergebnis — Gegenbeispiel oder next_guard (Bedingung, unter der die Spezifikation verletzt wird).
Stress-mutator / Mutationstesten von Spezifikationen: Automatische Generierung von Spezifikationsmutanten zur Robustheitsprüfung von Validatoren. Smoke-Ergebnis zeigt, welche Mutanten unbemerkt durchgingen — das ist der Immunitätsvektor des Validators.
Schattenspezifikationen (shadow specs): Kandidatenspezifikationen, die vom Agenten parallel zur Hauptspezifikation generiert werden. Werden nach Kriterien ausgewählt: nicht verfassungswidrig, decken neue Fakten ab, duplizieren nicht Vorhandenes. Angenommene — in capstone/README.md, abgelehnte — mit Begründung.
Spec ci: Specification CI: Spezifikation als ausführbares Artefakt. Prüft Anforderungsabdeckung, Vertragsschema, Vorhandensein von validation.md. Gibt PASS/BLOCK bei jedem Commit aus.
Datei-Schiedsgericht (multiagent tribunal): Rollenmodell für Review strittiger Änderungen: Safety (Sicherheit), Liveness (Funktionalität), Economy (Ressourcen). Ergebnis — judgment.md mit verdict, evidence_ref und dissenting opinion falls vorhanden.
Stufenbudgets (tier budgeting): Aufgabenrouting an Modelle verschiedener Stufen und Kosten. Günstige Stufe — schnelle Prüfungen, teure — Schiedsgericht. token_health verfolgt Verbrauch; bei Ablehnung der günstigen Stufe — Fallback oder manuelle Eskalation.
Goodhart-Schutz: Paar-Metrik: KPI (Zielmetrik) + Guard-Metrik (Wächtermetrik, die Systemspiel verhindert). Beispiel: KPI 'Remediation-Zeit' + Guard 'Anzahl falscher Remediation-Auslösungen'.
Readiness / dry-run: Produktions-API-Integration: Readiness-Metrik zeigt Bereitschaft des Kontours für Deployment (z.B. 23/25 Prüfungen bestanden). Dry-run — Durchlauf ohne Seiteneffekte zur Validierung vor echter Anwendung.
Antipattern-audit.md: Drei diagnostische Risiken in der Form blocker / owner / next_check nach Antipattern-Durchlauf. Nicht die Umwandlung jedes Antipatterns in eine CI-Richtlinie — das ist der vollständige Track.
Capstone/readme.md: Abschließende Zusammenstellung aller Artefakte für einen Fall. Muss ohne Chat-Verlauf als eigenständiges Beweispaket vom Legacy-Spur bis zur produktionsreifen Lösung lesbar sein.
Wichtige Termine: 2026-05-20: Version v1.0 des Praxisbandes — geprüft und fixiert. Stichtag für Lehrbuchmaterialien.
Kapitel 0: Erste Schritte — Auswahl des Falls high_memory_usage, Erstellung eines leeren capstone/
Kapitel 1-3: Bildung der Basisartefakte: genealogy.md, poisoned/fixed-Paar, constitution.md
Kapitel 4-5: Gewinnung des Gegenbeispiels und Smoke-Ergebnisses des stress-mutator
Kapitel 6-7: Auswahl der Schattenkandidaten, Start von Spec CI
Kapitel 8-9: Zusammenstellung von judgment.md, Durchspielen der Ablehnung der günstigen Stufe
Kapitel 10-11: Prüfung der Guard-Metriken, readiness und dry-run für high_memory_usage
Kapitel 12: Aufzeichnung der drei Risiken blocker/owner/next_check
Kapitel 13: Zusammenstellung des abschließenden capstone/README.md und praktische Prüfung
Übungsaufgaben: Titel: Wiederherstellung einer Anforderung aus einem Post-Mortem
Problem: Gegeben ist ein Fragment eines Post-Mortems des Incidents node_not_ready: 'Um 03:15 ging Node node-7 in NotReady, Pods wurden nicht innerhalb von 5 Minuten evakuiert, Kunden erhielten Timeouts. Manuelles drain + reboot halfen nach 12 Minuten. Auto-Evakuierung funktionierte nicht wegen Taint custom-scheduler=protected'. Stellen Sie eine überprüfbare Anforderung wieder her und verfassen Sie genealogy.md. Geben Sie den Unsicherheitsgrad (high/medium/low) an und begründen Sie.
Lösung: 1. Rohsignal isolieren: Auto-Evakuierung funktionierte nicht auf Node mit Taint custom-scheduler=protected. 2. In überprüfbare Anforderung umwandeln: 'Wenn eine Node den Taint custom-scheduler=protected hat, muss die automatische Pod-Evakuierung deaktiviert oder durch einen manuellen Workflow mit On-Call-Benachrichtigung ersetzt sein'. 3. In genealogy.md eintragen: source='post-mortem-2024-03-15-node7', raw_signal='auto-evacuation skipped due to protected taint', uncertainty='medium' (unklar, ob intentional oder Bug), requirement='protected-taint-evacuation-policy', derivation_steps=['incident report', 'taint analysis', 'policy decision']. 4. Begründung medium: einzelner Incident, keine Bestätigung dass Verhalten intentional, Replay oder zusätzlicher Fall für low nötig.
Schwierigkeit: mittel
Titel: Erstellung eines poisoned/fixed-Paars für einen Prioritätskonflikt
Problem: Gegeben ist eine Spezifikation: 'Given ein Terminbuchungssystem; When die Anzahl gleichzeitiger Anfragen 100 übersteigt; Then werden alle Anfragen in FIFO-Reihenfolge mit maximaler Verzögerung von 2 Sekunden verarbeitet'. Finden Sie den Defekt, erstellen Sie poisoned-spec.md und fixed-spec.md. Zeigen Sie den Rückwärtsgang (backwards walk) vom Defekt zur Wurzel.
Lösung: 1. Defekt: Implizite Annahme, dass 'alle Anfragen' gleichwertig sind. VIP-Patienten und Emergency-Anfragen sollten nicht FIFO warten. 2. Poisoned-spec.md: Original beibehalten, Markierung DEFECT='priority-blindness', trigger='emergency request during peak load', expected_failure='VIP patient waits 2+ seconds while routine appointment processed'. 3. Fixed-spec.md: 'Given ein Terminbuchungssystem mit priorisierten Warteschlangen (routine, urgent, emergency); When die Anzahl gleichzeitiger Anfragen 100 übersteigt; Then werden Emergency-Anfragen mit Verzögerung ≤ 500ms, urgent ≤ 1s, routine — FIFO mit Verzögerung ≤ 2s bei verfügbarem Capacity verarbeitet'. 4. Backwards walk: erwarteter Fehler (VIP-Timeout) → Ursache (keine Prioritäten in Then) → Ursache (keine Klassifikation in Given) → Wurzel (Domänenannahme 'alle Patienten gleich', für Healthcare falsch).
Schwierigkeit: mittel
Titel: Start des stress-mutator und Interpretation der Immunität
Problem: Im Verzeichnis book2/examples/ führen Sie bash smoke_all.sh aus. Finden Sie die Ausgabe des stress-mutator für den Fall payment_latency_spike. Wie viele Mutanten gingen unbemerkt durch? Welchen Immunitätsvektor des Validators zeigt das? Tragen Sie das Ergebnis in validation.md ein.
Lösung: 1. Wechseln Sie in book2/examples/ und führen Sie bash smoke_all.sh aus. 2. Finden Sie den Block [stress-mutator] payment_latency_spike. Beispielhafte erwartete Ausgabe: 'MUTANTS_GENERATED=12, CAUGHT=9, ESCAPED=3, ESCAPE_VECTOR=timing-assertion-weakness'. 3. ESCAPED=3 zeigt, dass der Validator Randbedingungen der Zeit nicht streng genug prüft. Immunitätsvektor: 'strenge Prüfung P99 < 200ms bei spike > 500% baseline hinzufügen, nicht nur Durchschnitt'. 4. In validation.md hinzufügen: 'Mutation Immunität: stress-mutator payment_latency_spike, 3/12 escaped, Vektor timing-assertion-weakness. Stärkung: strenger P99-guard bei spike-Bedingung'.
Schwierigkeit: mittel
Titel: Auswahl einer Schattenspezifikation: annehmen oder ablehnen
Problem: Gegeben sind zwei Schattenkandidaten für den Fall voice_handoff: A) 'Bei Übergabe eines Sprachanrufs zwischen Operatoren wird die vollständige Audioaufzeichnung des Gesprächs gespeichert' und B) 'Bei Übergabe eines Sprachanrufs zwischen Operatoren wird die Audioaufzeichnung nur ab Bestätigung durch den empfangenden Operator gespeichert'. Die Projektverfassung enthält eine immutable-Regel: 'Vollständige Audioaufzeichnung aller Kundeninteraktionen wird 7 Jahre für Compliance gespeichert'. Annehmen oder ablehnen Sie jeden Kandidaten? Begründen Sie und tragen Sie in capstone/README.md im Block Shadow notes ein.
Lösung: 1. Kandidat A: Verfassungsprüfung — widerspricht nicht der immutable-Regel (vollständige Aufzeichnung). Deckt neuen Fakt ab (Handoff als Teil der Interaktion). Dupliziert nicht Vorhandenes (Handoff war bisher nicht explizit spezifiziert). ENTSCHEIDUNG: annehmen. 2. Kandidat B: Widerspricht der immutable-Regel ('nur ab Bestätigung' ≠ 'vollständige Audioaufzeichnung aller Interaktionen'). ENTSCHEIDUNG: ablehnen, Grund 'verletzt constitution.md §3.1 immutable-Regel full-recording-compliance'. 3. In capstone/README.md Block Shadow notes: 'Accepted: shadow.p0.voice_handoff.full-recording — verfassungskonform, deckt Handoff-Lücke ab. Rejected: shadow.p0.voice_handoff.partial-recording — verletzt immutable full-recording-compliance. Präzedenz: Compliance hat Priorität vor Speicheroptimierung'.
Schwierigkeit: mittel
Titel: Bewertung des Budgetrisikos und Verfassung von budget-note.md
Problem: Szenario: Die günstige Stufe (Qwen2.5-7B-instruct, $0.10/1K Tokens) scheiterte bei Prüfung eines komplexen Vertrags autoscale_200pct — gab falsches PASS bei verletzter Then-Bedingung. Die teure Stufe (Qwen2.5-72B-instruct, $1.20/1K Tokens) fing den Fehler. Aktuelles token_health: 3400 Tokens verbleiben im Tagesbudget der günstigen Stufe, dabei müssen 15 Spezifikationen geprüft werden. Verfassen Sie budget-note.md mit Budgetrisiko und Ausfallszenario.
Lösung: 1. Risiko berechnen: 15 Spezifikationen × durchschnittlicher Verbrauch 400 Tokens = 6000 Tokens benötigt, verfügbar 3400. Defizit: 2600 Tokens (43% fehlen). 2. Ausfallwahrscheinlichkeit der günstigen Stufe: hoch — bereits ein falsches PASS zeigte, dass 7B-Modell mit skalierbaren Verträgen nicht zurechtkommt. 3. Ausfallszenario: Bei Erschöpfung des günstigen Budgets erhöht Fallback auf teure Stufe Prüfkosten von $0.60 auf $7.20 (12×). Bei Mangel auch der teuren Stufe — manuelle Eskalation mit Verzögerung 4-24 Stunden. 4. budget-note.md: 'tier: cheap, model: Qwen2.5-7B-instruct, token_health: 3400/6000 needed, risk_level: critical, failure_mode: false_PASS_on_scale_contracts, fallback: expensive_tier_with_cost_spike, mitigation: pre-filter_scale_contracts_to_expensive_tier, owner: on-call-SRE, next_check: 2026-05-21T09:00Z'.
Schwierigkeit: fortgeschritten
Titel: Paarige Anti-Goodhart-Metrik für Remediation-KPI
Problem: KPI des SRE-Teams: 'Durchschnittliche Remediation-Zeit für Incidents (MTTR) ≤ 15 Minuten'. Welche Guard-Metrik verhindert Spiel mit dieser Metrik? Verfassen Sie goodhart-note.md für den Fall cdn_error_budget_burn.
Lösung: 1. Spielstrategie: Incidents automatisch mit resolved-Marker 'remedieren' ohne Fix, damit MTTR gut aussieht. 2. Guard-Metrik: 'Prozent der Remediations mit bestätigtem Fix innerhalb von 24 Stunden' (confirmed_fix_rate) + 'Prozent wiederholter Incidents aus gleicher Ursache innerhalb von 7 Tagen' (recurrence_rate). 3. Alarmbedingung: wenn MTTR < 15min aber confirmed_fix_rate < 80% oder recurrence_rate > 15% — Notfallmodus, Verbot automatischer Remediation ohne menschliche Bestätigung. 4. goodhart-note.md: 'KPI: MTTR ≤ 15min, guard: confirmed_fix_rate ≥ 80% AND recurrence_rate ≤ 15%, emergency_mode_trigger: MTTR_green_but_guard_red, action: disable_auto_remediation_require_human_approval, case: cdn_error_budget_burn_2024-11'.
Schwierigkeit: mittel
Fallstudien: Titel: Implementierung von Spec CI im Zahlungskontur eines Fintech-Startups
Szenario: Fintech-Startup mit 50 Mikroservices, die 10M Transaktionen/Tag verarbeiten. Team aus 8 Entwicklern, 2 SRE. Zuvor ad-hoc-Spezifikationen in Confluence, die innerhalb von 2-3 Wochen veralteten. Nach Incident mit Doppelabbuchung (Verlust $340K Entschädigungen) forderte das Management 'überprüfbare Anforderungen für jede Änderung'.
Herausforderung: Legacy-Code des Zahlungsgateways seit 8 Jahren — keine aktuellen Spezifikationen, nur Code-Kommentare und mündliche Absprachen. Entwickler widersetzten sich 'überflüssiger Bürokratie'. CI-Pipeline dauerte 23 Minuten, Spec CI drohte Erhöhung auf 40+. Wert musste ohne Delivery-Blockade gezeigt werden.
Lösung: Angewandter Ansatz des Praxisbands: Kapitel 1-7 in komprimierter Form. 1) Ein kritischer Fall ausgewählt — payment_latency_spike (Kapitel 5). 2) genealogy.md aus Post-Mortem der Doppelabbuchung wiederhergestellt (Kapitel 1). 3) Poisoned-spec gefunden: 'bei latency > 2s automatisch retry' ohne idempotency-key — erzeugt Doppelabbuchung (Kapitel 2). 4) constitution.md erstellt mit immutable-Regel 'alle Payment-Retries erfordern idempotency-key' (Kapitel 3). 5) LLM-Duell fand Gegenbeispiel: retry bei network_timeout vs retry bei insufficient_funds — unterschiedliches Verhalten (Kapitel 4). 6) Stress-mutator prüfte Validator: 2/8 Mutanten durchgingen — Idempotency-Prüfung verstärkt (Kapitel 5). 7) Spec CI nur auf Payment-Services implementiert, nicht alle 50 — Zeile in CI: 'spec-ci --scope=payment-* --block-on-uncovered' (Kapitel 7). Zeit: +4 Minuten zur Pipeline.
Ergebnis: Nach 3 Monaten: 0 Doppelabbuchungs-Incidents (waren 4 in 6 Monaten davor). Spec CI fing 12 ungedeckte Anforderungen vor Produktion. Entwicklerteam bewertete — 'wir sehen wofür das ist, nicht nur Papier'. Erweiterung auf weitere Services von Entwicklern initiiert, nicht vom Management. Durchschnittliche Zeit für Spezifikationserstellung sank von 45 auf 12 Minuten (Vorlagen aus capstone/).
Erkenntnisse: Mit einem kritischen Fall beginnen, nicht 'überall einführen' — Prinzip 'eine einzige kleine überprüfbare Spur' funktioniert auch für organisatorische Veränderungen
Poisoned-spec mit realem finanziellem Schaden überzeugender als jedes Training — 'hier haben wir bereits geirrt'
Spec CI auf Teilmenge von Services liefert schneller Wert als Warten auf vollständige Abdeckung
Entwickler akzeptieren Prozess, wenn er reale Bugs vor Produktion fängt, nicht wenn er 'von oben verordnet' wird
Verwandte Konzepte: genealogy.md
poisoned-spec.md / fixed-spec.md
constitution.md
LLM-Duell
stress-mutator
Spec CI
capstone/README.md
Titel: Schiedsgericht für strittige Autoscale-Änderung in Cloud-Plattform
Szenario: Cloud-Plattform mit 2000+ Kubernetes-Clustern. Platform-SRE-Team schlug Änderung vor: 'Bei CPU > 80% für 5 Minuten — automatische Skalierung +200% Nodes'. Änderung strittig: Liveness-Team meint, das verhindere Kaskadenfehler; Safety-Team — 200% sprunghafter Anstieg erzeuge Overprovisioning-Risiko und Cost-Spike bei kurzen Bursts.
Herausforderung: Klassischer Prioritätskonflikt: Verfügbarkeit vs Wirtschaftlichkeit. Zuvor entschied Senior-SRE allein — entstand Gefühl der 'Diktatur', Entscheidungen nicht reproduzierbar. Formeller Prozess mit Beweisen für Audit und Schulung neuer Ingenieure nötig.
Lösung: Angewandtes Datei-Schiedsgericht (Kapitel 8) mit Rollenmodell. 1) Safety bereitete Gegenbeispiel: Burst über 4 Minuten 50 Sekunden — sollte nicht +200% triggern, triggert aber bei aktueller Spezifikation. 2) Liveness bereitete Evidence: Incident-Historie, wo 80% über 6+ Minuten in 73% der Fälle zu Kaskadenfehler führte. 3) Economy berechnete: Kosten false-positive (überflüssige Nodes für 10 Minuten) vs Kosten Kaskadenfehler (Downtime-Minuten × SLA-Strafen). 4) judgment.md: verdict='CONDITIONAL_APPROVE', Bedingung 'Guard-Metrik burst_duration < 5min AND rate_of_change > 50%/min für Ausschluss kurzer Spikes hinzufügen', evidence_ref=['safety-counterexample-burst-290s', 'liveness-historical-73pct', 'economy-cost-model-v2']. Dissenting opinion Safety: 'hätte 70% Schwelle bevorzugt, akzeptiere aber 80% mit Guard-Bedingung'.
Ergebnis: Änderung mit Guard-Bedingung implementiert. Nach 2 Monaten: 3 Fälle Guard-Bedingung-Triggers (keine Skalierung), alle als kurze Bursts bestätigt. 1 Fall wo 80% über 7 Minuten hielt — Skalierung funktionierte, potenzieller Kaskadenfehler verhindert. Kosten falscher Auslösungen sanken um 67% gegenüber ursprünglichem Vorschlag. Schiedsgerichtsprozess als Standard für alle strittigen Änderungen > $10K potenziellen Impacts angenommen.
Erkenntnisse: Rollenschiedsgericht mit dissenting opinion schafft reproduzierbare Präzedenzfälle — neue Ingenieure lernen aus Geschichte, nicht aus Autorität
Gegenbeispiel + historische Daten + Wirtschaftsmodell = drei Evidence-Arten, die zusammen überzeugender sind als jede einzelne
CONDITIONAL_APPROVE besser als binäres approve/reject — erhält Entscheidungsgeschwindigkeit bei Hinzufügung von Guard-Bedingungen
Dissenting opinion in judgment.md schwächt Entscheidung nicht, sondern stärkt Legitimität — zeigt dass Alternativen geprüft wurden
Verwandte Konzepte: Datei-Schiedsgericht
judgment.md
evidence_ref
Rollen Safety/Liveness/Economy
Guard-Metrik
dissenting opinion
Titel: Goodhart-Schutz bei Automatisierung von CDN-Incident-Remediation
Szenario: Großer Media-Streaming-Service mit globalem CDN. KPI: 'Remediation-Zeit für CDN-Incidents ≤ 5 Minuten'. Erreicht durch automatische Remediation: bei error_rate > 5% — automatischer Cache-Purge + Umschaltung auf Origin. MTTR sank von 12 auf 4 Minuten.
Herausforderung: Nach 3 Monaten nach Implementierung: MTTR = 3,2 Minuten, aber Kunden beschweren sich über Buffering. Untersuchung: Automatische Remediation bei error_rate > 5% triggerte auf falschen Spikes (Messfehler, keine echten 5xx). Cache-Purge bei falschem Trigger erzeugte Thundering Herd auf Origin, verschlechterte reales UX. Team 'spielte' KPI: MTTR exzellent, echter Service verschlechtert.
Lösung: Angewandter Ansatz Kapitel 10. 1) Diagnose: KPI (MTTR) 'lügt' — Optimierung verschlechterte reales Ergebnis. 2) Guard-Metrik: 'Prozent der Remediations mit bestätigtem echtem 5xx (kein Messfehler)' + 'Origin-Load-Spike nach Remediation < 150% baseline'. 3) Notfallmodus: bei guard_red + KPI_green — disable auto-remediation, require human confirmation, alert on-call. 4) goodhart-note.md: 'KPI: MTTR ≤ 5min, guard: confirmed_5xx_rate ≥ 90% AND origin_post_remediation_load ≤ 150%, emergency_mode: 3 consecutive guard_red in 24h'. 5) Zusätzlich: dry-run-Modus hinzugefügt (Kapitel 11) — bei neuen Incident-Typen Remediation ohne Seiteneffekte, Ergebnis menschlich geprüft.
Ergebnis: Nach Implementierung der Guard-Metriken: MTTR stieg auf 6,5 Minuten (schlechter als KPI), aber bestätigte reale Remediations — 94% (vs 61% zuvor). Buffering-Beschwerden sanken um 78%. Team hörte auf, Metrik zu 'spielen' — wurde unrentabel. Management überarbeitete Bonusstruktur: jetzt 50% Gewicht auf Guard-Metriken, 50% auf KPI. Dry-run für neue Incident-Typen verhinderte 2 potenzielle falsche Remediations im ersten Monat.
Erkenntnisse: KPI ohne Guard-Metrik schadet aktiv — Ingenieure optimieren rational das Messbare, auch wenn es nicht mit realem Ergebnis übereinstimmt
Notfallmodus muss automatisch sein — 'require human confirmation' bei guard_red sollte ohne zusätzliche Entscheidungen greifen
Dry-run für neue Incident-Typen — unverzichtbar bei Erweiterung der Automatisierung, sonst jeder neue Fall potenzielle Goodhart-Falle
Bonusstruktur muss Guard-Metriken einschließen, sonst gewinnt KPI — organisationale Ingenieurie wichtiger als technische
Verwandte Konzepte: Goodhart-Schutz
KPI und Guard-Metrik
goodhart-note.md
Notfallmodus
dry-run
readiness.md
Studientipps: Lesen Sie niemals ein Kapitel linear von Anfang bis Ende. Finden Sie zuerst den Block 'Vor dem Lesen', führen Sie dann das minimale Lernszenario aus, kehren Sie dann zu 'Schlüsselideen' zurück. Erst danach — Kalibrierungen, [project script] und [conceptual interface].
Halten Sie fünf Fragen beim Lesen jedes Kapitels bereit: Stütze aus erstem Band? Minimales Lernszenario? Kontrollfakt? Wie gelangt es in capstone/? Was gehört zum vollständigen Track?
Regel eines neuen Begriffs: Wenn ein Kapitel fünf Namen einführt, aber nur einer für die aktuelle capstone/-Datei nötig ist — merken Sie einen, den Rest auf zweiten Durchgang verschieben.
Erstellen Sie eine physische oder digitale 'Durchgangskarte' an Wand/Bildschirm: welches Kapitel → welche capstone/-Datei → was genau hineingeschrieben wird. Prüfen Sie danach nach jedem Kapitel.
Für Kapitel mit fremden Fällen (nicht high_memory_usage) sofort Übertragungszeile schreiben: 'Prinzip X aus Fall Y schützt high_memory_usage, weil...'. Wenn nicht geschrieben — Kapitel nicht abgeschlossen.
Führen Sie bash book2/examples/smoke_all.sh nach jedem Kapitel mit runnable-Beispielen aus. Erwartete Blockaden sind Teil des Lernens, kein Fehler. Wenn Beispiel nicht blockiert wo es sollte — Version prüfen.
Verwenden Sie die Vorlage capstone-dossier.md als Minimalitätsmaßstab. Wenn Ihr Paket 3× länger — haben Sie wahrscheinlich den vollständigen Track im ersten Durchgang erfasst.
Für visuelle Lerner: Zeichnen Sie die Artefakt-Pipeline genealogy → poisoned/fixed → constitution → validation → judgment → budget → goodhart → readiness → antipattern. Markieren Sie, wo Sie gerade sind.
Für auditive Lerner: Sprechen Sie Kontrollfakten laut vor Dateieintragung. Wenn es verschwommen klingt — Fakt nicht überprüfbar genug.
Für kinästhetische Lerner: Bewegen Sie Artefakt-'Karten' physisch auf einer Tafel von 'roher Idee' zu 'in capstone/ geprüft'. Taktile Fortschritt motiviert.
Bilden Sie eine Lerngruppe aus 2-3 Personen: einer liest Kapitel, erklärt anderen minimales Szenario, dritter prüft capstone/. Lernen durch Lehren beschleunigt Aufnahme um Faktor 2-3.
Versuchen Sie nicht, 'production-ready Implementierung' im ersten Durchgang zu erreichen. Ziel des ersten Durchgangs — reproduzierbarer Kontour für einen Fall. Vollständiger Track — separates Projekt nach Prüfung.
Zusätzliche Ressourcen: Book2/examples/readme.md: Lokale Smoke-Durchläufe und Vorlagen für alle Kapitel. Obligatorische Ressource für Praxis.
Book2/examples/templates/capstone-dossier.md: Ausgefüllter Maßstab des minimalen Pakets für high_memory_usage. Zeigt, wie kurz ein guter erster Durchgang sein kann.
Book2/glossary.md: Definitionen aller Begriffe des zweiten Bands. Als Nachschlagewerk verwenden, nicht als Auswendiglern-Text.
Book2/appendix-a-bridges-to-book.md: Brücken zum ersten Band — Voraussetzungen und vollständige Domänenkarte AgentClinic. Nützlich bei Fragen 'wo wurde das früher erklärt'.
Book2/appendix-b-qwen-code-compatibility.md: Eingebaute Befehle, benutzerdefinierte Befehle und Projektscripts Qwen Code. Nötig für Anpassung runnable-Beispiele an Ihre CLI-Version.
Book2/appendix-c-checklists.md: Checklisten für Spec CI, Schiedsgericht, Metriken und Produktionsbereitschaft. Zur Selbstprüfung vor Prüfung verwenden.
Book2/appendix-d-threshold-calibration.md: Tabellen 'Niedrig / Standard / Hoch', Übungen zur Schwellenverschiebung. Auf zweiten Durchgang oder reale Implementierung verschieben.
Book2/instructor.md: Workshop-Formate und typische Fehler. Nützlich wenn Sie Team schulen oder in Gruppe durchlaufen.
Book2/changelog.md: Redaktionsgeschichte des Textes. Aktualität bei Materialverwendung prüfen.
Ausgangsdokument des Kurses (Readme des Praxisbands): Basisdokument, auf dem dieser Leitfaden aufbaut. Zurückkehren für Prüfung Ihres Fortschritts gegen Plan.
Zusammenfassung: Der Praxisband Production SDD für Qwen Code CLI lehrt die Übertragung des Basiszyklus spezifikationsgesteuerter Entwicklung in reale Produktionsbedingungen. Schlüsselprinzip — eine einzige kleine überprüfbare Spur pro Durchgang: Jedes Kapitel fügt genau eine Zeile, Datei oder Blocker in capstone/ hinzu. Der Hauptfall high_memory_usage durchläuft alle Phasen: Wiederherstellung von Anforderungen aus Legacy (genealogy.md), Defektdiagnose (poisoned/fixed-Paar), Projektverfassung, LLM-Duell und Mutationstest (validation.md), Auswahl von Schattenspezifikationen, Spec CI, Datei-Schiedsgericht (judgment.md), Stufenbudgets (budget-note.md), Metrikschutz gegen Goodhart (goodhart-note.md), readiness und dry-run (readiness.md), Antipatterns (antipattern-audit.md). Ergebnis — reproduzierbarer Kontour von Spur bis zur produktionsreifen Lösung, ohne Chat-Verlauf verständlich. Erster Durchgang erfordert Abschneidedisziplin: Vollständiger Track nach Prüfung, nicht stattdessen.