Summary

There is a race condition between the kanban dispatcher claiming a task and the worker process actually starting up and reading the task state. During this window, the task can be:

• Blocked by an operator
• Archived by an operator
• Reassigned to a different profile
• Reclaimed by another dispatcher tick

The worker starts up, calls kanban_show, and gets a task in a state it shouldn't be running in. The kanban-worker skill explicitly warns: "Always kanban_show first. If it reports blocked or archived, stop — you shouldn't be running." But this relies on every worker correctly implementing this check, and there is no enforcement at the framework level.

Steps to Reproduce

1. Dispatcher claims task t_xxx and starts spawning a worker
2. Operator blocks t_xxx via hermes kanban block t_xxx
3. Worker process starts, reads task — it's blocked
4. Worker either ignores the block and proceeds, or crashes with confusion

Expected Behavior

1. The worker bootstrap code (not the skill, but the framework) should automatically check the task state on startup
2. If the task is blocked, archived, or reassigned, the framework should exit gracefully — no skill code needed
3. The dispatcher should verify the task is still in a dispatchable state after the worker process starts but before marking it as running

Suggested Fix

• Add a state-verification step in the worker bootstrap (in agent/prompt_builder.py or the kanban worker entrypoint)
• If state is not running or ready, log a warning and exit with a specific exit code that the dispatcher recognizes as "task changed state, not a failure"
• Do NOT increment consecutive_failures for this exit code — the worker didn't fail, the task just changed

Environment

• Hermes Agent v2.x
• Documented in kanban-worker skill under "Pitfalls": "Task state can change between dispatch and your startup"