feat(discord): configurable reaction emojis for processing lifecycle

[btorresgil]

What does this PR do?

Adds optional reaction_emojis config block under discord: to let users override the thinking/done/error emojis used during message processing. The master discord.reactions switch and DISCORD_REACTIONS env var continue to control all reaction activity as before.

Config shape:

discord:
  reactions: true
  reaction_emojis:
    thinking: "👀"   # optional; defaults to 👀
    done: "✅"        # optional; defaults to ✅
    error: "❌"       # optional; defaults to ❌

reaction_emojis is optional — omitting it preserves legacy behavior exactly.

Resolution semantics

For each slot (thinking, done, error):

Config value	Resolved behavior
Missing key	Use default emoji
null or ""	Disabled (no reaction)
Whitespace-only string	Disabled
Non-empty string	Use trimmed value

Lifecycle behavior

• On processing start: if reactions enabled and thinking resolves, add it.
• On processing complete: remove thinking if it was enabled; add done or error per outcome. Cancelled path removes thinking only, adds no terminal emoji.
• Reaction API errors remain non-fatal throughout.

Related Issue

Fixes #22365

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/platforms/discord.py — _resolve_emoji() helper + updated start/complete handlers
• gateway/config.py — reaction_emojis field added to Discord config model
• tests/gateway/test_discord_reactions.py — 15 new/updated tests covering defaults, disable semantics, trim, cancelled path, custom emojis, and master-switch override
• website/docs/user-guide/messaging/discord.md — documents the new config block

How to Test

1. Set config.yaml per this example:

discord:
  reaction_emojis:
    thinking: "🦄"   # optional; defaults to 👀
    done: ""        # optional; defaults to ✅
    error: "😭"       # optional; defaults to ❌

2. Send message in Discord
3. Notice that thinking emoji is now 🦄
4. Notice that after response, the thinking emoji is removed and a done emoji does not appear (because it is an empty string. Also null has the same behavior as empty string)

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• [N/A] I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• [N/A] I've updated tool descriptions/schemas if I changed tool behavior — or N/A

[MarcusTseng]

I took a pass over this because it matches #22365 exactly. The implementation shape looks good and matches the existing Discord reaction lifecycle. A few edge cases that may be worth adding before merge:

• Treat whitespace-only values the same as empty strings, e.g. done: " " disables that slot.
• Trim non-empty configured emoji strings, e.g. error: " ⚠️ " resolves to ⚠️.
• Gracefully ignore malformed reaction_emojis values that are not mappings, e.g. reaction_emojis: "🎉", and fall back to the built-in defaults instead of failing or applying the scalar to every slot.
• Keep omitted keys on defaults, especially partial overrides like:

  discord:
    reaction_emojis:
      done: "🎉"

  should still use 👀 for thinking and ❌ for error.

I also tested the same behavior locally with focused coverage around:

• full custom thinking / done / error
• per-slot disable with null, "", and whitespace-only strings
• partial override fallback to defaults
• malformed non-dict config fallback to defaults
• discord.reaction_emojis loading into PlatformConfig.extra

Validation command I used locally:

pytest tests/gateway/test_discord_reactions.py tests/gateway/test_discord_reply_mode.py -q

One process suggestion: keep this PR scoped to reaction_emojis only. I initially considered bundling related Discord linear-reply docs/tests, but a separate review caught that as scope creep; keeping this focused should make it easier to land for #22365.

[teknium1]

Thanks for the focused implementation and lifecycle coverage. The requested configurability is still needed: current main hardcodes the three lifecycle emojis in plugins/platforms/discord/adapter.py:1974-1986.

Problems

• The PR targets the pre-plugin adapter path, gateway/platforms/discord.py. Commit cc8e5ec2afbfd10a3cff4e710210dd9ecae64a33 moved the live adapter to plugins/platforms/discord/adapter.py without a compatibility shim.
• Current main routes top-level Discord YAML through gateway/config.py:1252-1287 into the plugin hook, plugins/platforms/discord/adapter.py:8229-8352. The PR's PlatformConfig.extra bridge must be adapted to that hook; otherwise reaction_emojis will not reach the env-driven runtime adapter.

Suggested changes

• Port the resolver and lifecycle substitutions to plugins/platforms/discord/adapter.py.
• Add the YAML translation to _apply_yaml_config and test config loading as well as direct lifecycle behavior.

Automated hermes-sweeper review.

[teknium1]

Current main moved Discord's YAML bridge into plugins/platforms/discord/adapter.py::_apply_yaml_config in cc8e5ec2. Please port this configuration handling to that plugin hook; the legacy bridge is no longer the runtime path.