Abgleich mit dem Vault-Stand b932a0c

1 Datei(en) geändert.
Erzeugt von .vault-tools/auto-push/werkzeuge_spiegel.py.

.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.