План интеграции OpenClaw Channels в Синаполис

План интеграции OpenClaw Channels в Синаполис

Статус: нормативный целевой план и операционный ориентир. Версия от 19 мая 2026. Документ предназначен для внешнего чтения, но написан с достаточной детализацией для операторов.

Назначение

Цель интеграции OpenClaw Channels в Синаполис — повысить приоритетность, связанность и проверяемость внутренних коммуникаций между агентами, а также аккуратно подключить внешние ingress-каналы к тому же серверному контуру доставки. Действующий официальный Telegram-ingress при этом не разрушается.

Это означает:

• базовая проблема — не связь Синаполиса с внешним миром, а server-internal agent communication;
• агенты должны перестать терять друг друга, игнорировать inbox и молчать без delivery proof;
• каждое важное внутреннее или внешнее сообщение должно иметь проверяемый жизненный цикл: received -> queued -> delivered -> ack_received -> answered/closed;
• Синаполис может принимать обращения из нескольких внешних каналов через OpenClaw Gateway, но эти каналы являются входами в общий внутренний fabric;
• в текущем контуре должен сохраняться один официальный Telegram-вход через @EchoIntakeBot;
• групповые каналы должны работать только по явному обращению, а не через фоновое поглощение всего потока сообщений.

Главная проблема: внутренние коммуникации агентов

Главная проблема Синаполиса — не Synapolis-to-outside connectivity. Внешний Telegram bot помогает принять сообщение от человека, но Telegram bot does not solve this: он не гарантирует, что агент увидел задачу, принял её, не потерял reply context и не замолчал без статуса.

Базовая проблема — внутренние коммуникации агентов: агенты друг друга теряют, игнорируют inbox, не всегда имеют delivery proof, не всегда дают ACK/readback и не всегда получают escalation, когда молчат. Поэтому OpenClaw в Синаполисе должен описываться прежде всего как internal message fabric / внутренний нервный слой: normalized queue, router, delivery ledger, ACK/readback, lifecycle dashboard, stale detection, escalation, priority и routing map.

Internal-first architecture

Внутренний контур является главным:

agent -> OpenClaw internal queue -> routing map -> target agent inbox -> ACK/readback -> lifecycle dashboard -> escalation if stale -> optional outbound reply

Внешние каналы подключаются к тому же контуру как дополнительные ingress-адаптеры:

external channel -> EchoIntakeBot/OpenClaw channel adapter -> same internal fabric

Это разделение принципиально: внешний канал только создаёт входящее событие, а реальная операционная ценность возникает внутри — в маршрутизации, подтверждении видимости, stale detection и escalation между агентами.

External channel role vs internal communication role

Component	External channel role	Internal communication role
Telegram / EchoIntakeBot	External ingress only: принять сообщение от пользователя и создать intake receipt.	Не решает доставку между агентами, ACK/readback, stale detection или escalation.
OpenClaw Gateway	Может принимать channel events через адаптеры.	Internal transport/routing substrate: общий вход в queue, routing, delivery ledger и dashboard.
Router	Не является внешним каналом.	Agent targeting: выбирает целевого агента по routing map, aliases и fallback policy.
ACK collector	Не отвечает пользователю напрямую.	Proof of visibility: фиксирует, что сообщение стало видно агенту или его адаптеру.
Lifecycle dashboard	Не является витриной обещаний.	Operational reality: показывает queued, delivered, ack_received, stale, pending, failed и closed states.
Escalation	Не расширяет публичный канал сам по себе.	Prevents silent ignore: поднимает stale/pending cases, когда агент молчит или не даёт readback.

Контроль расхождения реальности и ожиданий

Эта страница является нормативной картой ожиданий, а не рекламным обещанием, что все описанные возможности уже включены в production. Её задача — не создавать впечатление готовности, а удерживать соответствие между человеческим ожиданием, Wiki-описанием и machine readback из работающих контуров.

