Urazuke — der evolutiv-korrektive Weg: ein System normalisieren, das nicht mit der Methode geboren wurde, und danach die Leiter erklimmen

Autor: Pablo Kuschniroff, unterstützt von Claude Code. Version 1, 18. Oktober 2026. Diese Seite ist die zweite Hälfte der Methode: das Hauptdokument beschreibt den Weg eines neuen Projekts, und hier beschreibe ich, was ich tue, wenn das System schon existiert, ein anderer es gemacht hat (oder ich selbst es gemacht habe, „vibecodend“, ohne Beleg), und es jetzt korrigiert oder weiterentwickelt werden muss. Die seltsamen Wörter stehen im Glossar des Hauptdokuments; die realen Fälle in den Referenzen. Öffentliches Repository: github.com/pkuschnirof/urazuke.

Warum es diese Seite gibt

Als ich die Leiter schrieb, schrieb ich sie mit Blick auf den leeren Ordner: Schritt 0 entscheidet, ob das Projekt angegangen wird, Schritt 4 deployt das Skelett ohne Funktionalität, und erst in Schritt 5 erscheint das erste Ding, das der Nutzer sehen wird. Das ist der saubere Fall, und es ist der, der am besten lehrt. Aber es ist nicht der häufigste Fall. In der Praxis gibt es in den meisten Fällen, in denen mich jemand ruft, ein System, das schon läuft, mit Nutzern, die davon abhängen, gemacht von jemandem, der nicht mehr da ist, oder von einem Modell, von dem niemand einen Beleg verlangt hat, und die Anfrage lautet „reparier das“ oder „bau mir das dazu“. Mein eigenes Werkzeug ist in fremde Systeme im Diagnosemodus hineingegangen, lange bevor die Leiter geschrieben war Ref. 11, und das erste Mal, dass sich die Methode aus einem System in Produktion gespeist hat, geschah beim Blick auf eines, das schon existierte Ref. 12.

Und hier gibt es eine Falle, die ich benennen will, bevor ich weitermache: die Versuchung vor einem Altsystem ist, zwischen zwei Extremen zu wählen, die beide falsch sind. Das eine ist „ich schreibe es mit der Methode neu, von null“: es klingt sauber und endet fast immer in einem zweiten System, das es nie schafft, das erste zu ersetzen. Das andere ist „ich wende einfach die Schleife an, dafür gibt es ja die Schritte 5 bis 12“: es klingt pragmatisch und heißt, auf Sand zu bauen, denn die Schleife setzt voraus, dass es eine Vereinbarung gibt, eine Karte, eine Testumgebung, eine Batterie, die läuft, und ein Deployment, das sich wiederholt. Nichts davon existiert in einem System, das nicht mit der Methode geboren wurde. Dieser Weg ist der, der in der Mitte verläuft: zuerst wird normalisiert, ohne neu zu schreiben, und danach wird die Leiter erklommen.

Die Anwendungsfälle der Methode

Die Methode hat drei Anwendungsfälle, und es lohnt sich zu wissen, in welchem du steckst, bevor du den Agenten öffnest, denn es ändert sich, wo man einsteigt.

Was draußen bleibt, benannt, damit es nicht verwechselt wird: die technologische Migration (die Plattform, die Sprache, die Datenbank wechseln) ist kein Anwendungsfall der Methode; sie ist ein anderes Projekt, und sie fällt im Allgemeinen unter die Ausschlusskriterien von Schritt 0 Ref. 46. Wenn das System, das du erbst, kein zugängliches Repository hat oder seine Bildschirme sich nicht programmatisch bedienen lassen und auch nicht bedienbar gemacht werden können, ist das Angemessene nicht, es zu normalisieren, sondern ein neues Projekt, das es ersetzt, mit dem ganzen Schritt 0.

Und eine Klarstellung, die für den dritten Fall gilt: es ist egal, ob das Altsystem von einem anderen Team ist oder deines. Ein System, das du vor drei Monaten mit einem Modell gebaut hast, ohne Beleg, ist genauso ein Altsystem wie das, was ein Auftragnehmer vor drei Jahren gemacht hat. Es ändert sich der Aufwand, es zu lesen, nicht der Weg.

Das Prinzip: normalisieren ohne neu zu schreiben, mit allen Eingaben

Normalisieren heißt, das System in den Zustand zu bringen, den die Methode beim Öffnen der Schleife voraussetzt. Und ich tue es mit drei Regeln, über die ich nicht verhandle.

Und etwas, das den drei Regeln vorausgeht: auf diesem Weg gibt es ebenfalls keine Fristen. Die Methode ist ein Prozess, keine Versprechung von Geschwindigkeit; ein Altsystem zu normalisieren dauert, was das Altsystem verlangt, und das Einzige, was ich festlege, sind die Reihenfolge und die Tore.

Erstens: es wird nicht neu geschrieben. Die Normalisierung fasst keine Funktionalität an. Sie legt um das System herum, was ihm fehlt (die Vereinbarung, die Karte, die Testumgebung, die Batterie, das wiederholbare Deployment, die Sperren auf dem, was schon auf die Welt wirkt), und lässt das System dasselbe tun, was es vorher tat. Ein Altsystem geht häufiger an der Begeisterung des „ich räume alles auf“ kaputt als an dem Bug, der zu beheben war.

Zweitens: zwei Geschwindigkeiten. Es gibt einen Teil der Schuld, der vor jeder Änderung bezahlt wird, und den nenne ich den Sicherheitsgurt: das System in einer Testumgebung mit realitätsnahen Daten laufen lassen können, es wiederholbar deployen, die Geheimnisse außerhalb des Codes haben, und eine Charakterisierungsbatterie der kritischen Flüsse haben, die rot wird, wenn sich davon etwas ändert. Der Gurt ist ein hartes Tor: ohne ihn wird nichts geändert, mit einer einzigen schriftlichen Ausnahme für den Notfall in der Produktion, die ich weiter unten erkläre. Der Rest der Schuld wird beim Anfassen bezahlt: wenn ein Block in ein Modul eintritt, treten die Normalisierungsposten dieses Moduls mit ihm ein. Niemals „ein allgemeines Aufräumen“ vor dem Anfangen.

Drittens: alle Eingaben der vorherigen Etappen müssen existieren, auch wenn sie durch Selbsterschließung wiedergewonnen werden müssen. Das ist die Regel, die diesen Weg von „einfach die Schleife anwenden“ unterscheidet. Jeder Schritt des Startabschnitts erzeugt ein Artefakt, das die folgenden Schritte lesen: die Ersterhebung, das Eignungsblatt, die Arbeitsvereinbarung, die Projektdatei, der semantische Baum, die Erhebung der Mengendaten, die Dimensionierung, die Erhebung der Umgebungen, die Tore. Im neuen Projekt schreibt der Eigentümer diese Eingaben mit dem Agenten aus der Aufnahme heraus. Im Altsystem hat sie niemand geschrieben, und die Schleife kann ohne sie nicht anlaufen. Die Lösung ist nicht, sie zu überspringen: der Agent soll sie aus dem System selbst wiedergewinnen, indem er den Code liest, das Schema der Datenbank, die Konfiguration der Umgebungen, die Logs und das, was es an Dokumentation gibt, und jede Behauptung dieser Dokumente trägt eine Marke, woher sie stammt. Die Marken, die ich benutze, sind fünf: [Code], [Datenbank], [Konfiguration], [Dokumentation] und [erschlossen], dazu [Geschäft] für das, was der Eigentümer bestätigt oder korrigiert hat. Ein wiedergewonnenes Dokument mit Marken ist ein Dokument, das sich prüfen lässt, ohne Code zu lesen: der Eigentümer schaut sich die mit [erschlossen] markierten Behauptungen an und bestätigt oder korrigiert sie, und er schaut sich die mit [Code] markierten an, um zu sehen, ob das System tut, was er glaubt, dass es tut. Was nicht übereinstimmt, ist eine Diskrepanz, und die Diskrepanzen sind das Gold der Normalisierung: sie sind die Bugs, die niemand gemeldet hat, und die Regeln, die niemand entschieden hat.

Die Tabelle der wiedergewonnenen Eingaben

Damit es nicht abstrakt bleibt, hier jede Eingabe des Startabschnitts, wo sie im neuen Projekt entsteht, und wie sie auf dem evolutiv-korrektiven Weg beschafft wird.

Wenn am Ende von N7 eine dieser Dateien fehlt, ist der Abschnitt nicht erklommen. Es spielt keine Rolle, dass das System „funktioniert“: die Schleife wird sie in der ersten Sitzung brauchen.

Der Normalisierungsabschnitt: die acht Stationen

Ich nenne sie Stationen und nicht Schritte, und ich nummeriere sie N0 bis N7, damit sie nicht mit den vierundzwanzig der Leiter verwechselt werden. Es sind keine neuen Schritte: es sind die Schritte des Starts und drei aus dem Betrieb (die 11, die 13 und die 14), in anderer Reihenfolge und mit anderem Eingang. Im neuen Projekt ist der Eingang die Erhebung; hier ist der Eingang das System, und das Lesen übernimmt der Agent.

Die Reihenfolge ist wichtig. N3 kommt vor N4, weil das Audit sagt, was in den Gurt hineingehört (die Geheimnisse, die es gefunden hat, die Bildschirme, die sich nicht bedienen lassen, das Deployment, das sich nicht wiederholen lässt). N5 kommt nach dem Gurt, weil das Inventarisieren von Aktionen mit Konsequenz verlangt, dass man das System an einem Ort laufen lassen kann, an dem ein Fehler nichts kostet. N6 kommt zuletzt, weil es auf der Testumgebung mit Daten misst, die erst seit N4 existiert. Und N7 schließt ab, weil es alles Vorherige in einer einzigen Warteschlange zusammenführt.

Die Reihenfolge der Normalisierung

Es gibt keine Fristen: jede Etappe dauert, was das System verlangt, und das Einzige, was feststeht, ist die Reihenfolge.

Wenn das System groß ist, wächst die Etappe 1 (es gibt mehr zu lesen) und die Charakterisierungsbatterie der Etappe 2 (es gibt mehr Flüsse). Was nicht wächst, ist N7: ein Normalisierungs-Backlog, das sich nicht in einem Zug schreiben lässt, ist ein Backlog, das niemand pflegen wird.

N0 — Eignung eines bestehenden Systems: die Voraussetzungen, die ein Modell verifizieren kann

• Absicht: entscheiden, ob dieses System mit der Methode übernommen werden kann, bevor es angefasst wird, mit Kriterien, die nicht von einer menschlichen Einschätzung abhängen, sondern davon, was ein Frontier-Modell mit dem System tun kann und was nicht. Wenn eine Voraussetzung nicht erfüllt ist, ist das kein „geht nicht“: es ist ein eigenes Projekt, vorher, damit das System geeignet wird.
• Wann: einmal, vor allem anderen.
• Eingaben: die kurze Ersterhebung, Lesezugang zum Repository und, wenn möglich, zu der Umgebung, in der es läuft, und zu seiner Datenbank.
• Artefakt: docs/ELIGIBILITY.md mit der Entscheidung und den sieben ausschließenden Voraussetzungen des Altsystems, jede vom Agenten mit Beleg verifiziert, nicht von einer Person erklärt:
• Es lässt sich eine vollständige Umgebung des Systems aufbauen, mit all seinen Quellen, seinem Datenmodell und seiner Persistenz, aus dem Repository und einer Kopie der Daten.
• Der Code ist für ein Frontier-Modell verständlich und handhabbar: der Agent kann ihn ganz lesen und erklären, was jedes Modul tut, ohne zu erfinden.
• Aus dem Code heraus kann das Modell die vollständige Funktionalität des Systems in einem Dokument beschreiben, in einer Form, die ein Endnutzer als sein System wiedererkennt und akzeptiert.
• Das Frontend lässt sich von Testwerkzeugen durchlaufen, um Ende-zu-Ende-Tests zu erzeugen, mit jedem Element zugänglich und der Wirkung im Backend prüfbar (das ist X2).
• Das System lässt sich mit heute verfügbaren Werkzeugen aus den Quellen bauen und ausführen: die Abhängigkeiten lösen sich auf, die Versionen existieren, nichts hängt von einer verlorenen Binärdatei ab.
• Die Produktionsdaten lassen sich kopieren und anonymisieren für eine Testumgebung, und es gibt eine Sicherungskopie, die mindestens einmal wiederhergestellt wurde.
• Die externen Integrationen haben einen Testmodus oder lassen sich am Rand isolieren (ein falsches Postfach, ein Anbieter im Trockenlauf), damit die Aktionen mit Konsequenz ohne Konsequenzen geprüft werden können.
• Tor: alle sieben grün, mit dem Beleg des Agenten (die aufgebaute Umgebung, das geschriebene Funktionalitätsdokument, ein laufender Ende-zu-Ende-Test eines Flusses). Jedes Rot wird zu einem Vorprojekt mit seinem eigenen Ausgangskriterium.
• Wer entscheidet: der Agent verifiziert und legt den Beleg vor; der Eigentümer entscheidet, ob er die Vorprojekte angeht oder nicht.

