validator.json 2.47 KB

Edit Raw Blame History



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

{
  "id": "validator",
  "label": "org-validator 的 work graph（归因排第一位）",
  "whenToUse": "宿主 org node 是 org-validator（org graph 末端那个「整个任务达成了吗」的节点）时**必须**用本骨架。它与另外两个骨架的硬性区别：第一个节点必须是归因节点 validator-triager——先归因、再决定后面怎么验/怎么退（27-P3/P4 §四.D.3）。它产出的 fail_reason + remediation_note 会透传回 org 层，成为 org graph 选走哪条 fail 边的唯一依据（§四.D.0 三值透传 / §四.D.2.2 选边）。少了这个节点，org 层失败后不知道该退回 org-planner 还是 org-coder。宿主不是 org-validator 就别用本骨架。",
  "ownerOrgNode": "org-validator",
  "dataContractNotes": "本图两条 forward 边只有 needs 没有 produces，这是刻意的：归因节点的判词写在 attempt-{n}.json 里、由引擎自己读（readNodeProduct），产出侧刻意把这个文件名排除在产物索引之外，benchmark-validator 的评分同理只喂给 goal-contract.js 的执行器；写 produces 会让每一轮都出现一条「声明了会产出但索引里查不到实例」的 ⚠️ 假警报。被验产物由上一层 org graph 的执行节点（org-coder 等）产出、不在本图，所以 needs 标 required:false——这既是规则 6（data-contract）的逃生口，也是本骨架能过校验的原因；产物索引按 company + task 查、不按图，路径照样递得到。验收标准 acceptance 由 org-planner 那张图产出，属任务级共享，引擎自动递（节点上的 readsArtifacts 已经把它写明），不沿边声明。",
  "nodes": [
    { "nodeName": "validator-triager", "systemAgentId": "validator-triager" },
    { "nodeName": "benchmark-validator", "systemAgentId": "benchmark-validator", "readsArtifacts": ["goal-benchmark.json"] },
    { "nodeName": "testdata-validator", "systemAgentId": "testdata-validator", "readsArtifacts": ["goal-test-data/"] }
  ],
  "edges": [
    { "from": "validator-triager", "to": "benchmark-validator", "condition": "success", "needs": [{ "kind": "artifact", "required": false }] },
    { "from": "benchmark-validator", "to": "testdata-validator", "condition": "success", "needs": [{ "kind": "artifact", "required": false }] },
    { "from": "benchmark-validator", "to": "validator-triager", "condition": "fail", "edgeKind": "backward" },
    { "from": "testdata-validator", "to": "validator-triager", "condition": "fail", "edgeKind": "backward" }
  ]
}