docs(blueprint/governance-feedback-loop): 缺口① 立卡使者回传闭环，记录实现、审查与自验，进行中

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

.blueprint/modules/governance-feedback-loop.md

@@ -13,6 +13,36 @@
 - 现状：`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 写明依据）
 
 ### ② 反馈进入梦核蒸馏
 - 现状：梦核吃被动数据（commit 指标、复盘笔记、停滞模块、高风险 scope）
@@ -192,4 +222,8 @@ R 规则层=CONVENTIONS 规则库（炼境强项，业务侧反而隐式）｜E
   ④ 文档防腐铁律加注「prompt/skill 文件豁免删冗余——重复是遵循度手段，非腐化」
 - acceptance: `[人工] 下次模板批 diff 含 4 项；版本号随批次升级`
 
+### 💭 使者回执落档（可拆除性）
+- status: concept
+- 内容：`envoy_dispositions` 回执只在 SQLite（同 notes 档案落地前的 project_notes），是炼境侧原创判断。归宿不宜写进子项目 git（不是子项目的事实）；炼境安装态又定位不到自身仓库。第二个「炼境侧原创资产」出现时一并设计归宿（2026-10-02 缺口①卡辩证收缩挂出）
+
 （其余 concept 阶段，L 级——待 /architect 设计确认后由 /splitter 拆卡）