Thema: Teil 22. Praktische Prüfung

Schwierigkeitsgrad: Mittelstufe

Geschätzte Lernzeit: 12-16 Stunden (Theorie: 4 Stunden, Praxis: 8-12 Stunden)

Voraussetzungen: Kenntnis der SDD-Methodologie aus den Teilen 1-21 des Kurses

Erfahrung mit Qwen Code CLI

Grundlegende Fähigkeiten im Umgang mit Git und Branches

Verständnis der Struktur des specs/-Verzeichnisses

Vertrautheit mit Markdown-Spezifikationen

Lernziele: Einen vollständigen SDD-Entwicklungszyklus eines Features von der Absicht bis zum Merge durchführen, indem eine Spezifikation (requirements.md, plan.md, validation.md) erstellt, Code implementiert und eine Prüfung mit einer Bewertung von mindestens 21 Punkten auf einer 25-Punkte-Skala bestanden wird

Mindestens 8 kritische Probleme in einer fehlerhaften Spezifikation identifizieren und diese im SDD-Format mit konkreten Grenzen, Lösungen und überprüfbaren Akzeptanzkriterien umschreiben

22 Kontrollfragen zu SDD-Prinzipien schriftlich beantworten und dabei das Verständnis der Quelle der Wahrheit, der Unterschiede zwischen QWEN.md und tech-stack.md, der Gründe für das Schreiben der Spezifikation vor der Implementierung, des Inhalts von validation.md und der Sicherheitsregeln für Geheimnisse demonstrieren

Eine Rollenspiel-Interaktion „Autor-Reviewer" in einer Paarprüfung durchführen und dabei die Fähigkeit zeigen, konstruktives Feedback auf vier Review-Ebenen zu geben und zu erhalten: Code, Spezifikationen, Fakten, Prozess

Überblick: Die praktische Prüfung ist der Höhepunkt des SDD-Kurses (Specification-Driven Development), der den passiven Test durch eine reale Überprüfung der Fähigkeiten ersetzt. Der Studierende muss die Fähigkeit nachweisen, ein Feature durch den vollständigen Zyklus zu führen: von der Absicht bis zur Überprüfung unter Verwendung von Qwen Code CLI. Die Prüfung besteht aus vier Blöcken: Schnellfragen (theoretische Basis), Problemanalyse in Spezifikationen (kritisches Denken), Umschreiben der Spezifikation im SDD-Format (Dokumentationspraxis) und Abschlussprojekt „Feedback-Formular" (vollständiger Entwicklungszyklus). Besonderheit der Prüfung ist die Unterstützung einer Paarvariante, bei der die Teilnehmer die Rollen des Autors und Reviewers abwechseln, was reale Teamarbeit modelliert und die Illusion der Passivität des Reviews aufhebt. Die Bewertung auf einer 25-Punkte-Skala umfasst fünf Dimensionen: Spezifikationen, Implementierung, Überprüfung, Prozess, Teambereitschaft und Sicherheit. Ein Ergebnis von 21+ Punkten bedeutet Bereitschaft für die industrielle Anwendung von SDD.

Schlüsselkonzepte: Quelle der Wahrheit in SDD: Eine versionierte Spezifikation im Repository, nicht das Gedächtnis des Agenten, mündliche Absprachen oder externe Dokumente. Dies ermöglicht den Austausch von Agenten und IDEs bei gleichzeitiger Aufrechterhaltung der Prozesskontinuität. Jede Abweichung zwischen Spezifikation und Code ist ein Defekt, der behoben werden muss.

Qwen.md vs tech-stack.md: QWEN.md legt die Verhaltensregeln des Agenten fest (wie zu arbeiten ist), tech-stack.md — die technischen Entscheidungen des Produkts (was zu verwenden ist). Eine Überschneidung ist unzulässig: Die Verfassung des Agenten ist von der Architektur des Produkts getrennt. tech-stack.md — langfristige Entscheidungen (Sprache, Framework, DBMS); requirements.md des Features — Entscheidungen auf Ebene einer einzelnen Phase (Routen, Felder, Fehlertexte).

Spezifikation vor Implementierung: Der Agent darf keine Grenzen und Akzeptanzkriterien erraten. Die Spezifikation fixiert die Absicht des Menschen, bevor der Agent mit der Code-Generierung beginnt. Dies verhindert „Halluzinationen" des Agenten und liefert die Grundlage für eine objektive Überprüfung.

Validation.md: Enthält vier Elemente: Befehle für automatische Überprüfungen (npm test, typecheck), manuelle Überprüfungen mit konkreten Schritten, Abweichungsüberprüfungen (Vergleich von Code mit Spezifikation), Definition der Fertigstellung (klares Kriterium für den Abschluss der Phase). Ohne validation.md ist es unmöglich, objektiv zu sagen, ob ein Feature abgeschlossen ist.

