feat(slack): port Discord parity — mentions, multibot, bot turn limits

[dogzzdogzz]

Discord Discussion URL: https://discord.com/channels/1491295327620169908/1494739741600387204/1495409492089769984

Summary

Ports recent Discord-side work to the Slack adapter so both platforms share the same safety and feature surface, plus a Discord race-condition fix. Slack slash-command support was attempted and then removed — see row 4 below.

#	Area	What changes	Why
1	Mention resolution	strip_slack_mention → resolve_slack_mentions(text, bot_id): strips only the bot's own <@UID>, preserves other user mentions.	Correctness: the old function wiped every <@…>, so the LLM could never @-mention users in its reply (Discord's resolve_mentions already works this way).
2	MultibotMentions	AllowUsers::MultibotMentions was accepted by config but fell through to Involved with no other-bot check. Added a multibot_threads cache populated eagerly from incoming bot events, widened bot_participated_in_thread to return (involved, other_bot), and split the gating arm.	Advertised behaviour now actually fires — mirrors Discord #481 / #483.
3	Bot turn limits	Ported the soft/hard BotTurnTracker to Slack, running before self-check so every bot message counts. Reset on human message. New max_bot_turns field on SlackConfig (default 20). Discord's local copy moves into a new src/bot_turns.rs so both adapters share it.	Safety: Slack allowed bot-to-bot loops with only a 10-msg cap; now matches Discord's soft+hard 100 cap with human-reset.
4	Slash commands	Not supported on Slack. The Slack adapter ack-and-drops slash_commands / interactive envelopes with a debug log. Discord slash commands (/models, /agents, /cancel) are unchanged.	Slack's UI blocks third-party slash commands invoked from a thread reply composer ("/cmd is not supported in threads. Sorry!"), and the channel-level payload carries no thread_ts so it can't route to a per-thread ACP session. Most ACP agents (notably claude-code) also don't emit configOptions for model/agent switching, making the menu empty even when routing works. The feature was added and then removed in this same PR (see the revert(slack): remove slash command support commit) because there was no working path end-to-end.
5	Docs / example config	Updated config.toml.example and docs/slack-bot-howto.md with max_bot_turns and the multibot-mentions variant. (Slash-command registration steps were added and later removed in line with row 4.)	User-facing surface changed.
6	Chore	Added CLAUDE.md to .gitignore (local AI context file shouldn't land in the repo).	—
7	Discord bug fix	On create_thread_from_message failing with error 160004 ("A thread has already been created for this message"), refetch the trigger message and join the thread the sibling bot just created instead of giving up.	Reproduced in prod: "@bob say hi to @patrick" → both bots race to create a thread from the same trigger; the loser used to log ERROR failed to create thread: A thread has already been created for this message and drop the turn.

Test plan

• cargo clippy --all-targets -- -D warnings — clean
• cargo test — 81 pass / 0 fail (8 Slack tests + 3 Discord tests for the thread-race matcher + 12 BotTurnTracker tests relocated to the shared module)
• Smoke test: start a bot-to-bot loop with allow_bot_messages = "all" and max_bot_turns = 5 → loop halts at the soft cap with a warning; human message resets
• Smoke test: allow_user_messages = "multibot-mentions" with two bots in a thread → @mention required after the second bot posts
• Smoke test: Discord message @bot-a say hi to @bot-b → both bots post in the same thread (no failed to create thread error)

Commit history

1. feat(slack): port Discord parity — mentions, multibot, turn limits, slash commands — initial bundle
2. chore: ignore CLAUDE.md
3. fix(discord): join existing thread when racing a sibling bot
4. feat: force send-once per thread when a trigger message tags other members — experimental (reverted)
5. Revert "feat: force send-once per thread when a trigger message tags other members" — revert of fix: pull --rebase before push in bump-chart #4
6. revert(slack): remove slash command support — row 4 above

Net effect vs main: rows 1, 2, 3, 5, 6, 7 are live; row 4 is a no-op in the diff.

Notes for reviewers

• Single PR per author request. History has a noisy pair (force send-once + its revert) that cancels out in the diff.
• Helm chart isn't updated — Slack's max_bot_turns falls back to the Rust default (20), same as Discord currently does in the chart.
• multibot-mentions validation already exists in charts/openab/templates/configmap.yaml:84 — no chart change needed to unlock the Slack behaviour.
• Row 7's fix is matched by error-string heuristic (160004 or "already been created"); covered by unit tests so serenity formatting changes will be caught.
• If Slack eventually removes the thread restriction on third-party slash commands, restoring row 4 is straightforward — the deleted helpers live only in git history.

🤖 Generated with Claude Code

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: feat(slack): port Discord parity — mentions, multibot, bot turn limits, slash commands
• Source: feat(slack): port Discord parity — mentions, multibot, bot turn limits #487
• Status: moved to PR-Screening
• Generated at: 2026-04-20T09:31:49.792Z
• Discord thread: https://discord.com/channels/1488041051187974246/1495718367212994621

Screening report

## Intent

This PR is trying to close the feature and safety gap between the Slack adapter and the Discord adapter. The concrete operator-visible problem is that Slack currently behaves differently in several important areas: it strips all mentions instead of only the bot's own mention, does not correctly enforce the advertised multibot-mentions behavior, has weaker bot-loop protection, lacks slash-command UX that Discord already has, and still leaves a known Discord thread-race bug unresolved.

In practical terms, the item is about making Slack safer to run in multi-bot environments and more usable for admins and end users, while also fixing one production-relevant Discord edge case discovered during parity testing.

Feat

This is primarily a feature-parity PR with bundled safety fixes, one bug fix, and accompanying docs/config updates.

Behaviorally, it does five real things:

• Makes Slack mention resolution preserve user mentions while stripping only the current bot's own mention.
• Implements actual MultibotMentions gating logic on Slack instead of silently falling back to a looser mode.
• Ports the shared bot turn-limit logic to Slack so bot-to-bot loops are bounded the same way as Discord.
• Adds Slack slash-command handling for /models, /agents, and /cancel.
• Fixes a Discord race where two bots can try to create the same thread and one used to drop the turn.

Classification: feature + fix + docs improvement, bundled into one PR.

Who It Serves

The primary beneficiaries are Slack deployers and multi-bot runtime operators, because they need Slack to behave predictably and safely under the same policies already established on Discord.

Secondary beneficiaries are:

• Slack end users, who get usable mentions and slash-command controls
• Maintainers and reviewers, who benefit from shared bot-turn logic and reduced platform drift
• Discord operators, because the thread-race bug fix prevents dropped turns in real multi-bot use

Rewritten Prompt

Bring the Slack adapter to parity with current Discord behavior in four scoped areas: mention resolution, multibot mention gating, bot turn limits, and slash-command handling. Preserve non-bot user mentions in Slack input, implement real multibot-mentions enforcement using thread participation state, reuse a shared BotTurnTracker module across Discord and Slack with configurable max_bot_turns, and add Socket Mode handling for /models, /agents, and /cancel using ephemeral select-based responses.

Also fix the Discord thread-creation race by detecting the "thread already exists" case, refetching the trigger message, and joining the existing thread instead of dropping the turn. Update config/docs for all new or exposed behavior, and cover each area with unit tests plus smoke-test notes for Slack command flow, multibot gating, loop stopping, and Discord dual-bot thread creation.

Merge Pitch

This item is worth advancing because it reduces platform inconsistency in a place where inconsistency directly creates operator confusion and runtime risk. OpenAB already has the intended safety model and interaction model on Discord; this PR mostly makes Slack stop being the odd one out.

The risk profile is moderate. The main reviewer concern will be bundling: multiple behavior changes across Slack plus a Discord fix in one PR makes regression review harder. The substance is good, but the merge discussion should focus on whether to land as one bundle or split into smaller reviewable slices.

Best-Practice Comparison

Relevant OpenClaw principles:

• Explicit delivery routing: relevant. Mention resolution and multibot gating both affect whether the system responds to the right actor in the right context.
• Retry/backoff and run logs: only partially relevant. The Discord thread-race fix is in the same reliability family, but this PR is not introducing broader retry or observability structure.
• Gateway-owned scheduling: not relevant.
• Durable job persistence: not relevant.
• Isolated executions: not directly relevant, though bot turn limits do reduce cross-bot runaway behavior.

Relevant Hermes Agent principles:

• Fresh session per scheduled run: not relevant.
• Self-contained prompts for scheduled tasks: not relevant.
• File locking to prevent overlap: conceptually relevant to the Discord race fix, in the sense that overlapping work must be handled safely, but this PR resolves overlap by fallback recovery rather than locking.
• Atomic writes for persisted state: only lightly relevant if the new Slack thread/bot caches are persisted, which does not appear to be the core design here.
• Gateway daemon tick model: not relevant.

Best-practice read:

• The strongest alignment is with operational safety and explicit routing, not with scheduling architecture.
• The Slack bot-turn tracker and multibot gating move OpenAB toward clearer execution boundaries.
• The Discord race fix is pragmatic and production-oriented, but it is still heuristic-driven rather than a stronger coordination primitive.

Implementation Options

Option 1: Merge the PR largely as-is, with targeted review focus

Keep the bundled parity approach. Review it as one parity/safety package, verify the unit tests, and require the listed smoke tests before merge or immediately after behind maintainer validation.

This is the fastest path and preserves the author's intended "single PR" packaging, but it keeps review complexity high.

Option 2: Split into two merge units

Separate the work into:

• Slack parity and safety changes: mention resolution, multibot gating, bot turn limits, slash commands, docs/config
• Discord bug fix: thread creation race handling

This keeps the logical theme mostly intact while isolating the unrelated Discord fix. It reduces review noise and makes rollback safer if Slack behavior needs iteration.

Option 3: Split into three narrower tracks with shared-core extraction

Separate into:

• Shared bot_turns extraction and Slack bot turn enforcement
• Slack interaction parity: mentions, multibot gating, slash commands, docs/config
• Discord thread-race fix

This is the most maintainable review shape and best for long-term change history. It makes each behavior set easier to test and reason about, but costs more maintainer overhead now.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Option 1: Merge as bundled parity PR	High	Medium-High in review	Medium	Medium-Low	High	Medium
Option 2: Split Slack parity from Discord fix	Medium-High	Medium	High	High	High	High
Option 3: Split into three narrower tracks	Medium-Low	High process overhead	High	Very High	High	Medium-High

Recommendation

Recommend Option 2: split the Slack parity/safety work from the Discord thread-race fix, then advance both.

That is the right step for merge discussion because it preserves nearly all delivery momentum while removing the clearest review objection: one PR currently mixes a broad Slack parity bundle with a separate Discord production bug fix. The Slack bundle is coherent enough to stand on its own, and the Discord fix is small, concrete, and independently valuable. If further splitting is needed after review, the next split should be to isolate slash commands from the Slack safety/core parity path, but that should be a second-order decision rather than the default starting point.

[chaodu-agent]

🔴 MultibotMentions gating bug — multi-bot threads silently drop all messages

The MultibotMentions arm in slack.rs does if other_bot { continue; } without checking mentions_bot. This means in a multi-bot thread, even if the user explicitly @mentions the bot, the message is dropped.

Expected flow:

┌─────────────────────────────┐
│  Thread message arrives     │
│  (allow_user_messages =     │
│   MultibotMentions)         │
└─────────────┬───────────────┘
              │
              ▼
       ┌──────────────┐
       │  has_thread?  │──── No ───▶ continue (skip)
       └──────┬───────┘
              │ Yes
              ▼
       ┌──────────────┐
       │   involved?   │──── No ───▶ continue (skip)
       └──────┬───────┘
              │ Yes
              ▼
       ┌───────────────┐
       │  other_bot?   │──── No ───▶ ✅ process (single-bot thread, no mention needed)
       └──────┬────────┘
              │ Yes (multi-bot thread)
              ▼
     ┌─────────────────┐
     │  mentions_bot?  │──── Yes ──▶ ✅ process (user @mentioned this bot, allow)
     └────────┬────────┘
              │ No
              ▼
        ❌ continue (skip)
        "multi-bot thread without @mention → ignore"

Current PR code (bug):

       ┌───────────────┐
       │  other_bot?   │──── No ───▶ ✅ process
       └──────┬────────┘
              │ Yes
              ▼
        ❌ continue (skip)    ◀── 🐛 missing mentions_bot check
                                    drops ALL messages in multi-bot threads

Suggested fix — one-line change:

- if other_bot {
+ if other_bot && !mentions_bot {
      continue;
  }

Without this, MultibotMentions on Slack = bot goes completely silent in any thread where another bot has posted, even when the user explicitly @mentions it. Discord's implementation correctly gates on !mentions_bot, so this would be a parity gap.

[chaodu-agent]

🟡 NIT: Bot turn result handling is duplicated across adapters

BotTurnTracker is now shared in src/bot_turns.rs (nice!), but the ~50-line match block that acts on TurnResult is copy-pasted in both discord.rs and slack.rs. The warning messages, log levels, and warn-once semantics are nearly identical — only the ChannelRef construction differs.

Discord side (simplified):

match tracker.on_bot_message(&thread_id) {
    TurnResult::HardLimit => {
        warn!(channel_id, "hard bot turn limit reached");
        adapter.send_message(&channel_ref,
            &format!("🛑 Hard bot turn limit reached ({HARD_BOT_TURN_LIMIT}). ...")
        ).await;
        return;
    }
    TurnResult::SoftLimit(n) => {
        info!(channel_id, turns = n, "soft bot turn limit reached");
        adapter.send_message(&channel_ref,
            &format!("⚠️ Bot turn limit reached ({n}/{max}). ...")
        ).await;
        return;
    }
    TurnResult::Throttled | TurnResult::Stopped => return,
    TurnResult::Ok => {}
}

Slack side (simplified) — almost identical:

match tracker.on_bot_message(&turn_key) {
    TurnResult::HardLimit => {
        warn!(channel_id, "hard bot turn limit reached");
        adapter.send_message(&warn_channel,
            &format!("🛑 Hard bot turn limit reached ({HARD_BOT_TURN_LIMIT}). ...")
        ).await;
        continue;
    }
    TurnResult::SoftLimit(n) => {
        info!(channel_id, turns = n, "soft bot turn limit reached");
        adapter.send_message(&warn_channel,
            &format!("⚠️ Bot turn limit reached ({n}/{max}). ...")
        ).await;
        continue;
    }
    TurnResult::Throttled | TurnResult::Stopped => continue,
    TurnResult::Ok => {}
}

The only real difference is how ChannelRef / warn_channel is built. It might be worth considering extracting the message formatting into a shared helper in bot_turns.rs, e.g.:

// in src/bot_turns.rs
pub enum TurnAction {
    Continue,
    WarnAndStop(String),  // warning message to send
    SilentStop,
}

impl BotTurnTracker {
    pub fn check_and_format(&mut self, thread_id: &str, soft_limit: u32) -> TurnAction {
        match self.on_bot_message(thread_id) {
            TurnResult::Ok => TurnAction::Continue,
            TurnResult::SoftLimit(n) => TurnAction::WarnAndStop(
                format!("⚠️ Bot turn limit reached ({n}/{soft_limit}). \
                         A human must reply in this thread to continue.")
            ),
            TurnResult::HardLimit => TurnAction::WarnAndStop(
                format!("🛑 Hard bot turn limit reached ({HARD_BOT_TURN_LIMIT}). \
                         A human must reply to continue.")
            ),
            TurnResult::Throttled | TurnResult::Stopped => TurnAction::SilentStop,
        }
    }
}

Then both adapters shrink to:

match tracker.check_and_format(&key, max_bot_turns) {
    TurnAction::WarnAndStop(msg) => { adapter.send_message(&ch, &msg).await; continue; }
    TurnAction::SilentStop => continue,
    TurnAction::Continue => {}
}

Not a blocker for this PR — the current code works. But as more adapters land (Teams? Telegram?), maintaining identical warning text and log semantics in N places will get painful.

[masami-agent]

PR Review: #487

Summary

• Problem: Slack adapter lacked several safety and feature-parity items that Discord already had: correct mention resolution, multibot-mentions gating, shared bot turn limits, text-file attachments, and a Discord thread-race fix.
• Approach: Port each feature from Discord to Slack, extract shared logic (BotTurnTracker → bot_turns.rs), and fix a Discord race condition where two bots create threads from the same trigger message.
• Risk level: Medium — touches core message routing in both adapters, but well-tested (81+ tests) and CI passes.

Core Assessment

1. Problem clearly stated: ✅ — PR description is thorough with a table of changes, rationale, and test plan.
2. Approach appropriate: ✅ — Extracting shared bot_turns.rs is the right call. Porting feature-by-feature with matching semantics is clean.
3. Alternatives considered: ✅ — Slash commands were attempted and deliberately reverted with clear reasoning (Slack platform limitations).
4. Best approach for now: ✅ — Minimal, focused changes with good parity reasoning.

Findings

src/bot_turns.rs (new shared module)

Clean extraction. The classify_bot_message → TurnAction helper is a good abstraction that eliminates the duplicated match block in both adapters. Tests are comprehensive (20 tests covering soft/hard limits, reset, warn-once, per-thread independence, classify API).

One observation: on_human_message resets both soft and hard counters to 0. The doc comment on HARD_BOT_TURN_LIMIT says "the hard counter also tracks the lifetime total and caps it regardless" — but the implementation resets hard on human message too. This is consistent with the existing Discord behavior (same code was moved), so it's not a regression, but the doc comment is slightly misleading. The hard limit is really "max consecutive bot turns without human intervention", not a lifetime cap.

src/discord.rs — thread race fix

The is_thread_already_exists_error heuristic (string matching on 160004 or "already been created") is pragmatic. The fallback path (refetch message → read .thread → join) is correct. Unit tests cover the detection. One edge case worth noting: if the refetch succeeds but message.thread is None (e.g., the sibling bot's thread was deleted between the error and the refetch), the error message is clear and propagates correctly.

src/slack.rs — multibot-mentions

The MultibotMentions arm now correctly checks !mentions_bot before continuing — this was the bug fix from the follow-up commit. The eager note_other_bot_in_thread call before self-check mirrors Discord #481 ordering. The bot_participated_in_thread return type change to (bool, bool) is clean.

src/slack.rs — bot turn tracking

The turn key construction uses thread_ts when in a thread, else channel:ts. For non-thread messages, channel:ts is unique per message, so the tracker would never accumulate — but this is correct because non-thread bot messages can't form loops. The tracker lock scope is tight (released before the handle_message call).

src/slack.rs — is_plain_user_message whitelist

Good defensive approach. The whitelist ("" | me_message | thread_broadcast | file_share) is safer than the previous blacklist approach. Tests cover the full system-subtype list. Parity with Discord's MessageType::Regular | InlineReply gate.

src/slack.rs — text-file attachments

Clean port of Discord PR #291. The strip_mime_params helper handles Slack's text/plain; charset=utf-8 edge case. The post-download cap check (text_file_bytes + actual_bytes > TEXT_TOTAL_CAP) correctly handles the size == 0 bypass for externally-backed files. The slack_file_download_url helper with url_private_download → url_private fallback is well-tested.

src/slack.rs — resolve_slack_mentions

Core correctness fix: the old strip_slack_mention wiped all <@UID> patterns, preventing the LLM from @-mentioning users back. The new function strips only the bot's own mention. Simple and correct.

src/slack.rs — handle_message signature change

The strip_mentions: bool parameter is removed and replaced with always calling resolve_slack_mentions. This is correct — both app_mention and message events should resolve mentions the same way (strip bot, preserve others).

Review Summary

🔴 Blockers

(none)

💬 Questions

1. The Cargo.lock diff shows openab version changing from 0.7.8 → 0.8.1. This appears to come from the merge commits pulling in main's Cargo.toml version bump. Can you confirm this is just a merge artifact and not an intentional version bump in this PR? (The PR itself doesn't modify Cargo.toml version.)

2. The PR description mentions "Single PR per author request" — was there a reason not to split the Discord thread-race fix (row 7) into its own PR? It's an independent bug fix that could be merged separately. Not blocking, just curious about the rationale.

3. No Closes #XX in the PR description — are there tracking issues for any of these features (multibot-mentions on Slack, bot turn limits on Slack, the Discord thread-race bug)?

🔧 Suggested Changes

1. Doc comment on HARD_BOT_TURN_LIMIT — The comment says "the hard counter also tracks the lifetime total and caps it regardless" but on_human_message resets both counters. Consider updating the comment to say something like "Absolute per-thread cap on consecutive bot turns without human intervention" to match the actual behavior.

2. MAX_CONSECUTIVE_BOT_TURNS is now dead code — src/discord.rs line 23 still has const MAX_CONSECUTIVE_BOT_TURNS: u8 = 10; which was the old Slack-only cap. It's no longer referenced anywhere in the diff. Should be removed.

ℹ️ Info

• CI is all green (check + 7 smoke tests pass).
• The commit history has a noisy add/revert pair (force send-once + its revert) that cancels out in the net diff — confirmed, no residual changes.
• The slash command removal is well-documented with three independent technical reasons. The docs/slack-bot-howto.md section explaining why is a nice touch for users.

⚪ Nits

(none — code is clean and well-commented)

Verdict

COMMENT — no blockers, but would like answers to the questions above (especially Q1 on the Cargo.lock version and Q3 on issue tracking) before approving.

[obrutjack]

PR Review: #487

Summary

• Problem: Slack adapter lacked Discord's safety features — bot turn limits, multibot mention gating, correct mention resolution, text-file attachments
• Approach: Port Discord safety features to Slack, extract shared BotTurnTracker into bot_turns.rs, fix Discord thread-creation race
• Risk level: Low

Core Assessment

1. Problem clearly stated: ✅
2. Approach appropriate: ✅
3. Alternatives considered: ✅ (slash commands tried and reverted with clear reasoning)
4. Best approach for now: ✅

Review Summary

🔴 Blockers

None.

ℹ️ Info

• BotTurnTracker extracted identically from discord.rs → bot_turns.rs, no logic change
• resolve_slack_mentions correctly strips only bot's own <@UID> — fixes the old strip_slack_mention that wiped all mentions
• MultibotMentions now has explicit !mentions_bot guard — correct Discord parity
• is_plain_user_message whitelist prevents system subtypes from resetting counter (#497 parity)
• Text file caps (5 files / 1MB) match Discord; post-download enforcement handles Slack's size==0 edge case
• Thread race fix uses string heuristic for error 160004, covered by unit tests
• max_bot_turns has serde(default) → backward compatible with existing config.toml
• turn_key for non-thread Slack messages is unique per message (channel:ts) — effectively a no-op counter, correct since bot loops only happen in threads
• MAX_CONSECUTIVE_BOT_TURNS (legacy history-based cap) still used in discord.rs for AllowBots::All — separate from BotTurnTracker, not touched by PR
• CI all green (10/10 checks), 81 tests pass, no secrets/PII in diff

Verdict

APPROVE — clean PR with thorough test coverage, well-documented commit history, and faithful Discord→Slack parity.

[thepagent]

Thank you @masami-agent ! You did great jobs!