Automatischer Push: 45 Datei(en) geändert

- .claude/agents/planer.md
- .claude/agents/quorum-stimme.md
- .claude/skills/bookstack-upload/SKILL.md
- .claude/skills/bookstack-upload/scripts/bookstack/archiv.py
- .claude/skills/bookstack-upload/scripts/bookstack/auswahl.py
- .claude/skills/bookstack-upload/scripts/bookstack/beschreibung.py
- .claude/skills/bookstack-upload/scripts/bookstack/bilder.py
- .claude/skills/bookstack-upload/scripts/bookstack/ergebnis.py
- .claude/skills/bookstack-upload/scripts/bookstack/hochladen.py
- .claude/skills/bookstack-upload/scripts/bookstack/konvertierung.py
- .claude/skills/bookstack-upload/scripts/bookstack/struktur.py
- .claude/skills/bookstack-upload/scripts/bookstack/verweise.py
- … und 33 weitere

Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py.

Co-Authored-By: Claude Opus 5 <[email protected]>

AI/Regelwerk/codeworkflow.md

@@ -5,7 +5,7 @@ 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-09-29
+updated: 2026-09-30
 ---
 
 # Codeworkflow
@@ -108,7 +108,7 @@ Nach jeder programmatischen Änderung an einem Plan: eingebettete Codeblöcke pa
 
 **Ablaufdokumente werden in Ausführungsreihenfolge geprüft, nicht Block für Block.** Ein Installationskapitel wechselte mitten im Text das Arbeitsverzeichnis. Jeder Codeblock war für sich richtig — genau deshalb fällt so etwas beim Lesen nicht auf und beim Kunden schon. Ein Dokument, das jemand von oben nach unten abarbeitet, wird einmal von oben nach unten durchgespielt.
 