Anfangs:

Was ich hier verlange: dass die Voraussetzungen durch Tun verifiziert werden (aufbauen, lesen, das Dokument schreiben, einen Test laufen lassen), denn ein Frontier-Modell kann alle vier Dinge tun, und damit hört die Eignung auf, eine Meinung zu sein; das Dokument der wiedergewonnenen Funktionalität, das der stärkste Beweis dafür ist, dass der Code handhabbar ist, und das außerdem der erste Entwurf dessen ist, was N2 in die Karte verwandeln wird; und dass jedes Rot mit dem Projekt kommt, das es grün macht, denn eine fehlende Voraussetzung ist keine Ablehnung, sondern eine Vorarbeit mit eigenem Umfang.

Vollständigkeitsprüfung: hat jede Voraussetzung einen Beleg für etwas, das der Agent getan hat, und nicht eine Antwort von dir? Existiert docs/FUNCTIONALITY_RECOVERED.md, und hast du es wie der Eigentümer gelesen: beschreibt es das System, das er zu haben glaubt? Hat er einen echten Ende-zu-Ende-Test eines Flusses laufen lassen? Hat jedes Rot sein Vorprojekt mit Ausgangskriterium? Warnsignal: alle an einem Nachmittag grün, für ein System, das niemand versteht. Der Agent hat geantwortet, statt zu tun.

N1 — Die Arbeitsvereinbarung für ein Altsystem

• Absicht: die Regeln festlegen, bevor irgendetwas angefasst wird, mit fünf Regeln mehr als Schritt 1, nämlich denen, die ein geerbtes System braucht, damit der Agent es nicht auf eigene Faust „verbessert“.
• Wann: nach N0, bevor irgendetwas gelesen wird.
• Eingaben: deine Arbeitsvorlieben, wie in Schritt 1.
• Artefakt: docs/WORKING_AGREEMENT.md mit den sechs Regeln der Methode und den fünf des Altsystems.
• Tor: die Vereinbarung hat Datum und Version, und die Projektdatei (wenn sie in N2 existiert) ordnet an, sie zu lesen.
• Wer entscheidet: der Eigentümer.

Anfangs:

Was ich hier verlange: die sechs Regeln wie immer, und fünf, die es gibt, weil ein Modell vor fremdem Code drei Dinge reflexhaft tut: es ordnet ihn um, es „repariert“ ihn dort, wo er ihm falsch erscheint, und es nimmt an, dass das, was der Code tut, ein Fehler ist, wenn es von dem abweicht, was es selbst erwarten würde. Die Regeln 7, 9 und 10 blockieren genau diese drei Reflexe. Die Regel 8 verwandelt das Lesen in Karte, damit das, was der Agent über ein Modul lernt, beim Schließen der Sitzung nicht verloren geht. Die 11 ist der Sicherheitsgurt als Regel geschrieben, damit er existiert, bevor die Batterie existiert.

Zum Abschluss: der Abschluss-Prompt von Schritt 1, unverändert: du nimmst die Vorschläge an oder lehnst sie mit Begründung ab, und die Vereinbarung bekommt Datum und Version.

Warnsignal: der Agent schlägt als Regel „den Code modernisieren, während er angefasst wird“ vor. Diese Regel ist die verkleidete Neuschreibung; lehn sie mit schriftlicher Begründung ab.

N2 — Das Lesen des Systems: die wiedergewonnene Karte und die Diskrepanzen

• Absicht: dass die Karte existiert, die Schritt 2 in einem neuen Projekt erzeugt, aber aus dem System selbst gezogen, mit Quellenmarken, und mit der Liste von allem, was zwischen dem Code, der Datenbank, der Dokumentation und dem, was das Geschäft glaubt, nicht übereinstimmt. Es ist Schritt 2 durch Reverse Engineering, und es ist der Schritt, der pro Stunde den meisten Wert des ganzen Weges bringt.
• Wann: nach N1, mit dem Eigentümer verfügbar zum Bestätigen.
• Eingaben: das vollständige Repository, das Schema der Datenbank nur lesend, die Konfiguration jeder Umgebung, die Logs, falls es welche gibt, die Dokumentation, die existiert, und die kurze Erhebung aus N0.
• Artefakt: docs/INITIAL_SURVEY.md mit Marken vervollständigt; PROJECT.md; docs/SEMANTIC_TREE.md mit jedem Knoten markiert; docs/STATUS.md; und die Liste der Diskrepanzen, jede vom Eigentümer entschieden und in docs/DECISIONS.md geschrieben.
• Tor: kein Knoten [erschlossen] ohne Urteil des Eigentümers; keine Diskrepanz ohne Entscheidung oder ohne offenen Posten; die Leseprobe von Schritt 2 bestanden.
• Wer entscheidet: der Eigentümer, Diskrepanz für Diskrepanz.

