Praxisteil 11. Integration mit echter API: von der Spezifikation bis zum Deployment

Status: Empfehlung. Die SDD-Phasenunterteilung Specify/Plan/Tasks/Implement/Validate und das 25-Punkte-Readiness-Modell sind der empfohlene Rahmen. Für den Lernpfad sind echtes Kubernetes, GitOps oder ein externer Executor nicht erforderlich.

Frontier. Vollständig automatisierte Auto-Remediation ohne manuelle Bestätigung (human-review) auf dem kritischen Pfad bleibt Frontier: selbst Teams mit umfangreicher SDD-Erfahrung halten einen Menschen in der Schleife. Von den eingebauten Qwen Code-Befehlen ist hier nur /plan verfügbar; die übrigen Schritte sind benutzerdefinierte Befehle oder direkte qwen -p-Aufrufe über Projektskripte.

Für den Lernpfad reicht die lokale Pipeline examples/real-api/: Webhooks normalisieren, den Readiness-Gateway passieren und eine verbotene Aktion blockieren. GitOps, Kubernetes API und vollständige Auto-Remediation gehören zum vollständigen Production-Track.

> [runnable] — Die ausführbare Entsprechung der Pipeline «Webhook → Normalisierung → Readiness-Gateway → Dry-Run» befindet sich in [examples/real-api/](examples/real-api/README.md). Die Skripte arbeiten mit der Standardbibliothek ohne externe Abhängigkeiten; sie ersetzen keine Production-Infrastruktur, ermöglichen aber einen lokalen Durchlauf des Gateways und zeigen, welche Bedingungen eine Aktion blockieren.

Das Szenario high_memory_usage ist der Höhepunkt der Lektüren zum gleichen SQLite, das wir in Teil 12 des ersten Bandes aufgebaut haben, und verwendet dieselbe idempotente Migrationsmethode. Jetzt wird es jedoch aus der Betriebsperspektive betrachtet. Der in Teil 7, Teil 8 und Teil 9 des ersten Bandes erprobte Zyklus Specify → Plan → Tasks → Implement wird hier nicht aufgehoben oder ersetzt. Er wird durch ein Production-Gateway eingefasst und endet mit einem Team-Review des Beweispakets im Stil von Teil 16.

Vor der Lektüre

• Grundlage aus dem ersten Band: Teile 7–9 definieren den Spezifikation-Plan-Validierungs-Zyklus, Teil 16 das Team-Review.
• Lokaler Lernfall: high_memory_usage, der kanonische Fall des gesamten ersten Durchgangs.

• Spur für capstone/: Readiness-Verdikt, zwei blockierende Bedingungen und Dry-Run einer erlaubten Aktion.
• Hauptbegriffe des ersten Durchgangs: readiness und Dry-Run. Die 25-Punkte-Rubrik, audit_trace, GitOps, Executor — Referenzmaterial.
• Was zurückgestellt werden soll: GitOps, Kubernetes API, vollständiger Executor und Auto-Remediation ohne manuelle Bestätigung.

Ziel

Im Lernminimum prüft dieses Kapitel die kurze Kette Webhook -> Normalisierung -> Readiness -> Dry-Run für high_memory_usage. Der vollständige Production-Track erweitert sie auf GitOps-Deployment, Rollback von Änderungen und Readiness-Bewertung vor eingeschränkter Auto-Remediation. Jede Aktion muss mit Artefakten specify/plan/tasks/implement/validate verknüpft sein, nicht in manuellen Befehlen verloren gehen.

Das praktische Ergebnis des ersten Durchgangs ist kein Production-Orchestrator, sondern der Nachweis, dass eine erlaubte Aktion die Readiness besteht und eine verbotene bis zur Systemänderung blockiert wird.

readiness (Bereitschaft) ist hier die formale Bewertung der Pipeline auf einer 25-Punkte-Skala mit einem Schwellenwert von 23/25. Auto-Remediation in diesem Kapitel bedeutet ein eingeschränktes Playbook mit vorab genehmigten Aktionen (pre-approved actions), Rollback-Bedingungen und manueller Bestätigung durch einen Menschen (human-review). Es ist nicht das Recht eines Agenten, Production willkürlich zu ändern.

