Канбан — совместная работа нескольких агентов по профилям

Хотите пошаговое руководство? Прочтите Учебное пособие по Канбану — четыре пользовательские истории (одиночная разработка, автопарковое фермерство, ролевой конвейер с повтором, автоматический выключатель) со скриншотами панели мониторинга каждой. Эта страница является справочной; Учебное пособие – это повествование.

VibeOS Kanban — это надежная доска задач, общая для всех ваших профилей VibeOS, которая позволяет нескольким именованным агентам сотрудничать в работе без хрупкого роя субагентов в процессе. Каждая задача представляет собой строку в ~/.vibeos/kanban.db; каждая передача — это строка, которую каждый может читать и писать; каждый рабочий процесс представляет собой полноценный процесс ОС со своей индивидуальностью.

Две поверхности: модель говорит с помощью инструментов, вы говорите с помощью CLI

Плата имеет две передние двери, обе подкреплены одним и тем же ~/.vibeos/kanban.db:

• Агенты управляют платой с помощью специального набора инструментов kanban_* — kanban_show, kanban_list, kanban_complete, kanban_block, kanban_heartbeat, kanban_comment, kanban_create, kanban_link, kanban_unblock. Диспетчер порождает каждого работника с этими инструментами, уже включенными в его схему; Профили оркестратора также могут явно включать набор инструментов kanban. Модель считывает и маршрутизирует задачи, вызывая инструменты напрямую, а не путем вызова vibeos kanban. См. раздел Как работники взаимодействуют с доской ниже.
• Вы (и скрипты, и cron) гоните плату через vibeos kanban … на CLI, /kanban … как slash-команду, или на дашборд. Они предназначены для людей и автоматизации — мест, за которыми не стоит модель вызова инструментов.

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

Эта форма охватывает рабочие нагрузки, которые delegate_task не может:

• Исследовательская сортировка — параллельные исследователи + аналитик + писатель, человек в курсе.
• Запланированные операции — повторяющиеся ежедневные сводки, которые составляют журнал в течение нескольких недель.
• Цифровые двойники — постоянные именные помощники (inbox-triage, ops-review), которые со временем накапливают память.
• Проектирование конвейеров — декомпозиция → реализация параллельных рабочих деревьев → обзор → итерация → PR.
• Работа с автопарком — один специалист, управляющий N субъектами (50 социальных аккаунтов, 12 контролируемых сервисов).

Полное обоснование дизайна, сравнительный анализ с Cline Kanban/Paperclip/NanoClaw/Google Gemini Enterprise и восемь канонических шаблонов сотрудничества см. в docs/vibeos-kanban-v1-spec.pdf в репозитории.

Канбан против delegate_task

Они выглядят похоже; они не такие же примитивные.

	delegate_task	Канбан
Форма	RPC вызов (вилка → присоединиться)	Устойчивая очередь сообщений + конечный автомат
Родитель	Блокирует до тех пор, пока ребенок не вернется	«Выстрелил и забыл» после create
Детская идентичность	Анонимный субагент	Именованный профиль с постоянной памятью
Возобновляемость	Нет — не удалось = не удалось	Заблокировать → разблокировать → запустить заново; авария → вернуть
Человек в курсе	Не поддерживается	Комментировать/разблокировать в любой момент
Агенты на задачу	Один звонок = один субагент	N агентов в течение срока действия задачи (повторная попытка, проверка, последующие действия)
Аудиторский след	Потеряно при сжатии контекста	Надежные строки в SQLite навсегда
Координация	Иерархический (вызывающий → вызываемый)	Peer — любой профиль читает /writes любую задачу

Различие в одно предложение: delegate_task — вызов функции; Канбан — это рабочая очередь, в которой каждая передача представляет собой строку, которую любой профиль (или человек) может видеть и редактировать.

Используйте delegate_task, когда родительскому агенту требуется краткий аргументирующий ответ, прежде чем продолжить, без участия людей, результат возвращается в контекст родительского объекта.

Используйте Канбан, когда работа выходит за границы агента, должна пережить перезапуск, может потребовать участия человека, может быть выполнена другой ролью или должна быть обнаружена постфактум.

Они сосуществуют: канбан-работник может вызвать delegate_task внутри себя во время своего выполнения.

Основные понятия