-**6 Abschließen.** Bevor Pascal irgendetwas als fertig sieht, fährst du die „Fertig heißt“-Liste aus dem Plan in der Reihenfolge aus [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 3: alle Checks ausführen, Durchgefallenes reparieren, alle noch einmal ausführen, je Check eine Zeile mit Ergebnis und Beleg, und alles benennen, was du nicht prüfen konntest. Fallen im ersten Durchlauf mehr als zwei Checks durch, flickst du nicht, sondern benennst den Teil des Ablaufs, der das verursacht hat — das ist „Läuft etwas schief, hörst du auf und planst neu“ mit einer Zahl daran. Die Liste ersetzt Schritt 4 nicht; sie ist das, was Pascal davon zu sehen bekommt.
+**6 Abschließen.** Steht ein Meilenstein an, läuft vorher das Quorum (siehe „Quorum am Meilenstein“ unten); ohne freies Urteil gibt es kein Merge, keinen Push, kein Einspielen und keine Abgabe. Bevor Pascal irgendetwas als fertig sieht, fährst du die „Fertig heißt“-Liste aus dem Plan in der Reihenfolge aus [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 3: alle Checks ausführen, Durchgefallenes reparieren, alle noch einmal ausführen, je Check eine Zeile mit Ergebnis und Beleg, und alles benennen, was du nicht prüfen konntest. Fallen im ersten Durchlauf mehr als zwei Checks durch, flickst du nicht, sondern benennst den Teil des Ablaufs, der das verursacht hat — das ist „Läuft etwas schief, hörst du auf und planst neu“ mit einer Zahl daran. Die Liste ersetzt Schritt 4 nicht; sie ist das, was Pascal davon zu sehen bekommt.
 
 Der Koordinator committet (Subagenten nie), ergänzt `tasks/lessons.md` um jeden Befund aus Schritt 4 und den Abschnitt „Review" in `todo.md`. Im „Review" steht auch, was in diesem Durchlauf neu gebaut wurde und wieder gebraucht wird (Prüfskript, Vorlage, Auftragstext) — das sind Kandidaten für die Ablage nach Abschnitt 4 derselben Datei. Pascal entscheidet, was davon gespeichert wird.
 
@@ -160,6 +160,32 @@ Seit 2026-09-26 auf Pascals Freigabe:
 - **Ein Paket hat höchstens etwa fünf Tasks.** Wird es größer, teilst du es vor dem Planen in Pakete, die je für sich prüfbar und committbar sind.
 - **Das Drehbuch eines Einbautags pflegt der Koordinator direkt**, ohne Planer und Executer. Jede Änderung trägt ein Datum. Es liegt nicht in dem Zweig, den es einspielt, sondern im Vault unter `AI/secondbrain/<projekt-tag>-memory/drehbuecher/`. Grund: Am 2026-09-27 ließen sich zwei Drehbücher der Trading Plattform nicht berichtigen, weil jeder Commit auf ihren Zweig die Fast-Forward-Kette der Einbauwoche gebrochen hätte. Vor dem Einbau spielst du es einmal in Ausführungsreihenfolge durch (siehe „Ablaufdokumente“ oben).
 
+### Quorum am Meilenstein
+
+**Stand 2026-09-30: umgesetzt, aber noch nicht abgenommen.** Die Prüfung der letzten Nachbesserung und der erste echte Lauf stehen aus (Plan unter `.vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/`). Bis zur Abnahme läuft das Quorum nur auf Pascals Zuruf, und seine Sperre gilt noch nicht. Dieser Absatz fällt mit der Abnahme weg.
+
+Pascals Entscheidung vom 2026-09-29. Was die Wellenprüfung übersehen hat, soll nicht in die Zielumgebung, auf master oder zum Kunden. Dafür prüfen drei Modelle aus zwei Familien unabhängig denselben Unterschied: Opus und Sonnet als `quorum-stimme`, dazu Codex über das Plugin. Die Wellenprüfung bleibt, das Quorum kommt dazu. Der Ablauf steht in `.claude/workflows/quorum.js`, die Werkzeuge unter `.vault-tools/quorum/`. Vor der Opus-Stimme liest der Workflow `verbrauch` ab; gebremst heißt kein Urteil und ein Neustart nach dem Fenster.
+
+**Auslöser, genau drei:**
+
+- **Einspielen:** vor einem Einbautag oder bevor ein Stand auf einen Server, in Produktion oder in einen Echtgeld-Pfad geht.
+- **Neue Version auf master:** vor Merge und Push einer neuen Minor- oder Major-Version laut CHANGELOG. Patch-Versionen lösen nichts aus.
+- **Kundendokument:** vor der Übergabe eines Dokuments oder Dokumentensatzes an einen Kunden.
+
+Regelwerk-Änderungen im Vault lösen kein Quorum aus.
+
+**Kein Unterschied wird zweimal geprüft.** Der Lauf nimmt nur, was seit dem letzten Quorum dazukam: bei Code den Diff vom Stand des letzten Berichts bis HEAD, bei Dokumenten beim ersten Mal den ganzen Satz, danach die Dateien mit geänderter Prüfsumme. Das erste Quorum eines Code-Projekts braucht deshalb eine `basis`, etwa den Commit der letzten abgenommenen Version. Der Arbeitsbaum muss außerhalb von `docs/quorum/` sauber sein, weil die Stimmen ihn lesen. Ist der Unterschied leer, übernimmt der Lauf das Urteil des letzten Quorums, ohne eine Stimme zu starten.
+
+**Urteil.** Was zwei Stimmen an derselben Datei und Stelle melden, gilt, mit der höchsten Schwere der Gruppe. Einzelbefunde der Schwere blockierend und wichtig prüft ein Sonnet-Agent nach; Hinweise mit nur einer Stimme gehen ungeprüft in den Bericht. Ein Befund ohne Beleg zählt nicht für die Mehrheit. Frei heißt: kein bestätigter blockierender Befund und keiner, der ungeprüft blieb. Mit weniger als zwei abgegebenen Stimmen gibt es kein Urteil.
+
+**Ersatz.** Gibt Codex keine gültige Stimme ab, springt Haiku ein. Gültig heißt: Der Status des Plugins ist vor dem Lauf gelesen, der Job endet `completed`, sein Log ist gelesen und trägt kein „usage limit“, und die Antwort zitiert die Lesemarke aus dem Paket. Mit `codex: false` springt Haiku sofort ein, etwa wenn das Kontingent bekannt aufgebraucht ist. Der Bericht sagt, wenn Haiku statt Codex drinsteht. Steht das oft da, ist das Quorum faktisch nur mit Claude besetzt.
+
+**Sperre.** Solange das Urteil nicht frei ist, also ein bestätigter oder ungeprüft gebliebener blockierender Befund offen ist oder der Lauf kein Urteil hat, gibt es kein Merge, keinen Push, kein Einspielen und keine Abgabe. Die Korrekturen entscheidest du, umgesetzt werden sie über die Standardschleife. Danach läuft kein neues Quorum: Eine `quorum-stimme` auf Sonnet, über das Agent-Werkzeug mit der Auftragsart Nachkontrolle gestartet, bestätigt je behobenem Befund, dass er behoben ist. Den Korrektur-Diff prüft das nächste Quorum mit, weil dessen Basis der Stand dieses Laufs ist.
+
+**Bericht.** Der Workflow liefert `bericht_md`, `bericht_pfad` und `ablegen_befehl`. Du schreibst `bericht_md` in eine Datei und legst sie mit dem Befehl ab. Er setzt `stand` aus `paket.json` ein, damit die Liste der Prüfsummen durch kein Modell abgeschrieben werden muss. Danach committest du den Bericht: im Code-Projekt unter `docs/quorum/`, beim Kundendokument unter `quorum/` im Projektordner, Dateiname `JJJJ-MM-TT-<anlass>.md`. Der Bericht verlinkt README bzw. Übersicht. Sein Frontmatter trägt `nummer`, `basis` und `stand`, und daran setzt der nächste Lauf an. Ein Lauf ohne Urteil liefert keinen Bericht, die Basis bleibt dann die alte. Je Stimme stehen darin Befunde, bestätigte und Alleinfunde, also bestätigte Befunde, die nur diese Stimme hatte, dazu die Codex-Laufzeit und der Verbrauch vor und nach dem Lauf.
+
+**Was bleibt:** die Echtgeld-Regeln und die volle Schleife für Geld-, Sicherheits- und Netzpfade. Gekürzt wird erst, wenn die Ertragskurve es trägt. Nach fünf Quoren liest du die Berichte, schreibst die Auswertung als Dump und legst Pascal einen Vorschlag hin. Die Frage dabei: Findet das Quorum, was die Wellenprüfung übersieht, und welche Stimme trägt die Alleinfunde? Über Kürzungen entscheidet Pascal.
+
 ### Was die Schleife bisher gefunden hat
 
 Belege aus dem Projekt „Bookstack Upload" (2026-08-05), fünf Fehler, **keiner davon aus der Testsuite** — die war grün, während drei davon im Code saßen:
@@ -247,7 +273,7 @@ Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck.
 
 Was die Messung nicht belegt: Die Prüfstände waren klein, ein Modul mit 73 Zeilen. Bei Plänen und Reviews über viele Dateien kann der Abstand zwischen den Stufen anders aussehen. Die Recherche-Aufgabe (acht Fragen, Antworten verteilt auf fünf Regelwerk-Dateien) war zu leicht: Haiku und Sonnet beantworteten sie in jeder Stufe 8 von 8. Belegt ist dort nur, dass Nachschlagen keinen hohen Effort braucht.
 
-**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Gespeicherte Workflows unter `.claude/workflows/`: `plankritik`, `executer-welle`, `pruefung`, `welle-mit-pruefung`, `planung` für die Erstplanung und `verbrauch` für die Ablesung des Planverbrauchs. Sie setzen genau das um; wie viele Opus-Agenten sie gleichzeitig starten, regelt „Verbrauch und Opus-Plätze" unten. Was sie darüber hinaus tun:
+**In Workflows** bekommt jeder `agent()`-Aufruf `model`. Den Effort liefert mit `agentType` (`planer`, `pruefer`, `executer`, `recherche`, `quorum-stimme`) dessen Frontmatter; ein `effort`-Parameter daneben schlägt das Frontmatter und steht nur für eine bewusste Abweichung. Ohne `agentType` erbt der Agent die Sitzung, dort wird der Effort immer mitgegeben. Gespeicherte Workflows unter `.claude/workflows/`: `plankritik`, `executer-welle`, `pruefung`, `welle-mit-pruefung`, `planung` für die Erstplanung, `verbrauch` für die Ablesung des Planverbrauchs und `quorum` für die Prüfung am Meilenstein (siehe „Quorum am Meilenstein“ oben). Sie setzen genau das um; wie viele Opus-Agenten sie gleichzeitig starten, regelt „Verbrauch und Opus-Plätze" unten. Was sie darüber hinaus tun:
 
 - `plankritik` baut auf Wunsch die Kopie mit angewendetem Plan selbst (`materialisieren` mit Ausschlüssen) und lässt einen billigen Hilfsagenten die Planwerkzeuge fahren; die Linsen bekommen die Rohausgabe. Danach fasst sie doppelte Befunde zusammen und lässt jeden wichtigen oder blockierenden von einem zweiten `pruefer` zu widerlegen versuchen: „bestätigt" nur mit eigener Reproduktion, „widerlegt" nur mit Gegenbeleg, sonst „offen". Das filtert Fehlalarme, bevor du den Plan korrigierst, und kostet je Befund einen Opus-Lauf.
 - `welle-mit-pruefung` fasst Schritt 3 und 4 zusammen: Kopie aus dem Stand **vor** der Welle, `executer-welle`, Byte-Vergleich und Suite durch den Hilfsagenten, dann `pruefung` mit diesen Rohbelegen. Ist die Welle unvollständig, prüft er nicht und sagt das.
@@ -274,6 +300,7 @@ 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.
 - **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.