Thema: Anwendungsteil 13. Praktische Prüfung: Aufbau eines produktiven SDD-Workflows
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 6-8 Stunden
Voraussetzungen: Erfolgreicher Abschluss der Kapitel 1-12 des zweiten Kursbandes
Verständnis der Konzepte von SDD (Spec-Driven Development) und des AgentClinic-production-Frameworks
Kenntnisse im Umgang mit dem Terminal und Ausführen von runnable-Skripten (Python/Shell)
Grundlegendes Verständnis der Funktionsweise von KI-Agenten, CI/CD und Post-Mortems
Lernziele: Selbstständiges Zusammenstellen eines kohärenten Artefaktpakets (capstone/) zur Durchführung eines produktiven SDD-Szenarios.
Lernen, Anforderungen mit Provenienz (genealogy.md) wiederherzustellen und kontrolliert fehlerhafte Spezifikationen zu erstellen.
Beherrschen der Konfiguration von Verfassungsregeln (constitution.md), Budgetkontrolle und Anti-Goodhart-Metriken.
Validierung von Fällen mittels runnable-Skripten und Erstellen von Datei-Schiedsgericht-Einträgen (judgment.md).
Bewertung der Paketbereitschaft auf einer 30-Punkte-Skala, um die Reproduzierbarkeit für einen unabhängigen Prüfer zu gewährleisten.
Übersicht: Dieses Modul stellt die abschließende praktische Prüfung des zweiten Bandes dar. Sein Hauptziel ist es zu beweisen, dass Sie in der Lage sind, ein reales produktives SDD-Szenario (Spec-Driven Development) von einem Legacy-Stand bis zu einer endgültigen Entscheidung zu durchlaufen, die durch strenge Fakten begründet ist und nicht durch blindes Vertrauen in einen KI-Agenten. Anstatt neues theoretisches Material zu erlernen, müssen Sie einen einheitlichen überprüfbaren Pfad (Paket capstone/) auf Basis des Vorfalls high_memory_usage oder autoscale_200pct zusammenstellen. Die Prüfung gilt als bestanden, wenn ein externer Prüfer Ihr Paket öffnen und ohne zusätzliche mündliche Erläuterungen die Prüflogik, die Anforderungsquelle und die Gründe für die Sperrung oder Zulassung in der Produktion verstehen kann.
Schlüsselkonzepte: SDD-Workflow (Spec-Driven Development): Eine Methodologie für Entwicklung und Betrieb, bei der jede automatische Aktion eines Agenten auf einer überprüfbaren Spezifikation und unveränderlichen Regeln basiert und nicht auf Heuristiken.
Provenienz (Genealogy): Das Prinzip der Rückverfolgbarkeit des Ursprungs jeder Anforderung. Das Artefakt genealogy.md verknüpft die Anforderung mit Quellen (Post-Mortem, QWEN.md, mündliche Praxis) und bewertet das Vertrauensniveau.
Bereitschafts-Tor (Readiness Gate): Die abschließende Überprüfung einer Entscheidung vor der Produktionszulassung. Umfasst den Readiness-Score, eine Liste blockierender Bedingungen und Nachweise (evidence_ref).
Kontrolliert fehlerhafte Spezifikation (Poisoned Spec): Eine Spezifikation, in die absichtlich genau ein Fehler eingebaut wird (z. B. ein Prioritätenkonflikt oder ein verstecktes Überschreiten von Grenzwerten), um die Validierungs- und Korrekturmechanismen zu testen (fixed-spec).
Verfassung (Constitution): Ein Satz von Systemregeln, klar unterteilt in immutable_principles (unveränderliche Gesetze) und mutable_rules (veränderliche Regeln mit definierter Lebensdauer TTL, Geltungsbereich und Rollback-Bedingungen).
Anti-Goodhart-Kontrolle: Ein Schutzmechanismus gegen die Verzerrung von Metriken, bei der eine übermäßige Optimierung des Ziel-KPI zu negativen Konsequenzen führt. Dies wird durch die Einführung von Guard-Metriken (z. B. token_health) kontrolliert.
Übungsaufgaben: Name: Paketinitialisierung und Routing
Problem: Erstellen Sie das Verzeichnis capstone/ und die Datei README.md. Formulieren Sie 5 Schlüsselzeilen-Vorlagen für den Vorfall high_memory_usage: Incident-case, Hauptrisiko, Schlüsselprüfung, Hauptblocker, Nächste Korrektur.
Lösung: 1) Erstellen Sie den Ordner mkdir -p capstone. 2) Erstellen Sie die Datei capstone/README.md. 3) Tragen Sie die Vorlage ein: Incident-case: high_memory_usage; Hauptrisiko: auto-remediation ohne vollständige audit_trace; Schlüsselprüfung: python3 scripts/check_readiness.py; Hauptblocker: stateful workload ohne backup_verified; Nächste Korrektur: evidence_ref für backup hinzufügen. Dies fokussiert die weitere Arbeit.
Komplexität: Anfänger
Name: Wiederherstellung von Provenienz und Defekt
Problem: Erstellen Sie auf Basis eines abstrakten Post-Mortems die Datei genealogy.md (eine Anforderung, 2 Quellen) und das Paar poisoned-spec.md / fixed-spec.md mit einem zyklischen Defekt und dessen Korrektur.
Lösung: 1) Geben Sie in genealogy.md die Anforderung 'Cache-Bereinigung bei Erreichen von 90% Speicher' an, Quellen: 'Grafana Alert' und 'Mündliche SRE-Praxis', Vertrauensniveau: High. 2) Erstellen Sie in poisoned-spec.md die Regel: 'Wenn Speicher >90%, Cache leeren; wenn Cache leer ist, Speicher vom System anfordern'. 3) Geben Sie in fixed-spec.md an: 'Zyklen-Korrektur: bei leerem Cache GC ausführen, anstatt Speicher anzufordern'.
Komplexität: Mittelstufe
Name: Validierung ausführen und Ergebnis dokumentieren
Problem: Führen Sie das Prüfskript readiness_block_stateful.json aus den runnable-Beispielen aus. Übertragen Sie das Ergebnis in validation.md im Format: Befehl, erwartetes Faktum, tatsächliches Ergebnis, Blocker.
Lösung: 1) Führen Sie python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json aus. 2) Der Befehl gibt Code 1 zurück (Fehler/Blocker). 3) Notieren Sie in validation.md: Befehl: check_readiness...; Erwartung: Sperrung stateful; Ergebnis: Exit code 1; Blocker: Bestätigung des Backups fehlt. Dies beweist, dass das Bereitschafts-Tor korrekt funktioniert.
Komplexität: Fortgeschritten
Fallstudien: Name: Vorfall high_memory_usage: vom Alert zum geschützten Deployment
Szenario: Das System AgentClinic-production hat einen kritischen Alert von Grafana über eine Überschreitung des Speicherverbrauchs erhalten. Legacy-Spuren sind teilweise verloren: Einige Wiederherstellungsregeln sind nur aus der alten Dokumentation QWEN.md und der mündlichen Wissensvermittlung bekannt. Eine automatische Remediation (Bereinigung und Neustart) erscheint als attraktive Lösung.
Aufgabe: Ein automatisches Eingreifen kann das Limit des Auswirkungsradius (Blast Radius) oder das Budget der Stufen verletzen. Das Team muss nachweisen, dass die vorgeschlagene Spezifikation sicher ist, keine versteckten Fehler enthält und für die Produktionszulassung ohne Risiko eines Datenverlusts bereit ist.
Lösung: Die Ingenieure stellten das Paket capstone/ zusammen. Sie stellten den Ursprung der Anforderungen in genealogy.md wieder her. Sie erstellten eine absichtlich fehlerhafte Spezifikation und korrigierten sie, wobei sie die Regeln in constitution.md festhielten. Sie führten einen Testlauf (Dry-Run) mit dem Skript check_readiness.py durch, das die Aktion aufgrund fehlender backup_verified-Markierungen bei der Stateless-Workload blockierte. Die Ergebnisse wurden in judgment.md mit dem Status DEFERRED festgehalten.
Ergebnis: Das Beweispaket erreichte 26/30 Punkte. Ein gefährliches Deployment wurde durch die korrekte Funktion des Bereitschafts-Tors verhindert. Die Entscheidung wurde aufgeschoben, bis evidence_ref für Backups hinzugefügt wird, wodurch eine Downtime in der Produktion vermieden werden konnte.
Gewonnene Erkenntnisse: Ein Readiness-Score ohne Nachweise (evidence_ref) ist sinnlos und kann nicht als Zulassung dienen.
Ein in der Testphase entdeckter Blocker ist wertvoller als eine formelle APPROVE ohne Durchführung von Prüfungen.
Die out/-Logs sollten nicht in die finale prüfbare Spur aufgenommen werden, der Prüfer benötigt nur die Zusammenfassung validation.md.
Verwandte Konzepte: Readiness Gate
Genealogy
Poisoned Spec
Validation
Name: Beilegung einer Streitigkeit bei der Skalierung autoscale_200pct
Szenario: Bei Spitzenlasten schlug der KI-Agent (Implementor) vor, die Ressourcen um 200% zu skalieren, basierend auf einer Vorlage aus QWEN.md. Der Sicherheits-Agent (Safety) legte ein Veto ein und verwies auf das Risiko einer Budgetüberschreitung und einen möglichen Goodhart-Effekt, bei dem das System Ressourcen um der Metrik willen skaliert und nicht zum tatsächlichen Nutzen.
Aufgabe: Es entstand ein Rollenkonflikt. Es ist erforderlich, ein Datei-Schiedsverfahren durch ein Duell (duel) durchzuführen und eine Entscheidung zu treffen, die sich auf die Verfassung des Systems und die Metriken stützt und nicht auf die Autorität der Agenten.
Lösung: Der Tribunal-Mechanismus wurde gestartet: run_duel.py zur Fixierung der Argumente und check_invariants.py zur Überprüfung der Budgets. In goodhart-note.md wurde festgehalten, dass die KPI 'Antwortgeschwindigkeit' irreführend ist, und die Guard-Metrik 'Kosten/Anfrage' wurde hinzugefügt. In judgment.md wurde das Urteil DENY gefällt, was automatisch einen Präzedenzfall in precedents.md (mit den Feldern case_id und applies_to) erstellte.
Ergebnis: Der Konflikt wurde formalisiert gelöst. Es wurde ein Präzedenzfall geschaffen, der es in Zukunft ermöglicht, ähnliche Anfragen automatisch abzulehnen, ohne Token für ein Duell zu verschwenden. Budget-note.md zeigte deutlich die Grenzen der günstigen Stufe.
Gewonnene Erkenntnisse: Ein Safety-Veto kann nicht durch eine einfache Stimmenmehrheit umgangen werden.
Jede wiederkehrende Streitigkeit sollte in einen aufgezeichneten Präzedenzfall (Precedent) umgewandelt werden.
Die Anti-Goodhart-Kontrolle (Verbindung von KPI und Guard-Metrik) ist für die automatische Skalierung unerlässlich.
Verwandte Konzepte: Schiedsverfahren und Rollen
Judgment
Anti-Goodhart
Precedents
Lerntipps: Beginnen Sie am Ende: Füllen Sie zuerst die 5 Vorlagenzeilen in README.md aus, um den Rahmen festzulegen, und erst dann erstellen Sie die übrigen Artefakte.
Mischen Sie keine Vorfälle. Wählen Sie strikt einen Fall (z. B. high_memory_usage) und fügen Sie keine Elemente aus anderen Szenarien hinzu.
Nutzen Sie den 'Goldenen Pfad': Öffnen Sie examples/templates/capstone-dossier.md als Vorbild dafür, wie prägnant Ihr Paket sein sollte. Blähen Sie die Dokumentation nicht auf.
Simulieren Sie eine fremde Prüfung: Legen Sie die Arbeit nach der Zusammenstellung von capstone/ für eine Stunde beiseite und versuchen Sie dann, 5 Kontrollfragen zu beantworten, indem Sie nur auf Ihre Dateien schauen, ohne auf den Chatverlauf mit der KI zurückzugreifen.
Wenn Sie bei einem Artefakt nicht weiterkommen, kehren Sie zum entsprechenden Kapitel (1-12) zurück und suchen Sie den Block 'Wie dies in capstone/ gelangt'.
Zusätzliche Ressourcen: Examples/templates/capstone-dossier.md: Referenzbeispiel (Goldener Pfad), das die ideale Balance der Detaillierung für die Prüfung demonstriert.
Teil 00: production-lab: Der grundlegende Laborrahmen AgentClinic-production. Unbedingt zu lesen, wenn der Kontext verloren erscheint.
Teil 11: real-api-deployment: Anweisungen zum Ausführen von runnable-Skripten für den Hauptfall high_memory_usage.
Teil 08: multiagent-tribunal: Theorie und Praxis der Durchführung von Datei-Schiedsverfahren, Duellen und der Arbeit mit Präzedenzfällen für den Fall autoscale_200pct.
Zusammenfassung: Die praktische Prüfung 'Aufbau eines produktiven SDD-Workflows' ist eine Überprüfung Ihrer Fähigkeit, eine Kultur der Beweisbarkeit in die Prozesse von KI-Agenten einzuführen. Sie haben gelernt, ein kompaktes, reproduzierbares Artefaktpaket (capstone/) zu erstellen, das Vorfälle, Defekte, Verfassung und Validierung in einem einheitlichen überprüfbaren Pfad verknüpft. Die wichtigste Erkenntnis: Die Produktionsbereitschaft wird nicht durch perfekte Metriken oder das Volumen der Dokumentation bestätigt, sondern durch das Vorhandensein einer transparenten Provenienz, funktionierender Sperren und klarer Antworten auf die Frage 'Warum ist dies sicher?'.