Automatischer Push: 46 Datei(en) geändert

- .claude/agents/planer.md
- .claude/skills/plan-executer-pruefung/SKILL.md
- .claude/workflows/plankritik.js
- .claude/workflows/planung.js
- .claude/workflows/pruefung.js
- .claude/workflows/verbrauch.js
- .claude/workflows/welle-mit-pruefung.js
- .vault-tools/plan-kopie/LIESMICH.md
- .vault-tools/plan-kopie/plan_zeichen.py
- .vault-tools/plan-kopie/rot_nachweis.py
- .vault-tools/trading-plattform-pruefung/LIESMICH.md
- .vault-tools/trading-plattform-pruefung/abendkontrolle.py
- … und 34 weitere

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

Co-Authored-By: Claude Opus 5 <[email protected]>

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-09-23
+updated: 2026-09-24
 ---
 
 # Codeworkflow
@@ -69,6 +69,8 @@ Das Feld `effort:` im Task-Frontmatter ist freiwillig. Fehlt es, gilt das Frontm
 - Die zentralen Artefakte selbst lesen (SKILL.md, README, die Hauptmodule) statt sie aus dem Bericht zu glauben.
 - **Einen eigenen Lauf mit echten Daten fahren, mit eigenem Prüfcode.** Nicht die Tests des Agenten. Siehe „Lauf mit echten Daten" unten.
 
+**Die eigene Gegenprüfung läuft, während der `pruefer` arbeitet, nicht danach.** `welle-mit-pruefung` mit `bis: "vergleich"` endet vor der Prüfung und gibt `pruefung_args` mit den Rohbelegen zurück; damit startest du `pruefung` im Hintergrund und prüfst in derselben Zeit selbst. Solange er läuft, schreibst du nichts in Projektbaum oder Planordner, fährst Rot- und Mutantentests nur auf einer Kopie und brichst ihn nicht ab, auch nicht bei einem eigenen Blocker. Ein abgebrochener Prüfer hinterlässt eine Runde ohne volle Abdeckung, und jede weitere Korrekturrunde bringt ihre eigene Fehlerschicht. Plankorrektur und Commit kommen nach seinem Bericht. Der Gewinn ist höchstens die Lücke nach der Prüfung: im Hub am 2026-09-24 drei bis elf Minuten je Prüfung, gerechnet aus sechs Prüfungen, nicht gemessen.
+
 **Mechanische Prüfungen brauchen einen Regressionsnachweis.** Ein Prüfskript gilt erst als Gate, wenn du es mit absichtlich kaputter Eingabe hast anschlagen sehen — Exit-Code und Meldung selbst beobachtet, nicht aus einem Bericht übernommen. Ohne diesen Nachweis ist ein grüner Lauf kein Ergebnis, sondern eine unbelegte Zusicherung.
 
 Für jede Prüfung, die eine **offene Menge** einschränkt (verbotene Aktionen, verbotene Wörter, unerlaubte Muster), gilt zusätzlich: **Positivliste statt Negativliste.** Was nicht ausdrücklich erlaubt ist, ist ein Befund. Eine handgepflegte Negativliste verliert prinzipiell gegen eine offene Menge — 2026-08-18 im Projekt „Logging" fünfmal hintereinander belegt: jede Fassung des Rollenprüfskripts schloss die genannte Lücke und riss eine neue auf. Der Kopfkommentar eines solchen Skripts benennt deshalb seinen Geltungsbereich: was es prüft, was es nicht sieht, und dass es ein Fangnetz ist und kein Nachweis. Wo der belastbare Nachweis erst in der Zielumgebung möglich ist, gehört er dorthin und wird bis dahin als offen geführt.
