refactor: 统一项目名称从OpenFang到ZCLAW

重构所有代码和文档中的项目名称，将OpenFang统一更新为ZCLAW。包括：
- 配置文件中的项目名称
- 代码注释和文档引用
- 环境变量和路径
- 类型定义和接口名称
- 测试用例和模拟数据

同时优化部分代码结构，移除未使用的模块，并更新相关依赖项。

docs/plans/2026-03-12-zclaw-delivery-execution-plan.md

@@ -7,8 +7,8 @@
 当前对“完整可用 ZCLAW”的定义如下：
 
 - 用户能够在本机启动 ZCLAW 桌面应用
-- 用户安装 ZCLAW 时，OpenClaw 运行时已经随包提供，而不是要求用户另行安装
-- 桌面应用能够引导并管理随 ZCLAW 一起分发的本地 OpenClaw Gateway
+- 用户安装 ZCLAW 时，ZCLAW 运行时已经随包提供，而不是要求用户另行安装
+- 桌面应用能够引导并管理随 ZCLAW 一起分发的本地 ZCLAW Gateway
 - 前端能够稳定连接 Gateway，并完成基础握手与鉴权
 - 用户能够创建、编辑、切换 Agent（Clone）
 - 用户能够发起真实对话并收到流式回复
@@ -21,11 +21,11 @@
 
 ### 2.1 已完成的关键能力
 
-- Gateway 握手参数已修正，能够兼容 OpenClaw 2026.3.11
+- Gateway 握手参数已修正，能够兼容 ZCLAW 2026.3.11
 - Token 鉴权已接入前端连接流程
 - `zclaw-ui` 插件可被 Gateway 正常加载
 - Agent 的创建、编辑、保存链路已打通
-- `scripts/setup.ts` 已可在已有 `~/.openclaw/openclaw.json` 时非破坏性合并插件与 skills 路径
+- `scripts/setup.ts` 已可在已有 `~/.zclaw/zclaw.json` 时非破坏性合并插件与 skills 路径
 - 自定义插件 manifest/package id 对齐问题已修复
 
 ### 2.2 当前仍阻塞交付的核心问题
@@ -37,9 +37,9 @@
    - `desktop/src-tauri/src/lib.rs` 仍是默认模板
    - 当前产品更像“前端连接外部 Gateway”，还不是“完整桌面应用”
 
-2. **当前仍默认依赖用户独立安装 OpenClaw**
+2. **当前仍默认依赖用户独立安装 ZCLAW**
    - 这与最终产品目标不一致
-   - 最终必须做到：安装 ZCLAW 后即可直接使用 OpenClaw 能力
+   - 最终必须做到：安装 ZCLAW 后即可直接使用 ZCLAW 能力
    - 因此现阶段的 CLI/PATH 依赖只能作为开发期和过渡期方案
 
 3. **真实桌面链路缺少本地运行闭环验证**
@@ -59,8 +59,8 @@
 ### 3.1 核心原则
 
 - **先打通闭环，再做扩展**：优先修复阻塞真实使用的能力缺口，而不是继续加功能
-- **优先最短交付路径**：优先复用 OpenClaw 现有 CLI/service 能力，而不是一开始就做完整 sidecar 架构
-- **最终必须内置 OpenClaw**：开发阶段允许复用系统已安装的 OpenClaw，但交付阶段必须改为随 ZCLAW 一起分发和托管
+- **优先最短交付路径**：优先复用 ZCLAW 现有 CLI/service 能力，而不是一开始就做完整 sidecar 架构
+- **最终必须内置 ZCLAW**：开发阶段允许复用系统已安装的 ZCLAW，但交付阶段必须改为随 ZCLAW 一起分发和托管
 - **浏览器模式不回退**：新增 Tauri 能力必须有运行时保护，不影响现有浏览器预览/开发体验
 - **阶段可提交**：每个阶段都有独立验收标准，达到后可形成 clean checkpoint
 
@@ -68,7 +68,7 @@
 
 - **P0**：Tauri 桌面壳接入本地 Gateway 生命周期管理
 - **P0**：完成真实桌面端基础闭环验证
-- **P0**：确定并落地“ZCLAW 安装即内置 OpenClaw”的分发方案
+- **P0**：确定并落地“ZCLAW 安装即内置 ZCLAW”的分发方案
 - **P1**：补齐最影响可用性的设置页占位项
 - **P1**：形成交付前 smoke checklist 和文档更新
 - **P2**：补测试、清理遗留代码、准备打包发布
@@ -81,7 +81,7 @@
 
 ### A.1 目标
 
-让 ZCLAW 桌面应用在 Tauri 环境下具备对本地 OpenClaw Gateway 的基础管理能力：
+让 ZCLAW 桌面应用在 Tauri 环境下具备对本地 ZCLAW Gateway 的基础管理能力：
 
 - 查询本地 Gateway 状态
 - 启动本地 Gateway
@@ -91,13 +91,13 @@
 
 ### A.2 实现策略
 
-优先采用**Tauri Rust 命令封装 OpenClaw CLI** 的方式，而不是直接引入完整 sidecar：
+优先采用**Tauri Rust 命令封装 ZCLAW CLI** 的方式，而不是直接引入完整 sidecar：
 
 - Rust 侧封装以下命令：
-  - `openclaw gateway status --json`
-  - `openclaw gateway start --json`
-  - `openclaw gateway stop --json`
-  - `openclaw gateway restart --json`
+  - `zclaw gateway status --json`
+  - `zclaw gateway start --json`
+  - `zclaw gateway stop --json`
+  - `zclaw gateway restart --json`
 - 前端通过 `invoke` 调用 Rust 命令
 - 通过运行时判断，仅在 Tauri 环境中启用这组能力
 - 浏览器模式继续保留“手工连接外部 Gateway”的现有逻辑
@@ -107,7 +107,7 @@
 - 这一阶段是**开发期过渡方案**
 - 它的价值是先把桌面端产品闭环跑通
 - 但它**不是最终交付形态**
-- 最终交付必须把 OpenClaw 运行时随 ZCLAW 一起打包，而不是要求用户本机已有 `openclaw`
+- 最终交付必须把 ZCLAW 运行时随 ZCLAW 一起打包，而不是要求用户本机已有 `zclaw`
 
 ### A.3 代码范围
 
@@ -124,12 +124,12 @@
 - 用户可点击启动/停止/重启
 - 启动成功后，前端可继续连接并拉取基础数据
 - 浏览器模式不因该改动而报错或白屏
-- 开发环境下，即使仍依赖系统 `openclaw`，也已经明确与最终 bundling 方案解耦
+- 开发环境下，即使仍依赖系统 `zclaw`，也已经明确与最终 bundling 方案解耦
 
 ### A.5 风险与应对
 
-- **风险**：不同机器上 `openclaw` 不在 PATH
-  - **应对**：前端明确提示“未安装 OpenClaw CLI”或“命令不可用”
+- **风险**：不同机器上 `zclaw` 不在 PATH
+  - **应对**：前端明确提示“未安装 ZCLAW CLI”或“命令不可用”
 - **风险**：`status --json` / `start --json` 输出结构不稳定
   - **应对**：Rust 侧优先使用 `serde_json::Value` 宽松解析，再映射到前端稳定结构
 - **风险**：服务模式与前台 `gateway run` 并存导致认知混乱
@@ -169,31 +169,31 @@
 
 ---
 
-## Phase C：OpenClaw 随包分发与运行时托管
+## Phase C：ZCLAW 随包分发与运行时托管
 
 ### C.1 目标
 
-把当前“依赖用户本机单独安装 OpenClaw”的开发态方案，推进到真正可交付的产品方案：
+把当前“依赖用户本机单独安装 ZCLAW”的开发态方案，推进到真正可交付的产品方案：
 
-- 用户安装 ZCLAW 时，OpenClaw 运行时已经包含在安装包内
-- ZCLAW 启动后，能够直接找到并启动内置 OpenClaw
-- 用户不需要再单独安装一套 OpenClaw CLI / 环境
+- 用户安装 ZCLAW 时，ZCLAW 运行时已经包含在安装包内
+- ZCLAW 启动后，能够直接找到并启动内置 ZCLAW
+- 用户不需要再单独安装一套 ZCLAW CLI / 环境
 
 ### C.2 目标形态
 
 最终交付建议采用以下形态：
 
-- 安装包内包含 OpenClaw 可执行运行时或受控分发产物
+- 安装包内包含 ZCLAW 可执行运行时或受控分发产物
 - Tauri Rust 侧通过固定相对路径或 sidecar 机制调用该运行时
 - ZCLAW 负责：
-  - 初始化 OpenClaw home / workspace
+  - 初始化 ZCLAW home / workspace
   - 写入或合并默认配置
   - 启动 / 停止 / 重启 Gateway
   - 读取日志与状态
 
 ### C.3 方案比较
 
-#### 方案 1：继续依赖系统安装的 `openclaw`
+#### 方案 1：继续依赖系统安装的 `zclaw`
 
 优点：
 
@@ -209,7 +209,7 @@
 
 - **仅适合开发期，不可作为最终交付方案**
 
-#### 方案 2：把 OpenClaw 作为 sidecar / bundled runtime 随 ZCLAW 分发
+#### 方案 2：把 ZCLAW 作为 sidecar / bundled runtime 随 ZCLAW 分发
 
 优点：
 
