Plugin 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. У кожній картці, повернутій інструментом агента або викликом Gateway RPC, значення 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 "Виправити життєвий цикл застарілої картки" --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
• Плагіни
• Керування плагінами
• Сеанси