OpenClaw-style chat bot: drive ARTEX from Telegram (inbound bridge + remote approvals)

Idea

An always-on assistant bot in the spirit of OpenClaw: talk to your ARTEX from a chat app (Telegram first), get pushed what matters, and act remotely — instead of watching the web UI.

Why this is very feasible here

Most of the pieces already exist:

• Telegram outbound is done: the notification system already ships a Telegram channel (bot token + chat id, notify.KindTelegram) — findings and digest pushes work today
• The conversational brain exists: the Main agent is the human interface (task chat, hints, intent steering) and the Auto agent already creates/controls tasks and assets through natural language
• Approvals have an API: pending interception decisions are listable and decidable over HTTP
• The container has outbound network access, so long polling needs no inbound port

The missing piece is the inbound bridge: receive messages, route them to the right conversation, reply.

Proposed v1 scope

• A single Telegram bot (token stored like a notify channel) with a strict chat-id whitelist — unknown chats get one refusal line and are ignored
• Message routing:
  • plain text with a selected/last task → main-agent conversation of that task (same path as the web chat), reply relayed back, truncated with a link
  • /tasks, /task <id>, /pause <id>, /resume <id> → platform controls via the existing APIs
  • findings digest on demand (/findings)
• Remote approvals: when an interception decision is pending, push it with inline keyboard buttons (Allow / Block / preview snippet); the callback hits the existing decision API
• Presence: a small "bot online" indicator in the UI (System Settings), logs tagged [tgbot]

Security notes

• whitelist is mandatory, not optional; no evidence bodies or credentials in outbound messages by default — summaries and links only (chat apps are an external data surface, unlike the local UI)
• bot token lives in the DB like other channel secrets; rotating it must not require a restart
• approvals via callback carry a per-message nonce so a leaked button URL cannot be replayed

Out of scope for v1

Other bridges (Discord, WhatsApp adapters) — the bridge core should be transport-agnostic so they slot in later; voice; proactive chatty summaries beyond the existing digest system.

Open questions

• one bot per deployment or per task? (proposal: one bot, task chosen by command)
• should the main-agent conversation history be shared between web chat and the bot? (proposal: yes, same conversation, so context stays single)