Kanban dispatcher should validate assignee profile readiness before spawning workers

[steezkelly]

Bug Description

Kanban task assignment treats assignee as a Hermes profile slug. If the profile directory exists but is incomplete or not runnable, the dispatcher can still claim the task and spawn hermes -p <profile> chat -q .... The failure then surfaces later as confusing worker/provider/auth behavior instead of a clear Kanban/profile-readiness diagnostic.

Observed Behavior

While recovering a local multi-agent Kanban setup, I found a profile directory:

~/.hermes/profiles/debugger-v1/

The directory existed and contained profile material such as skills / SOUL.md, but was missing the runnable profile prerequisites:

• config.yaml
• .env
• auth.json

A Kanban task assigned to debugger-v1 was still eligible for dispatch. The resulting worker startup path failed indirectly through provider/auth fallback behavior rather than reporting something like:

assignee profile debugger-v1 is not runnable: missing config.yaml / credentials

After creating a proper profile config and syncing credential state, the same assignee worked and completed a smoke-test Kanban task.

Code Path / Evidence

Current dispatch path appears to normalize the assignee but not validate profile readiness before claiming/spawning:

• hermes_cli/kanban_db.py::_canonical_assignee() only calls normalize_profile_name(assignee).
• hermes_cli/kanban_db.py::dispatch_once() claims ready assigned tasks before spawn.
• hermes_cli/kanban_db.py::_default_spawn() builds:

cmd = ["hermes", "-p", profile_arg, "--skills", "kanban-worker", "chat", "-q", prompt]

but does not appear to check that profile_arg is a runnable profile before spawning.

There is profile-name validation support in hermes_cli/profiles.py, including:

• normalize_profile_name()
• validate_profile_name()
• profile_exists()

However, profile_exists() only checks that the profile directory exists. A half-created profile directory can therefore pass the rough existence condition while still being unrunnable.

The gateway dispatcher has aggregate stuck-queue telemetry:

kanban dispatcher stuck: ready queue non-empty ... Check profile health (venv, PATH, credentials)

but the per-task failure could be diagnosed earlier and more precisely.

Expected Behavior

Before claiming/spawning a Kanban worker, the dispatcher should validate that the assignee profile is runnable. For example:

• profile name is valid and normalized
• profile exists, unless default
• profile has a readable config.yaml, or documented/default inheritance applies
• provider/model can be resolved from the profile config
• required credential state is present or explicitly inherited
• optional: a cheap non-interactive profile startup/config check passes

If validation fails, Kanban should not spawn the worker. It should either:

1. leave the task unclaimed and comment with the readiness failure, or
2. auto-block the task with a clear reason, e.g.:

Profile debugger-v1 is not runnable: missing ~/.hermes/profiles/debugger-v1/config.yaml

Why This Matters

Kanban is a multi-profile orchestration primitive. A stale or half-created profile currently creates an opaque failure mode: the board says a task is assigned and dispatchable, but the worker cannot actually start correctly. Failing fast with a precise profile-readiness error would save debugging time and prevent dispatcher churn.

Related Issues / Distinction

This is related to Kanban multi-profile robustness, but distinct from:

• [Bug]: Kanban DB is profile-scoped instead of shared across profiles, so workers cannot see root tasks #18442 — Kanban DB profile-scoping / shared board visibility
• [Bug]: Kanban dispatcher fails to claim tasks assigned to "jules" due to case sensitivity in profile validation #18498 — case sensitivity in assignee/profile validation

This report is specifically about validating whether an assignee profile is runnable before worker spawn.

Environment

• Hermes Agent v0.12.0 (2026.4.30)
• Source commit: b816fd4e2
• OS: Linux desktop 6.17.0-22-generic x86_64
• Python: 3.11.15