Boards und das Dashboard

Drei Flächen tragen die laufende Arbeit eines Workspace. Die Übersicht (/) ist das Cockpit: ein Bildschirm, der beantwortet, was gerade passiert. Das Task-Board (/tasks) listet die Arbeit, die du definiert hast. Das Run-Board (/runs) listet jede Ausführung – Agent wie Workflow.

Diese Seite ist die Referenz für diese drei Flächen – ihre Panels, Spalten, Filter und Badges. Was ein Task und ein Run tatsächlich sind und wie die Kind-Runs eines Workflow-Runs verschachtelt sind, steht in Runs und Tasks; lies das zuerst, diese Seite wiederholt das Modell bewusst nicht.

Ein Paging-Vertrag, drei Boards

Task-Board und Run-Board teilen sich ein Tabellen-Primitiv und einen Server-Vertrag: {items, total, facets}. Suche, Filter, Sortierung und Paging greifen alle serverseitig über den gesamten Geltungsbereich – ein Board beschneidet nie nur eine bereits geladene Seite im Browser. Eine Zahl in einem Reiter oder auf einem Facetten-Chip ist deshalb die Zahl über den ganzen Workspace, nicht über die sichtbaren Zeilen.

Das Dashboard-Cockpit

/ – ein einziges Board, das sich in den Viewport einpasst. Nichts darauf ist ein Formular: Jedes Panel ist eine Lesung desselben Run-Fensters, und jede Zahl verlinkt in die Fläche, die sie besitzt.

Die Kopfzeile

Steuerung	Werte	Wirkung
Zeitraum	1h, 24h, 7d, 30d	Lädt das Run-Fenster neu (bis zu 500 Runs). Standard 24h
Domänenfilter	Alle, A, W, S, P	Grenzt auf Agent- / Workflow- / Skript- / App-Runs ein. Wirkt im Speicher, der Wechsel ist also sofort da
Run starten	–	Öffnet den vereinheitlichten Start-Dialog an Ort und Stelle

Der Breadcrumb unter dem Titel liest sich <Workspace> · alle Runs · Echtzeit. Beide Segment-Gruppen und der CTA sind auf dem Telefon ausgeblendet.

Ein brandneuer Workspace bekommt zusätzlich eine Erste-Schritte-Checkliste über dem abgedunkelten Board, die dich von Anmeldedaten über Git und Projekt bis zum ersten Task führt.

Die Panels

Panel	Was es beantwortet
KPI-Leiste	Fünf Karten: Jetzt aktiv, Wartet auf Dich, Fehlgeschlagen <Zeitraum>, Fleet-Auslastung, Ausgaben <Fenster>
Run-Stream	Die Runs des Fensters als Diagramm. Drei Sichten: Dauer × Status, Durchsatz, Verlauf (die Parallelitätskurve). Nur lesend – es filtert das Board nicht
Cockpit-Umschalter	Eine segmentierte Karte mit Parallel (Spitze / Gesamtslots), Fleet (online / registrierte Runner) und Sicherheit (Gefahren-Eskalationen dieser Sitzung) – jedes Segment zeigt seine Kennzahl auch im eingeklappten Zustand
Attention-Queue	Die Zeilen, die eine Entscheidung oder einen neuen Versuch brauchen (siehe unten)
Verteilung	Drei Sichten – Matrix, Funnel, Aktivität. Die Matrix kreuzt die vier Arten (Agent · Workflow · Skript · App) mit vier groben Spalten: läuft, wartet, ok, fehler
Spend	Die Kosten des Zeitraums, aufgeteilt nach Art oder Agent, über dem Balken des Monatsbudgets

Jede KPI-Karte ist ein Deep-Link: Jetzt aktiv → /runs?status=running, Wartet auf Dich → /runs?status=waiting, Fehlgeschlagen → /runs?status=failed&range=…, Fleet-Auslastung → die Runner-Einstellungen, Ausgaben → die Budget-Einstellungen.

Zwei Karten melden ein engeres Fenster als ihr Titel

