Kernkonzepte¶

flower bringt eine eigene Begriffsmenge mit: Run, Schritt, Session, Koordinator, Worker, Clarify, Goal Guard, Continuity, Handoff. Diese Seite erklärt sie alle auf einmal, damit man auf den anderen Seiten nicht beim Lesen raten muss. In fünf Minuten durch.

Hier stehen nur die Konzepte, keine API-Signaturen — Signaturen gibt es in der Python-API, Ein-Satz-Definitionen samt Chinesisch-Englisch-Gegenüberstellung im Glossar, Kommandozeilen-Schalter in der CLI-Referenz.

Welche Form ein Run hat¶

Drei Ebenen, von groß nach klein:

Die Verschachtelung ist keine 1:1-Beziehung:

Run ── dieser eine Aufruf von flower
 ├── Schritt Anforderungen klären ── Session A
 ├── Schritt Ziel setzen ─────────── Session B
 └── Schritt Arbeiten ───────────── Session C ──[Kontext fast voll]──> Session C'
      └── Arbeiten·Verdict#1 ─────── Session D

• Ein Schritt kann mehrere Sessions verbrennen. Wenn der Kontext fast voll ist, wird nicht komprimiert, sondern ein Handoff-Dokument geschrieben und eine neue Session übernimmt — das heißt Handoff und passiert innerhalb eines Runs.
• Ein neuer Run kann an alte Sessions anknüpfen. Ein weiterer flower-Aufruf im selben Verzeichnis setzt jeden Schritt auf der Session vom letzten Mal fort — das heißt Continuity und passiert prozessübergreifend. runs/lineage.json merkt sich dafür, „welcher Schrittname zu welcher session_id gehört".
• Die Verdict-Runde ist immer eine neue Session. Sie knüpft nicht an und geht nicht in die Lineage ein — wer beurteilt, „ob es fertig ist", darf nicht derselbe sein, der eben gearbeitet hat.

Eine der Reihe nach verkettete Gruppe von Schritten heißt Workflow. flower ohne Argumente nutzt den mitgelieferten Drei-Schritt-Workflow: Anforderungen klären → Ziel setzen → Arbeiten.

Arbeitsteilung: der Koordinator fasst nichts an¶

Das ist der Satz, auf dem das ganze Framework steht.

Der Koordinator ist der Agent auf dem Main Thread. Er zerlegt Aufgaben, verteilt Arbeit, liest Berichte, trifft Entscheidungen — aber er bekommt kein Write und kein Edit, und sein Bash reicht nur für Ephemeral Commands wie ls oder git status, um kurz nachzusehen (kontrolliert per Hook, nicht per Prompt-Ermahnung; und diese Ergebnisse landen nicht in der persistierten Session-Aufzeichnung). Seine Toolliste ist Agent, TodoWrite, Read plus dieses eingeschränkte Bash.

Die eigentliche Arbeit macht der Worker — ein über das Agent-Tool losgeschickter Subagent.

Warum diese Aufteilung. Ein Subagent hat eine eigene Transcript-Spur: wie viele Dateien er gelesen hat, wie oft er Tests laufen ließ, wie viele Irrwege er ging — alles steht dort; der Main Thread bekommt nur den Abschlussbericht. Und der Main Thread ist der einzige Kontext, der den gesamten Run durchzieht, also der, an dem am dringendsten gespart werden muss.

Gemessen (HT001, ein Run über 10.4 Stunden):

Pro Beauftragung bleiben im Schnitt 82 Tool-Aufrufe für den Main Thread komplett unsichtbar. Das ist die erste Ebene der Kontexteinsparung und zugleich die ergiebigste; die vollständige Herleitung steht in Kontextökonomie.

Zwei häufige Missverständnisse:

• Der Koordinator ist kein klügerer Agent. Er läuft standardmäßig auf derselben Modellklasse wie der Worker; gespart wird Kontext, nicht Modell.
• Das Antwortformat ist erzwungen. Die Antwort eines Workers besteht aus genau vier Abschnitten — Schlussfolgerung / Belege / Artefakte / Ungeprüftes, nicht länger als 30 Zeilen, und Dateiinhalte, Kommandoausgaben, Logs sowie Roh-Diffs sind verboten. Langes gehört nach artifacts/ in der Workbench, in der Antwort steht nur der Pfad.

flower hat insgesamt fünf Rollen, alle nach demselben Bauprinzip: ein eingespeister Regeltext + ein Toolset + ein Satz Hooks.

Parameter und Defaults der Factory-Funktionen stehen in der Python-API.

Long-Horizon geht an vier Stellen kaputt¶

