Anwendungsteil 12. Antipattern im Produktions-SDD: Diagnosekarte des angewandten Zyklus

Status: Empfehlung. Der Teil sammelt Antipattern, die genau im angewandten Zyklus auftreten: bei Duellen, Datei-Schiedsverfahren, Spec CI, Stufenbudgets, Anti-Goodhart-Metriken und automatischer Behebung. Sie setzen die Linie aus Teil 20 des ersten Bands fort: Artefakte sind vorhanden, Prüfungen sind vorhanden, der Agent arbeitet schnell, aber die Kontrolle über das System geht allmählich verloren.

Dieser Teil wird als Diagnosekarte des angewandten Bands benötigt. Wenn der Produktionskreislauf laut, widersprüchlich geworden ist oder seine eigene Geschwindigkeit auf Kosten des Nutzers verteidigt, beginnen Sie hier.

Vor dem Lesen

• Anker aus dem ersten Band: Teil 20 zeigt die grundlegenden SDD-Antipattern.
• Lokaler Lernfall: ein beliebiges 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: diagnostischer Blocker. Die Namen der einzelnen Antipattern sind nachschlagbar, sie müssen nicht hintereinander gelesen werden.
• Was zurückzustellen ist: die Umwandlung jedes Antipatterns in eine automatische CI-Richtlinie.

Ziel

Ziel des Kapitels ist es nicht, eine Liste von Namen auswendig zu lernen, sondern ein kurzes Audit des bereits zusammengestellten Produktions-SDD-Pakets durchzuführen. Nach dem Kapitel sollten Sie drei diagnostische Zeilen haben: was die Zulassung blockiert, wer für die Behebung verantwortlich ist und wann dies erneut geprüft wird.

Lesen Sie dieses Kapitel beim ersten Durchgang als Checkliste, nicht als Wörterbuch aller möglichen Fehler. Der folgende Katalog dient dazu, das gefundene Problem zu erkennen; das Kapitel kann mit drei Zeilen blocker / owner / next_check abgeschlossen werden.

Eskalationen der Antipattern aus dem ersten Band

Einige Antipattern in diesem Katalog sind nicht neu, sondern Produktionsvarianten der in Teil 20 des ersten Bands beschriebenen. Der Unterschied liegt im Umfang: Im Lernzyklus verbrennt ein grundlegendes Antipattern einen Arbeitstag, im angewandten Zyklus eröffnet es eine Klasse von Vorfällen auf einem laufenden Dienst.

| Schattenspezifikation ohne Überprüfungsfrist | „QWEN.md als Müllhalde" — Gedächtnis ohne ttl und Autor | | Spur ohne Evidenzmarkierung | „Fakten nach Gehörsagen" — fehlendes evidence_ref |

Wenn Sie Teil 20 des ersten Bands durchgearbeitet haben, können Sie diese Einträge selektiv lesen — hier ist nur das enthalten, was Produktionskontext hinzufügt. Die übrigen 12 Antipattern in diesem Kapitel treten nur im angewandten Zyklus auf (Duelle, Schiedsverfahren, Budgets, Anti-Goodhart, automatische Behebung) und werden in Band 1 nicht behandelt.

Minimales Lernszenario

Lernfall

Vor der Abschlussprüfung muss ein Produktions-SDD-Kreislauf auf Lärm 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 Antipattern zu finden oder explizit zu belegen, dass keine vorhanden sind.

Vorbereitung

• Diagnostische Checkliste unten.
• book2/examples/templates/retrospective.md — Formular für eine kurze Ergebnismitschrift.
• Ein Artefakt, das bereits ein Runnable-Beispiel oder ein manuelles Lernszenario durchlaufen hat.

Schritte

1. Wählen Sie ein Artefakt aus und erweitern Sie den Prüfbereich nicht. Erwartung: Das Audit dauert 15–30 Minuten und wird nicht zu einer Review des gesamten Projekts.