• Доска — автономная очередь задач со своей базой данных SQLite, рабочими пространствами. каталог и цикл диспетчера. В одной установке может быть много плат. (например, по одному на проект, репозиторий или домен); см. Доски (мультипроект) ниже. Пользователи одного проекта остаются на плате default и никогда не видят слово «доска» за пределами этого раздела документации.
• Задача — строка с заголовком, необязательное тело, один исполнитель (имя профиля), статус (triage | todo | ready | running | blocked | done | archived), необязательное пространство имен клиента, необязательный ключ идемпотентности (дедупликация для повторной попытки автоматизации).
• Ссылка — строка task_links, записывающая родительскую → дочернюю зависимость. Диспетчер повышает todo → ready, когда все родительские элементы — done.
• Комментарий — межагентский протокол. Агенты и люди добавляют комментарии; когда рабочий (повторно) создается, он читает всю ветку комментариев как часть своего контекста.
• Рабочая область — каталог, в котором работает работник. Три вида:
  • scratch (по умолчанию) — новый каталог tmp под ~/.vibeos/kanban/workspaces/<id>/ (или ~/.vibeos/kanban/boards/<slug>/workspaces/<id>/ на платах не по умолчанию). Удаляется после завершения задачи — царапина по задумке является эфемерной, поэтому каталог удаляется в тот момент, когда рабочий (или vibeos kanban complete <id>) отмечает задачу как выполненную. Если вы хотите сохранить выходные данные работника, используйте вместо этого worktree:илиdir:<path>. При первом создании временного рабочего пространства при установке диспетчер регистрирует предупреждение и генерирует событие tip_scratch_workspace для задачи (видимое через vibeos kanban show <id>`).
  • dir:<path> — существующий общий каталог (хранилище Obsidian, каталог почтовых операций, папка для каждой учетной записи). **Должен быть абсолютный путь.** Относительные пути, такие как dir:../tenants/foo/`, отклоняются при отправке, поскольку они разрешаются против любого CWD, в котором находится диспетчер, что является неоднозначным и представляет собой escape-вектор с запутанным заместителем. В противном случае путь является доверенным — это ваш компьютер, ваша файловая система, рабочий процесс запускается с вашим uid. Это модель угроз «доверенный локальный пользователь»; Канбан по задумке рассчитан на один хост. Сохраняется после завершения.
  • worktree — рабочее дерево git под .worktrees/<id>/ для задач кодирования. Используйте worktree:<path>, чтобы указать точный целевой путь. git worktree addна рабочей стороне создает его, используя--branch`, если он предусмотрен. Сохраняется после завершения.
• Диспетчер — долгоживущий цикл, который каждые N секунд (по умолчанию 60): восстанавливает устаревшие утверждения, восстанавливает вышедших из строя рабочих процессов (PID исчез, но срок действия TTL еще не истек), продвигает готовые задачи, атомарные утверждения, порождает назначенные профили. По умолчанию запускается внутри шлюза (kanban.dispatch_in_gateway: true). Один диспетчер прочесывает все доски за тик; рабочие создаются с прикрепленным VIBEOS_KANBAN_BOARD, поэтому они не могут видеть другие доски. После последовательных сбоев создания kanban.failure_limit для одной и той же задачи (по умолчанию: 2) диспетчер автоматически блокирует ее, указав в качестве причины последнюю ошибку — предотвращает сбой на задачах, профиль которых не существует, рабочая область не может смонтироваться и т. д.
• Tenant — необязательное строковое пространство имен внутри доски. Один специализированный парк может обслуживать несколько предприятий (--tenant business-a) с изоляцией данных по пути к рабочему пространству и префиксу ключа памяти. Арендаторы – это мягкий фильтр; платы — это жесткая граница изоляции.

Доски (мультипроект)

Доски позволяют разделять несвязанные потоки работы — по одному на проект, репозиторий, или домен — в изолированные очереди. В новой установке ровно одна плата. называется default (DB по адресу ~/.vibeos/kanban.db для обратной совместимости). Пользователи, которые нужен только один поток работы, никогда не нужно знать о досках; особенность является добровольным.

Изоляция каждой платы абсолютна:

• Отдельная база данных SQLite для каждой платы (~/.vibeos/kanban/boards/<slug>/kanban.db).
• Отдельные каталоги workspaces/ и logs/.
• Рабочие, созданные для выполнения задачи, видят только задачи своей доски — диспетчер устанавливает VIBEOS_KANBAN_BOARD в дочернем окружении и каждый Инструмент kanban_*, к которому имеет доступ рабочий, читает его.
• Связывание задач между досками не допускается (сохраняет простоту схемы; если вам действительно нужны межпроектные ссылки, используйте упоминания в свободном тексте и смотрите их по идентификатору вручную).

###Управляющая плата от CLI

# See what's on disk. Fresh installs show only "default".
vibeos kanban boards list

# Create a new board.
vibeos kanban boards create atm10-server \
    --name "ATM10 Server" \
    --description "Minecraft modded server ops" \
    --icon 🎮 \
    --switch                   # optional: make it the active board

# Operate on a specific board without switching.
vibeos kanban --board atm10-server list
vibeos kanban --board atm10-server create "Restart ATM server" --assignee ops

# Change which board is "current" for subsequent calls.
vibeos kanban boards switch atm10-server
vibeos kanban boards show             # who's active right now?

# Rename the display name (the slug is immutable — it's the directory name).
vibeos kanban boards rename atm10-server "ATM10 (Prod)"

# Archive (default) — moves the board's dir to boards/_archived/<slug>-<ts>/.
# Recoverable by moving the dir back.
vibeos kanban boards rm atm10-server

# Hard delete — `rm -rf` the board dir. No recovery.
vibeos kanban boards rm atm10-server --delete

Порядок принятия решений Правлением (сначала высший приоритет):

1. Явное использование --board <slug>` в вызове CLI.
2. VIBEOS_KANBAN_BOARD env var (устанавливается диспетчером при создании работник, поэтому работники не могут видеть другие доски).
3. ~/.vibeos/kanban/current — пул, сохраненный канбаном vibeos платы переключаются.
4. default.

Проверяются слаги: строчные буквы и цифры + дефисы + подчеркивания, 1–64. символы должны начинаться с буквенно-цифровых символов. Ввод в верхнем регистре автоматически преобразуется в нижний регистр. Все остальное (косые черты, пробелы, точки, ..) отклоняется на уровне CLI. поэтому трюки с обходом пути не могут назвать доску.

Управление досками из панели управления

vibeos dashboard → На вкладке Канбан вверху отображается переключатель досок. поскольку существует более одной доски (или на любой доске есть задачи). Одноплатные пользователи видим только маленькую кнопку + New board; переключатель скрыт до тех пор, пока он имеет значение.

• Раскрывающийся список досок — выберите активную доску. Ваш выбор сохраняется в localStorage браузера, поэтому он сохраняется при перезагрузках без перемещение указателя current CLI из-под терминала, который вы оставили открытый.
• + Новая доска — открывает модальное окно с запросом слага, отображаемого имени, описание и значок. Возможность автоматического переключения на новую плату.
• Архив — отображается только на платах, отличных от default. Подтверждает, затем перемещает каталог платы boards/_archived/.

Все конечные точки информационной панели API принимают ?board=<slug>` для области видимости платы. события WebSocket закрепляется на доске во время подключения; включение пользовательский интерфейс открывает новый WS на новой плате.

Вложения файлов

Задачи могут содержать вложенные файлы — PDF-файлы, изображения, исходные документы — поэтому у работника есть исходный материал, который ему нужен, без необходимости вставки путей в файл. тело и надеются, что оно их найдет.

• Загрузить — откройте задачу в панели управления и воспользуйтесь Кнопка Загрузить файл в разделе Вложения (несколько файлов одновременно) все в порядке). Размер каждой загрузки ограничен 25 МБ.
• Хранилище — файлы помещаются в <vibeos-home>/kanban/attachments/<task_id>/ для платы по умолчанию или <vibeos-home>/kanban/boards/<slug>/attachments/<task_id>/ для имени доска. Установите VIBEOS_KANBAN_ATTACHMENTS_ROOT, чтобы закрепить произвольное местоположение.
• Что видит работник — когда диспетчер передает задание работнику, контекст работника включает раздел Вложения, в котором перечислены все имя файла и его абсолютный путь. У рабочего есть полный файл /terminal доступ к инструменту, поэтому он читает вложения напрямую (read_file или оболочка такие инструменты, как pdftotext).
• Загрузить/удалить — в ящике перечислены все загруженные вложения. ссылку и элемент управления удалением (×). Удаление вложения удаляет как строку метаданных и файл на диске.

Серверные части удаленного терминала

Пути вложений разрешаются непосредственно на локальном сервере терминала, что является значением по умолчанию для работников Канбана. Если вы запускаете рабочие процессы на удаленном бэкэнде (Docker, Modal), смонтируйте каталог attachments/ платы в песочница, чтобы абсолютные пути в рабочем контексте были доступны.

Быстрый старт

Приведенные ниже команды предназначены для вы (человека) настройки доски и создания задач. После назначения задачи диспетчер создает назначенный профиль в качестве рабочего, и оттуда модель управляет задачей посредством вызовов инструментов kanban_*, а не команд CLI — см. Как работники взаимодействуют с доской.

# 1. Create the board (you)
vibeos kanban init

# 2. Start the gateway (hosts the embedded dispatcher)
vibeos gateway start

# 3. Create a task (you — or an orchestrator agent via kanban_create)
vibeos kanban create "research AI funding landscape" --assignee researcher

# 4. Watch activity live (you)
vibeos kanban watch

# 5. See the board (you)
vibeos kanban list
vibeos kanban stats

Когда диспетчер берет t_abcd и создает профиль researcher, самое первое, что делает рабочая модель, — это вызывает kanban_show(), чтобы прочитать свою задачу. vibeos kanban show t_abcd не работает.

Диспетчер, встроенный в шлюз (по умолчанию)

Диспетчер работает внутри процесса шлюза. Нечего устанавливать, нет. отдельный сервис для управления — если шлюз включен, подбираются готовые задачи на следующем тике (по умолчанию 60 с).

# config.yaml
kanban:
  dispatch_in_gateway: true        # default
  dispatch_interval_seconds: 60    # default
  journal_mode: delete             # default — see table below

journal_mode управляет тем, как kanban.db хранится на диске. По умолчанию delete — безопасный выбор, когда открывается и закрывается множество рабочих процессов. SQLite-соединения (диспетчер + параллельные утверждения). Подключайтесь к wal, только если вам сознательно нужен WAL и вы используете один долгоживущий писатель; доски уже созданные в режиме WAL, остаются в WAL (без автоматического понижения версии). Для WAL → Миграция DELETE и устранение неполадок, см. docs/kanban-journal-mode.md в хранилище.

Переопределить флаг конфигурации во время выполнения через VIBEOS_KANBAN_DISPATCH_IN_GATEWAY=0. для отладки. Применяется стандартный контроль шлюза: запустите шлюз vibeos. startнапрямую или подключите шлюз как пользовательскую единицу systemd (см. документацию шлюза). Без работающего шлюза задачиreadyостаются там, где они есть. пока не появится один —vibeos kanban create` предупреждает об этом при создании время.

Запуск vibeos kanban daemon как отдельного процесса устарел; используйте шлюз. Если вы действительно не можете запустить шлюз (безголовый хост политика запрещает долгосрочные услуги и т. д.) аварийный люк --force сохраняет старый автономный демон, работающий в течение одного цикла выпуска, но работающий в обоих встроенный в шлюз диспетчер AND, автономный демон против того же самого kanban.db вызывает гонки заявок и не поддерживается.

Идемпотентное создание (для автоматизации/вебхуков)

# First call creates the task. Any subsequent call with the same key
# returns the existing task id instead of duplicating.
vibeos kanban create "nightly ops review" \
    --assignee ops \
    --idempotency-key "nightly-ops-$(date -u +%Y-%m-%d)" \
    --json

Массовые глаголы CLI

Все команды жизненного цикла принимают несколько идентификаторов, поэтому вы можете очистить пакет. одной командой:

vibeos kanban complete t_abc t_def t_hij --result "batch wrap"
vibeos kanban archive  t_abc t_def t_hij
vibeos kanban unblock  t_abc t_def
vibeos kanban block    t_abc "need input" --ids t_def t_hij

Как работники взаимодействуют с доской

Работники не выделяют vibeos kanban. Когда диспетчер порождает работника, он устанавливает VIBEOS_KANBAN_TASK=t_abcd в дочернем окружении, и эта переменная окружения включает специальный набор инструментов канбана в схеме модели. Тот же набор инструментов также доступен для профилей оркестратора, которые включают kanban в конфигурации своих наборов инструментов. Эти инструменты считывают и изменяют плату напрямую через уровень Python kanban_db, так же, как это делает CLI. Работающий рабочий вызывает их, как и любой другой инструмент; он никогда не видит и не нуждается в vibeos kanban CLI.

Инструмент	Цель	Обязательные параметры
kanban_show	Прочитайте текущую задачу (заголовок, тело, предыдущие попытки, передачу родительских функций, комментарии, полный предварительно отформатированный worker_context). По умолчанию используется идентификатор задачи env.	—
kanban_list	Получение списка сводок задач с фильтрами для assignee, status, tenant, видимости архива и ограничений. Предназначен для организаторов, изучающих работу с доской.	—
kanban_complete	Завершите структурированной передачей обслуживания summary + metadata.	хотя бы один из summary/result
kanban_block	Остановить работу и указать причину: kind=dependency (ожидание в todo, автоматическое возобновление), needs_input/capability/transient (поверхность для человека). Повторные повторные блокировки одного и того же типа автоматически перерастают в triage.	reason
kanban_heartbeat	Живучесть сигнала при длительной работе. Чистый побочный эффект.	—
kanban_comment	Добавьте надежную заметку в цепочку задач.	task_id, body
kanban_create	(Оркестраторы) распределяют дочерние задачи с помощью assignee, дополнительных parents, skills и т. д.	title, assignee
kanban_link	(Оркестраторы) добавляют край зависимости parent_id → child_id постфактум.	parent_id, child_id
kanban_unblock	(Оркестраторы) перемещают заблокированную задачу обратно в ready.	task_id

Типичная очередь работника выглядит так:

# Model's tool calls, in order:
kanban_show()                                     # no args — uses VIBEOS_KANBAN_TASK
# (model reads the returned worker_context, does the work via terminal/file tools)
kanban_heartbeat(note="halfway through — 4 of 8 files transformed")
# (more work)
kanban_complete(
    summary="migrated limiter.py to token-bucket; added 14 tests, all pass",
    metadata={"changed_files": ["limiter.py", "tests/test_limiter.py"], "tests_run": 14},
)

Вместо этого оркестратор работает веером:

kanban_show()
kanban_create(
    title="research ICP funding 2024-2026",
    assignee="researcher-a",
    body="focus on seed + series A, North America, AI-adjacent",
)
# → returns {"task_id": "t_r1", ...}
kanban_create(title="research ICP funding — EU angle", assignee="researcher-b", body="…")
# → returns {"task_id": "t_r2", ...}
kanban_create(
    title="synthesize findings into launch brief",
    assignee="writer",
    parents=["t_r1", "t_r2"],                     # promotes to ready when both complete
    body="one-pager, 300 words, neutral tone",
)
kanban_complete(summary="decomposed into 2 research tasks + 1 writer; linked dependencies")

Инструменты «(Оркестраторы)» — kanban_list, kanban_create, kanban_link, kanban_unblock и kanban_comment для внешних задач — доступны через тот же набор инструментов; соглашение (закодированное в автоматически внедряемом руководстве по канбану) заключается в том, что рабочие профили не разветвляются и не маршрутизируют несвязанную работу, а профили оркестратора не выполняют работу по реализации. Рабочие процессы, созданные диспетчером, по-прежнему ограничиваются деструктивными операциями жизненного цикла и не могут изменять несвязанные задачи.

Почему инструменты вместо обстрела для vibeos kanban

Три причины:

1. Переносимость бэкенда. Работники, чей инструмент терминала указывает на удаленный бэкэнд (Docker/Modal/Singularity/SSH), будут запускать vibeos kanban complete внутри контейнера, где vibeos не установлен и ~/.vibeos/kanban.db не смонтирован. Инструменты канбана запускаются в собственном процессе Python агента и всегда достигают ~/.vibeos/kanban.db независимо от серверной части терминала.
2. Нет хрупкости цитирования оболочки. Передача --metadata '{"files": [...]}' через shlex + argparse — это скрытая проблема. Аргументы структурированного инструмента полностью пропускают его.
3. Улучшение ошибок. Результаты инструмента структурированы JSON, о которых модель может рассуждать, а не строки stderr, которые ей приходится анализировать.

Нулевой объем схемы в обычных сеансах. Обычный сеанс vibeos chat не содержит в своей схеме инструментов kanban_*, если только активный профиль явно не включает набор инструментов kanban для работы оркестратора. Рабочие задачи, созданные диспетчером, получают инструменты области задач, поскольку установлен VIBEOS_KANBAN_TASK; Профили оркестратора получают более широкую поверхность маршрутизации через config. Никаких раздутых инструментов для пользователей, которые никогда не прикасаются к канбану.

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

Рекомендуемое доказательство передачи

kanban_complete(summary=..., metadata={...}) намеренно гибок: резюме — это удобочитаемое завершение, а metadata — это машиночитаемая передача, которую могут выполнять нижестоящие агенты, рецензенты или панели мониторинга. повторное использование без очистки прозы.

Для задач проектирования и проверки предпочтительнее использовать эту необязательную форму метаданных:

{
  "changed_files": ["path/to/file.py"],
  "verification": ["pytest tests/vibeos_cli/test_kanban_db.py -q"],
  "dependencies": ["parent task id or external issue, if any"],
  "blocked_reason": null,
  "retry_notes": "what failed before, if this was a retry",
  "residual_risk": ["what was not tested or still needs human review"]
}

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

1. Что изменилось?
2. Как это проверялось?
3. Что может разблокировать или повторить попытку в случае неудачи?
4. Какой риск намеренно остается открытым?

Храните секреты, необработанные журналы, токены, материалы OAuth и несвязанные расшифровки metadata. Вместо этого храните указатели и сводки. Если задача не имеет файлов или тестах, скажите об этом явно в summary и используйте metadata для доказательства того, что существует, например, исходные URL-адреса, идентификаторы проблем или действия по проверке вручную.

Жизненный цикл работника

Каждый профиль, который выполняет задачи канбана, автоматически получает жизненный цикл работника — он вводится в системную подсказку работника при запуске (блок KANBAN_GUIDANCE), поэтому нечего устанавливать или настраивать. Он обучает рабочего полному жизненному циклу с помощью вызовов инструментов, а не команд CLI:

1. При появлении вызовите kanban_show(), чтобы прочитать заголовок + тело + родительские передачи + предыдущие попытки + полную ветку комментариев.
2. cd $VIBEOS_KANBAN_WORKSPACE (через терминал) и там делаем работу.
3. Во время длительных операций звоните по kanban_heartbeat(note="...") каждые несколько минут. Если ваша работа может длиться более 1 часа, вызывайте kanban_heartbeat не реже одного раза в час — диспетчер восстанавливает задачи, которые выполнялись после kanban.dispatch_stale_timeout_seconds (по умолчанию 4 часа) без контрольного сигнала в течение последнего часа, при условии, что рабочий процесс аварийно завершился без очистки. Возврат является безопасным (задача возвращается к ready для повторной отправки без отметки счетчика неудач), но вы теряете прогресс текущего выполнения.
4. В комплекте с kanban_complete(summary="...", metadata={...}) или kanban_block(reason="..."), если он застрял.

Этот последний вызов kanban_complete/kanban_block является частью рабочего процесса. протокол. Если рабочий процесс завершается со статусом 0, пока задача еще выполняется running, диспетчер расценивает это как нарушение протокола, выдает сообщение protocol_violation и вместо этого автоматически блокирует задачу на следующем тике. возрождения его в том же цикле. Обычно это означает, что модель написала ответить открытым текстом и выйти без использования панели инструментов Канбан.

Жизненный цикл, а также справочные сведения о нагрузке (типы рабочих пространств, результат artifacts, утверждение созданных карточек) поставляются в этом блоке системных подсказок, поэтому они есть у каждого работника независимо от того, под каким профилем он работает — настройка навыков для каждого профиля не требуется.

Привязка дополнительных навыков к конкретной задаче

Иногда для одной задачи требуется контекст специалиста, которого профиль ответственного лица не имеет по умолчанию: задание на перевод, для которого требуется навык translation, задание проверки, для которого требуется github-code-review, аудит безопасности, для которого требуется security-pr-audit. Вместо того чтобы каждый раз редактировать профиль исполнителя, прикрепите навыки непосредственно к задаче.

Из агента оркестратора (обычный случай — маршрутизация работы одного агента другому) используйте массив skills инструмента kanban_create:

kanban_create(
    title="translate README to Japanese",
    assignee="linguist",
    skills=["translation"],
)

kanban_create(
    title="audit auth flow",
    assignee="reviewer",
    skills=["security-pr-audit", "github-code-review"],
)

От человека (команда CLI / slash-команда) повторите --skill для каждого из них:

vibeos kanban create "translate README to Japanese" \
    --assignee linguist \
    --skill translation

vibeos kanban create "audit auth flow" \
    --assignee reviewer \
    --skill security-pr-audit \
    --skill github-code-review

На панели управления введите навыки, разделенные запятыми, в поле навыки встроенной формы создания.

Диспетчер выдает один флаг --skills <name> для каждого перечисленного навыка, поэтому работник появляется со всеми ними, загруженными поверх автоматически внедряемого руководства канбана. Имена навыков должны соответствовать навыкам, которые фактически установлены в профиле исполнителя (запустите vibeos skills list`, чтобы увидеть, что доступно); нет установки во время выполнения.

Карточки с режимом цели (--goal)

По умолчанию каждый работник получает один шанс по своей карточке — выполните работу, позвоните kanban_complete/kanban_block, выйдите. Передайте --goal (CLI) или goal_mode=True (инструмент / панель управления kanban_create), чтобы вместо этого запустить этого работника в цикле целей, том же движке в стиле Ральфа, что и slash-команда /goal: после каждого хода вспомогательный судья проверяет выходные данные работника по заголовку + телу карты (трактуется как критерии приемки), и если работа не выполнена (а бюджет очереди остается), работник продолжает работать в том же сеансе до тех пор, пока судья не согласится, работник сам не завершит задачу или не закончится бюджет (что блокирует карточку для проверки человеком, а не завершает работу молча).

vibeos kanban create "Translate the docs site to French" \
    --body "Acceptance: every page translated, no English left, links intact." \
    --assignee linguist \
    --goal \
    --goal-max-turns 15      # optional; default 20

Используйте его для открытых, многошаговых карточек или карточек «продолжайте, пока X не станет правдой». Пропустите его для дешевой разовой работы — накладные расходы на оценку за ход того не стоят, а существующая функция retry/circuit-breaker диспетчера уже обрабатывает временные сбои рабочих процессов. Оценка оценивается настолько, насколько хорош текст вашей цели, поэтому напишите тело как явные критерии приемлемости.

Как ведет себя оркестратор

Хороший оркестратор не выполняет всю работу сам. Он разбивает цель пользователя на задачи, связывает их, назначает каждую из них одному из настроенных вами профилей и отступает. Руководство оркестратора — правила предотвращения искушений, запрос на обнаружение профиля Step-0 (диспетчер молчаливо терпит неудачу при неизвестных именах исполнителей, поэтому оркестратор должен закрепить каждую карту в профилях, которые действительно существуют на вашей машине) и сценарий декомпозиции с ключами kanban_create / kanban_link / kanban_comment — автоматически вводится в системное приглашение работника; нечего устанавливать.

Канонический ход оркестратора (два параллельных исследователя передают роль писателю):

# Goal from user: "draft a launch post on the ICP funding landscape"
kanban_create(title="research ICP funding, NA angle",  assignee="researcher-a", body="…")  # → t_r1
kanban_create(title="research ICP funding, EU angle",  assignee="researcher-b", body="…")  # → t_r2
kanban_create(
    title="synthesize ICP funding research into launch post draft",
    assignee="writer",
    parents=["t_r1", "t_r2"],        # promoted to 'ready' when both researchers complete
    body="one-pager, neutral tone, cite sources inline",
)                                     # → t_w1
# Optional: add cross-cutting deps discovered later without re-creating tasks
kanban_link(parent_id="t_r1", child_id="t_followup")
kanban_complete(
    summary="decomposed into 2 parallel research tasks → 1 synthesis task; writer starts when both researchers finish",
)

Рекомендации оркестратора автоматически доставляются в системную подсказку работника — для каждого профиля не нужно ничего устанавливать или синхронизировать.

Для достижения наилучших результатов соедините его с профилем, наборы инструментов которого ограничены операциями с платой (kanban, gateway, memory), чтобы оркестратор буквально не мог выполнять задачи реализации, даже если он попытается.

Панель управления (GUI)

Команды /kanban CLI и slash достаточно, чтобы управлять доской без головы, но визуальная доска часто является подходящим интерфейсом для людей, находящихся в процессе: сортировка, межпрофильный контроль, чтение веток комментариев и перетаскивание карточек между столбцами. VibeOS поставляется как включенный плагин информационной панели в plugins/kanban/ — не основная функция и не отдельная услуга — в соответствии с моделью, изложенной в Расширение информационной панели.

Откройте его с помощью:

vibeos kanban init      # one-time: create kanban.db if not already present
vibeos dashboard        # "Kanban" tab appears in the nav, after "Skills"

Что дает вам плагин

– Вкладка Канбан, показывающая один столбец для каждого статуса: triage, todo, ready, running, blocked, done (плюс archived, когда переключатель включен).

• triage — это парковочная колонка для грубых идей. По умолчанию (kanban.auto_decompose: true) диспетчер автоматически запускает декомпозер для задач, которые попадают сюда. Встроенный декомпозер использует путь модели auxiliary.kanban_decomposer, считывает список вашего профиля (с описаниями) и разбивает задачу на небольшой график дочерних задач, направляемых наиболее подходящим специалистам. Исходная задача остается родительской для каждого дочернего процесса, поэтому ее ответственный (kanban.orchestrator_profile или активный профиль по умолчанию, если он не установлен) снова просыпается, чтобы оценить завершение, когда все завершится. Переверните табличку Оркестровка: Auto/Manual вверху страницы (изумрудный = автоматический, приглушенный серый = ручной) или отредактировав config.yaml напрямую. Оба режима сосуществуют с vibeos kanban specify — он по-прежнему доступен в виде переписанной спецификации для одной задачи, если вам не нужно разветвление. – На карточках отображаются идентификатор задачи, заголовок, значок приоритета, тег арендатора, назначенный профиль, количество комментариев /link, таблетка прогресса (дети N/M выполняются, когда у задачи есть зависимые элементы) и «создано N назад». Флажок для каждой карты позволяет осуществлять множественный выбор.
• Дорожки для каждого профиля внутри «Бег» — флажок на панели инструментов переключает подгруппировку столбца «Бег» по ответственному.
• Живые обновления через WebSocket — плагин отслеживает таблицу task_events, предназначенную только для добавления, с коротким интервалом опроса; плата отражает изменения в тот момент, когда действует любой профиль (CLI, шлюз или другая вкладка панели мониторинга). Перезагрузки устраняются, поэтому пакет событий запускает одну повторную выборку.
• Перетаскивайте карты между столбцами, чтобы изменить статус. Падение отправляет PATCH /api/plugins/kanban/tasks/:id, который проходит через тот же код kanban_db, что и CLI, — три поверхности никогда не могут смещаться. Переходит в деструктивные состояния (done, archived, blocked) с запросом подтверждения. Сенсорные устройства используют резервный вариант на основе указателя, поэтому плату можно использовать с планшета.
• Встроенное создание — нажмите + в заголовке любого столбца, чтобы ввести название, ответственного, приоритет и (необязательно) родительскую задачу из раскрывающегося списка для каждой существующей задачи. Нажмите Enter, чтобы создать задачу, Shift+Enter, чтобы вставить новую строку в поле заголовка, или Escape, чтобы отменить ее. Создание из столбца «Сортировка» автоматически помещает новую задачу в сортировку.
• Множественный выбор с массовыми действиями — сдвиньте /ctrl-click карту или установите флажок, чтобы добавить ее в выбор. Вверху появляется панель массовых действий с переходами состояний пакета, архивированием и переназначением (в раскрывающемся списке профиля или «(отменить назначение)»). Разрушительные партии подтверждают в первую очередь. Сообщается о частичных сбоях каждого идентификатора без прерывания остальных.
• Нажмите карту (без Shift/ctrl), чтобы открыть боковой ящик (Escape или щелчок снаружи закрывается) с помощью:
  • Редактируемый заголовок — нажмите заголовок, чтобы переименовать.
  • Редактируемый исполнитель/приоритет — щелкните мета-строку, чтобы переписать ее.
  • Редактируемое описание — по умолчанию отображается markdown (заголовки, жирный, курсив, inline/code blocks, ссылки http(s) / mailto:, списки), с кнопкой «редактировать», которая меняет местами текстовое поле. Рендеринг Markdown — это крошечный, XSS-безопасный рендеринг — каждая замена выполняется на входных данных, экранированных HTML, проходят только ссылки http(s) / mailto:, а target="_blank" + rel="noopener noreferrer" всегда установлены.
  • Редактор зависимостей — список чипов родительских и дочерних элементов, каждый из которых имеет × для отключения, а также раскрывающиеся списки над каждой другой задачей для добавления нового родителя или дочернего элемента. Попытки цикла отклоняются на стороне сервера с четким сообщением.
• Строка действий по состоянию (→ сортировка / → готово / → выполняется / заблокировать / разблокировать / завершить / заархивировать) с запросами на подтверждение деструктивных переходов. Для карточек в столбце Триаж строка также предоставляет два действия, управляемых LLM: ⚗ Разложить задачу по разбивке на граф дочерних задач, перенаправленных в профили специалистов по описанию, а ✨ Указать выполняет перезапись спецификации одной задачи. Decompose возвращается к расширению в стиле спецификации, когда LLM решает, что задача не выиграет от разветвления, поэтому это строгий надмножество. Оба доступны с CLI (vibeos kanban decompose <id> / specify <id> / --all), с любой платформы шлюза (/kanban decompose <id>) и программно через POST /api/plugins/kanban/tasks/:id/decomposeи…/specify. Настройте модели под auxiliary.kanban_decomposerиauxiliary.triage_specifierвconfig.yaml`.
  • Раздел результатов (тоже markdown), ветка комментариев с полем отправки, последние 20 событий.
• Фильтры панели инструментов — поиск по произвольному тексту, раскрывающийся список арендаторов (по умолчанию dashboard.kanban.default_tenant из config.yaml), раскрывающийся список ответственных, переключатель «показать архивированные», переключатель «дорожки по профилю» и кнопка Сдвинуть диспетчера, чтобы вам не приходилось ждать следующих 60 секунд.

Визуально цель представляет собой знакомый макет Linear/Fusion: темная тема, заголовки столбцов со счетчиками, цветные точки состояния, таблички для приоритета и арендатора. Плагин считывает только переменные темы CSS (--color-*, --radius, --font-mono, ...), поэтому он автоматически меняет оформление в зависимости от того, какая тема панели инструментов активна.

Автоматическая и ручная оркестровка

На доске канбан есть два способа выполнения задачи, которую вы помещаете в столбец сортировки:

Авто (по умолчанию) — kanban.auto_decompose: true. Диспетчер, встроенный в шлюз, запускает декомпозер на каждом такте, ограниченном kanban.auto_decompose_per_tick (по умолчанию 3 задачи на такт), поэтому массовая загрузка задач сортировки не приводит к пакетному расходованию вспомогательного LLM. Декомпозер использует встроенную подсказку декомпозиции плюс путь к модели auxiliary.kanban_decomposer, считывает установленные профили + их описания и просит LLM создать граф задач JSON: какие задачи создавать, к кому они переходят и какие от чего зависят. Исходная задача сортировки становится родительской для каждого листа в графе, поэтому она остается активной до тех пор, пока не завершится весь граф, а затем возвращается обратно в ready, чтобы ее ответственный (kanban.orchestrator_profile или активный профиль по умолчанию, если он не установлен) мог оценить завершение и добавить дополнительные задачи, если работа не выполнена. Это принцип «брось остроту и уходи».

Руководство — kanban.auto_decompose: false. Задачи сортировки остаются в сортировке до тех пор, пока вы не начнете действовать. Нажмите кнопку ⚗ Разложить на карточке, запустите vibeos kanban decompose <id> (или --all) или используйте /kanban decompose <id> из чата. Это соответствует поведению платы до декомпозера, что полезно, когда вам нужен полный контроль над тем, что и когда запускается.

Переключайтесь между двумя режимами с помощью таблички Оркестровка: Auto/Manual в верхней части страницы канбана (изумрудный = автоматический, приглушенный серый = ручной) или непосредственно отредактировав config.yaml. Оба режима сосуществуют с vibeos kanban specify — он по-прежнему доступен в виде переписанной спецификации для одной задачи, если вам не нужно разветвление.

Решения по маршрутизации декомпозера зависят от описаний профилей, которые представляют собой примитивы маркировки для каждого профиля, которые вы устанавливаете с помощью vibeos profile create --description "...", vibeos profile describe <name> --text "...", vibeos profile describe <name> --auto (LLM генерируется на основе установленных навыков и модели профиля), или редактора каждого профиля панели мониторинга на расширенной панели Настройки оркестрации. Профили без описания по-прежнему отображаются в списке — их можно маршрутизировать по имени, но с меньшей точностью. Декомпозер NEVER отправляет дочернюю задачу с помощью assignee=None: когда LLM выбирает неизвестный профиль, дочерний элемент перенаправляется на kanban.default_assignee (или на активный профиль по умолчанию, если он не установлен).

kanban.orchestrator_profile не загружает приглашение, навыки или пользовательскую логику этого профиля в вызов декомпозиции. Он контролирует, кому принадлежит задача root/orchestration после разветвления. Чтобы изменить модель декомпозера /provider, настройте auxiliary.kanban_decomposer. Чтобы использовать настраиваемую логику разделения задач профиля вместо встроенного декомпозера, переключитесь в ручной режим и разрешите этому профилю явно создавать или разлагать задачи.

Ручки конфигурации (все под kanban: в ~/.vibeos/config.yaml):

Ключ	По умолчанию	Цель
auto_decompose	true	Диспетчер автоматически запускает декомпозер каждый тик.
auto_decompose_per_tick	3	Ограничение декомпозиции на тик диспетчера. Превышение переносится на следующий тик.
orchestrator_profile	""	Профиль, назначенный задаче root/orchestration после декомпозиции. Пусто = вернуться к активному профилю по умолчанию.
default_assignee	""	Куда попадает дочерняя задача, когда LLM выбирает неизвестный профиль. Пусто = возврат к активному значению по умолчанию.
auto_subscribe_on_create	true	Когда работник вызывает kanban_create из сеанса с постоянным каналом доставки (шлюз сообщений или TUI), исходный сеанс автоматически подписывается на события завершения новой задачи/block. Диспетчер по-прежнему управляет доставкой — это меняет только то, отображается ли чат вызывающего абонента /key в таблице notify-sub. Установите значение false, чтобы требовать явных вызовов kanban_notify-subscribe для каждой задачи.
journal_mode	delete	Журнал SQLite для kanban.db. delete (по умолчанию) позволяет избежать гонок контрольных точек WAL, когда много рабочих подключаются к /close для каждого утверждения. Устанавливайте wal только для намеренного согласия; существующие платы WAL остаются на WAL.

И два вспомогательных слота LLM:

Ключ	Цель
auxiliary.kanban_decomposer	Модель, создающая граф задач (вызываемая Decompose). Установите provider/model, чтобы переопределить модель основного чата.
auxiliary.profile_describer	Модель, которая автоматически генерирует описания профилей (вызывается vibeos profile describe --auto).

Архитектура

GUI представляет собой строго уровень чтения через БД + сквозной записи-kanban_db без собственной доменной логики:

<!-- ascii-guard-ignore -->

┌────────────────────────┐      WebSocket (tails task_events)
│   React SPA (plugin)   │ ◀──────────────────────────────────┐
│   HTML5 drag-and-drop  │                                    │
└──────────┬─────────────┘                                    │
           │ REST over fetchJSON                              │
           ▼                                                  │
┌────────────────────────┐     writes call kanban_db.*        │
│  FastAPI router        │     directly — same code path      │
│  plugins/kanban/       │     the CLI /kanban verbs use      │
│  dashboard/plugin_api.py                                    │
└──────────┬─────────────┘                                    │
           │                                                  │
           ▼                                                  │
┌────────────────────────┐                                    │
│  ~/.vibeos/kanban.db   │ ───── append task_events ──────────┘
│  (WAL, shared)         │
└────────────────────────┘

<!-- ascii-guard-ignore-end -->

REST поверхность

Все маршруты монтируются под /api/plugins/kanban/ и защищены эфемерным токеном сеанса панели управления:

Метод	Путь	Цель
GET	/board?tenant=<name>&include_archived=…	Полный пансион сгруппирован по столбцу статуса, а также арендаторы + исполнительи для раскрывающихся списков фильтров
GET	/tasks/:id	Задача + комментарии + события + ссылки
POST	/tasks	Создать (обертывает kanban_db.create_task, принимает triage: bool и parents: [id, …])
PATCH	/tasks/:id	Статус/исполнитель/приоритет/название/орган/результат
POST	/tasks/bulk	Примените один и тот же патч (статус/архив/исполнитель/приоритет) к каждому идентификатору в ids. Сообщается об ошибках каждого идентификатора без прерывания одноуровневых элементов
POST	/tasks/:id/comments	Добавить комментарий
POST	/tasks/:id/specify	Запустите спецификатор сортировки — вспомогательный LLM расширяет тело задачи и повышает его уровень с triage до todo. Возвращает {ok, task_id, reason, new_title}; ok=false с понятной для человека причиной «не в сортировке» / нет дополнительного клиента / ошибка LLM — 200, а не 4xx
POST	/tasks/:id/decompose	Запустите декомпозер канбана — вспомогательный LLM создает граф задач, а помощник атомарно создает дочерние элементы + связывает корень + переворачивает triage → todo. Возвращает {ok, task_id, reason, fanout, child_ids, new_title}. То же соглашение об ошибках 200-на-LLM, что и /specify.
GET	/profiles	Перечислите установленные профили с их описаниями (используемые редактором описаний профилей панели мониторинга и средством выбора оркестратора).
PATCH	/profiles/:name	Установить или очистить описание профиля (авторское — description_auto: false). Возвращает {ok, profile, description}.
POST	/profiles/:name/describe-auto	Создайте описание профиля с помощью auxiliary.profile_describer. Сохраняется с description_auto: true, поэтому на панели мониторинга может отображаться значок «отзыв».
GET	/orchestration	Прочтите настройки оркестрации канбана (orchestrator_profile, default_assignee, auto_decompose), а также разрешенные эффективные значения после отката.
PUT	/orchestration	Обновите один или несколько из трех ключей оркестровки в config.yaml. Проверяет, действительно ли существуют непустые имена профилей.
POST	/links	Добавить зависимость (parent_id → child_id)
DELETE	/links?parent_id=…&child_id=…	Удалить зависимость
POST	/dispatch?max=…&dry_run=…	Подтолкнуть диспетчера — пропустить 60 секунд ожидания
GET	/config	Прочитайте настройки dashboard.kanban от config.yaml — default_tenant, lane_by_profile, include_archived_by_default, render_markdown
WS	`/events?since=<event_id>	Прямая трансляция строк task_events

Каждый обработчик представляет собой тонкую обертку — плагин состоит из примерно 700 строк Python (маршрутизатор + хвост WebSocket + пакетный пакетатор + средство чтения конфигурации) и не добавляет никакой новой бизнес-логики. Крошечный помощник _conn() автоматически инициализирует kanban.db при каждом чтении и записи, поэтому новая установка работает независимо от того, открыл ли пользователь сначала панель управления, нажал REST API напрямую или запустил vibeos kanban init.

Конфигурация панели управления

Любой из этих ключей под dashboard.kanban в ~/.vibeos/config.yaml изменяет настройки вкладки по умолчанию — плагин считывает их во время загрузки через GET /config:

dashboard:
  kanban:
    default_tenant: acme              # preselects the tenant filter
    lane_by_profile: true             # default for the "lanes by profile" toggle
    include_archived_by_default: false
    render_markdown: true             # set false for plain <pre> rendering

Каждый ключ является необязательным и возвращает значение по умолчанию.

Модель безопасности

Промежуточное программное обеспечение аутентификации HTTP панели мониторинга явно пропускает /api/plugins/ — маршруты плагина не аутентифицируются по своей конструкции, поскольку панель мониторинга по умолчанию привязывается к локальному хосту. Это означает, что поверхность канбана REST доступна из любого процесса на хосте.

WebSocket делает еще один шаг: ему требуется эфемерный токен сеанса панели мониторинга в качестве параметра запроса ?token=… (браузеры не могут установить Authorization в запросе на обновление), соответствующий шаблону, используемому мостом PTY в браузере.

Если вы запустите vibeos dashboard --host 0.0.0.0, каждый маршрут плагина, включая канбан, станет доступен из сети. Не делайте этого на общем хосте. Доска содержит тела задач, комментарии и пути к рабочей области; Злоумышленник, достигший этих маршрутов, получает доступ для чтения ко всей вашей поверхности для совместной работы, а также может создавать, переназначать и архивировать задачи.

Задачи в ~/.vibeos/kanban.db специально не зависят от профиля (это примитив координации). Если вы откроете панель управления с помощью vibeos -p <profile> dashboard, на доске по-прежнему будут отображаться задачи, созданные любым другим профилем на хосте. Все профили принадлежат одному и тому же пользователю, но об этом стоит знать, если одновременно существует несколько персон.

Постоянные обновления

task_events — это таблица SQLite, предназначенная только для добавления, с монотонным id. Конечная точка WebSocket хранит идентификатор последнего события каждого клиента и отправляет новые строки по мере их поступления. Когда поступает пакет событий, интерфейс перезагружает (очень дешевую) конечную точку платы — это проще и правильнее, чем пытаться исправить локальное состояние для каждого типа событий. Режим WAL означает, что цикл чтения никогда не блокирует транзакции утверждений BEGIN IMMEDIATE диспетчера.

Расширяем его

Плагин использует стандартный контракт плагина информационной панели VibeOS — см. Расширение информационной панели для получения полной ссылки на манифест, слоты оболочки, слоты на уровне страниц и плагин SDK. Дополнительные столбцы, настраиваемый хром карточек, макеты с фильтрацией арендаторов или полные замены tab.override — все это можно реализовать без разветвления этого плагина.

Чтобы отключить без удаления: добавьте dashboard.plugins.kanban.enabled: false к config.yaml (или удалите plugins/kanban/dashboard/manifest.json).

Граница области действия

GUI намеренно тонкий. Все, что делает плагин, доступно из CLI; плагин просто делает его удобным для людей. Автоматическое назначение, бюджеты, элементы управления и представления организационной диаграммы остаются в пользовательском пространстве — профиль маршрутизатора, другой плагин или повторное использование tools/approval.py — точно так, как указано в разделе «Выход за рамки» спецификации дизайна.

CLI Справочник по командам

Это поверхность, которую вы (или скрипты, cron, панель управления) используете для управления платой. Рабочие, работающие внутри диспетчера, используют kanban_* поверхность инструмента для одних и тех же операций — CLI здесь и инструменты там маршрутизируются через kanban_db, поэтому обе поверхности согласованы по конструкции.

vibeos kanban init                                     # create kanban.db + print daemon hint
vibeos kanban create "<title>" [--body ...] [--assignee <profile>]
                                [--parent <id>]... [--tenant <name>]
                                [--workspace scratch|worktree|worktree:<path>|dir:<path>]
                                [--branch <name>]
                                [--priority N] [--triage] [--idempotency-key KEY]
                                [--max-runtime 30m|2h|1d|<seconds>]
                                [--max-retries N]
                                [--goal] [--goal-max-turns N]
                                [--skill <name>]...
                                [--json]
vibeos kanban list [--mine] [--assignee P] [--status S] [--tenant T] [--archived]
        [--workflow-template-id <id>] [--current-step-key <key>]
        [--sort created|created-desc|priority|priority-desc|status|assignee|title|updated]
        [--json]
vibeos kanban show <id> [--json]
vibeos kanban assign <id> <profile>                    # or 'none' to unassign
vibeos kanban reassign <id>... <profile>               # bulk re-assign tasks to a profile
vibeos kanban edit <id> [--title ...] [--body ...]     # edit task title / body / priority in place
        [--priority N]
vibeos kanban promote <id>...                          # move todo/blocked tasks to ready (recovery)
vibeos kanban schedule <id> --at <ISO8601>             # set/clear a task's scheduled_at start time
vibeos kanban diagnostics [--json]                     # board health snapshot (alias: diag)
vibeos kanban link <parent_id> <child_id>
vibeos kanban unlink <parent_id> <child_id>
vibeos kanban claim <id> [--ttl SECONDS]
vibeos kanban comment <id> "<text>" [--author NAME]

# Bulk verbs — accept multiple ids:
vibeos kanban complete <id>... [--result "..."]
vibeos kanban block <id> "<reason>" [--ids <id>...]
vibeos kanban unblock <id>...
vibeos kanban archive <id>...

vibeos kanban tail <id>                                # follow a single task's event stream
vibeos kanban watch [--assignee P] [--tenant T]        # live stream ALL events to the terminal
        [--kinds completed,blocked,…] [--interval SECS]
vibeos kanban heartbeat <id> [--note "..."]            # worker liveness signal for long ops
vibeos kanban runs <id> [--json]                       # attempt history (one row per run)
vibeos kanban assignees [--json]                       # profiles on disk + per-assignee task counts
vibeos kanban dispatch [--dry-run] [--max N]           # one-shot pass
        [--failure-limit N] [--json]
vibeos kanban daemon --force                           # DEPRECATED — standalone dispatcher (use `vibeos gateway start` instead)
        [--failure-limit N] [--pidfile PATH] [-v]
vibeos kanban stats [--json]                           # per-status + per-assignee counts
vibeos kanban log <id> [--tail BYTES]                  # worker log from ~/.vibeos/kanban/logs/
vibeos kanban notify-subscribe <id>                    # gateway bridge hook (used by /kanban in the gateway)
        --platform <name> --chat-id <id> [--thread-id <id>] [--user-id <id>]
vibeos kanban notify-list [<id>] [--json]
vibeos kanban notify-unsubscribe <id>
        --platform <name> --chat-id <id> [--thread-id <id>]
vibeos kanban context <id>                             # what a worker sees
vibeos kanban specify [<id> | --all] [--tenant T]      # flesh out a triage-column idea
        [--author NAME] [--json]                       #   into a full spec and promote to todo
vibeos kanban gc [--event-retention-days N]            # workspaces + old events + old logs
        [--log-retention-days N]

Все команды также доступны как slash-команда в интерактивном CLI и в шлюзе обмена сообщениями (см. slash-команда /kanban ниже).

--max-retries — это блокировка автоматического выключателя для каждой задачи диспетчера. --max-retries 1 блокирует задачу при первой неудачной попытке, а --max-retries 3 разрешает две повторные попытки и блокирует третью неудачную попытку. Опустите его, чтобы использовать kanban.failure_limit из config.yaml, а затем встроенную настройку по умолчанию.

Конфигурация параллелизма, планирования и дочернего продвижения

Конфигурационный ключ	По умолчанию	Что он делает
kanban.max_in_progress	отключено (без ограничений)	Ограничивает количество одновременно выполняемых задач. Когда на плате уже работает N, диспетчер пропускает создание большего количества — это полезно для медленных работников (локальные LLM, хосты с ограниченными ресурсами), чтобы они закончили то, что у них есть, до того, как накопится еще больше и истечет время ожидания. Недопустимые значения или значения ниже 1 регистрируют предупреждение и ведут себя как неограниченные.
kanban.max_in_progress_per_profile	отключено (без ограничений)	Вариант max_in_progress для каждого профиля — ограничивает количество задач, которые может выполнять одновременно один профиль уполномоченного. Полезно, когда один профиль медленный или имеет ограниченную скорость, но другие должны продолжать работать. Применяется вместе с max_in_progress для всей платы; оба должны разрешить появление, чтобы оно продолжилось.
kanban.auto_promote_children	true	После того как decompose_triage_task() создает дочерние элементы без зависимостей родительского блокировщика, они автоматически повышаются до ready, чтобы диспетчер мог их забрать. Установите false, чтобы требовать проверки вручную — дети остаются в todo, пока вы не повысите их.
kanban.default_workdir	не установлен	Рабочий каталог по умолчанию на уровне платы применяется к новым задачам, когда ни --workspace, ни сама задача не переопределяют его. Для каждой задачи workspace: по-прежнему побеждает.

kanban:
  max_in_progress: 2
  auto_promote_children: false
  default_workdir: ~/work/active-project

Запуск запланированного задания (scheduled_at)

Установите scheduled_at на задачу, чтобы отложить отправку до определенного времени. Диспетчер пропускает готовые задачи, scheduled_at которых находится в будущем, и подхватывает их на первом тике после этой метки времени.

vibeos kanban create "nightly backup audit" \
  --assignee ops --scheduled-at "2026-06-01T03:00:00Z"

Респаун охранник

Диспетчер отказывается повторно запускать готовую задачу, если при предыдущем запуске (blocker_auth) возникла ошибка quota/auth/429, успешно завершился запуск в защитном окне (recent_success) или если недавний комментарий к задаче ссылается на PR GitHub (active_pr). Это предотвращает повторные атаки рабочих на одну и ту же ошибку или задачу, пока человек их догоняет. См. строку respawn_guarded в ссылка на событие.

Удаление с помощью перетаскивания и массовое удаление (панель управления)

На панели управления отображается зона удаления мусора на странице канбана — перетащите в нее любую карточку, чтобы удалить задачу (каскадно через task_events, дочерние ссылки и подписки). Запрос подтверждения защищает от несчастных случаев. Массовое удаление также доступно через DELETE /api/plugins/kanban/tasks с телом JSON {"ids": ["t_abc", "t_def", ...]}.

Конечные точки видимости работников

Плагин информационной панели API теперь предоставляет эти конечные точки только для чтения (плюс команду управления запуском) для внешних мониторов:

Конечная точка	Возврат
GET /api/plugins/kanban/workers/active	В настоящее время созданы рабочие с PID, профилем, идентификатором задачи, началом, последним контрольным сигналом
GET /api/plugins/kanban/runs/{id}	Подробности однократного запуска — идентификатор задачи, статус, запуск /ended, код выхода, путь к журналу
POST /api/plugins/kanban/runs/{run_id}/terminate	Завершить возвратный прогон — останавливает работника и освобождает задачу для повторной отправки
GET /api/plugins/kanban/inspect	Комбинированный снимок диспетчера — журнал невыполненной работы, количество незавершенных работ по сравнению с max_in_progress, последние события

Все они защищены той же аутентификацией плагина панели управления, что и остальная часть плагина канбана API.

Помощник по топологии Kanban Swarm

vibeos kanban swarm создает надежный график Kanban Swarm v1 за один раз: завершенную корневую карту /blackboard, N параллельных рабочих карт, карту верификатора, доступную для всех рабочих, и карту синтезатора, доступную верификатору. Общий контекст роя («классная доска») хранится в виде структурированных комментариев JSON на корневой карте, поэтому любой работник может его прочитать.

vibeos kanban swarm "Design a multi-region failover plan" \
  --workers researcher,architect,sre \
  --verifier reviewer --synthesizer writer

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

/kanban slash-команда

Каждый глагол vibeos kanban <action> также доступен как /kanban <action> — из интерактивного сеанса vibeos chat и с любой платформы шлюза (Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost, электронная почта, SMS). Обе поверхности вызывают одну и ту же точку входа vibeos_cli.kanban.run_slash(), которая повторно использует дерево аргументов vibeos kanban, поэтому поверхность аргументов, флаги и формат вывода идентичны в CLI, /kanban и vibeos kanban. Чтобы управлять доской, не обязательно выходить из чата.

/kanban list
/kanban show t_abcd
/kanban create "write launch post" --assignee writer --parent t_research
/kanban comment t_abcd "looks good, ship it"
/kanban unblock t_abcd
/kanban dispatch --max 3
/kanban specify t_abcd                  # flesh out a triage one-liner into a real spec
/kanban specify --all --tenant engineering  # sweep every triage task in one tenant

Аргументы, состоящие из нескольких слов, заключайте в кавычки так же, как и в оболочке: run_slash анализирует остальную часть строки с помощью shlex.split, поэтому "..." и '...' работают.

Использование в середине запуска: /kanban обходит защиту работающего агента

Шлюз обычно ставит в очередь команды и пользовательские сообщения, пока агент еще думает — именно это удерживает вас от случайного запуска второго хода, пока первый находится в полете. /kanban явно освобожден от этой защиты. Плата находится в ~/.vibeos/kanban.db, а не в состоянии работающего агента, поэтому читается (list, show, context, tail, watch, stats, runs) и пишет (comment, unblock, block, assign, archive, create, link, …) все проходит сразу, даже в середине хода.

В этом вся суть разделения:

• Рабочий блокирует ожидание узла → вы отправляете /kanban unblock t_abcd со своего телефона, и диспетчер подхватывает узел при следующем тике. Заблокированный работник не прерывается — он просто перестает блокироваться.
• Вы заметили карточку, требующую человеческого контекста → /kanban comment t_xyz "use the 2026 schema, not 2025" попадает в поток задачи, и следующий запуск этой задачи прочитает ее в kanban_show().
• Вы хотите знать, что делает ваш автопарк, не останавливая оркестратор → /kanban list --mine или /kanban stats проверяет доску, не касаясь вашего основного разговора.

Автоматическая подписка на /kanban create (только шлюз)

Когда вы создаете задачу из шлюза с помощью /kanban create "…", исходный чат (платформа + идентификатор чата + идентификатор потока) автоматически подписывается на события терминала этой задачи (completed, blocked, gave_up, crashed, timed_out). Вы получите одно сообщение обратно для каждого события терминала, включая первую строку сводки результатов работника на completed, без необходимости опроса или запоминания идентификатора задачи.

you> /kanban create "transcribe today's podcast" --assignee transcriber
bot> Created t_9fc1a3  (ready, assignee=transcriber)
     (subscribed — you'll be notified when t_9fc1a3 completes or blocks)

… ~8 minutes later …

bot> ✓ t_9fc1a3 completed by transcriber
     transcribed 42 minutes, saved to podcast/2026-05-04.md

Подписки автоматически удаляются, как только задача достигает done или archived. Если вы создаете сценарий создания с помощью --json (машинный вывод), автоматическая подписка пропускается — предполагается, что вызывающие программы по сценарию хотят управлять подписками явно через /kanban notify-subscribe.

Усечение вывода при обмене сообщениями

Платформы шлюзов имеют практичные ограничения на длину сообщений. Если /kanban list, /kanban show или /kanban tail выдают более ~3800 символов, ответ усекается с помощью нижнего колонтитула … (truncated; use \vibeos канбан …` in your terminal for full output)`. Поверхность CLI не имеет такой крышки.

Автозаполнение

В интерактивном CLI введите /kanban и нажимайте Tab, просматривая встроенный список подкоманд (list, ls, show, create, assign, link, unlink, claim, comment, complete, block, unblock, archive, tail, dispatch, context, init, gc). Остальные глаголы, перечисленные в ссылке на CLI выше (watch, stats, runs, log, assignees, heartbeat, notify-subscribe, notify-list, notify-unsubscribe, daemon) тоже работают — просто их еще нет в списке подсказок автозаполнения.

Шаблоны сотрудничества

Плата поддерживает эти восемь шаблонов без каких-либо новых примитивов:

Узор	Форма	Пример
Разветвление P1	N братьев и сестер, одна и та же роль	«исследовать 5 углов параллельно»
Трубопровод P2	ролевая цепочка: разведчик → редактор → писатель	ежедневная краткая сборка
Голосование/кворум P3	N братьев и сестер + 1 агрегатор	3 исследователя → выбор 1 рецензента
P4 Долгосрочный журнал	тот же профиль + общий каталог + cron	Обсидиановый свод
P5 Человек в курсе событий	рабочие блоки → комментарии пользователей → разблокировать	неоднозначные решения
P6 @mention	инлайн-маршрутизация из прозы	@reviewer look at this
Рабочая область P7 с областью действия потока	/kanban here в теме	потоки шлюза для каждого проекта
P8 Флотское фермерство	один профиль, N предметов	50 социальных аккаунтов
Спецификатор сортировки P9	приблизительная идея → triage → vibeos kanban specify расширяет корпус → todo	«превратить эту однострочную фразу в конкретную задачу»

Рабочие примеры каждого из них см. в docs/vibeos-kanban-v1-spec.pdf.

Мультитенантное использование

Tenant — это мягкое пространство имен внутри одной платы. доска остается твердой граница (VIBEOS_KANBAN_BOARD). Используйте арендаторов, когда один специализированный автопарк (профили+диспетчер) обслуживает несколько клиентов/products без раскрутки отдельная доска для каждого клиента.

Модель изоляции

Слой	Что он изолирует	Как
Совет	Задачи, БД, рабочие области, область действия диспетчера	vibeos kanban boards create … / --board
Арендатор	Мягкий фильтр + соглашение об операциях	--tenant <slug>` при создании/list/watch
Путь к рабочей области	Данные файла на каждого клиента	--workspace dir:~/tenants/&lt;slug&gt;/…
Память	Программный префикс, если установлен $VIBEOS_TENANT	Рабочие наследуют env от диспетчера

Арендаторы не создают отдельные файлы SQLite. Фильтрация осуществляется tenant. столбец. Межклиентская видимость возможна, если оркестратор опускает --tenant. — воспринимайте это как преднамеренную (сортировку по всему флоту) или как стрельбу.

Рецепт А — два предприятия, общий парк кодеров/reviewer

# Shared board (once)
vibeos kanban boards create agency --name "Agency fleet"

# Client A intake
vibeos kanban create "monthly report" \
  --board agency \
  --assignee researcher \
  --tenant business-a \
  --workspace dir:$HOME/tenants/business-a/data/

# Client B intake
vibeos kanban create "invoice audit" \
  --board agency \
  --assignee researcher \
  --tenant business-b \
  --workspace dir:$HOME/tenants/business-b/data/

# Operator views
vibeos kanban list --board agency --tenant business-a
vibeos kanban watch --board agency --tenant business-b
vibeos kanban specify --all --tenant business-a

Панель инструментов: установите dashboard.kanban.default_tenant: business-a в config.yaml. поэтому фильтр арендаторов открывается для клиента, который вам нужен сегодня.

Рецепт Б — дорожки продуктов на одной доске

vibeos kanban create "rate limit API" --assignee coder --tenant api --workspace worktree
vibeos kanban create "billing UI polish" --assignee coder --tenant web --workspace worktree
vibeos kanban list --tenant api

Объедините арендаторов с досками, привязанными к проекту, если вам также нужен детерминированный подход Имена рабочего дерева/branch (vibeos project bind-board + --workspace worktree). См. навык project-kanban-worktrees.

###Рецепт C — автоматизация/вебхуки с идемпотентностью

vibeos kanban create "sync CRM contacts" \
  --assignee worker \
  --tenant acme \
  --idempotency-key "acme-crm-sync-$(date -u +%Y%m%d)" \
  --workspace dir:$HOME/tenants/acme/crm/

Повторные веб-перехватчики с тем же ключом повторно используют существующую задачу вместо двойной нерест.

Контрольный список оператора

1. Отдавайте предпочтение одной доске на парк, арендаторам на каждого клиента, а не одной доске на каждого клиента. (если только клиенты никогда не должны совместно использовать диспетчер или БД).
2. Всегда передавайте абсолютные пути к рабочей области dir: (относительный dir: отклоняется).
3. Фильтр с --tenant в списке /watch/specify/decompose развертки.
4. Не полагайтесь на секретность только арендатора — используйте отдельный env/profiles, если учетные данные различаются.
5. vibeos kanban stats/раскрывающийся список арендатора информационной панели для проверки работоспособности каждого клиента.

Рабочие получают $VIBEOS_TENANT и должны использовать пути к памяти/чистым пространствам имен этот префикс при записи устойчивых данных клиента.

Уведомления шлюза

Когда вы запускаете /kanban create … со шлюза (Telegram, Discord, Slack и т. д.), исходный чат автоматически подписывается на новую задачу. Фоновый уведомитель шлюза опрашивает task_events каждые несколько секунд и доставляет в этот чат одно сообщение на каждое событие терминала (completed, blocked, gave_up, crashed, timed_out). Завершенные задачи также отправляют первую строку --result работника, чтобы вы могли видеть результат без необходимости использовать /kanban show.

Вы можете напрямую управлять подписками из CLI — это полезно, когда задание скрипта/хрона хочет уведомить чат, из которого оно не создано:

vibeos kanban notify-subscribe t_abcd \
    --platform telegram --chat-id 12345678 --thread-id 7
vibeos kanban notify-list
vibeos kanban notify-unsubscribe t_abcd \
    --platform telegram --chat-id 12345678 --thread-id 7

Подписка автоматически удаляется, как только задача достигает done или archived; очистка не требуется.

Запуски — одна строка за попытку

Задача — это логическая единица работы; run — это одна попытка выполнить его. Когда диспетчер заявляет о готовности задачи, он создает строку в task_runs и указывает на нее tasks.current_run_id. Когда эта попытка заканчивается — завершена, заблокирована, аварийно завершена, истекло время ожидания, неудачно создано, возвращено — строка выполнения закрывается с помощью outcome, и указатель задачи очищается. Задача, которая была предпринята три раза, имеет три строки task_runs.

Зачем две таблицы вместо простого изменения задачи: вам нужна полная история попыток для реальных анализов («вторая попытка рецензента должна быть одобрена, третья объединена»), и вам нужно чистое место для хранения метаданных по каждой попытке — какие файлы были изменены, какие тесты были проведены, какие результаты отметил рецензент. Это факты выполнения, а не факты задач.

Забеги также являются местом, где живет структурированная передача. Когда работник выполняет задачу (через kanban_complete(...)), он может передать:

• summary (параметр инструмента) / --summary (CLI) — передача управления человеком; бежит; последующие дети видят это в своих build_worker_context.
• metadata (параметр инструмента) / --metadata (CLI) — дикт JSON в свободной форме на ходу; дети видят его в сериале рядом с кратким изложением.
• result (параметр инструмента) / --result (CLI) — короткая строка журнала, которая идет в строке задачи (устаревшее поле, сохранено для обратной совместимости).

Нижестоящие дети читают сводку последнего завершенного прогона + метаданные для каждого родителя. Повторные работники читают предыдущие попытки выполнения своей задачи (результат, сводка, ошибка), чтобы не повторять путь, который уже потерпел неудачу.

# What a worker actually does — a tool call, from inside the agent loop:
kanban_complete(
    summary="implemented token bucket, keys on user_id with IP fallback, all tests pass",
    metadata={"changed_files": ["limiter.py", "tests/test_limiter.py"], "tests_run": 14},
    result="rate limiter shipped",
)

Такая же передача обслуживания доступна с CLI, когда вам (человеку) нужно закрыть задачу, которую работник не может выполнить — например. задача, которая была заброшена или которую вы отметили как выполненную вручную на панели управления:

vibeos kanban complete t_abcd \
    --result "rate limiter shipped" \
    --summary "implemented token bucket, keys on user_id with IP fallback, all tests pass" \
    --metadata '{"changed_files": ["limiter.py", "tests/test_limiter.py"], "tests_run": 14}'

# Review the attempt history on a retried task:
vibeos kanban runs t_abcd
#   #  OUTCOME       PROFILE           ELAPSED  STARTED
#   1  blocked       worker               12s  2026-04-27 14:02
#        → BLOCKED: need decision on rate-limit key
#   2  completed     worker                8m   2026-04-27 15:18
#        → implemented token bucket, keys on user_id with IP fallback

Запуски отображаются на информационной панели (раздел «История выполнения» в ящике, одна цветная строка для каждой попытки) и в REST API (GET /api/plugins/kanban/tasks/:id возвращает массив runs[]). PATCH /api/plugins/kanban/tasks/:id с {status: "done", summary, metadata} пересылают оба в ядро, поэтому кнопка «Отметить выполненное» на информационной панели эквивалентна CLI. Строки task_events содержат run_id, которому они принадлежат, поэтому пользовательский интерфейс может группировать их при попытке, а событие completed встраивает сводку первой строки в свою полезную нагрузку (ограниченную 400 символами), поэтому уведомители шлюза могут отображать структурированные передачи обслуживания без второго двустороннего обхода SQL.

Предупреждение о массовом закрытии. vibeos kanban complete a b c --summary X отклоняется — структурированная передача обслуживания выполняется для каждого запуска, поэтому копирование одной и той же сводки для N задач почти всегда является неправильным. Массовое закрытие без --summary / --metadata по-прежнему работает в обычном случае «Я выполнил кучу административных задач».

Восстановленные запуски в результате изменения статуса. Если вы перетащите выполняющуюся задачу из running на панели управления (обратно в ready или прямо в todo) или заархивируете задачу, которая все еще выполнялась, текущий запуск закроется с outcome='reclaimed', а не останется потерянным. Строка task_runs всегда находится в конечном состоянии, когда tasks.current_run_id — это NULL, и наоборот — этот инвариант сохраняется для CLI, информационной панели, диспетчера и уведомителя.

Синтетические запуски для никогда не заявленных завершений. Завершение или блокировка задачи, которая никогда не была заявлена ​​(например, человек закрывает задачу ready на информационной панели со сводкой или пользователь CLI запускает vibeos kanban complete <ready-task> --summary X) в противном случае приведет к прекращению передачи обслуживания. Вместо этого ядро ​​вставляет строку запуска нулевой длительности (started_at == ended_at), содержащую сводку/метаданные/причину, поэтому история попыток остается полной. run_id события completed/blocked указывает на эту строку.

Живое обновление ящика. Когда поток событий WebSocket панели мониторинга сообщает о новых событиях для задачи, которую пользователь в данный момент просматривает, ящик перезагружается (через счетчик событий для каждой задачи, связанный с его списком зависимостей useEffect). Закрытие и повторное открытие больше не требуется, чтобы увидеть новую строку выполнения или обновленный результат.

Прямая совместимость

Два столбца с нулевым значением в tasks зарезервированы для маршрутизации рабочего процесса версии 2: workflow_template_id (какому шаблону принадлежит эта задача) и current_step_key (какой шаг в этом шаблоне активен). Ядро v1 игнорирует их при маршрутизации, но позволяет клиентам записывать их, поэтому в версии v2 можно добавить механизм маршрутизации без другой миграции схемы.

Ссылка на событие

Каждый переход добавляет строку к task_events. Каждая строка содержит необязательный run_id, поэтому пользовательский интерфейс может группировать события по попыткам. Виды группируются в три кластера, что упрощает фильтрацию (vibeos kanban watch --kinds completed,gave_up,timed_out):

Жизненный цикл (что изменилось в задаче как логической единице):

Вид	Полезная нагрузка	Когда
created	{assignee, status, parents, tenant}	Задача вставлена. run_id — это NULL.
promoted	—	todo → ready, потому что все родители нажали done. run_id — это NULL.
claimed	{lock, expires, run_id}	Диспетчер атомарно запросил задачу ready для появления.
completed	{result_len, summary?}	Рабочий написал --result/--summary, и задача попала в done. summary — передача обслуживания первой линии (ограничение в 400 символов); полная версия живет в строке запуска. Если complete_task вызывается для никогда не заявленной задачи с полями передачи обслуживания, синтезируется прогон нулевой длительности, поэтому run_id все еще указывает на что-то.
blocked	{reason, kind, recurrences}	Рабочий или человек переключил задачу на blocked. kind — причина типизированной блокировки (needs_input, capability, transient или null для универсального блока); recurrences — счетчик цикла разблокировки. Синтезирует выполнение нулевой продолжительности при вызове никогда не востребованной задачи с помощью --reason.
dependency_wait	{reason, kind}	Рабочий блок заблокирован с помощью kind=dependency — задача ожидает только другой задачи, поэтому она маршрутизируется на todo (с родительским контролем, автоматическое продвижение) вместо blocked. Никакой человек не нужен.
block_loop_detected	{reason, kind, recurrences, limit}	Задача была разблокирована и повторно заблокирована по той же причине BLOCK_RECURRENCE_LIMIT раз (по умолчанию 2). Вместо того, чтобы снова попасть в blocked — где cron будет продолжать его разблокировать — он направляется к triage для принятия человеком решения, разрывая цикл разблокировки↔повторной блокировки.
unblocked	—	blocked → ready (или todo, если родительские элементы еще открыты), либо вручную, либо через /unblock. Сбрасывает consecutive_failures диспетчера, но намеренно сохраняет block_recurrences, чтобы прерыватель цикла сохранил свою память. run_id — это NULL.
archived	—	Скрыто с доски по умолчанию. Если задача все еще выполнялась, она содержит run_id выполнения, которое было возвращено как побочный эффект.

Редактирование (внесенные человеком изменения, не являющиеся переходами):

Вид	Полезная нагрузка	Когда
assigned	{assignee}	Исполнитель изменен (включая отмену назначения).
edited	{fields}	Заголовок или тело обновлено.
reprioritized	{priority}	Приоритет изменился.
status	{status}	Перетаскивание панели мониторинга напрямую записывает статус (например, todo → ready). Содержит run_id пробега, который был возвращен при перетаскивании running; в противном случае run_id — это NULL.

Рабочая телеметрия (о процессе выполнения, а не о логической задаче):

Вид	Полезная нагрузка	Когда
spawned	{pid}	Диспетчер успешно запустил рабочий процесс.
heartbeat	{note?}	Рабочий позвонил vibeos kanban heartbeat $TASK, чтобы сигнализировать о работоспособности во время длительных операций.
reclaimed	{stale_lock}	Срок действия претензии TTL истек, а завершение не выполнено; задача возвращается к ready.
crashed	{pid, claimer}	Рабочего PID больше нет в живых, но срок действия TTL еще не истек.
timed_out	{pid, elapsed_seconds, limit_seconds, sigkill}	max_runtime_seconds превышен; диспетчер SIGTERM (затем SIGKILL через 5 секунд) и повторно поставил в очередь.
stale	{elapsed_seconds, last_heartbeat_at, heartbeat_age_seconds, timeout_seconds, pid, terminated}	Задача выполнялась дольше, чем kanban.dispatch_stale_timeout_seconds (по умолчанию 4 часа). AND За последний час kanban_heartbeat не прибыл. Диспетчер SIGTERM вызвал локального рабочего процесса (если таковой имеется) и сбросил задачу на ready для повторной отправки. Отмечает ли NOT счетчик ошибок (устаревшее — это обнаружение отсутствия на стороне диспетчера, а не ошибка работника). Во избежание этого работникам, выполняющим длительные операции, следует звонить по номеру kanban_heartbeat не реже одного раза в час.
respawn_guarded	{reason}	Диспетчер отказался повторно создать эту готовую задачу в этом галочке. Причины: blocker_auth (последний сбой связан с ошибкой quota/auth/429 — дождитесь сброса окна ставок), recent_success (завершенный запуск произошел в течение последнего часа — дождитесь проверки перед повторным запуском), active_pr (в недавнем комментарии появляется PR GitHub URL — предыдущий работник уже открыл PR). Задача остается в ready; следующий тик получает еще один шанс появиться. Если основное состояние сохраняется, обычный автоматический выключатель consecutive_failures автоматически блокируется через gave_up после сбоев failure_limit.
spawn_failed	{error, failures}	Одна попытка создания не удалась (отсутствует PATH, рабочая область не монтируется, …). Счетчик приращений; задача возвращается в ready для повторной попытки.
protocol_violation	{pid, claimer, exit_code}	Рабочий процесс успешно завершился, пока задача все еще была running, обычно потому, что он ответил без вызова kanban_complete или kanban_block. Диспетчер также выдает gave_up и немедленно автоматически блокирует вместо повторной попытки.
gave_up	{failures, effective_limit, limit_source, error}	Автоматический выключатель сработал после N неудачных попыток подряд. Задача автоматически блокируется при последней ошибке. Действующее ограничение определяется как задача max_retries, затем диспетчер failure_limit/kanban.failure_limit, затем встроенное значение по умолчанию.

vibeos kanban tail <id> показывает их для одной задачи. vibeos kanban watch` передает их по всей плате.

Вне области видимости

Канбан намеренно использует один хост. ~/.vibeos/kanban.db — это локальный файл SQLite, и диспетчер создает рабочие процессы на той же машине. Использование общей платы на двух хостах не поддерживается — не существует примитива координации для «работника X на хосте A, рабочего Y на хосте B», а путь обнаружения сбоев предполагает, что PID являются локальными для хоста. Если вам нужно несколько хостов, запустите независимую плату для каждого хоста и используйте delegate_task / очередь сообщений для их соединения.

Спецификация дизайна

Полный проект — архитектура, корректность параллелизма, сравнение с другими системами, план реализации, риски, открытые вопросы — находится в docs/vibeos-kanban-v1-spec.pdf. Прочтите это, прежде чем подавать заявку на изменение поведения.