Kanban

На этой странице

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

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

Два интерфейса: модель общается через инструменты, вы — через 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 в репозитории.

Kanban vs delegate_task​

Они выглядят похоже, но это не один и тот же примитив.

	delegate_task	Kanban
Форма	RPC-вызов (fork → join)	Надёжная очередь сообщений + конечный автомат
Родитель	Блокируется до возврата потомка	Создал и забыл после create
Идентичность потомка	Анонимный подагент	Именованный профиль с постоянной памятью
Возобновляемость	Нет — не удалось = не удалось	Блок → разблокировать → перезапуск; сбой → возврат
Человек в цикле	Не поддерживается	Комментарий / разблокировка в любой момент
Агентов на задачу	Один вызов = один подагент	N агентов за время жизни задачи (повтор, ревью, доработка)
Аудит-след	Теряется при сжатии контекста	Постоянные строки в SQLite навсегда
Координация	Иерархическая (вызывающий → вызываемый)	Равноправная — любой профиль читает/пишет любую задачу

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

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

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

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

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

• Доска (Board) — самостоятельная очередь задач с собственной БД SQLite, директорией рабочих областей и циклом диспетчера. Одна установка может иметь много досок (например, по одной на проект, репозиторий или домен); см. раздел Доски (мультипроект) ниже. Пользователи с одним проектом работают на доске default и никогда не видят слово «доска» за пределами этого раздела документации.
• Задача (Task) — строка с заголовком, необязательным телом, одним исполнителем (имя профиля), статусом (triage | todo | ready | running | blocked | done | archived), необязательным пространством имён арендатора и необязательным ключом идемпотентности (дедупликация для повторяющейся автоматизации).
• Связь (Link) — строка task_links, записывающая зависимость родитель → потомок. Диспетчер переводит todo → ready, когда все родители переходят в done.
• Комментарий (Comment) — протокол меж-агентного взаимодействия. Агенты и люди добавляют комментарии; когда рабочий (повторно) запускается, он читает всю ветку комментариев как часть своего контекста.
• Рабочая область (Workspace) — директория, в которой работает рабочий. Три вида:
• scratch (по умолчанию) — свежая временная директория в ~/.hermes/kanban/workspaces/<id>/ (или ~/.hermes/kanban/boards/<slug>/workspaces/<id>/ для нестандартных досок).
• dir:<path> — существующая общая директория (хранилище Obsidian, директория почтовых операций, папка для каждой учётной записи). Должен быть абсолютным путём. Относительные пути, такие как dir:../tenants/foo/, отклоняются при диспетчеризации, потому что они разрешались бы относительно текущей рабочей директории диспетчера, что двусмысленно и представляет собой вектор побега для запутанного посредника. В остальном путь считается доверенным — это ваша машина, ваша файловая система, рабочий работает с вашим uid. Это модель угроз доверенного локального пользователя; kanban по замыслу однопользовательский.
• worktree — git worktree в .worktrees/<id>/ для задач программирования. Создаётся через git worktree add на стороне рабочего.
• Диспетчер (Dispatcher) — долгоживущий цикл, который каждые N секунд (по умолчанию 60): возвращает устаревшие захваты, возвращает упавшие рабочие (PID исчез, но TTL ещё не истёк), переводит готовые задачи, атомарно захватывает, порождает назначенные профили. Работает внутри шлюза по умолчанию (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_*, доступный рабочему, читает её.
• Связывание задач между досками не разрешено (чтобы схема оставалась простой; если вам действительно нужны межпроектные ссылки, используйте упоминания в свободном тексте и ищите их по id вручную).

Управление досками через CLI​

[code] # 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

[/code]

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

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

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

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

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

• Board dropdown — выберите активную доску. Ваш выбор сохраняется в localStorage браузера, так что он переживает перезагрузки, не сдвигая указатель current CLI из-под терминала, который вы оставили открытым.
• + New board — открывает модальное окно с запросом slug, отображаемого имени, описания и иконки. Опция автоматического переключения на новую доску.
• Archive — показывается только для не-default досок. Подтверждает, затем перемещает директорию доски в boards/_archived/.

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

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

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

[code] # 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

[/code]

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

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

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

[code] # config.yaml kanban: dispatch_in_gateway: true # default dispatch_interval_seconds: 60 # default [/code]

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

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

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

[code] # 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 [/code]

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

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

[code] 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 [/code]

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

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

Инструмент	Назначение	Обязательные параметры
kanban_show	Прочитать текущую задачу (заголовок, тело, предыдущие попытки, передачи от родителя, комментарии, полный предварительно отформатированный worker_context). По умолчанию использует id задачи из окружения.	—
kanban_complete	Завершить со структурированной передачей summary + metadata.	хотя бы один из summary / result
kanban_block	Эскалировать для ввода человека с указанием reason.	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

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

[code] # 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}, ) [/code]

Оркестратор вместо этого разветвляется:

[code] 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") [/code]

Три инструмента «(Оркестраторы)» — kanban_create, kanban_link и kanban_comment для чужих задач — доступны каждому рабочему; соглашение (подкреплённое навыком kanban-orchestrator) гласит, что профили рабочих не разветвляются, а профили оркестраторов не выполняют.

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

Три причины:

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

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

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

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

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

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

[code] { "changed_files": ["path/to/file.py"], "verification": ["pytest tests/hermes_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"] } [/code]

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

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

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

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

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

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

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

[code] hermes skills install devops/kanban-worker [/code]

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

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

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

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

[code] 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"],
)

