Plugin Workboard

El plugin Workboard añade un tablero opcional de estilo Kanban a la IU de control: tarjetas de trabajo adaptadas a los agentes, asignación a agentes y un enlace a la tarea, la ejecución y la sesión del panel de la tarjeta.

Workboard es intencionadamente pequeño: realiza el seguimiento del trabajo operativo local de un Gateway de OpenClaw. No sustituye a GitHub Issues, Linear, Jira ni otros sistemas de gestión de proyectos en equipo.

Habilitarlo

Workboard está incluido, pero deshabilitado de forma predeterminada:

1. Abra Plugins en la IU de control o use /settings/plugins con respecto a la ruta base configurada de la IU de control. Por ejemplo, una ruta base de /openclaw usa /openclaw/settings/plugins.
2. Busque Workboard y seleccione Habilitar. Como Workboard está incluido con OpenClaw, no necesita una acción Instalar.
3. Si la IU indica que es necesario reiniciar, reinicie el Gateway.

La pestaña Workboard aparece en la navegación del panel después de que se cargue el entorno de ejecución del plugin. Mientras está deshabilitado, la pestaña permanece oculta en la navegación. Al abrir directamente la ruta /workboard mientras el plugin está deshabilitado o bloqueado por plugins.allow/plugins.deny, se muestra un estado de plugin no disponible en lugar de los datos de las tarjetas.

El flujo de trabajo equivalente en la CLI es:

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Configuración

Workboard no tiene configuración específica del plugin. Habilítelo o deshabilítelo con la entrada estándar del plugin:

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

openclaw plugins disable workboardopenclaw gateway restart

Campos de las tarjetas

Las tarjetas también incluyen metadatos compactos de intentos, comentarios, enlaces, pruebas, artefactos, ajustes de automatización, archivos adjuntos, registros de trabajadores, estado del protocolo de los trabajadores, reclamaciones, diagnósticos, notificaciones, id. de plantilla, estado de archivado y detección de sesiones obsoletas, además de una lista de eventos recientes (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). Estos metadatos permiten que un operador vea cómo se desplazó una tarjeta por el tablero sin abrir la sesión vinculada; constituyen contexto operativo local, no sustituyen las transcripciones de las sesiones ni el historial de incidencias de GitHub.

El plugin y la IU de control usan un único contrato de tarjeta de Workboard. Por lo tanto, las actualizaciones del panel conservan la procedencia y la autoridad del espacio de trabajo, el estado de reclamación, las acciones de diagnóstico y los números de secuencia de las notificaciones, en lugar de proyectar una copia más pequeña de la tarjeta exclusiva de la IU. Los tipos de diagnóstico, las gravedades de diagnóstico y los tipos de notificación desconocidos se ignoran hasta que ambas superficies los admitan; nunca se reescriben como otro estado válido.

El panel abierto se actualiza a partir de las invalidaciones de plugin.workboard.changed. Cada evento solo contiene una época y una revisión del almacén; a continuación, la IU vuelve a leer las tarjetas canónicas mediante la RPC operator.read habitual. Varias revisiones se combinan en una única lectura posterior. Workboard aplaza esa lectura mientras se arrastra, edita o escribe una tarjeta y la reanuda cuando finaliza la interacción local. Una reconexión siempre realiza una recarga canónica. No hay ningún sondeo completo rutinario de las tarjetas y Actualizar sigue disponible como recuperación manual.

Cuando existe más de un tablero, la barra de herramientas incluye un filtro Tablero respaldado por metadatos persistentes del tablero, en lugar de únicamente por las tarjetas visibles en ese momento. Por lo tanto, los tableros vacíos y archivados siguen siendo seleccionables. Las tarjetas sin un id. de tablero explícito pertenecen al tablero canónico default. Cada tablero tiene una página canónica /workboard/<boardId> que se puede añadir a marcadores, compartir o fijar en la barra lateral. El formato /workboard?board=<boardId> publicado anteriormente se mantiene como alias de compatibilidad y redirige a esa página conservando los demás parámetros de consulta. Al seleccionar Todos los tableros, se vuelve a /workboard.

Las tarjetas se almacenan en el estado propio del Gateway del plugin y se trasladan con el resto del estado de OpenClaw de ese Gateway (consulte Almacenamiento).

Iniciar trabajo desde una tarjeta

Las tarjetas no vinculadas pueden iniciar trabajo directamente:

• Ejecutar Codex / Ejecutar Claude inicia una ejecución de agente con seguimiento de tareas y un motor explícito, envía la instrucción de la tarjeta y marca la tarjeta como running. Las ejecuciones de Codex usan openai/gpt-5.6-sol; las de Claude usan anthropic/claude-sonnet-4-6.
• Abrir Codex / Abrir Claude crea una sesión vinculada del panel sin enviar la instrucción de la tarjeta ni moverla, para realizar trabajo manual que permanece asociado al tablero.

Los inicios autónomos usan la ruta de ejecución de agentes con seguimiento de tareas del Gateway (el agente y el modelo predeterminados, salvo que se elija Codex/Claude explícitamente); a continuación, Workboard vincula la tarea resultante, el id. de ejecución y la clave de sesión con la tarjeta. Cada ejecución vinculada también registra un resumen del intento (motor, modo, modelo, id. de ejecución, marcas de tiempo, estado y recuento acumulado de fallos) para que los fallos repetidos sigan visibles.

El panel actualiza el estado de las tareas desde el registro de tareas del Gateway y relaciona las tareas con las tarjetas mediante el id. de tarea, el id. de ejecución o la clave de sesión vinculada. Una tarea en cola o en ejecución mantiene activo el ciclo de vida de la tarjeta; una tarea finalizada, fallida, agotada por tiempo o cancelada mueve la tarjeta hacia review o blocked mediante la misma regla de sincronización que las sesiones vinculadas (consulte Sincronización del ciclo de vida de las sesiones).

Herramientas del agente

Los estados de prueba son resultados comunicados por el trabajador, no una verificación independiente. Una entrada passed significa que el trabajador informa que su comando o comprobación se ejecutó correctamente; los consumidores que necesiten una puerta de calidad independiente deben inspeccionar el comando, la URL o el artefacto adjuntos y ejecutar su propio verificador. workboard_proof devuelve el proofId del nuevo registro. Cuando workboard_complete informe del estado terminal de esa misma prueba, pase proofId para que el registro pendiente se resuelva en el mismo lugar sin perder su identidad ni marca de tiempo. Una prueba que ya tenga el mismo estado terminal se reutiliza sin cambios. Las pruebas de finalización sin proofId siguen siendo de solo anexado, por lo que un reintento posterior no puede reescribir el historial anterior solo porque su comando o nota sean idénticos.

Las tarjetas reclamadas rechazan las mutaciones mediante herramientas de agente procedentes de otros agentes, salvo que el llamante posea el token de reclamación devuelto por workboard_claim. Cada tarjeta devuelta por una herramienta de agente o una llamada RPC del Gateway censura metadata.claim.token como [redacted] (el token propiamente dicho se devuelve una sola vez, en el nivel superior y únicamente desde workboard_claim), para que los operadores del panel y otros agentes puedan inspeccionar el estado de reclamación sin ver nunca un token utilizable. La recuperación se realiza mediante workboard_promote/workboard_reassign/workboard_reclaim, que no requieren el token.

Despacho

El despacho es local al Gateway: no inicia procesos arbitrarios del sistema operativo. Las sesiones normales de subagentes de OpenClaw siguen siendo responsables de la ejecución. Una pasada de despacho:

1. Promueve las tarjetas cuyas dependencias están listas.
2. Registra metadatos de despacho en las tarjetas listas.
3. Bloquea reclamaciones vencidas o ejecuciones que han superado el tiempo de espera.
4. Marca como candidatas de orquestación las tarjetas de triaje configuradas en el tablero.
5. Reclama un pequeño lote de tarjetas listas e inicia ejecuciones de trabajadores mediante el entorno de ejecución de subagentes del Gateway.

Los trabajadores reciben contexto acotado de la tarjeta junto con el token de reclamación necesario para actualizar el Heartbeat, completar o bloquear la tarjeta mediante las herramientas de Workboard.

Las rutas del espacio de trabajo respetan la autoridad existente del llamante sobre el sistema de archivos. Los clientes del Gateway con operator.write pueden usar espacios de trabajo de agentes configurados; los clientes operator.admin pueden usar otros checkouts del host. Las herramientas de agente en sandbox usan el acceso al espacio de trabajo de su sandbox, mientras que las herramientas sin sandbox limitadas al espacio de trabajo usan la raíz de espacio de trabajo configurada. Workboard registra esa autoridad cuando se asigna un espacio de trabajo y vuelve a intersectarla con la autoridad actual del llamante durante el despacho, por lo que una tarjeta persistente no puede ampliar el acceso de un llamante posterior. Las tarjetas antiguas con un espacio de trabajo explícito del host pero sin una autoridad registrada deben volver a guardar dicho espacio de trabajo antes de un despacho con acceso completo al host; las tarjetas sin una ruta del host adoptan la autoridad del llamante actual al despacharse por primera vez.

El despacho vinculado a un espacio de trabajo acepta un directorio o checkout de Git únicamente cuando su raíz de repositorio coincide exactamente con el espacio de trabajo del agente de destino. Una solicitud de worktree se restringe a ese directorio y se conserva como espacio de trabajo de directorio, de modo que el host no materializa el checkout ni ejecuta código de configuración del repositorio. El trabajador de destino debe usar un sandbox de Docker con permiso de escritura y no compartido para ese espacio de trabajo exacto, sin ejecución con privilegios elevados, anulaciones persistentes de ejecución en el host/Node ni herramientas de Plugin y MCP sin clasificar. Workboard enumera sus herramientas registradas en lugar de confiar en un prefijo workboard_*, y el despacho rechaza un contenedor Docker activo cuyo hash de montaje/configuración en ejecución esté obsoleto. El despacho informa de la política de destino incompatible en lugar de iniciar un trabajador con menos restricciones. El despacho con acceso completo al host puede dirigirse a otros checkouts locales y mantiene la configuración normal de worktrees gestionados.

La autoridad sobre el espacio de trabajo no crea un segundo modelo de permisos para el ciclo de vida de las tarjetas. Los llamantes que pueden modificar tarjetas de Workboard pueden moverlas manualmente por los mismos estados en todas las superficies; el acceso de solo lectura al espacio de trabajo solo impide el despacho de trabajadores que necesitan permisos de escritura.

Selección de trabajadores

Cada pasada inicia como máximo 3 trabajadores de forma predeterminada. Las tarjetas listas se ordenan por prioridad, después por posición y, por último, por fecha de creación. Una pasada inicia solo una tarjeta por propietario/agente y omite a los propietarios que ya tienen trabajo en ejecución o en revisión en el tablero. Las tarjetas archivadas, las tarjetas con una reclamación activa y las tarjetas que no están en el estado ready nunca se seleccionan para iniciar trabajadores (aun así, pueden verse afectadas por la parte de datos del despacho: limpieza de reclamaciones obsoletas, promoción de dependencias y limpieza por tiempo de espera).

Las claves de sesión son deterministas por tablero/tarjeta, por lo que los despachos repetidos se dirigen de nuevo al mismo carril de trabajo en lugar de crear sesiones no relacionadas:

• Tarjetas asignadas: agent:<agentId>:subagent:workboard-<boardId>-<cardId>
• Tarjetas sin asignar: subagent:workboard-<boardId>-<cardId> (el Gateway resuelve el agente predeterminado configurado)

Si no se puede iniciar un trabajador después de reclamar una tarjeta, Workboard bloquea la tarjeta, elimina la reclamación, registra el fallo de inicio de la ejecución y añade una línea al registro del trabajador, visible en el panel, el JSON de la CLI, las herramientas del agente y los diagnósticos de la tarjeta.

Puntos de entrada

• Acción de despacho del panel
• openclaw workboard dispatch
• /workboard dispatch en un canal compatible con comandos

Los tres usan el entorno de ejecución de subagentes del Gateway cuando este está disponible. La CLI tiene una alternativa para operadores: si la llamada al Gateway falla con un error de conexión/no disponible (o un error unknown method en Gateways anteriores), y no se aplica ningún destino explícito --url/--token ni ningún Gateway remoto configurado (OPENCLAW_GATEWAY_URL o gateway.mode: remote), la CLI ejecuta un despacho solo de datos sobre el estado SQLite local: puede promover dependencias, limpiar reclamaciones obsoletas y bloquear ejecuciones que superen el tiempo de espera, pero no puede iniciar trabajadores. Los fallos de autenticación, permisos y validación de un Gateway accesible no se tratan como falta de disponibilidad; se muestran como errores del comando, al igual que cualquier fallo del Gateway cuando se ha proporcionado un destino explícito --url/--token.

Los metadatos del tablero pueden establecer autoDecompose, autoDecomposePerDispatch, defaultAssignee y orchestratorProfile. OpenClaw registra esta intención y la expone en el contexto del trabajador; la especificación/descomposición real sigue ejecutándose mediante las herramientas normales de Workboard.

CLI y comando con barra

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]

La salida de texto de list oculta las tarjetas archivadas de forma predeterminada (--include-archived lo anula); --json siempre incluye las tarjetas archivadas, de acuerdo con el contrato de tarjetas completas utilizado por los scripts existentes. show y move aceptan un prefijo de id inequívoco. list, create, show y move siempre leen/escriben directamente el estado local del plugin. Solo dispatch llama al Gateway en ejecución, con la alternativa descrita anteriormente.

Consulte CLI de Workboard para conocer todas las opciones, la salida JSON, el comportamiento alternativo del Gateway, la gestión de prefijos de id, las reglas de selección del despacho y la solución de problemas.

/workboard list, /workboard show <card-id>, /workboard create <title>, /workboard move <card-id> --status <status> y /workboard dispatch reproducen la CLI. Listar y mostrar son operaciones de lectura para cualquier remitente de comandos autorizado. Crear, mover y despachar requieren la condición de propietario en las superficies de chat, o un cliente del Gateway con operator.write/operator.admin. Los movimientos manuales del operador usan el mismo comportamiento de anulación de reclamaciones que arrastrar y soltar en el panel. Su acceso al árbol de trabajo sigue respetando el mismo límite del espacio de trabajo descrito anteriormente.

Sincronización del ciclo de vida de las sesiones

Las tarjetas pueden vincularse a una sesión existente del panel o a una creada al iniciar el trabajo desde la tarjeta. Las tarjetas vinculadas muestran el ciclo de vida de la sesión en línea: en ejecución, obsoleta, vinculada e inactiva, completada, fallida o ausente. También se puede capturar una sesión existente desde la pestaña Sessions con Add to Workboard; la tarjeta se vincula a esa sesión, usa como título la etiqueta de la sesión o la solicitud reciente del usuario e inicializa las notas con la solicitud reciente del usuario y la respuesta más reciente del asistente cuando están disponibles.

Si la sesión vinculada desaparece, la tarjeta permanece vinculada para conservar el contexto y sigue ofreciendo controles de inicio para reiniciar en una sesión nueva. Si una sesión vinculada activa deja de comunicar actividad reciente, Workboard marca la tarjeta como stale y lo almacena como metadatos hasta que el ciclo de vida lo elimine.

Mientras una tarjeta se encuentra en un estado de trabajo activo, Workboard sigue la sesión vinculada:

Los estados de revisión manual tienen prioridad. Mover una tarjeta a review, blocked o done detiene la sincronización automática de esa tarjeta hasta que vuelva a moverse a todo o running.

Al iniciar una tarjeta se usan sesiones normales del Gateway; Workboard solo almacena los metadatos y vínculos de la tarjeta. La transcripción de la conversación, la selección del modelo y el ciclo de vida de la ejecución siguen siendo responsabilidad del sistema de sesiones habitual. Use Stop en una tarjeta vinculada activa para anular la ejecución activa; Workboard marca esa tarjeta como blocked para que permanezca visible y se pueda realizar el seguimiento.

Las tarjetas nuevas pueden partir de plantillas de Workboard (bugfix, docs, release, pr_review, plugin). Las plantillas rellenan previamente el título, las notas, las etiquetas y la prioridad; el id de la plantilla se almacena como metadatos de la tarjeta.

Flujo de trabajo del panel

