-
## 起因 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>
-
system/templates/ 已随 28 号改造整体并入 system/agents/，目录在磁盘和 git 里都已不存在。 但引用还散在各处，其中几处是 agent 运行时真会照着读写的： 本体提示词（读不到就静默降级，不报错） workgraph-planning/agent.md system/templates/base/ ×3、模板库路径 ×1 orggraph-planning/agent.md 同上 ×1 orggraph-planning/tools.md ×1 org-innovator/agent.md 四条产出落点 system/templates/weibo-scraper/train/* skill 代码里的硬编码目标 evolver-youtube-crawler 的 refactor.js / mock_setup.js / evolve.js 共 4 处 innovator-hunt/collect_seed.js —— 这处是真 bug 且已发作过： 写的是裸相对路径 'system/templates/…'，相对 cwd 解析，于是在 agent 自己目录下 造出一棵野生嵌套树 system/agents/innovator-hunt/system/templates/… 现在改成由 __dirname 推导，不再依赖 cwd（cwd 已经是深度 3 的任务态目录） 图模板契约（work-graph-templates / org-graph-templates 的 README） CI 防线的三条规则写的还是「在 system/templates/ 下必须有目录」「在 system/templates/_registry.json 里必须有条目」，与实际执行的检查已经对不上 DevLoop PRD（13 份 HTML + 重新生成的 52 份 _spec + build-manifest + search-index） 写的是 system/templates/devloop-pm.md（扁平 .md）。根和形状都错： loop-controller.js:166 实际读的是 system/agents/{agentName}/prompt.md。 按真实形状改，然后跑 spec:extract / extract-manifest / build-search-index 重新生成。 顺带订正两处早于本次改造就已过期的内容： - 「避开 6 个命名冲突 id」这条约束列的 digester / evolver / hunter / innovator 四个 id 根本不存在（早已改名），而它的理由（两个目录下各有一份、内容不同步） 也已随合并消失。约束保留（元 agent 本来就不该进执行流），理由与清单按实际本体重写。 - orggraph-planning/agent.md 里「真相源是 company.json.agents[]」—— 28 号起真相源是 company_agents 表，company.json.agents[] 仅作兼容保留。 刻意不动的三类（改了是净损失）： 历史说明 server/ 下解释「原来指向 X、批次 1 并进了 Y」的注释、docs/done/、tasks/ 完成证明 server/tests/ 里断言该目录已不存在的守卫 运行态记录 未跟踪的 workspace/ conversations/ 与 train/ 下的历次训练报告 新增 server/tests/unit/no-stale-templates-path.test.js 守住活定义这一档： 扫 system/ 与 fixtures/ 下被 git 跟踪的文件（跟踪=人工维护的定义， 未跟踪=运行态产物），零例外。带「样本非空」前置断言防 git 失灵时退化成永远通过。 改坏一处实测能精确点名到文件行号。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
第六次真 CLI 冒烟 gapClosed=true：org 层契约落库 4 行（此前恒 0）， 且那段文字真的进了 workgraph-planning 收到的提示词（52677 字节，第 746 行起）。 ## workflow 四路并行的产出 - **org 层两半一起接**（关键顺序）：先接读回方 buildPlanningPrompt 的 ③bis 段 （org 边入边 → 上游绝对路径；出边 produces → 「你规划的子图必须有节点产出这些」）， 再接声明方 orggraph-planning 模板。只补模板的话就是又一次「声明了没人读」—— org 图节点全是 subgraph，而 describeInputs 对 subgraph 直接返回空。 resolveInboundLines 从 describeInputs 抽出共用，两侧口径物理上不可能漂移。 - **清掉 404 死路径**：模板三处教的 POST /api/company/:id/work-graphs 从未注册。 真跑复验：agent 侧零调用，改为按新 Step 7 写项目根绝对路径，还自己 require validateWorkGraph 预检了一遍才交回，round=1 一次过。 - **四张骨架补 produces/needs**：从「靠模板文字施压」变成结构保证，每张过规则 6。 真跑里 agent 照抄了 planner.json 并跟着任务删掉 sdd 节点——是改编不是复制。 - **graph-seed 顺序依赖**：靠生产代码里已有的 GRAPH_SEED_ROOT 缝隙指向冻结快照。 不是「跑几次都绿」结案：构造了原先必红的 churn，修前 12 次 3 红、修后 15 次 0 红。 ## 我自己收的 4 条 major + 1 条 minor（都在 graph-engine.js） 复验挖出「引擎自己拼的提示词在教 agent 做模板明令禁止的事」，同一条提示词里对立： 1. 「已自行落库成功时回一行 workGraphId: wg_xxx」vs 模板「你永远拿不到真的 wg_ id， 永远别写」。agent 没有任何受支持的落库途径，写出来必是编的，而 extractPlannedGraph 优先匹配那个形状、查库查不到就整轮作废。删掉邀请，保留引擎解析真实 wg_ 的能力。 2. 内联图示例的边一个 produces 都没有——agent 唯一见过的「边长什么样」是零声明的。 3. 「端点尚未上线」暗示将来会上线，于是它还想去试一次。改成「不存在、也不会上线」。 4. indexNodeOutputs 收集 declared 不按 role 过滤，把出边的 needs 当成本节点的产出。 Chrome 走查实测：产品需求文档.md 落成 artifact，下游 prd 输入变 ⚠️。 更坏的一面是错标（brd_notes.md 命中中继 needs[brd] → 归因给错的产出方）。 1ea9efa 加的 role 列，这里正是它存在的理由。 5. (minor) contract.prev.json（retryNode 的契约快照）被索引成 artifact 噪声。 新增 guard：引擎提示词不许与模板对立（静态读源码，剔掉注释行—— 第一版把「解释为什么不许说某句话」的注释也扫进去了，量错了对象）。 测试 850 全绿（83 文件），既有断言未改。5 处变异精确变红后逐字还原。 Chrome 走查确认控制台正常分支（此前只验过降级分支）：契约药丸、绝对路径、 needs 中继说明、tab 上的 ⚠️ 计数全部渲染，零 console 报错。 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>