docs(blueprint): P8e、P8f 端到端实测通过标 ✅，P8 卡记录新登记项目一键接入与收敛证据

新登记临时项目 register_project → plan_onboarding → onboard_project(confirmed) 得 done，
三端可用子集全部就绪（Codex 列待用户信任目录单列 pending_user），再次执行 9 步全收敛、
文件 mtime 不变。enterprise 主工作区落后 origin/main，计划如实显示 update 3，不对其 apply。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.blueprint/manifest.yaml

@@ -511,9 +511,9 @@ modules:
     name: 三端客户端对等
     area: infra
     status: in_progress
-    progress: 61
+    progress: 70
     updated: 2026-10-03
-    note: "P1/P2/P3/P3b/P7/P9/P10 完成：三端（Claude Code、Codex 含 Desktop、DSH 含桌面 GUI）在 Enterprise 经 %USERPROFILE%\\.lian-jing 稳定入口连项目专用地址，人终验通过。Claude 条目经 claude CLI 写入、以 claude mcp get 为准；DSH 由托管块全局行（headless）+ 会话级插件（GUI/web/acp 按会话工作目录）路由；接入写入幂等；接入包改写块外带未提交改动的托管块文件时给出混合文件预警；P7 实测 MCP 服务器说明仅 Claude/DSH 带入模型上下文、Codex 不带，引导提示保留在 skill。2026-10-03 P8 一键接入设计定稿（docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md）：A1 不前置；P4 分 L0 静态 / L1 零模型 / L3 无头会话，P8 只依赖 L1（P4a）；拆为 P8-0、P8a–P8g 与 P4-0、P4a–P4e（P8-0、P8a、P4-0 已完成，P8b 适配器注册表与三端结构化注入结果（PR #33，enterprise 实测两次注入三端 converged、零写入）、P8c 写入汇与写入前计划（PR #36）、P4a L1 零模型三端检查（PR #38，enterprise 三端 18 格 ready）、P8d 编排本体（PR #39）已完成，P8f 已合并待链路实测；P8a 把「已接入」统一为有项目 token；P4-0 实测六项假设，Codex 只在目录受信任时加载项目配置、Claude 用无效模型名可零额度取 init 并入 L1），P8 进行中；进度按拆分后卡数重算。待做 P5、P6（基于 P8c 的 WriteSink）。"
+    note: "P1/P2/P3/P3b/P7/P9/P10 完成：三端（Claude Code、Codex 含 Desktop、DSH 含桌面 GUI）在 Enterprise 经 %USERPROFILE%\\.lian-jing 稳定入口连项目专用地址，人终验通过。Claude 条目经 claude CLI 写入、以 claude mcp get 为准；DSH 由托管块全局行（headless）+ 会话级插件（GUI/web/acp 按会话工作目录）路由；接入写入幂等；接入包改写块外带未提交改动的托管块文件时给出混合文件预警；P7 实测 MCP 服务器说明仅 Claude/DSH 带入模型上下文、Codex 不带，引导提示保留在 skill。2026-10-03 P8 一键接入设计定稿（docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md）：A1 不前置；P4 分 L0 静态 / L1 零模型 / L3 无头会话，P8 只依赖 L1（P4a）；拆为 P8-0、P8a–P8g 与 P4-0、P4a–P4e（P8-0、P8a、P4-0 已完成，P8b 适配器注册表与三端结构化注入结果（PR #33，enterprise 实测两次注入三端 converged、零写入）、P8c 写入汇与写入前计划（PR #36）、P4a L1 零模型三端检查（PR #38，enterprise 三端 18 格 ready）、P8d 编排本体（PR #39）、P8e 投影（PR #40）、P8f register_project（PR #37）已完成，端到端：新登记项目 plan→onboard_project done、重复执行全收敛；P8a 把「已接入」统一为有项目 token；P4-0 实测六项假设，Codex 只在目录受信任时加载项目配置、Claude 用无效模型名可零额度取 init 并入 L1），P8 进行中；进度按拆分后卡数重算。待做 P5、P6（基于 P8c 的 WriteSink）。"
     position: [3500, 950]
 
   - id: architecture-evolution