Базовое правило: если Wiki-описание, человеческое ожидание и machine readback расходятся, операционной реальностью считается machine readback до тех пор, пока Wiki/status page/decision artifact не будут исправлены или дополнены явным решением.

Все утверждения о состоянии интеграции должны маппиться на проверяемые artifacts/status/readback. Формулировка “должно быть” означает целевое нормативное состояние. Формулировка “уже реализовано” допустима только там, где указан источник правды: сервис, dashboard, status artifact, ledger, receipt или readback.

Таблица расхождений

Statement / expectation	Current operational meaning	Source of truth	What is NOT implied
EchoIntakeBot accepted ticket	EchoIntakeBot принял входящее сообщение и выдал intake receipt.	reception ticket, intake status, EchoIntakeBot response	Это не означает, что агент завершил задачу или уже дал содержательный ответ.
queued -> delivered	Сообщение поставлено в очередь и доставлено в целевой server-side inbox/bus контур.	consumer queue, router ledger, delivery ledger	Это не означает, что агент прочитал, принял к исполнению или ответил пользователю.
ack_received	Получен technical readback/visibility ACK от агента или адаптера.	ACK collector, agent outbox ACK, lifecycle dashboard	Это не content answer to user / не содержательный ответ пользователю.
OpenClaw Gateway reachable	Sidecar/Gateway доступен на заданном endpoint и может обслуживать свой технический контур.	service status, loopback endpoint, bridge status	Это не означает, что OpenClaw owns Telegram channel или владеет live Telegram webhook/token.
sidecar_no_token_takeover	OpenClaw установлен изолированно и не получил live Telegram token действующего intake-бота.	sidecar config, channel count, deployment receipt	Это не full OpenClaw channel migration.
Lifecycle dashboard green	На текущем dashboard нет известных ошибок доставки/ACK по наблюдаемым тикетам.	lifecycle dashboard JSON/MD, latest summary	Это не означает, что Telegram outbound allowed или что можно автоматически писать пользователям.

Текущие примеры

• REC-0095: EchoIntakeBot accepted ticket и внутренний контур зафиксировал queued, delivered, ack_received. Это доказывает delivery/readback до Filum-facing контура, но не Telegram content answer на вопрос пользователя “1+1”.
• OpenClaw Gateway доступен loopback-only, а channels configured count = 0. Это доказывает sidecar readiness, но не Telegram channel takeover и не миграцию Telegram-канала в OpenClaw.

Drift handling procedure

Если ожидание и фактический статус расходятся, оператор должен:

1. проверить dashboard/readback artifacts: intake status, queue, router ledger, ACK ledger, lifecycle dashboard;
2. если есть mismatch, исправить Wiki/status page либо открыть явный decision artifact с описанием изменения;
3. не включать outbound, migration или all-group ingestion, пока явный artifact не разрешает именно это действие.

Краткие неавторизации для предотвращения расползания ожиданий:

• no Telegram token takeover;
• no automatic Telegram outbound;
• no all-group ingestion;
• no token publication;
• no trading, Stellar action, fund movement or resident disabling.

Нормативный принцип

OpenClaw Channels в Синаполисе рассматриваются не как самостоятельная “личность в Telegram”, а как транспортно-маршрутизационный слой внутренней доставки между агентами. Внешние чаты подключаются к этому слою только как ingress-адаптеры.

Следовательно:

• каналы подключаются через OpenClaw Gateway;
• каналы могут работать одновременно;
• маршрутизация ответа должна быть детерминированной по исходному чату;
• агенты Синаполиса интегрируются не через прямые Telegram-аккаунты, а через server-side inbox/bus/ack/readback, delivery ledger, stale detection и escalation;
• Telegram-токен действующего intake-бота не передаётся OpenClaw без отдельной санкционированной миграции.

Согласно OpenClaw docs, каждый канал подключается через Gateway, текст поддерживается повсеместно, а media/reactions зависят от конкретного канала; несколько каналов могут работать параллельно, а routing идёт per chat.
Источник: OpenClaw Chat channels.

