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
@@ -5,7 +5,7 @@ status: reference
 summary: "Projekt-Tag mit Ableitungsregel, README als Einstieg, Verbindung zum Themen-Seed, Administrator-Anleitung und Dump-Ordner für Projekte in Code Projekte und Security - Compliance Projekte."
 tags: [regelwerk, projekte]
 created: 2026-08-03
-updated: 2026-09-13
+updated: 2026-09-20
 ---

 # Projekte-Regeln
@@ -20,6 +20,7 @@ Gilt beim Anlegen oder Bearbeiten eines Projekts unter `/Code Projekte` oder `/S
 4. **Projekt und Themenwissen verbinden.** Gibt es im IT Workspace einen Themenordner zum selben Gegenstand, bekommt dessen Seed eine Zeile „Zugehöriges Projekt" mit Link aufs README. Die Oberseed-Zeile des Projekts nennt umgekehrt den Seed. **Vault-Links bleiben außerhalb des Projekt-Repos:** Das README geht nach Gitea, wo Wikilinks nur Text sind. Die Verbindung in Richtung Seed steht deshalb im Oberseed, nicht im README.
 5. **Dump-Ordner** heißen `AI/secondbrain/<projekt-tag>-memory/`, mit dem Tag aus Regel 1. Vier ältere Ordner tragen noch den Ordnernamen mit Präfix. Sie werden nicht umbenannt, weil Pfade im Harness-Gedächtnis und in Projektdateien darauf zeigen.
 6. **Referenzprojekte, die nur Volltexte tragen** (unter Security - Compliance), haben keinen Hub. Der Oberseed verlinkt den Volltext direkt. Das Ordnerpräfix `active - ` ist der Projektstatus, `status: reference` in der Datei der Dokumentstatus. Das ist kein Widerspruch.
+7. **Wiederkehrende Arbeit im Projekt wird ein Playbook** (angeordnet am 2026-09-20). Steht in einem Projekt etwas immer wieder an (Monatsbericht, Rezertifizierung, Update-Runde), wird daraus ein Skill nach [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]]: erst das Interview, dann die SKILL.md. Und jedes Projektergebnis, das Pascal abnimmt, bekommt vorher die „Fertig heißt“-Zeilen aus Abschnitt 3 derselben Datei — je Check bestanden oder nicht, mit Beleg, dazu das, was nicht prüfbar war. Das gilt auch für Dokumente unter Security - Compliance, nicht nur für Code.

 ## Referenzen

@@ -27,3 +28,4 @@ Gilt beim Anlegen oder Bearbeiten eines Projekts unter `/Code Projekte` oder `/S
 - [[Code Projekte/_MOC-Code-Projekte|Code Projekte (Oberseed)]]
 - [[Security - Compliance Projekte/_MOC-Security-Compliance|Security - Compliance Projekte (Oberseed)]]
 - [[AI/Regelwerk/frontmatter|frontmatter.md]]: README-Frontmatter (`type: project`)
