Summary

send_message is unavailable to kanban-dispatcher-spawned workers because _check_send_message falls back to is_gateway_running(), which reads {HERMES_HOME}/gateway.pid — and workers run under the assignee profile's HERMES_HOME (e.g. ~/.hermes/profiles/calendar/), where no PID file exists. The parent gateway is alive and reachable; only the check fails.

This is asymmetric with _check_kanban_mode in tools/kanban_tools.py:42, which already honors HERMES_KANBAN_TASK (the env var the dispatcher sets on every spawned worker, see hermes_cli/kanban_db.py:3782). So today, a worker can call every kanban_* tool but cannot call send_message.

This PR mirrors that pattern in _check_send_message: if HERMES_KANBAN_TASK is set, the worker is dispatcher-spawned, the parent gateway is by definition running, and send_message is safe to allow.

Why this matters

The kanban completion notifier truncates payload_summary to its first line, max 200 chars (gateway/run.py:3963):

h = payload_summary.strip().splitlines()[0][:200]

For workers whose natural output is richer than a one-liner (a calendar listing, a deck export with a paste URL, a research idea ranking, a video summary with bullets), the only ergonomic delivery path is for the worker to call send_message(platform=..., chat_id=..., text=<full content>) itself, then kanban_complete(summary=<one-liner>) for the notifier's "✔ done" line. Today that pattern silently fails: send_message is gated off, the worker either hallucinates success or substitutes kanban_comment (which the user never sees on Telegram).

Net user-visible effect: a Telegram-originated kanban task completes, the user gets ✔ Kanban t_xxxx done — <one-line headline> and nothing else. Rich content lives in the kanban DB but never reaches the chat.

Relationship to other in-flight work

• feat(kanban): return agent-created task completions to origin #21523 (open) — feat(kanban): return agent-created task completions to origin solves the broader "completions return to origin" problem at the gateway notifier layer (provenance threading + auto-subscribe + synthesis). It does not modify _check_send_message. This PR is orthogonal: even with feat(kanban): return agent-created task completions to origin #21523 merged, workers may want to message other chats (e.g., notify a team channel on completion of a user-originated task), and that requires send_message to be callable from the worker. Both can land independently.
• [Bug]: Newly created kanban profiles default to toolsets: [hermes-cli] only — missing web/browser/terminal/file causes silent failure #22924 (open) — the related "newly-created profiles default to toolsets: [hermes-cli]" bug. Different gate, same family of "workers can't reach a tool that should be available" surprises.

Change

 def _check_send_message():
-    """Gate send_message on gateway running (always available on messaging platforms)."""
+    """Gate send_message on gateway running (always available on messaging platforms).
+
+    Also passes for kanban workers — the dispatcher sets HERMES_KANBAN_TASK
+    on every spawned worker, but those workers run with the assignee profile's
+    HERMES_HOME which has no gateway.pid, so the gateway-running check would
+    fail even though the parent gateway is alive. Honoring the env var lets
+    workers call send_message to deliver rich content directly to the
+    originating chat (paired with kanban_complete for the short notifier
+    summary), which is the canonical pattern for any worker that needs to
+    reply with more than the ~200-char first-line truncation the kanban
+    notifier applies.
+    """
+    if os.environ.get("HERMES_KANBAN_TASK"):
+        return True
     from gateway.session_context import get_session_env
     platform = get_session_env("HERMES_SESSION_PLATFORM", "")
     ...

os is already imported at module top (tools/send_message_tool.py:11).

Test plan

• Reproduced locally: spawned a kanban worker via Telegram-originated dispatch; before patch, worker's tool registry showed send_message unavailable (check failed) and the worker silently fell back to kanban_comment.
• Applied patch + restarted gateway. Worker can now invoke send_message(platform="telegram", chat_id=..., text=...) and the rich content reaches the originating chat.
• No new tests added — happy to add one if reviewers want; the existing test surface for _check_send_message is thin.

Out of scope

• The 200-char first-line truncation in gateway/run.py:3963 is intentional (notifier wants scannable headlines). This PR does not touch it; instead it makes the documented worker-side workaround actually work.
• No changes to _check_kanban_mode, profile config defaults, or the dispatcher.