Feature request: notify subscribers when a comment is added to a kanban task
Summary
Kanban subscribers currently receive notifications only for terminal/state events (completed, blocked, gave_up, crashed, timed_out, status, archived, unblocked — the TERMINAL_KINDS set). There is no notification when a new comment is added to a task, even though comments are the primary mid-flight communication channel between an orchestrator (the task creator) and a worker (the assignee).
Motivation
In orchestrator ↔ worker setups, the worker posts progress updates and blocker notes to the task thread via kanban_comment mid-run (e.g. "turn 10 check-in: have everything I need", "blocked on X", "U3 done, U4 next"). These comments are valuable live signals:
- An orchestrator can catch a worker thrashing (spinning on a missing credential / broken access / repeated tool failures) instead of only learning about it at the terminal event, hours later.
- A worker's "I'm missing access to X" comment is a sooner signal than the eventual
blocked — the orchestrator can intervene before 100 turns burn.
- Currently the only way to see these is manual polling (
kanban_show) — the comments never push to the creator.
The notification machinery already exists; comments are simply not in the event kinds that the notifier/wake path observes.
Proposed behavior
- Add a
comment event kind (or an analogous subscription-driven path) so that when a kanban_comment is appended to a task, subscribers of that task receive a notification containing the comment author and body (truncated like the existing blocked reason text).
- Respect the existing per-kind quieting model: it should be opt-in / config-gated (e.g.
kanban.notify_on_comment: false by default, or a subscribe-time kind filter), because comment volume can be high and the project has already tuned notification kinds to avoid noise.
- The worker's own comments should not echo back to the worker (mirroring the existing self-comment skip in the comment-injection poller).
- Wake semantics: a
comment notification should NOT wake the creator's agent by default (comments are informative, not actionable-terminal); if wake-on-comment is desired, gate it behind the existing wake-kind mechanism.
Out of scope (related, separately tracked)
Acceptance criteria
- A task with an active subscription receives a notification when an operator/worker posts a new comment (author + truncated body).
- No notification fires for the author's own comment.
- Config flag (default off) controls whether comment notifications are emitted at all; when off, behavior is byte-identical to today.
- Existing terminal-event notifications are unchanged.
Notes
This mirrors the existing status kind pattern (claimed silently, surfaced to subscribers) and reuses the subscription row + notifier plumbing. If maintainers prefer, a narrower version could emit comment notifications only for comments whose body starts with a marker (e.g. [progress]) to keep volume low.
Feature request: notify subscribers when a comment is added to a kanban task
Summary
Kanban subscribers currently receive notifications only for terminal/state events (
completed,blocked,gave_up,crashed,timed_out,status,archived,unblocked— theTERMINAL_KINDSset). There is no notification when a new comment is added to a task, even though comments are the primary mid-flight communication channel between an orchestrator (the task creator) and a worker (the assignee).Motivation
In orchestrator ↔ worker setups, the worker posts progress updates and blocker notes to the task thread via
kanban_commentmid-run (e.g. "turn 10 check-in: have everything I need", "blocked on X", "U3 done, U4 next"). These comments are valuable live signals:blocked— the orchestrator can intervene before 100 turns burn.kanban_show) — the comments never push to the creator.The notification machinery already exists; comments are simply not in the event kinds that the notifier/wake path observes.
Proposed behavior
commentevent kind (or an analogous subscription-driven path) so that when akanban_commentis appended to a task, subscribers of that task receive a notification containing the comment author and body (truncated like the existingblockedreason text).kanban.notify_on_comment: falseby default, or a subscribe-time kind filter), because comment volume can be high and the project has already tuned notification kinds to avoid noise.commentnotification should NOT wake the creator's agent by default (comments are informative, not actionable-terminal); if wake-on-comment is desired, gate it behind the existing wake-kind mechanism.Out of scope (related, separately tracked)
Acceptance criteria
Notes
This mirrors the existing
statuskind pattern (claimed silently, surfaced to subscribers) and reuses the subscription row + notifier plumbing. If maintainers prefer, a narrower version could emit comment notifications only for comments whose body starts with a marker (e.g.[progress]) to keep volume low.