Praxisteil 13. Praktische Prüfung: Production-SDD-Kontur aufbauen

Status: Empfehlung. Dieser Teil führt keinen neuen Mechanismus ein. Er fasst den zweiten Band zu einer überprüfbaren Route zusammen, nach dem Muster der praktischen Prüfung des ersten Bands. Ziel ist es zu beweisen, dass Sie einen Production-Szenario von SDD vom Legacy-Trace bis zu einer Lösung durchlaufen können, die durch Fakten zugelassen wird, nicht durch die Überzeugung des Agenten.

Die Prüfung sollte nach den Kapiteln 1–12 absolviert werden. Wenn Sie den Band selektiv lesen, nutzen Sie diesen Teil als Karte fehlender Artefakte: Jede Lücke im Paket capstone/ zeigt, zu welchem Kapitel Sie zurückkehren müssen. Falls unklar ist, wie Dateien zu einem Fall verbunden werden, kehren Sie zu Teil 0 zurück: Dieser legt den Laborrahmen AgentClinic-production fest und erklärt, was als didaktisches Minimum gilt.

Ziel

Am Ende der Prüfung sollten Sie ein zusammenhängendes Beweispaket für AgentClinic-production haben:

• eine wiederhergestellte Anforderung mit Provenienz;
• eine kontrolliert defekte, korrigierte Spezifikation;
• constitution.md mit unveränderlichen und veränderlichen Regeln;
• mindestens ein Gegenbeispiel und ein Duell-Eintrag;
• ein lokaler Spec CI oder sein runnable-Analogon;

• judgment.md oder ein Präzedenzfall-Eintrag;
• Budget- und Anti-Goodhart-Kontrolle;
• eine Bereitschaftsschleuse (readiness gate) und eine Liste von Blockern;
• eine diagnostische Antipattern-Checkliste.

Die Prüfung gilt nicht als bestanden, wenn alle Dateien vollständig aussehen, sondern wenn eine andere Person das Paket öffnen, die wichtigsten Prüfungen wiederholen und verstehen kann, warum die Lösung sicher zugelassen werden sollte oder warum sie zurückgestellt werden muss.

Endgültiger Fall

Arbeiten Sie mit einem Production-Vorfall. Der empfohlene Hauptfall ist high_memory_usage, da er durch die Webhook-Normalisierung, die Readiness-Schleuse und den Probelauf aus Teil 11 führt. autoscale_200pct kann an seiner Stelle gewählt werden, wenn Sie die Prüfung um Duell und Dateiarbitrage herum gestalten. Mischen Sie nicht beide Fälle in einer Prüfung.

Minimale Aufstellung:

• AgentClinic-production erhielt einen Alert von Grafana oder PagerDuty;
• Legacy-Spuren sind unvollständig: Ein Teil der Regeln ist aus dem Post-Mortem bekannt, ein Teil aus QWEN.md, ein Teil aus mündlicher Praxis;
• die automatische Remediation erscheint nützlich, kann aber das Limit des Wirkungsradius, das Budget der Ebenen oder die Anti-Goodhart-Invariante verletzen;
• vor der Zulassung muss bewiesen werden, dass Spezifikation, Plan, Prüfung und Readiness einander nicht widersprechen.

Paketstruktur

Erstellen Sie ein Verzeichnis:

capstone/
  README.md
  genealogy.md
  poisoned-spec.md
  fixed-spec.md
  constitution.md
  validation.md
  judgment.md
  budget-note.md
  goodhart-note.md
  readiness.md
  antipattern-audit.md

Wenn Sie an einem realen Projekt arbeiten, können die Namen angepasst werden. Die Rollen der Dateien müssen jedoch gleich bleiben: Herkunft, Defekt, Korrektur, Regeln, Fakten, Arbitrage, Budget, Metriken, Bereitschaft und Prozessaudit.

Bevor Sie Ihr Paket ausfüllen, öffnen Sie [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md). Dies ist der referenzielle „Goldene Pfad" des ersten Durchlaufs für high_memory_usage: Er zeigt, wie viele Fakten für die Prüfung ausreichen, ohne das Kapitel in ein großes Production-Dokument zu verwandeln.

Nutzen Sie ihn als Größenbegrenzer. Wenn Ihr capstone/README.md oder validation.md deutlich länger als die Referenz wird, prüfen Sie zuerst, ob Artefakte des vollständigen Tracks hineingeraten sind: scorebook, metric_network, vollständiges out/duel.json, gesamter Budgetplan oder detaillierte Chat-Historie.

