Plugin Workboard

Le plugin Workboard ajoute un tableau facultatif de type Kanban à l’interface de contrôle : des cartes de travail dimensionnées pour les agents, leur attribution aux agents, ainsi qu’un lien vers la tâche, l’exécution et la session du tableau de bord associées à la carte.

Workboard est volontairement simple : il suit le travail opérationnel local d’un Gateway OpenClaw. Il ne remplace pas GitHub Issues, Linear, Jira ni les autres systèmes de gestion de projet en équipe.

L’activer

Workboard est fourni avec OpenClaw, mais désactivé par défaut :

1. Ouvrez Plugins dans l’interface de contrôle, ou utilisez /settings/plugins relativement au chemin de base configuré de l’interface de contrôle. Par exemple, avec /openclaw comme chemin de base, utilisez /openclaw/settings/plugins.
2. Recherchez Workboard et choisissez Activer. Comme Workboard est inclus avec OpenClaw, aucune action Installer 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. Si vous ouvrez directement la route /workboard alors que le plugin est désactivé ou bloqué par plugins.allow/plugins.deny, un état indiquant que le plugin est indisponible s’affiche à la place des données des cartes.

Le flux de travail CLI équivalent est le suivant :

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Configuration

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

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

openclaw plugins disable workboardopenclaw gateway restart

Champs des cartes

Les cartes contiennent également des métadonnées compactes sur les tentatives, commentaires, liens, preuves, artefacts, paramètres d’automatisation, pièces jointes, journaux des workers, état du protocole des workers, revendications, diagnostics, notifications, identifiant de modèle, état d’archivage et 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 a progressé sur le tableau sans ouvrir la session liée ; elles constituent un contexte opérationnel local et ne remplacent pas les transcriptions de session ni l’historique des issues GitHub.

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 :

• Exécuter Codex / Exécuter Claude démarre une exécution d’agent suivie par une tâche avec un moteur explicite, envoie l’invite de la carte et marque la carte comme running. Les exécutions Codex utilisent openai/gpt-5.6-sol ; les exécutions Claude utilisent anthropic/claude-sonnet-4-6.
• Ouvrir Codex / Ouvrir Claude crée une session de tableau de bord liée sans envoyer l’invite de la carte ni déplacer celle-ci, pour un travail manuel qui reste attaché au tableau.

Les démarrages autonomes utilisent le chemin d’exécution d’agent suivi par une tâche du Gateway (agent et modèle par défaut, sauf si Codex ou Claude est choisi explicitement) ; Workboard lie ensuite la tâche obtenue, 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 depuis le registre des tâches du Gateway, en faisant correspondre les tâches aux cartes selon l’identifiant de tâche, l’identifiant d’exécution ou la clé de session liée. Une tâche en file d’attente ou en cours d’exécution maintient le cycle de vie de la carte actif ; une tâche terminée, ayant échoué, ayant dépassé le délai imparti 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 modifications effectuées par les outils d’agent 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 par [redacted] (le jeton lui-même n’est renvoyé qu’une fois, au niveau supérieur, uniquement par workboard_claim), afin que les opérateurs du tableau de bord et les autres agents puissent examiner l’état de la revendication sans jamais voir un 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 de sous-agents OpenClaw normales restent responsables de l’exécution. Un passage de répartition :

1. Fait passer les cartes dont les dépendances sont satisfaites à l’état prêt.
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.
4. Marque les cartes de triage configurées par le tableau comme candidates à l’orchestration.
5. Revendique un petit lot de cartes prêtes et démarre les exécutions des travailleurs via l’environnement d’exécution des sous-agents du Gateway.

Les travailleurs reçoivent un contexte de carte limité ainsi que le jeton de revendication nécessaire pour envoyer un Heartbeat, achever ou bloquer la carte au moyen des outils Workboard.

Sélection des travailleurs

