-
## 起因 e2e-demo 真实任务卡住:org-planner-sdd 自己判 input_underspecified 并点名 org-planner-prd,但这张图里 sdd 没有任何 fail 出边——精确匹配、 兜底边两条路都接不住,节点直接 blocked,靠人工点了「重试」才续上。 ## 根因 fail-fallback-edge 校验(27-P3/P4 §三.7 第五项)只在节点已经画了别的 fail 边时才检查兜底边齐不齐。一条 fail 边都没有的节点完全不受约束—— workgraph-planning/agent.md 原文明说这是「合法设计」。但系统里所有本体 共用 _base 的四段式协议,VERIFY 阶段任何 agent_call 节点都可能自判 失败,不止专职判词节点。四个骨架模板审计后发现 6 个中间节点存在同一个 漏洞(sdd 只是撞上的那一个)。 ## 决策 除图的唯一入口节点外,每个节点必须留一条兜底边(判据是 forward 入度, 不是节点名字模式)。org 层暂不动——node 全是 subgraph 类型,失败来源 机制不同,且套用同一条规则会让三个 org 模板立刻不合法,属于 27-p3b 「验收9」还没收口的链路,留给那边一起做。 中途发现无条件收紧会炸 46 个用例/13 个文件(createWorkGraph 被大量 测试当成建最小图的通用工具)。改法是加 strict 开关,默认关闭(行为 不变),只在 workgraph-planning 真实提交图落库的那个唯一入口 (createWorkGraphSafely)打开。 ## 改动 - work-graph-db.js / graph-engine.js:新规则 + strict 开关 - planner.json / executor-fanout.json:补 6 条兜底边 - workgraph-planning/agent.md:约束三等四处措辞同步 - 新增单测:strict 模式 7 例 + 真实链路回归用例(真实引擎代码+真实 DB+只换最外层 CLI 子进程,复现 sdd 自判失败后引擎自动路由到 prd, 全程零 retryNode 调用)——比重跑一次真实任务更严格,可回归、进 CI 978/978 单测通过。需求与决策记录见 docs/todo/system-design/31-work-graph-fail-fallback-coverage.md。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>