Anwendungsteil 13. Praktische Prüfung: einen produktionsreifen SDD-Ablauf zusammenbauen

Status: Empfehlung. Dieser Teil führt keinen neuen Mechanismus ein. Er fasst den zweiten Band in einer überprüfbaren Route nach dem Vorbild der praktischen Prüfung des ersten Bandes zusammen. Das Ziel ist zu beweisen, dass Sie ein Produktions-SDD-Szenario vom Legacy-Stand bis zu einer Entscheidung durchlaufen können, die durch Fakten und nicht durch das Selbstbewusstsein eines Agenten zugelassen wird.

Die Prüfung sollte am besten nach den Kapiteln 1–12 durchgeführt werden. Wenn Sie den Band punktuell lesen, nutzen Sie diesen Teil als Karte der fehlenden Artefakte: Jede Lücke im capstone/-Paket zeigt, zu welchem Kapitel Sie zurückkehren müssen. Wenn unklar ist, wie die Dateien zu einem Fall verknüpft werden, kehren Sie zu Teil 0 zurück: Er legt den Laborrahmen AgentClinic-production fest und erklärt, was als pädagogisches Minimum gilt.

Ziel

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

• eine wiederhergestellte Anforderung mit Provenienz;
• eine kontrolliert defekte Spezifikation, die repariert wurde;
• eine constitution.md mit unveränderlichen und veränderlichen Regeln;
• mindestens ein Gegenbeispiel und einen Duell-Eintrag;
• eine lokale Spec CI oder deren lauffähiges Äquivalent;

• eine judgment.md oder einen Präzedenz-Eintrag;
• eine Budget- und Anti-Goodhart-Kontrolle;
• ein Readiness-Gate und eine Liste von Blockern;
• eine diagnostische Checkliste für Antimuster.

Die Prüfung gilt als bestanden, wenn die Dateien nicht nur vollständig aussehen, sondern wenn eine andere Person das Paket öffnen, die Schlüsselprüfungen wiederholen und verstehen kann, warum die Entscheidung sicher zugelassen werden kann oder warum sie verschoben werden muss.

Abschlussfall

Arbeiten Sie mit einem Produktionsvorfall. Der empfohlene Hauptfall ist high_memory_usage, da er die Webhook-Normalisierung, das Readiness-Gate und den Probelauf aus Teil 11 durchläuft. autoscale_200pct kann stattdessen gewählt werden, wenn Sie die Prüfung um ein Duell und Datei-Schiedsverfahren herum aufbauen. Mischen Sie nicht zwei Fälle in einer Prüfung.

Minimale Aufgabenstellung:

• AgentClinic-production hat einen Alert von Grafana oder PagerDuty erhalten;
• Legacy-Spuren sind unvollständig: Einige Regeln sind aus dem Post-Mortem bekannt, einige aus QWEN.md, einige aus mündlicher Praxis;
• eine automatische Behebung erscheint nützlich, kann jedoch das Konsequenzradius-Limit, das Stufenbudget oder die Anti-Goodhart-Invariante verletzen;
• vor der Zulassung muss bewiesen werden, dass Spezifikation, Plan, Prüfung und Readiness einander nicht widersprechen.

Struktur des Pakets

Erstellen Sie das 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 in einem realen Projekt arbeiten, können die Namen angepasst werden. Die Rollen der Dateien müssen jedoch gleich bleiben: Herkunft, Defekt, Korrektur, Regeln, Fakten, Schiedsverfahren, Budget, Metriken, Bereitschaft und Prozess-Audit.

Bevor Sie Ihr Paket füllen, öffnen Sie [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md). Dies ist der Referenz-"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 Produktionsdokument zu verwandeln.

Verwenden Sie ihn als Größenbegrenzer. Wenn Ihre capstone/README.md oder validation.md merklich länger als die Referenz ausfällt, prüfen Sie zuerst, ob Artefakte des vollständigen Tracks hineingeraten sind: scorebook, metric_network, die vollständige out/duel.json, der gesamte Budgetplan oder eine ausführliche Chat-Historie.

Suchen Sie in den Kapiteln 1–12 den Block „Wie dies in capstone/ gelangt". Er ist beim ersten Durchgang wichtiger als die vollständige Artefaktliste des Kapitels. Wenn der Block sagt, eine Zeile, einen akzeptierten Kandidaten, eine Schutzinvariante oder ein Readiness-Urteil zu übernehmen, erweitern Sie das Evidenzpaket nicht auf alle Dateien des vollständigen Produktions-Tracks.

Notieren Sie vor dem Beginn in capstone/README.md fünf Platzhalterzeilen:

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

Für die Standardroute muss 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 Lernszenario

Lernfall

Nehmen Sie high_memory_usage aus [examples/real-api/](examples/real-api/) als Standardroute. 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 perfekten Produktionsprozess, sondern ein kleines reproduzierbares Evidenzpaket zusammenzubauen: ein Vorfall, ein Spezifikationsdefekt, ein Gegenbeispiel oder ein Readiness-Befund, eine Blocker-Liste.

