Automatischer Push: 14 Datei(en) geändert

- .vault-tools/plan-kopie/LIESMICH.md - .vault-tools/plan-kopie/rot_nachweis.py - .vault-tools/trading-plattform-pruefung/LIESMICH.md - .vault-tools/trading-plattform-pruefung/dienste_stand.sh - .vault-tools/trading-plattform-pruefung/ha_einrichten.py - .vault-tools/trading-plattform-pruefung/hole_kerzen.py - .vault-tools/trading-plattform-pruefung/neustart_echtlauf.py - .vault-tools/trading-plattform-pruefung/ntfy_lesen.py - .vault-tools/trading-plattform-pruefung/pause_echtlauf.py - .vault-tools/trading-plattform-pruefung/wiederanlauf_probe.ps1 - AI/Regelwerk/codeworkflow.md - AI/Regelwerk/projekte.md - … und 2 weitere Erzeugt vom PostToolUse-Hook .vault-tools/auto-push/auto_push.py. Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-21 04:00:01 +02:00
1 parent 5e0577a871
commit 94116e5a32
@@ -5,7 +5,7 @@ title: Codeworkflow
 summary: Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.
 tags: [regelwerk, codeworkflow, code-projekte]
 created: 2026-08-03
-updated: 2026-09-18
+updated: 2026-09-20
 ---

 # Codeworkflow
@@ -25,10 +25,12 @@ Dateikopf, CHANGELOG-Regel und Codedoku stehen seit 2026-08-30 in [[AI/Regelwerk
                                                                  └──── Befund ─────┘
 ```

-**1 Klären.** Offene Entscheidungen vor dem Plan stellen, nicht mittendrin. Nur Fragen, deren Antwort die Arbeit verändert — alles andere selbst entscheiden und die Annahme benennen.
+**1 Klären.** Offene Entscheidungen vor dem Plan stellen, nicht mittendrin. Nur Fragen, deren Antwort die Arbeit verändert — alles andere selbst entscheiden und die Annahme benennen. Ausnahme: Soll ein Ablauf übernommen werden, den nur Pascal kennt (ein wiederkehrender Job, ein neues Vorhaben ohne Vorlage im Code), gilt die Interviewform aus [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 1 — eine Frage je Nachricht, mindestens acht, und keine Datei vor Pascals „fertig“.

 **2 Planen.** Detailplan unter `docs/plans/JJJJ-MM-TT-<thema>/` mit echtem Test- und Implementierungscode, exakten Zieldateipfaden und Verifikationsbefehlen. Keine Platzhalter, kein „analog zu Task N". Der Executer sieht nur den Plan, nicht dieses Gespräch.

+**Die Abnahme im Plan ist eine „Fertig heißt“-Liste.** Fünf bis zehn Checks, die zu genau diesem Vorhaben passen, jeder mit einem Beleg außerhalb der eigenen Meinung prüfbar; Qualitätswörter wie „klar“ oder „professionell“ sind kein Check. Die Form steht in [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]], Abschnitt 3. Schreibt der `planer` den Plan, steht die Form im Auftrag an ihn — er lädt das Regelwerk nicht.
+
 **Plankritik vor dem ersten Executer.** Ein Plan ab etwa drei Tasks wird, bevor ein Executer startet, von `pruefer`-Subagenten (Opus) mit getrennten Linsen gelesen: (1) Fixture-Arithmetik und Rot-Nachweise — jede Mindestzahl im Produktivcode gegen jede Fixture gerechnet, jede erwartete Fehlermeldung wörtlich; (2) Bezeichner, Signaturen über Taskgrenzen, Byte-Treue der Aus-Blöcke, Parsen der Codeblöcke, Prüf-greps nur auf Code; (3) Spec-Abdeckung in beide Richtungen. Der wirksamste Griff: Der Kritiker wendet alle Blöcke des Plans auf einer Kopie unter `/tmp` an und fährt die Suite dort. Beleg vom 2026-09-16/17 im Projekt „Trading Plattform" (Teil 9, fünf Tasks): 55 Befunde vor dem ersten Executer, darunter zwei blockierende Rechenfehler in Testerwartungen, dreimal ein grep auf die eigenen Kommentare und ein Fehler in der Referenzmessung des Koordinators; der Nachkritiker fand auf der materialisierten Fassung sechs weitere, darunter eine falsche Gültigkeitsgrenze („weit vor Zeile 30" — gemessen Zeile 60) und einen Mutanten, der nur ein zurückgespiegeltes Konfigurationsfeld traf. Danach liefen drei Executer-Wellen ohne eine einzige Abweichung durch. Ohne diese Runde wäre jeder dieser Befunde eine Executer-Meldung oder eine Korrekturrunde geworden — und der Koordinatorkontext ist die knappe Ressource (siehe Schritt 5).

 **Die Kopie mit dem angewendeten Plan bleibt stehen und ist der Vergleichsstand für jede Welle.** Steht der Code wörtlich im Plan, wendet der Koordinator alle Blöcke vor der ersten Welle per Skript auf eine Kopie des Baums an, fährt dort Suite und Mutanten und vergleicht nach jeder Welle zwei Dinge: ob genau die Zieldateien der Taskdateien geändert sind, und ob jede byte-gleich mit der Kopie ist. Beleg vom 2026-09-17 („Trading Plattform", 15 Tasks, vier Wellen): acht abweichende Dateien, sechs davon aus Berichten mit „keine Abweichungen", eine davon ein sichtbarer Fehler bei grünen Tests. Der Vergleich zeigt je Datei nur die erste Abweichung — danach immer `diff` auf die ganze Datei. Abweichungen an Einzelstellen setzt der Koordinator aus der Kopie, statt denselben Executer-Typ ein zweites Mal an dieselbe Fehlerklasse zu lassen. Die Skripte dafür liegen unter `.vault-tools/plan-kopie/` (Gebrauch in `LIESMICH.md` dort, samt der Warnung zur `node_modules`-Junction).
@@ -92,7 +94,9 @@ 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.** Der Koordinator committet (Subagenten nie), ergänzt `tasks/lessons.md` um jeden Befund aus Schritt 4 und den Abschnitt „Review" in `todo.md`.
+**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.
+
+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.

 ### Lauf mit echten Daten

@@ -223,6 +227,7 @@ Dateikopf, CHANGELOG statt Versionsnummern in der Datei, was aus dem Code versch
 - [[CLAUDE|↑ Claude.md (Stamm)]]
 - [[AI/Regelwerk/codedoku|codedoku.md]] — Dateikopf und Codedoku
 - [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]] — alles, was beurteilt statt tut
+- [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]] — Interviewform, „Fertig heißt“-Checks, Ablage
 - [[AI/Regelwerk/fable-5-1|fable-5-1.md]] — nur für Fable 5.1: modellspezifische Verhaltensunterschiede
 - [[AI/Regelwerk/prompting|prompting.md]] — Aufträge an Subagenten formulieren
 - [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]] — Verhalten der Zielmodelle von Planer/Prüfer bzw. Executer