1. Beantworten Sie die 12 Fragen der Checkliste. *Erwartung: Jede Antwort ist yes, no oder not_applicable mit einem kurzen Datei-Link.*
2. Geben Sie für jedes no das Antipattern, den Eigentümer und die Frist für die Behebung an.
3. Finden Sie mindestens einen [project script] im ausgewählten Kapitel und prüfen Sie, ob er als Runnable-Analogon oder als „Implementieren-Sie-selbst"-Schnittstelle markiert ist.
4. Tragen Sie das Ergebnis in antipattern-audit.md oder in die Retrospektive ein: was die Produktionszulassung blockiert, was als Verbesserung belassen werden kann.

Kontrollfakt

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

Wie dies in capstone/ landet

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

Minimaler Auszug:

| blocker | owner | next_check |
|---|---|---|
| readiness ohne `evidence_ref` | platform | Dry-Run mit Verweis auf Fixture wiederholen |

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

Überprüfbare Spur

Speichern Sie antipattern-audit.md, wenn sich das Audit auf ein Lernpaket oder capstone/ bezieht. Beheben Sie die gefundenen Probleme nicht in derselben Änderung ohne separaten Eintrag: zuerst muss die Diagnose sichtbar sein, dann die Behandlung.

Schlüsselideen

Jedes Antipattern unten wird nach demselben Schema aus drei Feldern behandelt: Symptom — was in den Artefakten und Protokollen beobachtet wird, Warum schlecht — wie dies das Verhalten des Teams oder Agenten verändert, Wie zu beheben — minimale Schritte zu einem Zustand, in dem das Symptom automatisch erfasst wird.

Der Katalog kann in beliebiger Reihenfolge gelesen werden: Jeder Eintrag ist eigenständig und folgt denselben drei Feldern. Die Einträge sind keine Alternativen — es sind verschiedene Klassen von Lärm, die häufig zusammen auftreten. Wenn in einem Produktionspaket drei oder mehr Antipattern gefunden wurden, lesen Sie sie als ein verflochtenes Netz von Problemen mit einer gemeinsamen Wurzel im verlorenen Risikokontrakt.

Beispiele und Anwendung

Konstitution als Kosmetik

> Eskalation des Antipatterns aus Band 1. Die Basisversion ist „Konstitution, die niemand öffnet" aus Teil 20 des ersten Bands. Im angewandten Zyklus führt derselbe Fehler nicht zu schlechtem Code, sondern zu einer ausgeführten 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 ausgelöst. In judgment.md gibt es einen Verweis auf die Regel forbid_unscoped_delete, in den Team-Protokollen (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, schränken den Agenten aber im Moment des Drucks nicht ein. Nach einigen Vorfällen beginnt das Team, die Konstitution als Dekoration zu betrachten. Bei der Analyse des nächsten Vorfalls taucht der charakteristische Satz auf: „Die Regel gab es, nur hat niemand geprüft" — das ist ein Signal, dass die Konstitution als Kommentar funktionierte, nicht als Vertrag.

Wie zu beheben:

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

• in judgment.md einen Verweis auf die Version der Konstitution und decision_hash festhalten;
• wenn eine Regel nicht automatisch geprüft wird, sie aus immutable_principles in das Playbook verschieben und explizit als „Anweisung, kein Gateway" markieren;
• prüfen, ob es in den letzten 30 Tagen mindestens ein Protokoll gibt, in dem das Gateway ausgelöst und eine Aktion blockiert hat. Null Auslösungen pro Quartal — entweder ist die Konstitution nicht angebunden oder sie beschreibt nicht existente 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 als „nach Entscheidung des Teams" formuliert.

Warum schlecht: Die Regel lebt unbefristet und wird mit der Zeit zu einem verborgenen Teil der Invariante. Nach einem Jahr erinnern sich die Teilnehmer nicht mehr, warum sie eingeführt wurde, und haben Angst, sie anzufassen. Die Korrektur wird analog auf Situationen angewendet, für die sie nicht gedacht war.

Wie zu beheben:

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

