lanrtop/dev-manager-tauri
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity

feat(mcp/parity): 三端经稳定 helper 入口连项目专用地址（P1 + P3） #24

Merged
lanrtop merged 15 commits from feat/agent-client-parity into master 2026-10-02 12:05:16 +08:00
Conversation 0 Commits 15 Files Changed 16 +1457 -94

15 Commits

Author SHA1 Message Date
lanrtop
c4241f075d fix(mcp/parity): 更正 Codex Desktop 取认证失败的根因，撤销基于错误前提的 exe 副本逻辑
All checks were successful
Push & PR Check / check (push) Successful in 1m37s
Details
Push & PR Check / check (pull_request) Successful in 1m2s
Details 
2b0a55a 判断「Codex Desktop（MSIX）看不见其安装后在 AppData 下新建的顶层目录」是错的：当时的对照
目录本身也是在 Claude 桌面版的包环境里建的。真正原因：worktree 版炼境由 Claude 桌面版（MSIX）里的
agent 启动，继承了其包环境，写到 %LOCALAPPDATA%\lian-jing 的入口被重定向进
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\，只有 Claude 的进程树看得到。
对照：经 WMI 启动的非包进程在 AppData 下新建的顶层目录，Codex 包内可见；%USERPROFILE% 根不做重定向。

- 入口迁至 %USERPROFILE%\.lian-jing\bin 仍是正解（与炼境在什么环境里启动无关），保留
- 撤销「exe 在 AppData 下就复制副本」逻辑及其测试：exe 总在真实路径上，前提不成立（按「退出」原则）
- 更正代码注释、verify_onboarding 的 Legacy 提示、契约文档与蓝图 P3 返工记录

验证：cargo test 243 passed / 5 ignored（删去 2 个只测副本逻辑的测试）。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 11:31:59 +09:00
lanrtop
cca3bf9db1 fix(mcp/parity): 审查修复——shim 单行退出、副本刷盘后改名、DSH 仅 headless 按目录路由
All checks were successful
Push & PR Check / check (push) Successful in 1m28s
Details
Push & PR Check / check (pull_request) Successful in 1m5s
Details 
对抗审查（14 个 agent，3 条核实成立）与 DSH 桌面版只读调研的修复：

- shim 改为调用与退出同一行（`& call exit /b %%ERRORLEVEL%%`）：cmd 在命令返回后按字节偏移重读
  批处理，入口恰在 helper 运行期间被改写时，分行写法会执行到错位片段（实测 exit 9009）
- helper exe 副本 sync_all 后再改名：避免断电留下残缺副本却因同名被一直复用
- 旧副本改为入口写好之后再清理；旧位置入口写失败时暂不清理，避免入口悬空
- DSH 托管块只在 headless profile 按启动目录路由：web/acp/tui 一个进程可服务多个工作区，
  按启动目录会让别的工作区会话连到该项目并带上认证（跨项目越权）；profile 取 profileContext.name，
  DSH 0.1.x 无该服务时退回看启动参数
- AGENTS.md 入口路径补全反斜杠；蓝图立 P9（DSH 桌面 GUI 会话级插件，待人确认）

验证：cargo test 245 passed；shim 认证成功 exit 0 / 92 字节、错误 digest exit 1；DSH url 表达式按
Loader 方式求值 7 种情形均符合预期；四路零凭据探针（Codex 包内、Codex 包外、Claude、DSH 无头）复跑通过。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 20:06:14 +09:00
lanrtop
2b0a55adcd fix(mcp/parity): helper 入口迁至 %USERPROFILE%，修复 Codex Desktop（MSIX）取认证失败 
人终验发现 Codex Desktop 会话里 lian-jing 完全未加载，Codex 日志为 headers helper exit 1。
根因：Codex Desktop 是 MSIX 打包应用，看不见它安装之后在 %LOCALAPPDATA% / %APPDATA% 下新建的
顶层目录（Invoke-CommandInDesktopPackage 在包上下文对照实测：lian-jing 与新建对照目录均不可见，
与 ACL 无关；已有目录内的新文件、%USERPROFILE% 下的新目录可见）。原验收用包外的 codex exec，未覆盖。

