Pipeline-Ausführung

Pipeline ausführen

Sie starten oder setzen die Ausführung einer Pipeline fort. $1 ist die PIPELINE, die ausgeführt werden soll — ihr Ordner unter ./.pipeline/. (Eine V1-Pipeline kann auch durch einen Iterationsdateipfad benannt sein; siehe Voraussetzungen).

Was Sie tun

Sie sind der Supervisor, der in der Hauptsitzung (Tiefe 0) läuft. Sie durchlaufen die Iterationen nicht selbst. Stattdessen erzeugen Sie einen einzelnen pipeline-manager-Subagenten (Tiefe 1), der die gesamte Kette steuert — für jede Iteration einen neuen step-executor startet und zwischen den Schritten pipeline-improver / pipeline-script-creator ausführt (die von ihm gesteuerte pipeline next CLI gibt automatisch die UI-Ereignisse pro Iteration aus und führt selbst externe Worktree-Hooks aus) — und einen strukturierten Bericht zurückgibt, wenn der Durchlauf abgeschlossen ist, anhält oder auf einen nicht behandelbaren Blocker stößt.

Sie bleiben auf Tiefe 0, weil drei Dinge in der Hauptsitzung leben müssen und ein Subagent sie nicht erledigen kann: (a) Besitz einer stabilen PID für die Liveness-Lockdatei des Durchlaufs, (b) stundenlanges Warten auf eine externe Bedingung (einen zu mergenden Blocker-PR) und Wiederaufnahme, (c) schließlich die Ergebnisse dem Menschen präsentieren. Ihre Aufgabe ist es also: die Ausführungs-ID erstellen (oder bei --resume eine BESTEHENDE erneut aufrufen — siehe "Wiederaufnahmeverfahren"), das UI-Tracking einrichten, den Manager starten und auf dessen Bericht reagieren — einschließlich der Ausführung des verschachtelten Blocker-Poll-Wartens und des erneuten Aufrufs des Managers zur Wiederaufnahme.

KRITISCH — Token-Disziplin: fast nichts lesen

Diese Fähigkeit ist ein Supervisor, kein Leser. Jede Iterationsdatei wird von einem step-executor in seinem eigenen frischen Kontext gelesen; die Modellauflösung pro Schritt erfolgt innerhalb des pipeline-managers.

