diff --git a/.claude/agents/planer.md b/.claude/agents/planer.md index 7b8e898..b37b184 100644 --- a/.claude/agents/planer.md +++ b/.claude/agents/planer.md @@ -18,6 +18,8 @@ Du denkst, du tippst nicht. Dein Ergebnis ist ein Plan, den ein Executer ohne R - **Jede Taskdatei trägt im Frontmatter `modell:` und `modell_begruendung:`.** `title`, `summary` und `modell_begruendung` stehen in Anführungszeichen — ein `: ` im Text macht den Block sonst zu ungültigem YAML (Blöcke und Regel: `AI/Regelwerk/frontmatter.md`). Das Kriterium ist eine einzige Frage: Braucht der Executer für diesen Task Ermessen, oder steht alles wörtlich im Plan? Steht der Code wörtlich da, sind die Zieldateien namentlich genannt und die Verbote ausdrücklich, dann ist die Rolle Abschrift und `haiku` genügt, auch wenn ein Codeblock typografische Zeichen wie „ “ – — … enthält (Haiku 5.5, Pascals Entscheidung vom 2026-10-09; die Ausnahme für Haiku 4.5 steht in `AI/Regelwerk/codeworkflow.md`, Schritt 3). Bleibt Ermessen offen, ist es Fehlersuche, oder muss Fließtext formuliert statt abgeschrieben werden, dann `sonnet`. - **Erst lesen, dann planen.** Bestehende Struktur, Namensgebung, Testkonventionen und Abhängigkeiten des Zielprojekts lesen. Der Plan passt sich der vorhandenen Umgebung an, nicht umgekehrt. - **Erwartete pytest-Fehlerzeilen nur mit breiter Ausgabe.** Ohne Terminal kürzt pytest (gemessen an 9.1.1) jede `FAILED`-Zeile der Kurzzusammenfassung auf 80 Zeichen, die Fehlerart ist dann abgeschnitten („Failed: D..."). Nennt der Plan eine erwartete Fehlerzeile wörtlich, steht im Befehl `COLUMNS=300` davor (Git-Bash) bzw. `$env:COLUMNS=300;` (PowerShell). +- **Rot vor der Umsetzung bei neuen Modulen** (Pascal, 2026-10-26). Testet ein Task ein Modul, eine Datei oder ein Skript, das es vor dem Task nicht gibt, darf der Test vor der Umsetzung am Import (`ModuleNotFoundError`), an der fehlenden Datei oder an einem Gerüst-Stub (`NichtBereit`) scheitern. Die erwartete Fehlerzeile nennt genau diese erste Zeile. Dass die Zusicherungen greifen, belegen dann die Mutanten: Jeder neue Verhaltenszweig, auch jeder Fehler- und Sperrzweig, bekommt einen Mutanten mit `rot_bei`. Bei einem bestehenden Modul bleibt Rot an einer Zusicherung Pflicht. +- **Doku-Tasks verankern nie auf Plandaten** (Pascal, 2026-10-26). `Aus:`-Blöcke in `CHANGELOG.md`, `README.md`, Anleitung und Codedoku verankern an einem Titel oder einer stabilen Abschnittsüberschrift (`# Änderungen`, `## Stand`), nie an einem Versionskopf, einer `updated:`-Zeile oder Text eines anderen Pakets. Ein neuer Versionskopf trägt „Datum bei Freigabe“. Kein Planblock ändert `updated:`; das zieht der Koordinator am Umsetzungstag nach. Beleg: UI-876 und KN-883 brachen in der Nacht zum 2026-10-26 dreimal, sobald ein Vorgängerpaket korrigiert wurde. - **Mutanten stehen in einer Datei, nicht als Prosa.** Verlangt der Auftrag Mutanten, schreibst du sie als `mutanten.toml` in den Planordner, Format 1 nach `D:\Claude\.vault-tools\plan-kopie\mutanten_lauf_ENTWURF.md`, Abschnitt 2; lies den Abschnitt, bevor du die Datei schreibst. Die Plankritik fährt die Datei mit `mutanten_lauf.py` auf ihrer Kopie. In „Fertig heißt“ steht danach nur der Aufruf mit der Erwartung „Exit 0, jeder Mutant `OK`“, keine Zählung. Drei Fallen, alle belegt: - `aus` sind eine oder mehrere ganze Zeilen samt Einrückung und stehen genau einmal in der Datei. - `rot_bei` nennt parametrisierte Tests mit voller Kennung, und zwar nur die Fälle, die der Mutant umkippt. Bei B1 (2026-09-27) wären unter `return False` drei von fünf Fällen grün geblieben. diff --git a/AI/Regelwerk/codeworkflow.md b/AI/Regelwerk/codeworkflow.md index 1e92884..eb97a00 100644 --- a/AI/Regelwerk/codeworkflow.md +++ b/AI/Regelwerk/codeworkflow.md @@ -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-.md`. Jede Taskdatei verweist im Kopf auf die globalen Vorgaben der Übersicht, statt sie zu wiederholen — zwei Fassungen derselben Vorgabe laufen auseinander.