.blueprint/modules/agent-client-parity.md

@@ -224,6 +224,7 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 - 决策（Q2–Q11 均采纳推荐项）：写入前预览走 plan → digest 确认 → apply；bypassPermissions 默认值保持现状但在 plan 与报告中单列、可按项目取消；Codex 信任列入 next_actions，炼境不写 ~/.codex 信任表；L3 只在显式触发时跑，建议在 canary（enterprise）项目、指纹变化时跑；做 register_project 的全局路由投影；A4 先于 P4b；CLI 只做 pnpm probe:clients 薄脚本；A1 改写为三段；探针默认用各客户端默认模型。
 - 非目标：不自动 commit/push；不自动建 Gitea 仓库、webhook、CI，不自动装工具链（只列 next_actions，Gitea 一项注明「工具默认建公开仓库」）；不改客户端全局安全设置，不覆盖手写同名 MCP 配置；L3 不作接入门槛、不作 CI 闸门；不做离线 CLI 写入，不拆 core crate；P8 不改接入包模板；批量登记不自动接入。
 - 为什么：2026-10-01 Enterprise 验收时，接入散落在 inject_mcp、apply_onboarding_pack、verify_onboarding 与手工探针多个步骤。按「分发 vs 查询」：随仓库走的文件由炼境分发一次、按版本升级；与机器相关的客户端注册由炼境在本机维护、不进仓库；易变信息走 MCP 查询。默认三端都接入（成本小，保留随时换客户端的能力）；能用标准的不做专门适配（Codex、DSH 原生读 AGENTS.md 与 .agents/skills，只有 Claude 需要 CLAUDE.md 与 .claude/skills 投影）；炼境离线时规则与 skill 仍可用。
+- e2e_verify: "2026-10-03 22:5x 统筹会话端到端（炼境 d7f4816 重编译后经全局 MCP）：新建临时 git 仓库 E:code-projectlj-p8-e2e-20261003 → register_project 得 project_id=ac73a4bb-a601-4e21-bc0f-7eda71fae4aa（目录落库为规范反斜杠形式；换大小写/正斜杠/尾分隔符再登记被拒并给出已有 ID）→ plan_onboarding：文件 create 14、本机 token/claude/codex/dsh/product_group_buff/git_hooks=apply、shim=noop、阻断 0、bypass_permissions=true、codex_trust=untrusted（进 next_actions）→ onboard_project(expected_digest=bb60bf69…, confirmed=true) 7.9 s：status=done，9 步全收敛，completion 全 ready（AGENTS/git-workflow 管理块最新、身份、能力包 1.9.0、两份 skill、Codex MCP 块、lefthook 挂载与检查段、Claude local、Codex 托管块、DSH 白名单、L1 适用格、改动可报告、HEAD 不变），L1：Claude 2.1.90 与 DSH 0.2.0-rc.2 各 6/6 ready，Codex C–F 4 格 codex_project_untrusted 单列 pending_user（统筹决定 ⑩）；14 个接入文件留待提交、HEAD 不变 → 再次 plan：文件全 noop、七步全 noop（digest 83479aa5…）→ 再次 onboard_project 3.0 s：status=done，9 步全 converged，written_files 为空，14 个文件 mtime 全不变；verify_onboarding 10/12（origin、CI 两项按设计进 next_actions），clients 三端 converged，runtime ready。 human_verify 待用户：在 Claude Code、Codex（先信任该目录）、DSH 桌面 GUI 各新开会话调 read_project_test_account(name=LJ_PROBE_NONEXISTENT) 得「开发需求未登记」；P8g 界面终验。"
 
 ### ✅ P8-0 — 蓝图与依赖修正
 - status: done
