diff --git a/docs/todo/system-design/41-graph-vs-fde-reliability-discussion.md b/docs/todo/system-design/41-graph-vs-fde-reliability-discussion.md
index 19a377b..8d173cc 100644
--- a/docs/todo/system-design/41-graph-vs-fde-reliability-discussion.md
+++ b/docs/todo/system-design/41-graph-vs-fde-reliability-discussion.md
@@ -316,8 +316,28 @@ FDE 无关，纯粹为了让 org-hunt 做真调研）反复 `rerun` 同一个 ta
       这个路径是我的 kind=X 产出"的机制——这个改动面比三个 agent 大得多，影响所有 org node，
       未拍板是否要做，留作独立跟进项（见下一条）。两轮真跑（5、6）都靠 `contract.json` exports
       兜底成功，当前不是阻塞性问题。
-- [ ] **`indexNodeOutputs()` 覆盖项目根产出**——上一条挖出的架构级缺口，工作量和影响面都明显
-      大于这次的三个 agent，需要独立评估要不要做、怎么做（改索引扫描范围 vs 加显式声明机制）。
+- [x] **`indexNodeOutputs()` 覆盖项目根产出——已修复并验证生效**（2026-08-30）。改法：
+      `contract.json` 新增 `produces: {kind: 绝对路径}` 显式声明字段（`readDeclaredProduces()`），
+      校验通过（绝对路径/落在项目根或私有目录内/文件真实存在）才登记，不满足整个 kind 判
+      「没产出」；全局提示词（`describeArtifactContract`）同步教会所有 org/work 节点。
+      第 9~12 轮反复真跑验证：`org-hunt`/`org-digest`/`org-evolve` 声明的产出（不管物理落在
+      私有目录还是项目根）全部正确索引，`recordFile` 逐条确认成功。已提交（`496c249`），
+      补了 2 条守卫测试（`graph-files-index.test.js` ⑫⑬：声明生效 / 越界声明被拒）。
+- [x] **第 6 个独立缺陷：workgraph-planning 按"名字语义匹配"误选 validator.json 专属本体**——
+      第 11 轮 `org-evolve` 规划验收节点时，选了 `benchmark-validator`（"对评分结果做验收判决"，
+      名字很贴切），但该本体硬编码读 `artifacts/goal-benchmark.json`（只有 `planner.json` 的
+      `goal-benchmark` 节点才产），这条 Hunt→Digest→Evolve 链路里根本没有该节点，两轮都判
+      `blocked`。根因：`benchmark-validator`/`testdata-validator`/`validator-triager` 不是
+      通用验收工具，是 `validator.json` 骨架专属、绑定任务级共享契约文件的本体。**已修**：
+      `workgraph-planning/agent.md` 加第三条硬规则（判据从"名字像不像"改成"这条链路里有没有
+      节点产 goal-benchmark.json/acceptance.json"）；`deliverable.json` 的 `whenToUse` 补上
+      "自带自评分收敛逻辑的节点也不需要外部验收节点"这条例外条款并点名这次事故。第 12 轮
+      真跑验证：`org-evolve` 的规划记录原文直接引用了新条款选中 `deliverable.json`，
+      `backward_count=0`，评分 83/行业均线 78 收敛，全流程干净跑完。
+- [x] 至此，11 轮真跑挖出的 6 个独立缺陷（7.0 竞态 / 模板库缺口 / 验收节点任务描述越权 /
+      两个规划 agent 路径口径 / R-19 索引覆盖 / 名字语义匹配误选专属本体）全部修复并逐条
+      验证生效，第 12 轮起连续跑通。工作已提交（`496c249`），与另一并行会话的工作
+      （boss agent 看板 / 打字机流式打断，39/40 号文档）无冲突合并。
 - [ ] `routeFailure` 的 `infra_flake` 分支补上 `target_node` 路由（30 号文档遗留的"刻意没做②"）。
 - [ ] `27-p4-parallel-and-artifacts.md` 并发 fan-out 设计推进。
 - [ ] boss agent（暂定挂在 CEO 身份下）：主动巡检 goal/task/work 状态、卡住/漏结算主动喊人，功能待从零设计。
