Workboard-Plugin

Das Workboard-Plugin fügt dem Control UI ein optionales Board im Kanban-Stil hinzu: Arbeitskarten in Agentengröße, Zuweisung zu Agenten und einen Link zurück zur Aufgabe, zum Lauf und zur Dashboard-Sitzung der Karte.

Workboard ist bewusst klein gehalten: Es verfolgt lokale Betriebsarbeit für ein OpenClaw Gateway. Es ersetzt weder GitHub Issues, Linear, Jira noch andere Projektmanagementsysteme für Teams.

Aktivierung

Workboard ist enthalten, aber standardmäßig deaktiviert:

1. Öffnen Sie Plugins im Control UI oder verwenden Sie /settings/plugins relativ zum konfigurierten Basispfad des Control UI. Beispielsweise verwendet ein Basispfad von /openclaw den Pfad /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 Benutzeroberfläche meldet, dass ein Neustart erforderlich ist, starten Sie das Gateway neu.

Die Registerkarte „Workboard“ erscheint in der Dashboard-Navigation, nachdem die Plugin-Laufzeit geladen wurde. Solange es deaktiviert ist, bleibt die Registerkarte in der Navigation ausgeblendet. Wenn die Route /workboard direkt geöffnet wird, während das Plugin deaktiviert oder durch plugins.allow/plugins.deny blockiert ist, wird anstelle der Kartendaten ein Zustand angezeigt, der auf die Nichtverfügbarkeit des Plugins hinweist.

Der entsprechende CLI-Ablauf lautet:

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Konfiguration

Workboard besitzt keine Plugin-spezifische Konfiguration. Aktivieren oder deaktivieren Sie es über den 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, Worker-Protokollstatus, Ansprüchen, Diagnosen, Benachrichtigungen, Vorlagen-ID, Archivstatus und 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 ein Operator nachvollziehen, wie sich eine Karte durch das Board bewegt hat, ohne die verknüpfte Sitzung zu öffnen. Sie bilden lokalen Betriebskontext ab und ersetzen weder Sitzungstranskripte noch den Verlauf eines GitHub-Issues.

Das Plugin und das Control UI verwenden denselben Workboard-Kartenvertrag. Dashboard-Aktualisierungen bewahren daher die Herkunft und Autorität des Arbeitsbereichs, den Anspruchsstatus, Diagnoseaktionen und Sequenznummern von Benachrichtigungen, anstatt eine kleinere, ausschließlich für die Benutzeroberfläche bestimmte Kopie der Karte zu projizieren. Unbekannte Diagnosearten, Diagnoseschweregrade und Benachrichtigungsarten werden ignoriert, bis beide Oberflächen sie unterstützen; sie werden niemals in einen anderen gültigen Zustand umgeschrieben.

Das geöffnete Dashboard wird durch plugin.workboard.changed-Invalidierungen aktualisiert. Jedes Ereignis enthält nur eine Store-Epoche und Revision; die Benutzeroberfläche liest anschließend die kanonischen Karten über den normalen operator.read-RPC erneut ein. Mehrere Revisionen werden zu einem einzigen nachfolgenden Lesevorgang zusammengefasst. Workboard verschiebt diesen Lesevorgang, während eine Karte gezogen, bearbeitet oder geschrieben wird, und setzt ihn fort, nachdem die lokale Interaktion abgeschlossen ist. Bei einer erneuten Verbindung erfolgt immer ein kanonisches Neuladen. Es gibt keine routinemäßige Abfrage aller Karten, und Aktualisieren bleibt als manuelle Wiederherstellungsoption verfügbar.

Wenn mehr als ein Board vorhanden ist, enthält die Symbolleiste einen Board-Filter, der auf persistierten Board-Metadaten statt nur auf den derzeit sichtbaren Karten basiert. Leere und archivierte Boards bleiben daher auswählbar. Karten ohne explizite Board-ID gehören zum kanonischen Board default. Jedes Board besitzt eine kanonische Seite /workboard/<boardId>, die als Lesezeichen gespeichert, geteilt oder in der Seitenleiste angeheftet werden kann. Die zuvor ausgelieferte Form /workboard?board=<boardId> bleibt als Kompatibilitätsalias bestehen und leitet unter Beibehaltung anderer Abfrageparameter auf diese Seite weiter. Durch Auswahl von Alle Boards kehren Sie zu /workboard zurück.

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

Arbeit von einer Karte aus starten

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

• Codex ausführen / Claude ausführen startet mit einer expliziten Engine einen aufgabenverfolgten Agentenlauf, sendet den Prompt der Karte und markiert die Karte als 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 Arbeit, die mit dem Board verknüpft bleibt.

