Skip to main content
Le plugin Workboard ajoute un tableau facultatif de style Kanban à la Control UI : des cartes de travail dimensionnées pour les agents, l’affectation aux agents et un lien vers la tâche, l’exécution et la session du tableau de bord de la carte. Workboard est volontairement minimaliste : il suit le travail opérationnel local d’un Gateway OpenClaw. Il ne remplace pas GitHub Issues, Linear, Jira ni d’autres systèmes de gestion de projet d’équipe.

​
L’activer

Workboard est inclus, mais désactivé par défaut :
  1. Ouvrez Plugins dans la Control UI, ou utilisez /settings/plugins par rapport au chemin de base configuré de la Control UI. Par exemple, un chemin de base /openclaw utilise /openclaw/settings/plugins.
  2. Recherchez Workboard et choisissez Enable. Comme Workboard est inclus avec OpenClaw, aucune action Install n’est nécessaire.
  3. Si l’interface indique qu’un redémarrage est requis, redémarrez le Gateway.
L’onglet Workboard apparaît dans la navigation du tableau de bord après le chargement de l’environnement d’exécution du plugin. Lorsqu’il est désactivé, l’onglet reste masqué dans la navigation. L’ouverture directe de la route /workboard lorsque le plugin est désactivé ou bloqué par plugins.allow/plugins.deny affiche un état indiquant que le plugin est indisponible au lieu des données des cartes. Le flux de travail CLI équivalent est le suivant :

​
Configuration

Workboard ne possède aucune configuration propre au plugin. Activez-le ou désactivez-le avec l’entrée de plugin standard :

​
Champs des cartes

Les cartes contiennent également des métadonnées compactes sur les tentatives, les commentaires, les liens, les preuves, les artefacts, les paramètres d’automatisation, les pièces jointes, les journaux des workers, l’état du protocole des workers, les revendications, les diagnostics, les notifications, l’identifiant du modèle, l’état d’archivage et la détection des sessions obsolètes, ainsi qu’une liste des événements récents (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). Ces métadonnées permettent à un opérateur de voir comment une carte s’est déplacée dans le tableau sans ouvrir la session liée ; il s’agit d’un contexte opérationnel local, et non d’un remplacement des transcriptions de session ou de l’historique des tickets GitHub. Le plugin et la Control UI utilisent un contrat de carte Workboard unique. Les actualisations du tableau de bord préservent donc la provenance et l’autorité de l’espace de travail, l’état des revendications, les actions de diagnostic et les numéros de séquence des notifications, au lieu de projeter une copie plus petite de la carte destinée uniquement à l’interface. Les types de diagnostics, les niveaux de gravité des diagnostics et les types de notifications inconnus sont ignorés jusqu’à ce que les deux surfaces les prennent en charge ; ils ne sont jamais réécrits sous la forme d’un autre état valide. Le tableau de bord ouvert se met à jour à partir des invalidations plugin.workboard.changed. Chaque événement ne contient qu’une époque et une révision du stockage ; l’interface relit ensuite les cartes canoniques au moyen du RPC operator.read normal. Plusieurs révisions sont regroupées en une seule relecture ultérieure. Workboard diffère cette lecture lorsqu’une carte est en cours de déplacement, de modification ou d’écriture, puis la reprend une fois l’interaction locale terminée. Une reconnexion déclenche toujours un rechargement canonique. Il n’existe aucune interrogation régulière de toutes les cartes, et Refresh reste disponible comme mécanisme de récupération manuelle. Lorsque plusieurs tableaux existent, la barre d’outils comprend un filtre Board reposant sur les métadonnées persistantes des tableaux plutôt que sur les seules cartes actuellement visibles. Les tableaux vides et archivés restent donc sélectionnables. Les cartes sans identifiant de tableau explicite appartiennent au tableau canonique default. Le tableau sélectionné est stocké dans le paramètre de requête ?board=, de sorte que l’URL Workboard filtrée peut être ajoutée aux favoris ou partagée ; le choix de All boards supprime le paramètre. Les cartes sont stockées dans l’état Gateway propre au plugin et sont déplacées avec le reste de l’état OpenClaw de ce Gateway (voir Stockage).

