Commit Graph

173 Commits

Author SHA1 Message Date
lanrtop
5b6c197a74 feat(onboard/parity): UI 一键接入面板——先计划预览、人确认后接入,四个入口接线(P8g)
- onboardView.ts:计划 / 报告 → 视图模型的纯函数(阻断禁用确认、可跳过只看后端 skippable、
  not_installed / not_applicable 灰色说明、bypassPermissions 与 Codex 信任单列、确认带 expected_digest
  与生成计划时的选项),onboardView.test.ts 13 条 vitest
- OnboardPanel.tsx / OnboardSections.tsx:全局挂载的接入面板(plan → 预览 → onboard_project → 分步结果、
  L1 矩阵、待你提交的 N 个文件、待你操作),refused 可回到新计划重新确认
- 入口:新建项目选了目录、模板新建成功后弹出预览;批量添加只给逐项入口;蓝图治理「施加 Buff」
  改为同一面板(先 plan 再 apply)
- plan.rs:BlockedItem 序列化附派生字段 skippable(= BlockReason::skippable,不进 digest)

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 01:35:06 +09:00
lanrtop
97578b2261 feat(onboard/parity): 一键接入 MCP 与 Tauri 投影、Codex 信任计 pending_user 与仓库布局说明(P8e)
All checks were successful
Push & PR Check / check (push) Successful in 1m27s
Push & PR Check / check (pull_request) Successful in 1m6s
- MCP 新增 plan_onboarding(readOnly)与 onboard_project(幂等写操作):schema 各自单独成函数,
  dispatch 一行委托到 mcp_inject 生产入口(中间只做 JSON 类型解析);全局与项目路由都可见,
  项目路由强制本项目、跨项目返回 scope_violation;onboard_project required 含 expected_digest
  与 confirmed;共用可选选项 bypass_permissions / skip_targets;进 STRUCTURED_TOOLS 并给一行摘要
- Tauri 新增同名 async 命令(async fn + spawn_blocking),commands.ts 同步 OnboardOptions、
  OnboardingPlan、OnboardReport 类型与 planOnboarding / onboardProject 封装
- 统筹决定(P8d 审查 ⑩):L1 Codex 列仅因 codex_project_untrusted 未就绪的格不计入 done,
  completion 单列「Codex 信任」(pending_user),next_actions 保留 codex_trust;仓库子目录与
  worktree 补 next_action repo_layout 说明为何到不了 done;非 git 维持不能 done
- 契约同步:project-context.yaml、agent-button-system.md、AGENTS.md 架构速查;P8d 卡记统筹决定落地
- cargo test 413 passed / 0 failed / 6 ignored;pnpm typecheck、pnpm test 通过;三轮 10 处变异全部被杀

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 19:50:21 +09:00
lanrtop
2f2a9f10a3 fix(onboard/parity): P8d 处置独立审查——锁内重新解析登记并以根目录绑 digest、阻断项可逐项跳过、接入文件与用户改动分开报告等(P8d 审查)
All checks were successful
Push & PR Check / check (push) Successful in 1m9s
Push & PR Check / check (pull_request) Successful in 1m1s
- ① 接入写锁内重新解析登记:登记消失 failed,根目录或端口变了 refused 并附当前计划;
  计划新增 root 并进 digest;SystemOnboardHost 每次重读端口;删除登记持同一把写锁先清理
  MCP 配置再删登记(delete_project_registration 注入写锁与清理闭包);批量重注入在锁内取快照
- ② OnboardOptions.skip_targets:manual_entry / shared_key 可逐项跳过(进 digest,计划单列
  skipped),跳过的一端记 skipped、不调用适配器;身份冲突、混合文件、needs_human 仍只能中止
- ③ 报告新增 written_files;repo_changes 限定项目根,分出 onboard_files 与 other_changes,
  建议提交信息与 next_action commit 只针对接入文件
- ④ 一键接入补写 mcp_inject 事件(inject_event),诊断注入状态随之更新
- ⑤ ClientAdapter::project_config_file:codex 步本次由 project_files 写入时记 applied,blocked 文案如实
- ⑥ lefthook 保留启动错误,本地存在却起不来记 failed;⑦ git_hooks 移到写锁外
- ⑧⑨⑩ 登记 known_limits / P8e 指引 / 转统筹决定;project-context.yaml 同步(T1)
- cargo test 402 passed / 0 failed / 6 ignored;pnpm typecheck 通过;四轮变异验证

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 17:27:57 +09:00
lanrtop
57665768b1 feat(onboard/parity): onboard_project 编排本体与接入报告,apply_onboarding_pack 改 async(P8d)
- 新增 onboard/apply.rs:计划与应用共用同一份演算(本机七步 token/shim/claude/codex/dsh/
  product_group_buff/git_hooks + 项目文件);apply 依次项目级运行锁(busy)→ 预检(failed)→
  确认(refused)→ 接入写锁内重算计划核对 digest 与阻断项(refused),以上零写入;之后按依赖
  执行 identity、project_files、git_hooks、product_group_buff、token → shim → 三端适配器,
  某步失败只阻断依赖它的步骤(blocked(dep=…)),整体 partial,不自动回滚;随后 L1(未完成的
  客户端一端整列 blocked、不起进程)与 L0