Anfangs:

Was ich hier verlange: dass er alles liest und erklärt, was er nicht lesen konnte (die Vollständigkeitsklausel in ihrer Altsystem-Form: die Lücke wird markiert, nicht gefüllt); dass die Erhebung und der Baum mit Quellenmarken an jeder Behauptung herauskommen, denn diese Marke ist das, was dir erlaubt, ohne Code zu lesen zu prüfen; dass die Prozesse und die Zustände die sind, die der Code umsetzt, nicht die, die sein sollten, denn das aktuelle Verhalten ist die Spezifikation (Regel 10 der Vereinbarung); dass er die geplanten Prozesse einschließt, die niemand erinnert und die am meisten Schaden anrichten; und dass die Diskrepanzen mit dem Beleg jeder Seite und ungelöst aufgelistet bleiben, denn sie zu lösen heißt zu entscheiden, und entscheiden ist deine Sache.

Was ich hier verlange: dass die Entscheidung über jede Diskrepanz an den drei üblichen Orten landet (das Entscheidungsregister, der offene Posten, falls etwas zu ändern ist, der Baum, falls bestätigt wird), und dass die Quellenmarken beim Abschließen nicht gelöscht werden: ein Baum, der die Marken verloren hat, ist ein Baum, der sich nicht mehr prüfen lässt.

Vollständigkeitsprüfung: geh den Baum als Eigentümer durch: gibt es einen Entitätszustand, den das Geschäft nie benutzt hat? Wenn er [Code] markiert ist, hat das System ihn, auch wenn ihn niemand benutzt, und das ist eine Diskrepanz. Gibt es einen geplanten Prozess im Baum? Wenn es keinen gibt, frag den Agenten, wo er gesucht hat. Hat jede Diskrepanz eine Entscheidung mit Datum? Hat er die Leseprobe von Schritt 2 bestanden (eine neue Sitzung weiß, was das System NICHT tut)? Warnsignale: der Baum hat nichts mit [erschlossen] markiert (der Agent unterscheidet nicht zwischen dem, was er gelesen, und dem, was er angenommen hat); die Liste der Diskrepanzen ist leer (in einem Altsystem ist sie nie leer: der Agent hat schlecht verglichen oder gar nicht verglichen); die Projektdatei überschreitet die dreihundert Zeilen, weil „es viel zu dokumentieren gab“ (das gehört in den Baum, und was passiert ist, gehört in den lebendigen Stand Ref. 41).

N3 — Das Audit als Inventar der Schuld

• Absicht: Schritt 13, aber am Anfang und mit einer zusätzlichen Frage pro Befund: blockiert er, wird er beim Anfassen des Moduls bezahlt, oder kann er warten? Der Bericht ist kein Bericht: er ist der Rohstoff des Gurts (N4) und des Backlogs (N7). In meinem ersten Projekt, das mit der schon geschriebenen Methode anlief, verwandelte sich die Serie der frühen Audits direkt in offene Posten Ref. 30; hier mache ich dasselbe an einem fremden System.
• Wann: nach N2, in einer anderen Sitzung als der, die das System gelesen hat, wenn das möglich ist.
• Eingaben: das Repository nur lesend, die Umgebung, in der es läuft, nur lesend, die wiedergewonnene Karte (N2).
• Artefakt: docs/AUDIT_[Datum].md mit jedem Befund markiert als „blockiert / wird beim Anfassen bezahlt / kann warten“.
• Tor: kein Befund ohne Geschwindigkeitsmarke; die blockierenden haben einen offenen Posten, bevor N4 beginnt.
• Wer entscheidet: der Eigentümer, über die Geschwindigkeitsmarken.

Anfangs:

Was ich hier verlange: das Audit von Schritt 13 mit der hinzugefügten Dimension „Deploybarkeit“ (denn in einem Altsystem ist das Deployment meist das erste Problem) und mit dem Geschwindigkeitsfeld, das einen Bericht in einen Plan verwandelt: ohne dieses Feld hat ein auditiertes Altsystem vierzig Befunde und niemand weiß, womit er anfangen soll. Das Kriterium, was blockiert, gebe ich vor, nicht der Auditor, denn es hängt von den Konsequenzen des Geschäfts ab.

Zum Abschluss: der Abschluss-Prompt von Schritt 13, an den Konstrukteur, mit einer Ergänzung: die offenen Posten, die er eröffnet, tragen die Geschwindigkeitsmarke des Befunds.

Prüfung: sagt der Bericht, was er NICHT auditieren konnte? Gibt es mindestens einen Befund mit der Marke „blockiert“? (In einem Altsystem gibt es immer einen; wenn nicht, hat der Auditor weder die Geheimnisse noch das Deployment angesehen.) Haben zwei zufällige Befunde Datei, Zeile und reproduzierbaren Beleg? Warnsignal: alles steht auf „kann warten“. Das ist ein Auditor, der nicht stören will.

N4 — Der Sicherheitsgurt

• Absicht: dass um das System herum und ohne seine Funktionalität anzufassen das existiert, was es sicher macht, es zu ändern: eine Testumgebung mit realitätsnahen Daten, ein Deployment, das sich wiederholt, die Geheimnisse außerhalb des Codes, die Continuous Integration, die laufen lässt, was es gibt, und die Charakterisierungsbatterie der kritischen Flüsse. Es ist Schritt 4, die erste Hälfte von Schritt 15 und eine umgekehrte Form von Schritt 8, zusammen und vor jeder Änderung. Es ist ein hartes Tor: solange der Gurt nicht grün ist, wird keine Zeile Funktionalität geändert.
• Wann: nach N3, vor jeder Änderung.
• Eingaben: die Erhebung der Umgebungen (in N2 wiedergewonnen und von dir bestätigt), der Bericht aus N3 mit seinen blockierenden Befunden, der semantische Baum mit den Prozessen, und Zugang zum Server und zur Datenbank.
• Artefakt: die Testumgebung, die mit anonymisierten Daten läuft; docs/DEPLOYMENT.md mit dem zweimal wiederholten Deployment in den Test; die Geheimnisse in der Konfiguration des Servers und rotiert; die Continuous Integration grün; docs/GATES.md; und die Charakterisierungsbatterie grün, mit dem bewiesenen Rot für jeden Fluss.
• Tor: Screenshot des im Test laufenden Systems, von dir gesehen; zweiter Lauf des Deployments ohne Änderungen; Suche nach Geheimnissen im Repository leer; Charakterisierungsbatterie grün und jeder Test durch Mutation rot bewiesen.
• Wer entscheidet: der Eigentümer, darüber, welche Flüsse kritisch sind, und über die Anonymisierung der Daten.