​
Démarrer un travail depuis une carte

Les cartes non liées peuvent démarrer directement un travail :
  • Run Codex / Run Claude démarre une exécution d’agent suivie comme tâche avec un moteur explicite, envoie l’invite de la carte et marque la carte running. Les exécutions Codex utilisent openai/gpt-5.6-sol ; les exécutions Claude utilisent anthropic/claude-sonnet-4-6.
  • Open Codex / Open Claude crée une session liée dans le tableau de bord sans envoyer l’invite de la carte ni déplacer celle-ci, pour un travail manuel qui reste rattaché au tableau.
Les démarrages autonomes utilisent le chemin d’exécution d’agent suivie comme tâche du Gateway (agent et modèle par défaut, sauf si Codex/Claude est choisi explicitement) ; Workboard lie ensuite la tâche résultante, l’identifiant d’exécution et la clé de session à la carte. Chaque exécution liée enregistre également un résumé de tentative (moteur, mode, modèle, identifiant d’exécution, horodatages, état, nombre cumulatif d’échecs) afin que les échecs répétés restent visibles. Le tableau de bord actualise l’état des tâches à partir du registre des tâches du Gateway, en associant les tâches aux cartes par identifiant de tâche, identifiant d’exécution ou clé de session liée. Une tâche en file d’attente ou en cours maintient le cycle de vie de la carte actif ; une tâche terminée, échouée, arrivée à expiration ou annulée déplace la carte vers review ou blocked selon la même règle de synchronisation que les sessions liées (voir Synchronisation du cycle de vie des sessions).

​
Outils des agents

Les cartes revendiquées refusent les mutations effectuées par les outils d’agent provenant d’autres agents, sauf si l’appelant détient le jeton de revendication renvoyé par workboard_claim. Chaque carte renvoyée par un outil d’agent ou un appel RPC du Gateway masque metadata.claim.token sous la forme [redacted] (le jeton lui-même n’est renvoyé qu’une seule fois, au niveau supérieur, uniquement par workboard_claim), afin que les opérateurs du tableau de bord et les autres agents puissent inspecter l’état de la revendication sans jamais voir de jeton utilisable. La récupération passe par workboard_promote/workboard_reassign/workboard_reclaim, qui ne nécessitent pas le jeton.

​
Répartition

La répartition est locale au Gateway : elle ne lance pas de processus arbitraires du système d’exploitation. Les sessions normales de sous-agents OpenClaw restent responsables de l’exécution. Une passe de répartition :
  1. Promeut les cartes dont les dépendances sont prêtes.
  2. Enregistre les métadonnées de répartition sur les cartes prêtes.
  3. Bloque les revendications expirées ou les exécutions ayant dépassé le délai imparti.
  4. Marque les cartes de triage configurées dans le tableau comme candidates à l’orchestration.
  5. Revendique un petit lot de cartes prêtes et démarre les exécutions des agents via l’environnement d’exécution des sous-agents du Gateway.
