Teil 22. Praktische Abschlussprüfung

Dieser Teil ersetzt den passiven Test durch eine praktische Überprüfung. Das Ziel ist es zu beweisen, dass Sie ein Feature durch den SDD-Zyklus mit Qwen Code CLI führen können: von der Absicht bis zur Validierung.

Block 1. Schnelle Fragen

Beantworten Sie schriftlich, ohne Qwen Code.

1. Was ist die Quelle der Wahrheit in SDD?
2. Worin unterscheidet sich QWEN.md von specs/tech-stack.md?
3. Warum wird die Feature-Spezifikation vor der Implementierung geschrieben?
4. Was muss in validation.md enthalten sein?
5. Wann muss eine Neuausrichtung erfolgen?
6. Warum ist /clear zwischen Arbeitsphasen nützlich?
7. Welche drei Fragen müssen vor der Erstellung einer Feature-Spezifikation gestellt werden?
8. Warum dürfen API-Schlüssel nicht in Spezifikationen gespeichert werden?
9. Worin ist ein Projektskill besser als ein persönlicher Skill für das Team?
10. Was bedeutet Austauschbarkeit des Agenten?
11. Was muss der Reviewer in einem SDD-Projekt neben dem Code überprüfen?
12. Wann muss eine Spezifikationsänderung in einen separaten Neuausrichtungs-Branch ausgelagert werden?
13. Wozu dienen Qwen Code-Hooks?
14. Warum darf externer Text nicht als vertrauenswürdige Anweisung für den Agenten betrachtet werden?
15. Worin unterscheidet sich der Agentenspeicher von der Spezifikation?
16. Wo verläuft die Grenze zwischen tech-stack.md und requirements.md eines Features (Teil 6)?

1. Welche drei Arten von Änderungen muss der Reviewer in einem Pull-Request außer Code suchen (Teil 16)?
2. Warum müssen „grüne Punkte“ während der MVP-Phase getaggt werden (Teil 12)?
3. Worin unterscheidet sich ein Schutz-Hook von einem Hook zur Protokollierung von Tools (Teil 17)?
4. Welche Daten gehören zur Kategorie „Geheimnisse“, die nicht in QWEN.md, Spezifikationen und Speicher gehören dürfen (Teil 18)?
5. Welche drei Antipatterns aus Teil 20 treten bei Anfänger-SDD-Teams am häufigsten auf?
6. Wann ist die Aktivierung des Agentenspeichers auf SQLite gerechtfertigt, und wann ist sie überflüssig (Teil 19)?

Block 2. Finden Sie Probleme in der Spezifikation

Gegeben ist eine Feature-Spezifikation:

# Anforderungen — Dashboard

Baue ein schönes Dashboard für Administratoren.

## Grenzen

Zeige nützliche Statistiken und Diagramme.

## Lösungen

Verwende die beste Bibliothek.

## Validierung

Stelle sicher, dass alles funktioniert.

Finden Sie mindestens 8 Probleme. Eine gute Antwort sollte bemerken:

• keine Zielgruppe angegeben;
• keine Grenzen dessen, was nicht zur Arbeit gehört;
• „schönes“ ist nicht überprüfbar;
• „nützliche Statistik“ ist nicht definiert;
• „Diagramme“ sind nicht definiert;
• Abhängigkeit ohne Prüfung von tech-stack.md genehmigt;
• keine Datenquelle;
• keine Route;
• keine Zugriffsrechte;

• keine automatischen Prüfungen;
• kein manuelles Validierungsszenario;
• keine Fertigkeitsdefinition.

Block 3. Schreiben Sie die Spezifikation um

Schreiben Sie das Dashboard in SDD-Format um:

# Anforderungen — Administrator-Dashboard

## Grenzen

## Außerhalb der Grenzen

## Lösungen

## Kontext

## Kurzvalidierung

Einschränkungen:

• HTML wird serverseitig gerendert;
• SQLite;
• in dieser Phase keine Authentifizierung;
• Route /dashboard;
• Anzahl der Agenten, Beschwerden, Therapien und Termine anzeigen;
• noch keine Diagrammbibliothek hinzufügen;
• npm test und npm run typecheck müssen bestehen.

Block 4. Abschlussprojekt

Führen Sie es auf Ihrem AgentClinic oder einem anderen kleinen Projekt aus.

Aufgabe

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.

Prozessanforderungen

1. Beginnen Sie mit einem sauberen main.
2. Erstellen Sie einen Feature-Branch.
3. Erstellen Sie ein Spezifikationsverzeichnis:

specs/YYYY-MM-DD-feedback-form/
  requirements.md
  plan.md
  validation.md