@@ -297,8 +298,8 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 - merge_verify: "2026-10-03 统筹会话：PR #39（2f2a9f1，CI passed；独立审查 10 条：6 修、1 部分修、2 登记/转指引、1 转统筹）合并为 d018d44，合并结果全量 cargo test 402 passed / 0 failed / 6 ignored。acceptance ①–⑨ 均为 cargo onboard::apply 层，据此标 ✅；端到端（新登记项目 plan → onboard_project）随 P8e 合并后由统筹实测。统筹决定（审查 ⑩）：codex_project_untrusted 按设计 Q5 计为 next_action、不计入 done（只放宽这一种原因），非 git 目录维持不能 done（acceptance ⑥），子目录与 worktree 补 next_action 说明——由 P8e 实现。"
 - 统筹决定落地（审查 ⑩，2026-10-03，P8e 实现，详见 P8e 卡）：codex_project_untrusted 视为 next_action、不阻断 done——L1 的 Codex 列里仅因 cause=codex_project_untrusted 未就绪的格不计入「L1 适用格」，completion 单列一项「Codex 信任」（source=l1、ready=false、新增字段 pending_user=true，不计入 done），next_actions 保留一条 codex_trust（计划已列不重复；计划预判已信任而 L1 仍显示未信任时补一条）——设计 Q5：炼境不写 Codex 信任表。其余原因的 Codex 格（含 blocked）照常计入；L1Report.all_applicable_ready 保持 L1 自身的原始判定。非 git 目录维持不能 done（acceptance ⑥）；仓库子目录与 worktree / 子模块（.git 为文件）补 next_action repo_layout，说明「lefthook hook 挂载」只认项目根 .git/hooks、按当前口径到不了 done，并给出外层仓库根或实际 hooks 目录与怎样才能 done。由此 known_limits ④「Codex 未信任 → partial」改为 done + pending_user；⑤ 的判定口径不变，只补说明。
 
-### 🔵 P8e — 投影收口与契约同步
+### ✅ P8e — 投影收口与契约同步
-- status: in_progress
+- status: done
 - complexity: S
 - files: src-tauri/src/mcp_tools.rs, src-tauri/src/lib.rs, src/lib/commands.ts, docs/ai-context/project-context.yaml, docs/ai-context/agent-button-system.md, AGENTS.md（实际另含 src-tauri/src/commands/onboarding.rs（Tauri command 本身）、src-tauri/src/mcp_inject.rs（去掉生产入口的 dead_code 标注）、src-tauri/src/onboard/report.rs、onboard/apply.rs、onboard/apply/tests.rs（统筹决定 ⑩））
 - depends: P8d