Autonome Starts verwenden den Pfad des Gateways für aufgabenverfolgte Agentenläufe (standardmäßig Agent und Modell, sofern Codex/Claude nicht ausdrücklich ausgewählt wird); Workboard verknüpft anschließend die resultierende Aufgabe, Lauf-ID und den Sitzungsschlüssel mit der Karte. Jede verknüpfte Ausführung zeichnet außerdem eine Versuchszusammenfassung auf (Engine, Modus, Modell, Lauf-ID, Zeitstempel, Status, fortlaufende Fehleranzahl), sodass wiederholte Fehler sichtbar bleiben.

Das Dashboard aktualisiert den Aufgabenstatus aus dem Aufgabenjournal 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 bei verknüpften Sitzungen in Richtung review oder blocked (siehe Synchronisierung des Sitzungslebenszyklus).

Agentenwerkzeuge

Nachweisstatus sind von Workern gemeldete Ergebnisse, keine unabhängige Überprüfung. Ein Eintrag passed bedeutet, dass der Worker den Erfolg seines Befehls oder seiner Prüfung meldet; Verbraucher, die ein unabhängiges Qualitätstor benötigen, sollten den angehängten Befehl, die URL oder das Artefakt prüfen und eine eigene Verifizierung ausführen. workboard_proof gibt die proofId des neuen Datensatzes zurück. Wenn workboard_complete den endgültigen Status desselben Nachweises meldet, übergeben Sie proofId, damit der ausstehende Datensatz an Ort und Stelle aufgelöst wird, ohne seine Identität oder seinen Zeitstempel zu verlieren. Ein Nachweis, der bereits denselben endgültigen Status hat, wird unverändert wiederverwendet. Abschlussnachweise ohne proofId bleiben nur anhängbar, sodass ein späterer Wiederholungsversuch den älteren Verlauf nicht allein deshalb überschreiben kann, weil sein Befehl oder seine Notiz identisch ist.

