Плагин Workboard

Плагин Workboard добавляет необязательную доску в стиле Kanban в интерфейс управления: карточки задач подходящего для агентов размера, назначение агентам и ссылки из карточки на связанную задачу, запуск и сеанс панели управления.

Workboard намеренно невелик: он отслеживает локальную операционную работу одного OpenClaw Gateway. Он не заменяет GitHub Issues, Linear, Jira или другие системы управления командными проектами.

Включение

Workboard входит в комплект поставки, но по умолчанию отключён:

1. Откройте Plugins в интерфейсе управления или перейдите по адресу /settings/plugins относительно настроенного базового пути интерфейса управления. Например, для базового пути /openclaw используется /openclaw/settings/plugins.
2. Найдите Workboard и выберите Enable. Поскольку Workboard входит в состав OpenClaw, действие Install не требуется.
3. Если интерфейс сообщает, что требуется перезапуск, перезапустите Gateway.

Вкладка Workboard появляется в навигации панели управления после загрузки среды выполнения плагина. Пока плагин отключён, вкладка не отображается в навигации. При прямом открытии маршрута /workboard, когда плагин отключён или заблокирован параметрами plugins.allow/plugins.deny, вместо данных карточек отображается состояние недоступности плагина.

Эквивалентный рабочий процесс в CLI:

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Конфигурация

У Workboard нет конфигурации, специфичной для плагина. Включайте и отключайте его с помощью стандартной записи плагина:

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

openclaw plugins disable workboardopenclaw gateway restart

Поля карточки

Карточки также содержат компактные метаданные о попытках, комментариях, ссылках, подтверждениях, артефактах, настройках автоматизации, вложениях, журналах исполнителей, состоянии протокола исполнителя, заявках, диагностике, уведомлениях, идентификаторе шаблона, состоянии архива и обнаружении устаревших сеансов, а также список недавних событий (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). Эти метаданные позволяют оператору увидеть, как карточка перемещалась по доске, не открывая связанный сеанс; это локальный операционный контекст, а не замена расшифровкам сеансов или истории задач GitHub.

Плагин и интерфейс управления используют единый контракт карточки Workboard. Поэтому обновления панели управления сохраняют происхождение и полномочия рабочей области, состояние заявки, диагностические действия и порядковые номера уведомлений вместо создания уменьшенной копии карточки только для интерфейса. Неизвестные виды диагностики, уровни серьёзности диагностики и виды уведомлений игнорируются, пока обе поверхности не начнут их поддерживать; они никогда не преобразуются в другое допустимое состояние.

Открытая панель управления обновляется при аннулировании данных plugin.workboard.changed. Каждое событие содержит только эпоху и ревизию хранилища; затем интерфейс повторно считывает канонические карточки через обычный RPC operator.read. Несколько ревизий объединяются в одно последующее считывание. Workboard откладывает это считывание, пока карточку перетаскивают, редактируют или записывают, а затем возобновляет его после завершения локального взаимодействия. При повторном подключении всегда выполняется каноническая перезагрузка. Регулярный полный опрос карточек отсутствует, а Refresh остаётся доступной для ручного восстановления.

Если существует несколько досок, панель инструментов включает фильтр Board, основанный на сохранённых метаданных досок, а не только на видимых в данный момент карточках. Поэтому пустые и архивные доски остаются доступными для выбора. Карточки без явно заданного идентификатора доски относятся к канонической доске default. Выбранная доска сохраняется в параметре запроса ?board=, поэтому URL-адрес отфильтрованной доски Workboard можно добавить в закладки или предоставить другим пользователям; при выборе All boards параметр удаляется.

Карточки хранятся в собственном состоянии Gateway плагина и перемещаются вместе с остальной частью состояния OpenClaw этого Gateway (см. раздел Хранилище).

Запуск работы из карточки

Из карточек без связей можно запустить работу напрямую:

• Run Codex / Run Claude запускает отслеживаемый как задача запуск агента с явно заданным движком, отправляет запрос карточки и присваивает карточке состояние running. Запуски Codex используют openai/gpt-5.6-sol; запуски Claude используют anthropic/claude-sonnet-4-6.
• Open Codex / Open Claude создаёт связанный сеанс панели управления без отправки запроса карточки или перемещения карточки — для ручной работы, которая остаётся привязанной к доске.

Для автономных запусков используется путь отслеживаемого как задача запуска агента в Gateway (агент и модель по умолчанию, если Codex/Claude не выбран явно); затем Workboard добавляет в карточку ссылки на полученную задачу, идентификатор запуска и ключ сеанса. Каждое связанное выполнение также записывает сводку попытки (движок, режим, модель, идентификатор запуска, временные метки, статус, накопительное число сбоев), чтобы повторяющиеся сбои оставались видимыми.