Von den eingebauten Qwen Code-Befehlen ist in dieser Pipeline nur /plan verfügbar. Die übrigen Schritte — /sdd:specify, /sdd:tasks, /sdd:validate — formulieren Sie als benutzerdefinierte Befehle in .qwen/commands/sdd/ oder ersetzen Sie sie durch gewöhnliche Prompts über qwen -p und Projektskripte.

Minimaler Lernszenario

Lernfall

Production-Incident high_memory_usage für appointments-api — abgeleitet von der MVP-Phase und SQLite-Migrationen aus book/part-12-mvp.md. Pipeline: Webhook Grafana+PagerDuty → normalize_webhook.py → Readiness-Gateway nach 25-Punkte-Modell → Dry-Run gegen Liste vorab genehmigter Aktionen. Ziel — den vollständigen Weg von der rohen Payload bis zum kontrollierten restart_pod durchlaufen und sicherstellen, dass blockierende Bedingungen (Audit, Stateful) den Fehler genau dort abfangen, wo sie sollen.

Vorbereitung

• book2/examples/real-api/fixtures/webhook_grafana.json, webhook_pagerduty.json — rohe Payloads mit identischem incident_key.
• book2/examples/real-api/fixtures/incident_event.expected.json — Referenz für das normalisierte Ereignis.
• book2/examples/real-api/fixtures/readiness_pass.json (24/25), readiness_block_audit.json (22/25 + Audit unter 1.0), readiness_block_stateful.json (24/25, aber Stateful ohne bestätigtes Backup).
• book2/examples/real-api/specs/high_memory_usage/specify.md — vorab genehmigte restart_pod und scale_up_replicas_one.
• book2/examples/real-api/scripts/normalize_webhook.py, check_readiness.py, dry_run.py.

Schritte

1. cd book2/examples/real-api. Erwartung: Sie befinden sich im Beispielverzeichnis, keine zusätzlichen Abhängigkeiten erforderlich.
2. python3 scripts/normalize_webhook.py --grafana fixtures/webhook_grafana.json --pagerduty fixtures/webhook_pagerduty.json --expected fixtures/incident_event.expected.json. *Erwartung: Rückgabecode 0, normalisiertes incident_event stimmt mit Referenz überein.*
3. python3 scripts/check_readiness.py --readiness fixtures/readiness_pass.json. *Erwartung: Rückgabecode 0, PASS incident=HM-2026-05-17-01 score=24/25.*

1. python3 scripts/check_readiness.py --readiness fixtures/readiness_block_audit.json. *Erwartung: Rückgabecode 1, Grund — audit_trace_coverage=0.7 < 1.0, plus Unterschreitung der Gesamtpunktzahl (22/25).*
2. python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json. *Erwartung: Rückgabecode 1, Grund — stateful workload ohne bestätigtes Backup, obwohl die Gesamtpunktzahl 24/25 beträgt.*

Schlecht: dry_run.py vor dem Readiness-Gateway ausführen — die Aktion ist formal durch die Spezifikation erlaubt, aber audit_trace_coverage oder backup_verified könnten fehlen. Gut: zuerst das Readiness-Gateway, Dry-Run nur bei Rückgabecode 0 vom Gateway — diese Reihenfolge garantiert, dass der Wirkungsradius vor der Prüfung der Aktionsliste bekannt ist.

1. python3 scripts/dry_run.py --spec specs/high_memory_usage/specify.md --action restart_pod. *Erwartung: Rückgabecode 0, PASS: action=restart_pod erlaubt (2 actions in spec).*
2. python3 scripts/dry_run.py --spec specs/high_memory_usage/specify.md --action delete_namespace. *Erwartung: Rückgabecode 1, BLOCK: action="delete_namespace" nicht unter pre-approved gefunden.*

1. Für das Lernminimum stoppen Sie hier: Die runnable-Kette hat Normalisierung, PASS für den erlaubten Pfad und BLOCK für audit/stateful/delete_namespace gezeigt.

Wenn Qwen Code installiert ist und eine Erklärung für das Review benötigt wird, führen Sie einen separaten optionalen Schritt aus:

