fix(agents): restore delegated workflow mentions - #2399

* origin/main: (52 commits)
  feat(agents): give plugin agent types the Buzz side of a turn (#2364)
  feat(plugins): pin buzz://plugin-install links to a path and commit (#2315)
  feat(plugins): tint currentColor SVG page icons like host icons (#2314)
  feat(notifications): add a soft notification sound (#1536)
  feat(agents): let agents propose a profile picture (#2267)
  fix(plugins): default reminders and workflows off for fresh installs (#2291)
  Show all reactors in compact, separate emoji capsules (#2179)
  fix(panels): remember page split widths per workspace (#2264)
  feat(search): browse open channels from a Channels tab in search (#2164)
  perf(relay): page combined replay filters after a reconnect (#2308)
  fix(composer): make native Mac text shortcuts work past link chips (#2390)
  perf(relay): read creator proofs for many channels per filter (#2312)
  fix(channels): let published leave and delete confirm through access loss (#2357)
  fix(media): save native context menu media downloads and hide loopback links on macOS (#2131)
  fix(links): say why a message preview is unavailable, and preview unjoined public channels (#2136)
  test(browser): serve emoji artwork in the reaction hit-area journey (#2138)
  test(browser): click a reply link only after its row settles (#2358)
  fix(agents): restore delegated workflow mentions (#2399)
  feat(identity): always back up keys in managed builds (#2398)
  test(threads): render before checking the reader across activity resizes (#2389)
  ...

Signed-off-by: Gil Birman <[email protected]>
Co-authored-by: Claude <[email protected]>

# Conflicts:
#	src/plugins/author.test.mjs

The kit test "refuses a mention from anyone else, and triggers that are
not its" fails on main. Its workflow fixture was a message signed by the
owner with a `buzz:workflow` tag. #2364 wrote it against #2360, whose
`fromOwner` refused any event with that tag. #2399 merged first and
restored the older `fromOwner`, which admits any event the owner signs,
so the fixture became an owner message and the kit admitted it.

The kit itself still calls `fromOwner` without a workflow check, so a
real relay workflow mention is refused. Make the fixture that real
mention: signed by the community's workflow key, owned by the owner and
aimed at this agent, with the workflow key set on the session. The
bundled harnesses admit this event; the kit must not. Wiring the
bundled workflow check into the kit makes the test fail.

Before the refusal, assert that the bundled check admits the fixture,
so the negative case cannot pass for the wrong reason again. Say at the
call that the missing workflow check is deliberate, and fix the workflow
docs, which named only Claude Code and Codex.

Signed-off-by: Logan Johnson <[email protected]>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-Authored-By: Claude Opus 5.5 <[email protected]>

The kit test "refuses a mention from anyone else, and triggers that are
not its" fails on main. Its workflow fixture was a message signed by the
owner with a `buzz:workflow` tag. #2364 wrote it against #2360, whose
`fromOwner` refused any event with that tag. #2399 merged first and
restored the older `fromOwner`, which admits any event the owner signs,
so the fixture became an owner message and the kit admitted it.

The kit itself still calls `fromOwner` without a workflow check, so a
real relay workflow mention is refused. Make the fixture that real
mention: signed by the community's workflow key, owned by the owner and
aimed at this agent, with the workflow key set on the session. The
bundled harnesses admit this event; the kit must not. Wiring the
bundled workflow check into the kit makes the test fail.

Before the refusal, assert that the bundled check admits the fixture,
so the negative case cannot pass for the wrong reason again. Also assert that an owner mention carrying only a
`buzz:workflow` marker is still admitted: the marker neither grants
authority nor revokes the owner's own. Say at the
call that the missing workflow check is deliberate, and fix the workflow
docs, which named only Claude Code and Codex.

Signed-off-by: Logan Johnson <[email protected]>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-Authored-By: Claude Opus 5.5 <[email protected]>

…#2444)

🤖

## Summary
- `main` fails the JavaScript unit tests at
`src/features/agent-harness/kit.test.ts` ("refuses a mention from anyone
else, and triggers that are not its"). This PR makes it pass again
without changing what agents accept.
- The cause is two PRs that merged in an order neither one expected.
#2364 added the harness kit, which plugin agent types use to decide
which messages start a turn. Its test was written against the rule from
#2360, which refused every message that carried a workflow tag. #2399
merged before it and restored the older rule, which accepts any message
the agent's owner signs. The test's "workflow" message was signed by the
owner, so it was accepted.
- The kit's behavior has not changed. It still accepts only messages
from the owner or an agent the owner attests. A real relay workflow
message is signed by the community's workflow key, so the kit still
refuses it. Only the test fixture was out of date.

## Details
- The fixture is now a real relay workflow mention: signed by the
community's workflow key, owned by the agent's owner, and aimed at this
agent. The bundled harnesses (Claude Code, Codex, Pi, Goose) would run
this message.
- Before checking the refusal, the test first checks that the bundled
workflow check accepts the fixture. Without that step the negative test
could pass for the wrong reason again. Giving the kit the bundled
workflow check makes the test fail.
- The test also checks that an owner mention with only a `buzz:workflow`
marker is still accepted: the marker neither grants authority nor
removes the owner's own. This covers the same fix as
#2445, so this PR includes it.
- `docs/workflows.md` listed only Claude Code and Codex as accepting
workflow mentions. It now lists Pi and Goose too, and says that plugin
agent types do not.

## Deliberate divergence
A workflow that mentions an agent of a plugin-provided type is ignored,
while the same workflow wakes a Claude Code or Codex agent. This is
intentional. #2399 restored workflow mentions for the bundled harnesses
only to keep existing behavior working, and it says the
template/substitution issue from #2360 is still open. Plugin agent types
have never accepted workflow mentions, so nothing regresses. Accepting
them would give these agent types a known open issue. If the team wants
plugin agent types to accept workflow mentions after the follow-up
discussion on workflow authorization, that change belongs in its own PR.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Logan Johnson <[email protected]>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5.5 <[email protected]>

Reapply the workflow authorization portion of #2360 that #2399 reverted. Preserve later Codex protection wiring and align the newer plugin harness tests with the restored shared gate.

Co-authored-by: jm-astra <06644cf6fec857393d5978909f511d88830f1a147ecdbec24e7b6f6e17da1534@buzz.block.builderlab.xyz>
Signed-off-by: Jordan Mecom <[email protected]>

Add BUZZ_WORKFLOW_RESTRICTED_COMMUNITIES, a frontend build flag listing
community origins where workflow-marked messages cannot authorize local
agent requests. Desktop preview releases set it to bb-block. Other
communities, including bb-public, keep the checked workflow delegation
from #2399.

In a listed community, fromOwner rejects any buzz:workflow message before
owner, attestation, or delegation checks, in bundled and plugin harnesses.
While any community is listed, an agent whose community origin is unknown
is restricted too.

Signed-off-by: Jordan Mecom <[email protected]>

Restrict workflow-triggered requests to local agents in bb-block only.
Other communities, including bb-public, keep the checked workflow
delegation from #2399. This replaces the earlier version of this PR,
which reapplied #2360 in every community.

## Behavior

A new frontend build flag, `BUZZ_WORKFLOW_RESTRICTED_COMMUNITIES`, lists
the community origins where workflow-marked messages cannot authorize a
local agent request. The desktop preview workflow sets it to
`https://buzz.block.builderlab.xyz`, which follows the existing
`BUZZ_EXTERNAL_MCP_COMMUNITIES` and `BUZZ_OWNER_MCP_COMMUNITIES` flags.
When the flag is empty, which is the default for OSS and development
builds, behavior matches main.

In a listed community, `fromOwner` rejects any event carrying a
`buzz:workflow` tag before the owner, attestation or delegation checks
run. Claude, Codex, Goose, Pi and plugin harnesses all use this gate, so
owner-created static templates and scheduled workflows no longer start
or steer these agents there. Workflow messages stay visible, and direct
owner requests and attested-sibling requests are unaffected. While any
community is listed, an agent whose community origin is unknown is also
restricted. That case already fails today, because delegation needs the
community's workflow authority.

The community comes from the agent's relay snapshot `origin`, which is
the normalized community origin and not the `origin:viewer` storage
partition. `AgentReads` now exposes it as `origin`.

This change does not prevent workflow output from influencing a later
authorized turn.

## Validation

- Unit tests cover the following: workflow mentions are denied in the
listed community and still delegated in an unlisted one; owner-signed
workflow-marked messages are denied there while direct and attested
requests run; an unknown community is restricted while the list is
non-empty, and the empty list falls back to main's behavior.
- A Claude runtime test checks the call-site wiring end to end. An
owner's trusted workflow mention runs when another community is listed
and is refused when the agent's own community is listed.
- `tsc --noEmit`, Biome, and the Claude, Codex, Goose, Pi,
agent-harness, agents and relay suites passed: 5,844 passed, 22 skipped.
The pre-commit and pre-push hooks passed without bypass.
- A production `vite build` with the flag set compiles the bb-block
origin into the gate.
- Native app execution, packaged preview builds and human acceptance
remain unverified.

For acceptance on a preview build, trigger an owner-created workflow in
bb-block that mentions a local agent and confirm it appears without
starting a turn. Then repeat it in a bb-public community and confirm the
agent runs. A direct owner request should run in both.

Signed-off-by: Jordan Mecom <[email protected]>