@@ -227,15 +227,15 @@
 
 ### C.4 实施任务
 
-- 确认 OpenClaw 可分发形态
+- 确认 ZCLAW 可分发形态
   - npm 包直接落地
   - 预构建二进制
-  - 内置 Node + OpenClaw 组合运行时
+  - 内置 Node + ZCLAW 组合运行时
 - 确认 Tauri 2 下 sidecar / bundled binary 的最佳实现方式
 - 为 Windows 优先落地一版 bundling 方案
 - 调整 Rust 侧命令执行逻辑
   - 优先调用内置运行时
-  - 开发模式可回退到系统 `openclaw`
+  - 开发模式可回退到系统 `zclaw`
 - 验证安装后首次启动流程
   - 不依赖用户额外安装
   - 可直接启动 Gateway
@@ -243,10 +243,10 @@
 
 ### C.5 验收标准
 
-- 全新机器上，未单独安装 OpenClaw 的情况下，可直接安装并启动 ZCLAW
-- ZCLAW 可成功拉起内置 OpenClaw Gateway
+- 全新机器上，未单独安装 ZCLAW 的情况下，可直接安装并启动 ZCLAW
+- ZCLAW 可成功拉起内置 ZCLAW Gateway
 - Agent / 聊天 / 设置等核心功能可正常工作
-- 用户文档不再要求“先安装 OpenClaw 再使用 ZCLAW”
+- 用户文档不再要求“先安装 ZCLAW 再使用 ZCLAW”
 
 ---
 
@@ -298,7 +298,7 @@
 
 说明：
 
-- 最终交付 smoke test 不应再把系统级 `openclaw --version` 作为前置要求
+- 最终交付 smoke test 不应再把系统级 `zclaw --version` 作为前置要求
 - 应改为验证 ZCLAW 内置运行时是否可用
 
 #### 桌面启动检查
@@ -329,7 +329,7 @@
 
 #### 安装闭环检查
 
-- 全新环境中无需单独安装 OpenClaw
+- 全新环境中无需单独安装 ZCLAW
 - 安装 ZCLAW 后首次启动即可使用
 - 若内置运行时损坏或缺失，错误提示明确
 
@@ -383,17 +383,17 @@
 
 - 从桌面打开到完成一次对话全链路可用
 
-## Milestone 3：OpenClaw 随包分发打通
+## Milestone 3：ZCLAW 随包分发打通
 
 输出物：
 
 - Windows 优先的一体化 bundling 方案
-- ZCLAW 优先调用内置 OpenClaw 运行时
-- 安装后无需用户额外安装 OpenClaw 的可运行链路
+- ZCLAW 优先调用内置 ZCLAW 运行时
+- 安装后无需用户额外安装 ZCLAW 的可运行链路
 
 完成标志：
 
-- 在未安装 OpenClaw 的机器/环境中，安装 ZCLAW 后即可直接使用
+- 在未安装 ZCLAW 的机器/环境中，安装 ZCLAW 后即可直接使用
 
 ## Milestone 4：设置页与交付收尾
 
@@ -417,7 +417,7 @@
 2. 在前端新增 Tauri Gateway bridge
 3. 在 `gatewayStore` 中接入本地 Gateway 状态与动作
 4. 在 Settings > General 中增加本地 Gateway 管理卡片
-5. 明确 OpenClaw 随包分发方案，避免把系统安装依赖固化为最终设计
+5. 明确 ZCLAW 随包分发方案，避免把系统安装依赖固化为最终设计
 6. 进行编译/运行级验证
 7. 若验证通过，记录到 `PROGRESS.md`
 
@@ -439,7 +439,7 @@
 
 ### Checkpoint C
 
-- 完成 OpenClaw bundling / sidecar 方案设计
+- 完成 ZCLAW bundling / sidecar 方案设计
 - 明确 Windows 优先的交付路径
 
 ### Checkpoint D
@@ -455,12 +455,12 @@
 
 ## 8. 结论
 
-当前最短、最正确的交付路径，不是继续扩展更多功能，而是先把 ZCLAW 从“能连 Gateway 的前端”推进成“能在桌面端真正管理并使用内置 OpenClaw 的产品”。
+当前最短、最正确的交付路径，不是继续扩展更多功能，而是先把 ZCLAW 从“能连 Gateway 的前端”推进成“能在桌面端真正管理并使用内置 ZCLAW 的产品”。
 
 因此，本轮执行的核心结论是：
 
 - **先做 Tauri 本地 Gateway 生命周期管理**
-- **再完成 OpenClaw 随包分发方案**
+- **再完成 ZCLAW 随包分发方案**
 - **然后做真实桌面端闭环验证**
 - **最后收尾设置页与交付文档**