Anwendungsteil 0. AgentClinic-production Labor

Status: Standard für den Lernpfad. Dieser Teil führt keine neue Technik ein. Er erklärt, wie man den zweiten Band als einen Laborzweig nach dem ersten Band liest.

Der erste Band baut eine kleine AgentClinic: Routen, SQLite, Feature-Spezifikationen, Prüfungen und Reviews. Im zweiten Band wird dasselbe Projekt als Lern-Produktionsmodell verwendet. Wir verlangen kein echtes Kubernetes, Grafana, PagerDuty oder GitOps. Diese Wörter bezeichnen Rollen in Szenarien: woher das Signal kam, welche Aktion gefährlich sein kann, wo ein Rollback nötig ist und welches Artefakt die Entscheidung belegt.

Wenn man die Kapitel als unabhängige fortgeschrittene Techniken liest, wird der Band schnell schwer. Lesen Sie ihn anders: ein Projekt, ein Hauptproduktionskreis, ein wachsendes Beweispaket. Für die standardmäßige Bewertung verwenden Sie high_memory_usage; die übrigen Vorfälle dienen als kleine Laborfenster für einzelne Mechanismen.

Faustregel für den ersten Durchlauf: capstone/README.md muss über einen Incident-Fall antworten. Das lokale Beispiel eines anderen Kapitels kann einen anderen Vorfall verwenden, aber in das Bewertungspaket wird nur ein überprüfbarer Grundsatz übertragen. Zum Beispiel wird aus autoscale_200pct nicht der zweite Fall übertragen, sondern die Schutzregel (guard) „den Wirkungsradius nicht über das Kontingent hinaus erweitern". Aus cdn_error_budget_burn wird kein neuer Dienst übertragen, sondern die Anti-Goodhart-Invariante „MTTR darf nicht auf Kosten eines stillen P0 verbessert werden".

Vor dem Lesen

Teil 0 ist methodisch, ohne Lernfall. Hier gibt es keine Schritte und keine Kontrolltatsache; die Aufgabe ist, die Karte des Bandes festzulegen und den Ausführungsstack abzustimmen. Ab dem nächsten Kapitel kehrt der Standardblock „Vor dem Lesen" zurück und fungiert als Vertrag zwischen Kapitel und Bewertung.

Ziel

Vor Kapitel 1 muss man vier Dinge verstehen:

• welcher Lern-Produktionsfall durch das Bewertungspaket läuft;
• welche Dateien als Ergebnis jedes Kapitels gelten;
• welche Befehle tatsächlich ausführbar sind und welche nur die Schnittstelle der zukünftigen Produktionsebene sind;
• wo das Lernminimum endet und der vollständige Implementierungspfad beginnt.

Durchgehender Fall

Das Basisszenario heißt AgentClinic-production. Es ist dieselbe AgentClinic, aber jetzt gibt es einen Betriebskreis darum. Der Hauptbewertungsfall ist high_memory_usage in appointments-api: er lässt sich bequem bis zur Webhook-Normalisierung, dem Readiness-Gateway, dem Probelauf und dem endgültigen Beweispaket führen. Zusätzliche Fälle zeigen einzelne Mechanismen, müssen aber nicht in einem einzigen capstone/ gemischt werden.

• Dienst appointments-api;
• Alarme high_memory_usage, autoscale_200pct, appointment_latency / appointment_latency_spike, node_not_ready, cdn_error_budget_burn;
• Spezifikationen, die /clear, Modellwechsel und die Review durch eine andere Person überstehen müssen;
• Verbot gefährlicher Handlungen ohne Beweise: Erweiterung des Wirkungsradius, Verlust des Audits, verstecktes Schließen von P0, automatische Umgehung des Rollbacks.

Der Lernzweig muss keinen echten Produktionscode enthalten. Es reichen Artefakte in capstone/, Vorlagen aus examples/templates/ und ausführbare Beispiele aus examples/. Wenn ein Kapitel nicht high_memory_usage verwendet, schreiben Sie in capstone/ nur die überprüfbare Schlussfolgerung: welcher Defekt, welches Gegenbeispiel, welches Budgetrisiko oder welche Invariante in den Hauptfall zu übertragen ist.

Kurze Übertragungskarte:

Ausführungsstack

Im ersten Band ist AgentClinic eine Anwendung auf Basis von TypeScript, Hono, serverseitigem JSX, SQLite und Vitest. Dieser Stack verschwindet nirgendwo: im Lernmodell AgentClinic-production bleibt er der Stack des Produkts selbst.

