[wpfleger96]

Removes the BUZZ_WORKFLOW_RESTRICTED_COMMUNITIES build flag added in #2518, shows owners a note when their agent ignores a message from their own workflow, and warns in the workflow editor when the relay uses owner-only agent mentions (block/buzz#9227).

Removing the flag. This removes the vite.config.ts wiring, the gate in owner-attestation.ts and the harness call sites that passed the community, the AgentReads.origin field, the flag's tests, and its docs in configuration.md, workflows.md and buzz-help.md. The relay-signed buzz:workflow-mention check alone decides workflow delegation again. docs/workflows.md and docs/unread.md say that a relay using owner-only agent mentions may leave that tag off.

A note when an agent ignores the owner's workflow. mentionAuthority() sits next to fromOwner() and returns workflow when the owner's own workflow posted a mention without a buzz:workflow-mention for this agent. Every other refusal has no reason, including a direct mention from someone else and someone else's workflow, so those stay silent as on main.

fromOwner() is now mentionAuthority() === "owner". The Claude, Codex, Goose and Pi runtimes pass the reason to Delivery.ignored(refusal). The runner records it in local activity, and AgentDeclineNotes shows it under the message on the owner's device. On an owner relay (read with the editor's useWorkflowAgentMentions, only once a note exists) the note gives the community reason and points to Runs; elsewhere it says "‹Agent› didn't respond because this workflow message wasn't set up to direct agents." Nothing is published. Other rejections call ignored() with no reason and store and show no note. Two behaviour details:

• A workflow message that doesn't name the agent never starts a profile read. A sibling's workflow is labelled workflow only if that profile was already read.
• When a creator's profile can't be read, there is no reason, so no note shows.

An editor warning. useWorkflowAgentMentions reads the active community's NIP-11 workflow_agent_mentions field through nativeRelayInfo. A missing or unknown value counts as any. When the value is owner and a send_message step's text mentions an agent in the channel, the editor shows a warning while you edit:

• Message, reaction or diff trigger with only Send Message and Delay steps: "Agents you mention respond only when you start this workflow, not when someone else does. This community limits which workflows can use agents, so other people can't use yours."
• Webhook trigger, whatever its steps: "Agents won't respond to workflows started by a webhook. This community limits which workflows can use agents, so other people can't use yours."
• Any non-webhook trigger with a step other than Send Message or Delay: "Agents won't respond to this workflow because it has steps other than Send Message and Delay. This community limits which workflows can use agents, so other people can't use yours."
• Schedule trigger with only message and delay steps: no warning.

Block's build scripts drop the flag in https://github.com/squareup/buzz-releases/pull/146. This stays a draft until block/buzz#9227 is deployed to bb-block production.

[jmecom]

🤖 Security review of 3c814d50fed1421b518b353d2daab074972d0a3d: I recommend holding the rollout until the replacement relay policy is enforced and verified across every serving pod.

Removing the build restriction makes mentionAuthority accept any otherwise valid relay-signed buzz:workflow-mention, including one produced by an older relay or a pod running any. The new NIP-11 lookup controls warning text; it is not an authorization gate. I verified with the actual pre- and post-change authority functions that the same genuinely signed workflow event changes from denied to authorized. The listener's history cutoff limits replay reachability, so this is not a claim that an attacker can arbitrarily replay old messages.

Please keep the existing restriction until every production pod runs BUZZ_WORKFLOW_AGENT_MENTIONS=owner. For the permanent cutover, I recommend a distinct relay-signed assertion that the strict policy authorized this particular message, checked by the client. That also fails closed during mixed-version deployments and rollbacks. The existing signature, recipient, and ownership checks remain sound; 228 focused existing tests passed, and I found no additional security bypass in the other changes.

[kalvinnchau]

🤖 One non-blocking regression-coverage gap; no current functional defect demonstrated.