宜博 / lemonboss

{
  "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。",
  "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}}" }
  ],
  "edges": []
}