--- type: resource status: active title: "Workflow-Prüfung: Attrappe, Fälle und Messreihe zum Verbrauch" summary: "Node-Attrappe für die gespeicherten Workflows des Vaults mit Fällen je Workflow, dazu verbrauch_reihe.py, das aus den Workflow-Protokollen rechnet, wie viel vom 5-Stunden-Fenster und von der Woche zwischen zwei Verbrauchsablesungen verbraucht wurde. Entstanden 2026-09-24." tags: [vault-tools, codeworkflow] created: 2026-09-24 updated: 2026-10-16 --- # Workflow-Prüfung Die Regel dazu steht in [[AI/Regelwerk/codeworkflow|codeworkflow.md]], Abschnitt „Verbrauch und Opus-Plätze". Hier steht nur, wie man die Werkzeuge benutzt und was belegt ist. Der Plan, mit dem sie entstanden sind: `docs/plans/2026-09-24-parallelitaet/00-uebersicht.md` in diesem Ordner. ## Ablauf 1. **Nach jeder Änderung an einem Workflow unter `.claude/workflows/`:** `node .vault-tools/workflow-pruefung/faelle_workflows.mjs` im Vault-Wurzelordner. Mit einem Ordner als Argument prüft das Skript die Workflows dort, etwa eine Kopie mit angewendetem Plan. Jeder Workflow hat zuerst eine Grundlinie; scheitert sie, messen seine übrigen Fälle nichts. 2. **Ein neuer Fall braucht einen Rotlauf.** Die Fälle gegen den Stand vor der Änderung fahren, oder den Mutanten nachstellen, den der Fall fangen soll. Grün allein belegt nichts. 3. **Mutanten:** `python .vault-tools/workflow-pruefung/mutanten_workflows.py` (am 2026-10-16 knapp 50 Minuten, im Hintergrund fahren) und `python .vault-tools/workflow-pruefung/mutanten_reihe.py`. Ein veraltetes Muster bricht mit Exit 2 ab und muss an den neuen Code angepasst werden; ein wirkungsloser Mutant steht mit Grund in `WIRKUNGSLOS`. Wer einen Workflow ändert, ergänzt hier den Mutanten, den sein neuer Fall fangen soll. 4. **Messreihe:** `python .vault-tools/workflow-pruefung/verbrauch_reihe.py [--seit JJJJ-MM-TT]`. Die Ausgabe ist eine Tabelle je Paar aufeinanderfolgender Ablesungen eines Laufs: Minuten, Agentenminuten je Modellfamilie, Differenz im 5-Stunden-Fenster und in der Woche. Darunter steht eine Näherung in Prozent des 5-Stunden-Fensters je Opus-Agentenstunde. Ein `Reset` zwischen zwei Ablesungen zählt nicht mit. ## Was die Attrappe nachbildet `attrappe.mjs` führt ein Workflow-Skript mit nachgebauten Globals aus, genauso streng wie das Laufzeitsystem: `workflow()` im Kind wirft, im Kind ist `phase()` wirkungslos und jeder Agent trägt die Phase `▸ ` (ab dem zweiten Aufruf desselben Kindes `▸ #`), ein unbekannter Workflow wirft, `Date.now()`, `new Date()` ohne Argument und `Math.random()` werfen. Ein Schema ohne `properties` wirft, ein Ergebnis ohne die `required`-Felder wird zu `null`, und ein `agent()` ohne `model` ist ein Verstoß. Aufrufe über `D:/Claude/.claude/workflows/...` leitet sie in den Ordner unter Test um. Sie zählt, wie viele Agenten je Phase und Modell gleichzeitig laufen. **Was sie nicht sieht:** die Obergrenze gleichzeitiger Agenten je Lauf, Budget, Resume und das Verhalten echter Modelle. Wie lange echte Linsen bei drei gleichzeitigen Opus-Agenten laufen und wie viel Verbrauch sie erzeugen, zeigt nur ein echter Lauf. ## Was belegt ist Stand 2026-09-24 nach Plankritik, Prüfung und Nachbesserung. Die Zahlen gelten für diesen Stand; wer Fälle oder Mutanten ergänzt, fährt die Läufe neu, statt die Zahlen hier nachzuziehen. - **Rotlauf:** Gegen die vier alten Workflows scheiterten 122 von 134 Fällen (Stand vor der letzten Nachbesserung). Grün blieben die elf Selbsttests der Attrappe und „kritisch hebt auf xhigh“, ein Verhalten, das sich nicht geändert hat. - **Mutanten an den Workflows:** 52 Mutanten, alle gefangen. Ausgenommen ist „harte Obergrenze fehlt“ in `verbrauch.js`: Er ist wirkungslos, solange keine Stufe mehr als vier Plätze gibt. Wer die Stufen anhebt, braucht dafür einen Fall. - **Selbsttests der Attrappe:** Ein Mutant, bei dem `Date.now()` nicht mehr wirft, fällt auf. - **`verbrauch_reihe.py`:** 27 Fälle, 18 Mutanten, alle gefangen. Die Plankritik fand den wichtigsten Fehler, den kein Fall gesehen hatte: `resetsAt` schwankt bei jeder Ablesung um Millisekunden und springt über Sekunden- und Datumsgrenzen. Das Skript hielt deshalb jedes echte Paar für einen Reset, weil die Testdaten denselben festen Zeitstempel annahmen wie der Code. Seitdem gilt eine Toleranz von fünf Minuten, und die Grundlinie trägt echte Zitterwerte. - **`verbrauch.js` im echten Laufzeitsystem** (wf_8746f9c7-f1f): Die Ablesung ergab 43 % und 12 %, genau den Wert, den der Koordinator zur selben Zeit selbst über `get_usage` las, und damit 3 Plätze. Mit `probe` bei 95 % kamen 0 Plätze und `gebremst` heraus; ein Lauf mit `probe` startet keinen Agenten und steht deshalb in keinem Journal. - **Neue `plankritik.js` im echten Laufzeitsystem** (wf_32edc4e9-501): Nach der Ablesung von 44 % starteten die drei Linsen innerhalb einer Sekunde; die Widerlegung lief zu zweit. Die Ablesungen stehen im Journal unter den Phasen `▸ verbrauch`, `▸ verbrauch #2` und `▸ verbrauch #3`. `verbrauch_reihe.py` wertet sie aus: erstes Paar `Reset` (das Fenster wurde um 18:30 UTC zurückgesetzt), zweites Paar 3 Punkte bei 19 Opus-Minuten. - **Neue `pruefung.js` im echten Laufzeitsystem** (wf_e0294c82-76c): Ablesungen 13 %/16 % vor und 18 %/18 % nach einem `pruefer` von 24 Minuten. - **Neue `planung.js` im echten Laufzeitsystem** (wf_5df09faa-a4d, Probe mit drei Tasks im Scratchpad): Task 1 lief allein, Task 2 und 3 starteten erst nach seinem Ende und liefen gleichzeitig; beide übernahmen die Zieldatei-Zeile aus Task 1, haben seine Taskdatei also gelesen. - **Erster Eichwert** am Abend des 2026-09-24, Plan laut App „Pro“: `verbrauch_reihe.py --seit 2026-09-24` ergab 8,1 % des 5-Stunden-Fensters je Opus-Agentenstunde (5 Paare, 1,7 Opus-Stunden, darunter ein Plankritik-Lauf der Trading-Sitzung). Die Woche stieg in denselben Paaren um 5 Punkte. Der Verbrauch anderer Sitzungen und der Hauptsitzung steckt mit drin; die Zahl ist also eher zu hoch. Für das Nachstellen der Stufen reicht ein Abend nicht. - **Ableser verlässt den Auftrag** (2026-10-16, Plan `docs/plans/2026-10-16-ableser-abweichung/`): Zweimal bearbeitete der Haiku-Ableser die Nutzeranfrage statt `get_usage` zu lesen und schrieb seine Antwort in `status` und `plan` (wf_7ca17029-421, wf_80616e8e-0e3). `verbrauch.js` meldet diese Form jetzt als `status: abgewichen` mit einer Logzeile, die mit `WARNUNG` beginnt; Plätze wie ohne Ablesung. Neun neue Fälle, sieben davon gegen den alten Stand rot; die zwei Gegenproben (ehrlicher Fehlschlag, `not_applicable`) bleiben auf beiden Ständen grün. Acht neue Mutanten, alle gefangen; der volle Mutantenlauf brauchte knapp 50 Minuten. Die drei echten Antworten aus den Journalen ergaben `abgewichen`, `abgewichen` und `nicht_gelesen`. **Ungemessen:** ob der neue Brückensatz im Auftrag einen echten Ableser vom Abweichen abhält; der Fall misst nur, dass der Satz dasteht. Ein abweichender Ableser hat weiterhin alle Werkzeuge. **Offen:** Die Trading-Sitzung hat `plankritik.js` am 2026-09-24 nach einem echten Lauf nachgebessert (Ausgabe der Planwerkzeuge nur bei `EXIT 0`). Für diese Stelle gibt es noch keinen Fall. ## Was die Skripte nicht sehen Den Verbrauch anderer Sitzungen und der Hauptsitzung: Er steckt in jeder Differenz mit drin. Ablesungen über `probe` starten keinen Agenten und fehlen in der Messreihe. `get_usage` gibt es nur in der Desktop-App; anderswo gilt über den Rückfall die Zwei, und die Messreihe bleibt leer. Die Stufen in `verbrauch.js` sind vorläufig. Sie sind ein Fangnetz und kein Nachweis dafür, dass ein Lauf das Fenster nicht reißt.