宜博 / lemonboss

Commit 5879917da5e370dfe30ccabc268b9825e800f7f5

Authored by yibo
1 parent 0282033b

fix(workgraph-planning): 补第 6 个缺陷——按名字语义匹配误选 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 收敛，全流程干净跑完。41 号文档收尾——
11 轮真跑挖出的 6 个独立缺陷全部修复并逐条验证生效。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Inline Side-by-side
Showing 3 changed files with 42 additions and 4 deletions
docs/todo/system-design/41-graph-vs-fde-reliability-discussion.md
  View file @5879917
... ... @@ -316,8 +316,28 @@ FDE 无关，纯粹为了让 org-hunt 做真调研）反复 `rerun` 同一个 ta
316 316 这个路径是我的 kind=X 产出"的机制——这个改动面比三个 agent 大得多，影响所有 org node，
317 317 未拍板是否要做，留作独立跟进项（见下一条）。两轮真跑（5、6）都靠 `contract.json` exports
318 318 兜底成功，当前不是阻塞性问题。
319   -- [ ] **`indexNodeOutputs()` 覆盖项目根产出**——上一条挖出的架构级缺口，工作量和影响面都明显
320   - 大于这次的三个 agent，需要独立评估要不要做、怎么做（改索引扫描范围 vs 加显式声明机制）。
  319 +- [x] **`indexNodeOutputs()` 覆盖项目根产出——已修复并验证生效**（2026-08-30）。改法：
  320 + `contract.json` 新增 `produces: {kind: 绝对路径}` 显式声明字段（`readDeclaredProduces()`），
  321 + 校验通过（绝对路径/落在项目根或私有目录内/文件真实存在）才登记，不满足整个 kind 判
  322 + 「没产出」；全局提示词（`describeArtifactContract`）同步教会所有 org/work 节点。
  323 + 第 9~12 轮反复真跑验证：`org-hunt`/`org-digest`/`org-evolve` 声明的产出（不管物理落在
  324 + 私有目录还是项目根）全部正确索引，`recordFile` 逐条确认成功。已提交（`496c249`），
  325 + 补了 2 条守卫测试（`graph-files-index.test.js` ⑫⑬：声明生效 / 越界声明被拒）。
  326 +- [x] **第 6 个独立缺陷：workgraph-planning 按"名字语义匹配"误选 validator.json 专属本体**——
  327 + 第 11 轮 `org-evolve` 规划验收节点时，选了 `benchmark-validator`（"对评分结果做验收判决"，
  328 + 名字很贴切），但该本体硬编码读 `artifacts/goal-benchmark.json`（只有 `planner.json` 的
  329 + `goal-benchmark` 节点才产），这条 Hunt→Digest→Evolve 链路里根本没有该节点，两轮都判
  330 + `blocked`。根因：`benchmark-validator`/`testdata-validator`/`validator-triager` 不是
  331 + 通用验收工具，是 `validator.json` 骨架专属、绑定任务级共享契约文件的本体。**已修**：
  332 + `workgraph-planning/agent.md` 加第三条硬规则（判据从"名字像不像"改成"这条链路里有没有
  333 + 节点产 goal-benchmark.json/acceptance.json"）；`deliverable.json` 的 `whenToUse` 补上
  334 + "自带自评分收敛逻辑的节点也不需要外部验收节点"这条例外条款并点名这次事故。第 12 轮
  335 + 真跑验证：`org-evolve` 的规划记录原文直接引用了新条款选中 `deliverable.json`，
  336 + `backward_count=0`，评分 83/行业均线 78 收敛，全流程干净跑完。
  337 +- [x] 至此，11 轮真跑挖出的 6 个独立缺陷（7.0 竞态 / 模板库缺口 / 验收节点任务描述越权 /
  338 + 两个规划 agent 路径口径 / R-19 索引覆盖 / 名字语义匹配误选专属本体）全部修复并逐条
  339 + 验证生效，第 12 轮起连续跑通。工作已提交（`496c249`），与另一并行会话的工作
  340 + （boss agent 看板 / 打字机流式打断，39/40 号文档）无冲突合并。