Jetzt aktiv trägt einen Chip +N / 1h, der die in der letzten Stunde eingetroffenen Runs zählt, und Fehlgeschlagen trägt ein Delta ↑N vs. 24h, das die letzten 24 Stunden mit den 24 davor vergleicht. Dieses Delta ist ein fester Wanduhr-Vergleich und wird deshalb nur angezeigt, solange der Zeitraum exakt 24h ist. Die Karte Ausgaben folgt dem Zeitraum der Kopfzeile, gefaltet auf die gröberen Fenster der Spend-API (Heute · 7T · 30T) – beide Zeiträume unter einem Tag lesen sich als Heute.

Die Attention-Queue

Die Queue ist das eine handlungsfähige Panel, und was eine Zeile hineinbringt, ist eine Regel, keine Kuratierung. Über das aktuelle Run-Fenster und den aktuellen Domänenfilter:

Reiter	Ein Run landet hier, wenn	Zeilen-Aktionen
Offen	sein Status waiting ist	Freigeben · Ablehnen
Offen	sein Status den Fehler-Ton trägt (failed, error, timeout, rejected)	Neu starten · Log
Gelöst	er als completed oder cancelled geendet ist	Neu starten · Log

Beide Listen stehen nach jüngster Aktivität zuerst. Jede Zeile zeigt das Art-Glyph, den Task-Titel (sonst den Ergebnistitel des Runs, im Notfall Art + Kurz-ID), den Projektnamen und den Status.

Drei Folgen dieser Regel solltest du kennen:

• Freigeben / Ablehnen lösen nur ein Workflow-Human-Gate auf. Das Urteil geht gegen den übergeordneten Workflow-Run der Zeile und dessen Node-Key. Ein wartender Run ohne Workflow-Kontext hat nichts, wogegen entschieden werden könnte – die Schaltflächen öffnen dann einfach den Run.
• Neu starten erscheint nur, wenn die Zeile einen Task hat. Ein fehlgeschlagener Workflow- oder Skript-Run hat aus der Queue heraus nichts zum Neustarten und bietet allein Log an, statt einer Steuerung, die nichts täte.
• Eine Zeile auszuwählen öffnet /tasks/{id}, wenn der Run einen Task hat, sonst /runs/{id}.

Ein Run außerhalb des gewählten Fensters oder der gewählten Domäne steht nicht in der Queue – weite den Zeitraum aus, wenn eine Entscheidung zu fehlen scheint. Den dauerhaften Entscheidungs-Posteingang, der nicht fensterbezogen ist, beschreibt Den Posteingang abarbeiten.

Live-Aktualisierung

Das Cockpit abonniert Run-Lebenszyklus-Ereignisse und lädt das Fenster entprellt nach, sodass KPI-Leiste und Queue laufende Arbeit ohne Neuladen mitverfolgen. Nur Lebenszyklus-Ereignisse zählen; der Ausgabestrom eines Agenten löst nie ein Nachladen aus.

Das Task-Board

/tasks – eine Zeile je Task, oder eine Zeile je Gruppe, wenn mehrere Tasks gemeinsam aufgefächert wurden.

Status-Reiter

Über der Tabelle sitzen vier Reiter, jeder mit einer Live-Zahl über den gesamten Workspace-Geltungsbereich (nicht über die Seite):

Reiter	Lässt zu
Aktiv	running, starting, pending
Alle	jeden Task, kein Statusfilter
Abgeschlossen	completed
Fehlgeschlagen	failed

Spalten

Neun Spalten; jede einzelne sortiert serverseitig. Die Standardreihenfolge ist neueste zuerst (nach Erstellungszeit).

Spalte	Was sie trägt	Auf dem Telefon
Task	Status-Glyph + Titel, den Git-Branch als Unterzeile und – sobald der Task fertig ist – ein einzeiliges Ergebnis oder den Fehlergrund	sichtbar
Agent	Der Name des Agentenprofils, ersatzweise der rohe Agententyp	ausgeblendet
Modell	Das auf dem Task fixierte Modell, sonst —	ausgeblendet
Aufwand	Die auf dem Task fixierte Reasoning-Stufe, sonst —	ausgeblendet
Projekt	Das besitzende Projekt	ausgeblendet
Status	Das dual kodierte Status-Badge	sichtbar
Gestartet	Wann der Task gestartet ist, als relative Zeit (ersatzweise wann er angelegt wurde)	ausgeblendet
Dauer	Wanduhrzeit von Start bis Abschluss	sichtbar
Kosten	Der Geldbetrag über einer gedämpften Zeile Eingabe → Ausgabe-Tokens	sichtbar

