# 治理反馈闭环

老板-员工手册隐喻：用户发现子项目不足 → 告诉炼境（结构化落账）→ 炼境更新"企业文化与员工手册"（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 阶段定）

### ② 反馈进入梦核蒸馏
- 现状：梦核吃被动数据（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、报告模板系统——坑驱动增量，人肉版跑出疼点后再在本模块机制化。

## 任务卡

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