So bauen Sie ein agentisches Betriebssystem mit Fable 5 (Leitfaden für Entwickler)

Dies ist eine vollständige A–Z Aufschlüsselung von Claude Fable 5 – was es ist und wie man es wie ein 100x Engineer nutzt.

Das wird alles verändern, wie du mit Claude arbeitest.

Lesezeichen für diese 8 Builds, bevor du es vergisst

Einleitung

Du hast das leistungsfähigste Modell, das jemals allgemein verfügbar war, und du tippst immer noch einzelne Prompts ein. Dieser Leitfaden behebt das.

Hier ist die Situation, Stand Juli 2026. Fable 5 kann stundenlang unbeaufsichtigt laufen, eigene Sub-Agenten entsenden und eine Woche Arbeit in einer Nacht erledigen. Es wird auch abgerechnet ($10/M Input, $50/M Output über Nutzungsguthaben), es liefert übermäßig viel, wenn der Umfang nicht eingegrenzt ist, und es argumentiert überzeugender für seine Fehler, als die meisten Menschen für ihre richtigen Antworten argumentieren.

Bei beiläufiger Nutzung ist es eine teure Art, beeindruckende falsche Dinge zu generieren. Innerhalb eines Systems genutzt, ist es das, was einem Angestellten am nächsten kommt, den man für drei Dollar am Tag mieten kann.

Dieser Leitfaden baut dieses System. Keine Philosophie davon: die eigentlichen Dateien, in der richtigen Reihenfolge, mit einem Checkpoint nach jedem, damit du weißt, dass es funktioniert, bevor du das nächste Teil darauf aufsetzt.

Was du am Ende haben wirst:

• Eine CLAUDE.md, mit der das Modell nicht verhandeln kann (BUILD 1)
• Eine tägliche Schleife, in der Fable 5 jede Entscheidung trifft, aber fast keine Tokens schreibt, günstige Modelle die Arbeit erledigen, ein unabhängiger Prüfer es bewertet und ein Bash-Skript die endgültige Stimme hält (BUILDs 2-3)
• Ein Vertrauensregister, das Autonomie pro Fähigkeit automatisch gewährt und entzieht, basierend auf gemessenen Bestehensquoten (BUILD 4)
• Ein Zielverzeichnis, in dem alles, was du jemals fertigstellst, täglich für immer erneut verifiziert wird, damit nichts stillschweigend verrottet (BUILD 5)
• Ein Budget, das sich selbst durchsetzt, anstatt dich zu überraschen (BUILD 6)
• Vier optionale Schleifen (Quorum, Ratschen, Sparring, Kompost), jede mit der Bedingung, die dir sagt, wann du sie installieren sollst (BUILD 7)
• Ein Cron-Zeitplan, ein Runbook für jeden Alarm, den das System auslösen kann, und ein 30-Tage-Vertrauensplan, der es von beaufsichtigt zu selbsterweiternd führt.

Für wen das ist. Jeder mit einem Repo, einem Terminal und einem Claude Code Abonnement oder API-Schlüssel. Die Beispiele sind code-lastig, weil sich Schleifen um Codebasen herum entwickelt haben, aber das Zielsystem und die Hälfte der Schleifen funktionieren genauso gut mit Rechnungen, Berichten und Leselisten; die Prädikate sind nur Shell-Befehle.

Wie man es liest. Der Reihe nach, mit den Checks. BUILD 0 sind die offiziellen Anthropic-Einstellungen und die Prompt-Sprache; alles danach ist das darauf aufgebaute System. Jeder Build dauert 10 bis 20 Minuten. Die 30 Tage am Ende sind keine Lesezeit; sie sind der abgestufte Vertrauensplan, während dem das System sich das Recht verdient, ohne dich zu laufen. Gesamte praktische Zeit: etwa 2 Stunden.

Die drei Prinzipien, die allem zugrunde liegen, damit du jede Designentscheidung vorhersagen kannst, bevor du sie liest:

1. Gesetze, keine Tipps. Jede Regel hat eine Nummer, ein "Nie" oder einen Befehl, der sie überprüft. Alles Weichere wird wegoptimiert.
2. Nichts benotet seine eigenen Hausaufgaben. Der Planer, der Arbeiter, der Prüfer und das Tor sind vier verschiedene Parteien, und die letzte ist deterministisch.
3. Nichts, was einmal bestanden hat, bleibt unbeobachtet. Abgeschlossene Arbeit wird zu einer erneut verifizierten Invariante. Ein Ziel, das du nur einmal verifizierst, ist eine Annahme mit einem Zeitstempel.

Ab hier keine Aufsätze mehr. Acht Builds, jeder mit Dateien, Befehlen und einem Checkpoint.

Voraussetzungen

1claude CLI (Claude Code) mit Fable 5 Zugriff     # Nutzungsguthaben aktiviert, /usage-credits Limit gesetzt
2llm CLI + OpenRouter Schlüssel                    # llm install llm-openrouter
3jq, gh, git, make, cron
4ein Repo mit einem Testbefehl

Was du baust

1dein-repo/
2  CLAUDE.md                    # BUILD 1: die Verfassung
3  loop/
4    loop.sh                    # BUILD 3: der Herzschlag
5    conductor.md               # BUILD 3: Routing-Prompt
6    triage.md                  # BUILD 3: Günstiger-Leser-Prompt
7    contract.md                # BUILD 2: die drei Listen
8    workers/implement.md       # BUILD 3
9    workers/verify.md          # BUILD 3
10    guardrails/verify.sh       # BUILD 2: deterministisches Tor
11    scripts/trust-log.sh       # BUILD 4
12    scripts/log-cost.sh        # BUILD 6
13    scripts/cost-check.sh      # BUILD 6
14    quorum.sh                  # BUILD 7 (optional)
15    verify-goals.sh            # BUILD 5
16    goals/                     # BUILD 5: stehende Ziele
17    skills/                    # BUILD 4: eine Datei pro Fähigkeit
18    memory/
19      STATE.md  trust.tsv  goal-ledger.tsv  dispatch.tsv  usage.log
20  Makefile                     # BUILD 8: tick / queue / trust / audit / dream

