Workboard-Plugin

Das Workboard-Plugin fügt der Control UI optional ein Board im Kanban-Stil hinzu: Arbeitskarten in Agent-Größe, die Zuweisung an Agents und einen Link zurück zur Aufgabe, zum Lauf und zur Dashboard-Sitzung der Karte.

Workboard ist bewusst kompakt gehalten: Es erfasst lokale operative Arbeiten für ein OpenClaw Gateway. Es ersetzt weder GitHub Issues, Linear oder Jira noch andere Projektmanagementsysteme für Teams.

Aktivierung

Workboard ist im Lieferumfang enthalten, aber standardmäßig deaktiviert:

1. Öffnen Sie Plugins in der Control UI oder verwenden Sie /settings/plugins relativ zum konfigurierten Basispfad der Control UI. Ein Basispfad von /openclaw verwendet beispielsweise /openclaw/settings/plugins.
2. Suchen Sie Workboard und wählen Sie Aktivieren. Da Workboard in OpenClaw enthalten ist, ist keine Aktion zum Installieren erforderlich.
3. Wenn die UI meldet, dass ein Neustart erforderlich ist, starten Sie das Gateway neu.

Die Registerkarte Workboard wird in der Dashboard-Navigation angezeigt, nachdem die Plugin-Laufzeit geladen wurde. Solange es deaktiviert ist, bleibt die Registerkarte in der Navigation ausgeblendet. Wenn Sie die Route /workboard direkt öffnen, während das Plugin deaktiviert oder durch plugins.allow/plugins.deny blockiert ist, wird anstelle der Kartendaten ein Status angezeigt, dass das Plugin nicht verfügbar ist.

Der entsprechende CLI-Ablauf lautet:

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Konfiguration

Workboard verfügt über keine Plugin-spezifische Konfiguration. Aktivieren oder deaktivieren Sie es mit dem standardmäßigen Plugin-Eintrag:

{  plugins: {    entries: {      workboard: {        enabled: true,        config: {},      },    },  },}

openclaw plugins disable workboardopenclaw gateway restart

Kartenfelder

Karten enthalten außerdem kompakte Metadaten zu Versuchen, Kommentaren, Links, Nachweisen, Artefakten, Automatisierungseinstellungen, Anhängen, Worker-Protokollen, dem Worker-Protokollstatus, Ansprüchen, Diagnosen, Benachrichtigungen, der Vorlagen-ID, dem Archivstatus und der Erkennung veralteter Sitzungen sowie eine Liste der letzten Ereignisse (created, edited, moved, linked, specified, decomposed, claimed, heartbeat, execution_updated, attempt_started, attempt_updated, comment_added, link_added, proof_added, artifact_added, attachment_added, diagnostic, notification, dispatch, orchestration, protocol_violation, archived, unarchived, stale). Anhand dieser Metadaten kann eine Bedienperson nachvollziehen, wie eine Karte das Board durchlaufen hat, ohne die verknüpfte Sitzung zu öffnen. Es handelt sich um lokalen operativen Kontext, nicht um einen Ersatz für Sitzungstranskripte oder den Verlauf von GitHub Issues.

Karten werden im eigenen Gateway-Status des Plugins gespeichert und zusammen mit dem übrigen OpenClaw-Status dieses Gateways verschoben (siehe Speicherung).

Arbeit von einer Karte aus starten

Nicht verknüpfte Karten können Arbeit direkt starten:

• Codex ausführen / Claude ausführen startet einen aufgabenverfolgten Agent-Lauf mit einer expliziten Engine, sendet den Prompt der Karte und setzt die Karte auf running. Codex- Läufe verwenden openai/gpt-5.6-sol; Claude-Läufe verwenden anthropic/claude-sonnet-4-6.
• Codex öffnen / Claude öffnen erstellt eine verknüpfte Dashboard-Sitzung, ohne den Prompt der Karte zu senden oder die Karte zu verschieben, für manuelle Arbeiten, die mit dem Board verknüpft bleiben.

Autonome Starts verwenden den aufgabenverfolgten Agent-Laufpfad des Gateways (Standard-Agent und -Modell, sofern Codex/Claude nicht ausdrücklich ausgewählt wurde). Workboard verknüpft anschließend die resultierende Aufgabe, die Lauf-ID und den Sitzungsschlüssel wieder mit der Karte. Jede verknüpfte Ausführung zeichnet außerdem eine Zusammenfassung des Versuchs auf (Engine, Modus, Modell, Lauf-ID, Zeitstempel, Status, fortlaufende Fehleranzahl), damit wiederholte Fehler sichtbar bleiben.

