Automatischer Push: 2 Datei(en) geändert

- .claude/agents/planer.md
- AI/Regelwerk/codeworkflow.md

Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Pascal MichelandClaude Opus 5 committed 2026-10-27 03:00:01 +01:00
1 parent b404bf3601
commit b932a0cf17
2 files changed
+5 -1

No files matched your search

+3 -1
View File
@@ -5,7 +5,7 @@ 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-13
updated: 2026-10-26
---
# Codeworkflow
@@ -33,6 +33,8 @@ Dateikopf, CHANGELOG-Regel und Codedoku stehen seit 2026-08-30 in [[AI/Regelwerk
**Plankritik vor dem ersten Executer.** Ein Plan ab etwa drei Tasks wird, bevor ein Executer startet, von `pruefer`-Subagenten (Opus) mit getrennten Linsen gelesen: (1) Fixture-Arithmetik und Rot-Nachweise — jede Mindestzahl im Produktivcode gegen jede Fixture gerechnet, jede erwartete Fehlermeldung wörtlich; (2) Bezeichner, Signaturen über Taskgrenzen, Byte-Treue der Aus-Blöcke, Parsen der Codeblöcke, Prüf-greps nur auf Code; (3) Spec-Abdeckung in beide Richtungen. Der wirksamste Griff: Der Kritiker wendet alle Blöcke des Plans auf einer Kopie unter `/tmp` an und fährt die Suite dort. Beleg vom 2026-09-16/17 im Projekt „Trading Plattform" (Teil 9, fünf Tasks): 55 Befunde vor dem ersten Executer, darunter zwei blockierende Rechenfehler in Testerwartungen, dreimal ein grep auf die eigenen Kommentare und ein Fehler in der Referenzmessung des Koordinators; der Nachkritiker fand auf der materialisierten Fassung sechs weitere, darunter eine falsche Gültigkeitsgrenze („weit vor Zeile 30" — gemessen Zeile 60) und einen Mutanten, der nur ein zurückgespiegeltes Konfigurationsfeld traf. Danach liefen drei Executer-Wellen ohne eine einzige Abweichung durch. Ohne diese Runde wäre jeder dieser Befunde eine Executer-Meldung oder eine Korrekturrunde geworden — und der Koordinatorkontext ist die knappe Ressource (siehe Schritt 5).
**Rot bei neuen Modulen und Anker in Doku-Tasks (Pascal, 2026-10-26).** Zwei Planregeln stehen in `.claude/agents/planer.md` unter „Auftragsgrenzen“: Rot über fehlendes Modul oder Gerüst ist zulässig, wenn Mutanten jeden neuen Verhaltenszweig belegen; Doku-Tasks verankern nur an Titeln und stabilen Überschriften, nie an Versionsköpfen, `updated:`-Zeilen oder Text anderer Pakete, und `updated:` setzt der Koordinator am Umsetzungstag. Beides gilt auch für Pläne von Codex: Jeder Planungs- und Korrekturauftrag an Codex nennt die zwei Regeln, und die Plankritik prüft sie. Anlass: In der Nacht zum 2026-10-26 brachen Doku-Anker dreimal an korrigierten Vorgängerpaketen, und zwei Vorkritiken stuften Import-Rot als blockierend ein.
**Die Kopie mit dem angewendeten Plan bleibt stehen und ist der Vergleichsstand für jede Welle.** Steht der Code wörtlich im Plan, wendet der Koordinator alle Blöcke vor der ersten Welle per Skript auf eine Kopie des Baums an, fährt dort Suite und Mutanten und vergleicht nach jeder Welle zwei Dinge: ob genau die Zieldateien der Taskdateien geändert sind, und ob jede byte-gleich mit der Kopie ist. Beleg vom 2026-09-17 („Trading Plattform", 15 Tasks, vier Wellen): acht abweichende Dateien, sechs davon aus Berichten mit „keine Abweichungen", eine davon ein sichtbarer Fehler bei grünen Tests. Der Vergleich zeigt je Datei nur die erste Abweichung — danach immer `diff` auf die ganze Datei. Abweichungen an Einzelstellen setzt der Koordinator aus der Kopie, statt denselben Executer-Typ ein zweites Mal an dieselbe Fehlerklasse zu lassen. Die Skripte dafür liegen unter `.vault-tools/plan-kopie/` (Gebrauch in `LIESMICH.md` dort, samt der Warnung zur `node_modules`-Junction).
**Ein Plan ab etwa drei Tasks wird als Ordner angelegt, nicht als eine Datei:** `00-uebersicht.md` mit Ziel, Architektur, globalen Vorgaben, Dateiübersicht, Tasktabelle und Abnahme, dazu je Task eine Datei `task-NN-<thema>.md`. Jede Taskdatei verweist im Kopf auf die globalen Vorgaben der Übersicht, statt sie zu wiederholen — zwei Fassungen derselben Vorgabe laufen auseinander.