lanrtop/dev-manager-tauri
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
369 Commits 43 Branches 4 Tags 14 MiB
e13599fbbd
Commit Graph

22 Commits

Author SHA1 Message Date
lanrtop
e13599fbbd feat(onboarding/parity): lian-jing skill 补写操作确认与 unavailable/unknown 两条通用边界，接入包升至 1.8.0
All checks were successful
Push & PR Check / check (push) Successful in 59s
Details
Push & PR Check / check (pull_request) Successful in 1m0s
Details 
P7 实测 Codex 不把 MCP 服务器说明带入模型上下文，服务器说明里的「其他写操作
须用户明确确认」「unavailable/unknown 不得当作成功」在 skill 中只有分场景表述。
现把两条作为通用边界写进 lian-jing skill 模板开头（同一模板双投影到 .agents
与 .claude），措辞与服务器说明一致；只读查询、登记开发需求元数据、回传炼境
列为无需确认的例外，与 skill「回传不必逐条征得同意」相容。

- base-onboarding 1.7.0→1.8.0（BASE_ONBOARDING_PACK_VERSION、模板
  capability-packs.json、TEMPLATE_FINGERPRINTS 指纹）
- mcp_server 新增 server_instruction_universal_rules_are_in_skill：服务器说明与
  skill 任一侧缺这两条即失败
- 蓝图 agent-client-parity P7 known_limits 记录已补齐

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-03 05:25:18 +09:00
lanrtop
cce7d92ee0 docs(blueprint/agent-client-parity): P7 实测服务器说明仅 Claude/DSH 带入模型上下文，保留 skill 引导
All checks were successful
Push & PR Check / check (push) Successful in 1m1s
Details
Push & PR Check / check (pull_request) Successful in 1m3s
Details 
三端无头探针（node 桩 MCP 服务，实验组 initialize 带含唯一标记的 instructions，
对照组不带）结论为部分支持：Claude Code 2.1.173 与 DSH headless 答出标记、
对照组答 NONE；Codex 0.155.0-alpha.9.2 两组都答 NONE、输入 token 完全相同，
桩服务日志证明 initialize 与 tools/list 均成功、模型能调用桩工具，说明已送达
客户端却没进入模型。

按 acceptance 不迁移：引导提示仍以 lian-jing skill 与 AGENTS.md 托管块为三端
单一来源，mcp_server.rs 与 skill 均不改。

- 蓝图 P7 标 ✅，记录结论、三端证据与 known_limits（Codex TUI/桌面版与 SSE
  未验、真实说明未实测、服务器说明中两条通用规则在 skill 只有分场景表述）
- agent-button-system.md「本地 Agent 控制面的稳定边界」增一条：服务器说明只是
  增强层，三端都须遵守的引导不得只写在服务器说明里
- manifest 中 agent-client-parity 进度 55 → 64，note 补 P7

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-03 05:02:12 +09:00
lanrtop
c9b951dd30 fix(onboarding/parity): 混合文件预警收窄空白归一、失败时不丢预警、测住改写判断（P10 审查修复）
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
Details
Push & PR Check / check (pull_request) Successful in 1m5s
Details 
P10 审查核实的三处缺陷：

- 块外比较原先逐行 trim_end 并丢弃全部空行，项目在块外删空行（Markdown 两段
  并成一段）或加行尾空格（硬换行）时判为无改动，升级后不预警却产生混合文件。
  改为 CRLF 统一为 LF、托管块原位换成占位符，只把文末占位符连同其前空白按
  trim_end 归一（正好抵消炼境追加托管块时的 trim_end + 空行）；文中托管块两侧
  的空行与行尾空格照常比较——炼境只原位替换文中的块，不碰两侧。
- dispatch_templates_with_mixed_file_check 先 `then()?` 后标注：buff 先同步蓝图
  规则改写了 AGENTS.md/CLAUDE.md、再写 DB 失败时，预警随 Err 一起丢失。改为
  无论成败先标注，失败时把混合文件名并入错误信息；无混合文件则原样返回错误。
- 「块外有未提交改动但托管块已是最新、本次不改写」组合没有测试，删掉 annotate
  的改写判断测试照样全绿。主场景测试补情形三。

测试：新增 outside_managed_whitespace_edits_count_as_changes、
mixed_file_warning_survives_failure_after_write，主场景补情形三；纯函数测试的
期望值随归一化收窄更新（"# 标题\n项目内容" → "# 标题\n\n项目内容"，保留「之前
追加的块尚未提交、只多出块前空行」不算改动的断言）。变异自检：三处修复逐一回退，
对应测试各自失败，已还原。cargo test --locked：lib 272 passed / 5 ignored，0 failed；
pnpm typecheck 通过。契约文档 project-context.yaml 与蓝图 P10 卡同步。