Das Dashboard aktualisiert den Aufgabenstatus aus dem Aufgabenverzeichnis des Gateways und ordnet Aufgaben anhand der Aufgaben-ID, Lauf-ID oder des verknüpften Sitzungsschlüssels den Karten zu. Eine in der Warteschlange befindliche oder laufende Aufgabe hält den Lebenszyklus der Karte aktiv; eine abgeschlossene, fehlgeschlagene, wegen Zeitüberschreitung beendete oder abgebrochene Aufgabe verschiebt die Karte gemäß derselben Synchronisierungsregel wie verknüpfte Sitzungen in Richtung review oder blocked (siehe Synchronisierung des Sitzungslebenszyklus).

Agent-Tools

Beanspruchte Karten lehnen Agent-Tool-Mutationen anderer Agents ab, sofern der Aufrufer nicht über das von workboard_claim zurückgegebene Anspruchstoken verfügt. Bei jeder Karte, die von einem Agent-Tool oder Gateway-RPC-Aufruf zurückgegeben wird, ist metadata.claim.token als [redacted] unkenntlich gemacht (das Token selbst wird genau einmal auf oberster Ebene und nur von workboard_claim zurückgegeben), sodass Dashboard-Bediener und andere Agents den Anspruchsstatus prüfen können, ohne jemals ein verwendbares Token zu sehen. Die Wiederherstellung erfolgt über workboard_promote/workboard_reassign/workboard_reclaim, wofür das Token nicht erforderlich ist.

Dispatch

Dispatch erfolgt lokal im Gateway: Dabei werden keine beliebigen Betriebssystemprozesse gestartet. Die normalen OpenClaw-Subagent-Sitzungen übernehmen weiterhin die Ausführung. Ein Dispatch-Durchlauf:

1. Stuft Karten hoch, deren Abhängigkeiten erfüllt sind.
2. Zeichnet Dispatch-Metadaten auf bereiten Karten auf.
3. Blockiert abgelaufene Ansprüche oder Läufe mit Zeitüberschreitung.
4. Markiert anhand der Board-Konfiguration Triage-Karten als Orchestrierungskandidaten.
5. Beansprucht einen kleinen Stapel bereiter Karten und startet Worker-Läufe über die Subagent-Laufzeit des Gateways.

Worker erhalten begrenzten Kartenkontext sowie das Anspruchstoken, das erforderlich ist, um über die Workboard-Tools einen Heartbeat zu senden oder die Karte abzuschließen beziehungsweise zu blockieren.

Worker-Auswahl

Jeder Durchlauf startet standardmäßig höchstens 3 Worker. Bereite Karten werden nach Priorität, dann nach Position und anschließend nach Erstellungszeit sortiert. Ein Durchlauf startet nur eine Karte pro Besitzer/Agent und überspringt Besitzer, die bereits laufende oder zur Prüfung anstehende Arbeit auf dem Board haben. Archivierte Karten, Karten mit einem aktiven Anspruch und Karten, deren Status nicht ready ist, werden niemals zum Starten von Workern ausgewählt (sie können jedoch weiterhin von der Datenseite des Dispatch betroffen sein: Bereinigung veralteter Ansprüche, Hochstufung von Abhängigkeiten, Bereinigung von Zeitüberschreitungen).

Sitzungsschlüssel sind pro Board/Karte deterministisch, sodass wiederholte Dispatches zurück zur selben Worker-Spur geleitet werden, anstatt unabhängige Sitzungen zu erstellen:

• Zugewiesene Karten: agent:<agentId>:subagent:workboard-<boardId>-<cardId>
• Nicht zugewiesene Karten: subagent:workboard-<boardId>-<cardId> (das Gateway ermittelt den konfigurierten Standard-Agent)

Wenn ein Worker nach dem Beanspruchen einer Karte nicht gestartet werden kann, blockiert Workboard die Karte, löscht den Anspruch, zeichnet den Fehler beim Starten des Laufs auf und fügt eine Worker-Protokollzeile hinzu – sichtbar im Dashboard, im CLI-JSON, in Agent-Tools und in der Kartendiagnose.

Einstiegspunkte

• Dispatch-Aktion im Dashboard
• openclaw workboard dispatch
• /workboard dispatch in einem befehlsfähigen Kanal

