sidebar_position: 12 title: "Kanban (Multi-Agent Board)" description: "Durable SQLite-backed task board for coordinating multiple Hermes profiles" lang: ru

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

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

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

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

На плате есть две передние двери, обе с одинаковым ~/.hermes/kanban.db:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление платами из CLI

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

# Create a new board.
hermes 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.
hermes kanban --board atm10-server list
hermes kanban --board atm10-server create "Restart ATM server" --assignee ops

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

# Rename the display name (the slug is immutable — it's the directory name).
hermes 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.
hermes kanban boards rm atm10-server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# config.yaml
kanban:
  dispatch_in_gateway: true        # default
  dispatch_interval_seconds: 60    # default

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

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

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

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

Массовые команды CLI

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

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

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

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

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

# Model's tool calls, in order:
kanban_show()                                     # no args — uses HERMES_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_create, kanban_link и kanban_comment для внешних задач — доступны каждому работнику; соглашение (обеспечиваемое навыком kanban-orchestrator) заключается в том, что рабочие профили не разветвляются, а профили оркестратора не выполняются.

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

Три причины:

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

Нулевой объем схемы в обычных сеансах. Обычный сеанс hermes chat не содержит инструментов kanban_* в своей схеме. check_fn в каждом инструменте возвращает True только тогда, когда установлен HERMES_KANBAN_TASK, что происходит только тогда, когда диспетчер запускает этот процесс. Никаких раздутых инструментов для пользователей, которые никогда не прикасаются к канбану.

Навыки kanban-worker и kanban-orchestrator учат модель, какой инструмент вызывать, когда и в каком порядке.

Навык рабочего

Любой профиль, который должен иметь возможность выполнять задачи канбана, должен загрузить навык kanban-worker. Он обучает работника полному жизненному циклу с помощью вызовов инструментов, а не команд CLI:

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

Загрузите его (это вы, установка в профиль, а не вызов инструмента):

hermes skills install devops/kanban-worker

Диспетчер также автоматически передает --skills kanban-worker при создании каждого работника, поэтому работник всегда имеет доступную библиотеку шаблонов, даже если конфигурация навыков профиля по умолчанию не включает ее.

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

Иногда для одной задачи требуется контекст специалиста, которого профиль ответственного лица не имеет по умолчанию — задание на перевод, для которого требуется навык 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/косая черта) повторите --skill для каждого:

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

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

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

Эти навыки являются дополнительными к встроенным kanban-worker — диспетчер выдает по одному флагу --skills <name> для каждого (и для встроенного), поэтому воркер появляется со всеми ими загруженными. Имена навыков должны соответствовать навыкам, которые фактически установлены в профиле исполнителя (запустите hermes skills list, чтобы увидеть, что доступно); нет установки во время выполнения.

Навык оркестратора

Хороший оркестратор не делает работу сам. Он разбивает цель пользователя на задачи, связывает их, назначает каждую специалисту и отступает. Навык kanban-orchestrator кодирует это как шаблоны вызова инструментов: правила борьбы с искушениями, стандартный список специалистов (researcher, writer, analyst, backend-eng, reviewer, ops) и сборник инструкций по декомпозиции с ключами 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",
)

Загрузите его в свой профиль оркестратора:

hermes skills install devops/kanban-orchestrator

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

Панель управления (графический интерфейс)

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

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

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

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