Suchen Sie in den Kapiteln 1–12 nach dem Block „Wie das in capstone/ gelangt". Er ist beim ersten Durchlauf wichtiger als die vollständige Artefaktliste des Kapitels. Wenn der Block sagt, eine Zeile, einen akzeptierten Kandidaten, einen Schutzinvarianten oder einen Readiness-Verdikt zu übertragen, erweitern Sie das Beweispaket nicht auf alle Dateien des vollständigen Production-Tracks.

Notieren Sie vor Beginn fünf Zeilen als Vorlage in capstone/README.md:

Incident-case:
Hauptrisiko:
Schlüsselprüfung:
Hauptblocker:
Nächste Korrektur:

Für den Standardpfad sollte die erste Zeile Incident-case: high_memory_usage lauten. Wenn autoscale_200pct gewählt wurde, geben Sie dies sofort an und fügen Sie high_memory_usage nicht als zweiten gleichberechtigten Fall hinzu.

Wenn diese Zeilen nicht ausgefüllt werden können, ist das Paket noch nicht um einen Fall herum aufgebaut.

Minimales didaktisches Szenario

Didaktischer Fall

Nehmen Sie high_memory_usage aus [examples/real-api/](examples/real-api/) als Standardpfad. Wenn stattdessen autoscale_200pct aus [examples/tribunal/](examples/tribunal/) gewählt wurde, schreiben Sie dies direkt in capstone/README.md und fügen Sie high_memory_usage nicht als zweiten gleichberechtigten Fall hinzu. Ziel ist es, nicht einen idealen Production-Prozess, sondern ein kleines reproduzierbares Beweispaket aufzubauen: ein Vorfall, ein Spezifikationsdefekt, ein Gegenbeispiel oder Readiness-Ergebnis, eine Blockerliste.

Vorbereitung

• Lesen Sie das README des gewählten runnable-Beispiels.
• Kopieren Sie die benötigten Vorlagen aus [examples/templates/](examples/templates/).
• Erstellen Sie ein leeres Verzeichnis capstone/.
• Entscheiden Sie im Voraus, was als Blocker gilt: schwacher evidence_ref, Prioritätskonflikt, Verletzung von manual_review_floor, Budgetüberschreitung oder Readiness unter dem Schwellenwert.

Schritte

1. Füllen Sie capstone/genealogy.md aus: eine wiederhergestellte Anforderung, mindestens zwei Quellen, Vertrauensstufe und offene Frage.
2. Erstellen Sie capstone/poisoned-spec.md: Fügen Sie genau einen Defekt ein — Prioritätskonflikt, Zyklus oder verdeckte Grenzüberschreitung.

1. Erstellen Sie capstone/fixed-spec.md: Beheben Sie den Defekt mit einer Ausnahmeregel, einem Schema oder einer expliziten negativen Anforderung.
2. Füllen Sie capstone/constitution.md aus: mindestens zwei immutable_principles, eine mutable_rule mit ttl, max_scope, rollback_condition, und ein kurzes governance_protocol.
3. Führen Sie ein runnable-Beispiel für den gewählten Fall aus.

• Für high_memory_usage — die Befehle aus dem Abschnitt „Minimales didaktisches Szenario" Teil 11: ein positiver Readiness, ein blockierender stateful, ein erlaubter und ein verbotener Dry-Run. Befehle mit readiness_block_stateful.json und delete_namespace geben erwartungsgemäß Code 1 zurück — dies ist kein Fehler im Beispiel, sondern Quellen von Blockern für capstone/validation.md.
• Für autoscale_200pct — drei Skripte aus dem Abschnitt „Minimales didaktisches Szenario" Teil 8: run_duel.py, check_invariants.py, write_judgment.py.

Vollständige Befehle werden hier nicht dupliziert, damit die Prüfung nicht zur Kopierarbeit wird. Wenn Sie beide Kapitel geöffnet haben, folgen Sie ihren Schritten in derselben Reihenfolge.