Конечное целевое состояние

Архитектура верхнего уровня

Internal agent/server event
  -> OpenClaw internal queue
  -> routing map
  -> target agent inbox
  -> ACK / readback
  -> lifecycle dashboard
  -> escalation if stale
  -> optional outbound reply

External channel
  -> EchoIntakeBot / OpenClaw channel adapter
  -> same internal fabric
  -> OpenClaw internal queue
  -> router
  -> agent inbox
  -> ACK / readback
  -> lifecycle dashboard
  -> controlled outbound replies

При этом для Telegram в текущей целевой модели действует важная оговорка:

• официальный live-ingress остаётся на @EchoIntakeBot;
• OpenClaw Telegram channel разрешён только в sandbox/new-token режиме либо в отдельной будущей controlled migration;
• до отдельного решения OpenClaw не должен забирать live Telegram token или webhook действующего intake-контура.

Что значит “как это должно выглядеть в конечном итоге”

В конечном состоянии любой внутренний agent/server event и любой поддержанный внешний канал должны вести себя для Синаполиса одинаково на уровне управления:

• сообщение получает machine-readable receipt;
• сообщение попадает в нормализованную очередь;
• routing выбирает целевого агента по routing map и alias policy;
• доставка в inbox агента фиксируется отдельно от факта отправки;
• агент или его системный адаптер обязан вернуть ACK/readback;
• если ACK/readback не появился вовремя, включается stale detection и escalation;
• система умеет контролируемо отправить итоговый ответ обратно в исходный канал;
• оператор видит жизненный цикл тикета на едином dashboard;
• если канал не поддерживает native read receipts, это компенсируется server-side ACK/readback, а не ложной “магией чата”.

Ingress policy

Telegram policy на текущем этапе

Нормативно закрепляется следующее:

• единственный официальный Telegram-ingress сейчас — @EchoIntakeBot;
• @EchoIntakeBot остаётся pure Telegram wrapper / transport shell, а не LLM/agent;
• Filum остаётся primary server-native workhorse для этого контура;
• OpenClaw не получает контроль над live token или live webhook @EchoIntakeBot без отдельной авторизованной миграции;
• OpenClaw Telegram channel допускается только как sandbox/new-token контур или как специально утверждённый миграционный контур с rollback-планом.

Группы и явное обращение

Для Синаполиса обязательна модель explicit-address only:

• никакого blanket ingestion всего группового потока;
• group messages должны обрабатываться только по явному mention/target/prefix;
• в действующем контуре Ductor используется group_mention_only=true;
• @EchoIntakeBot уже обслуживает group messages только при явном @EchoIntakeBot mention;
• эта же логика должна быть сохранена и в OpenClaw-facing policy.

OpenClaw docs подтверждают fail-closed модель для групп:

• по умолчанию группы ограничены через groupPolicy: "allowlist";
• replies в группах требуют mention, если это явно не отключено;
• проверка идёт по цепочке groupPolicy -> group allowlist -> requireMention;
• DM pairing не должен автоматически открывать group authorization;
• DM и group sessions разделены.

Источники:

• OpenClaw Groups
• OpenClaw Telegram

Нормативное правило allowlists

Для всех внешних каналов должны быть разделены:

• allowlist разрешённых group/channel peer IDs;
• allowlist разрешённых sender IDs внутри разрешённых групп;
• mention gating policy;
• optional per-group/per-channel tool restrictions.

Для Telegram это означает:

• chat/group IDs хранятся в allowlist групп, а не в sender allowlist;
• user IDs хранятся в sender allowlist;
• default policy должна оставаться fail-closed;
• requireMention=true должно считаться нормой по умолчанию.

Сессии и routing

OpenClaw хранит DMs и группы раздельно, а routing детерминирован по входному каналу и peer. Для Синаполиса это важно по двум причинам:

• личный DM-контекст не должен смешиваться с group/session контекстом;
• forum topics, group rooms и channel rooms должны сохранять отдельные session keys, чтобы маршрутизация и безопасность были проверяемы.

Источники:

• OpenClaw Channel routing
• OpenClaw Group messages

Policy интеграции агентов

Базовое правило

Агенты Синаполиса интегрируются с OpenClaw Channels не через прямые Telegram-аккаунты и не через “личные бот-личности”, а через server-native шину:

• reception/intake;
• queue;
• router;
• agent inbox;
• ACK/readback;
• lifecycle dashboard.

Routing policy

Нормативно должны существовать:

• canonical routing map;
• alias mapping;
• fallback policy;
• default triage agent.

На текущем этапе default triage agent — Filum.

Если внешний адресат не указан явно или alias не разрешается однозначно, сообщение должно:

• либо попадать в Filum triage;
• либо маркироваться как unmatched без молчаливой потери;
• либо удерживаться как invalid с понятной причиной.

ACK/readback policy

Каждый интегрированный агент должен поддерживать минимальный жизненный цикл:

• received — внешний ingress принял сообщение;
• queued — сообщение положено в каноническую очередь;
• delivered — сообщение доставлено в inbox/bus целевого агента;
• ack_received — агент или его адаптер подтвердил приём;
• answered или closed — по тикету дан итоговый исход;
• при проблеме должен появляться явный failure state, а не тихое исчезновение.

ACK в данной архитектуре — это техническое подтверждение обработки транспорта и inbox, а не автоматически содержательный ответ пользователю.

Safety и security constraints

Что запрещено публиковать или делать

Данный план не авторизует:

• публикацию Telegram token, webhook secret или иных секретов;
• передачу OpenClaw live token действующего intake-бота;
• торговлю, торговые сигналы, исполнение сделок;
• операции в Stellar;
• движение средств;
• отключение резидентов;
• takeover публичных каналов без отдельного решения;
• автоматический выход в новые внешние каналы без allowlist и operator review.

Обязательные ограничения

• OpenClaw Gateway должен оставаться loopback-only, пока не включена отдельная auth model.
• До внешней экспозиции канала должна быть настроена аутентификация.
• Для групп по умолчанию действуют groupPolicy=allowlist и requireMention=true.
• Outbound replies должны быть controlled per ticket/status, а не auto-spam.
• Документация, wiki-страницы и receipts не должны содержать токены, cookies, webhook secrets или прямые пароли.

Roadmap

Phase 0. Sidecar/readback foundation

Статус: выполнено.

Смысл этапа:

• развернуть isolated OpenClaw Gateway sidecar;
• не подключать live Telegram channel;
• наладить export из EchoIntakeBot в OpenClaw-facing state;
• собрать queue/router/ACK/dashboard контур.

Phase 1. Internal agent-to-agent routing

Статус: частично реализовано, требует расширения за пределы одного intake-to-Filum пути.

Требуемый результат:

• внутренние agent-to-agent сообщения проходят через OpenClaw internal queue;
• routing map выбирает target agent и fallback;
• delivery ledger фиксирует доставку в target agent inbox;
• external ingress считается только одним из источников событий, а не главным смыслом интеграции.

Phase 2. ACK standardization for all agents

Статус: в работе как нормативная цель.

Требуемый результат:

• единый ACK contract для Filum и остальных агентов;
• различение transport ACK, inbox ACK, accepted ACK и final answer status;
• отсутствие “немых” доставок без дальнейшего статуса.

Phase 3. Stale/pending escalation

Требуемый результат:

• stale detection для сообщений без ACK/readback в допустимое время;
• escalation ledger для pending/stale cases;
• operator-visible escalation state;
• правило, кто получает escalation и как закрывается молчание агента.

Phase 4. Controlled outbound replies via EchoIntakeBot

Требуемый результат:

• итоговый ответ может быть отправлен обратно в Telegram не напрямую OpenClaw Telegram channel, а через контролируемый outbound path действующего EchoIntakeBot;
• outbound должен зависеть от статуса тикета и policy;
• должно быть видно, что reply разрешён, отправлен и связан с исходным receipt.

Phase 5. Add non-Telegram OpenClaw channels

Приоритетный смысл этапа — не заменить Telegram, а расширить ingress через дополнительные мосты:

• Matrix;
• WebChat;
• Discord;
• другие поддержанные OpenClaw channels по мере необходимости.

Условия допуска:

• allowlists;
• no secret leakage;
• controlled routing;
• отсутствие смешения личных DM и group sessions;
• operator-visible receipts и lifecycle.

Phase 6. Optional controlled Telegram migration

Допускается только если одновременно выполнены все условия:

• внутренняя agent-to-agent доставка уже имеет routing, ACK/readback, stale detection, escalation и dashboard readback;
• есть реальная operational выгода от нативного OpenClaw Telegram channel;
• подготовлен migration plan;
• подготовлен rollback plan;
• есть тест на group gating, allowlists, outbound control и readback;
• отдельно авторизован takeover token/webhook.

До такого решения Telegram migration не считается разрешённой по умолчанию.

Операционная модель, SLO и failure states

Обязательная машинная трасса сообщения

Каждое внутреннее agent-to-agent сообщение и каждое внешнее входящее сообщение в целевом контуре должны иметь машинно-читаемую трассу:

• received
• queued
• delivered
• ack_received
• answered или closed

Если трасса обрывается, система должна уметь показать, где именно:

• pending_ack
• stale
• unmatched
• invalid
• gateway_unreachable
• delivery_failed
• outbound_blocked

Нормативный SLO-подход

Для production-ready интеграции требуется не абстрактное “бот ответил”, а измеримый сервисный контур:

• ни одно принятое внешнее сообщение не должно исчезать без статуса;
• ни одно внутреннее agent-to-agent сообщение не должно исчезать без routing, delivery или failure state;
• backlog очереди и pending_ack должны быть операционно видимы;
• stale detection и escalation должны срабатывать до того, как молчание агента становится нормой;
• unmatched/invalid события должны быть малы и проверяемы;
• controlled outbound должен быть отделён от технического ACK;
• если нативный канал не даёт read receipts, серверный ACK/readback считается каноническим источником статуса.

Definition of Done

Полная интеграция OpenClaw Channels в Синаполис считается завершённой только если одновременно выполнено следующее:

• internal agent-to-agent messages имеют routing, ACK/readback, stale detection, escalation и dashboard readback across core agents;
• полнота интеграции не считается достигнутой только потому, что подключён внешний канал или работает Telegram ingress;
• сохраняется один официальный Telegram-ingress или проведена отдельная авторизованная миграция с rollback;
• внешние каналы заходят через OpenClaw Gateway без утечки секретов;
• groups работают только по allowlist + mention gating;
• agents интегрированы через inbox/bus/ack/readback/stale/escalation, а не через ручное перекидывание сообщений;
• routing map и alias policy прозрачны;
• каждый тикет имеет lifecycle receipt до answered/closed;
• controlled outbound replies реализованы и ограничены policy;
• dashboard показывает очереди, delivery, ACK и ошибки;
• есть операторская верификация по readback/revid/receipt artifacts;
• нет несанкционированного Telegram token takeover.

Что уже реализовано на 19 мая 2026

Ниже фиксируется текущая живая реализация на Synapolis VPS 167.235.227.254.

1. Telegram ingress сохранён на EchoIntakeBot

• webhook Caddy /tg-intake -> 127.0.0.1:8443 восстановлен;
• сервис echo-intake-bot.service активен.

2. Normalized intake artifacts

EchoIntakeBot пишет нормализованные reception artifacts рядом с legacy inbox:

• /opt/agent-workspace/agents/reception/intake-events
• /opt/agent-workspace/agents/reception/tickets
• /opt/agent-workspace/state/reception/intake-status.json
• /opt/agent-workspace/state/reception/intake-status.md