Alle drei verwenden die Subagent-Laufzeit des Gateways, wenn das Gateway verfügbar ist. Die CLI verfügt über genau eine Bediener-Ausweichlösung: Wenn der Gateway-Aufruf aufgrund eines Verbindungs-/Nichtverfügbarkeitsfehlers fehlschlägt (oder bei älteren Gateways aufgrund eines unknown method-Fehlers) und weder ein explizites --url-/--token-Ziel noch ein konfiguriertes Remote-Gateway (OPENCLAW_GATEWAY_URL oder gateway.mode: remote) zutrifft, führt die CLI einen rein datenbezogenen Dispatch mit dem lokalen SQLite-Status aus – sie kann Abhängigkeiten hochstufen, veraltete Ansprüche bereinigen und Läufe mit Zeitüberschreitung blockieren, aber keine Worker starten. Authentifizierungs-, Berechtigungs- und Validierungsfehler eines erreichbaren Gateways werden nicht als Nichtverfügbarkeit behandelt; sie werden als Befehlsfehler ausgegeben. Dasselbe gilt für jeden Gateway-Fehler, wenn ein explizites --url-/--token-Ziel angegeben wurde.

Board-Metadaten können autoDecompose, autoDecomposePerDispatch, defaultAssignee und orchestratorProfile festlegen. OpenClaw zeichnet diese Absicht auf und stellt sie im Worker-Kontext bereit; die eigentliche Spezifikation/Zerlegung erfolgt weiterhin über die normalen Workboard-Tools.

CLI und Slash-Befehl

openclaw workboard list [--board <id>] [--status <status>] [--include-archived] [--json]openclaw workboard create "Veralteten Kartenlebenszyklus korrigieren" --priority high --labels bug,workboardopenclaw workboard show <card-id> [--json]openclaw workboard dispatch [--board <id>] [--json]

Die Textausgabe von list blendet archivierte Karten standardmäßig aus (--include-archived setzt dies außer Kraft); --json enthält immer archivierte Karten und entspricht damit dem von vorhandenen Skripten verwendeten Vertrag für vollständige Karten. show akzeptiert ein eindeutiges ID-Präfix. list, create und show lesen beziehungsweise schreiben den lokalen Plugin-Status immer direkt. Nur dispatch ruft das laufende Gateway auf, mit der oben beschriebenen Ausweichlösung.

Vollständige Flags, JSON-Ausgabe, Gateway-Ausweichverhalten, Behandlung von ID-Präfixen, Dispatch-Auswahlregeln und Fehlerbehebung finden Sie unter Workboard-CLI.

/workboard list, /workboard show <card-id>, /workboard create <title> und /workboard dispatch entsprechen der CLI. Auflisten und Anzeigen sind Lesevorgänge für alle autorisierten Befehlsabsender. Erstellen und Dispatch erfordern auf Chat-Oberflächen den Besitzerstatus oder einen Gateway-Client mit operator.write/operator.admin.

Synchronisierung des Sitzungslebenszyklus

Karten können mit einer bestehenden Dashboard-Sitzung oder mit einer Sitzung verknüpft werden, die erstellt wird, wenn Sie die Arbeit über die Karte starten. Verknüpfte Karten zeigen den Sitzungslebenszyklus direkt an: laufend, veraltet, verknüpft und inaktiv, abgeschlossen, fehlgeschlagen oder nicht vorhanden. Sie können auch eine bestehende Sitzung auf der Registerkarte Sessions mit Add to Workboard erfassen; die Karte wird mit dieser Sitzung verknüpft, verwendet die Sitzungsbezeichnung oder die letzte Benutzereingabe als Titel und übernimmt als Notizen die letzte Benutzereingabe sowie die neueste Assistentenantwort, sofern verfügbar.

Wenn die verknüpfte Sitzung nicht mehr vorhanden ist, bleibt die Karte für den Kontext verknüpft und bietet weiterhin Steuerelemente zum Starten, um mit einer neuen Sitzung neu zu beginnen. Wenn eine aktive verknüpfte Sitzung keine aktuelle Aktivität mehr meldet, markiert Workboard die Karte als stale und speichert dies als Metadaten, bis der Lebenszyklus die Markierung aufhebt.

Während sich eine Karte in einem aktiven Arbeitsstatus befindet, folgt Workboard der verknüpften Sitzung:

Manuelle Prüfstatus haben Vorrang. Wenn Sie eine Karte nach review, blocked oder done verschieben, wird die automatische Synchronisierung für diese Karte beendet, bis Sie sie wieder nach todo oder running verschieben.

Beim Starten einer Karte werden normale Gateway-Sitzungen verwendet; Workboard speichert lediglich Kartenmetadaten und Verknüpfungen. Gesprächsprotokoll, Modellauswahl und Ausführungslebenszyklus bleiben Eigentum des regulären Sitzungssystems. Verwenden Sie Stop auf einer aktiven verknüpften Karte, um die aktive Ausführung abzubrechen – Workboard markiert diese Karte als blocked, damit sie für die Nachverfolgung sichtbar bleibt.

