claude-werkzeuge/.vault-tools/workflow-pruefung/docs/plans/2026-09-24-parallelitaet/00-uebersicht.md

type, title, status, summary, tags, created, updated

type	title	status	summary	tags	created	updated
plan	Parallelität im Codeworkflow: Verbrauchsbremse, Linsen gleichzeitig, Planer nach Voraussetzungen	active	Nach dem Plan liest ein neuer Workflow verbrauch den Planverbrauch ab und rechnet die erlaubten Opus-Plätze, die Plankritik fährt ihre Linsen danach gleichzeitig, ein neuer Workflow planung startet Planer nach ihren Voraussetzungen, pruefung und welle-mit-pruefung schreiben den Verbrauch mit, und Attrappe, Fälle, Mutantenläufe und ein Auswerteskript für die Messreihe liegen unter .vault-tools/workflow-pruefung/.	plan vault-tools codeworkflow	2026-09-24	2026-09-24

Parallelität im Codeworkflow

Ziel

Pascal hat am 2026-09-24 im Chat alle drei Stufen der Vorschläge freigegeben („Setze alle Stufen so um.“); die Vorschläge stehen in AI/secondbrain/regelwerk-memory/2026-09-24-parallelitaet-codeworkflow. „So“ heißt wie vorgeschlagen: Stufe 3, drei bis vier Opus-Plätze für Reviews und Erstplanung, kommt erst nach der Messreihe und der Eichung der Stufen. Nach diesem Plan gilt:

• verbrauch.js liest über get_usage das 5-Stunden-Fenster und die Woche ab und rechnet, wie viele Opus-Agenten gleichzeitig laufen dürfen. Die Mechanik reicht bis vier, bei steigendem Verbrauch sinkt die Zahl, null heißt gebremst. Ohne lesbare Ablesung gilt die alte Zwei.
• plankritik.js fährt ihre Linsen mit so vielen Plätzen, wie verbrauch.js erlaubt; bei drei Linsen sind das bis zu drei (Stufe 2). Die Widerlegung bleibt bei höchstens zwei. Die Aufträge sagen, wo Tests laufen dürfen.
• planung.js (neu) startet je Task einen planer, sobald die Taskdateien seiner Voraussetzungen geschrieben sind, statt paarweise nach Wellen. Vorgegeben sind zwei Plätze (Stufe 1); mehr erst nach der Eichung.
• pruefung.js und welle-mit-pruefung.js schreiben den Verbrauch um die Prüfung mit. welle-mit-pruefung kann mit bis: "vergleich" vor der Prüfung enden, damit der Koordinator seine Gegenprüfung parallel zum pruefer fährt.
• .vault-tools/workflow-pruefung/ enthält die Node-Attrappe mit Fällen für alle geänderten Workflows, die beiden Mutantenläufe und verbrauch_reihe.py für die Messreihe.

Nicht im Umfang