• nach Ablauf der ttl die Anwendung der Regel bis zur ausdrücklichen Verlängerung durch ein Referendum blockieren;
• Regeln löschen, die während ihres Lebenszeitraums nie ausgelöst wurden.

Giftige Spezifikation ohne Diff in den Artefakten

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

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

Warum schlecht: Die Übung lehrt nicht mehr die Lokalisierung der Ursache. Nach einer Woche besteht dieselbe Klasse von giftigen Spezifikationen erneut — der Patch hat die Grundursache nicht geschlossen.

Wie zu beheben:

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

• wenn der Patch nur den Erklärungstext ändert, zur Wiederholung schicken;
• die Klasse der kontrolliert defekten Spezifikation in precedents.md registrieren, damit ein nächster ähnlicher Defekt automatisch erfasst wird.

ask_storm unter dem Deckmantel der Sorgfalt

Symptom: Der Agent stellt im Zyklus Klärungsfragen und geht nicht zur Lösung über. Kontrollzeichen: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false (ask_storm — Zähler wiederholter Klärungen ohne neue Daten).

Warum schlecht: Die Fragen sehen wie Vorsicht aus, sind aber ein Signal für einen inneren Widerspruch in der Spezifikation. Jede Antwort des Menschen fügt unterwegs eine neue Formulierung hinzu, die nirgends festgehalten wird und beim nächsten /clear verschwindet.

Wie zu beheben:

• die Sitzung nach der dritten aufeinanderfolgenden Klärung stoppen und requirements.md auf Widersprüche prüfen;
• die Spezifikation als giftig behandeln (Teil 2) — ein Defekt, Suche nach der Grundursache;
• Antworten nicht im Chat festhalten, sondern in requirements.md oder clarifications.md;
• die Fragen des Agenten nicht in einen fortlaufenden Dialog verwandeln: jede Klärung muss entweder einen Punkt der Spezifikation schließen oder zu deren Korrektur zurückkehren.

stage_regress ohne expliziten Grund

Symptom: Die Phase implement kehrt zu plan zurück, die Phase plan zu specify, ohne dass der Grund vermerkt wird. Am nächsten Tag erinnert sich niemand, warum der Plan umgeschrieben wurde. (stage_regress — Rückfall auf eine frühere Phase des SDD-Zyklus ohne expliziten Grund.)

Warum schlecht: Der SDD-Zyklus wird zum Drift. Jeder Schritt zurück verliert den Kontext des vorherigen, und nach einer Woche hat das Projekt drei Halbentwürfe des Plans, von denen keiner durch ein Faktum in validation.md geschlossen ist.

Wie zu beheben:

• den Übergang zwischen Phasen explizit festhalten: überprüfbarer Änderungseintrag, Eintrag in genealogy.md, Grund;
• einen Rückfall auf eine frühere Phase ohne Aktualisierung mindestens eines Fakts in validation.md verbieten;
• einen Project-Skill verwenden, der bei git status zeigt, welche Phase aktuell ist und welche Fakten noch nicht geschlossen sind;
• wenn ein Rückfall häufiger als einmal pro Tag auftritt — das ist ein Signal, dass die Spezifikation zu klein ist, nicht der Prozess laut ist.

phase_context_loss zwischen Phasen

Symptom: specify hat eine Entscheidung festgehalten, plan hat sie nicht geerbt, implement hat mit einem Entwurf begonnen, der nie validation.md durchlaufen hat. (phase_context_loss — Verlust des Kontexts zwischen Phasen.)

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

Wie zu beheben:

• zwischen Phasen nur Verweise auf Dateien (@specs/...) übergeben, keine Nacherzählung aus dem Chat;
• einen Projektskill check_phase_handoff einführen, der prüft, dass der Plan auf das geltende requirements.md verweist und die Implementierung auf den geltenden Plan;
• nach /clear eine neue Phase mit dem Lesen von QWEN.md, dem aktuellen requirements.md und dem aktuellen 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.

Der Verifizierer wird zu einem gewöhnlichen Code-Review

