Automatischer Push: 46 Datei(en) geändert

- .claude/agents/planer.md
- .claude/settings.json
- .claude/workflows/executer-welle.js
- .claude/workflows/plankritik.js
- .claude/workflows/planung.js
- .claude/workflows/quorum.js
- .claude/workflows/verbrauch.js
- .claude/workflows/welle-mit-pruefung.js
- .vault-tools/shell-wache/ENTWURF.md
- .vault-tools/shell-wache/docs/code/shell_wache.md
- .vault-tools/shell-wache/docs/plans/2026-10-30-shell-wache/00-uebersicht.md
- .vault-tools/shell-wache/docs/plans/2026-10-30-shell-wache/task-01-shell-wache.md
- … 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: pending-review
+status: reference
 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-10-26
+updated: 2026-10-30
 ---
 
 # Codeworkflow
@@ -91,6 +91,15 @@ Faustregel: Lässt sich die Nachbesserung in einem Auftrag beschreiben, der für
 
 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.
 
+**Die letzte Handkorrektur eines Plans liest ein Gegenleser** (Pascal, 2026-10-30). Auch die Stellen, die du nach der letzten Runde selbst setzt, sind neuer Text. Ein `pruefer` liest nur diese Stellen mit zweigeteiltem Auftrag: jede Korrektur einzeln bestätigen, dann gezielt nach Fehlern suchen, die beim Umschreiben entstanden sind. Der Gegenleser zählt als Runde der Ertragskurve: Bringt er nur noch Umformulierungen, ist Schluss, eine weitere Lesung gibt es nicht. Anlass: Letzte Handkorrekturen blieben in den Wochen 40 und 41 mehrfach ohne Gegenleser (Workflow-Review 2026-10-30, S-04); Fallgeschichte in der Harness-Erinnerung `korrekturrunden-erzeugen-neue-fehlerschichten`.
+
+**Zweitlauf der Plankritik nur mit den Linsen, die etwas gefunden haben** (Pascal, 2026-10-30):
+
+- `linsen` nennt nur die Linsen mit bestätigten oder offenen Befunden aus dem Vorlauf.
+- `mutanten: "aus"`, wenn die Korrektur weder `mutanten.toml` noch eine Codestelle ändert, auf die ein Mutant zielt.
+- Für Geld-, Sicherheits- und Netzpfade gilt die volle Schleife aus „Prüfaufwand nach Risiko“ unten auch im Zweitlauf: alle Linsen, Mutanten aus der Plantabelle.
+- Grund: Zweitläufe starteten bisher alle Linsen und den vollen Mutantenlauf; eine Linse kostete im Mittel 5,35 USD Listenpreis (Workflow-Review 2026-10-30, S-02). Neue Fehler in einer bisher befundfreien Linse fängt der Zweitlauf damit nicht mehr; dafür steht der Gegenleser oben.
+
 **Werkzeugdisziplin beim Ändern von Plänen und Dokumenten.** Zwei Korrekturen sind in einer einzigen Sitzung nicht am Inhalt gescheitert, sondern am Werkzeug:
 
 - **Suchen ohne Anker.** Eine Suche nach einem Schrittnamen ohne Suchanfang traf den gleichnamigen Schritt eines früheren Abschnitts, der *vor* dem Suchbeginn lag. Der Schnitt duplizierte alles dazwischen — ein ganzer Task stand zweimal im Plan. Regel: Anker immer **ab** dem Abschnittsanfang suchen, gegen die nächste Überschrift begrenzen, danach die Einmaligkeit der Überschriften zusichern.
@@ -143,6 +152,7 @@ Drei Punkte, die überall in der Schleife gelten:
 - **Läuft etwas schief, hörst du auf und planst neu.** Nicht weitermachen und hoffen. Das gilt auch mitten in Schritt 3, wenn der Executer etwas meldet, das den Plan in Frage stellt.
 - **Bei nicht trivialen Änderungen einmal innehalten: Gibt es einen eleganteren Weg?** Fühlt sich eine Korrektur wie ein Hack an, baust du die Lösung, die du mit dem jetzigen Wissen von Anfang an gebaut hättest. Bei offensichtlichen Korrekturen entfällt die Frage — Eleganz ist kein Grund für zusätzliche Komplexität.
 - **Einen Fehlerbericht behebst du, statt nachzufragen.** Fehlgeschlagene Tests, rote CI, Meldungen im Protokoll: benennen und beheben, ohne dass der Auftraggeber den Kontext wechseln muss.
+- **Je Paket eine frische Sitzung** (Pascal, 2026-10-30). Nach einem Paket startest du neu oder setzt `/clear`, die Übergabe läuft über Dump und `todo.md`. `/compact` mit Fokusanweisung setzt du an Paketgrenzen, nicht erst, wenn die Auto-Kompaktierung greift. Grund: 63 % der Runden der Hauptsitzungen liefen über 400k Kontext und trugen 76 % ihrer Kosten, weil jede Runde den ganzen Verlauf liest (Workflow-Review 2026-10-30, S-01). Einen globalen `autoCompactWindow` gibt es nicht: Er erbt auf Subagenten und würde Planer mitten in der Arbeit kompaktieren.
 
 ### Wann die Schleife entfällt
 
