> ## Documentation Index
> Fetch the complete documentation index at: https://docs.skrmir.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dialog Ecosystem v0

> Reuse strategy for dialog multi-channel ecosystem, OpenClaw compatibility, and canonical AIOS ownership boundaries.

# Dialog Ecosystem v0

## Scope

Defines how AIOS v0 extends `dialog` into a multi-channel ecosystem while preserving canonical AIOS ownership over session, routing, lease, and policy models.

This page formalizes what AIOS reuses from OpenClaw, `cc-connect`, and bridge-style channel projects, and what MUST remain under AIOS control.

## Terminology

* **Dialog**: the canonical multi-channel ingress layer in AIOS.
* **Target**: the concrete dialog-backed destination such as `codex`, `claude_code`, `opencode`, `wechat`, or `telegram`.
* **Protocol compatibility**: adapter compatibility without handing over core platform authority.
* **Implementation reuse**: selectively reusing channel adapter implementations behind AIOS contracts.

## Normative Spec

### Ecosystem Strategy

AIOS v0 MUST treat dialog ecosystem reuse with this priority order:

1. protocol and transport semantics may reference `cc-connect`
2. channel ecosystem boundaries may reference OpenClaw
3. bridge-style operational experience may reference WeChat and Telegram channel projects
4. canonical session, route, lease, desired-version, and policy models MUST remain AIOS-owned

### Core Reuse Rule

AIOS MUST follow this principle:

> reuse channel ecosystem, not platform sovereignty.

### What AIOS Reuses

#### From OpenClaw

* channel adapter boundary model
* centralized Gateway routing mindset
* multi-channel access shape
* unified health, retry, and event handling patterns

#### From `cc-connect`

* `session_id / msg_id / seq`
* dedup semantics
* reconnect semantics
* resume cursor semantics
* at-least-once with receiver idempotency

#### From bridge-style WeChat/Telegram projects

* owner or allowlist gating
* polling versus webhook transport tradeoffs
* context cache and cursor window experience
* product mindset that remote channels are entrypoints, not the primary development authority

### What AIOS MUST Keep Canonical

The following MUST NOT be delegated to OpenClaw or any channel adapter:

* canonical session model
* stable route key `workspace_id + agent_id`
* lease, desired\_version, and fencing model
* platform-level approval and policy boundary
* forward-only and metadata-only persistence boundary
* DevBox, Probe, and Worker Sandbox lifecycle authority

### Target Set

The initial dialog target set in v0 SHOULD include:

* `codex`
* `claude_code`
* `opencode`
* `wechat`
* `telegram`

All targets MUST normalize through the canonical dialog model rather than invent target-specific session rules.

### Reuse Levels

* **Level 1**: protocol compatibility first. This is the v0 default.
* **Level 2**: implementation reuse by adapter evaluation. This is a later-stage option.
* Product-level control-plane wholesale reuse MUST NOT be the v0 approach.

## Examples

### Ownership split

| Concern                         | Reuse allowed | AIOS canonical owner               |
| ------------------------------- | ------------- | ---------------------------------- |
| envelope semantics              | yes           | shared contract enforcement        |
| channel adapter boundary        | yes           | AIOS Gateway and Probe integration |
| stable routing key              | no            | AIOS only                          |
| lease and fencing               | no            | AIOS only                          |
| transcript persistence boundary | no            | AIOS only                          |

### Target normalization example

```json theme={null}
{
  "channel_type": "dialog",
  "target": "telegram",
  "workspace_id": "ws-001",
  "agent_id": "codex",
  "event_type": "message"
}
```

## Error & Recovery

* A channel ecosystem integration MUST NOT bypass canonical dialog contracts during reconnect or replay.
* Adapter-specific transport recovery MAY exist, but canonical route and lease ownership MUST remain with AIOS.
* Any attempt to persist transcript bodies as part of ecosystem reuse is a policy violation.

## Security & Audit

* Multi-channel reuse MUST preserve forward-only and metadata-only audit boundaries.
* OpenClaw-compatible adapters MUST still emit AIOS-compatible metadata and health signals.
* Channel reuse MUST NOT create a parallel control plane.

## Status

Current status: `draft`

Source discussions:

* `docs/maintainers/conversation-records/agent-platform/2026-03-24-dialog-channel-ecosystem-reuse-strategy-v0.md`
* `docs/maintainers/conversation-records/agent-platform/2026-03-24-openclaw-to-aios-architecture-crosswalk.md`
* `docs/maintainers/conversation-records/agent-platform/2026-03-24-p1-freeze-result-accepted.md`

## Changelog

* 2026-03-24: Initial formal dialog ecosystem specification created from frozen discussion drafts.

## 相关页面

* [Channel Adapter Contract v0](/agent-platform/contracts/channel-adapter-v0/index)
* [WeChat Integration v0](/agent-platform/integrations/wechat/index)
* [Telegram Integration v0](/agent-platform/integrations/telegram/index)