BUILD 0: Konfiguriere die Engine (aus der offiziellen Fable 5 Dokumentation)

Alles in diesem Build stammt aus der offiziellen Anthropic-Dokumentation. Setze diese, bevor du eigene Dateien erstellst.

Das Datenblatt:

Einstellung

Wert

Quelle

Modell-String

claude-fable-5

Modellübersicht

Kontext / Ausgabe

1M Tokens / bis zu 128k Ausgabe pro Anfrage

Einführungsdokumente

Preis

$10/M Input, $50/M Output

Einführungsdokumente

Denken

adaptiv, immer an;

thinking: {type:"disabled"}

wird ABGELEHNT; Denkausgabe wird nur zusammengefasst

Einführungs- + Aufwandsdokumente

Aufwand

niedrig

mittel

hoch

xhoch

max

;

hoch

= Standard = Parameter weglassen

Aufwandsdokumente

API-Form

output_config: {"effort": "..."}

auf der Messages API

Aufwandsdokumente

Fünf offizielle Fakten, die deine Art zu bauen verändern:

1. max_tokens ist eine harte Obergrenze für Denk- PLUS Antworttext. Bei hoch und xhoch setze es groß (beginne mit 64k), sonst geht Fable mitten im Gedanken der Platz aus. Gilt für jeden claude -p Aufruf in diesem Leitfaden.
2. xhoch ist offiziell für "langlaufende agentische Aufgaben (über 30 Minuten) mit Token-Budgets in den Millionen." Das ist der Platz des Dirigenten und nichts anderes in diesem System. Die Dokumente sagen auch, dass niedrigerer Aufwand bei Fable 5 "oft die xhoch-Leistung früherer Modelle übertrifft", also widerstehe dem Upgrade von Arbeitern.
3. Ablehnungen sind HTTP 200. Fable 5 führt Sicherheitsklassifikatoren aus (offensive Cyber, Biologie/Lebenswissenschaften, Reasoning-Extraktion). Eine abgelehnte Anfrage gibt stop_reason: "refusal" als ERFOLGREICHE Antwort zurück. Deine Skripte müssen den Stop-Grund überprüfen, nicht den Exit-Code. Offizielle Abhilfe: Konfiguriere serverseitige Fallbacks oder SDK-Middleware, um zu Opus 4.8 umzuleiten.
4. Bitte Fable niemals, seine Gedankengänge zu wiederholen. Prompts oder Fähigkeiten, die "zeig deine Gedanken" oder "erkläre deine Argumentation in der Antwort" sagen, lösen die Kategorie reasoning_extraction refusal aus und erhöhen die Fallbacks. Überprüfe jede alte Fähigkeit bei der Migration darauf. Lies stattdessen die strukturierten Denkblöcke.
5. Züge sind von Natur aus lang. Schwierige Aufgaben laufen viele Minuten pro Anfrage bei höherem Aufwand; autonome Läufe erstrecken sich über Stunden. Passe die Client-Timeout-Werte an und überprüfe Läufe asynchron (geplante Jobs, keine blockierenden Wartezeiten). Deshalb ist der Herzschlag ein Cron-Job, keine blockierende Schleife.

Das offizielle Prompt-Paket. Anthropic liefert getestete Prompt-Sprache für Fable 5s bekanntes Verhalten. Diese kommen wortwörtlich in deine Prompts; paraphrasiere sie nicht dünner:

1. Anti-Überplanung (für den Dirigenten und jede interaktive Sitzung):

1Wenn du genug Informationen zum Handeln hast, handle. Leite keine bereits im
2Gespräch etablierten Fakten erneut ab, verhandle keine Entscheidung neu, die
3der Benutzer bereits getroffen hat, und beschreibe keine Optionen, die du
4nicht verfolgen wirst. Wenn du eine Wahl abwägst, gib eine Empfehlung, keine
5erschöpfende Übersicht.

1. Anti-Gold-Plating (für jeden Arbeiter-Prompt; dies ist der offizielle Rahmen gegen übermäßige Lieferung):

1Füge keine Funktionen hinzu, refaktoriere nicht und führe keine Abstraktionen
2ein, die über das hinausgehen, was die Aufgabe erfordert. Ein Bugfix braucht
3keine umgebende Bereinigung. Entwerfe nicht für hypothetische zukünftige
4Anforderungen: mach das Einfachste, das gut funktioniert. Füge keine
5Fehlerbehandlung oder Validierung für Szenarien hinzu, die nicht eintreten
6können. Validiere nur an Systemgrenzen.

1. Fundierte Fortschrittsbehauptungen (für jeden langen Lauf; in Anthropics Tests hat dies fabrizierte Statusberichte fast eliminiert):

1Überprüfe vor der Berichterstattung über Fortschritte jede Behauptung anhand
2eines Tool-Ergebnisses aus dieser Sitzung. Berichte nur über Arbeit, für die
3du Belege vorweisen kannst; wenn etwas noch nicht verifiziert ist, sag das
4ausdrücklich. Wenn Tests fehlschlagen, sag das mit der Ausgabe; wenn ein
5Schritt übersprungen wurde, sag das.

1. Autonome-Pipeline-Erinnerung (für jeden cron-gesteuerten Prompt; tötet den "Ich werde jetzt X ausführen" frühen Stopp):

