Anwendungsband. Production SDD für Qwen Code CLI

Dieses Verzeichnis ist der zweite, anwendungsbezogene Band des Lehrbuchs. Der erste Band in book/ vermittelt den grundlegenden SDD-Zyklus auf AgentClinic: Konstitution, Feature-Spezifikation, Plan, überprüfbare Fakten, Implementierung, Review und Neuplanung. Der zweite Band überträgt denselben Zyklus in Produktionsszenarien: Legacy-Spuren, Validatoren, Multi-Agenten-Prüfungen, Spec CI, Metriken, Modellbudgets und eingeschränkte Auto-Remediation.

Version: v1.0 — geprüft am 2026-05-20. Änderungshistorie siehe CHANGELOG.md.

Das Material ist nicht für die erste Bekanntschaft mit SDD gedacht. Vor dem Lesen müssen Sie requirements.md, plan.md, validation.md, QWEN.md, Feature-Grenzen, negative Anforderungen und Faktenprüfung verstehen. Falls diese Begriffe noch nicht zum Arbeitsvokabular gehören, absolvieren Sie zunächst den ersten Band.

Die wichtigste Regel des zweiten Bands: Der erste Durchlauf muss eine einzige kleine überprüfbare Spur hinterlassen, nicht einen Überblick über die gesamte Produktionsterminologie verschaffen. In jedem Kapitel schließen Sie zunächst das didaktische Minimum ab: ein Artefakt, ein Befehl oder ein Blocker für capstone/. Der Hauptprüfungsfall ist high_memory_usage; Regeln für die Übertragung lokaler Fälle in den Hauptfall sind in Teil 0 beschrieben.

Schnellstart

1. Öffnen Sie Teil 0 und wählen Sie den Hauptfall high_memory_usage.
2. Erstellen Sie einen leeren capstone/.
3. In den Kapiteln 1–3 füllen Sie genealogy.md, das poisoned/fixed-Paar und constitution.md aus.
4. In den Kapiteln 4–11 führen Sie nur den Abschnitt „Minimales Lernszenario“ und runnable-Befehle aus [examples/](examples/) aus; verwendet ein Kapitel einen anderen Fall (autoscale_200pct, node_not_ready, appointment_latency / appointment_latency_spike, cdn_error_budget_burn), notieren Sie eine Übertragungszeile — welches Prinzip dieses Falls Ihr high_memory_usage schützt.
5. In Kapitel 12 prüfen Sie das Paket auf Antipatterns.
6. In Kapitel 13 erstellen Sie das abschließende capstone/README.md und prüfen, ob es ohne Chat-Verlauf verständlich ist.

Minimale Prüfung der Beispiele, einschließlich erwarteter Blockaden:

bash book2/examples/smoke_all.sh

Wie man Kapitel liest

Kapitel 1–12 sollten im gleichen Rhythmus gelesen werden. Am Kapitelanfang finden Sie zunächst einen kurzen Block „Vor dem Lesen“: Er beantwortet, was das Kapitel aus dem ersten Band übernimmt, welcher lokale Fall gestartet wird, was in capstone/ übertragen wird und was zum vollständigen Track gehört.

Danach halten Sie sich an fünf Fragen:

1. Stütze aus dem ersten Band. Welche AgentClinic-Idee wird erweitert.
2. Minimales Lernszenario. Was manuell oder lokal ausgeführt wird.
3. Kontrollfakt. Was beweist, dass das Kapitel abgearbeitet ist.
4. **Wie das in capstone/ gelangt.** Welche Zeile oder Datei nach dem Kapitel verbleibt.
5. Vollständiger Track. Was erst bei Einführung in ein echtes Produktions-Repository benötigt wird.

Falls ein Kapitel dicht erscheint, lesen Sie es nicht linear. Führen Sie zunächst das minimale Szenario aus, kehren Sie dann zu „Schlüsselideen“ zurück, und erst danach betrachten Sie Kalibrierungen, [project script] und [conceptual interface]. Ein Begriff, der nicht beim aktuellen Ausfüllen der capstone/-Datei hilft, kann bis zum zweiten Durchlauf übersprungen werden.

Redaktionsregel des zweiten Bands: Beim ersten Durchlauf sollte ein neues Kapitel nicht mehr als einen neuen Pflichtbegriff zu Ihrem Arbeitsvokabular hinzufügen. Falls fünf weitere Begriffe auftauchen, aber für die aktuelle capstone/-Datei nicht benötigt werden, betrachten Sie sie als Nachschlagewerk und kehren nach dem minimalen Szenario zu ihnen zurück.

Praxistest für ein Kapitel: Nach dem minimalen Szenario muss der Leser eine Zeile in eine capstone/-Datei schreiben können. Falls dafür zwei neue Mechanismen gleichzeitig verstanden werden müssen, gehört einer davon zum zweiten Durchlauf oder zum vollständigen Track.

