Anwendungsteil 12. Anti-Patterns für Production SDD: Diagnosekarte des Anwendungszyklus

Status: Empfehlung. Dieser Teil sammelt Anti-Patterns, die genau im Anwendungszyklus auftreten: bei Duellen, Datei-Schiedsgerichten, Spec CI, stufigen Budgets, Anti-Goodhart-Metriken und Auto-Remediation. Sie setzen die Linie aus Teil 20 des ersten Bandes fort: Artefakte existieren, Prüfungen existieren, der Agent arbeitet schnell, aber die Kontrolle über das System geht allmählich verloren.

Dieser Teil dient als Diagnosekarte für den Anwendungsband. Wenn der Production-Kontur laut, widersprüchlich geworden ist oder seine eigene Geschwindigkeit zulasten des Benutzers schützt, fangen Sie hier an.

Vor dem Lesen

• Bezug aus dem ersten Band: Teil 20 zeigt grundlegende SDD-Anti-Patterns.
• Lokaler Lernfall: Ein bereits erstelltes Artefakt aus den Kapiteln 8–11.
• Spur für capstone/: Drei Zeilen blocker / owner / next_check für das ausgewählte high_memory_usage-Paket.
• Hauptbegriff des ersten Durchgangs: Diagnose-Blocker. Die Namen einzelner Anti-Patterns sind referenzartig, sie müssen nicht nacheinander gelesen werden.
• Was zurückgestellt werden soll: Die Umwandlung jedes Anti-Patterns in eine automatische CI-Richtlinie.

Ziel

Das Ziel des Kapitels ist es, nicht eine Liste von Namen auswendig zu lernen, sondern einen kurzen Audit eines bereits zusammengestellten Production SDD-Pakets durchzuführen. Nach dem Kapitel sollten Sie drei Diagnosezeilen haben: Was blockiert die Freigabe, wer ist für die Korrektur verantwortlich und wann wird dies erneut geprüft.

Für den ersten Durchgang lesen Sie dieses Kapitel als Checkliste, nicht als Lexikon aller möglichen Ausfälle. Der untenstehende Katalog dient dazu, das gefundene Problem zu erkennen; das Kapitel kann mit drei Zeilen blocker / owner / next_check abgeschlossen werden.

Eskalationen von Anti-Patterns des ersten Bandes

Ein Teil der Anti-Patterns dieses Katalogs sind keine neuen, sondern Production-Varianten derjenigen, die in Teil 20 des ersten Bandes beschrieben sind. Der Unterschied liegt im Maßstab: Im Lernzyklus verbrennt ein grundlegendes Anti-Patterns einen Arbeitstag, im Anwendungszyklus eröffnet es eine Klasse von Vorfällen auf einem Live-Service.

| Schattenspezifikation ohne Überprüfungsfrist | „QWEN.md als Müllhalde" — Gedächtnis ohne ttl und Autor | | Spur ohne Nachweis-Markierung | „Fakten aufs Wort" — Fehlen von evidence_ref |

Wenn Sie Teil 20 des ersten Bandes durchlaufen haben, können diese Einträge selektiv gelesen werden — hier steht nur das, was den Production-Kontext hinzufügt. Die anderen 12 Anti-Patterns dieses Kapitels treten nur im Anwendungszyklus auf (Duelle, Schiedsgericht, Budgets, Anti-Goodhart, Auto-Remediation) und werden in Band 1 nicht behandelt.

Minimaler Lernszenario

Lernfall

Vor der Abschlussprüfung muss ein Production SDD-Kontur auf Rauschen geprüft werden. Wählen Sie ein beliebiges Paket aus den Kapiteln 8–11: judgment.md, validation.md, budget_network.yaml oder die Readiness-Tabelle. Ziel ist es, mindestens drei Anti-Patterns zu finden oder explizit nachzuweisen, dass es keine gibt.

Vorbereitung

• Diagnose-Checkliste unten.
• book2/examples/templates/retrospective.md — Formular für eine kurze Aufzeichnung des Ergebnisses.
• Ein Artefakt, das bereits durch ein ausführbares Beispiel oder ein manuelles Lernszenario gegangen ist.

Schritte

1. Wählen Sie ein Artefakt und erweitern Sie den Prüfungsbereich nicht. Erwartung: Der Audit dauert 15–30 Minuten und verwandelt sich nicht in ein Review des gesamten Projekts.