@@ -81,6 +83,8 @@ 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.
+
 **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.
 
 Dabei die **Ertragskurve mitschreiben**: was hat Runde 1 gefunden, was Runde 2, was Runde 3. Fällt der Ertrag auf Umformulierungen, ist Schluss — und der Prüfer wird im Abschlussauftrag ausdrücklich gefragt, ob eine weitere Runde noch Substanz hat. Er hat darauf brauchbar geantwortet und einmal von sich aus empfohlen, ohne weitere Runde zu committen. **Jede Nachbesserung ist selbst neuer, ungeprüfter Code** und bekommt in derselben Runde ihren eigenen Regressionsfall.
@@ -122,6 +126,7 @@ Was echte Daten aufdecken und Fixtures nicht: verdrehte Vorzeichen, Skalierungsp
 - **Testdoubles, die nur zurückspiegeln.** Ein Fake, der beim Lesen zurückgibt, was er beim Schreiben bekam, bestätigt die Annahmen des Produktivcodes statt die echte Schnittstelle. Bei asymmetrischen APIs (Schreiben nimmt IDs, Lesen liefert Objekte) muss der Fake die Asymmetrie nachbilden. Im Zweifel in der API-Dokumentation nachschlagen statt Symmetrie anzunehmen.
 - **Schalterpaare.** Wo ein Schalter Schreibzugriffe freigibt und ein anderer sie unterdrückt, ist die Kombination der Testfall — nicht jeder für sich. Für jeden Trockenlauf-Modus einen Test führen, der über das Testdouble *jeden* schreibenden Aufruf zählt und auf null prüft, statt nur das erwartete Endergebnis zu betrachten.
 - **Der Test misst den Inhalt, nicht den Rahmen.** (2026-08-07, „Paketierung Intune") Die Layouttests prüften, ob der Text ins Fenster passt — grün. Ob das *Fenster* auf den *Bildschirm* passt, prüfte niemand: auf 1366×768 bei 125 % Skalierung lag die Fußzeile mit beiden Schaltflächen unter dem Bildschirmrand, der Benutzer hätte nichts mehr anklicken können. Wo etwas in einen Container gesetzt wird, immer beide Ebenen prüfen: passt der Inhalt hinein, und passt der Container dorthin, wo er landet. Die äußere Ebene gehört als reine Funktion mit den Maßen als Parameter getestet — der Entwicklungsrechner ist nie das kleinste Zielgerät.
+- **Ein Thread im Test, viele im Betrieb.** (2026-09-24, „Nexhorizons Hub") FastAPI führt synchrone Abhängigkeiten und Endpunkte im Threadpool aus, und alle Anfragen teilten sich eine SQLite-Verbindung. 402 Tests, drei Plankritik-Runden und zwei Prüfungen waren grün, weil jeder Test einen Thread hat; erst ein Lastlauf gegen die echte Mittelschicht zeigte ein falsches Cookie mit Admin-Sitzung und eine gebrochene Audit-Kette. Hält ein Zustand eine Verbindung, einen Zähler oder einen Cache, steht im Plan, wer ihn aus welchem Thread benutzt, und der Lauf mit echten Daten fährt parallele Klienten.
 
 **Screenshots zur Fehlersuche.** Vor `CopyFromScreen` immer `SetProcessDPIAware()` aufrufen und das Fenster gezielt über `GetWindowRect` abfotografieren. Ohne das liefert `SystemInformation.VirtualScreen` bei aktiver Skalierung die *logische* Größe, während *physische* Pixel kopiert werden — das Ergebnis ist ein Ausschnitt der linken oberen Ecke, kein verkleinertes Gesamtbild. Sieht ein Fenster auf einem Screenshot abgeschnitten aus: zuerst das Aufnahmeverfahren prüfen, dann den Code. Sonst wird am Produktivcode ein Fehler „behoben", den es nicht gibt.
 
@@ -231,14 +236,16 @@ Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck.
 
 Was die Messung nicht belegt: Die Prüfstände waren klein, ein Modul mit 73 Zeilen. Bei Plänen und Reviews über viele Dateien kann der Abstand zwischen den Stufen anders aussehen. Die Recherche-Aufgabe (acht Fragen, Antworten verteilt auf fünf Regelwerk-Dateien) war zu leicht: Haiku und Sonnet beantworteten sie in jeder Stufe 8 von 8. Belegt ist dort nur, dass Nachschlagen keinen hohen Effort braucht.
 
-**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Plankritik, Executer-Welle und Prüfung liegen als gespeicherte Workflows unter `.claude/workflows/` (`plankritik`, `executer-welle`, `pruefung`); sie setzen genau das um und halten Opus bei höchstens zwei gleichzeitig. Was sie darüber hinaus tun:
+**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Gespeicherte Workflows unter `.claude/workflows/`: `plankritik`, `executer-welle`, `pruefung`, `welle-mit-pruefung`, `planung` für die Erstplanung und `verbrauch` für die Ablesung des Planverbrauchs. Sie setzen genau das um; wie viele Opus-Agenten sie gleichzeitig starten, regelt „Verbrauch und Opus-Plätze" unten. Was sie darüber hinaus tun:
 
 - `plankritik` baut auf Wunsch die Kopie mit angewendetem Plan selbst (`materialisieren` mit Ausschlüssen) und lässt einen billigen Hilfsagenten die Planwerkzeuge fahren; die Linsen bekommen die Rohausgabe. Danach fasst sie doppelte Befunde zusammen und lässt jeden wichtigen oder blockierenden von einem zweiten `pruefer` zu widerlegen versuchen: „bestätigt" nur mit eigener Reproduktion, „widerlegt" nur mit Gegenbeleg, sonst „offen". Das filtert Fehlalarme, bevor du den Plan korrigierst, und kostet je Befund einen Opus-Lauf.
 - `welle-mit-pruefung` fasst Schritt 3 und 4 zusammen: Kopie aus dem Stand **vor** der Welle, `executer-welle`, Byte-Vergleich und Suite durch den Hilfsagenten, dann `pruefung` mit diesen Rohbelegen. Ist die Welle unvollständig, prüft er nicht und sagt das.
 - Eine selbst gebaute Kopie verlangt eine nicht leere Liste von Ausschlüssen (`ohne`), gedacht für `.git` und Geheimnisdateien; fehlt sie oder ist sie leer, bricht der Workflow vor dem ersten Agenten ab. Ob die Liste die Geheimnisse wirklich trifft, sieht er nicht — das bleibt deine Sorgfalt. Die Kopie bleibt im Temp liegen, der Rückgabewert nennt den Ordner (`temp_ordner`).
-- Scheitert in `welle-mit-pruefung` ein verschachtelter Schritt, kommen Welle, Kopie und Vergleich trotzdem zurück, der Fehler steht unter `fehler`.
+- Scheitert in `welle-mit-pruefung` ein verschachtelter Schritt, kommen Welle, Kopie und Vergleich trotzdem zurück, der Fehler steht unter `fehler`. Mit `bis: "vergleich"` endet er vor der Prüfung (Schritt 4).
+- `plankritik` fährt ihre Linsen mit so vielen Plätzen, wie `verbrauch` erlaubt, die Widerlegung mit höchstens zwei. Die Aufträge verbieten Tests im echten Projektbaum; Mutanten entstehen in einer eigenen Kopie der Kopie.
+- `planung` startet je Task einen `planer`, sobald die Planer seiner Voraussetzungen fertig sind, statt paarweise nach Wellen. Das spart Wartezeit ohne einen Opus-Agenten mehr: gerechnet 19 Minuten bei der Hub-Planung mit 38 Tasks. Außerdem liest jeder Planer die Taskdateien seiner Voraussetzungen, bevor er einen Namen daraus übernimmt. Gebremst oder abgebrochen kommen die offenen Tasks zurück; nachgeholt wird in einem neuen Lauf mit `erledigt`, nicht über Resume. Die Plankritik läuft danach als eigener Workflow.
 
-Deine eigene Gegenprüfung aus Schritt 4 ersetzt keiner davon; sie wird nur billiger, weil die Rohbelege schon da sind. Recherche und Sammeln `medium` — gemessen reichte fürs Nachschlagen sogar `low`, `medium` ist die Reserve für Recherche mit Synthese oder Webquellen, die der Prüfstand nicht hatte. Reine Abschrift `low` (gleich treu wie `high`, halbe Laufzeit), Urteil und Plan `high`. Höchstens zwei Opus-Agenten gleichzeitig: Am 2026-09-20 riss das Wochenkontingent bei neun parallelen Opus-Agenten, und alles stand zwei Stunden. Wo das richtige Ergebnis feststeht, wertet ein Muster im Skript aus statt eines Richter-Agenten.
+Deine eigene Gegenprüfung aus Schritt 4 ersetzt keiner davon; sie wird nur billiger, weil die Rohbelege schon da sind. Recherche und Sammeln `medium` — gemessen reichte fürs Nachschlagen sogar `low`, `medium` ist die Reserve für Recherche mit Synthese oder Webquellen, die der Prüfstand nicht hatte. Reine Abschrift `low` (gleich treu wie `high`, halbe Laufzeit), Urteil und Plan `high`. Wie viele Opus-Agenten gleichzeitig laufen, regelt „Verbrauch und Opus-Plätze" unten. Wo das richtige Ergebnis feststeht, wertet ein Muster im Skript aus statt eines Richter-Agenten.
 
 **Bei Sonnet-Agenten treibt das Lesen die Kosten, nicht der Effort.** In den sechs Sonnet-Recherche-Läufen machte das Cache-Schreiben der gelesenen Dateien je Lauf ein Drittel bis gut 70 Prozent der Kosten aus, im Mittel gut die Hälfte; teurer oder billiger nach Effort sortierten sich die Läufe nicht. Gezielt lesen — `Grep` mit Zeilennummern, `Read` mit `offset` und `limit` — spart dort mehr als eine niedrigere Stufe. Bei Opus-Agenten dominiert die Ausgabe einschließlich Thinking, und genau die steuert der Effort.
 
@@ -246,8 +253,27 @@ Deine eigene Gegenprüfung aus Schritt 4 ersetzt keiner davon; sie wird nur bill
 
 **Die Escape-Folge für U+2028 hat jedes Modell verloren.** Alle acht Abschrift-Läufe, Haiku wie Sonnet in jeder Stufe, schrieben sie als echtes Zeichen in die Datei. Alle acht Berichte nannten die Datei trotzdem „byte-genau" übernommen, die Tests blieben grün. Das liegt an der Schreibschicht, nicht am Modell. Der Byte-Vergleich nach jeder Welle bleibt Pflicht, egal mit welchen Parametern.
 
+### Verbrauch und Opus-Plätze
+
+**Wie viele Opus-Agenten gleichzeitig laufen, richtet sich nach dem Verbrauch, nicht nach einer festen Zahl** (Pascals Freigabe vom 2026-09-24). Vor jeder Opus-Staffel liest der Workflow `verbrauch` über `get_usage` das 5-Stunden-Fenster und die Woche ab. Er senkt die gewünschten Plätze bei steigendem Verbrauch und gibt bei hohem keinen mehr frei; mehr als vier gibt es nie. Ohne Platz startet die Phase nicht, und der Workflow kommt mit `status: gebremst` zurück. Ein gebremster Lauf wird nach dem Zurücksetzen des Fensters neu gestartet, nicht über Resume, sonst käme die Ablesung aus dem Zwischenspeicher. Die Stufen stehen nur in `.claude/workflows/verbrauch.js`.
+
+Warum keine feste Zwei mehr: Der Vorfall vom 2026-09-20 war die Wochengrenze aller Modelle (`seven_day`), und alle 18 Opus-Agenten dieser Nacht liefen mit effort `max`. Häufiger reißt das 5-Stunden-Fenster, 16 von 19 typisierten Abbrüchen seit dem 22.08. Eine feste Menge Agenten verbraucht parallel dieselben Tokens wie nacheinander, nur schneller. Die Zwei hat also nur die Rate gebremst, und sie galt je Workflow, nicht über zwei gleichzeitige Sitzungen hinweg. Die Ablesung ist kontoweit.
+
+Wo das gilt:
+
+- **`plankritik`:** Die Linsen laufen nach Verbrauch. Die dritte Linse wartete vorher im Mittel 14,5 Minuten auf einen Platz (fünf echte Pläne). Die Widerlegung bleibt bei höchstens zwei.
+- **`planung`:** Vorgegeben sind zwei Plätze, nach Verbrauch gesenkt und nach je vier fertigen Planern neu gelesen.
+- **Ad-hoc-Workflows mit vielen Opus-Agenten** (Reviews, Erstplanungen): Vor jeder Staffel `workflow({ scriptPath: "D:/Claude/.claude/workflows/verbrauch.js" }, { anlass, wunsch })` aufrufen und dessen `plaetze` nehmen, bis zur Eichung mit `wunsch` zwei. Ein Kind eines Workflows kann das nicht, dort gilt zwei.
+- **Opus-Agenten über das Agent-Werkzeug:** Vorher selbst `get_usage` lesen; bei hohem Verbrauch weniger starten, höchstens zwei. Die Stufen stehen in `verbrauch.js`.
+- **`pruefung` und `welle-mit-pruefung`** lesen nur ab, für die Messreihe. Sie bremsen nicht.
+- **Ohne `get_usage`**, also außerhalb der Desktop-App, gilt zwei.
+
+**Stufe 3 kommt erst nach der Eichung.** Drei oder vier Opus-Plätze für Reviews und Erstplanungen (`planung` mit `plaetze`, Ad-hoc-Fan-outs mit höherem `wunsch`) gibt es erst, wenn die Stufen in `verbrauch.js` an der Messreihe nachgestellt sind; bis dahin laufen drei gleichzeitig nur in den Linsen der Plankritik. **Die Stufen sind vorläufig** und stehen nur in `verbrauch.js`. Ein erster Messpunkt vom 2026-09-24, Plan laut App „Pro": Ein Workflow mit 21 Opus-Agenten auf `high` hob zusammen mit dem übrigen Verbrauch der Sitzung das 5-Stunden-Fenster von 7 auf 43 % und die Woche von 2 auf 12 %. Das sind grob 1,5 bis 2 % des Fensters je Opus-Lauf. Nach etwa einer Woche wertet `.vault-tools/workflow-pruefung/verbrauch_reihe.py` die Ablesungen aus, danach werden die Stufen nachgestellt. Werkzeuge und Belege: `.vault-tools/workflow-pruefung/LIESMICH.md`. Ein neuer oder geänderter Workflow unter `.claude/workflows/` wird dort mit `faelle_workflows.mjs` gegen die Attrappe gefahren, bevor er ins Verzeichnis kommt.
+
 **Bei parallelem Einsatz zusätzlich:**
 
+- **Tests nur in der Kopie.** Laufen mehrere Prüfer gleichzeitig, fährt keiner Tests im echten Projektbaum; Mutanten entstehen in einer eigenen Kopie der Kopie. Im echten Baum fährt die Suite immer nur einer.
+
 - **Disjunkte Zieldateien.** Jeder Subagent bekommt die exakten Pfade genannt, die er anlegen darf, und die Anweisung, nichts anderes anzufassen. Gemeinsam benötigte Dateien (Paket-`__init__.py`, `.gitignore`) legt der Koordinator vorher an.
 - **Subagenten committen nicht.** Mehrere gleichzeitige `git commit` im selben Repository kollidieren am Index-Lock. Der Koordinator committet nach dem Rücklauf, je Task einzeln.
 - **`git status` in der Taskdatei nennt die eigenen Zieldateien.** „Genau diese Dateien im Baum und sonst nichts" scheitert in einer parallelen Welle an den Dateien der Nachbarn. In die Taskdatei gehört `git status --porcelain -- <Zieldateien>`; die Mengenprüfung über die ganze Welle macht der Koordinator nach dem Rücklauf.