Rules-Applied: R07,R12
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-03 04:32:39 +09:00
lanrtop
13aa3a1a8c feat(onboarding/parity): 接入包改写托管块前检测块外未提交改动，给出混合文件预警（P10）
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
Details
Push & PR Check / check (pull_request) Successful in 59s
Details 
2026-10-01 enterprise 的 git-workflow.md 在有项目未提交改写时被升级了托管块，
同一文件混有炼境与项目两种来源的改动，按「禁止字符串手术」无法拆分提交，只能交人定案。
管家应在制造混合文件时明确告知，而不是事后由人发现。

- TemplateResult 新增可选 warning（序列化时缺省省略，前端类型同步）
- apply_onboarding_pack 在模板分发与 buff 蓝图规则同步前后夹一层检测：写入前对
  AGENTS.md、docs/ai-context/git-workflow.md、CLAUDE.md 跑 git status，有改动再取
  HEAD:./<文件>（不在 HEAD 中按空内容算），两边去掉 ONBOARDING_MANAGED 与
  BLUEPRINT_MANAGED 块后比较（忽略行尾与空行）；写入后只对本次确被改写的文件预警，
  文案含文件名与「块外有未提交改动，升级后将成为混合文件」
- 只提示不阻断，块外内容照旧不动；git 不可用、非仓库或命令失败一律静默；
  git status 带 --no-optional-locks，不抢 index.lock
- CLAUDE.md 只由蓝图规则同步改写，不在模板结果里，预警时补一条结果
- BLUEPRINT_MANAGED 标记提为 blueprint.rs 的 pub(crate) 常量，检测与 upsert 共用
- MCP 单项目输出在该文件行下加预警行，批量输出追加混合文件清单；工具描述同步；
  炼境 UI 接入包结果行下显示预警
- 契约文档 project-context.yaml 同步；蓝图 P10 标 ✅ 并记录验证与已知限制

验证：cargo test --locked lib 270 passed / 5 ignored；新增 3 个测试（纯函数、临时 git
仓库三种情形、非 git 目录），变异自检（探测强制返回 true 时两个场景测试均失败）；
pnpm typecheck 与 pnpm test 通过。

Rules-Applied: R01,R06,R12
Feature-Confirmed: true

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-03 03:58:28 +09:00
lanrtop
f8d658b790 docs(blueprint/agent-client-parity): P9 人终验通过，标记完成
All checks were successful
Push & PR Check / check (push) Successful in 1m4s
Details
Push & PR Check / check (pull_request) Successful in 1m6s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 16:32:21 +09:00
lanrtop
fe0458fe97 fix(mcp/parity): P9 审查修复——受限子代理不挂载、条目 id 带版本、插件缺失守卫、规范路径键
All checks were successful
Push & PR Check / check (push) Successful in 1m6s
Details
Push & PR Check / check (pull_request) Successful in 1m4s
Details 
对抗审查（11 个 agent，6 条成立，均 low）：
- 受限子代理（toolFilter）会绕过限制：挂在子代理自己作用域的工具不受过滤。改为经 tools.view 判断，
  受限或无法判断即不挂；根会话与未受限子代理照常挂载
- 版本号只编进文件名时，运行中的 DSH 不会重载新插件（同 id 只改 name 不重载）：条目 id 改为
  lianjing-session-mcp-v1，与文件名同一版本；新增内容哈希测试，改插件漏升版本即失败；块外手写按前缀拒绝
- 插件文件缺失时 DSH 0.1.x 启动失败：条目加 `disabled: !!js` 文件存在性守卫
- GUI 会话工作目录是 realpath：白名单同时写入登记路径的规范形态（junction、8.3 短名）
- 补测试：分层停止哨兵、取认证失败与超时（.cmd 夹具）、受限/未受限/无法判断的子代理
- 蓝图如实更正首轮端到端只有插件一行；补测完整托管块

验证：cargo test 247 passed；vitest 16 passed（插件 8 条）、typecheck 通过；完整托管块端到端在
DSH 0.2.0-rc.2 与 0.1.5-rc.2 上项目会话带认证连上项目地址、其他会话无请求；插件文件缺失时两版都正常启动。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 15:04:54 +09:00
lanrtop
f21345bf1a feat(mcp/parity): DSH 桌面 GUI 按工作区连项目地址（会话级插件，P9） 
DSH 桌面版只有一个 Host 进程、启动目录固定，托管块的 !!js 只在启动时求值，拿不到会话信息；
web/acp 同样一个进程服务多个工作区。改由炼境分发一个会话级插件：会话创建（agent/created）时
按会话工作目录匹配炼境登记的项目白名单，命中才在该会话作用域挂连项目专用地址的 mcp-client，
同名工具覆盖全局 lian-jing，其他会话不受影响。

- 插件随二进制打包（resources/dsh/lianjing-session-mcp.v1.mjs），刷新 DSH 托管块时写到
  %USERPROFILE%\.lian-jing\dsh\；文件名带版本号（Node 按 URL 缓存 ESM）
