A mention in Slack reaches the role through its person's conversation

What the Slack tools reach was widened from threads to channels in ADR 0015.

ADR 0013 left mentions in channels for later, with a direction: mentioning a role's Slack app in a channel reaches the role through the mentioning person's conversation with it, and the role gets tools to read that thread and to post in it. We decided how. A linked person's mention is said in their conversation as a message of theirs that carries the mention, a link to it, and the thread to answer in, and asks the agent to answer there with send_slack_message; the relay routes nothing by itself. The agent reads the thread with read_slack_thread. Both tools reach only threads in which the conversation's person mentioned the role, so a conversation is never a way into a channel its person did not bring it into.

Considered Options

• The relay posts the agent's answer in the thread by itself (while the mention is being worked on, whatever the agent says goes to the thread instead of the DM): rejected. It routes by guessing which message an answer belongs to, and cannot post a follow-up later, such as when a task made from the mention is done. The agent decides where it speaks, as it does with send_message.
• Counting a thread reply as the agent speaking up, so the turn ends without a reply in the DM: not built. The end of a turn still sends the agent's last message to the DM, which is usually a short line saying where it answered. Revisit if those lines are noise.
• A general "where it was said" field on messages, which conversations would carry: not built, as ADR 0013 decided for a general channel seam. Where a mention came from is in the message text.
• Any channel the app is in, or what the person could read in Slack: rejected for now. The first lets anyone linked have the agent read private channels the app was invited to; the second costs another permission and a membership lookup on every call. Mentioned threads are what the person brought the role into, and can be widened later without breaking anything.
• Catching up on missed mentions, as DMs are: not built. A channel's history is not cheap to read, so mentions rely on Slack sending events again that were not acknowledged; one made during a long outage is lost.

Consequences

• A mention at the top of a channel is answered in a thread under it; one inside a thread, in that thread. 👀 goes on the mention while the agent works, as on a DM.
• What is said in a thread is seen by everyone in the channel. The mention's message and the tool that posts both tell the agent not to bring in what was said privately in its conversation, unless its person asks it to. Nothing can enforce that; it is a rule the agent is given.
• Someone not linked who mentions a role is answered every time, in a message only they see (an ephemeral one), that an owner must link them; they are listed with those waiting, as for DMs, and nothing they wrote is kept. Answering in the thread would tell the channel; staying silent would look broken.
• Mentions in DMs are left alone: a DM message is taken as one already.
• Apps need more of Slack: the app_mention event, and permission to read mentions and the history of public and private channels. Apps made before need their manifest updated in Slack and to be installed again. Slack says which permissions a token has, so the role's page says when an app needs that, rather than mentions failing unseen.