Thema: Anhang C. Checklisten für angewandtes SDD
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 8–12 Stunden (Theorie + Praxis)
Voraussetzungen: Abgeschlossenes Studium des ersten Bandes des SDD-Kurses (Grundchecklisten vor Spezifikation, Implementierung und Merge)
Verständnis der Artefaktstruktur: requirements.md, plan.md, validation.md, QWEN.md
Erfahrung mit CI/CD und grundlegendes Verständnis von Git-Workflows
Vertrautheit mit den Konzepten: Domänenmodell, API-Vertrag, JSON Schema
Gelesener Teil 0 des angewandten Bandes (Auswahl des Lern-Incident-Cases)
Lernziele: Checklisten aus Anhang C als operatives Nachschlagewerk in jeder Phase des angewandten SDD-Zyklus anwenden, von der Vorbereitung bis zur abschließenden Production-Abnahme
Qualitätskontrollmechanismen implementieren: Spezifikations-Gateways (Spec CI), Datei-Schiedsverfahren, vergiftete Spezifikationen und automatische Remediation mit klaren Rollback-Bedingungen
Antimuster des angewandten Zyklus anhand der 12-Punkte-Diagnostik erkennen und beseitigen, mit Entscheidung zur Automatisierungsstoppung bei ≥3 Fehlschlägen
Vollständiges Capstone-Artefakt-Paket mit Traceability erstellen: genealogy.md, poisoned/fixed-Paare, judgment.md und Nachweisbasis
Überblick: Anhang C des angewandten Bandes ist ein operatives Nachschlagewerk — eine Erweiterung der Grundchecklisten des ersten Bandes. Er umfasst acht kritische Kontrollpunkte des angewandten Zyklus: Arbeitsvorbereitung, Wiederherstellung der Spezifikation aus Legacy-Systemen, Einführung vergifteter Spezifikationen zur Prozessvalidierung, Aktivierung von Spec CI, Datei-Schiedsverfahren bei strittigen Änderungen, Optimierung von Production-Metriken mit Schutz vor dem Goodhart-Effekt, automatische Incident-Remediation, Antimuster-Audit und abschließende Production-Abnahme. Jede Checkliste ist als Gateway konzipiert: das Bestehen der Prüfungen ist für den Übergang zur nächsten Phase zwingend erforderlich. Prozessvorlagen (Merge-Request, Retrospektive, Prompts für /clear und Replanung) sind im Verzeichnis examples/templates/ ausgelagert. Besonderheit der angewandten Ebene ist der Übergang von „Vorhandensein von Artefakten“ zu „nachweislicher Funktion der Artefakte unter Production-Bedingungen“: jede Anforderung ist nachverfolgbar, jede Änderung begründet, jedes Risiko durch einen Invarianten kontrolliert.
Schlüsselkonzepte: Spezifikations-Gateway (Spec CI): Automatisierte Prüfung, die den Fortschritt von Änderungen bei Verletzung struktureller Regeln blockiert. Anforderungen: stabile REQ-*-Identifikatoren, Rückwärts-Traceability des Plans auf Anforderungen, Validierung von JSON-Beispielen gegen Schema, informative Fehlermeldungen (Datei, Zeile, Regel, Grund, Aktion). Spec CI fungiert als „Tor vor der Ausführung“, nicht als Review danach.
Vergiftete Spezifikation (poisoned spec): Validierungsmethode für den Prozess: es wird genau ein kontrollierter Defekt eingeführt, das erwartete Symptom beschrieben, das Wiederherstellungskriterium festgelegt. Die Korrektur muss spec/plan/validation betreffen, nicht nur textuelle Erklärung. Prüft, ob das Qualitätskontrollsystem in der Lage ist, einen Fehler zu erkennen und zu lokalisieren.
Datei-Schiedsverfahren: Mechanismus zur Streitbeilegung durch Diff in Dateien, nicht durch Diskussionen im Chat. Rollen: Koordinator (Prozess), Implementor (Code), Verifikator (prüfbare Nachweise). Wiederkehrende Entscheidungen werden in precedents.md festgehalten. Es gibt eine Stopp-Bedingung für den Übergang zum manuellen Review.
Goodhart-Effekt und Anti-Goodhart-Metriken: Prinzip: Wenn eine Metrik zum Ziel wird, hört sie auf, eine gute Metrik zu sein. Schutz: jeder Zielmetrik ist eine gepaarte Invarianten-Metrik zugeordnet, es gibt eine „Roter-Knopf“-Regel für Stopp bei Verhaltensverzerrung. Eine Schwellenwertänderung ist eine Risikoänderung, die einem Verfahren folgen muss.
Wirkungsradius (blast radius): Grenze der betroffenen Systeme bei automatischer Remediation. Kontrollfragen: ist der Radius bekannt, gibt es Dry-Run, ist die Rollback-Bedingung vor Ausführung dokumentiert, ist manuelle Bestätigung bei Radiuserweiterung oder wiederholtem Fehlschlag erforderlich. Hochriskante Incidents erfordern zwei unabhängige Wiederherstellungsbestätigungen.
Spur (trace) und evidence ref: Reproduzierbarer Identifikator einer Entscheidung: Quelle, Version der Richtlinie, Hash des Prompts. Jeder Eintrag in QWEN.md enthält Autor, Nachweis und TTL. Das Feld evidence_ref ist für alle Spureinträge zwingend. Gewährleistet Auditierbarkeit und Debugging von Systemdrift.
Mutable rules und ttl: Regeln mit begrenzter Geltungsdauer. Verbot: Regeln ohne TTL oder mit TTL > 90 Tagen. Erzwungene Überprüfung verhindert das Erstarren veralteter Einschränkungen und die Akkumulation technischer Schulden in der Governance.
Budget ceiling und Stufen (tiers): Finanzielle und operative Kontrolle beim Wechsel zwischen Systemebenen. Jeder Wechsel hat ein Budget-Limit und einen Notfallmodus. Verhindert unkontrolliertes Kostenwachstum bei Skalierung.
Manual review floor: Unverrückbares Minimum an manueller Prüfung, unabhängig vom KPI-Wert. Schutz vor vollständiger Automatisierung kritischer Entscheidungen. Bleibt auch bei Erreichen hoher Automatisierungsgrade erhalten.
Genealogy.md: Artefakt des Abschlusspakets: Anforderung, Quellen, Vertrauensniveau, offene Frage. Gewährleistet Transparenz über die Herkunft jedes Spezifikationselements und Ehrlichkeit über Unsicherheit.
Übungsaufgaben: Titel: Readiness-Audit für den angewandten Zyklus
Problem: Sie haben das Repository eines Teams erhalten, das behauptet, für den angewandten Band bereit zu sein. Prüfen Sie folgende Fakten: (1) das Verzeichnis capstone/ fehlt, (2) in der README gibt es keine Unterscheidung zwischen [runnable] und [project script], (3) requirements.md existiert, aber plan.md verweist implizit darauf durch Text, nicht durch REQ-*-Identifikatoren, (4) validation.md enthält JSON-Beispiele ohne Schema. Erstellen Sie eine Liste von Blockern und einen Behebungsplan mit Prioritäten.
Lösung: Schritt 1: Blocker — Fehlen von capstone/. Aktion: Verzeichnisstruktur erstellen, Abschlusspaket planen. Schritt 2: Blocker — keine Typunterscheidung bei Befehlen. Aktion: alle Kapitel durchgehen, explizit kennzeichnen, README aktualisieren. Schritt 3: Blocker — keine stabilen Identifikatoren. Aktion: REQ-*-Nummerierung einführen, plan.md mit direkten Verweisen aktualisieren. Schritt 4: Blocker — nicht validierbare Beispiele. Aktion: JSON Schema erstellen, Validierung in CI hinzufügen. Priorität: 3 und 4 — kritisch für Spec CI, 1 und 2 — kritisch für Abschlussabnahme. Frist: 2 Arbeitstage.
Schwierigkeit: mittel
Titel: Entwurf einer vergifteten Spezifikation
Problem: Ihr Zahlungsverarbeitungssystem hat die Anforderung REQ-PAY-07: „Timeout der Operation — 30 Sekunden“. Erstellen Sie eine vergiftete Spezifikation: führen Sie genau einen Defekt ein, beschreiben Sie das erwartete Symptom, legen Sie das Wiederherstellungskriterium fest. Stellen Sie sicher, dass die Korrektur mindestens zwei Artefakte aus spec/plan/validation betrifft.
Lösung: Schritt 1: Defekt — Timeout in plan.md auf 300 Sekunden ändern (im Konfigurationsabschnitt des Services), requirements.md unverändert lassen. Schritt 2: Symptom — Metrik p99 Latency steigt über 45 Sekunden, Benutzer erhalten Timeout auf Client-Seite, bevor der Server die Operation beendet, was zu doppelten Zahlungen führt. Schritt 3: Wiederherstellungskriterium — p99 Latency < 10 Sekunden, keine Duplikate in validation.md (Prüfung per trace_id). Schritt 4: Korrektur betrifft: plan.md (Rückkehr zu 30 Sekunden), validation.md (Hinzufügung der Konsistenzprüfung von trace_id + Timeout). requirements.md erfordert keine Änderung, was die Trennung der Verantwortlichkeiten demonstriert.
Schwierigkeit: mittel
Titel: Incident-Analyse nach Anti-Goodhart-Protokoll
Problem: Ein Team hat die Metrik „Anzahl geschlossener Tickets pro Tag“ optimiert. Nach einem Monat: Tickets werden in 2 Minuten geschlossen, aber die Reinzidenzrate ist um 400% gestiegen, die Kundenzufriedenheit ist gefallen. Die Metrik hat das Ziel von 150% erreicht. Das Team möchte „die Latte auf 200% anheben“. Wenden Sie die Checkliste vor der Metrikoptimierung an.
Lösung: Schritt 1: Stopp — Roter-Knopf-Regel anwenden: Reinzidenzanstieg > 50% ist Stopp-Bedingung. Schritt 2: Trennung: Zielmetrik (Tickets/Tag) getrennt von Invariante (Reinzidenz < 10%, NPS > 30). Schritt 3: Replay: nicht nur Aggregate (Durchschnitt) prüfen, sondern Verhaltensdrift — Verteilung der Lösungszeiten, Korrelation „schnelle Schließung → Wiedereröffnung“. Schritt 4: Spur: Version der Richtlinie dokumentieren, Hash des Prompts, der die 150%-Entscheidung getroffen hat. Schritt 5: Schwellenwertänderung — als Risikoänderung behandeln: Anti-Goodhart-Metrikanalyse erforderlich, Safety-Abstimmung, Aktualisierung von governance_protocol. Ergebnis: Anhebung auf 200% — abgelehnt, Rückkehr zu 100% mit Hinzufügung der Reinzidenz-Invariante.
Schwierigkeit: fortgeschritten
Titel: Simulation des Datei-Schiedsverfahrens
Problem: Streitfall: Implementor hat in plan.md den Schritt „API-Antworten für 24 Stunden cachen“ hinzugefügt, Verifikator lehnt ab — Anforderung REQ-DATA-03 verlangt „Datenaktualität innerhalb von 1 Stunde“. Koordinator hat 15 Nachrichten im Chat mit Argumenten erhalten. Wenden Sie das Datei-Schiedsverfahren-Protokoll an.
Lösung: Schritt 1: Diskussion im Chat stoppen, Umstellung auf Datei-Schiedsverfahren verkünden. Schritt 2: Implementor erstellt Branch mit zwei Varianten von plan.md: (A) Original mit 24h-Cache, (B) modifiziert mit 1h-Cache + Fallback auf stale-Daten. Schritt 3: Verifikator liefert prüfbaren Nachweis: Diff zwischen (A) und (B), JSON-Test mit Time-Travel-Prüfung der Aktualität, CI-Logs für beide Varianten. Schritt 4: Entscheidung: (B) annehmen, in precedents.md festhalten: „Bei Konflikt zwischen Cache und Aktualität — Fallback auf stale mit TTL=erforderliche Aktualität“. Schritt 5: Stopp-Bedingung: wenn der Streit die Speicherarchitektur betrifft — Eskalation an Architekturkomitee. Lösungszeit: 2 Stunden statt 2 Tage Chat-Korrespondenz.
Schwierigkeit: mittel
Titel: Antimuster-Audit: Entscheidungsfindung
Problem: Führen Sie ein Audit eines hypothetischen Teams anhand der 12-Punkte-Checkliste durch. Fakten: (1) constitution.md wird nur am Sprintende geprüft, (2) 3 Regeln in mutable_rules ohne TTL, (3) nach Fehlschlag der vergifteten Spezifikation wurde nur die Erklärung in der README geändert, (4) CI fällt aus — validation.md wurde abgeschwächt, (5) der Metrik „Deployments/Tag“ fehlt die Anti-Goodhart-Paarung. Alle übrigen Punkte positiv. Welche Entscheidung erfordert Anhang C?
Lösung: Schritt 1: Zählung negativer Antworten: 5 Punkte (1, 2, 3, 4, 5). Schritt 2: Regel anwenden: ≥3 negative Antworten → Verbot neuer Automatisierungsschichten. Schritt 3: Priorisierung: Punkt 4 (Abschwächung von validation bei CI-Ausfall) — kritisch, erfordert sofortigen Revert und Root-Cause-Analyse. Punkt 3 — zweitkritisch, erfordert erneute Durchführung des vergifteten-Spezifikation-Zyklus mit Artefaktänderungen. Punkt 2 — operativ, Eigentümer zuweisen, TTL 90 Tage setzen. Punkte 1 und 5 — strukturell, in Sprintplan aufnehmen. Schritt 4: Kontrolle: nach 2 Wochen erneutes Audit, Ziel ≤2 negative Antworten.
Schwierigkeit: fortgeschritten
Fallstudien: Titel: Einführung von Spec CI in der Zahlungsplattform eines Fintech-Startups
Szenario: Startup mit 50 Microservices, 8 Teams, täglich 200+ PRs. Problem: 40% der Production-Rollbacks durch Nichtübereinstimmung zwischen Implementierung und Anforderungen verursacht, wobei requirements.md existierte, aber nicht mit Code verknüpft war. Management-Entscheidung: „Automatisierung innerhalb eines Monats einführen“.
Herausforderung: Teams verstanden die Anforderung als „noch ein CI“. Sie führten eine Prüfung auf Vorhandensein der Datei requirements.md ein, nicht auf Struktur. Nach 2 Monaten: Dateien vorhanden, aber REQ-*-Identifikatoren dupliziert, plan.md verweist auf nicht existierende Anforderungen, JSON-Beispiele in validation.md nicht validierbar. Rollbacks nicht gesunken. Management forderte „mehr Automatisierung“ — ML-Prüfung der Semantik hinzufügen.
Lösung: Checkliste „Vor Aktivierung des Spezifikations-Gateways“ aus Anhang C angewendet. Stopp: 7 Verstöße gegen 5 Checklistenpunkte festgestellt. Entscheidung — kein ML hinzufügen, sondern grundlegende Fehlschläge schließen. Maßnahmen: (1) Standardisierung von REQ-* mit Domänenpräfix (PAY-, AUTH-, LED-), (2) Einführung der Rückwärts-Traceability: jeder Punkt in plan.md beginnt mit [REQ-...], (3) JSON Schema für alle API-Beispiele, (4) strukturierte CI-Meldungen: Datei, Zeile, Regel, Grund, Aktion. Schlüsselpunkt: Spec CI als obligatorischer Status-Check konfiguriert — PR wird bei Fehlschlag blockiert.
Ergebnis: Nach 6 Wochen: Rollbacks durch Anforderungsinkonsistenz von 40% auf 8% gesenkt. Review-Zeit um 30% verkürzt, da Verifikatoren maschinell prüfbare Artefakte erhielten. Nach 4 Monaten: Anti-Goodhart-Metrik „Zeit von Inkonsistenz-Erkennung bis Korrektur“ hinzugefügt — Verzerrung zu „schönen, aber nutzlosen“ requirements.md verhindert.
Erkenntnisse: Automatisierung ohne grundlegende Gateways verstärkt Chaos, nicht Ordnung — die ≥3-Fehlschläge-Regel funktioniert
CI-Meldungen müssen umsetzbar sein: Entwickler investiert < 2 Minuten in Ursachenverständnis des Fehlschlags
Rückwärts-Traceability plan→requirements ermöglicht automatische Auffindung betroffener Aufgaben bei Anforderungsänderung
Verwandte Konzepte: Spezifikations-Gateway (Spec CI)
Rückwärts-Traceability von Anforderungen
Automatisierungsstopp-Regel bei ≥3 Fehlschlägen
Titel: Auto-Remediation eines Incidents mit kontrolliertem Wirkungsradius
Szenario: Cloud-Provider, System zur automatischen Kubernetes-Cluster-Skalierung. Nächtlicher Peak-Incident: API-Latency um 300% gestiegen, Trigger ausgelöst, System begann Skalierung — erstellte 500 neue Pods statt 50, erschöpfte Cluster-Budget und verursachte kaskadierenden Ausfall benachbarter Services.
Herausforderung: Ursprüngliches Auto-Remediation-System hatte nicht: (1) Wirkungsradius-Begrenzung, (2) Dry-Run für Skalierung, (3) dokumentierte Rollback-Bedingung, (4) manuelle Bestätigung bei Erweiterung. „Intelligentes“ System traf Entscheidung auf Basis von Aggregaten ohne Verhaltensdrift-Prüfung.
Lösung: Checklisten „Vor Optimierung von Production-Metriken“ und „Vor Auto-Remediation“ angewendet. Eingeführt: (1) Wirkungsradius — maximal 2x aktuelle Replikazahl für einen Service, kaskadierende Skalierung ohne manuelle Bestätigung verboten; (2) Dry-Run: Kubernetes-Scheduler-Simulation mit Ressourcenabschätzung; (3) Rollback-Bedingung: wenn Latency nach Skalierung nicht innerhalb 5 Minuten sinkt — Rückkehr zum Ursprungszustand; (4) doppelte Wiederherstellungsbestätigung für Incidents mit Radius > 1 Service.
Ergebnis: Nächster vergleichbarer Peak: System erstellte 45 Pods (innerhalb 2x-Grenze), Latency normalisierte sich. Dry-Run prognostizierte CPU-Erschöpfung im Cluster — Trigger wechselte in Notfallmodus mit Traffic-Umleitung in Reserve-Region. Wiederherstellungszeit von 47 Minuten auf 8 verkürzt. Incident-Kosten: von $120K (SLA-Strafen + Ressourcenüberverbrauch) auf $3K (Traffic-Switching).
Erkenntnisse: Wirkungsradius ohne Begrenzung ist keine Auto-Remediation, sondern Auto-Katastrophe
Dry-Run in verteilten Systemen muss globale Ressourcen berücksichtigen, nicht nur lokale Metriken des Ziel-Services
Vor Ausführung dokumentierte Rollback-Bedingung verhindert „Vergessen“ in Incident-Panik
Verwandte Konzepte: Wirkungsradius (Blast Radius)
Dry-Run und sichere Vorabprüfung
Roter-Knopf-Regel für Goodhart-Effekt
Doppelte Wiederherstellungsbestätigung
Titel: Abschließende Production-Abnahme: vom Chat zur Nachweisbasis
Szenario: Ein 4-Personen-Team beendete ein 6-monatiges Projekt zur Migration des Abrechnungssystems. Bei Vorbereitung zur Abnahme festgestellt: capstone/README.md enthält Kopie der Chat-Historie mit dem Kunden, genealogy.md fehlt, judgment.md — ein Satz „alles funktioniert“, keine poisoned/fixed-Paare.
Herausforderung: Das Team verstand den angewandten Zyklus als „Code schreiben und im Chat erklären“. Artefakte wurden retrospektiv erstellt, ohne Traceability. Kunde forderte auditierbare Basis für regulatorische Prüfung (PCI DSS).
Lösung: Checkliste „Vor abschließender Production-Abnahme“ als Wiederherstellungsrahmen angewendet. Maßnahmen: (1) README.md neu geschrieben: Case durch Domänenmodell beschrieben, ohne Chat-Erwähnung; (2) genealogy.md für jede kritische Anforderung erstellt (PAN-Speicherung, Verschlüsselung, Audit) — mit Quelle (PCI DSS Punkt), Vertrauensniveau (hoch/mittel/niedrig), offener Frage; (3) poisoned/fixed-Paar wiederhergestellt: Defekt in PAN-Validierung eingeführt, Korrektur in validation.md dokumentiert; (4) judgment.md: Verdikt „bedingt geeignet“, Grund — 2 mittlere Vertrauensniveaus in genealogy, evidence_ref auf Tests, nächster Schritt — Neubewertung nach Quartal; (5) Budget- und Anti-Goodhart-Schichten mit blockierenden Invarianten hinzugefügt.
Ergebnis: Abnahme mit Vermerk „erfordert Vertrauensverbesserung“ bestanden. Regulatorische Prüfung: genealogy.md als Nachweis der Anforderungsherkunft akzeptiert. Nach Quartal: 2 offene Fragen geschlossen, Vertrauensniveau erhöht, judgment.md auf „geeignet“ aktualisiert. Team führte parallele genealogy-Erstellung während der Entwicklung ein, nicht retrospektiv.
Erkenntnisse: Im Prozess erstelltes genealogy.md erfordert 10% Zeit; retrospektiv wiederhergestelltes — 300%
Offene Fragen in genealogy — kein Zeichen von Schwäche, sondern von Ehrlichkeit; ihr Fehlen erweckt Misstrauen
Judgment.md mit Verdikt „bedingt geeignet“ und Plan ist wertvoller als „geeignet“ ohne Begründung
Verwandte Konzepte: Genealogy.md und Vertrauensniveau
Poisoned/fixed-Paar als Prozessnachweis
Judgment.md mit Verdikt und nächstem Schritt
Readiness-Ergebnis: Trennung von Blockern und Verbesserungen
Studientipps: Checklisten nicht als Formalität, sondern als Gateway durchlaufen: bei negativer Antwort — Stopp und Behebung, nicht Häkchen „später korrigieren“
Erstellen Sie einen physischen oder digitalen „Projektpass“ — Tabelle mit 8 Kontrollpunkten aus Anhang C, mit Datum des Bestehens, Eigentümer, Verweis auf Nachweis
Für visuelle Lernende: bauen Sie einen Flussdiagramm — von „Vor Beginn“ bis „Abschlussabnahme“ — und markieren Sie, welche Vorlagen aus examples/templates/ in jeder Phase verwendet werden
Für Praktiker: nehmen Sie Ihr aktuelles Projekt und führen Sie ein Audit anhand der 12-Punkte-Antimuster-Checkliste durch; die reale Zählung negativer Antworten wirkt stärker als theoretisches Lesen
Für auditive Lernende: diskutieren Sie Fälle in Paaren — die Rollen Koordinator, Implementor, Verifikator beim Datei-Schiedsverfahren werden durch Spielen besser verstanden
„Präzedenzfälle“ (precedents.md) vom ersten Streitfall an festhalten — Zeitersparnis bei wiederkehrenden Situationen übersteigt den Dokumentationsaufwand
TTL als „Erinnerung an den Tod“ für Regeln nutzen: Kalendererinnerungen eine Woche vor Ablauf setzen
Zusätzliche Ressourcen: Prozessvorlagen (examples/templates/): pr-template.md — Struktur des Merge-Requests mit obligatorischen Anforderungsverweisen; retrospective.md — Retrospektivformat mit Fokus auf Nachweis; clear-prompt.md und replan-prompt.md — minimale Prompts für /clear und Replanung
Teil 0 — Production Lab: Auswahl und Vorbereitung des Lern-Incident-Cases, Unterscheidung von [runnable] und [project script], Erstellung von capstone/
Teil 12 — Production Antipatterns: Vollständige Analyse der 12 Antimuster, auf die die Schnell-Checkliste aus Anhang C abzielt
Anhang C des ersten Bandes: Grundchecklisten: vor Spezifikation, Implementierung, Merge — Fundament, auf dem die angewandte Ebene aufbaut
JSON Schema Specification: Dokumentation zur Erstellung von Validierungsschemata für validation.md (json-schema.org)
PCI DSS Requirements Checklist: Beispiel einer externen Anforderungsquelle für Übung zur Erstellung von genealogy.md mit regulatorischer Traceability
Zusammenfassung: Anhang C des angewandten Bandes verwandelt SDD von einer Methodik in ein Betriebssystem: acht Kontrollpunkte mit klaren Gateways, 12-Punkte-Antimuster-Audit als Prozessgesundheitssensor, abschließende Abnahme mit Nachweisbasis. Schlüsselprinzipien: Gateways vor Ausführung (nicht Review danach), Datei-Schiedsverfahren statt Chat-Diskussionen, Anti-Goodhart-Schutz für Metriken, kontrollierter Radius der Auto-Remediation, Automatisierungsstopp bei ≥3 Fehlschlägen. Erfolgreiche Anwendung erfordert nicht Auswendiglernen von Punkten, sondern innere Annahme der Kultur: „Negative Antwort ist kein Fehlschlag, sondern ein verhinderter Fehlschlag in Production“.