Neuplanung: Wird zwischen Features durchgeführt, wenn neue Erkenntnisse die Verfassung (QWEN.md), die Roadmap (roadmap.md) oder den Prozess aktualisieren müssen. Eine Änderung der Spezifikation wird in einen separaten Branch ausgelagert, wenn sie den Stack, die Roadmap, die Verfassung, die Agentenregeln oder mehrere zukünftige Features betrifft.

Befehl /clear zwischen Phasen: Überprüft, ob genügend Kontext in Dateien aufgezeichnet wurde. Ohne /clear kann der Agent weiterhin auf veralteten Kontext der vorherigen Phase angewiesen sein, was zu „Leakage" von Absichten und unkontrollierbaren Entscheidungen führt.

Drei Fragen vor der Spezifikation: Grenzen (was in die Arbeit einfließt), Entscheidungen (welche technischen Wahlen getroffen wurden), Kontext (welche Einschränkungen und Voraussetzungen existieren). Die Antworten auf diese Fragen bilden die Struktur von requirements.md.

Sicherheit von Geheimnissen: API-Schlüssel, Zugriffstoken, Passwörter, private Schlüssel, personenbezogene Daten von Benutzern, interne URLs und Infrastruktur-Identifikatoren dürfen nicht in QWEN.md, Spezifikationen und im Gedächtnis des Agenten gespeichert werden. Spezifikationen werden committet und vom Agenten gelesen; Geheimnisse müssen in Umgebungsvariablen oder einem Geheimnisspeicher leben.

Projektfähigkeit vs persönliche Fähigkeit: Die Projektfähigkeit wird vom Team geteilt und mit dem Repository versioniert. Die persönliche Fähigkeit ist an einen Benutzer gebunden und wird nicht vererbt. Die Projektfähigkeit gewährleistet die Austauschbarkeit des Agenten — die Möglichkeit, den Agenten oder die IDE zu wechseln und den Prozess durch Repository-Artefakte aufrechtzuerhalten.

Austauschbarkeit des Agenten: Die Möglichkeit, den Agenten oder die IDE zu wechseln und den Prozess durch Repository-Artefakte aufrechtzuerhalten. Wird dadurch erreicht, dass alle wesentlichen Informationen in versionierten Dateien und nicht im Gedächtnis des Agenten oder in den Gewohnheiten eines bestimmten Entwicklers liegen.

Review in SDD-Projekt: Der Reviewer überprüft nicht nur Code, sondern auch Anforderungen, Plan, Überprüfungsfakten, Änderungen außerhalb der Feature-Grenzen und die Übereinstimmung von Implementierung und Spezifikation. Vier Review-Ebenen: Code, Spezifikationen, Fakten, Prozess.

Drei Arten von Änderungen im PR außer Code: Änderungen in tech-stack.md oder roadmap.md ohne Diskussion; neue Hooks, MCP-Server oder Abhängigkeiten; Abweichung zwischen validation.md und Fakten im PR.

Grüne Punkte in MVP-Phase: Tagging von Commits, die einen funktionierenden Inkrement liefern. Sichert einen Rollback-Punkt ohne Verlust der gesamten Phasenarbeit und macht das Signal „nächste Gruppe bricht alles" explizit.

Schutz-Hook vs protokollierender Hook: Der Schutz-Hook blockiert eine Operation nach Regel (PreToolUse, nicht-nuller Rückgabecode); der protokollierende Hook schreibt nur ein Ereignis und beeinflusst den Arbeitsablauf nicht. Die Trennung der Verantwortlichkeiten ist für die Sicherheit kritisch.

Agentengedächtnis auf SQLite: Gerechtfertigt, wenn das Team stabile Beobachtungen über Code und Prozess ansammelt. Überflüssig, wenn QWEN.md, Verfassung und Änderungsprotokoll ausreichen. Gedächtnis — Hinweis und Protokoll stabiler Schlussfolgerungen; Spezifikation — reviewbare Quelle der Wahrheit für das Produkt.

Antipatterns bei SDD-Anfängerteams: Spezifikation ohne Fakten (nicht überprüfbar), Zusammenführen von Verfassung und Spezifikation in einer Datei (Verletzung der Verantwortungstrennung), Implementierung ohne /clear zwischen Phasen (Kontextleakage und unkontrollierbare Entscheidungen).

Externer Text als Anweisung: Issues, Webseiten, Logs und externe Dokumente dürfen nicht als vertrauenswürdige Anweisungen für den Agenten betrachtet werden, da sie Anweisungsinjektionen enthalten können. Sie müssen als Daten gelesen werden, nicht als Handlungsanweisungen.

