Skip to content

feat(kanban): notify_fallback — auto-subscribe channel-less task creates - #88477

Closed
sstark21 wants to merge 2 commits into
NousResearch:mainfrom
sstark21:feat/kanban-notify-fallback
Closed

feat(kanban): notify_fallback — auto-subscribe channel-less task creates#88477
sstark21 wants to merge 2 commits into
NousResearch:mainfrom
sstark21:feat/kanban-notify-fallback

Conversation

@sstark21

Copy link
Copy Markdown

Summary

Tasks created from sessions with no persistent delivery channel (CLI, cron, dashboard scripts, bare API calls) silently get no auto-subscription — the gateway notifier only delivers to subscribed chats, so completion/block events from such tasks reach nobody unless someone polls the board.

This adds an opt-in kanban.notify_fallback config (format "<platform>:<chat_id>", e.g. "telegram:123456789"):

  • When set, _maybe_auto_subscribe falls back to this target for channel-less creates instead of the historical no-op.
  • Strictly opt-in: the empty default preserves the behaviour restored by revert: auto-subscribe gateway chat on tool-driven kanban_create (#19718) #19721 — no over-eager auto-subscription of every CLI invocation.
  • A live session channel (gateway/TUI) always wins over the fallback.
  • Fallback rows carry no live-session delivery metadata (thread/reply anchors) — it is a synthetic subscription.

Design rationale

The upstream revert in #19721 fixed auto-subscribing every channel-less create (over-eager, #19718). The gap that remains is intentional for defaults but leaves self-hosted single-operator boards (e.g. one human, one Telegram bot, tasks created via hermes kanban create from SSH) with zero notification coverage. A config-gated fallback keeps the default conservative while giving single-operator deployments a one-line fix instead of a per-task notify-subscribe habit or an external watchdog script.

Config example

kanban:
  notify_fallback: "telegram:388101199"

Test plan

  • test_channelless_create_noop_without_fallback — default unchanged (no fallback → no sub)
  • test_channelless_create_uses_notify_fallback — fallback configured → sub written with platform/chat from config, no delivery metadata
  • test_notify_fallback_ignored_when_session_has_channel — live session channel wins
  • Full tests/tools/test_kanban_tools.py (32 tests) + tests/hermes_cli/test_config.py green via scripts/run_tests.sh
  • Docs table in website/docs/user-guide/features/kanban.md updated

Tasks created from sessions with no persistent delivery channel (CLI,
cron, dashboard scripts) got no auto-subscription — completion/block
events silently reached nobody. The gateway notifier only delivers to
subscribed chats, so such tasks only surfaced when someone polled the
board.

Add kanban.notify_fallback ("<platform>:<chat_id>", default "").
When set, _maybe_auto_subscribe falls back to this target for
channel-less creates instead of the historical no-op. Strictly opt-in:
empty default preserves pre-feature behaviour; a live session channel
always wins; no delivery metadata (thread/reply anchors) is attached
to fallback rows.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/cron Cron scheduler and job management comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint area/config Config system, migrations, profiles sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades labels Aug 17, 2026
@sstark21 sstark21 closed this Aug 17, 2026
@sstark21
sstark21 deleted the feat/kanban-notify-fallback branch August 17, 2026 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint comp/cron Cron scheduler and job management P3 Low — cosmetic, nice to have sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants