feat(computer-use): 将 Cindy Computer Use 迁移为官方插件

## 使用场景 / Use case

我们需要把 Desktop Computer Use 从当前的 Desktop Core 内置能力，迁移为可独立设计、分发和更新的官方 `.cindy` 插件。

这个 issue 作为长期 tracking issue，持续记录产品设计、架构边界、迁移方案和分阶段落地；不要求一次 PR 完成。

核对基线：2026-08-07，`origin/main@9bdc1fa1`。

## 当前问题 / Current limitation

### 当前真实状态

1. **已有“内置插件”配置壳，但不是可分发插件**
- `maker-host/plugins/builtin-plugins.ts` 注册了 `computer`，用于名称、开关和 MCP provider 映射。
- 该体系仍是 Phase 1 metadata：descriptor 的 `capabilities.mcps` 为空，且 `computer` 被归类为 machine-wide、默认关闭、从通用「内置工具」列表隐藏。
- 开关状态写在 `builtin-tools-settings.json -> builtinTools.computer`，不是 `.cindy` 插件的安装、批准、启用状态。

2. **Agent 能力仍由 Core 直接提供**
- `packages/lizi-mcps/src/computer/` 提供 `cindy_computer` MCP 的 `list_tools / call_tool`。
- `apps/desktop/src/main/mcp-integrations/computer.ts` 直接承载 CuaDriver 探测、安装、更新、权限、daemon、MCP session、光标、Windows fallback 和错误恢复。
- 每个 Cindy session 会建立独立的 CuaDriver MCP session，并在 session 关闭时清理。

3. **产品 UI 与权限流程深度耦合 Desktop**
- `ComputerUseSection.tsx` 直接编排安装、更新、macOS 权限预检/引导、轮询、启用和 Codex bridge 刷新。
- `maker-ipc/channels.ts` / `register.ts` 暴露了整组 Computer Use 专用 IPC。
- macOS 原生权限引导 helper、Electron fallback、System Settings 开关定位与真实 App 拖拽均随 Desktop 打包。

4. **能力路由仍把它视为 Host 能力**
- 当前 capability routing 使用 `replacement: { kind: 'cindy-host', id: 'cindy_computer' }`。
- PR #1215、#1693 已解决下游 harness / Sky Computer Use 重复暴露，但权威来源仍不是官方 Cindy 插件。

5. **生命周期尚未完全闭环**
- 当前有 session 级 cleanup 和 `cleanupAllComputerDriverSessions()`，但后者未接入应用退出 disposer。
- 仓库中的 `cua-driver stop` 主要用于 macOS fresh permission probe；“退出 Cindy 时 best-effort 停 daemon、保留用户开关偏好”仍需正式接线与验证。

因此，当前状态更准确地说是：**Computer Use 已进入内置工具注册表，但真实产品、运行时和权限仍属于 Desktop Core。**

## 期望方案 / Proposed solution

### 目标边界

- **官方 Computer Use 插件负责**
- 产品身份、描述、图标和版本；
- Agent tool / Skill 暴露与使用说明；
- 启用、安装、更新、设置与状态 UI；
- CuaDriver 版本策略和用户可见引导；
- 插件分发、独立迭代与回滚。

- **Cindy Core 只保留必须由宿主掌握的最小特权原语**
- Electron / OS 权限边界；
- macOS 签名 native helper、System Settings 协作和 TCC 事实读取；
- Windows 托盘与 Win32 fallback 等平台桥；
- CuaDriver 进程/session 的窄 Host service；
- 应用退出、崩溃恢复和 capability routing 基础设施。

不新增一个泛化的“任意宿主能力”槽。若插件需要调用宿主，应设计 Computer Use 专用、可审计、权限可展示的窄契约。

### 分阶段计划

#### M0：设计与迁移契约

- [ ] 确定官方插件 id、manifest、版本与分发方式。
- [ ] 明确哪些代码进入插件，哪些继续作为 Host primitive。
- [ ] 确定 Agent 暴露方式：插件 tool/Skill 为权威来源；迁移期可保留 `cindy_computer` 兼容 adapter。
- [ ] 定义旧状态迁移：
- 读取 `builtinTools.computer`；
- 已启用用户保留等价授权，已关闭用户继续关闭；
- 等价权限不得要求重新确认，新增权限必须单独确认；
- fresh install 继续默认关闭；
- 保留旧 key/旧版本回退的兼容窗口。

#### M1：收敛 Host runtime

- [ ] 将 CuaDriver status/install/update/permission/session/tool/stop 收敛为一个可测试的 Computer Use Host service。
- [ ] 为插件定义窄、结构化、带来源校验的请求与事件契约。
- [ ] Renderer 不再直接持有整套 CuaDriver 状态机。
- [ ] 把全局 cleanup 接入 Cindy 正式退出链；异常退出与更新重启路径也要给出明确结论。

#### M2：建立官方 `.cindy` 插件