Chaque passage démarre au maximum 3 travailleurs par défaut. Les cartes prêtes sont classées par priorité, puis par position, puis par date de création. Un passage ne démarre qu’une carte par propriétaire/agent et ignore les propriétaires qui ont déjà un travail en cours ou en révision sur le tableau. Les cartes archivées, les cartes avec une revendication active et les cartes qui ne sont pas à l’état ready ne sont jamais sélectionnées pour démarrer des travailleurs (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 soient redirigées vers la même voie de travail au lieu de créer des sessions sans rapport :

• Cartes assignées : agent:<agentId>:subagent:workboard-<boardId>-<cardId>
• Cartes non assignées : subagent:workboard-<boardId>-<cardId> (le Gateway résout l’agent par défaut configuré)

Si un travailleur ne peut pas être démarré après la revendication d’une carte, Workboard bloque la carte, efface la revendication, enregistre l’échec de démarrage de l’exécution et ajoute une ligne au journal du travailleur, 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 du tableau de bord
• openclaw workboard dispatch
• /workboard dispatch sur un canal prenant en charge les commandes

Les trois utilisent l’environnement d’exécution des sous-agents du Gateway lorsque celui-ci est disponible. La CLI dispose d’une solution de repli pour l’opérateur : si l’appel au Gateway échoue en raison d’une erreur de connexion/indisponibilité (ou d’une erreur unknown method pour les anciens Gateways), qu’aucune cible explicite --url/--token n’a été définie et qu’aucun Gateway distant configuré (OPENCLAW_GATEWAY_URL ou gateway.mode: remote) ne s’applique, 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 dépassé le délai, mais ne peut pas démarrer de travailleurs. 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, tout comme tout échec du Gateway lorsqu’une cible explicite --url/--token a été fournie.

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 travailleur ; la spécification/décomposition effective s’effectue toujours au moyen des outils Workboard normaux.

CLI et commande oblique

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 dispatch [--board <id>] [--json]

La sortie texte de list masque les cartes archivées par défaut (--include-archived annule ce comportement) ; --json inclut toujours les cartes archivées, conformément au contrat de carte complète utilisé par les scripts existants. show accepte un préfixe d’identifiant non ambigu. list, create et show lisent/é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> et /workboard dispatch reproduisent le fonctionnement de la CLI. La liste et l’affichage sont des opérations de lecture accessibles à tout expéditeur de commande autorisé. La création 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.

Synchronisation du cycle de vie des sessions

Les cartes peuvent être liées à une session existante du tableau de bord, ou à une session créée lorsque vous commencez à travailler depuis la carte. Les cartes liées affichent directement le cycle de vie de la session : en cours d’exécution, obsolète, liée inactive, terminée, en échec ou manquante. Vous pouvez également récupérer une session existante depuis l’onglet Sessions avec Ajouter au Workboard ; la carte est liée à cette session, utilise comme titre le libellé de la session ou la récente invite utilisateur, et préremplit les notes à partir de cette invite et de la dernière réponse de l’assistant lorsqu’elles sont disponibles.

Si la session liée devient introuvable, la carte reste liée afin de conserver le contexte et propose toujours des commandes de démarrage permettant de relancer le travail dans une nouvelle session. Si une session liée active cesse de signaler une activité récente, Workboard marque la carte comme stale et conserve cette information dans les métadonnées jusqu’à ce que le cycle de vie l’efface.

Lorsqu’une carte est dans un état de travail actif, Workboard suit la session liée :

Les états de révision manuels sont prioritaires. Le déplacement d’une carte vers review, blocked ou done interrompt sa synchronisation automatique jusqu’à ce que vous la replaciez dans todo ou running.

Le démarrage d’une carte utilise des sessions Gateway normales ; Workboard stocke uniquement les métadonnées et les liens 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 liée active pour abandonner l’exécution en cours ; Workboard marque alors cette carte comme blocked afin qu’elle reste visible pour le suivi.

Les nouvelles cartes peuvent être créées à 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, éventuellement un agent et une session liée, ou ouvrez Sessions et choisissez Ajouter au Workboard pour une session existante.
3. Faites glisser la carte entre les colonnes, ou placez le focus sur son contrôle d’état compact et utilisez le menu ou ArrowLeft/ArrowRight.
4. Commencez le travail depuis la carte afin de créer ou de réutiliser une session du tableau de bord.
5. Ouvrez la session lié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 lorsqu’il est accepté.

Diagnostics

Les diagnostics sont calculés à partir des métadonnées locales des cartes. Les vérifications intégrées 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.

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 : tableaux, cartes, libellés, événements du cycle de vie, tentatives d’exécution, commentaires, liens de dépendance, preuves, références d’artefacts, métadonnées et données binaires des pièces jointes, diagnostics, notifications, journaux des workers, état du protocole et abonnements résident tous dans les tables de Workboard, et non dans des entrées clé-valeur du Plugin. L’exportation d’une carte préserve le récit du tableau sans incorporer le contenu binaire des pièces jointes.

Les installations ayant utilisé Workboard dans la version .28 peuvent exécuter openclaw doctor --fix afin de migrer vers la base de données relationnelle les espaces de noms historiques de l’état du Plugin livrés avec cette version (workboard.cards, workboard.boards, workboard.notify et, le cas échéant, workboard.attachments).

Dépannage

L’onglet indique que Workboard est indisponible

openclaw plugins inspect workboard --runtime --json

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 opérateur en lecture seule peuvent répertorier les cartes, mais ne peuvent pas les créer, les modifier, les déplacer ni les supprimer.

Le démarrage d’une carte n’ouvre pas la session attendue

Vérifiez l’identifiant de l’agent et la session liée de la carte, puis ouvrez Sessions ou Chat afin d’examiner l’état réel de l’exécution.

La distribution ne démarre pas de worker

Vérifiez qu’il existe au moins une carte ready sans réservation active :

openclaw workboard list --status ready

Si la CLI signale une distribution limitée aux données, démarrez ou redémarrez le Gateway, puis réessayez : une distribution limitée aux données met à jour l’état local du tableau, mais ne peut pas démarrer les exécutions des workers 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 distribuer davantage au même propriétaire.

Voir aussi

• Interface de contrôle
• CLI Workboard
• Plugins
• Gérer les Plugins
• Sessions