1. Implementierung erst nach Commit der Spezifikation.

1. Validierung in einer separaten Qwen Code-Sitzung.
2. Roadmap aktualisiert.
3. Änderungsprotokoll aktualisiert.
4. Kurze Pull-Request-Beschreibung nach SDD-Vorlage vorbereitet.
5. Sicherheitsprüfung durchgeführt: Geheimnisse sind nicht in Spezifikationen, Logs und Speicher gelandet.
6. Merge erst nach Prüfungen.

Empfohlenes Qwen Code-Szenario

Spezifikationserstellung:

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

Implementierung:

/clear
Lies @QWEN.md, @specs/mission.md, @specs/tech-stack.md,
@specs/YYYY-MM-DD-feedback-form/requirements.md,
@specs/YYYY-MM-DD-feedback-form/plan.md,
und @specs/YYYY-MM-DD-feedback-form/validation.md.

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

Validierung:

/clear
Vergleiche den aktuellen Branch mit @specs/YYYY-MM-DD-feedback-form/validation.md.
Zeige, was bestanden, was durchgefallen und wo Lücken sind.
Ändere keine Dateien.

Änderungsprotokoll:

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

Bewertungskriterien

Bewerten Sie sich selbst mit 25 Punkten.

Spezifikationen — 5 Punkte

• 1: es gibt requirements.md, plan.md, validation.md;
• 1: Arbeitsgrenzen und was nicht dazugehört, sind konkret;
• 1: Lösungen widersprechen dem Technologie-Stack nicht;
• 1: Plan ist in überprüfbare Gruppen unterteilt;
• 1: Validierung enthält automatische und manuelle Prüfungen.

Implementierung — 5 Punkte

• 1: Änderungen entsprechen der Spezifikation;
• 1: keine unzusammenhängenden Refactorings;
• 1: Datenbankmigration ist verständlich und reproduzierbar;
• 1: Routen und Komponenten folgen bestehenden Konventionen;
• 1: Validierungsfehler sind behandelt.

Validierung — 5 Punkte

• 1: npm run typecheck besteht;
• 1: npm test besteht;
• 1: manueller Formular-Durchlauf ausgeführt;
• 1: ungültige Eingabe geprüft;
• 1: grundlegende Prüfung auf Mobil- und Desktop-Bildschirmen ausgeführt, wenn die Benutzeroberfläche geändert wurde.

Prozess — 5 Punkte

• 1: Branch wurde korrekt verwendet;
• 1: Spezifikation wurde vor Implementierung committed;
• 1: Roadmap aktualisiert;
• 1: Änderungsprotokoll aktualisiert;
• 1: Abschlussprüfung vergleicht Code mit Spezifikation.

Team-Readiness und Sicherheit — 5 Punkte

• 1: Merge-Request beschreibt die Verbindung zwischen Spezifikation, Code und Fakten;

• 1: Änderungen außerhalb der Feature-Grenzen fehlen oder sind explizit erklärt;
• 1: Geheimnisse sind nicht in Spezifikationen, Logs und Speicher gelandet;
• 1: neue Hooks, MCP-Server oder Einstellungen fehlen oder wurden geprüft;
• 1: schwache oder aufgeschobene Fakten sind explizit aufgelistet.

21+ Punkte — Prozess ist für echtes Projekt bereit.

16–20 — verwenden Sie SDD weiter, aber verbessern Sie Validierung und Team-Kontur.

Unter 16 — reduzieren Sie die Phasengröße und machen Sie Spezifikationen konkreter.

Antworten auf schnelle Fragen

1. Versionskontrollierte Spezifikation im Repository.
2. QWEN.md legt die Verhaltensregeln des Agenten fest; tech-stack.md legt die technischen Entscheidungen des Produkts fest.
3. Damit der Agent Grenzen und Akzeptanzkriterien nicht erraten muss.
4. Befehle, manuelle Prüfungen, Abweichungsprüfungen und Fertigkeitsdefinition.
5. Zwischen Features, wenn neue Erkenntnisse die Verfassung, Roadmap oder den Prozess aktualisieren müssen.
6. Er prüft, ob genug Kontext in den Dateien aufgezeichnet ist.
7. Grenzen, Lösungen, Kontext.
8. Spezifikationen werden committed und vom Agenten gelesen; Geheimnisse müssen in Umgebungsvariablen oder einem Geheimnisspeicher leben.
9. Ein Projektskill wird vom Team geteilt und mit dem Repository versioniert.
10. Die Möglichkeit, Agenten oder IDE zu wechseln und den Prozess durch Repository-Artefakte beizubehalten.

