Рабочие линии канбана

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

Эта страница — контракт. Она существует для двух аудиторий:

• Операторов, выбирающих, какие линии подключить к доске (какие профили создать, каких исполнителей использовать).
• Авторов плагинов / интеграций, желающих добавить новую форму линии (CLI-воркер, оборачивающий Codex / Claude Code / OpenCode, контейнеризированный ревьюер, не-VibeOS сервис, забирающий задачи через API).

Если вы пишете сам код воркера — агента, работающего внутри линии, — жизненный цикл канбана и справочные детали автоматически внедряются в системный промпт воркера (блок KANBAN_GUIDANCE в agent/prompt_builder.py).

Иерархия

VibeOS Kanban  =  канонический жизненный цикл задачи + аудиторский след
Рабочая линия  =  исполнитель реализации для одной назначенной карточки
Ревьюер        =  человек или прокси-человек, контролирующий статус «готово»
GitHub PR      =  артефакт для отправки выше (опционально, для кодовых линий)

VibeOS Kanban владеет истиной жизненного цикла — ready → running → blocked / done / archived. Рабочие линии выполняют работу, но никогда не владеют этой истиной; всё, что они делают, возвращается обратно в ядро канбана через инструменты kanban_* (или, для внешних воркеров не-VibeOS, через API). Ревьюеры контролируют переход от «изменения кода написаны» к «задача выполнена».

Что предоставляет линия

Чтобы быть рабочей линией канбана, интеграция должна предоставлять три вещи:

1. Строка исполнителя

Диспетчер сопоставляет task.assignee либо с именем профиля VibeOS (форма линии по умолчанию), либо с зарегистрированным не-запускаемым идентификатором (форма линии плагина — см. Добавление внешней CLI-линии воркера ниже). Задачи, чей исполнитель не разрешается, остаются в статусе ready с событием skipped_nonspawnable, чтобы оператор доски мог их исправить; они не отбрасываются молча и не выполняются произвольным запасным вариантом.

2. Механизм запуска

Для линий профилей VibeOS _default_spawn диспетчера запускает vibeos -p <исполнитель> chat -q <промпт> (или эквивалентную модульную форму, когда прослойка vibeos отсутствует в $PATH) внутри закреплённого рабочего пространства задачи, с установленными следующими переменными окружения:

Переменная	Содержит
VIBEOS_KANBAN_TASK	id задачи, над которой работает воркер
VIBEOS_KANBAN_DB	абсолютный путь к SQLite-файлу доски
VIBEOS_KANBAN_BOARD	слаг доски
VIBEOS_KANBAN_WORKSPACES_ROOT	корень дерева рабочих пространств доски
VIBEOS_KANBAN_WORKSPACE	абсолютный путь к рабочему пространству этой задачи
VIBEOS_KANBAN_RUN_ID	id текущего запуска (для шлюза жизненного цикла)
VIBEOS_KANBAN_CLAIM_LOCK	строка блокировки захвата (<хост>:<pid>:<uuid>)
VIBEOS_PROFILE	имя собственного профиля воркера (для атрибуции автора kanban_comment)
VIBEOS_TENANT	пространство имён арендатора, если у задачи есть

Для линий не-VibeOS (зарегистрированных через плагин) плагин предоставляет собственную вызываемую spawn_fn, которая получает task, workspace и board и возвращает опциональный pid для обнаружения сбоев.

3. Терминатор жизненного цикла

Каждый захват должен завершаться ровно одним из:

• kanban_complete(summary=..., metadata=...) — задача успешна, статус переключается на done.
• kanban_block(reason=...) — задача ожидает ввода человека, статус переключается на blocked. Диспетчер перезапускает, когда выполняется kanban_unblock.
• Процесс воркера завершается без вызова инструмента. Ядро собирает его и выдаёт crashed (PID умер) или gave_up (сработал прерыватель последовательных сбоев) или timed_out (превышено max_runtime). Это путь отказа; здоровые воркеры не завершаются здесь.

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

Результаты и соглашение о необходимости ревью

Для большинства задач, изменяющих код, работа не является по-настоящему завершённой в момент окончания работы воркера — ей нужен ревьюер-человек. Ядро канбана не обеспечивает это различие («задача, изменяющая код» — размытое понятие, и принудительное блокирование вместо завершения для каждого кодового воркера сломало бы процессы, где ревью не требуется). Это соглашение, надстроенное сверху:

• Блокировать вместо завершения, с префиксом review-required: в reason, чтобы панель управления / vibeos kanban show отображали строку как ожидающую ревью.
• Помещать структурированные метаданные в kanban_comment сначала, поскольку kanban_block несёт только человекочитаемый reason. Комментарии — это канал долговечных аннотаций — все поля, относящиеся к аудиту (изменённые файлы, запущенные тесты, путь к diff или URL PR, решения), принадлежат туда.
• Ревьюер либо одобряет и разблокирует, что перезапускает воркера с цепочкой комментариев для доработок; либо запрашивает изменения через другой комментарий, который следующий запуск воркера видит как часть контекста kanban_show.

