Die Schrittverträge

Eine Datei pro Schritt. Alle haben dasselbe Gerüst, und zwar mit Absicht, damit du sie vergleichen kannst und damit mit der Zeit der Reflex, sie zu lesen, automatisch wird: die Kopfzeile mit dem Abschnitt, dem Wann, der Form und der Größe (verpflichtend oder proportional); wozu er dient; (1) der benötigte Kontext, generisch benannt; (2) die Prompts, auf Englisch, jeder mit einem Block „Bevor du den Prompt schickst“ davor (die Dateien und die Eingaben, die du selbst fertig haben musst, bevor du ihn einfügst, mit ihrem Inhalt und ihrem Mindestzustand), gefolgt von seiner Übersetzung und, darunter, von der Erklärung, was ich vom Modell verlange und warum jede Klausel dort steht; (3) das erwartete Ergebnis mit seinen Merkmalen; (4) die Vollständigkeitsprüfung, die du machst, ohne Code zu lesen; (5) die Warnsignale, die Symptome eines schlecht erklommenen Schritts.

Die englischen Prompts sind ein einziges Stück, identisch in den acht Fassungen des Dokuments; node build/build.mjs extrahiert sie nach prompts/ und prüft, dass keine Übersetzung sie verändert hat. Die Übersetzung, die jeden Prompt begleitet, ist dafür da, dass du ihn verstehst; dem Modell wird das Englische eingefügt.

Ich habe sie aus dem geschrieben, was ich in drei Systemen getan habe, die heute in Produktion sind; eins zu eins ausgeführt habe ich sie noch nicht. Das erste Projekt, das sie von Anfang bis Ende nutzt, wird mehrere korrigieren; das ist Teil von Schritt 23. Wenn ein Vertrag einen realen Fall zitiert, tut er das mit einer Marke [Ref. N], die auf das Referenzdokument verweist; das Verfahren bleibt sauber, und das Detail ist einen Klick entfernt.

Abschnitte: Start wird einmal pro Projekt erklommen; Schleife wiederholt sich bei jeder Änderung; Betrieb, wenn das System schon lebt. Die 23 kehrt zur 0 für das nächste Projekt zurück. Die vollständige Zeitlinie, mit dem, was zwischen Schritt und Schritt passiert, steht in Teil B des Hauptdokuments.

Schritt 0 — Lässt sich dieses Projekt so angehen? (Schrittvertrag)

Abschnitt: Start. Wann: ein einziges Mal, bevor das Repository geöffnet wird und vor allem anderen. Form: Gespräch: der Agent bewertet und fragt; du entscheidest. Größe: verpflichtend in jedem Projekt, so klein es auch sei. Stand: die Ausschlusskriterien X1 und X2 sind geschlossen; die gewichtenden Kriterien (D1 bis D10) kalibriere ich noch und markiere sie als Hypothese.

Wozu er dient

Steig in kein Projekt ein, in dem die Methode nicht funktionieren kann. Wenn der Agent sich nicht von Ende zu Ende selbst wird prüfen können, oder wenn es keinen Eigentümer der Domäne gibt, der entscheidet, verkommt die Methode zu „mit KI programmieren“, und am Ende liest du Code. Dieser Schritt ist die Eingangstür: man geht einmal hindurch, und wenn man nicht hindurchgeht, weiß man das besser vorher als nachher.

Und eine Grundidee, die ich dir klar mitgeben will: die Methode taugt nicht für jedes Projekt, und das ist kein Mangel. Eine Methode, die verspricht, für alles zu taugen, sagt gar nichts. Was dieser Schritt tut, ist die Grenze schriftlich festzulegen, damit die Entscheidung, einzusteigen oder nicht, eine Entscheidung ist und keine Hoffnung. Die beiden Ausschlusskriterien stammen aus Projekten, die ich abgelehnt habe, nicht aus denen, die ich angenommen habe Ref. 46.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

Generisch benannt; der Agent bewertet, ob er ausreicht, und fragt nach dem, was fehlt.

• Erhebung der Anfrage: was der Kunde will, für wen, und was heute ohne das System passiert.
• Technologische Erhebung: welche Technologie vorhanden ist oder vorgeschlagen wird, ob es ein Vorgängersystem gibt, ob dieses System ein Repository hat und wie es verwaltet wird.
• Erhebung der Testbarkeit: ob die Bildschirme programmatisch ausgeführt werden können und ob jedes Element der Oberfläche mit seinen verschiedenen Methoden zugänglich ist (Klick, Tippen, Zustand lesen), so dass ein Test den Bildschirm durchläuft und die Wirkung im Backend prüft.
• Wer der Eigentümer der Domäne ist und wie viel Zeit er zum Entscheiden hat.
• Welche Konsequenz ein Fehler hat (Geld, Gesundheit, Betrieb, keine).
• Umgebungen und Zugänge: ob es eine Testumgebung geben wird, ob der Agent Zugang hat, ob es eine nur lesend abfragbare Produktion gibt.

2. Prompts

Die Prompts sind auf Englisch, der Sprache, in der die Modelle Anweisungen am präzisesten und mit den wenigsten Tokens befolgen. Jeder bringt seine Übersetzung mit (im HTML über einen Knopf) und darunter die Erklärung, was ich verlange und warum jede Klausel dort steht. Dem Modell wird das Englische eingefügt.

Zu Beginn:

Was ich hier verlange: dass er die beiden Eingaben liest (die Erhebung und das Kriterienblatt); dass er vor dem Antworten bewertet, ob die Erhebung ausreicht, und, wenn sie nicht ausreicht, fragt statt anzunehmen (das ist die zentrale Klausel aller Prompts der Methode); dass er das Blatt mit der Quelle jeder Antwort ausfüllt, damit sie sich später nachverfolgen lässt; dass er die Ausschlusskriterien grün oder rot markiert; und dass er nicht entscheidet, weil die Eignung ich entscheide. Die letzte Zeile bittet ihn, in meiner Sprache zu antworten, denn der Prompt ist auf Englisch, aber das Gespräch muss es nicht sein.

Zum Abschluss:

Was ich hier verlange: dass er die Entscheidung schriftlich hinterlässt, mit Datum und Eigentümer (Schritt 6), mit den Bedingungen, falls es welche gibt, und mit der Spur aus Fragen und Antworten, die der Beleg dafür ist, dass er nichts angenommen hat.

3. Erwartetes Ergebnis

Eine Datei docs/ELIGIBILITY.md (oder der Name, den dein Projekt verwendet), eine Seite lang, mit:

• Datum und wer entschieden hat.
• Den beiden Ausschlusskriterien mit ihrer Antwort und ihrer Quelle:
• X1: es gibt ein zugängliches, standardmäßig verwaltetes Repository (oder das Projekt ist neu).
• X2: die Oberfläche lässt sich programmatisch ausführen und jedes Element ist mit seinen verschiedenen Methoden zugänglich, mit Prüfung der Wirkung im Backend.
• Den gewichtenden Kriterien, jedes mit Antwort, Quelle und Gewicht (sobald das Gewicht kalibriert ist).
• Der Entscheidung: go, no-go oder go mit Bedingungen, und die Bedingungen ausgeschrieben.
• Den Fragen, die der Agent gestellt hat, und den Antworten, damit die Spur bleibt.

4. Vollständigkeitsprüfung (du machst sie, ohne Code zu lesen)

• Haben die beiden Ausschlusskriterien eine explizite Antwort und eine Quelle? Wenn eines rot ist, lautet die Entscheidung „no-go“ oder gibt es eine Bedingung, die es auflöst?
• Ist irgendein Kriterium mit „ich nehme an, ja“ oder „wahrscheinlich“ beantwortet? Wenn ja, ist der Schritt nicht erklommen: der Agent hätte fragen müssen.
• Ist die Entscheidung mit Datum und Namen festgehalten?
• Sind die Bedingungen (falls es welche gibt) prüfbar? („Lesezugang zur Produktion vor Schritt 3 haben“ ja; „dass der Kunde mitwirkt“ nein.)

5. Warnsignale

• Der Agent hat das ganze Blatt ausgefüllt, ohne eine einzige Frage zu stellen. Entweder war die Erhebung perfekt (das ist sie nie) oder er hat angenommen.
• Die Entscheidung lautet „go mit Bedingungen“ und die Bedingungen sind mehr als drei. Wahrscheinlich ist es ein „no-go“, das man nicht aussprechen will.
• Das Kriterium X2 wurde mit „ja, mit ein bisschen Arbeit“ beantwortet. Wenn sich die Bildschirme heute nicht programmatisch bedienen lassen, ist dieses „bisschen Arbeit“ das ganze Projekt.

Schritt 1 — Die Arbeitsvereinbarung (Schrittvertrag)

Abschnitt: Start. Wann: ein einziges Mal, unmittelbar nach der Eignung; wird überarbeitet, wenn ein Rückschlag es verlangt. Form: ein einziger Durchgang, mit einer Anpassungsrunde von dir. Größe: verpflichtend in jedem Projekt. Es ist der billigste Schritt von allen und der, der am meisten Frustration vermeidet.

Wozu er dient

Leg vor der ersten Zeile Code schriftlich fest, wie du und der Agent arbeiten werden. Es sieht aus wie eine Formalität und ist keine: es ist das, was verhindert, dass der Agent „hilft“, indem er den Umfang ausweitet, Schulden für später liegen lässt oder als erledigt meldet, was er zu erledigt glaubt. In meinem Werkzeug heißt diese Datei SQ.md (Qualitätsstandards); der Name ist egal, der Inhalt nicht.

Denk es dir so: der Agent ist ein neuer Mitarbeiter, der jeden Morgen ohne Erinnerung an gestern ankommt. Die Vereinbarung ist das, was du ihm am ersten Tag sagst, und das, was er jeden Tag wieder lesen wird. Wenn du sie nicht aufschreibst, wirst du es ihm jedes Mal sagen müssen, und jedes Mal ein bisschen anders. Ich habe sie zum ersten Mal geschrieben, als ich zwei Wochen lang in jeder Sitzung dasselbe wiederholt hatte Ref. 1, und nichts von dem, was ich hineinschrieb, war neu in der Systemtechnik; neu war, es für jemanden ohne Gedächtnis aufschreiben zu müssen.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Keiner aus dem Projekt: es ist die erste Datei.
• Von dir: deine Arbeitsvorlieben (Sprache, wie du gefragt werden willst, was du als Verschwendung deiner Zeit betrachtest, welches Maß an Autonomie du dem Agenten gibst).

2. Prompts

Zu Beginn:

Was ich hier verlange: die sechs Mindestregeln, jede mit dem Fehler, den sie verhindert (das ist es, was sie zu Regeln macht und nicht zu Ratschlägen); dass er projekteigene Regeln vorschlägt, sie aber als Vorschläge markiert, damit du sie annimmst oder ablehnst; und dass er fragt, was er über dich wissen muss. Eine Vereinbarung, die ohne eine einzige Frage verfasst wurde, ist verdächtig: der Agent kennt die Person nicht, mit der er arbeiten wird.

Zum Abschluss:

Was ich hier verlange: dass er die Vereinbarung mit Datum und Version abschließt und sie in die Projektdatei einhängt, damit sie in jeder Sitzung gelesen wird. Ohne dieses Einhängen existiert die Vereinbarung, aber sie wirkt nicht.

3. Erwartetes Ergebnis

Eine Datei docs/WORKING_AGREEMENT.md (oder SQ.md, oder CONTRATO.md) mit:

• Datum und Version.
• Jeder Regel nummeriert, in ein oder zwei Sätzen, mit dem Fehler, den sie verhindert.
• Den projekteigenen Regeln, als solche markiert.
• Einer Fußzeile, die sagt, dass der Agent Änderungen vorschlägt, die Vereinbarung aber nicht allein bearbeitet.

Und eine Zeile in der Projektdatei (PROJECT.md oder CLAUDE.md), die anordnet, sie zu Beginn jeder Sitzung zu lesen.

4. Vollständigkeitsprüfung

• Sind die sechs Mindestregeln da, jede mit dem Fehler, den sie verhindert?
• Ist irgendeine Regel als Absichtserklärung geschrieben („versuchen, …“, „nach Möglichkeit …“)? Wenn ja, taugt sie nichts: Regeln werden eingehalten oder nicht.
• Ordnet die Projektdatei an, sie in jeder Sitzung zu lesen?
• Hat dir der Agent mindestens eine Frage dazu gestellt, wie du arbeitest? Wenn er alles verfasst hat, ohne etwas zu fragen, ist das verdächtig: er kennt dich nicht.

5. Warnsignale

• Die Vereinbarung hat mehr als zwanzig Regeln. Niemand, weder Mensch noch Modell, hält zwanzig Regeln ein; sechs oder acht werden eingehalten.
• Eine Regel sagt „der Agent darf diese Vereinbarung ändern, wenn er es für nötig hält“. Nein.
• Zwei Wochen später tut der Agent etwas, das die Vereinbarung verbietet, und niemand merkt es. Die Vereinbarung wird nicht gelesen: prüf das Einhängen in der Projektdatei.

Schritt 2 — Die Projektdefinition, der semantische Baum und die Pflichtlektüre (Schrittvertrag)

Abschnitt: Start. Wann: wird einmal geschrieben, nach der Vereinbarung; der semantische Baum und der lebende Zustand werden während des ganzen Projekts gepflegt, mit jedem Block und jeder neuen Entscheidung. Form: Gespräch: der Agent verfasst, fragt nach dem, was fehlt, du korrigierst. Größe: verpflichtend in jedem Projekt. In einem kleinen kann die Projektdatei fünfzig Zeilen haben und der semantische Baum zwanzig Knoten; was sie nicht können, ist nicht zu existieren.

Wozu er dient

Jede Sitzung des Agenten beginnt bei null: er erinnert sich nicht an gestern. Gib ihm eine Karte, kurz, die ihm sagt, was das Projekt ist, in welchem Zustand es ist und welche Entscheidungen schon getroffen wurden, und zwing ihn, sie zu lesen, bevor er irgendetwas anfasst. Der Fehler, den das verhindert, ist ein doppelter: wegwerfbare Arbeit, weil die Karte nicht gelesen wurde Ref. 9, und die Karte, die wächst, bis sie unlesbar wird Ref. 41. Die praktische Regel: die Projektdatei ist das Programm, nicht die Historie. Was passiert ist, gehört woandershin.

Die Karte hat zwei Teile, und der zweite ist der, der die meiste Arbeit leistet. Der erste ist die Projektdatei: was das System ist, für wen, was es NICHT ist, die getroffenen Entscheidungen. Der zweite ist der semantische Baum: das System als Baum zerlegt, mit den Domänen und unter jeder ihre Akteure, ihre Prozesse (die Anwendungsfälle), ihre Entitäten mit ihren Zuständen, ihre Bildschirme und ihre Integrationen; und an jedem Knoten hängen die offenen Posten und die Entscheidungen, die ihn betreffen. Der Baum entsteht aus der Erhebung, die du mit den klassischen Methoden der Anforderungstechnik gemacht hast (Interviews, Anwendungsfälle, Domänenmodell), der Agent baut ihn, du korrigierst ihn, und er ist das, was dem Modell den exakten Kontext des Knotens gibt, den es anfassen wird, ohne das ganze Projekt lesen zu müssen. Und er ist das, was dir erlaubt, ohne Code zu lesen zu prüfen, dass das System, das der Agent versteht, das ist, das das Geschäft verlangt hat.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Erhebung des Geschäfts: was der Kunde tut, wer das System benutzt, welches Problem es löst, was es nicht tun soll. Mit den Interviews, den Anwendungsfällen oder User Stories, die du benennen kannst, und den Entitäten des Geschäfts mit ihren Zuständen, auch wenn sie unvollständig sind.
• Die Arbeitsvereinbarung (Schritt 1).
• Wenn es ein Vorgängersystem gibt: Lesezugang zu seinem Code oder seiner Dokumentation.
• Die schon getroffenen Entscheidungen, falls es welche gibt, und sei es mündlich.

2. Prompts

Zu Beginn:

Was ich hier verlange: dass er die Erhebung bewertet und fragt, bevor er verfasst; dass die Projektdatei kurz ist (die Obergrenze von dreihundert Zeilen ist willkürlich, aber nötig: ohne Obergrenze wächst sie); dass sie explizit sagt, was das System nicht ist, denn was nicht gesagt ist, wird das Modell erfinden; dass die Entscheidungen ein Datum haben; dass er den semantischen Baum mit der vollständigen Struktur baut (Domänen, Akteure, Anwendungsfälle mit ihren Teilen, Entitäten mit Zuständen und Übergängen, Bildschirme, Integrationen), der das Domänenmodell der Anforderungstechnik in Baumform ist; dass er markiert, was er erschlossen hat, denn dort verstecken sich die Erfindungen; und dass er den lebenden Zustand in eine andere Datei trennt, damit die Karte nicht zur Historie wird.

Zum Abschluss:

Was ich hier verlange: deine Korrekturen (vor allem an den Knoten, die er als erschlossen markiert hat), das Datum, und zwei neue Regeln in der Vereinbarung: die, die die Projektdatei davor schützt, zur Historie zu werden, und die, die jeden offenen Posten an einen Knoten des Baums bindet, was den Baum lebendig hält und dir erlaubt, in zehn Sekunden einen offenen Posten außerhalb des Umfangs zu erkennen.

3. Erwartetes Ergebnis

• PROJECT.md (oder CLAUDE.md): kurz, Pflichtlektüre, mit was es ist, für wen, was es nicht ist, Modulen, Entscheidungen mit Datum, und der Anweisung, sie zusammen mit dem Baum zu lesen. Höchstens dreihundert Zeilen.
• docs/SEMANTIC_TREE.md: der semantische Baum, mit den erschlossenen Knoten markiert, bis du sie bestätigst, und, ab dem ersten Block, den offenen Posten und Entscheidungen an ihren Knoten.
• docs/STATUS.md: lebender Zustand, getrennt von den vorigen.
• In allen dreien ein Datum der letzten Aktualisierung.
• In der Vereinbarung die zwei neuen Regeln.

4. Vollständigkeitsprüfung

• Passt PROJECT.md in eine Lektüre von fünf Minuten? Wenn nicht, ist es falsch: es ist das Programm, nicht die Historie.
• Sagt es explizit, was das System NICHT tut? (Was fehlt, ist das, was der Agent erfinden wird.)
• Geh den semantischen Baum durch, als wärst du der Kunde: sind alle Akteure da, die du kennst? Hat jede Entität die Zustände, die das Geschäft verwendet, nicht mehr und nicht weniger? Gibt es einen Knoten, den du nicht erkennst? Das ist eine Erfindung: korrigier ihn jetzt.
• Sind die erschlossenen Knoten markiert? Hast du sie alle bestätigt oder korrigiert?
• Hat jede Entscheidung ein Datum und wer sie getroffen hat?
• Hat der Agent etwas über das Geschäft gefragt, bevor er verfasst hat? Wenn er nichts gefragt hat, prüf, was er angenommen hat.
• Ist der lebende Zustand in einer anderen Datei?
• Die Leseprobe: schließ die Sitzung, öffne eine neue und frag ihn, was das System NICHT tut und an welchem Knoten des Baums ein bestimmter Bildschirm hängt. Wenn er mit der Karte antwortet, funktioniert das Einhängen.

5. Warnsignale

• Die Projektdatei ist in einem Monat um mehr als 20 % gewachsen. Etwas, das kein Programm ist, kommt hinein.
• Der Agent beginnt eine Sitzung damit, etwas vorzuschlagen, das schon entschieden und aufgeschrieben ist. Er hat die Karte nicht gelesen: das Einhängen der Pflichtlektüre hat versagt.
• Der Abschnitt „was es nicht ist“ ist leer oder sagt „nichts Besonderes“. Jedes System hat Grenzen; wenn sie nicht aufgeschrieben sind, wird das Modell sie überschreiten.
• Es gibt offene Posten, die an keinem Knoten des Baums hängen. Entweder ist der Baum veraltet oder diese Posten liegen außerhalb des Umfangs; beides muss man sich ansehen.
• Eine Entität des Baums hat einen Zustand, den das Geschäft nie benannt hat. Das Modell hat ihn erfunden, weil er ihm logisch erschien, und wird darauf bauen.

Schritt 3 — Dimensionieren, bevor die Architektur entworfen wird (Schrittvertrag)

