dev-manager-tauri/.blueprint/modules/governance-feedback-loop.md

治理反馈闭环

老板-员工手册隐喻：用户发现子项目不足 → 告诉炼境（结构化落账）→ 炼境更新"企业文化与员工手册"（CONVENTIONS 规则 + 接入包模板）→ 批量分发给子项目 → 飞轮观测新规则是否生效。

为什么

• 现在用户发现子项目问题只能在会话里口头说（如 2026-07-06 的 group_id 探路问题），不落任何结构化通道，问题→体系改进全靠当次会话的执行力，跨会话就丢
• 治理管线已存在大半（blueprint-governance 的规则编辑与批量同步、blueprint-feedback 的梦核蒸馏、onboarding-pack 的模板版本化分发），但三处断环让"反馈驱动体系进化"没有闭合

三个缺口（待 /architect 细化）

① 治理反馈入口

• 现状：append_project_note 挂单项目、无类型标记，是"员工工作日志"而非"给老板的管理反馈"
• 方向：report_governance_feedback 类入口（MCP 工具优先，UI 上报按钮可后置），记录：哪个项目、什么问题、疑似哪条规则/模板缺陷；落 project_notes 加类型字段或独立治理账本表
• 形态待定：MCP 工具 vs UI 按钮 vs 笔记类型约定（三选或组合，architect 阶段定）
• 2026-10-02 定形：沿用「使者回传」笔记约定 + MCP 工具三端入口 + 独立回执表，见下卡

🔵 缺口①·使者回传闭环（回执 + 三端入口）

• status: in_progress
• complexity: M
• files: src-tauri/src/envoy.rs（新）, src-tauri/src/mcp_tools.rs, src-tauri/src/db.rs, src-tauri/src/lib.rs, src-tauri/src/commands/onboarding.rs, src-tauri/resources/onboarding/.agents/skills/lian-jing/SKILL.md, src-tauri/resources/onboarding/.claude/commands/envoy.md, src-tauri/resources/onboarding/AGENTS.md.tmpl, src-tauri/resources/onboarding/.lian-jing/capability-packs.json, docs/templates/agents-meta-rules.md, docs/ai-context/project-context.yaml
• acceptance:
  • agent_verify: [cargo test] resolve_envoy_return 处置后 list_envoy_returns 不再列出该条、已处置计数 +1，全部处置后待处置为 0；report_envoy_return 在项目 scoped 目录可见，resolve/list 仅全局可见。[三端无头探针] enterprise 中 Claude、Codex、DSH 各调 report_envoy_return 一条 → list_envoy_returns 可见且带「客户端」行；随后 resolve 为 rejected。[MCP] 59 条历史回传补录后 list_envoy_returns 待处置 0、已处置 59
  • human_verify: 在 DSH 或 Codex 的日常会话里遇到摩擦时，能自然地完成一次回传
• 需求卡：用户 2026-10-02 确认（「按照你推荐的来」），交接文档 lj-p9-spike/handoff-governance-feedback-loop.md
• 背景：回传只进不出（无回执，LIMIT 50 把更早的静默挤掉）；入口只有 Claude /envoy，08-23 后 enterprise 主力转 DSH/Codex 即零回传
• 设计：envoy_dispositions 表（note_id 主键，landed/carded/watching/obsolete/rejected，landed/carded 必填 reference，允许 upsert 更正）；report_envoy_return（项目级，三端在 scoped 地址可用）、resolve_envoy_return（全局）、list_envoy_returns 只列未处置
• 动工前辩证收缩（2026-10-02）：
  • 载体补强：只靠 skill 不保证 DSH/Codex「自然」想起回传（skill 按需加载），AGENTS.md 托管块是三端必读面——加一行指路，细则仍只在 skill（AGENTS 块 1.9.0→1.10.0）
  • 补洞①：列表原 JOIN project_profiles 会把登记已删项目的回传静默丢掉 → LEFT JOIN 兜底显示 project_id
  • 补洞②：MCP 断连重试会重复写入 → 同项目同内容幂等，返回已有编号
  • 补洞③：内容含换行会破坏行格式 → 字段压成单行
  • 补洞④：/envoy Step 1 仍读旧 .claude/liangjing.json → 改读 .lian-jing/context.json（旧文件仅兜底）
  • 不做：回执落档文件（可拆除性）——回执是炼境侧判断、归宿不在子项目 git，挂 concept 卡待第二个场景