1. Abra la pestaña Workboard en la interfaz de control.
2. Cree una tarjeta con título, notas, prioridad, etiquetas, un agente opcional y una sesión vinculada opcional; o abra Sessions y elija Add to Workboard para una sesión existente.
3. Arrastre la tarjeta entre columnas, o enfoque su control de estado compacto y use el menú o ArrowLeft/ArrowRight. Durante el arrastre, la tarjeta de origen se atenúa y las columnas de destino disponibles muestran un contorno.
4. Inicie el trabajo desde la tarjeta para crear o reutilizar una sesión del panel.
5. Abra la sesión vinculada desde la tarjeta mientras el agente trabaja.
6. Permita que la sincronización del ciclo de vida mueva el trabajo en ejecución a review/blocked y, después, mueva manualmente la tarjeta a done cuando se acepte.

Widgets de sesión y tablero

Workboard incluye dos widgets nativos para los paneles de sesión (consulte Paneles). El agente los fija con su herramienta dashboard mediante content: { kind: "plugin", pluginKind, props }, y se representan como interfaz propia con datos en tiempo real, sin marco aislado ni concesión de capacidades:

• workboard:card con props: { cardId } muestra una tarjeta con su control de estado, prioridad y agente asignado.
• workboard:mini con el valor opcional props: { boardId, limit } muestra recuentos por estado, además de las principales tarjetas listas/en ejecución, y enlaza con la página completa del tablero. Sin boardId, agrega todos los tableros; con boardId, limita el ámbito a ese tablero (las tarjetas creadas sin un id de tablero explícito se encuentran en default).

Diagnósticos

Los diagnósticos se calculan a partir de los metadatos locales de las tarjetas. Las comprobaciones integradas señalan:

Permisos

Los métodos RPC del Gateway se encuentran bajo workboard.*:

Ningún método RPC requiere operator.admin. Los navegadores conectados con acceso de operador de solo lectura pueden inspeccionar el tablero, pero no modificar las tarjetas. Un ámbito de administrador amplía las rutas de host de Workboard aceptadas; no cambia los métodos disponibles.

Almacenamiento

Workboard almacena los datos duraderos en una base de datos SQLite relacional propiedad del plugin dentro del directorio de estado de OpenClaw: los tableros, las tarjetas, las etiquetas, los eventos del ciclo de vida, los intentos de ejecución, los comentarios, los vínculos de dependencias, las pruebas, las referencias de artefactos, los metadatos y blobs de archivos adjuntos, los diagnósticos, las notificaciones, los registros de trabajadores, el estado del protocolo y las suscripciones se almacenan en tablas de Workboard (no en entradas de clave-valor del plugin). La exportación de una tarjeta conserva la narrativa del tablero sin insertar el contenido de los blobs de archivos adjuntos.

Las instalaciones que usaron Workboard en la versión .28 pueden ejecutar openclaw doctor --fix para migrar los espacios de nombres del estado heredado del plugin distribuido (workboard.cards, workboard.boards, workboard.notify y, si existe, workboard.attachments) a la base de datos relacional.

Solución de problemas

La pestaña indica que Workboard no está disponible

openclaw plugins inspect workboard --runtime --json

Si plugins.allow está configurado, añada workboard. Si plugins.deny contiene workboard, elimínelo antes de habilitar el plugin.

Las tarjetas no se guardan

Confirme que la conexión del navegador tenga acceso operator.write. Las sesiones de operador de solo lectura pueden listar tarjetas, pero no crearlas, editarlas, moverlas ni eliminarlas.

Al iniciar una tarjeta no se abre la sesión esperada

Compruebe el id de agente y la sesión vinculada de la tarjeta; después, abra Sessions o Chat para inspeccionar el estado real de la ejecución.

El despacho no inicia un trabajador

Confirme que haya al menos una tarjeta ready sin una reclamación activa:

openclaw workboard list --status ready

Si la CLI informa de un despacho solo de datos, inicie o reinicie el Gateway y vuelva a intentarlo: el despacho solo de datos actualiza el estado del tablero local, pero no puede iniciar ejecuciones de trabajadores de subagentes. También se pueden omitir tarjetas cuando otra tarjeta del mismo propietario o agente ya se está ejecutando o está esperando revisión; complete, bloquee o libere ese trabajo activo antes de despachar más trabajo para el mismo propietario.

Relacionado

• Interfaz de control
• CLI del tablero de trabajo
• Plugins
• Gestionar plugins
• Sesiones