Abschnitt: Start. Wann: einmal, nach der Definition und bevor das Skelett gebaut wird; wird neu gemacht, wenn das Geschäft seine Größenordnung ändert. Form: Gespräch: der Agent rechnet und legt Optionen vor; du wählst. Größe: immer verpflichtend, aber proportional: in einem kleinen Projekt kann die Dimensionierung eine halbe Seite und eine einzige Entscheidung sein („passt jahrelang in SQLite“). Was sie nicht kann, ist nicht gemacht zu werden, denn die Frage „wie stark wird es wachsen?“ kostet fünf Minuten und die falsche Antwort kostet Wochen.

Wozu er dient

Triff die strukturellen Entscheidungen —welche Datenbank-Engine, ob die Schnittstelle synchron oder asynchron ist, wie viel Nebenläufigkeit— mit Zahlen und nicht nach Geschmack. Es ist der Schritt, dessen Überspringen am teuersten kommt, und ich sage das aus eigener Erfahrung: in einem meiner Systeme habe ich mit JSON-Dateien angefangen, und als ich maß, stellte sich heraus, dass es 3,4 Millionen Zeilen pro Jahr erzeugen würde; die Schnittstelle danach zu ändern kostete eine ganze Etappe der Neuentwicklung Ref. 15.

Es gibt einen Schlüsselpunkt, den du im Kopf behalten solltest: es gibt Daten, die nur das Geschäft hat (wie viele Entitäten, wie viele Ereignisse pro Entität, wie viele Operatoren in der Spitze, wie lange aufbewahrt werden muss), und das Modell kann sie nicht erschließen. Was es erschließen kann, ist das Abgeleitete. Deshalb verlangt der Prompt von ihm, zu bewerten, ob die Primärdaten vollständig sind, und die fehlenden zu erfragen, statt sie mit sicherer Miene zu schätzen. Wer weiß, was ihm zum Rechnen fehlt, ist das Modell, nicht ein Formular.

Und eine zweite Idee, die du mitnehmen sollst: die asymmetrischen Entscheidungen. Es gibt Entscheidungen, die sehr wenig kosten, wenn du sie triffst und sie sich als unnötig erweisen, und sehr viel, wenn du sie nicht triffst und sie sich als nötig erweisen. Die Persistenzschnittstelle asynchron ab der ersten Zeile ist das kanonische Beispiel: wenn die Engine am Ende synchron ist, war ein await zu viel; wenn sie am Ende asynchron ist und du es nicht vorgesehen hast, muss alles neu geschrieben werden. Diese Entscheidungen triff immer, wenn sie billig sind, auch wenn sie heute nicht nötig sind.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Erhebung der Mengendaten des Geschäfts, so generisch benannt: Hauptentitäten und ihr Wachstum, Ereignisse pro Entität, gleichzeitige Operatoren und Zeitpunkt der Spitze, Aufbewahrungsdauer der Daten, Ausnahmelasten (Kampagnen, Abschlüsse), erwartetes Wachstum. Die Erhebung ist von Natur aus unvollständig; der Agent bewertet und fragt.
• Wenn es ein Vorgängersystem gibt: Lesezugang zu seiner Datenbank, um echte Zahlen statt Schätzungen zu holen.
• PROJECT.md und der semantische Baum (Schritt 2): die Entitäten des Baums sind die, die dimensioniert werden müssen.

2. Prompts

Zu Beginn:

Was ich hier verlange, Klausel für Klausel: Primärdaten von abgeleiteten unterscheiden (das ist die Unterscheidung, die die Erfindung verhindert); die fehlenden Primärdaten erfragen und sie nie schätzen; echte Zahlen des Vorgängersystems verwenden, wenn es eines gibt, mit ihrer Quelle; das Abgeleitete mit sichtbarer Rechnung berechnen, damit du sie nachrechnen kannst; das Szenario „mal zehn“, das zeigt, was zuerst bricht; drei Optionen mit den Kosten, zwischen ihnen zu migrieren, denn die Entscheidung ist nicht nur „welche“, sondern „wie viel kostet es, sich zu irren“; und dass er weder wählt noch Code schreibt, denn dieser Schritt ist einer der Entscheidung, nicht des Bauens.

Zum Abschluss:

Was ich hier verlange: die vollständige Aufzeichnung, mit Quellen und Rechnungen; die gewählte Option und den Grund; und die asymmetrischen Entscheidungen ausgeschrieben, denn wenn sie implizit bleiben, werden sie nicht eingehalten.

3. Erwartetes Ergebnis

Eine Datei docs/SIZING.md mit:

• Datum und wer entschieden hat.
• Tabelle der Primärdaten: Wert, Quelle (vom Geschäft mitgeteilt / im Vorgängersystem gemessen), Datum. Keiner mit Quelle „Annahme“.
• Tabelle der abgeleiteten Daten: Wert, aus welchen Primärdaten er stammt, die Rechnung.
• Das Szenario „mal zehn“: was zuerst bricht.
• Die drei nummerierten Optionen, mit den Kosten, zwischen ihnen zu migrieren.
• Die gewählte und der Grund, in ein oder zwei Sätzen.
• Die asymmetrischen Entscheidungen, aufgelistet.
• Die Fragen, die der Agent gestellt hat, und die Antworten.

4. Vollständigkeitsprüfung

• Gibt es ein Primärdatum mit Quelle „Annahme“ oder ohne Quelle? Wenn ja, ist der Schritt nicht erklommen: der Agent hätte es erfragen müssen.
• Zeigt jedes abgeleitete Datum, aus welchen Primärdaten es stammt und mit welcher Rechnung? Kannst du eine Rechnung von Hand nachrechnen, und sie stimmt?
• Gibt es drei Optionen und eine gewählte mit schriftlichem Grund?
• Sagt es, was passiert, wenn die Menge mit zehn multipliziert wird?
• Sind die asymmetrischen Entscheidungen aufgeschrieben, oder blieben sie implizit?
• Hat der Agent gefragt? Wenn er Zahlen vorgelegt hat, ohne eine einzige Frage gestellt zu haben, sei misstrauisch.

5. Warnsignale

• Die drei Optionsszenarien führen zur selben Schlussfolgerung. Der Agent hatte schon gewählt und die anderen zwei der Form halber gebaut.
• Eine abgeleitete Zahl hat mehr Präzision als die Primärdaten, aus denen sie stammt („1.234.567 Zeilen“ aus „etwa 5.000 Familien“). Die Präzision ist falsch.
• Das Szenario „mal zehn“ sagt „passiert nichts“. Es passiert immer etwas; wenn er es nicht gefunden hat, hat er nicht gesucht.

Schritt 4 — Das Skelett mit seinen Toren (Schrittvertrag)

Abschnitt: Start. Wann: einmal, zum Abschluss des Starts, nach der Dimensionierung und vor jeder Funktionalität. Hier wird die gesamte anfängliche Infrastruktur und die Integrations- und Deployment-Kette aufgebaut. Form: ein einziger langer Durchgang, mit deiner visuellen Freigabe am Ende. Größe: verpflichtend in jedem Projekt, das Nutzer haben wird. Bei einem wegwerfbaren Prototyp kann man ihn überspringen; aber wenn der Prototyp überlebt (sie überleben immer), ist dieser Schritt das Erste, was bezahlt werden muss.

Wozu er dient

Sorg dafür, dass das System LEER startet, getestet und deployt wird, bevor es Funktionalität hat. Das Deployment am Ende zu entdecken ist sündhaft teuer: in einem meiner Systeme kam es einen Monat nach dem Start und kostete fünf offene Posten in Folge Ref. 32. Wenn das Skelett im Start deployt wird, treffen diese Schläge, wenn null Funktionalität auf dem Spiel steht.

Die allgemeine Idee dahinter: der Weg in die Produktion ist Teil des Produkts, keine Formalität am Ende. Ein System, das auf der Maschine des Programmierers läuft und sich nicht deployen lässt, ist kein System; es ist eine Demo. Und die einzige Art zu wissen, dass der Weg funktioniert, ist, ihn zu gehen, solange es noch nichts zu verlieren gibt. Deshalb wird in diesem Schritt alles aufgebaut, was die Schleife später benutzen wird: das Repository mit seiner Struktur, die Testumgebung, die Continuous Integration, die die Batterie bei jedem Push laufen lässt, und das automatische Deployment in die Testumgebung.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• docs/SIZING.md (Schritt 3): die gewählte Option definiert das Skelett.
• Erhebung der Umgebungen: wo es laufen wird (Cloud, eigener Server), ob es eine Testumgebung und eine Produktionsumgebung gibt, wer Zugang hat, wie heute deployt wird, falls es etwas gibt.
• Die Zugangsdaten des Ortes, an den deployt wird, und sei es ein kostenloser Dienst.
• Die Projektart: neu, Korrektur oder Weiterentwicklung von etwas Bestehendem.

2. Prompts

Zu Beginn:

Was ich hier verlange: dass er prüft, ob er die Zugänge hat, bevor er anfängt (ohne das bleibt das Skelett auf der Maschine des Agenten); die exakte Liste dessen, was ein Skelett ist (Struktur, Start, ein Test, Continuous Integration, Deployment in die Testumgebung); die Tore schriftlich; einen echten Screenshot der Testumgebung, der der einzige gültige Beleg dafür ist, dass deployt wurde; und das ausdrückliche Verbot, Funktionalität hinzuzufügen, denn das Modell neigt zum „wo ich schon dabei bin“, und das bricht den exakten Umfang.

Zum Abschluss:

Was ich hier verlange: die drei Befehle dort hinterlassen, wo die nächste Sitzung sie findet, und beweisen, dass das Deployment wiederholbar ist (es zweimal laufen lassen, ohne etwas zu brechen). Dieser zweite Lauf ist der Beweis, dass das Verfahren ein Verfahren ist und kein Glück.

3. Erwartetes Ergebnis

• Das Repository mit der Struktur, dem Server und dem Bildschirm, die starten.
• Ein grüner Smoke-Test und die Batterie, die in Continuous Integration läuft (mit dem Link zum grünen Lauf).
• Das Deployment in die Testumgebung, das funktioniert, mit der URL, und zweimal ausgeführt.
• docs/GATES.md: die Liste der Tore, jedes mit der Bedingung zum Passieren.
• Ein Screenshot des leeren Systems, das in der Testumgebung läuft.
• docs/STATUS.md aktualisiert mit den drei Befehlen (ausführen, testen, deployen).

4. Vollständigkeitsprüfung

• Kannst du die URL der Testumgebung öffnen und den leeren Bildschirm sehen? (Das machst du, nicht der Agent.)
• Gibt es einen Link zu einem grünen Lauf der Continuous Integration?
• Wurde das Deployment zweimal ausgeführt, und der zweite Lauf hat nichts gebrochen?
• Sind die Tore mit je einer prüfbaren Bedingung aufgeschrieben?
• Gibt es irgendeine Funktionalität, die du nicht verlangt hast? Wenn ja, hat der Agent den exakten Umfang verletzt.

5. Warnsignale

• Das Skelett „läuft lokal“, aber das Deployment „sehen wir später“. Nein: das Deployment ist das Skelett.
• Der Screenshot stammt von der Maschine des Agenten, nicht aus der Testumgebung. Verlang die URL.
• Die Tore sagen Dinge wie „der Code hat gute Qualität“. Ein Tor ist eine prüfbare Bedingung: „die Batterie ist grün“, „das Deployment in die Testumgebung hat funktioniert“.

Schritt 5 — Der Plan sind die offenen Posten: die detaillierte Spezifikation lebt in jedem einzelnen (Schrittvertrag)

Abschnitt: Schleife. Wann: das Register wird beim Öffnen des ersten Funktionsblocks angelegt, sobald der Start abgeschlossen ist; jeder neue Block beginnt damit, die Anfrage des Kunden in spezifizierte offene Posten zu verwandeln; die Routine wird in jeder Sitzung während des ganzen Projekts verwendet; die Dokumentation des erledigten Postens wird beim Schließen geschrieben, in derselben Sitzung. Form: ein einziger Durchgang beim Öffnen jedes Blocks; danach Routine jeder Sitzung. Größe: verpflichtend in jedem Projekt. Es ist der Schritt, der alle anderen nachvollziehbar macht: ohne nummerierte und spezifizierte offene Posten gibt es keinen Ort, an dem die Spezifikation oder der Beleg hängen kann.

Wozu er dient

Hab eine einzige Arbeitswarteschlange, geordnet und mit Tor, die die Wahrheit des Projekts ist. Es gibt keinen „Plan“ auf der einen und „Aufgaben“ auf der anderen Seite: die Liste der offenen Posten IST der Plan. Das verhindert die lange Spezifikation, die nach zwei Wochen überholt ist und veraltet Ref. 17, und die Arbeit, von der niemand weiß, warum sie gemacht wurde Ref. 7.

Aber da ist mehr, und es ist das, was diesen Schritt von einer beliebigen Aufgabenliste unterscheidet. In der klassischen Methode gab es ein Anforderungsspezifikationsdokument, lang, das alles beschrieb, was das System tun sollte, und das alterte, bevor es fertig war. Hier wird dieses Dokument zerlegt: die detaillierte Spezifikation lebt in jedem offenen Posten. Ein gut geschriebener offener Posten bringt mit: den Knoten des semantischen Baums, an dem er hängt; die User Story oder den Anwendungsfall, der ihn auslöst, mit den Worten des Kunden; die detaillierte Beschreibung; die anwendbaren Geschäftsregeln, mit ihrer Entscheidung und ihrem Datum; die Daten, die hinein- und hinausgehen; die betroffenen Bildschirme, mit dem Prototyp, falls es einen gibt; die Randfälle und die Ausnahmen; die Abnahmekriterien in der Form „gegeben, wenn, dann“; und wie geprüft wird. Die Summe der offenen Posten ist die Spezifikation des Systems, und die Nachverfolgbarkeit (Anforderung → offener Posten → Test → Commit) ist keine separate Matrix: sie ist der offene Posten selbst.

Und das Dritte, das den Kreis schließt: die geschlossenen Posten sind Dokumentation. Wenn ein offener Posten geschlossen wird, wird er nicht gelöscht und nicht leer archiviert: er bleibt mit seiner Spezifikation, der Entscheidung, die ihn ausgelöst hat, dem Beleg, mit dem er geschlossen wurde (die Zahlen des Rot und des Grün, der Screenshot, die gemessene Zahl), dem Commit und dem Datum. Die Warteschlange der geschlossenen Posten ist die funktionale Historie des Systems: was gebaut wurde, warum, wann und wie es getestet wurde. Daraus entstehen das Änderungsprotokoll, die neuen Abschnitte des Handbuchs und die Antwort auf „warum tut das System das?“ sechs Monate später.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Anfrage des Kunden für den Block, in Prosa, so wie er sie sagen würde, mit ihren Mehrdeutigkeiten. Wenn du in der Aufnahme Anwendungsfälle oder User Stories gemacht hast, umso besser: sie sind die natürliche Einheit eines Blocks.
• Der semantische Baum (Schritt 2), um jeden offenen Posten an seinen Knoten zu hängen.
• Die Audits und die Befunde der menschlichen Tests, falls es schon welche gab.
• PROJECT.md und docs/STATUS.md.

2. Prompts

Zum Öffnen eines Blocks:

Was ich hier verlange: dass er die Anfrage in prüfbare Einträge verwandelt und fragt, wenn die Anfrage nicht ausreicht, um einen prüfbaren zu schreiben (Mehrdeutigkeit wird durch Fragen gelöst, nicht durch Wählen); die vollständige Spezifikation jedes offenen Postens, Feld für Feld, die die klassische Anforderungstechnik ist, in kleine Einheiten zerlegt; den Knoten des Baums, an dem er hängt, der es dir erlaubt, einen offenen Posten außerhalb des Umfangs zu erkennen; die Geschäftsregeln mit ihrer Entscheidung oder als fehlend markiert, was die Verbindung zu Schritt 6 ist; die Abnahmekriterien in der klassischen Form, die das Drehbuch des Ende-zu-Ende-Tests von Schritt 8 sind; und eine vorgeschlagene Reihenfolge mit ihrem Grund, damit du sie bestätigst oder änderst.

Routine jeder Sitzung (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: die Disziplin jeder Sitzung: ankündigen, was genommen wird, und die Spezifikation noch einmal lesen (der Agent startet ohne Gedächtnis, und die Spezifikation ist sein Gedächtnis des offenen Postens), den Posten in jedem Commit zitieren, mit Beleg schließen, den erledigten Posten dokumentieren im selben Register, und notieren statt tun, was außerhalb der Liste auftaucht. Diese letzte Klausel ist die, die den exakten Umfang schützt, wenn das Modell „noch etwas sieht“.

3. Erwartetes Ergebnis

docs/PENDING.md (oder das Werkzeug, das dein Projekt nutzt) mit, pro offenem Posten:

• Nummer, Titel, Status (offen / in Arbeit / geschlossen), Öffnungs- und Schließdatum.
• Dem Knoten des semantischen Baums.
• Der User Story oder dem Anwendungsfall des Ursprungs, mit den Worten des Kunden.
• Der detaillierten Spezifikation: Beschreibung, Geschäftsregeln mit Entscheidung und Datum, Daten, Bildschirme, Randfälle, Abnahmekriterien, wie geprüft wird.
• Beim Schließen: der Beleg, der Commit, das Datum, die unterwegs getroffenen Entscheidungen.

Und die Routine in der Arbeitsvereinbarung.

4. Vollständigkeitsprüfung

• Lies die Spezifikation eines zufälligen offenen Postens, als wärst du der Kunde: beschreibt sie, was du verlangt hast, mit deinen ursprünglichen Worten? Sind die Abnahmekriterien die, die du verwenden würdest, um „so ist es richtig“ zu sagen? Gibt es einen Randfall, den du kennst und der nicht drin ist?
• Hängt jeder offene Posten an einem Knoten des Baums? Hängt einer an einem Knoten, den du nicht erkennst?
• Sagt jeder offene Posten, wie er geprüft wird? Ein Posten ohne Prüfung kann nicht geschlossen werden.
• Gibt es Geschäftsregeln, die als „fehlt, nachgefragt“ markiert sind, nach denen du nicht gefragt wurdest?
• Gibt es „geschlossene“ Posten ohne Beleg und Commit? Wenn ja, öffne sie wieder. Behalten die geschlossenen ihre Spezifikation und ihre Abschlussdokumentation?
• Nimm drei Commits nach Zufall: zitieren sie ihren Posten?
• Ist im Code etwas aufgetaucht, das keinen offenen Posten hat? Dort hat der Agent den Umfang verlassen.

5. Warnsignale

• Ein offener Posten ist seit mehr als drei Sitzungen „in Arbeit“. Entweder sind es drei Posten, oder er ist durch eine Entscheidung blockiert, die niemand getroffen hat (Schritt 6).
• An einem Tag werden mehr Posten geschlossen als Commits gemacht. Sie werden ohne Beleg geschlossen.
• Die Spezifikationen sind einzeilig. Der Agent hat sie der Form halber geschrieben, nicht um darauf zu bauen; er wird beim Bauen erfinden, was fehlt.
• Die Liste hat mehr als fünfzig offene Posten. Das ist kein Plan, das ist ein Inventar von Ängsten: priorisieren und archivieren.
• Jemand fragt, warum das System etwas tut, und die Antwort steht in keinem geschlossenen Posten. Die Dokumentation des Erledigten wird nicht geschrieben.

Schritt 6 — Entscheidungen werden neben dem Code festgehalten (Schrittvertrag)

Abschnitt: Schleife. Wann: in jeder Sitzung der Schleife, jedes Mal, wenn der Agent auf eine nicht aufgeschriebene Geschäftsregel oder auf eine Verzweigung stößt, die ändert, was der Nutzer sieht. Meist sind es zwei oder drei pro Block. Auch im Start (Schritte 0 und 3) und in der Produktionsfreigabe (14 und 15). Form: kurzes Gespräch: der Agent erkennt, dass eine Entscheidung ansteht, fragt und hält sie schriftlich fest. Größe: verpflichtend in jedem Projekt. In einem kleinen kann das Register eine Tabelle mit zehn Zeilen sein; worauf es ankommt, ist, dass die Geschäftsregeln einen Eigentümer haben.

Wozu er dient

Sorg dafür, dass jede Geschäftsregel und jede strukturelle Entscheidung einen Eigentümer, ein Datum und einen Ort hat. Sonst weiß in sechs Wochen niemand, ob „genehmigt plus Saldo kehrt in die Warteschlange zurück“ eine Entscheidung des Kunden oder ein Einfall des Agenten war. Und vermeide das Schlimmste: den Agenten, der Domänenregeln erfindet, weil sie ihm vernünftig erschienen.

Das hat eine Konsequenz, die ich laut aussprechen will: das Modell, wenn es auf eine Lücke in den Regeln stößt, füllt sie. Es hält nicht inne; es ergänzt mit dem, was ihm am wahrscheinlichsten erscheint, und tut das mit derselben Selbstverständlichkeit, mit der es alles andere schreibt. Deshalb lautet die Routine dieses Schritts nicht „schreib die Entscheidungen auf“, sondern „halt an und frag, wenn eine fehlt“. Das Zweite ist das Schwierige, und es ist das, was in der Vereinbarung verlangt werden muss. Die Praxis, die Regel im Commit festzuhalten, mit meinen Worten und dem Datum, habe ich bei der Krankenkasse durchgesetzt Ref. 29, und die, Entscheidungen vor dem Bauen einzufrieren, stammt aus meinem Werkzeug Ref. 5.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Das Gespräch mit dem Eigentümer: es ist der einzige Kontext. Der Agent kann keine Geschäftsregeln entscheiden.
• Ein vereinbarter Ort, an dem die Entscheidungen geschrieben werden: die Commit-Nachricht, die Spezifikation des offenen Postens und ein Register docs/DECISIONS.md.

2. Prompts

Routine (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: dass er anhält vor einer nicht aufgeschriebenen Regel oder einer sichtbaren Verzweigung; dass er mit Empfehlung und Alternative fragt (damit du in zehn Sekunden entscheidest, nicht in zehn Minuten); dass er die Entscheidung mit deinen wörtlichen Worten an den drei Orten festhält (dem Commit, dem offenen Posten, dem Register), nicht mit einer „verbesserten“ Paraphrase; und, für den Fall, dass du nicht antwortest, die am besten umkehrbare Option, markiert als „durch Unterlassung“, was erlaubt weiterzumachen, ohne dass die Entscheidung verschwindet.

Zum Abschluss (jede Entscheidung):

Was ich hier verlange: das Mindestformat einer Entscheidung: die wörtliche Regel, wer, wann. Drei Dinge; ohne eines der drei ist es keine registrierte Entscheidung.

3. Erwartetes Ergebnis

• docs/DECISIONS.md: eine Zeile oder ein Absatz pro Entscheidung, mit Datum, wer entschieden hat, dem wörtlichen Satz, dem offenen Posten oder Commit, in dem sie angewendet wurde, und ob sie „durch Unterlassung“ war.
• In der Spezifikation jedes betroffenen offenen Postens: die Regel mit ihrer Entscheidung und ihrem Datum.
• In jedem Commit, der eine Geschäftsregel umsetzt: der Ursprungssatz.

4. Vollständigkeitsprüfung

• Öffne drei Commits, die Geschäftsregeln berühren: zitiert jeder, wer entschieden hat und wann?
• Gibt es unbestätigte Entscheidungen „durch Unterlassung“? Bestätige sie oder mach sie rückgängig; lass sie nicht liegen.
• Gibt es eine Regel im System, die du nicht als deine erkennst? Wenn ja, hat der Agent sie erfunden: das ist ein Versagen des Schritts, wird als offener Posten geschrieben und geprüft.
• Sind die Sätze wörtlich oder vom Agenten „verbessert“? Es müssen deine sein.

5. Warnsignale

• Eine Arbeitswoche ist vergangen und das Entscheidungsregister ist nicht gewachsen. Entweder war die Arbeit rein mechanisch (selten) oder der Agent hat allein entschieden.
• Die registrierten Entscheidungen sind alle im selben polierten Stil verfasst. Es sind Paraphrasen des Agenten, nicht deine Worte.
• Ein Nutzer des Systems fragt „warum tut es das?“ und niemand findet die Entscheidung.

Schritt 7 — Messen vor dem Bauen, mit einem Instrument, das ebenfalls geprüft wird (Schrittvertrag)

Abschnitt: Schleife. Wann: jedes Mal, wenn ein offener Posten von einer Zahl oder einer Ursachenhypothese abhängt, BEVOR gebaut wird. Im Start ist die Dimensionierung der erste Fall. In einem kleinen Projekt heißt „messen“: mit einem Befehl zählen und die Zahl mit dem Datum notieren. Form: ein einziger Durchgang pro Messung; manchmal ein Gespräch, wenn die Hypothese deine ist. Größe: proportional. Die Ratsche und das Abfragebudget sind für Systeme mit Volumen. Was sich mit der Größe nicht ändert: keine Zahl, die etwas entscheidet, stammt aus einem Eindruck.

Wozu er dient

Sorg dafür, dass jede Zahl, die eine Entscheidung speist, aus einem Programm mit Test stammt und nicht aus einer Textsuche, einem Eindruck oder einem „ich glaube, es sind so an die hundert“. Und sorg dafür, dass das Instrument selbst auditiert wird, denn Messgeräte lügen: eines von meinen sah 84 Aufrufe nicht, mit dem Zähler auf null, und ein anderes sagte 27, wo es 44 waren Ref. 35, Ref. 36. Die fünf Regeln, die ich danach geschrieben habe, sind: Messgerät mit Schutz; wenn das Instrument nicht existiert, wird es gebaut; es wird in zwei Richtungen auditiert; das Näherungsweise wird markiert; und wer ausführt, verifiziert die Zahlen dessen, der geplant hat.

Dieser Schritt ist der, den ich am spätesten formalisiert habe, und aus einem Grund, der es wert ist, erzählt zu werden: ich ging davon aus, dass ein Modell etwas so Grundlegendes der Ingenieurs- kunst wie „miss, bevor du anfasst“ von allein anwenden würde. Tut es nicht. Das Modell ist sehr gut darin, Behauptungen mit Zahl zu produzieren („es gibt etwa 120 Schleifen dieser Art“), und diese Behauptungen klingen exakt gleich, wenn sie gemessen sind und wenn sie geschätzt sind. Du hast keine Möglichkeit, sie am Tonfall zu unterscheiden. Die einzige Art ist, das Instrument zu verlangen: „womit hast du das gemessen? zeig mir den Befehl“. Wenn es keinen Befehl gibt, ist es ein Eindruck, so viele Nachkommastellen er auch hat. Die Regeln habe ich in der Sitzung durchgesetzt, indem ich den Agenten korrigierte, bevor sie Doktrin wurden Ref. 45.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Hypothese, deine oder die des Agenten: „ich glaube, das Problem ist X“, „es müssten so an die hundert sein“.
• Zugang zu dem, was gemessen werden soll: der Code, die Datenbank nur lesend, das Log.
• Die Messgeräte, die es im Repository schon gibt, falls vorhanden.

2. Prompts

Zu Beginn:

Was ich hier verlange, Klausel für Klausel: das Messgerät im Repository (keinen losen Befehl, der verloren geht); den Test des Messgeräts gegen einen bekannten Fall (den Schutz); die Vollständigkeitsklausel in ihrer Form fürs Messen (um den Zugang bitten, nicht stillschweigend annähern); das Näherungsweise mit seiner Toleranz markieren; die Zahl mit dem Befehl, der sie erzeugt, damit du ihn ausführen kannst; das Audit in zwei Richtungen, das meine zwei lügenden Messgeräte entlarvt hat; und die Reihenfolge: erst messen, dann vorschlagen.

Wenn es ein Budget gibt:

Was ich hier verlange: dass das Budget das Gemessene plus wenig ist, keine runde Zahl, und dass es einen Test hat, der fehlschlägt, wenn es überschritten wird. So taucht eine Leistungsregression in der Batterie auf und nicht in der Produktion Ref. 37.

Wenn derjenige, der geplant hat, Zahlen geliefert hat (Regel fünf):

Was ich hier verlange: dass derjenige, der ausführt, den Zahlen dessen, der geplant hat, nicht vertraut, auch wenn es dasselbe Modell in einer anderen Sitzung ist. In meinem Fall waren drei von vier Behauptungen des Plans falsch; wo es ein Instrument gab, war die Zahl exakt.

3. Erwartetes Ergebnis

• Das Messgerät im Repository (tools/measure_*.py, scripts/meter-*.mjs oder ähnlich), mit seinem Test.
• Die Zahl, mit dem Befehl, der sie erzeugt, und dem Datum.
• Das Audit in zwei Richtungen, in zwei oder drei Zeilen geschrieben.
• Das Näherungsweise als solches markiert, mit seiner Toleranz.
• Wenn es ein Budget gibt: der Wert, die Marge und der Test, der es schützt.
• Im Commit: "measured: [number] with [meter]".

4. Vollständigkeitsprüfung

• Kannst du den Befehl des Messgeräts selbst ausführen, und er gibt dir dieselbe Zahl? (Du führst ihn aus; du musst ihn nicht verstehen, nur ausführen.)
• Hat das Messgerät einen Test? Gegen welchen bekannten Fall?
• Gibt es im Bericht eine Zahl ohne Messgerät dahinter? Frag, woher sie stammt.
• Ist das Näherungsweise markiert?
• Wenn der Plan Zahlen mitbrachte: hat der Agent sie vor dem Ausführen verifiziert und dir gesagt, welche nicht stimmten?

5. Warnsignale

• Eine Zahl hat sich zwischen zwei Berichten geändert, ohne dass sich der Code geändert hat. Eine der beiden wurde nicht gemessen.
• Das Messgerät liefert null. Es ist fast nie null; fast immer sieht das Messgerät etwas nicht.
• Der Agent schlägt vor, „während des Messens“ zu bauen, um Zeit zu gewinnen. Die Reihenfolge ist die Methode: erst die Zahl, dann der Plan.

Schritt 8 — Tests als Sperren, rot bewiesen (Schrittvertrag)

Abschnitt: Schleife. Wann: mit jedem offenen Posten, beim Schließen: der Test in Rot und in Grün, die Regression der Nachbarn und der Ende-zu-Ende-Test des berührten Flusses. Die vollständige Ende-zu-Ende-Batterie aller Flüsse beim Abschluss jedes Blocks und vor jedem Deployment in die Produktion. Form: ein einziger Durchgang; der Agent führt aus und berichtet, du liest den Bericht. Größe: verpflichtend in jedem Projekt. Es ist das Herz der Methode: wenn es einen Schritt gibt, der nicht verhandelbar ist, dann dieser.

Wozu er dient

Von einem Test, den du nie hast fehlschlagen sehen, weißt du nicht, ob er etwas beweist. Die Regel hier lautet nicht „schreib Tests“: sie lautet „beweise, dass der Test gegen den alten Code rot wird, und danach grün mit dem neuen“. Das verhindert die Tests, die bestehen, weil sie nichts prüfen, und das Grün, das einen Bug versteckt Ref. 44.

Warum das mit einem Modell wichtiger ist als mit einem menschlichen Programmierer: das Modell schreibt den Code und den Test in derselben Sitzung, mit demselben Verständnis. Wenn es die Anfrage falsch verstanden hat, wird der Test prüfen, was es verstanden hat, und er wird bestehen. Das Rot gegen den alten Code ist die einzige billige Art zu prüfen, dass der Test auf das schaut, was zählt: wenn der alte Code ihn besteht, unterscheidet der Test das Vorher nicht vom Nachher, und dann taugt er nichts. Der Fall, der das am besten zeigt, ist der der Zähler, die nicht übereinstimmten Ref. 26.

Es gibt einen ernsten Einwand gegen diesen Schritt, und ich will ihn aufgeschrieben lassen, denn man wird ihn gegen die Methode verwenden: derselbe Agent, der den Test und den Code schreibt, kann das Rot vortäuschen. Eine im August 2026 veröffentlichte Studie hat gemessen, dass ein Agent, wenn man ihm den Zyklus „erst der Test“ abverlangt, das Rot manchmal auslässt, es erzählt, ohne es laufen gelassen zu haben, oder vor dem Test implementiert, damit er von Anfang an besteht (das steht in Teil F des Hauptdokuments, dem über die verwandten Arbeiten). Meine Antwort hat drei Teile, und alle drei stehen in der Leiter. Der erste, hier: das Rot ist keine Erzählung, es ist ein Beleg: der exakte Befehl, die Kennung der Version, gegen die er lief, die Zahl der fehlschlagenden Tests und der Exit-Code, alles so eingefügt, wie es herauskam, sodass du es mit einem einzigen Befehl noch einmal laufen lassen kannst, ohne zu verstehen, was es tut. Der zweite, in Schritt 13: das Audit durch eine andere Sitzung lässt eine Stichprobe dieser Belege noch einmal laufen. Der dritte, in Schritt 9: die Mutationstests, die absichtlich Fehler einpflanzen und zählen, wie viele davon die Tests fangen; es ist das einzige Maß, das in derselben Studie die Tests, die wachen, von denen unterschieden hat, die dekorieren.

Und die zweite Hälfte: die Ende-zu-Ende-Tests. Ein Test, der vom Bildschirm aus prüft (klickt, tippt, liest) und die Wirkung im Backend kontrolliert (die Zeile ist da, der Zustand hat sich geändert), ist der, der deine Lektüre des Codes ersetzt. Die Abnahmekriterien des offenen Postens („gegeben, wenn, dann“) sind sein Drehbuch. Und sie laufen dreimal, in drei Maßstäben: der berührte Fluss mit jedem offenen Posten, alle Flüsse beim Abschluss jedes Blocks, und alle Flüsse mit der exakten Version vor der Produktion.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die bereits umgesetzte Änderung (standardmäßig kommen die Tests nach der Umsetzung; „erst der Test“ bleibt als Option für kleine, gut abgegrenzte Umfänge).
• Der offene Posten, der die Änderung auslöst, mit seinen Abnahmekriterien und seinem „wie wird geprüft“.
• Die bestehende Batterie und der Befehl, sie auszuführen (Schritt 4).

2. Prompts

Routine (gehört in die Arbeitsvereinbarung; gilt bei jeder Änderung):

Das Rot des ersten Blocks. Im ersten Block eines neuen Projekts gibt es keinen vorherigen Code: der neue Test schlägt fehl, weil das Modul nicht existiert, und dieser Fehlschlag beweist nicht, dass der Test Verhalten unterscheidet. Deshalb wird, wenn die vorherige Version das Modul nicht hat, das Rot durch Mutation bewiesen: der Agent pflanzt absichtlich einen Fehler in die gerade geschriebene Funktion, zeigt den Test rot gegen diesen Fehler (der Beleg trägt den Diff des Fehlers, damit du siehst, dass er nicht trivial war), macht ihn rückgängig und zeigt das Grün. Ein Mutant pro offenem Punkt, ausgeführt und aufgezeichnet wie jeder andere Beleg; Mutationstests über die ganze Codebasis bleiben die optionale Verstärkung der Stufe 9. (Entscheidung D-037, aus der Übung Turnera: sechs rote Belege, die nur "die Datei lädt nicht" sagten.)

Was ich hier verlange, Klausel für Klausel: (1) den Test, geführt von den Abnahmekriterien des offenen Postens; (2) das bewiesene Rot als Beleg (Befehl, Version, Zahlen, Exit-Code), die Klausel, die diese Methode von „schreib Tests“ unterscheidet und die verhindert, dass das Rot eine Erzählung bleibt; (3) das Grün; (4) die Regression der Nachbarn in derselben Sitzung, denn eine Änderung bricht Dinge nebenan; (5) den Ende-zu-Ende-Test des berührten Flusses, mit der Wirkung im Backend vor Augen; (6) nicht ausgerechnet das simulieren, was geprüft wird; und die Vollständigkeitsklausel, angepasst an diesen Schritt: wenn etwas fehlt, um Ende zu Ende zu testen, darum bitten, nicht simulieren. Die Commit-Nachricht mit den Zahlen hinterlässt den Beleg dort, wo der Code lebt.

Beim Abschluss jedes Blocks und vor jedem Deployment in die Produktion:

Was ich hier verlange: den zweiten und dritten Maßstab der Ende-zu-Ende-Tests, mit der exakten Version (nicht „der neuesten“), mit der Wirkung im Backend pro Fluss, und mit der Vollständigkeitsklausel: was nicht abgedeckt ist, wird erklärt und wird zum offenen Posten, es geht nicht als abgedeckt durch.

Wenn der Agent sagt, dass sich etwas nicht testen lässt:

Was ich hier verlange: dass „lässt sich nicht testen“ nicht das Ende des Gesprächs ist, sondern der Anfang eines offenen Postens. Nicht-Testbarkeit ist Schuld, und Schulden werden registriert.

3. Erwartetes Ergebnis

• Der neue Test im Repository, benannt nach dem offenen Posten, den er schließt.
• Im Bericht des Agenten und in der Commit-Nachricht: die rote Ausgabe als Beleg (der Befehl, die Version, gegen die er lief, wie viele fehlschlagen, der Exit-Code), die grüne Ausgabe und die grüne Regression mit ihren Zahlen.
• Der Ende-zu-Ende-Test des berührten Flusses, mit dem Beleg, dass sich das Backend geändert hat (die Zeile, der Eintrag, der Zustand).
• Beim Abschluss jedes Blocks und vor der Produktion: die vollständige Ende-zu-Ende-Batterie in Grün, pro Fluss, mit der exakten Version.

4. Vollständigkeitsprüfung

• Zeigt der Bericht das Rot? Mit Zahlen: „4 von 8 schlagen gegen das alte Kriterium fehl“. Wenn er nur Grün zeigt, ist der Schritt nicht erklommen.
• Ist das Rot ein Beleg oder eine Erzählung? Es muss den exakten Befehl, die Version, gegen die er lief, die Zahlen und den Exit-Code enthalten. Einmal pro Block wähl einen offenen Posten zufällig aus und lass diesen Befehl selbst laufen: das Rot muss wieder erscheinen.
• Lief die Regression in derselben Sitzung? Wie viele Tests, wie viele grün?
• Gibt es einen „simulierten“ Teil (Mock) genau dort, wo die Änderung ist? Frag den Agenten, was er simuliert hat und warum.
• Zitiert der Commit den offenen Posten und sagt „rot bewiesen“?
• Prüft der Bildschirmtest auch die Wirkung im Backend?
• Beim Abschluss des Blocks: sind alle Flüsse in der Ende-zu-Ende-Batterie, oder gibt es einen, der „durch die Unit-Tests abgedeckt wird“?

5. Warnsignale

• Alle neuen Tests der Woche waren auf Anhieb grün, und nie wurde ein Rot gezeigt. Entweder lässt der Agent den Schritt aus oder die Tests prüfen nichts.
• Die Batterie dauert immer länger und niemand weiß, warum. Meist wurden die Ende-zu-Ende-Tests nach und nach durch Simulationen ersetzt, „damit es schnell läuft“.
• Der Agent berichtet „die Tests bestehen“, ohne zu sagen, wie viele. Immer mit Zahlen.
• Das Rot kommt in Prosa erzählt („der Test ist wie erwartet fehlgeschlagen“), ohne Befehl, ohne Version und ohne Zahlen. Ein Rot ohne Beleg ist so viel wert wie keines.
• Du kommst zur Produktionsfreigabe und die vollständige Ende-zu-Ende-Batterie läuft zum ersten Mal. Die Blockabschlüsse haben gefehlt.

Schritt 9 — Maschinell verifizierte Code-Qualität, mit Tor (Schrittvertrag)

Abschnitt: Schleife. Wann: wird einmal aufgebaut, beim Öffnen des ersten Funktionsblocks (sobald der Start fertig ist), und läuft von da an allein bei jedem Commit, als Tor der Continuous Integration; jeder offene Posten wird mit der Qualität in Grün geschlossen, nach dem roten Test (8) und vor dem manuellen Testfall (10). Beim Abschluss jedes Blocks und vor jedem Deployment wird der Qualitätsbericht mit dem Eigentümer gelesen. In einem Altsystem ist der erste Lauf die Basislinie, und die Funde kommen mit ihrer Geschwindigkeitsmarke ins Backlog. Form: ein einziger Durchgang zum Aufbauen; danach Routine bei jeder Änderung und Lektüre pro Block. Größe: verpflichtend in seinem Mindestniveau in jedem Projekt (ein Linter und eine Größenbeschränkung in der Kette); vollständig, Mutationstests eingeschlossen, in jedem Projekt mit Nutzern. Die Mutationstests bleiben nur dann eine optionale Verstärkung, wenn es keine echten Nutzer gibt (ein internes Werkzeug, ein Prototyp, den sonst niemand ausführt).

Wozu er dient

Der Eigentümer liest den Code nicht, und genau das ist der Sinn der Methode. Aber der Code existiert, irgendjemand wird ihn pflegen (der nächste Agent, der nächste Entwickler), und ein Code, der heute funktioniert und morgen unlesbar ist, ist Schuld, die im dritten Monat eingetrieben wird. Wenn ihn niemand liest, muss ihn eine Maschine ansehen: Werkzeuge, die bei jedem Commit messen, was ein menschlicher Prüfer ansehen würde, und es in eine Zahl mit einer Grenze verwandeln. Ich habe das in all meinen Projekten gemacht, ohne es Schritt zu nennen, und ein Qualitätsaudit brachte mir eine Komponente mit mehr als zweitausend Zeilen und eine Projektdatei mit fast zehntausend zurück Ref. 41: keine von beiden hätte eine geschriebene Größenbeschränkung bestanden. Die statische Ratsche, die verhindert, dass eine Qualitätszahl schlechter wird Ref. 35, ist die Form, die ich diesem Schritt gebe.

Was maschinell gemessen wird, nach Wichtigkeit geordnet: dass der Code einen einzigen Stil achtet (der Linter und der Formatierer); dass keine Funktion und keine Datei eine Größe überschreitet; dass die Komplexität jeder Funktion unter einer Grenze bleibt; dass es keinen duplizierten und keinen toten Code gibt; dass die Abhängigkeiten deklariert und benutzt sind; dass die Abdeckung der Tests nie sinkt (die Ratsche); und, wenn die Sprache es erlaubt, dass die Typen aufgehen. Nichts davon ersetzt den roten Test: ein makelloser Code kann falsch sein. Was es verhindert, ist der korrekte Code, den niemand mehr anfassen kann.

Und das, was ich in jedem Projekt mit Nutzern nicht mehr als optionale Verstärkung behandle: die Mutationstests. Ich hatte sie in einer früheren Version dieses Dokuments als „optional, empfohlen“ belassen, und eine externe Bewertung der Methode machte mich auf den Widerspruch aufmerksam: Wenn Teil F sagt, dass die Mutation, soweit ich weiß, das einzige Maß ist, das in den Studien von 2026 die Tests, die beweisen, von denen unterschied, die nur dekorieren, ergibt es keinen Sinn, sie ausgerechnet in den Projekten aus dem „Vollständig“ auszulassen, in denen ein dekorativer Test mehr jemandem schadet. Ein Werkzeug pflanzt absichtlich Fehler in den Code (ändert ein „größer“ in „größer oder gleich“, löscht eine Zeile, kehrt eine Bedingung um) und lässt die Tests laufen; jeder Fehler, den die Tests nicht fangen, ist ein überlebender Mutant, und der Anteil der gefangenen ist die Punktzahl. Es ist das Maß, das das bewiesene Rot aus Schritt 8 ergänzt: das Rot beweist, dass ein Test die Änderung von heute bewacht; die Mutation misst, wie viel die ganze Batterie bewacht. Und es ist, soweit ich weiß, das einzige, das in den Studien von 2026 die Tests, die prüfen, von denen unterschieden hat, die dekorieren (Teil F des Hauptdokuments).

Wenn du Anfänger bist. Ein Linter ist ein Programm, das den Code liest und markiert, was schlecht geschrieben oder gefährlich ist (eine Variable, die nicht benutzt wird, ein Vergleich, der immer dasselbe ergibt), wie die Rechtschreibprüfung einer Textverarbeitung. Ein Formatierer rückt ihn in einem einzigen Stil zurecht (Einrückungen, Leerzeichen), damit der ganze Code aussieht, als hätte ihn dieselbe Hand geschrieben. Die Komplexität einer Funktion ist, wie viele verschiedene Wege sie nehmen kann (jedes „wenn“ erhöht sie); eine Funktion mit vierzig Wegen versteht niemand. Duplizierter Code ist derselbe Block, an zwei Stellen kopiert: an dem Tag, an dem man den einen repariert, bleibt der andere kaputt. Die Abdeckung ist, welcher Prozentsatz des Codes von irgendeinem Test ausgeführt wird. Und eine Ratsche ist ein Mechanismus, der nur Verbesserung zulässt: die Zahl von heute ist der Boden von morgen. Die Mutationstests sind ein Programm, das den Code absichtlich kaputt macht, mit je einer kleinen Änderung auf einmal, und schaut, ob irgendein Test es merkt; wenn keiner es merkt, ist dieses Stück Code nicht bewacht.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Continuous Integration, die bei jedem Push läuft (Schritt 4).
• Der erste Funktionsblock geöffnet, mit mindestens einem gebauten offenen Posten: ohne Code gibt es keine Qualität zu messen.
• Deine Entscheidung über die Grenzen, oder die Bereitschaft, die anzunehmen, die der Agent mit Begründung vorschlägt.
• Das vorherige Audit (13, oder N3 in einem Altsystem), falls es eines gab.

2. Prompts

Zu Beginn (das Tor aufbauen):

Was ich hier verlange: die fünf Prüfungen, die ein menschlicher Prüfer machen würde, maschinell gemacht und mit dem roten Build als Konsequenz, denn eine Prüfung, die nicht blockiert, ist ein Ratschlag; die Grenzen mit ihrem gemessenen Wert, damit die Grenze aus der Zahl kommt und nicht aus einer Meinung; die Abdeckungs-Ratsche, die das Stück ist, das verhindert, dass die Qualität von allein verfällt; und noch nichts zu reparieren, denn in einem System mit bereits geschriebenem Code ist der erste Lauf immer rot, und die Entscheidung, was jetzt repariert und was mit Datum toleriert wird, ist meine.

Routine (kommt in die Arbeitsvereinbarung):

Was ich hier verlange: dass die Qualität Teil des Abschlusses jedes offenen Postens ist und keine getrennte Aufgabe; das Verbot, sie zum Schweigen zu bringen (ein Modell vor einem roten Linter neigt dazu, die Ausnahme hinzuzufügen, statt zu reparieren, weil das schneller geht) und die Grenze anzuheben; und die Lektüre pro Block, die der einzige Moment ist, in dem du die Zahlen ansiehst.

Verpflichtend in jedem Projekt mit Nutzern (optional nur ohne echte Nutzer): Mutationstests.

Was ich hier verlange: das Maß, das die Abdeckung nicht gibt (die Abdeckung sagt, welcher Code ausgeführt wurde; die Mutation sagt, welcher Code bewacht ist); den Umfang, beschränkt auf die geänderten Zeilen, was dafür sorgt, dass sich die Kosten bei jedem offenen Posten bezahlen lassen; noch nichts zu reparieren, denn zu entscheiden, welcher Mutant zählt, ist meine Sache; und die Punktzahl beim Abschluss jedes Blocks, neben der Abdeckung, mit einem Rückgang, der als Rot behandelt wird.

3. Erwartetes Ergebnis

• Der Linter, der Formatierer, die Grenzen, die Erkennung von Duplizierung und totem Code, die Abdeckung mit Ratsche und die Typen, laufend bei jedem Push und rot, wenn es sein muss.
• docs/CODE_QUALITY.md mit Werkzeugen, Konfiguration, Grenzen mit gemessenem Wert, und der Liste dessen, was fehlschlägt, mit seinem offenen Posten oder seinem Datum.
• Das Tor in docs/GATES.md und die Routine in der Vereinbarung.
• In jedem Projekt mit Nutzern: die Mutationspunktzahl in docs/CODE_QUALITY.md, pro Block, neben der Abdeckung, und ein offener Posten für jeden überlebenden Mutanten in Code, der zählt.

4. Vollständigkeitsprüfung (die machst du, ohne Code zu lesen)

• Verlang den Link zum letzten Lauf der Kette: ist die Qualität grün?
• Verlang, dass er absichtlich, in einem Zweig, eine Funktion mit hundert Zeilen und eine ungenutzte Variable einbaut: wird die Kette wegen beider Dinge rot?
• Ist die Abdeckung von heute größer oder gleich der beim Abschluss des vorherigen Blocks? Verlang beide Zahlen.
• Gibt es irgendeine Linter-Ausnahme im Code? Verlang die Liste; jede muss eine geschriebene Begründung haben.
• Ist seit dem ersten Lauf irgendeine Grenze angehoben worden? Mit welcher Begründung und wer hat das entschieden?
• Wenn das Projekt echte Nutzer hat: laufen die Mutationstests? Wenn nicht, welche geschriebene Begründung rechtfertigt, sie nicht zu haben?
• Wenn es Mutationstests gibt: wie viele Mutanten haben im letzten Block überlebt, und hat jeder einen offenen Posten oder eine geschriebene Begründung?

5. Warnsignale

• Die Qualität war auf Anhieb grün über bereits geschriebenem Code. Das stimmt fast nie: die Grenzen sind viel zu locker.
• Der Agent schlägt vor, „diese Regel abzuschalten, weil sie zu streng ist“. Manchmal hat er recht; immer muss es über dich gehen, mit geschriebener Begründung.
• Die Abdeckung steigt, weil Tests hinzugefügt wurden, die nichts prüfen (das Grün, das einen Bug versteckt, Schritt 8). Die Ratsche misst Menge; das bewiesene Rot misst Qualität. Sie gehören zusammen.
• Eine Datei ist bis an die Grenze gewachsen und wurde in zwei Dateien mit demselben Inhalt geteilt. Das ist Duplizierung, als Einhaltung verkleidet.
• Die Abdeckung ist hoch und die Mutationspunktzahl niedrig. Das sind Tests, die den Code ausführen, ohne etwas zu prüfen: genau der Fall, den das bewiesene Rot aus Schritt 8 verhindern will.
• Das Projekt hat echte Nutzer, und niemand hat die Mutationstests laufen lassen oder aufgeschrieben, warum nicht. „Es ist optional“ ist für ein Projekt mit Nutzern keine gültige Begründung mehr.

Schritt 10 — Die manuellen Testfälle werden zusammen mit der Funktionalität geschrieben, und Menschen führen sie aus (Schrittvertrag)

Abschnitt: Schleife. Wann: bei jedem offenen Posten, beim Schließen, nach dem roten Test (8) und nach der Qualität (9): der Agent schreibt die manuellen Testfälle des Flusses, den er berührt hat. Sie werden von Menschen in drei Momenten ausgeführt: beim Abschluss jedes Blocks (die menschlichen Tests), vor dem ersten Deployment in die Produktion (die Abnahmetests mit dem Eigentümer) und nach jedem Deployment, in einem nur lesenden Durchgang. Jede Ausführung, die fehlschlägt, speist eine Anforderung als korrektiven offenen Posten in die Schleife zurück. Form: Routine bei jedem offenen Posten; danach menschliche Ausführung pro Zyklus. Größe: verpflichtend in jedem Projekt mit Nutzern: der manuelle Testfall ist der einzige Test, den das Modell weder schreibt noch ausführt.

Wozu er dient

Die Methode hat automatische Tests im Überfluss: den roten Test, die Regression, das Ende zu Ende in drei Maßstäben. Alle schreibt und alle lässt das Modell laufen, und alle prüfen das, was das Modell verstanden hat. Es fehlt der Test, den eine Person mit ihren eigenen Augen und ihren eigenen Händen macht, einem geschriebenen Drehbuch folgend, und der findet, was kein Test findet: den Knopf, der dort ist, wo er nicht hingehört, die Meldung, die man nicht versteht, den Fluss, der technisch läuft und menschlich nichts taugt. Der menschliche Blick und die menschlichen Tests standen schon in der Zeitlinie; was fehlte, war, dass sie ein Drehbuch haben, und dass dieses Drehbuch derselbe schreibt, der die Funktionalität gebaut hat, im selben Moment, aus den Abnahmekriterien des offenen Postens. Ohne Drehbuch ist der menschliche Test „spiel ein bisschen mit dem System“, und was gefunden wird, hängt von der Tageslaune ab. Mit Drehbuch wird er jedes Mal gleich ausgeführt, es wird festgehalten, was passiert ist, und was fehlschlägt, kehrt als Anforderung in die Schleife zurück. Das ist der Schluss des Kreises, den das Prozessbild zeigt: die manuelle Ausführung der Testfälle speist Anforderungen in die Entwicklung zurück.

Ein manueller Testfall hat immer dieselbe Form: eine Kennung; der offene Posten, aus dem er stammt; die Vorbedingung (was vorher existieren muss: ein Patient, ein Termin von gestern); die Schritte, nummeriert, jeder mit dem, was die Person tut, und dem, was sie sehen muss; das erwartete Ergebnis am Schluss, einschließlich der Wirkung im Backend, die eine Person verifizieren kann (ein Datensatz, der erscheint, eine Nachricht im falschen Postfach); die zu benutzenden Testdaten; und der Platz für das Ergebnis jeder Ausführung: Datum, wer, bestanden oder fehlgeschlagen, Anmerkung.

Wenn du Anfänger bist. Ein manueller Testfall ist ein Rezept, damit eine Person eine Funktionalität prüft: was vorzubereiten ist, was Schritt für Schritt zu tun ist, und was bei jedem Schritt passieren muss. Er wird so geschrieben, dass ihm jeder gleich folgen kann, ohne zu wissen, wie das System gemacht ist. Einen Fall auszuführen heißt, dem Rezept zu folgen und zu notieren, ob er bestanden hat oder fehlgeschlagen ist. Vorbedingung ist das, was vor dem Anfang existieren muss. Und zurückspeisen heißt, dass das, was die Person falsch gefunden hat, als neue Bitte auf die Liste der offenen Posten zurückkehrt, mit ihren Worten.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Der offene Posten, der gerade geschlossen wird, mit seinen Abnahmekriterien „gegeben, wenn, dann“ (Schritt 5): sie sind der Rohstoff des Falls.
• Die Testumgebung mit Daten, damit man den Schritten wirklich folgen kann.
• Wer die Fälle ausführen wird (der Eigentümer, ein Nutzer des Vertrauens) und wann (Abschluss des Blocks, Abnahme, nach jedem Deployment).

2. Prompts

Routine bei jedem offenen Posten (kommt in die Arbeitsvereinbarung):

Was ich hier verlange: dass der Fall aus den Abnahmekriterien kommt (so prüft er, was verlangt wurde, und nicht, was das Modell verstanden hat); dass er für jemanden geschrieben ist, der nicht weiß, wie das System funktioniert, was der Unterschied zwischen einem Testfall und einer technischen Notiz ist; dass er die von einer Person verifizierbare Wirkung im Backend enthält, damit der manuelle Test auch auf die andere Seite des Bildschirms schaut; dass die Fälle im selben Commit gepflegt werden, genau wie die Dokumentation; und dass das Modell sie nie ausführt, denn vom Modell ausgeführt sind sie ein weiterer Test, und der Witz ist, dass eine Person sie ausführt.

Für eine Ausführung (Abschluss eines Blocks, Abnahme, nach einem Deployment):

Was ich hier verlange: die Rückspeisung, operativ gemacht: jeder menschliche Fehlschlag ist ein korrektiver offener Posten, mit den Worten der Person (nicht denen des Modells) als Reproduktion, und am Baum aufgehängt; den Vergleich mit der vorherigen Ausführung, der dir sagt, ob das System zwischen den Blöcken besser oder schlechter wird; und die Unterscheidung zwischen „der Fall ist schlecht geschrieben“ und „das System ist schlecht“, denn das sind zwei verschiedene offene Posten.

3. Erwartetes Ergebnis

• docs/MANUAL_TESTS.md mit einem Fall pro Fluss, den jeder geschlossene offene Posten berührt hat, im Format, für eine Person geschrieben.
• Die festgehaltenen Ausführungen, mit Datum und wer, in jedem Zyklus.
• Ein korrektiver offener Posten pro Fehlschlag und pro Anmerkung.
• Die Routine in der Vereinbarung.

4. Vollständigkeitsprüfung (die machst du, ohne Code zu lesen)

• Nimm einen beliebigen Fall und folg ihm selbst in der Testumgebung, ohne den Agenten etwas zu fragen: hast du es geschafft? Wenn du fragen musstest, ist der Fall nicht für eine Person geschrieben.
• Hat jeder geschlossene offene Posten, der einen Bildschirm berührt, seinen Fall? Verlang die Liste der Posten ohne Fall.
• Sagt der Fall, welche Wirkung auf der anderen Seite des Bildschirms zu verifizieren ist, und wie eine Person sie verifiziert?
• Hat die letzte Ausführung bei jedem Fall Datum und Namen? Gibt es ein „bestanden“ ohne Datum?
• Hat jeder Fehlschlag der letzten Ausführung seinen offenen Posten, mit den Worten der Person?

5. Warnsignale

• Der Agent hat die Fälle als ausgeführt markiert. Er hat sie ausgeführt, und das ist dasselbe, wie sie nicht auszuführen.
• Die Fälle sind Kopien des automatischen Tests in Prosa. Ein manueller Fall muss ansehen, was der Test nicht ansieht: was man sieht, was man versteht, was stört.
• Alle Fälle bestehen in allen Ausführungen. Menschen finden immer etwas; wenn sie nichts finden, folgen sie dem Drehbuch nicht, oder das Drehbuch verlangt nicht hinzusehen.
• Die Fehlschläge werden „im Moment repariert“, ohne offenen Posten. Die Worte der Person gehen verloren und auch die Spur davon, was sich wiederholt hat.

Schritt 11 — Symmetrie zwischen Produzent und Konsument, und das Register der Anti-Muster (Schrittvertrag)

Abschnitt: Schleife. Wann: mit jedem offenen Posten, der einen Vertrag zwischen zwei Teilen des Systems berührt. Die Vertragskarte wird beim Öffnen des zweiten Funktionsblocks gebaut, wenn es schon Bildschirm und Server gibt. Das Register der Anti-Muster wächst jedes Mal, wenn etwas zum zweiten Mal bricht. Form: automatisch innerhalb der Schleife; plus eine Datei, die mit jedem Rückschlag wächst. Größe: die Symmetrie ist immer verpflichtend; die Produzent/Konsument-Karte ist in einem Projekt mit einem einzigen Modul optional und verpflichtend, sobald es einen Bildschirm und einen Server getrennt gibt.

Wozu er dient

Wenn du ein Ende änderst (den Server, den Roboter, das Datenbankschema), sorg dafür, dass das andere Ende (der Bildschirm, der Zähler, der Konsument) sich im selben Commit ändert. Sonst driften sie früher oder später auseinander, und der Nutzer sieht auf der einen Seite eine Zahl und auf der anderen eine andere Ref. 26. Und die Fehler, die du schon einmal bezahlt hast, schreib auf, um sie nicht zweimal zu bezahlen Ref. 2.

Das allgemeine Prinzip dahinter, das ich bei der Krankenkasse durchgesetzt habe und das für jedes System gilt Ref. 27: jede Liste hat einen einzigen Eigentümer. Die Spalten einer Tabelle, die möglichen Zustände eines Auftrags, die Gründe, warum etwas wartet: ein einziger Teil des Systems (der Produzent) definiert sie, und alle anderen lesen sie von dort. Sobald es zwei Kopien derselben Liste gibt, ist eine veraltet; man weiß nur noch nicht, welche. Der semantische Baum von Schritt 2 ist der erste Ort, an dem diese Listen deklariert werden: die Zustände einer Entität stehen dort, und der Code muss sie aus einer einzigen Quelle lesen.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Eine Karte, welche Teile des Systems was konsumieren: welche Bildschirme welche Dienste lesen, welche Prozesse welche Tabellen schreiben. Wenn sie nicht existiert, baut der erste Prompt sie.
• Das Register der Anti-Muster docs/GOTCHAS.md, auch wenn es leer ist.

2. Prompts

Zum Bauen der Karte (einmal):

Was ich hier verlange: das Inventar der Verträge mit ihren zwei Seiten, und die Vollständigkeitsklausel in ihrer Form für diesen Schritt: was nicht gesehen wird, wird erklärt, nicht weggelassen. Eine Karte mit versteckten Löchern ist schlimmer als keine Karte.

Routine (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: die Symmetrie als Reflex (die andere Seite suchen, bevor geschlossen wird), die Regel der Liste mit einem einzigen Eigentümer, und dass die Karte sich von selbst pflegt, während sie benutzt wird.

Wenn etwas zum zweiten Mal bricht:

Was ich hier verlange: das feste Format eines Anti-Musters (Geruch, Grundursache, Behebung, Früherkennung) und vor allem die automatische Prüfung: ein notiertes, aber nicht automatisiertes Anti-Muster wird sich wiederholen, wenn die Person oder die Sitzung wechselt.

3. Erwartetes Ergebnis

• docs/PRODUCER_CONSUMER_MAP.md: die Liste der Verträge mit Produzent und Konsumenten.
• In jedem Commit, der einen Vertrag berührt: die Konsumenten aktualisiert, in der Nachricht benannt.
• docs/GOTCHAS.md: ein Eintrag pro Anti-Muster, mit den vier Teilen (Geruch, Grundursache, Behebung, wie man es vorher erkennt), und dem Datum des ersten Mals.

4. Vollständigkeitsprüfung

• Wähl einen Vertrag aus der Karte und bitte den Agenten, dir zu zeigen, wo jeder Konsument ihn liest. Wenn einer seine eigene Kopie der Liste hat, gibt es Schulden.
• Gibt es eine Zahl, die auf zwei verschiedenen Bildschirmen gezeigt wird? Vergleich: stimmen sie überein?
• Hat jeder Eintrag in GOTCHAS die vier Teile?
• Hat sich ein Fehler wiederholt, der schon in GOTCHAS stand? Wenn ja, fehlt die automatische Prüfung.

5. Warnsignale

• Derselbe Wert steht von Hand geschrieben in mehr als einer Datei („AUSSTEHEND“, „GENEHMIGT“ im Server und im Bildschirm). Zwei Kopien; eine wird abweichen.
• Eine Änderung am Server wurde mit grünem Servertest geschlossen und niemand hat den Bildschirm angefasst.
• GOTCHAS hat Einträge ohne den Teil „wie man es vorher erkennt“. Das sind Anekdoten, keine Anti-Muster.

Schritt 12 — Ehrliche Verifikation und verhältnismäßiger Bericht (Schrittvertrag)

Abschnitt: Schleife. Wann: in jedem Bericht, zu jedem offenen Posten, während des ganzen Projekts. Es ist die Form, die alles haben muss, was der Agent dir sagt. Form: Routine; es ist die Form, die jeder Bericht des Agenten haben muss. Größe: verpflichtend in jedem Projekt, ohne Ausnahmen. Es kostet nichts und ist das, was dem Eigentümer erlaubt, keinen Code zu lesen.

Wozu er dient

Wenn du keinen Code lesen wirst, muss der Bericht des Agenten vertrauenswürdig sein. Nicht optimistisch, nicht „dem Anschein nach vollständig“: vertrauenswürdig. Das ist das genuin Neue an der Methode: der Autor des Codes stellt auch die Belege her, und er tut das mit derselben Sicherheit in der Stimme, wenn es richtig ist und wenn es falsch ist. Deshalb muss der Beleg sich selbst beweisen, und der Bericht muss das Verifizierte vom Geglaubten trennen. Die Regel habe ich im Juni geschrieben Ref. 8, und ich habe sie im Oktober wieder gebraucht, als ein Authentifizierungsfehler mit der Aufschrift „success“ gemeldet wurde Ref. 43.

Versteh, warum das Modell dazu neigt, zu viel zu berichten. Es ist keine böse Absicht: es wurde darauf trainiert, nützlich und vollständig zu sein, und ein Bericht, der sagt „das konnte ich nicht verifizieren“, fühlt sich weniger nützlich an als einer, der „erledigt“ sagt. Also verlang ausdrücklich die schlechten Nachrichten, die blinden Flecken und das, was er nicht getan hat. Wenn du es nicht verlangst, gibt er es dir nicht, nicht weil er es verbirgt, sondern weil er es nicht als Teil der Antwort betrachtet.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die erledigte Arbeit und der offene Posten, der sie verlangt hat.
• Die Arbeitsvereinbarung (Schritt 1), die schon verbietet, Nicht-Erledigtes anzukündigen.

2. Prompts

Routine (gehört in die Arbeitsvereinbarung; gilt bei jedem Bericht):

Was ich hier verlange, Klausel für Klausel: die drei Blöcke, die die Struktur sind, die einen Bericht ehrlich macht (das Verifizierte mit seinem Beweis, das Geglaubte mit dem Grund, warum es nicht getestet wurde, das, was er nicht sehen kann); die Abdeckung Punkt für Punkt, damit nichts „vergessen“ wird; den Beweis neben jeder Behauptung; das Verbot des bloßen „erledigt“; und die schlechten Nachrichten zuerst, denn das Modell neigt dazu, sie für den Schluss oder für nie aufzuheben.

Bei einem „ist immer noch kaputt“ von dir:

Was ich hier verlange: dass er bei einem „ist immer noch kaputt“ nicht von null neu diagnostiziert, sondern zuerst Versionen vergleicht. Die Hälfte der „ist immer noch kaputt“ sind Behebungen, die im Repository sind, aber nicht an dem Ort, wo du hinschaust Ref. 45.

3. Erwartetes Ergebnis

Jeder Bericht des Agenten mit:

• Den drei Blöcken (verifiziert / geglaubt / blinde Flecken), auch wenn einer leer ist.
• Einer Zeile pro verlangtem Punkt, mit seinem Status.
• Für jedes „verifiziert“: der Befehl und die Ausgabe, oder der Test und sein Ergebnis, oder die Zahl und ihr Messgerät.
• Dem, was schiefgegangen ist, am Anfang und nicht am Ende.

4. Vollständigkeitsprüfung

• Sind die drei Blöcke da? Wenn „geglaubt“ und „blinde Flecken“ immer leer sind, ist der Agent nicht ehrlich: es gibt immer etwas, das er nicht gesehen hat.
• Wähl nach Zufall eine Behauptung aus dem Block „verifiziert“: hat sie ihren Beweis daneben? Kannst du ihn reproduzieren?
• Deckt er jeden Punkt dessen ab, was du verlangt hast, oder gibt es einen, der „vergessen“ wurde?
• Stehen die schlechten Nachrichten am Anfang?
• Hat er irgendwann einfach nur „erledigt“ gesagt? Das ist ein Verstoß gegen die Vereinbarung.

5. Warnsignale

• Zehn Berichte in Folge ohne einen einzigen blinden Fleck. Niemand sieht alles; der Block ist aus Gewohnheit leer, nicht aus Wahrheit.
• Der Block „verifiziert“ enthält Sätze wie „sollte funktionieren“. Das ist verkleidetes „geglaubt“.
• Der Bericht ist länger als die Änderung. Ein verhältnismäßiger Bericht sagt, was zu sagen ist; ein aufgeblähter verdeckt etwas mit Volumen.

Schritt 13 — Das periodische Audit als Input für den Plan (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: verpflichtend vor dem ersten Deployment in die Produktion; es eröffnet den Abschnitt der Produktionsfreigabe. Danach, im Betrieb, alle ein bis zwei Monate je nach Änderungstempo, und beim Abschluss jeder großen Etappe. Form: ein einziger langer Durchgang, idealerweise an einen anderen Agenten als den, der baut. Größe: verpflichtend vor dem ersten Deployment in die Produktion, in jedem Projekt; danach proportional zum Änderungstempo (ein System, das sich jede Woche ändert, wird jeden Monat auditiert; ein stabiles alle sechs).

Wozu er dient

Schau dir ab und zu das ganze System mit frischen Augen an, und verwandle, was du siehst, in offene Posten. Das Audit ist kein Bericht, der abgelegt wird: es ist Plan. Es verhindert das im Code geschriebene Passwort, das niemand gesehen hatte, die Abfragen, die ganze Tabellen lesen Ref. 18, die bekannte Schwachstelle in einer Abhängigkeit, die Komponente mit tausenden Zeilen Ref. 41. Und es ist die Unabhängigkeit der Qualitätskontrolle, einen Schritt weiter nach innen getragen: wer auditiert, ist nicht der, der gebaut hat.

Zur Unabhängigkeit: es braucht weder eine andere Firma noch ein anderes Werkzeug. Es reicht eine andere Sitzung, mit einer anderen Anweisungsdatei, die am Bau nicht beteiligt war. Was du suchst, ist, dass der Auditor die Annahmen des Bauenden nicht teilt. Ein Modell, das ein Modul gebaut hat, „weiß“, dass das hartkodierte Passwort provisorisch war; ein Modell, das es zum ersten Mal sieht, meldet es als das, was es ist. So wurden zwei Administrator-Türen entdeckt, die der Bauende an einem Tag hinterlassen hatte Ref. 40.

Wenn du wählen kannst, soll es außerdem ein anderes Modell als das des Bauenden sein, nicht nur eine andere Sitzung desselben: eine Studie von 2026 hat gemessen, dass eine saubere Sitzung mit einem anderen Modell mehr Fehler findet als zwei Sitzungen desselben Modells (arXiv 2610.01471). Es ist kein hartes Tor, weil manchmal das Modell des Bauenden das einzig verfügbare ist; es ist eine Präferenz, die es wert ist, ausgeübt zu werden, wenn man kann, und je kritischer das System, desto mehr lohnt es sich.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Das vollständige Repository, nur lesend.
• Die Produktion oder die Testumgebung, nur lesend (Datenbank, Logs).
• Das vorherige Audit, falls es eines gab, um zu messen, was sich geändert hat.
• Der Umfang: Integrität, Sicherheit, Leistung, Codequalität, oder alles.
• docs/PENDING.md mit den im letzten Zyklus abgeschlossenen offenen Posten und ihren Belegen, damit der Auditor auswählen kann, welche er reproduziert.

2. Prompts

Zu Beginn (an einen anderen Agenten als den Bauenden, wenn möglich):

Was ich hier verlange, Klausel für Klausel: nur lesend (der Auditor behebt nicht; er schlägt vor); die Vollständigkeitsklausel in ihrer Form fürs Auditieren: was nicht verifiziert werden konnte, wird erklärt, nicht durch Unterlassung freigegeben; den ganzen Code und nicht eine Stichprobe, denn die schweren Befunde liegen meist dort, wo niemand hinschaut; die wortwörtliche Reproduktion von zwei oder drei Belegen, damit das Audit Beweise verifiziert statt sie nur zu lesen (das ist die Klausel, die die D-033-Lücke schließt: ein erzähltes Rot ist kein auditiertes Rot); jeden Befund mit Ort, Risiko, Beleg und Priorität, damit er umsetzbar ist, ohne den Bericht erneut zu lesen; Noten pro Dimension, zum Vergleich mit dem vorherigen Audit; und die P0 schon in vorgeschlagene offene Posten umgewandelt.

Zum Abschluss (an den Bauenden):

Was ich hier verlange: dass das Audit zu offenen Posten wird (sonst ist es ein Bericht, der abgelegt wird), und dass der Widerspruch explizit und mit Beleg erfolgt, nicht stillschweigend.

3. Erwartetes Ergebnis

• docs/AUDIT_[Datum].md mit: Umfang, was verifiziert werden konnte und was nicht (und warum), den Befunden mit Ort, Risiko, Beleg und Priorität, einer Note pro Dimension, dem Ergebnis der Reproduktion von zwei oder drei Belegen aus dem letzten Zyklus, und der Liste der vorgeschlagenen offenen Posten.
• In docs/PENDING.md: ein offener Posten für jeden P0 und P1, mit Verweis auf den Befund.

4. Vollständigkeitsprüfung

• Sagt der Bericht, was er NICHT verifizieren konnte? Wenn er sagt, er habe alles verifiziert, sei misstrauisch.
• Wähl zwei Befunde: haben sie Datei und Zeile, und einen Beleg, den du reproduzieren kannst?
• Sagt der Bericht, welche Belege er reproduziert hat, mit dem Befehl und dem Ergebnis, oder sagt er nur, er habe sie gelesen?
• Hat jeder P0 seinen offenen Posten, bevor das Audit als abgeschlossen gilt?
• Werden sich die Noten pro Dimension mit dem vorherigen Audit vergleichen lassen?
• Hat derselbe Agent auditiert, der gebaut hat? Wenn ja, verlang einen zweiten Blick auf die P0.

5. Warnsignale

• Das Audit hat keinen einzigen P0 gefunden. In einem System, das älter als drei Monate ist, ist das fast nie wahr; wahrscheinlicher ist, dass der Umfang klein war oder der Auditor die Annahmen teilte.
• Die Befunde haben keine Dateizeile. Das sind Meinungen, keine Befunde.
• Der Bericht sagt, die Belege „wurden überprüft“, ohne den ausgeführten Befehl oder seine Ausgabe zu zeigen. Ein gelesener Beleg und ein reproduzierter Beleg sind nicht dasselbe, und nur der zweite schließt den D-033-Einwand.
• Zwei Wochen sind vergangen und die P0 haben immer noch keinen offenen Posten. Das Audit wurde abgelegt.

Schritt 14 — Fail-closed, Sperren und null stiller Schaden (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: im Abschnitt der Produktionsfreigabe, BEVOR irgendeine Funktionalität gebaut wird, die abbucht, sendet, genehmigt oder löscht; wird mit jeder neuen Aktion mit Konsequenzen überprüft. Neue Automatisierungen starten im Trockenlauf und werden freigeschaltet, nachdem man ihr Protokoll ein paar Tage angesehen hat. Form: Gespräch: der Agent listet die Aktionen mit Konsequenz auf, du bestätigst, welche eine Sperre bekommen und welcher Art. Größe: verpflichtend, sobald das System etwas Unumkehrbares tut (abbuchen, senden, löschen, genehmigen). Ein reines Lesesystem kann ihn überspringen; in dem Moment, in dem es seinen ersten Knopf bekommt, der auf die Welt wirkt, wird dieser Schritt zum wichtigsten.

Wozu er dient

Sorg dafür, dass das System bei Zweifel oder Fehler NICHT handelt, und dass es das sagt. Das klingt offensichtlich und ist das Gegenteil von dem, was Software standardmäßig tut, nämlich im Zweifel weiterzumachen. Es verhindert die doppelte Abbuchung, die automatische Genehmigung ohne einen Menschen, das git add -A, das ein Zugangsgeheimnis hochlädt, und das Löschen von Kundendaten. Die Sperren, die ich bei der Krankenkasse eingebaut habe, sind das Vorbild: der Panikknopf mit doppelter Sicherung, der automatische Genehmiger im Trockenlauf, der Wächter mit Schutzvorrichtungen Ref. 28; und der Reflex, dass ein Fehler eine Zeile ohne ihren Knopf lässt, statt die ganze Liste zu brechen Ref. 25.

Das Prinzip hat einen Namen, „fail-closed“, und stammt aus der physischen Sicherheit: eine Sicherheitstür, die geschlossen bleibt, wenn der Strom ausfällt. Das Gegenteil, „fail-open“, ist die Tür, die aufgeht. In Software sind die meisten Dinge standardmäßig fail-open: wenn die Validierung fehlschlägt, läuft der Code weiter; wenn der Dienst nicht antwortet, wird angenommen, alles sei in Ordnung. Die Methode kehrt den Standard um: im Zweifel nein. Und das gilt sowohl für das System als auch für den Agenten, der es betreibt.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Erhebung der Aktionen mit Konsequenz, so generisch benannt: was das System tut, das abbucht, sendet, genehmigt, löscht oder jemanden außerhalb benachrichtigt; was passiert, wenn es zweimal getan wird; was passiert, wenn es falsch getan wird; wie es rückgängig gemacht wird. Das weiß das Geschäft; der Agent bewertet, ob die Liste vollständig ist, und fragt. Der semantische Baum hilft: jeder Prozess mit Konsequenz steht dort.
• Welche Aktionen der Agent selbst am System ausführen kann (wenn er eingebettet ist).

2. Prompts

Zu Beginn:

Was ich hier verlange: den Abgleich zwischen dem, was das Geschäft gesagt hat, und dem, was der Code tut (dort tauchen die Aktionen auf, an die sich niemand erinnerte); die Vollständigkeitsklausel in ihrer Form für diesen Schritt: die Unterschiede zwischen den beiden Listen werden erfragt, nicht aufgelöst; für jede Aktion Umkehrbarkeit, Sperre und Rückweg; und die allgemeine Regel des Fail-closed im Prompt ausgeschrieben, damit sie in der Tabelle und im Code bleibt.

Zum Abschluss:

Was ich hier verlange: den Test pro Sperre, rot bewiesen (ohne die Sperre fand die Aktion statt; mit der Sperre nicht), was Schritt 8 angewandt auf die Sicherheit ist; die endgültige Tabelle; und die Regel des Trockenlaufs für jede neue Automatisierung, die es erlaubt zu sehen, was sie getan hätte, bevor man sie handeln lässt.

3. Erwartetes Ergebnis

• docs/LOCKS.md: eine Zeile pro Aktion mit Konsequenz: was sie tut, ob sie umkehrbar ist, die Sperre, der Rückweg, wer sie freigegeben hat und wann.
• Ein Test pro Sperre, rot bewiesen, der prüft, dass die Aktion im Zweifel nicht stattfindet.
• Die neuen Automatisierungen, die im Trockenlauf starten, mit dem Protokoll „hätte getan“.
• Wenn der Agent eingebettet ist: seine Berechtigungen schriftlich (was er lesen darf, was er ändern darf, was eine Freigabe erfordert).

4. Vollständigkeitsprüfung

• Steht jede Aktion, die abbucht, sendet, genehmigt oder löscht, in der Tabelle? Denk dir eine aus, die nicht drin ist, und frag.
• Hat jede Sperre ihren roten Test? („Ohne die Sperre fand die Aktion statt; mit der Sperre nicht.“)
• Hat jede unumkehrbare Aktion einen aufgeschriebenen Rückweg? Wenn nicht, braucht sie eine doppelte Sicherung.
• Sind die neuen Automatisierungen im Trockenlauf gestartet? Hast du das Protokoll „hätte getan“ gesehen, bevor du sie freigeschaltet hast?
• Was passiert, wenn der eingebettete Agent etwas außerhalb seiner Berechtigungen versucht? Bitte ihn, es zu versuchen und dir die Ablehnung im Log zu zeigen.

5. Warnsignale

• Eine Automatisierung ist von „existiert nicht“ zu „läuft allein“ übergegangen, ohne eine Trockenlaufphase.
• Das Log hat keinen einzigen Eintrag „Aktion wegen Zweifel nicht ausgeführt“. Entweder zweifelt das System nie (unmöglich) oder es macht im Zweifel weiter.
• Eine Sperre lässt sich mit einem Parameter „für Tests“ umgehen. Dieser Parameter wird in der Produktion gesetzt bleiben.

Schritt 15 — Continuous Integration, Umgebungen, Geheimnisse und Deployment als Teil des Produkts (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: die Integrationskette und das Deployment in die Testumgebung werden in Schritt 4 aufgebaut. Der Abschluss Richtung Produktion —echte Umgebung, Geheimnisse auf dem Server, Beförderung, getestetes Rollback, Sperre gegen Geheimnisse— geschieht im Abschnitt der Produktionsfreigabe, nach dem Audit und den Sperren. Die Routine jedes Deployments gilt im ganzen Betrieb. Form: ein einziger Durchgang zum Aufbauen; Routine für jedes Deployment. Größe: verpflichtend in jedem Projekt mit Nutzern. In einem kleinen kann „Continuous Integration“ eine einzige GitHub-Action sein und „Umgebungen“ können zwei Ordner auf demselben Server sein; was nicht verhandelbar ist: dass die Tests von allein laufen, dass die Konfiguration nicht im Repository ist, und dass es ein Rollback gibt.

Wozu er dient

Sorg dafür, dass der Weg in die Produktion ein reproduzierbares Paket ist: die Tests laufen EINMAL, die Konfiguration lebt außerhalb des Repositorys, und die Geheimnisse kursieren nicht herum. Es verhindert die dreimal pro Commit gelaufenen Tests und das verbrannte Kontingent Ref. 39, das Schlag für Schlag mit offenen Posten gehärtete Deployment, weil es spät entdeckt wurde Ref. 32, und die in den Chat eingefügten Geheimnisse Ref. 42.

Zu den Geheimnissen gibt es eine Regel, die du als Reflex übernehmen sollst, ohne Ausnahmen: ein Geheimnis, das in einem Chat, in einem Log oder in einem Commit zu sehen war, ist kein Geheimnis mehr. Es ist egal, ob „es niemand gesehen hat“ oder ob „es danach gelöscht wurde“. Es wird rotiert. Die Rotation kostet zehn Minuten; herauszufinden, ob jemand es benutzt hat, ist unmöglich.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Erhebung der Umgebungen und Zugänge, generisch: welche Umgebungen es gibt (Test, Produktion), wo sie laufen, wer Zugang hat, wie etwas von einer in die andere befördert wird, welche Geheimnisse existieren und wo sie heute leben, wie viel Kontingent an Continuous Integration es gibt. Der Agent bewertet, ob es reicht, und fragt.
• Das Skelett mit seiner Continuous Integration und seinem Deployment in die Testumgebung (Schritt 4).

2. Prompts

Zu Beginn:

Was ich hier verlange, Klausel für Klausel: die Zugänge, bevor begonnen wird; die Tests ein einziges Mal pro Commit (sie dreimal laufen zu lassen ist das, was das Kontingent verbrannt hat); das Deployment, das nur verpackt; die Konfiguration außerhalb des Repositorys; die Beförderung als wiederholbares Verfahren; das getestete Rollback mit seinem Datenplan (ein Rollback, das nie getestet wurde, existiert nicht, und eine Schema- oder Datenmigration wird nicht rückgängig gemacht, indem man den Commit zurücksetzt); die Sperre gegen Geheimnisse in den Commits; und die Dokumentation für eine Person, die Schritt 20 angewandt auf die Infrastruktur ist.

Routine jedes Deployments:

Was ich hier verlange: die drei Vorbedingungen (Testumgebung grün mit derselben Version, Rollback bereit, Konfigurationsänderungen angekündigt) und die zwei nachträglichen Beweise (die laufende Version und eine Ende-zu-Ende-Prüfung, ohne etwas zu schreiben).

Wenn ein Geheimnis im Chat oder in einem Commit aufgetaucht ist:

Was ich hier verlange: sofortige Rotation, Inventar, wo es sonst noch war, und die Prüfung, die es erkannt hätte, damit es nächstes Mal nicht in den Chat gelangt.

3. Erwartetes Ergebnis

• Die Continuous Integration, die ein einziges Mal pro Commit läuft, mit dem Link zu einem Lauf.
• Das Deployment, das auf die Integration wartet und nur verpackt; gemessen: wie lange es vorher und nachher dauert.
• Die Konfiguration außerhalb des Repositorys; im Repo nur ein Beispiel ohne Werte.
• docs/DEPLOYMENT.md: wie man deployt, befördert und zurückrollt, Schritt für Schritt, für eine Person.
• Das Rollback mindestens einmal getestet, mit seinem Beleg.
• Die Anti-Geheimnis-Prüfung aktiv (ein Versuch, eines hochzuladen, abgelehnt).
• Eine Aufzeichnung des pro Monat verbrauchten Kontingents an Continuous Integration.

4. Vollständigkeitsprüfung

• Wie oft läuft die Batterie pro Commit? Es muss einmal sein. Verlang den Link.
• Gibt es einen echten Konfigurationswert (einen Schlüssel, ein Passwort, eine interne URL) im Repository? Bitte den Agenten zu suchen und dir die leere Suche zu zeigen.
• Könntest du docs/DEPLOYMENT.md allein befolgen, ohne den Agenten? Lies es mit dieser Frage.
• Wurde das Rollback getestet? Wann? Welchen Beleg gibt es?
• Falls es eine Schema- oder Datenmigration gab: gibt es einen schriftlichen Plan, sie rückgängig zu machen oder auszugleichen, zusätzlich zum Code-Rollback?
• Wurde während des Projekts ein Geheimnis in den Chat eingefügt? Wenn ja, wurde es rotiert?
• Weißt du, wie viel Kontingent an Continuous Integration diesen Monat noch übrig ist?

5. Warnsignale

• Das Deployment in die Produktion wird „von Hand, schnell, weil es eine kleine Änderung ist“ gemacht. Die kleinen Änderungen sind die, die die Produktion brechen, weil niemand sie testet.
• Die Beispieldatei der Konfiguration hat Werte, die echt aussehen. Wahrscheinlich sind sie es.
• Niemand kann sagen, wann das Rollback zuletzt getestet wurde.
• Eine Migration hat Daten oder Schema geändert, und „das Rollback“, von dem die Rede ist, ist nur das des Codes. Für diese Migration gibt es kein Rollback: es gibt, bestenfalls, einen Plan, sie auszugleichen.

Schritt 16 — Vollständige Beobachtbarkeit und Nachverfolgbarkeit, mit konfigurierbarem Level (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: in der Phase der Produktionsfreigabe, nach der 15 (es gibt schon eine Deployment-Kette und Konfiguration pro Umgebung) und vor den Lasttests (19), denn ohne Beobachtbarkeit sagen die Lasttests nicht, was kaputtgegangen ist. In einem Altsystem gehört das Mindestniveau (strukturierte Logs mit konfigurierbarem Level und eine Korrelations-ID) in den Sicherheitsgurt (N4); das vollständige Niveau hierher. Die Regel „jedes neue Modul loggt und propagiert“ gilt während des ganzen Betriebs. Form: ein einziger Durchgang; der Agent baut es auf und beweist es; du liest eine echte Spur. Größe: verpflichtend in seinem Mindestniveau in jedem Projekt, das Nutzer haben wird; vollständig in jedem Projekt mit Konsequenzen.

Wozu er dient

Wenn in der Produktion etwas schiefgeht, und es wird schiefgehen, will ich einer Aktion vom Bildschirm bis zur Datenbank und bis zu jedem externen Aufruf folgen können, mit einer einzigen Kennung, ohne den Code zu öffnen und ohne den Agenten zu bitten, „nachzusehen“. Und ich will das Detailniveau der Logs in der Produktion in einer Minute hochdrehen können, ohne neu zu deployen, und danach wieder herunterdrehen. Das ist Beobachtbarkeit: sehen, was das System tut. Und das Zweite ist Nachverfolgbarkeit: dass jede Aktion mit Konsequenz (abgebucht, gesendet, gelöscht, genehmigt) eine Spur hinterlässt — wer, wann, was, von wo und mit welchem Ergebnis —, in einer Aufzeichnung, die die Anwendung nicht bearbeiten kann. Ohne das agiert der residente Agent aus Schritt 23 blind, das Monitoring der Schritte 21 und 22 hat nichts, wovon es sich ernähren könnte, und jeder Vorfall wird mit Hypothesen statt mit Belegen diagnostiziert. Der verwaiste Zug, der eine Stunde dreiundvierzig weiterlebte, wurde über das Log gefunden, nicht über den Code Ref. 16; und der residente Agent fing genau damit an, Logs zu lesen Ref. 13.

„Konfigurierbares Level“ ist die Klausel, die das hier von „Logs einbauen“ unterscheidet: das Level (Fehler, Warnung, Information, Debug, Trace) wird per Konfiguration auf dem Server geändert, pro Umgebung, ohne Code anzufassen und ohne zu deployen, und die Produktion läuft auf Information, außer wenn gerade etwas untersucht wird.

Wenn du Anfänger bist. Ein Log-Eintrag ist eine Zeile, die das System jedes Mal schreibt, wenn es etwas tut: „10:42:13, Modul Agenda, Nutzer recepcion1, Termin 17 abgesagt“. Strukturiert heißt, dass alle Zeilen dieselben Teile in derselben Reihenfolge haben, damit man sie maschinell durchsuchen kann. Das Level ist, wie viel Detail geschrieben wird: bei „Fehler“ nur das, was fehlgeschlagen ist; bei „Trace“ jeder einzelne Schritt. Die Korrelations-ID ist eine eindeutige Nummer, die jeder Aktion zu Beginn gegeben wird (du hast auf „absagen“ gedrückt) und die an allem klebt, was diese Aktion auslöst (die Abfrage an die Datenbank, die Nachricht an den Patienten); so sucht man hinterher diese Nummer und die ganze Geschichte erscheint. Und das Audit-Log ist eine nicht bearbeitbare Liste der wichtigen Aktionen: wer hat was wann getan.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Deployment-Kette und die Konfiguration pro Umgebung (Schritt 15): das Level wird dort konfiguriert.
• Die Tabelle der Sperren (Schritt 14): jede Aktion mit Konsequenz ist ein Eintrag des Audit-Logs.
• Die anfängliche Erhebung mit den markierten personenbezogenen Daten: die Logs dürfen sie nicht enthalten.
• Wo die Logs und die Metriken leben werden (eine rotierte Datei, ein Dienst): das entscheidest du.

2. Prompts

Zu Beginn:

Was ich hier verlange: die fünf Teile, und zwei Beweise, die der Beleg dieses Schritts sind: eine echte Kennung, der durch alle Schichten gefolgt wird (wenn er sie nicht zeigen kann, ist die Weitergabe irgendwo kaputt) und das Level, das sich ohne Deployment ändert (wenn man deployen muss, ist es nicht konfigurierbar). Das Audit-Log der Aktionen mit Konsequenz muss aus der Anwendung heraus unveränderlich sein, denn eine Spur, die die Anwendung löschen kann, ist keine Spur. Und die Maskierung der personenbezogenen Daten steht im selben Prompt, weil die Logs der Ort sind, an dem die meisten personenbezogenen Daten abfließen, ohne dass jemand es entschieden hat.

Routine (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: dass sich die Beobachtbarkeit nicht mit jedem neuen Modul verschlechtert, was immer passiert, wenn es keine Regel ist: das Modul aus Monat drei loggt nichts und ist genau das, das ausfällt.

3. Erwartetes Ergebnis

• Strukturierte Logs mit pro Umgebung konfigurierbarem Level, ohne Deployment geändert.
• Eine Korrelations-ID in jedem Log-Eintrag, weitergegeben vom Bildschirm bis zur Datenbank und zu den externen Aufrufen.
• Ein unveränderliches Audit-Log der Aktionen mit Konsequenz.
• Endpunkte oder Dateien für Gesundheit und Metriken, dokumentiert.
• Keine personenbezogenen Daten in den Logs.
• docs/OBSERVABILITY.md und die Routine in der Vereinbarung.

4. Vollständigkeitsprüfung (die machst du, ohne Code zu lesen)

• Verlang von ihm die Kennung einer echten Anfrage und such sie selbst in den Logs: erscheint sie im Bildschirm, im Backend, in der Datenbank und im externen Aufruf, falls es einen gab?
• Dreh das Level in der Testumgebung auf Debug, mach eine Aktion, schau in die Logs, dreh es wieder herunter. Musstest du deployen? Dann ist der Schritt nicht erklommen.
• Such einen Testnamen oder eine Testtelefonnummer in den Logs: sie dürfen nicht da sein.
• Mach eine Aktion mit Konsequenz in der Testumgebung (absagen, an den falschen Posteingang senden): steht sie im Audit-Log, mit wer, wann, was und Ergebnis?
• Reicht dir docs/OBSERVABILITY.md, um nachts um drei allein einen Log-Eintrag zu finden?

5. Warnsignale

• Der Agent zeigt „Logs“, aber jedes Modul schreibt in einem anderen Format. Das ist nicht strukturiert; niemand wird sie durchsuchen können.
• Die Kennung erscheint im Backend, aber nicht in den externen Aufrufen oder in den geplanten Aufgaben. Das sind genau die Orte, an denen die Vorfälle verloren gehen.
• Das Level der Produktion ist „erst mal“ auf Debug geblieben. Die Platte läuft voll und Daten fließen ab.
• Das Audit-Log der Aktionen mit Konsequenz lebt in derselben Tabelle wie die übrigen Daten, und die Anwendung kann es löschen.

Schritt 17 — Optimierung der Persistenzschicht, vorher und nachher gemessen (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: in der Phase der Produktionsfreigabe, nach der 16 (man muss die Abfragen sehen können, um sie zu messen) und vor der 19 (die Lasttests laufen auf der bereits optimierten Persistenz; sonst messen sie das Problem, das man schon kannte). Er wiederholt sich, wenn ein Block eine große Tabelle hinzufügt oder einen kritischen Fluss ändert, und wenn das Monitoring (21) eine Abfrage außerhalb des Bereichs zeigt. In einem Altsystem stammen die Messungen aus N6, und das meiste von dem, was man findet, wird „beim Anfassen“ bezahlt, außer dem, was schon außerhalb des Bereichs liegt. Form: zwei Durchgänge: messen und vorschlagen; anwenden mit Vorher und Nachher. Größe: proportional: in einem kleinen Projekt die Indizes der echten Abfragen und das Ende der N+1-Schleifen; in einem mit Konsequenzen vollständig, mit Budgets pro Pfad.

Wozu er dient

Die Persistenzschicht ist der Ort, an dem Systeme langsam sterben: sie laufen gut mit hundert Datensätzen, annehmbar mit zehntausend, und bei hunderttausend braucht jeder Bildschirm zwanzig Sekunden, und niemand weiß, wann das angefangen hat. Diesen Schritt gibt es, damit das mit Zahlen und vor der Produktion entschieden wird, nicht mit Beschwerden und danach. Und damit es mit der Methode von Schritt 7 entschieden wird: jede Abfrage, die das System macht, wird mit einem Messgerät gezählt und gestoppt, das einen Test hat, es wird geändert, was die Zahlen sagen, und es wird auf denselben Daten noch einmal gemessen. Das erste Audit der Abfragen ohne Index auf einem lebenden System Ref. 18 und das auf das Gemessene gezurrte Abfragebudget Ref. 37 sind der Ursprung dieses Schritts; die Entscheidung für die asynchrone Schnittstelle ab Zeile eins Ref. 15, sein Vorläufer beim Start.

Was er nicht ist: er ist nicht „den Datenzugriff neu schreiben“ und auch nicht eine andere Datenbank wählen. Das hat Schritt 3 entschieden. Er ist das Justieren dessen, was da ist (Indizes, Paginierung, Stapel, Retention, Größe des Verbindungspools), ausgehend von dem, was die echten Abfragen tun.

Wenn du Anfänger bist. Die Persistenzschicht ist der Teil des Systems, der die Daten speichert und liest, fast immer eine Datenbank. Ein Index ist wie das Register eines Buches: ohne ihn liest die Datenbank die ganze Tabelle, um einen Termin zu finden (das ist ein Full Scan); mit ihm geht sie direkt hin. Eine N+1-Schleife ist ein sehr häufiger Fehler: um hundert Termine anzuzeigen, macht das System eine Abfrage für die Liste und danach hundert weitere Abfragen, eine pro Termin, statt einer einzigen. Paginierung heißt, immer zwanzig auf einmal zu zeigen statt alles zusammen. Retention ist, wie lange jedes Datum aufbewahrt wird, bevor es archiviert oder gelöscht wird. Und der Verbindungspool ist die Anzahl der „offenen Leitungen“, die das System gleichzeitig zur Datenbank hat. Nichts davon verlangt, dass du Code liest: es verlangt, dass du Zahlen vorher und nachher ansiehst.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Dimensionierung und die Mengen (Schritt 3, oder N6 in einem Altsystem): die Volumina, bei denen gemessen werden muss.
• Die Produzenten-Konsumenten-Karte (Schritt 11): was jede Tabelle konsumiert.
• Die Beobachtbarkeit (16): jede Abfrage mit ihrer Zeit sichtbar.
• Die Testumgebung, geladen mit Daten im erwarteten Volumen.

2. Prompts

Zu Beginn (messen und vorschlagen):

Was ich hier verlange: messen mit der Methode von Schritt 7 (Messgerät mit Test, in beide Richtungen auditiert, Zahl mit Befehl), bevor vorgeschlagen wird; Abfrage für Abfrage vorschlagen, mit dem Gewinn und dem Risiko, und mit den Konsumenten der Karte, die jede Änderung berührt (ein neuer Index berührt niemanden; eine Retention pro Tabelle berührt alle, die diese Tabelle lesen); und nichts ändern, bis ich zustimme, denn die Optimierung ist der Ort, an dem am meisten „verbessert“ wird, was niemand verlangt hat.

Zum Abschluss (anwenden, mit Vorher und Nachher):

Was ich hier verlange: ein Commit pro Änderung, damit das Vorher und das Nachher zuordenbar sind; dasselbe Messgerät auf denselben Daten (wenn sich die Daten ändern, sagt die Zahl nichts); das Budget mit Test, das verhindert, dass die N+1-Schleife in drei Monaten zurückkommt; und die Symmetrie von Schritt 11, angewandt auf die Persistenz.

3. Erwartetes Ergebnis

• Die Messgeräte für Abfragen im Repository, mit Test.
• docs/PERSISTENCE.md mit der Tabelle von Vorher und Nachher pro Änderung, den Budgets pro Pfad und der Retention pro Tabelle.
• Die Indizes, die Paginierung, die Stapel und die Retention angewandt, ein Commit pro Stück, mit der Regression und der Ende-zu-Ende-Batterie in Grün.
• Ein Test pro Budget, der fehlschlägt, wenn es überschritten wird.

4. Vollständigkeitsprüfung

• Lass selbst ein Messgerät vorher und nachher laufen (der Agent gibt dir beide Befehle): stimmen sie mit der Tabelle überein?
• Gibt es irgendeine Abfrage, die in einem kritischen Fluss eine ganze Tabelle liest? Warum ist sie geblieben?
• Hat jede Tabelle eine geschriebene Retention-Regel, und sei es „für immer“?
• Haben die Budgets einen Test? Verlang von ihm, eines absichtlich zu überschreiten und dir das Rot zu zeigen.
• Braucht der langsamste Bildschirm, mit den Daten im Volumen, so lange, wie es die Dimensionierung erwartet hat?

5. Warnsignale

• Die Messungen wurden mit den Beispieldaten des Skeletts gemacht. Mit zehn Zeilen ist alles schnell.
• Der Agent schlägt vor, „auf eine andere Datenbank zu migrieren“ oder „die Datenschicht neu zu schreiben“. Das ist Schritt 3, und wenn man dorthin zurück muss, ist das deine Entscheidung, keine Optimierung.
• Die Zahl hat sich verbessert, aber die Ende-zu-Ende-Prüfung eines Flusses geht nicht mehr durch. Ein Index bricht keinen Fluss; eine Retention oder eine Paginierung schon: da fehlte ein Konsument der Karte.
• Es gibt keine Budgets. Ohne Budget hält die Optimierung bis zum nächsten Block.

Schritt 18 — Scannen und Beheben von Schwachstellen, in der Kette und mit Zeitplan (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: in der Phase der Produktionsfreigabe, nach der 15 (der Scan läuft in der Continuous Integration) und vor dem ersten Deployment: kein offenes P0 wird befördert. Danach bei jedem Push, und mit einem eigenen Zeitplan (wöchentlich), auch wenn es keine Pushes gibt, denn neue Schwachstellen tauchen auf, ohne dass du irgendetwas änderst. In einem Altsystem ist der erste Durchlauf Teil von N3 (die Sicherheitsdimension des Audits), und die Befunde kommen mit ihrer Geschwindigkeitsmarke in das Backlog. Form: ein einziger Durchgang zum Aufbauen und Laufenlassen; danach automatisch, mit einem Bericht, den du liest. Größe: verpflichtend in jedem Projekt, das Nutzer haben wird: der Scan der Abhängigkeiten und der Geheimnisse ist nicht verhandelbar; die statische Analyse und die Konfigurations-Basislinie sind proportional.

Wozu er dient

Das Audit aus Schritt 13 sieht sich das System hin und wieder mit frischen Augen an; dieser Schritt sieht sich eine einzige Sache an, die Sicherheit, die ganze Zeit und maschinell. Sie ergänzen sich: das Audit findet das, was Urteilsvermögen verlangt (eine Administratortür, die niemand haben dürfte Ref. 40); der Scan findet das, was Beharrlichkeit verlangt (die Abhängigkeit, die gestern keine bekannte Schwachstelle hatte und heute schon Ref. 41). Das erste formale Sicherheitsaudit hat mich davon überzeugt, dass Sicherheit eine periodische Routine ist und keine Liste, die man einmal abhakt Ref. 23; dieser Schritt ist diese Routine, zur Maschine gemacht.

Und eine Regel, die ich geschrieben haben will: eine Aktualisierung einer Abhängigkeit ist eine Änderung, und sie geht durch die Schleife wie jede andere. „Ich habe die Version hochgezogen, um die Schwachstelle zu schließen“, ohne Regression und ohne Ende-zu-Ende-Prüfung, ist die häufigste Art, die Produktion an einem Freitag kaputtzumachen.

Wenn du Anfänger bist. Eine Schwachstelle ist ein Defekt, den jemand nutzen kann, um einzudringen, Daten zu stehlen oder das System etwas tun zu lassen, was es nicht tun sollte. Es gibt vier Arten davon, die dieser Schritt maschinell sucht. In den Abhängigkeiten: den Softwarebausteinen anderer, die dein System benutzt (es gibt öffentliche Datenbanken, die auflisten, welche bekannte Defekte haben, mit einer CVE-Nummer gekennzeichnet). Im Code: die statische Analyse liest den Code, ohne ihn auszuführen, und sucht nach gefährlichen Mustern, etwa einer Injektion (dass ein Nutzer in ein Formular etwas schreibt, das die Datenbank als Befehl auffasst). In der Historie: ein Geheimnis (ein Passwort, ein Schlüssel), das irgendwann im Repository gespeichert wurde, ist immer noch da, auch wenn es später gelöscht wurde. Und in der Konfiguration: offene Ports, die nicht nötig waren, Standardpasswörter, fehlende Sicherheits-Header (Anweisungen, die der Server dem Browser schickt, um ihn zu schützen).

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Continuous Integration (Schritt 4 und 15), in der der Scan läuft.
• Die Erhebung der Umgebungen: welcher Server, welcher Container, welche Ports, für die Konfigurations-Basislinie.
• Das vorherige Audit (11, oder N3), um nicht schon Bekanntes zu melden.
• Dein Kriterium dafür, was P0 ist: was das Eindringen erlaubt, was personenbezogene Daten offenlegt, was das Abbuchen oder Senden ohne Kontrolle erlaubt.

2. Prompts

Zu Beginn (aufbauen, laufen lassen, vorschlagen):

Was ich hier verlange: die vier Scan-Schichten (Abhängigkeiten, Code, Geheimnisse in der Historie, Konfiguration), in der Kette und mit Zeitplan, denn neue Schwachstellen warten nicht auf deinen nächsten Push; den Bericht in der Form von Schritt 13, mit der Klausel „nicht gescannt“ statt „sauber“; das von mir vorgegebene P0-Kriterium; und das Verbot, ohne Durchgang durch die Schleife zu aktualisieren, das den kaputten Freitag verhindert.

Zum Abschluss (reparieren und in ein Tor verwandeln):

Was ich hier verlange: ein offener Posten pro Reparatur, mit dem Rot von Schritt 8, wo es möglich ist (eine ohne Test reparierte Schwachstelle kommt mit dem nächsten Refactor zurück); den wiederholten Scan als Beleg; und die Verwandlung in ein Tor, die dafür sorgt, dass dieser Schritt weiterlebt, wenn niemand hinsieht.

3. Erwartetes Ergebnis

• Der Scan in vier Schichten, der bei jedem Push und wöchentlich läuft.
• docs/SECURITY_[Datum].md mit den Befunden und dem nicht Gescannten; docs/SECURITY.md mit der Richtlinie, dem Zeitplan, dem Tor und der Abdeckung.
• Die P0 und P1 repariert, jedes mit seinem offenen Posten und seinem Test, wo zutreffend.
• Das Tor in docs/GATES.md.

4. Vollständigkeitsprüfung

• Verlang den Link zum letzten Durchlauf des Scans: ist er grün, und von welchem Datum ist er?
• Sagt der Bericht, was er NICHT gescannt hat?
• Hat jedes P0 seinen mit Beleg geschlossenen offenen Posten, oder einen offenen mit Datum?
• Verlang von ihm, in einem Zweig absichtlich eine Abhängigkeit mit bekannter Schwachstelle einzufügen: wird die Kette rot?
• Weißt du, wann der nächste geplante Scan läuft?

5. Warnsignale

• Der Scan war beim ersten Mal sauber, in einem System, das älter als ein Monat ist. Das stimmt fast nie: es fehlt eine Schicht, oder es wurde nur der Zweig und nicht die Historie gescannt.
• Zehn Abhängigkeiten wurden in einem Commit aktualisiert, „um die Befunde zu schließen“. Dieser Commit hat kein Vorher und kein Nachher; er ist der kaputte Freitag, der schon wartet.
• Der Scan ist da, aber er ist kein Tor: er produziert Berichte, die niemand liest.
• Es gibt ein „akzeptiertes“ P0 ohne offenen Posten, ohne Datum und ohne Unterschrift.

Schritt 19 — Lasttests im Volumen und Bruchpunkt (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: in der Phase der Produktionsfreigabe, nach der 16 (ohne Beobachtbarkeit weiß man nicht, was kaputtgegangen ist) und nach der 17 (auf der bereits optimierten Persistenz), und vor dem ersten Deployment in die Produktion. Er wiederholt sich vor jedem Deployment, das die Architektur, die Persistenz oder einen kritischen Fluss ändert, und wenn sich die Dimensionierung ändert (es wird an einen weiteren Kunden verkauft, das Volumen verdoppelt sich). In einem Altsystem läuft er mit den in N6 gemessenen Volumina, vor dem ersten Deployment nach der Normalisierung. Form: ein einziger Durchgang; der Agent lädt, misst und bricht; du liest die Zahlen und den Bruchpunkt. Größe: proportional: in einem kleinen Projekt ein Durchlauf im erwarteten Volumen und einer im „mal zehn“; in einem mit Konsequenzen vollständig, mit gefundenem Bruchpunkt und mit den für das Monitoring festgehaltenen Schwellenwerten.

Wozu er dient

Schritt 3 hat mit Rechnungen dimensioniert; dieser Schritt überprüft die Rechnungen mit dem echten laufenden System. Ich will drei Dinge wissen, bevor der erste Nutzer hereinkommt: wie sich das System bei dem Volumen verhält, das das Geschäft genannt hat (antwortet der meistbenutzte Bildschirm in dem, was der Eigentümer tolerieren würde?), wie es sich beim „mal zehn“ verhält (hält es aus, oder was hält als Erstes nicht mehr?), und wo es bricht: die genaue Last, bei der etwas nachgibt, und was dieses Etwas ist (die Verbindungen zur Datenbank, der Speicher, eine Warteschlange, eine Blockade). Der Bruchpunkt ist die nützlichste Zahl des ganzen Abschnitts, denn aus ihm kommen die Alarm-Schwellenwerte von Schritt 21: ein „nach Augenmaß“ gesetzter Alarm meldet zu spät oder meldet immer; ein Alarm, der unter dem gemessenen Bruchpunkt gesetzt ist, mit einem Spielraum, meldet, solange noch Zeit ist. Die Skalierungsmuster, die ich aus einem System in Produktion gezogen habe Ref. 12, und die Batterie, die am Speicher starb und wie ein fehlgeschlagener Test aussah Ref. 44, sind die beiden Vorläufer: der erste vom Messen der echten Last; der zweite davon, dass sich ein nicht rechtzeitig gefundener Bruchpunkt als etwas anderes verkleidet.

Wenn du Anfänger bist. Ein Lasttest ist ein Programm, das viele Nutzer simuliert, die das System gleichzeitig benutzen, um zu sehen, was passiert. Durchsatz (throughput) ist, wie viele Aktionen pro Sekunde es aushält. Latenz ist, wie lange eine Aktion zum Antworten braucht; man sieht sich den Median an (die Hälfte der Aktionen brauchte weniger als das) und das 95. Perzentil (95 % brauchten weniger als das; die restlichen 5 % sind die Nutzer, die sich beschweren). Der Bruchpunkt ist die Lastmenge, bei der etwas aufhört zu funktionieren: nicht „es wird langsam“, sondern „die Verbindungen zur Datenbank waren erschöpft“ oder „der Speicher war voll“. Und ein Schwellenwert ist eine Grenzzahl, ab der das Monitoring meldet.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Dimensionierung (Schritt 3 oder N6): das erwartete Volumen und das „mal zehn“.
• Die Beobachtbarkeit (16) eingeschaltet, um zu sehen, was bricht.
• Die optimierte Persistenz (17) mit ihren Budgets.
• Eine Testumgebung, die der Produktion in den Ressourcen ähnlich ist, oder das Bewusstsein darüber, worin sie sich unterscheidet.
• Die kritischen Flüsse (die des semantischen Baums, oder die der Charakterisierung in einem Altsystem).

2. Prompts

Zu Beginn (laden, messen, brechen):

Was ich hier verlange: ein Lastskript, das ein weiteres Messgerät ist (es lebt im Repository und hat einen Test, denn ein Lastskript, das den Fluss nicht ausübt, misst die Luft); drei Durchläufe (erwartet, mal zehn, bis es bricht); die Zahlen mit Befehlen; den Vergleich mit den Budgets, der Toleranz des Geschäfts und den Annahmen der Dimensionierung, und genau da entdeckt man, dass sich Schritt 3 in etwas geirrt hat; und noch nichts optimieren, denn optimieren, ohne die Diagnose gelesen zu haben, heißt das zu ändern, was es nicht war.

Zum Abschluss (Schwellenwerte und offene Posten):

Was ich hier verlange: die Alarm-Schwellenwerte, abgeleitet aus dem Bruchpunkt, was die Verzahnung mit Schritt 21 ist; die Flaschenhälse als offene Posten mit der Zahl als Kriterium (so werden sie mit Belegen geschlossen und nicht mit „jetzt läuft es besser“); und den Lasttest als archiviertes Tor, damit man in sechs Monaten vergleichen kann.

3. Erwartetes Ergebnis

• Das Lastskript im Repository, mit Test.
• docs/PERFORMANCE_[Datum].md mit den drei Durchläufen, den Zahlen, dem Bruchpunkt und der Diagnose; docs/PERFORMANCE.md mit den Schwellenwerten und dem Tor.
• Ein offener Posten pro Flaschenhals unterhalb des entschiedenen Volumens.
• Der Lasttest als Tor vor den Deployments, die ihn verlangen.

4. Vollständigkeitsprüfung

• Braucht der meistbenutzte Bildschirm im erwarteten Volumen weniger als die Toleranz des Eigentümers? Wenn nicht, gibt es einen offenen Posten mit dieser Zahl.
• Sagt der Bruchpunkt, was gebrochen ist und bei welcher Last, oder sagt er „das System wurde langsam“?
• Liegen die Schwellenwerte aus docs/PERFORMANCE.md unter dem Bruchpunkt und über dem erwarteten Volumen?
• Lass selbst das Skript im erwarteten Volumen laufen, mit dem Befehl, den er dir gegeben hat: ähneln sich die Zahlen?
• Unterscheidet sich die Testumgebung in den Ressourcen von der Produktion, und ist notiert, wie?

5. Warnsignale

• „Es hält das mal zehn ohne Probleme aus“ ohne einen Bruchpunkt. Wenn er nicht gefunden hat, wo es bricht, hat er die Last nicht weit genug hochgefahren.
• Das Lastskript geht auf die API, aber nicht über den Bildschirm, in einem System, in dem der Bildschirm das ist, was lädt. Es misst etwas anderes.
• Die Ergebnisse stammen aus einem Durchlauf auf der Maschine des Agenten, nicht in der Testumgebung.
• Während des Tests wurden Flaschenhälse repariert, „wo man schon mal dabei war“. Jetzt weißt du nicht, welche Zahl zu welcher Version gehört.

Schritt 20 — Lebendige Dokumentation und Handbücher, denen eine Person ohne KI folgen kann (Schrittvertrag)

Abschnitt: Produktionsfreigabe. Wann: das Benutzerhandbuch wächst mit jedem Funktionsblock, beim Abschluss, mit den neuen Bildschirmen; gespeist von den geschlossenen Posten, die die Dokumentation des Erledigten sind. Die drei vollständigen Handbücher werden im Abschnitt der Produktionsfreigabe erzeugt, nach Schritt 15, und der Test mit einer Person, die nicht programmiert, findet vor dem ersten Deployment statt. Die Routine des selben Commits gilt im ganzen Betrieb. Form: Routine; plus ein langer Durchgang, wenn die Handbücher erzeugt werden. Größe: proportional. Ein kleines System braucht mindestens das Infrastruktur- und Wiederherstellungshandbuch; das Benutzerhandbuch kann eine Seite sein. Was sich nicht ändert: wenn die Person, die es gebaut hat, verschwindet, muss eine andere weitermachen können.

Wozu er dient

Sorg dafür, dass das System ohne den Agenten und ohne dich benutzt, gewartet und wiederhergestellt werden kann. Wenn es an dem Tag, an dem es keinen Agenten gibt, nicht deployt werden kann, ist es nicht fertig. In der klassischen Methode war Dokumentation teuer und alterte; hier ist sie neu zu erzeugen gratis, also wird die Regel zu „im selben Commit“ und „von Hand reproduzierbar“. Die Handbücher, die ich für die Krankenkasse mit diesem Kriterium geschrieben habe, sind das Vorbild Ref. 24; und die Projektdatei, die zu einer Historie von tausenden Zeilen wurde, ist das Gegenbeispiel Ref. 41.

Ein Qualitätskriterium für das Wiederherstellungshandbuch, das erlaubt, es ohne Technikkenntnis zu beurteilen: eine Vertrauensperson, die nicht programmiert, muss ihm folgen können, um drei Uhr morgens, mit ausgefallenem System und dem Agenten ohne Verbindung. Wenn in irgendeinem Schritt „mit dem Entwickler abklären“ oder „je nach Fall“ steht, ist dieser Schritt unvollständig.

Und eine Quelle, die man nicht ungenutzt lassen darf: die geschlossenen Posten. Jeder bringt seine Spezifikation, seine Entscheidung, seinen Beleg und sein Datum mit. Das Benutzerhandbuch wird nicht am Ende von null geschrieben: es wird, Block für Block, aus den geschlossenen Posten zusammengesetzt, und das Änderungsprotokoll entsteht direkt aus ihnen.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Wer die Leser jedes Handbuchs sind: der Endnutzer, der Wartende, der Betreiber der Infrastruktur. Das weiß das Geschäft; der Agent fragt, wenn es nicht klar ist.
• Das System, das in der Testumgebung läuft, um echte Screenshots zu machen.
• Die geschlossenen Posten des Blocks, mit ihrer Abschlussdokumentation (Schritt 5).
• docs/DEPLOYMENT.md (Schritt 15) und docs/LOCKS.md (Schritt 14), die Eingaben sind.

2. Prompts

Routine (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: die Regel des selben Commits, die einzige, die ein Handbuch aktuell hält; den Blockabschluss als Moment, in dem die geschlossenen Posten zu Handbuch und Änderungsprotokoll werden; und die Frage, wenn nicht klar ist, in welches Handbuch es gehört.

Zum Erzeugen der Handbücher:

Was ich hier verlange: die drei Handbücher mit ihren Lesern; echte Screenshots aus der Testumgebung (keine Zeichnungen oder Beschreibungen); das Kriterium der drei Uhr morgens für das Wiederherstellungshandbuch; die Vollständigkeitsklausel in ihrer Form fürs Dokumentieren: was nur das Geschäft weiß, wird erfragt, und es wird keine Lücke gelassen und nichts erfunden; und Datum und Version, damit man weiß, zu welchem System jedes Handbuch gehört.

3. Erwartetes Ergebnis

• docs/USER_MANUAL.md (oder HTML), mit echten, eingebetteten Screenshots, das Block für Block gewachsen ist.
• docs/MAINTENANCE_MANUAL.md.
• docs/INFRASTRUCTURE_AND_RECOVERY_MANUAL.md: Schritt für Schritt, für eine Person.
• docs/CHANGELOG.md, gespeist von den geschlossenen Posten.
• Jedes mit Datum und der Version des Systems, das es dokumentiert.
• In den Commits, die Bildschirme, Betrieb oder Deployment ändern: das aktualisierte Handbuch.

4. Vollständigkeitsprüfung

• Öffne das Benutzerhandbuch bei einem zufälligen Bildschirm: stimmt der Screenshot mit dem überein, was heute in der Testumgebung ist?
• Könntest du dem Wiederherstellungshandbuch folgen, oder jemand aus deinem Vertrauen, der nicht programmiert? Lies den Abschnitt „es ist ausgefallen“: sagt er, was zu tun ist, in Reihenfolge, mit den Befehlen?
• Wähl einen jüngeren Commit, der einen Bildschirm geändert hat: hat er das Handbuch angefasst?
• Hat das Änderungsprotokoll einen Eintrag für jeden geschlossenen Posten des letzten Blocks?
• Gibt es eine Lücke vom Typ „[ergänzen]“ oder „mit dem Verantwortlichen abklären“? Dort hätte der Agent fragen müssen.
• Sagt jedes Handbuch, für welche Version des Systems es gilt?

5. Warnsignale

• Das Benutzerhandbuch hat Screenshots einer Version, die nicht mehr existiert. Es wurde einmal erzeugt und nicht gepflegt: die Regel des selben Commits steht nicht in der Vereinbarung oder wird nicht angewendet.
• Das Wiederherstellungshandbuch beginnt mit „öffne eine Sitzung mit dem Agenten“. Wenn der Agent Voraussetzung ist, ist es kein Handbuch für eine Person.
• Niemand außer dem Bauenden hat je das Wiederherstellungshandbuch gelesen. Bitte jemanden, ihm in der Testumgebung zu folgen; woran er hängen bleibt, ist das, was zu reparieren ist.

Schritt 21 — Monitoring von Ressourcen, Funktionen und Abfragen außerhalb des Bereichs, mit zyklischem Bericht (Schrittvertrag)

Abschnitt: Betrieb. Wann: er wird in der Betriebsphase aufgebaut, mit dem ersten Deployment in die Produktion, mit den Schwellenwerten aus der 19 und den Metriken aus der 16; von da an läuft er allein, und der zyklische Bericht wird in jedem Zyklus mit dem Eigentümer gelesen (wöchentlich in einem System mit Konsequenzen, monatlich in einem kleinen). Jedes Ereignis außerhalb des Bereichs tritt als korrektiver offener Posten in die Schleife ein. In einem Altsystem genauso, mit einem Unterschied: die erste Lesung des Berichts ist die Basislinie, und was am ersten Tag schon außerhalb des Bereichs lag, wird zu offenen Posten mit ihrer Geschwindigkeitsmarke. Form: ein einziger Durchgang zum Aufbauen; danach zyklische Routine. Größe: minimal in einem kleinen Projekt (ein monatlicher Bericht, ein Alarm für die Platte und einer für Datenbankfehler); vollständig in einem mit Konsequenzen (Schwellenwerte pro Funktion und pro Abfrage, Alarme, wöchentlicher Bericht).

Wozu er dient

Die Tests aus Schritt 19 sagen, wie sich das System an einem Tag verhält, mit einer Last, die ich gewählt habe. Die Produktion ist jeden Tag, mit der Last, die die Nutzer wählen, mit wachsenden Daten und mit Änderungen, die jede Woche hereinkommen. Was im Oktober im Bereich lag, liegt im März außerhalb, ohne dass jemand etwas geändert hat, nur weil die Tabelle gewachsen ist. Diesen Schritt gibt es, damit man das sieht, bevor der Nutzer es sieht: die Ressourcennutzung gegen die Kapazität, die Antwortzeit jeder Funktion, jedes Endpunkts, jeder Aufgabe und jeder Abfrage, verglichen mit den Schwellenwerten aus der 19 und mit ihrer eigenen Geschichte; ein Alarm, wenn etwas aus dem Bereich läuft; und ein zyklischer Bericht, den ich mit dem Eigentümer lese und in dem jede Abweichung eine Ursache oder einen offenen Posten hat. Die auf das Gemessene gezurrte Obergrenze Ref. 37 ist der Grundgedanke: der Bereich ist keine Meinung, er ist die gemessene Zahl plus ein Spielraum; und das Kontingent der Continuous Integration, das verbrannte, ohne dass jemand hinsah Ref. 39, ist der Fehler, den er verhindert: eine Ressource, die sich ohne Monitoring verbraucht, wird entdeckt, wenn sie alle ist.

Zwei Regeln, über die ich nicht verhandle. Ein Alarm, der auslöst und den niemand liest, ist ein Defekt des Alarms, nicht dessen, der ihn nicht gelesen hat: er wird justiert oder entfernt. Und ein Schwellenwert wird nicht ohne eine geschriebene, gemessene Begründung angehoben, um einen Alarm zum Schweigen zu bringen.

Wenn du Anfänger bist. Monitoren heißt, das System die ganze Zeit maschinell anzusehen und zu melden, wenn etwas aus dem Normalen läuft. Die Ressourcen sind das, was das System verbraucht: Prozessor, Speicher, Platte, Verbindungen zur Datenbank, und auch Kontingente externer Dienste (wie viele Nachrichten pro Monat dich der Anbieter senden lässt). „*Außerhalb des Bereichs*“ heißt über einem Schwellenwert (einer festen Grenze, die aus den Tests von Schritt 19 kam) oder sehr verschieden von der Basislinie (dem, was dieselbe Zahl in den letzten Tagen ergeben hat). Ein Alarm ist die Meldung im Moment; der zyklische Bericht ist die Zusammenfassung, die man jede Woche oder jeden Monat in Ruhe liest.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Beobachtbarkeit (16): die Metriken und die Logs, von denen es sich ernährt.
• Die Schwellenwerte aus der 19 und die Budgets aus der 17.
• Die deployte Produktion (15), mit nur lesendem Zugang für das Monitoring.
• Der Alarmkanal und der Zyklus des Berichts: die entscheidest du mit dem Eigentümer.

2. Prompts

Zu Beginn (aufbauen und beweisen):

Das Fenster der Messung. Der zyklische Bericht vergleicht die beobachteten Zeilen pro Jahr mit dem, was Stufe 3 erklärt hat. Eine richtige Zahl mit einem falschen Fenster öffnet einen falschen offenen Punkt: in der Übung mit dem geerbten Turnera wurden 30.000 Zeilen aus drei Jahren übergeben, als wären sie aus einem. Deshalb trägt die Messung ihr überprüfbares Fenster: den ersten und den letzten Datensatz, aus der Datenbank oder dem Protokoll gelesen, keine von Hand getippte Zahl. Kann das Werkzeug die Datenbank nicht lesen, erklärt es das als blinden Fleck; ein von Hand getipptes Fenster wird im Bericht als solches markiert und warnt nur, es öffnet nie von allein einen offenen Punkt. (Entscheidung D-039.)

Was ich hier verlange: Erfassung mit Geschichte (ohne Geschichte gibt es keine Basislinie, und ohne Basislinie gibt es kein „außerhalb des Bereichs“); Alarme gegen zwei Referenzen, den absoluten Schwellenwert aus der 19 und die relative Abweichung von der eigenen Geschichte; den zyklischen Bericht in der Form eines Berichts aus Schritt 12 (jede Abweichung mit Ursache oder mit Vorschlag, nichts von „alles normal“); die Verwandlung jeder Abweichung in einen offenen Posten mit Zahl; und die zwei Beweise: den ersten Bericht und einen provozierten Alarm.

Routine jedes Zyklus (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: dass der Bericht gelesen wird und entschieden wird, mit Spur; und die Regel des Schwellenwerts, die verhindert, dass das Monitoring nach und nach stumm wird.

3. Erwartetes Ergebnis

• Erfassung von Ressourcen und Antwortzeiten mit Geschichte, ohne personenbezogene Daten.
• Alarme nach Schwellenwert und nach Abweichung, an einen Kanal, den eine Person liest.
• Der zyklische Bericht, allein erzeugt, mit jeder Abweichung begründet oder mit Vorschlag.
• docs/MONITORING.md mit Schwellenwerten, Kanal, Zyklus und der Art, einen Alarm mit einer geschriebenen Begründung stummzuschalten.
• Die Routine in der Vereinbarung; die Abweichungen als korrektive offene Posten.

4. Vollständigkeitsprüfung

• Lass absichtlich einen Schwellenwert in der Testumgebung überschreiten: ist der Alarm bei dir angekommen, über den vereinbarten Kanal, mit der Kennung?
• Lies den letzten Bericht: hat jedes Ereignis außerhalb des Bereichs eine Ursache oder einen Vorschlag? Ist eines ohne irgendetwas geblieben?
• Gibt es einen offenen Posten für jede Abweichung, die du angehen wolltest, mit der Zahl als Kriterium?
• Ist seit der 19 irgendein Schwellenwert angehoben worden? Mit welcher geschriebenen Begründung?
• Erwähnt der Bericht das Kontingent der externen Dienste (Messenger, Continuous Integration)?

5. Warnsignale

• Die Alarme lösen jeden Tag aus und niemand liest sie. Man muss ihre Zahl senken, bis jeder einzelne etwas bedeutet, und sich nicht an sie gewöhnen.
• Der Bericht sagt drei Zyklen hintereinander „alles normal“. Entweder hat das System keine Nutzer, oder der Bericht sieht sich nicht das an, was zählt.
• Ein Schwellenwert wurde angehoben, „damit er aufhört zu melden“. Das ist Schritt 21, der still stirbt.
• Das Monitoring speichert personenbezogene Daten, „um diagnostizieren zu können“. Das ist ein Datenabfluss mit Uhrzeit.

Schritt 22 — Fehler-Monitoring und zyklischer Bericht: kein Fehler ohne offenen Posten (Schrittvertrag)

Abschnitt: Betrieb. Wann: er wird in der Betriebsphase aufgebaut, mit dem ersten Deployment, zusammen mit der 21, auf den Logs der 16; von da an läuft er allein, mit Alarmen im Moment und einem zyklischen Bericht, der mit dem Eigentümer gelesen wird. Jeder neue Fehler tritt als korrektiver offener Posten in die Schleife ein und wird mit dem Test geschlossen, der ihn rot reproduziert. In einem Altsystem ist die erste Lesung die Basislinie: die Fehler, die am ersten Tag schon existierten, werden zu offenen Posten mit ihrer Geschwindigkeitsmarke, und keiner bleibt als „bekannt“ ohne einen offenen Posten, der sagt, warum er toleriert wird und bis wann. Form: ein einziger Durchgang zum Aufbauen; danach zyklische Routine. Größe: verpflichtend in jedem Projekt mit Nutzern: die zentrale Erfassung und der Bericht sind nicht verhandelbar; die Alarme im Moment sind proportional.

Wozu er dient

Ein System in Produktion erzeugt Fehler, die kein Nutzer meldet: der, der den weißen Bildschirm gesehen und es noch einmal versucht hat, der der nächtlichen Aufgabe, die fehlschlug und auf die niemand schaut, der des externen Aufrufs, der einen Fehler zurückgab und den der Code verschluckt hat. Wenn ich sie nicht erfasse, existieren sie nicht, bis sie zu sehr existieren. Dieser Schritt ist das Gegenstück zur 20: jene wacht über die Leistung, dieser über die Fehler, und beide enden am selben Ort, in der Schleife, als korrektive offene Posten. Die Grundregeln sind zwei. Kein Fehler ohne offenen Posten: ein neuer Fehler eröffnet einen, und er wird mit dem Test geschlossen, der ihn rot reproduziert, wie es der korrektive Modus des evolutiven Wegs verlangt. Und es gibt keinen „bekannten Fehler“ ohne einen offenen Posten, der sagt, warum er toleriert wird und bis wann; „diesen Fehler gab es schon immer“ ist der Satz, mit dem ein System verrottet. Der Authentifizierungsfehler, der als Erfolg gemeldet wurde Ref. 43, und die vier Runden bis zur Grundursache Ref. 22 sind die beiden Vorläufer: der erste davon, dass sich Fehler verstecken, wenn man sie nicht maschinell erfasst; der zweite davon, dass ein Fehler ohne Reproduktion mehrmals repariert wird.

Wenn du Anfänger bist. Ein Fehler ist alles, was das System zu tun versuchte und nicht konnte: ein Bildschirm, der nicht geladen hat, eine nächtliche Aufgabe, die abgebrochen ist, ein Aufruf an einen anderen Dienst, der fehlgeschlagen ist. Eine unbehandelte Ausnahme ist ein Fehler, den der Code nicht vorgesehen hat und der abbricht, was er gerade tat. Einen Fehler zu erfassen heißt, ihn mit all seinen Daten (wann, in welcher Version, mit welcher Kennung, dem Stack, also der Liste der Programmschritte bis zum Fehlschlag) an einem einzigen zentralen Ort zu speichern, statt ihn auf dem Bildschirm eines Nutzers verloren gehen zu lassen. Gruppieren heißt, die tausend Male, die derselbe Fehler passiert ist, in einem einzigen Eintrag mit einem Zähler zusammenzufassen. Und die Fehlerrate pro Fluss ist: von hundert Malen, die jemand einen Termin eingetragen hat, wie viele fehlgeschlagen sind.

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

• Die Beobachtbarkeit (16): die Fehler kommen mit Korrelations-ID, Version und Akteur an.
• Die Tabelle der Sperren (14): die Fehler in Aktionen mit Konsequenz sind sofortiger Alarm.
• Die deployte Produktion (15), mit dem Browser des Nutzers in der Erfassung eingeschlossen.
• Der Alarmkanal und der Zyklus des Berichts, geteilt mit der 21.

2. Prompts

Zu Beginn (aufbauen und beweisen):

Die Fehler des Werkzeugs sind nicht die Fehler des Systems. Die zentrale Erfassung trennt nach Quelle: die Fehler des Systems und die der Werkzeuge, die es beobachten (das Panel, der residente Agent, das Monitoring selbst), werden unter verschiedenen Quellen gespeichert, der Bericht führt sie in getrennten Abschnitten auf, und nur die Fehler des Systems öffnen offene Punkte. In der Übung Turnera öffnete der erste zyklische Bericht sechs "Bugs", die das Forge-Panel im Gespräch mit einem abgeschalteten Server waren. (Entscheidung D-038.)

Was ich hier verlange: die Erfassung an den drei Orten, an denen sich die Fehler verstecken (Backend, Aufgaben, Browser), mit der Kennung aus der 16, um ihnen folgen zu können; die Gruppierung, ohne die der Bericht eine Liste von zehntausend Zeilen ist; die drei Alarme, die zählen (neu, wiederkehrend und wachsend, mit Konsequenz); den Bericht mit der Rate pro Fluss, die die Zahl ist, die der Eigentümer versteht; die zwei Regeln; und den Beweis von Anfang bis Ende, vom Browser bis zum Bericht.

Routine jedes Zyklus (gehört in die Arbeitsvereinbarung):

Was ich hier verlange: die Disziplin des Zyklus, und die Regel des Fehlers, der verschwindet, die die kontraintuitivste ist und die am meisten wert ist: ein Fehler, der von allein ging, kommt von allein zurück.

3. Erwartetes Ergebnis

• Zentrale Fehlererfassung im Backend, in den Aufgaben und im Browser, nach Ursache gruppiert, ohne personenbezogene Daten.
• Alarme bei neuem Fehler, bei wiederkehrendem, der wächst, und bei Fehlern mit Konsequenz.
• Der zyklische Bericht mit der Fehlerrate pro Fluss.
• docs/MONITORING.md vollständig (zusammen mit der 21); die Routine in der Vereinbarung.
• Ein offener Posten für jeden offenen Fehler; keiner „bekannt“ ohne offenen Posten.

4. Vollständigkeitsprüfung

• Provozier selbst einen Fehler im Browser in der Testumgebung (eine Aktion, von der du weißt, dass sie fehlschlägt): ist er in der Erfassung mit deiner Kennung erschienen, und ist der Alarm bei dir angekommen?
• Lies den letzten Bericht: gibt es irgendeinen wiederkehrenden Fehler ohne offenen Posten und ohne Begründung?
• Nimm einen „reparierten“ Fehler aus dem Bericht: hat sein offener Posten den Test, der ihn rot reproduziert hat?
• Ist die Fehlerrate pro Fluss da, und ist sie gegenüber dem vorigen Zeitraum gesunken oder gestiegen?
• Such ein personenbezogenes Datum in der Fehlererfassung: es darf nicht da sein.

5. Warnsignale

• Null Fehler in der Produktion während eines Monats mit echten Nutzern. So ein System gibt es nicht; die Erfassung sieht den Browser oder die Aufgaben nicht.
• Ein Fehler mit tausend Vorkommen und einem Kommentar „bekannt, stört nicht“. Ohne offenen Posten, ohne Datum.
• Die Fehler werden „repariert“, indem der Dienst neu gestartet wird. Sie verschwinden und kommen zurück.
• Den Fehlerbericht und den Ressourcenbericht lesen verschiedene Leute, und niemand kreuzt sie: die langsame Abfrage aus der 21 ist die Ursache für den abgelaufenen Timeout aus der 22.

Schritt 23 — Der Agent im System, und die Retrospektive mit Zahlen (Schrittvertrag)

Abschnitt: Betrieb. Wann: der residente Agent beim Eintritt in den Betrieb, nach dem ersten Deployment in die Produktion. Die Retrospektive beim Abschluss jeder Etappe und des Projekts; sie kehrt zu Schritt 0 für das nächste Projekt zurück. Führ außerdem eine kurze Retrospektive durch, wenn sich das Modell ändert, das baut: Ein Vertrag, der für ein Modell kalibriert wurde, leistet mit einem anderen nicht unbedingt dasselbe, und ein Modellwechsel ist genau die Art von Befund, den diese Leiter in einen Änderungsvorschlag verwandeln soll, nicht in eine Überraschung, die mitten in einem Block entdeckt wird. Form: zwei Teile: ein Gespräch, um den Umfang des residenten Agenten zu definieren, und ein langer Durchgang für die Retrospektive. Größe: der residente Agent ist optional (viele Systeme brauchen ihn nicht; die mit Nutzern, die Support verlangen, schon). Die Retrospektive ist in jedem Projekt verpflichtend, und sei sie eine Seite lang: ohne sie lernt die Methode nicht.

Wozu er dient

Zwei Dinge, die denselben Kreis schließen. Erstens: lass den Agenten resident in der Produktion, mit begrenztem Umfang, um zu diagnostizieren, zu betreiben und Support zu geben, ohne dass du da sein musst Ref. 13. Zweitens: überprüfe die Methode selbst mit Zahlen, und lass das Gelernte die Leiter ändern. Das verhindert den Agenten, der ohne Systemkarte agiert, und die Methode, die sich Projekt für Projekt gleich wiederholt, ohne zu lernen. Die Retrospektive mit Zahlen, die mich dazu brachte, ein ganzes Team von Agenten abzuschaffen, ist das Vorbild für das Zweite Ref. 6.

Zum residenten Agenten, die Regel, die alles ordnet: er handelt im Namen von jemandem. Sein Zugangsschlüssel ist einer verantwortlichen Person zugeordnet, und alles, was er tut, wird unter dem Namen dieser Person protokolliert. Es ist kein anonymes Systemkonto: es ist ein Angestellter mit Chef. Das definiert seinen Umfang (was diese Person ihm erlaubt hat) und seine Nachverfolgbarkeit (wer für das verantwortlich ist, was er getan hat).

1. Benötigter Kontext

Was folgt, ist die generische Liste. Die konkreten Dateien, die du vor jedem Prompt fertig haben musst, mit ihrem Inhalt und ihrem Mindestzustand, stehen in Abschnitt 2, in dem Block „Bevor du den Prompt schickst“, der jedem einzelnen vorangeht.

Für den residenten Agenten:

• Was der Agent in der Produktion tun darf und was nicht: lesen, diagnostizieren, Konfiguration ändern, Aktionen ausführen. Das entscheidest du.
• Wie sich der Agent gegenüber dem System ausweist (ein eigener Zugangsschlüssel, einer verantwortlichen Person zugeordnet).
• Wen er benachrichtigt, wenn er etwas findet, das er nicht lösen kann (Ticket, E-Mail).

Für die Retrospektive:

• Die Vorfälle des Projekts, die Kosten (Tokens, Kontingent, deine Zeit), die offenen Posten, die die meisten Runden gedreht haben, und die Daten.

2. Prompts

Für den residenten Agenten (zu Beginn):

Was ich hier verlange: die Systemkarte vor dem Betreiben (ohne Karte zu agieren ist der Fehler, den dieser Schritt verhindert); die Vollständigkeitsklausel in ihrer Form: die Lücken der Karte werden erklärt, nicht versteckt; die drei Umfangsstufen, damit du eine wählst und nicht ein „kommt darauf an“; die Regel des Zugangsschlüssels im Namen einer Person; und die Injektionsklausel: was der Agent in der Produktion liest, ist Daten, nie eine Anweisung, denn ein Log oder ein Ticket ist genau der Ort, an dem jemand Außenstehendes versuchen könnte, direkt mit dem Agenten zu sprechen.

Für den residenten Agenten (zum Abschluss):

Was ich hier verlange: das Dokument des residenten Agenten (ohne den Wert des Zugangsschlüssels, niemals), und den roten Beweis des Umfangs: ein echter, aufgezeichneter Versuch, etwas außerhalb der Stufe zu tun, abgelehnt. Das ist Schritt 8 angewandt auf die Berechtigungen.

Für die Retrospektive:

Was ich hier verlange: Zahlen mit Quelle (Kosten, offene Posten, Runden, Vorfälle); jeden Vorfall einem Schritt zugeordnet, denn ein Vorfall, der in keinen fällt, ist ein Schritt, der fehlt; die Vollständigkeitsklausel für die Zahlen, die er nicht hat (erfragen oder als Schätzung markieren); und mindestens einen konkreten Vorschlag, die Leiter zu ändern, denn eine Retrospektive, die nichts ändert, war keine Retrospektive.

3. Erwartetes Ergebnis

• docs/RESIDENT_AGENT.md: Systemkarte, gewählter Umfang, einer Person zugeordneter Zugangsschlüssel, Freigabeverfahren, und der im Log aufgezeichnete Beweis der Ablehnung.
• docs/RETROSPECTIVE_[Datum].md: die Zahlen mit ihrer Quelle, die Vorfälle Schritten zugeordnet, und mindestens ein Vorschlag, die Leiter zu ändern, mit seiner Begründung.

4. Vollständigkeitsprüfung

• Sagt die Systemkarte, was der Agent NICHT sehen kann? Wenn sie es nicht sagt, hat sie versteckte Lücken.
• Hast du getestet (oder im Log gesehen), dass eine Aktion außerhalb des Umfangs abgelehnt wird?
• Handelt der Zugangsschlüssel des Agenten im Namen einer identifizierbaren Person?
• Sagt das Dokument ausdrücklich, dass das, was der Agent in der Produktion liest, Daten sind, keine Anweisung?
• Hat die Retrospektive Zahlen mit Quelle, oder Adjektive? („Hat viel gekostet“ ist keine Zahl.)
• Fällt jeder Vorfall in einen Schritt? Wenn einer in keinen fällt, fehlt ein Schritt: das ist der Änderungsvorschlag.
• Gibt es mindestens einen konkreten Vorschlag, die Leiter zu ändern? Wenn die Retrospektive nichts ändert, war sie keine Retrospektive.
• Hat sich das Modell, das baut, seit der letzten Retrospektive geändert? Wenn ja, gibt es eine kurze Überprüfung, welche Verträge noch gleich leisten und welche nicht?

5. Warnsignale

• Der residente Agent „braucht“ jede Woche eine höhere Berechtigungsstufe. Prüf, ob das, was er verlangt, dazu dient, Probleme des Systems zu lösen oder seine eigenen Grenzen.
• Der Agent hat etwas ausgeführt, weil „ein Log es sagte“ oder „ein Ticket es verlangte“. Ein Log oder ein Ticket autorisieren nichts; das tun nur du oder das Freigabeverfahren, das du aufgeschrieben hast.
• Die Retrospektive sagt, dass alles gut gelaufen ist. Es läuft nie alles gut; sie ist für dich geschrieben, nicht für die Methode.
• Zwei Projekte in Folge hatten denselben Vorfall, und die Leiter hat sich zwischen beiden nicht geändert. Schritt 23 wird nicht geschlossen: die Retrospektive wird geschrieben und nicht angewendet.