• Lesen Sie niemals eine Iterationsdatei (steps/**/*.md). Sie berühren sie nie — nicht einmal deren Frontmatter. Der Manager löst die Modelle pro Schritt auf; Sie übergeben ihm nur das pipeline-weite Standardmodell.
• Lesen Sie PIPELINE.md nur als Frontmatter (limit: 50), einmal, zu Beginn der Kette, um das Feld model: für pipeline_default_model zu extrahieren und sonst nichts. Übergeben Sie seinen Inhalt nicht an den Manager. Bei --resume überspringen Sie diesen Lesevorgang vollständig — pipeline_default_model stammt stattdessen aus der next.json.default_model des bestehenden Durchlaufs (siehe "Wiederaufnahmeverfahren"), was verhindert, dass eine Wiederaufnahme einen Manifest-Lesevorgang zusätzlich zum bereits benötigten next.json-Lesevorgang für current_iteration hinzufügt.
• Die einzigen Dateien, die Sie vollständig Read dürfen, sind diejenigen, die Sie selbst im verschachtelten Blocker-Ablauf schreiben (Issue-Bodies, Teilaufgaben-Notizen) und, bei --resume, die kleinen .runtime/*/next.json-Orchestrierungs-Cursordateien — niemals eine Iterationsdatei oder den Körper von PIPELINE.md.

Runner-Auswahl (experimentell)

Es gibt vier Modi, und pipeline next entscheidet in jedem davon (E1), was als Nächstes läuft — niemals die Schleife, die es aufruft. Sie unterscheiden sich nur darin, wo die Schleife lebt und was einen Schritt ausführt:

Modus	Schleife lebt in	Führt einen Schritt aus
session	dieser Hauptsitzung	das Agent-Tool, in der Sitzung
manager (Standard)	einem pipeline-manager-Subagenten	das Agent-Tool, in der Sitzung
driver	einem Prozess, den dieses Plugin besitzt, kein Modell in der Schleife (pipeline drive)	einem frischen claude -p-Prozess pro Schritt
standalone	demselben besessenen Prozess wie driver	dem Agent SDK mit Ihrem eigenen API-Key — überhaupt keine Claude Code-Sitzung

driver und standalone sind leicht zu verwechseln, weil sie sich eine Schleife teilen und sich nur im Ausführenden unterscheiden; verwechseln Sie keinen von beiden mit pipeline drive, dem Befehlsnamen für den driver-Pfad, nicht einem Synonym für den Modus. Diese gebündelte CLI implementiert session, manager und driver — V1-Pipelines schreiben driver als runner: headless in das PIPELINE.md-Frontmatter (siehe unten); standalone und ein runner:-Schlüssel auf pipeline.yml-Ebene gehören zum selben Vier-Modus-Design, sind aber noch nicht in diese gebündelte Kopie eingebunden. Sagen Sie einem Benutzer also nicht, dass einer von beiden heute laufen wird.

Lösen Sie runner: zusammen mit dem model:-Lesevorgang in Schritt 3 des Verfahrens auf. In einer V2-Pipeline ist es ein Schlüssel der obersten Ebene in pipeline.yml — Grepen Sie dort nach ^runner:, was eine Zeile liest und niemals eine Schrittdatei öffnet; in V1 ist es PIPELINE.md-Frontmatter, bereits innerhalb der ≤50 Zeilen, die Sie für model: lesen. Fehlend oder nicht lesbar ⇒ manager, das heutige Verhalten und der bewusste Standardwert (E10). Ein Wert, der deklariert ist, aber keinen Zweig unten hat, läuft dennoch als manager — aber sagen Sie dies in einer Zeile, bevor Sie beginnen, denn ein Modus, den das Manifest nicht deklariert hat, ist ein Modus, den der Autor nicht gewählt hat. Leiten Sie den Modus niemals aus der Kettenlänge ab: Eine unsichtbare Schwelle lässt einen Befehl sich auf zwei Arten verhalten.

runner: session — die Hauptsitzung führt die Schleife selbst aus

Erzeugen Sie KEINEN pipeline-manager. Lesen Sie die Schleife der Sitzung und befolgen Sie sie an Stelle der Verfahrensschritte 5.1–5.3; alles andere in dieser Datei — Schritte 1–4, das Wiederaufnahmeverfahren, der verschachtelte Blocker-Ablauf, die Supervisor-Invarianten und das Berichtsformat — gilt unverändert für Sie, weil Sie immer noch der Supervisor auf Tiefe 0 sind und nur die Schleife absorbiert haben, anstatt sie zu delegieren.

Diese Datei enthält die beiden Vorab-Verweigerungen, die dieser Modus benötigt (eine CLI, die zu alt für pipeline next --brief-file ist, und execution: parallel, deren Nutzlasten in einem Brief leben, den die Sitzung nicht öffnen darf) und ist ehrlich über den Kompromiss: Jede Aktion und jeder Schrittreport landet im Kontext, den der Benutzer beobachtet, daher gehört eine lange Kette in manager — genau deshalb ist manager immer noch der Standard.

runner: headless (v1) — der driver-Modus

Wenn die Pipeline V1 ist und das PIPELINE.md-Frontmatter, das Sie für model: gelesen haben, auch runner: headless trägt (V1-Schreibweise des driver-Modus — siehe Tabelle oben), erzeugen Sie KEINEN pipeline-manager. Führen Sie stattdessen den gebündelten Treiber als Hintergrundprozess aus und überwachen Sie ihn:

bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" drive \
  --root "<pipeline_root>" --run-id "<run_id>" [--start "<step-name>"] \
  --default-model "<pipeline_default_model-or-null>" \
  [--default-effort "<level-or-null>"] \
  [--model "<step_id>=<model>" ...] [--effort "<step_id>=<level>" ...] --json [--resume]

Starten Sie es mit run_in_background: true und reagieren Sie auf sein abschließendes JSON, wenn es beendet wird: Exit 0 → pipeline.completed ausgeben; Exit 1 → pipeline.halted ausgeben und den Grund nennen; Exit 3 (blocked) → den verschachtelten Blocker-Ablauf unten ausführen, dann drive erneut mit --resume ausführen. Alles andere an Ihrer Supervisor-Rolle (Ausführungs-ID, Liveness, Mirror-Bindung, Benutzerberichterstattung) bleibt unverändert. Dieser driver-Pfad (V1: runner: headless) überspringt Selbstverbesserungsaktionen und lässt .feedback/<run_id>/ intakt — erwähnen Sie dies in Ihrem Abschlussbericht, damit der Benutzer einen manuellen Verbesserungsdurchlauf ausführen kann. Wenn runner: fehlt oder manager ist, fahren Sie genau wie unten beschrieben fort.

Modellauswahl

Eine Pipeline (und jede Iteration) kann sich über das OPTIONALE Frontmatter-Feld model: für ein Claude-Modell entscheiden. Das Feld standardmäßig auf „vererbt“ — weglassen führt dazu, dass der Schritt-Ausführer das Sitzungsmodell erbt. Sie lösen nur den Pipeline-Standard auf und übergeben ihn an den Manager; die pipeline next CLI löst das effektive Modell pro Iteration auf (Außerkraftsetzung pro Durchlauf ?? step.model ?? pipeline_default_model), und der Manager übergibt es an jeden step-executor über den model-Parameter pro Aufruf des Agent-Tools. Übergeben Sie den aufgelösten Wert unverändert — übersetzen Sie KEINEN Alias in eine kanonische ID. Der Agent-Parameter model akzeptiert die Aliase, kanonischen IDs und inherit direkt.

Akzeptiertes model:-Vokabular (durchgängig): einer der Aliase haiku / sonnet / opus / fable ODER eine beliebige exakte kanonische Claude-Modell-ID (ein String, der mit claude- beginnt, z. B. claude-opus-4-8, claude-sonnet-4-6, claude-fable-5) ODER inherit / fehlend (→ Sitzungsstandard).

Lösen Sie pipeline_default_model auf: In einer V2-Pipeline liest die CLI defaults.model selbst aus pipeline.yml — übergeben Sie null und lassen Sie es sie tun. Andernfalls, falls <pipeline-root>/PIPELINE.md existiert, Readen Sie es mit limit: 50 und nehmen Sie den Frontmatter-Wert model:, wenn es sich um einen akzeptierten Wert handelt (ein Alias, eine claude-*-ID, unverändert beibehalten); inherit/fehlend → null. Falls PIPELINE.md fehlt, null. Ungültige Werte — alles, was nicht einer der akzeptierten Aliase, eine claude-*-ID, inherit oder fehlend ist — einmal warnen und auf null zurückfallen (nicht anhalten). (Das Lesen von ≤ ~10 Zeilen Frontmatter ist Metadatenextraktion, kein Inhaltslesen — es dupliziert niemals das, was der Schritt-Ausführer lädt.)

Außerkraftsetzungen von Schrittmodellen pro Durchlauf (step_model_overrides): Der Benutzer kann einzelne Schritte NUR FÜR DIESEN DURCHLAUF auf ein anderes Modell festlegen — ohne eine Pipeline-Datei zu bearbeiten — entweder mit expliziten Flags nach dem Pfad (--model <step_id>=<model>, wiederholbar) oder in natürlicher Sprache („führe Schritte 02-implement und 03-refine auf fable aus“). Normalisieren Sie das Gesagte in Paare <step_id>=<model>: step_id ist das step_id-Frontmatter des Schritts oder sein Dateinamenstamm (z. B. 02-implement für steps/02-implement.md); model verwendet das obige akzeptierte Vokabular (inherit erzwingt den Sitzungsstandard für diesen Schritt). Sie lesen KEINE Schrittdatei, um die IDs zu validieren — die CLI warnt bei unbekannten IDs und lehnt ungültige Modelle ab. Übergeben Sie die Paare an den Manager als step_model_overrides (siehe 5.1) oder, auf dem driver-Pfad, als wiederholte --model-Flags im drive-Befehl. Eine Außerkraftsetzung schlägt das eigene model:-Frontmatter des Schritts; Schritte ohne Außerkraftsetzung bleiben unberührt. Die CLI persistiert die Außerkraftsetzungen im Zustand des Durchlaufs bei der Initialisierung, sodass Wiederaufnahmen sie automatisch behalten — übergeben Sie die gleichen Paare trotzdem erneut, wenn Sie den Manager erneut aufrufen (harmlos und überlebt ein gelöschtes .runtime/). Keine Außerkraftsetzungen erwähnt ⇒ vollständig weglassen.

Aufwandsauswahl (Argumentationsaufwand — das model:-Gegenstück)

Eine Pipeline und jede Iteration kann sich auch über das OPTIONALE Frontmatter-Feld effort: für einen Argumentationsaufwand entscheiden (Stufen: low / medium / high / xhigh / max; inherit/fehlend → den Aufwand der Sitzung). Es wird über die exakt gleiche Leiter wie das Modell aufgelöst — Außerkraftsetzung pro Durchlauf ?? Schritt-effort: ?? Pipeline-effort: ?? vererbt — vollständig innerhalb der pipeline next CLI. Lösen Sie pipeline_default_effort aus dem gleichen PIPELINE.md-Frontmatter-Lesevorgang auf, den Sie bereits für model: durchführen (gleiche Regel für ungültige Werte: einmal warnen, auf null zurückfallen), übergeben Sie es an den Manager als pipeline_default_effort, und normalisieren Sie Benutzeranfragen wie „führe 03-refine mit max effort aus“ in step_effort_overrides-Paare (<step_id>=<level>), die genau wie die Modellpaare übergeben werden (--effort-Flags auf dem driver-Pfad). EHRLICHKEITSHINWEIS: Der driver-Runner wendet den Aufwand tatsächlich an (claude --effort pro Start); im Manager-Modus stellt das Agent-Tool möglicherweise noch keinen Aufwandsparameter pro Aufruf bereit — der Manager übergibt ihn, wenn unterstützt, und andernfalls erbt der Schritt den Aufwand der Sitzung (siehe pipeline-manager.md § run-step).

Voraussetzungen

• Eine Pipeline existiert unter dem aktuellen ./.pipeline/ des Projekts (normalerweise erstellt mit /pipeline:design).
• $1 ist der Pipeline-ORDNER unter ./.pipeline/ (z. B. ./.pipeline/ship-feature), der einen FRISCHEN Durchlauf startet — dies erstellt immer eine NEUE run_id. --start <step-name> startet diesen frischen Durchlauf bei einem benannten Schritt anstatt beim ersten des Manifests. Ein Iterationsdateipfad wird immer noch akzeptiert und ist die Art und Weise, wie eine V1-Pipeline einen Startschritt benennt. ODER --resume [<run_id>], um einen BESTEHENDEN Durchlauf unter seiner URSPRÜNGLICHEN run_id erneut aufzurufen (siehe „Wiederaufnahmeverfahren") — die einzige Möglichkeit, einen Durchlauf einer toten Sitzung fortzusetzen, ohne seinen Zustand zu verwaist.
• Das aktuelle Arbeitsverzeichnis ist das Wurzelverzeichnis des Consumer-Projekts — alle Dateibearbeitungen, die von Iterationen durchgeführt werden, landen hier.

Ausgabe von Journal-Ereignissen

Sie geben den Durchlauf-Lebenszyklus an <project>/.pipeline/.runtime/events.jsonl aus; die Ereignisse pro Iteration (iteration.*, improver.*, script_creator.*, worktree.*) werden automatisch innerhalb des von Ihnen gesteuerten pipeline next-CLI-Prozesses ausgegeben, den der Manager steuert (der Manager selbst gibt nur die retrospektiven Ereignisse von Improver/Script aus). Da der gesamte Durchlauf eine einzige session_id teilt, ermöglicht die unten registrierte Mirror-Bindung dem Analyse-Hook, die Tool-Aufrufe des Managers und der Schritt-Ausführer mit diesem Durchlauf zu korrelieren. Ausgaben sind nach bestem Bemühen — lassen Sie niemals zu, dass ein Fehler den Durchlauf anhält.

Einmalige Einrichtung zu Beginn des Verfahrens: Erstellen Sie die Ausführungs-ID, indem Sie die CLI aufrufen — niemals selbst eine generieren oder ein Format erfinden: bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" id. Erfassen Sie den Literalwert, den sie ausgibt (eine UUIDv7, z. B. 019fc762-5762-7000-a9bf-922ed8fa00be).

KRITISCH — übergeben Sie run_id bei jedem Writer-Aufruf wörtlich. Das Bash-Tool von Claude Code bewahrt den Shell-Zustand nicht zwischen Aufrufen, daher erreicht eine exportierte Umgebungsvariable den nächsten pipeline event-Aufruf nicht. Übergeben Sie run_id=<die-literal-id> als k=v-Argument bei JEDEM Aufruf. k=v-Argumente haben keine Leerzeichen um das =; setzen Sie einen Wert, der Leerzeichen enthält, in einfache Anführungszeichen.

Ausgabehilfe (mit Bun ausführen, still bei Erfolg, beendet auch bei Fehler mit 0 — Ausgabe nicht prüfen):

bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" event <event-type> run_id=<literal-id> [k=v ...]

Was Sie ausgeben (ein Aufruf pro Aufzählungspunkt):

• Bei --resume gilt diese gesamte Liste nicht — das Wiederaufnahmeverfahren gibt nur write-liveness + register-mirror-binding für die BESTEHENDE run_id aus und niemals pipeline.started (das erneute Betreten eines Durchlaufs ist kein Starten eines neuen). Siehe „Wiederaufnahmeverfahren".
• Nach dem Banner: pipeline.started run_id=<id> pipeline_name=<name> first_iteration_path=<abs> pipeline_root=<abs> default_model=<model-or-null> — default_model ist pipeline_default_model (ein Alias haiku/sonnet/opus/fable, eine kanonische claude-*-ID oder literal null).
• Unmittelbar nach pipeline.started schreiben Sie die Liveness-Lockdatei, damit ein Leser erkennen kann, dass dieser Durchlauf ohne ein Abschlussereignis gestorben ist: bun "${CLAUDE_PLUGIN_ROOT}/apps/pipeline-cli/src/cli.ts" event write-liveness run_id=<id> pid=$PPID (PowerShell: pid=$PID). Übergeben Sie die OS-PID des Prozesses, der diesen Supervisor steuert — $PPID ist der beste tragbare Handle für die persistente Claude-Sitzung. Der Daemon setzt einen Durchlauf nur automatisch zurück, wenn diese PID ein echter, toter Prozess ist, daher ist ein unzuverlässiger Wert eine sichere Nulloperation.

Im …

[abgeschnitten für Übersetzung]