• 实现留痕（2026-10-03）：本体在 envoy.rs（连接注入）；report_envoy_return 写库后复用 archive_note_append 双写档案； 主工具清单 json! 触达宏递归上限，回传/处置 schema 拆为 envoy_tool_schemas() 插在 list 之后（不抬全局 recursion_limit）
• 对抗审查（两路并行）采纳：① 服务端 instructions「写操作需用户确认」与「自然回传」冲突 → 工具描述 / skill / AGENTS 指路写明回传只追加信号、不必逐条征得同意； ② 硬门槛会吞掉「只在本项目复现」的模板 bug → 炼境分发物出错免门槛（scope=this_project），用户要求时直接回传； ③ 会话中途已报、结束跑 /envoy 换说法重报 → skill 与 /envoy 写明不重报、沿用编号；④ 去重先查后插有并发竞态（6 线程实测复现）→ IMMEDIATE 事务； 去重键去掉含项目名的首行、只比 1 天内（重试窗口，避免吞掉复发信号）；⑤ 内容随档案进子项目 Git → 服务端兜底拒绝私钥头 / 常见令牌前缀； ⑥ resolve 覆盖旧回执 → destructiveHint=true；note_id 宽容解析 "#123"/"123"；缺 project_id 明确提示； ⑦ 炼境仓库内 Codex 迁移遗留的 .agents/skills/source-command-envoy（读旧身份文件、走 append_project_note）已删，炼境自身 /envoy 副本同步模板
• 审查挂出未做：托管文件改内容忘升版本无机器拦截（另开任务，指纹测试）；noteapp 未跟踪的同款遗留技能（子项目内容，不动）；炼境自身 skill / 能力包副本停在 1.4.0（既有漂移，控制面项目）
• 自验（agent_verify 第一段）：cargo test --locked 266 通过 / 0 失败（新增 envoy 9 + MCP 层 2：scoped 目录可见性与注解、dispatch 往返——项目地址回传 → 全局列表带编号与客户端 → 项目地址处置被拒 → 控制面处置后不再列出 → include_resolved 可审计）；pnpm typecheck 通过； 只读核对真实库：使者回传恰 59 条（#77–#150），无孤儿；补录清单经复核 landed 29 / watching 23 / carded 6 / obsolete 1（#82/#93/#147 与台账口径不同处已在 reason 写明依据）
• 上线实证（2026-10-03，PR #28 合并 f948c4c，主仓库 ff 后 tauri dev 热重编译生效）：
  • 真实库迁移生效：list 显示「待处置 59 条（已处置 0 条）」+「另有 9 条更早的待处置回传未展示」（旧版此处静默截断）
  • 三端无头探针（enterprise，零凭据）：Claude #200、Codex #201、DSH #202 均经项目地址回传成功（project_id 自动绑定，Codex exec 无需人工批准即调用）， 控制面列表三条可见、来源 enterprise-system、各带对应「客户端:」行；随后 resolve 为 rejected（探针测试）
  • 59 条历史补录经 MCP 逐条 resolve 全部成功：list「📭 暂无待处置（已处置 62 条）」；只读核对库内分布 landed 29 / watching 23 / carded 6 / obsolete 1，landed/carded 无空落点
  • verify_onboarding(enterprise) 正确报出托管块 v1.9.0 / 能力包 1.6.0 落后——子项目要重跑接入包才拿到新 skill 与指路
