[Feature]: Add Li Auto Livis smart glasses as a built-in channel

[tcp404]

由社区分诊从 issue #3738 转入。原发起者 @eyaeya

Feature Description

Add Li Auto Livis smart glasses as a first-party AionUi Channel.

A user who already owns Livis glasses should be able to open Settings → Remote Connections → Channels → Livis, sign in to the Li Auto service, copy the generated AgentID, and paste it into the 理想同学 app to complete the binding. After that, a request spoken to the glasses should enter AionUi as a channel conversation and the final answer should be returned to the app/glasses.

The channel should support:

• a default AionUi Assistant selected in Settings;
• Assistants backed by any healthy local runtime already supported by AionUi, including Codex and Claude Code;
• an explicit, voice-friendly per-request override when the user wants a different Agent for one instruction.

The UI must state clearly that physical Livis glasses are required to use this channel.

Problem Statement

Li Auto currently documents this capability only for OpenClaw:

bash <(curl -fsSL https://li-center.lixiang.com/livis-pc-kit/openclaw/mac-linux/latest/setup.sh) --openclaw

That installer deploys an OpenClaw-specific plugin and skill, writes OpenClaw runtime state, and restarts the OpenClaw gateway. An AionUi user therefore cannot connect Livis directly, even when the desired local Agents are already installed and available in AionUi. Running OpenClaw only as a transport would duplicate runtime/configuration and would bypass AionUi's existing Channel, Assistant, conversation, and diagnostics flows.

This is a new integration rather than a duplicate of the existing remote-Agent feature: remote Agents let AionUi connect outward to another Agent runtime, while Livis is an external input/output device connecting inward to AionUi.

Current Research

I checked the current official release and the latest AionUi/AionCore channel architecture on 2026-07-25.

• The official latest installer currently resolves to Livis PC Kit v2.0.0. The release archive inspected for this proposal has SHA-256 96702f8f2d335380cd2ca0ea92ee709deaa9d9bf5947ea628194515d04824506.
• The official Livis guide states that the app and glasses share the same personal-Agent connection, and that an Agent reply is played through the glasses.
• The published client uses OAuth Device Flow followed by an outbound WebSocket relay connection. Its text path includes connect/heartbeat, inbound request acknowledgement, cancellation, final-result acknowledgement/retry, and reconnect recovery keyed by the original job ID.
• AgentID is created and persisted by the local client after login, then copied by the user into the mobile app.
• The relay protocol does not contain an Agent/model selector. Per-request selection of Codex, Claude, or another runtime must therefore be implemented by AionUi, not assumed to be a Livis server feature.
• The published archive contains compiled OpenClaw output but no reusable Livis SDK, source map, or license for the Livis-specific code. An AionUi implementation should be independent; it should not vendor or copy the official bundle.

These are static client findings, not claims that an unregistered AionUi client identity is already accepted by the production relay. The server-side identity contract still needs confirmation from Li Auto.

Proposed Solution

1. Use the existing Channel architecture

Implement Livis as a built-in Channel, not as an Electron-only side service and not as an OpenClaw wrapper.

On current main, Channel orchestration and platform plugins live in AionCore, while AionUi owns the typed /api/channel/* adapter and the Settings UI. The clean split appears to be:

• AionCore
  • add a livis Channel plugin and its protocol/auth state machine;
  • normalize an accepted Livis request into the existing unified incoming-message flow;
  • dispatch through the existing Assistant-backed conversation path;
  • correlate cancellation and final delivery with the original Livis job ID;
  • expose typed login, logout, connection-state, and AgentID operations.
• AionUi
  • add a built-in Livis card under Channels;
  • display login, waiting-for-authorization, ready-to-bind, connected, reconnecting, expired, and error states;
  • display AgentID as a read-only value with a copy action and exact mobile-app binding steps;
  • reuse the existing assistant_id binding for the default Assistant;
  • expose retry, switch-account, disconnect, and logout actions without putting credentials in renderer state;
  • add all new text to the existing settings i18n module for every configured locale.

The existing Channel status response does not carry AgentID or OAuth lifecycle state, so this should be a typed API addition rather than an undocumented renderer-side field.

If maintainers prefer to ship Livis first as a bundled extension, please confirm that direction before implementation. The requirement here is still a built-in user experience: no manual extension install, no OpenClaw dependency, and AgentID/auth state visible in AionUi Settings.

2. Authentication and binding

Proposed user flow:

1. Open the Livis Channel card and select Connect.
2. AionUi starts the Li Auto device-authorization flow and opens the verification URL.
3. After authorization succeeds, AionUi creates or loads a stable AgentID.
4. Settings shows the AgentID and instructs the user to open 理想同学 → 设置 → 连接与服务 → 连接我的 Agent, then paste the value.
5. AionUi connects to the relay and reports the observed connection state.
6. Logout revokes/clears the local credential, closes the relay connection, and makes the old local binding state explicit.

AgentID is a binding identifier, not an authentication token. Refresh credentials must remain in the backend's encrypted credential storage, never in localStorage, renderer logs, or diagnostic exports.

3. Agent routing and conversation semantics

• With no override, Livis uses the Assistant selected in its Channel settings.
• A request may begin with a deterministic, voice-friendly Agent selector, for example Codex: ... or Claude: .... The exact grammar should be agreed with maintainers and should reuse a common Channel command from Feature Request: Add /agent slash command to switch models in Telegram #2736 if that work is generalized.
• Only installed, enabled, locally allowlisted Assistants may be selected.
• If the requested Agent is missing or unhealthy, return a clear error through Livis; do not silently run the request on a different Agent.
• Session identity must include the selected Assistant. Switching Agents must create or resolve a valid persisted conversation before dispatch, avoiding the orphan-conversation failure described in [Bug]: I found the actual AionUI bug: Telegram’s “Switch to Codex” creates a session with a new random conversation ID, but it does not create the matching conversations row. That is why you get Conversation not found every time. #2841.
• Relay payload fields must not be allowed to choose an arbitrary workspace, Assistant ID, model, or permission mode.

4. Reliability and security

The first version should be text-only and should include:

• strict schema/type/size/timestamp validation for inbound envelopes;
• idempotency for every non-terminal state, not only completed jobs;
• bounded acknowledgement retries without overlapping timers;
• exponential reconnect with jitter and clean shutdown;
• cancellation before dispatch and during an active Agent run;
• recovery of a completed final result after a temporary disconnect;
• secret redaction in errors and logs;
• no Livis-specific trust elevation based only on a remote payload;
• no arbitrary local-file upload in the initial implementation.

The official package currently identifies itself as OpenClaw and generates an OpenClaw-prefixed AgentID. A production AionUi release should use a Li Auto-approved OAuth client, client name, AgentID namespace, and branding. It should not indefinitely impersonate OpenClaw just because that is what the current relay accepts.

Acceptance Criteria

• A clean AionUi installation can configure Livis without OpenClaw being installed.
• The Livis card states that physical Livis glasses are required.
• Login has explicit pending, success, cancellation, expiry, and failure states.
• AgentID appears only after successful authorization, is copyable, survives an ordinary AionUi restart, and is handled predictably on account switch/logout.
• The mobile-app binding instructions are visible beside AgentID.
• A bound Livis device can send a spoken request to the configured default Assistant and receive the final reply.
• On a machine where both runtimes are healthy, separate spoken requests can explicitly select Codex and Claude Code and receive replies from the requested runtime.
• An unknown or unavailable Agent produces an explicit error and does not fall back silently.
• Duplicate delivery of one job ID executes the request at most once.
• Relay cancellation stops the matching task and does not cancel another Assistant/session.
• A temporary relay disconnect does not lose or duplicate the final answer after reconnection.
• Restart recovery preserves the correct job/result correlation.
• Tokens are encrypted at rest and absent from renderer state, logs, and exported diagnostics.
• New UI text is present in all languages from i18n-config.json; i18n types and validation pass.
• Unit, integration, and mocked relay tests pass, followed by a physical-device E2E run.
• Production release is gated on confirmation of the Li Auto client/OAuth/AgentID contract.

Test Plan

AionCore

• protocol serialization/deserialization and invalid-envelope rejection;
• OAuth pending/slow-down/expiry/denial/refresh/revocation paths;
• stable AgentID lifecycle;
• connect, heartbeat, reconnect, token refresh, and shutdown state transitions;
• job deduplication in queued/running/ready/delivering/completed states;
• cancel-before-start and cancel-in-flight behavior;
• result ACK success, timeout, bounded retry, and reconnect recovery;
• default Assistant resolution, per-request override, unavailable Assistant, and session isolation;
• credential encryption and log-redaction assertions.

AionUi

• Livis card rendering and stable selectors;
• loading/error/reconnect/auth-expired states;
• AgentID hidden/visible/copy behavior;
• binding instructions and hardware prerequisite;
• Assistant selection and unavailable-Assistant feedback;
• API mapper coverage so AgentID/auth state cannot be dropped;
• all 13 current locales plus generated i18n key validation.

Physical-device E2E

I have access to Livis glasses and can perform the device-side steps. Once an implementation is ready, the E2E pass can cover:

1. first login and AgentID binding in the 理想同学 app;
2. one default-Assistant request;
3. one Codex request and one Claude Code request;
4. a long-running request whose final answer arrives later;
5. cancellation;
6. relay interruption/reconnection;
7. AionUi restart and a second request;
8. logout/unbind behavior.

After each step, the local AionUi/AionCore logs, conversation records, job IDs, selected Assistant, and returned result should be read back before calling it passed.

Delivery Plan

To keep changes atomic and respect the repository split:

1. Confirm the server/client identity contract and the accepted implementation boundary.
2. Submit a focused AionCore PR for the Livis Channel runtime and typed API.
3. After an AionCore release is available, submit a focused AionUi PR for the Settings experience, API mapping, i18n, tests, and the required AionCore version bump.
4. If common per-message Agent switching is intentionally separated, link it to Feature Request: Add /agent slash command to switch models in Telegram #2736 and keep the Livis transport PR independent while preserving the acceptance criterion.

Related work:

• Feature Request: Add /agent slash command to switch models in Telegram #2736 — dynamic Agent selection from a Channel message;
• [Bug]: I found the actual AionUI bug: Telegram’s “Switch to Codex” creates a session with a new random conversation ID, but it does not create the matching conversations row. That is why you get Conversation not found every time. #2841 — conversation validity when switching Agent;
• [Feature]: Allow binding Assistants (not just Agents) to Lark/Feishu channels for role-based OPC #3433 — Assistant-backed Channel binding already delivered;
• [Feature]: Add Mattermost remote channel support #3494 / feat(channel): add Mattermost settings #3390 — current paired AionCore/AionUi precedent for a new built-in Channel.

Out of Scope for the First Version

• file/image upload from an Agent to Livis;
• copying or redistributing the official OpenClaw plugin/skill;
• changing routing behavior for unrelated Channels;
• claiming Relay/App/glasses behavior that has not passed the physical-device E2E;
• support for non-Livis glasses.

Open Questions for Maintainers

1. Is the AionCore built-in Channel plus AionUi Settings split the preferred boundary, or should this begin as a bundled extension?
2. Can the project obtain an AionUi-specific OAuth client, relay client identity, AgentID namespace, and branding approval from Li Auto?
3. Should the per-request selector reuse/generalize Feature Request: Add /agent slash command to switch models in Telegram #2736, and which voice-friendly grammar should be canonical?
4. Is text-only the correct first delivery, with file transfer explicitly deferred?
5. If the plan is acceptable, could a maintainer assign the implementation to @eyaeya (or explicitly confirm that work may begin)?

Feature Category

Other

Module

Channel Integrations

Additional Context

I will wait for the integration boundary to be confirmed and for the issue to be assigned (or explicitly approved) before starting implementation. No OpenClaw installer has been executed and no user OpenClaw configuration is required by this proposal.

原 issue：#3738

[tcp404]

@eyaeya 这个想法太酷了 🤩 非常欢迎你来一起讨论这个话题！不过落地前需要先做点调研，也想和你聊聊具体怎么实现。

---

@eyaeya Love this idea 🤩 You're very welcome to drive the discussion here! It'll need some research before we commit, and we'd like to talk through the concrete implementation with you.

[github-actions[bot]]

Thanks for posting! @IceyLiu will take a look soon. / 感谢发帖！@IceyLiu 会尽快跟进。

[eyaeya]

@tcp404 @IceyLiu 按你们的要求做了一轮完整调研，把架构设计和技术设计整理如下。全文较长，关键结论在前，细节折叠。两份完整 spec（架构设计 + 技术设计）已在本地整理成文，可按你们偏好以 draft PR 或 gist 形式提供。

本项目已经获得理想汽车 Livis 眼镜开发组产品经理们的认可，不存在商业协议违背风险。

---

1. 调研

bash <(curl -fsSL [https://li-center.lixiang.com/livis-pc-kit/openclaw/mac-linux/latest/setup.sh](https://li-center.lixiang.com/livis-pc-kit/openclaw/mac-linux/latest/setup.sh)) --openclaw

官方套件： latest 仍解析为 v2.0.0（release-2.0.0-fbbbea48.tar.gz），SHA-256 与 07-25 记录完全一致 → 无新版本，原协议分析继续有效。官方 README 新确认的事实：

• Windows 也有官方套件（openclaw/windows/latest/setup.ps1）→ 三平台实现无障碍；
• 眼镜端唤醒词（「让我的个人Agent」等 4 个）+「优先响应」模式（眼镜端所有对话直达个人 Agent）→ 到达 Agent 的是纯文本转写，按请求选 Agent 只能在文本层做；「优先响应」同时意味着显著的环境语音隐私面（设计里有对应披露与保留策略）；
• 每个理想账号仅支持绑定一个个人 Agent；App 与眼镜共享同一连接；
• 官方支持 Agent 向 App 推送 Word/PDF/HTML/MD 文件 → 一期不做，二期有据可依。

参考项目：我仔细评审了第三方兼容实现 Jassy930/livis-relay-daemon（MIT）。它的核心状态机工程质量很高，值得借鉴：执行/投递双持久化状态机 + outbox（含迟到 ACK 收敛边）、每次投递前先落盘 msg_id、提交可证明性（歧义绝不自动重试）、连接代数/租约围栏、幂等 ingest、帧级字节上限先于解析、入站静默截止时间。但也有明确要做不同的地方：它的全局串行链有队头阻塞、session 隔离要靠操作者 CLI 解除（消费级桌面不可行）、单租户硬编码、无数据保留策略，以及两个它自己文档里登记过的 auth 缺陷（瞬态 OAuth 错误误清 refresh token、token 刷新无 single-flight）——这些都不带入。

2. 集成方式

如实对比后，主推荐内置 Channel，但把 extension 路径的真实优点也摆出来，最终由你们定：

维度	Extension 现状	Extension + 泛型能力增强*	内置
发布解耦	✅ 运行时安装	✅	❌ 双仓配对发版
OAuth Device Flow 交互 / AgentID 只读展示	❌ 泛型表单无法表达	✅（需先加 interactiveLogin/只读状态字段能力）	✅（weixin SSE 登录是现成先例）
Assistant / 默认模型绑定	❌（仅 renderer 联合类型收窄——后端 API 本就 platform 泛型）	✅（小改动）	✅
非官方协议代码是否进入主二进制	否（隔离在扩展内）	否	是

* 该增强惠及所有 extension 渠道，但是独立的机制型改动，规模需要你们估价。

推荐内置的理由：需求要求「内置体验、无需手动装扩展」，且 weixin SSE 先例让专属登录交互成本最低。但 extension 路径能把非官方协议实现隔离在主二进制之外——如果你们倾向 extension-first，本设计的协议/任务运行时可以原样落在扩展内，我照做。

3. 总体架构

理想同学 App / Livis 眼镜（语音 → 文本转写，理想云）
        ▼
  Li Auto Livis Relay（云端）
        │  OAuth Device Flow（IDaaS）+ 出站 WSS 长连接
        ▼
┌─ AionCore：crates/aionui-channel/src/plugins/livis/ ──────────┐
│  auth（device flow/single-flight 刷新/revoke，凭据走既有加密存储）│
│  relay（WSS 状态机 + 编解码 + 帧级校验 + 心跳/静默截止/重连围栏）  │
│  store（幂等 ingest → 持久 ACK → 租约派发 → outbox 投递）        │
│  router（覆写文法 → Assistant 解析 → 会话创建/滚动）             │
│  受限执行契约 → 既有 Assistant 会话调度                          │
│  typed API：plugin status 扩展 + /api/channel/livis/*          │
└────────┬──────────────────────────────────────────────────────┘
         │ HTTP + WS（127.0.0.1，现有传输，零新机制）
┌─ AionUi：Livis 卡片（登录 SSE / AgentID / 绑定步骤 / 状态机）────┐
│  assistant_id 绑定 + 默认模型（复用 #3433）+ 配对审批（复用现有） │
└───────────────────────────────────────────────────────────────┘

职责边界与现有渠道完全一致：协议、凭据、任务持久化、派发、投递全在 AionCore；AionUi 只做 UI、类型映射、i18n。Channel 终止于「持久化的入站任务 + 持久化的出站结果」，执行交给既有 Assistant 编排——不自带执行后端。

4. 关键设计决策

1. 发布安全硬门禁：在取得理想官方授予的 AionUi 专属 OAuth client / AgentID 命名空间 / 协议 profile 之前，两仓任何构建都不连接任何理想端点；全部开发验证基于 mock relay。Livis 卡片以现有 coming_soon 机制落地（用户不可见成本≈0），翻转 active 是独立的一行 PR，唯一验收条件 = 身份契约确认。不存在「dev 构建冒用 OpenClaw 身份」的路径。端点/client 真实值不硬编码、不入仓，全部经授权 profile 配置注入。
2. 投递不变式：每个已 ACK 的任务恰好产出一条 outbox 终态投递——Succeeded/Failed/Timeout/Interrupted/Rejected/Overflow 全部有语音可读终态文本（含「执行中重启」的恢复路径，恢复事务内补写 outbox）。否则会出现已 ACK 却永远沉默的任务，眼镜端无限等待。执行 at-most-once、投递 at-least-once（迟到 ACK 有显式收敛边）。
3. ACK 本身持久化：AckPending（落盘）→ socket 写成功 → AckSent，写失败原子回滚，重连握手后补发全部 pending ACK。ACK 发送时机默认对齐参考实现（派发提交后）——那是唯一被观察到端到端可用的行为，服务端 ACK 语义未知，不轻率「改进」；「持久化后立即 ACK」作为假设项做成配置开关，真机阶段双时序对比后再定默认。
4. 无人值守执行契约：channel 来源 turn 的审批请求一律自动拒绝并结算 Failed（语音可读原因）；禁止交互式追加输入；该契约在派发参数层强制。首次启用 Livis 需显式确认「允许远程语音触发本机 Agent 执行」。
5. 会话模型：会话身份 = (livis × assistant × 已批准 node)；空闲/轮次阈值滚动铸新；语音「新对话」指令；CancelUnknown/Interrupted 时作废当前会话铸新（旧 turn 输出按租约/围栏丢弃）——以此替代参考项目的 quarantine-CLI，消费级场景不会静默停摆。派发前先创建/解析持久化会话，显式规避 [Bug]: I found the actual AionUI bug: Telegram’s “Switch to Codex” creates a session with a new random conversation ID, but it does not create the matching conversations row. That is why you get Conversation not found every time. #2841 的孤儿会话缺陷。
6. 按请求 Agent 覆写：首词别名匹配、分隔符可选（中文 ASR 转写常无标点，「必需冒号」会把最高频说法静默落到默认 Assistant），别名经转义字典最长匹配（不拼正则），歧义显式报错，回复首句回显实际使用的 Agent；命中但不可用 → 明确报错，绝不静默换 Agent。文法在真机转写语料（≥10 条）验证前不冻结；备选方案是一期完全不做覆写。不认领 Feature Request: Add /agent slash command to switch models in Telegram #2736（其提案是粘性配置变更，语义不同）；若你们想泛化成通用渠道命令层，另行立项，我保持 Livis 传输 PR 独立。
7. 纵深防御：帧级字节上限（默认 1 MiB，先于解压/解析）→ schema/长度/时间戳校验 → job_id 幂等 → node 配对状态 → 文法白名单。from_node_id 只是路由提示、非身份证明 → 首次接入走现有 pairing 审批 UI，且待批准 node 有上限 + TTL、拒绝回复限速（防灌水）。Device Flow 响应也过闸（verification_uri_complete 必须 https + host 允许列表、interval/expires_in 夹取）——参考实现登记过服务端会返回未校验数据，而这个链接要给用户点。
8. 隐私：语音转写文本本地保留默认 7 天后清理；卡片文案披露「语音经理想云转写后到达本机、转写文本本机短期保留」；登录 SSE 与 status API 不携带任何 token（这点与 weixin 先例的 done{botToken} 回传模式明确不同，Core 侧有 schema 测试断言）。
9. 登出拆两步：本地断连+清凭据必定成功；远端 revoke 失败（该端点曾被第三方观察到返回 404）→ 明确提示「请在理想同学 App 侧解绑」。clear=true 是显式重新绑定流程（官方确认一账号一 Agent，UI 前置告知旧绑定失效）。

协议契约细节（点开）— 出处：第三方公开实现（MIT）+ 官方包 v2.0.0 静态检视，均为观察非规范

• Device Flow：/aux（设备码）→ /token 轮询（以 OAuth error 字段而非 HTTP 状态裁决——观察到 authorization_pending 伴随 HTTP 428；slow_down → +5s）→ /revoke（观察到过 404，见上第 9 条）。刷新响应可能平铺或按 audience 嵌套；仅确定性 invalid_grant 清 refresh token。
• WSS（protocol_version=1）：connect（仅 access token）/ heartbeat（+WS ping；入站静默 > 2× 心跳间隔判死重连）/ send_message（data.type=="exec"）/ ack_send_message / cancel_chat（仅 job_id、无来源身份 → 只在本 scope 匹配）/ send_result（data = JSON.stringify({text})，每次投递新 msg_id）/ ack_send_result / token_expiring|refresh|refreshed。
• ack_send_result 关联：服务端优先级未知（参考实现的 ref_msg_id → job_id → msg_id 只是其客户端兜底，其自查文档已把「多候选指向不同 job」列为风险）→ 本实现仅以本地 delivery_attempts.message_id 精确匹配，解析不唯一则不结算、记日志。
• agent_id/device_id：客户端生成（前缀 + UUID）、持久化；前缀/命名空间待理想授权。account 作用域的可信来源（id_token claim 可用性）列为待厂商确认项。

AionUi 侧改动清单（点开）

PR-0（前置机械重构）：channels/ 目录现有恰好 10 个子项（AGENTS.md ≤10 规则，新增文件即恶化），先把 5 个 *ConfigForm.tsx 移入 channels/forms/（无行为变更；对在途渠道 PR 的影响为一处 import 路径）。

Feature PR：

• channel-logos/livis.svg+ ChannelHeader.tsx logo map + WebuiModalContent.tsx 的 CHANNEL_LOGOS 条；
• channels/forms/LivisConfigForm.tsx（七态：logged_out→authorizing→ready_to_bind→connected / reconnecting / auth_expired / error；首次启用同意弹窗；AgentID 复制 + 四步绑定指引；enable × auth_state 矩阵已定义——登录前 enable 被拒、授权成功自动 enable、disable 断连保留凭据）+ channels/livisAuth.ts（纯逻辑，可单测）；
• ChannelModalContent.tsx 12 处既定编辑位（卡片初始 status: 'coming_soon'）；
• IChannelPluginStatus 增类型化 authState / agentId / authError{code,retryable}；toPluginStatus mapper 增相应映射，顺带修复现存的 raw.error 被静默丢弃问题，并 export 以便单测；channel 增 livisLoginCancel / livisLogout（登录 SSE 由表单直接 EventSource，同 weixin 先例；另有显式 login/cancel 端点——只关 SSE 不足以停掉 Core 侧轮询）；
• i18n：channels.livisTitle/Desc + 嵌套 "livis": {…} 全量进 13 个 locale（含同意文案、隐私披露、错误码文案），bun run i18n:types 再生成；
• 测试：tests/unit/renderer/channels/{livisAuth.test.ts, LivisConfigForm.dom.test.tsx} + tests/unit/common-adapter/ipcBridgeChannel.test.ts（mapper 保真回归）；E2E 先进 COMING_SOON_CHANNEL_IDS，翻转 PR 时移入 ACTIVE_CHANNEL_IDS；
• aioncoreVersion bump。
• 不需要动 configKeys/configMigration/configService（Livis 无用户输入的非敏感配置，全部状态在 Core 侧——比既有渠道更简）。
• PRD（docs/prds/remote/channels/）属产品团队文档：F-WEBUI-22 条目由我随 PR 撰写还是你们 post-merge 补录？请指示。

5. 交付计划与风险

M0  ① 本讨论确认边界（内置 vs extension-first）+ 双仓指派
    ② 理想授予 client 身份/协议 profile/品牌许可（接洽由我执行并同步进展）
    —— 两者齐备才动工
M1  PR-0 重构（AionUi）
M2  AionCore PR（我提交；mock relay 测试全绿）→ 评审合并、发版
M3  AionUi PR（coming_soon 状态）→ 合并
M4  真机 E2E（用正式身份；我持有眼镜）：原提案 8 步清单 + ACK 双时序对比 + 文法语料采集
M5  翻转 PR：coming_soon → active（一行，验收条件 = M4 通过）

6. 对 5 个 Open Question 的明确回答

1. 边界：主推荐「AionCore 内置 plugin + AionUi 专属卡片」（§2 有如实对比，extension-first 我也接受）；
2. 理想接洽：我来执行接洽并在此同步进展；请确认项目侧署名方式与法务签认路径；
3. 覆写文法：默认按 §4-6 方案（真机语料前不冻结），备选「一期不做覆写」；不认领 Feature Request: Add /agent slash command to switch models in Telegram #2736；
4. text-only 一期：是；文件推送二期（官方能力已确认）；
5. 指派：认可后请在 AionUi 与 AionCore 两仓分别指派给我。

—

设计细节任何一条都可以展开讨论。若方向认可，我从 M0-② 的接洽和 PR-0 开始。