Summary

• Problem: Slack implicit thread wakes could collapse the wake decision without preserving enough provider-native mention detail for the agent prompt.
• Why it matters: Agents need to distinguish a direct bot mention from an implicit thread wake that happens to mention another Slack user or user group.
• What changed: Preserve Slack mention target metadata, user-group mention metadata, implicit wake reasons, and mention source in inbound prompt context; keep selective reply guidance for implicit Slack thread wakes without direct bot mentions.
• What did NOT change (scope boundary): No Slack docs/changelog changes remain in this PR, and no unrelated Canvas hash drift is included.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Slack: preserve explicit mention targets and distinguish implicit thread wakes from bot mentions #79025
• Related fix: preserve slack mention source metadata #79046
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Slack thread messages that explicitly mention another user now preserve provider-native mention targets and distinguish implicit thread wakes from direct bot mentions.
• Real environment tested: Local OpenClaw checkout on Ubuntu 24.04 with Node v22.22.0, live Slack socket-mode app, channel #social, PR head 83008331ff8eac444277251d8ceea566d804237b.
• Exact steps or command run after this patch:
  1. Started the gateway from /home/ubuntu/codes/tmimmanuel/openclaw-pr-75356 on PR head 83008331ff8eac444277251d8ceea566d804237b.
  2. Confirmed Slack socket mode connected in a real Slack workspace.
  3. Used an existing #social Slack thread where OpenClaw had already participated.
  4. Sent a Slack thread message that mentioned another Slack user (@dev), not the bot.
  5. Compared the runtime prompt metadata against the same Slack thread behavior previously observed on main commit 3a0b81af9d7d86807be030415e2d1b1b38dae949.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Copied live Slack output and redacted runtime log excerpt from the PR branch:

tmimmanuel: Let me repro the fix behavior.
OpenClaw: Looks like tmimmanuel is testing something related to a fix — probably not needing my input on this one. I'll stay quiet and let them work.
tmimmanuel: @dev I am talking to you.

{
  "is_group_chat": true,
  "was_mentioned": true,
  "explicitly_mentioned_bot": false,
  "mentioned_user_ids": ["U_DEV_REDACTED"],
  "implicit_mention_kinds": ["bot_thread_participant"],
  "mention_source": "implicit_thread"
}

OpenClaw reply guidance: This turn woke from implicit thread participation, not a direct bot mention. If the message is addressed to someone else, reply only when you have a specific useful addition, such as correcting an important mistake or adding requested context; otherwise use the current chat's no-response behavior.

• Observed result after fix: The runtime context now distinguishes implicit thread participation from a direct bot mention and preserves the actual mentioned Slack user id. The agent receives enough metadata to know that @dev was the explicit Slack mention, not OpenClaw.
• What was not tested: Slack user-group live membership behavior was covered by focused tests but not by a live workspace user-group repro.
• Before evidence: On main commit 3a0b81af9d7d86807be030415e2d1b1b38dae949, the same Slack thread path woke OpenClaw but only exposed the collapsed mention state:

{
  "is_group_chat": true,
  "was_mentioned": true
}

The prompt did not expose explicitly_mentioned_bot, mentioned_user_ids, implicit_mention_kinds, or mention_source, so the agent could not reliably tell that the visible Slack mention was aimed at another user.

Root Cause (if applicable)

• Root cause: The Slack inbound path reduced mention handling to a boolean wake decision before prompt metadata was built, so provider-native mention details could be lost.
• Missing detection / guardrail: The previous Slack prepare tests did not lock in explicit mention-target metadata for implicit thread wakes.
• Contributing context (if known): Slack has multiple wake sources: app mentions, user-group mentions, regex mention patterns, implicit thread participation, and command bypasses.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/slack/src/monitor/message-handler/prepare.test.ts, src/auto-reply/reply/inbound-meta.test.ts
• Scenario the test should lock in: Explicit user/user-group mention metadata and mention source survive Slack prepare and appear in inbound prompt context, including implicit thread wakes and command-bypass wakes.
• Why this is the smallest reliable guardrail: The bug is in message preparation and prompt metadata construction, both of which are covered without needing a live Slack workspace.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Slack agents receive more precise inbound metadata for group/thread mention decisions. No config or default behavior changes.

Diagram (if applicable)

Before:
Slack message -> boolean wake decision -> prompt lacks native mention detail

After:
Slack message -> mention metadata + wake source -> prompt includes native mention detail

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Ubuntu 24.04
• Runtime/container: Node v22.22.0, pnpm v10.33.2
• Model/provider: openrouter/owl-alpha for live Slack repro
• Integration/channel: Slack socket mode, #social channel thread
• Relevant config (redacted): channels.slack.mode="socket", channels.slack.groupPolicy="open", channels.slack.requireMention=false, channels.slack.replyToMode="all", channels.slack.thread.requireExplicitMention=false; visible group replies temporarily set to automatic for screenshot/log proof.

Steps

1. On main, start the gateway with Slack enabled.
2. In a Slack channel where OpenClaw can respond, create or reuse a thread where OpenClaw has already participated.
3. In that thread, send a message that mentions another Slack user, not the bot.
4. Inspect the OpenClaw runtime context for the resulting Slack session.
5. Repeat the same thread flow on this PR branch.
6. Run focused tests and checks:
   • pnpm test extensions/slack/src/monitor/message-handler/prepare.test.ts src/auto-reply/reply/inbound-meta.test.ts -- --reporter=verbose
   • pnpm tsgo:core
   • pnpm tsgo:extensions
   • pnpm exec oxfmt --check --threads=1 extensions/slack/src/monitor/message-handler/prepare.ts src/auto-reply/reply/inbound-meta.ts src/auto-reply/templating.ts extensions/slack/src/monitor/message-handler/prepare.test.ts src/auto-reply/reply/inbound-meta.test.ts
   • git diff --check

Expected

• Main branch shows the collapsed/insufficient metadata: was_mentioned: true without the native Slack mention target/source fields.
• PR branch includes explicitly_mentioned_bot, mentioned_user_ids, implicit_mention_kinds, and mention_source for the same behavior path.
• Slack prepare and inbound prompt tests pass.
• Type checks pass.
• Formatter and diff whitespace checks pass.
• PR file list contains only implementation/test files for this fix.

Actual

• Main branch reproduced the issue: runtime context only showed was_mentioned: true for the affected implicit-thread path.
• PR branch fixed the runtime context: explicitly_mentioned_bot: false, mentioned_user_ids: ["U_DEV_REDACTED"], implicit_mention_kinds: ["bot_thread_participant"], and mention_source: "implicit_thread" were present.
• Focused Vitest run passed 97 tests across 2 shards.
• pnpm tsgo:core passed.
• pnpm tsgo:extensions passed.
• Formatter check passed.
• git diff --check passed.
• GitHub PR file list contains only the five Slack/prompt implementation and test files.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Live Slack implicit thread wake with another user mentioned; Slack mention metadata preservation; user-group mention source handling in tests; command-bypass priority in tests; prompt metadata rendering; selective implicit-thread reply guidance.
• Edge cases checked: Explicit bot mentions, implicit thread wakes, command-bypass wakes, bot user-group membership and non-membership, regex mention roots, direct vs group prompt metadata.
• What you did not verify: Live Slack user-group membership path.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Prompt metadata shape changes could expose Slack-native mention fields in more cases than before.
  • Mitigation: Fields are bounded string arrays/source enums already derived from inbound Slack message metadata and covered by focused prompt tests.