• 补录独立复核与用户裁决（2026-10-03，另一会话复核）：被引 16 个 commit 均在 master，landed 落点文本现存；carded 6 对应杂项挂车批 + dsh-takeover T3/T4， watching 23 与两本台账逐项对上。用户裁决：carded/watching 29 条接受现状（不回列待处置——查阅走 include_resolved=true；不新立卡； 杂项挂车批维持随下次模板升版本批车；模式库候选守透镜节三闸门）
• enterprise 已重跑接入包（2026-10-03，用户确认）：AGENTS 块 1.9.0→1.10.0、两份 skill、/envoy、能力包 1.7.0 更新，git-workflow 同版本跳过（块内既有手改保留），verify_onboarding 14/14； 分发前核实：AGENTS 块与 1.9.0 模板逐字一致、全托管文件均为旧模板原样，无定制被抹；改动未提交，归 enterprise 自行提交。探针 3 行档案按用户选择保留（档案是库的镜像）
• 更正（2026-10-03 代理终验实测）：此前据 enterprise .dsh/README.md 推断「DSH 只读 .dsh/skills/、读不到 lian-jing skill」—— 对桌面版内置 0.2 运行时（headless）不成立：其会话技能加载读到了 .agents/skills/lian-jing 的「遇到摩擦时回传炼境」一节。 README 的结论可能只适用于 enterprise 本地 pnpm dsh（0.1.5）；两个运行时的技能发现可能不同，未逐一验证。不加 .dsh/skills 投影
• 代理终验（用户委托检查会话，2026-10-03）：enterprise 日常式提示（不提「回传」）各跑一次 DSH（桌面 0.2 headless）与 Codex exec—— 两端均未遇到属于炼境的摩擦、均未调用 report_envoy_return（无摩擦不误报 ✅）；「遇到真摩擦会主动回传」合成场景未能验证，留待日常观察， 由 B4 沉默项目信号兜底（近 30 天有提交零回传会告警）
• enterprise 入库：接入包托管改动经 PR lanrtop/enterprise-system#181（chore 分支自 origin/main，全托管文件整文件复制、AGENTS 只替换托管块）
• 待人终验（human_verify）：DSH 或 Codex 日常会话中遇到摩擦时自然完成一次回传（DSH 改了上下文后建议重启 pnpm dsh）

② 反馈进入梦核蒸馏

• 现状：梦核吃被动数据（commit 指标、复盘笔记、停滞模块、高风险 scope）
• 方向：用户主动治理反馈作为梦核 prompt 的高权重数据段（老板亲口说的问题 > 统计推断的问题），蒸馏产出规则修订/模板修订建议

③ 接入包批量重分发

• 现状：sync_blueprint_rules 有批量，但接入包 apply_onboarding_pack 单项目一次一发；模板更新后无"全员换发新手册"动作
• 方向：批量 re-apply（复用 ONBOARDING_MANAGED 块安全覆写机制），输出报告：哪些项目更新了哪些块、哪些跳过/失败

闭环全景

发现问题 → ① 结构化落账 → ② 梦核蒸馏 → 更新 CONVENTIONS/模板
    ↑                                        ↓
飞轮观测生效（Rules-Applied trailer / 复盘） ← ③ 批量分发

每一环都有数据留痕，管理动作可回溯。

设计档案：agent 自验协议的辩证与务实版选择（2026-07-06）

用户确立的协作协议：需求对话 → 构建默认 agent 按钮化 → agent 自验 → 快速自修 → 结构化反馈 → 人终验。经多角度辩证后识别出五个内生张力与对应调节器，最终按"大量开发者经验（流程死于执行成本而非设计错误；检查单短才有效；机制记的留下、靠记忆的蒸发）"选择最小执行版落地，完整辩证存档于此备查：

内生张力	调节器	关键点
运动员兼裁判（验证与功能共享理解偏差）	负面披露（「没验什么」一节）	只覆盖已知盲区；未知盲区由人终验兜底——两柱互补，缺一超载。实证：mcp-single-server 自验全绿但 git-bash 层全挂，靠端到端终验抓住
Goodhart（宽松断言让自己过）	改断言需报备	非自觉依赖：断言修改在 diff 天然可审计
橡皮图章化（终验退化为签字）	意外感触发深查	深查频率是自由参数，框架内无机制阻止衰减——最终锚是人的纪律，框架诚实承认此点方自洽
默认按钮化 vs 少而稳	默认分层	默认的是"存在可验证路径"，不是"永久驻军测试"；豁免需声明
不可按钮化工作（审美/体感/探索）	显式豁免	强推得到仪式性假按钮

关键澄清（两把尺子）：acceptance 由 agent 参与撰写，可能继承需求理解偏差——agent 自验对 acceptance，人终验必须对意图，否则是拿被污染的尺子量两次。

落地物（最小版，执行成本趋零）：AGENTS.md / 接入包模板 / agents-meta-rules 增设「自验报告纪律」三条；用户侧两个习惯（先看「没验什么」；意外感或外部契约变更时深查）。刻意不做：新工具、强制 hook、报告模板系统——坑驱动增量，人肉版跑出疼点后再在本模块机制化。

使者回传处置台账（2026-07-18 消化，共 23 条）

已落地（本轮 3 项）

• /ship 三处模板修正（~/.claude/commands/ship.md，全局命令即分发源）：① blueprint 尾 commit 铁律改为「每轮 /ship 的最后一个 PR 末位 commit」（多 PR 场景 manifest 单文件不可能每 PR 都带）；② 规模闸补两个不可拆例外（单一功能域强耦合 / 全新业务线初版）→ 警告放行不阻塞；③ MCP 连接错误注明可原地重试 2~3 次（偶发抖动非业务失败）
• envoy.md 分类硬门槛（接入包全托管文件）：Step 3 前置追问「任何有经验的工程师是否会提前想到？」——常识性知识与过窄 corner case 一律留本项目，堵住 2 例误回传的根因
• CONVENTIONS v1.12.0：飞轮工作流阶段 2 末新增「动工前辩证收缩」（M/L 卡必做），实证返工率对照写入

此前会话已落地（11 条，本轮核实关闭）

MANAGED 块警示（5b0b068）、Bug Fix/Feature 分类 + S 级轻量卡 + 汇总补录限定语（67bdacb AGENTS v1.5.0）、蓝图机器门控（f04eb6e blueprint-gate 双层，回应 07-09「文档约束无机器门控」假设）、lefthook API typecheck 必填项 + CONVENTIONS scope 前置提示（be2f695 v1.11.0）、Playwright 版本锁死（AGENTS tmpl）、agent_verify/human_verify 分层（AGENTS + CONVENTIONS）、/ship 阶段八 rebase 前 stash 保护（已在 ship.md）、空路径分发防护（473cf7e）

待观察（log_for_review，暂不动模板）

• verify_onboarding lefthook 键名匹配是名义非语义：等价功能不同键名会误报缺失；enterprise-system 6/7 fail 待核实是缺失还是改名
• /ship 运行期间并行开发混入变更（under_validation）：建议最终报告对比第零步 status 快照、新增变更单独列出不纳入本轮——再积累 1~2 次实例后进模板
• /antirot 命令模板化：enterprise-system 实现的文档防腐命令（机器验+文档一致性+蓝图健康三步），候选纳入接入包标配
• Loop 模型路由（Haiku=Observer / Sonnet=Actor）与种子层/土壤层分工：enterprise-system 特有 Loop 体系，尚不构成跨项目通用约定，观察其长期效果
• OpenAI SDK tool_calls 联合类型守卫：可作 AI 代码审查检查项候选（project_type:web）

遗留尾巴

• src-tauri/ 下空路径污染残留 → 2026-07-18 辩证收缩后三步收官：①9 个污染文件已移出（暂存 %TEMP%\liangjing-pollution-20260718）；②两条空路径僵尸登记（agent编排界面(opencode)/银龙集团应用）已 unregister（磁盘无对应目录，实为死登记）；③辩证挖出 inject 链路漏拦同一空路径洞（project_root() 对空串 win_path 穿透写 cwd，正是 settings.json/liangjing.json 污染的来源）——已单点补 validate_registered_path（拒空+拒相对路径）+ 2 条回归测试。空路径事故至此两链路（apply/inject）全堵
• envoy.md 硬门槛已进模板，需重建安装炼境后 apply 才会分发到子项目（模板打包在二进制资源）

使者回传处置台账 · 第二轮（2026-09-11 分诊，覆盖 07-22→08-23 共 36 条）

通道缺陷实锤升级：第一轮已消化的 23 条至今仍挂在 list_envoy_returns「待处理」列表—— 回传只进不出，无回执标记。在缺口①机制化之前，本台账是唯一消化凭证； 2026-10-03 已机制化：两本台账的 59 条已逐条补录进 envoy_dispositions 回执（见缺口①卡），此后以 list_envoy_returns 为准； notes 档案落地卡（下方）因此优先级上调（它是回执机制的地基）。

已消化 6（有落点证据，直接关闭）

• 世界模型同构（08-23）→ 本文件「开发侧世界模型透镜」节
• 新 agent CLI 接入模式（08-23）→ dsh-takeover-readiness T3 卡吸收
• 换主力前基线快照（08-23）→ dsh-takeover-readiness T4 卡吸收
• 统计先于自动化闸门（08-23）→ dsh-takeover 辩证收敛③已实际应用（上游化否决即用此模式）
• Gitea 1.22 无 actions API 的替代路径（07-24）→ cicd-workflow.md「本机 CI runner 速查」（09-11 回流）
• get_ci_status 三态语义（07-23 报）→ 代码已修（gitea.rs 结论三分支 ✅/❌/⏳），09-11 实调 success 路径验证

已过时 1

• DSH 0.1.1-rc.2 坑清单（08-23）→ 0.1.5 时代大半失效，.dsh/README.md 活文档为单一来源，炼境侧无动作

待行动 10 → 收敛为 3 张候选卡（见下方任务卡；模板变更属 Feature，执行前须用户确认）

仅归档 19

• 模式库候选 +11（透镜节闸门证据显著加厚）：三资产闭环 / NL→过滤服务端验证 / DualScopeBridge / crypto.randomUUID 非安全上下文 / DB 触发器审计注册表 / ALS+postgres-js 注入 / capacitor 三条 / ssh-action secrets envs / 部署脚本 git pull 自更新延迟
• /ship 规模闸实证 ×3（超大 PR 例外有效 / L1 无人值守例外放行 / MCP 断连续接有效）→ 喂「/ship 体检」卡的阈值复核
• 挂触发 ×2：SQL migration 文件漏提交检测（再发一例立卡）；blueprint-gate files 重叠误标 🔵 → 2026-10-02 第二例触发（炼境自身 P6/P7/P8/A4）已结案：误标源头实为 buff 后台轮询（非 blueprint-gate）， 见 blueprint-buff B1（files 重叠降为兜底，同批已有显式推进则不推断）
• review 体系设计输入 ×2：对抗验证系统性过滤结构性建议 / 严苛 review 标准条件性收益——review 体系动工时消费
• 坑库候选 ×1：Windows 复制 SSH 私钥须 cat | clip 保 LF（CRLF 致 ssh-action 静默失败）

开发侧世界模型透镜（2026-08-23 辩证收敛）

源头：enterprise-system 使者回传「炼境=开发侧世界模型容器」（2026-08-23）+ 业务侧四载体 （vision-world-model.md / estate1-world-model.md / hub-relation-catalog.md / hub-matrix-biz-ecology.md）回顾。 合题：世界模型是透镜，不是工程——用透镜照出真实病灶就修，其余全部挂闸门。

同构映射（业务侧 ↔ 开发侧）

R 规则层=CONVENTIONS 规则库（炼境强项，业务侧反而隐式）｜E 实体层=项目/模块/任务卡/服务器（实体丰富、跨项目关系贫乏）｜A 资产层=接入包（唯一模式雏形）｜地图=单项目蓝图画布（无全局）｜可拆除性=资产纯文件 git（notes 是唯一违规点）。

两处判断修正（辩证结论，防后续会话重新推演）

1. 「独立世界仓库」被否：现在只有一个住户（notes 档案），为一个住户建仓库违反晋升阶梯（第二个场景才晋升）。炼境自身仓库本来就是事实上的元仓库，跨项目资产先住这里。
2. 可拆除性缺口比直觉窄：飞轮数据可从 git 历史重生（ingest_git_history=重生配方），不违规；唯一硬违规是 project_notes（复盘笔记+使者回传，原创不可再生，只活在 SQLite）——即下方 A 卡。

三个闸门（等真实场景敲门，禁止提前建设）

候选	闸门条件	备注
跨项目 edges	第一个真实跨项目查询需求（最可能从梦核来）	方案已定：自省派生 ∪ 显式声明（继承 hub-relation-catalog）
全局地图视图	edges 落地之后	开闸时先辩证「矩阵 vs 画布」——manage-multi-view 已承载一半需求，勿撞车；节点须双承载（入口+健康度）
模式库	⚡ 闸门已敲响（2026-08-23 第三候选到位，待用户决定开建）	接入包=第一个模式，库=接入包机制泛化；三候选：DSH 接入模板（活文档在 enterprise-system/.dsh/README.md，炼境不复抄——第二消费者出现时直接从活文档拷）、子主题规范、dev path 定位投影；09-11 分诊归档再 +11 候选

三投影准入律（新资产类型的验收清单）

任何新世界模型资产类型，三投影不齐不算入模：文件形态（git 可拆除）+ MCP 工具（agent 可消费）+ UI 投影（人可终验）。

已否决方案存档：用 enterprise-system 框架整体重构炼境（2026-08-23 辩证，用户暂存待续）

结论：整体重构否决，机制移植推荐（种子拿来，土壤留下）。

三个硬阻断：① 炼境命根子是"本地之手"（启动编辑器/写本地文件/git/托盘），web 栈给不了，重构完仍需本地 daemon，架构更重；② 数据哲学正面冲突——enterprise「页面身份在数据库」vs 炼境「可拆除性：资产=文件在 git」，搬进配置引擎 DB 是哲学掉头；③ 单用户桌面背不动多用户 web 引擎的权限/隔离死重。收益错位：世界模型瓶颈（edges 无数据/无消费场景）没有一个是 UI 框架造成的。

种子清单（可移植机制，经模式库通道逐颗引入）：dev path 定位投影（下方 💭 卡）、view-lab 多维视图交互（做 manage-multi-view 时借）、关系目录方法论（已继承为 edges 方案）、Hub 矩阵交叉点双承载（地图开闸时用）、注册表反转三件套（设计纪律）。

反转条件（出现再重估引擎化）：① 需要多端/远程访问 → 届时是"炼境长出 web 投影"非重构本体；② 实体清单页持续增殖（现 15+ 张）→ 届时炼境内部长轻量配置化表格引擎，只管新页不回迁旧页。

💭 DevPath 卡 1：模板契约层「定位投影」

• status: concept
• 内容：AGENTS.md.tmpl agent 按钮节新增「定位投影（dev path）」条——UI 项目应提供 DEV 浮层，一键复制"当前页面 → 代码/配置锚点"（ROUTE/CODE/DATA/STATE 四段契约），参考实现 enterprise-system components/DevPathHint.tsx；自身 AGENTS.md + meta-rules 同步。S 级，1.7.0 若仍未分发可补遗不升号
• 概念定位：dev path = 人这边的发话按钮——agent 按钮让 agent 能做，dev path 让人能说（把"我在这里"的手势转成 agent 可解析地址）；搭配截图 = 人语视觉参照 + agent 语机器锚点双通道

💭 DevPath 卡 2：炼境自建 DevPathHint（吃自己狗粮）

• status: concept
• 内容：新增 src/components/DevPathHint.tsx + App 挂载，DEV 环境左下浮层：当前路由 → 页面组件文件路径 → 选中项目/模块 ID，一键复制。M 级
• 注意：炼境页面是代码路由非配置驱动，价值低于 enterprise 版（那边 grep 会扑空，这边 grep 通常能中）——实现时保持轻量，勿照抄其配置推导层

任务卡

✅ notes 档案落地（可拆除性修复：双写 + 存量回填）· done 2026-09-11