Paarprüfung: Realistische Prüfungsform: Autor schreibt Spezifikation und implementiert, Reviewer überprüft Spezifikation vor Implementierung, führt Überprüfungen selbstständig durch, gibt strukturiertes Feedback. Rollen wechseln beim zweiten Feature. Jeder wird nach seiner eigenen Rubrik bewertet.

Übungen: Titel: Block 1: Schnellfragen — Selbstüberprüfung

Problem: Beantworten Sie 22 Kontrollfragen schriftlich ohne Verwendung von Qwen Code. Beispielfragen: Was ist die Quelle der Wahrheit in SDD? Worin unterscheidet sich QWEN.md von specs/tech-stack.md? Warum wird die Feature-Spezifikation vor der Implementierung geschrieben? Was muss in validation.md stehen? Wann ist Neuplanung erforderlich? Warum ist /clear zwischen Phasen nützlich? Welche drei Fragen müssen vor Erstellung einer Feature-Spezifikation gestellt werden? Warum dürfen API-Schlüssel nicht in Spezifikationen gespeichert werden? Worin ist die Projektfähigkeit für das Team besser als die persönliche Fähigkeit? Was bedeutet Austauschbarkeit des Agenten? Was muss der Reviewer in SDD-Projekten außer Code überprüfen? Wann muss eine Spezifikationsänderung in einen separaten Neuplanungs-Branch ausgelagert werden? Wozu dienen Qwen Code Hooks? Warum darf externer Text nicht als vertrauenswürdige Anweisung für den Agenten betrachtet werden? Worin unterscheidet sich das Gedächtnis des Agenten von der Spezifikation? Wo verläuft die Grenze zwischen tech-stack.md und requirements.md eines Features? Welche drei Arten von Änderungen im Pull-Request muss der Reviewer außer Code suchen? Wozu dient das Taggen von „grünen Punkten" während der MVP-Phase? Worin unterscheidet sich ein Schutz-Hook von einem Hook zur Protokollierung von Werkzeugen? Welche Daten fallen in die Kategorie „Geheimnisse"? Welche drei Antipatterns aus Teil 20 treten bei SDD-Anfängerteams am häufigsten auf? Wann ist die Anbindung des Agentengedächtnisses an SQLite gerechtfertigt und wann überflüssig?

Lösung: 1. Versionierte Spezifikation im Repository. 2. QWEN.md legt Verhaltensregeln des Agenten fest; tech-stack.md legt technische Produktentscheidungen fest. 3. Damit der Agent keine Grenzen und Akzeptanzkriterien errät. 4. Befehle, manuelle Überprüfungen, Abweichungsüberprüfungen und Definition der Fertigstellung. 5. Zwischen Features, wenn neue Erkenntnisse die Verfassung, Roadmap oder den Prozess aktualisieren müssen. 6. Er überprüft, ob genügend Kontext in Dateien aufgezeichnet wurde. 7. Grenzen, Entscheidungen, Kontext. 8. Spezifikationen werden committet und vom Agenten gelesen; Geheimnisse müssen in Umgebungsvariablen oder einem Geheimnisspeicher leben. 9. Die Projektfähigkeit wird vom Team geteilt und mit dem Repository versioniert. 10. Möglichkeit, den Agenten oder die IDE zu wechseln und den Prozess durch Repository-Artefakte aufrechtzuerhalten. 11. Anforderungen, Plan, Überprüfungsfakten, Änderungen außerhalb der Feature-Grenzen und Übereinstimmung von Implementierung und Spezifikation. 12. Wenn die Änderung den Stack, die Roadmap, die Projektverfassung, die Agentenregeln oder mehrere zukünftige Features betrifft. 13. Um automatisch kleine wiederholbare Aktionen auszuführen: Kontext hinzufügen, Protokoll führen, gefährliche Befehle überprüfen, Ereignisse sammeln. 14. Weil Issues, Webseiten, Logs und externe Dokumente Anweisungsinjektionen enthalten können; sie müssen als Daten gelesen werden. 15. Gedächtnis — Hinweis und Protokoll stabiler Schlussfolgerungen; Spezifikation — reviewbare Quelle der Wahrheit für das Produkt. 16. tech-stack.md — langfristige Projektentscheidungen; requirements.md des Features — Entscheidungen auf Ebene einer einzelnen Phase. 17. Änderungen in tech-stack.md oder roadmap.md ohne Diskussion; neue Hooks, MCP-Server oder Abhängigkeiten; Abweichung zwischen validation.md und Fakten im PR. 18. Um einen Rollback-Punkt ohne Verlust der gesamten Phasenarbeit zu haben und damit das Signal „nächste Gruppe bricht alles" explizit ist. 19. Schutz-Hook blockiert Operation nach Regel; protokollierender Hook schreibt nur ein Ereignis. 20. API-Schlüssel, Zugriffstoken, Passwörter, private Schlüssel, personenbezogene Daten von Benutzern, interne URLs und Infrastruktur-Identifikatoren. 21. Spezifikation ohne Fakten, Zusammenführen von Verfassung und Spezifikation in einer Datei, Implementierung ohne /clear zwischen Phasen. 22. Gedächtnis gerechtfertigt, wenn das Team stabile Beobachtungen ansammelt; überflüssig, wenn QWEN.md, Verfassung und Änderungsprotokoll ausreichen.