- 新增 onboard/report.rs:status done/partial/failed/refused/busy,「完成」只按三端可用子集;
  repo_changes(git status --porcelain / diff --stat,非 git 为 unavailable)、HEAD 不变断言、
  建议提交信息、next_actions(Gitea 注明默认公开、CI、飞轮、工具链、lefthook、Codex 信任、
  重启 DSH GUI、Claude trust、重开已打开的会话)
- 计划单列 bypass_permissions,可按项目取消(写显式 defaultMode=default 记住选择)
- 下沉:本机七步组装、token_step/outcome_status、控制面判定、lefthook install、独立产品组建组
  移入 onboard(可注入),commands 与 mcp_inject 改为薄包装;生产入口
  mcp_inject::plan_onboarding / onboard_project 供 P8e 投影一行委托
- L1 Cell 增 dep、Cause 增 dependency(commands.ts 同步);project-context.yaml、AGENTS.md 同步
- cargo test 394 passed / 0 failed / 6 ignored;pnpm typecheck 通过;三轮变异验证

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 15:24:39 +09:00
lanrtop
a79bcb7fca chore(merge): 合并 master(含 P8f register_project)到 P4a,解决 mcp_tools.rs 与 project-context.yaml 相邻插入冲突
All checks were successful
Push & PR Check / check (push) Successful in 1m4s
Push & PR Check / check (pull_request) Successful in 1m2s
两边各自新增全局路由工具(probe_client_parity / register_project):清单插入、
is_project_scoped_tool 排除、STRUCTURED_TOOLS 与摘要分支均保留双方;契约文档合并两段说明。
合并结果 cargo test 377 passed / 0 failed / 6 ignored,pnpm typecheck 通过。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 13:48:28 +09:00
lanrtop
f0237da3c3 fix(onboard/parity): P4a 处置独立审查——超时不可被持续输出绕过、读超时归因、探针不抹 reload 证据等(P4a 审查)
独立审查 11 条发现处置(修复 agent 在分类器拦截前完成并暂存,统筹会话接手提交):
- SystemRunner 每轮按剩余时间等待,收到行也查超时;单行与 stderr 限长
- 读超时沿 error source 链按 io::ErrorKind 判定,不依赖英文子串
- probe 期间 quiet_project_initializes 守卫,探针的 initialize 不计入真实客户端
- F 格绑定真实 read_test_account 文案;Codex enabled/disabled_tools 过滤
- Claude 作用域回查 helper、Codex 项目表与生效地址不一致记 untrusted、
  helper 无 Authorization 记 auth_header_missing、Claude 未连上时 D–F 记 blocked
- init 加 --settings disableAllHooks;--mcp-config 只带 type/url/headersHelper;
  只执行托管写法 helper,其余记 unknown(manual_config)
- 改断言报备:Claude 未连上时 F 由 ready 改为 blocked(审查要求的口径),已写入卡片

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 13:40:00 +09:00
lanrtop
96cfe761f4 fix(projects/parity): 处置 P8f 独立审查——登记落库规范目录并加 canonical 键查重、恢复 UI 无目录占位、挂载仓库同事务(P8f)
- M1:Windows 目录 canonicalize 去长路径前缀后落库,register_project 回执带落库目录;
  scan_unregistered_projects 的已登记判定与父目录去重改用同一比较键
- M2:UI 添加项目不选目录时沿用既有概念占位(RootRequirement),MCP 入口仍拒绝空路径
- L1:已有登记按 platform 只取有效根目录,切换平台残留列不再误拦
- L2:新目录在写事务外另算 canonical 键,识别 8.3 短名与 .. 段
- L3:mount_repo 抽本体,重复检查前移、profile 与 workspace 同一 IMMEDIATE 事务
- L4(部分):registration_path_key 复用 normalize_dsh_root 与 strip_verbatim_prefix
- I3:目录遗留别的 project_id 的 context.json 时回执带 warning
- I4:register_project 分发抽成函数,按 schema 参数名测试
- 改动的既有断言:register_project_at 落库由「去首尾空白的原样路径」改为规范形式

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 13:15:36 +09:00
lanrtop
5b804bb967 feat(onboard/parity): L1 零模型三端检查 probe_client_parity(P4a)
All checks were successful
Push & PR Check / check (push) Successful in 1m3s
新增 onboard::probe_l1:不调用模型、零额度,按 Claude Code、Codex、DSH
各自实际生效的配置给出 A–F × 三端矩阵,每格带状态、证据等级与归因。

- 客户端自省:Claude 在项目目录 claude mcp get 取生效条目,再以坏模型名
  跑 claude -p(只挂该条目、读到 system/init 即止)取 skills/工具/连接状态;
  Codex 用 codex mcp get --json(看不到条目而项目有配置 → codex_project_untrusted);
  DSH 读托管块白名单并核对会话插件 sha256,版本读安装包 app.asar。
