Automatischer Push: 32 Datei(en) geändert

- .claude/agents/executer.md
- .claude/agents/planer.md
- .claude/agents/pruefer.md
- .claude/agents/recherche.md
- .claude/skills/plan-executer-pruefung/SKILL.md
- .claude/workflows/executer-welle.js
- .claude/workflows/plankritik.js
- .claude/workflows/pruefung.js
- .claude/workflows/welle-mit-pruefung.js
- .gitignore
- .vault-tools/regelwerk-check/ENTWURF.md
- .vault-tools/regelwerk-check/regelwerk_check.py
- … und 20 weitere

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

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

AI/Regelwerk/codeworkflow.md

@@ -2,10 +2,10 @@
 type: resource
 status: reference
 title: Codeworkflow
-summary: Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.
+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-20
+updated: 2026-09-23
 ---
 
 # Codeworkflow
@@ -55,6 +55,14 @@ Die Lehre daraus gilt über diesen Fall hinaus: **Eine gerechnete Ersparnis ist
 
 Steht der Code wörtlich da, sind die Zieldateien namentlich genannt und die Verbote ausdrücklich, dann ist die Executer-Rolle **Abschrift, nicht Autorschaft** — dafür genügt Haiku. Bleibt Ermessen offen, ist es Fehlersuche, oder muss Fließtext formuliert statt abgeschrieben werden, dann Sonnet.
 
+**Ausnahme für Abschrift mit typografischen Zeichen (seit 2026-09-23, Pascals Entscheidung):** Enthält ein Codeblock des Tasks Anführungszeichen wie „ “ ” ‚ ‘ ’ « », Gedanken- oder Streckenstriche – — oder Auslassungspunkte …, dann `modell: sonnet` und `effort: low` statt Haiku. Haiku hat solche Zeichen in der Messung still ersetzt, siehe „Effort je Rolle". Nachsehen lässt sich das je Taskdatei, die Ausgabe `[]` heißt Haiku geht:
+
+```bash
+python -X utf8 -c "import sys; t=open(sys.argv[1],encoding='utf-8').read(); b=''.join(t.split(chr(96)*3)[1::2]); print(sorted(set(b) & set('„“”‚‘’«»–—…')))" task-NN-thema.md
+```
+
+Das Feld `effort:` im Task-Frontmatter ist freiwillig. Fehlt es, gilt das Frontmatter des Executers (`medium`); bei `modell: haiku` bleibt es wirkungslos.
+
 **4 Gegenprüfen — der Kern der Schleife.** Ein Agentenbericht ist eine Behauptung, kein Beleg. Pflicht sind drei Dinge:
 
 - Testlauf selbst wiederholen, nicht die zitierte Ausgabe übernehmen.
@@ -88,6 +96,8 @@ Dabei die **Ertragskurve mitschreiben**: was hat Runde 1 gefunden, was Runde 2,
 
 - **Escape-Folgen und unsichtbare Zeichen überleben die Schreibschicht nicht verlässlich.** Eine Unicode-Escape-Folge im Code (Backslash, `u`, vier Hex-Ziffern) wird auf dem Weg durch die JSON-Eingabe eines Schreibwerkzeugs mal zum echten Zeichen, mal bekommt sie einen zweiten Backslash — beim Executer wie beim Koordinator. Umgekehrt wird ein echtes unsichtbares Zeichen im Plan (etwa U+2028) beim Abschreiben zum Leerzeichen, und der Test dazu bleibt grün und blind. Am 2026-09-17 im Projekt „Trading Plattform" wichen vier von fünf Haiku-Tasks mit solchen Folgen ab, einmal mit sichtbarem Fehler auf der Seite bei grünen Tests; der Koordinator hat denselben Fehler beim Korrigieren des Plans selbst gemacht. Regel: Nach jedem Schreiben einer solchen Stelle die Bytes ansehen (`od -c`); Korrekturen daran per Skript mit `chr()`-Codepunkten; nach jeder programmatischen Plankorrektur die Codeblöcke auf Zeilen- und Absatztrenner, Format- und Steuerzeichen absuchen; der Planer vermeidet Escape-Folgen, wo ein sichtbares Zeichen erlaubt ist — und wo die Folge Absicht ist (Homoglyph, unsichtbares Zeichen), sichert ein Test den gerenderten Wortlaut. Die Selbstprüfung eines Executers läuft über das Read-Werkzeug, nicht über grep: Dort sieht man, ob ein oder zwei Backslashes dastehen.
 
