TelegramAdapter.send_kanban_blocked call site drifts from deployed adapter API

[leonardsellem]

Bug Description

The Hermes gateway/kanban notification path can attempt to patch or call TelegramAdapter.send_kanban_blocked, but the deployed Telegram adapter API does not reliably expose that symbol. In our homelab deployment this surfaced as an AttributeError during plugin registration and disabled the kanban-guardrails plugin's notifier quarantine/backoff protections.

Impact

A missing optional Telegram blocked-notification method should not be able to prevent unrelated kanban guardrail/plugin registration. The current drift forces downstream deployments to use defensive getattr(...) guards and mark the symbol as optional in boot self-tests.

Expected Behavior

Either:

1. TelegramAdapter exports a stable send_kanban_blocked(...) API matching the gateway/plugin call site, or
2. the upstream call site guards the lookup and degrades gracefully when the platform adapter does not implement blocked-task notifications.

Actual Behavior

A runtime/plugin path that assumes TelegramAdapter.send_kanban_blocked exists raises AttributeError when the deployed adapter does not provide it. Downstream workaround is to skip notifier-quarantine patch installation when the upstream symbol is missing.

Evidence / Downstream Workaround

• Downstream guardrail boot self-test tracks the symbol in projects/homelab/iac-staging/hermes/plugins/kanban-guardrails/REQUIRED_SYMBOLS.txt as send_kanban_blocked optional=true until upstream resolves the API drift.
• The same class of upstream gateway-vs-CLI symbol drift already affects hermes_cli.kanban_db.read_board_metadata, which our deployment also tracks as optional with a local shim.

Environment

• Hermes Agent v0.12.0-style deployment from NousResearch/hermes-agent
• Gateway + Telegram adapter + kanban guardrails plugin enabled

[teknium1]

Thanks for the detailed report, but this isn't a drift on our side.

send_kanban_blocked does not exist anywhere in the hermes-agent codebase — not in gateway/platforms/telegram.py, not in any caller. grep -r "send_kanban_blocked" on current main returns zero hits. The "gateway/kanban notification path" you describe attempting to patch or call this symbol is your downstream kanban-guardrails plugin's behavior, not ours. Your own workaround doc confirms this: projects/homelab/iac-staging/hermes/plugins/kanban-guardrails/REQUIRED_SYMBOLS.txt lives in your repo, and the shim you're asking us to ship would exist only to satisfy your plugin's expectation.

Our adapters expose a single public send(chat_id, text, reply_to=, metadata=) method; anything richer (kanban blocked, cron fired, etc.) is the caller's job to format. That's the contract.

Right fix for kanban-guardrails: defensive getattr + format-and-delegate on your end, about 5 lines:

async def notify_blocked(adapter, chat_id, task_id, reason, assignee=None):
    text = f"⏸ @{assignee} Kanban {task_id} blocked: {reason}" if assignee else f"⏸ Kanban {task_id} blocked: {reason}"
    send_specialized = getattr(adapter, "send_kanban_blocked", None)
    if send_specialized:
        return await send_specialized(chat_id, task_id, reason, assignee=assignee)
    return await adapter.send(chat_id, text)

This matches what PR #20508's shim does internally (it's self.send(chat_id, formatted_message) under the hood) and works against any adapter that implements send() — Telegram, Discord, Slack, all of them. Closing this; closing #20508 on the same reasoning (adds 41 lines of API surface with zero in-tree consumer to serve one external plugin).

If you find an actual call site in our code that assumes send_kanban_blocked exists, reopen with the file/line and we'll fix that call site directly.