- 认证链重放:按客户端方式执行稳定 shim 取认证头(只在进程内使用),
  在该端配置的地址上 initialize(clientInfo=lian-jing-l1-probe)、tools/list
  (与 tools_list_result_for_project 比对)、get_diagnostics、
  list_project_dev_variables、read_project_test_account(LJ_PROBE_<nonce>)。
  归因 shim_missing / helper_failed / auth_failed / unreachable / route_global 等;
  未安装记 not_installed,控制面 Claude 与 DSH 记 not_applicable,均不计失败。
- 进程、HTTP、客户端定位经 ProcessRunner / McpHttp / ClientLocator 注入;
  ClientAdapter 新增 l1_facts;本体入口 mcp_inject::probe_client_parity。
- 投影:MCP probe_client_parity(仅全局路由,readOnly)、Tauri async command、
  commands.ts 类型与封装;mcp_server 不把 l1 探针计入真实客户端初始化。
- T1:project-context.yaml 补 MCP 工具与 Tauri command 契约;蓝图 P4a 记实现与验证。

cargo test 349 passed / 0 failed / 6 ignored;pnpm typecheck 通过;
实机冒烟 enterprise 三端 18 格 ready(1.4–1.6 秒)。

Rules-Applied: R01
Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 12:29:56 +09:00
lanrtop
0851aa9783 feat(projects/parity): register_project 控制面投影,登记本体拒绝同目录重复登记(P8f)
- projects:从 create_project 抽出登记本体 register_project_records(连接注入),
  UI create_project 与 MCP register_project 共用;只写数据库,不建目录、不执行 git init、不接入。
  拒绝空 ID、空路径、相对路径、不存在的目录、空名称、同一目录已登记、已存在的 ID;
  重复检查与插入放进同一 IMMEDIATE 事务;workspace 插入去掉 OR IGNORE,ID 冲突不再静默成功
