[Bug] Workflow send_message @mentions never wake the mentioned agent: author_allowed drops relay-signed workflow events before mention matching

[santhoshguru]

Describe the bug

A scheduled workflow send_message that @mentions an agent never wakes that agent, even though the emitted event is well formed (kind 9, correct p tag for the agent, buzz:workflow tag). The same agent wakes within seconds when the same channel mention comes from a human or another agent. The daily automation fails silently: the message posts on schedule, the agent never gets a turn, and nothing surfaces the drop.

This is the same root cause makgunay documented in a comment on #2702 (#2702 (comment)): in crates/buzz-acp/src/lib.rs, author_allowed runs before filter::match_event, and workflow output is signed by the relay keypair, which is neither the agent's owner nor a sibling with a NIP-OA auth tag. Under the default RespondTo::OwnerOnly the event is dropped before its p tags are ever inspected. Filing it as a dedicated bug so it is visible in triage rather than living only inside a feature request thread; #2702 is the feature ask (silent invocation), this is the defect (documented mention-wake path does not work at all).

Steps to reproduce

1. Create a channel workflow with a schedule trigger and a send_message action whose text @mentions a managed agent running under buzz-acp with default (owner-only) access. Ours:

trigger:
  on: schedule
  cron: "0 2 * * *"
steps:
  - id: morning_brief
    action: send_message
    text: "@Dozer Prepare and post the morning briefing ..."

2. Let it fire (or buzz workflows trigger it as the workflow creator).
3. Observe the posted event: correct h tag, correct p tag for the agent, buzz:workflow=true, authored by the relay/workflow keypair, no auth tag.
4. The mentioned agent never receives a turn. Control: an ordinary owner- or agent-authored @mention in the same channel wakes the same agent in 1-2 seconds.

Ruled out on our deployment before finding the author gate:

• Machine asleep: pmset -g log shows the Mac awake at every missed fire (buzz-desktop holds a sleep assertion).
• Harness down: Buzz Desktop and all ACP processes up continuously across two consecutive missed fires.
• Membership: adding the workflow author pubkey as a channel member changes nothing (expected, since the gate is authorization, not membership).
• Mention construction: plain-text @Name, valid p tag present (so this is not workflow_sink's @-mention parser is a third divergent implementation — workflow-emitted **@Name** emits zero p tags #2686).

Sample failing events on our relay: b79e5ff09a558839bb54a4b395a1cda8e8e6f28fcd8cfaa2f37661aea4fea1e4 (2026-07-30 02:00:03 UTC), 6c95a35485a0522ba85b17c40c4650dbfb3555c2c2ee98f7217628afbad9ace1 (2026-07-31 02:00:03 UTC), 34dd15128569a3b8eb7d57f4ab7c60acd53d881827dfb56ffa375c61f302e0e6 (manual trigger, 2026-07-31 04:07:08 UTC). All three: zero wakes. Tags on each: [["p","<agent>"],["h","<channel>"],["buzz:workflow","true"]].

Expected behavior

A workflow-emitted channel message with a valid p tag for an agent should wake that agent, matching the wake contract stated in crates/buzz-relay/src/workflow_sink.rs ("so mentioned agents are woken (wake is p-tag gated)"). makgunay's suggested direction on #2702 seems right: for relay-signed events carrying buzz:workflow, resolve the effective author from the workflow's owner attribution (ideally an explicit buzz:workflow_owner tag) before applying author_allowed, so owner-only semantics are preserved per owner without trusting the shared relay key.

Version and platform

• Buzz version: 0.5.2
• OS: macOS (Darwin 25.5.0), Apple Silicon

Logs / additional context

• Two independent agents on this deployment (the target agent and the investigating agent) reproduced both halves: workflow mention drops silently, owner/agent-authored mention wakes instantly.
• strings on the shipped buzz-acp binary shows the gate messages ("NIP-OA auth tag verification failed", "owner resolved from BUZZ_AUTH_TAG"), consistent with the source analysis on feat(workflow): silent agent-invocation action — wake an agent from a scheduled workflow without a visible channel post #2702.
• Related: feat(workflow): silent agent-invocation action — wake an agent from a scheduled workflow without a visible channel post #2702 (feature: silent agent invocation), workflow_sink's @-mention parser is a third divergent implementation — workflow-emitted **@Name** emits zero p tags #2686 (markdown-wrapped mentions emit zero p tags), Workflows: add a safe dispatch_agent step for configured managed agents #3697 (closed: dispatch_agent step), [Bug] Workflow owner p-tag wakes the owner agent on every send_message #3638 (owner p-tag wakes owner agent on every send_message; that owner attribution p tag at index 0 is presumably the one a fix would resolve the effective author from).

[iroiro147]

Standing down — covered by open PR #2737

Verified the defect seam before touching code: in crates/buzz-acp/src/lib.rs author_allowed is applied at :2152 and filter::match_event only at :2173, so any workflow event signed by the relay keypair is rejected under the default owner-only rule before its p tags are read — exactly as diagnosed here and on #2702 (…#issuecomment-5108048221).

It's already fixed by PR #2737 (fix(workflows): restore discovery and authorize agent wake, OPEN), which:

• adds a dedicated workflow-owner authority tag to relay-signed workflow messages while p tags stay attribution/mention-routing only;
• makes ACP accept that delegated principal only when a kind-9 event is validly signed by the configured endpoint's NIP-11 self identity and carries exactly one valid buzz:workflow marker + owner tag (fail-closed on missing/malformed/ambiguous/forged provenance);
• touches crates/buzz-acp/src/lib.rs, relay.rs, crates/buzz-relay/src/workflow_sink.rs, action_sink.rs.

That's the direction proposed in this issue (resolve effective author from workflow owner attribution before author_allowed, fail closed), so an independent PR would duplicate the same lib.rs change. (See also the closed #3498, the earlier attempt at the same gate.)

Suggest this be closed as covered by #2737, or tracked against its merge.