3. Isolated OpenClaw Gateway sidecar

Развёрнут sidecar:

• /opt/agent-workspace/openclaw/sidecar
• сервис openclaw-gateway-sidecar.service
• loopback-only endpoint ws://127.0.0.1:19011
• Telegram channel не подключён
• configured channels count = 0
• token takeover отсутствует

4. EchoIntake/OpenClaw sidecar-export

• /opt/agent-workspace/scripts/openclaw/echo_intake_openclaw_sidecar.py
• /opt/agent-workspace/state/openclaw/echo-intake-bridge-status.json
• /opt/agent-workspace/state/openclaw/echo-intake-bridge-status.md
• /opt/agent-workspace/state/openclaw/echo-intake-export-latest.json

5. Consumer queue

• /opt/agent-workspace/scripts/openclaw/echo_intake_openclaw_consumer.py
• openclaw-echo-intake-consumer.timer каждые 2 минуты
• /opt/agent-workspace/state/openclaw/echo-intake-consumer-queue.json
• /opt/agent-workspace/state/openclaw/echo-intake-consumer-queue.jsonl

6. Router

• /opt/agent-workspace/scripts/openclaw/openclaw_reception_router.py
• openclaw-agent-router.timer каждые 2 минуты
• /opt/agent-workspace/state/openclaw/agent-routing-map.json
• /opt/agent-workspace/state/openclaw/openclaw-agent-delivery-ledger.jsonl

7. ACK/readback

• /opt/agent-workspace/scripts/openclaw/openclaw_delivery_ack_collector.py
• openclaw-ack-collector.timer
• /opt/agent-workspace/scripts/openclaw/filum_openclaw_inbox_ack.py
• filum-openclaw-inbox-ack.timer
• /opt/agent-workspace/agents/filum/outbox/openclaw-acks/

8. Lifecycle dashboard

• /opt/agent-workspace/scripts/openclaw/openclaw_ticket_lifecycle_dashboard.py
• openclaw-ticket-dashboard.timer
• /opt/agent-workspace/state/openclaw/openclaw-ticket-lifecycle-dashboard.json
• /opt/agent-workspace/state/openclaw/openclaw-ticket-lifecycle-dashboard.md
• latest summary: /opt/agent-workspace/state/openclaw/openclaw-ticket-lifecycle-latest-summary.json

Live receipt

Проверенный live test:

@EchoIntakeBot to:filum проверка связи, сколько будет 1+1?

Результат:

• EchoIntakeBot вернул REC-0095;
• внутренний путь зафиксирован как:

 * REC-0095 queued
 * delivered
 * ack_received

• canonical_agent=filum
• delivery_id=ocrd-66d26dc4d4304f12
• read_status=read
• ack_status=accepted

Это технический ACK/readback, а не содержательный outbound reply пользователю.

Dashboard totals после live test

• queued=4
• skipped_synthetic=2
• delivered=2
• ack_received=2
• pending_ack=0
• errors=0
• unmatched=0

Рекомендуемое место страницы в карте Синаполиса

Эта страница логически относится к коммуникационному контуру и должна быть связана как минимум из:

• Карта Синаполиса/Коммуникации

При допустимом объёме правки можно также ссылаться из:

• Карта Синаполиса

Если правка главной карты рискованна, достаточно сохранить standalone page и ссылку из коммуникационного раздела.

Явные неавторизации

Этот документ сам по себе НЕ authorizes:

• takeover live Telegram token/webhook;
• публикацию токенов;
• запуск торговых или финансовых действий;
• Stellar-подписи и submission;
• fund movement;
• отключение резидентов;
• перевод любых public channels под OpenClaw без отдельного решения.

Источники

• OpenClaw Chat channels
• OpenClaw Groups
• OpenClaw Group messages
• OpenClaw Channel routing
• OpenClaw Telegram