Plugin робочої дошки

Plugin Workboard додає необов’язкову дошку в стилі Kanban до інтерфейсу керування: робочі картки розміру, зручного для агентів, призначення агентам і посилання на пов’язані з карткою завдання, запуск і сеанс панелі керування.

Workboard навмисно має невеликий обсяг функцій: він відстежує локальну операційну роботу для одного OpenClaw Gateway. Він не замінює GitHub Issues, Linear, Jira чи інші командні системи керування проєктами.

Увімкнення

Workboard постачається в комплекті, але за замовчуванням вимкнений:

1. Відкрийте Плагіни в інтерфейсі керування або скористайтеся /settings/plugins відносно налаштованого базового шляху інтерфейсу керування. Наприклад, для базового шляху /openclaw використовується /openclaw/settings/plugins.
2. Знайдіть Workboard і виберіть Увімкнути. Оскільки Workboard входить до складу OpenClaw, дія Установити не потрібна.
3. Якщо інтерфейс повідомляє про необхідність перезапуску, перезапустіть Gateway.

Вкладка Workboard з’являється в навігації панелі керування після завантаження середовища виконання Plugin. Поки його вимкнено, вкладка залишається прихованою в навігації. Якщо відкрити маршрут /workboard безпосередньо, коли Plugin вимкнено або заблоковано через plugins.allow/plugins.deny, замість даних карток відображається стан недоступності Plugin.

Еквівалентний робочий процес у CLI:

openclaw plugins enable workboardopenclaw gateway restartopenclaw dashboard

Налаштування

Workboard не має власних налаштувань Plugin. Вмикайте або вимикайте його за допомогою стандартного запису Plugin:

{  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.

Картки зберігаються у власному стані Gateway цього Plugin і переміщуються разом з рештою стану OpenClaw відповідного Gateway (див. Зберігання).

Початок роботи з картки

З непов’язаних карток можна розпочати роботу безпосередньо:

• Запустити Codex / Запустити Claude запускає відстежуваний як завдання запуск агента з явно заданим рушієм, надсилає запит картки та позначає картку як running. Запуски Codex використовують openai/gpt-5.6-sol; запуски Claude використовують anthropic/claude-sonnet-4-6.
• Відкрити Codex / Відкрити 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.

Вибір виконавців

Кожен прохід за замовчуванням запускає щонайбільше 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 dispatch [--board <id>] [--json]

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

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

/workboard list, /workboard show <card-id>, /workboard create <title> і /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 зберігає довготривалі дані в реляційній базі даних SQLite, що належить Plugin, у каталозі стану OpenClaw: дошки, картки, мітки, події життєвого циклу, спроби виконання, коментарі, зв’язки залежностей, підтвердження, посилання на артефакти, метадані та двійкові дані вкладень, діагностика, сповіщення, журнали виконавців, стан протоколу й підписки зберігаються в таблицях Workboard (а не в записах Plugin типу «ключ — значення»). Експорт картки зберігає опис дошки, не вбудовуючи вміст двійкових даних вкладень.

Інсталяції, що використовували Workboard у випуску .28, можуть запустити openclaw doctor --fix, щоб перенести випущені застарілі простори імен стану Plugin (workboard.cards, workboard.boards, workboard.notify і, за наявності, workboard.attachments) до реляційної бази даних.

Усунення несправностей

Вкладка повідомляє, що Workboard недоступний

openclaw plugins inspect workboard --runtime --json

Якщо налаштовано plugins.allow, додайте до нього workboard. Якщо plugins.deny містить workboard, видаліть його звідти, перш ніж увімкнути Plugin.

Картки не зберігаються

Переконайтеся, що підключення браузера має доступ operator.write. Сеанси оператора лише для читання можуть отримувати список карток, але не можуть створювати, редагувати, переміщувати чи видаляти їх.

Запуск картки не відкриває очікуваний сеанс

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

Розподілення не запускає виконавця

Переконайтеся, що існує принаймні одна картка зі статусом ready без активної заявки:

openclaw workboard list --status ready

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

Пов’язані матеріали

• Control UI
• CLI Workboard
• Plugin
• Керування Plugin
• Сеанси