• Die Regeltexte: CLAUDE.md („Agenten & Modelle"), AI/Regelwerk/codeworkflow.md, .claude/agents/planer.md (Delta-Nachbesserung) und der Skill plan-executer-pruefung. Sie kommen vom Koordinator.
• .claude/workflows/executer-welle.js bleibt unverändert: Opus läuft dort nur bei der Hochstufung nach zwei Fehlschlägen, und dort bleibt die Zwei.
• Die Prüfstände für die offenen Hebel (vierte Linse „Nebenläufigkeit", Widerlegung auf Sonnet, eigene Kopie je Agent, Rot-Nachweis in der Vorbereitung). Sie waren in den Vorschlägen ein späterer Schritt, keine der drei Stufen.
• LIESMICH.md des Werkzeugordners schreibt der Koordinator mit den Belegen dieses Laufs.
• Kein Commit. Im Vault-Repo committet nur Pascal oder die Aufgabe um 04:00.

Globale Vorgaben

• Arbeitsverzeichnis ist D:/Claude, alle Pfade in den Taskdateien gelten von dort.
• Code, der im Plan steht, wird byte-genau übernommen, auch Kommentare, Umlaute und die Zeichen · und ▸. Jede Datei endet mit genau einem Zeilenumbruch, Zeilenenden LF.
• Ein Widerspruch zwischen Plan und Baum wird gemeldet und nicht still aufgelöst.
• Jeder Executer fasst nur die Dateien unter „Zieldateien" seiner Taskdatei an.
• .claude/workflows/ und .vault-tools/ gehen um 04:00 ins öffentliche Repo. Die Dateien dieses Plans enthalten keine Kundennamen, Domains oder Zugangsdaten.

Architektur

plankritik / planung / pruefung / welle-mit-pruefung
   └─ workflow({ scriptPath: "D:/Claude/.claude/workflows/verbrauch.js" }, { anlass, wunsch })
         └─ agent (haiku): ToolSearch -> mcp__ccd_session_mgmt__get_usage -> fenster
         └─ Skript: Fenster einordnen, Stufen anwenden -> { status, plaetze, gebremst, grund }
   Rückfall, wenn verbrauch.js nicht läuft (etwa als Kind): plaetze = min(wunsch, 2)

welle-mit-pruefung ── workflow('executer-welle') ── workflow('pruefung', { verbrauch: false })
                   └─ liest selbst vor und nach der Prüfung ab

.vault-tools/workflow-pruefung/
   attrappe.mjs              Globals des Laufzeitsystems nachgebaut, streng wie das Ziel
   faelle_workflows.mjs      Grundlinie und Angriffsliste je Workflow
   mutanten_workflows.py     Mutantenliste gegen die Workflows
   verbrauch_reihe.py        Differenzen zwischen Ablesungen aus journal.jsonl
   faelle_verbrauch_reihe.py, mutanten_reihe.py

Entscheidungsliste (pruefwerkzeuge.md, Abschnitt 1)

Frage	Herkunft	Antwort
Welche Fenster zählen?	Quelle	get_usage in der Desktop-App lieferte am 2026-09-24 5-hour limit, Weekly · all models, Weekly · Fable. Von 19 typisierten Limit-Abbrüchen seit 22.08. waren 16 five_hour, 3 seven_day, keiner seven_day_opus. Gezählt werden 5 Stunden und Woche aller Modelle, dazu Weekly · Opus, falls es auftaucht.
Woran erkennt das Skript sie?	Quelle, Annahme aufgelöst	An den Labels (Regex, Groß- und Kleinschreibung egal). Ein unbekanntes oder fehlendes Fenster ist der Status unbekannte_fenster mit Rückfall auf zwei, nie ein stilles Grün.
Was ist ein gültiger Wert?	Projektvorgabe	Eine endliche Zahl ab 0. Über 100 % heißt überschritten und bremst.
Welche Stufen?	Projektvorgabe, vorläufig	Stehen nur in verbrauch.js: 5 Stunden unter 50 % vier, unter 70 % zwei, unter 85 % einer, sonst gebremst; Woche mit 70, 85 und 95 %. Nachgestellt wird nach der Messreihe.
Harte Obergrenze?	Projektvorgabe	Vier (Mechanik für Stufe 3).
Was gilt ohne Ablesung?	Projektvorgabe	Zwei, die bisherige Stammregel.
Wer wünscht wie viele?	Projektvorgabe	Plankritik: so viele wie Linsen (Stufe 2). Planung: zwei (Stufe 1), drei bis vier über plaetze erst nach der Eichung (Stufe 3). Widerlegung: höchstens zwei.
Wer entscheidet?	Projektvorgabe	Das Skript. Der Haiku-Agent überträgt nur Zahlen (Harness-Gedächtnis: lokales-modell-urteilt-nicht).
Wann ist zwischen zwei Ablesungen ein Reset?	Quelle	resetsAt schwankt je Ablesung um Millisekunden und springt über Sekunden- und Datumsgrenzen (gemessen 2026-09-24). Reset ist eine Verschiebung um mehr als fünf Minuten oder ein fallender Wert.
Wie oft wird abgelesen?	Projektvorgabe	Plankritik vor den Linsen, vor der Widerlegung, am Ende. Planung am Anfang, nach je vier fertigen Planern, solange Tasks offen sind, und am Ende. Prüfung vor und nach dem pruefer. Eine Ablesung kostete 12 bis 13 s.

Dateien und Tasks

Task	Zieldatei	Art	Modell	Welle
01	.claude/workflows/verbrauch.js	neu	sonnet, low	0 (ausgeführt)
02	.claude/workflows/planung.js	neu	haiku	1
03	.claude/workflows/plankritik.js	ersetzt	haiku	1
04	.claude/workflows/pruefung.js	ersetzt	haiku	1
05	.claude/workflows/welle-mit-pruefung.js	ersetzt	haiku	1
06	.vault-tools/workflow-pruefung/attrappe.mjs, faelle_workflows.mjs, mutanten_workflows.py	neu	sonnet, low	2
07	.vault-tools/workflow-pruefung/verbrauch_reihe.py, faelle_verbrauch_reihe.py, mutanten_reihe.py	neu	sonnet, low	1
08	.claude/workflows/verbrauch.js	Delta zu 01	haiku	1
09	acht Dateien aus 02 bis 07	Delta nach der Prüfung	sonnet, low	3

Die Zieldateien einer Welle sind disjunkt. Welle 0 zog Task 01 vor die Plankritik, damit sie schon mit echter Ablesung lief. Task 08 bessert Task 01 nach der Plankritik als Delta nach; Task 01 bleibt byte-gleich. Welle 2 folgt auf Welle 1, weil Task 06 die Fälle und die Mutanten gegen die Dateien aus Welle 1 fährt.

Plankritik

Gelaufen am 2026-09-24 mit der neuen plankritik.js über scriptPath (wf_32edc4e9-501, 26 Minuten, drei Linsen gleichzeitig nach einer Ablesung von 44 %). 32 Befunde nach dem Zusammenfassen, 12 bestätigt, keiner widerlegt, 20 kleine ungeprüft. Eingearbeitet:

• Blockierend, alle drei Linsen: verbrauch_reihe.py hielt jedes echte Paar für einen Reset, weil resetsAt je Ablesung um Millisekunden schwankt. Die Fälle hatten denselben festen Zeitstempel wie der Produktivcode angenommen. Jetzt gilt die Toleranz aus der Entscheidungsliste; die Grundlinie trägt echte Zitterwerte.
• Fehlende Fälle: gesenkte Plätze vor der Widerlegung, gesenkte und gehobene Plätze beim Nachlesen der Planung, Bremse am Anfang der Planung, Startreihenfolge, kein Nachlesen ohne offene Tasks, Testort in allen Aufträgen, Wochenschwellen knapp darunter, Opus-Woche unter der Woche aller Modelle, Kappen am Ende eines Paars, höchstes statt erstes Fenster, Ablesezeit.
• Mutantenliste nicht im Plan: Die Mutantenläufe liegen jetzt als Zieldateien in Task 06 und 07.
• Stufe 3 zu früh: planung.js gibt ohne plaetze zwei Plätze vor.
• Über 100 %: bremst jetzt (Task 08).
• Klein, mit erledigt: zaehlung bleibt im gebremsten Fall ein Objekt, ein Planer-Ergebnis zählt nur mit der erwarteten Taskdatei, die Attrappe führt Agenten im Kind unter ▸ <name> und wirft die Meldung des Ziels, ascii heißt nur_ascii, die Kommentare zur Hilfsfunktion stimmen.
• Offen gelassen: die Laufkopie unter _lauf/ löscht der Koordinator nach dem letzten Lauf; ob gleichzeitige Linsen sich in einer gemeinsamen Kopie stören, ist ungemessen (siehe Risiken).

Prüfung

Gelaufen am 2026-09-24 mit der neuen pruefung.js über scriptPath (wf_e0294c82-76c, pruefer auf high, 24 Minuten, Ablesungen 13 %/16 % vorher und 18 %/18 % nachher). Kein blockierender Befund, 2 wichtige, 12 kleine. Der Prüfer riet von einer vollen weiteren Runde ab und nannte die Nacharbeit mit Substanz. Eingearbeitet als Task 09 (Delta, 17 Blöcke):

• Wichtig: Die Reset-Toleranz hatte keinen Fall für ihren Wert; eine Toleranz von 1 s bis 6 h blieb grün. Jetzt vier Fälle (4:59, 5:01 vor und zurück, fünf Stunden bei steigendem Wert) und drei Mutanten am Wert.
• Wichtig: planung.js war nie im echten Laufzeitsystem gelaufen. Nachgeholt mit einer Probe aus drei Tasks, siehe Check 9.
• Klein, erledigt: doppelte Linsen werden abgewiesen; welle-mit-pruefung meldet status: ohne_pruefung, wenn keine Prüfung lief; der Dateiname des Planer-Ergebnisses wird mit Pfadgrenze verglichen; die Attrappe nummeriert wiederholte Kinder wie das Ziel (▸ name #2); Fälle für den Nachlesetakt, den Lesehinweis, ein fehlendes verbrauch.js und das verankerte 5-Stunden-Label.
• Klein, bewusst nicht geändert: Fehlt das 5-Stunden-Fenster, gilt der Rückfall auf zwei, auch wenn die Woche hoch steht (so in der Entscheidungsliste). Die Platzregel bis zur Eichung steht an drei Stellen (Stamm, codeworkflow.md, planung.js) und muss bei der Freigabe von Stufe 3 gemeinsam nachgezogen werden.

Fremde Änderung im Baum: Die Trading-Sitzung hat plankritik.js am 2026-09-24 um 21:47 Uhr nach einem echten Lauf nachgebessert. Die Ausgabe der Planwerkzeuge gilt nur noch bei EXIT 0 als gelaufen. Dabei hat sie die Datei im Arbeitsbaum auf CRLF umgestellt; Git normalisiert das beim Commit. Diese Stelle steht nicht in diesem Plan und hat noch keinen eigenen Fall in faelle_workflows.mjs. Task 09 liegt sauber darüber.

Rot-Nachweis

Erbracht an den Entwürfen; die Executer brauchen keine Produktivdatei beiseitezulegen.

• faelle_workflows.mjs gegen die vier alten Workflows ohne verbrauch.js und planung.js (Stand vor Task 09): 122 von 134 Fällen rot. Grün blieben die elf Selbsttests der Attrappe und „kritisch hebt auf xhigh", ein unverändertes Verhalten.
• mutanten_workflows.py nach Task 09: 52 Mutanten, alle gefangen bis auf den in WIRKUNGSLOS begründeten („harte Obergrenze fehlt": keine Stufe gibt mehr als vier Plätze).
• mutanten_reihe.py nach Task 09: 18 Mutanten, alle gefangen.

Abnahme — Fertig heißt

1. node .vault-tools/workflow-pruefung/faelle_workflows.mjs: Die letzte Zeile enthält 0 gescheitert, Exit 0.
2. python .vault-tools/workflow-pruefung/faelle_verbrauch_reihe.py: Die letzte Zeile enthält 0 gescheitert, Exit 0.
3. Jede Zieldatei ist byte-gleich mit der Kopie, auf die der ganze Plan angewendet ist (Task 01, 08, 02 bis 07, 06), belegt mit cmp und welle_vergleich.py.
4. python .vault-tools/workflow-pruefung/mutanten_workflows.py und mutanten_reihe.py im echten Baum: jeweils 0 ueberlebt, 0 veraltet, Exit 0.
5. verbrauch.js liest im echten Laufzeitsystem ab: Status ok, 5-Stunden-Wert gleich der eigenen get_usage-Ablesung des Koordinators (erfüllt am 2026-09-24, wf_8746f9c7-f1f: 43 % und 12 % auf beiden Seiten).
6. verbrauch.js mit wunsch 3 und probe bei 95 % im echten Laufzeitsystem: plaetze 0, gebremst true (erfüllt, wf_8746f9c7-f1f).
7. verbrauch_reihe.py wertet die drei Ablesungen der Plankritik wf_32edc4e9-501 aus: Das Paar „vor Linsen → vor Widerlegung" steht im 5-Stunden-Fenster als Reset (das Fenster wurde um 18:30 UTC zurückgesetzt), das Paar „vor Widerlegung → Ende" mit einer Zahl.
8. pruefung.js läuft im echten Laufzeitsystem mit zwei Ablesungen im Ergebnis (erfüllt, wf_e0294c82-76c).
9. planung.js läuft im echten Laufzeitsystem mit einer Probe aus drei Tasks (2 und 3 hängen an 1): Task 1 läuft allein, 2 und 3 starten erst nach seinem Ende und laufen gleichzeitig, jede Taskdatei liegt im Planordner (erfüllt, wf_5df09faa-a4d: Task 1 20:06:59 bis 20:07:10 UTC, Task 2 und 3 ab 20:07:12; beide übernahmen die Zieldatei-Zeile aus Task 1).

Lauf mit echten Daten

Die Checks 5 bis 8 sind der Lauf mit echten Daten. Die Plankritik dieses Plans war der erste echte Lauf mit drei gleichzeitigen Opus-Linsen: Sie starteten innerhalb einer Sekunde, die Linsenphase dauerte bis zur letzten Linse, und die Plankritik brauchte insgesamt 26 Minuten.

Risiken

• Andere Sitzungen nutzen die gespeicherten Workflows. Die Trading-Sitzung fährt heute ab 22:04 Wellen und Prüfungen. Die neuen Fassungen sind rückwärtsverträglich: Alle neuen Argumente sind freiwillig, alle bisherigen Rückgabefelder bleiben. Ein altes welle-mit-pruefung mit neuem Kind pruefung ergibt Ablesungen mit nicht_gelesen, die Prüfung läuft trotzdem.
• Verzögertes Nachladen. Ein Aufruf über den Namen kann noch eine Weile die alte Fassung treffen (am 2026-09-23 gut eine Stunde, am 2026-09-24 gut 20 Minuten). Aufrufe über scriptPath lesen die Datei direkt.
• Gemeinsame Kopie. Bis zu drei Linsen und zwei Widerleger fahren Tests in derselben Kopie. Schon bei zwei Widerlegern liefen in 68 % ihrer Laufzeit zwei gleichzeitig. Ob sie sich dabei stören, ist nicht gemessen; es hängt davon ab, ob die Suite des Projekts gemeinsamen Zustand in die Kopie schreibt. Mutanten entstehen nach dem Auftrag in einer eigenen Kopie der Kopie.
• get_usage gibt es nur in der Desktop-App. In anderen Sitzungen gilt über den Rückfall die Zwei.
• Die Stufen sind ungeeicht. Ein erster Messpunkt: Ein Workflow mit 21 Opus-Agenten auf high hob das 5-Stunden-Fenster mit dem übrigen Sitzungsverbrauch um rund 36 Punkte und die Woche um rund 10 Punkte (Plan laut App „Pro").