+- **pytest kürzt ohne Terminal.** Die `FAILED`-Zeilen der Kurzzusammenfassung enden bei 80 Zeichen, die Fehlerart fehlt dann („Failed: D..."). Am 2026-09-23 fanden das zwei Plankritik-Linsen unabhängig, nachgemessen an pytest 9.1.1: 80 Zeichen ohne, 103 mit `COLUMNS=300`. Ein Plan, der eine Fehlerzeile wörtlich erwartet, setzt deshalb `COLUMNS=300` in den Befehl; sonst hält der Executer an oder bestätigt ungesehen. Die Regel für den Planer steht in `.claude/agents/planer.md`.
+
 Nach jeder programmatischen Änderung an einem Plan: eingebettete Codeblöcke parsen lassen und die Überschriften zählen. Beides kostet zwei Zeilen und hätte beide Fälle gefangen. Und nach jedem Executer-Lauf: jede vollständig ersetzte oder neu angelegte Datei byteweise gegen den Codeblock im Plan vergleichen — ein Bericht mit „keine Abweichungen" ist eine Behauptung, der Vergleich ist der Beleg.
 
 **Die Messung verformt die Arbeit, wenn sie mehr misst als gemeint war.** Eine Nachweisvorgabe verlangte Zahlengleichheit über eine ganze Datei — damit musste ein Befehlszusatz auch in Überschriften stehen und machte das Kapitel unlesbar. Der Executer hat das als Abweichung gemeldet statt still davon abzuweichen; der Fehler lag in der Vorgabe, nicht in der Umsetzung. Prüfbefehle auf den Geltungsbereich einschränken, den sie meinen.
@@ -167,7 +177,7 @@ Dieselbe Quellenpflicht gilt für dich als Koordinator. Was du nicht an einer Qu
 
 ### Modellzuordnung und Superpowers
 
-Die Rollentabelle steht im Stamm ([[CLAUDE|Claude.md]], Abschnitt „Agenten & Modelle"). Kurz: Denken und Prüfen auf **Opus 5**, Tippen und Suchen auf **Sonnet 5**.
+Die Rollentabelle steht im Stamm ([[CLAUDE|Claude.md]], Abschnitt „Agenten & Modelle"). Kurz: Denken und Prüfen auf **Opus 5.5**, Tippen und Suchen auf **Sonnet 5**. Den Effort je Rolle regelt „Effort je Rolle" unten.
 
 **Beim Start eines Subagenten das Modell immer explizit angeben.** Ohne Angabe erbt der Subagent das Sitzungsmodell — bei Opus-Sitzungen laufen dann auch mechanische Umsetzungsaufgaben auf Opus, was die Zuordnung still aushebelt.
 
@@ -180,8 +190,8 @@ Superpowers-Skills sprechen von „dispatch a `general-purpose` subagent". Diese
 | `subagent-driven-development` → Task Reviewer / Re-Review | `pruefer` | `opus` |
 | `requesting-code-review` → Code Reviewer | `pruefer` | `opus` |
 | `verification-before-completion` | `pruefer` | `opus` |
-| `dispatching-parallel-agents` (Recherche) | `Explore` / `general-purpose` | `sonnet` |
-| `systematic-debugging` → Hypothese bilden | Koordinator selbst | Opus 5 |
+| `dispatching-parallel-agents` (Recherche) | `recherche`; reine Dateisuche `Explore` | `sonnet` |
+| `systematic-debugging` → Hypothese bilden | Koordinator selbst | Opus 5.5 |
 
 Die Modellwahl-Empfehlung in `subagent-driven-development` („use the least powerful model that can handle each role") bleibt gültig und wird hier auf drei Stufen gebracht: alles Urteilende auf Opus, alles Ausführende auf Sonnet, reine Abschrift auf Haiku. Nur wenn der Executer in der Fehlerbehebungsschleife zweimal hintereinander scheitert, wird die Nachbesserung an einen Opus-Agenten hochgestuft.
 
@@ -201,6 +211,41 @@ Was das **nicht** belegt: Es sind zwei verschiedene Aufgaben, kein kontrollierte
 
 Und der wichtigste Punkt zur Reihenfolge der Hebel: **Die teure Ressource ist nicht der Executer, sondern der Koordinatorkontext, den jede zusätzliche Korrekturrunde verbraucht.** Ein Modell, das eine Runde spart, schlägt jede Ersparnis am Tokenpreis. Deshalb steht die Frage „braucht dieser Task Ermessen" vor der Frage „welches Modell ist billiger".
 
+### Effort je Rolle
+
+Der Effort ist neben dem Modell der zweite Regler, und bis 2026-09-23 war er nirgends gesetzt. Ein Subagent ohne eigenen Effort erbt den der Hauptsitzung. Läuft die auf `xhigh` oder `max`, laufen Planer, Prüfer und Executer mit. Was das gekostet hat, zeigt die Historie über 751 Subagenten aus 47 Sitzungen (2026-08-05 bis 2026-09-23). Der Median je Lauf lag beim Planer auf Opus 5 bei 5,16 $ mit `high` und 18,55 $ mit `max`, beim Prüfer bei 7,11 $ gegen 13,24 $, beim Sonnet-Executer bei 0,76 $ gegen 1,59 $. Die Aufgaben waren verschieden groß, sauber vergleichbar ist das also nicht. Der Modellkatalog im Claude-Code-Programm nennt für Sonnet 5 aber selbst die Kostenfaktoren: `xhigh` das 2,4-Fache, `max` das 5,6-Fache von `high`.
+
+Woher ein Agent seinen Effort bekommt, in dieser Rangfolge (nachgelesen im Programm 2.1.280): eine gesetzte Umgebungsvariable `CLAUDE_CODE_EFFORT_LEVEL` schlägt alles, ist im Vault aber nicht gesetzt (geprüft 2026-09-23); danach der `effort`-Parameter eines Workflow-`agent()`-Aufrufs, dann `effort:` im Frontmatter der Agentendatei, dann der Effort der Sitzung, dann der Standard des Modells. Das Agent-Werkzeug hat keinen Effort-Parameter; dort wirkt nur das Frontmatter. Belegt am 2026-09-23 in einer frischen Sitzung auf `xhigh`: `executer` lief mit `medium`, `pruefer` mit `high`, beides aus dem Transkriptfeld `effort`. Belegt ist das auch im Workflow: Mit `agentType` liefen `executer` und `recherche` mit `medium` aus dem Frontmatter, der Agent ohne Typ mit dem `xhigh` der Sitzung. Zwei Fallstricke dabei. Eine geänderte Agentendatei wirkt in der laufenden Sitzung nicht sofort: Die Änderung von 13:58 zeigte sich um 14:00 noch nicht, knapp eine Stunde später schon. Was das Nachladen auslöst, ist nicht bekannt; sicher ist nur der Blick ins Transkriptfeld `effort`. Einen neu angelegten gespeicherten Workflow kannte die laufende Sitzung zuerst nicht, eine frische schon. Gut eine Stunde später war er auch in der laufenden aufrufbar. Und Haiku 4.5 kennt keinen Effort; ein gesetzter Wert wird gar nicht gesendet.
+
+Die Werte stammen aus einer Messung vom 2026-09-23 an drei Prüfständen mit bekanntem Ergebnis, je Stufe zwei Läufe:
+
+| Rolle | Effort | Was gemessen wurde | Median je Lauf |
+|---|---|---|---|
+| `pruefer` (Opus 5.5) | `high` | Review-Fall mit neun eingebauten Fehlern gegen eine SPEC, Tests grün. Jede Stufe von `low` bis `xhigh` fand 9 von 9, keine Fehlalarme. Berechtigte Zusatzfunde je Lauf: `low` 1 und 1, `medium` 3 und 1, `high` 3 und 3, `xhigh` 3 und 3. | `low` 0,24 $, `medium` 0,29 $, `high` 0,34 $, `xhigh` 1,09 $ |
+| `planer` (Opus 5.5) | `high` | Korrekturplan für dieselben neun Fehler, danach mit `plan_materialisiere.py` angewendet. Alle sechs Pläne ließen sich anwenden, Suite grün, 9 von 9 behoben (eigene Probe). Gegen den alten Code schlugen je Plan 9 bis 13 der neuen Tests fehl; die 1 bis 3 schon vorher grünen sind laut Planerbericht bewusste Absicherungstests. Bei Anwendbarkeit, Suite und Probe kein Unterschied zwischen den Stufen. | `medium` 0,75 $, `high` 0,82 $, `xhigh` 2,90 $ |
+| `executer` (Sonnet 5) | `medium` | Abschrift-Task mit einem Prüf-grep, der den Docstring trifft. Alle Stufen schrieben gleich treu ab und meldeten den Widerspruch, statt den Docstring umzuformulieren. | `low` 0,13 $, `medium` 0,15 $, `high` 0,19 $ |
+
+Warum nicht überall die billigste Stufe: Beim Prüfer ist Abdeckung der Zweck. Ab `high` brachten beide Läufe die drei Zusatzfunde, darunter nicht; `xhigh` brachte nicht mehr als `high`. Beim Planer war `medium` gleich gut und 9 Prozent billiger. Ein Fehler im Plan kostet aber Executer-Wellen und Korrekturrunden im Koordinatorkontext, deshalb `high`. Beim Executer entspricht `medium` laut Doku etwa Sonnet 4.6 bei `high`. Ob `medium` bei Tasks mit Ermessen hält, ist nicht gemessen; scheitert ein Executer dort, gilt die Hochstufung auf Opus aus dem Abschnitt oben.
+
+`xhigh` kostete beim Prüfer das 3,2-Fache, beim Planer das 3,5-Fache von `high`, ohne einen zusätzlichen Treffer im Schlüssel. Ein Prüfer auf `xhigh` fuhr dafür laut seinem Bericht einen großen eigenen Datenlauf (600 Artikel, 5000 Buchungen). Das ist genau der Lauf mit echten Daten, der Fehler findet, die erst bei realistischen Mengen auftreten — der Prüfstand hatte keinen solchen Fehler. Für die Abschlussprüfung einer sicherheits- oder datenrelevanten Änderung gibst du im Workflow deshalb `effort: 'xhigh'` mit.
+
+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. Plankritik, Executer-Welle und Prüfung liegen als gespeicherte Workflows unter `.claude/workflows/` (`plankritik`, `executer-welle`, `pruefung`); sie setzen genau das um und halten Opus bei höchstens zwei gleichzeitig. 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.
+- Eine selbst gebaute Kopie verlangt eine nicht leere Liste von Ausschlüssen (`ohne`), gedacht für `.git` und Geheimnisdateien; fehlt sie oder ist sie leer, bricht der Workflow vor dem ersten Agenten ab. Ob die Liste die Geheimnisse wirklich trifft, sieht er nicht — das bleibt deine Sorgfalt. Die Kopie bleibt im Temp liegen, der Rückgabewert nennt den Ordner (`temp_ordner`).
+- Scheitert in `welle-mit-pruefung` ein verschachtelter Schritt, kommen Welle, Kopie und Vergleich trotzdem zurück, der Fehler steht unter `fehler`.
+
+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`. Höchstens zwei Opus-Agenten gleichzeitig: Am 2026-09-20 riss das Wochenkontingent bei neun parallelen Opus-Agenten, und alles stand zwei Stunden. 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.
+
+**Haiku und typografische Zeichen.** Im Abschrift-Prüfstand ersetzte Haiku 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.
+
+**Die Escape-Folge für U+2028 hat jedes Modell verloren.** Alle acht Abschrift-Läufe, Haiku wie Sonnet in jeder Stufe, schrieben sie als echtes Zeichen in die Datei. Alle acht Berichte nannten die Datei trotzdem „byte-genau" übernommen, die Tests blieben grün. Das liegt an der Schreibschicht, nicht am Modell. Der Byte-Vergleich nach jeder Welle bleibt Pflicht, egal mit welchen Parametern.
+
 **Bei parallelem Einsatz zusätzlich:**
 
 - **Disjunkte Zieldateien.** Jeder Subagent bekommt die exakten Pfade genannt, die er anlegen darf, und die Anweisung, nichts anderes anzufassen. Gemeinsam benötigte Dateien (Paket-`__init__.py`, `.gitignore`) legt der Koordinator vorher an.

AI/Regelwerk/opus-5.md

@@ -2,17 +2,18 @@
 type: resource
 status: reference
 title: Prompting-Hinweise für Claude Opus 5
-summary: Verhaltensunterschiede und Prompt-Muster von Claude Opus 5 (Teil A) sowie Spezifikation, API-Brüche, neue Funktionen, Preise (Teil B) aus der Anthropic-Doku. Betrifft Koordinator, Planer und Prüfer.
+summary: Verhaltensunterschiede und Prompt-Muster von Claude Opus 5 (Teil A) sowie Spezifikation, API-Brüche, neue Funktionen, Preise (Teil B) aus der Anthropic-Doku; Teil D nennt, was bei Opus 5.5 abweicht. Betrifft Koordinator, Planer und Prüfer.
 tags: [regelwerk, modelle, opus, prompting]
 created: 2026-09-05
-updated: 2026-09-05
+updated: 2026-09-23
 source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
 ---
 
 # Prompting-Hinweise für Claude Opus 5
 
-> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Opus 5** verhält und wie man Aufträge an es formuliert. Im Vault läuft Opus 5 als Koordinator, als `planer` und als `pruefer`. Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Opus-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Opus 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
+> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Opus 5** verhält und wie man Aufträge an es formuliert. Im Vault liefen Koordinator, `planer` und `pruefer` auf Opus 5, bis der Alias `opus` auf Opus 5.5 wechselte (siehe unten und Teil D). Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Opus-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Opus 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
 > Angeordnet am 2026-09-05. Quellen: „Prompting Claude Opus 5" (Teil A), „What's new in Claude Opus 5" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Aussagen stammen aus der Doku, nicht aus eigener Messung.
+> **Seit spätestens Claude Code 2.1.280 löst der Alias `opus` auf Opus 5.5 auf, nicht mehr auf Opus 5.** Laut Anthropic bleiben die Muster dieser Datei für Opus 5.5 ein vernünftiger Ausgangspunkt. Was abweicht, steht in Teil D.
 
 ## Wozu diese Datei
 
@@ -215,6 +216,24 @@ Gleiche API-Oberfläche — Thinking an, Effort `high`, 1M/128k, kein Priority T
 
 Für den Vault heißt das konkret: Ein Harness, der rundenbezogene System-Nachrichten oder Werkzeugänderungen im Gespräch nutzt, läuft so nur auf Opus 5 und Fable 5.1, nicht auf dem Executer-Modell.
 
+---
+
+# Teil D — Opus 5.5: was abweicht
+
+Am 2026-09-23 nachgelesen, zum einen im Modellkatalog von Claude Code 2.1.280 (Programmdatei), zum anderen in der Anthropic-Doku. Die Doku hat ein Recherche-Agent abgerufen; die Zitate unten stammen aus seinem Bericht, nicht aus eigenem Abruf. Eine eigene Vorlage wie für Opus 5 gibt es für Opus 5.5 noch nicht.
+
+- **Der Alias.** `opus` löst in 2.1.280 auf `claude-opus-5-5` auf. Planer, Prüfer und eine Hauptsitzung mit `opus` laufen also auf Opus 5.5.
+- **Standard-Effort ist `medium`**, bei Opus 5 war es `high`. Die Doku empfiehlt, bei `medium` zu starten und Stufen neu zu messen, statt die Einstellung von Opus 5 zu übernehmen. Sie sagt, Opus 5.5 habe bei `medium` Opus 5 auf `high` erreicht oder übertroffen, „in fewer steps and with fewer tokens". Für lange agentische Arbeit über 30 Minuten nennt die Effort-Seite `xhigh`. Was im Vault gilt, steht mit eigener Messung in [[AI/Regelwerk/codeworkflow|codeworkflow.md]], „Effort je Rolle".
+- **Thinking lässt sich nicht abschalten**, auf keiner Stufe. `thinking: {"type": "disabled"}` und `budget_tokens` liefern 400. Abschnitt 9 sowie die Thinking-Zeilen in B1 und B2 gelten für Opus 5.5 deshalb nicht.
+- **Preis:** 4 $ Eingabe, 20 $ Ausgabe, 0,20 $ Cache-Lesen je Million Tokens (Katalog-Tarif `tier_4_20_cache_read_0_20`). Opus 5 kostet 5 $, 25 $ und 0,50 $.
+- **Kontext 1M, Ausgabe 128k.** Laut Doku ist Opus 5.5 mit Zero Data Retention verfügbar.
+- **Kürzer und schneller.** Laut Prompting-Seite erzeugt es Ausgabetokens über 30 Prozent schneller als Opus 5 und braucht für dieselbe Aufgabe tendenziell weniger Tokens. Die Prozentzahlen zur Kürze auf der Ankündigungsseite sind Kundenzitate, keine Messung von Anthropic.
+- **Erzwungene Werkzeugwahl** (`tool_choice` mit `any` oder `tool`) liefert laut Bericht des Recherche-Agenten 400. Das hat er als Nebenfund ohne Zitat gemeldet, belegt ist es also nicht.
+
+Nicht eigens behandelt: Über-Verifikation (Abschnitt 5), Delegieren (6) und Schwellen im Prüfauftrag (8) greift die Opus-5.5-Seite nicht noch einmal auf. Dass sie weiter gelten, ist ein Rückschluss aus dem Satz, die Opus-5-Muster blieben ein Ausgangspunkt. Ein eigener Beleg dafür fehlt. Der Review-Prüfstand vom 2026-09-23 lief ohne Schwelle im Auftrag und sagt deshalb nichts darüber.
+
+Quellen: https://platform.claude.com/docs/en/build-with-claude/effort, https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5, https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5, https://platform.claude.com/docs/en/models/opus-5-5/overview (abgerufen 2026-09-23).
+
 ## Wohin die Punkte im Regelwerk zeigen
 
 | Regelwerk-Datei | Verweist auf Abschnitt |

AI/Regelwerk/sonnet-5.md

@@ -5,13 +5,13 @@ title: Prompting-Hinweise für Claude Sonnet 5
 summary: Verhaltensunterschiede und Prompt-Muster von Claude Sonnet 5 (Teil A) sowie Spezifikation, API-Brüche, Tokenizer, Cyber-Schutz, ZDR-Fähigkeit (Teil B) aus der Anthropic-Doku. Betrifft den Executer und die Recherche-Agenten.
 tags: [regelwerk, modelle, sonnet, prompting]
 created: 2026-09-05
-updated: 2026-09-05
+updated: 2026-09-23
 source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5
 ---
 
 # Prompting-Hinweise für Claude Sonnet 5
 
-> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Sonnet 5** verhält und wie man Aufträge an es formuliert. Im Vault läuft Sonnet 5 als `executer` und als Recherche-Agent (`Explore`, `general-purpose`). Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Sonnet-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Sonnet 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
+> **Geltungsbereich.** Diese Datei beschreibt, wie sich **Claude Sonnet 5** verhält und wie man Aufträge an es formuliert. Im Vault läuft Sonnet 5 als `executer` (Effort `medium`), als Rechercheagent `recherche` (Effort `medium`, seit 2026-09-23 statt `general-purpose`) und im eingebauten `Explore`. Zwei Leser: (1) **Fable 5.1**, wenn es als Koordinator einen Auftrag an einen Sonnet-Subagenten schreibt — dann ist das hier verbindlich für die Formulierung. (2) **Sonnet 5 selbst** — es arbeitet nach seinen eigenen Optimierungen und entscheidet selbst, ob es einen Punkt übernimmt. Die Rollentabelle im Stamm ([[CLAUDE|Claude.md]]) bleibt unverändert.
 > Angeordnet am 2026-09-05. Quellen: „Prompting Claude Sonnet 5" (Teil A), „What's new in Claude Sonnet 5" (Teil B) und der Migrationsleitfaden (Teil C), alle abgerufen am 2026-09-05. Aussagen stammen aus der Doku, nicht aus eigener Messung.
 
 ## Wozu diese Datei

AI/Regelwerk/veroeffentlichung.md

@@ -5,7 +5,7 @@ title: "Veröffentlichung der Anweisungsschicht"
 summary: "Welcher Teil des Vaults in das Gitea-Repo claude-regelwerk geht, wie die Positivliste funktioniert und was der automatische Push tut. Laden, bevor der veröffentlichte Umfang geändert wird oder wenn ein Auto-Push-Befund im Kontext steht."
 tags: [regelwerk, git, veroeffentlichung, werkzeuge]
 created: 2026-09-17
-updated: 2026-09-17
+updated: 2026-09-23
 ---
 
 # Veröffentlichung der Anweisungsschicht
@@ -24,7 +24,7 @@ Angeordnet am 2026-09-17. Die Anweisungsschicht des Vaults liegt seitdem in eine
 
 Die `.gitignore` im Vault-Root ist eine **Positivliste**: Sie schließt mit `/*` erst alles aus und nimmt dann einzeln wieder auf. Eine Ausschlussliste wäre hier falsch herum — sie müsste jede künftige Notiz, jeden neuen Kundenordner und jede Depotdatei vorhersehen, und die erste vergessene Zeile ist eine Veröffentlichung.
 
-Eingeschlossen sind: `CLAUDE.md`, `README.md`, `AI/Regelwerk/`, `.claude/agents/`, `.claude/skills/`, `.claude/settings.json`, `.vault-tools/`.
+Eingeschlossen sind: `CLAUDE.md`, `README.md`, `AI/Regelwerk/`, `.claude/agents/`, `.claude/skills/`, `.claude/workflows/` (seit 2026-09-23, auf Pascals Wort), `.claude/settings.json`, `.vault-tools/`.
 
 Draußen bleibt damit alles andere, insbesondere `Inbox/`, `Code Projekte/`, `Security - Compliance Projekte/`, `Finanzen/`, `IT Workspace/`, `AI/sessions/`, `AI/secondbrain/`, `Bookstack/`, `Import/` und `.claude/settings.local.json`.