Automatischer Push: 25 Datei(en) geändert
- .claude/agents/executer.md - .claude/agents/recherche.md - .claude/skills/anleitung-straffen/SKILL.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/00-uebersicht.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-01-zaehler.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-02-sitzungsstart.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-03-regeltexte.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-04-bestandsskript.md - .vault-tools/linkcheck/docs/plans/2026-09-29-waisen/task-05-bestandslauf.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/00-uebersicht.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/task-01-quorum-werkzeug.md - .vault-tools/workflow-pruefung/docs/plans/2026-09-29-quorum/task-02-quorum-workflow.md - … und 13 weitere Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py. Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Pascal MichelandClaude Opus 5 committed
1 parent
e28dd9c280
commit
60dee0ab68
25 files changed
+6403
-86
No files matched your search
@@ -0,0 +1,182 @@
|
||||
---
|
||||
type: plan
|
||||
title: "Quorum am Meilenstein: drei Stimmen, Mehrheit, Nachprüfung"
|
||||
status: draft
|
||||
summary: "Nach dem Plan prüft ein neuer Workflow quorum vor Einspielen, neuer Version auf master und Abgabe eines Kundendokuments denselben Unterschied seit dem letzten Quorum mit Opus, Sonnet und Codex (Ersatz Haiku), zählt Mehrheiten, lässt Einzelbefunde von Sonnet nachprüfen und liefert Urteil und Bericht."
|
||||
tags: [plan, vault-tools, codeworkflow]
|
||||
created: 2026-09-29
|
||||
updated: 2026-09-29
|
||||
---
|
||||
|
||||
# Quorum am Meilenstein
|
||||
|
||||
## Ziel
|
||||
|
||||
Die Anforderung ist die Spec `Inbox/2026-09-29-spec-quorum.md`; dieser Plan zitiert sie nicht, er setzt sie um. Nach dem Plan gibt es:
|
||||
|
||||
- **`.claude/workflows/quorum.js`:** baut über einen Hilfsagenten ein Prüfpaket, startet Opus und Sonnet als `quorum-stimme` und Codex über das Plugin gleichzeitig, setzt Haiku ein, wenn Codex keine gültige Stimme abgibt, lässt einen Sonnet-Agenten gleiche Befunde gruppieren, zählt die Stimmen, lässt Einzelbefunde der Schwere blockierend und wichtig nachprüfen und liefert Urteil, Bericht und Berichtspfad.
|
||||
- **`.vault-tools/quorum/quorum_werkzeug.py`:** tut für den Workflow, was nur mit Dateisystem und Shell geht: Paket bauen, leeren Unterschied erkennen, Basis und Berichtsnummer bestimmen, das Ergebnis eines Codex-Jobs auswerten. Mit eigenen Fällen und Mutanten.
|
||||
- **`.claude/agents/quorum-stimme.md`:** die nur lesende Stimme mit drei Auftragsarten (Stimme, Nachprüfung, Nachkontrolle), dazu eine Zeile in der Rollentabelle des Stamms.
|
||||
- **`AI/Regelwerk/codeworkflow.md`:** der Abschnitt „Quorum am Meilenstein“ als der eine Ort der Regel, Schritt 6 verweist darauf.
|
||||
- **`.vault-tools/workflow-pruefung/`:** Grundlinie, Fälle und Mutanten für `quorum.js` wie für die übrigen Workflows.
|
||||
|
||||
## Nicht im Umfang
|
||||
|
||||
- `pruefung.js`, `plankritik.js`, `welle-mit-pruefung.js` und die übrigen Workflows bleiben unverändert. Die Wellenprüfung bleibt laut Spec.
|
||||
- Kein Git-Hook, keine Kürzung von Wellenprüfung oder Plankritik, kein Quorum für Regelwerk-Änderungen.
|
||||
- `LIESMICH.md` für `.vault-tools/quorum/` und der Abschnitt „Was belegt ist“ in `.vault-tools/workflow-pruefung/LIESMICH.md` schreibt der Koordinator mit den Belegen der Läufe, wie beim Plan vom 2026-09-24.
|
||||
- Paket 2 (unten) wird hier nur beschrieben.
|
||||
- Kein Commit. Der Koordinator committet nach Pascals Abnahme.
|
||||
|
||||
## Architektur
|
||||
|
||||
```text
|
||||
quorum.js (Args: anlass, projekt | ordner+dateien+uebersicht, basis?, kontext?, suite? | suite_datei?, codex?, codex_runden?)
|
||||
├─ Paket werkzeug:paket (sonnet, low) ── python quorum_werkzeug.py paket ... --ziel $T
|
||||
│ → QUORUM_PAKET {ordner, leer, basis, stand, dateien, lesemarke, bericht_pfad, nummer, vorher, ...}
|
||||
│ leer → Urteil des letzten Berichts übernehmen, keine Stimme, kein verbrauch
|
||||
├─ Stimmen verbrauch.js (wunsch 1) → gebremst: kein Urteil
|
||||
│ gleichzeitig: stimme:opus (quorum-stimme, opus)
|
||||
│ stimme:sonnet (quorum-stimme, sonnet)
|
||||
│ Codex: codex:start status --json, dann task --background --json --prompt-file
|
||||
│ codex:warten:N status <job> --wait --timeout-ms 540000 (höchstens codex_runden)
|
||||
│ codex:ende result <job> --json > datei; quorum_werkzeug.py codex
|
||||
│ (alle sonnet, low; Gültigkeit rechnet das Skript)
|
||||
│ danach, nur wenn Codex ungültig: stimme:haiku (quorum-stimme, haiku)
|
||||
├─ Zusammenführen zusammenfuehren (sonnet, medium, ohne agentType), nur belegte Befunde;
|
||||
│ das Skript löst Gruppen über verschiedene Dateien auf und zählt Stimmen
|
||||
├─ Nachprüfen nachpruefung (quorum-stimme, sonnet): Einzelbefunde blockierend und wichtig
|
||||
└─ Urteil, Zählung je Stimme, bericht_md; verbrauch.js am Ende (wunsch 0)
|
||||
```
|
||||
|
||||
Die Taskdateien 01 bis 04 enthalten den Code wörtlich.
|
||||
|
||||
## Codex: welcher Befehl, und warum so
|
||||
|
||||
Nachgelesen im Quelltext des Plugins `openai-codex/codex/1.0.6` (unter `~/.claude/plugins/cache/`), Dateien relativ zu dessen Wurzel; `cc` heißt `scripts/codex-companion.mjs`.
|
||||
|
||||
| Frage | Befund im Quelltext |
|
||||
|---|---|
|
||||
| Rein lesende Prüfung eines Git-Diffs | `review` fährt den eingebauten Reviewer mit Sandbox `read-only` (`scripts/lib/codex.mjs` 1010-1013), kennt aber nur Arbeitsbaum oder Branch als Ziel (cc 259-269) und nimmt keinen eigenen Auftragstext (cc 271-276). `adversarial-review --base <ref>` fährt `read-only` (cc 414) mit festem Ausgabeschema (cc 415, `schemas/review-output.schema.json`, `additionalProperties: false`, kein Feld für einen Lesebeleg). Beide verlangen Git (cc 360). |
|
||||
| Dokumente ohne Git | nur `task`: ohne `--write` Sandbox `read-only` (cc 491), Auftrag aus `--prompt-file` (cc 643-645), kein `ensureGitRepository` in `executeTaskRun` (cc 461-495). Die Wurzel ist das Git-Repo oder, ohne Git, das Arbeitsverzeichnis (`scripts/lib/workspace.mjs` 3-9). |
|
||||
| Warten über zehn Minuten | `task --background` startet einen abgekoppelten Prozess (cc 671-682, 788-805) und gibt `jobId` und `logFile` zurück (cc 700-707); `status <job> --wait --timeout-ms` wartet höchstens so lange (cc 318-334, 891-897) und meldet `waitTimedOut`. `result <job> --json` liefert Job und gespeichertes Ergebnis, nur für beendete Jobs (cc 910-926, `scripts/lib/job-control.mjs` 256-263). |
|
||||
| Kontingentabbruch | Ein Fehler des Codex-Servers geht als Zeile `Codex error: <Meldung>` ins Log (`scripts/lib/codex.mjs` 537-540, geschrieben über `scripts/lib/tracked-jobs.mjs` 122-131); die Schlussausgabe steht ebenfalls im Log (`tracked-jobs.mjs` 179). Exit 0 gibt es nur bei Turn-Status `completed` (`codex.mjs` 754-756, cc 665-667). Die Meldung selbst („usage limit“) ist aus dem Vorfall vom 2026-09-05 bekannt (Harness-Gedächtnis `codex-kontingent-begrenzt`), ihre Form im Log ist nicht gemessen. |
|
||||
| Status und Logs | Zustand unter `$CLAUDE_PLUGIN_DATA/state/<ordnername>-<hash>/`, ohne die Variable im System-Temp unter `codex-companion/` (`scripts/lib/state.mjs` 29-44); darin `state.json` und `jobs/<job>.json` und `jobs/<job>.log` (`state.mjs` 183-191). `status` ohne Job-Kennung zeigt nur Jobs der eigenen Sitzungs-ID (`job-control.mjs` 15-25), mit Kennung alle (242-254). `status` startet keinen Codex-Lauf (cc 883-908, `job-control.mjs` 213-240, `codex.mjs` 906-923). |
|
||||
|
||||
**Entscheidung:** `task` ohne `--write`, im Hintergrund, für Code und Dokumente gleich. Nur `task` erreicht Dokumente ohne Git und erlaubt einen eigenen Auftrag mit Antwortformat und Lesebeleg; alle drei Stimmen lesen dann dasselbe Paket. Das Warten übernehmen kurze Hilfsagenten mit `status --wait`, weil das Bash-Werkzeug eines Agenten nach zehn Minuten endet.
|
||||
|
||||
**Wie der Workflow Codex erreicht:** über Hilfsagenten ohne `agentType` auf **`sonnet` mit `effort: 'low'`**, die je genau einen im Workflow zusammengesetzten Befehl fahren und die Ausgabe übertragen. Das Urteil über die Gültigkeit rechnet der Workflow aus den übertragenen Feldern, nicht der Agent. `low`, weil mechanische Arbeit auf `low` gemessen gleich treu war wie auf `high` (codeworkflow.md, „Effort je Rolle“). Nicht Haiku, weil `codex:ende` die Befundtexte von Codex überträgt und Haiku typografische Zeichen still ersetzt (ebenda, „Haiku und typografische Zeichen“).
|
||||
|
||||
**Gültige Codex-Stimme** (Spec, Abschnitt Codex): `status` vor dem Lauf mit Exit 0; Job endet `completed`; Log gelesen und null Treffer für „usage limit“; Antwort im vereinbarten Block; der Lesebeleg zitiert die Zeile `Lesemarke: <16 Hex>` aus `paket.md`. Die Lesemarke steht nicht im Codex-Auftrag, also kann sie nur zitieren, wer die Datei gelesen hat.
|
||||
|
||||
## Entscheidungsliste (pruefwerkzeuge.md, Abschnitt 1)
|
||||
|
||||
| Frage | Herkunft | Antwort |
|
||||
|---|---|---|
|
||||
| Was ist das letzte Quorum? | Projektvorgabe | Der Bericht mit der höchsten `nummer` im Frontmatter unter `docs/quorum/` bzw. `quorum/`. Zwei gleiche Nummern sind ein Befund. Der Dateiname ordnet zwei Berichte vom selben Tag nicht. |
|
||||
| Basis bei Code? | Spec, Projektvorgabe | `stand` des letzten Berichts; `basis` im Auftrag schlägt das mit Hinweis. Ohne beides Befund. |
|
||||
| Stand bei Code? | Projektvorgabe | HEAD. Der Arbeitsbaum muss außerhalb von `docs/quorum/` sauber sein, weil die Stimmen den Arbeitsbaum lesen. |
|
||||
| Wann ist der Unterschied leer? | Spec | Code: kein Unterschied außerhalb von `docs/quorum/`. Dokumente: keine Datei neu, geändert oder entfernt nach SHA-256. |
|
||||
| Was gilt bei leerem Unterschied? | Spec | Das Urteil des letzten Berichts, ohne Stimme und ohne `verbrauch`. |
|
||||
| Wann zählt ein Befund für die Mehrheit? | Spec | Mit nicht leerem Beleg (nach `trim`). |
|
||||
| Wann sind Befunde gleich? | Spec, Projektvorgabe | Der Sonnet-Agent gruppiert; das Skript löst jede Gruppe über verschiedene Dateien auf. Mehrheit heißt zwei verschiedene Stimmen. |
|
||||
| Schwere einer Mehrheitsgruppe? | Annahme (offen) | Die höchste ihrer Mitglieder. |
|
||||
| Wer wird nachgeprüft? | Spec | Gruppen ohne Mehrheit mit Schwere blockierend oder wichtig. Hinweise gehen ungeprüft in den Bericht. |
|
||||
| Urteil frei? | Spec, verschärft (offen) | Kein bestätigter blockierender Befund und kein blockierender, der ungeprüft blieb. |
|
||||
| Wie viele Stimmen braucht ein Urteil? | Annahme (offen) | Zwei abgegebene. Sonst `kein_urteil` und kein Bericht; die Basis bleibt die alte. |
|
||||
| Gebremst vor der Opus-Stimme? | Projektvorgabe (codeworkflow.md, „Verbrauch und Opus-Plätze“) | Keine Stimme startet, `kein_urteil`, Neustart nach dem Fenster. |
|
||||
| Laufzeit je Stimme? | Quelle | Das Laufzeitsystem hat keine Uhr (`attrappe.mjs` 13, 28-34 bildet das nach). Codex: aus `startedAt` und `completedAt` des Jobs. Claude-Stimmen: „nicht gemessen“, nachträglich aus dem Journal (Paket 2). |
|
||||
|
||||
## Globale Vorgaben
|
||||
|
||||
- Arbeitsverzeichnis ist `D:/Claude`, alle Pfade in den Taskdateien gelten von dort.
|
||||
- **Codeblöcke werden nur mit `plan_materialisiere.py` angewendet**, der Befehl steht in jeder Taskdatei. Nichts von Hand nachschreiben, auch keine Korrektur eines vermeintlichen Tippfehlers. Das Skript schreibt 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.
|
||||
- **Kein Aufruf des Codex-Plugins**, weder `task` noch `review` noch `adversarial-review`, und nie `task --help`: Das startet einen echten Codex-Lauf und verbraucht Kontingent. Einzige Ausnahme ist Messung M1 unten (`status`).
|
||||
- Kein Lauf eines echten Workflows durch einen Executer, kein Commit, kein `git add`.
|
||||
- `.claude/` und `.vault-tools/` gehen um 04:00 ins öffentliche Repo. Die Dateien dieses Plans enthalten keine Kundennamen, Domains oder Zugangsdaten.
|
||||
|
||||
## Tasks
|
||||
|
||||
| Task | Zieldateien | Art | Modell | Welle |
|
||||
|---|---|---|---|---|
|
||||
| 01 | `.vault-tools/quorum/quorum_werkzeug.py`, `faelle_quorum_werkzeug.py`, `mutanten_quorum_werkzeug.py` | neu | haiku | 1 |
|
||||
| 02 | `.claude/workflows/quorum.js` | neu | haiku | 1 |
|
||||
| 03 | `.vault-tools/workflow-pruefung/faelle_workflows.mjs`, `mutanten_workflows.py` | geändert | haiku | 2 |
|
||||
| 04 | `.claude/agents/quorum-stimme.md` (neu), `CLAUDE.md`, `AI/Regelwerk/codeworkflow.md` (geändert) | neu und geändert | sonnet, low | 1 |
|
||||
|
||||
Die Zieldateien sind disjunkt. **Welle 1** (Task 01, 02, 04) läuft parallel. **Welle 2** (Task 03) folgt, weil ihre Fälle und Mutanten gegen `quorum.js` aus Task 02 laufen.
|
||||
|
||||
## Messungen vor und nach den Wellen
|
||||
|
||||
- **M1, kostenlos, vor Welle 1** (Sonnet-Executer oder Koordinator, im Bash-Werkzeug eines Subagenten, denn so ruft der Workflow das Plugin):
|
||||
`node "$HOME/.claude/plugins/cache/openai-codex/codex/1.0.6/scripts/codex-companion.mjs" status --json --cwd D:/Claude; echo "EXIT $?"; [ -n "$CLAUDE_PLUGIN_DATA" ] && echo "CLAUDE_PLUGIN_DATA gesetzt" || echo "CLAUDE_PLUGIN_DATA leer"`
|
||||
Erwartet: Exit 0 und ein JSON mit `workspaceRoot`. Die Zeile zu `CLAUDE_PLUGIN_DATA` sagt, ob Jobs aus dem Workflow im Plugin-Datenordner oder im System-Temp landen. `status` startet keinen Codex-Lauf (Belege oben).
|
||||
- **M2, kostet Codex-Kontingent, im Lauf mit echten Daten:** Überlebt der Hintergrundjob das Ende des Bash-Aufrufs von `codex:start`? Wie lange braucht Codex für ein Paket? Wie sieht die Log-Zeile bei „usage limit“ aus, falls sie auftritt?
|
||||
- **M3, im Lauf mit echten Daten:** Verbrauch je Lauf (Ablesungen vorher und am Ende stehen im Bericht).
|
||||
|
||||
## Fertig heißt
|
||||
|
||||
1. `python .vault-tools/quorum/faelle_quorum_werkzeug.py`: Die letzte Zeile endet auf `0 gescheitert`, Exit 0.
|
||||
2. Rot-Nachweis Werkzeug: `python .vault-tools/quorum/faelle_quorum_werkzeug.py .vault-tools/quorum/gibt-es-nicht.py`: Exit 1, jede Fallzeile beginnt mit `FEHLER`, keine mit `OK`.
|
||||
3. `python .vault-tools/quorum/mutanten_quorum_werkzeug.py`: Die letzte Zeile endet auf `0 ueberlebt, 0 veraltet`, Exit 0.
|
||||
4. `node .vault-tools/workflow-pruefung/faelle_workflows.mjs`: Die letzte Zeile enthält `0 gescheitert`, Exit 0.
|
||||
5. Rot-Nachweis Workflow: `faelle_workflows.mjs` gegen eine Kopie von `.claude/workflows/` ohne `quorum.js` (Befehl in Task 03): Exit 1, jede `FEHLER`-Zeile beginnt mit `FEHLER quorum:`.
|
||||
6. `python .vault-tools/workflow-pruefung/mutanten_workflows.py`: Die letzte Zeile endet auf `0 ueberlebt, 0 veraltet`, Exit 0.
|
||||
7. `python .vault-tools/regelwerk-check/regelwerk_check.py --vault .`: keine Befundzeile, die `quorum-stimme` oder `Rollentabelle` enthält, und nicht mehr Befunde als vor Task 04.
|
||||
8. Byte-Vergleich: `welle_vergleich.py` je Welle gegen die Kopie mit angewendetem Plan, dazu `plan_bloecke.py nach` für Task 03 und 04 ohne Befund.
|
||||
9. M1 wie oben: Exit 0 und JSON.
|
||||
10. Lauf mit echten Daten wie unten: `status: fertig` mit Bericht, danach ein Leerlauf mit `status: leer`.
|
||||
|
||||
## Lauf mit echten Daten
|
||||
|
||||
Nach Welle 2, in einer frischen Sitzung oder über `scriptPath` (ein neuer Workflow wirkt in der laufenden Sitzung erst nach einer Weile):
|
||||
|
||||
1. Ein Probe-Repo im Scratchpad: zwei Commits, im zweiten eine eingebaute Macke mit klarer Schwere (etwa eine vertauschte Bedingung in einer kleinen Funktion, dazu ein Test, der sie nicht fängt, und ein Suite-Ergebnis in einer Datei).
|
||||
2. `workflow({ scriptPath: "D:/Claude/.claude/workflows/quorum.js" }, { anlass: "einspielen", projekt: "<probe>", basis: "<erster commit>", suite_datei: "<datei>" })`.
|
||||
3. Auffallen müsste: Die Macke steht als Mehrheit oder als bestätigter Einzelbefund im Bericht. Codex ist gültig oder der Grund steht im Bericht (M2). Die Lesemarken der Claude-Stimmen passen (sonst Hinweis im Bericht). Verbrauch vorher und am Ende stehen drin (M3). Das Journal zeigt Opus, Sonnet und `codex:start` gleichzeitig.
|
||||
4. `bericht_md` unter `bericht_pfad` ablegen, dann denselben Aufruf ohne `basis` noch einmal: `status: leer`, das Urteil ist übernommen, genau ein Agent (`werkzeug:paket`) lief.
|
||||
5. Das Temp-Paket (`paket` im Ergebnis) danach löschen.
|
||||
|
||||
Der erste echte Meilenstein eines Projekts ist der zweite Lauf mit echten Daten; die Auswertung nach fünf Quoren steht in der Regel.
|
||||
|
||||
## Plankritik
|
||||
|
||||
`mutanten.toml` passt hier nicht: `mutanten_lauf.py` fährt nur pytest, die Fälle dieses Plans laufen über `node` und eigene Python-Treiber. Vorschlag: Plankritik mit `mutanten: "aus"`; die Linse `arithmetik` fährt in der Kopie `faelle_quorum_werkzeug.py`, `mutanten_quorum_werkzeug.py`, `node faelle_workflows.mjs <kopie>/.claude/workflows` und `mutanten_workflows.py <kopie>/.claude/workflows`. Die Kopie des Vaults braucht nur `.claude/`, `.vault-tools/`, `AI/Regelwerk/` und `CLAUDE.md`.
|
||||
|
||||
## Paket 2 (nur beschrieben)
|
||||
|
||||
- **Laufzeit je Claude-Stimme** aus dem Workflow-Journal, nach dem Muster von `verbrauch_reihe.py` (Labels `stimme:*`, Zeitstempel aus `agent-<id>.jsonl`), als kleines Skript unter `.vault-tools/quorum/`.
|
||||
- **Auswertung nach fünf Quoren:** eine Tabelle über alle Berichte eines Projekts (Stimme, Befunde, bestätigt, Alleinfunde, wie oft Haiku statt Codex), als Grundlage für den Dump.
|
||||
- **`LIESMICH.md`** für `.vault-tools/quorum/` mit den Belegen der ersten Läufe.
|
||||
- Falls Pascal es will: ein Workflow-Modus für die Nachkontrolle behobener Befunde statt des Agent-Werkzeugs, und die Stamm-Zeile für Kundendokumente (Offene Punkte 3 und 9).
|
||||
|
||||
## Risiken
|
||||
|
||||
- **Fremde Änderungen im Baum.** `CLAUDE.md` und `AI/Regelwerk/codeworkflow.md` tragen am 2026-09-29 nicht committete Änderungen einer anderen Sitzung (Sonnet 5.5). Die Aus-Blöcke von Task 04 zitieren diesen Stand. Vor Welle 1 `plan_bloecke.py vor` fahren; bei einem Befund den Plan nachziehen, nicht den Baum.
|
||||
- **Hintergrundjob stirbt** mit dem Bash-Aufruf von `codex:start` (M2). Dann endet `status --wait` mit einem Job, der nie fertig wird, oder mit `failed`; die Codex-Stimme ist ungültig, Haiku springt ein, und der Bericht nennt den Grund.
|
||||
- **Codex braucht länger** als `codex_runden` mal neun Minuten. Dann bricht der Workflow den Job ab und setzt Haiku ein.
|
||||
- **Falsche Gruppen** erzeugen eine falsche Mehrheit. Dagegen stehen die Originaltexte je Gruppe im Bericht; gemessen ist die Fehlerquote nicht.
|
||||
- **Nachprüfer urteilt bei Unklarheit `bestaetigt`** (Agentendatei). Das sperrt eher zu oft als zu selten.
|
||||
- **Temp-Pakete bleiben liegen** im System-Temp; der Pfad steht im Ergebnis unter `paket`.
|
||||
- **Verzögertes Nachladen:** neue Agentendatei und neuer Workflow wirken in der laufenden Sitzung erst nach einer Weile (am 2026-09-23 knapp eine Stunde, am 2026-09-24 gut 20 Minuten). Bis dahin über `scriptPath`; ob `quorum-stimme` greift, zeigt das Transkript.
|
||||
|
||||
## Offene Punkte für Pascal
|
||||
|
||||
1. **„Prüfpaket bauen ohne Agent“ geht nicht wörtlich.** Ein Workflow-Skript hat weder Dateisystem noch Shell; das Laufzeitsystem reicht nur `agent`, `parallel`, `pipeline`, `phase`, `log`, `workflow`, `args` und `budget` hinein (nachgebildet in `attrappe.mjs` 45). Deshalb fährt ein Hilfsagent (Sonnet, `low`) genau einen Skriptbefehl. Bei leerem Unterschied läuft also genau dieser Hilfsagent, keine Stimme.
|
||||
2. **Den Bericht schreibt der Koordinator**, nicht der Workflow: Der liefert `bericht_md` und `bericht_pfad`, der Koordinator legt ab, verlinkt und committet. Ein Hilfsagent, der den Text abschreibt, wäre eine Fehlerquelle mehr.
|
||||
3. **Nachkontrolle behobener Befunde** läuft über das Agent-Werkzeug (`quorum-stimme` auf Sonnet, Auftragsart Nachkontrolle), nicht als Workflow-Modus. Reicht das?
|
||||
4. **Laufzeit je Claude-Stimme** steht im Bericht als „nicht gemessen“, bis Paket 2 sie aus dem Journal nachträgt. Codex-Laufzeit steht drin.
|
||||
5. **Schwere einer Mehrheitsgruppe** bei abweichender Einstufung: Der Plan nimmt die höchste.
|
||||
6. **Ungeprüft blockierend sperrt:** Liefert die Nachprüfung kein Urteil, sperrt ein blockierender Einzelbefund wie ein bestätigter. Die Spec nennt nur „bestätigt“.
|
||||
7. **Weniger als zwei Stimmen:** kein Urteil, kein Bericht, die Basis bleibt die alte. Die Spec regelt den Fall nicht.
|
||||
8. **Unbelegte Einzelbefunde** werden nicht nachgeprüft, auch blockierende nicht. Die Spec sagt nur, dass sie nicht für die Mehrheit zählen.
|
||||
9. **Kundendokumente lösen die Regel nie aus:** `codeworkflow.md` wird nur bei Code-Projekten geladen. Vorschlag: eine Zeile im Regelwerk-Verzeichnis des Stamms („Einspielen, neue Version auf master oder Kundendokument vor der Abgabe → codeworkflow.md, Quorum am Meilenstein“). Nicht umgesetzt.
|
||||
10. **Erstes Quorum eines Code-Projekts** braucht eine Basis. Welche, entscheidet der Koordinator je Projekt (etwa der Commit der letzten abgenommenen Version).
|
||||
11. **Welche Spec- und Planübersichten ins Paket kommen**, nennt der Koordinator über `kontext`. Eine automatische Erkennung gibt es nicht.
|
||||
12. **Effort der Sonnet-Stimme:** keine Abweichung, `high` aus dem Frontmatter. Abdeckung ist der Zweck, und bei Sonnet treibt das Lesen die Kosten, nicht der Effort (codeworkflow.md, „Effort je Rolle“). Gemessen ist Sonnet als Prüfer nicht.
|
||||
13. **Zusätzliche Frontmatter-Felder** im Bericht: `nummer`, `anlass`, `urteil` und `codex` neben `basis` und `stand`. `nummer` braucht der nächste Lauf, `codex` die Auswertung.
|
||||
14. **Codex-Modell und -Effort** setzt der Plan nicht; es gilt die Vorgabe der Codex-Konfiguration.
|
||||
15. **Messungen M1 bis M3** siehe oben; M2 und M3 gehen nur mit echtem Kontingent.
|
||||
16. **`updated` in `codeworkflow.md`** setzt der Koordinator beim Commit; Task 04 fasst das Frontmatter nicht an. `pending-review` entfällt, wenn Pascal Spec und Plan abnimmt, denn dann ist die Änderung angeordnet.
|
||||
Reference in new issue
Block a user