-
## W14 · POST /:cid/tasks 补上前端调用方 该端点此前**全仓库没有任何前端调用方** —— 界面走查确认过：用户在控制台上 没有任何办法给公司下达任务，只能 curl。这是「实现在、零调用方」在 P3 里的 第 N 次出现（W8 刚给 replan 补上，tasks 还欠着）。 新增 DispatchTaskButton.vue： - 手动/自动**在下达时就选**，不是跑起来再改 —— execution_mode 是 run 的属性， 起 run 时定；后补一个下拉会让人以为能中途换 - 自动模式在这一步就给成本预警（真 CLI 一次中等任务 $10-20 / 1-2 小时）， GraphRunPane 的「启动」那道确认是针对已有 run 的，下达是更早的闸门 - 409（v1 并发约束）连同服务端 hint 原样透出，比翻译成「出错了」有用 - run 在跑时按钮直接不出现，而不是让人点了吃 409 挂载：有图未跑 run 时给主操作位（这时候它是页面唯一该做的事）， 有 run 时收进标题栏。顺手修 .left-actions 缺 gap 导致两个按钮重叠。 ## 第二次真 CLI 冒烟（worktree 隔离，主仓库 data/ 零写入） 链路比上一轮走得远得多，两个硬缺陷的修复都在真跑中直接验证： 1. **R-18.1 端到端成立**：POST /create 自动触发 orggraph-planning 真跑， 它自己把图落库（3 节点 4 边，含两条 backward fail 边）**并自己雇了 org-planner / org-coder / org-validator** —— Step 7 的招聘真执行了。 2. **W5/W6 自雇再次验证，且规划质量明显更高**：workgraph-planning 规划出 brd → prd → benchmark → validator 四节点主干，两条回退边一条带 fail_reason=input_underspecified、一条无 reason 作兜底 —— 它自己用上了 D.2.2 的细分路由并满足 fail-fallback-edge 规则。四个本体全部自雇。 3. **守卫归属修复直接命中**：timeline 里 「本次调用窗口内有 1 处 agent 运行态文件改动，无法归属到本节点，不计入越界 unattributable = ['M system/agents/agent-creator/.claude/scheduled_tasks.json']」 ——正是上一轮把成功节点判成 fail 的那个文件，这次被正确摘出， org-planner-brd → **success**（上一轮它跑起来了但被误判）。 4. tokens 真的在计量（24,218），mock 下恒为 0。 产出位置正确：brd.md 落在 runs/<rootRunId>/nodes/<nodeRunId>/， 项目根 projects/p-4hjo36 按 root run 分配。worktree 源码跑完已复原到跑前状态。 测试 760/760 全绿（72 文件）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
真 CLI 冒烟（worktree 隔离，PORT 3010）九轮来首次把 work 节点跑起来： orggraph-planning 真跑 3 分钟自主裁成单 org node 零边图 → workgraph-planning 第 1 轮产出合法图 → **自己按 Step 6 把 brd-planning / planner-validator 雇进公司** （W5/W6 核心验收成立，且 W7 判据生效、两者都没写进 org_graph_nodes）→ 第一个 work 节点 brd-planning 真起 CLI 子进程，产出 brd.md / contract.json / attempt-0.json 全部落在 run 目录内。图内预算仅 2 次调用 / 13998 tokens（上限 15）。 W5/W6 · workgraph-planning 自雇：撤掉「你不招人也不辞人」，Step 6 加招聘环节， 写死「先雇、再提交图」的顺序，给出失败分级与幂等要求 W7 · work 层招聘不写 org_graph_nodes：按 type 与 work graph 骨架点名两条判据区分层级， P2 「hire org 角色 → org graph 出现该节点」的语义保持不变 W8 · 控制台「规划组织结构」按钮（抽成 ReplanOrgGraphButton.vue，带过渡态与秒表）， 接 POST /:companyId/org-graph/replan（该端点此前无任何前端调用方）； 新增 fixtures/devloop-mock/orggraph-planning.json W12 · 节点失败留痕：node.output 带 output_excerpt、新增 node.error 事件。 真跑当场救场——守卫误判那条归因正是靠它才查得出来， 换成之前看到的只有「节点 fail、无原因、无痕迹」 测试 753/753 全绿（71 文件，起点 736/68）。 已知未修（下一轮）：子 run 转终态不回写父 node_run 导致任务永久卡死； applyBoundaryGuard 用整仓 git diff 判归属会把并行 agent 的写算到当前节点头上； W12 的 fail_reason 未落库（概览 tab 仍为空）；POST /:cid/tasks 无前端调用方。 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>