qwen -p "Lies @fixtures/readiness_block_audit.json und @specs/high_memory_usage/specify.md. Was muss ergänzt werden, damit Readiness 23/25 und audit_trace_coverage=1.0 erreicht? Dateien nicht ändern." --approval-mode plan

Diese Anfrage gehört nicht zum runnable-Minimum. Ihre Ausgabe kann dem Review beigefügt werden, aber die Readiness-Zulassung muss sich auf check_readiness.py und dry_run.py stützen.

Kontrollfakt

Schritte 3, 6 — PASS. Schritte 4, 5, 7 — BLOCK mit konkretem Grund in stderr. Wenn Schritt 5 bei stateful=true, backup_verified=false besteht, ist das Readiness-Gateway defekt: Eine harte Blockade für Stateful darf nicht umgangen werden.

Wie dies in capstone/ einfließt

Übertragen Sie in capstone/readiness.md das Readiness-Ergebnis, die zwei blockierenden Bedingungen und das Ergebnis von dry_run.py für die erlaubte Aktion. In capstone/validation.md geben Sie die tatsächlich ausgeführten Befehle an. GitOps, Kubernetes API und der vollständige Executor gehören nicht zum Lernminimum, sofern sie nicht implementiert wurden.

Dieses Fragment so lesen: Eine positive Fixture zeigt den zulässigen Pfad, zwei blockers dokumentieren konkrete Ablehnungsgründe, dry_run — der Grenzfall erlaubter und blockierter Aktion. Fehlt auch nur eine Zeile, ist das Readiness-Paket unvollständig.

readiness:
  pass_fixture: "readiness_pass.json -> 24/25"
  blockers:
    - "audit_trace_coverage=0.7 blocks auto mode"
    - "stateful=true without backup_verified blocks action"
  dry_run: "restart_pod PASS; delete_namespace BLOCK"

Review-fähige Spur

Die Skripte schreiben nach stdout/stderr und erstellen kein out/. Dokumentieren Sie den Durchlauf als lesbares Artefakt: kurzes capstone/readiness.md oder CI-Bericht, falls in Ihrem Projekt vorhanden. Minimale Inhalte — dieselben vier YAML-Zeilen aus dem Block oben (pass_fixture, zwei blockers, dry_run); der vollständige 25-Punkte-Bericht ist nur im vollständigen Track erforderlich.

Erstellen Sie keinen Commit-Marker um des Commits willen. Für das Lehrbuch ist eine reproduzierbare Spur wichtig, die ohne Chat-Verlauf lesbar ist.

Schlüsselideen

Der Startpunkt der Rückverfolgung ist audit_trace (Live-Log von Qwen Code), in dem eingehender Webhook und Spezifikationsunterschiede (diff) als ein kausaler Verlauf festgehalten werden. Für den Incident HM-2026-05-17-01 verknüpft der erste Eintrag incident_event.json, den benutzerdefinierten Befehl /sdd:specify und die erstellte Datei specs/high_memory_usage/specify.md. Fehlt ein Element, hat die Pipeline bereits ihre Beweiskraft verloren. Minimales Log-Fragment: webhook_received -> incident_event_normalized -> /sdd:specify -> spec_diff_created; jeder weitere Unterschied verweist auf dieselbe incident_id. /sdd:specify ist eine Projekterweiterung; formulieren Sie sie als benutzerdefinierten Befehl in .qwen/commands/sdd/specify.md oder ersetzen Sie sie durch direktes qwen -p.

Normalisieren Sie Grafana- und PagerDuty-Alerts in ein einheitliches incident-event. Andernfalls diktieren verschiedene Quellen unterschiedliche Versionen desselben Vorfalls. Grafana liefert Metriken und Beobachtungsfenster, z.B. memory_percent=93 über 10m. PagerDuty ergänzt Priorität, Service-Zuordnung und Eskalationsstatus. Der Normalisierer reduziert sie auf die Felder service, namespace, pod, severity, window_minutes, metric_context, source_refs. Danach beschreibt der Specify-Schritt nur WHY und WHAT: warum Eingriff nötig ist und welches Ergebnis als erfolgreich gilt. Er wählt keine Bibliothek, kein SDK und keine konkrete API-Methode.

