Thema: Anhang A. Brücken zum ersten Band
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden aktives Lernen + 2-3 Stunden praktische Übungen
Voraussetzungen: Absolvierung der Hauptteile des ersten Bands (Teile 6, 7, 9, 10, 12, 13, 15, 16, 17, 20, 22)
Verständnis der Struktur von SDD-Artefakten: mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md
Grundlegende Vertrautheit mit dem Projekt AgentClinic aus dem ersten Band
Verständnis der Formate EARS und Given/When/Then für die Anforderungsspezifikation
Vertrautheit mit den Qwen Code-Hooks (PreToolUse, PostToolUse)
Verständnis des Konzepts der Agentenersetzbarkeit und der Verweise auf ACP/AGENTS.md
Lernziele: Alle 12 Production-Szenarien des zweiten Bands erfolgreich mit den entsprechenden Lernkomponenten von AgentClinic aus dem ersten Band zuordnen
Migration von Artefakten zwischen drei SDD-Dialekten (Autoren-Dialekt, Spec Kit, Kiro) ohne Semantikverlust durchführen
Minimalen Durchlaufweg für den zweiten Band formulieren, wobei Pflichtartefakte vom vollständigen Implementierungstrack unterschieden werden
Identifizieren und erklären, welche 8 Themen des ersten Bands kritische Voraussetzungen für die Lektüre des zweiten Bands sind
Domänenkarte von AgentClinic anwenden, um Production-Symptome (node_not_ready, appointment_latency, high_memory_usage u.a.) im Kontext konkreter Kapitel zu interpretieren
Überblick: Anhang A dient als architektonische Brücke zwischen dem lehrbuchartigen ersten Band und dem anwendungsorientierten zweiten Band des SDD-Kurses (Specification-Driven Development). Er systematisiert drei kritische Verbindungen: Voraussetzungen aus dem ersten Band (ohne die der zweite Band nicht lesbar ist), Entsprechung der SDD-Dialekte (Autoren-Dialekt, GitHub Spec Kit, AWS Kiro) sowie die Domänenkarte zur Transformation des Lernprojekts AgentClinic in Production-Szenarien. Der Anhang enthält keine neue Methodologie — sein Ziel ist es, kognitive Überlastung des Lesers zu verhindern, indem explizit gezeigt wird, wie jeder „Production-Begriff“ des zweiten Bands aus dem bereits bekannten Lern-Code erwächst. Der zweite Band errichtet 14 neue Schichten auf der Basis des ersten Bands: von der Spezifikationsarchäologie und stufenbasierten Budgets bis zu Anti-Patterns des Production-SDD und der abschließenden Production-Prüfung.
Schlüsselkonzepte: Brücke (bridge): Explizite Verbindung zwischen einem Artefakt/Konzept des ersten Bands und dessen Production-Interpretation im zweiten Band. Brücken sind in Tabellenform zusammengestellt für schnelle Quersuche beim Lesen eines beliebigen Kapitels des zweiten Bands.
Minimaler Durchlaufweg: Reduzierter Track für den zweiten Band, bei dem einige Artefakte manuell ausgefüllt, einige Beispiele lokal ausgeführt und einige Blöcke nur zum vollständigen Implementierungstrack gehören. Beschrieben in Teil 0 (part-00-production-lab.md).
SDD-Dialekt: Konkrete Implementierung der Methodologie Specification-Driven Development mit festgelegtem Artefaktsatz und Benennungsregeln. Der Autoren-Dialekt des Lehrbuchs verwendet .md-Dateien; Spec Kit verwendet Befehle /speckit.*; Kiro verwendet eine eigene Artefaktstruktur.
AgentClinic-Domänenkarte: Tabelle der Entsprechungen zwischen Lernentitäten des ersten Bands (Hono-Routen, SQLite-Migrationen, Feedback-Formulare) und Production-Symptomen des zweiten Bands (node_not_ready, appointment_latency_spike, rate_limit_breach u.a.).
Production-Symptom: In der Production beobachtbares Anomaliezeichen (z.B. high_memory_usage), das im zweiten Band durch die Linse des SDD-Zyklus analysiert wird: Spezifikation → Plan → Validierung → Eskalation/Remediation.
Prüfungsweg: Obligatorisches Minimum für die Bestehensprüfung des anwendungsorientierten Bands. Für die AgentClinic-Domänenkarte ist der Prüfungsfall high_memory_usage (SQLite-Lesespitze nach Deployment); die übrigen Symptome dienen dem Verständnis lokaler Beispiele.
Spezifikationsarchäologie: Prozess der Wiederherstellung einer Spezifikation aus Spuren eines übernommenen Systems ohne Originaldokumentation. Der zweite Band entwickelt dieses Thema aus Teil 13 des ersten Bands weiter.
Schatten-Spezifikationen: Informelle Heuristiken und implizite Anforderungen, die nicht in expliziten Artefakten festgehalten, aber entscheidungsrelevant sind. Der zweite Band formalisiert sie durch ein Auswahlverfahren.
Stufenbasierte Budgets: System zur Verteilung der Kosten von LLM-Modellaufrufen nach Ebenen (Stufen) der Aufgabenkomplexität, das Budgetentleerung bei einfachen Operationen verhindert.
Anti-Goodhart-Metriken: Paarweise Wächtermetriken, so konstruiert, dass Optimierung nach einer Metrik nicht zur Degradation bei der anderen führt (Schutz vor Goodhart-Effekt).
Praxisübungen: Titel: Übung 1: Lückendiagnose in Voraussetzungen
Problemstellung: Vor Ihnen liegt eine Liste von 8 Themen des ersten Bands. Bestimmen Sie für jedes Thema: (a) welches SDD-Artefakt es erzeugt, (b) in welchem Kapitel des zweiten Bands dieses Artefakt verwendet wird, (c) was beim Lesen des Kapitels ohne Kenntnis der Voraussetzung geschieht. Themen: Struktur von mission.md/tech-stack.md/roadmap.md; Format von requirements.md/plan.md/validation.md; Merge-Freigabefakten und EARS; Neuplanung und Aktualisierung der Roadmap; Unterstützung übernommener Codebasis; Agentenersetzbarkeit; Team-Review und Nachweispaket; Qwen Code-Hooks.
Lösung: Schritt 1: Erstellen Sie eine 3×8-Tabelle. Schritt 2: Für 'Struktur mission.md' — Artefakte: Projektverfassung; Kapitel zweiten Bands: Teil 3 (Production-Verfassung); Folge des Auslassens: Unverständnis der Trennung unveränderlicher und veränderlicher Schichten. Schritt 3: Für 'Format requirements.md/plan.md/validation.md' — Artefakte: Feature-Spezifikation; Kapitel: Teil 7 (Specification CI); Folge: Unmöglichkeit, Spezifikations-Gateway als Pflicht-Gate zu konfigurieren. Schritt 4: Für 'Freigabefakten und EARS' — Artefakte: Validierungsfakten; Kapitel: Teil 4 (LLM-Duell); Folge: Unmöglichkeit, adversarielle Validierung zwischen Rollen zu organisieren. Schritt 5: Für 'Neuplanung' — Artefakte: aktualisierte roadmap; Kapitel: Teil 9 (Stufenbasierte Budgets); Folge: Unverständnis, wie Budgetbeschränkungen die Neuplanung beeinflussen. Schritt 6: Für 'Spezifikationsarchäologie' — Artefakte: wiederhergestellte Spezifikation; Kapitel: Teil 1; Folge: Unmöglichkeit, Wiederherstellungstechniken aus Legacy anzuwenden. Schritt 7: Für 'Agentenersetzbarkeit' — Artefakte: ACP/AGENTS.md; Kapitel: Teil 8 (Datei-Schiedsgericht); Folge: Unverständnis, wie ein Multi-Agenten-Tribunal die Rollenunabhängigkeit wahrt. Schritt 8: Für 'Team-Review' — Artefakte: Nachweispaket; Kapitel: Teil 13 (Praktische Prüfung); Folge: Unmöglichkeit, abschließende Production-Prüfung zu formulieren. Schritt 9: Für 'Qwen Code-Hooks' — Artefakte: PreToolUse/PostToolUse; Kapitel: Teil 11 (Production API); Folge: Unmöglichkeit, Auto-Remediation über Hooks zu realisieren.
Schwierigkeitsgrad: mittel
Titel: Übung 2: Übersetzung zwischen SDD-Dialekten
Problemstellung: Ein Team arbeitet mit GitHub Spec Kit. Übersetzen Sie folgende Artefakte des Autoren-Dialekts des Lehrbuchs in Spec Kit-Befehle: requirements.md für das Feature 'Terminvereinbarung', plan.md für die Sprint-Iteration, validation.md für die Feature-Prüfung. Führen Sie dann die Rückübersetzung durch: /speckit.analyze → Autoren-Dialekt.
Lösung: Schritt 1: requirements.md → /speckit.specify (Erstellung der Anforderungsspezifikation). Schritt 2: plan.md → /speckit.plan + /speckit.tasks (Plan wird in Planstruktur und konkrete Aufgaben aufgeteilt). Schritt 3: validation.md → /speckit.analyze + Prüflisten (Validierung umfasst Analyse und Abnahmechecklisten). Schritt 4: Rückübersetzung: /speckit.analyze → validation.md (Validierungsdatei mit Freigabefakten, EARS-Spezifikationen, Given/When/Then-Szenarien). Schritt 5: Prüfen Sie die Semantikerhaltung: In Spec Kit werden Befehle im Chat-Interface ausgeführt, im Autoren-Dialekt werden Dateien in Git versioniert; beide Ansätze müssen identische Mengen prüfbarer Fakten erzeugen.
Schwierigkeitsgrad: mittel
Titel: Übung 3: Interpretation eines Production-Symptoms über die Domänenkarte
Problemstellung: In einer auf AgentClinic basierenden Production-System wurde das Symptom autoscale_200pct (plötzliche Laststeigerung um 200%) festgestellt. Bestimmen Sie mithilfe der Domänenkarte: (a) welcher Lernkomponente des ersten Bands dieses Symptom zugrunde liegt, (b) in welcher Projektphase (MVP) es auftrat, (c) welche Kapitel des zweiten Bands für die Analyse anwendbar sind, (d) welche Metriken und Budgets eingesetzt werden.
Lösung: Schritt 1: Laut Domänenkartentabelle entspricht autoscale_200pct der 'MVP-Phase (Teil 12)' des ersten Bands. Schritt 2: Die MVP-Phase war durch manuelles Deployment und fehlende automatische Skalierung gekennzeichnet — plötzliche Laststeigerung war unerwartet. Schritt 3: Anwendbare Kapitel des zweiten Bands: Teil 9 (Stufenbasierte Budgets — Modellverteilung nach Aufgabenkomplexität bei Laststeigerung), Teil 10 (Anti-Goodhart-Metriken — Verhinderung der Optimierung von autoscale zu Lasten der Latenz), Teil 11 (Production API — Integration mit Auto-Skalierungssystemen). Schritt 4: Metriken: appointment_latency (Antwortverzögerung), high_memory_usage (Ressourcenverbrauch bei Skalierung). Schritt 5: Budgets: Stufenbasiertes Modellbudget (keine teuren Aufrufe für Routineprüfungen erschöpfen), cdn_error_budget_burn (keinen CDN-Fehlerbudget bei plötzlichem Traffic-Anstieg erschöpfen).
Schwierigkeitsgrad: mittel
Titel: Übung 4: Formulierung eines minimalen Durchlaufwegs für ein konkretes Kapitel
Problemstellung: Sie bereiten sich auf Teil 5 des zweiten Bands (Mutationstesten von Spezifikationen) vor. Bestimmen Sie auf Basis der Struktur des minimalen Durchlaufwegs aus Teil 0: welche Artefakte manuell ausgefüllt werden, welche Beispiele lokal ausgeführt werden, welche Blöcke nur zum vollständigen Implementierungstrack gehören.
Lösung: Schritt 1: Bestimmen Sie die Voraussetzungen aus Anhang A: Teil 9 des ersten Bands (Freigabefakten, EARS, Given/When/Then) — kritisch notwendig, sonst können Spezifikationsmutationen nicht geprüft werden. Schritt 2: Manuell auszufüllende Artefakte: requirements.md für das Feature im EARS-Format, Mutantensatz (kontrolliert verzerrte Versionen der Spezifikation), Orakel-Liste erwarteter Fehlschläge. Schritt 3: Lokal ausführbare Beispiele: Mutations-Skript (kontrollierte Defekteinfügung in Spezifikation), Validator-Durchlauf gegen Mutanten, Mutationsabdeckungsanalyse. Schritt 4: Blöcke des vollständigen Tracks: CI/CD-Integration für automatisches Mutationstesten jedes PR, Mutation-Score-Metriken im Dashboard, Verbindung mit stufenbasierten Budgets (Teil 9). Schritt 5: Prüfung: Falls Sie Teil 9 des ersten Bands nicht absolviert haben — kehren Sie dorthin zurück, sonst wird Mutationstesten zu einer 'Begriffshäufung'.
Schwierigkeitsgrad: mittel
Fallstudien: Titel: Fallstudie: Migration eines Teams von Spec Kit in den Autoren-Dialekt bei Vorbereitung auf die Production-Prüfung
Szenario: Ein Team von 4 Entwicklern arbeitete 18 Monate mit GitHub Spec Kit in Chat-Interface für die Spezifikation eines internen Arzttermin-Systems. Beim Übergang zum SDD-Kurs zur Vorbereitung auf die Production-Prüfung stellte sich heraus, dass die Spezifikationshistorie nicht versioniert wird, die Befehle /speckit.* keine prüfbaren Artefakte für Audits erzeugen, und ein Nachweispaket für Team-Review nicht formuliert werden kann.
Herausforderung: (1) Semantikverlust bei Übersetzung: /speckit.plan enthält implizite Annahmen, die in der Datei plan.md explizit sein müssen. (2) Fehlende Merge-Freigabefakten — in Spec Kit wurden Prüfungen manuell ohne EARS-Formalisation durchgeführt. (3) Das Team verstand nicht, wie Agentenersetzbarkeit mit ACP/AGENTS.md zusammenhängt, da in Spec Kit die Agentenrolle im Chat-Kontext fixiert wurde. (4) Es musste der Prüfungsweg mit high_memory_usage als Hauptfall absolviert werden.
Lösung: Schritt 1: Reverse Engineering aller /speckit.*-Befehle in Dateistruktur .md unter Erhaltung von Zeitstempeln. Schritt 2: Formalisierung impliziter Annahmen durch Schatten-Spezifikationen (Teil 6 des zweiten Bands) mit anschließender Auswahl in explizite requirements.md. Schritt 3: Einführung von EARS und Given/When/Then für alle kritischen Pfade, Durchlauf von Teil 9 des ersten Bands im beschleunigten Wiederholungsmodus. Schritt 4: Erstellung von ACP/AGENTS.md mit expliziter Rollentrennung, Konfiguration von Qwen Code-Hooks für automatische Kontextfixierung. Schritt 5: Anwendung der Domänenkarte: high_memory_usage als SQLite-Lesespitze nach Deployment interpretiert (Teil 12 des ersten Bands), was Formulierung von Metriken und Budgets für die Prüfung ermöglichte.
Ergebnis: Nach 3 Wochen formulierte das Team ein vollständiges Nachweispaket für Teil 13 (Production-Prüfung). Der Mutation-Score für Spezifikationen stieg von 0% auf 73%. Das stufenbasierte Budget ermöglichte 34% Kosteneinsparung bei LLM-Aufrufen bei Beibehaltung der Latenz. Kritische Erkenntnis: Die Brücken zwischen den Bänden erwiesen sich nicht als Formalität, sondern als Instrument zur Verhinderung kognitiven Kollapses beim Übergang von chat-orientierter Spezifikation zu production-ready SDD.
Gewonnene Erkenntnisse: Die Übersetzung zwischen SDD-Dialekten erfordert explizite Prüfung semantischer Äquivalenz, nicht nur syntaktische Entsprechung von Dateinamen und Befehlen
In Chat-Format akkumulierte Schatten-Spezifikationen werden bei Skalierung zum kritischen Risiko; ihre Formalisierung muss der Production-Implementierung vorausgehen, nicht folgen
Der Prüfungsweg (high_memory_usage) fungiert als Anker für das gesamte Team: er konkretisiert abstrakte Konzepte des zweiten Bands durch bereits absolvierten Lern-Code
Auslassen von Voraussetzungen (hier: Teil 15 und 16 des ersten Bands) verlängert die Migrationszeit um das 2-3-fache aufgrund erforderlicher Rückkehr
Verwandte Konzepte: SDD-Dialekt
Schatten-Spezifikationen
AgentClinic-Domänenkarte
Agentenersetzbarkeit
Prüfungsweg
Nachweispaket
Titel: Fallstudie: Deployment von Specification CI in übernommenem AgentClinic-Projekt ohne Originalspezifikation
Szenario: Das Lernprojekt AgentClinic, das ein Student nach Absolvierung des ersten Bands deployed hatte, wurde über 6 Monate ohne Führung von SDD-Artefakten weiterentwickelt. Beim Versuch, Teil 7 des zweiten Bands (Specification CI) als Pflicht-Gate anzuwenden, stellte sich heraus, dass der aktuelle Systemzustand nicht von Spezifikationen abgedeckt ist und das Gateway jede Änderung blockiert.
Herausforderung: (1) Spezifikationsarchäologie: Spezifikation aus bestehendem Code und Datenbank musste wiederhergestellt werden. (2) Kontrollierte Defekte: Teil 2 des zweiten Bands erfordert Fähigkeit zur Diagnose 'vergifteter' Spezifikationen — aber ohne Original gibt es nichts zu diagnostizieren. (3) Production-Verfassung (Teil 3): Unveränderliche Schichten wurden durch ad-hoc-Änderungen verletzt. (4) Es musste bestimmt werden, welche Teile des ersten Bands für die Wiederherstellung kritisch sind und welche bei begrenzter Zeit ausgelassen werden können.
Lösung: Schritt 1: Anwendung von Teil 13 des ersten Bands (Unterstützung bestehender Projekte) für strukturierte Erfassung von Systemspuren: Logs, Datenbankmigrationen, Commit-Historie, API-Endpunkte. Schritt 2: Formulierung einer temporären 'Schatten-Verfassung' mit expliziter Trennung dessen, was bereits unveränderlich ist (DB-Schema mit Daten), und was Refactoring unterliegt (Geschäftslogik in Handlern). Schritt 3: Verwendung von EARS und Given/When/Then aus Teil 9 zur Formalisierung des beobachteten Systemverhaltens als temporäre Spezifikation. Schritt 4: Schrittweise Einführung von Specification CI: zunächst für neue Features, dann retrospektive Abdeckung kritischer Pfade. Schritt 5: Anwendung der Domänenkarte: Symptom node_not_ready als Testfall für Funktionsprüfung der wiederhergestellten Spezifikation verwendet.
Ergebnis: Nach 4 Wochen funktionierte Specification CI für 60% der kritischen Pfade. Die restlichen 40% wurden explizit als 'Legacy ohne Spezifikation' markiert mit Plan zur schrittweisen Abdeckung. Die wiederhergestellte Spezifikation ermöglichte Entdeckung von 3 versteckten Bugs, die sich in Testumgebung nicht manifestierten, aber in Production kritisch waren (im Zusammenhang mit rate_limit_breach).
Gewonnene Erkenntnisse: Spezifikationsarchäologie ohne Kenntnis von Teil 13 des ersten Bands wird zu chaotischem Reverse Engineering; strukturierter Ansatz spart 40-50% Zeit
Temporäre 'Schatten-Verfassung' — zulässiges Artefakt auf Zwischenstufe; entscheidend ist explizite Trennung von Unveränderlichem und Veränderlichem
Domänenkarte funktioniert in beide Richtungen: nicht nur 'Lern-Code → Production-Symptom', sondern auch 'Production-Symptom → Testfall für Validierung wiederhergestellter Spezifikation'
Versuch, Specification CI ohne Absolvierung der Teile 6-7 des ersten Bands einzuführen, führt zur Formalisierung falscher Artefaktstrukturen
Verwandte Konzepte: Spezifikationsarchäologie
Production-Verfassung
Kontrollierte Defekte
Specification CI
AgentClinic-Domänenkarte
Minimaler Durchlaufweg
Studientipps: Verwenden Sie die Tabelle 'Minimum, ohne das der zweite Band nicht lesbar ist' als Checkliste vor jedem Kapitel: falls eine Voraussetzung unbekannt ist — kehren Sie sofort zum entsprechenden Teil des ersten Bands zurück, sonst wird das Folgende zum passiven Durchblättern einer 'Begriffshäufung'
Drucken oder halten Sie die AgentClinic-Domänenkartentabelle in separatem Fenster beim Lesen eines beliebigen Kapitels des zweiten Bands bereit — dies reduziert die kognitive Belastung um 30-40% gegenüber dem Versuch, alle Entsprechungen im Gedächtnis zu behalten
Für auditive Wahrnehmung: Lesen Sie Brückenformulierungen laut vor wie 'Route GET / (Hello Hono) → node_not_ready: Repliken antworten nicht auf Health-Check' — die rhythmische Struktur 'Lern-Code → Production' unterstützt das Merken
Für kinästhetische Wahrnehmung: Setzen Sie physische Häkchen in der Voraussetzungstabelle, schreiben Sie 3-4 Schlüsselbrücken handschriftlich in eigener Formulierung um, erstellen Sie eine physische 'Brückenkarte' auf A3-Blatt
Für visuelle Wahrnehmung: Färben Sie die Domänenkartentabelle ein — grün für Prüfungsweg (high_memory_usage), gelb für lokale ausführbare Beispiele, rot für vollständigen Implementierungstrack
Führen Sie 'Übersetzungssitzungen' durch: Nehmen Sie ein Kapitel des zweiten Bands und markieren Sie explizit, welche Voraussetzungen des ersten Bands in jedem Absatz verwendet werden — dies verwandelt passives Lesen in aktives Konstruieren von Verbindungen
Falls Ihr Team mit Spec Kit oder Kiro arbeitet — erstellen Sie eine eigene Entsprechungstabelle mit dem Autoren-Dialekt und hängen Sie sie am Arbeitsplatz auf; Artefaktumbenennung sollte automatische Fertigkeit werden
Verwenden Sie den chronologischen Ansatz: Durchlaufen Sie die Teile des ersten Bands in der Reihenfolge ihrer Erwähnung in Anhang A (6 → 7 → 9 → 10 → 12 → 13 → 15 → 16 → 17 → 20 → 22), nicht nach Nummern — dies entspricht der Komplexitätssteigerungslogik im zweiten Band
Für die Kapitel 9-11 des zweiten Bands (Budgets, Metriken, Production API) kehren Sie unbedingt zu Teil 17 und 20 des ersten Bands zurück — Qwen Code-Hooks und SDD-Anti-Patterns sind direkte Voraussetzungen für Verständnis stufenbasieter Budgets und Auto-Remediation
Formulieren Sie ein 'persönliches Brückenlexikon': Erfassen Sie neu entdeckte Entsprechungen zwischen den Bänden in einem Dokument — nach 2-3 Kapiteln erstellen Sie eine individuelle Version von Anhang A, angepasst an Ihren Denkstil
Zusätzliche Ressourcen: Teil 0. AgentClinic-Production-Labor (part-00-production-lab.md): Basisrahmen für Übersetzung von AgentClinic in Lern-Production-Modell; enthält Definition des minimalen Durchlaufwegs
Anhang A des ersten Bands (appendix-a-sdd-dialects.md): Detaillierter Vergleich der drei SDD-Dialekte: Artefaktentprechungstabelle, Übertragungsempfehlungen, Formatbeschränkungen
Anhang B des ersten Bands (appendix-b-agentclinic-domain.md): Vollständige Beschreibung der AgentClinic-Domänenentitäten: Agenten-Patienten, Krankheiten, Therapien, Terminvereinbarungen, Bewertungen, Feedback
Readme des anwendungsorientierten Bands (readme.md): Kurze Lesekarte des zweiten Bands und Verweis auf Anhang A
Teil 6 des ersten Bands (part-06-constitution.md): Verfassungserstellung: mission.md, tech-stack.md, roadmap.md
Teil 7 des ersten Bands (part-07-feature-specification.md): Feature-Spezifikation: requirements.md, plan.md, validation.md
Teil 9 des ersten Bands (part-09-feature-validation.md): Feature-Prüfung: Merge-Freigabefakten, EARS, Given/When/Then
Teil 13 des ersten Bands (part-13-legacy-support.md): Unterstützung bestehender Projekte: Spezifikationsarchäologie
Teil 15 des ersten Bands (part-15-agent-replaceability.md): Agentenersetzbarkeit, Verweise auf ACP/AGENTS.md
Teil 17 des ersten Bands (part-17-qwen-code-hooks.md): Qwen Code-Hooks: PreToolUse und PostToolUse
Zusammenfassung: Anhang A ist kein Hilfsmaterial, sondern eine kritische Infrastrukturkomponente des Kurses, die Kontinuität zwischen Lern- und anwendungsorientiertem Band sicherstellt. Seine drei Funktionen: (1) Leserbereitschaftsdiagnose durch Checkliste aus 8 Pflichtvoraussetzungen, (2) SDD-Multidialektikalität durch explizite Übersetzungsregeln zwischen Autorenformat, Spec Kit und Kiro, (3) Konkretisierung abstrakter Production-Szenarien durch die AgentClinic-Domänenkarte. Schlüsselprinzip: Jedes Production-Symptom des zweiten Bands (node_not_ready, appointment_latency, high_memory_usage, rate_limit_breach, autoscale_200pct, cdn_error_budget_burn) ist ein umbenanntes und komplexifiziertes Lernkomponente des ersten Bands. Der Prüfungsweg fixiert high_memory_usage als Ankerfall; die übrigen Symptome dienen dem Verständnis lokaler Beispiele. Ohne aktive Nutzung der Brücken degradiert der zweite Band zum passiven Akkumulieren von Begriffen; mit Brücken wird er zur sinnvollen Fortsetzung bereits aufgebauter Kompetenzen.