Панель управления обновляет статус задачи из реестра задач Gateway, сопоставляя задачи с карточками по идентификатору задачи, идентификатору запуска или ключу связанного сеанса. Задача в очереди или выполняющаяся задача поддерживает активность жизненного цикла карточки; завершённая, неуспешная, превысившая время ожидания или отменённая задача переводит карточку к состоянию review или blocked по тому же правилу синхронизации, что и связанные сеансы (см. Синхронизация жизненного цикла сеанса).

Инструменты агента

Назначенные карточки отклоняют изменения через инструменты агента от других агентов, если вызывающая сторона не располагает токеном назначения, возвращённым workboard_claim. В каждой карточке, возвращаемой инструментом агента или вызовом RPC Gateway, значение metadata.claim.token заменяется на [redacted] (сам токен возвращается один раз на верхнем уровне и только из workboard_claim), поэтому операторы панели управления и другие агенты могут просматривать состояние назначения, никогда не получая пригодный для использования токен. Восстановление выполняется через workboard_promote/workboard_reassign/workboard_reclaim, для которых токен не требуется.

Диспетчеризация

Диспетчеризация выполняется локально в Gateway: она не создаёт произвольные процессы ОС. Выполнением по-прежнему управляют обычные сеансы субагентов OpenClaw. Один проход диспетчеризации:

1. Продвигает карточки с готовыми зависимостями.
2. Записывает метаданные диспетчеризации в готовые карточки.
3. Блокирует истёкшие назначения или выполнения с превышенным временем ожидания.
4. Помечает настроенные на доске карточки разбора как кандидатов на оркестрацию.
5. Назначает небольшую группу готовых карточек и запускает исполнителей через среду выполнения субагентов Gateway.

Исполнители получают ограниченный контекст карточки и токен назначения, необходимый для отправки Heartbeat, завершения или блокировки карточки с помощью инструментов Workboard.

Пути рабочих пространств подчиняются существующим полномочиям вызывающей стороны в файловой системе. Клиенты Gateway с operator.write могут использовать настроенные рабочие пространства агентов; клиенты operator.admin могут использовать другие рабочие копии на хосте. Инструменты агентов в песочнице используют доступ к рабочему пространству своей песочницы, а инструменты без песочницы, ограниченные рабочим пространством, используют настроенный корень рабочего пространства. Workboard записывает эти полномочия при назначении рабочего пространства и при диспетчеризации снова пересекает их с текущими полномочиями вызывающей стороны, поэтому сохранённая карточка не может расширить доступ последующей вызывающей стороны. Для старых карточек с явно заданным рабочим пространством хоста, но без записанных полномочий, необходимо повторно сохранить это рабочее пространство перед диспетчеризацией с полным доступом к хосту; карточки без пути на хосте принимают полномочия текущей вызывающей стороны при первой диспетчеризации.

Диспетчеризация, привязанная к рабочему пространству, принимает каталог или рабочую копию Git, только если корень репозитория точно соответствует целевому рабочему пространству агента. Запрос рабочего дерева ограничивается этим каталогом и сохраняется как рабочее пространство-каталог, поэтому хост не создаёт рабочую копию и не выполняет код настройки репозитория. Целевой исполнитель должен использовать доступную для записи, необщую песочницу Docker именно для этого рабочего пространства, без выполнения с повышенными привилегиями, сохранённых переопределений выполнения на хосте/Node, а также неклассифицированных инструментов плагинов и MCP. Workboard перечисляет зарегистрированные инструменты вместо доверия префиксу workboard_*, а диспетчеризация отклоняет активный контейнер Docker, если хеш его текущего подключения/конфигурации устарел. Диспетчеризация сообщает о несовместимой политике целевой среды вместо запуска исполнителя с менее строгими ограничениями. Диспетчеризация с полным доступом к хосту может использовать другие локальные рабочие копии и сохраняет обычную настройку управляемого рабочего дерева.

Полномочия рабочего пространства не создают вторую модель разрешений жизненного цикла карточек. Вызывающие стороны, которым разрешено изменять карточки Workboard, могут вручную переводить их между теми же статусами на любой поверхности; доступ к рабочему пространству только для чтения предотвращает лишь диспетчеризацию исполнителей, требующую записи.

Выбор исполнителей