Für die Umgebung, das Deployment und die Geheimnisse:

Was ich hier verlange: das Skelett von Schritt 4, um etwas herum gebaut, das schon existiert, mit der halben Schritt 15 vorgezogen (Geheimnisse draußen, Deployment dokumentiert), denn in einem Altsystem sind die Geheimnisse im Code die Regel und nicht die Ausnahme Ref. 42; die Anonymisierung als Teil der Umgebung und nicht als Detail; und die Tore geschrieben, bevor die Batterie existiert, damit die Batterie schon als Tor geboren wird.

Was ich hier verlange: Schritt 8 verkehrt herum. Im neuen Projekt wird der Test rot geboren und geht mit der Änderung auf Grün; hier wird der Test grün geboren, denn er erfasst, was da ist, und der Beweis, dass er taugt, ist, dass er rot wird, wenn du den Fluss absichtlich kaputt machst. Ohne diese bewiesene Mutation ist ein Charakterisierungstest ein Test, der besteht, weil er nichts ansieht, und das ist dasselbe Problem wie das Grün, das einen Bug verbirgt Ref. 44. Und die zwei Disziplinklauseln: was sich nicht bedienen lässt, wird erklärt und blockiert, und was falsch aussieht, wird als Diskrepanz notiert und nicht repariert, denn bis der Eigentümer entscheidet, ist das aktuelle Verhalten die Spezifikation.

Vollständigkeitsprüfung: hast du selbst die URL der Testumgebung geöffnet und das System mit Daten gesehen? Hast du einen echten Namen in diesen Daten gesucht und ihn nicht gefunden? Lief das Deployment zweimal und hat der zweite Lauf nichts geändert? Hast du die Suche nach Geheimnissen im Repository verlangt und kam sie leer zurück? Hast du jedes Geheimnis der Liste rotiert? Hat jeder kritische Fluss seinen Test, und hat jeder Test sein Rot durch Mutation sichtbar? Warnsignale: die Charakterisierungsbatterie bestand ganz „auf Anhieb“ und es wurde nie ein Rot gezeigt; die Testumgebung läuft „auf der Maschine des Agenten“ und nicht an einem Ort, den du öffnen kannst; die Testdaten sind „ein paar Beispieldatensätze“ statt einer anonymisierten Kopie (die Bugs eines Altsystems leben in den echten Daten, nicht in den Beispieldaten).

N5 — Sperren und Produzenten-Konsumenten-Karte aus dem Code

• Absicht: wissen, bevor irgendetwas geändert wird, was das System tut, das auf die Welt wirkt (abbuchen, senden, genehmigen, löschen, benachrichtigen, nachts allein laufen) und wer jeden Vertrag zwischen Teilen produziert und konsumiert. Im neuen Projekt wird das vor dem Bauen entschieden (Schritt 14) und beim Bauen kartiert (Schritt 11). Im Altsystem ist es schon gebaut, und niemand erinnert es vollständig. Eine evolutive Änderung kann eine Aktion mit Konsequenz auslösen, die schlief, und eine korrektive Änderung kann einen Konsumenten veraltet zurücklassen.
• Wann: nach dem Gurt, denn Aktionen zu inventarisieren verlangt, das System dort laufen lassen zu können, wo ein Fehler nichts kostet.
• Eingaben: der Code, die Datenbank, die geplanten Prozesse des Servers, der semantische Baum, und die Liste von dem, was außerhalb des Repositorys lebt.
• Artefakt: docs/CONSEQUENTIAL_ACTIONS_SURVEY.md mit Quellenmarken, docs/PRODUCER_CONSUMER_MAP.md, und nach dem Abschluss docs/LOCKS.md mit den Sperren, die jetzt kommen, und denen, die später kommen.
• Tor: keine Aktion mit Konsequenz ohne Urteil des Eigentümers; die als „jetzt“ markierten Sperren implementiert mit ihrem roten Test vor dem ersten Block.
• Wer entscheidet: der Eigentümer, Sperre für Sperre.

Anfangs:

Was ich hier verlange: das Inventar der Schritte 14 und 11 in einem Durchgang, denn sie durchlaufen denselben Code; den Vergleich zwischen dem, was das Geschäft erinnert, und dem, was der Code tut, wo die Versendungen auftauchen, an die sich niemand erinnerte; und den Vorschlag jetzt oder beim Anfassen für jede Sperre, der die Regel der zwei Geschwindigkeiten auf den Schutz angewendet ist: eine Sperre auf einer Aktion, die abbucht, kommt jetzt; eine Sperre auf einem monatlichen Export kann auf den Block warten, der dieses Modul anfasst.

Zum Abschluss: der Abschluss-Prompt von Schritt 14, mit den als „jetzt“ markierten Sperren, jede mit ihrem roten Test gegen die Version ohne Sperre; die übrigen bleiben im Backlog mit ihrer Marke.

Warnsignal: der Agent hat genau dieselben Aktionen gefunden, die das Geschäft aufgelistet hat. In einem Altsystem passiert das nie; es fehlte der Blick auf die geplanten Aufgaben oder auf die Trigger der Datenbank.

N6 — Dimensionieren mit echten Zahlen

