-
48 号文档补做收口：调研另外三条任务创建路径（task-planning/ org-planner 的 acceptance_item 物化/人类快速派单）是否需要同款 acceptance_contract 强绑定,结论是不需要——都走完整 org graph, workgraph-planning 的 benchmark 节点"不可裁"约定已天然保证契约存在, 强行加会与 task-planning 的极简边界、快速派单的零 LLM 定位冲突。 顺带梳理 todo/system-design 下已完成的文档,移入 done/: 31/32/34/43/45/47 号（含此前漏收录进索引的 32 号文档),并修正 因搬家产生的相对路径死链（44号/46号 对 43/47 号的引用)。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UP1omSsXkyGhopHvWeSnyy
-
44 号：writesArtifacts 节点产出闸门永远打不过 - goal-benchmark 按设计把产物写进 root run 共享 artifacts/ 目录（三个节点合成同一份 acceptance.json，天然不可能落在某节点私有目录），但 unsatisfiedRequiredProduces 的 R-19 逃生口 readDeclaredProduces 的 allowedRoots 只认节点私有目录 + 项目根，够不到 共享区——这条契约在当前实现下无论 agent 表现多好都无法通过。 - 修法（44 号文档方案 1，改动面最小）：allowedRoots 加入 runRootDir(run)/artifacts/； goal-benchmark 的 agent.md/tools.md 补上"写完共享产物后在自己节点私有目录声明一份 contract.json"这一步。 - 回归：graph-files-index.test.js 新增用例 ⑭。 41 号：routeFailure 的 infra_flake 分支完全无视 target_node - 30 号文档记录过一次真实死循环：节点自称 infra_flake 并点名 target_node，引擎原来 一律原地重跑该节点自己，从不看 target_node。 - 修法（最保守方案，用户确认）：新增 infraFlakeTargetEdge——target_node 只有在图上 真有一条从本节点出发的 backward fail 边指向那个节点时才生效，命中就改走正常的 backward 边路由（计入 backward_count/双层熔断），不再享受"原地重跑、只受 infra_flake_count 约束"的免账本待遇；没命中维持原有行为。 - 重要澄清：这条修复堵不住 30 号文档那次真实事故——事故里点名的目标是下游节点， 而 org-graph-service.js 规则 4（backward-labeled）从图结构上就不允许 backward 边 指向非祖先，那次事故本来就不是"有边不认"，是"诊断内容在打图结构不允许表达的 主意"，已经靠 INFRA_FLAKE_HARD_CAP 熔断收敛，不在这条修复范围内。 - 回归：graph-engine.test.js 的 infra_flake describe 块新增两条用例。 44 号文档移入 done/，41 号清单项相应更新，43 号文档的交叉引用一并修正。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CwGcvMfUcgCcweN5vjhTkn