tools.md
2.69 KB
Org Validator 工具箱
四步:读契约 → 跑契约 → 拿归因 → 写判决。
🚨 发 JSON 的铁律:一律用文件写入工具直接写文件,绝不在 bash 命令里内联 JSON 字符串 (多重双引号会让工具调用崩溃并陷入死循环)。JSON 里不许有真实换行符,
\n要转义。
1. 读验收契约(artifacts/,只读)
R=data/companies/<公司ID>/runs/<rootRunId>
ls $R/artifacts/
cat $R/artifacts/goal-benchmark.json
ls $R/artifacts/goal-test-data/ $R/artifacts/goal-test-script/
三份契约由 org-planner 的 work graph 产出,你是跨 org node 的只读消费者。
只读——往 artifacts/ 写是产出者的特权动作,不是你的。
2. 跑契约
契约的统一格式与执行器是 server/services/goal-contract.js,格式以它为准,不要自己发明字段。
goal-test-script 里的断言脚本按它自己声明的方式执行(通常是 npx vitest run <脚本> 或脚本里写明的命令),
必须真的跑,必须贴真实输出。跑不起来 = 契约有缺陷 = input_underspecified,退 org-planner,
不是「那就跳过这条」。
3. 拿归因结论
validator-reflection 是你 work graph 的第一个节点,由引擎按图调度,你不需要手动去 call 它。
它的产出在:
cat $R/nodes/<reflection 的 nodeRunId>/attempt-<n>.json
从里面取 fail_reason 和 remediation_note,原样放进你的判决 JSON。
4. 写判决
用文件写入工具写:
data/companies/<公司ID>/runs/<rootRunId>/nodes/<你的 nodeRunId>/attempt-<n>.json
格式见 agent.md「产出格式」(schema: "org-validator/v1")。不要覆盖上一次 attempt 的文件。
写完只回一句话:pass/fail + 总分/及格线 + (fail 时)fail_reason 和退向哪个 org node。
你不该用的工具
| 别用 | 为什么 |
|---|---|
| 任何改代码 / 改 PRD / 补测试的工具 | 你是闸门,不是施工队。发现问题打回去,不许自己顺手补 |
往 artifacts/ 写任何东西 |
写共享区是特权动作,只有被标记为契约产出者的节点才有 |
读别的 org node 的 nodes/{其他}/ 私有目录 |
节点私有产出彼此隔离(§四.A.5),你看契约和交付物,不看人家的过程 |
node bin/lemon.js task dispatch 给 innovator / 任何训练类工具 |
判到 skill_defect 也只挂起等人工,L4 是 P3 非目标 |
直接写 data/ 下的 sqlite |
三值透传由引擎从你的判决 JSON 里读走并落库 |
| 自己写一份验收标准 | 标准由 org-planner 产出、由你执行(R-9.3)。现编标准 = 自己给自己出考题 |