Statusmarkierungen und Befehle

In den Kapiteln werden dieselben Vertrauensstufen wie im ersten Band verwendet:

• Standard — festgelegtes Verhalten eines Tools oder allgemein anerkannte Praxis.
• Empfehlung — Praxis, die in den meisten Fällen funktioniert, aber Anpassung zulässt.
• Frontier — Ansatz wird angewendet, aber Form hängt von Team, Modellen und Infrastruktur ab.

Befehlsblöcke sind in drei Typen unterteilt:

• [runnable] — funktioniert lokal in [book2/examples/](examples/) ohne externe Abhängigkeiten.
• [project script] — Schnittstelle eines Skripts, das im eigenen Projekt implementiert werden muss.
• [conceptual interface] — Form eines zukünftigen Orchestrierers, Policy-Gates, MCP-Layers oder CI-Integration.

Für das didaktische Durchlaufen werden nur [runnable]-Blöcke und manuelle Artefakte benötigt. Alles andere gehört zum vollständigen Track.

Durchgängige Route

| 0 | AgentClinic-production verstehen, high_memory_usage wählen, leeren capstone/ erstellen | Anpassung an eigene Produktionsdomäne | | 1–3 | eine Anforderung wiederherstellen, einen Defekt zeigen, constitution.md erstellen | automatische Normalisierer von Beweisen und Regel-Referenden | | 4–5 | Gegenbeispiel und Smoke-Ergebnis des Stress-Mutators erhalten | permanente Duell und Mutationsfabrik in CI | | 6–7 | Schattenkandidat annehmen/ablehnen, Spec CI starten | vollständiges Scorebook, Scope-Gate und PR-Berichte | | 8–9 | judgment.md zusammenstellen, Ablehnung der günstigen Stufe durchspielen | separater Budget-Service und Schiedsorchester | | 10–11 | Guard-Metriken prüfen, Readiness und Dry-Run für high_memory_usage | GitOps-Deployment und automatische Remediation ohne manuelle Bestätigung | | 12 | drei Risiken blocker / owner / next_check notieren | Umwandlung jedes Antipatterns in CI-Richtlinie | | 13 | abschließendes Paket zusammenstellen | produktionsreife Einführung des gesamten Prozesses |

Pflichtartefakte des ersten Durchlaufs

Verfolgen Sie nur diese Dateien. Andere Begriffe können nachgelesen werden, sobald das Hauptpaket als einheitlicher Fall lesbar ist.

• genealogy.md — Herkunft der Anforderung.

• poisoned-spec.md / fixed-spec.md — welcher Defekt gefunden und womit behoben wurde.
• constitution.md — welche Handlungen dem Agenten verboten oder eingeschränkt erlaubt sind.
• validation.md — welche Fakten tatsächlich geprüft wurden.
• judgment.md — welches Urteil gefällt und auf welchem Beweis.
• budget-note.md — was bei Ablehnung der günstigen Stufe passiert.
• goodhart-note.md — welche Metrik zu lügen beginnen könnte und welche Guard-Metrik sie begrenzt.
• readiness.md — warum der Kontur zugelassen, blockiert oder in halbmanuellen Modus versetzt wird.
• antipattern-audit.md — drei Risiken in der Form blocker / owner / next_check nach Kapitel 12.
• capstone/README.md — abschließende Zusammenstellung des Pakets für einen Fall.

Kapitel 6 fügt einen kurzen Block Shadow notes in capstone/README.md hinzu (oder, falls QWEN.md im Lern-Repository verwendet wird, dorthin). Dies ist keine separate Datei der Hauptliste.

Andere Namen (scorebook, metric_network, decision_hash, precedents.md) gehören zum vollständigen Track, sofern sie nicht direkt beim Ausfüllen einer der obigen Dateien helfen.

Jedes Kapitel muss ein minimales abschließendes Fragment für eine dieser Dateien liefern. Falls nach dem Kapitel nur allgemeines Verständnis, aber keine Zeile, kein Befehl oder kein Blocker für capstone/ vorhanden ist, ist das Kapitel auf Lernniveau noch nicht abgeschlossen.

Durchgängige Karte „welches Kapitel welche capstone/-Datei schreibt“:

Vor der selbstständigen Prüfung öffnen Sie [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md). Dies ist ein ausgefüllter Maßstab des minimalen Pakets für high_memory_usage: Er zeigt, wie kurz ein guter erster Durchlauf sein kann.

Kapitelkarte

| 7. Specification CI | Verbindung requirements.md → plan.md → validation.md | Zeile Spec CI mit PASS/BLOCK | | 8. Datei-Schiedsgericht | unabhängiges Review | judgment.md mit evidence_ref | | 9. Stufenbudgets | Modellauswahl nach Aufgabenrisiko | Budgetrisiko und token_health | | 10. Schutz von Metriken vor Goodhart | Fakten statt überzeugender Prosa | KPI und Guard-Metrik | | 11. Production API | Feature-Grenzen, Rollback, manuelle Prüfung | Readiness und Dry-Run | | 12. Antipatterns des Production SDD | SDD-Antipatterns | drei diagnostische Risiken | | 13. Praktische Prüfung | vollständiger SDD-Zyklus | abschließendes Paket capstone/ |

Warum sich der Fall von Kapitel zu Kapitel ändert

Der Hauptprüfungsfall ist high_memory_usage. Aber Kapitel 1–10 verwenden verschiedene Vorfälle, da nicht jeder gleich gut den untersuchten Mechanismus zeigt: Manchmal ist ein Prioritätskonflikt in einer anderen Domäne leichter zu erkennen, manchmal wird eine Mutationshistorie benötigt, die bei high_memory_usage nicht vorhanden ist. Ein Fall für den gesamten Band würde jedes Muster zu einer Formalität machen.

Die Übertragungsregel ist einfach: Notieren Sie nach dem Kapitel eine Zeile — welches Prinzip dieses Falls Ihr high_memory_usage schützt.

| 8 | autoscale_200pct | judgment.md mit verdict, evidence_ref und Rolle Safety | | 9 | autoscale_200pct | Budgetrisiko, token_health und Ablehnungsszenario der günstigen Stufe | | 10 | cdn_error_budget_burn | paarweise Anti-Goodhart-Metrik zur Remediation-KPI | | 11 | high_memory_usage | Readiness 23/25 und Dry-Run für Hauptfall | | 12 | beliebiges Paket der Kapitel 8–11 | drei Zeilen blocker / owner / next_check | | 13 | high_memory_usage | Zusammenstellung aller Artefakte in einheitliches capstone/ |

Falls der Fall des Kapitels nicht in einer Zeile übertragbar ist — das Kapitel wurde gelesen, aber nicht abgeschlossen.

Teile

1. AgentClinic-production-Labor
2. Wiederherstellung von Spezifikationen aus Legacy
3. Diagnose von Spezifikationsdefekten
4. Projektkonstitution: erstes Regel-Referendum
5. LLM-Duell: Verifikator gegen Implementator in formalen Behauptungen
6. Mutationstest von Spezifikationen
7. Auswahl von Schattenspezifikationen
8. Specification CI: Spezifikation als ausführbares Artefakt

1. Datei-Schiedsgericht für strittige Änderungen: Rollen, Urteile und Präzedenzfälle
2. Modell-Routing und Token-Budget
3. Schutz von Metriken vor Goodhart: Wächtermetriken und Notfallmodus
4. Integration mit echter API: von Spezifikation bis Deployment
5. Antipatterns des Production SDD: diagnostische Karte des Anwendungszyklus
6. Praktische Prüfung: Production SDD-Kontur zusammenstellen

Begleitdokumente

• Glossar des Anwendungsbands — Definitionen der Begriffe des zweiten Bands.
• Änderungsjournal des Anwendungsbands — Redaktionsgeschichte des Textes.
• Hinweis für Dozenten — Workshop-Formate und typische Fehler.
• Brücken zum ersten Band — Voraussetzungen und Domänenkarte AgentClinic.
• Kompatibilität mit Qwen Code — eingebaute Befehle, benutzerdefinierte Befehle und Projektskripte.
• Checklisten des Applied SDD — Prüfungen für Spec CI, Schiedsgericht, Metriken und Produktionsreife.

• Schwellenkalibrierung — Tabellen „Niedrig / Standard / Hoch“, Übungen zur Schwellenverschiebung und Überprüfungssignale für Kapitel 5, 6, 9, 10, 11. Beim ersten Durchlauf nicht erforderlich.
• Runnable-Beispiele — lokale Smoke-Läufe und Vorlagen.

Was als Erfolg gilt

Am Ende des Anwendungsbands sollte kein Satz schöner Regeln, sondern ein reproduzierbarer Kontur entstehen:

• strittige Anforderungen haben Provenienz und Unsicherheitsgrad;
• gefährliche Automatisierungen sind durch Konstitution, Guardrails und Rollback-Bedingungen begrenzt;
• validation.md prüft happy path, negative path, Gegenbeispiele, Drift und Goodhart-Fallen;
• CI oder sein runnable-Analog blockiert ungedeckte Anforderungen und schwache Payload-Verträge;
• Agentenentscheidungen hinterlassen Beweise, die für Review durch andere Personen oder Modelle geeignet sind;
• abschließendes capstone/ zeigt einen Pfad von Legacy-Spur bis zur produktionsreifen Lösung mit expliziten Blockern und Korrekturplan.