Was das in der Praxis bedeutet. Vergleichen wir zwei Specify-Varianten für denselben Incident:

Schlecht:

> Specify für high_memory_usage: Pod über kubectl delete pod neu starten ...

Problem: Specify wählt sofort den Implementierungsbefehl und blockiert Plan.

Gut:

> Specify für high_memory_usage: memory_percent < 80% für 5 Minuten nach der Aktion halten. Pre-approved actions: restart_pod, scale_up_replicas_one. Audit-Trace obligatorisch.

Die SDD-Phasentrennung schützt die Pipeline vor vorzeitiger Implementierung. Jede Phase ist für ihr eigenes verantwortlich:

• Specify fixiert die User Story, Erfolgskriterien, funktionale und nicht-funktionale Einschränkungen;
• Plan wählt die Strategie;
• Tasks zerlegt sie in ausführbare Schritte;
• Implement wendet Änderungen über einen kontrollierten Mechanismus an.

Diese Struktur entspricht dem praktischen Phasenrahmen Specify → Plan → Tasks → Implement aus dem GitHub Spec Kit (siehe auch GitHub Spec Kit Quickstart). In Production ist dies wichtig, weil das Modell nicht das Recht erhält, einen Incident «sofort zu heilen», bevor Ursache, Eingriffsgrenzen und Ergebnisprüfung nachgewiesen sind.

Erweitern Sie den Kapitelkern nicht zum gesamten Production-Orchestrator. Im ersten Durchgang wird hier nur die Kette Webhook -> Normalisierung -> Readiness -> Dry-Run geprüft. Die übrigen Mechanismen aus vorherigen Kapiteln dienen als Kontrollpunkte:

• Der Verifikator aus Teil 4 und 8 ist nötig, wenn der Dry-Run ein strittiges Gegenbeispiel hervorruft.
• Die stufigen Budgets aus Teil 9 sind nötig, wenn der frontier-reviewer nicht nur High-Risk-Branches bedient.
• Anti-Goodhart aus Teil 10 ist nötig, wenn Memory zu Lasten von 5xx, Latency oder manuellem Audit sinkt.

Sind diese Mechanismen noch nicht zusammengestellt, versuchen Sie nicht, sie innerhalb von Kapitel 11 zu modellieren. Notieren Sie sie als Blocker oder Verweise auf die entsprechenden Kapitel und schließen Sie den minimalen Durchlauf mit Readiness-Verdikt und Dry-Run-Ergebnis ab.

Für high_memory_usage beginnen Sie den Plan mit minimalem Eingriff. Das Basis-/plan wählt den Neustart eines bestimmten Pods mit Priorität auf den Wirkungsradius. Dann prüft es die Notwendigkeit eines Scale-Up. Und erst danach erlaubt es eine erweiterte Aktion bei Erhalt des Rollback-Pfads.

Der Tasks-Schritt zerlegt dies in Operationen: Bestätigen des Stateless-Charakters des Workloads, Dry-Run ohne echte Änderungen, Löschen nur des Ziel-Pods, Beobachten von RSS, CPU, 5xx; bei ausbleibender Verbesserung im festgelegten Fenster — Aktivieren des Rollbacks und Erstellen eines human_review.

Die Validierung schließt den Auto-Remediation-Kreis erst nach Prüfung echter Metriken, Sicherheits-Gateway und GitOps-Festschreibung (dies ist Teil des Frontier-Szenarios, siehe Kapitelkopf). In validation.md prüfen Sie vier Bedingungen:

• Memory bleibt unter dem Schwellenwert in zwei aufeinanderfolgenden Fenstern;
• 5xx steigt nicht;
• Latency degradiert nicht;
• Rollback ist beschrieben und ausführbar.

Nach erfolgreicher Prüfung gelangen sechs Basisartefakte in GitOps: Spezifikation, Plan, Tasks, Unterschiede (diff), Entscheidungsprotokoll und 25-Punkte-Bericht. Eine Verfassungsaktualisierung wird bei Bedarf hinzugefügt. Ohne dies kann ein Incident technisch gemildert, aber nicht als kontrolliert geschlossen gelten.

