Plugin: extract a generic channel adapter layer #15
Description
Problem
We should stop rebuilding the same Telegram-vs-Discord branching logic in the Codex controller and instead introduce a generic channel interface inside the plugin.
This should make future features cheaper to add and reduce the surface area for platform-specific regressions.
Current Findings
- The plugin controller currently contains a large amount of explicit channel branching (
telegramvsdiscord) for command handling, picker delivery, rename behavior, pinning, typing, and interactive callbacks. - OpenClaw core already has a shared
channel-runtimesurface and even channel-agnostic boundary checks in tests, which is a strong signal that the broader project wants these boundaries to stay clean. - The plugin SDK already exposes similar-but-separate channel capabilities (
telegram.sendMessageTelegram,discord.sendMessageDiscord, provider-specific conversation actions, etc.).
Proposed Scope
- Introduce a plugin-local channel adapter interface with capabilities such as:
- send text
- send/edit interactive controls
- rename topic/thread/channel when supported
- pin/unpin/edit status message
- start/stop typing
- report channel capabilities
- Move high-level Codex logic onto that generic interface.
- Keep provider-specific code in small adapters instead of in the core controller flow.
- Use this refactor as the foundation for monitor channels, richer status cards, and any future provider support.
Source Notes
- Plugin controller explicit channel branching starts near:
src/controller.ts:148 - Plugin SDK provider-specific runtime surface:
src/openclaw-plugin-sdk.d.ts:157 - OpenClaw shared channel runtime exports:
/Users/huntharo/github/openclaw/src/plugin-sdk/channel-runtime.ts:1 - OpenClaw shared conversation runtime exports:
/Users/huntharo/github/openclaw/src/plugin-sdk/conversation-runtime.ts:1 - OpenClaw channel-agnostic boundary guard tests:
/Users/huntharo/github/openclaw/test/scripts/check-channel-agnostic-boundaries.test.ts:9