Symptom: Der Verifizierer schreibt Kommentare wie „Stil nicht so gut", „besser umbenennen", „lasst uns das besprechen". Es gibt kein konkretes Gegenbeispiel, keinen Regelverweis oder Verstoß gegen das JSON-Schema.

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

Wie zu beheben:

• dem Verifizierer jegliche Urteile ohne konkretes Artefakt verbieten: Gegenbeispiel mit Minimalität, Hook-Protokoll, JSON-Schema, Given/When/Then;
• die Replikation des Verdikts muss lokal sein: eine andere Person erhält mit demselben cases/ und metrics/ dasselbe judgment.md;
• wenn der Verifizierer kein Gegenbeispiel findet — verdict=APPROVE festhalten und weitergehen, nicht die Diskussion in allgemeinen Formulierungen fortsetzen;
• stilistische Anmerkungen in einen separaten Review-Kanal auslagern, nicht mit dem Duell vermischen.

Datei-Schiedsverfahren, bei 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 dem Datum der Einberufung.

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

Wie zu beheben:

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

• jede Abweichung durch Safety-Veto in precedents.md mit Verweis auf die Immutable-Regel festhalten, damit eine wiederholte ähnliche Auseinandersetzung schneller geschlossen wird.

Fiktiver [project script]

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

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

Wie zu beheben:

• neben jedem [project script]-Block explizit angeben, ob es ein ausführbares Analogon in examples/ gibt oder ob dies eine „Implementieren-Sie-selbst"-Schnittstelle ist;
• in Spec CI prüft ein separater Schritt, dass die in validation.md erwähnten 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 wird, aber nicht existiert — ein Ticket mit festem Implementierungsdatum anlegen, nicht als „später" belassen.

Nackter KPI ohne gepaarte Gegenmetrik

Symptom: In validation.md gibt es eine Zielmetrik (MTTR<=5m, coverage>=80%, auto_close_rate>=0.9), aber keine gepaarten Gegenmetriken (Guard-Metriken). Das CI-Gateway geht durch, 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 leichte schließen, P0 als P2 markieren, manuelles Review umgehen. Die Metrik steigt, die tatsächliche Qualität sinkt.

Wie zu beheben:

• zu jeder Zielmetrik eine Anti-Goodhart-Metrik paaren (siehe Teil 10): zu MTTR — silent_p0_ratio und manual_review_floor; zu coverage — mutation_kill_rate;
• das Gateway geht nur bei gleichzeitiger Erfüllung des Paares durch;
• jede Änderung des Schwellenwerts ist ein Risikoereignis, keine kosmetische YAML-Korrektur; sie wird mit Begründung festgehalten;
• regelmäßig Replays über historische Vorfälle durchführen: die neue Version darf die Verdikte in den analysierten Fällen nicht verschlechtern.

Drift von validation.md nach rotem CI

Symptom: CI ist gescheitert, woraufhin der Autor des Pull Requests den Schwellenwert ändert oder ein Faktum in validation.md löscht, anstatt den Code zu reparieren. Die Änderungsbeschreibung lautet „Validierung präzisiert".

Warum schlecht: Der Prozess beginnt, die Implementierung zu schützen, nicht den Nutzervertrag. Es ist derselbe Fehler wie „Aufweichen von Fakten nach einem Fehler" aus Teil 20 des ersten Bands, aber in angewandtem Maßstab: die Aufweichung des Schwellenwerts silent_p0 vom Standardwert 0,05 (AgentClinic-Baseline, siehe Anhang D.4) auf 0,10 mit einem einzigen Pull Request verschiebt eine ganze Klasse von Risiken.

Wie zu beheben:

• jede Korrektur von validation.md, die eine Prüfung aufweicht, getrennt als Änderung des Risikovertrags reviewen;
• in der Änderungsbeschreibung den Grund festhalten: Vorfall-ID, Verweis auf den Post-Mortem, erwartete Wirkung;
• das Löschen obligatorischer Fakten ohne Eintrag in precedents.md verbieten;
• wenn der Schwellenwert im letzten Quartal mehr als zweimal geändert wurde — das ist ein Signal, dass Ziel und Prüfung getrennt leben.

