|
| 1 | +# Remote Multi-Channel |
| 2 | + |
| 3 | +## Summary |
| 4 | + |
| 5 | +Extend the existing Remote settings and runtime from Telegram-only to a fixed two-channel model: Telegram and Feishu. Telegram keeps hook notifications, while Feishu adds remote control only. Both channels continue to bind one remote endpoint to one DeepChat session and reuse the existing detached-session flow in Electron main. |
| 6 | + |
| 7 | +This iteration also fixes the Telegram "deleted message" draft issue by preventing draft streaming from using reasoning-only, tool-call-only, or permission/question-request blocks as visible text. |
| 8 | + |
| 9 | +## User Stories |
| 10 | + |
| 11 | +- As a desktop user, I can configure Telegram and Feishu remote control from one Remote page without mixing their credentials and rules together. |
| 12 | +- As a Telegram user, I can continue using the existing private-chat pairing flow and hook notifications. |
| 13 | +- As a Feishu user, I can pair in a bot DM, then continue the same DeepChat session from DM, group chat, or topic thread. |
| 14 | +- As an admin of the desktop app, I can see per-channel runtime health and binding counts from a shared overview area. |
| 15 | +- As a paired Feishu user, I can trigger a remote session in group/topic only when I explicitly `@bot`. |
| 16 | +- As a Telegram user, I no longer see bot replies visually attached to a deleted draft/reference while the assistant is only reasoning or issuing tool calls. |
| 17 | + |
| 18 | +## Acceptance Criteria |
| 19 | + |
| 20 | +- The Remote page renders a shared overview plus separate Telegram and Feishu tabs. |
| 21 | +- Telegram settings continue to support bot token, remote pairing, allowlist, default agent, hook settings, and hook test actions. |
| 22 | +- Feishu settings support app credentials, pairing, paired user management, default agent selection, and binding management. |
| 23 | +- Feishu runtime runs in Electron main via WebSocket event subscription and does not require a renderer window. |
| 24 | +- Feishu endpoints are keyed by `chatId + optional threadId`, with topic/thread replies isolated from the group root conversation. |
| 25 | +- Feishu authorization requires DM pairing first; in groups/topics, only paired users who `@bot` may send commands or plain text to the bound session. |
| 26 | +- `/pair`, `/new`, `/sessions`, `/use`, `/stop`, `/status`, `/open`, and `/model` work for Feishu remote control. |
| 27 | +- Telegram `/model` continues to use inline keyboard menus; Feishu `/model` uses text commands only. |
| 28 | +- Telegram draft streaming only uses stable visible content blocks. Reasoning-only, tool-call-only, and pending action-only assistant states never call `sendMessageDraft`. |
| 29 | +- Existing local desktop chat behavior remains unchanged. |
| 30 | + |
| 31 | +## Constraints |
| 32 | + |
| 33 | +- Keep a fixed two-channel architecture. Do not introduce a generic plugin registry for remote channels. |
| 34 | +- Telegram hook notifications remain under the shared Remote page; Feishu hook notifications are out of scope. |
| 35 | +- Remote sessions continue to use the existing `RemoteConversationRunner` and detached session creation path. |
| 36 | +- Feishu v1 supports DM, group, and topic/thread input; media upload, cards, approvals, and user-OAuth automation remain out of scope. |
| 37 | + |
| 38 | +## Non-Goals |
| 39 | + |
| 40 | +- A general remote channel SDK or third-party channel plugin system. |
| 41 | +- Feishu user-OAuth flows, approval cards, or hook notifications. |
| 42 | +- Rich Feishu card-based model switching. |
| 43 | +- Telegram group chat support. |
| 44 | + |
| 45 | +## Compatibility |
| 46 | + |
| 47 | +- Existing `remoteControl.telegram` store data stays valid and is normalized into the new dual-channel config. |
| 48 | +- Existing Telegram hook settings remain valid and continue to be saved through the Remote page. |
| 49 | +- New Feishu-specific state is additive under `remoteControl.feishu`. |
0 commit comments