1. Beantworten Sie die 12 Fragen der Checkliste. *Erwartung: Jede Antwort ist yes, no oder not_applicable mit kurzer Dateireferenz.*
2. Geben Sie für jedes no das Anti-Pattern, den Eigentümer und den Korrekturtermin an.
3. Finden Sie mindestens einen [project script] im ausgewählten Kapitel und prüfen Sie, ob er als ausführbares Analogon oder als Schnittstelle „implementieren Sie selbst" markiert ist.
4. Zeichnen Sie das Ergebnis in antipattern-audit.md oder in die Retrospektive auf: Was blockiert die Production-Freigabe, was kann als Verbesserung verbleiben.

Kontrollfakt

Es gibt eine Liste aus drei Punkten: blocker, owner, next_check. Wenn negative Antworten nur in allgemeine Ratschläge umgewandelt werden, hat die Diagnosekarte ihre Funktion nicht erfüllt.

Wie es in capstone/ gelangt

Übertragen Sie in capstone/antipattern-audit.md drei Zeilen blocker / owner / next_check. Beheben Sie diese Probleme nicht in derselben Datei ohne separate Aufzeichnung: Für die Prüfung ist wichtig, die Diagnose und die nächste Kontrolle zu sehen, nicht ein schönes Ergebnis ohne Historie.

Minimaler Fragment:

| blocker | owner | next_check |
|---|---|---|
| readiness ohne `evidence_ref` | platform | dry-run mit Fixture-Referenz wiederholen |

| `[project script]` ohne ausführbares Analogon | devex | durch `examples/real-api` ersetzen oder Skript implementieren |
| `manual_review_floor` nicht angegeben | sre | Guard-Metrik vor Auto-Modus hinzufügen |

Reviewbare Spur

Bewahren Sie antipattern-audit.md auf, wenn sich der Audit auf das Lernpaket oder capstone/ bezieht. Beheben Sie gefundene Probleme nicht in derselben Änderung ohne separate Aufzeichnung: Zuerst muss die Diagnose sichtbar sein, dann die Behandlung.

Schlüsselideen

Jedes Anti-Pattern unten wird nach einem Schema aus drei Feldern analysiert: Symptom — was in Artefakten und Logs beobachtet wird, Warum schlecht — wie dies das Verhalten des Teams oder des Agents verändert, Wie korrigieren — minimale Schritte bis zu einem Zustand, in dem das Symptom automatisch erkannt wird.

Der Katalog kann in beliebiger Reihenfolge gelesen werden: Jeder Eintrag ist eigenständig und hält sich an dieselben drei Felder. Die Einträge sind nicht alternativ — es sind verschiedene Klassen von Rauschen, die oft zusammen auftreten. Wenn in einem Production-Paket drei und mehr Anti-Patterns gefunden werden, lesen Sie sie als vernetztes Problemfeld mit gemeinsamer Wurzel im verlorenen Risikovertrag.

Beispiele und Anwendung

Verfassung als Kosmetik

> Eskalation des Anti-Patterns aus Band 1. Die Basisversion ist „Verfassung, die niemand öffnet" aus Teil 20 des ersten Bandes. Im Anwendungszyklus führt derselbe Fehler nicht zu schlechtem Code, sondern zur Ausführung einer gefährlichen Operation.

Symptom: Im Repository gibt es constitution.md mit immutable_principles und mutable_rules, aber das Gateway vor gefährlichen Aktionen wird nicht gestartet. In judgment.md gibt es eine Referenz auf die Regel forbid_unscoped_delete, in den Team-Logs (logs/auto-remediation.jsonl) gibt es keinen einzigen Aufruf von scripts/constitution/check.py. In den letzten 30 Tagen — null Gateway-Auslösungen.

Warum schlecht: Die Regeln existieren formal, beschränken den Agent aber nicht im Moment des Drucks. Nach mehreren Vorfällen beginnt das Team, die Verfassung als Dekoration zu betrachten. Bei der Analyse des nächsten Vorfalls taucht die charakteristische Phrase auf: „Die Regel war ja da, nur hat sie niemand geprüft" — das ist das Signal, dass die Verfassung als Kommentar und nicht als Vertrag funktionierte.

Wie korrigieren:

• constitution.md an Gateway-Prüfungen vor der Playbook-Ausführung anbinden (siehe Teil 3);
• Jede gefährliche Operation durch scripts/constitution/check.py oder CI-Äquivalent leiten;