Im zweiten Band erscheint eine zweite Codeebene — kleine ausführbare Skripte in book2/examples/. Sie sind in Python-Standardbibliothek geschrieben und dienen nur dazu, dass eine Person auf ihrem Rechner ein minimales Beispiel eines Kapitels in wenigen Sekunden ohne Infrastrukturaufbau ausführen kann. Es ist kein Wechsel des Produktstacks und kein Hinweis, dass die Produktions-AgentClinic auf Python umgeschrieben wurde. Dies sind Lernsimulatoren: Stress-Mutator, Duell, Spec CI, Token-Budget, Readiness-Rechner. In einem realen Projekt werden solche Prüfungen häufiger als pre-commit, GitHub Actions, MCP-Werkzeug oder Dienst auf dem eigenen Stack umgesetzt — Python ist hier nur die günstigste Sprache für die Ausführung ohne Build.

Die Regel ist einfach: alles, was in book2/examples/ vorkommt, kann als python3 ... ohne Abhängigkeiten ausgeführt werden. Alles, was im Kapitel als [project script] oder [conceptual interface] gekennzeichnet ist, ist die Form eines zukünftigen Skripts oder einer Integration in Ihrem Projekt, nicht an Python gebunden.

Minimalroute

Wenn Sie wenig Zeit haben, gehen Sie den zweiten Band so durch:

1. Lesen Sie diesen Teil und die README des gewählten ausführbaren Beispiels.
2. Füllen Sie in den Kapiteln 1–3 drei manuelle Artefakte aus: genealogy.md, ein vergiftetes/fixiertes Paar und constitution.md.

1. Führen Sie in den Kapiteln 4–11 nur [runnable]-Befehle aus examples/ aus; übertragen Sie die Ergebnisse anderer Fälle als Grundsatz in capstone/, nicht als neue Domäne.
2. Überprüfen Sie in Kapitel 12 das Paket anhand der diagnostischen Checkliste.
3. Stellen Sie in Kapitel 13 einen kleinen capstone/ zu einem Vorfall zusammen.

Die Minimalroute erfordert nicht das Schreiben externer Orchestratoren, MCP-Server, Kubernetes-Integrationen oder echter CI-Gateways. Diese Elemente gehören zum vollständigen Pfad.

Die Routenprüfung ist einfach: nach jedem Kapitel muss in capstone/ eine neue überprüfbare Schlussfolgerung erscheinen. Kein vollständiger Produktionsprozess, sondern eine kleine Aufzeichnung, die man einer anderen Person zeigen kann.

> Wie man die Tabelle liest. Die Spalte „Schlussfolgerung" ist absichtlich in eigenen Worten beschrieben, ohne Begriffe aus den Kapiteln 4–13. Wenn in der rechten Spalte ein Wort auftaucht, das noch nicht im kurzen Wörterbuch unten steht, wird es in dem Kapitel eingeführt, in dem es benötigt wird. Versuchen Sie nicht, das Wörterbuch des Bandes anhand dieser Tabelle zu lernen.

| 3 | constitution.md mit zwei unveränderlichen Regeln und einer Regel mit Gültigkeitsdauer | | 4 | minimales Gegenbeispiel zu einer Regel oder Formulierung des nächsten Limitierers | | 5 | Ergebnis des Smoke-Laufs des Stress-Mutators oder kurzer Bericht darüber, welche Mutationen der Validator gefangen hat | | 6 | ein angenommener und ein abgelehnter Schattenkandidat (Regeln, die in die Spezifikation hätten aufgenommen werden können) | | 7 | Spec-CI-Zeile: was abgedeckt ist, was blockiert wird | | 8 | eine Datei mit Urteil zur strittigen Änderung und Verweis auf den Beweis | | 9 | Risiko der Erschöpfung des Modellbudgets und Schwelle, bei der auf die günstige Stufe gewechselt wird | | 10 | Zielmetrik und gepaarte Schutzmetrik gegen deren Goodhart-Verzerrung | | 11 | Urteil zur Produktionszulassung und Trockenlauf der erlaubten Aktion | | 12 | drei Punkte blocker / owner / next_check | | 13 | zusammengestellter capstone/ zu einem Vorfall mit fünf PASS-Zeilen der Rubrik |

Wenn im Kapitel zusätzliche Begriffe vorkommen, aber diese Schlussfolgerung fehlt, schließen Sie zuerst die Schlussfolgerung ab. Die Begriffe können Sie später nachlesen.

Zur Orientierung halten Sie ein ausgefülltes Beispiel [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md) bereit. Dies ist keine Vorlage zum gedankenlosen Kopieren, sondern die Minimalform der Antwort auf die Frage: „Welche Spur soll nach dem ersten Durchlauf bleiben?"

Das minimale Wörterbuch für den ersten Durchlauf ist kurz:

