Thema: Anwendungsteil 12. Anti-Patterns in der Produktions-SDD: Diagnosekarte des Anwendungszyklus
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 6-8 Stunden
Voraussetzungen: Grundkenntnisse SDD (Software Design Document)
Abschluss von Teil 20 des ersten Bandes (Grund-Anti-Patterns SDD)
Erfahrung mit SDD-Artefakten (requirements.md, validation.md, plan.md)
Verständnis der Konzepte Spec CI und Duelle
Vertrautheit mit stufenweiser Budgetierung (Teil 9)
Verständnis von Goodhart-Metriken (Teil 10)
Lernziele: Einen diagnostischen Audit eines Produktions-SDD-Pakets durchführen und mindestens 3 Anti-Patterns identifizieren (oder deren Abwesenheit bestätigen) in 15-30 Minuten
Eine Diagnosekarte mit drei Feldern erstellen: blocker, owner, next_check für jedes gefundene Anti-Pattern
Die 12-fragen Diagnose-Checkliste auf ein ausgewähltes Artefakt anwenden mit Dokumentation der Antworten yes/no/not_applicable
Produktions-Varianten von Anti-Patterns von ihren Grundversionen des ersten Bandes unterscheiden und das Ausmaß des Problems eskalieren
Mindestens einen Spec CI-Gateway entwerfen, der das gefundene Anti-Pattern automatisch abfängt
Überblick: Dieser Teil stellt eine Diagnosekarte des Anwendungs-SDD-Zyklus dar, die Anti-Patterns sammelt, die spezifisch im Produktionskontext entstehen: bei Duellen, Datei-Arbitrage, Spec CI, stufenweisen Budgets, Anti-Goodhart-Metriken und Auto-Remediation. Das Ziel des Kapitels ist nicht, eine Liste von Namen auswendig zu lernen, sondern einen kurzen Audit eines bereits zusammengestellten Produktions-SDD-Pakets durchzuführen und drei Diagnosezeilen zu erhalten: was blockiert die Freigabe, wer ist für die Behebung verantwortlich und wann wird dies erneut geprüft. Jedes Anti-Pattern wird nach einem Schema mit drei Feldern analysiert: Symptom (was beobachtet wird), Warum schlecht (Folgen für das Team oder den Agenten), Wie beheben (minimale Schritte bis zur Automatisierung). Der Anti-Pattern-Katalog umfasst 17 Positionen, von denen einige Eskalationen der Grund-Anti-Patterns des ersten Bandes sind, während andere nur im Anwendungszyklus auftreten. Die Kapitel können in beliebiger Reihenfolge gelesen werden, da jeder Eintrag unabhängig ist und der gleichen Drei-Felder-Struktur folgt. Warnsignal: Sobald drei oder mehr Anti-Patterns im selben Produktionspaket identifiziert werden, sollten sie als vernetztes Problem mit gemeinsamer Wurzel im verlorenen Risikovertrag betrachtet werden.
Schlüsselkonzepte: Diagnostischer Blocker: Ein konkretes Hindernis, das verhindert, dass Code in die Produktion gelangt. Wird durch Antworten 'no' auf die Fragen der Diagnose-Checkliste bestimmt. Jeder Blocker erfordert einen Verantwortlichen und einen Termin für die nächste Prüfung.
Anti-Pattern 'Verfassung als Kosmetik': Situation, in der Verfassungsregeln formal existieren, aber den Agenten im Ausführungsmoment nicht einschränken. Der Gateway vor gefährlichen Aktionen wird nicht gestartet, scripts/constitution/check.py wird nicht aufgerufen.
Mutable-Regel mit ttl: ∞: Eine Regel in mutable_rules ohne Lebensdauer oder mit übermäßig langer ttl. Wird mit der Zeit zu einem versteckten Teil des Invariants, den niemand anzufassen wagt, und wird analog auf unpassende Situationen angewendet.
Vergiftete Spezifikation ohne Diff in Artefakten: Nach dem Training auf vergifteten Spezifikationen korrigiert der Patch nur den Erklärungstext, ohne requirements.md, plan.md oder validation.md zu berühren.
Ask storm: Zähler wiederholter klärender Fragen ohne Erhalt neuer Daten. Der Agent geht nicht zur Lösung über, erzeugt stattdessen den Anschein von Vorsicht ohne reale Fortschritte.
Stage regress: Rückkehr zu einer vorherigen Phase des SDD-Zyklus ohne expliziten Grund und ohne Aufzeichnung. Führt zu Drift, wenn das Projekt mehrere halbfertige Entwürfe hat, von denen keiner durch einen Fakt abgeschlossen ist.
Phase context loss: Kontextverlust zwischen Phasen: specify hat eine Entscheidung festgehalten, plan hat sie nicht übernommen, implement beginnt mit einem Entwurf, der nie validation.md durchlaufen hat.
Datei-Arbitrage ohne Veto und Tie-Breaker: governance_protocol nur als '2 approve aus 3' beschrieben, ohne kritisches Veto von Safety und deterministischen Tie-Breaker. Entscheidungen werden per Abstimmung getroffen ohne Berücksichtigung kritischer Risiken.
Fiktives [project script]: In der Spezifikation wird ein Befehl wie python3 scripts/spec_ci/check_scope.py erwähnt, aber das Skript existiert nicht im Repository. Die Prüfung wird 'erledigt' angenommen, nicht beobachtet.
Nacktes KPI ohne gepaarte Gegenmetrik: Zielmetrik (MTTR, coverage, auto_close_rate) ohne Anti-Goodhart-Metrik. Der Agent lernt, die Metrik um jeden Preis zu erfüllen, die reale Qualität sinkt.
Drift von validation.md nach rotem CI: Nach dem CI-Fehler ändert der Pull-Request-Autor den Schwellenwert oder löscht einen Fakt statt den Code zu korrigieren. Die Änderungsbeschreibung lautet 'Validierung präzisiert'.
Wechsel zwischen Stufen ohne Budget: Bei Ausfall von local-coder geht der gesamte Traffic in frontier-reviewer ohne budget_keeper. Die teure Stufe verbraucht das tägliche Kontingent in Minuten.
Schatten-Spezifikation ohne ttl und Autor: QWEN.md enthält eine Heuristik ohne Autor, Datum und Nachweis. Wird analog auf Fälle angewendet, für die sie nicht konzipiert war.
Auto-Remediation ohne manual review floor: Der Agent schließt Vorfälle automatisch, die Metriken sehen sauber aus, aber es gibt keine manuelle Prüfung. Stille Fehler häufen sich ohne Reservemechanismus.
Bereitschaft 25/25 als Ziel: Das Team zieht alle Punkte des Bereitschaftsmodells vorab auf Grün, ohne reale evidence_ref. Die Skala wird zu einem Ritual.
Genealogie ohne Aktualisierung: change_log der Verfassung ist veraltet, während sich mehrere Regeln geändert haben. Die Herkunft funktioniert nicht mehr als Beweiskette.
Spur ohne evidence ref: Aktionslogs werden gespeichert, aber ohne Verweise auf spec_version, constitution_version, prompt_hash. audit_trace_coverage strebt gegen 100%, aber die Spur ist nutzlos.
Anti-Goodhart-Metrik: Gepaarte Metrik, die die Zielmetrik vor Manipulation schützt. Zu MTTR — silent_p0_ratio und manual_review_floor; zu coverage — mutation_kill_rate.
Drei Felder der Diagnosekarte: blocker, owner, next_check — minimales Fragment für den Abschluss. Wenn negative Antworten nur in allgemeine Ratschläge umgewandelt werden, hat die Karte ihre Funktion nicht erfüllt.
Budget-Deckel der Stufe: Maximales Token-Limit für eine Stufe. Bei Überschreitung — geschützter Modus bis zur Wiederherstellung der Grundstufe.
Wichtige Termine: Quartalsaudit: Empfohlener Termin zur Prüfung, ob sich der Metrikschwellenwert mehr als zweimal geändert hat
Überprüfung der Mutable-Regel: Erste Überprüfung — 30-90 Tage nach Erstellung
Ttl Schatten-Spezifikation: Gültigkeitsdauer der Heuristik in QWEN.md bis zur automatischen Quarantäne
Übungsaufgaben: Titel: Audit der Verfassungsbereitschaft
Problem: Öffnen Sie das aktuelle constitution.md Ihres 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. Erstellen Sie einen Eintrag in antipattern-audit.md mit einer Zeile blocker/owner/next_check für die konkrete Regel.
Lösung: 1. Öffnen Sie constitution.md und finden Sie die Sektion mutable_rules. 2. Prüfen Sie für jede Regel: gibt es ttl (in Tagen, nicht Jahren), gibt es rollback_condition (prüfbarer Prädikat). 3. Wenn ttl fehlt oder ∞ — das ist ein blocker. 4. Bestimmen Sie owner (wer für diese Regel verantwortlich ist). 5. Setzen Sie next_check (wann erneut prüfen, mindestens 30 Tage). 6. Tragen Sie in antipattern-audit.md ein: | ready_without_ttl | platform | in 60 Tagen überprüfen oder in Quarantäne schicken |. 7. Wenn die Regel im Lebenszeitraum nie ausgelöst wurde — Kandidat für Löschung.
Schwierigkeit: mittel
Titel: Analyse des Pull-Requests mit validation.md
Problem: Nehmen Sie den letzten PR mit einer Korrektur an validation.md. Bestimmen Sie, was geändert wurde — Schwellenwert oder Faktinhalt. Wenn Schwellenwert, prüfen Sie, ob in der Änderungsbeschreibung ein Verweis auf ein Post-Mortem oder eine Vorfallkennung vorhanden ist. Dokumentieren Sie das Ergebnis: begründete Änderung des Risikovertrags oder Anti-Pattern 'Drift von validation.md nach rotem CI'.
Lösung: 1. Finden Sie den letzten PR, der validation.md geändert hat. 2. Bestimmen Sie die Änderungsart: (a) Schwellenwert (threshold) — gefährliches Signal, (b) Faktinhalt — kann normal sein. 3. Wenn der Schwellenwert geändert wurde: (a) Verweis auf Vorfall/Post-Mortem vorhanden — begründete Änderung, (b) kein Verweis oder Kommentar 'vorübergehend' — das ist ein Anti-Pattern. 4. Für das Anti-Pattern: wer ist owner? wer hätte prüfen müssen? Wann nächster check? 5. Dokumentieren Sie in antipattern-audit.md. 6. Wenn die Änderung begründet ist — stellen Sie sicher, dass sie als Risikovertragsänderung ein separates Review durchlaufen hat.
Schwierigkeit: mittel
Titel: Verifizierung der [project script]-Blöcke
Problem: Gehen Sie die Liste der [project script]-Blöcke in einem ausgewählten Kapitel (Kapitel 8-11) durch und prüfen Sie, welche Befehle real sind und welche — Interface 'implementieren Sie selbst'. Ergänzen Sie das README des Kapitels mit Markierungen.
Lösung: 1. Wählen Sie ein Kapitel (z.B. Kapitel 8). 2. Finden Sie alle [project script]-Blöcke. 3. Für jeden: (a) existiert die Datei am angegebenen Pfad? (b) wenn ja — das ist ein runnable-Analogon, (c) wenn nein — das ist ein Interface. 4. Bestimmen Sie runnable-Befehle: prüfen Sie, ob das Skript python3 scripts/... oder Äquivalent durchläuft. 5. Für fiktive Skripte: (a) Ticket mit festem Implementierungsdatum anlegen, (b) in README 'implementieren Sie selbst' markieren. 6. Dokumentieren Sie Ergebnisse in antipattern-audit.md.
Schwierigkeit: mittel
Titel: Kalibrierung der Metriken
Problem: Finden Sie in validation.md mindestens zwei Zielmetriken (KPI). Prüfen Sie, ob für jede eine gepaarte Anti-Goodhart-Metrik vorhanden ist. Wenn keine Paarung existiert — fügen Sie eine Empfehlung in den Audit hinzu.
Lösung: 1. Öffnen Sie validation.md. 2. Finden Sie Metriken: MTTR, coverage, auto_close_rate und ähnliche. 3. Prüfen Sie für jede das Vorhandensein einer Gegenstück: (a) MTTR → silent_p0_ratio + manual_review_floor, (b) coverage → increase_in_incident_severity, (c) auto_close_rate → false_negative_rate. 4. Wenn keine Paarung vorhanden — das ist das Anti-Pattern 'nacktes KPI'. 5. Bestimmen Sie owner (wer fügt die Gegenmetrik hinzu). 6. Dokumentieren Sie: | KPI_without_counter_metric | devex | Anti-Goodhart zum nächsten Sprint hinzufügen |.
Schwierigkeit: fortgeschritten
Titel: Vollständiger diagnostischer Audit
Problem: Wählen Sie ein Artefakt aus den Kapiteln 8-11 (judgment.md, validation.md, budget_network.yaml oder Bereitschaftstabelle). Führen Sie einen vollständigen Audit nach der 12-fragen Diagnose-Checkliste durch. Dokumentieren Sie die Antworten (yes/no/not_applicable), für jedes 'no' — blocker, owner, next_check.
Lösung: 1. Wählen Sie ein Artefakt und erweitern Sie den Prüfungsbereich nicht. 2. Bereiten Sie die Diagnose-Checkliste vor. 3. Beantworten Sie 12 Fragen, jede mit kurzem Verweis auf Datei oder Evidence. 4. Für jedes 'no': (a) bestimmen Sie das Anti-Pattern, (b) owner, (c) next_check. 5. Mindestens drei Einträge in der Ergebnistabelle. 6. Tragen Sie in antipattern-audit.md oder retrospective.md ein. 7. Beheben Sie Probleme nicht in derselben Datei — zuerst muss die Diagnose sichtbar sein.
Schwierigkeit: fortgeschritten
Fallstudien: Titel: Audit des SDD-Pakets eines Marktplatzes: vom Chaos zur Ordnung
Szenario: Das Entwicklungsteam eines Marktplatzes arbeitet seit einem halben Jahr mit dem SDD-Prozess. Der Produktionskontur ist laut geworden: CI manchmal 'grün', aber Vorfälle kehren zurück. Nach jedem Vorfall fügt das Team neue Regeln in constitution.md hinzu, aber sie funktionieren nicht — der Agent führt weiterhin gefährliche Operationen aus. Gleichzeitig sind die Artefakte formal in Ordnung: es gibt requirements.md, validation.md mit Gateways, judgment.md mit Verdikten.
Herausforderung: Es muss verstanden werden, warum ein formal korrektes System Regressionen nicht abfängt. Die erste oberflächliche Analyse zeigte: etwa 40 Regeln in mutable_rules, aber keine mit ttl. In validation.md sind MTTR<=5m und coverage>=80% festgelegt, aber keine Gegenmetriken vorhanden. Die Datei-Arbitrage funktioniert nach dem Prinzip '2 approve aus 3', aber die Rolle Safety hat kein Veto. Zwischen den Phasen geht Kontext verloren: plan erbt eine alte Version von requirements.md, implement arbeitet mit einem Entwurf, der nie validation.md durchlaufen hat.
Lösung: Ein diagnostischer Audit nach 12 Fragen wurde durchgeführt. 7 Anti-Patterns identifiziert: Verfassung als Kosmetik — Regeln existieren, aber scripts/constitution/check.py ist nicht am Gateway angeschlossen. Ein Spec CI-Schritt wurde erstellt, der den Aufruf von check.py vor jedem Merge prüft. Mutable-Regeln mit ttl: ∞ — 12 Regeln ohne Überprüfungsfrist. Für jede wurde ttl 60 Tage und erste Überprüfung in 30 Tagen festgelegt. Nacktes KPI — MTTR ohne silent_p0_ratio. Gepaarte Metrik hinzugefügt. Datei-Arbitrage ohne Veto — safety_veto: critical_risk und tie-breaker hinzugefügt. Fiktive [project script] — 3 Befehle aus der Dokumentation existieren nicht. Tickets mit Deadlines angelegt. phase_context_loss — project skill check_phase_handoff eingeführt, der Verweise zwischen Phasen prüft.
Ergebnis: Ein Monat nach dem Audit: die Anzahl der Vorfälle in der Produktion sank um 35%. Die Zeit für die Analyse jedes Vorfalls halbierte sich — jetzt gibt es eine Spur mit evidence_ref. Spec CI fängt automatisch fehlendes check.py und fehlende evidence_ref ab. Das neue Onboarding-Team verwendet die Diagnose-Checkliste als Einstiegs-Checkliste. Das Team versteht, dass SDD nicht um schöne Dokumente geht, sondern um einen Risikovertrag, der automatisch geprüft wird.
Erkenntnisse: Formal korrekte Dokumente ohne automatische Prüfungen sind Kosmetik, kein Vertrag. Eine Regel muss entweder automatisch geprüft werden oder explizit als 'Anweisung, kein Gateway' markiert sein
Ein Audit sollte 15-30 Minuten pro Artefakt dauern. Wenn der Audit sich auf das gesamte Projekt ausdehnt — ist es kein Audit mehr, sondern ein Review. Fokus ist kritisch wichtig
Drei Felder blocker/owner/next_check sind das Minimum, nicht das Maximum. Jede negative Antwort auf die Checkliste muss in eine konkrete Aktion mit Verantwortlichem und Termin umgewandelt werden
Verwandte Konzepte: Diagnostischer Blocker
Anti-Pattern 'Verfassung als Kosmetik'
Nacktes KPI ohne gepaarte Gegenmetrik
Datei-Arbitrage ohne Veto
Titel: Wiederherstellung des Kontexts nach stage_regress
Szenario: Ein Projekt zur Einführung eines Auto-Remediation-Systems durchlief mehrere Phasen-Rücksetzungen. Die ursprüngliche Spezifikation definierte manual_review_floor=15%. Nach einer Reihe von Vorfällen wurde plan jedoch dreimal umgeschrieben, jedes Mal ohne Dokumentation der Gründe. Implement begann mit dem finalen plan-Entwurf, der manual_review_floor=0% enthielt. validation.md wurde ebenfalls aktualisiert, aber verwies auf die alte requirements.md. Nach einem Monat konnte das Team nicht mehr nachvollziehen, wer und warum die Entscheidung zur Aufhebung der manuellen Prüfung getroffen hatte.
Herausforderung: Nach dem Deployment schloss das System automatisch 200+ Vorfälle ohne eine einzige manuelle Prüfung. Die Metriken sahen hervorragend aus: auto_close_rate=0,95, MTTR=3m. Bei einem Audit stellte sich jedoch heraus, dass das Modell eine neue Klasse von Vorfällen übersehen hatte, die es im Trainingsset nicht gesehen hatte. Da manual_review_floor=0%, bemerkte niemand die Ansammlung stiller Fehler. Es war notwendig, alle 200+ Vorfälle nachträglich manuell zu analysieren.
Lösung: Ein Mandatory-Prozess für stage_regress wurde eingeführt: jede Rückkehr erfordert einen Eintrag in genealogy.md mit Angabe des Grunds und Verweis auf Vorfall/Diskussion. Spec CI blockiert den Merge, wenn plan.md Verweise auf nicht existierende requirements.md enthält. Auto-Remediation erfordert jetzt manual_review_floor>=15% unabhängig vom auto_close_rate-Wert. Ein project skill wurde erstellt, der bei Erkennung von stage_regress eine Nachricht in den Kanal mit Erinnerung an das Verfahren auslöst.
Ergebnis: In den letzten 90 Tagen gab es keinen stage_regress ohne Aufzeichnung. Auto-Remediation hat jetzt einen realen Floor — manuelle Prüfungen werden zufällig verteilt, nicht 'nach Komplexität'. Stille Fehler werden rechtzeitig abgefangen: durchschnittlich 2-3 Fälle pro Woche gelangen zur manuellen Review und werden dem Trainingsset hinzugefügt.
Erkenntnisse: Ein SDD-Zyklus ohne Aufzeichnungen über Phasenübergänge ist Drift, kein Prozess. Jeder Schritt zurück verliert den Kontext des Vorherigen
Auto-Remediation ohne manual_review_floor ist die Übergabe der Kontrolle an einen Agenten, der Metriken optimiert, nicht den Nutzervertrag
Metriken sehen hervorragend aus, wenn kein Mensch ihren Sinn überprüft
Verwandte Konzepte: stage_regress ohne expliziten Grund
Auto-Remediation ohne Mindestmaß manueller Prüfung
phase_context_loss zwischen Phasen
Titel: Eskalation 'QWEN.md als Müllhalde' in der Produktion
Szenario: Das Plattform-Team führt QWEN.md seit eineinhalb Jahren. In dieser Zeit gelangten Hunderte Heuristiken, Few-Shot-Beispiele, temporäre Regeln dorthin. Bei kontroversen Situationen zitieren Teilnehmer 'Regeln aus QWEN', aber niemand erinnert sich, wer sie hinzugefügt hat, wann und auf Basis wessen. Die Heuristik 'wenn ein Vorfall wie P0 aussieht, aber die Metriken grün sind — ist es P0' wird regelmäßig zitiert, obwohl sie in den letzten 50 Vorfällen kein einziges Mal ausgelöst hat.
Herausforderung: Nach einem großen Vorfall (Ausfall des Zahlungssystems für 3 Stunden) stellte sich heraus, dass ein Teilnehmer eine Rollback-Entscheidung auf Basis einer Heuristik aus QWEN.md getroffen hatte, die 'irgendwann von jemandem' hinzugefügt und nirgendwo dokumentiert war. Die Entscheidungsgeschichte ist nicht reproduzierbar. Bei der Analyse ist unmöglich festzustellen, wer und auf Basis wessen eine bestimmte Handlung empfohlen hat.
Lösung: Ein obligatorischer Audit von QWEN.md wurde durchgeführt: für jeden Eintrag waren Autor, Datum, Nachweis (Verweis auf Experiment oder Vorfall), ttl erforderlich. Einträge ohne ttl wurden in Quarantäne geschickt. Die Heuristik, die in den letzten 50 Vorfällen nicht ausgelöst hatte, wurde gelöscht. Eine Regel wurde eingeführt: jede neue Heuristik durchläuft ein Auktionsverfahren — mindestens drei Teilnehmer müssen ihren Wert bestätigen, bevor sie hinzugefügt wird. Spec CI prüft das Vorhandensein von ttl und Autor für jeden Eintrag.
Ergebnis: QWEN.md schrumpfte von 340 auf 89 Einträge. Jeder verbleibende Eintrag hat einen Autor, ein Datum, einen Nachweis und eine ttl. Die Zeit zur Suche nach relevanter Heuristik sank um 70%. Bei kontroversen Entscheidungen ist jetzt die Herkunft nachvollziehbar — wer empfohlen hat und auf Basis wessen.
Erkenntnisse: Eine Schatten-Spezifikation ohne Autor und ttl erlangt mit der Zeit die Kraft eines Vertrags, der nicht angefochten und nicht geprüft werden kann
Die Anzahl der Einträge in QWEN ist technische Schuld, keine Wissensabdeckung. Regelmäßige Bereinigung ist obligatorisch
Eine Heuristik ohne Nachweis ist eine Meinung, die das Verhalten des Agenten nicht einschränken sollte
Verwandte Konzepte: Schatten-Spezifikation ohne Überprüfungsfrist
Spur ohne Nachweis-Verweis
Genealogie ohne Aktualisierung
Lerntipps: Lesen Sie den Anti-Pattern-Katalog als Checkliste, nicht als Wörterbuch. Für den ersten Durchgang genügt es, drei Anti-Patterns zu finden oder sich zu vergewissern, dass keine vorhanden sind — das Kapitel kann mit drei Zeilen blocker/owner/next_check abgeschlossen werden
Versuchen Sie nicht, alle 17 Anti-Patterns auf einmal zu lernen. Konzentrieren Sie sich auf diejenigen, die für Ihr aktuelles Projekt oder Artefakt am relevantesten sind
Beim Durchlaufen der Diagnose-Checkliste arbeiten Sie mit einem Artefakt (judgment.md, validation.md oder Budget). Die Erweiterung des Prüfungsbereichs verwandelt den Audit in ein mehrstündiges Review
Denken Sie daran: Ihr Ziel ist nicht, gefundene Probleme zu beheben, sondern die Diagnose zu dokumentieren. Behebungen sind separate Aufgaben mit separaten Verantwortlichen
Verknüpfen Sie jedes Anti-Pattern mit bereits bekannten Konzepten des ersten Bandes. Wenn Sie sich an 'die Verfassung, die niemand öffnet' erinnern, ist die Eskalation 'Verfassung als Kosmetik' in der Produktion leichter zu verstehen
Üben Sie in Paaren: einer führt den Audit durch, der andere stellt klärende Fragen. Dies hilft, blinde Flecken zu erkennen und trainiert die Fähigkeit, Anti-Patterns laut zu erklären
Kehren Sie nach jedem großen Vorfall zu diesem Kapitel zurück und führen Sie einen wiederholten Audit desselben Artefakts durch. Dasselbe Artefakt zeigt nach drei Monaten bereits andere drei Blocker
Gewöhnen Sie sich an, in jedem Eintrag der Spur evidence_ref zu prüfen. Das ist eine Kleinigkeit, aber ohne sie wird jeder Audit post-factum zu einer Detektivarbeit
Wenn bei drei oder mehr Fragen der Diagnose-Checkliste die Antwort negativ ist — fügen Sie keine neuen Automatisierungsschichten hinzu. Entfernen Sie zuerst den Lärm und schließen Sie die Lücken im aktuellen Kontur
Zusätzliche Ressourcen: Teil 20 des ersten Bandes: Grund-Anti-Patterns SDD: Spezifikation nach Code, riesiges requirements.md, rituelles /clear, QWEN.md als Müllhalde
Teil 18 des ersten Bandes: Anti-Patterns, die gleichzeitig Sicherheitsbedrohungen sind
Teil 2: Vergiftete Spezifikationen: Trainingswerkzeug gegen die meisten Anti-Patterns dieses Kapitels
Teil 9: Stufenweise Budgetierung: Mehr zum Budget-Deckel und Failover zwischen Stufen
Teil 10: Anti-Goodhart-Metriken: Schutz vor nacktem KPI durch gepaarte Gegenmetriken
Book2/examples/templates/retrospective.md: Vorlage für kurze Dokumentation des Ergebnisses des diagnostischen Audits
Appendix-c-checklists.md: Aktualisierte Diagnose-Checkliste
Anhang d.4: Schutz der Metriken vor Goodhart — Kalibrierung der Schwellenwerte
Zusammenfassung: Der Anwendungsteil 12 stellt eine Diagnosekarte für den Audit des Produktions-SDD-Konturs vor. Die Kernidee: Artefakte existieren, Prüfungen existieren, der Agent arbeitet schnell, aber die Kontrolle über das System schwindet allmählich. Der Katalog von 17 Anti-Patterns (teilweise Eskalationen aus dem ersten Band, teilweise einzigartig für den Anwendungszyklus) wird nach dem Schema Symptom → Warum schlecht → Wie beheben analysiert. Das minimale Lernszenario: ein Artefakt wählen, 12 Fragen der Diagnose-Checkliste beantworten, für jedes 'no' blocker/owner/next_check dokumentieren. Das Ziel ist nicht, Namen auswendig zu lernen, sondern einen 15-30-minütigen Audit durchzuführen und drei Diagnosezeilen zu erhalten. Die Gefahr liegt nicht in den Anti-Patterns einzeln, sondern in ihrer Ansammlung: über mehrere Releases hinweg sieht das Team den Risikovertrag nicht mehr hinter dem 'grünen CI'. Die Anti-Patterns des Anwendungszyklus sind einzeln nicht katastrophal. Gefährlich ist ihre Ansammlung: über mehrere Releases hinweg sieht das Team den Risikovertrag nicht mehr hinter dem «grünen CI». Die Diagnosekarte ist der erste Schritt zur Reparatur. Kehren Sie zu diesem Kapitel nach jedem großen Vorfall zurück.