[loganj]

🤖

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. feat(agents): give plugin agent types the Buzz side of a turn #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 fix(security): close workflow, Canvas, upload, and broker gaps #2360, which refused every message that carried a workflow tag. fix(agents): restore delegated workflow mentions #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 test(agents): align harness fixture with owner authorization #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

[joahg]

🤖 Approving. I checked this against main:

• Cause: #2364's fixture is signed by the owner (alice), and fromOwner accepts the owner before it looks at any workflow tag. Since #2399 restored that rule, the "workflow" message was admitted. This PR fixes the fixture, not the kit.
• The new refusal case is the right one to pin. kit.conversation calls fromOwner(trigger.event, agent.owner) without a WorkflowCheck. A relay workflow mention signed by the community's workflow key never reaches workflowMentionOwner, so the kit refuses it. The extra fromOwner(workflow, alice, { agent, authority }) → true assertion proves the fixture is a valid delegated mention. Without it, the refusal could just be a bad signature.
• Documentation: the docs/workflows.md line and the kit comment record that plugin agent types don't accept delegated workflow mentions. That keeps the kit's (a workflow's never is) doc comment accurate.
• CI: green, including JavaScript (1/4).

Follow-up, not a blocker: whether plugin harnesses should eventually accept owner workflow mentions the way the bundled ones do is a product call. Refusing them is the safer default while the template/substitution issue that #2399 reopened is unresolved.