@@ -204,7 +204,7 @@ Slack requirements:
204204Slack should prefer reaction names such as ` eyes ` in stored policy. The Slack
205205adapter can normalize aliases and provider syntax at the edge.
206206
207- ## Deferred Agent-Authored Reactions
207+ ## Agent-Authored Reactions
208208
209209Automatic acknowledgement reactions and agent-authored reactions are separate
210210capabilities. This plan implements only automatic acknowledgement reactions.
@@ -234,8 +234,9 @@ For Slack, this requires:
234234- ` reactions:write ` on the Slack app installation
235235- clear error reporting when the bot is not allowed to react
236236
237- Do not implement this by enabling OpenClaw's generic Slack, Discord, Teams, or
238- other provider-channel integrations in a Spritz gateway-routed runtime. Those
237+ Do not implement future explicit reactions by enabling OpenClaw's generic Slack,
238+ Discord, Teams, or other provider-channel integrations in a Spritz
239+ gateway-routed runtime. Those
239240integrations are for deployments where OpenClaw owns the provider connection
240241directly. In Spritz gateway mode, they give the model a direct provider-send
241242path that cannot work without provider tokens in the runtime pod.
@@ -246,6 +247,10 @@ The important boundary is:
246247- future explicit user-requested reactions must be narrow Spritz-owned actions,
247248 not generic provider-channel tools
248249
250+ Current Spritz code should therefore not expose a Slack reaction MCP tool or
251+ internal provider-action endpoint by default. The only Slack reaction behavior
252+ in this phase is the gateway's automatic acknowledgement reaction lifecycle.
253+
249254## Runtime Boundary
250255
251256The runtime should not be asked to add automatic acknowledgement reactions or
0 commit comments