-
## 起因 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>
-
28-followups §3.1。**审计结论与那条待办原来的写法不一样，两列要分开处理。** ## source_kind：删 与 origin 一一映射（global_agent↔builtin / company_hired↔created）， 实查生产库 76 行零例外。全仓唯一读侧是 migrate() 里那条 origin 回填， 而那是给「origin 列出现之前写下的行」用的一次性迁移。 顺序：**先回填、再删列**，两步都用 hasColumn 守着（幂等）。反过来做不报错 —— 库能开、测试能过，只是那几行 origin 悄悄是错的。守卫 source-kind-drop-migration.test.js 走存量库重启那条路，专门钉这个顺序， 反向验过：弄反立刻红。 写侧散在 3 处生产 INSERT + 35 个测试文件。批量改的时候正则误伤了 4 处 （吃掉了 JS 默认参数、位置占位符、ON CONFLICT 的赋值行），逐个修回并复查了 diff —— **这种跨几十个文件的机械改动，靠「全量跑一遍」兜底比靠正则写得对更可靠**。 ## legacy_path：不能删，它还没死 原待办说「所有读取点都已改成从 id 推导」——那半句对新行成立，对存量行不成立： · 新行 legacy_path 恒等于 system/agents/{id}（确实冗余）； · **存量行里存着批次 4 之前的公司侧路径**，而 graph-seed-service 判「悬空行 / 孤儿行」 靠的正是这个路径指向的目录还在不在。从 id 推导出来的路径永远指向 system/agents/， 那条判据会整个失效。 实查生产库：76 行里还有 2 行是老路径（org-planner / org-coder 指着已不存在的 data/companies/mycompany/agents/）—— 正是这条判据要认出来的那种行。 退出条件写进了 graph-db.js 的建表注释（不只留在文档里）： 库里不再有 legacy_path <> 'system/agents/' || id 的行。 ## 顺带记一条：getDb() 会就地迁移生产库 删列那次，生产库的列是被一条**查状态用的**一行 node -e 删掉的 —— 服务当时没重启，人也没打算迁移。结果是对的（幂等；与备份逐行核对 76 行一致、 origin 全部按映射回填正确），但「读一下状态」不该顺手改 schema 这件事值得知道。 闸门只挡测试进程，故意不挡普通脚本（挡了服务自己也起不来）。 注释里给了只读的正确姿势。 全量：140 文件 / 1299 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
界面走查（真 server + HTTP + 真 AgentManager，底层 mock 协议）已把 manual 模式全流程点通：org 节点起子图 → 下钻 work graph → 单步 → 第 3 步触发回退（徽标 0/3→1/3、run 级 1/5 双层计数同时可见）→ 归因记录与 remediation_note 完整送达 → 收敛后父节点结算、左栏前移。 mock 侧补两处缺失接线（都是「四环漏一环」，非新功能） - ClaudeCliProtocol._sendMockPrompt 按 agent 类型查 fixture：图执行侧的 agent 名带公司前缀（resolveAgentName 返回 {cid}:{id}），fixture 不该 按公司复制一份。DevLoop 侧名字不含冒号，行为不变 - graph-engine.defaultAgentExecutor 接住 mock/files 事件：此前只有 DevLoop 的 loop-controller 接，图执行侧没接，于是 mock 下 readNodeProduct 永远找不到 attempt-{n}.json，validator 系节点恒 blocked。 写入限制在节点产物目录内，越界丢弃并留痕 新增 5 份 P3 fixture（workgraph-planning / prd-planning / sdd-planning / coder-validator / validator-triager），coder-validator 用 sequence 演示 一次回退。图必须放 chunks 不能只放 result——callAgent 的 output 来自 流式 chunks，session/result 的文本不进 output。 控制台入口：CompanyDashboard 加「🕸️ 执行控制台」按钮（路由早已注册， 此前无任何入口，只能手敲 URL）。 scripts/p3-demo-setup.js：手工测试准备脚本（雇人+写图+起 run），头部 写明它是两个已知缺口的绕行，缺口修好后第 1 步即可删。 _registry.json 补齐 6 条本体登记（brd/prd/sdd-planning、goal-benchmark、 benchmark/testdata-validator）——同轮新增的 template-refs 防线测试正是 因为缺这 6 条而变红，防线抓到了「交付与报告不符」。 文档 - 27-REQ R-18：招聘归 workgraph-planning（方案 a）、停用 mock 改真 CLI - 27-P3B 真实运行前置（新增）：11 个工作项分三批，含现状核实 10 条证据 （seedTemplates 无运行时调用方、10 条悬空 company_hired 行、 FAILING_VERDICTS 不含 "fail" 导致验收假放行等） 测试 719/719 全绿（66 文件）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
按 27-p3-p4-work-graph-console.md v0.3 实现，三轮开发+校验后测试全绿 （693/693，P2 26/26、DevLoop 230/230 未被打破，web:build 干净）。 服务层 - work-graph-db.js 定义层(work_graph_*) + 运行时层(graph_runs/graph_run_nodes/ graph_run_loop_records) 五张表；状态转换表照 unit-registry 模式； 复用 org-graph-service 四项校验 + 新增第五项 fail-fallback-edge - graph-engine.js advanceOne 幂等原语；agent_call / subgraph 两种 executor； 手动与自动共用同一原语；双层熔断（单边 loop_count + 按 root_run_id 共池的 backward_count）；任务级预算挂 root run；三层暂停/停止级联； 重试按 contract_hash unchanged 判据 - graph-run-sse.js 按 run_id 广播，状态转换+timeline+SSE 三者原子化 - goal-contract.js 验收契约格式与执行器（R-15.6 验收先行） 引擎泛化（R-15.4）：org graph 与 work graph 走同一套 advanceOne， 定义层两套、运行时层一套，三层下钻用 parent_run_id 链。 R-16 失败归因：validator-reflection 专职归因节点；fail_reason 多边路由 （精确匹配→兜底边→死路）；子 run 收敛透传 success/fail + fail_reason + remediation_note 三值；infra_flake 不烧任何计数。 路由 / 前端 / 模板 - routes/graph-run.js 八个端点；company.js 任务入口 - WorkGraphCanvas.vue 扩展 UnitsDAG（subgraph 角标、backward 虚线曲线、 N/3 循环徽标、异常流程视觉降权）；GraphConsole.vue 三栏 + 四 tab 详情 - 五个新 agent 模板：validator-reflection / org-validator / planner-validator / coder-validator / workgraph-planning 命名统一（R-15.3 + NAMING §三）：org 节点改为 org-{职能}， 三个 org-graph 模板末节点收敛到 org-validator；org_graph_edges 加 fail_reason 列并把唯一索引补上该列（避免精确边与兜底边互相吞掉）。 三轮校验修掉的主要缺陷：subgraph 重跑不起新子 run 导致永久死锁； SSE/timeline 零调用方；org 侧 fail_reason 写入被丢弃；fail-fallback-edge 只做了一层；backward_count 跨 run 树重置架空熔断外层； seedEntryNodes 误点亮只有 fail 入边的节点。 已知缺口见后续提交：remediation_note 仅在 backward 边落库、 total_tokens 预算维度无生产方。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>