- shim 迁至 %USERPROFILE%\.lian-jing\bin\；Codex 配置、Claude local 条目、DSH 托管块统一引用新入口
- 炼境 exe 位于 AppData 下（安装版默认位置）时，按大小+修改时间指纹复制到入口目录，清理旧副本；
  复制失败退回直接调用当前 exe 并记 warn
- 旧 %LOCALAPPDATA% 入口迁移期同步写入；verify_onboarding 把旧写法报 Legacy 引导 inject_mcp 升级
  （测试断言随之由 Ready 改为 Legacy，理由同上）
- 新增 helper 副本与 AppData 判定测试

复验：Codex 包内（等价 Desktop）、Codex 包外、Claude、DSH 无头四路零凭据探针均返回「开发需求未登记」
（修复前 Codex 包内为「工具不可用」）；cargo test 245 passed / 5 ignored。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 18:58:50 +09:00
lanrtop
1888f71626 docs(blueprint/agent-client-parity): P1 收尾审查记录与已知限制更新为 claude mcp get 为准的方案
All checks were successful
Push & PR Check / check (push) Successful in 1m32s
Details
Push & PR Check / check (pull_request) Successful in 1m5s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 16:57:26 +09:00
lanrtop
0a92a5b695 fix(mcp/parity): 收尾审查修复——Claude 现状以 claude mcp get 为准，接入命令移出界面线程 
收尾对抗审查指出：只读扫描 ~/.claude.json 的结论不能代表 Claude 在项目目录实际生效的条目
（共享项目键、worktree、目录迁移下会误删他项目条目或漏写），且同步 CLI 调用会阻塞界面线程。

- 快路径只认「项目根或其祖先目录键下」的一致托管条目；其余一律在项目目录执行
  `claude mcp get lian-jing` 取实际生效条目，按归属决策：本项目托管条目 → 刷新/移除
  （写入失败用原条目回滚）；他项目托管条目或手写条目 → 不碰并记录；无 local 条目 → 写入
- 输出无法识别、CLI 出错或目录不存在时一律不写，只记 warn
- 全局迁移需 claude CLI 与 git-bash 均可用才置完成标记；批量重注入的成员复查失败计入错误
- 删组/移出组先删成员关系再清 MCP 配置，避免并发重注入把项目加回；调 CLI 前释放数据库连接
- delete_group / add_group_member / remove_group_member / delete_project / update_settings /
  apply_blueprint_buff 改为 #[tauri::command(async)]，在线程池执行
- 新增 parse_claude_mcp_get / lianjing_project_of / key_covers_root 单元测试

实测（enterprise）：稳态注入 174ms 不起 CLI；条目缺失 → 写入；过期 helper → 刷新；
手写条目 → 保留；三种情况 claude mcp get 均为 Local 且 Connected；经 shim 零凭据探针认证通过。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 16:55:28 +09:00
lanrtop
92e6450403 docs(blueprint/agent-client-parity): 更新 P1 审查记录与已知限制为最终方案 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 15:41:08 +09:00
lanrtop
5f6ea586f8 fix(mcp/parity): 最终审查修复——Claude 条目写入回归 claude CLI，只读扫描认领 
最终审查指出直接编辑 ~/.claude.json 须复刻 Claude 私有机制（git 根 / worktree→主仓库 /
NFC 键推导、.claude.json.lock 锁协议、CLAUDE_CONFIG_DIR 与旧版 .config.json、BOM/符号链接/
fsync/键顺序），随 Claude 升级易失效，违背「标准优先、私有机制只进适配层」。

- 写入一律经 claude CLI（cwd=项目目录，同步、带 20 秒超时），由 Claude 自己负责键、锁与路径
- 只读扫描按 URL 中 /mcp/projects/<id> 认领炼境托管条目（不依赖键推导）；已一致则不起 CLI
  （实测稳态注入 0.04 秒），手写条目不碰；项目目录已不存在时只记录残留、不写文件