Vorbereitung

• Lesen Sie die README des gewählten lauffähigen Beispiels.
• Kopieren Sie die benötigten Vorlagen aus [examples/templates/](examples/templates/).
• Erstellen Sie ein leeres Verzeichnis capstone/.
• Legen Sie vorab fest, was als Blocker gilt: schwache evidence_ref, Prioritätskonflikt, Verletzung von manual_review_floor, Budgetüberschreitung oder Readiness unterhalb des Schwellenwerts.

Schritte

1. Füllen Sie capstone/genealogy.md: eine wiederhergestellte Anforderung, mindestens zwei Quellen, Konfidenzniveau und offene Frage.
2. Erstellen Sie capstone/poisoned-spec.md: führen Sie genau einen Defekt ein – Prioritätskonflikt, Zyklus oder versteckte Grenzüberschreitung.

1. Erstellen Sie capstone/fixed-spec.md: beheben Sie den Defekt durch eine Ausnahmeregel, ein Schema oder eine explizite Negativanforderung.
2. Füllen Sie capstone/constitution.md: mindestens zwei immutable_principles, eine mutable_rule mit ttl, max_scope, rollback_condition und ein kurzes governance_protocol.
3. Führen Sie ein lauffähiges Beispiel für den gewählten Fall aus.

• Für high_memory_usage – die Befehle aus dem Abschnitt „Minimales Lernszenario" von Teil 11: ein positiver Readiness, ein blockierender Stateful, ein erlaubter und ein verbotener Dry-Run. Befehle mit readiness_block_stateful.json und delete_namespace erwarten Rückgabewert 1 – dies ist kein Defekt des Beispiels, sondern die Quelle der Blocker für capstone/validation.md.
• Für autoscale_200pct – drei Skripte aus dem Abschnitt „Minimales Lernszenario" von Teil 8: run_duel.py, check_invariants.py, write_judgment.py.

Die Befehle werden hier nicht vollständig dupliziert, damit die Prüfung nicht zum Copy-Paste wird. Wenn Sie beide Kapitel geöffnet haben, folgen Sie deren Schritten in derselben Reihenfolge.

1. Übertragen Sie das Ergebnis in capstone/validation.md: Befehl, erwarteter Fakt, tatsächliches Ergebnis und Zulassungs-Blocker. Für real-api zeigt der positive Readiness-Lauf den zulässigen Pfad, readiness_block_stateful.json liefert einen Stateful-Blocker, und delete_namespace zeigt die Grenze der im Voraus vereinbarten Aktionen. Wenn der Befehl aus einem anderen lauffähigen Verzeichnis stammt, erklären Sie, welches Prinzip auf den Hauptfall übertragen wird.
2. Füllen Sie capstone/judgment.md: Urteil APPROVE, DENY oder DEFERRED, Begründung, evidence_ref, nächster Schritt. judgment.md ist der Entscheidungseintrag 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 passiert bei Ausfall von local-coder, welches Limit schützt frontier-reviewer, wann greift der Notfallmodus.
4. Fügen Sie capstone/goodhart-note.md hinzu: Welche Zielmetrik kann zu lügen beginnen und welche Schutzmetrik begrenzt sie.

1. Füllen Sie capstone/readiness.md: abschließende Bewertung, blockierende Bedingungen, warum 23/25 mit Belegen besser ist als 25/25 ohne sie.
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, Liste der Befehle, abschließender Status und Liste der Korrekturen vor der Produktion.

Lesen Sie nach Schritt 12 capstone/README.md als neuer Reviewer erneut. Darin sollten nicht alle Details sichtbar sein, sondern der Prüfpfad: woher die Anforderung stammt, was defekt war, welcher Befehl ausgeführt wurde, welches Urteil herauskam und was die Produktionszulassung blockiert.

Eine minimale capstone/README.md für den ersten Durchgang passt in fünf Zeilen:

Incident-case: high_memory_usage
Hauptrisiko: Auto-Remediation ohne vollständige audit_trace oder Backup-Evidenz
Schlüsselprüfung: python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json
Hauptblocker: Stateful-Workload ohne backup_verified blockiert die Aktion
Nächste Korrektur: evidence_ref für Backup hinzufügen und Dry-Run wiederholen

Kontrollfakt

Das Paket ist prüfungstauglich, wenn ein anderer Leser capstone/README.md öffnen und die fünf Fragen ohne den Verlauf Ihres Chats beantworten kann:

1. Welche Anforderung wurde wiederhergestellt und woher stammen die Belege?
2. Welcher Defekt wurde eingeführt und womit wurde er behoben?
3. Welche Prüfung wurde tatsächlich ausgeführt?
4. Warum lautet das Urteil des Datei-Schiedsverfahrens oder des Readiness-Gate genau so?
5. Was bleibt vor der Produktion ein Blocker?

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

Prüfbare Spur