1Du arbeitest autonom. Der Benutzer schaut nicht zu und kann keine Fragen
2mitten in der Aufgabe beantworten. Für reversible Aktionen, die aus der
3ursprünglichen Anfrage folgen, fahre fort, ohne zu fragen. Bevor du deinen
4Zug beendest, überprüfe deinen letzten Absatz: Wenn es ein Plan, eine Frage
5oder ein Versprechen über Arbeit ist, die du nicht erledigt hast, erledige
6diese Arbeit jetzt mit Tool-Aufrufen. Beende nur, wenn die Aufgabe
7abgeschlossen ist oder du durch Eingaben blockiert bist, die nur der Benutzer
8liefern kann.

1. Offizielles Speicherformat (für den Träumer und memory/learnings/):

1Speichere eine Lektion pro Datei mit einer einzeiligen Zusammenfassung oben.
2Halte Korrekturen und bestätigte Ansätze gleichermaßen fest, einschließlich
3warum sie wichtig waren. Speichere nicht, was das Repo bereits aufzeichnet;
4aktualisiere vorhandene Notizen, anstatt zu duplizieren; lösche Notizen, die
5sich als falsch herausstellen.

1. Offizielle Prüferanweisung (die Dokumente sagen es direkt: "separate Prüfer-Subagenten mit frischem Kontext übertreffen tendenziell die Selbstkritik"):

1Etabliere eine Methode zur Überprüfung deiner eigenen Arbeit in einem
2Intervall von [X] während des Bauens. Führe dies alle [X Intervall] aus und
3überprüfe deine Arbeit mit Subagenten gegen die Spezifikation.

Zwei Gerüstbau-Anordnungen aus den Docs, die es wert sind, befolgt zu werden: Beginne an der Spitze deines Schwierigkeitsbereichs (Fable nur mit einfachen Arbeitslasten zu testen, verkauft es unter Wert; gib ihm das schwierigste ungelöste Problem und lass es den Umfang bestimmen) und refaktoriere alte Fähigkeiten (Anweisungen, die für frühere Modelle geschrieben wurden, sind für Fable 5 oft zu vorschreibend und VERSCHLECHTERN die Ausgabe; wenn die Standardleistung ohne eine Anweisung besser ist, lösche die Anweisung).

CHECK 0: Jeder claude -p Aufruf in deinen Skripten hat ein explizites großes max_tokens, wo unterstützt; deine Skripte prüfen auf stop_reason: "refusal"; kein Prompt oder keine Fähigkeit sagt irgendwo "zeig deine Gedanken."

BUILD 1: Die Verfassung (CLAUDE.md)

Warum, in einem Satz: Fable befolgt Gesetze und optimiert um Tipps herum, also braucht jede Zeile eine Nummer, ein "Nie" oder einen Befehl, der sie überprüft.

Regeln für die Datei: vier Blöcke, unter 150 Zeilen, kein "denke Schritt für Schritt" (Denken ist immer an; das sind bezahlte Tokens), keine vordefinierten Agenten-Personas (Fable entwirft bessere Teams, als du vordefinieren kannst), hauptsächlich Stoppschilder.

Erstelle CLAUDE.md:

1# CLAUDE.md
2
3## NIE (Gesetze; Ausnahmen erfordern vorheriges Fragen)
4- Nie mehr als 200 geänderte Zeilen in einem Commit ohne zu fragen überschreiten.
5- Nie src/auth/, src/billing/, migrations/ oder prod-Konfiguration unbeaufsichtigt anfassen.
6- Nie Arbeit als erledigt von der eigenen Einschätzung melden. Erledigt = der Check wurde bestanden.
7- Nie ein Geheimnis, einen Endpunkt oder eine Konvention erfinden. Anhalten und fragen.
8- Nie eine Abhängigkeit hinzufügen. In STATE.md vorschlagen und anhalten.
9- Nie den Aufwand hoch innerhalb einer Schleife überschreiten. xhoch ist nur für einmalige Überprüfungen.
10- Nie einen Test bearbeiten oder löschen, um ihn bestehen zu lassen. Das ist ein Fehlschlag, immer.
11- Nie die eigene interne Argumentation im Antworttext wiedergeben, transkribieren oder erklären.
12  (Offiziell: löst reasoning_extraction refusals bei Fable 5 aus.)
13- Wenn eine /goal-Bedingung erfüllt ist, schreibe goals/<name>.md mit der Bedingung als
14  Prädikat, bevor du Erfolg meldest.
15
16## DISPATCH (leite jede Aufgabe weiter; erster Treffer gewinnt; protokolliere in memory/dispatch.tsv)
17| model           | marginal | appetite | intelligence | taste |
18|-----------------|----------|----------|--------------|-------|
19| claude-fable-5  | 2 (credits) | 3     | 10           | 10    |
20| claude-opus-4-8 | 7 (sub)  | 6        | 8            | 9     |
21| claude-sonnet-5 | 9 (sub)  | 8        | 7            | 7     |
22| codex (2nd sub) | 9        | 10       | 9            | 5     |
231. Entscheidung (planen/prüfen/routen/pattsituation) -> fable-5, Aufwand hoch, schreibgeschützt.
242. Liest >50k Tokens (Logs/PDFs/Screenshots) -> codex. Niemals fable.
253. Liefert an Benutzer aus (UI/API/Kopie) -> geschmack >= 8 bekommt letzten Durchgang.
264. Spezifikation vollständig -> sonnet-5, Aufwand mittel.
275. Sonst sonnet-5; eine Stufe höher eskalieren bei einem Fehlschlag ohne zu fragen.
28
29## WÖRTER
30- "intelligenz" = schwierigstes Problem unbeaufsichtigt gelöst
31- "geschmack" = UI/UX, Codequalität, API-Design, Kopie
32- "erledigt" = das Prädikat besteht; nichts anderes
33- "klein" = unter 50 geänderten Zeilen; "schnell" = unter 10 Minuten deiner Zeit
34- "bereinigung" = Verhalten identisch, verify.sh grün vorher und nachher
35
36## ERLEDIGT
37- Jede Aufgabe hat ein maschinenprüfbares done_when, bevor die Arbeit beginnt.
38- Ein Agent mit frischem Kontext, der weder Plan noch Entwurf gesehen hat, prüft dagegen.
39- guardrails/verify.sh hat die endgültige Stimme.
40- Abweichungen: konservative Option, protokollieren in IMPLEMENTATION.md, fortfahren.
41- Macher und Prüfer sind sich zweimal uneinig -> anhalten, für einen Menschen in die Warteschlange stellen.