[/code]

От человека (CLI / слэш-команда), повторяйте --skill для каждого:

[code] 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

[/code]

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

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

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

Воспитанный оркестратор не делает работу сам. Он декомпозирует цель пользователя на задачи, связывает их, назначает каждую специалисту и отступает. Навык kanban-orchestrator кодирует это как паттерны вызовов инструментов: правила анти-соблазна, стандартный список специалистов (researcher, writer, analyst, backend-eng, reviewer, ops) и плейбук декомпозиции, основанный на kanban_create / kanban_link / kanban_comment.

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

[code] # 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", ) [/code]

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

[code] hermes skills install devops/kanban-orchestrator [/code]

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

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

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

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

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

Что даёт плагин​

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

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

Архитектура​

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

[code] ┌────────────────────────┐ 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) │ └────────────────────────┘ [/code]

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	Применить тот же патч (статус / архив / исполнитель / приоритет) ко всем id в ids. Частичные ошибки сообщаются без прерывания остальных
POST	/tasks/:id/comments	Добавить комментарий
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 или выполнил hermes kanban init.

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

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

[code] 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

 rendering
[/code]

Каждый ключ опционален и возвращается к показанному значению по умолчанию.
Модель безопасности​
Промежуточное ПО HTTP-аутентификации панели управления явно пропускает /api/plugins/ — маршруты плагинов неаутентифицированы по замыслу, потому что панель управления по умолчанию привязывается к localhost. Это означает, что REST-поверхность kanban доступна с любого процесса на хосте.
WebSocket делает один дополнительный шаг: он требует эфемерный токен сессии панели управления как параметр запроса ?token=… (браузеры не могут установить Authorization на запросе обновления), следуя паттерну, используемому встроенным PTY-мостом в браузере.
Если вы запустите hermes dashboard --host 0.0.0.0, каждый маршрут плагина — включая kanban — становится доступен из сети. Не делайте этого на общем хосте. Доска содержит тела задач, комментарии и пути к рабочим областям; атакующий, получивший доступ к этим маршрутам, получает доступ на чтение ко всей вашей поверхности совместной работы, а также может создавать, переназначать и архивировать задачи.
Задачи в ~/.hermes/kanban.db намеренно агностичны к профилям (в этом и заключается координационный примитив). Если вы откроете панель управления с помощью hermes -p <profile> dashboard, доска всё равно покажет задачи, созданные любым другим профилем на хосте. Один и тот же пользователь владеет всеми профилями, но об этом стоит знать, если сосуществуют несколько персон.
Живые обновления​
task_events — это таблица SQLite только на добавление с монотонным id. Конечная точка WebSocket хранит последний просмотренный id события каждого клиента и отправляет новые строки по мере их появления. Когда прибывает всплеск событий, фронтенд перезагружает (очень дешёвую) конечную точку доски — проще и правильнее, чем пытаться обновлять локальное состояние из каждого типа событий. Режим WAL означает, что цикл чтения никогда не блокирует транзакции захвата BEGIN IMMEDIATE диспетчера.
Расширение​
Плагин использует стандартный контракт плагинов панели управления Hermes — см. Расширение панели управления для полного справочника манифеста, слотов оболочки, слотов с областью видимости страницы и 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, поэтому две поверхности согласованы по построению.
[code]
    hermes kanban init                                     # create kanban.db + print daemon hint
    hermes kanban create "