A useful Kanban board carries decisions forward. A downstream worker should receive the upstream result, a retry should retain the previous failure, and review should leave an audit trail instead of becoming a vague comment.
- Hermes Kanban stores durable tasks and runs in SQLite.
- Parent tasks gate their children until completion.
- Same-card review uses review and change-request transitions; blocking is for external intervention.
- Dispatcher workers call
kanban_*tools. The CLI is for people and automation outside a model run.
1. Choose Kanban for durable work
delegate_task is a short parent-child call. Kanban fits work that crosses profiles, must survive a restart, needs review, or may pause for a person. A task can move through todo, ready, running, review, blocked, and done, while each attempt remains in its run history.
The board is also an isolation boundary. Named boards have separate SQLite files, workspaces, and logs. This chapter’s fixture takes the same approach by creating one database at a caller-selected path.
2. Model dependencies and handoffs
A child with an unfinished parent stays in todo. Completing every parent promotes it to ready. Completion includes a summary and metadata, which become structured context for the child. That handoff is more reliable than asking the next agent to reconstruct a decision from chat history.
Do not make a support task the child of the blocked task it is supposed to unblock. That dependency points in the wrong direction and can park both cards.
3. Separate review from blocking
The same-card review path is implementation, review request, requested changes, a revised review request, and approval. The implementation and review attempts stay attached to one card. Use kanban_block when work needs an external decision, missing access, or unavailable infrastructure, not for ordinary review feedback.
A separate downstream reviewer card is another valid design. Pick one model per review stage. Combining both creates two review lanes for the same candidate.
4. Bound retries
Transient failures return a task to ready. Once its retry limit is reached, the task becomes blocked, which stops automatic thrashing. A person can fix the cause and unblock it. Prior errors remain available to the next attempt, so the worker can change strategy instead of repeating the same action.
Hermes applies this circuit breaker to repeated worker spawn failures. The fixture applies the same bounded rule to a deterministic operation, which keeps the example offline and repeatable.
5. Run the isolated board
cd examples/chapter-11-kanban-collaboration
python3 board.py --db board.db --reset
python3 -m unittest discover -s tests -vThe JSON snapshot shows dependency promotion, the verifier’s failed and successful attempts, and the writer/reviewer sequence. The database is disposable local state. The tests also prove that completion before a task starts is rejected.
6. Move the pattern to Hermes
Operators initialize and inspect a real board with hermes kanban init, hermes kanban create, hermes kanban show, and hermes kanban watch. Assigned workers do not shell out to these commands. The dispatcher gives them board-scoped tools such as kanban_show, kanban_heartbeat, kanban_request_review, kanban_request_changes, and kanban_complete.
Keep summaries specific: changed files, tests, decisions, and remaining limits. A commit alone does not complete a task. Completion should follow the task’s acceptance contract.
7. Know the fixture boundary
The example tests lifecycle semantics, not the Hermes dispatcher process, profile configuration, or a messaging gateway. Its schema is intentionally small and is not a copy of Hermes’s private database schema. Use Hermes commands and tools in production; do not point the fixture at a Hermes board file.
The next chapter assembles the dependency, retry, review, approval, Git, and delivery boundaries into one credential-free capstone.
Leave a Reply