Observed behavior

When channels.slack.groupPolicy is "allowlist", an entry keyed by a Slack channel name rather than its ID is silently ignored at routing time. Example openclaw.json:

"channels": {
  "slack": {
    "groupPolicy": "allowlist",
    "channels": {
      "example-channel":  { "requireMention": false },   // name — silently dropped
      "C0AL2GDUA7J":      { "requireMention": false }    // ID   — routes correctly
    }
  }
}

The bot accepts the config without error, connects, processes events normally for ID-keyed entries — but never matches the name-keyed entry. Messages in #example-channel simply don't reach the bot. There is no error log, no warning, no validation failure at boot.

Why it's a bug (not just a docs miss)

The docs at https://docs.openclaw.ai/channels/slack state that the keys under channels.slack.channels are Slack channel IDs. So name-keying is unsupported. But:

• Config validation accepts the unsupported shape.
• The routing layer doesn't log anything when it encounters a key that doesn't match ^[CGD][A-Z0-9]{8,}$.
• The operator has no signal until they notice the bot isn't responding in a channel they "configured" it for.

That combination — accepted-config + silent-runtime + no-signal — is the canonical silent-failure shape. It's the most common configuration mistake for any operator wiring Slack by hand against the docs.

Reproduction

1. Set groupPolicy: "allowlist" on a working Slack bot.
2. Add a name-keyed entry: "channels": { "<channel-name>": { "requireMention": false } }.
3. Send a message in #<channel-name>. No event reaches the bot. No log line is emitted.

Suggested fix

At minimum, a console.warn at gateway boot for any key in channels.slack.channels that fails the Slack channel ID heuristic:

[slack] channels.slack.channels."<channel-name>" is keyed by name, not a Slack channel ID.
        Entries under groupPolicy: "allowlist" key by ID and this entry will not match.
        Find the channel's Slack ID in the Slack URL or via conversations.info, then rekey.

Optional escalation: refuse to start under a strict mode flag, or surface as a structured event consumers can subscribe to.

The detection rule is trivial (regex test against the key); the warning closes the silent-failure loop without changing any semantics for correctly-configured installs.