Beanspruchte Karten lehnen Mutationen durch Agent-Tools anderer Agents ab, sofern der Aufrufer nicht über das von workboard_claim zurückgegebene Anspruchstoken verfügt. Jede von einem Agent-Tool oder Gateway-RPC-Aufruf zurückgegebene Karte schwärzt metadata.claim.token zu [redacted] (das Token selbst wird nur einmal auf oberster Ebene und ausschließlich 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

Der Dispatch ist Gateway-lokal: Er startet keine beliebigen Betriebssystemprozesse. Die normalen OpenClaw-Subagent-Sitzungen sind weiterhin für die Ausführung zuständig. Ein Dispatch-Durchlauf:

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

Worker erhalten begrenzten Kartenkontext sowie das Anspruchstoken, das benötigt wird, um über die Workboard-Tools einen Heartbeat zu senden und die Karte abzuschließen oder zu blockieren.

Workspace-Pfade richten sich nach den bestehenden Dateisystemberechtigungen des Aufrufers. Gateway- Clients mit operator.write können konfigurierte Agent-Workspaces verwenden; operator.admin-Clients können andere Host-Checkouts verwenden. Agent-Tools in einer Sandbox nutzen den Workspace-Zugriff ihrer Sandbox, während nicht in einer Sandbox ausgeführte, auf den Workspace beschränkte Tools ihren konfigurierten Workspace-Stamm verwenden. Workboard zeichnet diese Berechtigung auf, wenn ein Workspace zugewiesen wird, und bildet beim Dispatch erneut die Schnittmenge mit den aktuellen Berechtigungen des Aufrufers, sodass eine persistierte Karte den Zugriff eines späteren Aufrufers nicht erweitern kann. Bei älteren Karten mit einem expliziten Host-Workspace, aber ohne aufgezeichnete Berechtigung muss dieser Workspace vor einem Full-Host-Dispatch erneut gespeichert werden; Karten ohne Host-Pfad übernehmen beim ersten Dispatch die aktuellen Berechtigungen des Aufrufers.

Workspace-gebundener Dispatch akzeptiert ein Verzeichnis oder Git-Checkout nur, wenn dessen Repository-Stamm genau mit dem Ziel-Workspace des Agents übereinstimmt. Eine Worktree-Anforderung wird auf dieses Verzeichnis eingegrenzt und als Verzeichnis-Workspace persistiert, sodass der Host weder den Checkout materialisiert noch Repository-Einrichtungscode ausführt. Der Ziel-Worker muss eine beschreibbare, nicht gemeinsam genutzte Docker-Sandbox für genau diesen Workspace verwenden, ohne Ausführung mit erhöhten Berechtigungen, persistierte Host-/Node-Exec-Überschreibungen oder nicht klassifizierte Plugin- und MCP-Tools. Workboard listet seine registrierten Tools auf, anstatt einem workboard_*-Präfix zu vertrauen, und der Dispatch lehnt einen laufenden Docker- Container ab, dessen Live-Mount-/Konfigurationshash veraltet ist. Der Dispatch meldet die inkompatible Zielrichtlinie, anstatt einen weniger streng eingeschränkten Worker zu starten. Ein Full-Host-Dispatch kann andere lokale Checkouts als Ziel verwenden und behält die normale verwaltete Worktree-Einrichtung bei.

Workspace-Berechtigungen erzeugen kein zweites Berechtigungsmodell für den Kartenlebenszyklus. Aufrufer, die Workboard-Karten verändern dürfen, können sie auf jeder Oberfläche manuell durch dieselben Status verschieben; schreibgeschützter Workspace-Zugriff verhindert lediglich Worker- Dispatches, die Schreibzugriff benötigen.

Worker-Auswahl

Jeder Durchlauf startet standardmäßig höchstens 3 Worker. Bereite Karten werden nach Priorität, dann Position und anschließend Erstellungszeit sortiert. Ein Durchlauf startet nur eine Karte pro Eigentümer/Agent und überspringt Eigentümer, für die bereits laufende oder zu prüfende Arbeit auf dem Board vorhanden ist. Archivierte Karten, Karten mit einem aktiven Claim und Karten, die sich nicht im Status ready befinden, werden niemals für Worker-Starts ausgewählt (sie können weiterhin von der Datenseite des Dispatch betroffen sein: Bereinigung veralteter Claims, Hochstufung von Abhängigkeiten, Timeout- Bereinigung).

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

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

Wenn ein Worker nach dem Claim einer Karte nicht gestartet werden kann, blockiert Workboard die Karte, löscht den Claim, zeichnet den Fehler beim Start des Durchlaufs auf und fügt eine Worker- Protokollzeile hinzu – sichtbar im Dashboard, in CLI-JSON, Agenten-Tools und der Karten- diagnose.

Einstiegspunkte

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

Alle drei verwenden die Subagent-Laufzeit des Gateway, wenn das Gateway verfügbar ist. Die CLI verfügt über genau einen Operator-Fallback: Wenn der Gateway-Aufruf mit einem Verbindungs-/Nichtverfügbarkeitsfehler fehlschlägt (oder bei älteren Gateways mit einem unknown method-Fehler) und weder ein explizites Ziel --url/--token noch ein konfiguriertes entferntes Gateway (OPENCLAW_GATEWAY_URL oder gateway.mode: remote) gilt, führt die CLI einen rein datenbezogenen Dispatch für den lokalen SQLite-Status aus – sie kann Abhängigkeiten hochstufen, veraltete Claims bereinigen und Durchläufe mit Zeitüberschreitung blockieren, aber keine Worker starten. Authentifizierungs-, Berechtigungs- und Validierungsfehler eines erreichbaren Gateway werden nicht als Nichtverfügbarkeit behandelt; sie werden als Befehlsfehler ausgegeben, ebenso jeder Gateway- Fehler, wenn ein explizites Ziel --url/--token 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 "Fix stale card lifecycle" --priority high --labels bug,workboardopenclaw workboard show <card-id> [--json]openclaw workboard move <card-id> --status <status> [--json]openclaw workboard dispatch [--board <id>] [--json]

Die Textausgabe von list blendet archivierte Karten standardmäßig aus (--include-archived überschreibt dies); --json schließt archivierte Karten immer ein, entsprechend dem vollständigen Karten- Vertrag, den vorhandene Skripte verwenden. show und move akzeptieren ein eindeutiges ID- Präfix. list, create, show und move lesen/schreiben den lokalen Plugin- Status immer direkt. Nur dispatch ruft das laufende Gateway auf, mit dem oben beschriebenen Fallback.

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

/workboard list, /workboard show <card-id>, /workboard create <title>, /workboard move <card-id> --status <status> und /workboard dispatch entsprechen der CLI. Auflisten und Anzeigen sind Lesevorgänge für jeden autorisierten Befehlsabsender. Erstellen, Verschieben und Dispatch erfordern auf Chat-Oberflächen den Eigentümerstatus oder einen Gateway- Client mit operator.write/operator.admin. Manuelle Operator-Verschiebungen verwenden dasselbe Verhalten zum Überschreiben von Claims wie Drag-and-drop im Dashboard. Der Worktree-Zugriff folgt weiterhin derselben oben beschriebenen Workspace-Grenze.

Synchronisierung des Sitzungslebenszyklus

Karten können mit einer vorhandenen Dashboard-Sitzung oder einer beim Arbeitsstart von der Karte erstellten Sitzung verknüpft werden. Verknüpfte Karten zeigen den Sitzungslebenszyklus direkt an: laufend, veraltet, verknüpft und inaktiv, abgeschlossen, fehlgeschlagen oder nicht vorhanden. Sie können auch eine vorhandene 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 füllt die Notizen, sofern verfügbar, mit der letzten Benutzereingabe sowie der neuesten Assistentenantwort vorab aus.

Wenn die verknüpfte Sitzung nicht mehr vorhanden ist, bleibt die Karte als Kontext verknüpft und bietet weiterhin Startsteuerelemente, um sie in einer neuen Sitzung neu zu starten. Wenn eine aktive verknüpfte Sitzung keine aktuellen Aktivitäten mehr meldet, markiert Workboard die Karte als stale und speichert dies als Metadaten, bis der Lebenszyklus es löscht.

Solange 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 zurück nach todo oder running verschieben.

Beim Starten einer Karte werden normale Gateway-Sitzungen verwendet; Workboard speichert nur Karten- Metadaten und Verknüpfungen. Gesprächstranskript, Modellauswahl und Durchlauf- Lebenszyklus verbleiben im Besitz des regulären Sitzungssystems. Verwenden Sie Stop auf einer aktiven verknüpften Karte, um den aktiven Durchlauf abzubrechen – Workboard markiert diese Karte als blocked, sodass sie für Folgemaßnahmen sichtbar bleibt.

Neue Karten können aus Workboard-Vorlagen gestartet werden (bugfix, docs, release, pr_review, plugin). 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 Add to Workboard für eine vorhandene Sitzung.
3. Ziehen Sie die Karte zwischen Spalten oder fokussieren Sie das kompakte Statussteuerelement und verwenden Sie das Menü oder ArrowLeft/ArrowRight. Während des Ziehens wird die Quellkarte abgeblendet und verfügbare Zielspalten erhalten eine Umrandung.
4. Starten Sie die Arbeit von der Karte aus, um eine Dashboard-Sitzung zu erstellen oder wiederzuverwenden.
5. Öffnen Sie während der Arbeit des Agenten die verknüpfte Sitzung über die Karte.
6. Lassen Sie die Lebenszyklus-Synchronisierung laufende Arbeit nach review/blocked verschieben und verschieben Sie die Karte nach der Annahme manuell nach done.

Widgets für Sitzungs-Boards

Workboard enthält zwei native Widgets für Sitzungs-Dashboards (siehe Dashboards). Der Agent heftet sie mit seinem dashboard-Tool unter Verwendung von content: { kind: "plugin", pluginKind, props } an, und sie werden als integrierte Benutzeroberfläche mit Live-Daten dargestellt – ohne Sandbox-Frame oder Funktionsfreigabe:

• workboard:card mit props: { cardId } zeigt eine Karte mit ihrem Status- Steuerelement, ihrer Priorität und dem zugewiesenen Agenten.
• workboard:mini mit optionalem props: { boardId, limit } zeigt Anzahlen pro Status sowie die wichtigsten bereiten/laufenden Karten und verlinkt auf die vollständige Board-Seite. Ohne boardId werden alle Boards zusammengefasst; mit boardId wird der Umfang auf dieses Board beschränkt (Karten, die ohne explizite Board-ID erstellt wurden, befinden sich auf default).

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 Operator-Zugriff verbunden sind, können das Board prüfen, aber keine Karten ändern. Ein Admin-Umfang erweitert die akzeptierten Workboard-Hostpfade; er ändert nicht die verfügbaren Methoden.

Speicher

Workboard speichert dauerhafte Daten in einer Plugin-eigenen relationalen SQLite-Datenbank im OpenClaw-Statusverzeichnis: Boards, Karten, Bezeichnungen, Lebenszyklusereignisse, Durchlaufversuche, Kommentare, Abhängigkeitsverknüpfungen, Nachweise, Artefaktreferenzen, Anhangsmetadaten und -blobs, Diagnosen, Benachrichtigungen, Worker-Protokolle, Protokollstatus und Abonnements befinden sich alle in Workboard-Tabellen (nicht in Plugin-Schlüssel-Wert-Einträgen). Ein Kartenexport erhält die Board-Darstellung, 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 veralteten Plugin-Status-Namespaces (workboard.cards, workboard.boards, workboard.notify und, falls 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, aber 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 Durchlaufstatus zu prüfen.

Dispatch startet keinen Worker

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

openclaw workboard list --status ready

Wenn die CLI eine reine Datenverarbeitung meldet, starten Sie den Gateway oder starten Sie ihn neu und versuchen Sie es erneut – die reine Datenverarbeitung aktualisiert den lokalen Workboard-Status, kann jedoch keine Subagent-Worker-Läufe starten. Karten können auch übersprungen werden, wenn eine andere Karte für denselben Verantwortlichen oder Agenten bereits ausgeführt wird oder auf eine Überprüfung wartet. Schließen Sie diese aktive Arbeit ab, blockieren Sie sie oder geben Sie sie frei, bevor Sie weitere Aufgaben für denselben Verantwortlichen verteilen.

Verwandte Themen

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