• In judgment.md die Referenz auf die Verfassungsversion und decision_hash festhalten;
• Wenn eine Regel nicht automatisch geprüft wird, aus immutable_principles in ein Playbook verschieben und explizit als „Anweisung, kein Gateway" markieren;
• Prüfen, dass es in den letzten 30 Tagen mindestens ein Log gibt, in dem das Gateway ausgelöst und die Aktion blockiert hat. Null Auslösungen pro Quartal — entweder ist die Verfassung nicht angebunden oder sie beschreibt nichtexistente Risiken.

Mutable-Regel mit ttl: ∞

Symptom: In mutable_rules gibt es eine Regel ohne ttl, oder ttl steht sofort auf Jahre. rollback_condition fehlt oder ist formuliert als „nach Teamentscheidung".

Warum schlecht: Die Regel lebt unbefristet und wird mit der Zeit zu einem versteckten Teil des Invariants. Nach einem Jahr erinnern sich die Teilnehmer nicht mehr, warum sie eingeführt wurde, und fürchten sich, sie anzufassen. Änderungen werden per Analogie auf Situationen angewendet, für die sie nicht gedacht waren.

Wie korrigieren:

• ttl in Tagen, nicht Jahren angeben; erste Überprüfung — 30–90 Tage (siehe Referenzantwort in INSTRUCTOR.md);
• rollback_condition als prüfbares Prädikat formulieren: repeat_incidents_same_node>=2, silent_p0_ratio>0.05, safety_veto=true;

• Nach Ablauf des ttl die Anwendung der Regel blockieren, bis zur expliziten Verlängerung durch Referendum;
• Regeln entfernen, die im Lebenszeitraum kein einziges Mal ausgelöst haben.

Giftige Spezifikation ohne Diff in Artefakten

> Eskalation des Anti-Patterns aus Band 1. Die Basisversion ist „Spezifikation nach dem Code" aus Teil 20 des ersten Bandes: Die Erklärung ändert sich, das Artefakt nicht. Hier zeigt sich derselbe Fehler in der Umkehraufgabe (Wiederherstellung der Spezifikation) — der Patch heilt den Kommentar, nicht die Ursache.

Symptom: Das Team trainiert die Wiederherstellung der Spezifikation an giftigen Spezifikationen (siehe Teil 2), aber der Patch ändert nur den Erklärungstext oder Kommentar. requirements.md, plan.md, validation.md bleiben unverändert.

Warum schlecht: Die Übung hört auf, die Ursachenlokalisierung zu lehren. Nach einer Woche passiert dieselbe Klasse giftiger Spezifikation erneut — der Patch hat die Ursache nicht geschlossen.

Wie korrigieren:

• In den Done-Kriterien der Lektion einen Diff in mindestens einem Artefakt (requirements.md, plan.md, validation.md, constitution.md) verlangen — nicht nur in der Erklärung;
• Nach der Korrektur einen vollständigen Rückwärtslauf Specify → Plan → Tasks → Implement durchführen;

• Wenn der Patch nur den Erklärungstext ändert, zur Nachprüfung senden;
• Die Klasse der kontrolliert defekten Spezifikation in precedents.md registrieren, damit der nächste analoge Defekt automatisch erkannt wird.

ask_storm als Akkuratesse getarnt

Symptom: Der Agent stellt im Zyklus klärende Fragen und geht nicht zur Lösung über. Kontrollzeile: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false (ask_storm — Zähler für wiederholte Klärungen ohne neue Daten).

Warum schlecht: Die Fragen sehen wie Vorsicht aus, aber sie sind ein Signal für internen Widerspruch in der Spezifikation. Jede menschliche Antwort ad-hoc fügt eine neue Formulierung hinzu, die nirgends verankert ist und beim nächsten /clear verschwindet.

Wie korrigieren:

• Die Sitzung nach der dritten aufeinanderfolgenden Klärung stoppen und requirements.md auf Widersprüche prüfen;
• Die Spezifikation als giftig analysieren (Teil 2) — ein Defekt, Ursachensuche;
• Antworten nicht im Chat, sondern in requirements.md oder clarifications.md festhalten;
• Agentenfragen nicht in einen fortlaufenden Dialog verwandeln: Jede Klärung muss entweder einen Spezifikationspunkt schließen oder in deren Korrektur zurückführen.

stage_regress ohne explizite Ursache

Symptom: Die Phase implement kehrt zu plan zurück, die Phase plan zu specify ohne Aufzeichnung der Ursache. Am nächsten Tag erinnert sich niemand, warum der Plan umgeschrieben wurde. (stage_regress — Rückfall auf die vorherige Phase des SDD-Zyklus ohne explizite Ursache.)

Warum schlecht: Der SDD-Zyklus verwandelt sich in Drift. Jeder Schritt zurück verliert den Kontext des vorherigen, und nach einer Woche hat das Projekt drei halbe Planentwürfe, von denen keiner mit einem Fakt in validation.md abgeschlossen ist.

Wie korrigieren:

• Phasenübergänge explizit festhalten: Reviewbare Änderungsaufzeichnung, Eintrag in genealogy.md, Ursache;
• Rückfall auf die vorherige Phase ohne Aktualisierung mindestens eines Fakts in validation.md verbieten;
• Project Skill verwenden, der bei git status die aktuelle Phase und noch nicht geschlossene Fakten anzeigt;
• Wenn der Rückfall häufiger als einmal pro Tag auftritt — das ist das Signal, dass die Spezifikation zu klein ist, nicht dass der Prozess rauscht.

phase_context_loss zwischen Phasen

Symptom: specify hat eine Entscheidung festgehalten, plan hat sie nicht übernommen, implement beginnt mit einem Entwurf, der nie durch validation.md gegangen ist. (phase_context_loss — Kontextverlust zwischen Phasen.)

Warum schlecht: Jeder Schritt arbeitet mit seinem eigenen Weltbild. Nach zwei bis drei Übergängen divergieren sie so weit, dass die Artefakte einander widersprechen, und jede Prüfung trivial besteht — sie prüft das Falsche.

Wie korrigieren:

• Zwischen Phasen nur Dateireferenzen (@specs/...) übergeben, keine Nacherzählung aus dem Chat;
• Project Skill check_phase_handoff einführen, der prüft, dass der Plan auf das aktuelle requirements.md verweist und die Implementierung auf den aktuellen Plan;
• Nach /clear eine neue Phase mit dem Lesen von QWEN.md, aktuellem requirements.md und aktuellem plan.md beginnen;
• Wenn eine Phase nicht erklären kann, welchen Punkt der vorherigen Phase sie umsetzt — zu dieser zurückkehren, bevor Code geändert wird.

Verifizierer wird zum gewöhnlichen Code Review

Symptom: Der Verifizierer schreibt Kommentare wie „Stil nicht so gut", „besser umbenennen", „lassen Sie uns diskutieren". Es gibt kein konkretes Gegenbeispiel, keine Regelreferenz oder JSON-Schema-Verletzung.

Warum schlecht: Das Duell verliert seinen prozeduralen Charakter. Der Verifizierer hört auf, formaler Kontur zu sein, und wird zu einer weiteren Meinung. Der Implementor antwortet mit freiem Text, und der Streit wandert in den Chat, wo er nicht reproduzierbar ist.

Wie korrigieren:

• Dem Verifizierer jegliche Urteile ohne konkretes Artefakt verbieten: Gegenbeispiel mit Minimalität, Log des Hooks, JSON Schema, Given/When/Then;
• Die Replikation des Verdikts muss lokal sein: Eine andere Person mit denselben cases/ und metrics/ erhält dasselbe judgment.md;
• Wenn der Verifizierer kein Gegenbeispiel findet — verdict=APPROVE festhalten und weitergehen, statt die Diskussion in allgemeinen Formulierungen fortzusetzen;
• Stilistische Anmerkungen in einen separaten Review-Kanal auslagern, nicht mit dem Duell vermischen.

Datei-Schiedsgericht, in dem nur die Mehrheit abstimmt

Symptom: governance_protocol ist als „2 approve aus 3" beschrieben, ohne Veto von Safety und Tie-Breaker. Bei Gleichstand hängt das System oder entscheidet nach Datum der Einberufung.

Warum schlecht: Die Rolle Safety verliert ihren Sinn. Entscheidungen werden durch die Stimmen von Verifizierer und Implementor getroffen, die die Geschwindigkeit optimieren; kritische Risiken gehen als „akzeptabel" durch.

Wie korrigieren:

• safety_veto: critical_risk für die Rolle Safety einführen;
• tie_breaker: safety_first_then_latest_matching_precedent festlegen;
• governance_protocol durch Spec CI-Gateway prüfen: Fehlen von Tie-Breaker und Veto blockiert Merge;

