Make agents respond to mentions of it's role #866

New issue

Closed

opened 2026-08-16 15:55:13 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-08-16 15:55:13 +00:00

Owner

As opposed to just mentions of it's user / app

coilyco-ops added the

labels

2026-08-17 16:34:07 +00:00

coilyco-ops referenced this issue from a commit

2026-08-17 19:09:45 +00:00

feat: summon on a mention of a role this account holds

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-17 19:10:03 +00:00

feat: summon on a mention of a role this account holds #924

coilyco-ops commented

2026-08-17 19:10:21 +00:00

Member

Built and in review at #924. Angie (ENG, claude seat).

mentionsBot now reads MentionRoles off the Gateway payload against the roles Discord reports for this account in that guild, so an @-of-the-role summons the same way an @-of-the-account does.

Three things the one-line ask did not say, that the change had to decide.

@everyone does not summon. Its role id is the guild's and every member holds it, so without a guard every announcement would address every agent in the channel. That is the part with a real blast radius and it has its own test.
No privileged intent. Discord delivers this account's own member on GuildCreate without GUILD_MEMBERS, so nothing needs widening. A state miss falls back to one REST read written back to state, so a guild costs at most one lookup and then none, and a message with no role mention makes none at all.
The access-policy reference had to change. docs/access-policy.reference.yaml says a reader must be able to enumerate every summon path from it rather than from the code, and it listed six. It lists seven now. Leaving that is exactly the failure #127 is about.

Nothing downstream moves, which is the difference from #127: a role mention is a message in a channel and takes the same access.Evaluate, allowlist, and admission budget a direct mention takes. No new summon shape for the policy to model.

Built and in review at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/924. Angie (ENG, `claude` seat). `mentionsBot` now reads `MentionRoles` off the Gateway payload against the roles Discord reports for this account in that guild, so an `@`-of-the-role summons the same way an `@`-of-the-account does. **Three things the one-line ask did not say, that the change had to decide.** * **`@everyone` does not summon.** Its role id is the guild's and every member holds it, so without a guard every announcement would address every agent in the channel. That is the part with a real blast radius and it has its own test. * **No privileged intent.** Discord delivers this account's own member on `GuildCreate` without `GUILD_MEMBERS`, so nothing needs widening. A state miss falls back to one REST read written back to state, so a guild costs at most one lookup and then none, and a message with no role mention makes none at all. * **The access-policy reference had to change.** `docs/access-policy.reference.yaml` says a reader must be able to enumerate every summon path from it rather than from the code, and it listed six. It lists seven now. Leaving that is exactly the failure #127 is about. Nothing downstream moves, which is the difference from #127: a role mention is a message in a channel and takes the same `access.Evaluate`, allowlist, and admission budget a direct mention takes. No new summon shape for the policy to model.

coilyco-ops referenced this issue

2026-08-17 19:11:08 +00:00

Expose MCP prompts as Discord slash commands, which adds a summon path the access policy does not model #127

coilysiren closed this issue

2026-08-17 19:11:23 +00:00

coilyco-ops referenced this issue

2026-08-19 04:30:33 +00:00

The turn surface accepts a caller-supplied author, so a caller can present as the principal #1048