Anhang C. Checklisten für angewandtes SDD

Dieser Anhang kann als Kurzreferenz während des angewandten Zyklus verwendet werden. Er baut auf Anhang C des ersten Bandes auf: Grundlegende Checklisten vor Spezifikation, Implementierung und Zusammenführung werden dort nicht dupliziert. Prozessvorlagen (Merge-Anfrage, Retrospektive, Minimalanfragen für /clear und Neuplanung) 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 gelesen, ein Lehr-Incident-Case ausgewählt.
• [ ] Verständnis, welche Befehle in den Kapiteln den Status [runnable] haben und welche als [project script] markiert sind.
• [ ] Verzeichnis capstone/ für das abschließende Paket erstellt oder geplant.
• [ ] Aus dem ersten Band verständlich: requirements.md, plan.md, validation.md, QWEN.md und das Beweispaket.
• [ ] Lesemodus gewählt: Lehrminimum oder vollständiger Production-Track.

Vor der Wiederherstellung der Spezifikation aus einem Altsystem

• [ ] Alle Quellen mit Eigentümer und Verweis aufgelistet.
• [ ] Ereigniszeit normalisiert.

• [ ] Anforderungen vom Hintergrundkontext getrennt.
• [ ] Jede Behauptung hat einen Beweis oder ist als Hypothese markiert.
• [ ] Streitige Punkte sind nicht in den genehmigten Vertrag gelangt.

Vor dem Start einer vergifteten Spezifikation

• [ ] Genau ein Defekt eingefügt.
• [ ] Erwartetes Fehlersymptom beschrieben.
• [ ] Wiederherstellungskriterium vorhanden.
• [ ] Die Korrektur muss spec/plan/validation ändern, nicht nur die Erklärung.

Vor der Aktivierung der Spezifikations-Gate (Spec CI)

• [ ] Anforderungen haben stabile REQ-*-Kennungen.
• [ ] Planpunkte verweisen auf Anforderungen.
• [ ] Abdeckungsprüfung stützt sich auf Domänenmodell oder API-Vertrag.
• [ ] JSON-Beispiele aus validation.md werden durch Schema validiert.
• [ ] CI-Fehler enthält Datei, Zeile, Regel, Ursache und Maßnahme.

Vor der Dateischiedung einer umstrittenen Änderung

• [ ] Rollen Koordinator, Implementierer und Verifizierer im Voraus beschrieben.
• [ ] Verifizierer akzeptiert nur überprüfbare Beweise.
• [ ] Streit wird durch Unterschiede (diff) in Dateien gelöst, nicht durch Argumente im Chat.
• [ ] Wiederkehrende Entscheidungen gelangen in precedents.md.
• [ ] Stoppbedingung für manuelles Review vorhanden.

Vor der Optimierung von Produktionsmetriken

• [ ] Zielmetrik von Qualitätsinvarianten getrennt.
• [ ] Regel für den Notfall-Knopf im Goodhart-Szenario vorhanden.
• [ ] Replay prüft nicht nur Aggregate, sondern auch Verhaltensdrift.
• [ ] Spur enthält Quelle der Entscheidung, Version der Richtlinie, Hash des Prompts oder einen anderen reproduzierbaren Identifikator.
• [ ] Schwellenwertänderung wird als Risikoänderung behandelt, nicht als kosmetische YAML-Korrektur.

Vor der Auto-Remediation

• [ ] Auswirkungsradius bekannt.
• [ ] Probelauf (dry-run) oder sichere Vorabprüfung vorhanden.
• [ ] Rollback-Bedingung vor Ausführung dokumentiert.
• [ ] Manuelle Bestätigung bei Unsicherheit, wiederholtem Fehlschlag oder Ausweitung des Auswirkungsradius eingeschaltet.
• [ ] Vorfall wird bei hohem Risiko nicht vor zwei unabhängigen Wiederherstellungsbestätigungen geschlossen.

Vor dem Audit von Anti-Patterns des angewandten Zyklus

Vollständige Analyse von Symptomen und Ursachen in Teil 12. Hier — 12 Fragen als Kurzcheckliste.

• [ ] constitution.md fungiert als Gate vor der Ausführung, nicht nur als Review danach.
• [ ] In mutable_rules gibt es keine Regeln ohne ttl oder mit ttl über 90 Tagen.

• [ ] Nach dem Scheitern einer vergifteten Spezifikation ändert sich mindestens ein Artefakt (requirements.md, plan.md, validation.md), nicht nur die Erklärung.
• [ ] Verifizierer verwendet Gegenbeispiel, Log-Hook oder JSON Schema — keinen Freitext.
• [ ] In governance_protocol gibt es Veto von Safety und deterministischen Tie-Breaker.
• [ ] Ausführbare Befehle ([runnable]) sind explizit von [project script]-Schnittstellen getrennt.
• [ ] Jeder Zielmetrik ist eine gepaarte Anti-Goodhart-Metrik zugeordnet.
• [ ] Wenn CI fehlschlägt, wird Code repariert, nicht validation.md abgeschwächt.
• [ ] Für den Wechsel zwischen Ebenen gibt es eine Budgetobergrenze und einen Notfallmodus.
• [ ] Jeder Eintrag in QWEN.md hat einen Autor, einen Beweis und ein ttl.
• [ ] manual_review_floor bleibt unabhängig vom KPI-Wert erhalten.
• [ ] Feld evidence_ref ist in jedem Spureneintrag ausgefüllt.

Bei drei oder mehr verneinten Punkten — keine neuen Automatisierungsschichten hinzufügen; zuerst die Lücken im aktuellen Kreislauf schließen.

Vor der abschließenden Production-Prüfung

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

• [ ] 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 dessen projektbezogenes Analogon.
• [ ] judgment.md enthält Urteil, Begründung, evidence_ref und nächsten Schritt.
• [ ] Budget- und Anti-Goodhart-Ebenen haben jeweils mindestens eine blockierende Invariante.
• [ ] Readiness-Ausgabe trennt Blocker von Verbesserungen.
• [ ] Diagnosecheckliste von Teil 12 durchlaufen, verneinte Antworten haben einen Eigentümer und nächste Kontrolle.