1. Anforderungen, Plan, Validierungsfakten, Änderungen außerhalb der Feature-Grenzen und Übereinstimmung der Implementierung mit der Spezifikation.
2. Wenn die Änderung Stack, Roadmap, Projektverfassung, Agentenregeln oder mehrere zukünftige Features betrifft.
3. Um automatisch kleine wiederholbare Aktionen auszuführen: Kontext hinzufügen, Protokoll führen, gefährliche Befehle prüfen, Ereignisse sammeln.
4. Weil Issues, Webseiten, Logs und externe Dokumente Anweisungsinjektionen enthalten können; sie müssen als Daten gelesen werden.
5. Speicher ist Hinweis und Protokoll persistenter Schlussfolgerungen; Spezifikation ist geprüfte Quelle der Wahrheit für das Produkt.
6. tech-stack.md — langfristige Projektentscheidungen (Sprache, Framework, DBMS); requirements.md des Features — Entscheidungen auf Ebene einer Phase (Routen, Felder, Fehlertexte).
7. Ä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.
8. Um einen Rücksetzpunkt ohne Verlust der gesamten Phasenarbeit zu haben und damit das Signal „nächste Gruppe zerstört alles“ explizit ist.
9. Ein Schutz-Hook blockiert eine Operation nach Regel (PreToolUse, nicht-null Rückgabecode); ein protokollierender Hook schreibt nur ein Ereignis und beeinflusst den Arbeitsablauf nicht.

1. API-Schlüssel, Zugriffstoken, Passwörter, private Schlüssel, persönliche Daten der Nutzer, interne URLs und Infrastruktur-Identifikatoren.
2. Spezifikation ohne Fakten, Zusammenführen von Verfassung und Spezifikation in eine Datei, Implementierung ohne /clear zwischen Phasen.
3. Speicher ist gerechtfertigt, wenn das Team persistente Beobachtungen zu Code und Prozess ansammelt; überflüssig, wenn QWEN.md, Verfassung und Änderungsprotokoll ausreichen.

Varianten für Partnerprüfung

Die Prüfung ist realistischer in Paaren abzulegen. Ein Student übernimmt die Rolle des Feature-Autors, der zweite die des Reviewers. Aufgabenverteilung:

Autor:

• führt Interview mit dem Agenten und schreibt Spezifikation;
• implementiert Feature nach Aufgabengruppen;
• führt faktische Prüfungen aus;
• bereitet Pull-Request und Beschreibung nach SDD-Vorlage vor.

Reviewer:

• liest Spezifikation vor Implementierung und stellt Klärungsfragen (wie in Teil 7 „Klärungsfragen“);
• prüft PR nach vier Review-Ebenen aus Teil 16: Code, Spezifikationen, Fakten, Prozess;
• führt Prüfungen aus validation.md auf eigener Maschine aus, nicht auf dem Wort des Autors;
• schreibt kurzen Bericht über gefundene Lücken.

Jeder erhält Punkte nach seiner eigenen Rubrik. Autor — nach der Hauptskala „Spezifikationen / Implementierung / Validierung / Prozess / Team-Readiness“. Reviewer — nach der Zusatzskala:

• 1: hat mindestens eine echte Lücke in requirements.md vor Implementierung gefunden;
• 1: hat Fakten selbst geprüft, nicht dem Wort geglaubt;
• 1: hat Anmerkungen „zum Code“, „zur Spezifikation“, „zum Prozess" getrennt und nicht vermischt;
• 1: hat konkrete Maßnahme vorgeschlagen, nicht „muss überlegt werden";
• 1: hat sich in angemessener Zeit gehalten — Review wurde nicht zum Neustart der Arbeit des Autors.

Nach der Verteidigung werden die Rollen für das zweite Feature getauscht. Das gibt jedem Erfahrung auf beiden Seiten des SDD-Dialogs und beseitigt die Illusion, dass Review passives Lesen des Diffs ist.

Abschlussaufgabe

Führen Sie ein echtes Feature in Ihrem Projekt durch diesen Prozess. Nach dem Merge erstellen Sie eine kurze Notiz:

# SDD-Retrospektive

## Was die Spezifikation richtig beschrieben hat

## Was der Agent selbst ableiten musste

## Was die Validierung gefangen hat

## Welche Fakten schwach waren

## Was sicherheitstechnisch zu prüfen ist

## Was vor der nächsten Phase zu verbessern ist

Wenn im Abschnitt „Was der Agent selbst ableiten musste" mehr als drei Punkte stehen, schreiben Sie die nächste Feature-Spezifikation ausführlicher.