Каждый проход по умолчанию запускает не более 3 исполнителей. Готовые карточки упорядочиваются по приоритету, затем по позиции, затем по времени создания. За один проход запускается только одна карточка для каждого владельца/агента; владельцы, у которых на доске уже есть выполняемая или проверяемая работа, пропускаются. Архивированные карточки, карточки с активным назначением и карточки не в статусе ready никогда не выбираются для запуска исполнителей (на них по-прежнему может влиять часть диспетчеризации, работающая с данными: очистка устаревших назначений, продвижение зависимостей, очистка по превышению времени ожидания).

Ключи сеансов детерминированы для каждой пары доски/карточки, поэтому повторная диспетчеризация направляет работу обратно в ту же линию исполнителя, а не создаёт несвязанные сеансы:

• Назначенные карточки: agent:<agentId>:subagent:workboard-<boardId>-<cardId>
• Неназначенные карточки: subagent:workboard-<boardId>-<cardId> (Gateway определяет настроенного агента по умолчанию)

Если после назначения карточки исполнителя запустить не удаётся, Workboard блокирует карточку, снимает назначение, записывает ошибку запуска выполнения и добавляет строку в журнал исполнителя — она видна в панели управления, JSON CLI, инструментах агента и диагностике карточки.

Точки входа

• Действие диспетчеризации на панели управления
• openclaw workboard dispatch
• /workboard dispatch в канале с поддержкой команд

Все три варианта используют среду выполнения субагентов Gateway, когда Gateway доступен. У CLI есть один резервный вариант для оператора: если вызов Gateway завершается ошибкой подключения/недоступности (или ошибкой unknown method для более старых версий Gateway), при этом не задана явная цель --url/--token и не применяется настроенный удалённый Gateway (OPENCLAW_GATEWAY_URL или gateway.mode: remote), CLI выполняет диспетчеризацию только данных на основе локального состояния SQLite — он может активировать зависимости, очищать устаревшие заявки и блокировать запуски с истёкшим временем ожидания, но не может запускать исполнителей. Ошибки аутентификации, разрешений и валидации от доступного Gateway не считаются ошибками недоступности; они отображаются как ошибки команд, как и любая ошибка Gateway, если была задана явная цель --url/--token.

В метаданных доски можно задать autoDecompose, autoDecomposePerDispatch, defaultAssignee и orchestratorProfile. OpenClaw записывает это намерение и передаёт его в контекст исполнителя; фактическое составление спецификации и декомпозиция по-прежнему выполняются через обычные инструменты Workboard.

CLI и слеш-команда

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]

Текстовый вывод list по умолчанию скрывает архивные карточки (--include-archived отменяет это поведение); --json всегда включает архивные карточки в соответствии с контрактом полного набора карточек, который используют существующие скрипты. show и move принимают однозначный префикс идентификатора. list, create, show и move всегда напрямую читают и записывают локальное состояние плагина. Только dispatch обращается к работающему Gateway с резервным вариантом, описанным выше.

Полное описание флагов, вывода JSON, резервного поведения Gateway, обработки префиксов идентификаторов, правил выбора при диспетчеризации и устранения неполадок см. в разделе CLI Workboard.

/workboard list, /workboard show <card-id>, /workboard create <title>, /workboard move <card-id> --status <status> и /workboard dispatch соответствуют CLI. Операции просмотра списка и отдельной карточки доступны любому авторизованному отправителю команд. Создание, перемещение и диспетчеризация требуют статуса владельца в интерфейсах чатов либо клиента Gateway с operator.write/operator.admin. Перемещения, выполняемые оператором вручную, используют то же поведение переопределения заявки, что и перетаскивание на панели управления. Доступ таких операций к рабочему дереву по-прежнему ограничивается описанной выше границей рабочего пространства.

Синхронизация жизненного цикла сеанса

Карточки можно связать с существующим сеансом панели управления или с сеансом, созданным при запуске работы из карточки. В связанных карточках состояние жизненного цикла сеанса отображается непосредственно: выполняется, устарел, связан и простаивает, завершён, завершён с ошибкой или отсутствует. Существующий сеанс также можно добавить на вкладке Sessions с помощью Add to Workboard; карточка будет связана с этим сеансом, получит в качестве заголовка метку сеанса или недавний запрос пользователя, а её заметки будут заполнены недавним запросом пользователя и последним ответом ассистента, если они доступны.

Если связанный сеанс пропадает, карточка сохраняет связь для контекста и по-прежнему предоставляет элементы управления запуском, чтобы перезапустить работу в новом сеансе. Если активный связанный сеанс перестаёт сообщать о недавней активности, Workboard помечает карточку как stale и сохраняет эту отметку в метаданных, пока жизненный цикл её не удалит.

