kanban-worker

Run kanban_show first to confirm the task is not blocked or archived, do the work in $HERMES_KANBAN_WORKSPACE, then call kanban_complete with a concise summary and structured metadata. For code changes needing review, use kanban_block with a review-required reason instead.

Use kanban_block when the task needs a human decision or code review, prefixing the reason with 'review-required: ' for code changes. Put structured metadata like changed files and test counts in a kanban_comment first, since block only carries a human-readable reason.

If the workspace kind is worktree and .git does not exist at the resolved path, run git worktree add from the main repository first, then cd in and commit work normally. Scratch workspaces are disposable; dir: workspaces are shared persistent state.

The kernel verifies every ID in created_cards exists and was created by your profile. Only pass IDs captured from successful kanban_create return values; phantom or failed-create IDs trigger a gate rejection recorded permanently on the task event log.

When $HERMES_TENANT is set, prefix every persistent memory entry with the tenant namespace, such as 'business-a: Acme is our biggest customer'. Unprefixed entries leak context across tenant boundaries.

Inspect the prior runs' outcome and error fields from kanban_show before acting. Timeouts suggest chunking the work, crashes suggest reducing memory, spawn failures indicate profile config issues best escalated via kanban_block rather than blind retries.