-
代码修复： - SessionPool 的 scope 参数从未真正从 graph-engine 传到 AgentManager，导致 fan-out 场景下同一 agent 的并发调用会撞会话键；补上生产接线（graph-engine.js/agent-manager.js） - advanceTree 改成 Promise.allSettled 并发推进兄弟子 run（原来只推最深的一个） - graph-real-chain-smoke.test.js 补齐多节点/回退边/双层熔断的真实链路覆盖 真实验证： - 27-P3B 最后一条验收（org 层回退边指向 subgraph 节点）用隔离 worktree 真实 Claude CLI 跑通并记录证据（§六quater） - 27-P3B 正文里 W5/W6/W7/W9 的"仍未验"备注核实后发现均已被此前的真跑验过，只是没回填； W8（重新规划组织按钮）此前确实没验过，本轮用隔离 worktree + 真实浏览器点击补验 文档收口： - 27-P3B、27-P4 两份文档功能与验收均已完整，移入 docs/done/，更新全部交叉引用 - T5（账户欠费门真实计费接口）按用户决定移入 docs/todo/future/，不阻塞收口 - 订正两处过期判断：graph_edge_contracts.role 列早已落库、CONVENTIONS.md 非 spec:extract 生成物 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
先搭桩子，不接真实计费接口（用户明确选择：真实欠费判据依赖计费系统那边确认， 现在只把可插拔的挂载点和恢复机制先落地，接口确认后再换真实实现）。 新增： - setBillingGate(fn)：与 setAgentExecutor/setPlanWorkGraph 同款注入模式，未注入 时 checkBilling 恒返回「未欠费」，对现有行为零影响。 - checkBilling 挂进 advanceOne 与 advanceBatch，紧跟 checkBudget 之后——两者是 不同维度的门（任务级预算池 vs 账户级欠费），不合并成一个判据。 - 欠费挂起复用现成的 suspendRunTree（预算耗尽走的同一条路），只是 reason 换成 'billing-arrears'。suspendRunTree 加 reason/summary 参数，并把 reason 写进新增的 graph_runs.block_reason 列（欠费清零后的自动恢复扫描要按它过滤，不用解析 timeline 文本）；startRunSync「启动」时清空这一列。 - resumeBillingClearedRuns()：欠费清零后的自动恢复触发器——今天从 blocked 恢复靠 人手点「启动」，欠费清零不会有人去点，这个函数补上「扫一遍 block_reason= billing-arrears 的 blocked root run，欠费真清了就代它点启动」。调度触发源 （webhook/轮询）留给计费接口接通之后再定。 顺手修了一个 advanceBatch 的排序 bug：budget/billing 门必须在「确认真有 ready 候选」之后才查，跟 advanceOne 的既有顺序一致——反过来会把一个已经收敛、只是 恰好预算也花完了的 run 误判成「挂起」而不是正确收敛到 completed。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
自动模式的驱动原语 advanceTree 里 advanceOne 换成 advanceBatch：树上「最深 active run」的选取逻辑不变，但推进这一步现在能一次并发 claim 一批 ready 节点， 而不是每 tick 只推一个。核实过 advanceTree/runAuto 的返回值全仓库只被读 .ok， 不依赖 .node/.results 的具体形状，不需要兼容层。 顺带抓到并修了一个真 bug：advanceBatch 的 no-ready-node / taken-by-other 分支 原来写的是 ok:true，跟 advanceOne 用 result() helper 的惯例（这两种情形一律 ok:false）不一致。不修的话接进 runAuto 后，一个已经收敛的 run 会被自动循环 一路空转到 maxSteps 才停——旧测试从没对已收敛的 run 连续调 advanceBatch， 所以这条一直没被撞出来。 新增两条测试：ok:false 语义与 advanceOne 对齐（直接绕开引擎构造边界状态）； runAuto/advanceTree 端到端确实吃到并行（用真实 setTimeout 延迟证明并发窗口 重叠，不是同步假象）。全量 vitest 147 文件 / 1350 用例，零回归。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
planner 骨架（brd→prd→sdd→goal-benchmark→validator）复现：三个 planning 节点 声明了 produces 却没真落盘，executor 没抛异常就被引擎判 success；goal-benchmark 的入边 needs:[brd,prd,sdd] 只用来拼提示词里的 ⚠️ 提示，agent 视而不见照样产出 合法 acceptance。下游 validator 永远读不到三份文档，backward 重试撞循环硬顶后 只能人工兜底。 settleNode 判 success 之前新增两道闸门（均只对 agent_call 节点生效，subgraph/org 节点的契约由子 work run 自己的节点过闸）： - unsatisfiedRequiredProduces：声明的 required produces 一个候选文件都没落盘 → fail_reason=produces_missing，不再放行 - requiredInputsMissing：声明的 required needs 在 graph_files 里查不到实例 → fail_reason=missing_required_input，不采信 agent 自报的 success 两者都只判「有没有」，不判「分类对不对」——ambiguous 归类留给下游 ⚠️ 提示词处理， 避免把「写了东西但引擎猜不出对应哪个 kind」误判成没执行。 包含此前已完成但未提交的 27-P4 T3（graph_runs.max_concurrency 落库）及配套 advance-batch 测试。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>