hermes - 💡(How to fix) Fix Kanban: surface non-runnable ready tasks and unknown assignees

Summary

Please add stronger runnable-state validation and visibility for Kanban tasks, especially when a task is assigned to a profile/assignee that is not actually runnable.

Problem

A Kanban board can look healthy because tasks exist and the dispatcher is running, while some tasks are effectively stuck in ready because their assignee/profile cannot be resolved or run.

This makes it easy for users and agents to believe that Kanban is working, when the real state is closer to: "ready, but not runnable".

Requested behavior

1. Unknown assignee guard

If a task is created for an assignee/profile that does not exist on disk or cannot be run, Hermes should either:

• reject creation with a clear error, or
• move/mark the task as blocked with a structured reason such as blocked_unknown_assignee.

It should not silently sit in ready forever.

2. Dispatcher-visible blocked reason

When the dispatcher cannot run a ready task, the board/status should expose the exact reason, for example:

• missing profile
• profile disabled
• toolset unavailable
• max worker cap reached
• dependency/state mismatch
• stale/zombie/reclaimable worker

3. Runnable health/status

It would be useful to have a CLI/dashboard status that distinguishes:

• ready and runnable
• ready but blocked by missing assignee/profile
• ready but blocked by dispatcher limits
• running
• stale/zombie/reclaimable

4. Fan-in/frontier visibility

For parent/child workflows, it would help to show whether a workflow has:

• a next task waiting
• a next task running
• a next task that cannot run
• no next task/frontier at all

This would make multi-step workflows much easier to diagnose.

What should stay unchanged

The existing design is valuable and should stay:

• durable board state
• per-run history
• parent/child handoff summaries
• crash/retry handling
• multi-profile worker lanes
• CLI/dashboard/worker-tool consistency

Why this matters

The main issue is not whether the board exists. The important question is whether the current ready work is actually runnable. Stronger runnable-state proof would make Kanban more reliable for long-running and multi-profile workflows.