Passe die Zahlen und Pfade an deine an. Arbeitsablaufspezifisches Material (PR-Verfahren, Release-Checkliste) kommt in skills/, nicht hierher.

CHECK 1: Frage für jede Zeile: Könnte das Modell zu 80% konform sein und Erfolg melden? Wenn ja, schreibe sie mit einer Nummer oder einem "Nie" um. wc -l CLAUDE.md unter 15

BUILD 2: Mauern und Tor

Warum: Der Schadensradius muss vor dem ersten Tick deklariert werden, und ein Bash-Skript muss die endgültige Stimme halten.

Erstelle loop/contract.md:

1## handelt allein
2Entwurfs-PRs auf Branches; behebe Lint/Test-Schulden; aktualisiere STATE.md; label Issues
3
4## stellt für mich in die Warteschlange
5Auth, Zahlungen, Migrationen; jede Fähigkeit unterhalb der "auto"-Stufe; jeder Diff > 400 Zeilen
6
7## weckt mich auf
8Verify schlägt zweimal beim selben Element fehl
9Safeguard Router hat Modelle während des Laufs getauscht
10Tagesbudget überschritten
11irgendetwas fordert ein Geheimnis an
12ein stehendes Ziel ist VERLETZT

Erstelle loop/guardrails/verify.sh (passe für deinen Stack an):

1#!/usr/bin/env bash
2set -e
3npm run typecheck --if-present
4npm test --if-present
5npm run lint --if-present

CHECK 2: ./loop/guardrails/verify.sh läuft und beendet sich mit 0 in deinem aktuellen Repo. Wenn es jetzt fehlschlägt, behebe das zuerst; das gesamte System steht auf diesem Skript.

BUILD 3: Der Herzschlag

Warum, in drei Sätzen: Fable als Arbeiter ist eine vierstellige Rechnung (500k-1M Token-Sitzungen bei $50/M Output); Fable als Dirigent emittiert 10-20% der Tokens, während es 100% der Entscheidungen trifft. Ein $0.01 Modell liest die leisen Ticks. Agenten übergeben sich über ein JSON-Schema, damit jedes Modell in jeden Sitz passt.

Erstelle loop/triage.md:

1Du erhältst aktuelle Commits, offene Issues und CI-Läufe. Gib NUR Ergebnisse aus:
2- finding: <eine Zeile>
3  evidence: <Commit/Issue/Run-ID>
4  status: actionable | informational
5Keine Korrekturen, keine Meinungen. Nichts zu melden = gib genau "status: quiet" aus.
6Alles, was Auth, Zahlungen, Migrationen, Geheimnisse betrifft = immer actionable,
7notiert "contract-sensitive".

Erstelle loop/conductor.md:

1Du bist der Dirigent. Du schreibst keinen Code. Du bearbeitest keine Dateien.
21. Lies STATE, TRUST LEDGER, CONTRACT unten. Verlasse dich nicht auf dein Gedächtnis davon.
32. Wähle das EINE wertvollste actionable Element.
4   contract-sensitive, mehrdeutig oder wahrscheinlich >400-Zeilen-Diff -> action: queue
5   nichts, was es wert ist, getan zu werden -> action: stop
63. Sonst action: execute, mit einer Spezifikation, der ein mittelmäßiges Modell folgen kann.
7Gib NUR dieses JSON aus:
8{ "action": "execute|queue|stop", "item": "...", "skill": "<kebab-case,
9stabil über Läufe hinweg>", "spec": "...", "done_when": ["<überprüfbar>", ...] }
10Du bist teuer. Sei kurz. Deine Ausgabe ist eine Entscheidung, kein Aufsatz.

Erstelle loop/workers/implement.md:

1Du erhältst einen Arbeitsauftrag (JSON). Führe die Spezifikation genau aus.
2Mach den EINEN nächsten Schritt in Richtung done_when. Kleine Diffs gewinnen.
3Fehlende Anmeldeinformation oder undokumentierte Entscheidung -> STOPP, schreibe die Frage in
4IMPLEMENTATION.md. Erfinde niemals Geheimnisse oder Konventionen.
5Halte fest, was du getan hast und warum in IMPLEMENTATION.md (max. 3 Zeilen).

Erstelle loop/workers/verify.md:

1Du erhältst eine SPEZIFIKATION und einen DIFF, sonst nichts. Beurteile nur, was vor dir liegt.
21. Erfüllt der Diff jedes done_when? Zitiere Zeilen.
32. Irgendetwas außerhalb des Umfangs der Spezifikation? Sofortiger Fehlschlag. Gelöschte/übersprungene Tests? Sofortiger Fehlschlag.
4Gib genau eine Zeile aus: "PASS: <Grund>" oder "FAIL: <Grund>".
5Der Macher war zuversichtlich. Das ist kein Beweis.

Erstelle loop/loop.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3cd "$(dirname "$0")"
4MAX_ITERS="${MAX_ITERS:-10}"
5DAILY_BUDGET_USD="${DAILY_BUDGET_USD:-5}"
6CHEAP="${CHEAP:-openrouter/deepseek/deepseek-v4-flash}"
7WORKER="${WORKER:-openrouter/moonshotai/kimi-k2.6}"
8
9./scripts/cost-check.sh --budget "$DAILY_BUDGET_USD" || exit 3
10
11for ((i=1; i<=MAX_ITERS; i++)); do
12  # 1 TRIAGE: Leise-Tick-Tor, ~$0.01
13  { git log --oneline -20; gh issue list --limit 20 2>/dev/null || true; \
14    gh run list --limit 10 2>/dev/null || true; } \
15    | llm -m "$CHEAP" -s "$(cat triage.md)" >> memory/STATE.md
16  ./scripts/log-cost.sh triage 0.01
17  grep -q "status: actionable" memory/STATE.md || { echo quiet; exit 0; }
18
19  # 2 CONDUCT: Fable, xhoch, frischer Kontext, schreibgeschützt, JSON-Ausgabe
20  claude -p "$(cat conductor.md)
21STATE: $(cat memory/STATE.md)
22TRUST: $(./scripts/trust-log.sh --render)
23CONTRACT: $(cat contract.md)" \
24    --model claude-fable-5 --effort xhoch --allowedTools "Read" \
25    --output-format json > /tmp/c.json
26  ./scripts/log-cost.sh conductor 0.35
27
28  # 2a ROUTEN-TOLERANZ: niemals auf einem Modell iterieren, das du nicht gewählt hast
29  SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/c.json)
30  [[ "$SERVED" != *fable* ]] && { echo "rerouted" >> memory/STATE.md; exit 2; }
31
32  jq -r '.result' /tmp/c.json > work-order.json
33  SKILL=$(jq -r .skill work-order.json); ACTION=$(jq -r .action work-order.json)
34  [[ "$ACTION" == stop  ]] && exit 0
35  [[ "$ACTION" == queue ]] && { echo "queued: $SKILL" >> memory/STATE.md; continue; }
36
37  # 3 EXECUTE: günstiger Arbeiter, isolierter Arbeitsbaum
38  WT="../wt-$i"; git worktree add "$WT" -b "loop/$SKILL-$i" >/dev/null
39  ( cd "$WT" && llm -m "$WORKER" -s "$(cat "$OLDPWD/workers/implement.md")" \
40      "$(cat "$OLDPWD/work-order.json")" > IMPLEMENTATION.md )
41  ./scripts/log-cost.sh worker 0.10
42
43  # 4 VERIFY: frischer Fable, keine Tools, sieht nur Spezifikation + Diff
44  V=$(claude -p "$(cat workers/verify.md)
45SPEC: $(jq -r .spec work-order.json)
46DIFF: $(cd "$WT" && git diff)" \
47    --model claude-fable-5 --effort hoch --allowedTools "" \
48    --output-format json | jq -r .result)
49  ./scripts/log-cost.sh verifier 0.40
50
51  # 5 GATE: deterministisch; dann Register; versenden nur auf auto-Stufe
52  if [[ "$V" == PASS* ]] && ( cd "$WT" && "$OLDPWD/guardrails/verify.sh" ); then
53    ./scripts/trust-log.sh "$SKILL" pass
54    if [[ "$(./scripts/trust-log.sh --tier "$SKILL")" == auto ]]; then
55      ( cd "$WT" && git add -A && git commit -qm "loop: $SKILL" && gh pr create --fill || true )
56      echo "- shipped: $SKILL" >> memory/STATE.md
57    else
58      echo "- review: $SKILL in $WT" >> memory/STATE.md
59    fi
60  else
61    ./scripts/trust-log.sh "$SKILL" fail
62    echo "- FAILED: $SKILL in $WT" >> memory/STATE.md
63  fi
64  ./scripts/cost-check.sh --budget "$DAILY_BUDGET_USD" || exit 3
65done
66exit 1   # Iterationsgrenze ohne Stopp: überprüfe STATE.md

Exit-Map: 0 leise/erledigt, 1 Grenze, 2 umgeleitet, 3 Budget. Alle gekennzeichnet, absichtlich.

CHECK 3: chmod +x loop.sh guardrails/verify.sh dann führe ./loop.sh einmal von Hand aus. Bestätige: Ein ruhiges Repo beendet sich mit 0 für etwa einen Cent; ein repo mit handlungsbedarf erzeugt work-order.json mit allen fünf Feldern und einer Urteilszeile in STATE.md.

BUILD 4: Das Vertrauensregister

Warum: "Autonomie erhöhen, wenn Vertrauen wächst" ist kein Mechanismus; eine TSV mit Stufenregeln ist es. Autonomie ist pro Fähigkeit, nicht pro Schleife.

Erstelle loop/scripts/trust-log.sh:

1#!/usr/bin/env bash
2# Verwendung: trust-log.sh <skill> <pass|fail> | --render | --tier <skill>
3set -euo pipefail
4F="$(dirname "$0")/../memory/trust.tsv"; touch "$F"
5tier_of() { awk -v r="$1" -v p="$2" 'BEGIN{
6  rate=(r>0)?p/r:0
7  if (r>=20 && rate>=0.95) print "auto"
8  else if (r<10 || rate<0.90) print "watch"
9  else print "queue"}'; }
10case "${1:-}" in
11  --render)
12    printf "%-20s %5s %5s %6s %s\n" skill runs pass rate tier
13    while IFS=$'\t' read -r s r p; do [ -z "$s" ] && continue
14      printf "%-20s %5s %5s %5s%% %s\n" "$s" "$r" "$p" \
15        "$(awk -v r="$r" -v p="$p" 'BEGIN{printf "%.0f",(r>0)?p/r*100:0}')" \
16        "$(tier_of "$r" "$p")"; done < "$F";;
17  --tier)
18    line=$(grep -P "^${2}\t" "$F" || echo -e "${2}\t0\t0")
19    tier_of "$(cut -f2 <<<"$line")" "$(cut -f3 <<<"$line")";;
20  *)
21    awk -v s="$1" -v r="$2" -F'\t' 'BEGIN{OFS="\t"; f=0}
22      $1==s {f=1; print s,$2+1,$3+(r=="pass"); next} {print}
23      END{if(!f) print s,1,(r=="pass")?1:0}' "$F" > "$F.t" && mv "$F.t" "$F"
24    if [ "$2" = fail ]; then
25      runs=$(grep -P "^${1}\t" "$F" | cut -f2)
26      [ "$("$0" --tier "$1")" = watch ] && [ "$runs" -ge 10 ] \
27        && echo "ALARM: $1 nach $runs Läufen auf watch herabgestuft" >&2 || true
28    fi;;
29esac

