Bug Description

After commit a01e767b (fix(gateway): respect config.yaml slack.enabled when SLACK_BOT_TOKEN env var is set), the Slack gateway adapter silently fails to start whenever config.yaml contains a top-level slack: block — even if that block has no enabled key. Setting SLACK_BOT_TOKEN no longer enables the adapter the way it did pre-commit; the gateway just logs Gateway running with N platform(s) and Slack isn't in the list. No warning, no error.

The root cause is that the yaml-bridging loop adds Platform.SLACK to config.platforms whenever any bridged key (channel_prompts, require_mention, channel_skill_bindings, etc.) is present in the top-level slack: block. Once it's in config.platforms, the new env-override code path skips the enabled = True branch and the adapter is suppressed — even though the user has done nothing to disable it.

This produces a silent, hard-to-diagnose breakage for any pre-existing setup that had a slack: block (which is the natural place users put channel_prompts, etc.) and relied on SLACK_BOT_TOKEN to enable the adapter. In a multi-profile deployment it can take down Slack across every profile at once.

Steps to Reproduce

1. Have a working Slack gateway prior to a01e767b, with SLACK_BOT_TOKEN and SLACK_APP_TOKEN in the environment and a ~/.hermes/config.yaml like:

  slack:
    channel_prompts: {}

1. Pull a01e767b (or any release that includes it).
2. Restart the gateway: systemctl --user restart hermes-gateway.service.
3. Tail ~/.hermes/logs/gateway.log and observe:
   • Connecting to webhook...
   • Gateway running with 1 platform(s)
   • No Connecting to slack... line, no warning, no error.
4. In Slack, send the bot a DM. It does not respond.
5. Confirm the tokens are still valid by inspecting /proc/<gateway-pid>/environ (SLACK_BOT_TOKEN/SLACK_APP_TOKEN are present).

Expected Behavior

Either of:

• SLACK_BOT_TOKEN set → adapter enabled, unless config.yaml explicitly sets enabled: false. (Pre-a01e767b behavior.)
• Or, if the new behavior is intentional, the gateway should log a clear warning when a token is set but the adapter is suppressed — e.g.: Slack token set but adapter not started — add 'platforms.slack.enabled: true' to config.yaml.

Actual Behavior

Adapter is silently skipped. There is no log line indicating Slack was even considered. The user only finds out when the bot stops answering in Slack, and the only way to diagnose is to read gateway/config.py and trace the env-override code path.

The needed fix is non-obvious: adding enabled: true to the existing top-level slack: block does not work, because enabled is not in the bridged-keys list at gateway/config.py:580-624. Users have to add a separate top-level platforms: block:

  platforms:
    slack:
      enabled: true

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

Slack

Debug Report

N/A - Debug logs won't diagnose this.

Operating System

Ubuntu 24.04.4 LTS (Noble Numbat)

Python Version

3.11.15

Hermes Version

0.11.0

Additional Logs / Traceback (optional)

No Python traceback. This is a silent suppression — the only signal is the absence of expected log lines.

  Pre-a01e767b (working):
  INFO gateway.run: Connecting to slack...
  INFO gateway.platforms.slack: [Slack] Authenticated as @hermes …
  INFO gateway.run: ✓ slack connected
  INFO gateway.run: Gateway running with 2 platform(s)

  Post-a01e767b with same env + same yaml:
  INFO gateway.run: Connecting to webhook...
  INFO gateway.run: ✓ webhook connected
  INFO gateway.run: Gateway running with 1 platform(s)

Root Cause Analysis (optional)

Two interacting code paths in gateway/config.py:

1. The yaml-bridging loop at lines 574-624 walks each Platform and, when a top-level slack: block contains any bridged key (channel_prompts, require_mention,channel_skill_bindings, mention_patterns, etc.), inserts Platform.SLACK into platforms_data with an extra dict. enabled is not in the bridged-keys set, so the resulting PlatformConfig has enabled=False (the dataclass default).

2. The env-override code at lines 938-947 (introduced/changed by a01e767b):

slack_token = os.getenv("SLACK_BOT_TOKEN")
  if slack_token:
      if Platform.SLACK not in config.platforms:
          # No yaml config for Slack — env-only setup, enable it
          config.platforms[Platform.SLACK] = PlatformConfig()
          config.platforms[Platform.SLACK].enabled = True
      # If yaml config exists, respect its enabled flag …
      config.platforms[Platform.SLACK].token = slack_token

1. Because step (1) put Platform.SLACK into config.platforms, the enabled = True branch is skipped. The token is stored but the adapter is never activated.

The original commit's intent was to support skills-only SLACK_BOT_TOKEN usage (e.g., cron jobs that send Slack messages without running the gateway adapter). It conflated "yaml mentions Slack at all" with "yaml says enabled: false", which is what causes the regression.

Proposed Fix (optional)

Any of these would resolve it; combining (1) and (3) gives the best UX:

1. Treat enabled as tri-state. Distinguish "yaml didn't mention enabled" from "yaml said enabled: false". Only the latter should suppress activation when SLACK_BOT_TOKEN is set. The skills-only use case the original commit cared about can be expressed by an explicit enabled: false (or, more cleanly, by checking that SLACK_APP_TOKEN is also present before activating the adapter — its absence is what produced the original SLACK_APP_TOKEN not set errors).
2. Bridge enabled from the top-level slack: block. Add enabled to the bridged-keys set in the yaml loop (lines 580-624). That would let users put enabled: true next to channel_prompts — which is the natural location and matches what migration-on-upgrade users expect.
3. Log a warning when a token is set but the adapter is suppressed. Even keeping current behavior, a single logger.warning(...) line pointing at platforms.slack.enabled: true would have saved hours of diagnosis. Apply the same pattern to Discord/Telegram if they share the structure.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR