PR #59030: fix(slack): route live DM replies to the concrete DM channel

• Repository: openclaw/openclaw
• Author: afurm
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/59030

Description (problem / solution / changelog)

Summary

• Problem: Slack DMs could receive pairing/system messages, but normal assistant replies were routed through the stored user:<id> target instead of the concrete inbound D... DM channel.
• Why it matters: that split made the live reply path behave differently from the pairing/system path, so DM turns could reach final_answer without the user seeing the normal reply in Slack.
• What changed: extensions/slack/src/monitor/message-handler/prepare.ts now uses channel:<dm-channel-id> as the live replyTarget for direct messages while keeping persisted routing metadata user-scoped; extensions/slack/src/monitor/message-handler/prepare.test.ts adds a regression test for that contract.
• What did NOT change (scope boundary): stored session routing remains user:<id>, Slack channel/group reply behavior is unchanged, and no outbound adapter or token/auth logic was modified.

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 #59001
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: the Slack monitor built ctxPayload.To as user:<slack-user-id> for DM session metadata, then reused that value as the immediate live replyTarget. That is appropriate for persisted routing, but not for the current inbound DM turn where the concrete Slack DM channel id is already known.
• Missing detection / guardrail: there was no regression test asserting that Slack DM live replies should use the inbound D... channel while persisted routing stays user-scoped.
• Prior context (git blame, prior PR, issue, or refactor if known): unknown.
• Why this regressed now: unknown from local inspection. I did not trace the exact introducing commit.
• If unknown, what was ruled out: this change does not touch Slack auth, pairing authorization, or the outbound send adapter; the issue is in the monitor prepare-stage target selection.

Regression Test Plan (if applicable)

• Coverage level that should have caught this: Unit test
• Target test or file: extensions/slack/src/monitor/message-handler/prepare.test.ts
• Scenario the test should lock in: a Slack DM turn should produce replyTarget = channel:D... while preserving ctxPayload.To = user:... and NativeChannelId = D....
• Why this is the smallest reliable guardrail: the bug is pure Slack monitor preparation logic and does not require a live Slack session to validate the target split.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Slack DMs now send the live assistant reply back into the same DM channel that produced the inbound turn. Channel mentions and persisted session routing behavior are unchanged.

Diagram (if applicable)

Before:
Slack DM inbound -> ctxPayload.To = user:U123 -> live reply reuses user target -> reply can miss the active DM

After:
Slack DM inbound -> replyTarget = channel:D123 + ctxPayload.To = user:U123 -> live reply lands in the same DM -> persisted routing still works

## Changed files

- `CHANGELOG.md` (modified, +8/-0)
- `extensions/slack/src/monitor/message-handler/prepare.test.ts` (modified, +13/-0)
- `extensions/slack/src/monitor/message-handler/prepare.ts` (modified, +5/-1)