• Stufenregeln: auto = 20+ Läufe UND 95%+ Bestehensquote, versendet unbeaufsichtigt. queue = verifizierte Entwürfe warten auf dich. watch = unter 10 Läufen oder unter 90%, nur Entwurf. Herabstufung ist automatisch und gibt eine Meldung auf stderr aus, die cron dir mailt.
• Befülle den Kader: Erstelle loop/skills/<name>/SKILL.md für jede wiederkehrende Aufgabe (fix-lint-debt, fix-flaky-test, bump-deps, triage-issues sind die Standard-Vier). Jede Datei: Frontmatter (Name, Beschreibung, wann), Schritte, eine "Nie"-Liste, ein überprüfbares done-when. Jede Fähigkeit beginnt auf watch.

CHECK 4: Führe ./scripts/trust-log.sh demo pass 21 Mal aus, dann gibt --tier demo auto aus. Protokolliere einen Fehlschlag für eine Fähigkeit mit 10+ Läufen und sieh den ALARM auf stderr. Zurücksetzen: > memory/trust.tsv.

BUILD 5: Stehende Ziele + das Zielregister

Warum, in einem Satz: Ein Ziel, das du nur einmal verifizierst, ist eine Annahme mit einem Zeitstempel, also graduieren abgeschlossene Ziele zu Invarianten, die täglich erneut verifiziert und protokolliert werden.

Erstelle eine Datei pro abgeschlossener Sache, goals/<name>.md:

1predicate: cd $REPO && npm test -- tests/auth 2>&1 | tail -1 | grep -q passing
2born: 2026-07-06
3source: /goal session 2026-07-06 (fix auth flake)
4status: satisfied
5last-pass: 2026-07-06
6on-violation: wake me. Do not auto-fix.
7retire-when: auth module deleted. Retirement is a human decision, logged.

Erstelle loop/verify-goals.sh:

1#!/usr/bin/env bash
2set -uo pipefail
3LEDGER="memory/goal-ledger.tsv"; VIOLATIONS=0
4for g in goals/*.md; do
5  [ -e "$g" ] || continue
6  grep -q '^status: retired' "$g" && continue
7  pred=$(grep '^predicate:' "$g" | cut -d' ' -f2-); name=$(basename "$g" .md)
8  start=$(date +%s%3N)
9  if timeout 60 bash -c "$pred" >/dev/null 2>&1; then r=pass
10    sed -i "s/^status:.*/status: satisfied/; s/^last-pass:.*/last-pass: $(date +%F)/" "$g"
11  else r=FAIL; VIOLATIONS=$((VIOLATIONS+1)); sed -i "s/^status:.*/status: VIOLATED/" "$g"; fi
12  echo -e "$(date -Is)\t$name\t$r\t$(( $(date +%s%3N) - start ))" >> "$LEDGER"
13done
14[ "$VIOLATIONS" -gt 0 ] && { grep -l '^status: VIOLATED' goals/*.md; exit 1; }
15echo "alle stehenden Ziele gelten"

Starte den Wachposten (nur Erkennung; Korrekturen gehen durch die normale Pipeline):

1/loop 1d Führe ./verify-goals.sh aus. Wenn ungleich Null: Lies für jedes verletzte Ziel
2sein last-pass-Datum und liste auf, was seitdem gemergt wurde (git log --oneline --since=<date>).
3Melde Ziel, Verdächtige, on-violation-Richtlinie. Korrigiere nichts.

Das Abschlussgesetz steht bereits in CLAUDE.md (BUILD 1): Jedes bestandene /goal schreibt sein eigenes stehendes Ziel. Fertigstellen IST die Einschreibung.

Registerabfragen, die du tatsächlich verwenden wirst:

1awk -F'\t' '$3=="FAIL"{n[$2]++} END{for(g in n) print n[g],g}' memory/goal-ledger.tsv | sort -rn | head -5   # flakiest
2grep <goal> memory/goal-ledger.tsv | awk -F'\t' '$3=="FAIL"' | head -1                                      # when it broke

Flaky-Prädikat: quarantine (Status: retired, Hinweis "braucht ein besseres Prädikat"), niemals löschen.

CHECK 5: Füge ein Ziel mit predicate: true und eines mit predicate: false hinzu. ./verify-goals.sh beendet sich mit Exit-Code 1, setzt das zweite auf VIOLATED, und beide erscheinen im Ledger. Lösche die Dummies.

BUILD 6: Das Budget

Warum: Tägliche Kosten = Ticks × Triage + Hits × (Conductor + Worker + Verifier). Bei echten Preisen (Triage $0,01, Conductor $0,35, Worker $0,10, Verifier $0,40): Ein täglicher Hausmeister kostet ~$2,56/Tag; ein 15-minütiger Babysitter mit Fable auf dem Triage-Sitz kostet $34/Tag für das identische Ergebnis. Das Modell, das die ruhigen Ticks liest, entscheidet über die Rechnung.

Erstelle loop/scripts/log-cost.sh:

1#!/usr/bin/env bash
2echo -e "$(date -Is)\t$1\t$2" >> "$(dirname "$0")/../memory/usage.log"

Erstelle loop/scripts/cost-check.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3F="$(dirname "$0")/../memory/usage.log"; touch "$F"; TODAY=$(date +%F)
4case "${1:-}" in
5  --budget)
6    spent=$(awk -F'\t' -v d="$TODAY" '$1 ~ d {s+=$3} END{printf "%.2f",s}' "$F")
7    awk -v s="$spent" -v b="$2" 'BEGIN{exit (s>=b)?1:0}' \
8      || { echo "spent \$$spent of \$$2" >&2; exit 1;};;
9  --report)
10    awk -F'\t' -v since="$(date -d '7 days ago' +%F)" \
11      '$1>=since{s[$2]+=$3;t+=$3} END{for(k in s) printf "  %-10s $%.2f\n",k,s[k]; printf "  TOTAL      $%.2f\n",t}' "$F";;
12esac

Regeln, die es flach halten: Kadenz ist eine Kostenentscheidung (Halbierung des Intervalls verdoppelt die Untergrenze); der ruhige Tick muss Cent kosten; Aufwand in Loops niemals über high (xhigh ist für einmalige Reviews; Aufwand ist pro Schritt, nicht pro Durchlauf).

CHECK 6: Nach einer Woche Ticks stimmt ./scripts/cost-check.sh --report mit der Formel innerhalb der Toleranz überein. Setze DAILY_BUDGET_USD auf einen Betrag, den du nicht verschwenden würdest.

BUILD 7: Die optionalen Loops (installieren, wenn ihre Bedingung eintritt)

• Quorum (installieren, wenn Dispatch Fable-Aufwachvorgänge zeigt, die action: stop produziert haben). Drei günstige Modelle stimmen ab; Fable wacht bei 2 von 3 auf. Wähler sehen niemals die Antworten der anderen.

1V=0
2for m in deepseek/deepseek-v4-flash qwen/qwen-3.6 moonshotai/kimi-k2.6; do
3  llm -m "openrouter/$m" -s "$(cat triage.md)" < /tmp/signals.txt \
4    | grep -q "status: actionable" && V=$((V+1))
5done
6[ "$V" -ge 2 ] && exec ./conduct.sh || echo "quorum: quiet ($V/3)"

• Ratchet (installieren, wenn eine einzelne Zahl zählt). Monotone Verbesserung oder Selbst-Rückgängigmachung; die Metrik darf nicht manipuliert werden; der fertige Boden wird zu einem dauerhaften Ziel.

1/goal Reduziere `npm run lint 2>&1 | grep -c warning` auf 0.
2Berechtigungen: Bearbeite src/; committe pro Fix; messe nach jeder Änderung neu.
3Wände: Die Zahl steigt NIEMALS; mache jede Änderung rückgängig, die sie erhöht oder einen
4Test bricht; bearbeite niemals die Lint-Konfiguration, um sie zu senken.
5Zeitbox: Stoppe nach 3 Versuchen ohne Bewegung; melde Überlebende.

• Sparring (installieren, wenn du täglich Code auslieferst). Builder und Breaker, gegensätzlich; keiner berührt die Ausgabe des anderen; Streitigkeiten gehen an dich.

1/loop 1d [breaker] Lese die gemergten Diffs von gestern. Schreibe EINEN fehlschlagenden Test,
2der eine echte Schwachstelle aufdeckt. Committe unter tests/sparring/ getaggt mit @sparring.
3Repariere nichts. Solider Code = sag es, schreibe nichts.
4/loop 1d [builder] Wenn ein @sparring-Test fehlschlägt, repariere den CODE, bis er besteht.
5Bearbeite, schwäche oder lösche niemals einen Sparring-Test; Streitigkeiten stellen sich für mich in die Warteschlange.

• Compost (immer installieren, wöchentlich). Fehler werden zu Gesetzen; maximal drei Vorschläge; menschliche Unterschrift erforderlich.

1/loop 7d Lese diese Woche Ausfälle: FAILED in STATE.md, Fehler in trust.tsv,
2FAILs in goal-ledger.tsv, ungemergt geschlossene PRs. Extrahiere MAXIMAL 3 Vorschläge:
3ein neues CLAUDE.md-Gesetz (Vorfälle zitieren), eine Skill-Korrektur (gleicher Fehler wiederholt sich),
4oder ein fehlendes dauerhaftes Ziel. Nur vorschlagen. Saubere Woche = sag es.

CHECK 7: Jeder optionale Loop hat seine Installationsbedingung in deinen Notizen daneben stehen. Sie spekulativ zu installieren, ist, wie Systeme aufblähen.

BUILD 8: Betrieb

Erstelle Makefile:

1tick:            ; ./loop/loop.sh
2queue:           ; @grep -E "review:|queued:|FAILED:|rerouted" loop/memory/STATE.md || echo empty
3trust:           ; @./loop/scripts/trust-log.sh --render
4audit:           ; @./loop/scripts/cost-check.sh --report
5goals:           ; @./loop/verify-goals.sh
6clean-worktrees: ; @git worktree list | awk '/wt-/{print $$1}' | xargs -rn1 git worktree remove --force

Cron, wenn Woche 2 beginnt:

10 7 * * 1-5  cd /path/to/repo/loop && ./loop.sh >> memory/cron.log 2>&1
230 7 * * *   cd /path/to/repo/loop && ./verify-goals.sh >> memory/cron.log 2>&1

Der 30-Tage-Vertrauensplan

Überspringe keine Abschlüsse; jeder schaltet den nächsten frei.

Woche

Level

Du tust

Abschluss, wenn

1

L1 Bericht

Builds 1-6;

make tick

täglich von Hand; alles lesen

3 aufeinanderfolgende Läufe genau so routen, wie du es getan hättest

2

L2 Entwurf

cron an;

make queue

mit Kaffee; Reviews füttern das Ledger

2 Skills überschreiten 20 protokollierte Läufe

3

L3 Ausliefern

make audit

gegen die Formel; bester Skill läuft unbeaufsichtigt

1 Woche, null Eingriffe

4

L4 Wachsen

Compost-Abnahmen; 1 vorgeschlagenen Skill genehmigen; den Löschdurchlauf ausführen

du hast etwas entfernt und nichts ist kaputtgegangen

Das Runbook. Was jedes Signal bedeutet und was zu tun ist:

Signal

Bedeutung

Aktion

exit 2 (reroute)

Safeguard-Router hat Modelle während des Laufs getauscht

Lese den Checkpoint; führe das Element morgen erneut aus; iteriere niemals auf der getauschten Ausgabe

stop_reason: refusal

Sicherheitsklassifizierer abgelehnt (HTTP 200, kein Fehler)

Offizieller Pfad: Fallback auf Opus 4.8 über

fallbacks

oder Middleware; wenn es bei einem Skill wiederholt auftritt, überprüfe diesen Skill auf Reasoning-Echo oder Cyber/Bio-ähnliche Formulierungen

exit 3 (budget)

Tägliche Ausgaben haben die Grenze erreicht

make audit

; finde heraus, welche Stufe gewachsen ist; repariere die Aufwandskarte, nicht das Budget

ALERT demoted

Ein etablierter Skill fiel unter 90%

Lese seine letzten 3 Fehler; normalerweise das Spezifikationsmuster, nicht der Worker

goal VIOLATED

Etwas Abgeschlossenes ist nicht mehr wahr

Sentinel gibt Verdächtige; der Fix durchläuft die normale Pipeline

maker/checker standoff x2

Keiner wird als richtig angenommen

Du entscheidest, oder führe den Standoff-Breaker aus (dritter frischer Reviewer, bewertet Beweise, darf den Unterschied nicht teilen)

verify-goals timeout

Prädikat zu teuer

Das ist eine Verletzung; verbillige das Prädikat

Die Regeln (drucke dies)

1. Gesetze, keine Tipps: eine Zahl, ein Niemals oder ein Befehl, der es prüft.
2. Der Conductor plant, Worker führen aus, keiner verifiziert. --allowedTools setzt es durch.
3. Agenten sprechen in Arbeitsaufträgen. done_when = Spezifikation + Stoppbedingung + zukünftige Invariante.
4. Gib Aufwand dort aus, wo der Loop verzweigt. Niemals über high in einem Loop.
5. Der ruhige Tick kostet einen Cent oder der Loop kostet einen Tausender.
6. Wenn ein Shell-Skript es nicht prüfen könnte, schreibe es nicht als Ziel.
7. Ziele schließen ab; sie werden nicht geschlossen. verify-goals.sh läuft täglich, für immer.
8. Autonomie pro Skill: 20 Läufe, 95%, automatisch. Herabstufung automatisch und laut.
9. Zwei Ledger: trust (Worker) und goals (Arbeit). Beide mit Kaffee lesen.
10. Berechne den Stoffwechsel, bevor du cron aktivierst.
11. Vertrag im Repo: acts-alone / queues / wakes-me.
12. Iteriere niemals auf der Ausgabe eines Modells, das du nicht ausgewählt hast.
13. Der Sentinel erkennt; die Pipeline repariert.
14. Quorum vor dem Aufwecken von Fable. Ratchet dann schweißen. Täglich sparren. Wöchentlich kompostieren.
15. Ein Abschlusskriterium nach dem anderen. Jeden Monat etwas löschen.
16. Aus der offiziellen Dokumentation: max_tokens begrenzt Denken plus Text, Ablehnungen sind HTTP 200, bitte niemals um wiederholtes Reasoning, alte Skills verschlechtern Fable, und Verifier mit frischem Kontext schlagen Selbstkritik. Anthropic sagt es; das System setzt es durch.

Abschluss

In dreißig Tagen, wenn du die Checks gemacht hast: Ein Loop liefert langweilige Arbeit unbeaufsichtigt aus, ein Ziele-Verzeichnis überprüft alles, was du jemals abgeschlossen hast, zwei Ledger sagen dir die Wahrheit über deine Worker und deine Arbeit, und ein wöchentlicher Compost-Lauf schlägt die nächste Verbesserung des Systems selbst zur Unterschrift vor.

• Das Modell war nie der schwierige Teil. Der schwierige Teil war, etwas darum herum zu bauen, das ehrlich bleibt, wenn du nicht hinschaust. Das ist es, was du gerade gebaut hast.
• Beginne heute Abend mit den zwanzig Minuten, die es beweisen: BUILD 2s verify.sh, BUILD 3s erster Tick von Hand und ein dauerhaftes Ziel für das Letzte, das du abgeschlossen hast.
• Wenn verify-goals.sh zum ersten Mal eine stille Regression bei etwas erwischt, von dem du sicher warst, dass es erledigt ist, wirst du keine Überzeugungsarbeit mehr für den Rest brauchen.

Haftungsausschluss

Dieser Artikel wurde unter Verwendung der Notizen des Benutzers verfasst und von Claude Opus 4.8 max bearbeitet.