1. Übertragen Sie das Ergebnis in capstone/validation.md: Befehl, erwarteter Fakt, tatsächliches Ergebnis und Zulassungsblocker. Für real-api zeigt der positive Readiness-Durchlauf den zulässigen Pfad, readiness_block_stateful.json liefert den stateful-Blocker, und delete_namespace zeigt die Grenze vorab vereinbarter Aktionen. Wenn der Befehl aus einem anderen runnable-Verzeichnis stammte, erklären Sie, welcher Prinzip in den Hauptfall übertragen wird.
2. Füllen Sie capstone/judgment.md aus: Verdikt APPROVE, DENY oder DEFERRED, Begründung, evidence_ref, nächster Schritt. judgment.md ist ein Entscheidungsprotokoll zu einem konkreten Streit; eine wiederkehrende Konfliktklasse wird zusätzlich in capstone/precedents.md mit fünf Feldern festgehalten (case_id / verdict / evidence_ref / applies_to / next_check), siehe Teil 8.
3. Fügen Sie capstone/budget-note.md hinzu: Was geschieht bei Ablehnung von local-coder, welches Limit schützt frontier-reviewer, wann greift der Notfallmodus.
4. Fügen Sie capstone/goodhart-note.md hinzu: Welche Zielmetrik könnte anfangen zu lügen und welche Guard-Metrik begrenzt sie.

1. Füllen Sie capstone/readiness.md aus: Gesamtbewertung, blockierende Bedingungen, warum 23/25 mit Beweisen besser ist als 25/25 ohne.
2. Gehen Sie die diagnostische Checkliste aus Teil 12 durch und notieren Sie drei Risiken in capstone/antipattern-audit.md.
3. Vervollständigen Sie capstone/README.md: ein Absatz Kontext, Befehlsliste, Endstatus und Liste der Korrekturen bis Production.

Nach Schritt 12 lesen Sie capstone/README.md als neuer Reviewer. Darin sollten nicht alle Details sichtbar sein, sondern der Prüfpfad: Woher stammt die Anforderung, was war defekt, welcher Befehl wurde ausgeführt, welcher Verdikt ergab sich und was blockiert die Production-Zulassung.

Minimales capstone/README.md für den ersten Durchlauf passt in fünf Zeilen:

Incident-case: high_memory_usage
Hauptrisiko: Auto-Remediation ohne vollständigen audit_trace oder backup evidence
Schlüsselprüfung: python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json
Hauptblocker: stateful workload ohne backup_verified blockiert Aktion
Nächste Korrektur: evidence_ref für backup hinzufügen und dry-run wiederholen

Kontrollfakt

Das Paket ist für die Prüfung geeignet, wenn ein anderer Leser capstone/README.md öffnen und fünf Fragen ohne Ihre Chat-Historie beantworten kann:

1. Welche Anforderung wurde wiederhergestellt und woher stammen die Beweise?
2. Welcher Defekt wurde eingeführt und wodurch wurde er behoben?
3. Welche Prüfung wurde tatsächlich ausgeführt?
4. Warum lautet der Verdikt der Dateiarbitrage oder der Bereitschaftsschleuse genau so?
5. Was bleibt vor Production ein Blocker?

Wenn für mindestens eine Frage ein mündlicher Kommentar des Autors nötig ist, ist das Paket noch nicht fertig.

Reviewbarer Trace

Übertragen Sie out/ aus runnable-Beispielen nicht in das Endpaket. Der finale Trace ist ein kurzer capstone/ mit Dateien, die die fünf Fragen oben beantworten. Wenn Sie in Ihrem Repository arbeiten, verfassen Sie genau dieses Beweispaket, nicht die lokalen Durchlaufverzeichnisse.

Schnelle Fragen

Beantworten Sie schriftlich, ohne Qwen Code.

1. Worin unterscheidet sich genealogy.md von validation.md?
2. Warum muss die kontrolliert defekte Spezifikation genau einen Defekt enthalten?
3. Wann kann eine Schattenspezifikation in QWEN.md, aber nicht in requirements.md gelangen?
4. Warum ersetzt Spec CI den Verifikator nicht?
5. Was muss judgment.md enthalten, damit der Streit wiederholt werden kann?

1. Warum darf manual_review_floor auch bei guten KPIs nicht auf Null gesetzt werden?
2. Was macht token_health nützlicher als eine einfache Zählung verbrauchter Tokens?
3. Warum ist ein Readiness-Score ohne evidence_ref keine Zulassung?
4. Wann ist DEFERRED besser als ein formales APPROVE?
5. Welcher Antipattern aus Teil 12 zerstört Ihr Paket am häufigsten?

Bewertungskriterien