- 全局注册只读确认已存在就跳过 CLI；配置路径按 Claude 规则解析，容忍 BOM
- 批量重注入在锁内复查组成员关系，已移出组的项目不再注入、不重建 token

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 15:38:36 +09:00
lanrtop
1f90dcdeb0 docs(blueprint/agent-client-parity): P1/P3 完成，记录三端验收与审查证据 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 14:44:00 +09:00
lanrtop
fc8492b88b fix(mcp/parity): 第三轮审查修复——Claude 条目改为直接编辑配置，接入操作加进程锁 
- Claude local 条目不再经 claude CLI（cwd=项目目录）+ 后台队列管理，改为直接编辑
  ~/.claude.json 中本项目键下的 mcpServers.lian-jing：同步、毫秒级、原子替换，只动该字段；
  不依赖项目目录存在，消除删除本地文件夹时的竞态、目录移动后旧条目无法清理、队列丢任务/卡死
- 项目键用真实长路径（实测 8.3 短路径键不被 Claude 识别）；手写条目不碰
- 注入、移除、根目录迁移在进程锁内串行；移除时最先删 token，后续清理收集错误统一返回
- 根目录迁移：旧根解析不出也迁移；重新注入失败归入 mcp_inject 并补刷 DSH；DSH 补丁写入加锁

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 14:37:37 +09:00
lanrtop
7b702a9d88 docs(blueprint): 新建 architecture-evolution 模块，记录技术栈评估与 A1–A4 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 13:49:59 +09:00
lanrtop
e4214cd839 fix(mcp/parity): 第二轮审查修复——串行同步队列、白名单持久剔除、诊断分类 
- Claude local 同步统一投递到单个后台串行队列（注册与移除同队列、按提交顺序），
  消除并发 claude CLI 竞态与「注入后立即移除」留下孤儿条目；移除路径不再阻塞界面
- DSH 白名单只收有项目 token 的项目，退组/移除后剔除持久；控制面项目写 null 停止哨兵，
  不再越过它匹配到已登记的上级目录；Rust 与 JS 两端键规范化对齐（重复分隔符、盘符根、UNC）
- 客户端侧同步日志改为 mcp_client_sync 分类，不覆盖诊断中每个项目的注入结果
- 批量重注入只在末尾刷新一次 DSH；启动刷新移到后台线程
- 项目根目录/平台变更时迁移客户端配置（清旧根 Claude 条目，已接入项目在新根重新注入）
- SSE 消息路由仅在会话属于该项目时才移除；注入模块的进程调用统一 silent_cmd

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 13:39:23 +09:00
lanrtop
0bf5bd6994 docs(blueprint/agent-client-parity): 立卡 P8 一键接入 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 12:58:09 +09:00
lanrtop
0c40e1a5c9 fix(mcp/parity): 对抗审查 9 项修复——控制面保留全局、DSH 改登记白名单 
- 控制面项目（context.json mcp_scope=global，炼境自身已声明）不写 Claude local 条目、
  不入 DSH 白名单，避免遮蔽全局注册与跨项目工具（审查 high）
- DSH 托管块内嵌炼境登记的「项目根目录→project_id」白名单，不再以任意目录里的
  context.json 作为取 token 依据；LOCALAPPDATA/SystemRoot 须为绝对路径
- remove_project_mcp 同步清理 Claude local 条目并剔除 DSH 白名单；SSE 消息路由复核登记
- Claude local 只替换炼境托管条目，手写不覆盖，替换失败回滚；改走 silent_cmd 并移至后台线程
- 手写 DSH 条目改用 serde_yaml 检测（引号/注释/流式写法），无法解析时保守拒绝
- shim 中 exe 路径的 % 转义为 %%；注入日志 context 统一为 JSON，诊断查询防御非 JSON 行

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 11:48:41 +09:00
lanrtop
9a1635a225 docs(blueprint/agent-client-parity): P1 进行中 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 10:43:58 +09:00
lanrtop
ebf43d71c0 feat(mcp/parity): 三端经稳定 helper 入口连项目专用地址 
- P3：炼境启动写 %LOCALAPPDATA%\lian-jing\bin\lianjing-mcp-header.cmd 指向当前 exe；
  Codex 项目配置改为引用该入口，不再写本机 exe 绝对路径；verify_onboarding 对旧写法报可升级
- P1：inject_mcp 以 local scope 为 Claude 注册项目专用地址 + headersHelper（不进仓库）；
  DSH 机器级补丁写托管块，!!js 按启动目录选项目地址并经 cmd 调用同一入口，项目外回退全局
- 服务端：scoped route 拒绝未登记的 project_id（404，数据库不可用同样拒绝）

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 10:40:08 +09:00