Внедрённый KANBAN_GUIDANCE охватывает как kanban_complete (действительно терминальные задачи — исправления опечаток, изменения документации, исследовательские записки), так и шаблон блокировки review-required.

Логи и аудиторский след

Диспетчер записывает stdout/stderr воркера для каждой задачи в <корень-доски>/logs/<id_задачи>.log. Логи доступны для аудита из метаданных канбана:

• Строки task_runs содержат log_path, код выхода (где доступен), сводку и метаданные.
• Строки task_events содержат каждый переход состояния (promoted, claimed, heartbeat, completed, blocked, gave_up, crashed, timed_out, reclaimed, claim_extended).
• kanban_show возвращает и то, и другое, так что ревьюер (или последующий воркер), читающий задачу, получает полную историю без необходимости доступа к панели управления.

Панель управления отображает историю запусков со сводками, блоками метаданных и значками статуса выхода. Пользователи CLI могут запустить vibeos kanban tail <id_задачи> для отслеживания в реальном времени или vibeos kanban runs <id_задачи> для исторического списка попыток.

Существующие формы линий

Линия профиля VibeOS (по умолчанию)

Форма, которую принимает каждый воркер канбана сегодня: исполнитель — это имя профиля, диспетчер запускает vibeos -p <профиль>, воркер получает блок системного промпта KANBAN_GUIDANCE автоматически и использует инструменты kanban_* для завершения запуска. Никакой настройки, кроме определения профиля.

Когда вы создаёте профили для своей флотилии, выбирайте имена, соответствующие роли, на которую вы хотите, чтобы оркестратор направлял задачи. Оркестратор (когда он есть) обнаруживает имена ваших профилей через vibeos profile list — нет фиксированного списка, который система предполагает (сторона контракта оркестратора является частью внедрённого KANBAN_GUIDANCE).

Линия профиля оркестратора

Специализация линии профиля: оркестратор — это профиль VibeOS, чей набор инструментов включает kanban, но исключает terminal / file / code / web для реализации. Его работа — разбивать высокоуровневую цель на подзадачи через kanban_create + kanban_link и отступать. Навык оркестратора кодирует правила противодействия искушениям.

Добавление внешней CLI-линии воркера

Подключение не-VibeOS CLI-инструмента (Codex CLI, Claude Code CLI, OpenCode CLI, локальный раннер кодовых моделей и т.д.) в качестве рабочей линии канбана пока не является проторённым путём. Функция запуска диспетчера подключаема (spawn_fn — это параметр dispatch_once), и плагин может зарегистрировать свою собственную spawn_fn для не-VibeOS исполнителя, но окружающая интеграционная работа — обёртывание кода выхода CLI в вызовы kanban_complete / kanban_block, сопоставление соглашений CLI о рабочем пространстве/песочнице с env VIBEOS_KANBAN_WORKSPACE диспетчера, обработка аутентификации и политики для каждого CLI — всё ещё является проектной работой для каждой интеграции.

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

Исторический issue для этого — #19931, а закрытый, но не слитый PR, специфичный для Codex — #19924 — они описывают оригинальное архитектурное предложение, но раннер не был реализован.

Режимы отказа, обрабатываемые диспетчером

Чтобы авторам линий не пришлось перереализовывать их:

• TTL устаревшего захвата — воркер, который захватил задачу, а затем никогда не отправляет heartbeat / не завершает / не блокирует, перезахватывается после DEFAULT_CLAIM_TTL_SECONDS (по умолчанию 15 мин) — но только если процесс воркера действительно умер. Живой воркер (медленная модель, тратящая 20+ минут на один вызов LLM без инструментов) получает продление захвата вместо убийства; только мёртвый PID перезахватывается.
• Упавший воркер — воркер, чей локальный PID на хосте исчез, обнаруживается detect_crashed_workers и собирается; задача увеличивает consecutive_failures и может автоматически заблокироваться при срабатывании прерывателя.
• Повтор на уровне запуска — при повторной попытке задачи (после блокировки, после сбоя, после перезахвата) воркер может использовать параметр expected_run_id в завершающих инструментах, чтобы быстро завершиться с ошибкой, если его собственный запуск уже был заменён.
• Максимальное время выполнения на задачу — task.max_runtime_seconds жёстко ограничивает астрономическое время на запуск, независимо от живости PID. Ловит действительно заблокированные воркеры, которые продление живого PID иначе продолжало бы держать.
• Обнаружение зависших задач — задача в статусе ready, чей исполнитель никогда не создаёт захват в течение kanban.stranded_threshold_seconds (по умолчанию 30 мин), отображается в vibeos kanban diagnostics как предупреждение stranded_in_ready. Серьёзность повышается до ошибки при 2x порога и до критической при 6x. Ловит опечатанных исполнителей, удалённые профили и упавшие внешние пулы воркеров одним сигналом — независимо от идентичности, без необходимости курировать разрешённый список для каждой доски.

Связанное

• Обзор канбана — введение для пользователей.
• Учебник по канбану — пошаговое руководство с открытой панелью управления.
• KANBAN_GUIDANCE — жизненный цикл воркера + оркестратора, внедряемый в системный промпт каждого воркера канбана.