• Absicht: Schritt 3, aber mit dem enormen Vorteil des Altsystems: die Primärdaten muss man nicht erfragen, sie stehen in der Datenbank und in den Logs. Sie werden mit Schritt 7 gemessen (ein Messgerät mit Test, in zwei Richtungen auditiert), und der Eigentümer steuert nur bei, was nirgends steht: wie stark sie zu wachsen erwarten und ob das System an andere verkauft werden wird.
• Wann: nach N5, bevor der erste Block geöffnet wird.
• Eingaben: die Produktionsdatenbank nur lesend oder die vollständige Testkopie, die Logs, der semantische Baum mit den Entitäten.
• Artefakt: docs/VOLUME_SURVEY.md mit jeder Zahl markiert als [Datenbank] oder [Log] und ihrem Befehl, die Messgeräte im Repository mit ihrem Test, und docs/SIZING.md mit dem „mal zehn“ und den asymmetrischen Entscheidungen, die vor dem Weiterentwickeln zu treffen sind.
• Tor: keine Primärzahl ohne Messgerät; eine von dir nachgerechnete Zahl, die übereinstimmt.
• Wer entscheidet: der Eigentümer, über das erwartete Wachstum und die asymmetrischen Entscheidungen.

Anfangs:

Was ich hier verlange: messen statt fragen, was das Altsystem erlaubt und das neue Projekt nicht; das Messgerät mit Test und das Audit in zwei Richtungen aus Schritt 7, denn Messgeräte lügen Ref. 35, Ref. 36; und die Dimensionierung als Tor vor dem Weiterentwickeln Ref. 14: wenn die aktuelle Architektur das „mal zehn“ nicht aushält und die Anfrage des Kunden genau das Wachsen ist, weiß man das jetzt und nicht im dritten Block.

Zum Abschluss: der Abschluss-Prompt von Schritt 3, bei dem du zwischen den Optionen wählst, die er für das vorgeschlagen hat, was nicht aushält, oder bestätigst, dass das Aktuelle aushält.

Warnsignal: eine „ungefähre“ Zahl ohne Marke „ungefähr“. Wenn sie in der Datenbank steht, wird sie gemessen; wenn sie nicht darin steht, wird sie erfragt; eine dritte Möglichkeit gibt es nicht.

N7 — Das Normalisierungs-Backlog, gepaart mit der Anfrage des Kunden

• Absicht: eine einzige Warteschlange offener Posten, mit vollständiger Spezifikation, in der die Schuld (was aus dem Audit, den Diskrepanzen, den nicht bedienbaren Bildschirmen, den ausstehenden Sperren, den Entscheidungen der Dimensionierung kam) und die Anfrage des Kunden (was zu korrigieren und was hinzuzufügen ist) zusammenleben, jeder mit seiner Geschwindigkeitsmarke und nach Modul gepaart. Es ist Schritt 5 mit zwei Spalten mehr.
• Wann: zum Abschluss des Abschnitts. Danach die Schleife.
• Eingaben: docs/AUDIT_[Datum].md, docs/DISCREPANCIES.md mit den Entscheidungen, docs/LOCKS.md, docs/SIZING.md, der semantische Baum, und die Anfrage des Kunden für diese Etappe.
• Artefakt: docs/PENDING.md mit allen spezifizierten offenen Posten, markiert als „blockiert / wird beim Anfassen bezahlt / kann warten“ und „korrektiv / evolutiv / Normalisierung“, und die Paarung nach Modul.
• Tor: vor dem ersten Block bleibt kein als „blockiert“ markierter offener Posten offen; jeder offene Posten des Kunden hat die Normalisierungsposten aufgelistet, die mit ihm eintreten.
• Wer entscheidet: der Eigentümer, über die Reihenfolge.

Anfangs:

Was ich hier verlange: den vollständigen Schritt 5 (die detaillierte Spezifikation lebt in jedem offenen Posten, auch in denen der Normalisierung), mit den zwei Marken, die diesen Weg ausmachen: die Geschwindigkeit, die sagt, wann jede Schuld bezahlt wird, und der Typ, der sagt, wie sie geschlossen wird (ein korrektiver wird mit dem Test geschlossen, der den Fehler reproduziert; ein evolutiver mit dem aus Schritt 8). Und die Paarung nach Modul, die die Regel „wird beim Anfassen bezahlt“ operativ macht: wenn ich den Block „die Anzahlung“ öffne, treten die Normalisierungsposten des Zahlungsmoduls mit ihm ein, und nicht vorher und nicht nachher.

Zum Abschluss: die Routine jeder Sitzung aus Schritt 5, unverändert, in der Arbeitsvereinbarung.

Vollständigkeitsprüfung: bleibt ein „blockiert“ offen? Dann wird der erste Block nicht geöffnet. Sagt jeder korrektive Posten, wie er reproduziert wird, mit den Worten des Kunden? Hat jeder offene Posten des Kunden seine Liste der gepaarten, und sei sie leer? Warnsignal: das Backlog hat mehr als fünfzig Normalisierungsposten auf „kann warten“. Das ist keine registrierte Schuld: das ist die als Liste verkleidete Neuschreibung. Archivier, was nie bezahlt werden wird, und sag es.

Die Schleife über einem geerbten System: korrektiver Modus und evolutiver Modus

Nach N7 trifft der Weg auf die Leiter: die Schritte 5 bis 12 werden mit jedem offenen Posten erklommen, genau wie im neuen Projekt, mit denselben Verträgen und denselben Prompts. Aber es gibt zwei Nuancen, die einen eigenen Abschnitt wert sind, denn sie sind das, was „ein Altsystem mit Methode anfassen“ von „ein Altsystem vorsichtig anfassen“ unterscheidet.

Der korrektive Modus: das Rot ist natürlich

Ein korrektiver offener Posten ist ein Bug: etwas, das heute fehlschlägt, und der Kunde weiß es. In Schritt 8 des neuen Projekts wird das Rot hergestellt (der Test wird geschrieben, gegen den alten Code ausgeführt, man sieht ihn fehlschlagen). Im korrektiven Modus ist das Rot der Bug selbst: der Test, der den Fehler reproduziert, indem er den Fluss vom Bildschirm aus bedient wie der Nutzer, der ihn gemeldet hat, muss gegen den aktuellen Code fehlschlagen. Wenn er nicht fehlschlägt, hast du nicht den Bug reproduziert, den man dir gemeldet hat; du hast einen anderen reproduziert. Dieses Rot ist der Beweis, dass du das Richtige reparierst, und es ist mehr wert als jede Erklärung des Agenten darüber, „was wohl passieren muss“. Der Fall der vier Runden bis zur Grundursache Ref. 22 ist der, der mich gelehrt hat, dass ohne geschriebene Reproduktion jede Runde ein anderes Symptom repariert.

Zum Schließen eines korrektiven offenen Postens:

Was ich hier verlange: die Reproduktion vor der Diagnose, denn ein Modell diagnostiziert mit großer Sicherheit, was es nicht reproduziert hat; die Grundursache in Prosa vor dem Anfassen, damit du eine Reparatur stoppen kannst, die daneben zielt; die Wurzel und nichts weiter, denn in einem Altsystem ist „wenn ich schon dabei bin“ die häufigste Art, kaputt zu machen, was lief; die grüne Charakterisierung als Regression des ganzen Systems; und die Klausel 5, die die Verhaltensänderung in eine Entscheidung verwandelt. Und die Paarung: die Schuld dieses Moduls wird jetzt bezahlt, mit ihrem Beleg, nicht „später“.

Der evolutive Modus: die Charakterisierung ist die Regression

Ein evolutiver offener Posten ist etwas Neues auf etwas, das existiert. Er wird mit dem Prompt von Schritt 5 geöffnet, mit Schritt 6 und 8 genau so gebaut, und der einzige Unterschied ist, was „die Regression der Nachbarn“ bedeutet: hier sind die Nachbarn das ganze System, und die Charakterisierungsbatterie ist die, die sagt, dass das, was lief, weiter läuft. Zwei Regeln mehr. Erstens: wenn der Block in ein Modul eintritt, treten die als „wird beim Anfassen bezahlt“ markierten Normalisierungsposten dieses Moduls mit ihm ein, mit ihrem eigenen Beleg; das ist die Regel der zwei Geschwindigkeiten. Zweitens: das Neue wird schon mit der vollständigen Methode geboren, das heißt, mit seiner Spezifikation im offenen Posten, seinem roten Test, seinem Ende-zu-Ende-Test und seiner Sperre, falls es auf die Welt wirkt. Man tut dem neuen Modul nicht an, was das Altsystem dem alten angetan hat.

Die Ausnahme: der Notfall in der Produktion

Der Gurt ist ein hartes Tor, und ein hartes Tor braucht seine schriftliche Ausnahme, denn wenn ich sie nicht schreibe, wird die Ausnahme an dem Tag erfunden, an dem um elf Uhr nachts etwas abstürzt. Die Ausnahme ist diese: wenn die Produktion steht oder Daten beschädigt und der Gurt noch nicht vollständig ist, macht man das Minimum, das den Schaden stoppt, mit dem Rückweg von Hand und mit dem informierten Eigentümer, und am selben Tag wird der korrektive offene Posten eröffnet und mit der vollständigen Routine geschlossen: der Test, der ihn in Rot reproduziert, die Grundursache, die Regression. Eine Notfallreparatur, die nicht wieder durch die Schleife eintritt, ist Schuld, die mit Zinsen eingetrieben wird.

Was ich hier verlange: das Minimum, mit dem Rückweg vorher und nicht nachher, und mit dem ehrlichen Bericht über das Nichtverifizierte (Schritt 12); und die Pflicht, am selben Tag wieder durch die Schleife einzutreten, was eine Ausnahme von einer Gewohnheit unterscheidet.

Die sechs Schritte der Betriebsqualität (16 bis 19, 21 und 22) in einem Altsystem

Die Schritte 16 bis 19, 21 und 22 des Hauptdokuments (Beobachtbarkeit und Nachverfolgbarkeit, Persistenz, Schwachstellen, Leistung und die beiden Monitorings) gelten für beide Anwendungsfälle, und in einem Altsystem haben sie einen präzisen Platz, denn bei mehreren von ihnen ist die halbe Arbeit schon vom Normalisierungsabschnitt erledigt:

• 16, Beobachtbarkeit und Nachverfolgbarkeit: das Mindestniveau (strukturierte Logs mit konfigurierbarem Level und eine Korrelations-ID in den kritischen Flüssen) gehört in den Sicherheitsgurt (N4), denn ohne es sagt die Charakterisierungsbatterie nicht, was kaputtgegangen ist. Das vollständige Niveau, mit dem unveränderlichen Audit-Log der Aktionen mit Konsequenz, die N5 inventarisiert hat, wird vor dem ersten Deployment nach der Normalisierung erklommen.
• 17, Persistenz: die Messungen sind in N6 schon gemacht. Was aus ihnen folgt, kommt mit seiner Marke in das Backlog (N7): was schon außerhalb der Toleranz des Geschäfts liegt, „blockiert“ oder „jetzt“; der Rest „wird beim Anfassen bezahlt“ und kommt mit dem Block herein, der dieses Modul berührt.
• 18, Schwachstellen: der erste Durchlauf ist die Sicherheitsdimension des Audits von N3, und der Scan in der Kette ist Teil des Gurts (N4), denn ein Altsystem hat fast immer alte Abhängigkeiten und Geheimnisse in der Historie. Die P0 blockieren; der Rest kommt ins Backlog.
• 19, Leistung: er läuft mit den in N6 gemessenen Volumina, auf der Persistenz, die in dem schon korrigiert wurde, was blockierte, vor dem ersten Deployment nach der Normalisierung. In einem Altsystem entdeckt er meist, dass der Bruchpunkt näher liegt, als das Geschäft glaubt.
• 21 und 22, Monitoring: sie werden mit dem ersten Deployment aufgebaut, genau wie im neuen Projekt, mit einem Unterschied: die erste Lesung des Berichts ist die Basislinie des Altsystems, und die Abweichungen und die Fehler, die am ersten Tag schon existierten, werden zu offenen Posten mit ihrer Geschwindigkeitsmarke. Keiner bleibt als „bekannt“ ohne offenen Posten.

In der Praxis sind die vier vor dem Deployment eine weitere Etappe der Normalisierung, vor dem ersten evolutiven Block oder zusammen mit ihm, je nach Dringlichkeit der Anfrage, und die beiden Monitorings werden mit dem Deployment aufgebaut.

Wann das System normalisiert ist

Nie ganz, und das ist gut so: die als „wird beim Anfassen bezahlt“ markierte Schuld wird über Monate bezahlt, Modul für Modul, und die als „kann warten“ markierte wird manchmal nie bezahlt, und das muss man sagen. Was sehr wohl einen genauen Moment hat, ist der Abschluss des Abschnitts, nämlich dann, wenn der erste Block geöffnet wird. Das ist die Liste:

1. Es existieren alle Eingaben aus der Tabelle der wiedergewonnenen Eingaben, mit Quellenmarken, und der Eigentümer hat jeden Knoten [erschlossen] des Baums bestätigt (N2).
2. Jede Diskrepanz hat eine Entscheidung mit Datum, und die, die das System ändern, haben einen offenen Posten (N2).
3. Das Audit existiert und jeder Befund hat eine Geschwindigkeitsmarke (N3).
4. Der Gurt ist grün: Testumgebung mit anonymisierten Daten, die du geöffnet hast; Deployment zweimal gelaufen; Suche nach Geheimnissen leer und die gefundenen rotiert; Continuous Integration grün; Charakterisierungsbatterie grün mit dem bewiesenen Rot durch Mutation für jeden kritischen Fluss (N4).
5. Jede Aktion mit Konsequenz hat ein Urteil, und die als „jetzt“ markierten Sperren haben ihren roten Test (N5).
6. Die Primärzahlen sind mit Messgerät und Test gemessen, und das „mal zehn“ steht geschrieben (N6).
7. Es bleibt kein als „blockiert“ markierter offener Posten offen, und jeder offene Posten des Kunden hat seine gepaarten (N7).
8. Die Arbeitsvereinbarung hat die fünf Regeln des Altsystems, und eine neue Sitzung besteht die Leseprobe (N1, N2).

Wenn alle acht „ja“ ergeben, ist das System so weit normalisiert, wie dieser Weg es verlangt, und was folgt, ist die Leiter wie immer. Die Phasen 3 und 4 des Hauptdokuments (Produktionsfreigabe und Betrieb) gelten unverändert: das periodische Audit, die Handbücher (die es in einem Altsystem meist nicht gibt und die mit Schritt 20 aus dem System, wie es ist, erzeugt werden), der residente Agent, und die Retrospektive mit Zahlen, die in einem Altsystem eine eigene Frage hat: wie viel das Normalisieren gekostet hat, und was von der als „kann warten“ markierten Schuld am Ende doch gekostet hat.

Warnsignale des ganzen Weges

• Der Agent schlägt vor, ein Modul neu zu schreiben, „weil das einfacher ist, als es zu verstehen“. Das ist die verletzte Regel 7 der Vereinbarung; in einem Altsystem ist Verstehen die Arbeit.
• Man hat angefangen, Funktionalität zu ändern, mit halb fertigem Gurt („die Batterie machen wir später fertig“). Später kommt nie, und die erste Änderung ohne Batterie ist die, die kaputt macht, wovon niemand wusste, dass es existiert.
• Die Liste der Diskrepanzen wurde gelöst, indem „der Code so repariert wurde, dass er tut, was das Geschäft sagt“, ohne dass der Eigentümer jede einzelne entschieden hat. Einige dieser Diskrepanzen sind Regeln, die das Geschäft vergessen und der Code erinnert hat.
• Das Normalisierungs-Backlog wächst schneller, als es bezahlt wird. Es ist falsch markiert: es gibt Dinge auf „wird beim Anfassen bezahlt“, die „kann warten“ sind, oder es gibt Module, die angefasst werden, ohne ihre Schuld zu bezahlen.
• Die Zahlen der Dimensionierung stammen aus einer Schätzung, „weil die Datenbank zu groß ist, um sie zu zählen“. Eine große Datenbank zählt man mit einer Abfrage; das ist ein Messgerät.
• Eine Notfallreparatur ist nicht wieder durch die Schleife eingetreten. Zähl, wie viele es im Monat gab; wenn es mehr als eine ist, ist der Gurt kein Tor, sondern Dekoration.

Was noch auszuarbeiten ist Hypothese

1. Die sieben Voraussetzungen von N0 werden durch Tun verifiziert, und das macht sie kalibrierbar: jedes Altsystem, das durch N0 geht, hinterlässt sein Blatt mit Beleg. Was fehlt, ist die Kasuistik: wie viele Altsysteme an welcher Voraussetzung scheitern und was das Vorprojekt kostet, das sie grün macht. Es ist keine Hypothese mehr über das Kriterium; es ist eine Rechnung, die ich noch nicht habe.
2. Die Größe der Charakterisierungsbatterie: zwischen vier und acht Flüssen ist das, was bei mir in kleinen Systemen funktioniert hat; in einem großen weiß ich nicht, ob das Kriterium pro Fluss, pro Modul oder nach dem Geld läuft, das auf dem Spiel steht.
3. Wie sich die Normalisierung in einem großen System aufteilt: ich vermute, dass das Lesen (N2) ganz gemacht wird, der Gurt (N4) aber pro Modul aufgebaut wird, in dem Maß, in dem jedes Modul angefasst werden soll, und dass das harte Tor dann hart pro Modul wird und nicht pro System. Ich habe es nicht erprobt.
4. Was mit einem Altsystem passiert, das von einem Modell mit halber Methode gebaut wurde (Vereinbarung ja, Tests nein): ob dieser Weg ganz gegangen wird oder ob es eine Abkürzung gibt. Meine Intuition ist, dass es keine Abkürzung gibt und dass die Abkürzung genau der Fehler ist, aber es ist Intuition.