Slack handles get no channel context plane: claw-wall, channel-context feeds, and channel:// routing are Discord-gated

[mostlydev]

Verified against v0.27.0 (tag 65bf0db7; working tree v0.27.0-15-gf42af36).

Summary

Hermes Slack transport is wired, but the Clawdapus channel governance/context plane around it is Discord-only. A Slack-only agent starts and talks, then silently has none of the channel context, retrieval, or routing features a Discord agent gets. Nothing errors — the features are simply absent, which is the part that makes this worth fixing rather than documenting.

What is already wired for Slack

• internal/driver/hermes/config.go:38 — supportedPlatforms = []string{"discord", "slack", "telegram"}
• internal/driver/hermes/config.go:107 — adapter mapping "slack": "hermes-slack"
• internal/driver/hermes/driver.go:49-53 — preflight requires SLACK_BOT_TOKEN and SLACK_APP_TOKEN in the service environment
• internal/driver/hermes/config.go — hasSlackHandle participates in the shared handle paths at :156, :421, :437

So this is not "Slack is unsupported." Transport works.

What is Discord-gated

1. claw-wall is never injected for Slack. injectConversationWall (cmd/claw/compose_up.go:1960) selects trigger services with:

channelIDs := discordHandleChannelIDs(svc.Claw.Handles)
if len(channelIDs) == 0 {
    continue
}

A Slack-only pod therefore has len(triggerServices) == 0 and returns early. Consequences, all silent:

• no channel-context tail feed
• no default-on channel-awareness feed
• no search_channel_context / get_channel_messages mediated retrieval tools
• no channel-memory digest path (raw_window+digest), since it hangs off claw-wall

2. channel:// map-form routing is Discord-specific. cmd/claw/compose_up.go:2821 and :2825 speak only channel://discord, including the allow_from_services bot-identity check (DISCORD_BOT_TOKEN / DISCORD_TRADING_API_BOT_TOKEN). There is no Slack equivalent for DM policy or per-service allowlists.

3. Only the Discord wall base URL is plumbed. cmd/claw/compose_up.go:2049 handles conversationWallDiscordBaseEnv with no Slack counterpart.

Why it matters

The failure mode is absence, not error. A Slack agent comes up healthy, responds, and quietly lacks channel awareness and retrieval — so the gap surfaces later as "why does this agent have no memory of the channel" rather than at claw up.

Suggested direction

1. Generalize wall triggering from discordHandleChannelIDs to a platform-agnostic channel-ID accessor, with claw-wall growing a Slack poller alongside the Discord one.
2. Generalize channel:// map-form routing to channel://slack, with Slack-appropriate identity checks.
3. Short term, and cheap: fail loudly or warn at claw up when a Slack handle is declared and channel-context features are requested but cannot be provided. Silent absence is the worst of the available behaviours.

Scope note

Agents whose context comes from service:// feeds rather than channel history are unaffected — they need only the transport, which works today. This issue is specifically about the channel context plane.