f8dc95c6ee
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
三角度方案（最小编排 / 收敛流水线 / 本体收口）并行设计 + 综合评审，设计文档入库 docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md（16 条已核实代码事实、风险 R1–R18、决策 Q1–Q11）。用户以 /goal 授权按推荐方向代为推进，11 项全部采纳推荐项。 - 主方案：同步、零模型的最小编排本体 + 可选异步探针；嫁接 plan/digest 写前确认、 经真实 shim 的认证链重放、「已接入」单一判定、客户端适配器注册表 - A1 不前置：P8/P4 载体都在炼境进程内，离线写入会绕过进程内锁且有 MSIX 重定向 风险，真正耦合是全局 pool() 而非 crate 边界；A1 改为 A1a（随 P8b 的适应度测试）、 A1b（按需 CLI 薄客户端）、A1c（触发式拆 crate，四个触发条件） - P4 分 L0 静态 / L1 零模型 / L3 无头会话；P8 只依赖 L1（P4a） - 验收口径变更（Q1，报备）：P8 由「三端无头 A–F 矩阵」改为「L1 零模型矩阵 + 可选 L3 结果及是否过期」，理由写在 P8 卡 - P6 依赖 P8c（Q3）；P4b 排在 A4 之后（Q8）；manifest 清除「P4/P8 依赖 A1」 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
69 lines
5.9 KiB
Markdown
69 lines
5.9 KiB
Markdown
---
|
||
id: architecture-evolution
|
||
name: 炼境架构演进
|
||
status: planned
|
||
progress: 0
|
||
---
|
||
|
||
## 概述
|
||
|
||
2026-10-01 评估结论：现有技术栈（Tauri v2 + Rust + React/TS + SQLite）适合「管家 / agent 客户端兼容层」方针，不换栈。常驻托盘服务、凭据安全、单文件分发、cargo test 快速回归都是 Rust/Tauri 的强项；真正的难点在 Windows 与各客户端自身机制（cmd 引号与 %VAR% 展开、CRLF、Claude 配置作用域、DSH !!js、Node 拒绝直接执行 .cmd），与语言无关。Electron 全 Node 栈（与三家客户端同生态、JSON/YAML 顺手）因常驻内存大、凭据需原生模块且须整体重写而否决；Go、Python 无明显收益。
|
||
|
||
本模块收集比「换语言」更影响实现效率的结构性改进，按收益排序。
|
||
|
||
## 任务拆解
|
||
|
||
### 📋 A1 — 本体与投影分离（2026-10-03 改写为三段：A1a / A1b / A1c）
|
||
- status: todo
|
||
- complexity: L（已拆，见下）
|
||
- 原卡：core crate + CLI——「业务逻辑位于不依赖 Tauri 的 core crate；同一 exe 或独立 cli 在炼境界面未运行时可执行 onboard / probe / diagnostics」。原「为什么」：核心逻辑写在 Tauri 应用内，炼境不运行时 agent 与脚本无法调用；拆分后 Tauri 界面、MCP 服务、命令行成为同一本体的三个投影。
|
||
- 改写理由（2026-10-03 agent-client-parity P8 设计评审，`docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md` §5）：
|
||
1. P8 与 P4 的验收载体是 Tauri command 和 MCP，本来就跑在炼境进程里；探针测的是「客户端连上运行中的炼境 MCP」，炼境离线时无物可测——「界面不运行也能用的 CLI」对它们没有用例。
|
||
2. 离线写入有实际危害：MCP_OP_LOCK、DSH_PATCH_LOCK 与凭据存储的锁只在进程内有效，~/.claude.json（经 claude CLI）、~/.dsh/cordis.patch.yml、Credential Manager、SQLite 会被两个进程竞争写；agent 从 MSIX 客户端里调用时 AppData 写入可能被重定向（P3 已实证）。
|
||
3. 真正的耦合是全局 pool()（约 293 处、43 个文件）和进程内静态锁，拆 crate 解决不了；A1 是 L 级，会与 A4、P6 大面积冲突，把 P8 推迟数周。
|
||
4. 复用主 exe 做 CLI 还要处理控制台挂接（release 为 windows_subsystem="windows"）和 single-instance，那是拆 crate 时才需要解决的设计问题。
|
||
结论：P8 需要的是 A1 的原则（本体不依赖投影），不是 crate 拆分。
|
||
|
||
### 📋 A1a — onboard/ 模块的投影无关约束（随 agent-client-parity P8b 落地）
|
||
- status: todo
|
||
- complexity: S
|
||
- depends: agent-client-parity P8b
|
||
- acceptance: "agent_verify: [cargo test] onboard_module_is_projection_free——src-tauri/src/onboard/ 下的源码不含 tauri::、db::pool(、#[tauri::command]；连接、CredentialStore、ProcessRunner、ClientLocator 都由调用方注入，结果一律是 serde 结构体。"
|
||
- 说明：由 P8b 承载实现，P8b ✅ 时本卡同步 ✅。存量代码不扩散旧写法，旧入口按绞杀者模式逐步改成薄包装；A1-ready 由测试机器校验，而不是靠约定。
|
||
|
||
### 📋 A1b — CLI 薄客户端（按需）
|
||
- status: todo
|
||
- complexity: M
|
||
- acceptance: "agent_verify: [CLI] 由真实需求定义；探针场景已由 agent-client-parity P4e 的 pnpm probe:clients（调用全局 MCP 的薄脚本，不新增协议面）覆盖。"
|
||
- 触发：「会话启动时 MCP 没连上、需要第二通道」被证明是常态时，再做 Rust console 版 lianjing.exe 与 skill 降级说明（需升接入包版本、全部子项目重新分发）。
|
||
|
||
### 📋 A1c — core crate 拆分（触发式，届时先 /architect）
|
||
- status: todo
|
||
- complexity: L（先 /architect 再拆）
|
||
- acceptance: "agent_verify: [cargo test] 业务逻辑位于不依赖 Tauri 的 core crate；具体验收在触发后的 /architect 设计中定义。"
|
||
- 触发条件（满足任一即启动）：① 需要在没有 Tauri/WebView 的环境（例如 Linux CI）里跑本体；② 确实需要离线写入，并且跨进程锁和包上下文检测已经具备；③ cargo test 的编译时延成为主要的反馈延迟；④ 出现第三个独立的消费者。
|
||
|
||
### 📋 A2 — 前后端类型契约自动生成
|
||
- status: todo
|
||
- complexity: M
|
||
- files: src-tauri/src/commands/、src/lib/commands.ts
|
||
- acceptance: "agent_verify: [pnpm typecheck] commands.ts 的参数与返回类型由 Rust 定义生成（tauri-specta 或 ts-rs），新增 command 不再手抄类型；删改 Rust 字段时 typecheck 报出所有受影响处。"
|
||
- 为什么：现由规则 R01 要求手动同步 commands.ts，易漏；对应四支柱「可推理」。
|
||
|
||
### 📋 A3 — 配置文本生成模板化
|
||
- status: todo
|
||
- complexity: M
|
||
- files: src-tauri/src/mcp_inject.rs、src-tauri/resources/
|
||
- acceptance: "agent_verify: [cargo test] Codex 托管块、DSH 托管块、shim 等由模板（如 minijinja）渲染，并有「渲染结果是合法 YAML/TOML/JSON」测试。"
|
||
- 为什么：2026-10-01 实现 P1 时在 Rust 中手拼 YAML/JS，出现缩进被字符串续行吞掉、转义少一个反斜杠两个缺陷（均被测试拦下）。模板能从写法上避免这类问题。
|
||
|
||
### 📋 A4 — MCP 协议改用官方 Rust SDK（rmcp）
|
||
- status: todo
|
||
- complexity: M
|
||
- files: src-tauri/src/mcp_server.rs、src-tauri/src/mcp_tools.rs
|
||
- acceptance: "agent_verify: [cargo test + 三端无头探针] 换用 rmcp 后 scoped 路由、敏感读取认证、SSE 与 streamable HTTP 行为不变，三端 A–F 矩阵不回退。"
|
||
- 为什么：现为手写 JSON-RPC + SSE。各客户端对 MCP 的支持持续演进（streamable HTTP、认证、服务器说明等），自维护协议细节的成本会上升。
|
||
|
||
### 附：调用外部进程的 Tauri command 统一 async
|
||
- 同步 Tauri command 跑在主线程，内部调用 claude CLI 等外部进程会卡界面；agent-client-parity 审查已两次发现此类问题。新增此类 command 默认 async，存量随相关改动迁移，不单独立卡。
|