Wechsel zwischen Stufen ohne Budget

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

Warum schlecht: Die teure Stufe verbraucht in Minuten das Tageskontingent und verliert die Fähigkeit, echte P0/P1 zu bedienen, wenn sie kommen. Das Failover wird zu einer Quelle sekundärer Vorfälle.

Wie zu beheben:

• den Wechsel als abgestuft beschreiben, nicht als total (siehe Teil 9);
• an frontier-reviewer nur Aufgaben mit severity in [P0, P1] und age > N senden;
• den Rest in die Degradationswarteschlange, nach Timeout — in den manuellen Kanal;
• der Notfallmodus wird durch token_health ausgelöst und versetzt das System in den geschützten Modus, bis local-coder wiederhergestellt ist.

Schattenspezifikation ohne Überprüfungsfrist

> Eskalation des Antipatterns aus Band 1. Die Basisversion ist „QWEN.md als Müllhalde" aus Teil 20 des ersten Bands. Im Lernzyklus ist das Problem der wachsende Kontext; im angewandten erlangt eine Heuristik ohne Autor die Kraft eines Vertrags.

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

Warum schlecht: Die Heuristik erlangt die Kraft eines Vertrags 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 analog auf Fälle angewendet, für die sie nicht gedacht war.

Wie zu beheben:

• jede Heuristik in QWEN.md mit einem minimalen Kopf versehen: Autor, Datum, Beleg, ttl, Verweis auf die Auktion (siehe Teil 6);
• nach Ablauf der ttl — entweder aktualisieren oder mit Begründung in Quarantäne schicken;
• Few-Shot-Beispiele, die in den letzten 50 Vorfällen nicht funktioniert haben, als Löschkandidaten betrachten;
• eine Schattenspezifikation ersetzt keine genehmigte Anforderung — sie lenkt den Prompt nur in mehrdeutigen Fällen.

Automatische Behebung ohne Minimum an manueller Prüfung

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

Warum schlecht: Selbst wenn die Metriken sauber aussehen, verdrängt der Agent den Menschen allmählich aus dem Kreislauf. Wenn eine Klasse von Vorfällen auftritt, die das Modell nicht gesehen hat, gibt es keinen Reserve-Mechanismus, um die Abweichung zu bemerken. Nach einigen Wochen häufen sich stille Ausfälle, weil niemand sie fängt.

Wie zu beheben:

• manual_review_floor explizit festlegen: z. B. „mindestens 15 % der Vorfälle gehen unabhängig von den Metriken durch den Menschen";
• die Rotation wird zufällig gewählt, nicht nach dem Prinzip „wir überlassen den Menschen das Komplizierteste" — sonst sieht das manuelle Review das Grundniveau nicht;
• die Ergebnisse des manuellen Reviews gelangen in den Replay-Satz für den nächsten Validator-Lauf;
• jede Senkung von manual_review_floor gilt als Änderung des Risikovertrags, nicht als Optimierung.

Bereitschaft 25/25 als Ziel, nicht als Beschreibung

Symptom: Das Team zieht alle 25 Punkte des Bereitschaftsmodells auf grün, „weil wir veröffentlichen müssen". Ein Teil der Punkte wird im Voraus gesetzt, ohne echte Evidenzmarkierung.

Warum schlecht: Bereitschaft verliert ihre Bedeutung als Frühwarnsignal. Beim nächsten Release ist wieder alles „25/25", aber die Vorfälle kehren zurück. Die Skala wird zum Ritual.

Wie zu beheben:

• die Bereitschaft über evidence_ref prüfen, nicht über eine textliche Behauptung;
• 23/25 mit echten Belegen — das ist eine Zulassung; 25/25 ohne Belege bei zwei Punkten — keine Zulassung;
• bei Nichterfüllung eines Punkts das Risiko und die Rückrollbedingung explizit festhalten, nicht „auf grün setzen";