+- [[AI/Regelwerk/wiederkehrende-jobs|wiederkehrende-jobs.md]]: Playbook, „Fertig heißt“, Ablage
@@ -0,0 +1,107 @@
+---
+type: resource
+title: "Wiederkehrende Jobs als Playbook"
+status: reference
+summary: "Wie aus einem wiederkehrenden Job ein Skill wird, den der Agent ohne Pascal erledigt: Interview mit einer Frage je Nachricht, SKILL.md mit festen Abschnitten, Fertig-heißt-Checks mit Beleg und die Ablage für wiederverwendbare Dateien."
+tags: [regelwerk, playbook, skills, abnahme]
+created: 2026-09-20
+updated: 2026-09-20
+---
+
+# Wiederkehrende Jobs als Playbook
+
+Angeordnet am 2026-09-20. Gilt, sobald Pascal einen Job abgeben will, den er immer wieder macht. Am Ende steht ein Skill, mit dem du den Job ohne Rückfrage erledigst.
+
+Die Abschnitte 3 („Fertig heißt“) und 4 (Ablage) gelten auch außerhalb solcher Jobs. Wo sie in Projekten greifen, steht in [[AI/Regelwerk/codeworkflow|codeworkflow.md]] (Schritte 2 und 6) und in [[AI/Regelwerk/projekte|projekte.md]] (Regel 7). Die Form der Checks steht nur hier.
+
+## 1 Interview — erst fragen, dann schreiben
+
+Pascal beschreibt den Job in einer Zeile. Danach interviewst du ihn:
+
+- **Immer nur eine Frage je Nachricht.** Dann wartest du auf die Antwort.
+- **Du schreibst keine Datei, bevor zwei Dinge erfüllt sind:** Du hast mindestens acht Fragen gestellt, und Pascal hat gesagt, dass ihr fertig seid. Eins von beiden reicht nicht.
+
+Das Interview deckt alles hier ab:
+
+- was den Job auslöst und wie oft er ansteht
+- die Eingaben und wo genau jede davon liegt
+- die Schritte in der Reihenfolge, in der Pascal sie wirklich macht
+- jede Entscheidung, die er trifft, und die Regel dahinter
+- was er prüft, bevor er etwas fertig nennt
+- die Sonderfälle, die schon mal schiefgegangen sind
+- den Ton oder Standard, den das Ergebnis treffen muss
+- wie eine schlechte Version aussieht
+
+Das ist die Ausnahme zu Schritt 1 der Standardschleife („nur Fragen, deren Antwort die Arbeit verändert“). Dort liegt das meiste im Code. Hier liegt der Ablauf nur in Pascals Kopf, und jede nicht gestellte Frage wird später eine Annahme im Skill.
+
+## 2 Die SKILL.md
+
+Sobald du den Job ohne Pascal erledigen könntest, legst du `.claude/skills/<job-name>/SKILL.md` an. Der Ordnername ist kebab-case, ohne Datum und ohne Version. Das Frontmatter hat das Claude-Code-Format mit `name` und `description`; die `description` steht in Anführungszeichen ([[AI/Regelwerk/frontmatter|frontmatter.md]], „Quoting“).
+
+Die Abschnitte, in dieser Reihenfolge:
+
+1. **Zweck** — eine Zeile.
+2. **Wann nutzen**
+3. **Eingaben** — jede mit ihrem Ort.
+4. **Schritte** — nummeriert, in einfacher Sprache, kein Fachchinesisch.
+5. **Entscheidungen** — in der Form „wenn X, dann Y“.
+6. **Fertig heißt** — nach Abschnitt 3.
+7. **Sonderfälle**
+
+Danach zeigst du Pascal die komplette Datei und stellst zwei Fragen: Was habe ich falsch verstanden? Was hast du vergessen, mir zu sagen?
+
+Zwei Dinge aus dem Vault kommen dazu:
+
+- **Der Skill verweist auf das Regelwerk, statt es zu kopieren.** Braucht ein Schritt den Schreibstil oder die Windows-Shell-Regeln, nennt er die Datei.
+- **`.claude/skills/` wird täglich um 04:00 veröffentlicht, ohne Freigabe** ([[AI/Regelwerk/veroeffentlichung|veroeffentlichung.md]]). In SKILL.md und Ablage stehen deshalb keine Kundennamen, Domains, IP-Adressen oder Zugangsdaten. Hängt der Job an einem Kunden, liegen dessen Details außerhalb von `.claude/skills/`, und der Skill nennt nur den Pfad.
+
+## 3 Fertig heißt
+
+Der Abschnitt „Fertig heißt“ enthält fünf bis zehn Checks, die speziell zu diesem Job passen. **Jeder Check ist mit einem Beleg außerhalb deiner eigenen Meinung prüfbar:**
+
+- eine Zahl, die bis zu ihrer Quelldatei zurückgeht
+- ein Link, der lädt
+- ein Screenshot vom fertigen Ergebnis
+- ein Test, der läuft
+- eine Aussage, die zu einem Zitat passt
+- eine Zählung oder ein Wert, der gegen eine Referenzdatei geprüft ist
+
+Schwammige Qualitätswörter wie „klar“, „professionell“ oder „hochwertig“ sind kein Check. Niemand kann sie nachmessen, du auch nicht.
+
+**Jedes Mal, wenn du den Job fertig hast, und bevor du Pascal irgendetwas zeigst:**
+
+1. Führ jeden Check aus.
+2. Reparier, was durchfällt.
+3. Führ alle Checks noch einmal aus, nicht nur die reparierten.
+4. Gib Pascal je Check eine Zeile: bestanden oder nicht bestanden, mit dem Beleg, den du benutzt hast.
+5. Nenn alles, was du nicht prüfen konntest, und warum. Nimm nicht an, dass es passt.
+
+**Fallen beim ersten Durchlauf mehr als zwei Checks durch, hörst du auf.** Du sagst Pascal, welcher Teil des Ablaufs das verursacht hat, statt das Ergebnis zu flicken. Drei kaputte Checks sind ein Fehler im Ablauf, und den findet man nicht, indem man das Ergebnis repariert.
+
+Wird aus einem Check ein Skript, gilt [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]]: Es zählt erst, wenn du es an kaputter Eingabe hast anschlagen sehen.
+
+## 4 Ablage — was du wieder brauchst, baust du nur einmal
+
+Ist bei einem Job etwas entstanden, das Pascal noch einmal braucht (ein Skript, eine Vorlage, eine E-Mail, eine Checkliste), dann:
+
+1. Speicher es in `<job-name>/ablage/` mit einem sprechenden Namen, zum Beispiel `zahlen-ziehen.py` oder `update-vorlage.md`. Kein Datum und keine Versionsnummer im Namen.
+2. Ersetz Pascals Details durch Platzhalter in eckigen Klammern, damit es wiederverwendbar ist. Darunter bleibt ein ausgefülltes Beispiel als Referenz stehen. Wegen der Veröffentlichung ist das Beispiel mit neutralen Werten gefüllt, nicht mit echten Kundendaten.
+3. Aktualisier die SKILL.md: Der Schritt, der die Datei braucht, nennt sie beim Namen. Dazu steht, wann sie genutzt wird und wann nicht.
+4. Trag eine Zeile in `<job-name>/ablage/INDEX.md` ein: Dateiname, wofür sie da ist, heutiges Datum. Die `INDEX.md` ist ein Verzeichnis und bekommt kein Frontmatter.
+
+**Nicht in die Ablage:** einmalige Ergebnisse, nichts mit Passwort oder API-Schlüssel, und kein Entwurf, den Pascal nicht freigegeben hat.
+
+Danach erledigst du den ganzen Job noch einmal von vorn. Du sagst Pascal, welche gespeicherten Dateien du benutzt hast und welche Teile du komplett neu gebaut hast. Alles neu Gebaute ist ein Kandidat für die Ablage. Du sagst also auch, was du als Nächstes speichern würdest.
+
+## 5 Wenn du keine Dateien schreiben kannst
+
+In Claude Code kannst du schreiben. In einer Sitzung ohne Dateizugriff tust du nicht so, als hättest du es getan. Du gibst den kompletten Dateiinhalt im Chat aus, nennst den genauen Dateinamen und wo er in den Ordner gehört. Und du erinnerst Pascal daran, die alte hochgeladene Datei zu ersetzen, statt eine zweite anzulegen.
+
+## Referenzen
+
+- [[CLAUDE|↑ Claude.md (Stamm)]]
+- [[AI/Regelwerk/codeworkflow|codeworkflow.md]] — „Fertig heißt“ als Abnahme im Plan und vor der Fertigmeldung
+- [[AI/Regelwerk/projekte|projekte.md]] — wiederkehrende Arbeit im Projekt
+- [[AI/Regelwerk/pruefwerkzeuge|pruefwerkzeuge.md]] — wenn ein Check ein Skript wird
+- [[AI/Regelwerk/veroeffentlichung|veroeffentlichung.md]] — warum Skill und Ablage keine Kundendaten tragen
+- [[AI/Regelwerk/frontmatter|frontmatter.md]] — Quoting der `description`