Kanban в Hermes: 4 сценария использования

Настройка

hermes kanban init
hermes dashboard  # http://127.0.0.1:9119 → Kanban

Дашборд — лучшее место для наблюдения. Воркеры никогда не видят дашборд — они работают через инструменты kanban_*.

Шесть колонок доски

Triage — сырые идеи. Нажмите ✨ Specify, чтобы превратить однострочник в полную спецификацию

Todo — создано, ждёт зависимостей

Ready — назначено, ждёт диспетчера

Running — воркер выполняет (с дорожками по профилям)

Blocked — ожидает ввода человека

Done — завершено

---

Сценарий 1: Сольный разработчик

Классический поток: спроектировать → реализовать → протестировать. Три задачи с зависимостями.

SCHEMA=$(hermes kanban create "Design auth schema" \
    --assignee backend-dev --priority 2 \
    --body "Design user/session/token schema for auth module." \
    --json | jq -r .id)

API=$(hermes kanban create "Implement auth API" \
    --assignee backend-dev --priority 2 \
    --parent $SCHEMA \
    --body "POST /register, POST /login, POST /refresh, POST /logout." \
    --json | jq -r .id)

hermes kanban create "Write auth tests" \
    --assignee qa-dev --priority 2 \
    --parent $API \
    --body "Cover happy path, wrong password, expired token."

Что происходит:

SCHEMA стартует сразу (нет родителей)

API ждёт в todo, пока SCHEMA не завершится

Tests ждёт, пока API не завершится

Когда SCHEMA достигает done, диспетчер автоматически продвигает API в ready. Воркер API при запуске видит summary и metadata SCHEMA в передаче от родителя.

hermes kanban show $SCHEMA
hermes kanban runs $SCHEMA
#   OUTCOME      PROFILE      ELAPSED
# 1  completed   backend-dev       0s
#     → users(id, email, pw_hash), sessions(id, user_id, jti, expires_at)

---

Сценарий 2: Ферма из воркеров

Три воркера (переводчик, транскрайбер, копирайтер) и куча независимых задач. Все работают параллельно.

for lang in Spanish French German; do
    hermes kanban create "Translate homepage to $lang" \
        --assignee translator --tenant content-ops
done

for i in 1 2 3 4 5; do
    hermes kanban create "Transcribe Q3 customer call #$i" \
        --assignee transcriber --tenant content-ops
done

for sku in 1001 1002 1003 1004; do
    hermes kanban create "Generate product description: SKU-$sku" \
        --assignee copywriter --tenant content-ops
done

hermes gateway start  # диспетчер разруливает

Диспетчер запускает до N воркеров параллельно. Каждый берёт задачу, работает, завершает. Очередь осушается без участия человека.

---

Сценарий 3: Пайплайн с ревью и повтором

PM пишет спецификацию → инженер реализует → ревьюер отклоняет → инженер исправляет → ревьюер одобряет.

PM воркер:

kanban_show()
kanban_complete(
    summary="spec approved; POST /forgot-password sends email, "
            "GET /reset/:token renders form, POST /reset applies new password",
    metadata={"acceptance": [
        "expired token returns 410",
        "reused last-3 password returns 400",
        "successful reset invalidates all sessions",
    ]},
)

Инженер (попытка 1):

kanban_show()  # читает acceptance metadata от PM
# ... пишет код ...
kanban_block(
    reason="Review: password strength check missing, "
           "reset link isn't single-use",
)

Человек разблокирует:

hermes kanban unblock $IMPL

Инженер (попытка 2):

kanban_show()  # видит причину блокировки из попытки 1
kanban_complete(
    summary="added zxcvbn strength check, reset tokens single-use",
    metadata={
        "changed_files": ["auth/reset.py", "tests/test_reset.py"],
        "tests_run": 11,
        "review_iteration": 2,
    },
)

В ящике задачи — две попытки с полной историей. Каждый запуск — строка в task_runs.

---

Сценарий 4: Circuit breaker и восстановление после краша

Circuit breaker

Задача не может запустить воркера (нет credentials). После 3 сбоев подряд диспетчер блокирует задачу:

hermes kanban runs t_ef5d
#   OUTCOME        PROFILE      ELAPSED
# 1  spawn_failed   deploy-bot       0s
#       ! AWS_ACCESS_KEY_ID not set
# 2  spawn_failed   deploy-bot       0s
#       ! AWS_ACCESS_KEY_ID not set
# 3  gave_up        deploy-bot       0s
#       ! AWS_ACCESS_KEY_ID not set

Восстановление после краша

Воркер упал (OOM, segfault). Диспетчер обнаруживает мёртвый PID, освобождает клейм, задача возвращается в ready.

Пример: миграция, вызвавшая OOM:

Run 1 — crashed, OOM kill at row 2.3M

Run 2 — completed, стратегия «chunked with LIMIT + WHERE id > last_id»

Повторный воркер видит краш попытки 1 в контексте и выбирает безопасную стратегию.

---

Почему структурированная передача важна

kanban_complete(summary=..., metadata=...) — это не декорация, а основной канал связи между этапами.

Когда воркер на задаче B запускается, worker_context включает:

Предыдущие попытки B — чтобы не повторять провалившийся путь

Результаты родительских задач — summary и metadata каждого родителя

Это заменяет копание в комментариях и логах.

---

Следующие шаги

Что такое Kanban в Hermes — полный обзор

hermes kanban --help — справка по командам

Официальная документация