diff --git a/system/agents/workgraph-planning/agent.md b/system/agents/workgraph-planning/agent.md
index 35f422f..393b601 100644
--- a/system/agents/workgraph-planning/agent.md
+++ b/system/agents/workgraph-planning/agent.md
@@ -105,6 +105,21 @@ for f in $REPO/system/work-graph-templates/*.json; do echo "=== $f ==="; cat "$f
 **必须**把 `deliverable.json` 的 `whenToUse` 逐字读一遍再决定要不要用，不能因为
 `executor.json` 更眼熟就默认用它、把 `deliverable.json` 漏出候选表之外。
 
+⚠️ **第三条硬规则（2026-08-30 真实事故加的）**：`benchmark-validator` / `testdata-validator` /
+`validator-triager` 这三个本体**不是**通用的"给我一个验收判词"工具——它们是 `validator.json`
+骨架专属的，硬编码读 `artifacts/goal-benchmark.json` / `artifacts/acceptance.json` 这两份
+**任务级共享契约文件**（`goal-contract.js` 的输入），而这两份文件只有 `planner.json` 骨架里的
+`goal-benchmark` 节点会产。真实事故：给 `org-evolve` 规划验收节点时，看名字"语义匹配"选了
+`benchmark-validator`（"对评分结果做验收判决"，听着很对），但这条任务链路里根本没有
+`org-planner`/`goal-benchmark` 节点产出那两份契约文件——`benchmark-validator` 一读就是
+`goal-contract.js validate` 退出码 2「没有 acceptance.json」，两轮都这样，整个节点判
+`blocked`。**判据不是"名字听起来像"，是"这条任务链路里有没有节点产 `artifacts/goal-benchmark.json`
+/ `acceptance.json`"**——没有，就不能挂这三个本体，不管名字多贴切。
+且大多数情况下你根本不需要一个外部验收节点：如果宿主 org node 自己的 agent.md 里已经写了
+自我评分/自我判定收敛的逻辑（`org-evolve` 就是——它的 Small Loop 本身会对照 benchmark 打分、
+判 `success`/`fail`），那就是 `deliverable.json` 的单节点起手式，不需要额外挂任何验收节点，
+不止是"不挂 benchmark-validator"这一步。
+
 ### Step 3 · 读可引用的 system agent 本体
 
 ```bash
diff --git a/system/work-graph-templates/deliverable.json b/system/work-graph-templates/deliverable.json
index 63d133c..2cf01a3 100644
--- a/system/work-graph-templates/deliverable.json
+++ b/system/work-graph-templates/deliverable.json
@@ -1,11 +1,14 @@
 {
   "id": "deliverable",
   "label": "内容型交付物 org node 的 work graph（单节点起手式）",
-  "whenToUse": "宿主 org node 的产出是不可执行的内容型交付物——文档、知识库、研究方法论、数据集、技能定义这类，验收标准是「必需文件是否都按约定写出来了」，不是「跑测试/看 acceptance.json 是否达标」。典型信号词：调研、整理知识、写方法论、设计技能包、产出报告/数据集。与 executor.json 的区别：executor.json 假设产出是可运行代码，验收靠自测 + testdata/coder 类 validator 判 acceptance 契约；本骨架没有这套代码测试语义，也不引入验证 agent——校验交给宿主节点在 org graph 边上已经声明的 produces 契约（引擎按 required kind 检查文件是否真的产出，见 graph-engine.js 的 PRODUCES_MISSING）。这条边界踩错的真实案例：把 org-hunt（调研/知识产出节点）套进 executor.json 后，workgraph-planning 两次现场重规划分别选了 qa-judge（陷入 critic/judge 合一导致的无限重复确认，判 infra_flake）和 testdata-validator（死等一份任务本身不会产出的 acceptance.json，判 input_underspecified），两次都在验证层卡死，烧了 20 次调用/31 分钟才熔断——根子是这类任务从设计上就不该套代码测试范式的验证 agent。",
+  "whenToUse": "宿主 org node 的产出是不可执行的内容型交付物——文档、知识库、研究方法论、数据集、技能定义这类，验收标准是「必需文件是否都按约定写出来了」，不是「跑测试/看 acceptance.json 是否达标」。典型信号词：调研、整理知识、写方法论、设计技能包、产出报告/数据集。也适用于宿主 org node 自己的 agent.md 里已经写明会自我评分/自我判定收敛的角色（如某个技能训练节点自己对照 benchmark 打分、自判 success/fail）——这类节点不需要外部验收节点，它自己就是判词来源。与 executor.json 的区别：executor.json 假设产出是可运行代码，验收靠自测 + testdata/coder 类 validator 判 acceptance 契约；本骨架没有这套代码测试语义，也不引入验证 agent——校验交给宿主节点在 org graph 边上已经声明的 produces 契约（引擎按 required kind 检查文件是否真的产出，见 graph-engine.js 的 PRODUCES_MISSING）。这条边界踩错的真实案例：①把 org-hunt（调研/知识产出节点）套进 executor.json 后，workgraph-planning 两次现场重规划分别选了 qa-judge（陷入 critic/judge 合一导致的无限重复确认，判 infra_flake）和 testdata-validator（死等一份任务本身不会产出的 acceptance.json，判 input_underspecified），两次都在验证层卡死，烧了 20 次调用/31 分钟才熔断——根子是这类任务从设计上就不该套代码测试范式的验证 agent。",
   "ownerOrgNode": "{{orgNode}}",
   "dataContractNotes": "唯一节点的产出走 artifact（与 executor.json 一致），由宿主 org node 在 org graph 边上声明 produces；引擎按该声明检查文件是否真的落地，这是本骨架的唯一及格线。不引入验证 agent 是刻意的简化（ponytail：只查『文件有没有写出来』，不查『内容好不好』——这是当前上限）。若之后需要内容质量把关，按 2026 年生成器/评审者模式的设计经验加一个节点：judge 必须单次给出终态决策（通过 / 打回 / 转人工）+ 简短理由，不能反复迭代——critic（提修改意见）和 judge（下终态判决）合并成一个 agent 是已知会导致无限循环的反模式，千万别学 attempt-1 里 qa-judge 卡死的样子。",
   "nodes": [
-    { "nodeName": "{{orgNode}}-impl", "systemAgentId": "{{implAgent}}" }
+    {
+      "nodeName": "{{orgNode}}-impl",
+      "systemAgentId": "{{implAgent}}"
+    }
   ],
   "edges": []
 }