• Jede Ablehnung durch Safety-Veto in precedents.md mit Referenz auf die Immutable-Regel festhalten, damit ein wiederkehrender analoger Streit schneller geschlossen wird.

Fiktiver [project script]

Symptom: In Spezifikation, Checkliste oder Lernkapitel wird ein Befehl wie python3 scripts/spec_ci/check_scope.py verwendet, aber das Skript selbst existiert nicht im Repository. Niemand hat es ausgeführt, der Fakt „Prüfung bestanden" wird angenommen, nicht beobachtet.

Warum schlecht: Es entsteht ein falsches Gefühl der Kontrolle. Die CI sieht streng aus, aber die Prüfung wird nicht durchgeführt. Nach einigen Wochen vergisst das Team, welche Skripte real sind und welche — Schnittstelle.

Wie korrigieren:

• Neben jedem [project script]-Block explizit angeben, ob es ein ausführbares Analogon in examples/ gibt oder ob es sich um die Schnittstelle „implementieren Sie selbst" handelt;
• In Spec CI einen separaten Schritt prüfen, dass in validation.md erwähnte Befehle tatsächlich existieren (test -x path/to/script);
• Lernkapitel markieren [runnable] nur für Befehle, die lokal python3 scripts/... durchlaufen;
• Wenn ein Skript benötigt, aber nicht vorhanden ist — ein Ticket mit festem Implementierungsdatum anlegen, nicht als „später" stehenlassen.

Nackter KPI ohne gepaarte Kontrollmetrik

Symptom: In validation.md gibt es eine Zielmetrik (MTTR<=5m, coverage>=80%, auto_close_rate>=0.9), aber keine gepaarten Kontrollmetriken (Guard-Metriken). Das CI-Gateway besteht, wenn der KPI erfüllt ist.

Warum schlecht: Klassischer Goodhart. Der Agent oder das Team lernt, die Metrik um jeden Preis zu erfüllen: Komplexe Vorfälle als einfache schließen, P0 als P2 markieren, manuelles Review umgehen. Die Metrik steigt, die reale Qualität sinkt.

Wie korrigieren:

• Jeder Zielmetrik eine Anti-Goodhart-Metrik zur Seite stellen (siehe Teil 10): Zu MTTR — silent_p0_ratio und manual_review_floor; zu coverage — mutation_kill_rate;
• Das Gateway besteht nur bei gleichzeitiger Erfüllung des Paars;
• Jede Schwellenwertänderung — Risikoereignis, keine kosmetische YAML-Korrektur; wird mit Begründung festgehalten;
• Regelmäßig Replay anhand historischer Vorfälle durchführen: Neue Version darf Verdikte auf bereits analysierten Fällen nicht verschlechtern.

Drift von validation.md nach rotem CI

Symptom: CI ist gefallen, danach ändert der Autor des Pull Requests den Schwellenwert oder löscht einen Fakt in validation.md statt den Code zu korrigieren. Die Änderungsbeschreibung lautet „Validierung präzisiert".

Warum schlecht: Der Prozess beginnt, die Implementierung zu schützen, nicht den Benutzervertrag. Das ist derselbe Fehler wie „Abschwächung von Fakten nach Fehler" aus Teil 20 des ersten Bandes, aber im Anwendungsmaßstab: Die Abschwächung des silent_p0-Schwellenwerts vom Standardwert 0.05 (AgentClinic-Baseline, siehe Anhang D.4) auf 0.10 in einem Pull Request verschiebt eine ganze Risikoklasse.

Wie korrigieren:

• Jede validation.md-Korrektur, die die Prüfung abschwächt, separat als Risikovertragsänderung reviewen;
• In der Änderungsbeschreibung die Ursache festhalten: Vorfallsidentifikator, Post-Mortem-Referenz, erwarteter Effekt;
• Löschen obligatorischer Fakten ohne Eintrag in precedents.md verbieten;
• Wenn der Schwellenwert im letzten Quartal mehr als zweimal geändert wurde — das ist das Signal, dass Ziel und Prüfung getrennt leben.

Stufenwechsel ohne Budget

Symptom: Beim Ausfall von local-coder geht der gesamte Traffic automatisch in frontier-reviewer. budget_keeper (Budgetverwalter) ist nicht konfiguriert oder blockiert keine Überschreitung.