Les agents reçoivent un contexte de carte borné ainsi que le jeton de revendication nécessaire pour envoyer un Heartbeat, achever ou bloquer la carte au moyen des outils Workboard. Les chemins d’espace de travail respectent les autorisations existantes de l’appelant sur le système de fichiers. Les clients du Gateway avec operator.write peuvent utiliser les espaces de travail configurés des agents ; les clients operator.admin peuvent utiliser d’autres extractions de l’hôte. Les outils d’agent en bac à sable utilisent l’accès à l’espace de travail de leur bac à sable, tandis que les outils sans bac à sable limités à l’espace de travail utilisent leur racine d’espace de travail configurée. Workboard enregistre cette autorisation lorsqu’un espace de travail est assigné et la recoupe à nouveau avec l’autorisation actuelle de l’appelant lors de la répartition, afin qu’une carte persistante ne puisse pas élargir l’accès d’un appelant ultérieur. Les anciennes cartes ayant un espace de travail hôte explicite, mais aucune autorisation enregistrée, doivent avoir cet espace de travail réenregistré avant une répartition sur l’ensemble de l’hôte ; les cartes sans chemin d’hôte adoptent l’autorisation de l’appelant actuel lors de leur première répartition. La répartition liée à un espace de travail n’accepte un répertoire ou une extraction Git que si la racine de son dépôt correspond exactement à l’espace de travail de l’agent cible. Une demande d’arbre de travail est limitée à ce répertoire et conservée comme espace de travail de type répertoire, afin que l’hôte ne matérialise pas l’extraction et n’exécute pas le code de configuration du dépôt. L’ agent cible doit utiliser un bac à sable Docker accessible en écriture et non partagé pour cet espace de travail précis, sans exécution avec privilèges élevés, sans substitutions persistantes d’exécution sur l’hôte/Node, ni outils Plugin et MCP non classés. Workboard énumère ses outils enregistrés au lieu de faire confiance à un préfixe workboard_*, et la répartition refuse un conteneur Docker actif dont le hachage de montage/configuration en cours est obsolète. La répartition signale la politique cible incompatible au lieu de démarrer un agent moins confiné. La répartition sur l’ensemble de l’hôte peut cibler d’autres extractions locales et conserve la configuration normale des arbres de travail gérés. L’autorisation de l’espace de travail ne crée pas un second modèle d’autorisation pour le cycle de vie des cartes. Les appelants autorisés à modifier les cartes Workboard peuvent les faire passer manuellement par les mêmes états sur toutes les surfaces ; l’accès en lecture seule à l’espace de travail empêche uniquement la répartition d’agents nécessitant des droits d’écriture.

​
Sélection des agents

Chaque passe démarre au maximum 3 agents par défaut. Les cartes prêtes sont classées par priorité, puis par position, puis par date de création. Une passe ne démarre qu’une seule carte par propriétaire/agent et ignore les propriétaires qui ont déjà un travail en cours d’exécution ou en révision sur le tableau. Les cartes archivées, les cartes ayant une revendication active et les cartes qui ne sont pas à l’état ready ne sont jamais sélectionnées pour démarrer des agents (elles peuvent néanmoins être affectées par la partie données de la répartition : nettoyage des revendications obsolètes, promotion des dépendances, nettoyage des dépassements de délai). Les clés de session sont déterministes pour chaque tableau/carte, de sorte que les répartitions répétées sont redirigées vers la même file d’agent au lieu de créer des sessions sans lien :
  • Cartes assignées : agent:<agentId>:subagent:workboard-<boardId>-<cardId>
  • Cartes non assignées : subagent:workboard-<boardId>-<cardId> (le Gateway résout l’agent configuré par défaut)
Si un agent ne peut pas être démarré après la revendication d’une carte, Workboard bloque la carte, efface la revendication, enregistre l’échec du démarrage de l’exécution et ajoute une ligne au journal de l’agent, visible dans le tableau de bord, le JSON de la CLI, les outils d’agent et les diagnostics de la carte.

​
Points d’entrée

  • Action de répartition depuis le tableau de bord
  • openclaw workboard dispatch
  • /workboard dispatch sur un canal prenant en charge les commandes