• regelmäßig die Bereitschaft rückwärts durchgehen: welcher Punkt hat funktioniert und ein echtes Problem gefangen, welcher hat im Quartal nie funktioniert — Kandidat für eine Überprüfung.

Genealogie ohne Aktualisierung

Symptom: genealogy.md oder change_log der Konstitution existiert, aber der letzte Eintrag ist drei Monate alt. In der Zwischenzeit wurden fünf Regeln geändert.

Warum schlecht: Provenienz funktioniert nicht mehr als Beweiskette. Nach einem halben Jahr lässt sich nicht mehr rekonstruieren, „warum der Agent das Recht hatte, diese Aktion auszuführen", und der Streit nach einem Vorfall wird zur allgemeinen Diskussion.

Wie zu beheben:

• der Eintrag in change_log ist obligatorischer Teil jeder Verfassungskorrektur, ohne ihn lässt das Gateway den Merge nicht durch;
• parent_version ist obligatorisch; das Überspringen einer Version ist ein Anlass für ein separates Review;
• decision_hash wird automatisch aus dem Inhalt der Entscheidung berechnet, damit eine Substitution nicht stillschweigend durchgeht;
• monatlich — ein kurzes Audit: Abgleich von change_log mit den tatsächlichen Korrekturen der Datei. Eine Abweichung wird als Prozessvorfall festgehalten.

Spur ohne Evidenzmarkierung

> Eskalation des Antipatterns aus Band 1. Die Basisversion ist „Fakten nach Gehörsagen" aus Teil 20 des ersten Bands. Im Lernzyklus wird keine Spur benötigt, weil das Feature klein ist. Im angewandten lässt sich ohne evidence_ref nicht rekonstruieren, auf welcher Grundlage die Aktion ausgeführt wurde.

Symptom: Der Agent speichert Aktionsprotokolle, aber in den Einträgen gibt es keine Verweise auf die ursprünglichen Artefakte: welche Version der Spezifikation angewendet wurde, welche Verfassungsregeln, welcher Prompt. Nach einem Vorfall lässt sich der Kontext der Entscheidung nicht wiederherstellen.

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

Wie zu beheben:

