Summary

• unify Telegram durable outbound delivery around one channel outbound adapter
• centralize Telegram DM/command authorization helpers
• use grammY native constants and InputFile helpers directly
• preserve Telegram's 10-option poll cap in the unified outbound contract

Real behavior proof

Behavior or issue addressed: Telegram polls must preserve the channel-specific 10-option cap after the outbound adapter refactor, so over-limit polls fail before send instead of reaching Telegram and failing late.

Real environment tested: Local OpenClaw checkout at PR head fc2365d04a7006d38454c49df70792cf1d805b5c, real pnpm openclaw message poll CLI path, Telegram channel dry-run. Also rebuilt and restarted the WSL2 gateway from this PR stack for manual Telegram testing on ubuntu@100.79.136.128. No separate live Telegram poll send was automated from the local CLI.

Exact steps or command run after this patch: Ran /opt/homebrew/bin/bunx pnpm openclaw message poll --channel telegram --target 12345 --poll-question 'Cap proof?' --poll-option one --poll-option two --poll-option three --poll-option four --poll-option five --poll-option six --poll-option seven --poll-option eight --poll-option nine --poll-option ten --dry-run --json, then ran the same command with --poll-option eleven added. On the WSL2 box, built /home/ubuntu/openclaw-pr-78762 and restarted openclaw-gateway.service from /home/ubuntu/openclaw-pr-78762/dist/index.js gateway --port 18789.

Evidence after fix:

10-option command output included:
{
  "action": "poll",
  "channel": "telegram",
  "dryRun": true,
  "handledBy": "core",
  "payload": {
    "channel": "telegram",
    "to": "telegram:12345",
    "question": "Cap proof?",
    "options": ["one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "ten"],
    "via": "gateway",
    "dryRun": true
  }
}

11-option command output:
Error: Poll supports at most 10 options
ELIFECYCLE Command failed with exit code 1.

WSL2 gateway status:
Runtime: running (pid 12531, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Command: /usr/bin/node /home/ubuntu/openclaw-pr-78762/dist/index.js gateway --port 18789

Observed result after fix: The real CLI dry-run accepted exactly 10 Telegram poll options and rejected 11 options before send with Poll supports at most 10 options; the WSL2 Telegram gateway restarted from the PR build and reported a healthy connectivity probe.

What was not tested: Automated live Telegram API poll send from local CLI; WSL2 gateway was left running for maintainer manual Telegram testing.

Verification

• /opt/homebrew/bin/bunx pnpm test extensions/telegram/src/telegram-outbound.test.ts extensions/telegram/src/outbound-adapter.test.ts extensions/telegram/src/bot-message-context.reactions.test.ts extensions/telegram/src/bot-message-context.dm-threads.test.ts extensions/telegram/src/bot-message-context.thread-binding.test.ts extensions/telegram/src/bot-message-context.require-mention.test.ts extensions/telegram/src/bot-native-commands.test.ts extensions/telegram/src/bot-native-commands.group-auth.test.ts extensions/telegram/src/bot-native-commands.skills-allowlist.test.ts extensions/telegram/src/bot-handlers.runtime.test.ts extensions/telegram/src/group-access.base-access.test.ts extensions/telegram/src/dm-access.test.ts -- --reporter=verbose
• /opt/homebrew/bin/bunx pnpm check:changed
• /opt/homebrew/bin/bunx pnpm openclaw message poll --channel telegram --target 12345 --poll-question 'Cap proof?' --poll-option one --poll-option two --poll-option three --poll-option four --poll-option five --poll-option six --poll-option seven --poll-option eight --poll-option nine --poll-option ten --dry-run --json
• /opt/homebrew/bin/bunx pnpm openclaw message poll --channel telegram --target 12345 --poll-question 'Cap proof?' --poll-option one --poll-option two --poll-option three --poll-option four --poll-option five --poll-option six --poll-option seven --poll-option eight --poll-option nine --poll-option ten --poll-option eleven --dry-run --json (expected failure)