Merge pull request 'fix(coexist): 新炼境接管项目文件后，旧炼境的模板分发、蓝图规则同步与 buff 轮询跳过该项目' (#47) from fix/files-managed-guard into master

Reviewed-on: #47

.blueprint/catalog.md

@@ -1,5 +1,5 @@
 # 意图目录
-> catalog_version: 1.0 | 前言 → path:AGENTS.md#项目定位 | 语法 → path:docs/ai-context/intent-catalog-guide.md
+> catalog_version: 2.0 | 前言 → path:AGENTS.md#项目定位 | 语法 → path:docs/ai-context/intent-catalog-guide.md
 
 ## 书签
 - 当前 → path:docs/tasks/2026-10-03-coordination.md#0. 方针与本阶段终点
@@ -29,6 +29,14 @@
 - 不做: 不替 agent 思考或调度；不接管子项目自有事实；不因已经做了而保留
 - 墙: W11,W14
 
+## INT-04 MVP 收口
+- rev: 2.0
+- 意图: agent 拿到子项目即能开工、能自验、能交付，摩擦能闭环回传；四条都可用后再谈扩展
+- 人看: 在 enterprise-system 真实开发中，agent 能开工、自验、交付，摩擦能回传；常驻文档与代码一致
+- 机器: module:mvp-closure；path:docs/tasks/2026-10-03-coordination.md#0. 方针与本阶段终点
+- 不做: 不开新能力；冻结的扩展项不派单；不改子项目业务规则与凭据
+- 墙: W2,W3,W14
+
 ## 附录
 - 承重墙 → path:.blueprint/modules/intent-catalog.md#承重墙
 - 决策与否决 → 各模块「决策记录」；终验否决理由 → 卡上 `- 终验:` 行

.blueprint/manifest.yaml

@@ -258,7 +258,9 @@ modules:
     name: 蓝图 Buff
     area: backend
     status: in_progress
-    progress: 86
+    progress: 90
+    updated: 2026-10-04
+    note: "8 张卡全 ✅；B2 终验 2026-10-04 被否决（只改共用文档的提交仍误标无关 📋 卡，实例 IC10），剩余缺口为方案 C（files 重叠改记 DB 信号），MVP 收口期冻结为扩展。"
     position: [2250, 0]
 
   - id: claude-autonomy-config
@@ -511,9 +513,9 @@ modules:
     name: 三端客户端对等
     area: infra
     status: in_progress
-    progress: 74
+    progress: 78
     updated: 2026-10-04
-    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）、P8g UI 一键接入面板（PR #41，2026-10-04）已完成，P8 agent_verify 全部达成、human_verify 待用户终验，端到端：新登记项目 plan→onboard_project done、重复执行全收敛；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）、P8g UI 一键接入面板（PR #41，2026-10-04）已完成，P8 一键接入整卡 ✅（2026-10-04 用户终验：UI 新建→预览→确认 7.7 秒 done，三端 L1 18 格 ready，三端桌面会话调通），端到端：新登记项目 plan→onboard_project done、重复执行全收敛；P8a 把「已接入」统一为有项目 token；P4-0 实测六项假设，Codex 只在目录受信任时加载项目配置、Claude 用无效模型名可零额度取 init 并入 L1），P8 进行中；进度按拆分后卡数重算。待做 P5、P6（基于 P8c 的 WriteSink）。"
     position: [3500, 950]
 
   - id: architecture-evolution
@@ -534,6 +536,15 @@ modules:
     note: "两层模型（人持有的意图目录 .blueprint/catalog.md + 蓝图正文），书装意图、指向事实；卡侧 intent 钉版，agent 编译可判定 /goal，确认卡兼作最小任务简报，回执写进提交。IC1 设计已确认（最小文件优先方案）；IC2–IC4 只新增文档、可与 P8 并行，门控与接线等 P8 收口后做，IC13 按实测数据决定去留。"
     position: [4000, 950]
 
+  - id: mvp-closure
+    name: MVP 收口
+    area: infra
+    status: in_progress
+    progress: 75
+    updated: 2026-10-04
+    note: "2026-10-04 P8 达成后的阶段终点（INT-04）：炼境侧关账、清理、修常驻文档漂移（M2–M4，编进 /goal），四条能力在 enterprise-system 真实开发中只读取证（M5）；扩展项冻结见统筹文档 §3。"
+    position: [4250, 950]
+
 edges:
   - from: project-resource-broker
     to: project-dev-variables

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

@@ -213,8 +213,9 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 - known_limits: "Claude 与 DSH 只验了无头模式，Claude 只用了 sonnet-4-6；Codex 未验 TUI 与桌面版（桌面版可能走 app-server 路径，结论可能不同），也未验 SSE 传输。探针用的是桩服务的中英混合短说明，未用炼境真实说明（中文 238 字、UTF-8 500 字节，远低于 DSH 默认上限 32768 字节）实测。Codex 后续版本若开始带入服务器说明，按「检测行为而非嗅探版本」重跑本探针（P4 固化后纳入矩阵），三端都支持时再迁移。现有服务器说明五条要点中，「先读状态」「canonical project_id」「开发变量先查后登记」在 skill 有对应条目；「其他写操作须用户明确确认」与「unavailable/unknown 不得当作成功」在 skill 与 AGENTS.md 中只有分场景表述（合并 PR、CI workflow、工具链安装；MCP 不可用时不伪造诊断），Codex 会话只能从这些条目与工具描述获知——是否补成通用条目留待下次改 skill 时一并处理（需升接入包版本），本卡不改。
   已补齐（2026-10-03，分支 feat/agent-client-parity-p7-skill-rules）：两条已作为通用边界写进 lian-jing skill 模板开头（双投影到 .agents 与 .claude），两条规则的核心句与服务器说明逐字一致；只读查询、登记开发需求元数据与回传炼境明确列为无需确认的例外，与服务器说明的「其他写操作」及 skill「回传不必逐条征得同意」相容。服务器说明的例外是泛称「不含秘密的开发需求元数据」，skill 例外括注同时列出两个登记工具 register_project_test_account 与 register_project_dev_variable（审查修复：初版只列前者，会把开发变量登记误归入须确认的写操作）；同批修正 skill 第 8 条——开发变量改用 register_project_dev_variable 登记名称与用途，测试账号仍用 register_project_test_account（初版两者都指向后者）。接入包 base-onboarding 1.7.0→1.8.0（修复在 1.8.0 发布前，未再升版本，只更新指纹）；mcp_server 新增 server_instruction_universal_rules_are_in_skill，服务器说明与 skill 任一侧缺这两条即失败，skill 例外行缺任一登记工具也失败。AGENTS.md 托管块未改，仍只有分场景表述；存量项目需重建安装炼境后重跑 apply_onboarding_pack 才拿到新 skill。"
 
-### 🔵 P8 — 一键接入：创建/添加子项目即完成三端可用
-- status: in_progress
+### ✅ P8 — 一键接入：创建/添加子项目即完成三端可用
+- status: done
+- done_verify: "2026-10-04：子卡 P8-0、P8a–P8g 全部 ✅；agent_verify 见 e2e_verify 与各子卡 merge_verify（master 3228b49 全量 cargo test 414 passed、vitest 29 passed）；human_verify 由用户在 P8g 终验中完成（UI 新建→预览→确认 7.7 秒 done，Codex 信任后三端 L1 18 格 ready，Claude Code / Codex / DSH 桌面 GUI 新会话调 LJ_PROBE_NONEXISTENT 均得「开发需求未登记」），证据见 P8g human_verify。"
 - complexity: L（2026-10-03 设计评审后拆为 P8-0、P8a–P8g，均为 S/M）
 - depends: P4a（原为 P4；P8 只依赖 L1 零模型检查，不等 L3）
 - acceptance: "agent_verify: [Tauri command / MCP] 对新登记项目 plan_onboarding → 用户确认 → onboard_project(expected_digest, confirmed=true)，依次完成 canonical context、接入包分发（规则、skill 双投影、Codex 托管块）、本机三端注册（Claude local、DSH 白名单与会话插件、shim、token），并以 L1 零模型三端矩阵（每格带证据等级）验收，附最近一次 L3 结果及是否过期；重复执行收敛（全部 converged、文件 mtime 不变）；接入包对项目文件的改动只报告 diff、不自动提交。human_verify: 在 Claude Code、Codex、DSH 桌面 GUI 各新开会话调 read_project_test_account(name=LJ_PROBE_NONEXISTENT)，得「开发需求未登记」。"
@@ -333,7 +334,8 @@ skill 只是五个接入面之一，兼容层覆盖全部五面。
 
 ### ✅ P8g — UI 一键接入
 - status: done
-- merge_verify: "PR #41 CI passed（head c28caf72ee94a2ce9c749de941d9c43ffafc33ee，核对完整 SHA 后合并）→ master 3228b49：pnpm typecheck 通过；pnpm test 5 文件 29 passed（含 onboardView 13 条）；全量 cargo test 414 passed / 0 failed / 6 ignored（另一测试二进制 1 passed）。agent_verify 全部达成；human_verify ①–④ 待用户终验。"
+- merge_verify: "PR #41 CI passed（head c28caf72ee94a2ce9c749de941d9c43ffafc33ee，核对完整 SHA 后合并）→ master 3228b49：pnpm typecheck 通过；pnpm test 5 文件 29 passed（含 onboardView 13 条）；全量 cargo test 414 passed / 0 failed / 6 ignored（另一测试二进制 1 passed）。agent_verify 全部达成。"
+- human_verify: "2026-10-04 用户终验通过（临时 git 仓库 E:\\code-project\\lj-p8g-ui-test，project_id 5818aa5a-7789-4f4d-a0b3-3b2d433d0a8c）：① 「+ 添加项目」选目录保存后弹出接入预览（14 个新建文件、bypassPermissions 与 Codex 信任单列、本机七步、无阻断）；③ 在预览里取消，目录 git status 为空、零改动；② 经蓝图治理「一键接入」确认后 7.7 秒得 done（9 步收敛），分步结果、L1 矩阵（Claude/DSH 各 6 格就绪，Codex C–F 待你信任）、「待你提交的 14 个文件」与磁盘一致、HEAD 未变、lefthook 三个钩子已挂；用户在 Codex 桌面版该目录发起对话后信任表写入，重跑 probe_client_parity 三端 18 格 ready、all_applicable_ready=true（Codex 桌面版只「添加项目」不写信任）；④ Claude Code、Codex、DSH 桌面 GUI 新会话调 read_project_test_account(LJ_PROBE_NONEXISTENT) 均得「开发需求未登记」（DSH 未传 project_id，会话按工作区绑定本项目）。终验中记下的 UI 文案小问题转后续小修：新建文件的「查看差异」只有一行概要应改行内显示；git_hooks 与 Claude/DSH 行的「已写入」标签重复或不准。"
 - complexity: M
 - files: src/components/dashboard/OnboardPanel.tsx, src/components/dashboard/onboardView.ts, src/components/dashboard/onboardView.test.ts, src/components/dashboard/ProjectModal.tsx, src/components/dashboard/BatchAddModal.tsx, src/components/manage/NewProjectModal.tsx, src/components/dashboard/BlueprintModal.tsx, src/lib/commands.ts
 - depends: P8e

.blueprint/modules/blueprint-buff.md

@@ -13,6 +13,7 @@ id: blueprint-buff
 - Buff 同步后顺手调用 `get_blueprint()`，内部触发 `append_usage_snapshot()`，使飞轮数据与实际开发进度对齐
 - 使用文件路径匹配而非 commit message 解析，与 AI 工具/提交信息风格完全解耦
 - **files 重叠只作兜底（2026-10-02，B1）**：本批提交已有卡被显式推进（新增 🔵/✅/🔴 标题行）则不推断，整批无推进才视为「agent 忘了加锁」。原因：两阶段锁下在做的卡落地时已非 📋，files 重叠只能碰到未开工卡，精度结构性偏低。曾评估「提交说明引用卡 ID」——正文自由文本 4 次命中 3 次误判（「阶段二 N3/N4/N5 待启动」），结构化 trailer 又与上条解耦决策冲突且兜不住忘加锁场景，故不采用；「可能相关」改记 DB 信号不改卡片（方案 C）留作残余噪声持续时的升级路径
+- **剩余缺口与冻结（2026-10-04，MVP 收口 M2）**：manifest 曾记 86%，剩余 14% 起初判为未更新的进度数字；同日 B2 终验被否决（见 B2 卡），证明剩余是真实缺口——兜底推断的误标须按上条升级路径做方案 C（files 重叠改记 DB「可能相关」信号、不改卡片，L 级）。用户定：误标属噪声、不阻挡 MVP 四条能力，方案 C 冻结为扩展，模块保持 in_progress。
 
 ## 任务卡
 
@@ -79,3 +80,5 @@ id: blueprint-buff
 - 实现：infer_task_marks 增加第二个显式归属条件 edits_existing_lines——本批 .blueprint/modules patch 在 hunk 内有 `-` 行（删改既有内容）即视为 agent 在跟进维护，不推断；纯追加（新立 📋 卡、新模块）仍走兜底，保留「立卡即实现、忘了加锁」的捕获。
 - verification: "2026-10-03：cargo test 284 passed / 0 failed / 5 ignored；buff 10 passed（新增 edits_existing_lines 单测与端到端 ⑧⑨）；变异验证见 acceptance。回放 master 260 个 first-parent 批次：B1 下无推进 172 批，B2 新增抑制 27 批，其中含代码改动的 6 批：19b9388（本次误标）、8f3be6b、0d4c2ad、cbc1d46、23de433、0552180，其余为只改蓝图的 docs/chore 提交（本就不会命中代码卡）；纯追加立卡的 9881b56、9c2064e、4f5cf43 保持兜底。"
 - known_limits: "同批若只改写了无关 📋 卡的文字同时改代码且忘了加锁，B2 会少标（漏信号，不误标）。下次再出现误标时按 B1 决策记录升级到方案 C（files 重叠改记 DB「可能相关」信号，不改卡片，L 级）。"
+- human_verify: "2026-10-04 否决：主仓库 12:45 快进到 ef09ef2（只改 docs/tasks/2026-10-03-coordination.md，无蓝图改动）后约 1 分钟，buff 把 intent-catalog 未开工的 📋 IC10（files 含该文件）标为 🔵——无显式推进、files 共用即兜底命中，属 B1 known_limits「不更新蓝图的提交碰共享文件仍可能误标」。B1/B2 两道闸已生效但不足以消除此类误标。"
+- 终验: 2026-10-04 否决：只改共用文档、不动蓝图的提交仍会把无关 📋 卡误标 🔵（实例 IC10）

.blueprint/modules/mvp-closure.md

@@ -0,0 +1,56 @@
+# MVP 收口（mvp-closure）
+
+> status: in_progress | created: 2026-10-04 | intent: INT-04 | 统筹：docs/tasks/2026-10-03-coordination.md §0
+> 来源：2026-10-04 用户在 P8 达成后定下一阶段为「炼境 MVP 收口」，并定以 enterprise-system 真实开发作为验证场。
+
+## 概述
+
+把炼境收口到 MVP：agent 拿到子项目能开工、能自验、能交付，摩擦能闭环回传。炼境侧只做收拾（关账、清理、修文档漂移），
+不开新能力；四条能力是否真的可用，在 enterprise-system 的真实开发中只读观察取证。
+
+## 决策记录
+
+- 2026-10-04 用户定：扩展项（部署控制面、P4b–e、P5/P6、治理缺口②③、DSH 接管、Codex 模型切换、多维视图、架构演进、
+  intent-catalog Phase 4+、概念占位显式化、project-dev-variables V14–V16）冻结，MVP 达成后再排；清单在统筹文档 §3。
+- 2026-10-04 用户定：以 enterprise-system 真实开发验证四条能力（M5），原「开发变量人终验」（V13）并入 M5；
+  intent-catalog 的 enterprise 试点继续冻结，先把四条跑稳。
+- 观察边界：enterprise 主工作区有在制品，炼境侧只经 MCP 只读查询取证；要改 enterprise 就开临时 worktree、走 PR。
+
+## 任务卡
+
+### ✅ M2 — blueprint-buff 关账
+- status: done
+- complexity: S
+- intent: INT-04@2.0
+- files: .blueprint/modules/blueprint-buff.md, .blueprint/manifest.yaml
+- acceptance: "agent_verify: [shell] grep -cE '^### (📋|🔵|💭|🔴)' .blueprint/modules/blueprint-buff.md → 0 且 grep -c '^### ✅' 同文件 → 8；git -C 主仓库 log 中 2026-10-04 的 ff 合并后 git status --porcelain -- .blueprint/modules 为空（零误标）并写入 B2 卡 human_verify 证据；manifest blueprint-buff 为 status: done、progress: 100，模块决策记录写明「剩余 14% 为未更新的进度数字，核心卡已全部完成」。"
+- 验收变更（2026-10-04，按自验报告纪律报备，用户在会话中选定）：执行中发现 buff 12:46 把主仓库 IC10 误标 🔵，「零误标、14% 只是数字」的前提被证伪。改为：B2 卡记终验否决与证据、决策记录写明剩余缺口为方案 C 并冻结、manifest 保持 in_progress 并改 progress 90；原 acceptance 中 status: done / progress: 100 与「主仓库 .blueprint/modules 空」两项不再适用。
+- verification: "2026-10-04（INT-04 goal）：blueprint-buff 8 张卡全 ✅（未完成标题计数 0）；B2 human_verify 记 2026-10-04 否决与 IC10 实例；决策记录新增「剩余缺口与冻结」；manifest blueprint-buff progress 86 → 90、status in_progress。"
+- 为什么：manifest 记 86%，但模块 8 张卡全 ✅；唯一缺 B2 终验记录，而 2026-10-04 主仓库 6 次快进合并后 .blueprint/modules 零误标，正是 B2 的终验现象。
+
+### ✅ M3 — 本轮临时项目与 worktree 清理
+- status: done
+- complexity: S
+- intent: INT-04@2.0
+- files: docs/tasks/2026-10-03-coordination.md
+- acceptance: "agent_verify: [shell] git worktree list 不含 tmp-p7skill-review、tmp-delivery-status-review、tmp-p10-verify-mut、dev-manager-tauri-wt-p8、dev-manager-tauri-wt-intent、dev-manager-tauri-wt-p8g；[MCP] list_all_projects 不含路径带 lj-p8 的登记。human_verify: 用户手动删除统筹文档 §5「待你手动删除」所列目录与文件。"
+- verification: "2026-10-04（INT-04 goal）：git worktree list 按六个已清理名称计数 → 0；全局 MCP list_all_projects 完整输出（29 个项目）中 lj-p8 → 0。human_verify（手动删除 §5 所列目录与文件）待用户。顺带发现：list_all_projects 中 dev-manager-tauri 出现两条（组 f2418a3b 与 ffa9e42d），超出本卡范围，未处理。"
+
+### ✅ M4 — 常驻文档漂移修复
+- status: done
+- complexity: S
+- intent: INT-04@2.0
+- files: docs/ai-context/project-brief.md, AGENTS.md, docs/ai-context/agent-button-system.md, docs/templates/agents-meta-rules.md, docs/tasks/2026-09-30-dev-variables-materialize.md
+- acceptance: "agent_verify: [shell] ① grep -c 'onboard/' docs/ai-context/project-brief.md → ≥1；② grep -lE '^#+ 炼境自己的 Agent 按钮清单' AGENTS.md docs/ai-context/agent-button-system.md → 恰好 1 个文件，另一处改为指针；③ grep -c '1.10.0' docs/templates/agents-meta-rules.md → ≥1，且其规则正文与 src-tauri/resources/onboarding/AGENTS.md.tmpl 的 ONBOARDING_MANAGED 块逐节对照无缺漏（差异写进卡片）；④ grep -c '未合入 master' docs/tasks/2026-09-30-dev-variables-materialize.md → 0；⑤ grep -c '\\.agent/task\\.md' docs/ai-context/agent-button-system.md → 0 或改为与现行做法一致的说明；pnpm typecheck exit 0。"
+- 说明：只改文档，不动 resources/onboarding/ 模板（模板改动会触发指纹测试与版本升级，超出本卡）。
+- verification: "2026-10-04（INT-04 goal）：① project-brief 架构速查补 mcp_inject.rs 与 onboard/ 两行；② 按钮清单以 AGENTS.md 块外区为单一来源（并入 agent-button-system 版多出的 pnpm test 与一键接入两行），agent-button-system 原节改为「按钮清单的位置」指针；③ agents-meta-rules 头部改 version 1.10.0 + aligned_with，能力包五条同步为模板原文、T1/T3/T4/自查措辞同步；④ dev-variables 简报头部改为 frozen、模块已在 master；⑤ agent-button-system 持久层去掉不存在的最小接入文件，改为与单档接入一致。"
+- 差异清单（agents-meta-rules ↔ AGENTS.md.tmpl ONBOARDING_MANAGED 1.10.0，全文见 meta-rules「与分发模板的对照」节）: "托管块 7 节中，核心开发约束、需求对齐协议、Git 工作流三节 meta-rules 无、以模板为准不复制；能力包一节已同步，Node/pnpm 工具链只留指针；agent 按钮与验证路径——meta-rules 缺载体就近选择表、完成的定义、侦察→驻军、agent_verify/human_verify 分层与三分定位启发式，多出分工原则、按钮清单模板、降级约定（已不在托管块内）；多 AI CLI 协作与交接模板内容等价。托管块外四支柱、T1–T4、铁律、自查已同步。"
+
+### 📋 M5 — enterprise-system 实战验证四条能力
+- status: todo
+- complexity: M
+- intent: INT-04@2.0
+- depends: M2, M3, M4
+- files: .blueprint/modules/mvp-closure.md
+- acceptance: "agent_verify: [MCP 只读，project_id 为 enterprise 的 canonical id] ① 能开工：verify_onboarding clients 三端 converged 且 probe_client_parity all_applicable_ready=true；② 能自验：炼境日志或会话证据中至少 1 次 read_project_test_account 成功；③ 能交付：get_delivery_status 至少 1 个 PR 的 CI passed 并已合并；④ 摩擦闭环：list_envoy_returns 中 enterprise 来源的回传均有处置回执。human_verify: 用户在 enterprise 开发中确认——新会话无需手工配置即可开工；需要登录时 agent 先查炼境不索要账号（原 V13）；认可该次交付；回传内容是真问题。"
+- 说明：随用户开发进度积累证据，不进 M2–M4 的 /goal；证据攒够后统筹会话一次性核对并出终验清单。

AGENTS.md

@@ -321,8 +321,10 @@ docs/templates/                  炼境接入包模板草案（设计层）
 | 能力 | 调用方式 | 通过标准 |
 |------|---------|---------|
 | TypeScript 类型检查 | `pnpm typecheck` | 无输出，exit 0 |
+| 前端单元测试 | `pnpm test` | exit 0，无 FAILED |
 | Rust 单元测试 | `cargo test`（src-tauri/ 目录） | 无 FAILED |
 | MCP 工具调用 | 见 `src-tauri/src/mcp_tools.rs` 工具列表 | 返回 JSON，无 error 字段 |
+| 一键接入子项目 | MCP `plan_onboarding(project_id)` → 计划给用户看、用户确认 → `onboard_project(project_id, expected_digest=<计划 digest>, confirmed=true)`（两次选项相同；UI 投影为同名 Tauri command，同一本体） | 计划 `blocked` 为空；报告 `status=done`（`partial` 按 `steps`、`completion`、`next_actions` 修复后重跑即收敛；再跑一次全部 `converged`） |
 | 蓝图状态读取 | 读 `.blueprint/manifest.yaml` | 文件可解析，字段完整 |
 | 蓝图状态更新 | 编辑 `.blueprint/modules/<id>.md` | 文件写入成功，格式合法 |
 

docs/ai-context/agent-button-system.md

@@ -88,9 +88,8 @@ acceptance 是 agent 自验的唯一判断依据，必须是可执行断言：
 
 ### 持久层 — 目标持久化
 让 agent 跨会话续接，不靠对话记忆：
-- 炼境项目：蓝图（`.blueprint/`）
-- 子项目完整接入：随炼境分发的蓝图规范
-- 子项目最小接入：`.agent/task.md`
+- 炼境与已接入子项目：蓝图（`.blueprint/`），规范随接入包分发
+- 接入包只有一档（见下文「分发给子项目的方案」），不设「最小接入」，也不另设轻量任务文件
 
 蓝图在体系里的三个角色：
 1. **目标的结构化载体** — 把自然语言目标翻译成带 acceptance 的可执行任务卡
@@ -179,17 +178,9 @@ Gitea PR 继续使用既有 `create_pull_request` 有界操作；Windows 本机
 ### 原则三：acceptance 是体系的核心关节
 体系其他部分都能降级，acceptance 不能将就。acceptance 写得可执行，自验才是真自验；写得模糊，整个环路是假闭合，无人值守名存实亡。
 
-## 炼境自己的 Agent 按钮清单
+## 按钮清单的位置
 
-| 能力 | 调用方式 | 通过标准 |
-|------|---------|---------|
-| TypeScript 类型检查 | `pnpm typecheck` | 无输出，exit 0 |
-| 前端单元测试 | `pnpm test` | exit 0，无 FAILED |
-| Rust 单元测试 | `cargo test`（src-tauri/ 目录） | 无 FAILED |
-| MCP 工具调用 | 见 `src-tauri/src/mcp_tools.rs` 工具列表 | 返回 JSON，无 error 字段 |
-| 一键接入子项目 | MCP `plan_onboarding(project_id)` → 计划给用户看、用户确认 → `onboard_project(project_id, expected_digest=<计划 digest>, confirmed=true)`（两次选项相同；UI 投影为同名 Tauri command，同一本体） | 计划 `blocked` 为空；报告 `status=done`（`partial` 按 `steps`、`completion`、`next_actions` 修复后重跑即收敛；再跑一次全部 `converged`） |
-| 蓝图状态读取 | 读 `.blueprint/manifest.yaml` | 文件可解析，字段完整 |
-| 蓝图状态更新 | 编辑 `.blueprint/modules/<id>.md` | 文件写入成功，格式合法 |
+单一来源在 AGENTS.md「炼境自己的 Agent 按钮清单」节（常驻上下文，跨工具读取），此处不复制。
 
 ## 分发给子项目的方案
 

docs/ai-context/project-brief.md

@@ -30,6 +30,8 @@ src-tauri/src/credential_store.rs Windows 本机凭证引用、校验与兼容
 src-tauri/src/mcp_server.rs      MCP Server（agent 调用炼境的入口）
 src-tauri/src/mcp_tools.rs       MCP tool schema 与 dispatch
 src-tauri/src/envoy.rs           使者回传本体（三端回传写入、处置回执、待处置列表）
+src-tauri/src/mcp_inject.rs      接入注入与三端适配（canonical context、Codex 项目配置、Claude local 条目、DSH 托管块、稳定 helper 入口）
+src-tauri/src/onboard/           一键接入本体（客户端适配器注册表、写入前计划、编排与报告、L1 三端检查；不依赖 Tauri、连接注入）
 src-tauri/src/commands/dev_variables.rs  项目开发变量本体（Agent 登记、人填写、受认证单项读取）
 src-tauri/src/commands/delivery_status.rs  项目交付信号聚合（Git / Gitea / 部署证据）
 src-tauri/resources/onboarding/  接入包分发模板

docs/tasks/2026-09-30-dev-variables-materialize.md

@@ -1,8 +1,8 @@
 # 测试账户落地到被忽略文件（project-dev-variables 增量）
 
-> status: todo | complexity: L（拆为 3 张 M 卡）| created: 2026-09-30 | blueprint: project-dev-variables（该模块尚在 `feat/project-dev-variables` 分支，V7 blocked，未合入 master）
+> status: frozen（2026-10-04 MVP 收口期冻结为扩展，见统筹文档 §3）| complexity: L（拆为 3 张 M 卡）| created: 2026-09-30 | blueprint: project-dev-variables（模块已在 master；对应卡 V14–V16 为 📋）
 > ⚠️ 处置条款：本简报 done 后 24h 内删除；结论并入 `project-dev-variables` 模块的决策与任务卡，不让简报成为第二事实来源。
-> 类型：Feature。开工前需用户确认本设计；且须等 `project-dev-variables` 合入 master 后在其模块内立卡。
+> 类型：Feature。解冻后开工前需用户确认本设计（卡已在模块内立为 V14–V16）。
 
 ## 为什么（压缩背景 + 证据）
 

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

@@ -8,8 +8,16 @@
 
 - **方针**（AGENTS.md「项目定位」「管家准入与退出」）：炼境是 agent 开发子项目的管家；每个子项目都能在
   Claude Code、Codex、DSH 三端开发，重复配置尽量消除；不过度建设，能力按实测收益保留或撤销。
-- **本阶段终点**：P8「一键接入」——新建或添加子项目后，一次确认即三端可用（P8 卡的 acceptance）。
-  设计：`docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md`；任务卡：agent-client-parity 的 P8-0、P8a–P8g、P4-0、P4a–P4e。
+- **本阶段终点（2026-10-04 起）：炼境 MVP 收口**——agent 拿到子项目能开工、能自验、能交付，摩擦能闭环回传，四条都可用。
+  必做（用户 2026-10-04 定）：
+  1. project-dev-variables 人终验；
+  2. 核实 blueprint-buff 剩余 14% 是否核心：是就做完，否则冻结；
+  3. 本轮临时项目与 worktree 清理（agent 侧已做，见 §5 待手动删除）；
+  4. 修常驻文档漂移：project-brief 目录速查补 `onboard/`、Agent 按钮清单收敛到一处、agents-meta-rules 对齐托管块 1.10.0、
+     dev-variables 简报头部过期、agent-button-system 里 `.agent/task.md` 的矛盾。
+  其余一律冻结为扩展（§3「扩展（冻结）」），MVP 期间不派单。
+- **上一阶段终点 ✅**：P8「一键接入」——2026-10-04 用户终验通过（证据见 agent-client-parity P8 / P8g 卡）。
+  设计：`docs/tasks/2026-10-03-p8-onboarding-oneclick-design.md`。
 
 ## 1. 角色与协议
 
@@ -63,10 +71,16 @@
 | 5 | P8f register_project 控制面投影 | S | 已提前并行（只依赖 P8-0） | [MCP] 链路实测待 P8e 合并后做 |
 | ~~6~~ | ~~P8g UI 一键接入~~ ✅ | M | P8e 后 | human_verify 交用户 |
 | ~~并行~~ | ~~删除项目登记时一并解绑 Gitea 仓库~~ ✅ G8 | S/M | master | 来自重复登记排查会话的推荐任务卡（轮询会继续往已删除的项目 ID 写数据），主要改 projects.rs / gitea.rs，可并行 |
-| 后续 | P6（依赖 P8c）、P4c / P4d / P4e、A4→P4b、P5 | | | P8 完成后再排 |
+| MVP-1 | project-dev-variables 人终验 → 并入 mvp-closure M5 | — | — | 用户 2026-10-04 定：以 enterprise-system 真实开发验证四条能力（开工/自验/交付/摩擦闭环），原 V13 终验并入；炼境侧只经 MCP 只读取证 |
+| MVP-2 | blueprint-buff 关账 → mvp-closure M2 ✅ | S | master | 8 张卡全 ✅，但 B2 终验被否决（IC10 误标），剩余为方案 C、冻结；模块保持 in_progress 90% |
+| MVP-3 | 本轮清理 → mvp-closure M3 | — | — | 2026-10-04 agent 侧已完成（取消登记 2 个、删 worktree 5 个），剩 §5 的手动删除 |
+| MVP-4 | 常驻文档漂移修复 → mvp-closure M4 | S | master | 纯文档可直推；碰 agents-meta-rules 时同步检查接入包模板版本 |
+| 扩展（冻结） | 部署控制面（project-capability-control-plane）、P4b–P4e、P5、P6、治理缺口 ②③（governance-feedback-loop）、DSH 接管（dsh-takeover-readiness）、Codex 模型切换（codex-model-switch）、多维视图（manage-multi-view）、架构演进（architecture-evolution）、intent-catalog Phase 4+（IC6–IC13：门控脚本、接线、书签交接、enterprise 试点——用户 2026-10-04 定继续冻结）、project-dev-variables V14–V16（测试账户落地到被忽略文件）、blueprint-buff 方案 C（files 重叠改记 DB 信号，B2 终验 2026-10-04 被否决后的升级路径） | | | 2026-10-04 用户定：MVP 收口期间不派单，MVP 达成后再排 |
+| 扩展（冻结） | 概念占位登记显式化（UI 不选目录的占位登记） | S | — | 用户 2026-10-04 定：MVP 保持现状；出现具体干扰（诊断、统计、接入入口把占位当普通项目）再出 S 级确认卡 |
 | 后续小修 | P8f 审查转入：L4 路径归一函数统一到 crate::path_key（含 Codex 信任路径、WSL 发行版与 UNC 换算）、I1 update_project 有效根变化才查重并排除自身、I2 project_root_with_conn 拼接 UNC 形式 wsl_path 的已有缺陷 | S | master | 碰 mcp_inject.rs，P8 主线后再做 |
 | 后续小修 | backfill_notes_archive 静默跳过非 UTF-8 旧笔记（dev-manager-tauri 有 4 条）；PR #34 审查遗留 L3（保留他项目 Codex 块不留痕）、L4（沉默统计并列偏向非规范 ID，补测试）、I1（注释说明两处语义差异）、I2（沉默列表带 id） | S | master | 不碰 P8 热点文件的可并行 |
-| 后续小修 | P8g 审查 ④：L1 格子由本体带 pending_user（目前 onboardView.ts 写死 codex_project_untrusted 着色）；面板状态机（过期响应、refused 回预览）补组件测试 | S | master | 碰 probe_l1.rs / onboardView.ts |
+| 后续小修 | P8g 审查 ④：L1 格子由本体带 pending_user（目前 onboardView.ts 写死 codex_project_untrusted 着色）；面板状态机（过期响应、refused 回预览）补组件测试；终验记下的文案：新建文件「查看差异」只有一行概要改行内显示，git_hooks 与 Claude/DSH 行「已写入」标签重复或不准 | S | master | 碰 probe_l1.rs / onboardView.ts |
+| 说明 | 上面三行「后续小修」在 MVP 期间同样冻结，除非某条被证实阻碍 MVP 四条可用性 | | | |
 | 待用户 | beast-mode 同路径重复登记（beast-mode / 940dfbb4，无 Gitea 绑定） | — | — | 需写运行中 DB 与删除登记，按 U3 同法准备脚本后交用户执行 |
 
 ## 4. 派单与 PR 流水（统筹维护）
@@ -85,13 +99,20 @@
 | 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 |
+| 10-04 | 意图目录线 IC1–IC4（并行线交接登记） | 另一会话 | PR #42–#45 → master 0ffaad0 | ✅ 设计 docs/tasks/2026-10-04-intent-catalog-design.md、指南 docs/ai-context/intent-catalog-guide.md、目录 .blueprint/catalog.md 1.0（INT-01–03，书签暂指本文件 §0）；Codex 跨客户端纸面编译通过；模块进度 31%。IC5（首次真实 /goal）可用「MVP 收口」做；Phase 4+（IC6–IC13）冻结为扩展；目录改动按指南走（小版本须用户确认，提交带 Feature-Confirmed） |
+| 10-04 | 阶段切换与清理 | 统筹会话 | master 直推 | P8 达成；§0 终点改为「MVP 收口」，扩展冻结登记进 §3；临时登记 2 条与 worktree 5 个已清理，手动删除项见 §5 |
 
 ## 5. 待用户处理（统筹会话汇总，按时机）
 
 - ~~重复登记数据合并~~：已由用户执行完毕并验收（见 §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 已保留原行为）。是否要把占位做成显式概念（单独入口、标记为占位、不参与接入），等你决定。
+- ~~P8 human_verify~~：2026-10-04 用户终验通过（证据见 P8g 卡 human_verify），**本阶段终点 P8 达成**。
+- **本轮清理（2026-10-04 用户确认删除，agent 侧已完成）**：unregister_project 删除 lj-p8-e2e-20261003（ac73a4bb…）与 lj-p8g-ui-test（5818aa5a…）两条登记（本地文件未动）；git worktree remove：tmp-p7skill-review、tmp-delivery-status-review、tmp-p10-verify-mut（含审查探针测试，--force 丢弃）、dev-manager-tauri-wt-p8、dev-manager-tauri-wt-intent（已注销，空目录删不掉，可能被 Codex 侧边栏占用）；dev-manager-tauri-wt-p8g 在本次文档提交后移除。
+- **待你手动删除**（deny 规则禁止 agent 删除）：
+  - 目录：`E:\code-project\lj-p8-e2e-20261003`、`E:\code-project\lj-p8g-ui-test`、`E:\code-project\lj-p8g-ui-cancel`（误建、未登记）、`E:\code-project\dev-manager-tauri-wt-intent`（空目录）、`E:\code-project\dev-manager-tauri-wt-p8g`（若移除后残留）；
+  - 文件：`E:\verify_before.json`；
+  - `%TEMP%` 下：重复登记会话的 `merge_dup.py` 等，统筹会话的 `lj-p4-0`、`lj-p7-probe`、`lj-p9-spike` 等探针目录，`tmp.h9jWUlwgmv\`（意图目录探索章检查夹具）；
+  - 可选：Codex 信任表（`~/.codex/config.toml`）里 `e:\code-project\lj-p8g-ui-test` 的信任条目。
+- ~~需求澄清：概念占位登记~~：用户 2026-10-04 定 MVP 保持现状、列入扩展（§3）。
 - **Codex 信任**：Codex 只在目录受信任后加载项目 `.codex/config.toml`（P4-0 H-P8-1）。一键接入会把它列进 next_actions，炼境不改 Codex 的信任表。
 
 ## 6. 当前已知事实（易变，以工具自省为准）
@@ -102,6 +123,8 @@
 
 ## 7. 交接（2026-10-04，统筹会话上下文将满，换新会话继续）
 
+> **已执行完毕（2026-10-04）**：本节的 P8g 与收尾全部完成，见 §4；下一阶段按 §0「MVP 收口」推进。本节保留作交接记录。
+
 新会话即新的统筹会话：先读本文件 §1–§6，再按下面接手。旧统筹会话的 30 分钟巡检已停止。
 
 **当前状态**

docs/templates/agents-meta-rules.md

@@ -1,6 +1,7 @@
 ---
-version: 1.2.0
-updated: 2026-09-21
+version: 1.10.0
+aligned_with: src-tauri/resources/onboarding/AGENTS.md.tmpl ONBOARDING_MANAGED 1.10.0
+updated: 2026-10-04
 usage: 炼境接入包分发时写入被管理项目 AGENTS.md 的元规则标准内容
 ---
 
@@ -9,12 +10,34 @@ usage: 炼境接入包分发时写入被管理项目 AGENTS.md 的元规则标
 > 本节由炼境接入包分发，规则技术栈无关，适用于所有项目和所有 AI 工具。
 > 项目特定的路径映射见 `docs/ai-context/project-context.yaml`。
 
+## 与分发模板的对照（ONBOARDING_MANAGED 1.10.0，2026-10-04 逐节核对）
+
+分发实体是 `src-tauri/resources/onboarding/AGENTS.md.tmpl`，措辞以模板为准；本文件是设计层，补「为什么」，不重复模板全文。
+
+| 模板小节（托管块内） | 本文件 | 差异 |
+|---|---|---|
+| 核心开发约束（包管理、代码规范、Playwright 版本固定） | 无 | 不复制，以模板为准 |
+| 需求对齐协议（Bug/Feature 分流、S 级三行卡、M/L 完整卡、Feature-Confirmed、补录≠确认卡） | 无 | 不复制，以模板为准 |
+| Git 工作流（git-workflow.md、Conventional Commits） | 无 | 不复制，以模板为准 |
+| 炼境项目上下文与能力包 | 同名小节 | 五条已同步为模板原文；Node/pnpm 工具链小节只留指针 |
+| agent 按钮与验证路径（1–6 条 + 收束） | 「Agent 按钮体系」 | 本文件有同源同边界、acceptance 写法、自验报告纪律及其「为什么」；缺载体就近选择表、完成的定义、侦察→驻军、agent_verify/human_verify 分层与三分定位启发式（以模板为准）；本文件多出的分工原则、按钮清单模板、自验失败降级约定已不在托管块内（炼境自身见 AGENTS.md 块外区） |
+| 多 AI CLI 协作 | 「跨 AI 工具交接模板」 | 内容等价，模板为编号三条 |
+
+| 模板小节（托管块外） | 本文件 | 差异 |
+|---|---|---|
+| 四支柱、文档防腐 T1–T4、铁律、定期防腐自查 | 同名小节 | 已同步：T1 补「（若存在）」、T3/T4 改指「本文件（AGENTS.md）」、自查路径写全 `docs/ai-context/` |
+
 ## 炼境项目上下文与能力包
 
-- 项目根目录 `.lian-jing/context.json` 是工具无关的 `project_id` 单一事实来源；客户端项目 UI、用户级插件和全局配置都不能替代它。
-- `.claude/liangjing.json` 仅用于兼容已接入的旧 Claude 项目；发现 legacy-only 状态时，应通过炼境迁移，不应复制或猜测 ID。
-- `.lian-jing/capability-packs.json` 仅描述炼境托管基线的版本与自检。升级必须显式报告版本不符，并且不能覆盖项目自己的业务规则、测试、部署声明或手工 MCP 配置。
-- 子项目 agent（Claude、Codex、DSH）遇到炼境分发物的摩擦或验证出跨项目实践时，经同一 MCP 入口 `report_envoy_return` 回传；何时回传与字段规范只写在 lian-jing skill，AGENTS 托管块只留一行指路（skill 按需加载，AGENTS 三端必读）。
+- `.lian-jing/context.json` 是项目 `project_id` 的工具无关单一事实来源；不要从客户端项目 UI、用户级插件或全局配置推断项目身份。
+- `.claude/liangjing.json` 只是旧项目的 Claude 兼容投影。只发现它时，调用 `inject_mcp(project_id)` 迁移，而不是手工复制或猜测 ID。
+- `.lian-jing/capability-packs.json` 记录炼境托管基线的版本。`verify_onboarding(project_id)` 报告 `legacy`、`version_mismatch` 等状态时，按其 `detail` 中的升级提示处理。
+- `apply_onboarding_pack(project_id)` 只更新炼境明确托管的接入包文件；项目自己的业务规则、测试、部署声明和手工定义的同名 MCP server 仍归项目所有，不能被升级覆盖。
+- 遇到炼境分发的模板、约定或 MCP 工具的摩擦，或验证出跨项目可复用的实践时，调用 `report_envoy_return` 回传炼境（只追加信号，不必逐条征得用户同意；Claude 会话结束时也可跑 `/envoy`）；何时回传、字段怎么填见 lian-jing skill「遇到摩擦时回传炼境」一节。
+
+### Node/pnpm 工具链
+
+见模板同名小节（.nvmrc / packageManager 为版本事实源、mise 最小声明、get_toolchain_status 先查、prepare_toolchain 须用户确认）；措辞以模板为准。
 
 ---
 
@@ -38,7 +61,7 @@ usage: 炼境接入包分发时写入被管理项目 AGENTS.md 的元规则标
 
 ### T1 外部契约变更（最高优先级）
 其他代码、服务、或 agent 依赖的定义——接口、共享类型、数据结构、配置键名、环境变量名。
-→ 查 `docs/ai-context/project-context.yaml` 找到记录该契约的文档，检查并同步更新。
+→ 查 `docs/ai-context/project-context.yaml`（若存在）找到记录该契约的文档，检查并同步更新。
 
 ### T2 架构边界变更
 模块划分、目录结构、依赖方向、包边界调整。
@@ -46,10 +69,10 @@ usage: 炼境接入包分发时写入被管理项目 AGENTS.md 的元规则标
 
 ### T3 工具链变更
 引入或替换库、框架、构建工具。
-→ 更新 AGENTS.md 技术栈声明；通知炼境重新扫描并更新 `project-context.yaml`。
+→ 更新本文件（AGENTS.md）技术栈声明；通知炼境重新扫描并更新 `project-context.yaml`。
 
 ### T4 常驻上下文过期
-AGENTS.md 或 `docs/ai-context/project-brief.md` 描述的现实已经改变。
+本文件（AGENTS.md）或 `docs/ai-context/project-brief.md` 描述的现实已经改变。
 → 立即更新。这两份文档常驻 agent 上下文，过期危害最大。
 
 ### 不触发检查
@@ -83,9 +106,9 @@ AGENTS.md 或 `docs/ai-context/project-brief.md` 描述的现实已经改变。
 每隔一阵或大改后，对照以下清单：
 
 - [ ] AGENTS.md 里的技术栈声明还和代码一致吗？
-- [ ] `project-brief.md` 最近 30 天有没有随架构改动更新？
+- [ ] `docs/ai-context/project-brief.md` 最近 30 天有没有随架构改动更新？
 - [ ] 有没有两份文档说同一件事且打架？
-- [ ] `project-context.yaml` 的契约路径还准确吗？
+- [ ] `docs/ai-context/project-context.yaml` 的契约路径还准确吗？
 
 ---
 

src-tauri/src/commands/blueprint.rs

@@ -1323,6 +1323,15 @@ pub(crate) fn sync_blueprint_rules_with(
     root: &Path,
     sink: &dyn crate::WriteSink,
 ) -> Result<SyncResult, crate::WriteFailure> {
+    if crate::mcp_inject::files_managed_by_next(root) {
+        return Ok(SyncResult {
+            success: true,
+            conventions_written: false,
+            claude_md_action: "skipped".into(),
+            agents_md_action: "skipped".into(),
+            message: crate::mcp_inject::FILES_MANAGED_BY_NEXT_SKIP.into(),
+        });
+    }
     let bp_dir = root.join(".blueprint");
     let project_name = root
         .file_name()
@@ -2876,6 +2885,22 @@ pub fn archive_project_docs(project_path: String) -> Result<ArchiveResult, Strin
 #[cfg(test)]
 mod tests {
     use super::*;
+
+    // 共存期防回写：项目文件已由新炼境接管时，蓝图规则同步零写入
+    #[test]
+    fn sync_skips_projects_managed_by_next() {
+        let base = std::env::temp_dir().join(format!("lianjing_sync_guard_test_{}", std::process::id()));
+        let _ = std::fs::remove_dir_all(&base);
+        std::fs::create_dir_all(base.join(".lian-jing")).unwrap();
+        std::fs::create_dir_all(base.join(".blueprint")).unwrap();
+        std::fs::write(base.join(".lian-jing/context.json"), r#"{"project_id":"p1","files_managed_by":"lian-jing-next"}"#).unwrap();
+        let result = sync_blueprint_rules_with(&base, &crate::DiskSink).unwrap();
+        assert_eq!((result.agents_md_action.as_str(), result.claude_md_action.as_str()), ("skipped", "skipped"));
+        assert!(!result.conventions_written);
+        assert!(!base.join(".blueprint/CONVENTIONS.md").exists());
+        assert!(!base.join("AGENTS.md").exists() && !base.join("CLAUDE.md").exists());
+        let _ = std::fs::remove_dir_all(&base);
+    }
     use rusqlite::Connection;
     use std::fs;
 

src-tauri/src/commands/buff.rs

@@ -125,6 +125,10 @@ fn poll_all_buffs(app: &AppHandle) {
 
 fn check_project(app: &AppHandle, project_path: &str) -> Result<(), String> {
     let root = Path::new(project_path);
+    // 共存期防回写：项目文件已由新炼境接管，不再改写其任务卡
+    if crate::mcp_inject::files_managed_by_next(root) {
+        return Ok(());
+    }
 
     // 获取当前 HEAD commit
     let current_commit = match get_head_commit(root) {

src-tauri/src/commands/onboarding.rs

@@ -199,6 +199,14 @@ pub(crate) fn dispatch_templates_with(
     root: &Path,
     sink: &dyn crate::WriteSink,
 ) -> Vec<TemplateResult> {
+    if crate::mcp_inject::files_managed_by_next(root) {
+        return vec![TemplateResult {
+            name: ".lian-jing/context.json".into(),
+            action: "skipped".into(),
+            detail: crate::mcp_inject::FILES_MANAGED_BY_NEXT_SKIP.into(),
+            warning: None,
+        }];
+    }
     vec![
         dispatch_versioned(root, "AGENTS.md", TMPL_AGENTS, sink),
         dispatch_one(root, "lefthook.yml", TMPL_LEFTHOOK, sink),
@@ -1243,6 +1251,21 @@ pub fn silent_projects(conn: &rusqlite::Connection) -> Result<Vec<(String, i64)>
 
 #[cfg(test)]
 mod tests {
+    // 共存期防回写：项目文件已由新炼境接管时，接入包模板分发零写入
+    #[test]
+    fn dispatch_skips_projects_managed_by_next() {
+        let base = std::env::temp_dir().join(format!("lianjing_dispatch_guard_test_{}", std::process::id()));
+        let _ = std::fs::remove_dir_all(&base);
+        std::fs::create_dir_all(base.join(".lian-jing")).unwrap();
+        std::fs::create_dir_all(base.join(".blueprint")).unwrap();
+        std::fs::write(base.join(".lian-jing/context.json"), r#"{"project_id":"p1","files_managed_by":"lian-jing-next"}"#).unwrap();
+        let results = super::dispatch_templates(base.to_str().unwrap());
+        assert_eq!(results.len(), 1);
+        assert_eq!(results[0].action, "skipped");
+        assert!(!base.join("AGENTS.md").exists() && !base.join(".claude").exists() && !base.join("lefthook.yml").exists());
+        let _ = std::fs::remove_dir_all(&base);
+    }
+
     use super::*;
 
     #[test]

src-tauri/src/mcp_inject.rs

@@ -235,6 +235,20 @@ fn write_json_with(
         .map_err(|error| format!("写入 {label} 失败: {error}"))
 }
 
+/// 新炼境（lian-jing-next）接管项目文件后写入 `.lian-jing/context.json` 的 `files_managed_by` 取值。
+pub(crate) const FILES_MANAGED_BY_NEXT: &str = "lian-jing-next";
+
+/// 共存期防回写守卫：项目文件已由新炼境接管时，旧炼境的模板分发、蓝图规则同步与 buff 轮询一律跳过，
+/// 避免两边来回覆盖同一批托管文件。只读判断，文件缺失或不合法时视为未接管。
+pub(crate) fn files_managed_by_next(root: &std::path::Path) -> bool {
+    std::fs::read_to_string(root.join(".lian-jing").join("context.json"))
+        .ok()
+        .and_then(|text| serde_json::from_str::<Value>(&text).ok())
+        .is_some_and(|ctx| ctx.get("files_managed_by").and_then(Value::as_str) == Some(FILES_MANAGED_BY_NEXT))
+}
+
+pub(crate) const FILES_MANAGED_BY_NEXT_SKIP: &str = "项目文件已由新炼境接管（.lian-jing/context.json 的 files_managed_by），旧炼境不再分发";
+
 /// 写工具无关的项目身份锚点。项目根目录是边界，客户端项目 UI 或用户级配置均不是身份来源。
 /// 合并写入：保留未来字段与项目定制字段，只有炼境拥有的身份字段会被刷新。
 #[cfg(test)]
@@ -3623,6 +3637,26 @@ trust_level = "trusted"
         );
     }
 
+    #[test]
+    fn files_managed_by_next_guard_reads_context_and_survives_identity_rewrite() {
+        let base = std::env::temp_dir().join(format!("lianjing_files_guard_test_{}", std::process::id()));
+        let _ = std::fs::remove_dir_all(&base);
+        std::fs::create_dir_all(base.join(".lian-jing")).unwrap();
+        assert!(!files_managed_by_next(&base), "没有 context.json 视为未接管");
+        std::fs::write(
+            base.join(".lian-jing/context.json"),
+            r#"{"project_id":"p1","schema_version":1,"files_managed_by":"lian-jing-next"}"#,
+        )
+        .unwrap();
+        assert!(files_managed_by_next(&base));
+        // 旧炼境刷新身份时必须保留接管标记，否则守卫会被自己抹掉
+        write_canonical_context_at(&base, "p1").unwrap();
+        assert!(files_managed_by_next(&base), "身份合并写后接管标记仍在");
+        std::fs::write(base.join(".lian-jing/context.json"), r#"{"project_id":"p1","files_managed_by":"other"}"#).unwrap();
+        assert!(!files_managed_by_next(&base));
+        let _ = std::fs::remove_dir_all(&base);
+    }
+
     #[test]
     fn canonical_context_migrates_legacy_project_id_and_preserves_unknown_fields() {
         let base = std::env::temp_dir().join(format!(