@@ -309,9 +310,10 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 - verification: "2026-10-03：全量 cargo test 413 passed / 0 failed / 6 ignored（master 402，新增 11 条），编译 0 warning；改动的 Rust 文件 rustfmt --check（skip_children）无差异；pnpm typecheck 通过，pnpm test（vitest）4 文件 16 条通过。cargo test mcp_tools 40 条通过，其中 P8e 新增 5 条：onboarding_tools_are_on_both_routes_with_confirmation_contract（全局与项目路由 tools/list 都含两工具；plan required=[project_id]，onboard_project required 含 project_id、expected_digest、confirmed 且 confirmed 为 boolean；plan readOnly+idempotent+非破坏，apply 非只读+idempotent+非破坏+非 openWorld；两工具都有 bypass_permissions / skip_targets 且描述含 manual_entry、shared_key；描述含「给用户看」「用户明确确认」「在 Codex 里信任」「公开仓库」「private=true」；排在 apply_onboarding_pack 之前且相邻；项目路由 project_id 为 const=p1、不在 required，onboard_project required 为 [expected_digest, confirmed]）、onboarding_tools_on_project_route_reject_cross_project_before_io（项目路由传 project_id=p2 两工具都 isError + structuredContent.code=scope_violation、文案含「绑定 project_id=p1」）、onboard_options_follow_schema_names_and_default（按 schema 声明的选项名构造入参解析正确；缺省与 null 为默认；两工具选项参数完全一致；三种类型错误文案）、onboarding_tools_reject_malformed_arguments_before_io（全局与项目路由：skip_targets 非数组、confirmed 非布尔、expected_digest 非字符串、bypass_permissions 非布尔均在 IO 前报错）、onboarding_responses_carry_structured_content_and_one_line_summary（序列化真实 OnboardingPlan / OnboardReport：structuredContent 原样、摘要含计数、本机步骤、阻断与 skip_targets 提示、digest、待提交接入文件数与 next_actions；status=done 不带 isError）。onboard::report 新增 4 条：codex_trust_only_cells_are_pending_user_and_do_not_block_done（Codex 列 C–F 只因未信任 → done、L1 适用格 ready、单列 1 项 pending_user、补 1 条 codex_trust、计划已列不重复、全就绪时无 pending 项）、other_not_ready_cells_still_block_done（Codex 列混入 auth_failed、别的列出现同一归因、Codex 列 blocked(dependency)、其他 L0 未就绪 → 均 partial）、repo_layout_next_action_explains_why_done_is_unreachable、repo_layout_detects_root_subdirectory_worktree_and_non_git（真实 git 仓库、子目录、git worktree 与普通目录）。onboard::apply 新增 2 条（测试替身 FakeRunner 增加 Codex 自省模拟、FakeLocator 可定位 Codex，lefthook 替身改为装到 git --git-path hooks 与真实 lefthook 一致）：codex_untrusted_cells_are_pending_user_and_do_not_block_done（经真实 L1 判定链：codex mcp get 找不到 → C–F 为 codex_project_untrusted → status=done、pending_user 1 项、codex_trust 1 条；计划预判已信任时 L1 结论补 1 条；生效为全局地址 → partial、无 pending 项）、worktree_project_is_partial_and_next_action_explains_why（真实 git worktree：hook 装在主仓库，未就绪的只有「lefthook hook 挂载」，repo_layout 1 条，重跑同样 partial 且 lefthook 再跑）；既有 project_in_repo_subdirectory_does_not_touch_outer_hooks 补断言（唯一障碍为 lefthook hook 挂载，repo_layout 含外层仓库名），first_apply 补断言（仓库根无 repo_layout、无 pending 项）。变异验证（全部改动先已 git add 暂存，用 Edit 注入、跑 cargo test --lib -- mcp_tools onboard:: commands::projects、git checkout 从暂存区还原，未用 sed）三轮 10 处全部被杀且失败集合与预期一致：第一轮 4 处——onboard_project 移出幂等列表、plan_onboarding 移出 STRUCTURED_TOOLS、l1_readiness 不限 Codex 列、repo_layout_next_action 恒为 None——恰好 6 条失败（路由契约、摘要、other_not_ready、repo_layout 说明及子目录 / worktree 两条 apply 用例）、126 条通过；第二轮 3 处——onboard_project 不进项目路由、done 判定不跳过 pending_user、.git 为文件也判仓库根——恰好 7 条失败、125 条通过；第三轮 2 处——L1 结论不补 codex_trust、选项解析丢弃 skip_targets——恰好 3 条失败、129 条通过。避开会绕过 IO 前校验的变异（如去掉 scope 绑定、去掉类型检查），以免测试进程调到生产入口。"
 - 有意偏差："① dispatch 的一行委托指向 mcp_tools 内的 plan_onboarding_call / onboard_project_call，再由它们调 mcp_inject 入口：中间只做 JSON 类型解析（类型错误须在任何 IO 之前报错，且与 register_project 的分发写法一致），判定仍全在本体。② onboard_project 的 annotations 为非只读、非破坏、幂等（重复执行收敛）、非 openWorld（只写本机与子项目文件、不出网）；plan_onboarding 靠既有 plan_ 前缀规则得 readOnly。③ 统筹决定 ⑩ 的 pending_user 做成 CompletionItem 的通用布尔字段（serde default，目前只有「Codex 信任」一项会置 true），而不是新增 completion 来源；L1 适用格的 detail 注明有几格单列出去。④ 仓库子目录与 worktree 的 next_action 统一名为 repo_layout，同时提示「origin 指向 Gitea」也只读项目根 .git/config（同类口径问题，只说明、不改 verify）；子模块与 worktree 同属「.git 为文件」一类，文案按 worktree 写。⑤ 非 git 目录不给 repo_layout（由 completion「项目文件改动可报告」未就绪说明，acceptance ⑥ 不变）。⑥ files 比卡片多，见 files。"
 - 没验什么："① acceptance 的 [MCP 全局]（对 enterprise 做 plan 全部 noop、apply done 且各步 converged）与 P8f 的 register_project → plan_onboarding → onboard_project 链路：需合并后在运行中的炼境重编译再调写工具，按授权规则由统筹会话实测，本卡保持 🔵。② Tauri command 两个薄包装与 commands.ts 封装没有自动化测试、没在 UI 里调过（P8g 才有界面），只由 pnpm typecheck 与类型逐字段对照保证；Tauri 入参 options 的 camelCase / snake_case 映射（顶层参数 camelCase、OnboardOptions 内部字段 snake_case）按 Tauri 约定推断，未实机验证。③ MCP 客户端侧的工具超时：首次一键接入可能 30 秒以上，Codex 默认 tool_timeout_sec 等客户端限制没有实测。④ repo_layout 的 git rev-parse 与报告里其他 git 观测一样直接起 git、无超时（P8d known_limits ① 同类）。⑤ 统筹决定的 done 判定只在测试替身与单元层验证；真实 Codex 未信任目录的端到端（L1 显示 codex_project_untrusted → done + pending_user）待统筹实测。⑥ 本卡未做独立审查（S 级）。"