Пока карточка находится в активном рабочем состоянии, Workboard следует за связанным сеансом:

Состояния ручной проверки имеют приоритет. Перемещение карточки в review, blocked или done останавливает её автоматическую синхронизацию, пока она не будет возвращена в todo или running.

При запуске карточки используются обычные сеансы Gateway; Workboard хранит только метаданные и связи карточки. Стенограмма разговора, выбор модели и жизненный цикл запуска остаются в ведении обычной системы сеансов. Чтобы прервать активный запуск, используйте Stop на работающей связанной карточке — Workboard пометит её как blocked, чтобы она оставалась видимой для последующих действий.

Новые карточки можно создавать на основе шаблонов Workboard (bugfix, docs, release, pr_review, plugin). Шаблоны предварительно заполняют заголовок, заметки, метки и приоритет; идентификатор шаблона сохраняется в метаданных карточки.

Рабочий процесс на панели управления

1. Откройте вкладку Workboard в Control UI.
2. Создайте карточку, указав заголовок, заметки, приоритет, метки, необязательного агента и необязательный связанный сеанс, либо откройте Sessions и выберите Add to Workboard для существующего сеанса.
3. Перетащите карточку между столбцами либо переведите фокус на компактный элемент управления её статусом и используйте меню или клавиши ArrowLeft/ArrowRight. Во время перетаскивания исходная карточка становится полупрозрачной, а доступные для перемещения столбцы выделяются контуром.
4. Запустите работу из карточки, чтобы создать или повторно использовать сеанс панели управления.
5. Откройте связанный сеанс из карточки, пока агент работает.
6. Позвольте синхронизации жизненного цикла переместить выполняемую работу в review/blocked, затем вручную переместите карточку в done после принятия результата.

Диагностика

Диагностика вычисляется на основе локальных метаданных карточек. Встроенные проверки выявляют:

Разрешения

Методы RPC Gateway находятся в пространстве workboard.*:

Ни один метод RPC не требует operator.admin. Браузеры, подключённые с доступом оператора только для чтения, могут просматривать доску, но не могут изменять карточки. Область администратора расширяет набор допустимых путей хоста Workboard; она не меняет доступные методы.

Хранилище

Workboard хранит долговременные данные в принадлежащей плагину реляционной базе данных SQLite в каталоге состояния OpenClaw: доски, карточки, метки, события жизненного цикла, попытки запуска, комментарии, связи зависимостей, подтверждения, ссылки на артефакты, метаданные и двоичные данные вложений, диагностика, уведомления, журналы исполнителей, состояние протокола и подписки хранятся в таблицах Workboard (а не в записях хранилища пар «ключ — значение» плагина). Экспорт карточки сохраняет историю доски, не включая в неё содержимое двоичных данных вложений.

В установках, где Workboard использовался в выпуске .28, можно выполнить openclaw doctor --fix, чтобы перенести поставлявшиеся пространства имён устаревшего состояния плагина (workboard.cards, workboard.boards, workboard.notify и, при наличии, workboard.attachments) в реляционную базу данных.

Устранение неполадок

На вкладке указано, что Workboard недоступен

openclaw plugins inspect workboard --runtime --json

Если настроен plugins.allow, добавьте в него workboard. Если plugins.deny содержит workboard, удалите его перед включением плагина.

Карточки не сохраняются

Убедитесь, что подключение браузера имеет доступ operator.write. Сеансы оператора только для чтения могут просматривать список карточек, но не могут создавать, редактировать, перемещать или удалять их.

При запуске карточки не открывается ожидаемый сеанс

Проверьте идентификатор агента и связанный сеанс карточки, затем откройте Sessions или Chat, чтобы проверить фактическое состояние запуска.

Диспетчеризация не запускает исполнителя

Убедитесь, что существует хотя бы одна карточка ready без активной заявки:

openclaw workboard list --status ready

Если CLI сообщает о диспетчеризации только данных, запустите или перезапустите Gateway и повторите попытку — диспетчеризация только данных обновляет локальное состояние доски, но не может запускать субагентов-исполнителей. Карточки также могут быть пропущены, если другая карточка того же владельца или агента уже выполняется или ожидает проверки; завершите, заблокируйте или освободите эту активную работу, прежде чем диспетчеризировать новые задачи для того же владельца.

Связанные разделы

• Control UI
• CLI Workboard
• Плагины
• Управление плагинами
• Сеансы