- 同目录判定 registration_path_key:去长路径前缀、斜杠统一、合并重复分隔符、去尾部分隔符、
  不区分大小写;win_path 与 wsl_path 两列都比较,WSL Linux 路径按 wsl.localhost 换算;
  错误信息给出已有 project_id(根治 PR #34 审查 L1/L2:同目录两条登记互相抢占 Codex 托管块)
- mcp_tools:新增 register_project(path 必填、name 可选,project_id 由炼境生成 UUID,归入当前空间,
  structuredContent 返回);只开放在全局路由,is_project_scoped_tool 显式排除;描述写明须用户确认目标
- 批量添加对已登记目录计入 skipped,模板新建与挂载仓库复用同一重复目录检查
- project-context.yaml「MCP 工具接口」段同步(T1)

cargo test 335 passed / 0 failed / 5 ignored(新增 10 条),0 warning;pnpm typecheck 通过;
9 处变异全部被对应用例捕获。

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 12:29:26 +09:00
04db0983e6 Merge pull request 'feat(onboard/parity): 写入汇 WriteSink 与写入前计划 plan_onboarding,处置独立审查(P8c)' (#36) from feat/agent-client-parity-p8c into master
All checks were successful
Push & PR Check / check (push) Successful in 1m4s
2026-10-03 09:59:15 +08:00
lanrtop
479f4ac2cd fix(onboard/parity): 处置 P8c 独立审查——Codex 信任改进 next_actions、存在即跳过只判存在、token 步区分 needs_repair(P8c)
- Codex 未信任不再并入 blocked:计划新增 codex_trust 与 next_actions 字段,未信任或读不出
  Codex 配置只进 next_actions,不阻断、不进 digest;「本机步骤 → 阻断项」抽成纯函数 machine_step_blocker。
- WriteSink 新增 exists():dispatch_one 只判存在,已存在的非 UTF-8 文件(UTF-16 lefthook.yml 等)
  恢复为 skipped(修复 apply_onboarding_pack 回归);全托管文件读不出仍记 failed。
- token 步改用只读 mcp_auth_token_state 区分 Present / Missing / NeedsRepair,needs_repair 记 needs_human,
  与 get_or_create_mcp_auth_token 的分支一一对应;is_project_injected 仍只作「已接入」判据。
- Codex 信任去掉未验证的祖先目录规则,候选为项目根 + git 主仓库根(worktree 继承主仓库信任);
  键解析按 TOML 规则处理字面量键、基本字符串转义、[projects] 内联表与点号键;删掉非法 TOML 的假阳性用例。
- 写入序列只留一份:抽出 write_project_identity_files_with,inject 与 plan 共用;删除 write_project_mcp_files_with。
- digest 绑定 update 文件的写入前哈希(before_sha256),模块文档写明准确语义。
- 新增 WriteFailure,阻断项指向真正出错的文件;本机 codex 步指向 .codex/config.toml,blocked 按(target, reason)去重。

cargo test 318 passed / 0 failed / 5 ignored(新增 7 条),cargo check 0 warning;两轮变异验证均被对应用例捕获。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 10:53:41 +09:00
lanrtop
fccb76783d fix(gitea-integration): 处置 G8 独立审查——删除登记本体补外部清理测试,轮询写入前复核绑定,解绑读删同事务(G8)
All checks were successful
Push & PR Check / check (pull_request) Successful in 1m8s
- 抽出连接与凭证存储注入的删除登记本体 projects::delete_project_registration
  (delete_project_records + 提交后 Gitea 外部清理),delete_project 只做薄包装;
  补测试校验被删项目的 webhook 签名凭证被清理、他项目凭证保留,以及孤儿绑定可经删除登记清理
- 轮询 commit 与 PR 写入抽成 ingest_polled_commits / ingest_polled_prs,写入前用
  poll_target_still_bound 复核绑定仍在且项目仍登记,避免按本轮开头的旧快照写入已删除或已解绑的项目
- gitea_unlink_repo 的读与删放进同一事务,与删除登记路径同写法
- 孤儿绑定 warn 写明清理路径(对该 ID 调 unregister_project)
- 审查第 5 条(连接池外键只在迁移连接开启)经探针证伪:bundled SQLite 默认 foreign_keys=1,不改

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 10:49:26 +09:00
lanrtop
c1632a0549 fix(gitea-integration): 删除项目登记时同一事务解除 Gitea 绑定,轮询跳过已删除项目的遗留绑定(G8)
删除登记(UI 删除项目、MCP unregister_project)原来不清 gitea_repos,
后台轮询每 10 分钟仍把 commit 与 PR 事件写到已删除的项目 ID 下。

- gitea:解绑本体拆为 remove_repo_link_records(只动数据库,可进调用方事务)
  与 cleanup_removed_repo_link(提交后尽力删 Gitea 侧 webhook 与本机签名凭证),
  UI 解绑 gitea_unlink_repo 与删除登记共用
- projects:抽出 delete_project_records(连接注入),关联表、Gitea 绑定、
  workspace、孤儿 profile 同一事务删除;delete_project 提交后再做 Gitea 外部清理
- 轮询兜底:load_poll_targets 把所属项目已不存在的遗留绑定排除在 commit / PR
  轮询之外,每个绑定每次运行只记一次 warn
- 契约:unregister_project 描述与 project-context.yaml 同步

回归测试 deleting_project_registration_unbinds_its_gitea_repo 修复前失败、修复后通过;
变异验证通过;全量 cargo test 307 passed / 0 failed / 5 ignored。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 10:18:49 +09:00
lanrtop
a3d1cc169b test(onboard/parity): 补「计划即实际写入」端到端测试,修正 plan_onboarding 只读注释(P8c 收尾)
- plan_predicts_exactly_what_apply_writes:空仓库先 plan 再经 DiskSink apply,逐文件比对计划内容哈希与
  实际写入,并核对 git status 的文件集合与计划一致。P8d 的 digest 复核依赖这条不变式;
  变异 PlanSink::read 忽略待写内容时,原有 plan 端到端测试仍通过,只有本测试与记录汇单元测试失败。
- mcp_inject::plan_onboarding 注释由「不起子进程」改为「不起客户端 CLI,混合文件预警会起只读 git」,
  与 has_uncommitted_outside_managed 的实际行为一致。

cargo test 311 passed / 0 failed / 5 ignored。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 10:08:43 +09:00
lanrtop
ea8ed26191 chore(merge): 合并 master(PR #34 重复登记修复 U1/U2)到 P8c 分支
自动合并,无冲突(mcp_inject.rs、commands/onboarding.rs、mcp_tools.rs 双方改动区域不重叠)。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 09:58:15 +09:00
lanrtop
ef2c7fd593 feat(onboard/parity): 写入汇 WriteSink 与写入前计划 plan_onboarding(P8c,待独立审查)
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
一键接入改写子项目受版本管理的文件,人在确认前必须看得到改什么;计划与 apply 走同一段
分发代码、只换写入汇,所以「看到的」就是「将写的」。

- lib.rs:WriteSink trait(read/write,内容忽略行尾未变不写)与 DiskSink
- 接入包模板分发、蓝图规则同步、项目身份与 MCP 投影(context、settings 兼容条目、
  liangjing、Codex 托管块)全部改经写入汇;原入口改为 DiskSink 薄包装,行为不变
- onboard/plan.rs:PlanSink 只记录不落盘、后续步骤读到前面步骤的待写内容;
  write_project_files 为 plan 与 apply 共用的写入序列;plan_onboarding 给出逐文件
  create/update/noop、有上限的 diff、混合文件预警(P10 前移到写入前)、身份冲突、
  手写条目与共享项目键阻断项,并对计划算 digest
- mcp_inject:plan_onboarding 生产入口与本机侧预计动作(token、稳定入口、三端只读
  状态、Codex 信任),只读、不起子进程
- 新增测试:空仓库全 create 且目录快照字节不变、apply 后两次计划全 noop 且 digest
  相同、CRLF 判 noop、内容/本机状态变化 digest 变化、混合文件与身份冲突阻断、
  手写 Codex 条目与共享键阻断、记录汇覆盖与撤销、diff 截断、Codex 信任解析;
  cargo test 307 passed

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 09:35:24 +09:00
lanrtop
e57da3aebb fix(mcp-single-server): 删除登记只清本项目托管条目,沉默项目统计每条 commit 只归属一个 workspace,注入状态带项目名(U1、U2)
All checks were successful
Push & PR Check / check (push) Successful in 1m34s
Push & PR Check / check (pull_request) Successful in 1m1s
同路径重复登记(dev-manager-tauri 与 2c5b54ef 并存)暴露的三处问题:
- remove_project_files_mcp 按路径解析目录后无条件删 Codex 管理块与 settings 条目,
  删 UUID 那条会连带切断规范 ID 的 Codex 接入;改为只删 URL 属于本 project_id
  或不是炼境项目路由(旧格式)的条目
- silent_projects 的「ID 或路径」任一匹配让一行吃到多条登记的并集(真机 147 / 86),
  改为每条 commit 先按直接 ID、再按 buff 路径归属唯一 workspace
- get_diagnostics 注入状态只打 ID,enterprise-system 的 UUID 被误读成炼境重复登记;
  改为「名称 (`id`)」,已删除的登记标注未登记

Rules-Applied: R06,R07

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 09:22:25 +09:00
lanrtop
59f2c9d5fb fix(onboard/parity): P8b 审查修复——未装记 not_installed、手写保留留痕、成功日志后移、只读判定误判(P8b 审查)
All checks were successful
Push & PR Check / check (push) Successful in 1m0s
Push & PR Check / check (pull_request) Successful in 1m3s
独立审查 agent 只读审查 d1b9b05(未发现死锁、重入或崩溃),十条发现处置:

- Claude apply:无全局配置且找不到 CLI 记 not_installed,与 DSH、static 同口径
- 手写条目保留(manual_kept)时补日志:DSH 照原文案,Codex 带 project_id
- 「MCP 配置注入成功」移到三端收敛之后,Codex 失败时改记 warn「注入失败」,
  诊断不再把失败显示成成功
- 控制面 Claude 静态判定:遮蔽全局注册的残留 local 条目报 missing
- 嵌套项目:根目录是 git 根时只认等于根目录的键,否则取最具体的键
- 适应度测试改为递归;registry() 注明适配器暂寄 mcp_inject 的传递依赖
- 状态名对齐设计:skipped 改为 not_applicable{control_plane|wsl} 与 deferred
- 只读判定:读失败与 YAML 解析失败报 unavailable,Codex 块与手写同名表并存、
  标记错序报 needs_human,DSH 块外手写报 manual_kept;client_static_status 改用
  与注入同源的 project_root
- 修正「目录不存在」假阳性用例,补 hard_failure、inject 回执、apply 映射、
  clients 不影响 pass 的测试;cargo test 300 passed,两处变异验证失败如期

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 08:52:25 +09:00
lanrtop
d1b9b0564e feat(onboard/parity): 客户端适配器注册表与三端结构化注入结果,onboard 模块投影无关适应度测试(P8b、A1a)
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
Push & PR Check / check (pull_request) Successful in 59s
一键接入(P8)编排前置:Claude local 与 DSH 托管块的成败原来只写日志,inject_mcp
笼统回「已配置 Codex 与 Claude」,失败会被报成成功(R4)。

- 新增 src-tauri/src/onboard/:ClientId、ClientOutcome(converged/applied/refreshed/
  removed/manual_kept/other_project/not_installed/skipped/missing/unavailable/
  needs_human/failed)、ClientAdapter(detect/static_status/apply)与 registry();
  适应度测试 onboard_module_is_projection_free 机器校验本体不依赖投影层
- 三端适配器实现在 mcp_inject,注册表反向接入;注入经 registry() 逐端 apply,
  新增 inject_project_mcp_report,inject_project_mcp 签名与「Codex 失败即整体失败」
  语义不变
- sync_claude_local / ensure_dsh_patch 抽出依赖注入版,每条分支返回结构化结果,
  日志类别与文案不变;upsert_codex_mcp_config 返回 converged/applied/manual_kept
- verify_onboarding(MCP)附加 clients 只读三端状态,不计入 checks、不影响 pass;
  inject_mcp 回执逐端列出实际结果
- 行为变化(有意):Codex 手写同名 server 改记 manual_kept 不再阻断 Claude/DSH;
  WSL 项目 Claude local 记 skipped 不再起 CLI
- 新增 9 条测试(假 CLI 覆盖 Claude 全部分支、临时 DSH 目录四态);cargo test
  295 passed;契约同步 project-context.yaml,AGENTS.md 架构速查补 onboard/

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 08:25:04 +09:00
lanrtop
8230910358 fix(mcp-inject): 「已接入」统一为有项目 token 单一判定,批量重注入补上独立接入项目(P8a)
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
「已接入」原有三套判定:reinject_all_mcp 按产品组成员、DSH 白名单与根目录迁移按
项目 token、list_all_projects 按 .claude/liangjing.json 是否存在。结果是独立接入
(不在任何组)的项目在端口变更后不会被重注入,list_all_projects 对只剩兼容文件的
项目误报「已注入」。

- 新增 mcp_inject::is_project_injected(store, project_id),DSH 白名单、
  on_project_root_changed、list_all_projects 统一调用
- reinject_all_mcp 目标改为「组成员 ∪ 有 token 的登记项目」(reinject_targets),
  锁内复查改为 is_reinject_target,token 先被删的项目不再注入(语义不变)
- list_all_projects 拆出 render_all_projects(conn, store),去掉循环内二次取池
- 新增两条测试,变异确认会失败;契约同步 project-context.yaml;蓝图 P8a 标 ✅

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 07:44:04 +09:00
lanrtop
44f7f667a6 fix(blueprint-buff): 跟进维护既有蓝图内容也算归属已显式,不再按 files 重叠误标(B2)
All checks were successful
Push & PR Check / check (push) Successful in 1m1s
2026-10-03 主仓库快进到 19b9388(PR #31 只补记 ✅ P7 的 known_limits,无标题
变化)后,P6/P8(onboarding.rs)与 A4(mcp_server.rs)再次被误标 🔵:B1 只把
「新增 🔵/✅/🔴 标题行」当显式推进,跟进已完成卡被判为无推进而走兜底。

- infer_task_marks 增加 edits_existing_lines:本批 .blueprint/modules patch 在
  hunk 内有 `-` 行(删改既有内容)即视为 agent 在维护蓝图,不推断
- 纯追加(新立 📋 卡、新模块)仍走兜底,保留「立卡即实现、忘了加锁」的捕获
- 新增单测与端到端 ⑧⑨;变异(去掉条件)确认 ⑧ 失败;回放 master 260 批次,
  B2 新增抑制 27 批,含代码改动 6 批
- 蓝图 blueprint-buff 立 B2 卡并标 ✅

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 07:30:38 +09:00
lanrtop
df5832f41b fix(delivery/mcp): 补 get_delivery_status 经 scoped dispatch 转发 pr_number/branch 的回归测试(P3-F 审查)
All checks were successful
Push & PR Check / check (push) Successful in 59s
Push & PR Check / check (pull_request) Successful in 1m2s
使者回传 #203 的症状是「传 pr_number 也不起作用」,但原有 MCP 层测试只覆盖非法参数报错,
dispatch 若丢弃已解析的查询目标、改传默认值,全部测试仍通过。新增 scoped dispatch 正向测试,
断言 pr_number/branch/null 分别得到 pull_request/branch/local_branch 目标;已用变异
(dispatch 改传 DeliveryQuery::default())确认该测试会失败。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 06:34:06 +09:00
lanrtop
1e3989d0d7 feat(delivery/mcp): get_delivery_status 支持按 pr_number/branch 查询,结论绑定 Gitea head SHA(使者回传 #203)
All checks were successful
Push & PR Check / check (push) Successful in 1m0s
Push & PR Check / check (pull_request) Successful in 1m2s
Enterprise 2026-10-03 实测:为避开主工作区里其他会话的在制品,在独立 worktree
分支上开 PR 交付时,get_delivery_status 只读主工作区当前分支,返回「当前分支没有
开放 PR」、CI 停在主工作区 HEAD,传 pr_number 也被忽略,只能用 git ls-remote 与
get_ci_status(commit_sha) 兜底。

- MCP schema 新增可选 pr_number(优先)与 branch;都不给时保持原行为
- pr_number:GET /pulls/{n} 取 head 分支与 head SHA,CI 与 review 均绑定该 PR;
  PR 不存在(404)返回 not_found,与 Gitea 不可达(unavailable)区分;
  同时传 branch 且与 PR head 分支不一致时以 pr_number 为准并在 detail 提示
- branch:匹配该分支的开放 PR 并以其 head SHA 查 CI;无开放 PR 时取 Gitea 上
  该分支 head SHA;远端分支不存在时 CI 为 unknown
- 顶层新增 target(mode/pr_number/branch/head_sha/source/detail),
  pull_request.data 增 head_sha;git 字段仍反映主工作区,既有字段兼容
- 取值校验在能力本体 DeliveryQuery 单点实现,MCP 只解析 JSON 类型;显式给出的
  非法值直接报错,不静默回退主工作区
- Gitea 读取拆为本地/PR/分支三种目标,凭证存储注入以便合成 Gitea 测试;
  merge_pull_request 门禁代码未改
- lian-jing skill 第 6 条改为 get_delivery_status(project_id, pr_number),
  base-onboarding 1.8.0→1.9.0(BASE_ONBOARDING_PACK_VERSION、模板
  capability-packs.json、TEMPLATE_FINGERPRINTS);Codex 插件 skill 同步
- 契约说明同步 docs/ai-context/project-context.yaml;蓝图 P3-F 标 ✅

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 06:22:09 +09:00
lanrtop
32e947b622 fix(onboarding/parity): lian-jing skill 免确认例外补列 register_project_dev_variable,第 8 条开发变量改用对应登记工具(P7 审查修复)
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
Push & PR Check / check (pull_request) Successful in 59s
服务器说明 MCP_SERVER_INSTRUCTIONS 的免确认例外是泛称「不含秘密的开发需求元数据」,
register_project_test_account 与 register_project_dev_variable 都属于;skill 新增的
通用边界括注只列了前者,开发变量登记会被误读为须用户确认的「其他写操作」。同源旧
问题:skill 第 8 条把「开发变量(沙箱 key 等)」也只指向 register_project_test_account。

- skill 例外括注同时列出两个登记工具
- 第 8 条拆分:测试账号用 register_project_test_account 登记名称、目标系统、非生产
  环境与用途;开发变量用 register_project_dev_variable 登记名称与用途
- base-onboarding 1.8.0 尚未发布,不再升版本,仅更新 TEMPLATE_FINGERPRINTS 摘要
- server_instruction_universal_rules_are_in_skill 加断言:服务器说明含「开发需求元
  数据」,skill 写操作确认规则所在行同时含该泛称与两个登记工具名
- 蓝图 P7 known_limits 把「措辞与服务器说明一致」精确为「两条规则核心句逐字一致」,
  并记录本次例外与第 8 条的修正

测试:cargo test --locked 全量通过(lib 273 passed / 5 ignored,0 failed)。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 05:43:32 +09:00
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
Push & PR Check / check (pull_request) Successful in 1m0s
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
c9b951dd30 fix(onboarding/parity): 混合文件预警收窄空白归一、失败时不丢预警、测住改写判断(P10 审查修复)
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
Push & PR Check / check (pull_request) Successful in 1m5s
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
Push & PR Check / check (pull_request) Successful in 59s
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
7595c37d22 test(onboarding): 托管模板指纹测试,改内容未升版本即失败
All checks were successful
Push & PR Check / check (push) Successful in 1m3s
全托管文件(envoy.md / SKILL.md)按内容覆盖,但 verify_onboarding 只凭
capability-packs.json 版本判落后——只改内容忘升 BASE_ONBOARDING_PACK_VERSION
时 verify 永远 ready,子项目收不到更新。升版规则此前只有文档约束。

- 新增 managed_template_fingerprints_track_versions:「版本号 → 摘要」登记表
  TEMPLATE_FINGERPRINTS 钉住 resources/onboarding/**(↔ BASE 版本)与
  AGENTS / git-workflow 管理块(↔ 块首 version);摘要前 CRLF→LF 归一化
- capability-packs.json 与 BASE 相等复用既有断言,补可读报错
- onboarding-sync.md 说明该测试

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 01:49:36 +09:00
lanrtop
3095df3d2a feat(mcp/envoy): 使者回传闭环——回执 + 三端回传入口
回传只进不出:list_envoy_returns 无处置状态、LIMIT 50 把更早的回传静默挤掉;
入口只有 Claude /envoy,08-23 后 enterprise 主力转 DSH/Codex 即零回传。

- envoy.rs 业务本体(连接注入)+ envoy_dispositions 回执表(migrate 补表)
- report_envoy_return(项目级,Claude/Codex/DSH 在项目地址均可用):字段枚举校验、
  内容压单行限长、兜底拒绝明显凭据;同项目 1 天内同内容未处置幂等返回原编号
  (IMMEDIATE 事务防并发重复);复用 append_project_note 的档案双写
- resolve_envoy_return(控制面):landed/carded 必填落点、reason 必填、允许更正
- list_envoy_returns 默认只列未处置(带编号),附已处置计数,超出展示上限明说;
  LEFT JOIN 不再丢掉登记已删项目的回传;include_resolved 可审计回执
- lian-jing skill 新增「遇到摩擦时回传炼境」;/envoy 改为指向该入口的薄指引
  (保留扫描与分类硬门槛,炼境分发物出错免门槛,身份改读 .lian-jing/context.json);
  AGENTS 托管块加一行指路(1.9.0→1.10.0),能力包 base-onboarding 1.6.0→1.7.0
- 删除炼境仓库内 Codex 迁移遗留的 source-command-envoy 技能(读旧身份文件、走旧写入路径)
- 契约与架构文档同步:project-context.yaml、project-brief.md、AGENTS.md、agents-meta-rules.md

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

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 01:15:40 +09:00
9da19cecaa Merge pull request 'feat(blueprint/buff): files 重叠推断降为兜底,同批已有显式推进则不推断' (#27) from feat/blueprint-buff into master
All checks were successful
Push & PR Check / check (push) Successful in 1m2s
2026-10-02 18:40:52 +08:00
lanrtop
4a37438a58 fix(credential): 修复并行测试偶发失败——Credential Manager 调用串行化,模拟 Gitea 改阻塞读
All checks were successful
Push & PR Check / check (push) Successful in 1m29s
全量并行 cargo test 10 次失败 3 次(单跑稳定通过),两个独立根因:

- 同进程并发 CredWriteW/CredDeleteW 会丢更新:写入并校验成功的凭据随后读回 NOT_FOUND,
  删除成功的条目又被并发写回。R10 readiness 报 needs_repair、开发变量试点报「凭证引用缺失」
  均源于此(诊断日志证实无跨测试删除;8 线程压力实验直接复现)。windows_store 的
  put/get/delete 经进程级锁串行,生产中 MCP 与 UI 并发写凭据同样受益;跨进程不在保护范围
- Windows 上从 nonblocking listener accept 的 socket 继承 nonblocking,set_read_timeout
  不生效,请求晚到即 WouldBlock。mcp_server 两处模拟 Gitea 补 set_nonblocking(false),
  与 commands/gitea.rs 既有写法一致

验证:修复后全量并行 cargo test 连续 30 次 0 失败(247 passed、5 ignored)。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 18:52:05 +09:00
lanrtop
b7987e160f feat(blueprint/buff): files 重叠推断降为兜底,同批已有显式推进则不推断
两阶段锁下真正在做的卡提交落地时已是 🔵/✅,files 重叠只能碰到仍为 📋 的卡,
命中共享热点文件(mcp_tools.rs / onboarding.rs 等)的多是未开工卡。
回放 master 240 个 first-parent 提交:旧算法命中 50 次,明确正确仅 3 次;
新规则 50 → 5,PR #24/#25/#26 对 P6/P7/P8/A4 的误标全部消除。

- 本批蓝图 diff 新增 🔵/✅/🔴 标题行(非原样搬移)→ 归属已显式,不做 files 推断
- last_commit 非 HEAD 祖先(checkout/reset/rebase)→ 跳过;git 出错记日志
- 同一批次全程使用轮询读到的 HEAD sha,判定口径一致
- 匹配修正:去掉反向后缀、后缀须落在 / 边界、尾逗号空项丢弃、「、」「,」作分隔
- 蓝图同步提示词:核实仅共用文件的 🔵 可降回 📋 并写明原因
- 补 buff.rs 首批测试(纯函数 + 临时 git 仓库端到端)

Rules-Applied: R09
Feature-Confirmed: true

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 18:49:56 +09:00
lanrtop
fe0458fe97 fix(mcp/parity): P9 审查修复——受限子代理不挂载、条目 id 带版本、插件缺失守卫、规范路径键
All checks were successful
Push & PR Check / check (push) Successful in 1m6s
Push & PR Check / check (pull_request) Successful in 1m4s
对抗审查(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
对抗审查(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
Push & PR Check / check (pull_request) Successful in 1m2s
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
Push & PR Check / check (pull_request) Successful in 1m5s
对抗审查(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
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
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
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
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
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
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
lanrtop
f4e75dc91f feat(onboarding): lian-jing skill 双投影到 Claude,接入包升至 1.6.0
All checks were successful
Push & PR Check / check (push) Successful in 1m4s
- 同一模板同时写 .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
663a723b3b feat(dev-variables): 修改时显式查看原值,并提示 agent 先查炼境测试账户
All checks were successful
Push & PR Check / check (push) Successful in 1m5s
Push & PR Check / check (pull_request) Successful in 1m9s
- V12:新增人用 Tauri command reveal_project_dev_variable(不进 MCP),
  点「修改」预填原账号与密码,密码默认遮罩可切换显示
- V13:lian-jing skill 新增第 8 步——需要测试账号先 list/read,
  没有则登记并请用户在 UI 填写;禁止对话索要明文;base-onboarding 升至 1.5.0
- 契约同步 project-context.yaml;materialize 提案顺延为 V14–V16

Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 14:22:54 +09:00
lanrtop
9211883a9b test(dev-variables/mcp): 以隔离宿主完成 V7 真实 Codex 跨会话试点
All checks were successful
Push & PR Check / check (push) Successful in 1m7s
Push & PR Check / check (pull_request) Successful in 1m5s
新增 ignored 宿主 isolated_dev_variables_client_pilot:内存 DB + 随机合成账户 +
临时 scoped MCP,认证走真实 helper。真实 Codex CLI 三会话完成登记→代填→跨会话
读取→撤销后读取失败,宿主断言目录无 .env/token/密码且凭据清理。

Rules-Applied: R03,R05,R10,R13
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 12:42:44 +09:00
lanrtop
d926591ace feat(dev-variables/ui): 一张卡填写测试账号和密码
项目面板一次提交两个字段到同一 Tauri 本体,列表与 React Query 仅保留非秘密状态。

Rules-Applied: R01,R08

Feature-Confirmed: true
2026-09-28 01:45:49 +09:00
lanrtop
1daef98af3 feat(dev-variables/mcp): 提供项目级测试账户登记与认证读取
scoped MCP 只登记非秘密元数据;读取共用 bearer 门槛,并以真实本机 HTTP 合成链路覆盖授权、复用和撤销。

Rules-Applied: R07,R10

Feature-Confirmed: true
2026-09-28 01:45:23 +09:00