out/ aus den lauffähigen Beispielen wird nicht in das Abschlusspaket übernommen. Die endgültige Spur ist ein kurzes capstone/ mit Dateien, die die fünf oben genannten Fragen beantworten. Wenn Sie in Ihrem eigenen Repository arbeiten, halten Sie genau dieses Evidenzpaket fest, nicht die lokalen Laufverzeichnisse.

Schnellfragen

Beantworten Sie schriftlich, ohne Qwen Code.

1. Worin unterscheidet sich genealogy.md von validation.md?
2. Warum sollte eine kontrolliert defekte Spezifikation genau einen Defekt enthalten?
3. Wann kann eine Schattenspezifikation in QWEN.md landen, aber nicht in requirements.md?
4. Warum ersetzt Spec CI den Verifier 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 formelles APPROVE?
5. Welches Antimuster 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 die fünf Pfeiler des Produktions-SDD: Faktprovenienz, Überprüfbarkeit, Streitbeilegung, Einhaltung der Begrenzer und Klarheit des Pakets. Gleiches Gewicht bedeutet, dass eine starke Kategorie eine schwache nicht ausgleicht, und innerhalb jeder Kategorie decken die 6 Punkte typische blinde Flecken ab, ohne zu tief ins Detail zu gehen.

Provenienz und Spezifikation – 6 Punkte

• 1: genealogy.md verknüpft die Anforderung mit mindestens zwei Quellen;
• 1: strittige Fakten werden nicht als genehmigte Anforderungen ausgegeben;
• 1: das Paar poisoned/fixed enthält einen Defekt und eine Korrektur;
• 1: die Korrektur verändert ein prüfbares Artefakt, nicht nur die Erklärung;
• 1: constitution.md trennt unveränderliche und veränderliche Schichten;
• 1: die veränderliche Regel hat ttl, max_scope, rollback_condition.

Prüfungen und Fakten – 6 Punkte

• 1: mindestens ein lauffähiges Beispiel aus book2/examples/ wurde ausgeführt;
• 1: das Ergebnis wurde mit Befehl und Erwartung in validation.md übertragen;
• 1: ein negatives oder blockierendes Szenario ist explizit beschrieben;
• 1: Spec CI oder ein Äquivalent prüft die Verbindung zwischen Anforderung und Plan;
• 1: Readiness oder Dry-Run umgehen keine blockierenden Bedingungen;
• 1: out/ wird nicht als prüfbares Artefakt ausgegeben.

Schiedsverfahren und Rollen – 6 Punkte

• 1: judgment.md enthält Urteil, Begründung und evidence_ref;
• 1: die Rollen Verifier/Implementor/Safety sind nicht vermischt, der Koordinator führt nur judgment.md;
• 1: das Gegenbeispiel ist minimal oder explizit als nicht minimal gekennzeichnet;
• 1: bei einem Streit gibt es DEFERRED oder einen nächsten prüfbaren Schritt;
• 1: der Präzedenzfall ist so notiert, dass er erneut angewendet werden kann;
• 1: ein Safety-Veto oder sein Äquivalent darf nicht durch Mehrheitsentscheid umgangen werden.

Produktions-Begrenzer – 6 Punkte

• 1: das Budget-Szenario beschreibt den Ausfall der günstigen Stufe;
• 1: frontier-reviewer ist nach Risiko oder Kontingent begrenzt;
• 1: das Anti-Goodhart-Paar verknüpft KPI und Schutzmetrik;
• 1: manual_review_floor ist erhalten;
• 1: der Readiness-Score wird von Belegen begleitet;
• 1: ein 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: die Befehlsliste ist lokal wiederholbar oder durch einen Verweis auf ein lauffähiges Äquivalent ersetzbar;
• 1: Blocker sind von Verbesserungen getrennt;
• 1: Verweise auf Kapitel und Vorlagen helfen, zur Quelle zurückzukehren;
• 1: die diagnostische Checkliste aus Teil 12 ist durchgegangen;
• 1: das Paket enthält keine überflüssigen Mechanismen, die nicht mit dem gewählten Fall zusammenhängen.

25–30 Punkte – der Produktions-SDD-Ablauf ist bereit für das Team-Review.

19–24 – der Ablauf ist für den Lerndurchgang geeignet, erfordert aber stärkere Belege oder Blocker.

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 Ganzes als Vorlage in die Produktion. Wählen Sie zwei bis drei der nützlichsten Artefakte aus und automatisieren Sie diese zuerst:

• wenn die Anforderungsherkunft am häufigsten verloren geht – beginnen Sie mit genealogy.md;
• wenn die CI schwache Spezifikationen durchlässt – beginnen Sie mit Spec CI;
• wenn sich Streitfälle wiederholen – beginnen Sie mit judgment.md und precedents.md;
• wenn KPIs zu lügen beginnen – beginnen Sie mit Anti-Goodhart validation.md.

Das Hauptergebnis des zweiten Bandes ist nicht ein Satz von Begriffen, sondern die Gewohnheit, eine überprüfbare Spur vor der Zulassung einer gefährlichen automatischen Aktion zu verlangen.