- 托管块在全局行之后追加插件条目（port、shim、roots 以 JSON 写入）；插件文件写失败时只保留全局行
- 插件防御：headless 交给全局行；特性探测不符即降级为全局；取认证 ≤3 秒、整次挂载 ≤5 秒；
  所有回调吞掉异常（Host 对未处理异常会崩溃，agent/created 串行失败会让会话创建失败）
- 块外手写的 lianjing-session-mcp 条目同样拒绝覆盖

验证：cargo test 246 passed；vitest 插件用例 6 条通过、typecheck 通过；端到端在 DSH 0.2.0-rc.2
与 0.1.5-rc.2 上，项目会话经真实稳定入口带认证连上项目地址，其他会话无请求。

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 13:33:45 +09:00
lanrtop
019d81c60e fix(onboarding): 审查修复——JSON 按语义比较，CI workflow 与生成文件同内容不重写
All checks were successful
Push & PR Check / check (pull_request) Successful in 1m3s
Details 
对抗审查（9 个 agent，2 条成立）：
- settings.json / context.json 改为按 JSON 语义比较：Claude Code 改写后键序与末尾换行不同，
  按文本比较仍会让每次注入整文件重排
- plan_cicd_workflow 忽略行尾判 noop：原按字节比较，autocrlf 检出的同内容 workflow 会被判 update，
  并请用户确认一次无变化的写入；apply 与 generate_workflow 只在内容变化时落盘
- 同类遗漏统一改用 write_if_content_changed：agent_infra 生成文件（未变时报 skipped）、notes-archive 回填
- lib.rs 抽出 same_text_ignoring_eol，与 write_if_content_changed 共用同一比较规则

验证：cargo test 245 passed / 5 ignored（新增 JSON 语义与 CI CRLF 回归断言）。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 11:51:33 +09:00
lanrtop
d098905f28 fix(onboarding): 接入写入幂等——内容不变不重写，Codex 托管块不再累积空行 
enterprise 未提交改动归属梳理发现两处炼境侧缺陷：
- Codex 托管块自带结尾换行，又原样保留 END 之后的换行，每次注入多一个空行（enterprise 已累积 16 行）
- sync_blueprint_rules 与注入在内容不变时也用 LF 重写文件：子项目开 core.autocrlf，CRLF 检出的
  同内容文件被 git status 误报为改动，修改时间也被刷新，干扰改动归属判断

修复：
- lib.rs 新增 write_if_content_changed（忽略行尾比较，内容不变不写）
- sync_blueprint_rules 的 CONVENTIONS 与 AGENTS/CLAUDE 托管块、context.json、.claude/settings.json、
  Codex 托管块统一改用它；托管块未变时返回 unchanged
- Codex 托管块写入吸收 END 之后的空行，块外后续内容以一个空行分隔
- 蓝图记 P3b（本修复）、P10（接入包升级前检测块外未提交改动，待做），P9 补可行性实测记录

验证：cargo test 246 passed；实测 enterprise 注入后 .codex/config.toml 末尾空行 16→0，
再次注入四个托管文件修改时间均不变。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-02 11:35:18 +09:00
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
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
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
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
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
5d15520e73 docs(blueprint/agent-client-parity): 定位为 agent 客户端兼容层，立卡 P6/P7
All checks were successful
Push & PR Check / check (push) Successful in 1m3s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 09:53:48 +09:00
lanrtop
f4e75dc91f feat(onboarding): lian-jing skill 双投影到 Claude，接入包升至 1.6.0
All checks were successful
Push & PR Check / check (push) Successful in 1m4s
Details 
- 同一模板同时写 .agents/skills（Codex、DSH）与 .claude/skills（Claude Code）
- verify_onboarding 新增「Claude 炼境技能已分发」检查
- skill 降级步骤改为三端通用，提示无开发变量工具即连的是全局地址
- capability-packs supported_clients 增加 dsh

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 09:11:32 +09:00
lanrtop
8babc545c3 docs(blueprint/agent-client-parity): H2/H4 零凭据实测成立，三端可共用 shim
All checks were successful
Push & PR Check / check (push) Successful in 1m33s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-01 08:58:27 +09:00
lanrtop
bbdc98b93f docs(blueprint/agent-client-parity): 记录 H1–H4 实测与对抗复核结果
All checks were successful
Push & PR Check / check (push) Successful in 1m14s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 22:03:02 +09:00
lanrtop
d1e75d2270 docs(blueprint): 新建 agent-client-parity 模块，记录三端无头基线
All checks were successful
Push & PR Check / check (push) Successful in 1m26s
Details 
- 三端（Claude Code / Codex / DSH 桌面版）同一只读任务的 A–F 矩阵作为基线证据
- 立 P1–P5：统一项目专用地址、Claude skill 投影、稳定 helper 入口、
  探针固化、落地兜底；原 V17/V18 迁入 P1/P3
- manifest 项目描述同步为「管家」定位

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 19:12:03 +09:00