• capstone/ — das endgültige Beweispaket zu einem Vorfall;
• genealogy.md — Herkunft der Anforderung und Konfidenzniveau;
• validation.md — Befehle, manuelle Fakten und Blocker;
• judgment.md — Urteil zur strittigen Änderung;
• readiness.md — warum eine Aktion zugelassen, blockiert oder in den halbmanuellen Modus überführt wird.

Alle übrigen Begriffe werden nur benötigt, wenn sie helfen, eine dieser Dateien auszufüllen. Wenn ein Begriff die aktuelle Schlussfolgerung des Kapitels nicht beeinflusst, halten Sie beim ersten Lesen nicht dabei an.

Was tatsächlich ausgeführt wird

Der zweite Band verwendet drei Arten von Befehlsblöcken:

• [runnable] — führen Sie es wie geschrieben aus. Das Beispiel liegt in book2/examples/.
• [project script] — dies ist der Vertrag für ein zukünftiges Skript in Ihrem Projekt. Wenn daneben kein ausführbares Analogon angegeben ist, muss der Befehl nicht im Lehrbuch-Repository existieren.

• [conceptual interface] — Form einer zukünftigen Integration. Sie muss beim Lerndurchlauf nicht ausgeführt werden.

Die Regel ist einfach: das Bewertungspaket darf nur auf Fakten verweisen, die Sie tatsächlich ausgeführt haben, oder auf manuelle Artefakte, die ohne Chat-Verlauf gelesen werden können.

Erster Smoke-Lauf

Vor dem Lesen der Kapitel 4–11 ist es sinnvoll sicherzustellen, dass die lokalen Beispiele funktionieren:

bash book2/examples/smoke_all.sh

Das Skript führt den Smoke-Lauf auf einer temporären Kopie von book2/examples aus und hinterlässt daher kein out/ und __pycache__ im Arbeitsverzeichnis. Wenn Sie wenig Zeit haben, öffnen Sie examples/README.md und wählen Sie nur den Block des Kapitels aus, das Sie gerade durcharbeiten.

Arbeitsverzeichnis für die Bewertung

Erstellen Sie das Verzeichnis für das zukünftige Paket:

mkdir -p capstone

Lassen Sie es vorerst leer. In den Kapiteln 1–12 werden Sie schrittweise verstehen, welche Dateien dort landen werden. Mischen Sie nicht mehrere Vorfälle in einem Beweispaket: eine Datei darf auf ein ausführbares Analogon aus einem anderen Fall verweisen, aber die Entscheidung muss einen Hauptvorfall erklären.

capstone/
  README.md
  genealogy.md
  poisoned-spec.md
  fixed-spec.md
  constitution.md
  validation.md
  judgment.md
  budget-note.md

goodhart-note.md
  readiness.md
  antipattern-audit.md

Diese Struktur wiederholt den ersten Band: zuerst Absicht und Grenzen, dann Plan und Fakten, dann Review und endgültiges Paket. Der Unterschied des zweiten Bandes besteht nur darin, dass sich die Fakten nicht auf ein einzelnes Feature beziehen, sondern auf die Produktionszulassung einer gefährlichen Aktion.

Fügen Sie beim ersten Durchlauf nicht Dateien aus dem vollständigen Pfad in capstone/ ein, nur weil sie im Kapitel erwähnt werden. scorebook, metric_network, decision_hash, precedents.md und CI-Berichte werden benötigt, wenn Sie sie tatsächlich erstellt haben oder erklären können, welches ausführbare Analogon denselben Grundsatz bestätigt.

Um die Orientierung zu erleichtern, welche Kapitel welche Datei eröffnet:

Wenn unterwegs in einem Kapitel eine vierte oder fünfte Datei auftaucht, die nicht in dieser Liste enthalten ist, gehört dies zum vollständigen Pfad. Notieren Sie den Grundsatz in einer Zeile und fahren Sie fort.

Kontrolltatsache

Nach diesem Kapitel ist ein Hauptvorfall ausgewählt, ein leeres capstone/ erstellt, und die ausführbaren Beispiele sind mit dem Befehl bash book2/examples/smoke_all.sh überprüft oder mit einem ausdrücklichen Grund zurückgestellt. Wenn Sie den Hauptfall und die erste Datei, die in capstone/ landen wird, nicht benennen können, ist es zu früh, mit Kapitel 1 zu beginnen.

Kontrollfragen

1. Warum ist AgentClinic-production ein Lernmodell und keine Anforderung, eine echte Infrastruktur aufzubauen?
2. Worin unterscheidet sich [runnable] von [project script]?
3. Warum darf man im endgültigen capstone/ high_memory_usage und autoscale_200pct nicht als zwei gleichberechtigte Fälle mischen?
4. Warum muss der endgültige capstone/ ohne Chat-Verlauf verständlich sein?