Bewerten Sie das Paket mit 30 Punkten. Fünf Kategorien mit je 6 Punkten spiegeln fünf Stützen der Production-SDD wider: Provenienz des Fakts, seine Überprüfbarkeit, Streitschlichtung, Einhaltung von Begrenzern und Klarheit des Pakets. Gleiches Gewicht bedeutet, dass eine starke Kategorie eine schwache nicht ausgleicht, und innerhalb jeder Kategorie decken 6 Punkte typische blinde Zonen ab, ohne übermäßige Detaillierung.

Provenienz und Spezifikation — 6 Punkte

• 1: genealogy.md verbindet die Anforderung mit mindestens zwei Quellen;
• 1: strittige Fakten werden nicht als approved-Anforderungen ausgegeben;
• 1: poisoned/fixed-Paar enthält einen Defekt und eine Korrektur;
• 1: die Korrektur ändert ein überprüfbares Artefakt, nicht nur die Erklärung;
• 1: constitution.md trennt immutable- und mutable-Schichten;
• 1: mutable-Regel hat ttl, max_scope, rollback_condition.

Prüfungen und Fakten — 6 Punkte

• 1: mindestens ein runnable-Beispiel aus book2/examples/ wurde ausgeführt;
• 1: Ergebnis wurde mit Befehl und Erwartung in validation.md übertragen;
• 1: negatives oder blockierendes Szenario ist explizit beschrieben;
• 1: Spec CI oder sein Analog prüft die Verbindung von Anforderung und Plan;
• 1: Bereitschaft oder Probelauf (dry-run) umgehen keine blockierenden Bedingungen;
• 1: out/ wird nicht als reviewbares Artefakt ausgegeben.

Arbitrage und Rollen — 6 Punkte

• 1: judgment.md enthält Verdikt, Begründung und evidence_ref;
• 1: Rollen Verifikator/Implementor/Safety sind nicht vermischt, Koordinator führt nur judgment.md;
• 1: Gegenbeispiel ist minimal oder explizit als nicht minimal gekennzeichnet;
• 1: bei Streit gibt es DEFERRED oder einen nächsten überprüfbaren Schritt;
• 1: Präzedenzfall ist so aufgezeichnet, dass er erneut angewendet werden kann;
• 1: Safety-Veto oder sein Analog ist nicht durch Mehrheitsbeschluss zu umgehen.

Production-Begrenzer — 6 Punkte

• 1: Budgetszenario beschreibt den Ausfall der günstigen Ebene;
• 1: frontier-reviewer ist nach Risiko oder Kontingent begrenzt;
• 1: Anti-Goodhart-Paar verbindet KPI und Guard-Metrik;
• 1: manual_review_floor ist erhalten;
• 1: Readiness-Score wird von Beweisen begleitet;
• 1: Rollback oder Blocker ist vor der Zulassung angegeben.

Klarheit des Pakets — 6 Punkte

• 1: capstone/README.md erklärt den Fall ohne externen Chat;
• 1: Befehlsliste ist lokal wiederholbar oder durch runnable-Analog ersetzbar;
• 1: Blocker sind von Verbesserungen getrennt;
• 1: Verweise auf Kapitel und Vorlagen helfen, zur Quelle zurückzukehren;
• 1: diagnostische Checkliste aus Teil 12 wurde durchgegangen;
• 1: Paket enthält keine überflüssigen, nicht am gewählten Fall beteiligten Mechanismen.

25–30 Punkte — Production-SDD-Kontur ist bereit für Team-Review.

19–24 — Kontur ist für didaktischen Durchlauf geeignet, erfordert aber Verstärkung von Beweisen oder Blockern.

Unter 19 — kehren Sie zu den minimalen Szenarien der Kapitel 1–12 zurück und verkleinern Sie den Fall.

Was nach der Prüfung zu tun ist

Übertragen Sie nicht das gesamte Paket als Vorlage in Production. Wählen Sie zwei bis drei der nützlichsten Artefakte und automatisieren Sie diese zuerst:

• wenn häufiger die Herkunft von Anforderungen verloren geht — beginnen Sie mit genealogy.md;
• wenn CI schwache Spezifikationen durchlässt — beginnen Sie mit Spec CI;
• wenn Streitigkeiten sich wiederholen — beginnen Sie mit judgment.md und precedents.md;
• wenn KPIs anfangen zu lügen — beginnen Sie mit anti-Goodhart validation.md.

Das Hauptergebnis des zweiten Bands ist nicht eine Sammlung von Begriffen, sondern die Gewohnheit, einen überprüfbaren Trace vor der Zulassung einer gefährlichen automatischen Aktion zu fordern.