- [ ] 插件拥有身份、设置/面板、tool、Skill 和使用引导。
- [ ] 插件调用 Host service，不自行绕过权限边界。
- [ ] 保持 CuaDriver 为一期真实 runtime；不重新实现电脑控制引擎。
- [ ] 禁用/卸载时不暴露 Computer Use 工具，不自动探测、下载或弹系统权限。
- [ ] 插件更新与 CuaDriver runtime 更新在 UI 中分清，不混成一个版本概念。

#### M3：迁移设置与用户流程

- [ ] 将「直接操作电脑」从 `ComputerUseSection.tsx` 的 Core 专用逻辑迁移到插件详情/设置体验。
- [ ] Browser、Android Automation 不被本迁移误伤。
- [ ] 启用流程保持：被动检查 → 显式安装 → Accessibility → Screen Recording → 完成后启用。
- [ ] macOS 继续使用真实 CuaDriver TCC 身份；一期不引入临时 companion 造成多身份并存。
- [ ] 处理设置页卸载、取消、重开、安装/更新在途和 Codex refresh deferred。

#### M4：运行状态与跨平台生命周期

- [ ] macOS：daemon 活跃时保持清晰、可打开、可停止的真实运行状态入口。
- [ ] Windows：复用 Cindy 单一托盘，不增加第二个托盘图标。
- [ ] 退出 Cindy 时 best-effort 停止 CuaDriver daemon，但保留用户插件启用偏好，供下次启动恢复。
- [ ] running session、Codex shared bridge、Claude Code 与后续 Agent 的启停语义一致。
- [ ] 本地 / SSH / Device Link / Mobile 的支持范围明确；不支持的场景 fail closed。

#### M5：能力路由、兼容与清理

- [ ] capability routing 的权威 replacement 从“Core 产品能力”收敛到官方插件来源。
- [ ] Cindy 插件可用时不重复暴露 Sky / harness Computer Use；不可用时不制造幽灵替代能力。
- [ ] `@` 窗口候选、session 生命周期、路径边界和快照代际护栏保持有效。
- [ ] 完成迁移观察期后，删除旧 builtin metadata、专用 Renderer 编排和不再需要的 IPC。

#### M6：验证与发布

- [ ] 旧 `builtinTools.computer` 状态升级 fixture。
- [ ] 已启用、已关闭、未安装、driver 缺失、权限缺失、权限撤销、更新后 TCC 变化等回归测试。
- [ ] macOS / Windows packaged build 验证；native helper、codesign/notarization 和插件发布链闭环。
- [ ] Codex / Claude Code 工具可见性、调用、启停和 deferred refresh 验证。
- [ ] 插件基座改动遵守存量插件无感升级红线，并经过对应白名单 review gate。

## 验收标准

- [ ] Computer Use 在产品上是一个真实的官方 `.cindy` 插件，而不只是 builtin registry metadata。
- [ ] Core 中只保留通用且必须特权执行的 Host primitive，不再承载完整产品入口。
- [ ] 老用户升级后无需重新安装、重新开启或重复授予等价权限。
- [ ] 插件关闭/卸载后没有工具暴露、后台探测、driver 自动拉起或权限弹窗。
- [ ] 启用、安装、授权、更新、停止和恢复都有确定状态与可测试语义。
- [ ] macOS 与 Windows 都有清晰且不重复的运行状态入口。
- [ ] 退出 Cindy 会收敛 Computer Use runtime，且不清除用户偏好。
- [ ] 下游 harness 不再与 Cindy Computer Use 重复或无感抢路。

## 已考虑的替代方案 / Alternatives considered

1. **继续维持当前 builtin plugin metadata**
- 只能统一开关，不能获得插件分发、独立更新、权限清单、设置承载和生态边界，不满足目标。

2. **把全部能力直接塞进插件 Node Worker**
- Node Worker 有用户级本机权限，但 macOS TCC、签名 native helper、Electron 生命周期和跨平台托盘仍需要宿主可信代码；全部下放会让权限边界与发布链更难审计。

3. **先做 branded Computer Use.app 再插件化**
- 不是一期前置。第一阶段继续沿用真实 CuaDriver；独立 companion、单一品牌 TCC 身份和内置签名 runtime 可作为后续里程碑单独设计。

## 相关项与重复项核对

- PR #248：macOS 权限引导。
- Issue #335：#248 的产品/UI 讨论，已关闭。
- Issue #574：CuaDriver 安装包兼容问题，已关闭。
- PR #1215：宿主 capability routing。
- PR #1693：屏蔽重复 Sky Computer Use。
- Issue #1806 / PR #1829：Android Automation 的 adb 生命周期，范围不同。

已按 `Computer Use`、`computer-use`、`CuaDriver`、`cindy_computer`、`电脑使用 插件` 检索现有 Issue/PR，未发现同范围的 Computer Use 插件化 tracking issue。

Read maker-host/plugins/builtin-plugins.ts, apps/desktop/src/main/mcp-integrations/computer.ts, and ComputerUseSection.tsx first; trace the related IPC entry points in maker-ipc/channels.ts and register.ts. Done means Computer Use is an independently distributable official .cindy plugin, with a narrow host service, migrated state and permissions, lifecycle cleanup, and regression coverage across the listed scenarios.

Written by the indexing model from the issue text.