Ein Long-Horizon-Run erstreckt sich über Stunden bis Tage, über mehrere Sessions, über Prozessneustarts hinweg. Er zerfällt auf genau ein paar Arten, und jede hat ihren Mechanismus:

Zwei Punkte lohnen sich extra zu merken:

Ein Verdict hat drei Ausgänge, nicht zwei. Erreicht, nicht erreicht, in dieser Umgebung nicht verifizierbar. Die letzten beiden sind verschiedene Ergebnisse — „hier lässt es sich nicht prüfen" wird nie als bestanden gewertet, sondern hält an und fragt den Menschen. Außerdem beurteilt der Judge das Artefakt, nicht den Quellcode: In HT002 ist genau das einmal schiefgegangen — nur der macOS-Zweig des Makefile wurde angesehen und durchgewinkt, ausgeliefert wurde tatsächlich ein Linux-ELF.

Handoff ist kein Compact. Compact heißt, das Modell fasst den bisherigen Dialog im Verborgenen zu einer Zusammenfassung zusammen: nicht lesbar, nicht änderbar, und was verloren ging, weißt du nicht. Das Handoff-Dokument ist strukturiert und liegt auf der Platte, du kannst es öffnen, eine Zeile ändern und weiterlaufen lassen. flower schaltet den nativen Auto-Compact standardmäßig ab und setzt stattdessen auf Handoff.

Zwei weitere Ebenen stehen nicht in dieser Tabelle, laufen aber bei jedem Run mit:

• Spill — Tool-Ergebnisse über 4000 Zeichen werden nach .flower/spill/ geschrieben, im Kontext bleibt nur eine Zeile mit dem Pfad. Sofort geschnitten, nicht erst zusammengefasst, wenn es voll ist.
• Workbench — die drei Verzeichnisse scripts/, artifacts/ und notes/ unter .flower/, dazu ein INDEX.md, das in den System-Prompt eingespeist wird, damit der Agent in jeder Runde weiß, was er zur Hand hat. In HT001 sammelten sich 61 Skripte an, die 331-mal ausgeführt wurden, davon 92 % mehr als einmal.

Was flower nicht macht¶

Erstens: es liefert keine fertigen Workflows. Das Framework kümmert sich nur um Mechanik: wie ein Schritt läuft, wie Kontext gespart wird, wie nach Verbindungsabbruch fortgesetzt wird, wie parallele Änderungen am selben Repository sich nicht in die Quere kommen, wie angehalten wird, wenn ein Mensch gefragt werden muss. Den Workflow schreibst du. Die drei Schritte beim nackten flower-Aufruf stammen aus flower/workflow/starter.py und sind so generisch, dass sie keinerlei Domänenannahme enthalten — sie sind zum Loslegen da, nicht die Leistungsgrenze des Frameworks. Für eigene siehe Workflows entwerfen.

Zweitens: es erbt keine Konfiguration des Hosts. flower läuft mit setting_sources=[]: weder ~/.claude/ des Hosts noch .claude/ des Projekts werden gelesen. Genau das heißt portabel — auf einer anderen Maschine dasselbe Verhalten. Domänenfähigkeiten kommen über Plugins, die mit dem Repository mitreisen, nicht darüber, was auf dieser Maschine zufällig installiert ist.

Drittens: Credentials musst du selbst mitbringen. Das ist der Preis für Punkt zwei. flower sucht Credentials in fester Reihenfolge (Prozess-Umgebungsvariablen → $FLOWER_ENV → .env im aktuellen Verzeichnis → ~/.config/flower/.env → .env im Wurzelverzeichnis des Quell-Repos) und leiht sich zuletzt als Rückfallebene die 9 Credential-Schlüssel aus dem env-Block von ~/.claude/settings.json — geliehen wird ausschließlich die Information „wo finde ich das Token", alles andere in der settings.json beeinflusst das Agent-Verhalten nicht. Die vollständige Reihenfolge und die Semantik jeder Variable stehen in der Konfigurationsreferenz.

Viertens: es ersetzt den System-Prompt nicht. Domänenanweisungen werden hinter den nativen System-Prompt von Claude Code angehängt, nicht an dessen Stelle gesetzt. Spezialisierung geht daher nicht auf Kosten der allgemeinen Fähigkeiten.

Bis hierher sollten die Ausgaben aus Schnellstart alle lesbar sein. Wer wissen will, wie sich diese Mechanismen jeweils einstellen lassen und wann man sie besser nicht einsetzt, liest ab Kontextökonomie weiter; wer nur Kommandos abschreiben will, geht zur CLI-Referenz.