Runs und Tasks

SupaCloud zieht eine klare Trennlinie zwischen dem, was du erledigt haben möchtest, und dem Akt des Erledigens. Wer diese Linie versteht, dem erschließen sich die Runs-Ansicht, das Neustart-Verhalten und die Workflow-Drill-downs auf Anhieb.

Task — die Definition

Ein Task ist eine dauerhafte Definition von agentischer Arbeit. Er enthält alles, was sich zwischen Runs nie ändert: Projekt, Prompt, Agententyp, Agentenprofil, Modell, Issue-Verknüpfung, Notizen und Subtask-Beziehungen. Du erstellst einen Task einmalig und kannst ihn beliebig oft ausführen.

Run — eine einzelne Ausführung

Ein Run ist eine einzelne Ausführung von etwas. Jeder Run besitzt einen kind:

Kind	Was er darstellt
`agent`	Eine Container-Ausführung eines Agenten. Ein eigenständig vom Nutzer gestarteter Task ist ein `agent`-Run ohne übergeordneten Run.
`workflow`	Eine Ausführung eines Workflows. Die untergeordneten Runs sind die Ausführungen der einzelnen Knoten.
`gate` / `human` / `end`	Eine Ausführung eines nicht-agentischen Workflow-Knotens; immer ein untergeordneter Run eines `workflow`-Runs.

Jeder Run enthält seinen eigenen Status, Zeitstempel, Trigger-Kontext und — bei Agent-Runs — sein eigenes append-only-Ereignisprotokoll. Ereignisse sind an run_id gebunden, nicht an task_id.

Neu starten — und vor dem Neustart bearbeiten

Ein fehlgeschlagener oder abgebrochener Task bietet auf seiner Detailseite zwei Aktionen:

Neu starten führt den Task unverändert erneut aus — gleicher Prompt, gleiches Modell, gleiche Stufe, gleiches Profil, gleicher Agent und gleiche Issue-Verknüpfung — als frischen Run.
Bearbeiten & neu starten öffnet erneut den vollständigen Start-Dialog, vorbefüllt mit der gesamten Konfiguration des Tasks: Titel, Prompt, Agent, Agent-Profil, Modell, Reasoning-Stufe, den Git-Workflow nach Abschluss, Anhänge und das verknüpfte Issue. Ändere, was du willst, und starte dann neu. Das hilft, wenn der Run an einer Einstellung gescheitert ist — richte ihn auf ein anderes Modell aus, wechsle den Agenten oder schärfe den Prompt — ohne den Task von Grund auf neu anzulegen.

Das Projekt bleibt fest im Bearbeiten-Dialog (es wird schreibgeschützt angezeigt): Ein Task gehört zu genau einem Projekt, und ein Wechsel könnte eine projektübergreifende Issue-Verknüpfung verwaisen lassen — beim Neu-Bearbeiten ändert sich also alles außer dem Ort des Tasks. Die Issue-Verknüpfung bleibt über ein Neu-Bearbeiten hinweg erhalten, selbst wenn dieses Issue inzwischen geschlossen wurde — sie wird nur entfernt, wenn du im Dialog aktiv kein Issue auswählst.

Die Ausführungsumgebung

Ein agent-Run läuft in einem gehärteten Docker-Container, und SupaCloud wählt dessen Image anhand der Sprache deines Projekts. Beim Start scannt es das Repository nach Stack-Markern — package.json, Cargo.toml, requirements.txt, *.csproj, go.mod, pom.xml und ähnliche — und startet das Image mit der passenden Toolchain:

Erkannte Sprache	Image	Toolchain über der Agent-Basis
Node.js / TypeScript	`node` (schlanker Standard)	Node + npm
Python, Rust, C#/.NET, Go, Java	`full`	Python-, Rust-, .NET-, Go- und Java-SDKs

Beide Images haben die Agent-CLIs (Claude Code, Codex, Qwen, opencode, openclaude, Copilot) und den Gemini-Runner eingebacken, sodass jeder Agententyp in jedem Image funktioniert. Ein Rust-, Python-, C#-, Go- oder Java-Projekt läuft damit gegen ein echtes SDK, statt mit command not found zu scheitern.

Workflow-Run — dasselbe Modell