• status: done
• complexity: M
• files: src-tauri/src/mcp_tools.rs, src-tauri/src/mcp_inject.rs（原卡列 db.rs 实际未动——无新表，纯双写层）
• acceptance: agent_verify: [Tauri command] append_project_note(pid, content) → DB 有记录且 .blueprint/notes-archive.jsonl 尾行 JSON 可解析出同一 content；存量回填命令执行后 JSONL 行数 = project_notes 表行数；cargo test 覆盖双写 + 并发追加不交错 ✅（110 测试全绿含新增 3：双写行匹配 / 回填幂等+死登记跳过 / 8 线程并发不交错）
• 归宿翻转声明（动工前辩证，偏离原卡设计）：原卡「炼境仓库集中式档案」→ 改为按项目分片 （各项目 .blueprint/notes-archive.jsonl 存自己的笔记）。理由：① 安装态进程无法可靠定位「炼境仓库」路径； ② 与「资产=纯文件在项目 git、可拆除性按项目」哲学一致（透镜节 .blueprint 分片描述）；③ 子项目会话 （含 DSH，文件直读）就地消费自家档案；④ usage.json 先例本就是 per-project 写入
• 实现留痕：双写失败不回滚笔记（DB 事实源）仅 log_event warn；backfill_notes_archive MCP 工具 全量重建幂等自愈；死登记（空/相对路径）跳过并报告（复用 validate_registered_path 防护， project_root 重构出依赖注入版 project_root_with_conn）
• 真机终验完成（2026-09-11，dev 模式热重建免了重建安装）：append 双写实调落盘 ✅（复盘笔记 id 164）； backfill 存量实调 156/156 全归档 ✅。真机终验抓到测试盲区：同路径重复登记（mcp-single-server 遗留 的双记录）逐项目整写互相覆盖，实锤丢 20 条——已修（01c9433 按落盘路径归并 + 回归驻军），复跑验证 21 条归并落盘。教训：分片落盘的分组键必须是「解析后的物理路径」而非逻辑 ID

✅ /ship 模板体检（第二轮分诊待行动 ×4）· done 2026-09-11

• status: done
• complexity: S
• files: ~/.claude/commands/ship.md（全局命令即分发源）
• 收官留痕：核实现状后 4 项中 2 项早已被此前会话修复（already_exists 为准＝37 行既有；20 分钟上限＝阶段五既有）， 本轮实补 3 处——① push 侧 job 成功作提前信号 + 轮询计数文案修正（3/10→3/16）；③ 新文件占比口径 （超限中新文件贡献 ≥70% → 按例外②放行，600 红线防旧文件大改非新增）；④ 误报表增「机械阈值类归 lint 管辖」行
• acceptance: [人工] ship.md diff 覆盖实补 3 项 ✅；[实战] 下次 /ship 无对应摩擦复发（留观）

✅ /envoy 模板体检（第二轮分诊待行动 ×2）· done 2026-09-11 零改动收官

• status: done
• complexity: S
• files: src-tauri/resources/onboarding/.claude/commands/envoy.md（核实，未改动）
• 收官留痕：核实模板现状发现 两项均已被此前会话消化——① 愿景类漏传提示＝Step 2 既有 ⚠️ 块； ② MCP 降级指引＝Step 4 既有（重试 1~2 次 → 整理文本输出请用户代传）。分诊时按回传文本标了待行动， 未先核实现状（教训：分诊定态前先 grep 目标文件，回传的「建议」可能早已落地）。 另核实 fully_managed 文件按内容比对覆盖、无需版本信号，原卡「升版本号」前提即不成立。 ③ .dsh 形态 → 挂「Claude 退出终审席」触发（当下由终审会话代传，见 dsh-takeover 协作模式纪律 4）

📋 接入包杂项挂车批（第二轮分诊待行动 ×4，不单独发车）

• status: todo
• complexity: S
• 内容：挂「下次模板升版本批车」顺路带走——① migration 建号前必 ls 目录取真实最大号；② 写配置 migration 前先 SELECT 消费方实际使用的 key；③「挂起模块 × 新模块」双向留痕进 CONVENTIONS「何时更新蓝图」候选场景； ④ 文档防腐铁律加注「prompt/skill 文件豁免删冗余——重复是遵循度手段，非腐化」
• acceptance: [人工] 下次模板批 diff 含 4 项；版本号随批次升级

💭 使者回执落档（可拆除性）

• status: concept
• 内容：envoy_dispositions 回执只在 SQLite（同 notes 档案落地前的 project_notes），是炼境侧原创判断。归宿不宜写进子项目 git（不是子项目的事实）；炼境安装态又定位不到自身仓库。第二个「炼境侧原创资产」出现时一并设计归宿（2026-10-02 缺口①卡辩证收缩挂出）

（其余 concept 阶段，L 级——待 /architect 设计确认后由 /splitter 拆卡）