Vollständiger Track: 25-Punkte-Readiness-Modell

Im ersten Durchgang reicht das Verständnis zweier Fakten: readiness_pass.json besteht, Audit/Stateful-Fixtures werden blockiert. Die vollständige Rubrik unten ist nötig, wenn Sie dieses Gateway in einen echten Production-Prozess übertragen und erklären müssen, warum der Schwellenwert genau so gewählt wurde.

Das Modell bewertet fünf Kategorien auf einer Skala von 0–5 und ergibt eine Gesamtsumme. Punkte werden anhand von Artefakten vergeben, nicht nach Eindruck. Lässt sich ein Kriterium nicht durch Datei, Log oder Schema bestätigen, wird eine niedrigere Bewertung vergeben. Unten — Rubriken für jede Kategorie.

Der Schwellenwert 23/25 ist ein Kompromiss «streng, aber nicht lähmend» für das Lernmodell AgentClinic-Production: bis zu zwei «behebbare» Beanstandungen mit «4» in verschiedenen Kategorien (4+4+5+5+5 = 23) oder eine «4» bei sonstigen «5» (24/25). «3» oder niedriger in mindestens einer Kategorie senkt die Summe sofort auf 22 oder weniger und entzieht den Auto-Zulassung. Unter 23: 20–22/25 versetzt die Pipeline in den halbmanuellen Modus mit Bestätigung durch den Menschen nach jedem Implement-Schritt. Darüber — Schwellenwert 24/25 — würde jede kleine Beanstandung Auto in halbmanuell versetzen, und das Team würde das Modell ignorieren. Kalibrieren Sie nach Risikoprofil: Zahlungen und Gesundheitswesen — Auto ≥24/25; interne Tools erlauben 21–22/25, aber nur als halbmanuell oder Canary, nicht als production-ready Auto-Remediation.

Spec — Vollständigkeit von WHY/WHAT/Constraints

Implementation — Idempotenz und kontrollierte Änderungen

Verification — Given/When/Then, Schemas, Stress, Monitoring

Process — Rückverfolgung «Webhook → CLI → Diff → Replay»

Security — Schutzmaßnahmen, Not-Aus, Rollback, Eskalation

Berechnung und Merge-Blocker

Die Punktesumme ergibt ein Ergebnis von 0 bis 25. Der Bestehens-Schwellenwert für Auto-Zulassung ist 23/25: Unterhalb dieser Grenze erhält die Pipeline keinen Production-ready-Status, auch wenn drei Kategorien auf Maximum sind. Null Punkte in Security bei jeder Summe verboten. 0 in dieser Spalte bedeutet fehlende Schutzschleife und blockiert selbst den halbmanuellen Modus bis zum Erscheinen minimalen Rollbacks, Schutzmaßnahmen und Eskalation.

Blockierende Bedingungen sind unabhängig von der Summe. Jeder dieser Fälle blockiert das Merging separat:

• gescheiterte Validation (Verification ≤ 2);
• fehlendes Rollback (Security ≤ 2);
• unbestimmter Wirkungsradius (Implementation ≤ 2 ohne explizites Feld).

Bei Ergebnis 20–22 wird die Pipeline nur im halbmanuellen Modul zugelassen und nur bei Fehlen der obigen Blocker: Stopp nach jedem Implement-Schritt, explizite Bestätigung durch den Menschen, obligatorische Spezifikationsaktualisierung und Neubewertung vor Rückkehr in den Auto-Kontur.

Checkliste vor Production-Umschaltung (Cutover)

Verwendet beim Übertragen des Gateways in einen echten Prozess — jeder Punkt ist an die Rubrik gebunden, in der ein versteckter Punktabfall möglich ist:

• [ ] Spec enthält WHY/WHAT/Constraints und ist an incident_id gebunden; jede Task hat implements: auf REQ-Identifikator.
• [ ] Dry-Run wird vor echten Änderungen geloggt; Wirkungsradius auf Pod- oder Deployment-Ebene festgehalten, nicht wortreich.
• [ ] JSON Schema validiert incident_event und finalen validation_report; Given/When/Then decken happy und negative path ab.
• [ ] Rollback-Bedingung vor Ausführung festgehalten und auf Staging geprüft; Not-Aus für Operator ohne Cluster-Zugang verfügbar.
• [ ] Spur webhook → CLI → diff → commit → validate ist über incident_id reproduzierbar; manuelle Bestätigung wird bei wiederholtem Scheitern oder Wirkungsradiuserweiterung automatisch ausgelöst.

Beispiel einer ausgefüllten Rubrik für high_memory_usage

Vollständiger Track: Schwellenwertkalibrierung

Die Tabelle «Niedrig / Standard / Hoch» für den Readiness-Schwellenwert, die Übung zur Überschreibung von THRESHOLD und Signale zur Überprüfung — in Anhang D, Abschnitt D.5. Im ersten Durchgang ist das Kapitelminimum bereits nachgewiesen, wenn readiness_pass.json besteht, Audit/Stateful-Fixtures blockiert werden und delete_namespace nicht in der Liste vorab genehmigter Aktionen enthalten ist.

Beispiele und Anwendung

Der praktische Eingangslog für Qwen Code kann so beginnen: POST /hooks/grafana meldet memory_percent=93, pod=api-7b4, namespace=appointments-api, window=10m. Dann bestätigt POST /hooks/pagerduty severity=critical und verknüpft das Ereignis mit dem Service appointments-api. Der Normalisierer erstellt incident_event mit incident_id=HM-2026-05-17-01, entfernt sensible Felder, fügt Quellenverweise bei und startet den benutzerdefinierten Befehl /sdd:specify --event incident_event.json --preset high_memory_usage oder einen äquivalenten qwen -p-Prompt — beide Varianten gehören zum empfohlenen Rahmen aus dem Kapitelkopf und werden als Projektbefehle um Qwen Code herum implementiert.

Der erste Unterschied (diff) in specify.md festschreibt drei Blöcke: WHAT (RSS unter 80% in 10 Minuten), WHY (OOMKill und Latenzanstieg verhindern), Constraints (Stateful Workloads nicht anfassen, HPA nicht ändern, Rollback nach 6 Minuten ohne Verbesserung). Auf /plan vergleicht das System zwei Strategien: (A) Neustart des Ziel-Pods und Beobachtung; (B) Neustart plus temporärer Scale-Up auf vier Repliken. Der Verifikator führt Given/When/Then aus: given pod stateless und memory über 90% für 10 Minuten; when Neustart nur des Ziel-Pods; then memory muss unter 80% fallen und 5xx darf Schwellenwert nicht überschreiten. Zeigt die Stress-Spezifikation, dass Scale-Up eine Änderung der Rollout-Politik erfordert oder einen Speicherleak durch Replikatenwachstum verschleiert, bleibt Variante B als Reservezweig mit manueller Bestätigung, nicht als automatische Aktion.

Im Implement-Schritt wird zuerst der Dry-Run ausgeführt. Dann erfolgt der Commit über GitOps und Synchronisierung in ArgoCD nur bei grünem Validator-Status. Der Executor schließt den PagerDuty-Incident nicht sofort nach dem Neustart. Er wartet zwei Monitoring-Fenster, prüft validation.md, überprüft das Sicherheits-Gateway und fügt dem Kommentar Verweise auf Spec, Tasks, Commit und Validierungsergebnis bei. Sinkt memory nach 6 Minuten nicht oder steigt 5xx, wird der Rollback-Pfad aktiviert, ein human_review erstellt und die Readiness-Bewertung unter Berücksichtigung des gescheiterten Verification-Kriteriums neu berechnet.

Zusammenfassung

