Anhang C. Checklisten für angewandtes SDD

Dieser Anhang kann während des angewandten Zyklus als schnelles Nachschlagewerk verwendet werden. Er baut auf Anhang C des ersten Bandes auf: Die grundlegenden Checklisten vor Spezifikation, Implementierung und Zusammenführung werden dort nicht dupliziert. Die Prozessvorlagen (Zusammenführungsanfrage, Retrospektive, minimale Anfragen für /clear und Umplanung) wurden nach [examples/templates/](examples/templates/) verschoben: pr-template.md, retrospective.md, clear-prompt.md, replan-prompt.md.

Vor Beginn des angewandten Bandes

• [ ] Teil 0 wurde gelesen, ein Lern-Incident-Case wurde ausgewählt.
• [ ] Es ist klar, welche Befehle in den Kapiteln den Status [runnable] haben und welche als [project script] gekennzeichnet sind.
• [ ] Das Verzeichnis capstone/ für das Abschlusspaket wurde erstellt oder geplant.
• [ ] Aus dem ersten Band sind requirements.md, plan.md, validation.md, QWEN.md und das Evidenzpaket verstanden.
• [ ] Der Lesemodus wurde gewählt: Lernminimum oder vollständiger Produktions-Track.

Vor der Wiederherstellung der Spezifikation aus einem Legacy-System

• [ ] Alle Quellen sind mit Eigentümer und Verweis aufgeführt.
• [ ] Die Ereigniszeit ist normalisiert.

• [ ] Anforderungen sind vom Hintergrundkontext getrennt.
• [ ] Jede Aussage hat eine Evidenz oder ist als Hypothese gekennzeichnet.
• [ ] Umstrittene Punkte sind nicht in den genehmigten Vertrag aufgenommen worden.

Vor dem Start der vergifteten Spezifikation

• [ ] Genau ein Defekt wurde eingebracht.
• [ ] Das erwartete Fehlersymptom ist beschrieben.
• [ ] Es gibt ein Wiederherstellungskriterium.
• [ ] Die Korrektur muss spec/plan/validation ändern, nicht nur die Erklärung.

Vor der Aktivierung des Spezifikations-Gateways (Spec CI)

• [ ] Anforderungen haben stabile REQ-*-Identifikatoren.
• [ ] Planpunkte verweisen auf Anforderungen.
• [ ] Die Abdeckungsprüfung stützt sich auf das Domänenmodell oder den API-Vertrag.
• [ ] JSON-Beispiele aus validation.md werden durch das Schema validiert.
• [ ] Der CI-Fehler enthält Datei, Zeile, Regel, Grund und Aktion.

Vor der Datei-Schlichtung einer umstrittenen Änderung

• [ ] Die Rollen Koordinator, Implementierer und Verifizierer sind im Voraus beschrieben.
• [ ] Der Verifizierer akzeptiert nur überprüfbare Evidenzen.
• [ ] Der Streit wird durch Unterschiede (Diffs) in Dateien beigelegt, nicht durch Argumente im Chat.
• [ ] Wiederkehrende Entscheidungen werden in precedents.md aufgenommen.
• [ ] Es gibt eine Stopp-Bedingung für die manuelle Überprüfung.

Vor der Optimierung von Produktionsmetriken

• [ ] Die Zielmetrik ist von Qualitätsinvarianten getrennt.
• [ ] Es gibt eine Notfallregel für das Goodhart-Szenario.
• [ ] Das Replay überprüft nicht nur Aggregate, sondern auch Verhaltensdrift.
• [ ] Die Spur enthält die Quelle der Entscheidung, die Version der Policy, den Hash des Hinweises oder eine andere reproduzierbare Kennung.
• [ ] Eine Schwellenwertänderung wird als Risikoänderung behandelt, nicht als kosmetische YAML-Korrektur.

Vor der automatischen Behebung

• [ ] Der Auswirkungsradius ist bekannt.
• [ ] Es gibt einen Probelauf (Dry-Run) oder eine sichere Vorabprüfung.
• [ ] Die Rückrollbedingung ist vor der Ausführung dokumentiert.
• [ ] Eine manuelle Bestätigung wird bei Ungewissheit, wiederholtem Fehlschlag oder Erweiterung des Auswirkungsradius aktiviert.
• [ ] Der Vorfall wird nicht geschlossen, bis bei hohem Risiko zwei unabhängige Wiederherstellungsbestätigungen vorliegen.

Vor dem Audit von Anti-Mustern des angewandten Zyklus

Die vollständige Analyse der Symptome und Ursachen befindet sich in Teil 12. Hier sind 12 Fragen als schnelle Checkliste.

• [ ] constitution.md wirkt als Gateway vor der Ausführung, nicht nur als nachträgliche Überprüfung.
• [ ] In mutable_rules gibt es keine Regeln ohne ttl oder mit einer ttl von mehr als 90 Tagen.

• [ ] Nach dem Fehlschlag der vergifteten Spezifikation wird mindestens ein Artefakt (requirements.md, plan.md, validation.md) geändert, nicht nur die Erklärung.
• [ ] Der Verifizierer verwendet ein Gegenbeispiel, ein Hook-Log oder ein JSON-Schema — keinen freien Text.
• [ ] In governance_protocol gibt es ein Veto von Safety und einen deterministischen Tie-Breaker.
• [ ] Ausführbare Befehle ([runnable]) sind explizit von [project script]-Schnittstellen getrennt.
• [ ] Jeder Zielmetrik ist eine Anti-Goodhart-Partner-Metrik zugeordnet.
• [ ] Wenn die CI fehlschlägt, wird der Code repariert, nicht validation.md abgeschwächt.
• [ ] Für den Ebenenwechsel gibt es ein Budgetlimit und einen Notfallmodus.
• [ ] Jeder Eintrag in QWEN.md hat einen Autor, eine Evidenz und eine ttl.
• [ ] manual_review_floor wird unabhängig vom KPI-Wert beibehalten.
• [ ] Das Feld evidence_ref ist in jedem Spureintrag ausgefüllt.

Wenn drei oder mehr Punkte mit Nein beantwortet werden, fügen Sie keine neuen Automatisierungsschichten hinzu; schließen Sie zuerst die Lücken im aktuellen Regelkreis.

Vor der abschließenden Produktionsprüfung

• [ ] capstone/README.md erklärt den Fall ohne Chat-Verlauf.
• [ ] genealogy.md enthält Anforderung, Quellen, Konfidenzniveau und offene Frage.

• [ ] Das Poisoned/Fixed-Paar enthält einen Defekt und eine überprüfbare Korrektur.
• [ ] validation.md verweist auf mindestens ein tatsächlich ausgeführtes Runnable-Beispiel oder sein Projekt-Äquivalent.
• [ ] judgment.md enthält Urteil, Grund, evidence_ref und nächsten Schritt.
• [ ] Die Budget- und Anti-Goodhart-Schichten haben jeweils mindestens eine blockierende Invariante.
• [ ] Die Readiness-Aussage trennt Blocker von Verbesserungen.
• [ ] Die Diagnose-Checkliste aus Teil 12 ist durchgearbeitet, negative Antworten haben einen Eigentümer und eine nächste Kontrolle.