Buzz: adding an agent mention through message edit does not activate Hermes

[reinhold-ph]

Bug description

The Buzz adapter does not receive or process edited messages (kind:40003). If a user initially posts an unmentioned channel message and then edits it to add @Agent, Buzz correctly emits an edit event carrying the newly added agent mention, but Hermes never wakes.

This makes Buzz Desktop's "new mention added by edit" behavior ineffective for Hermes agents.

Reproduction

1. Configure the Hermes Buzz gateway with both require_mention: true and WebSocket transport.
2. In a watched shared Buzz channel, send a message without mentioning the Hermes agent.
3. Edit that message and add the Hermes agent through Buzz's mention picker.
4. Observe that Buzz publishes a kind:40003 edit event containing:
   • the edited content beginning with @Agent;
   • an e tag targeting the original kind:9 event;
   • the agent's exact p tag;
   • the corresponding mention tag and buzz:mention-snapshot marker.
5. Observe that Hermes does not receive or answer the edited message.
6. Send the same mention as a new kind:9 message; Hermes receives it immediately.

Expected behavior

A kind:40003 edit that adds a new valid mention for the Hermes identity should activate the agent once, using the edited content and preserving the original message/thread route.

Ordinary edits that do not newly mention the agent must not re-trigger it.

Actual behavior

Hermes ignores every Buzz edit event, including edits carrying a newly added mention.

Confirmed root cause

The Buzz adapter defines only kind:9 as inbound chat:

_CHAT_KIND = 9

Its WebSocket subscription requests only that kind:

{"kinds": [_CHAT_KIND], "#h": [channel_id], "since": since}

The shared inbound handler also drops every event whose kind is not _CHAT_KIND:

if int(event.get("kind") or 0) != _CHAT_KIND:
    return

Therefore kind:40003 edit events never reach mention gating or dispatch. Polling has the same semantic gap because _handle_event() rejects the edit kind.

Relevant file: plugins/platforms/buzz/adapter.py.

Suggested fix constraints

• Subscribe to and fetch kind:40003 alongside kind:9.
• Resolve the edit's target from its e tag and retain the original thread/routing semantics.
• Dispatch only when the edit adds this Hermes identity as a new mention; do not re-run the agent for typo fixes or unchanged mentions.
• Deduplicate by edit event ID so reconnect/poll overlap cannot activate twice.
• Add WebSocket and polling regression tests covering:
  1. unmentioned original → edit adds Hermes mention → one dispatch;
  2. edit without a new Hermes mention → no dispatch;
  3. replay of the same edit → no duplicate dispatch;
  4. thread reply edit preserves the original thread route.

Environment

• Hermes Buzz gateway using WebSocket transport
• Buzz message event kind: 9
• Buzz message-edit event kind: 40003

[reinhold-ph]

2026-08-12 live follow-up: activation and acknowledgement are separate boundaries

Upstream duplicate/implementation sweep:

• Canonical Buzz issue: block/buzz#2540
• Open candidate fixes:
  • block/buzz#2569 — add kind 40003 to default ACP mention subscriptions
  • block/buzz#2697 — cover initial and dynamically discovered ACP subscriptions
  • block/buzz#4741 — broader edit routing, native steering, and exact-once work; currently has/has had an exact-once review gate
• Relevant Hermes precedent: NousResearch/hermes-agent#64957, whose Slack edited-mention work was ultimately merged through fix(slack): prevent multi-agent reply storms — peer-bot gating, edited mentions, per-channel overrides NousResearch/hermes-agent#69483.

New live observation on the external Hermes Buzz Gateway

The original cold-activation failure remains the behavior this issue was filed for. A second, subtler behavior is now reproducible in an already active Buzz thread:

1. Send a shared-channel message without @Reinhold.
2. Edit it and add @Reinhold through Buzz Desktop.
3. Reinhold receives/processes the edited message in the active thread.
4. The edited message does not receive the normal automatic 👀 acknowledgement.
5. Control: a newly published message containing @Reinhold at initial send consistently receives 👀.

This proves that delivery/processing and acknowledgement reaction parity are separate acceptance boundaries. In an active thread, successful processing can mask the cold wake-up bug while the missing reaction remains visible.

Updated acceptance criteria

A complete fix must verify all of the following independently:

• Cold/inactive agent: original unmentioned message → edit adds exact agent p tag → one turn activates.
• Already active thread: the same edit is processed exactly once.
• A successfully admitted edit-added mention receives the same 👀 acknowledgement as an initial-send mention.
• The reaction targets the correct visible/original message revision rather than an auxiliary invisible kind-40003 event.
• Typo-only edits and edits retaining an unchanged mention do not retrigger or add duplicate reactions.
• Replayed/reconnected delivery of the same edit does not duplicate the turn or acknowledgement.
• Original message/thread/root routing remains stable.
• WebSocket and polling paths have equivalent behavior where supported.

Do not infer successful activation solely from 👀, and do not infer failed delivery solely from its absence; require a target-authored response/turn proof during acceptance.