Les trois utilisent l’environnement d’exécution de sous-agent du Gateway lorsque le Gateway est disponible. La CLI dispose d’une solution de repli pour l’opérateur : si l’appel au Gateway échoue avec une erreur de connexion ou d’indisponibilité (ou une erreur unknown method pour les anciens Gateways), qu’aucune cible explicite --url/--token ne s’applique et qu’aucun Gateway distant (OPENCLAW_GATEWAY_URL ou gateway.mode: remote) n’est configuré, la CLI exécute une répartition limitée aux données sur l’état SQLite local : elle peut promouvoir les dépendances, nettoyer les revendications obsolètes et bloquer les exécutions ayant expiré, mais ne peut pas démarrer de processus de travail. Les échecs d’authentification, d’autorisation et de validation provenant d’un Gateway accessible ne sont pas considérés comme des indisponibilités ; ils sont signalés comme des erreurs de commande, de même que tout échec du Gateway lorsqu’une cible explicite --url/--token a été indiquée. Les métadonnées du tableau peuvent définir autoDecompose, autoDecomposePerDispatch, defaultAssignee et orchestratorProfile. OpenClaw enregistre cette intention et l’expose dans le contexte du processus de travail ; la spécification et la décomposition effectives passent toujours par les outils Workboard habituels.

​
CLI et commande slash

La sortie texte de list masque les cartes archivées par défaut (--include-archived remplace ce comportement) ; --json inclut toujours les cartes archivées, conformément au contrat de carte complète utilisé par les scripts existants. show et move acceptent un préfixe d’identifiant non ambigu. list, create, show et move lisent et écrivent toujours directement l’état local du plugin. Seul dispatch appelle le Gateway en cours d’exécution, avec la solution de repli décrite ci-dessus. Consultez CLI Workboard pour connaître tous les indicateurs, la sortie JSON, le comportement de repli du Gateway, la gestion des préfixes d’identifiant, les règles de sélection de la répartition et le dépannage. /workboard list, /workboard show <card-id>, /workboard create <title>, /workboard move <card-id> --status <status> et /workboard dispatch reproduisent la CLI. La liste et l’affichage sont des opérations de lecture accessibles à tout expéditeur de commande autorisé. La création, le déplacement et la répartition nécessitent le statut de propriétaire sur les interfaces de discussion, ou un client Gateway disposant de operator.write/operator.admin. Les déplacements manuels effectués par l’opérateur utilisent le même comportement de remplacement des revendications que le glisser-déposer du tableau de bord. Leur accès à l’arborescence de travail respecte toujours la même limite d’espace de travail décrite ci-dessus.

​
Synchronisation du cycle de vie des sessions

Les cartes peuvent être associées à une session existante du tableau de bord, ou à une session créée lorsque vous démarrez le travail depuis la carte. Les cartes associées affichent directement le cycle de vie de la session : en cours d’exécution, obsolète, associée et inactive, terminée, en échec ou manquante. Vous pouvez également capturer une session existante depuis l’onglet Sessions avec Ajouter à Workboard ; la carte est associée à cette session, utilise le libellé de la session ou l’invite utilisateur récente comme titre, et initialise les notes à partir de l’invite utilisateur récente et de la dernière réponse de l’assistant lorsqu’elles sont disponibles. Si la session associée devient introuvable, la carte reste associée pour conserver le contexte et propose toujours des commandes de démarrage permettant de recommencer dans une nouvelle session. Si une session associée active cesse de signaler une activité récente, Workboard marque la carte stale et stocke cet état dans les métadonnées jusqu’à ce que le cycle de vie l’efface. Lorsqu’une carte se trouve dans un état de travail actif, Workboard suit la session associée : Les états de révision manuelle prévalent. Le déplacement d’une carte vers review, blocked ou done arrête la synchronisation automatique de cette carte jusqu’à ce que vous la replaciez dans todo ou running. Le démarrage d’une carte utilise les sessions normales du Gateway ; Workboard stocke uniquement les métadonnées et les associations de la carte. La transcription de la conversation, la sélection du modèle et le cycle de vie de l’exécution restent gérés par le système de sessions habituel. Utilisez Arrêter sur une carte associée active pour interrompre l’exécution en cours : Workboard marque cette carte blocked afin qu’elle reste visible pour le suivi. Les nouvelles cartes peuvent démarrer à partir de modèles Workboard (bugfix, docs, release, pr_review, plugin). Les modèles préremplissent le titre, les notes, les libellés et la priorité ; l’identifiant du modèle est stocké dans les métadonnées de la carte.

​
Flux de travail du tableau de bord

  1. Ouvrez l’onglet Workboard dans l’interface de contrôle.
  2. Créez une carte avec un titre, des notes, une priorité, des libellés, un agent facultatif et une session associée facultative, ou ouvrez Sessions et choisissez Ajouter à Workboard pour une session existante.
  3. Faites glisser la carte d’une colonne à l’autre, ou placez le focus sur son contrôle compact de statut et utilisez le menu ou ArrowLeft/ArrowRight. Pendant le déplacement, la carte source s’estompe et les colonnes de destination disponibles sont entourées d’un contour.
  4. Démarrez le travail depuis la carte pour créer ou réutiliser une session du tableau de bord.
  5. Ouvrez la session associée depuis la carte pendant que l’agent travaille.
  6. Laissez la synchronisation du cycle de vie déplacer le travail en cours vers review/blocked, puis déplacez manuellement la carte vers done après acceptation.

​
Diagnostics

Les diagnostics sont calculés à partir des métadonnées locales des cartes. Les contrôles intégrés signalent :

​
Autorisations

Les méthodes RPC du Gateway se trouvent sous workboard.* : Aucune méthode RPC ne nécessite operator.admin. Les navigateurs connectés avec un accès opérateur en lecture seule peuvent consulter le tableau, mais ne peuvent pas modifier les cartes. Une portée d’administration élargit les chemins d’hôte Workboard acceptés ; elle ne modifie pas les méthodes disponibles.

​
Stockage

Workboard stocke les données durables dans une base de données relationnelle SQLite appartenant au plugin sous le répertoire d’état d’OpenClaw : les tableaux, cartes, libellés, événements de cycle de vie, tentatives d’exécution, commentaires, liens de dépendance, preuves, références d’artefacts, métadonnées et objets binaires des pièces jointes, diagnostics, notifications, journaux des processus de travail, état du protocole et abonnements se trouvent tous dans les tables Workboard (et non dans des entrées clé-valeur du plugin). Une exportation de carte conserve le récit du tableau sans incorporer le contenu binaire des pièces jointes. Les installations qui utilisaient Workboard dans la version .28 peuvent exécuter openclaw doctor --fix pour migrer les espaces de noms historiques de l’état du plugin livré (workboard.cards, workboard.boards, workboard.notify et, s’il est présent, workboard.attachments) vers la base de données relationnelle.

​
Dépannage

L’onglet indique que Workboard n’est pas disponible
Si plugins.allow est configuré, ajoutez-y workboard. Si plugins.deny contient workboard, supprimez-le avant d’activer le plugin. Les cartes ne sont pas enregistrées Vérifiez que la connexion du navigateur dispose de l’accès operator.write. Les sessions d’opérateur en lecture seule peuvent répertorier les cartes, mais ne peuvent ni les créer, ni les modifier, ni les déplacer, ni les supprimer. Le démarrage d’une carte n’ouvre pas la session attendue Vérifiez l’identifiant d’agent de la carte et la session associée, puis ouvrez Sessions ou Chat pour examiner l’état réel de l’exécution. La répartition ne démarre pas de processus de travail Vérifiez qu’il existe au moins une carte ready sans revendication active :
Si la CLI signale une répartition limitée aux données, démarrez ou redémarrez le Gateway et réessayez : la répartition limitée aux données met à jour l’état local du tableau, mais ne peut pas démarrer les exécutions des processus de travail des sous-agents. Des cartes peuvent également être ignorées lorsqu’une autre carte du même propriétaire ou agent est déjà en cours d’exécution ou en attente de révision ; terminez, bloquez ou libérez ce travail actif avant d’en répartir davantage pour le même propriétaire.

​
Voir aussi