Die Bereitschaft der Production-Pipeline wird durch das 25-Punkte-Modell festgehalten: fünf Kategorien (Spec, Implementation, Verification, Process, Security) mit gleichem Gewicht von 5 Punkten wiederholen die SDD-Zyklus-Phasen. Gleiches Gewicht ist Prinzip: keine Kategorie kompensiert eine Lücke in einer anderen, daher erlaubt der Schwellenwert 23 höchstens zwei partielle Lücken insgesamt. Production-ready — nicht unter 23/25 bei Abwesenheit kritischer Validation- und Sicherheits-Gateway-Verstöße. Unterschreiten des Schwellenwerts versetzt die Auto-Remediation in den halbmanuellen Modus bis zur Korrektur von Spezifikation, Politik oder Ausführungspfad. Vollständig automatisierte Remediation bleibt das Frontier-Szenario aus dem Kapitelkopf: Zulassen Sie sie erst nach Ansammlung von Replay-Beweisen und operativem Dry-Run. Solch ein Kontur verwandelt jeden zukünftigen Incident in eine überprüfbare Systemverbesserung.

Artefakte und Readiness-Kriterien

Der vollständige Track ergänzt specs/high_memory_usage/specify.md, plan.md, tasks.md und validation.md, GitOps-Diff oder Commit, verknüpft mit incident_id, Entscheidungsprotokoll webhook → CLI → diff → commit → validate und ausgefüllte 25-Punkte-Readiness-Tabelle mit Beweisen. Als bereit gelten, wenn Plan und Tasks Wirkungsradius, Dry-Run, Rollback-Bedingung und Trigger für manuelle Bestätigung haben; Validation zwei Metrikfenster, 5xx, Latency und Sicherheits-Gateway prüft; Benutzerbefehle entweder als Projektbefehle formuliert oder durch qwen -p-Prompts oder Projektskripte ersetzt sind; Readiness-Ergebnis nicht unter 23/25 ohne Blocker für Rollback, Verification oder Wirkungsradius.

Praxis

1. cd book2/examples/real-api && python3 scripts/normalize_webhook.py --grafana fixtures/webhook_grafana.json --pagerduty fixtures/webhook_pagerduty.json --expected fixtures/incident_event.expected.json — *Erwartung: Code 0, normalisiertes incident_event stimmt Feld für Feld mit Referenz überein.*
2. Führen Sie die vier Prüfungen einzeln aus (jede gibt eigenen Code zurück, daher && dazwischen ungeeignet):

   python3 scripts/check_readiness.py --readiness fixtures/readiness_pass.json
   python3 scripts/check_readiness.py --readiness fixtures/readiness_block_audit.json
   python3 scripts/dry_run.py --spec specs/high_memory_usage/specify.md --action restart_pod
   python3 scripts/dry_run.py --spec specs/high_memory_usage/specify.md --action delete_namespace

*Erwartung: readiness_pass → Code 0, PASS incident=HM-… score=24/25; readiness_block_audit → Code 1, BLOCK … score=22/25 mit Gründen «score 22/25 unter Schwellenwert 23» und «audit_trace_coverage=0.7 < 1.0 — vollständige Abdeckung obligatorisch»; restart_pod PASS, delete_namespace BLOCK.*

1. Bewerten Sie Ihren Fall nach dem 25-Punkte-Modell und füllen Sie die Tabelle unten aus. Geben Sie für jede Kategorie Punkte, Beweisartefakt und bei weniger als 5 Punkten den Senkungsgrund an. Berechnen Sie das Ergebnis, prüfen Sie blockierende Bedingungen und formulieren Sie, was geändert werden muss, damit die Pipeline den Schwellenwert 23/25 besteht. *Erwartung: in jeder Tabellenzeile sind alle drei Felder ausgefüllt; «Beweisartefakt» zeigt auf konkrete Datei oder Durchlauf, keine allgemeine Formulierung; Ergebniszelle enthält Zahl der Form N/25 und Liste blockierender Bedingungen oder explizites «keine Blocker».*

Kontrollfragen

1. Warum sollte Specify keine konkrete Remediationsbefehl wählen?
2. Welche Bedingungen machen Auto-Remediation unzulässig?
3. Was blockiert die Zulassung, wenn Readiness unter 23/25 liegt?

1. Ein Webhook zu high_memory_usage kam außerhalb der Arbeitszeit, automatische Remediation ist bereit, den Pod neu zu starten. Das Readiness-Modell gibt 22/25 (minus 3 für unvollständigen Audit). Was tun Sie — neu starten, bis morgen warten oder den Diensthabenden rufen?