Warum schlecht: Die teure Stufe frisst innerhalb von Minuten das Tageskontingent und verliert die Fähigkeit, echte P0/P1 zu bedienen, wenn sie eintreffen. Das Failover-Wechseln wird zur Quelle eines sekundären Vorfalls.

Wie korrigieren:

• Wechseln als rangiert beschreiben, nicht als total (siehe Teil 9);
• In frontier-reviewer nur Aufgaben mit severity in [P0, P1] und age > N senden;
• Rest — in Degradationswarteschlange, nach Timeout — in manuellen Kanal;
• Notfallmodus wird durch token_health ausgelöst und versetzt das System in geschützten Modus bis zur Wiederherstellung von local-coder.

Schattenspezifikation ohne Überprüfungsfrist

> Eskalation des Anti-Patterns aus Band 1. Die Basisversion ist „QWEN.md als Müllhalde" aus Teil 20 des ersten Bandes. Im Lernzyklus ist das Problem der wachsende Kontext; im Anwendungszyklus erhält eine Heuristik ohne Autor die Kraft eines Vertrags.

Symptom: QWEN.md enthält ein Few-Shot-Beispiel oder eine Heuristik, die „irgendwie von allein" dort gelandet ist. Der Autor erinnert sich nicht, wer und wann sie hinzugefügt hat. Der Eintrag hat kein ttl, keine Beweise oder Bewertungsreferenz.

Warum schlecht: Die Heuristik erwirbt Vertragskraft ohne Überprüfungsverfahren. Sie kann nicht angefochten werden (niemand erinnert sich an den Autor) und nicht genau geprüft werden (keine Quelle). Nach einem halben Jahr wird die Regel per Analogie auf Fälle angewendet, für die sie nicht gedacht war.

Wie korrigieren:

• Jede Heuristik in QWEN.md mit Mindestkopf versehen: Autor, Datum, Beweis, ttl, Auktionsreferenz (siehe Teil 6);
• Nach Ablauf des ttl — entweder aktualisieren oder in Quarantäne mit Ursachenaufzeichnung senden;
• Few-Shot-Beispiele, die in den letzten 50 Vorfällen nicht ausgelöst haben, als Löschkandidaten betrachten;
• Schattenspezifikation ersetzt keine approved-Anforderung — sie leitet nur den Prompt in unklaren Fällen.

Auto-Remediation ohne Mindestmaß manueller Prüfung

Symptom: Der Agent schließt Vorfälle automatisch auf Basis von Metriken. manual_review_floor ist nicht angegeben oder gleich null.

Warum schlecht: Auch wenn die Metriken sauber aussehen, verdrängt der Agent nach und nach den Menschen aus dem Kontur. Bei Auftreten einer Vorfallsklasse, die das Modell nicht gesehen hat, gibt es keinen Reservemechanismus, um die Abweichung zu bemerken. Nach einigen Wochen häufen sich stille Ausfälle, weil niemand sie fängt.

Wie korrigieren:

• manual_review_floor explizit angeben: Zum Beispiel „mindestens 15% der Vorfälle gehen unabhängig von Metriken durch einen Menschen";
• Rotation wird zufällig gewählt, nicht nach dem Prinzip „lassen Sie den Menschen das Schwierigste" — sonst sieht manuelles Review das Basisniveau nicht;
• Ergebnisse des manuellen Reviews gelangen in den Replay-Satz für den nächsten Validator-Lauf;
• Jede Senkung von manual_review_floor wird als Risikovertragsänderung behandelt, nicht als Optimierung.

Readiness 25/25 als Ziel, nicht als Beschreibung

Symptom: Das Team zieht alle 25 Punkte des Readiness-Modells auf Grün, weil „es raus muss". Einige Punkte sind im Voraus gesetzt, ohne reale Nachweis-Markierung.

Warum schlecht: Readiness verliert ihren Sinn als Frühwarnsignal. Beim nächsten Release wieder „25/25", aber die Vorfälle kommen zurück. Die Skala verwandelt sich in ein Ritual.

Wie korrigieren:

• Readiness durch evidence_ref prüfen, nicht durch Textbehauptung;
• 23/25 mit echten Beweisen — das ist Freigabe; 25/25 ohne Beweise bei zwei Punkten — keine Freigabe;
• Bei Nichterfüllung eines Punkts explizit Risiko und Rollback-Bedingung festhalten, nicht „grün anmalen";

