209 Commits

Author	SHA1	Message	Date
lanrtop	cf0f5b6a64	docs(blueprint/agent-client-parity): P8f 开工标 🔵（P8f） ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 12:11:14 +09:00
lanrtop	9dd0545456	docs(blueprint): P8c 与 G8 合并后验收标 ✅，P8d acceptance 并入 P8c 审查转入项（bypass_permissions 单列与七步本机变更），派 P4a ... PR #36（P8c）与 PR #35（G8）合并为 04db098，合并结果全量 cargo test 325 passed； 两卡 acceptance 均为 cargo 层。P8c 审查 ⑨ 转入项按统筹决定写进 P8d acceptance ⑨， 避免 P8g 视图拿不到计划数据。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 11:05:03 +09:00
lanrtop	04db0983e6	Merge pull request 'feat(onboard/parity): 写入汇 WriteSink 与写入前计划 plan_onboarding，处置独立审查（P8c）' (#36) from feat/agent-client-parity-p8c into master	2026-10-03 09:59:15 +08:00
lanrtop	8b9ae81f78	Merge pull request 'fix(gitea-integration): 删除项目登记时一并解除 Gitea 绑定，轮询不再写入已删除或已解绑的项目（G8）' (#35) from fix/gitea-unbind-on-unregister into master	2026-10-03 09:59:07 +08:00
lanrtop	7ef924127a	docs(blueprint/agent-client-parity): P8c 补审查处置与 known_limits，P8d 记审查转入项（P8c） ... - review：独立审查 9 条发现逐条处置（7 条已修并补测试，2 条信息项转入 known_limits / P8d）。 - 自查条目「任一目标文件变化 digest 就变 ✅」改为准确语义（只绑定计划会写入或核对的文件， update 另绑定写入前哈希）；按纪律报备：改的是验收表述，断言只增不减。 - known_limits：onboard 反向依赖投影层（过渡态）、Codex 信任静态预判的边界、shim unavailable 不阻断、 bypassPermissions 未单列、plan_machine_steps 组装未单测。 - P8d 卡新增「审查转入」：bypass_permissions 单列、machine_changes 补产品组与 buff、.git/hooks，待统筹决定是否并入 acceptance。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 10:54:04 +09:00
lanrtop	fccb76783d	fix(gitea-integration): 处置 G8 独立审查——删除登记本体补外部清理测试，轮询写入前复核绑定，解绑读删同事务（G8） ... - 抽出连接与凭证存储注入的删除登记本体 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	91017b6813	docs(blueprint/mcp-single-server): U3 存量合并完成，同路径重复登记遗留清理完毕，模块标 done（U3） ... 2c5b54ef 的 commit / 笔记 / PR 事件 / 待办并入 dev-manager-tauri 后删除登记； 全库无残留，诊断覆盖率只剩一行，verify_onboarding 与操作前一致。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 10:25:34 +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	04a0069363	docs(blueprint/agent-client-parity): P8c 标 🔵，补实现、验证、自查与有意偏差（P8c） ... - 实现：WriteSink/DiskSink、三处分发改经写入汇、onboard/plan.rs 记录汇与计划/digest、 mcp_inject 本机侧预计动作；合并 master（PR #34）自动合并无冲突。 - 验证：合并后 cargo test 310 passed，补测试后 311 passed / 0 failed / 5 ignored；变异记录。 - 自查：acceptance 逐条对照；有意偏差为计划阶段完全不起 claude CLI（比「假 CLI 只收到 mcp get」更严）、 文件动作只有 create/update/noop、DiskSink 读失败报错不覆盖。 - 自查发现留待独立审查：非 UTF-8 已存在文件由 skipped 变 failed；bypassPermissions 未在计划单列； Codex 信任解析不识别基本字符串转义段头。T1：plan_onboarding 尚无投影，project-context.yaml 由 P8e 补。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 10:09:04 +09:00
lanrtop	5f74a5644e	docs(blueprint/gitea-integration): 立 G8 卡并标 🔵——删除项目登记时一并解除 Gitea 绑定 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 10:02:44 +09:00
lanrtop	e57da3aebb	fix(mcp-single-server): 删除登记只清本项目托管条目，沉默项目统计每条 commit 只归属一个 workspace，注入状态带项目名（U1、U2） ... 同路径重复登记（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	a85f3d9bd0	docs(blueprint/agent-client-parity): P8b 合并后在运行中的炼境实测通过，标 ✅ ... PR #33（ddd729c）合并、tauri dev 重编译生效后：verify_onboarding(enterprise) 的 clients 三端均 converged；连续两次 inject_mcp 回执三端均「已一致（未改动）」， 耗时 26 ms、112 ms，四个项目文件 mtime 不变，git status 前后均干净。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 09:01:35 +09:00
lanrtop	59f2c9d5fb	fix(onboard/parity): P8b 审查修复——未装记 not_installed、手写保留留痕、成功日志后移、只读判定误判（P8b 审查） ... 独立审查 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） ... 一键接入（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	a6addc754d	docs(blueprint/agent-client-parity): P4-0 探针前置实测六项假设出结论，脱敏夹具入库（P4-0） ... 零凭据实测（全部连本地桩服务）Claude Code 2.1.173、codex-cli 0.155.0-alpha.9.2、 DSH 桌面版内置运行时，结论均未推翻 P8 设计： - H-P8-1：Codex 只在目录受信任时加载项目 .codex/config.toml（隔离 CODEX_HOME 对照），codex mcp get --json 零模型反映「项目配置 + 信任」，可作 L1 自省 - H-P8-2：项目 bypassPermissions 下单加 --allowedTools 不限制（R8 证实）；L3 收窄 组合定为 --permission-mode default --tools Skill --allowedTools <只读工具> Skill - H-P8-3：codex exec 下 readOnlyHint 工具在 -s read-only 可调，其余报需审批 - H-P8-4：claude -p 用不存在的模型名 3 秒内先发 init（MCP 状态、工具、skills）， 费用与 token 为 0，Claude 的 B、C 可并入 L1 - H-P8-5：75 秒的 MCP 工具调用 Codex 未超时 - H-P8-6：DSH headless --json 含 tool_call/tool_result 事件 - 夹具 10 个，用户路径、会话 ID、UUID 换占位符，长文本截断，无凭据 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 08:01:50 +09:00
lanrtop	8230910358	fix(mcp-inject): 「已接入」统一为有项目 token 单一判定，批量重注入补上独立接入项目（P8a） ... 「已接入」原有三套判定：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	f8dc95c6ee	docs(blueprint/agent-client-parity): P8 一键接入设计定稿，拆为 P8-0、P8a–P8g 与 P4-0、P4a–P4e，A1 改写为三段（P8-0） ... 三角度方案（最小编排 / 收敛流水线 / 本体收口）并行设计 + 综合评审，设计文档入库 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>	2026-10-03 07:35:53 +09:00
lanrtop	44f7f667a6	fix(blueprint-buff): 跟进维护既有蓝图内容也算归属已显式，不再按 files 重叠误标（B2） ... 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	1e3989d0d7	feat(delivery/mcp): get_delivery_status 支持按 pr_number/branch 查询，结论绑定 Gitea head SHA（使者回传 #203） ... 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	d8ba9dbf40	docs(blueprint/delivery): 立卡 P3-F get_delivery_status 按 PR／分支查询（使者回传 #203） ... Enterprise 2026-10-03 实测：在独立 worktree 分支开 PR 交付时，get_delivery_status 只读主工作区当前分支，PR/CI 结论与目标 PR 脱节。本卡开始执行，标 🔵。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 06:09:25 +09:00
lanrtop	32e947b622	fix(onboarding/parity): lian-jing skill 免确认例外补列 register_project_dev_variable，第 8 条开发变量改用对应登记工具（P7 审查修复） ... 服务器说明 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 ... 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 引导 ... 三端无头探针（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 审查修复） ... 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） ... 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	dd2d7ca369	docs(blueprint/governance-feedback-loop): 缺口①按代理终验收口标 ✅，记录 enterprise #181 合并 ... 用户委托检查会话代为终验：无摩擦不误报、DSH 0.2 可加载 skill 已实测；主动回传转运行期观察，由 B4 沉默项目信号兜底。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 03:32:06 +09:00
lanrtop	82a8530ad7	docs(blueprint/governance-feedback-loop): 缺口①更正 DSH 技能加载结论，记录代理终验与 enterprise 入库 PR ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 02:51:37 +09:00
lanrtop	b5671eed28	docs(blueprint/governance-feedback-loop): 缺口①记录 enterprise 接入包分发与 DSH 技能路径发现，待人终验 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 02:16:08 +09:00
lanrtop	b73d361413	docs(blueprint/governance-feedback-loop): 记录 59 条回传补录的独立复核与用户裁决——carded/watching 接受现状 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 02:05:50 +09:00
lanrtop	151d7adb20	docs(blueprint/governance-feedback-loop): 缺口①上线实证——三端探针通过、59 条历史回传补录清零，待人终验 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 01:55:11 +09:00
lanrtop	7595c37d22	test(onboarding): 托管模板指纹测试，改内容未升版本即失败 ... 全托管文件（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	c6ebc2d775	docs(blueprint/governance-feedback-loop): 缺口① 立卡使者回传闭环，记录实现、审查与自验，进行中 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-03 01:16:12 +09:00
lanrtop	b537847db7	docs(blueprint/blueprint-buff): B1 终验通过，标记完成 ... PR #27 合并后主仓库拉取，buff 处理含共享文件改动的提交批次，无任何卡片被误标 🔵。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-02 20:03:55 +09:00
lanrtop	9da19cecaa	Merge pull request 'feat(blueprint/buff): files 重叠推断降为兜底，同批已有显式推进则不推断' (#27) from feat/blueprint-buff into master	2026-10-02 18:40:52 +08:00
lanrtop	1778ca21d9	docs(blueprint/blueprint-buff): B1 记录实现与自验证据，挂触发条目结案，待人终验 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-02 18:52:24 +09:00
lanrtop	4a37438a58	fix(credential): 修复并行测试偶发失败——Credential Manager 调用串行化，模拟 Gitea 改阻塞读 ... 全量并行 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	ae6de1d324	docs(blueprint/blueprint-buff): 立卡 B1 files 重叠推断降为兜底，进行中 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-02 18:32:02 +09:00
lanrtop	f8d658b790	docs(blueprint/agent-client-parity): P9 人终验通过，标记完成 ... 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 带版本、插件缺失守卫、规范路径键 ... 对抗审查（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 与生成文件同内容不重写 ... 对抗审查（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 副本逻辑 ... 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 按目录路由 ... 对抗审查（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 为准的方案 ... 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	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	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