Abgleich mit dem Vault-Stand 22761eb
11 Datei(en) geändert. Erzeugt von .vault-tools/auto-push/werkzeuge_spiegel.py.
This commit is contained in:
1 parent
9e506ff588
commit
ae3ec3ca89
11 files changed
+1520
-65
No files matched your search
@@ -5,7 +5,7 @@ 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-30
|
||||
updated: 2026-11-02
|
||||
---
|
||||
|
||||
# Workflow-Prüfung
|
||||
@@ -43,8 +43,11 @@ Stand 2026-09-24 nach Plankritik, Prüfung und Nachbesserung. Die Zahlen gelten
|
||||
- **Ableser als Agententyp** (2026-10-17, Task 02 desselben Plans): Der Ableser läuft als `agentType: verbrauch-ableser` (Haiku, `effort: low`, nur ToolSearch und `get_usage`). Ein Startfehler, etwa ein in der Sitzung noch unbekannter Typ, kommt als `nicht_gelesen` mit `WARNUNG` zurück, nie als Rückfall auf einen Agenten mit allen Werkzeugen. Echtläufe: Vor der Registrierung warf `agent()` „agent type 'verbrauch-ableser' not found“ ohne Agent (`wf_63cb007d-71b`); danach lasen vier von vier Ablesern richtig, mit Effort `low` und nur ToolSearch, `get_usage` und StructuredOutput (`wf_1901f51f-dd3`, `wf_4d8a69f9-51a`). Die Sitzung kannte die neue Agentendatei nach etwa zehn Minuten. 261 Fälle grün, drei neue gegen den alten Stand rot; 157 Mutanten, alle gefangen oder als wirkungslos geführt. **Ungemessen:** ein Ableser, der eine abweichende Nutzeranfrage sieht. Alle vier Echtläufe starteten in Zügen ohne Nutzernachricht, der Harness reichte keine Anfrage durch.
|
||||
- **Eichung der Stufen** (2026-10-30, Workflow-Review S-11): `verbrauch_reihe.py` über den ganzen Speicher ergab 1.245 Ablesungen und 647 Paare. Getrennt wurde mit einem Wegwerfskript, das die Funktionen von `verbrauch_reihe.py` importiert: Plan aus dem Feld `plan` der Ablesung, Konto aus Wochentag und Stunde des Wochen-`resetsAt`, auf die volle Stunde gerundet, weil der Wert über die Stundengrenze zittert. Zwei Konten: Reset montags 00:00 UTC (Pro bis 2026-09-30, Max ab 2026-10-05) und mittwochs 20:00 UTC (Max ab 2026-10-09). 340 Ablesungen ohne Plan waren gescheiterte oder abgewichene Ablesungen. Max: 9,2 bzw. 10,1 % des 5-Stunden-Fensters und 2,5 bzw. 2,6 % der Woche je Opus-Agentenstunde (187 und 205 Paare, 107 und 125 Opus-Stunden), Median je Paar ab 15 Opus-Minuten 8,6 bzw. 9,0, P90 rund 19. Pro: 14 Paare, zu wenig. Anstieg des Fensters je Paar nach gleichzeitig laufenden Opus-Agenten: einer Median 3, P90 13, Spitze 33 Punkte (211 Paare); zwei 4, 14, 42 (134); drei 5, 9, 18 (45); vier nur 2 Paare. Pascal hat die Stufen daraufhin unverändert bestätigt und Stufe 3 freigegeben. **Ungemessen:** Max zeigt je Opus-Stunde mehr Prozent als Pro; als reiner Planeffekt ist das unplausibel, wahrscheinlich liefen im Max-Zeitraum mehr Sitzungen parallel. Die Kontentrennung kann `verbrauch_reihe.py` selbst nicht.
|
||||
- **`planung` mit `effort`** (2026-10-30, für die Messung A2): Das Argument wird geprüft (`low` bis `max`), an jeden Planer neben `agentType` weitergereicht und in der Rückgabe genannt, ohne Argument `(Frontmatter)`. Drei neue Fälle, alle drei gegen den alten Stand rot; drei neue Mutanten, einzeln gefahren und alle gefangen. Der volle Mutantenlauf ist dafür nicht gelaufen.
|
||||
- **Exit 2 der Planwerkzeuge als Befund** (2026-11-02, Auftrag der Startsitzung der Zaunprüfung, Pascal: „Ja, nachziehen“): `welle-mit-pruefung` hält vor `executer-welle`, wenn `plan_materialisiere.py` beim Bau der Kopie eine Zeile `BEFUND <taskdatei>:<zeile>:` meldet (`status: plan_befund`, die Zeilen in `plan_befunde`). `plankritik` zählt ein Planwerkzeug mit Exit 2 und Befundzeile als gelaufen, `plan_bloecke` auch mit Exit 3 und „Nichts geprueft:“. Die Ausgabe geht dann an die Linse `bezeichner`, die Zeilen stehen unter `werkzeug_befunde`. Exit 2 ohne Befundzeile nennt das Log mit Werkzeug und Exit statt „Hilfsagent ohne Ergebnis“. Beide lesen dafür alle `laeufe` des Hilfsagenten: Im Echtlauf `wf_9ab7fd8e-ad1` gab `werkzeug:planwerkzeuge` je Werkzeug einen Lauf zurück, und `laeufe[0]` allein enthielt `plan_bloecke` nicht. 24 neue Fälle, gegen den alten Stand 19 rot; die 5 Gegenproben für den alten Weg sind auf beiden Ständen grün. 292 Fälle grün. 22 neue Mutanten, je an ihrem Pflichtfall gefangen; alle 188 Mutanten, parallel über ein Wegwerfskript: 187 gefangen, 1 wirkungslos wie bisher. Echtläufe auf einem Wegwerfprojekt mit klebendem Zaun: `wf_63d99146-e89` hält mit `plan_befund`, ein Agent, kein Executer; die Mutante ohne Halt (`wf_2b979130-800`) endet mit `bis_vergleich`, ihr Executer schrieb den kaputten Plan ins Projekt; `plankritik` (`wf_f1867091-dda`) führt beide Befundzeilen unter `werkzeug_befunde`, und die Linse bekam die Werkzeugausgabe. **Ungemessen:** ein Hilfsagent, der Befundzeilen umformuliert oder weglässt; dann hält nichts.
|
||||
- **Alle `laeufe` an fünf weiteren Stellen** (2026-11-02, Folgeauftrag der Zaunprüfung): Der Erfolgspfad der Kopie in `welle-mit-pruefung` und in `kopieAusLauf()` von `plankritik`, der Vergleich für den `pruefer`, der Mutantenlauf in `plankritik` und `ausgabe()` in `quorum` lesen die Ausgabe aller `laeufe`, in ihrer Reihenfolge und mit Zeilenumbruch verbunden. Verwendbar ist eine Kopie nur, wenn jeder Lauf Exit 0 hat: Ihr Befehl ist eine Kette mit `&&`. Mit `laeufe[0]` allein galt ein erster Lauf mit 0 vor einem Absturz im zweiten als fertige Kopie, und im Quorum lief ein gestarteter Codex-Auftrag ungesehen weiter, während Haiku einsprang. `KEINE_MUTANTEN_TOML` zählt nur noch als ganze Zeile; sonst machte ein zusätzlicher Lauf mit dem Skripttext aus einem gefahrenen Mutantenlauf `keine_toml` (Befund der Gegenprüfung durch den `pruefer`). Die Antworten in `faelle_workflows.mjs` nehmen jetzt auch für `werkzeug:vergleich`, `werkzeug:mutanten` und die Quorum-Labels Listen von Läufen. 18 neue Fälle, gegen den alten Stand 16 rot; die 2 übrigen sichern Code, den erst dieser Auftrag braucht, und sind dort grün. 310 Fälle grün. 16 neue Mutanten und 3 alte mit angepasstem Muster, je an ihrem Pflichtfall gefangen; alle 204 Mutanten, parallel über ein Wegwerfskript: 203 gefangen, 1 wirkungslos wie bisher. **Ungemessen:** ein Echtlauf, in dem ein Hilfsagent an einer dieser Stellen seine Ausgabe verteilt; `laeufe` in anderer Reihenfolge als ausgeführt. An der Reihenfolge hängt bei einem langen Vergleich das Ergebnis der Suite für den `pruefer`; die jobId-Suche in `quorum.js` hängt seit dem Folgeauftrag zum Codex-Start nicht mehr daran.
|
||||
- **Codex-Start unabhängig von Reihenfolge und Form der `laeufe`** (2026-11-02, Folgeauftrag, Pascal: „Ja, hier bauen“; geplant mit Codex Sol `gpt-6.1-sol`, in vier Runden kritisiert von Codex Astra `gpt-6-astra`): `codexStimme()` in `quorum.js` nimmt die jobId nur noch am Objektanfang der Task-Antwort, `{` gefolgt von `"jobId": "<id>"`, Komma und `"status": "queued"` bei beliebigem Leerraum, und nur innerhalb eines Laufs. Verfolgt wird ein Auftrag nur bei genau einer verschiedenen ID. Die alte Regel nahm die erste jobId hinter dem letzten `EXIT status:`. In 42 echten Rückgaben von `codex:start` aus Workflow-Transkripten (2026-09-30 bis 2026-10-31) wählte sie einmal einen früheren Job, weil der Hilfsagent `EXIT status: 0` vor das Status-JSON gestellt hatte, und fand zweimal keine jobId, weil er die Task-Antwort kompakt neu serialisiert hatte. Zwei weitere Rückgaben verteilten die Ausgabe auf zwei `laeufe`, je Befehl einen; der Code vor dem Folgeauftrag „alle laeufe“ las nur den ersten. In allen fünf Läufen sprang Haiku ein, und der Codex-Auftrag lief ungesehen. Über den echten Code und die Attrappe gefahren, verfolgt der neue Stand in allen 42 die richtige ID. Kommt die Ausgabe nicht in Befehlsreihenfolge, steht ein Hinweis im Bericht; fehlt trotz `EXIT task: 0` eine sichere ID, warnt der Grund vor einem womöglich ungesehen weiterlaufenden Auftrag. Abgesichert ist das Bedrohungsmodell M1 bis M4: Verteilung und beliebige Reihenfolge der `laeufe`, Leerraum und kompakte Form, Kürzung nach der Vorgabe im Hilfsagentenauftrag, verschobene EXIT-Zeilen mit kurzen Vorsätzen. Frei umgestellte Zeilen innerhalb eines Laufs oder erfundene Inhalte fängt nur der Lesebeleg in `codexUngueltig()`. 31 neue Fälle, gegen den alten Stand 27 rot; die 4 übrigen sichern die Umrechnung der Fundstellen und zwei Gründe ohne Warnung. 341 Fälle grün. 25 neue oder angepasste Mutanten an ihrem Pflichtfall gefangen; alle 227 Mutanten, parallel über ein Wegwerfskript: 226 gefangen, 1 wirkungslos wie bisher. Die Breitensuche des `pruefer` über die echte Funktion fand in 1.944.937 erzeugten Lagen keine alte ID, gegen den alten Stand 537.307. **Ungemessen:** ein Echtlauf mit vertauschten `laeufe`; unter den 42 war keiner.
|
||||
|
||||
**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.
|
||||
**Offen:** Für `ausgabe()` im Quorum liegen echte Rückgaben mit zwei `laeufe` vor (2026-10-13, 2026-10-22); für die übrigen vier Stellen ist nur die Attrappe belegt, ein Echtlauf mit verteilten `laeufe` steht aus. Nicht gebaut: `kopieAusLauf()` in `plankritik.js` nennt den Temp-Ordner nicht, wenn die Kopie an einem Exit ungleich 0 scheitert. Am Codex-Start lehnt `quorum.js` mit Warnung ab, wenn die Task-Antwort zwischen `{` und `"jobId"` oder zwischen `"jobId"` und `"status"` auf zwei `laeufe` geteilt ist; ohne EXIT-Zeile am Zeilenanfang kommt der Reihenfolgehinweis auch bei richtiger Reihenfolge. Statuseinträge, die eine ältere Pluginversion in `state.json` geschrieben hat, sind nicht an Quellen geprüft; in den 42 Echtläufen trug keiner das Merkmal. `codex:warten` erkennt das Ende nur an `"waitTimedOut": false` mit Leerzeichen; so stand es in allen 54 echten Rückgaben, ob ein Hilfsagent mit kompaktem Start auch die Warte-Ausgabe kompakt liefert, ist ungemessen. Den Inhalt eines Hilfsagenten liest kein Workflow mehr nur aus `laeufe[0]`; `plankritik.js` fragt `laeufe[0]` bei den Planwerkzeugen nur ab, um „Hilfsagent ohne Ergebnis“ zu erkennen. Die Stelle „Ausgabe der Planwerkzeuge nur bei `EXIT 0`“ (Trading-Sitzung, 2026-09-24) hat seit 2026-11-02 Fälle.
|
||||
|
||||
## Was die Skripte nicht sehen
|
||||
|
||||
|
||||
Reference in new issue
Block a user