• in jedem Spureintrag sind spec_version, constitution_version, prompt_hash, decision_source, evidence_ref obligatorisch;
• Spec CI prüft die Vollständigkeit der Felder und blockiert den Merge, wenn mindestens eines davon leer ist;
• evidence_ref ist ein Pfad und eine Kennung innerhalb des Artefakts (logs/node-2026-05-12.parquet#row_4123), kein allgemeiner Verweis auf ein Verzeichnis;
• jeder Eintrag mit evidence_ref=null gilt für das Audit als ungültig.

Diagnostische Checkliste

Wenn der angewandte SDD-Kreislauf laut geworden ist oder keine Regressionen mehr erfasst, beantworten Sie:

1. Wird constitution.md als Gateway vor der Ausführung ausgelöst, und nicht nur als Review danach?
2. Gibt es in mutable_rules Regeln ohne ttl oder mit ttl über 90 Tagen?
3. Wird nach dem Scheitern einer giftigen Spezifikation mindestens ein Artefakt geändert (requirements.md, plan.md, validation.md)?
4. Verwendet der Verifizierer ein Gegenbeispiel, ein Hook-Protokoll oder ein JSON-Schema — oder nur freien Text?
5. Gibt es im governance_protocol ein Veto von Safety und einen deterministischen Tie-Breaker?
6. Sind im Repository ausführbare Befehle getrennt von [project script]-Schnittstellen markiert?
7. Wird jede Zielmetrik von einer gepaarten Anti-Goodhart-Metrik begleitet?
8. Wenn CI fehlschlägt, wird der Code repariert oder validation.md aufgeweicht?
9. Gibt es beim Wechsel zwischen Stufen eine Budgetobergrenze und einen Notfallmodus?
10. Hat jeder Eintrag in QWEN.md einen Autor, einen Beleg und ein ttl?
11. Wird manual_review_floor unabhängig vom KPI-Wert eingehalten?
12. Ist evidence_ref in jedem Spureintrag ausgefüllt?

Wenn drei oder mehr Fragen mit „nein" beantwortet werden — fügen Sie keine neuen Automatisierungsschichten hinzu: Datei-Schiedsverfahren, Stufenrouting, neue Notfallmodus-Regeln. Beseitigen Sie zuerst den Lärm und schließen Sie die Lücken im aktuellen Kreislauf.

Ergebnis

Die Antipattern des angewandten Zyklus sind einzeln nicht katastrophal. Gefährlich ist ihre Anhäufung: Nach einigen Releases sieht das Team den Risikovertrag hinter dem „grünen CI" nicht mehr. Die Diagnosekarte ist der erste Schritt zur Reparatur. Jede negative Antwort wird zu einem Projektskill, einem Spec-CI-Gateway oder einer Verfassungsregel mit überprüfbarem rollback_condition. Kehren Sie nach jedem größeren Vorfall zu diesem Kapitel zurück: dasselbe Artefakt zeigt nach drei Monaten bereits drei andere Blocker.

Verwandte Teile des ersten Bands

• Teil 20 des ersten Bands — grundlegende SDD-Antipattern: Spezifikation nach dem Code, riesiges requirements.md, rituelles /clear, QWEN.md als Müllhalde.
• Teil 18 des ersten Bands — Antipattern, die gleichzeitig Sicherheitsbedrohungen sind.
• Teil 2 — giftige Spezifikationen als Trainingsinstrument gegen die meisten Antipattern in diesem Kapitel.

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

Artefakte und Bereitschaftskriterien

Der vollständige Track fügt eine aktualisierte diagnostische Checkliste in [appendix-c-checklists.md](appendix-c-checklists.md) hinzu, Einträge in precedents.md für jedes aufgetretene Antipattern, Ergänzungen in QWEN.md für Wiederholungen und eine Spec-CI-Prüfung für mindestens eines davon. Betrachten Sie ihn als bereit, wenn es in Spec CI mindestens eine Prüfung gibt, die ein Antipattern automatisch erfasst (z. B. mutable_rules ohne ttl), und wiederkehrende Antipattern in precedents.md oder QWEN.md nur mit Beleg und Überprüfungsfrist landen.

Praxis

1. Öffnen Sie die aktuelle constitution.md des Teams und prüfen Sie mutable_rules auf das 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 ist eine Zeile blocker / owner / next_check für eine konkrete Regel erschienen; die ttl-Frist ist in Tagen angegeben, nicht in Jahren.*
2. Nehmen Sie den letzten Pull Request mit einer Korrektur von validation.md. Stellen Sie fest, was geändert wurde — der Schwellenwert oder der Inhalt des Fakts. Wenn der Schwellenwert, prüfen Sie, ob die Änderungsbeschreibung einen Verweis auf den Post-Mortem oder die Vorfall-ID enthält. *Erwartung: Für den Pull Request ist eines von zwei Ergebnissen festgehalten — entweder eine begründete Änderung des Risikovertrags mit Verweis auf den Vorfall oder das Antipattern „Drift von validation.md nach rotem CI" mit Eigentümer und Rückrollfrist.*
3. Gehen Sie die Liste der [project script]-Blöcke in einem ausgewählten Kapitel durch und gleichen Sie ab, welche Befehle real sind und welche Schnittstellen. Ergänzen Sie die README des Kapitels um Markierungen. *Erwartung: Für jeden [project script] ist explizit angegeben „es gibt ein Runnable-Analogon in examples/..." oder „selbst implementieren"; es gibt 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 gewissenhaften Klärungen, und wie unterscheidet man das eine vom anderen?
3. Welche drei Felder machen einen Spureintrag auditfähig, und warum ist audit_trace_coverage=100% ohne sie eine Goodhart-Metrik?
4. In einem Pull-Request-Review sehen Sie, dass der Autor den Schwellenwert silent_p0 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 gemergt werden darf?