+- mcp_verify: "PR #40（97578b2，CI passed，独立审查可合并：3 低 5 信息转后续）合并为 d7f4816。2026-10-03 22:5x 统筹会话端到端（炼境 d7f4816 重编译后经全局 MCP）：新建临时 git 仓库 E:code-projectlj-p8-e2e-20261003 → register_project 得 project_id=ac73a4bb-a601-4e21-bc0f-7eda71fae4aa（目录落库为规范反斜杠形式；换大小写/正斜杠/尾分隔符再登记被拒并给出已有 ID）→ plan_onboarding：文件 create 14、本机 token/claude/codex/dsh/product_group_buff/git_hooks=apply、shim=noop、阻断 0、bypass_permissions=true、codex_trust=untrusted（进 next_actions）→ onboard_project(expected_digest=bb60bf69…, confirmed=true) 7.9 s：status=done，9 步全收敛，completion 全 ready（AGENTS/git-workflow 管理块最新、身份、能力包 1.9.0、两份 skill、Codex MCP 块、lefthook 挂载与检查段、Claude local、Codex 托管块、DSH 白名单、L1 适用格、改动可报告、HEAD 不变），L1：Claude 2.1.90 与 DSH 0.2.0-rc.2 各 6/6 ready，Codex C–F 4 格 codex_project_untrusted 单列 pending_user（统筹决定 ⑩）；14 个接入文件留待提交、HEAD 不变 → 再次 plan：文件全 noop、七步全 noop（digest 83479aa5…）→ 再次 onboard_project 3.0 s：status=done，9 步全 converged，written_files 为空，14 个文件 mtime 全不变；verify_onboarding 10/12（origin、CI 两项按设计进 next_actions），clients 三端 converged，runtime ready。 偏差报备：acceptance 写的对 enterprise「plan 全 noop、apply 全 converged」——enterprise 的 plan 如实给出 update 3（两份 skill 与 capability-packs 待从 1.8.0 升 1.9.0，因其主工作区本地 main 落后 origin/main），按执行铁律不对他会话在制的工作区 apply；同一组断言（计划全 noop、apply 全 converged、mtime 不变）改在上述新登记项目上实测通过。enterprise 主工作区同步后再 plan 即应全 noop。"
 
-### 🔵 P8f — register_project 控制面投影
+### ✅ P8f — register_project 控制面投影
-- status: in_progress
+- status: done
 - complexity: S
 - files: src-tauri/src/commands/projects.rs, src-tauri/src/mcp_tools.rs, src-tauri/src/commands/templates.rs（实施扩展）, src-tauri/src/commands/git_repos.rs（实施扩展）, src/components/dashboard/BatchAddModal.tsx（实施扩展）, src-tauri/src/mcp_inject.rs（审查处置：路径键两函数改 pub(crate) 供复用）, docs/ai-context/project-context.yaml（T1）
 - depends: P8-0
