Thema: Angewandter Teil 2. Diagnose von Spezifikationsdefekten
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 8-12 Stunden (Theorie: 3 Stunden, Praxis: 5-9 Stunden)
Voraussetzungen: Teil 7 des ersten Bandes: negative Anforderungen (negative requirements)
Teil 20 des ersten Bandes: SDD-Antipatterns (SDD antipatterns)
Teil 11 des ersten Bandes: Einführung in die Domäne appointments-api und Hono JSX
Grundlegende Kenntnisse in YAML/JSON und JSON Schema
Erfahrung mit Qwen Code im Plan Mode
Verständnis des SDD-Lebenszyklus: Specify → Plan → Tasks → Implement
Lernziele: Selbstständig genau einen kontrollierten Defekt in die Spezifikation der Incident-Triage einbringen, klassifiziert als cycle, priority_conflict oder hidden_out_of_scope
Den Stillstandspunkt von Qwen Code durch messbare Metriken ask_storm, stage_regress und phase_context_loss mit Dokumentation in validation.md diagnostizieren
Eine überprüfbare Ausnahmeregel (override) formulieren, die einen Prioritätskonflikt auflöst, und diese in Given/When/Then + JSON Schema übertragen
Einen vollständigen Rücklauf des SDD-Zyklus Specify → Plan → Tasks → Implement zur Überprüfung der Stabilität der Korrektur durchführen
Ein poisoned/fixed-Paar von Spezifikationen mit einer einzigen Wiederherstellungszeile in validation.md erstellen, das für die Übernahme in das Capstone-Projekt geeignet ist
Überblick: Dieser Studienführer widmet sich der Ingenieurtechnik der „kontrolliert defekten Spezifikation“ – einer Methode des absichtlichen Einfügens eines Defekts in die Spezifikation der Incident-Triage mit dem Ziel, die diagnostischen Fähigkeiten des Agenten (Qwen Code) zu überprüfen und die Wiederherstellung von Anforderungen zu üben. Die Technik ist verwandt mit dem Mutationstesting, wird jedoch auf der Spezifikationsebene und nicht auf Code-Ebene angewendet. Schlüsselprinzip: eine Mutation, ein Symptom, ein Wiederherstellungskriterium. Das Kapitel baut auf dem Material des ersten Bandes auf (negative Anforderungen und SDD-Antipatterns) und entwickelt diese in Richtung eines kontrollierten Experiments weiter: Statt zufälliger Ausfälle erzeugen Sie einen vorhersagbaren, messbaren und behebbaren Defekt. Der Übungsfall ist die Latenzsteigerung der appointments-api-Route; der Prüfungsfall für das Capstone ist high_memory_usage. Das Ergebnis der Arbeit ist eine funktionierende Technik der reproduzierbaren Zerstörung und Wiederherstellung der Spezifikation als stabiler Vertrag.
Schlüsselkonzepte: Kontrollierter Defekt (controlled defect): Ein absichtlich eingefügter Defekt in die Spezifikation, begrenzt nach Klasse und Lokalisierung. Wird der zufälligen Fehler oder der Ansammlung mehrerer Defekte gegenübergestellt. Hauptregel: eine Mutation pro Iteration, ein erwartetes Symptom, ein Wiederherstellungskriterium. Wird zur Überprüfung der diagnostischen Fähigkeiten des Agenten und zur Übung der Wiederherstellungstechnik verwendet.
Vergiftete Spezifikation (poisoned specification): Ein didaktisches Etikett für eine Spezifikation mit einem kontrollierten Defekt. Nicht wörtlich zu verstehen: „Gift“ bedeutet kein Chaos, sondern eine streng dosierte Mutation. Wird als poisoned-spec.md erstellt und in fixed-spec.md korrigiert mit Dokumentation in validation.md.
Poisoned/Fixed-Paar: Ein Paar von Artefakten: poisoned-spec.md (Spezifikation mit Defekt) und fixed-spec.md (Spezifikation nach der Korrektur). Der Unterschied zwischen ihnen ist genau eine Mutation und ihr Patch. Das minimale prüfungsrelevante Set für das Capstone umfasst die Defektklasse, die Wiederherstellungszeile und die Tatsache der Nicht-Reproduktion des Konflikts.
Defektklassen – cycle: Zyklische Abhängigkeit zwischen Zuständen in der Triage-Spezifikation. Beispiel: WAIT_APPROVAL → VALIDATE_ESCALATION → WAIT_APPROVAL. Der Agent verfängt sich in einer Schleife und kann den endlichen Automaten nicht verlassen. Wird durch die Suche nach Zyklen im Zustandsgraphen überprüft (find_spec_loops.py).
Defektklassen – priority conflict: Zwei Regeln mit derselben Priorität, die zu sich gegenseitig ausschließenden Aktionen führen. Beispiel: „P0 innerhalb von 30 Sekunden eskalieren“ (priority=100) und „jede Eskalation erfordert human approval“ (priority=100). Der Agent kann nicht entscheiden, welche Regel anzuwenden ist. Wird durch check_rule_priority.py überprüft.
Defektklassen – hidden out of scope: Eine Aktion, die eine Anforderung zur Ausführung zwingt, obwohl sie in den Constraints verboten ist. Beispiel: Erstellung eines Jira-Tickets im Akzeptanztest bei Verbot von Jira in den Einschränkungen. Der Defekt ist in der Semantik „versteckt“, nicht in der Syntax. Erfordert Überprüfung durch JSON Schema und Akzeptanztests.
Metrik ask storm: Diagnostisches Merkmal: wiederholte klärende Anfragen des Agenten ohne Erscheinen neuer Daten. Wird als +1 für jede neue Nachricht gezählt, die Daten anfordert, die bereits in vorherigen Nachrichten der aktuellen Sitzung genannt wurden. Wird zurückgesetzt, wenn ein neues Feld zu requirements.md oder clarifications.md hinzugefügt wird. Heuristik für manuelle Zählung beim ersten Durchgang; wird durch Parser der Transkription automatisiert qwen --output-format json.
Metrik stage regress: Diagnostisches Merkmal: Rückkehr der aktuellen SDD-Phase (specify/plan/tasks/implement) auf eine vorherige Phase ohne explizite Aufzeichnung des Grundes in validation.md. Wird als +1 für jeden Rückschritt gezählt. Weist auf Instabilität der Spezifikation oder ungelösten Konflikt in den Anforderungen hin.
Metrik phase context loss: Diagnostisches Merkmal: Verlust des Phasenkontexts, wenn der Agent in einer neuen Phase auf eine Regel verweist, die im aktuellen requirements.md oder plan.md nicht vorhanden ist. Boolescher Wert: wahr/falsch. Zeigt, dass die Spezifikation keine Kontinuität zwischen den SDD-Phasen aufrechterhält.
Ausnahmeregel (override): Formale Strategie zur Auflösung von Prioritätskonflikten. Definiert, welche Anforderung am Rand von Zeit oder Kritikalität gewinnt. Beispiel: p0_time_critical_override steht über manual_gate_for_noncritical. Muss durch JSON Schema überprüfbar sein und in Akzeptanztests widergespiegelt werden.
Einzige Quelle der Wahrheit: Prinzip der Beseitigung von Abweichungen zwischen dem Text der Spezifikation, JSON Schema und Akzeptanztests. Prioritäten, die in YAML deklariert werden, müssen auf dieselbe Hierarchie aus Tests und Schemata verweisen, ohne parallele Auslegung.
Prüfinvariante: Dokumentation des Zustands vor und nach einem kritischen Übergang. Für Eskalation: vorher – severity, deadline, owner_state; nachher – channel, audit_record, reason_code. Gewährleistet Rückverfolgbarkeit und verhindert eine formale „Lösung“ des Konflikts mit Kontrollverlust.
Rücklauf des SDD-Zyklus: Vollständige Überprüfung von Specify → Plan → Tasks → Implement nach der Defektbehebung. Notwendig zur Bestätigung, dass der Defekt nicht von den Regeln in die Dekomposition (Tasks) oder von der Dekomposition in die Implementierung (Implement) verschoben wurde. Als zuverlässig gilt nur ein reproduzierbares Ergebnis: zwei aufeinanderfolgende Durchläufe ohne neue ask_storm, stage_regress und Prioritätskonflikte.
Wiederherstellungszeile in validation.md: Formale Aufzeichnung einer Tatsache, die nach der Reparatur nicht mehr reproduziert wird. Beispiel: priority_conflict=false && escalation_path_resolved=P0 && audit_required=true. Dient als Fertigkeitskriterium und Kontrollfakt für das Review.
Praxisübungen: Titel: Übung 1: Erstellung von poisoned-spec.md mit Prioritätskonflikt
Problem: Nehmen Sie den Übungsfall appointment_latency. Erstellen Sie die Datei poisoned-spec.md (oder specs/appointment-latency-poisoned.yaml) mit zwei konfliktierenden Regeln: (1) P0 wird innerhalb von 30 Sekunden eskaliert, priority=100; (2) jede Eskalation erfordert human approval, priority=100. Beide Regeln müssen formal sein (in YAML/JSON), nicht in einem Kommentar. Notieren Sie das erwartete Symptom vor dem Start des Agenten.
Lösung: Schritt 1: Kopieren Sie die Basisspezifikation aus Teil 11 des ersten Bandes. Schritt 2: Fügen Sie zwei Regeln mit identischem priority=100 hinzu, die zu sich gegenseitig ausschließenden Aktionen führen. Schritt 3: Stellen Sie sicher, dass der Konflikt in den Daten sichtbar ist: Starten Sie python3 scripts/spec_ci/check_rule_priority.py – es sollte eine Kollision anzeigen. Schritt 4: Notieren Sie in validation.md das erwartete Symptom: ask_storm >= 4 || stage_regress >= 2 || escalation_path_resolved=false. Schritt 5: Starten Sie Qwen Code im Plan Mode ohne Dateiänderungen, dokumentieren Sie die tatsächlichen Metriken.
Schwierigkeitsgrad: Anfänger
Titel: Übung 2: Diagnose eines Zyklus durch find_spec_loops.py
Problem: Fügen Sie eine zyklische Abhängigkeit in die Spezifikation ein: WAIT_APPROVAL → VALIDATE_ESCALATION → WAIT_APPROVAL. Starten Sie den Agenten und dokumentieren Sie, wie sich cycle manifestiert. Verwenden Sie [project script] find_spec_loops.py für die Visualisierung. Vergleichen Sie das Verhalten des Agenten bei cycle und bei priority_conflict: Worin unterscheiden sich die Metriken ask_storm und stage_regress?
Lösung: Schritt 1: Ersetzen Sie in poisoned-spec.md den linearen Übergang durch einen zyklischen: VALIDATE_ESCALATION.when = 'escalation_attempted == true', then = 'goto WAIT_APPROVAL'. Schritt 2: Starten Sie find_spec_loops.py – erhalten Sie einen DOT-Graphen mit Rückwärtskante. Schritt 3: Starten Sie den Agenten im Plan Mode, dokumentieren Sie: bei cycle dominiert stage_regress (Agent kehrt zur gleichen Stufe zurück), bei priority_conflict – ask_storm (Agent fragt mehrfach dasselbe nach). Schritt 4: Notieren Sie in validation.md den Unterschied: cycle_count > 0 && stage_regress >= 3 für cycle gegen ask_storm >= 4 && escalation_path_resolved=false für priority_conflict.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 3: Auflösung des Konflikts durch Ausnahmeregel und JSON Schema
Problem: Beheben Sie priority_conflict in appointment_latency durch p0_time_critical_override. Die Regel muss: (a) Auto-Eskalation von P0 bei nicht erreichbarem Owner erlauben; (b) human_audit_required=true als Postfaktum bewahren; (c) manuelle Barriere für P1-P3 blockierend lassen. Übertragen Sie die Lösung in JSON Schema, das eine Rückkehr zur versteckten manuellen Bestätigung verbietet.
Lösung: Schritt 1: Erstellen Sie in fixed-spec.yaml p0_time_critical_override: priority=100, when: severity=P0 && owner_unresponsive=true, then: escalation=critical_phone, human_audit_required=true. Schritt 2: Senken Sie die Priorität von human_gate_noncritical auf 10 für P1-P3. Schritt 3: Fügen Sie im JSON Schema eine if-then-Bedingung hinzu: wenn severity=P0 && owner_unresponsive=true, dann required: [auto_escalation_channel, human_audit_required, reason_code] mit Konstanten critical_phone, true, time_critical_override. Schritt 4: Starten Sie lint_spec.py – prüfen Sie Atomarität. Schritt 5: Starten Sie check_rule_priority.py – stellen Sie sicher, dass der Konflikt erschöpft ist. Schritt 6: Notieren Sie in validation.md die Wiederherstellungszeile: priority_conflict=false && escalation_path_resolved=P0 && audit_required=true.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 4: Vollständiger Rücklauf und Übertragung in das Capstone
Problem: Führen Sie einen Rücklauf Specify → Plan → Tasks → Implement für die korrigierte Spezifikation durch. Dokumentieren Sie, dass keine Phase den ursprünglichen Konflikt zurückgibt. Übertragen Sie das Ergebnis in capstone/ für den Fall high_memory_usage: Adaptieren Sie die Klasse priority_conflict auf den Konflikt zwischen restart_pod und human approval.
Lösung: Schritt 1: Starten Sie Qwen Code sequentiell: specify (requirements.md), plan (plan.md), tasks (tasks.md), implement. Dokumentieren Sie nach jeder Phase die Metriken in validation.md. Schritt 2: Wenn Tasks inkompatible Aktionen erstellen – ist der Defekt in die Dekomposition verschoben, überarbeiten Sie den Plan. Wenn Implement durchläuft, aber Tests fehlschlagen – ist die Grenze des zulässigen Verhaltens unvollständig beschrieben. Schritt 3: Für capstone/high_memory_usage: defect_class=priority_conflict, vergiftet: memory_percent>=90 erlaubt restart_pod, aber jeder restart_pod erfordert human approval mit derselben priority. Schritt 4: korrigiert: restart_pod als pre-approved action für stateless pod erlaubt, erster Production-Start erfordert human_review_for_first_run=true. Schritt 5: Validierung: priority_conflict=false && action=restart_pod && human_review_for_first_run=true.
Schwierigkeitsgrad: Fortgeschritten
Titel: Übung 5: Versteckter Grenzüberschreitung (hidden_out_of_scope)
Problem: Erstellen Sie eine Spezifikation, in der eine Anforderung die Erstellung eines Jira-Tickets erzwingt, obwohl Constraints Jira verbieten. Der Defekt soll „versteckt“ sein – syntaktisch ist die Spezifikation korrekt, semantisch verletzt sie die Einschränkungen. Diagnostizieren Sie durch phase_context_loss.
Lösung: Schritt 1: Fügen Sie in constraints.md forbidden_integrations: [jira] hinzu. Schritt 2: Fügen Sie in poisoned-spec.md eine Regel hinzu: when: severity=P2, then: create_ticket_in=jira. Schritt 3: Starten Sie den Agenten – er kann formal fortfahren, aber in der Phase Implement auf jira verweisen, die nicht in der erlaubten Liste ist. Schritt 4: Dokumentieren Sie phase_context_loss=true: Agent verweist in Implement auf eine Regel, die in den aktuellen Constraints nicht vorhanden ist. Schritt 5: Korrigieren Sie: Ersetzen Sie jira durch einen erlaubten Kanal (z.B. internal_tracker) oder fügen Sie eine Ausnahme in constraints hinzu. Schritt 6: Prüfen Sie durch JSON Schema: forbidden_integrations sollte ein enum mit kontrollierter Liste sein, then – ein reference auf dieses enum.
Schwierigkeitsgrad: Fortgeschritten
Fallstudien: Titel: Fall: Latenzsteigerung appointments-api und Diagnose von priority_conflict im Production-Team
Szenario: Plattform für Online-Arzttermine (Domäne aus Teil 11 des ersten Bandes). Die Route appointments-api zeigte eine p95-Latenzsteigerung auf 2,5 Sekunden. Das SRE-Team erhielt einen Alarm severity=P0. Die Triage-Spezifikation forderte: (1) P0 innerhalb von 30 Sekunden eskalieren; (2) jede Eskalation erfordert human approval. Beide Regeln hatten priority=100. Der On-Call-Ingenieur war im Flugzeug, Bestätigung unmöglich. Qwen Code, als Incident-Planer eingesetzt, verfing sich in einer Schleife von Klärungen.
Herausforderung: Der Agent fragte 12 Mal „präzisieren Sie, ob der Owner verfügbar ist“, obwohl der Status owner_unresponsive=true in der ersten Nachricht angegeben war (ask_storm=12). Dann kehrte der Agent von der Phase Plan zu Specify zurück und schlug vor, „die Anforderungen zu überdenken“ (stage_regress=2). Die Eskalation erfolgte nicht innerhalb von 4 Minuten statt 30 Sekunden. Das Team eskalierte manuell per Telefon, verlor dabei SLA und Audit-Trail.
Lösung: Nach dem Vorfall wandte das Team die Technik der kontrolliert defekten Spezifikation an. Erstellte poisoned-spec.md mit reproduziertem Konflikt. In fixed-spec.md wurde p0_time_critical_override eingeführt: Für P0 bei owner_unresponsive=true ist die Eskalation sofort über critical_phone erlaubt, human_audit_required wurde in Postfaktum-Audit verschoben. Für P1-P3 blieb die manuelle Barriere. JSON Schema verankerte die Pflichtfelder auto_escalation_channel, human_audit_required, reason_code. Rücklauf durchgeführt: Specify → Plan → Tasks → Implement – Metriken ask_storm=0, stage_regress=0, phase_context_loss=false.
Ergebnis: Die Reaktionszeit auf P0 sank von 4 Minuten auf 23 Sekunden. Audit-Trail wiederhergestellt: Alle Auto-Eskalationen haben reason_code=time_critical_override. Spezifikation wurde reproduzierbar testbar: Das Team führt monatlich das poisoned/fixed-Paar im Trainingsmodus durch. Methodik wurde in das Capstone-Projekt high_memory_usage mit Adaption auf restart_pod vs human approval übertragen.
Gelernte Lektionen: Prioritätskonflikt mit identischem priority=100 manifestiert sich im Normalbetrieb nicht, wird aber im Stress-Szenario fatal (owner_unresponsive)
Metriken ask_storm und stage_regress ermöglichen quantitative Unterscheidung zwischen Spezifikationsdefekt und „schlechtem Agentenverhalten“
Ausnahmeregel muss die überprüfbare Anforderung ändern, nicht nur die textuelle Erklärung – sonst kehrt der Agent zur alten Auslegung zurück
Rücklauf des vollständigen Zyklus ist notwendig: Lokale Korrektur in requirements.md kann den Defekt in plan.md oder tasks.md verschieben
JSON Schema als „einzige Quelle der Wahrheit“ verhindert versteckte Absprachen durch benachbarte Agentenschritte
Verwandte Konzepte: priority_conflict
ask_storm
stage_regress
p0_time_critical_override
Rücklauf des SDD-Zyklus
einzige Quelle der Wahrheit
Wiederherstellungszeile in validation.md
Titel: Fall: Adaption der Technik auf high_memory_usage im Capstone-Projekt
Szenario: Abschlussprojekt eines Kursteilnehmers des SDD-Kurses. Domäne: Cloud-Infrastruktur, Alarm high_memory_usage (memory_percent >= 90 für 10 Minuten). Der Student musste die Beherrschung der Spezifikationsdefektdiagnose in einer neuen Domäne demonstrieren, wobei die Defektklasse aus dem Übungsfall beibehalten wurde.
Herausforderung: Direkte Übernahme von appointment_latency nicht anwendbar: andere Entitäten (pod, restart, memory), andere Risiken (stateful vs stateless, Datenverlust bei Restart). Es musste priority_conflict adaptiert werden unter Beibehaltung der Struktur: zwei Regeln mit identischer priority, die zu sich gegenseitig ausschließenden Aktionen führen, und formale Auflösung durch override.
Lösung: Der Student erstellte poisoned-spec.md: memory_percent>=90 erlaubt restart_pod, aber jeder restart_pod erfordert human approval, beide mit priority=100. In fixed-spec.md führte er die Unterscheidung stateless/stateful ein: restart_pod als pre-approved action für stateless pod, für den ersten Production-Start – human_review_for_first_run=true. Dies bewahrte das Audit, aber entsperrte die Auto-Aktion für die bekannte Konfiguration. JSON Schema forderte die Felder pod_type, first_run_flag, review_record. Wiederherstellungszeile: priority_conflict=false && action=restart_pod && human_review_for_first_run=true.
Ergebnis: Der Reviewer bestätigte die Bestehensgrenze: Defektklasse identifiziert, Patch ändert überprüfbare Regel, Rücklauf sauber. Der Student merkte an, dass die größte Schwierigkeit nicht das Einbringen des Defekts, sondern die Beschränkung auf genau einen war: Erste Versuche enthielten gleichzeitig cycle im Zustandsgraphen des pod, was die Diagnose ununterscheidbar machte.
Gelernte Lektionen: Übertragung der Defektklasse auf eine neue Domäne erfordert Neudenken der Entitäten, aber Beibehaltung der Konfliktstruktur
Beschränkung „ein Defekt pro Iteration“ ist die schwierigste Regel in der Praxis; natürliche Tendenz zur „Verstärkung“ des Übungsfalls führt zu ununterscheidbarer Spur
human_review_for_first_run=true – Beispiel einer Ausnahmeregel, die skaliert: Sie funktioniert für memory, appointment und neue Domänen
Capstone-Review schätzt nicht das Volumen der Artefakte, sondern die Präzision: genau ein Defekt, eine Wiederherstellungszeile, reproduzierbares Ergebnis
Verwandte Konzepte: poisoned/fixed-Paar
priority_conflict
human_review_for_first_run
stateless vs stateful
Wiederherstellungszeile
Capstone-Übertragung
Studientipps: Beginnen Sie mit manueller Zählung der Metriken (Bleistift in validation.md), nicht mit Automatisierung. Verständnis der Heuristik ist wichtiger als das Skript: Sie müssen spüren, wann ask_storm ein Spezifikationsdefekt ist und wann – Unvollständigkeit des externen Weltkontexts
Erstellen Sie poisoned-spec.md vor dem Start des Agenten und notieren Sie das erwartete Symptom im Voraus. Dies verhindert Postfaktum-Rationalisierung: „aha, er sollte ja steckenbleiben“ – solche Logik beraubt die Technik der Kontrollierbarkeit
Verwenden Sie das didaktische Minimum: appointment_latency für den ersten Durchgang, high_memory_usage nur für das Capstone. Versuchen Sie nicht, beide Domänen parallel zu erlernen – der Unterschied in den Entitäten (latency vs memory, Eskalation vs restart) lenkt vom Erlernen der Technik selbst ab
Prüfen Sie den Defekt durch Projekt-Skripte (find_spec_loops.py, check_rule_priority.py) vor dem Start von Qwen Code. Wenn das Skript die Kollision nicht erfasst – ist der Defekt in einem Kommentar oder in natürlicher Sprache versteckt, nicht in der formalen Spezifikation
Beim Rücklauf dokumentieren Sie die Metriken nach jeder Phase, nicht am Ende. Der Defekt kann verschoben werden: Specify sauber → Plan sauber → Tasks erstellen inkompatible Aktionen. Typisches Anzeichen: stage_regress an der Grenze Plan→Tasks
Üben Sie die Übertragung in Given/When/Then und JSON Schema parallel, nicht sequentiell. Sie schließen verschiedene Seiten des Problems ab: GWT – überprüfbares Szenario, JSON Schema – Verbot unzulässiger Zustände. Eines ohne das andere lässt dem Agenten eine Schlupfluke
Für Präsenzunterricht: Teilen Sie sich in Paare – einer erstellt poisoned-spec, der andere diagnostiziert ohne Hinweise. Rollentausch nach der Analyse. Dies simuliert die reale Situation, in der der Spezifikationsautor für seinen eigenen Defekt „blind“ ist
Führen Sie ein „Mutationsjournal“: Notieren Sie alle Versuche des Defekteinbringens, auch missglückte. Häufiger Fehler: „Agent steckte nicht fest, obwohl er sollte“. Das ist kein Versagen, sondern Daten: Möglicherweise war der Defekt in einem Kommentar, oder die priorities unterschieden sich, oder der Agent nutzte implizites Wissen. Das Journal hilft, die Intuition zu kalibrieren
Verschieben Sie Metriken ask_storm, stage_regress, phase_context_loss nicht „auf später“. Beim ersten Durchgang erscheinen sie vage, aber genau sie verwandeln „seltsame Agentenantwort“ in ein diagnostisches Artefakt. Üben Sie an kurzen Sitzungen (3-5 Nachrichten)
Zur Selbstprüfung vor der Prüfung: Stellen Sie sicher, dass der diff zwischen poisoned und fixed genau eine überprüfbare Regel betrifft. Wenn der diff nur in Kommentaren oder textuellen Erläuterungen liegt, gilt die Korrektur nicht
Zusätzliche Ressourcen: Teil 7 des ersten Bandes (negative Anforderungen): Basistheorie, auf die die Defektdiagnose aufbaut. Notwendig zum Verständnis, warum Prioritätskonflikt eine außer Kontrolle geratene negative Anforderung ist
Teil 20 des ersten Bandes (SDD-Antipatterns): Katalog klassischer Spezifikationsfehler, der als Quelle von Mutationen dient. Cycle, priority_conflict, hidden_out_of_scope – Ableitungen dieser Antipatterns
Teil 11 des ersten Bandes (zweites Phasenprojekt): Ursprüngliche Domäne appointments-api, Agentenseite auf Hono JSX. Kontext für den Übungsfall appointment_latency
Examples/spec-ci/readme.md: Ausführbares Analogon des Basisspezifikations-Gateways (Spec CI). Automatische Überprüfung der Form von Anforderungen und Plan, nah am runnable-Analogon aus dem Kapitel
Book2/examples/templates/validation.md: Formularvorlage für die Aufzeichnung der Überprüfung. Wird zur Dokumentation des erwarteten Symptoms und der Wiederherstellungszeile verwendet
Github spec kit quickstart (https://github.github.io/spec-kit/quickstart.html): Offizielle Beschreibung der Phasen Specify → Plan → Tasks → Implement. Link aus dem Kapitel auf externe Spezifikation des SDD-Ansatzes
[project script] find spec loops.py: Skript zur Suche nach Zyklen im Zustandsgraphen der Spezifikation. Erzeugt DOT-Graphen für Visualisierung
[project script] check rule priority.py: Skript zur Überprüfung von Prioritätskollisionen in YAML-Spezifikation. Erfasst priority_conflict durch numerische Übereinstimmung von priority
[project script] lint spec.py: Skript zur Überprüfung der Atomarität der Spezifikation. Wird beim Rücklauf zur Validierung der fixed-Version verwendet
Qwen --output-format json + Aggregator-Skript: Weg zur Automatisierung der Metriken ask_storm, stage_regress, phase_context_loss. Beim Übungsdurchgang – Parser der Transkription, beim fortgeschrittenen – CI-Metrik
Zusammenfassung: Die Schlüsselleistung dieses Kapitels ist die Umwandlung der Spezifikation von einer Ansammlung von Wünschen in einen stabilen, reproduzierbaren Vertrag. Die Technik der kontrolliert defekten Spezifikation (poisoned/fixed-Paar) liefert vier Instrumente: (1) ein Defekt pro Iteration mit messbarem Symptom; (2) Diagnose des Stillstands durch ask_storm, stage_regress, phase_context_loss; (3) formale Konfliktlösung durch Ausnahmeregeln, Given/When/Then und JSON Schema; (4) Rücklauf des vollständigen SDD-Zyklus zur Stabilitätsprüfung. Didaktisches Minimum – poisoned-spec.md, fixed-spec.md und Wiederherstellungszeile in validation.md für appointment_latency; Capstone-Übertragung – dieselbe Klasse priority_conflict auf high_memory_usage. Das nächste Kapitel wird diese Regeln in constitution.md als erste projektbezogene Volksabstimmung formulieren.