Werkzeugleiste

Eine Zeile über der Tabellenkarte:

Steuerung	Verhalten
Filter	Facetten-Chips für Agent, Modell, Aufwand und Projekt, jede Option mit ihrer Anzahl beschriftet. Aktive Facetten erscheinen darunter als entfernbare Chips
Suchen…	Entprellte Freitextsuche allein über den Aufgabentitel. Serverseitig, sie durchsucht also jeden Task im Geltungsbereich
Spalten	Einzelne Spalten ein- oder ausblenden
Task starten	Öffnet /tasks/new

Der Blätterer bietet 10 / 20 / 50 Zeilen pro Seite (Standard 20) und meldet <gezeigt> von <gesamt>.

Gruppenzeilen werden nie über eine Seite hinweg zerschnitten

Tasks, die sich eine Gruppe teilen, klappen zu einer Zeile mit Gruppenlabel, Task-Anzahl und den verketteten Kind-Titeln zusammen; ihre Meta-Zellen lesen vom ersten Kind, ihre Kosten sind die Summe. Geblättert wird auf Ebene der Anzeige-Einheit, eine Gruppe wird also nie von einer Seitengrenze halbiert. Eine Gruppenzeile auszuwählen öffnet ihre eigene Aggregationsseite statt der Peek-Schublade.

Wählst du eine Einzel-Task-Zeile aus, öffnet sich eine Peek-Schublade über der weiterhin eingehängten Liste; /tasks/{id} bleibt ein funktionierender Deep-Link mit der Vollansicht.

Das Run-Board

/runs – eine Zeile je Ausführung. Ein Task ist die Definition, ein Run eine Ausführung davon; ein neu gestarteter Task erscheint hier also als mehrere Runs – siehe Runs und Tasks.

Art-Reiter

Reiter	Zeigt
Alle	Jeden Run der obersten Ebene – Agent, Workflow und den Rest
Workflows	Nur workflow-Runs
Agenten	Nur agent-Runs der obersten Ebene; ein Agent-Run, der Kind eines Workflows ist, bleibt außen vor

Spalten

Spalte	Was sie trägt	Auf dem Telefon
Art	Eine beschriftete, art-getönte Pille – die Art des Runs, ausdrücklich benannt	ausgeblendet
Run	Der Workflow-Node-Key, sonst der Task- oder Workflow-Name; eine Pille ×N für einen wiederholten Versuch; und eine Unterzeile mit Fehlermeldung, Prompt oder Git-Branch, in dieser Reihenfolge	sichtbar
Status	Das dual kodierte Status-Badge	sichtbar
Auslöser	Wie der Run gestartet wurde	ausgeblendet
Dauer	Wanduhrzeit	sichtbar
Kosten	Der Geldbetrag über der Zeile Eingabe → Ausgabe-Tokens	sichtbar
Wann	Die Erstellungszeit als kompakte relative Angabe	ausgeblendet

Sortiert wird serverseitig über eine feste Freigabeliste: Erstellungszeit, Startzeit, Endzeit, Status, Art, Auslöser, Dauer, Kosten und der Node-Key des Runs. Standard ist neueste zuerst.

Filter

Vier Facetten sitzen in der Werkzeugleiste der Tabelle und begrenzen Tabelle und Diagramm gemeinsam:

Facette	Optionen
Status	Alle, Läuft, Wartet, In Warteschlange, Abgeschlossen, Fehlgeschlagen, Abgebrochen, Übersprungen, Ausstehend
Typ	Alle, Agent, Workflow, Loop, Code, Gate, Mensch, Ende, Warten, Telegram-Benachrichtigung, E-Mail-Benachrichtigung, Webhook-Benachrichtigung
Trigger	Alle, Manuell, Zeitplan, Webhook, Linear, Notion
Wartegrund	Alle, Wartet auf Ereignis, Wartet auf Mensch

Wartegrund ist eine Zusammensetzung, keine fünfte Achse. Wählst du einen aus, fixiert das den Status auf Wartet und die Art auf den passenden Node-Typ – er überschreibt damit, was die Facetten Status und Typ gesagt haben.

Die Suche ist ein Freitext über Titel und Kennung des Quell-Issues eines Runs – nicht über den Prompt und nicht über das Protokoll.

Über der Tabelle sitzen die Art-Reiter, der Diagramm-Umschalter (Dauer × Status / Nebenläufigkeit), die Zeitraum-Voreinstellungen 1h / 24h / 7d / 30d, die Schaltfläche Zeitraum wählen und – nachdem du ein Fenster im Diagramm aufgezogen hast – ein Chip Zeitraum zurücksetzen.

Filterauswahl, Zeitraum-Voreinstellung und aktiver Reiter werden in die Seiten-URL gespiegelt (?status=, ?kind=, ?trigger=, ?wait_reason=, ?app_id=, ?range=, ?tab=), ein gefiltertes Board ist damit ein teilbarer Link. Die beiden Standardwerte (range=24h, tab=all) werden weggelassen, und ein aufgezogenes Fenster wird bewusst nicht kodiert.

Run-Arten

Die Facette Typ listet die Arten, nach denen du filtern kannst – die Spalte Art beschriftet aber mehr als das. Die Kind-Runs eines Workflow-Runs erscheinen auch als ihr Node-Typ – db_query, db_execute, http_request, transform, llm_classify, imap_ack und connector – und übernehmen dabei die Node-Namen des Workflow-Builders, dazu Script, App und Discord-Benachrichtigung. Diese erscheinen als Beschriftung, ohne als Filteroption angeboten zu werden.

Sammelaktionen

Das Run-Board hat eine führende Kontrollkästchen-Spalte (nur am Desktop). Sobald eine Auswahl aktiv ist, erscheint über der Tabelle eine Leiste:

Aktion	Wirkt auf
Erneut ausführen	Die bereits beendeten Runs der Auswahl – ein Workflow-Run startet einen frischen Run, ein Agent-Run startet seinen Task neu
Abbrechen	Die noch aktiven Runs der Auswahl
CSV exportieren / JSON exportieren	Die gesamte Auswahl, heruntergeladen als runs.csv / runs.json
Zurücksetzen	Verwirft die Auswahl

Jeder Run wird einzeln bearbeitet: Ein Fehlschlag bricht weder den Rest ab noch verliert er ihn. Runs, die nicht verarbeitet werden konnten, bleiben ausgewählt – mit einer Anzahl in der Leiste, damit du genau diese erneut versuchen kannst.

Der Blätterer bietet 10 / 20 / 50 Zeilen pro Seite und steht auf 50. Eine Zeile auszuwählen öffnet die Run-Peek-Schublade; /runs/{id} bleibt der vollständige Deep-Link.

Einen Status lesen

Status ist nie nur Farbe – jeder Ton trägt zusätzlich seine eigene Glyph-Form, damit die Badges auch ohne Farbsehen lesbar bleiben.

Badge	Ton (Glyph)	Was er bedeutet	Was zu tun ist
Ausstehend	ausstehend (Punkt)	Angenommen, noch nicht gestartet	Warten; nichts ist falsch
In Warteschlange	Warnung (Ring)	Hinter einer Parallelitätsgrenze geparkt, nicht durch eine Entscheidung	Warten oder die Parallelitätsgrenze von Workspace / Projekt anheben
Startet	läuft (pulsierender Punkt)	Der Container fährt hoch	Warten. Das Run-Board faltet das auf Läuft
Läuft	läuft (pulsierender Punkt)	Läuft gerade	Verfolgen, eingreifen oder abbrechen
Wartet	Warnung (Ring)	Pausiert auf eine Entscheidung oder ein Ereignis, kein Fehlschlag	Siehe die beiden Pausengründe unten
Pausiert	Warnung (Ring)	Pause auf Task-Ebene	Siehe die beiden Pausengründe unten
Abgeschlossen	Erfolg (Haken)	Sauber beendet	Ergebnis lesen; die Unterzeile der Zeile trägt die Zusammenfassung
Fehlgeschlagen	Fehler (Kreuz)	Mit einem Fehler beendet	Fehlergrund in der Zeile lesen, dann neu starten oder bearbeiten und neu starten
Abgebrochen	neutral (Punkt)	Von einer Person oder vom besitzenden Run gestoppt	Neu starten, wenn du die Arbeit noch willst
Übersprungen	neutral (Punkt)	Eine Richtlinie hat ihn übersprungen – keine passende Arbeit, übersprungene Autorschaft oder ein nicht erfüllter Pflichtstatus. Nur Runs	Nichts; der Übersprung ist das beabsichtigte Ergebnis

