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]>
2026-09-25 04:00:02 +02:00
1 parent 67d674cd0b
commit ea278dc24f
@@ -0,0 +1,143 @@
+---
+type: plan
+title: "Parallelität im Codeworkflow: Verbrauchsbremse, Linsen gleichzeitig, Planer nach Voraussetzungen"
+status: active
+summary: "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/."
+tags: [plan, vault-tools, codeworkflow]
+created: 2026-09-24
+updated: 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
+
+```text
+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").