feat(channels): outbound send to Telegram/Slack/Discord (CLI + MCP tool) (#152)

[getappz]

Closes #152.

The outward half of the channels effort: send a plain-text message out to Telegram / Slack / Discord. A one-shot blocking POST that fits agentflare's sync/ureq model, so an agent can push a message mid-run (MCP tool) or a human/script can from the CLI. The inbound daemon (getappz/flared#1) reuses this same path to send its replies.

What's new

• src/channels.rs
  • Platform { Telegram, Slack, Discord } with parse (case-insensitive) and secret_name.
  • pure build_request(platform, target, text, token) — the per-platform request shapes: Telegram POST /bot{token}/sendMessage {chat_id,text} (token in URL); Slack chat.postMessage {channel,text} + Authorization: Bearer; Discord POST /channels/{id}/messages {content} + Authorization: Bot.
  • pure interpret_response(platform, status, body) — status-only for Telegram/Discord; for Slack it inspects the ok field even on HTTP 200 and surfaces the error.
  • send() over ureq (handles ureq's non-2xx Err(Status) arm) and send_message(conn, …) which resolves the bot token from the encrypted gateway_secrets store.
• CLI: agentflare channel send --to <platform> --target <id> <message>.
• MCP tool: channel_send { platform, target, message } so an agent can send during a turn.

Design notes

• Tokens are never passed on the command line or hardcoded — read from the gateway secret <platform>_bot_token (AES-GCM in agentflare.db). Missing token → a clear error naming the secret.
• Plain text only for now — attachments, threads, and parse_mode/markdown are out of scope for this MVP.
• Sync/ureq, no new deps — matches agentflare's identity.

Tests (TDD)

• Platform::parse case-insensitivity + unknown rejection; secret_name mapping.
• build_request for each platform (URL, auth scheme, body fields).
• interpret_response: Telegram/Discord status-only; Slack ok:false on HTTP 200 → error surfacing the reason.
• send_message with no configured token → error naming the secret.
• Full suite green (296 passed, 0 failed); clippy clean; CLI driven end-to-end.

Summary by CodeRabbit

• New Features
  • Added outbound plain-text messaging to Telegram, Slack, and Discord.
  • Added a channel send CLI command to deliver messages by platform and destination.
  • Added an MCP tool to send outbound channel messages.
• Bug Fixes
  • Improved delivery result handling per platform (including Slack’s success flag behavior).
• Reliability Improvements
  • Clearer errors for missing credentials and transport/delivery failures, with sensitive details redacted.
• Tests
  • Added unit tests covering platform parsing, request/response handling, and error cases.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 2627aeb4-8d0c-416e-9ead-c9cc553877ab

📥 Commits

Reviewing files that changed from the base of the PR and between a08f190 and e69df0d.

📒 Files selected for processing (1)

• src/channels.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• src/channels.rs

---

📝 Walkthrough

Walkthrough

Adds outbound plain-text messaging to Telegram, Slack, and Discord through shared HTTP transport, a CLI command, and an MCP tool. Platform tokens are loaded from encrypted gateway secrets, and platform-specific response rules are applied.

Changes

Outbound channel messaging

Layer / File(s)	Summary
Channel transport and response handling src/channels.rs, src/main.rs	Defines platform parsing and secret names, builds Telegram/Slack/Discord requests, sends them through blocking HTTP, interprets responses, redacts transport errors, and tests the behavior.
CLI channel send command src/cli/channel.rs, src/cli/mod.rs	Adds channel send, validates the platform, opens the database, sends the message, and prints the result.
MCP channel send tool src/mcp_server.rs	Adds the channel_send request schema and handler with platform validation, message delivery, and JSON result/error mapping.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CLI_or_MCP
  participant send_message
  participant gateway_secrets
  participant TelegramSlackDiscord
  CLI_or_MCP->>send_message: platform, target, message
  send_message->>gateway_secrets: load encrypted bot token
  send_message->>TelegramSlackDiscord: send platform-specific POST
  TelegramSlackDiscord-->>send_message: status and response body
  send_message-->>CLI_or_MCP: success or error

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	It adds outbound sends and tooling, but misses the db-backed channel registry/config, enabled defaults, and configure-before-send behavior required by #152.	Add an agentflare.db-backed channel registry/migration, persist enabled platforms and default targets, and block sends until a platform is configured.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarizes the new outbound channel send feature and its CLI/MCP surfaces.
Description check	✅ Passed	The description covers summary, test plan, and reviewer notes, though it uses custom headings instead of the template.
Out of Scope Changes check	✅ Passed	The changes stay focused on outbound messaging, CLI/MCP wiring, and support code; no unrelated features are evident.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/outbound-channels

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

src/channels.rs (1)

128-142: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

No validation of empty target/text before hitting the network.

send_message forwards whatever target/text it's given straight into build_request/send. Neither call site validates non-empty values first: src/cli/channel.rs's ChannelArgs::run and src/mcp_server.rs's channel_send both pass user input through untouched (unlike most other MCP tools in this file, e.g. artifact_publish, skill_search, which reject empty required fields with invalid_params before doing any I/O). Adding the check once here covers both callers instead of duplicating it.

✅ Proposed fix

 pub fn send_message(
     conn: &rusqlite::Connection,
     platform: Platform,
     target: &str,
     text: &str,
 ) -> Result<(), String> {
+    if target.trim().is_empty() || text.is_empty() {
+        return Err("target and message must not be empty".to_string());
+    }
     let name = platform.secret_name();

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/channels.rs` around lines 128 - 142, Update send_message to reject empty
target or text before retrieving secrets, building the request, or calling send.
Return a clear Err describing the missing required value, while preserving the
existing secret lookup and network flow for non-empty inputs; this central
validation covers ChannelArgs::run and channel_send.

src/mcp_server.rs (1)

741-757: 🎯 Functional Correctness | 🔵 Trivial

channel_send is sync while sibling network-calling tools are async.

gateway_search/gateway_execute (both do outbound network I/O) are declared async fn, but channel_send calls a blocking ureq request synchronously. If the MCP tool dispatcher runs tool methods on a shared async runtime without spawn_blocking, this blocking call (compounded by the missing timeout noted in src/channels.rs::send) could stall other in-flight tool calls. Worth confirming how the #[tool] macro dispatches sync vs async methods before relying on this pattern for a network call.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/mcp_server.rs` around lines 741 - 757, Update channel_send to avoid
performing the blocking channels::send_message network request directly on the
async MCP runtime: either make the tool async and run the blocking operation
through the runtime’s established spawn_blocking pattern, or use the
dispatcher’s supported mechanism for offloading synchronous tools. Preserve the
existing platform validation, database error mapping, and response format.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/channels.rs`:
- Around line 118-122: Update the error handling in the request send flow to
avoid formatting sensitive req.url in the transport error message. In the Err(e)
branch of the match around r.send_json, use the non-sensitive platform
identifier for context while preserving the existing error propagation behavior.
- Around line 111-124: Update send to use a configured ureq Agent with an
explicit request timeout instead of the default ureq::post client. Preserve the
existing authorization, response-status/body extraction, and interpret_response
behavior while ensuring stalled Slack, Telegram, or Discord requests cannot
block indefinitely.

---

Nitpick comments:
In `@src/channels.rs`:
- Around line 128-142: Update send_message to reject empty target or text before
retrieving secrets, building the request, or calling send. Return a clear Err
describing the missing required value, while preserving the existing secret
lookup and network flow for non-empty inputs; this central validation covers
ChannelArgs::run and channel_send.

In `@src/mcp_server.rs`:
- Around line 741-757: Update channel_send to avoid performing the blocking
channels::send_message network request directly on the async MCP runtime: either
make the tool async and run the blocking operation through the runtime’s
established spawn_blocking pattern, or use the dispatcher’s supported mechanism
for offloading synchronous tools. Preserve the existing platform validation,
database error mapping, and response format.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: d37418d0-e97d-4cc5-8b8f-82c7c65984f1

📥 Commits

Reviewing files that changed from the base of the PR and between d2a0f44 and a08f190.

📒 Files selected for processing (5)

• src/channels.rs
• src/cli/channel.rs
• src/cli/mod.rs
• src/main.rs
• src/mcp_server.rs