Die beiden Pausengründe

Ein wartender Run ist nicht kaputt, und der Grund seines Anhaltens entscheidet, was du tust. Das Board zeigt nur den Status; die Task-Detailseite (/tasks/{id}) ergänzt ein ruhiges bernsteinfarbenes Banner, das den Grund benennt:

Banner	Grund	Auflösung
Pausiert — Nutzungsfenster voll	Das vorausbezahlte Nutzungsfenster des Anbieters ist ausgeschöpft	Nichts zu reparieren. Der Run läuft von selbst weiter, sobald sich das Fenster erneuert; Nutzung ansehen öffnet den Nutzungsbericht
Pausiert — wartet auf deine Entscheidung	Der Agent hat eine Frage gestellt oder braucht eine Werkzeug- oder Visual-Freigabe	Anfrage ansehen öffnet die offene Entscheidung; sie zu beantworten setzt den Run fort

Eine Pause wegen des Nutzungslimits gilt bewusst nicht als Fehlschlag, obwohl die Engine zusätzlich einen Fehler protokolliert – starte sie also nie in der Hoffnung neu, das zu lösen. Für den Kontingent-Fall siehe Wenn ein Modell sein Kontingent erreicht, für den Entscheidungs-Fall Agenten-Aktionen freigeben oder ablehnen. Ist ein Run fehlgeschlagen statt pausiert, beginne bei Einen hängenden oder fehlgeschlagenen Lauf diagnostizieren.

Auf dem Telefon

Beide Boards behalten jede Fähigkeit, umgeräumt statt entfernt. Die gemeinsame Werkzeugleiste bleibt eine Zeile ohne Umbruch: Filter, Sortierung und Spalten schrumpfen zu reinen Symbolschaltflächen, die statt der Desktop-Popover Bottom-Sheets öffnen, und das Suchfeld dehnt sich über den Rest der Zeile; aktive Facetten reiten weiterhin auf ihrer eigenen Chip-Zeile darunter. Sortierung gibt es nur hier – am Desktop sortierst du über die Spaltenköpfe, die ein Telefon nicht rendert. Die Desktop-Schaltfläche Neu wird durch eine runde schwebende Aktionsschaltfläche in der Daumenzone unten rechts ersetzt, und die Mehrfachauswahl-Spalte gibt es nur am Desktop. Zeilen werden als Karten gerendert, die breiten Spalten fallen weg, und nur die Liste scrollt – Reiter, Werkzeugleiste und Blätterer bleiben stehen, während die Tabellenkarte schrumpft und intern scrollt.

Das Run-Board geht einen Schritt weiter: Seine Desktop-Zeile aus Reitern und Zeitraum ist ganz ausgeblendet, ein Diagramm-Umschalter wandert in die obere Leiste, und das Diagramm wird ein eigener Bildschirm statt eines Blocks über der Liste. Das Dashboard legt unterhalb von 720 px seine breiten Zonen ab und behält KPI-Leiste, eine kompakte Aktivitäts-Sparkline und die Attention-Queue; die Karte Wartet auf Dich fällt einen Haltepunkt früher weg, damit die Leiste ein sauberes 2 × 2 bleibt.

Aus dem Web-Terminal

Dieselben Informationen sind lesbar, ohne ein Board zu öffnen:

Befehl	Entspricht
status [--all]	Dem Reiter Aktiv des Task-Boards (--all weitet ihn auf Alle)
task <id>	Dem Detail eines Tasks, mit Kosten, Dauer und letzter Aktivität
runs [--status=X]	Dem Run-Board, optional nach Status eingegrenzt
approvals	Den Entscheidungen hinter dem Reiter Offen der Attention-Queue

Siehe die Befehle des Web-Terminals.

Siehe auch

• Runs und Tasks
• Navigation und Hubs
• Den Posteingang abarbeiten
• Agenten-Aktionen freigeben oder ablehnen
• Einen hängenden oder fehlgeschlagenen Lauf diagnostizieren
• Berichte