Schwierigkeitsgrad: Mittelstufe

Titel: Block 2: Finden Sie Probleme in der Spezifikation

Problem: Gegeben ist eine Feature-Spezifikation:

Anforderungen — Dashboard

Baue ein schönes Dashboard für Administratoren.

Grenzen

Zeige nützliche Statistiken und Diagramme.

Entscheidungen

Verwende die beste Bibliothek.

Überprüfung

Stelle sicher, dass alles funktioniert.

Finden Sie mindestens 8 Probleme. Notieren Sie jedes Problem und erklären Sie, warum es für den SDD-Prozess kritisch ist.

Lösung: Mindestens 11 Probleme:

1. Zielgruppe nicht angegeben — „Administratoren" nicht definiert, kein Verständnis, wer genau das Dashboard nutzen wird.
2. Keine Grenzen dessen, was nicht in die Arbeit einfließt — unmöglich zu sagen, wann das Feature fertig ist.
3. „Schönes" ist nicht überprüfbar — subjektives Kriterium, automatische Überprüfung unmöglich.
4. „Nützliche Statistik" nicht definiert — keine konkreten Metriken, die angezeigt werden sollen.
5. „Diagramme" nicht definiert — keine Angabe zu Typen, Datenquellen, Formaten.
6. Abhängigkeit ohne Überprüfung von tech-stack.md erlaubt — „beste Bibliothek" kann dem genehmigten Stack widersprechen.
7. Keine Datenquelle — unklar, woher die Daten für die Statistik kommen.
8. Keine Route — keine URL angegeben, unter der das Dashboard erreichbar ist.
9. Keine Zugriffsrechte — nicht definiert, wer welche Daten sehen darf.
10. Keine automatischen Überprüfungen — validation.md leer, CI/CD unmöglich.
11. Kein manuelles Überprüfungsszenario — Tester weiß nicht, was zu tun ist.
12. Keine Fertigkeitsdefinition — kein Kriterium für den Phasenabschluss.

Schwierigkeitsgrad: Mittelstufe

Titel: Block 3: Schreiben Sie die Spezifikation im SDD-Format um

Problem: Schreiben Sie die Dashboard-Spezifikation im SDD-Format unter Berücksichtigung der Einschränkungen um: HTML wird serverseitig gerendert; SQLite; in dieser Phase keine Authentifizierung; Route /dashboard; Anzeige der Anzahl von Agenten, Krankheiten, Therapien und Terminen; noch keine Diagrammbibliothek hinzufügen; npm test und npm run typecheck müssen bestehen.

Erforderliche Struktur:

Anforderungen — Administrator-Dashboard

Grenzen

Außerhalb der Grenzen

Entscheidungen

Kontext

Kurzüberprüfung

Lösung: ```markdown

Anforderungen — Administrator-Dashboard

Grenzen

• Serverseitiges HTML-Rendering auf der Route /dashboard
• Anzeige von vier Zählern: Agenten, Krankheiten, Therapien, Termine
• Daten aus bestehender SQLite-Datenbank
• Grundlegendes Layout ohne externe CSS-Frameworks

Außerhalb der Grenzen

• Authentifizierung und Autorisierung (Phase ohne Auth)
• Diagrammbibliotheken (Chart.js, D3 usw.)
• Filterung, Sortierung, Suche nach Daten
• Berichtsexport
• WebSocket-Aktualisierungen in Echtzeit

Entscheidungen

• SQL-Abfragen SELECT COUNT(*) für jede Entität
• Serverseitiger Templating-Engine des Projekts (konkrete gemäß tech-stack.md angeben)
• Route wird zum bestehenden Router hinzugefügt
• Stile im Rahmen des bestehenden CSS-Ansatzes des Projekts

Kontext

• Phase ohne Authentifizierung: Dashboard für alle über direkte URL erreichbar
• SQLite wird bereits im Projekt verwendet, Schema existiert
• MVP-Ansatz: Diagramme zurückgestellt bis zur Bestätigung des Bedarfs

Kurzüberprüfung

Automatisch:

• npm run typecheck läuft fehlerfrei durch
• npm test läuft durch, einschließlich neuer Route-Tests
• Route /dashboard gibt HTTP 200 zurück

Manuell:

• /dashboard öffnen, 4 Zahlen sehen
• Überprüfen, dass Zahlen den realen Daten in der Datenbank entsprechen
• Überprüfung der Anzeige auf Mobilgerät (320px) und Desktop (1280px)
• Überprüfen, dass Link auf Dashboard in Navigation fehlt (kein Auth)

Fertigstellung: Alle automatischen Überprüfungen bestehen, manuelle Überprüfungen durchgeführt, keine Geheimnisse im Code.

Schwierigkeitsgrad: Mittelstufe

Titel: Block 4: Abschlussprojekt — Feedback-Formular

Problem: Führen Sie auf Ihrem AgentClinic oder einem anderen kleinen Projekt aus. Fügen Sie das Feature „Feedback-Formular" hinzu: Seite `/feedback`; Formular mit `name` und `message`; POST-Route; Speicherung in SQLite; Liste der letzten Feedback-Einträge; grundlegende Validierung; Tests; Änderungsprotokoll. Folgen Sie dem Prozess: sauberer main → Feature-Branch → Spezifikationsverzeichnis specs/YYYY-MM-DD-feedback-form/ mit requirements.md, plan.md, validation.md → Commit der Spezifikation vor Implementierung → Implementierung nach Gruppen → Überprüfung in separater Qwen Code-Sitzung → Aktualisierung von Roadmap und Änderungsprotokoll → Pull-Request nach SDD-Vorlage → Sicherheitsüberprüfung → Merge nach Überprüfungen. Verwenden Sie empfohlene Qwen Code-Szenarien für jede Phase.

Lösung: Vollständiger schrittweiser Prozess:

**Vorbereitung:**

git checkout main git pull git checkout -b feature/feedback-form mkdir -p specs/2024-01-15-feedback-form

**Phase 1: Spezifikation (Qwen Code-Sitzung):**

/clear Verwende den Feature-Spezifikations-Skill, um die nächste Phase der Roadmap zu starten: Feedback-Formular. Frage mich vor dem Schreiben der Dateien nach Grenzen, Entscheidungen und Kontext. Implementiere noch keinen Code.

requirements.md, plan.md, validation.md erstellen, committen.

**Phase 2: Implementierung (neue Qwen Code-Sitzung):**

/clear Lies @QWEN.md, @specs/mission.md, @specs/tech-stack.md, @specs/2024-01-15-feedback-form/requirements.md, @specs/2024-01-15-feedback-form/plan.md, und @specs/2024-01-15-feedback-form/validation.md.

Implementiere nur Gruppe 1. Stoppe nach der Liste der geänderten Dateien.

Für jede Plan-Gruppe wiederholen, grüne Punkte taggen.

**Phase 3: Überprüfung (neue Qwen Code-Sitzung):**

/clear Vergleiche aktuellen Branch mit @specs/2024-01-15-feedback-form/validation.md. Zeige, was bestanden, was fehlgeschlagen ist und wo Lücken bestehen. Ändere keine Dateien.

Gefundene Probleme in separater Sitzung beheben.

**Phase 4: Abschluss:**

Verwende den Änderungsprotokoll-Skill und aktualisiere @CHANGELOG.md für den Feedback-Formular-Branch.

roadmap.md aktualisieren, PR nach Vorlage vorbereiten, Abwesenheit von Geheimnissen überprüfen, Merge durchführen.

**Selbstbewertung nach 25 Punkten:**
- Spezifikationen (5): Vorhandensein von drei Dateien, konkrete Grenzen, Übereinstimmung mit tech-stack.md, Plan-Gruppierung, automatische und manuelle Überprüfungen
- Implementierung (5): Übereinstimmung mit Spezifikation, keine überflüssigen Refactorings, verständliche Migration, Projekt-Konventionen, Fehlerbehandlung
- Überprüfung (5): typecheck, Tests, manueller Durchlauf, fehlerhafte Eingabe, Responsivität
- Prozess (5): korrekter Branch, Spezifikation vor Code, aktualisierte Roadmap und Changelog, Übereinstimmungsüberprüfung
- Teambereitschaft und Sicherheit (5): Beschreibung der Verbindung im PR, keine Änderungen außerhalb der Grenzen, keine Geheimnisse, Review der Hooks, explizite schwache Fakten

Schwierigkeitsgrad: Mittelstufe

Fallstudien:
Titel: Fallstudie: AgentClinic — Einführung des Feedback-Formulars durch vollständigen SDD-Zyklus

Szenario: Ein kleines Team aus zwei Entwicklern verwendet AgentClinic (vereinfachtes Klinik-Management-System) zur Schulung der SDD-Methodologie. Das Produkt läuft auf Node.js + SQLite mit serverseitigem Rendering. Benutzer beschweren sich, dass es keine Möglichkeit gibt, über Probleme ohne E-Mail zu informieren. Das Team beschließt, ein Feedback-Formular als Schulungsfeature für die praktische Prüfung durch den vollständigen SDD-Zyklus hinzuzufügen.

Herausforderung: Beide Entwickler arbeiteten zuvor nach dem klassischen Agile-Modell mit informellen Anforderungen. Probleme: (1) Gewohnheit, Code direkt nach der Diskussion zu schreiben, ohne Dokumentation; (2) Unverständnis, wozu validation.md nötig ist, wenn „sowieso alles überprüft wird"; (3) Angst, dass /clear „nützlichen Kontext löscht"; (4) Unwillen, Spezifikationen und nicht nur Code zu reviewen; (5) Speicherung eines Test-API-Schlüssels in QWEN.md zur Bequemlichkeit.

Lösung: Das Team wendet die Paarprüfung an: Entwickler A — Autor, Entwickler B — Reviewer. Der Autor beginnt mit /clear und erstellt die Spezifikation über den Qwen Code-Skill, indem er drei Fragen beantwortet (Grenzen, Entscheidungen, Kontext). Der Reviewer liest requirements.md vor der Implementierung und findet eine kritische Lücke: keine Längenbeschränkung für message (SQL-Injection durch langen Text). Spezifikation wird vor dem Commit überarbeitet. Implementierung erfolgt nach Gruppen mit /clear zwischen Phasen. Überprüfung wird auf dem Rechner des Reviewers durchgeführt, der feststellt, dass Tests bestehen, aber die manuelle Überprüfung zeigt: Das Formular akzeptiert leere Namen (Spezifikation erforderte „grundlegende Validierung", präzisierte aber nicht konkret). Dies wird als „schwacher Fakt" für die Retrospektive festgehalten. Vor dem Merge überprüft der Reviewer die Abwesenheit von Geheimnissen — findet Test-API-Schlüssel in QWEN.md, entfernt ihn, fügt Regel zu .gitignore und Projektverfassung hinzu.

Ergebnis: Feature mit Bewertung 23/25 gemergt. Verlorene Punkte: (1) in validation.md kein expliziter XSS-Test in message (manuell gefunden, aber nicht formalisiert), (2) roadmap.md aktualisiert, aber ohne Priorität des nächsten Features. Retrospektive zeigte: „Was der Agent selbst ableiten musste" — 2 Punkte (konkrete Längenbeschränkung, Fehleranzeige-Format), was akzeptabel ist. Team fixierte Regel: Bei mehr als 3 Punkten wird nächste Spezifikation ausführlicher. Projektfähigkeit „Spezifikation Feedback-Formular" zum Repository hinzugefügt und als Vorlage für neue Features verwendet.

Erkenntnisse:
Review der Spezifikation vor Implementierung spart 3-5 Stunden Code-Nacharbeit; vom Reviewer gefundene Lücke mit Längenbeschränkung verhinderte Produktionsvorfall

/clear zwischen Phasen offenbarte, dass validation.md der ersten Version unvollständig war — Agent konnte ihn nicht als Kontext verwenden, was Notwendigkeit der Überarbeitung bewies

Paarformat schafft gesunden Druck: Autor strebt Konkretheit an, Reviewer trainiert Fähigkeit, konstruktives Feedback auf vier Ebenen zu geben

Überprüfung auf Rechner des Reviewers statt auf Wort des Autors fand Versionsabweichung in Node.js, die typecheck nicht erfasste — bestätigte Wichtigkeit unabhängiger Verifikation

Gefundener API-Schlüssel in QWEN.md führte zu Erstellung eines Schutz-Hooks PreToolUse, der Commits mit Schlüsselmustern blockiert — Investition in Sicherheit zahlte sich sofort aus

Verwandte Konzepte:
Quelle der Wahrheit in SDD

Paarprüfung und Rollen von Autor-Reviewer

validation.md und vier Elemente der Überprüfung

Sicherheit von Geheimnissen und Schutz-Hooks

/clear zwischen Phasen

SDD-Retrospektive und Schwellenwert von 3 Punkten

Projektfähigkeit vs persönliche Fähigkeit

Titel: Fallstudie: Umschreiben der Administrator-Dashboard-Spezifikation — vom Antipattern zum Vorbild

Szenario: Ein Entwickler-Student erhält die Aufgabe, die Dashboard-Spezifikation aus Block 2 des Kurses umzuschreiben. Ursprüngliche Spezifikation ist typisch für „Agile-Eile": schöne Worte, subjektive Kriterien, fehlende Grenzen. Student soll SDD-Ansatz unter Berücksichtigung realer Einschränkungen des AgentClinic-Projekts anwenden.

Herausforderung: Dem Studenten fällt es schwer, von gewohnten Formulierungen wie „schönes Dashboard" und „nützliche Statistik" abzulassen. Psychologischer Widerstand: Es scheint, als würde Konkretheit „Kreativität töten". Technische Schwierigkeit: Muss fehlende Authentifizierung in aktueller Phase berücksichtigen, was Datenleck-Risiko schafft. Weiteres Problem: Student möchte Chart.js „für alle Fälle" hinzufügen, obwohl explizit verboten.

Lösung: Student durchläuft Checkliste mit 11 Problemen der ursprünglichen Spezifikation. Für jedes Problem formuliert er konkrete Ersetzung: „schön" → „grundlegendes Layout im Rahmen des bestehenden CSS-Ansatzes", „nützliche Statistik" → „vier Zähler: Agenten, Krankheiten, Therapien, Termine". Besondere Aufmerksamkeit für Abschnitt „Außerhalb der Grenzen": explizite Angabe „keine Authentifizierung" schützt vor Versuchung, Login „solange Hände im Code" hinzuzufügen. Abschnitt „Entscheidungen" wird mit tech-stack.md des Projekts abgeglichen — bestätigte Verwendung bestehender Templating-Engine, keine neue Bibliothek hinzugefügt. Validation.md enthält Mobilüberprüfung, die Student ursprünglich als „überflüssig" betrachtete.

Ergebnis: Spezifikation vom Reviewer mit einer Anmerkung angenommen: keine maximale Länge der SQL-Abfrage bei großem Datenvolumen angegeben (COUNT(*) kann bei Millionen von Datensätzen langsam sein). Hinweis in „Kontext" über aktuelle Datenbankgröße und Bedingung zur Überprüfung bei Wachstum hinzugefügt. Student erkennt: Konkretheit tötet nicht Kreativität, sondern verlagert sie in architektonische Entscheidungen auf Projektebene statt auf Ebene „aus dem Stegreif erfinden".

Erkenntnisse:
Jede unklare Formulierung — potenzieller Konflikt zwischen Autor und Implementierer; Konkretheit — Investition in Vorhersagbarkeit

Abschnitt „Außerhalb der Grenzen" oft wichtiger als „Grenzen": er schützt vor Scope Creep und gibt psychologische Erlaubnis „jetzt nicht zu tun"

Mobilüberprüfung, die für Admin-Panel „überflüssig" schien, fand reales Problem: Tabelle mit 4 Zählern brach bei 320px wegen flex-wrap

Abgleich mit tech-stack.md vor Fixierung von Entscheidungen verhinderte Hinzufügung von Chart.js „für alle Fälle" — Einsparung von 2-3 Tagen Integration unnötiger Abhängigkeit

Verwandte Konzepte:
Grenzen und außerhalb der Grenzen in Spezifikationen

tech-stack.md als Beschränkung von Entscheidungen

validation.md mit manuellen und automatischen Überprüfungen

Neuplanung und zurückgestellte Fakten

Konkretheit vs Subjektivität in Anforderungen

Lerntipps:
Bearbeiten Sie die Blöcke sequentiell, ohne zu springen: Theorie (Block 1) → Kritische Analyse (Block 2) → Konstruktion (Block 3) → Vollständiger Zyklus (Block 4). Jeder Block bereitet Fähigkeiten für den nächsten vor

Für Block 1: Schreiben Sie Antworten von Hand oder in Texteditor ohne Nachschauen, vergleichen Sie dann. Mechanisches Auswendiglernen ist nutzlos — Verständnis der Logik ist wichtig, um auf neue Situationen anzupassen

Für Block 2: Hören Sie nicht bei 8 Problemen auf. Je mehr Sie finden, desto tiefer das Verständnis. Vergleichen Sie Ihre Funde mit dem Kurs-Checkliste — wenn Sie etwas Wichtiges übersehen haben, kehren Sie zum entsprechenden Kursteil zurück

Für Block 3: Schreiben Sie die Spezifikation zweimal um: erst selbstständig, zweitens nach Lesen des Musters. Vergleichen Sie: Wo ist Ihre Variante präziser, wo überflüssig

Für Block 4: Verwenden Sie unbedingt /clear zwischen Phasen. Das ist kein Ritual, sondern funktionale Überprüfung: Wenn der Agent nach /clear nicht ohne Ihre Erklärungen fortfahren kann — Spezifikation ist unzureichend

Finden Sie einen Partner für die Paarprüfung, auch wenn Sie selbstständig lernen. Reviewer-Rolle kann man selbst durch zeitlichen Abstand „spielen": Spezifikation schreiben, einen Tag warten, dann als Reviewer lesen

Führen Sie ein persönliches SDD-Fehler-Journal: Notieren Sie, welche Probleme Sie übersehen haben, welche Antipatterns sich wiederholten. Das wird Ihr „Agentengedächtnis" — aber persönlich, projektbezogen, versioniert

Für Retrospektive: Seien Sie ehrlich im Abschnitt „Was der Agent selbst ableiten musste". Bei mehr als 3 Punkten — kein Versagen, sondern Signal für nächste Iteration. Probleme verbergen ist teurer als deren Anerkennung

Üben Sie die Erklärung des SDD-Ansatzes einem Kollegen, der mit der Methodologie nicht vertraut ist. Wenn Sie es nicht in 5 Minuten erklären können — verstehen Sie es selbst nicht ganz

Verwenden Sie einen Timer: 30 Minuten für Spezifikation, 60 für Implementierung, 30 für Überprüfung. Strenge Zeitrahmen simulieren realen Druck und lehren, Konkretheit zu priorisieren

Vor der Abschlussprüfung: Führen Sie einen Probelauf mit einem erdachten Feature (z.B. „Newsletter-Abonnement") durch, ohne bis zum Merge zu führen. Das reduziert Angst und zeigt Schwachstellen im Prozess

Zusätzliche Ressourcen:
Teile 1-21 des SDD-Kurses: Grundmaterial, auf das die praktische Prüfung verweist. Besonders wichtig: Teil 6 (Grenzen von tech-stack.md und requirements.md), Teil 7 (Präzisierung), Teil 12 (MVP und grüne Punkte), Teil 16 (vier Review-Ebenen), Teil 17 (Hooks), Teil 18 (Geheimnisse), Teil 19 (Agentengedächtnis), Teil 20 (Antipatterns)

Qwen.md — Vorlage für Agentenverfassung: Beispieldatei, die Verhaltensregeln des Agenten festlegt. Verwenden Sie als Basis für Ihr Projekt, aber kopieren Sie nicht ohne Anpassung

Specs/tech-stack.md — Beispiel für technischen Stack: Musterdokument mit langfristigen Projektentscheidungen. Achten Sie auf Struktur und Detaillierungsgrad

Changelog.md — Vorlage für Änderungsprotokoll: Beispielformat für Feature-bezogene Änderungsdokumentation. Wichtig für Prozesspunkt in der Prüfung

Git flow / github flow: Materialien zur Arbeit mit Branches. SDD schreibt kein bestimmtes Modell vor, erfordert aber Feature-Isolation und Commit der Spezifikation vor Implementierung

OWASP Cheat Sheet Series: Praktische Sicherheitsempfehlungen. Besonders Abschnitte zur Eingabevalidierung und Geheimnisspeicherung — direkt verknüpft mit validation.md und Sicherheitsanforderungen der Prüfung

Cognitive Load Theory in Software Development: Verständnis der kognitiven Belastung hilft zu erkennen, wozu /clear und Phasentrennung dienen — Schlüsselpraktiken von SDD

Beispielspezifikationen aus offenen SDD-Projekten: Reale specs/-Verzeichnisse mit requirements.md, plan.md, validation.md zum Vergleich mit Ihrem Detaillierungsgrad

Zusammenfassung: Die praktische Prüfung ist kein Auswendiglern-Examen, sondern eine Demonstration der Fähigkeit, ein reales Feature durch den vollständigen SDD-Zyklus zu führen. Schlüsselfähigkeiten: konkrete Spezifikationen mit messbaren Kriterien schreiben, Qwen Code CLI als Werkzeug mit klaren Phasen und /clear dazwischen nutzen, vierstufiges Review durchführen (Code, Spezifikationen, Fakten, Prozess), Sicherheit durch Isolation von Geheimnissen und Schutz-Hooks gewährleisten. Erfolgreiche Prüfung (21+/25) bedeutet Bereitschaft für industrielle Anwendung; Ergebnis 16-20 erfordert Verbesserung der Überprüfung und des Teamkontexts; unter 16 zeigt Notwendigkeit, Phasengröße zu reduzieren und Spezifikationen zu detaillieren. Das Paarformat der Prüfung modelliert reale Teamdynamik und lehrt beide Seiten des SDD-Dialogs. Die abschließende Retrospektive mit Schwellenwert von 3 Punkten „selbst Abgeleitetem" schafft einen Mechanismus zur kontinuierlichen Verbesserung. Hauptprinzip: SDD geht nicht um mehr Dokumentation, sondern um richtige Dokumentation zum richtigen Zeitpunkt, damit der Agent nicht errät, sondern überprüfbare Absichten ausführt.