• Вкладка Канбан, показывающая один столбец для каждого статуса: triage, todo, ready, running, blocked, done (плюс archived, когда переключатель включен).
• triage — это столбец парковки для грубых идей, которые спецификатор должен воплотить в жизнь. Задачи, созданные с помощью hermes kanban create --triage (или с помощью встроенного создания столбца сортировки), попадают сюда, и диспетчер оставляет их в покое до тех пор, пока человек или спецификатор не повысит их до todo / ready. – На карточках отображаются идентификатор задачи, название, значок приоритета, тег арендатора, назначенный профиль, количество комментариев/ссылок, таблетка прогресса (N/Mдети, выполненные, когда у задачи есть иждивенцы) и «создано N назад». Флажок для каждой карты позволяет осуществлять множественный выбор.
• Дорожки для каждого профиля внутри «Бег» — флажок на панели инструментов переключает подгруппировку столбца «Бег» по ответственному.
• Живые обновления через WebSocket — плагин отслеживает таблицу task_events, предназначенную только для добавления, с коротким интервалом опроса; плата отражает изменения в тот момент, когда действует любой профиль (CLI, шлюз или другая вкладка информационной панели). Перезагрузки устраняются, поэтому пакет событий запускает одну повторную выборку.
• Перетаскивайте карты между столбцами, чтобы изменить статус. Отбрасывание отправляет PATCH /api/plugins/kanban/tasks/:id, который проходит через тот же код kanban_db, который использует CLI — три поверхности никогда не могут смещаться. Переходит в деструктивные статусы (done, archived, blocked) запрашивает подтверждение. Сенсорные устройства используют резервный вариант на основе указателя, поэтому плату можно использовать с планшета.
• Встроенное создание — нажмите + в заголовке любого столбца, чтобы ввести название, правопреемника, приоритет и (необязательно) родительскую задачу из раскрывающегося списка над каждой существующей задачей. Создание из столбца «Сортировка» автоматически помещает новую задачу в сортировку.
• Множественный выбор с массовыми действиями — щелкните карточку, удерживая клавишу Shift/Ctrl, или установите флажок, чтобы добавить ее в выбор. Вверху появляется панель массовых действий с переходами статуса пакета, архивированием и переназначением (в раскрывающемся списке профиля или «(отменить назначение)»). Разрушительные партии подтверждают в первую очередь. Сообщается о частичных сбоях каждого идентификатора без прерывания остальных.
• Нажмите карту (без Shift/Ctrl), чтобы открыть боковой ящик (Escape или щелчок снаружи закрывается) с помощью:
• Редактируемый заголовок — нажмите заголовок, чтобы переименовать.
• Редактируемый правопреемник/приоритет — щелкните мета-строку, чтобы переписать ее.
• Редактируемое описание — по умолчанию отображается уценка (заголовки, жирный шрифт, курсив, встроенный код, изолированный код, ссылки http(s) / mailto:, маркированные списки), с кнопкой «редактировать», которая меняет местами текстовое поле. Рендеринг Markdown — это крошечный, безопасный для XSS рендеринг — каждая замена выполняется на входных данных, экранированных HTML, проходят только ссылки http(s) / mailto:, а target="_blank" + rel="noopener noreferrer" всегда установлены.
• Редактор зависимостей — список чипов родителей и детей, каждый из которых имеет × для отключения, а также раскрывающиеся списки над каждой другой задачей для добавления нового родителя или ребенка. Попытки цикла отклоняются на стороне сервера с четким сообщением.
• Строка действий по состоянию (→ сортировка / → готово / → выполняется / заблокировать / разблокировать / завершить / заархивировать) с запросами на подтверждение деструктивных переходов.
• Раздел результатов (также с уценкой), ветка комментариев с вводом для отправки, последние 20 событий.
• Фильтры панели инструментов — поиск по произвольному тексту, раскрывающийся список арендаторов (по умолчанию dashboard.kanban.default_tenant из config.yaml), раскрывающийся список назначенных лиц, переключатель «показать архивированные», переключатель «полосы по профилю» и кнопка Сдвинуть диспетчера, чтобы вам не приходилось ждать следующих 60 секунд.

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

Архитектура

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

┌────────────────────────┐      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                                    │
└──────────┬─────────────┘                                    │
           │                                                  │
           ▼                                                  │
┌────────────────────────┐                                    │
│  ~/.hermes/kanban.db   │ ───── append task_events ──────────┘
│  (WAL, shared)         │
└────────────────────────┘

поверхность ОТДЫХ

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

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

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

Любой из этих ключей под dashboard.kanban в ~/.hermes/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 в браузере.

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

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

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

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

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

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

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

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

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

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

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

hermes kanban init                                     # create kanban.db + print daemon hint
hermes kanban create "<title>" [--body ...] [--assignee <profile>]
                                [--parent <id>]... [--tenant <name>]
                                [--workspace scratch|worktree|dir:<path>]
                                [--priority N] [--triage] [--idempotency-key KEY]
                                [--max-runtime 30m|2h|1d|<seconds>]
                                [--skill <name>]...
                                [--json]
hermes kanban list [--mine] [--assignee P] [--status S] [--tenant T] [--archived] [--json]
hermes kanban show <id> [--json]
hermes kanban assign <id> <profile>                    # or 'none' to unassign
hermes kanban link <parent_id> <child_id>
hermes kanban unlink <parent_id> <child_id>
hermes kanban claim <id> [--ttl SECONDS]
hermes kanban comment <id> "<text>" [--author NAME]

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

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

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

/kanban слэш-команда {#kanban-slash-command}

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

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

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

Шлюз обычно ставит в очередь команды и пользовательские сообщения, пока агент еще думает — именно это удерживает вас от случайного запуска второго хода, пока первый находится в полете. /kanban явно освобожден от этой защиты. Плата находится в ~/.hermes/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 \hermes kanban …` in your terminal for full output)`. Поверхность 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) также работают — их просто еще нет в списке подсказок автозаполнения.

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

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

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

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

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

hermes kanban create "monthly report" \
    --assignee researcher \
    --tenant business-a \
    --workspace dir:~/tenants/business-a/data/

Рабочие получают $HERMES_TENANT и пространство имен, которое их память записывает по префиксу. Доска, диспетчер и определения профиля являются общими; ограничиваются только данные.

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

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

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

hermes kanban notify-subscribe t_abcd \
    --platform telegram --chat-id 12345678 --thread-id 7
hermes kanban notify-list
hermes 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, когда вам (человеку) нужно закрыть задачу, которую работник не может выполнить — например. задача, которая была заброшена или которую вы отметили как выполненную вручную на панели управления:

hermes 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:
hermes 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.

Предупреждение о массовом закрытии. hermes 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 запускает hermes kanban complete <ready-task> --summary X) в противном случае приведет к прекращению передачи обслуживания. Вместо этого ядро ​​вставляет строку запуска нулевой длительности (started_at == ended_at), содержащую сводку/метаданные/причину, поэтому история попыток остается полной. Событие completed / blocked run_id указывает на эту строку.

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

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

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

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

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

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

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

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

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

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

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

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

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