#19917: feat(discord): allow disabling intermediate status reactions

## Summary - Problem: Discord shows intermediate status reactions (🧠 thinking, 🛠️ tool use, ✅ done, etc.) that cycle rapidly during message processing, causing a distracting flickering effect. - Why it matters: The visual noise is distracting in active conversations, and users often prefer the cleaner pre-2026.2.17 behavior. - What changed: Added a statusReactions configuration option (globally and per-Discord-account) to allow disabling these intermediate updates while keeping the initial acknowledgment reaction. - What did NOT change (scope boundary): The initial acknowledgment reaction and its removal after reply remain functional. Non-Discord channels are unaffected. ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #19790 ## User-visible / Behavior Changes Added statusReactions (boolean, default: true) to both messages and channels.discord config sections. When set to false, the bot will only show the initial acknowledgment reaction and skip intermediate status updates (🧠, 🛠️, ✅, etc.). ## Security Impact (required) - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No - Command/tool execution surface changed? No - Data access scope changed? No - If any Yes, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: Windows - Runtime/container: Native - Model/provider: AI-Assisted - Integration/channel (if any): Discord - Relevant config (redacted): messages: { statusReactions: false } ### Steps 1. Configure messages: { statusReactions: false }. 2. Send a message to the Discord bot that triggers reasoning or tool use. 3. Observe the reactions appearing on the message. ### Expected - Only the initial acknowledgment reaction (e.g., 👀) should appear. Intermediate status emojis should not be sent. ### Actual - Only the initial acknowledgment reaction appears. No flickering or emoji cycling observed. ## Evidence - [x] Failing test/log before + passing after (New verification test added to [message-handler.process.test.ts] - [x] Trace/log snippets: ```text RUN v4.0.18 ✓ src/discord/monitor/message-handler.process.test.ts (6 tests) 161ms Test Files 1 passed (1) Tests 6 passed (6) Duration 4.19s ``` ## Human Verification (required) - Verified scenarios: Disabling intermediate reactions via account-level config override. - Edge cases checked: Interaction with removeAckAfterReply: true (ensuring the ack is still removed correctly). - What you did not verify: Production environment deployment (verified in simulated local environment). ## Compatibility / Migration - Backward compatible? Yes (Default behavior is unchanged) - Config/env changes? Yes (New setting added) - Migration needed? No - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the commit or set statusReactions: true in config. - Files/config to restore: src/discord/monitor/message-handler.process.ts - Known bad symptoms reviewers should watch for: None expected. ## Risks and Mitigations None. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds a `statusReactions` boolean config option (default: `true`) at both the global `messages` level and per-Discord-account level to allow disabling intermediate status reactions (🧠 thinking, 🛠️ tool use, ✅ done, etc.) while preserving the initial acknowledgment reaction (e.g., 👀). - New `statusReactions` field added to `MessagesConfig` type, `DiscordAccountConfig` type, and their corresponding Zod schemas - `createDiscordStatusReactionController` gains an `intermediateEnabled` parameter; `requestEmoji` skips any emoji that differs from the initial ack emoji when intermediate reactions are disabled - Config resolution follows `discordConfig.statusReactions ?? cfg.messages.statusReactions ?? true` (account-level overrides global, default preserves existing behavior) - A new test verifies that intermediate and terminal status emojis are suppressed while the initial ack reaction still fires <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it adds a backward-compatible opt-in config flag with correct default behavior and clean implementation. - All changes are minimal, well-scoped, and backward compatible. The new config option defaults to `true` preserving existing behavior. Type definitions, Zod schemas, and runtime logic are consistent. The guard in `requestEmoji` correctly differentiates initial from intermediate emojis. Test coverage validates the core behavior. No security, performance, or correctness concerns identified. - No files require special attention. _{Last reviewed commit: c28d93d} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->