Codeworkflow: Korrektur nach der Plankritik als Ersetzungsliste (pending-review)

Beleg aus dem Paket FP der Trading Plattform: 129 Ersetzungen in sechs Dateien ohne Bruch. Das
Werkzeug ersetzungen_einsetzen.py liegt jetzt unter .vault-tools/plan-kopie/ (byte-gleich aus der
B4-Uebergabe), Gebrauch in LIESMICH.md, Schritt 9.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0126RDfXiECscXipzf67uypJ

AI/Regelwerk/codeworkflow.md

@@ -1,11 +1,11 @@
 ---
 type: resource
-status: reference
+status: pending-review
 title: Codeworkflow
 summary: Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen und Effort, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.
 tags: [regelwerk, codeworkflow, code-projekte]
 created: 2026-08-03
-updated: 2026-10-09
+updated: 2026-10-13
 ---
 
 # Codeworkflow
@@ -83,7 +83,7 @@ Für jede Prüfung, die eine **offene Menge** einschränkt (verbotene Aktionen,
 
 Faustregel: Lässt sich die Nachbesserung in einem Auftrag beschreiben, der für sich steht — geänderte Planstelle, Fehlerbild, erwartete Fehlermeldung —, dann ein frischer Subagent. Fortsetzen nur, wenn der Verlauf selbst gebraucht wird, etwa bei einer Fehlersuche über mehrere Runden.
 
-**Nachbesserung nach einer ausgeführten Welle als Delta, nicht als Neufassung.** Der `planer` schreibt dann neue Taskdateien mit `Aus:`/`wird:`-Blöcken und für ältere Tasks eine Folgenliste. Die Regel für ihn steht in `.claude/agents/planer.md`, weil er das Regelwerk nicht lädt. Dein Teil: Die Plankritik liest nur die neuen Tasks und die Folgenliste (`materialisieren.tasks`). Nach dem Anwenden läuft `plan_bloecke.py nach` auf einer frisch gebauten Kopie. Die Folgenliste setzt ein Executer ein, danach prüfst du die Zeilenenden mit `git ls-files --eol` oder `file`, nicht mit `grep`. Und die `spec.json` des Rot-Nachweises bekommt die neuen Tasks. Gemessen im Hub am 2026-09-24: rund 20 Minuten je Runde schneller als die Neufassung, drei gegen drei Runden, nicht kontrolliert. Am 2026-09-23 waren beim Neuschreiben 10 von 17 Befunden der Nachprüfung durch das Umschreiben selbst entstanden. Für die Korrektur nach der Plankritik vor der ersten Ausführung ist das Delta nicht belegt.
+**Nachbesserung nach einer ausgeführten Welle als Delta, nicht als Neufassung.** Der `planer` schreibt dann neue Taskdateien mit `Aus:`/`wird:`-Blöcken und für ältere Tasks eine Folgenliste. Die Regel für ihn steht in `.claude/agents/planer.md`, weil er das Regelwerk nicht lädt. Dein Teil: Die Plankritik liest nur die neuen Tasks und die Folgenliste (`materialisieren.tasks`). Nach dem Anwenden läuft `plan_bloecke.py nach` auf einer frisch gebauten Kopie. Die Folgenliste setzt ein Executer ein, danach prüfst du die Zeilenenden mit `git ls-files --eol` oder `file`, nicht mit `grep`. Und die `spec.json` des Rot-Nachweises bekommt die neuen Tasks. Gemessen im Hub am 2026-09-24: rund 20 Minuten je Runde schneller als die Neufassung, drei gegen drei Runden, nicht kontrolliert. Am 2026-09-23 waren beim Neuschreiben 10 von 17 Befunden der Nachprüfung durch das Umschreiben selbst entstanden. Auch die Korrektur nach der Plankritik vor der ersten Ausführung geht als Delta: Der `planer` liefert eine Ersetzungsliste im Format von `.vault-tools/plan-kopie/ersetzungen_einsetzen.py` (Gebrauch in `LIESMICH.md` dort, Schritt 9) und schreibt keine Datei neu; du setzt sie nach dem Prüflauf ein und baust die Kopie neu. Beleg vom 2026-10-13 („Trading Plattform“, Paket FP, vier Taskdateien mit je rund 1300 Zeilen): 129 Ersetzungen in sechs Dateien, Prüflauf ohne Befund, jede der 73 roten Zeilen des Plans beim ersten Messen wörtlich; nicht kontrolliert.
 
 **Die Nachbesserung folgt derselben Reihenfolge wie der Task selbst:** erst die neuen Tests, Fehlschlag im Wortlaut beobachten lassen, dann die Implementierung. Wer beides gleichzeitig schreiben lässt, bekommt einen grünen Lauf ohne Beleg, dass die neuen Tests je etwas gemessen haben.