claude-regelwerk/AI/Regelwerk/codeworkflow.md

type, status, title, summary, tags, created, updated

type	status	title	summary	tags	created	updated
resource	reference	Codeworkflow	Arbeitsweise für Code-Projekte — Standardschleife, Planaufteilung je Task, Subagenten und ihre Modellstufen und Effort, Gegenprüfung, Lauf mit echten Daten, Aufgabenmanagement.	regelwerk codeworkflow code-projekte	2026-08-03	2026-10-09

Codeworkflow

Gilt für alles unter /Code Projekte. Wird nur geladen, wenn tatsächlich an einem Code-Projekt gearbeitet wird — nicht bei IT-Workspace-Recherche, Reviews o. Ä.

Dateikopf, CHANGELOG-Regel und Codedoku stehen seit 2026-08-30 in AI/Regelwerk/codedoku. Die lädst du dazu, sobald Produktivdateien entstehen — nicht beim Planen und nicht beim Debuggen.

Standardschleife

Das ist der Regelfall für jede nicht triviale Code-Aufgabe, nicht die Ausnahme. Rollen sind fest verteilt: der Koordinator (Opus) denkt und prüft, der Executer (Sonnet) tippt.

1 Klären  →  2 Planen  →  3 Ausführen  →  4 Gegenprüfen  →  5 Korrigieren  →  6 Abschließen
 Koordinator  Koordinator   Executer       Koordinator      Koordinator      Koordinator
                                                                  ↑                 │
                                                                  └──── 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. 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, 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, 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).

Ein Plan ab etwa drei Tasks wird als Ordner angelegt, nicht als eine Datei: 00-uebersicht.md mit Ziel, Architektur, globalen Vorgaben, Dateiübersicht, Tasktabelle und Abnahme, dazu je Task eine Datei task-NN-<thema>.md. Jede Taskdatei verweist im Kopf auf die globalen Vorgaben der Übersicht, statt sie zu wiederholen — zwei Fassungen derselben Vorgabe laufen auseinander.

Die Gründe, in der Reihenfolge ihrer Belastbarkeit. Erstens: Der Auftrag wird präzise. Ein Executer, der nur seine Taskdatei bekommt, kann nicht in einen Nachbartask abrutschen. Zweitens: Die Modellangabe je Task braucht einen Ort, an dem sie steht — das ist das Frontmatter der Taskdatei. Drittens, und schwächer als zunächst angenommen: Tokens.

Zur dritten Begründung die ehrliche Messung vom 2026-08-27 im Projekt „Authentik". Der Gesamtplan umfasste rund 16.300 Tokens, ein einzelner Task rund 1.500. Die Erwartung war, dass die Aufteilung damit den größten Hebel darstellt. Sie tat es nicht. Der erste Lauf ohne Aufteilung kostete 42.918 Tokens, der erste Lauf mit Aufteilung 40.962 — rund 2.000 weniger, obwohl rechnerisch 13.000 weniger Plan gelesen wurde, und obwohl die zweite Aufgabe zugleich die kleinere war. Der feste Aufwand eines Subagenten — Systemvorgaben, Werkzeugbeschreibungen, sein eigenes Nachdenken — dominiert den Einzellauf.

Die Lehre daraus gilt über diesen Fall hinaus: Eine gerechnete Ersparnis ist keine gemessene. Wer einen Hebel einführt, misst ihn nach, bevor er ihn als Regel festschreibt.

Beim programmatischen Aufteilen eines bestehenden Plans: an Überschriften schneiden, die ab dem Abschnittsanfang gesucht werden, und danach Codeblöcke und Überschriften gegen das Original zählen. Ohne diese Zählprobe fällt ein verrutschter Schnitt erst auf, wenn ein Executer nach einem Schritt sucht, der zweimal dasteht.

3 Ausführen. Ein Executer, sofern die Zieldateien nicht sauber trennbar sind; sonst mehrere parallel mit disjunkten Dateimengen. Er bekommt den Pfad seiner Taskdatei — nicht des Gesamtplans —, die erlaubten Zieldateien, die Verbote und den Verifikationsbefehl.

Der Extraktor kennt kein „erst die Tests“. plan_materialisiere.py wendet eine Taskdatei immer vollständig an; Testdateien und Produktivcode entstehen in einem Durchgang. Die Reihenfolge aus Schritt 7 der Taskform — Test anlegen, Fehlschlag im Wortlaut sehen, dann die Umsetzung — lässt sich damit nicht über zwei Aufrufe herstellen. Der belegte Weg steht deshalb in den Auftrag: die fertige Produktivdatei kurz beiseitelegen (etwa aus git show HEAD:<pfad>), den roten Lauf beobachten, die materialisierte Fassung byte-gleich zurücklegen — nie neu schreiben. Am 2026-09-17/18 im Projekt „Home Assistant Dashboard“ sind zwei Executer über diesen Widerspruch gestolpert; beide haben ihn gemeldet statt ihn still aufzulösen, und beide haben den roten Zustand auf diesem Weg belegt. Wer den Satz nicht in den Auftrag schreibt, lässt den Executer zwischen Plan und Werkzeug zerreiben.

Das Modell steht in der Taskdatei, nicht in der Gewohnheit. Jede Taskdatei trägt im Frontmatter modell: und modell_begruendung:. Die Begründung ist Fließtext und steht in Anführungszeichen, wie der Titel (AI/Regelwerk/frontmatter, „Quoting"). Fehlt der Eintrag, gilt die Vorgabe aus dem Stamm: Sonnet. Das Kriterium ist eine einzige Frage:

Braucht der Executer für diesen Task Ermessen, oder steht alles wörtlich im Plan?

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.

Typografische Zeichen (Pascals Entscheidung vom 2026-10-09, ersetzt die vom 2026-09-23): Abschrift mit Anführungszeichen wie „ “ ” ‚ ‘ ’ « », Gedanken- oder Streckenstrichen – — oder Auslassungspunkten … läuft auf modell: haiku wie jede andere Abschrift. Haiku 5.5, auf das haiku seit 2026-10-07 zeigt, hat alle elf Zeichen am 2026-10-09 in 6 von 6 Läufen byte-genau übernommen (AI/Regelwerk/haiku-5-5, A3). Haiku 4.5 hatte sie am 2026-09-23 still ersetzt, siehe „Effort je Rolle". Wählt der Alias außerhalb der Anthropic-API noch Haiku 4.5, gilt dort weiter modell: sonnet und effort: low. Der Byte-Vergleich bleibt in jedem Fall Pflicht. Ob ein Task solche Zeichen enthält, zeigt dieser Befehl, die Ausgabe [] heißt keine:

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 verwirft executer-welle einen Task-Effort derzeit und lässt das medium des Executers stehen, das Haiku 5.5 auch erhält (AI/Regelwerk/haiku-5-5, A1 und A7).

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.
• Die zentralen Artefakte selbst lesen (SKILL.md, README, die Hauptmodule) statt sie aus dem Bericht zu glauben.
• Einen eigenen Lauf mit echten Daten fahren, mit eigenem Prüfcode. Nicht die Tests des Agenten. Siehe „Lauf mit echten Daten" unten.

Die eigene Gegenprüfung läuft, während der pruefer arbeitet, nicht danach. welle-mit-pruefung mit bis: "vergleich" endet vor der Prüfung und gibt pruefung_args mit den Rohbelegen zurück; damit startest du pruefung im Hintergrund und prüfst in derselben Zeit selbst. Solange er läuft, schreibst du nichts in Projektbaum oder Planordner, fährst Rot- und Mutantentests nur auf einer Kopie und brichst ihn nicht ab, auch nicht bei einem eigenen Blocker. Ein abgebrochener Prüfer hinterlässt eine Runde ohne volle Abdeckung, und jede weitere Korrekturrunde bringt ihre eigene Fehlerschicht. Plankorrektur und Commit kommen nach seinem Bericht. Der Gewinn ist höchstens die Lücke nach der Prüfung: im Hub am 2026-09-24 drei bis elf Minuten je Prüfung, gerechnet aus sechs Prüfungen, nicht gemessen.

Mechanische Prüfungen brauchen einen Regressionsnachweis. Ein Prüfskript gilt erst als Gate, wenn du es mit absichtlich kaputter Eingabe hast anschlagen sehen — Exit-Code und Meldung selbst beobachtet, nicht aus einem Bericht übernommen. Ohne diesen Nachweis ist ein grüner Lauf kein Ergebnis, sondern eine unbelegte Zusicherung.

Für jede Prüfung, die eine offene Menge einschränkt (verbotene Aktionen, verbotene Wörter, unerlaubte Muster), gilt zusätzlich: Positivliste statt Negativliste. Was nicht ausdrücklich erlaubt ist, ist ein Befund. Eine handgepflegte Negativliste verliert prinzipiell gegen eine offene Menge — 2026-08-18 im Projekt „Logging" fünfmal hintereinander belegt: jede Fassung des Rollenprüfskripts schloss die genannte Lücke und riss eine neue auf. Der Kopfkommentar eines solchen Skripts benennt deshalb seinen Geltungsbereich: was es prüft, was es nicht sieht, und dass es ein Fangnetz ist und kein Nachweis. Wo der belastbare Nachweis erst in der Zielumgebung möglich ist, gehört er dorthin und wird bis dahin als offen geführt.

Sobald ein Skript entsteht, das etwas beurteilt statt etwas zu tun, gilt AI/Regelwerk/pruefwerkzeuge — und zwar vor der ersten Zeile Code. Dort steht der Entwurfsschritt, der die teuren Schleifen verhindert: je Frage, die die Prüfung beantworten soll, die Herkunft der Antwort benennen (Quelle, Projektvorgabe oder Annahme) und jede Annahme auflösen, bevor Code entsteht. Dazu die vollständige Angriffsliste, die Absturzfestigkeit und die Abbruchbedingung. Eine einzige Prüfung hat ohne diese Datei drei Fix-Runden und drei Re-Reviews gekostet.

5 Korrigieren. Befunde am Plan beheben, nicht direkt am Code — sonst laufen Plan und Umsetzung auseinander. Danach den Executer nachziehen lassen, mit dem gefundenen Fehlerbild und der erwarteten Fehlermeldung des neuen Regressionstests. Zurück zu Schritt 4, bis nichts mehr übrig ist.

Fortsetzen oder frisch starten — das ist eine Kostenfrage, und hier liegen Zahlen vor. Eine Nachricht an den bestehenden Executer zieht dessen gesamten bisherigen Kontext mit. Am 2026-08-27 im Projekt „Authentik", zwei Nachbesserungen von je drei Dateien: als Fortsetzung 66.398 Tokens, als frischer Subagent 51.072 — rund 23 Prozent weniger. Das Ergebnis überlebt die Vermischung der Versuchsbedingungen, weil es gegen die Erwartung läuft: Der frische Lauf lief auf dem teureren Modell und kam trotzdem günstiger heraus.

Faustregel: Lässt sich die Nachbesserung in einem Auftrag beschreiben, der für sich steht — geänderte Planstelle, Fehlerbild, erwartete Fehlermeldung —, dann ein frischer Subagent. Fortsetzen nur, wenn der Verlauf selbst gebraucht wird, etwa bei einer Fehlersuche über mehrere Runden.

Nachbesserung nach einer ausgeführten Welle als Delta, nicht als Neufassung. Der planer schreibt dann neue Taskdateien mit Aus:/wird:-Blöcken und für ältere Tasks eine Folgenliste. Die Regel für ihn steht in .claude/agents/planer.md, weil er das Regelwerk nicht lädt. Dein Teil: Die Plankritik liest nur die neuen Tasks und die Folgenliste (materialisieren.tasks). Nach dem Anwenden läuft plan_bloecke.py nach auf einer frisch gebauten Kopie. Die Folgenliste setzt ein Executer ein, danach prüfst du die Zeilenenden mit git ls-files --eol oder file, nicht mit grep. Und die spec.json des Rot-Nachweises bekommt die neuen Tasks. Gemessen im Hub am 2026-09-24: rund 20 Minuten je Runde schneller als die Neufassung, drei gegen drei Runden, nicht kontrolliert. Am 2026-09-23 waren beim Neuschreiben 10 von 17 Befunden der Nachprüfung durch das Umschreiben selbst entstanden. Für die Korrektur nach der Plankritik vor der ersten Ausführung ist das Delta nicht belegt.

Die Nachbesserung folgt derselben Reihenfolge wie der Task selbst: erst die neuen Tests, Fehlschlag im Wortlaut beobachten lassen, dann die Implementierung. Wer beides gleichzeitig schreiben lässt, bekommt einen grünen Lauf ohne Beleg, dass die neuen Tests je etwas gemessen haben.

Dabei die Ertragskurve mitschreiben: was hat Runde 1 gefunden, was Runde 2, was Runde 3. Fällt der Ertrag auf Umformulierungen, ist Schluss — und der Prüfer wird im Abschlussauftrag ausdrücklich gefragt, ob eine weitere Runde noch Substanz hat. Er hat darauf brauchbar geantwortet und einmal von sich aus empfohlen, ohne weitere Runde zu committen. Jede Nachbesserung ist selbst neuer, ungeprüfter Code und bekommt in derselben Runde ihren eigenen Regressionsfall.

Werkzeugdisziplin beim Ändern von Plänen und Dokumenten. Zwei Korrekturen sind in einer einzigen Sitzung nicht am Inhalt gescheitert, sondern am Werkzeug:

• Suchen ohne Anker. Eine Suche nach einem Schrittnamen ohne Suchanfang traf den gleichnamigen Schritt eines früheren Abschnitts, der vor dem Suchbeginn lag. Der Schnitt duplizierte alles dazwischen — ein ganzer Task stand zweimal im Plan. Regel: Anker immer ab dem Abschnittsanfang suchen, gegen die nächste Überschrift begrenzen, danach die Einmaligkeit der Überschriften zusichern.

• Globales Ersetzen in gemischten Dateien. In einem Dokument, das Prosa und einzubettenden Skriptcode enthält, war derselbe Ausdruck an einer Stelle der Defekt und an der anderen die Lösung. Positionsgenau ersetzen, danach jedes nicht betroffene Vorkommen einzeln ansehen.

• Escaping-Schichten vermeiden. Code, der in ein Dokument eingebettet wird, aus einer Datei einsetzen statt durch eine Zeichenketten-Schicht. Ein falsch maskiertes Zeilenumbruch-Zeichen machte einen Regressionstreiber im Plan unlauffähig — das dort protokollierte Ergebnis hätte mit der hinterlegten Fassung nie entstehen können.

• Keine gepflegten Zahlen in Erwartungstexten. „Erwartet: 6 Tests grün" muss bei jeder Testergänzung von Hand nachgezogen werden und wird dabei falsch — 2026-08-23 im Projekt „Linux Härtung Rocky Linux - KS" zweimal in einer Sitzung, beide Male als Kollateralschaden eines globalen Ersetzens, das für einen anderen Task gedacht war. Der Executer hat es gemeldet, aber erst nachdem er auf die falsche Zahl hin geprüft hatte. Stattdessen: „alle Tests dieser Datei grün, kein Fehlschlag". Das kann nicht driften und sagt dasselbe.

• Prüfbefehle im Plan treffen nur Code, nicht Prosa. Ein Plan verlangte grep -i killswitch ohne Treffer und enthielt das Wort zugleich in den Docstrings desselben Codeblocks — 2026-09-06 im Projekt „Trading Plattform" zweimal in einem Plan. Einmal hat der Haiku-Executer die Kommentare still umformuliert und „keine Abweichungen" gemeldet; erst der Byte-Vergleich Plan gegen Datei hat es gezeigt. Das andere Mal (Sonnet-Auftrag mit dem ausdrücklichen Satz, Widersprüche zu melden statt umzuformulieren) kam die Meldung. Regel: Ein Prüfbefehl sucht das, was er meint — Importzeilen (grep "^from trading.killswitch"), Aufrufe, Konstanten —, nie ein Wort, das auch in einem erklärenden Kommentar stehen darf. Und jeder Executer-Auftrag trägt den Satz, dass ein Widerspruch im Plan gemeldet und nicht still aufgelöst wird.

• 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.

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. 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, 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

Grüne Tests beweisen, dass der Code tut, was die Tests erwarten — nicht, dass die Erwartung stimmt. Vor der Fertigmeldung deshalb einmal mit echten statt erfundenen Daten durchlaufen: Daten der Zielumgebung, des lokalen Rechners, ein realistischer Datensatz in voller Menge.

Zwei Belege aus einer einzigen Sitzung: 49 synthetische Tests waren grün, während eine Ampel verdreht war und gesunde Systeme gelb markierte — sichtbar erst mit echten Rechnerdaten. Und eine Statusberechnung wirkte korrekt, bis realistische Datenmengen zeigten, dass sie 9 von 11 Bereichen rot färbt und damit nichts mehr unterscheidet.

Was echte Daten aufdecken und Fixtures nicht: verdrehte Vorzeichen, Skalierungsprobleme bei realistischen Mengen, Annahmen über Wertebereiche, und Zusammenspiele, die im Kleinen unauffällig bleiben.

Drei Muster, die grüne Tests zuverlässig verstecken (alle 2026-08-05 in „Bookstack Upload" aufgetreten):

• Die Testumgebung verdeckt die Zielumgebung. capsys fängt stdout in UTF-8 ab, die echte Windows-Konsole läuft unter cp1252 — ein Sonderzeichen in der Ausgabe brach jeden Lauf ab, ohne dass ein Test es je sah. Prüfe Ausgabe, Pfade und Kodierung gegen die Zielumgebung, nicht gegen die Testumgebung.
• Testdoubles, die nur zurückspiegeln. Ein Fake, der beim Lesen zurückgibt, was er beim Schreiben bekam, bestätigt die Annahmen des Produktivcodes statt die echte Schnittstelle. Bei asymmetrischen APIs (Schreiben nimmt IDs, Lesen liefert Objekte) muss der Fake die Asymmetrie nachbilden. Im Zweifel in der API-Dokumentation nachschlagen statt Symmetrie anzunehmen.
• Schalterpaare. Wo ein Schalter Schreibzugriffe freigibt und ein anderer sie unterdrückt, ist die Kombination der Testfall — nicht jeder für sich. Für jeden Trockenlauf-Modus einen Test führen, der über das Testdouble jeden schreibenden Aufruf zählt und auf null prüft, statt nur das erwartete Endergebnis zu betrachten.
• Der Test misst den Inhalt, nicht den Rahmen. (2026-08-07, „Paketierung Intune") Die Layouttests prüften, ob der Text ins Fenster passt — grün. Ob das Fenster auf den Bildschirm passt, prüfte niemand: auf 1366×768 bei 125 % Skalierung lag die Fußzeile mit beiden Schaltflächen unter dem Bildschirmrand, der Benutzer hätte nichts mehr anklicken können. Wo etwas in einen Container gesetzt wird, immer beide Ebenen prüfen: passt der Inhalt hinein, und passt der Container dorthin, wo er landet. Die äußere Ebene gehört als reine Funktion mit den Maßen als Parameter getestet — der Entwicklungsrechner ist nie das kleinste Zielgerät.
• Ein Thread im Test, viele im Betrieb. (2026-09-24, „Nexhorizons Hub") FastAPI führt synchrone Abhängigkeiten und Endpunkte im Threadpool aus, und alle Anfragen teilten sich eine SQLite-Verbindung. 402 Tests, drei Plankritik-Runden und zwei Prüfungen waren grün, weil jeder Test einen Thread hat; erst ein Lastlauf gegen die echte Mittelschicht zeigte ein falsches Cookie mit Admin-Sitzung und eine gebrochene Audit-Kette. Hält ein Zustand eine Verbindung, einen Zähler oder einen Cache, steht im Plan, wer ihn aus welchem Thread benutzt, und der Lauf mit echten Daten fährt parallele Klienten.

Screenshots zur Fehlersuche. Vor CopyFromScreen immer SetProcessDPIAware() aufrufen und das Fenster gezielt über GetWindowRect abfotografieren. Ohne das liefert SystemInformation.VirtualScreen bei aktiver Skalierung die logische Größe, während physische Pixel kopiert werden — das Ergebnis ist ein Ausschnitt der linken oberen Ecke, kein verkleinertes Gesamtbild. Sieht ein Fenster auf einem Screenshot abgeschnitten aus: zuerst das Aufnahmeverfahren prüfen, dann den Code. Sonst wird am Produktivcode ein Fehler „behoben", den es nicht gibt.

Nur für Claude Fable 5.1

Läuft der Koordinator auf Fable 5.1, gelten in der Schleife zusätzlich die Punkte 3, 8, 10, 13 und 15 aus AI/Regelwerk/fable-5-1: unabhängige Werkzeugaufrufe in einer Antwort bündeln, einen entschiedenen Schritt ausführen statt ankündigen, Änderungen und Tests auf den Auftrag beschränken (der Regressionsfall je Nachbesserung aus Schritt 5 bleibt Pflicht — er ist beauftragt, kein Zusatz), Edit vor Write, und während ein Executer läuft das erledigen, was nicht von seinem Ergebnis abhängt. Opus 5, Opus 5.5, Sonnet 5, Sonnet 5.5 und Haiku 5.5 entscheiden selbst, ob sie etwas davon übernehmen — die Rollentabelle ändert sich dadurch nicht.

Haltung zwischen den Schritten

Drei Punkte, die überall in der Schleife gelten:

• Läuft etwas schief, hörst du auf und planst neu. Nicht weitermachen und hoffen. Das gilt auch mitten in Schritt 3, wenn der Executer etwas meldet, das den Plan in Frage stellt.
• Bei nicht trivialen Änderungen einmal innehalten: Gibt es einen eleganteren Weg? Fühlt sich eine Korrektur wie ein Hack an, baust du die Lösung, die du mit dem jetzigen Wissen von Anfang an gebaut hättest. Bei offensichtlichen Korrekturen entfällt die Frage — Eleganz ist kein Grund für zusätzliche Komplexität.
• Einen Fehlerbericht behebst du, statt nachzufragen. Fehlgeschlagene Tests, rote CI, Meldungen im Protokoll: benennen und beheben, ohne dass der Auftraggeber den Kontext wechseln muss.

Wann die Schleife entfällt

Situation	Vorgehen
Einzeiler, Tippfehler, offensichtliche Korrektur	Selbst umsetzen — der Auftragstext kostet mehr als die Änderung
Plan liegt vor, ≥ 2 Dateien oder nennenswerter Umfang	Volle Schleife
Offene Recherche, Architekturentscheidung, Debugging ohne Hypothese	Kein Executer — erst klären und planen

Prüfaufwand nach Risiko, Paketgröße und Drehbuch

Seit 2026-09-26 auf Pascals Freigabe:

• Die volle Schleife gilt für Geld-, Sicherheits- und Netzpfade. Dazu gehören Plankritik mit allen Linsen, Mutanten aus der Plantabelle und eine kritische Prüfung. Die Plantabelle ist seit 2026-09-27 die Datei mutanten.toml im Planordner; Format und Läufer stehen in .vault-tools/plan-kopie/LIESMICH.md, Schritt 8. Gemeint ist alles, was Orders erzeugt oder sperrt, Zugänge oder Geheimnisse berührt, nach außen sendet oder Firewall, TLS und Dienste ändert.
• Doku- und Textpakete bekommen einen pruefer, aber keine Plankritik und keine Mutanten. Das gilt für Anleitungen, Drehbücher, README und Regelwerk-Text.
• Für alles dazwischen gelten die Regeln oben unverändert.
• 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

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 und wird nicht nachgeprüft. Frei heißt: kein bestätigter blockierender Befund und kein belegter, der ungeprüft blieb. Ein blockierender Befund ohne Beleg sperrt nicht; er steht im Bericht unter „Unbelegt“, und der Grund des Urteils nennt ihn. Lies ihn, bevor du einspielst. Mit weniger als zwei abgegebenen Stimmen gibt es kein Urteil.

Ersatz. Gibt Codex keine gültige Stimme ab, springt Haiku ein — seit 2026-10-07 Haiku 5.5 mit dem high aus dem Frontmatter der Stimme; im Review-Prüfstand fand es am 2026-10-09 wie Sonnet 9 von 9 (AI/Regelwerk/haiku-5-5, A3). 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 mit Beleg 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 übergebenen Dokumentordner, 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:

• Absturz auf jeder Windows-Konsole, weil capsys die cp1252-Kodierung verdeckt.
• Ein Testdouble, das Anfragen nur zurückspiegelte, machte einen ganzen Pfad nur scheinbar grün.
• Der Probelauf schrieb auf die Produktivinstanz, weil ein Schalterpaar nie gemeinsam getestet wurde.

Wer Schritt 4 auf „Tests laufen lassen" verkürzt, findet nichts davon.

Rollen und Subagenten

Lagere Recherche, Erkundung und parallele Analysen an Subagenten aus — das hält den Koordinatorkontext frei, und das ist die knappe Ressource. Ein Ansatz pro Subagent, sonst vermischen sich die Befunde.

Wie ein Auftrag an einen Subagenten formuliert wird — Imperativ statt „kannst du vorschlagen", Grund zur Regel, Beispiele in Tags, Subagenten nicht für das, was ein grep erledigt — steht in AI/Regelwerk/prompting (Abschnitte 3 und 5). Was das jeweilige Zielmodell daraus macht: AI/Regelwerk/opus-5 für planer und pruefer (keine Selbstprüf-Anweisungen, keine Schwere-Schwelle im Prüfauftrag — Abschnitte 5 und 8), AI/Regelwerk/sonnet-5-5 für executer und Recherche (Auftragsvorlagen A2 und A3, Stoppsatz gegen ungefragte Zusätze), dazu AI/Regelwerk/sonnet-5 Abschnitt 5 (wörtliches Befolgen, Geltungsbereich je Task nennen). Verbindlich für Fable 5.1 als Auftraggeber; die Modelle selbst entscheiden.

Executer-Subagent (executer, Sonnet — bei reiner Abschrift Haiku, siehe Modellzuordnung unten) — definiert in .claude/agents/executer.md, eingesetzt in Schritt 3 der Standardschleife oben.

Der Executer setzt um, was bereits entschieden ist. Er plant nicht, er recherchiert nicht, er entscheidet nichts. Sein Auftrag enthält immer: Planpfad, exakte Zieldateipfade, ausdrückliche Verbote, Verifikationsbefehl. Er committet nicht und meldet am Ende Abweichungen und getroffene Annahmen — beides ist im Agent-Prompt als Pflichtfeld verankert.

Meldet er einen Widerspruch im Plan, ist das ein Treffer, kein Fehler: Plan korrigieren, ihn nachziehen lassen. Er darf Zweifelhaftes nie still zurechtbiegen.

Planer-Subagent (planer, Opus) — definiert in .claude/agents/planer.md. Liefert den Detailplan aus Schritt 2, wenn der Koordinator ihn nicht selbst schreibt: exakte Zieldateipfade, echter Test- und Implementierungscode, Verifikationsbefehle, keine Platzhalter. Er schreibt ausschließlich nach docs/plans/.

Prüfer-Subagent (pruefer, Opus) — definiert in .claude/agents/pruefer.md. Übernimmt Schritt 4 mit dem vollen Pflichtprogramm (Testlauf selbst wiederholen, Artefakte selbst lesen, eigener Lauf mit echten Daten und eigenem Prüfcode). Er ändert nichts und liefert eine Befundliste mit Schweregrad, Datei und Reproduktionsweg. Der Koordinator bleibt dabei in der Verantwortung: der Prüferbericht ist ein zweites Paar Augen, kein Ersatz für die eigene Gegenprüfung bei sicherheits- oder datenrelevanten Änderungen.

Quellenpflicht, Pflichtprogramm und Regressionsnachweis des Prüfers stehen maßgeblich in .claude/agents/pruefer.md. Das ist die Ausnahme aus dem Stamm: Der Subagent lädt das Regelwerk nicht, also steht die Regel dort, wo er sie liest, und wird hier nicht wiederholt. Ein Prüfauftrag nennt den tatsächlich eingesetzten Versionsstand, damit der Prüfer an der richtigen Quelle belegen kann.

Dieselbe Quellenpflicht gilt für dich als Koordinator. Was du nicht an einer Quelle belegt hast, wird nicht behauptet, sondern als offen geführt.

Modellzuordnung und Superpowers

Die Rollentabelle steht im Stamm (CLAUDE, Abschnitt „Agenten & Modelle"). Kurz: Denken und Prüfen auf Opus 5.5, Tippen und Suchen auf Sonnet 5.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.

Superpowers-Skills sprechen von „dispatch a general-purpose subagent". Diese Anweisung wird hier auf die eigenen Agenten abgebildet:

Superpowers-Skill / Rolle	Hier verwenden	Modell
brainstorming, writing-plans	planer	opus
subagent-driven-development → Implementer	executer	sonnet, bei reiner Abschrift haiku (siehe Schritt 3)
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)	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.

Beleg für die dritte Stufe, damit sie nicht als Sparmaßnahme missverstanden wird. Am 2026-08-27 lief Task 1 der Authentik-Werkzeugkette mit Haiku statt Sonnet, inklusive einer Korrekturrunde: null Abweichungen, null stille Zurechtbiegungen, korrekte Testreihenfolge auch bei der Nachbesserung. Die drei Befunde der Gegenprüfung waren Fehler im Plan, nicht in der Umsetzung. Haiku hat keine einzige zusätzliche Korrekturrunde verursacht. Diese Belege und die Tabelle darunter stammen von Haiku 4.5; für Haiku 5.5 steht die Messung in AI/Regelwerk/haiku-5-5, A3.

Zwei später gelaufene Tasks erlauben einen fast sauberen Vergleich, weil sie sich im Zuschnitt gleichen — je ein Modul mit Tests und Codedoku, je drei Dateien, je eine Korrekturrunde, beide mit aufgeteiltem Plan und frischem Subagenten für die Korrektur:

	Sonnet	Haiku
Umsetzung	40.962	31.854
Nachbesserung	51.072	36.413
Summe	92.034	68.267

26 Prozent weniger Tokens bei etwa einer Größenordnung geringerem Preis je Token — und ohne Qualitätsunterschied. Beide Modelle: null Abweichungen, null stille Zurechtbiegungen, erwartete Fehlschläge korrekt gemeldet. Haiku brauchte in der Korrektur vier Werkzeugaufrufe mehr.

Was das nicht belegt: Es sind zwei verschiedene Aufgaben, kein kontrollierter Versuch mit derselben. Die Aussage gilt für Tasks dieses Zuschnitts unter einem Plan, der dem Executer Ermessen bewusst wegnimmt — nicht für Executer-Arbeit allgemein. Wer die Stufe auf einen Task anwendet, in dem der Plan eine Lücke lässt, prüft etwas anderes als hier geprüft wurde.

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. Haiku 4.5 kennt keinen Effort; ein gesetzter Wert wird gar nicht gesendet. Haiku 5.5, auf das der Alias haiku laut Transkripten seit Claude Code 2.1.293 zeigt, kennt ihn und bekommt ihn nach derselben Rangfolge — ein Agent ohne agentType und ohne effort also den der Sitzung (AI/Regelwerk/haiku-5-5, A1).

Die Werte der ersten drei Zeilen stammen aus einer Messung vom 2026-09-23 an drei Prüfständen mit bekanntem Ergebnis, je Stufe zwei Läufe; die Sonnet-5.5-Zeile vom 2026-09-29, die Haiku-5.5-Zeile vom 2026-10-09:

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 $
executer (Sonnet 5.5, 2026-09-29)	medium	Derselbe Abschrift-Task plus ein Doku-Task (Anleitung und Hintergrund aus zehn Dossier-Aussagen, bewertet per Skript). Abschrift auf allen Stufen gleich, mit derselben Schreibschicht-Abweichung; Doku: Bewerter ohne Befund, strengere Probe mit Schwächen bei low und einmal medium. Einzelheiten in [[AI/Regelwerk/sonnet-5-5	sonnet-5-5.md]], A1.
executer (Haiku 5.5, 2026-10-09)	medium	Derselbe Abschrift-Task. Alle Stufen am Ende byte-gleich, „ “ erhalten, Widerspruch gemeldet; die Escape-Abweichung auf dem Write-Weg fanden die Läufe selbst. Sonnet 5.5 unter denselben Bedingungen ebenso. Einzelheiten in [[AI/Regelwerk/haiku-5-5	haiku-5-5.md]], A3.

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 auf Sonnet 5 entsprach medium laut Doku etwa Sonnet 4.6 bei high; für Sonnet 5.5 sagt die Doku nur, die Stufen seien neu geeicht. 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, 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.
• 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. Mit bis: "vergleich" endet er vor der Prüfung (Schritt 4).
• plankritik fährt ihre Linsen mit so vielen Plätzen, wie verbrauch erlaubt, die Widerlegung mit höchstens zwei. Die Aufträge verbieten Tests im echten Projektbaum; Mutanten entstehen in einer eigenen Kopie der Kopie.
• planung startet je Task einen planer, sobald die Planer seiner Voraussetzungen fertig sind, statt paarweise nach Wellen. Das spart Wartezeit ohne einen Opus-Agenten mehr: gerechnet 19 Minuten bei der Hub-Planung mit 38 Tasks. Außerdem liest jeder Planer die Taskdateien seiner Voraussetzungen, bevor er einen Namen daraus übernimmt. Gebremst oder abgebrochen kommen die offenen Tasks zurück; nachgeholt wird in einem neuen Lauf mit erledigt, nicht über Resume. Die Plankritik läuft danach als eigener Workflow.

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. Wie viele Opus-Agenten gleichzeitig laufen, regelt „Verbrauch und Opus-Plätze" unten. 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 4.5 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. Haiku 5.5 hat dasselbe Zeichenpaar und in einem zweiten Prüfstand alle elf Zeichen der Regel am 2026-10-09 in je 6 von 6 Läufen erhalten; am selben Tag hat Pascal die Ausnahme für Haiku 5.5 aufgehoben (Schritt 3).

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.

Verbrauch und Opus-Plätze

Wie viele Opus-Agenten gleichzeitig laufen, richtet sich nach dem Verbrauch, nicht nach einer festen Zahl (Pascals Freigabe vom 2026-09-24). Vor jeder Opus-Staffel liest der Workflow verbrauch über get_usage das 5-Stunden-Fenster und die Woche ab. Er senkt die gewünschten Plätze bei steigendem Verbrauch und gibt bei hohem keinen mehr frei; mehr als vier gibt es nie. Ohne Platz startet die Phase nicht, und der Workflow kommt mit status: gebremst zurück. Ein gebremster Lauf wird nach dem Zurücksetzen des Fensters neu gestartet, nicht über Resume, sonst käme die Ablesung aus dem Zwischenspeicher. Die Stufen stehen nur in .claude/workflows/verbrauch.js.

Warum keine feste Zwei mehr: Der Vorfall vom 2026-09-20 war die Wochengrenze aller Modelle (seven_day), und alle 18 Opus-Agenten dieser Nacht liefen mit effort max. Häufiger reißt das 5-Stunden-Fenster, 16 von 19 typisierten Abbrüchen seit dem 22.08. Eine feste Menge Agenten verbraucht parallel dieselben Tokens wie nacheinander, nur schneller. Die Zwei hat also nur die Rate gebremst, und sie galt je Workflow, nicht über zwei gleichzeitige Sitzungen hinweg. Die Ablesung ist kontoweit.

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.
• Ohne get_usage, also außerhalb der Desktop-App, gilt zwei.

Stufe 3 kommt erst nach der Eichung. Drei oder vier Opus-Plätze für Reviews und Erstplanungen (planung mit plaetze, Ad-hoc-Fan-outs mit höherem wunsch) gibt es erst, wenn die Stufen in verbrauch.js an der Messreihe nachgestellt sind; bis dahin laufen drei gleichzeitig nur in den Linsen der Plankritik. Die Stufen sind vorläufig und stehen nur in verbrauch.js. Ein erster Messpunkt vom 2026-09-24, Plan laut App „Pro": Ein Workflow mit 21 Opus-Agenten auf high hob zusammen mit dem übrigen Verbrauch der Sitzung das 5-Stunden-Fenster von 7 auf 43 % und die Woche von 2 auf 12 %. Das sind grob 1,5 bis 2 % des Fensters je Opus-Lauf. Nach etwa einer Woche wertet .vault-tools/workflow-pruefung/verbrauch_reihe.py die Ablesungen aus, danach werden die Stufen nachgestellt. Werkzeuge und Belege: .vault-tools/workflow-pruefung/LIESMICH.md. Ein neuer oder geänderter Workflow unter .claude/workflows/ wird dort mit faelle_workflows.mjs gegen die Attrappe gefahren, bevor er ins Verzeichnis kommt.

Bei parallelem Einsatz zusätzlich:

• Tests nur in der Kopie. Laufen mehrere Prüfer gleichzeitig, fährt keiner Tests im echten Projektbaum; Mutanten entstehen in einer eigenen Kopie der Kopie. Im echten Baum fährt die Suite immer nur einer.

• 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.

• Subagenten committen nicht. Mehrere gleichzeitige git commit im selben Repository kollidieren am Index-Lock. Der Koordinator committet nach dem Rücklauf, je Task einzeln.

• git status in der Taskdatei nennt die eigenen Zieldateien. „Genau diese Dateien im Baum und sonst nichts" scheitert in einer parallelen Welle an den Dateien der Nachbarn. In die Taskdatei gehört git status --porcelain -- <Zieldateien>; die Mengenprüfung über die ganze Welle macht der Koordinator nach dem Rücklauf.

• Ergebnisse unabhängig nachprüfen. Ein Agentenbericht ist eine Behauptung, kein Beleg. Testlauf selbst wiederholen, bei zentralen Zusicherungen eigenen Prüfcode schreiben statt den des Agenten zu übernehmen.

• Abweichungen abfragen. Jeder Subagent muss am Ende melden, was er anders gemacht hat als beauftragt und warum. Ohne diese Frage bleiben stille Abweichungen unentdeckt.

Aufgabenmanagement

• todo.md im Projektwurzelordner führt die Aufgaben als Checkboxen. Der Skill plane-abgleich setzt darauf auf — die Form ist also nicht kosmetisch.
• Punkte laufend abhaken, nicht gesammelt am Ende. Je Schritt eine Zusammenfassung in normaler Sprache: was sich geändert hat und warum.
• Zu Sitzungsbeginn tasks/lessons.md des Projekts lesen, bevor du planst.
• Nach jedem Durchlauf: Abschnitt „Review" in todo.md, jeder Befund aus Schritt 4 nach tasks/lessons.md — und zwar als Regel formuliert, die denselben Fehler das nächste Mal verhindert, nicht als Fallbeschreibung.

Was der Executer bei der Umsetzung einhält — kleinstmögliche Änderung, Ursachen statt Kaschieren, keine Scope-Erweiterung —, steht in .claude/agents/executer.md und wird hier bewusst nicht wiederholt.

Produktivdateien und Codedoku

Dateikopf, CHANGELOG statt Versionsnummern in der Datei, was aus dem Code verschwindet und was drinbleibt: AI/Regelwerk/codedoku.

Referenzen

• CLAUDE
• AI/Regelwerk/codedoku — Dateikopf und Codedoku
• AI/Regelwerk/pruefwerkzeuge — alles, was beurteilt statt tut
• AI/Regelwerk/wiederkehrende-jobs — Interviewform, „Fertig heißt“-Checks, Ablage
• AI/Regelwerk/fable-5-1 — nur für Fable 5.1: modellspezifische Verhaltensunterschiede
• AI/Regelwerk/prompting — Aufträge an Subagenten formulieren
• AI/Regelwerk/opus-5, AI/Regelwerk/sonnet-5-5, AI/Regelwerk/sonnet-5 — Verhalten der Zielmodelle von Planer/Prüfer bzw. Executer
• Code Projekte/_MOC-Code-Projekte