Eine Workflow-Ausführung ist ein Run mit kind='workflow'. Jeder Knoten in diesem Workflow wird zu einem untergeordneten Run, dessen parent_run_id auf den Workflow-Run zurückverweist. Ein Agenten-Knoten ist gleichzeitig ein agent-Run (er hat eine task_id und startet einen Container) und ein untergeordneter Run des Workflow-Runs. Es gibt genau ein Run-Modell — kein separates Workflow-Run-Konzept neben einem allgemeinen.

Diese Baumstruktur ermöglicht den Drill-down in der Runs-Ansicht: Ein Workflow-Run lässt sich zu seinen knotenspezifischen Runs aufklappen, und jeder Agenten-Knoten-Run lässt sich wiederum zu seinem Ereignisprotokoll aufklappen.

Sichten auf einen Run

Die Detailseite eines Runs bietet bis zu drei Sichten – verschiedene Arten, denselben Run zu betrachten –, zwischen denen du mit einer segmentierten Steuerung wechselst:

Baum – die Schritt-Hierarchie des Runs. Jeder Knoten zeigt seinen Status, seine Kosten und seine Dauer, und du klickst von einem Workflow-Run zu seinen knotenspezifischen Runs hinab.
Events – das Live-Ereignisprotokoll. Dies ist derselbe Feed, den der Ausführlichkeits-Schalter und der Debug-Modus beeinflussen, sodass das, was du hier siehst, diesen Einstellungen folgt.
Wasserfall – eine maßgeschneiderte Zeitachse, die die Schritte des Runs auf eine Zeitachse legt. Jeder Schritt ist ein Balken, dessen Breite proportional zu seiner Dauer ist, nach Tiefe verschachtelt, sodass du sehen kannst, wo ein Run seine Zeit verbracht hat – welcher Schritt dominierte, wo er wartete, was parallel lief. Ein Klick auf einen Balken öffnet neben der Zeitachse einen Schritt-Inspektor mit der Eingabe, der Ausgabe, den Logs und dem Retry-Verlauf dieses Schritts, und ein Topologie-Umschalter zeichnet die Schritte als Abhängigkeitsgraph neu. Aus der Run-Kopfzeile kannst du den Run erneut abspielen (neu starten), optional mit Overrides.

Welche Sichten erscheinen, hängt vom Kind des Runs ab. Ein mehrstufiger Workflow-Run zeigt Baum und Wasserfall – seine untergeordneten Runs liefern das Timing, das die Zeitachse zeichnet –, während ein einzelner Agent-Run Events zeigt. Die gewählte Sicht wird in der Seiten-URL gehalten, sodass ein Neuladen oder ein geteilter Link den Run mit derselben Sicht wieder öffnet.

Was `tasks` weiterhin enthält

tasks führt einen denormalisierten Spiegel des Status, des Containers, des Branches und der Zeitstempel des jeweils letzten Runs. Dieser Spiegel existiert nur, um bei jedem Lesen der Task-Liste einen runs-Join zu vermeiden — er ist ausdrücklich ein Cache, nicht die Quelle der Wahrheit. Wenn du den Ausführungsverlauf, die Anzahl der Neustarts oder run-spezifische Protokolle benötigst, lies runs (und die /runs-Ansicht), nicht die Task-Zeile.

Trigger

Jeder Run hält fest, wie er gestartet wurde, in trigger_kind:

manual — gestartet über die Web-UI, das CLI-Terminal oder einen Telegram-/Discord-Befehl.
schedule — ausgelöst durch einen Task-Schedule.
workflow — ein Agenten-Knoten, der von der Workflow-Engine als untergeordneter Run gestartet wurde.
git / webhook / email — ereignisgesteuerte Trigger.

Die Runs-Ansicht

Die Seite /runs in der Web-UI zeigt eine run-spezifische Zeitleiste: Status, Kind, Trigger, Dauer und Versuchsnummer. Ein Klick auf einen Run öffnet dessen eigenes Protokoll. Ein Klick auf einen workflow-Run zeigt seine untergeordneten Knoten-Runs als Baum, wobei jeder in sein eigenes Protokoll aufklappbar ist.

Der Run-Verlauf eines Tasks (alle agent-Runs für diesen Task, über alle Versuche hinweg) ist von der Task-Detailseite aus zugänglich.

Dieses Modell ist in ADR 0022 definiert (Runs als erstklassige Entität). Wie Tasks mit Workspaces und Projekten zusammenhängen, erfährst du unter Workspaces und Organisationen.