• Readiness regelmäßig rückwärts prüfen: Welcher Punkt hat ausgelöst und ein echtes Problem gefangen, welcher im Quartal kein einziges Mal — Kandidat für Überprüfung.

Genealogie ohne Aktualisierung

Symptom: genealogy.md oder change_log der Verfassung existiert, aber der letzte Eintrag ist drei Monate alt. Inzwischen haben sich fünf Regeln geändert.

Warum schlecht: Die Provenienz hört auf, als Beweiskette zu funktionieren. Nach einem halben Jahr ist es unmöglich, „warum der Agent berechtigt war, diese Aktion auszuführen" wiederherzustellen, und der Streit nach einem Vorfall wandert in die allgemeine Diskussion.

Wie korrigieren:

• Eintrag in change_log — obligatorischer Teil jeder Verfassungsänderung, ohne ihn lässt das Gateway keinen Merge durch;
• parent_version obligatorisch; Versionsüberspringung — Anlass für separates Review;
• decision_hash automatisch aus dem Entscheidungsinhalt berechnen, damit eine stille Substitution nicht durchgeht;
• Monatlich — kurzer Audit: Abgleich von change_log mit tatsächlichen Dateiänderungen. Abweichung wird als Prozessvorfall festgehalten.

Spur ohne Nachweis-Markierung

> Eskalation des Anti-Patterns aus Band 1. Die Basisversion ist „Fakten aufs Wort" aus Teil 20 des ersten Bandes. Im Lernzyklus ist die Spur nicht nötig, weil die Funktion klein ist. Im Anwendungszyklus kann ohne evidence_ref nicht wiederhergestellt werden, auf welcher Grundlage die Aktion ausgeführt wurde.

Symptom: Der Agent speichert Aktionslogs, aber in den Einträgen fehlen Referenzen auf ursprüngliche Artefakte: Welche Spezifikationsversion wurde angewendet, welche Verfassungsregeln, welcher Prompt. Nach einem Vorfall ist die Wiederherstellung des Entscheidungskontexts unmöglich.

Warum schlecht: audit_trace_coverage (Audit-Trail-Abdeckung) ist formal nahe 100%, aber die Spur ist nutzlos. Derselbe Fehler wie validation.md, das niemand ausgeführt hat, aber auf Audit-Ebene.

Wie korrigieren:

• In jedem Spureintrag obligatorisch: spec_version, constitution_version, prompt_hash, decision_source, evidence_ref;
• Spec CI prüft Vollständigkeit der Felder und blockiert Merge, wenn mindestens eines leer ist;
• evidence_ref — Pfad und Identifikator innerhalb des Artefakts (logs/node-2026-05-12.parquet#row_4123), keine allgemeine Katalogreferenz;
• Jeder Eintrag mit evidence_ref=null gilt für Audit als ungültig.

Diagnose-Checkliste

Wenn der Anwendungs-SDD-Kontur laut geworden ist oder aufhört, Regressionen zu fangen, beantworten Sie:

1. Wirkt constitution.md als Gateway vor der Ausführung, nicht nur als Review danach?
2. Gibt es in mutable_rules Regeln ohne ttl oder mit ttl über 90 Tagen?
3. Ändert sich nach dem Scheitern einer giftigen Spezifikation mindestens ein Artefakt (requirements.md, plan.md, validation.md)?
4. Verwendet der Verifizierer ein Gegenbeispiel, Hook-Log oder JSON Schema — oder nur Freitext?
5. Gibt es in governance_protocol Veto von Safety und deterministischen Tie-Breaker?
6. Sind im Repository ausführbare Befehle separat von [project script]-Schnittstellen markiert?
7. Begleitet jede Zielmetrik eine gepaarte Anti-Goodhart-Metrik?
8. Wenn CI fällt, wird der Code repariert oder validation.md abgeschwächt?
9. Hat der Stufenwechsel ein Budgetlimit und Notfallmodus?
10. Hat jeder Eintrag in QWEN.md einen Autor, Beweis und ttl?
11. Bleibt manual_review_floor unabhängig vom KPI-Wert erhalten?
12. Ist evidence_ref in jedem Spureintrag ausgefüllt?

Wenn bei drei und mehr Fragen die Antwort negativ ist — fügen Sie keine neuen Automatisierungsebenen hinzu: Datei-Schiedsgericht, stufige Routing, neue Notfallmodus-Regeln. Entfernen Sie zuerst das Rauschen und schließen Sie die Lücken im aktuellen Kontur.

Fazit

Die Anti-Patterns des Anwendungszyklus sind einzeln nicht katastrophal. Gefährlich ist ihre Ansammlung: Nach mehreren Releases sieht das Team den Risikovertrag nicht mehr hinter „grünem CI". Die Diagnosekarte ist der erste Schritt zur Reparatur. Jede negative Antwort verwandelt sich in einen Project Skill, ein Spec CI-Gateway oder eine Verfassungsregel mit prüfbarem rollback_condition. Kehren Sie zu diesem Kapitel nach jedem großen Vorfall zurück: Dasselbe Artefakt zeigt nach drei Monaten bereits drei andere Blocker.

Verwandte Teile des ersten Bandes

• Teil 20 des ersten Bandes — Grundlegende SDD-Anti-Patterns: Spezifikation nach dem Code, gigantisches requirements.md, rituelles /clear, QWEN.md als Müllhalde.
• Teil 18 des ersten Bandes — Anti-Patterns, die gleichzeitig Sicherheitsbedrohungen sind.
• Teil 2 — Giftige Spezifikationen als Trainingswerkzeug gegen die meisten Anti-Patterns dieses Kapitels.

• Teil 10 — Anti-Goodhart als Schutz vor nacktem KPI.

Artefakte und Readiness-Kriterien

Der vollständige Track fügt den aktualisierten Diagnose-Checkliste in [appendix-c-checklists.md](appendix-c-checklists.md), Einträge in precedents.md für jedes aufgetretene Anti-Pattern, Ergänzungen in QWEN.md für wiederkehrende und Spec CI-Prüfung für mindestens eines davon hinzu. Betrachten Sie ihn als fertig, wenn in Spec CI mindestens eine Prüfung existiert, die ein Anti-Pattern automatisch fängt (zum Beispiel mutable_rules ohne ttl), und wiederkehrende Anti-Patterns nur mit Beweis und Überprüfungsfrist in precedents.md oder QWEN.md gelangen.

Praxis

1. Öffnen Sie das aktuelle constitution.md des Teams und prüfen Sie mutable_rules auf Vorhandensein von ttl und rollback_condition. Finden Sie mindestens eine Regel, die entweder aktualisiert oder in Quarantäne geschickt werden muss. *Erwartung: In antipattern-audit.md erscheint eine Zeile blocker / owner / next_check für die konkrete Regel; ttl-Frist in Tagen angegeben, nicht Jahren.*
2. Nehmen Sie den letzten Pull Request mit validation.md-Korrektur. Bestimmen Sie, was geändert wurde — Schwellenwert oder Faktinhalt. Wenn Schwellenwert, prüfen Sie, ob in der Änderungsbeschreibung eine Post-Mortem-Referenz oder Vorfallsidentifikator vorhanden ist. *Erwartung: Für den Pull Request ist einer von zwei Ausgängen festgehalten — entweder begründete Risikovertragsänderung mit Vorfallsreferenz, oder Anti-Pattern „Drift von validation.md nach rotem CI" mit Eigentümer und Rollback-Frist.*
3. Gehen Sie die Liste der [project script]-Blöcke in einem ausgewählten Kapitel durch und prüfen Sie, welche Befehle real sind und welche Schnittstelle. Ergänzen Sie die Kapitel-README mit Markierungen. *Erwartung: Für jeden [project script] ist explizit angegeben „ausführbares Analogon in examples/... vorhanden" oder „implementieren Sie selbst"; keine Blöcke ohne Markierung.*

Kontrollfragen

1. Warum ist eine Mutable-Regel mit ttl: ∞ gefährlicher als eine Regel ohne Formulierung überhaupt?
2. Worin unterscheidet sich ask_storm von redlichen Klärungen und wie unterscheidet man beides?
3. Welche drei Felder machen einen Spureintrag auditgeeignet, und warum ist audit_trace_coverage=100% ohne sie eine Goodhart-Metrik?
4. Beim Review eines Pull Requests sehen Sie, dass der Autor den silent_p0-Schwellenwert von 0.05 auf 0.10 geändert und den Kommentar „vorübergehend, bis zur Stabilisierung" hinzugefügt hat. Was machen Sie mit diesem Pull Request und welche drei Bedingungen müssen erfüllt sein, bevor eine solche Änderung gemerged werden kann?