@@ -327,6 +329,7 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 - 有意偏差：① 未加 confirmed 参数——任务要求是「描述写明写操作须用户确认目标」；登记只写炼境 DB、可经 unregister_project 撤销，按 unregister_project 的先例只在描述里约束。② MCP 不收 project_id，统一由炼境生成 UUID，避免 agent 自拟 ID 与已有命名冲突。③ 重复目录检查扩到批量添加、模板新建、挂载仓库三个新建入口（files 标「实施扩展」）：PR #34 审查 L1/L2 的根因是同一目录多条登记，只堵 create_project 和 MCP 两个入口治不了根；编辑入口 update_project 仍未堵（审查 I1，转后续小修）。
 - T1：新 MCP 工具 register_project 已同步 docs/ai-context/project-context.yaml「MCP 工具接口」段（paths 补 projects.rs，doc 补路由、本体、同目录判定、落库规范化、UI 占位例外、warning 与入参语义，以及 scan_unregistered_projects 与 mount_repo 的同口径）；Tauri command 签名未变，src/lib/commands.ts 无需改动。
 - review: "2026-10-03 独立只读审查 bd4ebaf，结论 fix_then_merge，10 条发现处置：M1 [中] MCP 入参原样落库（正斜杠、尾部分隔符、长路径前缀、8.3、`..`），scan_unregistered_projects 按字面比较会自相矛盾 → 已修：本体对 Windows 目录 canonicalize 后去长路径前缀落库，register_project_at 回执 path 为落库值、名称缺省按规范形式取目录名（相对路径不 canonicalize，交本体拒绝）；scan 的已登记判定与父目录去重改用 registration_path_key。M2 [中] UI 不选目录的概念占位被取消，超出 P8f 范围且与 mcp-server 模块记录的用户用法冲突 → 已恢复原行为：本体新增 RootRequirement，UI 入口有效路径为空时只写 profile+workspace、不校验目录、不查重复，MCP 入口仍拒绝；是否改为显式占位概念交统筹会话问用户（需求澄清），本 PR 不预设答案。L1 [低] 已有登记两列都比，残留列误拦 → 已修：按 platform 只取有效根目录（registration_root），查询补 platform 列。L2 [低] 8.3、`..`、末尾点等漏判 → 已修：新目录在写事务外另算 canonical 键，两键比对已有行的字面键（已有行不读磁盘，写锁内无 I/O）。L3 [低] mount_repo 检查在插 profile 之后且无事务 → 已修：抽 mount_repo_records（连接注入），检查前移、整体 IMMEDIATE 事务；前端先 gitClone 再 mount 的白克隆属 UI 范围，未改。L4 [低] 路径比较键多份实现 → 部分修：registration_path_key 改为复用 mcp_inject::normalize_dsh_root + strip_verbatim_prefix（两函数改 pub(crate)）；normalize_trust_path、WSL 发行版查询与 UNC 换算的第三份拷贝统一抽 crate::path_key 转后续小修（会动 P4a/P8d 热点 mcp_inject.rs）。I1 [信息] update_project 仍可造同目录登记 → 转后续小修：UI 编辑整表提交，须「有效根目录实际变化才检查 + 排除自身」，否则存量重复登记（beast-mode）连改名都会被拦，单独做更稳。I2 [信息] project_root_with_conn 对 UNC 形式的 wsl_path 错误拼接（已有缺陷）→ 不在本 PR 改（mcp_inject.rs 热点），转后续小修；卡片与代码注释里「同口径」改为只指取列与 Linux 路径换算。I3 [信息] 重登目录遗留旧 context.json 无提示 → 已修：register_project_at 只读检查，project_id 不同时回执与摘要带 warning（不沿用旧 ID）。I4 [信息] 分发分支无测试 → 已修：分发抽成 register_project_call(conn, args)，测试按 schema 声明的参数名构造入参；IMMEDIATE 并发仍无测试（见没验什么③）。"
+- mcp_verify: "PR #37 合并（55dc637）；P8e 合并后经全局 MCP 实测链路 register_project → plan_onboarding → onboard_project 得 status=done（证据同 P8e mcp_verify）；同目录换写法再登记被拒并给出已有 project_id。"
 
 ### 📋 P8g — UI 一键接入
 - status: todo

docs/tasks/2026-10-03-coordination.md