Neue Karten können aus Workboard-Vorlagen (bugfix, docs, release, pr_review, plugin) erstellt werden. Vorlagen füllen Titel, Notizen, Bezeichnungen und Priorität vorab aus; die Vorlagen-ID wird als Kartenmetadaten gespeichert.

Dashboard-Arbeitsablauf

1. Öffnen Sie die Registerkarte Workboard in der Control UI.
2. Erstellen Sie eine Karte mit Titel, Notizen, Priorität, Bezeichnungen, optionalem Agenten und optionaler verknüpfter Sitzung – oder öffnen Sie Sessions und wählen Sie für eine bestehende Sitzung Add to Workboard.
3. Ziehen Sie die Karte zwischen den Spalten oder fokussieren Sie ihre kompakte Statussteuerung und verwenden Sie das Menü oder ArrowLeft/ArrowRight.
4. Starten Sie die Arbeit über die Karte, um eine Dashboard-Sitzung zu erstellen oder wiederzuverwenden.
5. Öffnen Sie die verknüpfte Sitzung über die Karte, während der Agent arbeitet.
6. Lassen Sie die Lebenszyklussynchronisierung laufende Arbeit nach review/blocked verschieben und verschieben Sie die Karte anschließend manuell nach done, wenn sie akzeptiert wurde.

Diagnose

Diagnosen werden aus lokalen Kartenmetadaten berechnet. Integrierte Prüfungen kennzeichnen:

Berechtigungen

Gateway-RPC-Methoden befinden sich unter workboard.*:

Keine RPC-Methode erfordert operator.admin. Browser, die mit schreibgeschütztem Operatorzugriff verbunden sind, können das Board einsehen, aber keine Karten ändern.

Speicherung

Workboard speichert dauerhafte Daten in einer Plugin-eigenen relationalen SQLite-Datenbank im OpenClaw-Statusverzeichnis: Boards, Karten, Bezeichnungen, Lebenszyklusereignisse, Ausführungsversuche, Kommentare, Abhängigkeitsverknüpfungen, Nachweise, Artefaktreferenzen, Anhangsmetadaten und -blobs, Diagnosen, Benachrichtigungen, Worker-Protokolle, Protokollstatus und Abonnements befinden sich sämtlich in Workboard-Tabellen (nicht in Plugin-Schlüssel-Wert-Einträgen). Ein Kartenexport bewahrt den Ablauf des Boards, ohne die Blob-Inhalte von Anhängen einzubetten.

Installationen, die Workboard in der Version .28 verwendet haben, können openclaw doctor --fix ausführen, um die ausgelieferten älteren Plugin-Statusnamensräume (workboard.cards, workboard.boards, workboard.notify und, sofern vorhanden, workboard.attachments) in die relationale Datenbank zu migrieren.

Fehlerbehebung

Die Registerkarte meldet, dass Workboard nicht verfügbar ist

openclaw plugins inspect workboard --runtime --json

Wenn plugins.allow konfiguriert ist, fügen Sie workboard hinzu. Wenn plugins.deny workboard enthält, entfernen Sie es, bevor Sie das Plugin aktivieren.

Karten werden nicht gespeichert

Stellen Sie sicher, dass die Browserverbindung über operator.write-Zugriff verfügt. Schreibgeschützte Operator- sitzungen können Karten auflisten, sie jedoch nicht erstellen, bearbeiten, verschieben oder löschen.

Beim Starten einer Karte wird nicht die erwartete Sitzung geöffnet

Prüfen Sie die Agenten-ID und die verknüpfte Sitzung der Karte und öffnen Sie anschließend Sessions oder Chat, um den tatsächlichen Ausführungsstatus zu prüfen.

Beim Dispatch wird kein Worker gestartet

Stellen Sie sicher, dass mindestens eine Karte mit Status ready ohne aktiven Anspruch vorhanden ist:

openclaw workboard list --status ready

Wenn die CLI einen reinen Daten-Dispatch meldet, starten Sie den Gateway oder starten Sie ihn neu und versuchen Sie es erneut – ein reiner Daten-Dispatch aktualisiert den lokalen Board-Status, kann jedoch keine Subagent-Worker-Ausführungen starten. Karten können auch übersprungen werden, wenn eine andere Karte für denselben Eigentümer oder Agenten bereits ausgeführt wird oder auf eine Prüfung wartet; schließen Sie diese aktive Arbeit ab, blockieren Sie sie oder geben Sie sie frei, bevor Sie weitere Arbeit für denselben Eigentümer dispatchen.

Verwandte Themen

• Control UI
• Workboard-CLI
• Plugins
• Plugins verwalten
• Sitzungen