321 341 - [ ] `routeFailure` 的 `infra_flake` 分支补上 `target_node` 路由（30 号文档遗留的"刻意没做②"）。
322 342 - [ ] `27-p4-parallel-and-artifacts.md` 并发 fan-out 设计推进。
323 343 - [ ] boss agent（暂定挂在 CEO 身份下）：主动巡检 goal/task/work 状态、卡住/漏结算主动喊人，功能待从零设计。
... ...
system/agents/workgraph-planning/agent.md
  View file @5879917
... ... @@ -105,6 +105,21 @@ for f in $REPO/system/work-graph-templates/*.json; do echo &quot;=== $f ===&quot;; cat &quot;$f
105 105 **必须**把 `deliverable.json` 的 `whenToUse` 逐字读一遍再决定要不要用，不能因为
106 106 `executor.json` 更眼熟就默认用它、把 `deliverable.json` 漏出候选表之外。
107 107  
  108 +⚠️ **第三条硬规则（2026-08-30 真实事故加的）**：`benchmark-validator` / `testdata-validator` /
  109 +`validator-triager` 这三个本体**不是**通用的"给我一个验收判词"工具——它们是 `validator.json`
  110 +骨架专属的，硬编码读 `artifacts/goal-benchmark.json` / `artifacts/acceptance.json` 这两份
  111 +**任务级共享契约文件**（`goal-contract.js` 的输入），而这两份文件只有 `planner.json` 骨架里的
  112 +`goal-benchmark` 节点会产。真实事故：给 `org-evolve` 规划验收节点时，看名字"语义匹配"选了
  113 +`benchmark-validator`（"对评分结果做验收判决"，听着很对），但这条任务链路里根本没有
  114 +`org-planner`/`goal-benchmark` 节点产出那两份契约文件——`benchmark-validator` 一读就是
  115 +`goal-contract.js validate` 退出码 2「没有 acceptance.json」，两轮都这样，整个节点判
  116 +`blocked`。**判据不是"名字听起来像"，是"这条任务链路里有没有节点产 `artifacts/goal-benchmark.json`
  117 +/ `acceptance.json`"**——没有，就不能挂这三个本体，不管名字多贴切。
  118 +且大多数情况下你根本不需要一个外部验收节点：如果宿主 org node 自己的 agent.md 里已经写了
  119 +自我评分/自我判定收敛的逻辑（`org-evolve` 就是——它的 Small Loop 本身会对照 benchmark 打分、
  120 +判 `success`/`fail`），那就是 `deliverable.json` 的单节点起手式，不需要额外挂任何验收节点，
  121 +不止是"不挂 benchmark-validator"这一步。
  122 +
108 123 ### Step 3 · 读可引用的 system agent 本体
109 124  
110 125 ```bash
... ...
system/work-graph-templates/deliverable.json
  View file @5879917
1 1 {
2 2 "id": "deliverable",
3 3 "label": "内容型交付物 org node 的 work graph（单节点起手式）",
4   - "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。",
  4 + "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。",
5 5 "ownerOrgNode": "{{orgNode}}",
6 6 "dataContractNotes": "唯一节点的产出走 artifact（与 executor.json 一致），由宿主 org node 在 org graph 边上声明 produces；引擎按该声明检查文件是否真的落地，这是本骨架的唯一及格线。不引入验证 agent 是刻意的简化（ponytail：只查『文件有没有写出来』，不查『内容好不好』——这是当前上限）。若之后需要内容质量把关，按 2026 年生成器/评审者模式的设计经验加一个节点：judge 必须单次给出终态决策（通过 / 打回 / 转人工）+ 简短理由，不能反复迭代——critic（提修改意见）和 judge（下终态判决）合并成一个 agent 是已知会导致无限循环的反模式，千万别学 attempt-1 里 qa-judge 卡死的样子。",
7 7 "nodes": [
8   - { "nodeName": "{{orgNode}}-impl", "systemAgentId": "{{implAgent}}" }
  8 + {
  9 + "nodeName": "{{orgNode}}-impl",
  10 + "systemAgentId": "{{implAgent}}"
  11 + }
9 12 ],
10 13 "edges": []
11 14 }
... ...