@@ -78,7 +78,8 @@
 | 10-03 | 删除登记时解绑 Gitea（G8） | 工作流 wf_c121815d-6ea | PR #35（fccb767） | ✅ 审查可合并、5 条已处置；真机删除实测为可选人工验证（涉及删除与写 DB） |
 | 10-03 | P4a L1 零模型三端检查 | 工作流 wf_b7092645-570（修复阶段被分类器拦截，统筹接手收尾） | PR #38（a79bcb7）→ cf2b5f0 | ✅ [MCP] 实测：enterprise 3.3 秒三端 18 格 ready；dev-manager-tauri 控制面 Claude/DSH not_applicable、Codex ready |
 | 10-03 | P8d onboard_project 编排本体 | 工作流 wf_004ffc20-7cb | PR #39（2f2a9f1）→ d018d44 | ✅ 审查 10 条已处置；master 402 passed；⑩ 统筹决定：Codex 未信任计 next_action 不计入 done（P8e 实现） |
-| 10-03 | P8e 投影收口与契约同步 | 工作流 wf_551dc525-270 | `feat/agent-client-parity-p8e` | 执行中 |
+| 10-03 | P8e 投影收口与契约同步 | 工作流 wf_551dc525-270（修复阶段卡死 6 次，审查已可合并，统筹以 97578b2 开 PR） | PR #40 → d7f4816 | ✅ 端到端：新登记项目 done、重复执行全 converged；enterprise 因主工作区落后不 apply（偏差已报备） |
+| 10-03 | P8g UI 一键接入 | 工作流 wf_531cfcda-b1a | `feat/agent-client-parity-p8g` | 执行中 |
 | 10-03 | P8f register_project 控制面投影（含登记拒绝同路径，承接 PR #34 审查 L1/L2） | 工作流 wf_2462357e-604（与 P4a 并行，开 PR 前合并 master） | `feat/agent-client-parity-p8f` | PR #37（04470bd）→ 55dc637 已合并；审查 10 条：7 修、1 部分修、M2 恢复 UI 概念占位原行为（产品问题待用户澄清）、2 转后续；卡片 🔵，[MCP] 链路实测待 P8e 合并 |
 | 10-03 | 重复登记修复 U1/U2 | 会话 `local_d2e1c156…`（「排查炼境 dev-manager-tauri 疑似重复登记」） | PR #34 → fc280db | ✅ 独立审查可合并、已合并，炼境已重编译；审查遗留 L1/L2 归 P8f（登记拒绝同路径），L3/L4/I1/I2 列入后续小修 |
 | 10-03 | 重复登记数据合并 U3 | 同上（用户执行 DB 写入） | master 91017b6；主仓库 .codex/config.toml 升级为稳定 helper 格式 06f20db | ✅ 无 2c5b54ef 残留、同路径 1 条登记、Gitea 绑定 1 行；备份 dev-manager.backup-20261003-before-dedupe.db |
@@ -87,6 +88,7 @@
 
 - ~~重复登记数据合并~~：已由用户执行完毕并验收（见 §4）。
 - **临时文件待用户清理**（deny 规则禁止 agent 删除）：E:	mperify_before.json；重复登记会话 %TEMP% 下的 merge_dup.py 等；统筹会话 %TEMP% 下的 lj-p4-0、lj-p7-probe、lj-p9-spike 等探针目录；已合并分支的 worktree（tmp-p7skill-review、tmp-delivery-status-review、tmp-p10-verify-mut、dev-manager-tauri-wt-p8）可用 git worktree remove 清理。
+- **端到端临时项目（删除需你确认）**：E:code-projectlj-p8-e2e-20261003（project_id=ac73a4bb-a601-4e21-bc0f-7eda71fae4aa）。验收后如需清理：先 unregister_project（删除登记，会同时清 token、Claude local 条目、DSH 白名单与 Gitea 绑定），再手动删除目录。
 - **需求澄清（不阻塞主线）**：UI「添加项目」不选目录时可建「概念占位」登记（P8f 已保留原行为）。是否要把占位做成显式概念（单独入口、标记为占位、不参与接入），等你决定。
 - **Codex 信任**：Codex 只在目录受信任后加载项目 `.codex/config.toml`（P4-0 H-P8-1）。一键接入会把它列进 next_actions，炼境不改 Codex 的信任表。