@@ -283,9 +293,9 @@ Was die Messung nicht belegt: Die Prüfstände waren klein, ein Modul mit 73 Zei
 - `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`. 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.
+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. Werkzeug-Hilfsagenten ohne `agentType`, deren Ausgabe nur das Skript liest (Kopie bauen, Paket lesen, Codex-Ende abwarten), `low`. Reine Abschrift durch den `executer` läuft mit dessen `medium` aus dem Frontmatter (Schritt 3, Rollentabelle im Stamm); gemessen war `low` dort gleich treu wie `high` bei halber 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.
+**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 treiben Runden mal Kontextgröße die Kosten: Cache-Lesen und -Schreiben je rund zwei Fünftel, die Ausgabe einschließlich Thinking ein Fünftel, beim Planer mehr (Lesen 26, Schreiben 45, Ausgabe 28 Prozent). Beleg: Workflow-Review 2026-10-30, Kostenzerlegung in `berichte/auswertung.md`, Planerwerte in `berichte/widerlegung.md` (S-09, Listenpreis seit 2026-09-15).
 
 **Haiku und typografische Zeichen.** Im Abschrift-Prüfstand ersetzte Haiku 4.5 in beiden Läufen still ein deutsches schließendes Anführungszeichen (U+201C) durch ein gerades und meldete trotzdem „byte-genau". Sonnet tat das in keiner Stufe. Haiku kostete 0,08 $ gegen 0,13 $ für Sonnet auf `low`. Pascal hat am 2026-09-23 entschieden: Abschrift mit typografischen Zeichen läuft auf Sonnet `low`, die Regel steht in Schritt 3. Der Byte-Vergleich bleibt trotzdem Pflicht. Haiku 5.5 hat dasselbe Zeichenpaar und in einem zweiten Prüfstand alle elf Zeichen der Regel am 2026-10-09 in je 6 von 6 Läufen erhalten; am selben Tag hat Pascal die Ausnahme für Haiku 5.5 aufgehoben (Schritt 3).
 
@@ -302,12 +312,22 @@ 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.
 - **`quorum`:** Liest vor der Opus-Stimme mit `wunsch` eins ab. Gebremst heißt: keine Stimme, kein Urteil, Neustart nach dem Fenster.
-- **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.
+- **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; `wunsch` bis vier ist seit der Eichung frei. 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.
+**Ein Wochenbudget über alle Sitzungen statt Grenzen je Projekt** (Pascal, 2026-10-30). Woche und 5-Stunden-Fenster zählen kontoweit, parallele Sitzungen teilen sie. Bei 100 % ist die Woche für alles gesperrt, auch für Pascals eigene Arbeit.
+
+- **Haltegrenze unter 100 %**, die Pascal setzt; vorgeschlagen waren bisher 95 %. Vor einer Phase, die sie mittendrin reißen würde, hältst du an.
+- **Tagesquote über alle Sitzungen** = (Haltegrenze − Stand) / Tage bis zum Reset der Woche.
+- **Reserve für den Trading-Runner:** Seine Haiku-Orderprüfungen ziehen über das Abo-Token aus derselben Woche und lehnen bei Erschöpfung ab. Die Höhe der Reserve ist nicht gemessen.
+- **Vor der Freigabe vieler Pakete hochrechnen:** je Paket Erstplanung, Kritik, Korrektur, Nachkritik und Wellen mit Prüfung. Pascal die Hochrechnung nennen. Vorher ablesen, ob andere Sitzungen laufen: Eine Opus-Phase kostete allein 1 bis 2 Wochenpunkte (2026-10-26), mit mitlaufender Trading-Kette bis 9 (2026-10-15, als Obergrenze).
+- **Opus-Fan-outs nach dem 5-Stunden-Fenster planen:** Plankritik, Gegenprüfung und Erstplanung an den Anfang eines frischen Fensters, nicht in ein halb verbrauchtes. Das Fenster reißt häufiger als die Woche (siehe oben).
+- **Einmal je Woche `/usage` mit Taste w lesen:** zeigt den Anteil je Skill, Subagent, Plugin und MCP-Server an den letzten sieben Tagen.
+- Belege und Messpunkte: Harness-Erinnerung `opus-phase-kostet-wochenpunkte`; rund 21 Stopps an Woche oder Fenster in sechs Wochen (Workflow-Review 2026-10-30, S-06).
+
+**Stufe 3 ist frei** (Pascal, 2026-10-30): Reviews und Erstplanungen dürfen drei oder vier Opus-Plätze wünschen (`planung` mit `plaetze`, Ad-hoc-Fan-outs mit höherem `wunsch`); `verbrauch.js` senkt den Wunsch nach den Stufen. Die Stufen sind am 2026-10-30 an der Messreihe geeicht und von Pascal unverändert bestätigt; sie stehen samt Begründung nur in `verbrauch.js`. Nachgeeicht wird mit `.vault-tools/workflow-pruefung/verbrauch_reihe.py`, wenn sich Plan oder Konten ändern. Die Ablesungen trennt das Skript nicht nach Konto und Plan; das geht über das Feld `plan` und den Wochen-Reset in `resetsAt`. 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:**