-
测试 786/786 全绿（76 文件，起点 760/72），未改任何既有断言。 ## 本轮三件新东西，全部经真 CLI 验证 W12 补完 · 失败原因四环打通 - 引擎自判的失败（executor 抛异常、边界越界、子 run 无归因）现在也落 graph_run_nodes.fail_reason，不再只有 agent 归因产出的才有值 - 概览 tab 展示「[引擎判定] boundary_escape」+ 终端样式 excerpt， 取不到 fail_reason 时回落 output_excerpt，并标明来源 - 真跑实查：两行 fail_reason='boundary_escape' 都在库里， 产生→传递→落库→读回四环在真 CLI 下走通 W13 · 运行态文件根治（守卫误判的根因） - 17 个 todo.md / plan.md / scheduled_tasks.json git rm --cached + gitignore； 源码（agent.md/config.json/soul.md/tools.md）一个未碰，模板本体仍跟踪 - _registry.json 的 usedCount 挪进已忽略的 data/template-usage.json - 真跑验收：整轮（agent-creator、Master 各一次真 CLI、3 次 hire）结束时 worktree git status 与基线逐字相同，_registry.json 零 diff 单步进度感 · 真 CLI 一个节点 3-7 分钟 - 画布卡片秒表 + 详情面板常驻条「运行中 2m40s · 最近事件 …（2m40s 前）」 - 不做假进度条：引擎不知道 agent 还要多久 - 顺手修 NodeDetailPanel 不跟 SSE 走（否则秒表也不会动） W9 失败上下文进提示词、W10 跨层地址两半、W11 Hot Swap 显式告警同批完成。 ## 真跑结论：链路更长，但「work 节点 → success」仍未跑到 走到：orggraph-planning 落图自雇 → agent-creator 补定义 → workgraph-planning 真跑规划 + **先雇后提交**（W5/W6 再次成立）→ 子 run 起来 → work 节点 RUNNING → 7m19s 后 fail。两层原因叠加，都与 W1-W14 无关： 1. **新缺陷**：agent-manager.js:324 把 idleTimeoutMs 硬编码 120s， readme-writer 通读源码静默超 2 分钟被掐死（动笔前就死了）。 同进程 ClaudeCliProtocol 早把自己的 idle 上限放到 24h， stream-executor 的 JSDoc 默认值写的是 30 分钟 —— 这里把两者都压掉一个数量级； 且 ...options 透传的 idleTimeoutMs 会被下一行覆盖，调用方无法覆写。 2. **并行 agent 污染**：retrain-watchdog 每 5 分钟唤起的 Master 在同一工作树里 改了两个源文件，被守卫 git status 差集算到该节点头上 → 额外署 boundary_escape。 这是 W3「拦不住」第 5 条第一次真实发生。 顺带记一笔：这一轮任务是 **LemonBoss 自己的 Master 自主下的单**， 走的正是 POST /api/company/:id/tasks，它还自行诊断出了上面那个 idle timeout 并动手改（引用了未定义的常量，是坏的）。 ## 已知未修（下一轮） - idleTimeoutMs 硬编码 120s —— 「work 节点 → success」跑不通的唯一技术原因 - W7 在**零边最小图**上失效：判据③要求存在 active org_graph_edges， 零边图上三条判据全落空，work 层本体被写进 org_graph_nodes。 服务层那 9 例测试造的都是有边的成型图，正好绕开这个形状 - 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含： 一家公司只要失败过一次，控制台上就再也下不了第二个任务（后端其实放行） - 真跑期间工作树里不能有第二个 agent 活动，否则守卫判罚不可信 —— 应写进真跑规程 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> -
R-16（归因由专职 subagent 做，回退边多条）： - §四.D.2.2 归因改为 org-validator work graph 内的 validator-reflection 专职节点，与 DevLoop 的 Integrator/BugTriager 分工同构；给出四类 fail_reason 取值与 DevLoop 四分类的对照 - §四.D.0 子 run 收敛改为透传三值（success/fail + fail_reason + remediation_note），归因结论才能穿透子 run 边界供父层选边 - §四.D.2.1 熔断改为双层计数：单边 loop_count 防同路径死循环，新增 run 级 backward_count 防"换个借口继续退"——多条回退边各自计数会把 硬顶架空成 3xN；infra_flake 不烧任何计数 - §三.7 写入前校验新增第五项 fail-fallback-edge（强制兜底边） - schema：graph_runs 加 backward_count - 任务表加 T13/T14，验收标准加 9b/9c/9d - skill_defect 属 L4，v1 保留归因取值但动作降级为挂起等人工 base agent 四段式（新增 §九bis）： - 核实后原表述"已强制一套四段式生命周期"只对一半 - Context Flush / P0 事前阻断阀 / OKR 联动确实在跑 - Hot Swap 换技能包静默失效：system/skills/ 目录不存在， agent-chat.js:1908 的 existsSync 守卫使其空转且不报错 - 后果：EXECUTE 才拿破坏性权限只剩 prompt 话术约束，无机制保障 - phase 参数无取值/顺序校验，且被直接拼进文件路径 需求文档：补回 R-15.1 全文、R-15.4 后半、R-15.5、R-15.6 及速查表 对应行（此前被误回滚丢失），新增 R-16 条目。R-15.3 的命名表保留 NAMING §三 重写后的版本，未还原旧版。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
改名：task-benchmark / task-test-data / task-test-script → goal-benchmark / goal-test-data / goal-test-script 理由（推翻此前"验收标准跟着一次 task 执行走"的论证）：关键区分是基数。 一个人类需求描述 = 1 个 goal，是验收的边界；而 goal 在图中会分解出 N 个 task （并行分支、下钻的 sub agent）。验收回答的是"人类想要的东西做到了没有"， 这是 goal 级判定；挂在 task 上会导致"以哪个 task 的验收为准"无法回答。 NAMING §一 作用域表补入 goal / task 两行及其基数定义；§四 重写选型理由； §六 增加与 §四 的辨析注（OKR 从 goal 解放后，goal 被重新赋予"人类需求"新义）。 连带： - acceptance.json 的键改为 goal_id - work_graphs schema 补 goal_id，与 okr_node_id / task_id 并列（三者基数不同， 分别是 1 / 长周期归属 / N，不能用单一字段表达） - 新增 27-REQ R-12 记录本次决策及其推翻关系 修复上一轮的一处失误：全局改名误改了 27-REQ 中的原话引用（R-10 一度被改成 "goal-benchmark 或者 goal-benchmark"）。原文照搬文档不得被批量替换触及，已还原。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
新增四份文档： - 27-e2e-task-execution-flow.md — 跨阶段总览：建公司 → 下达任务 → org graph 逐节点执行 → work graph 规划与循环 → 验收收敛。核心发现：这套流程 70-80% 已在 docs/prd/newfunction/_spec/ 里被完整设计（DevLoop 的 L1/L2/L3 三层循环、 BugTriager 四分类归因、分级预算熔断、contract_hash 闸门），DevLoop 实为本 架构唯一跑通的参考实现，通用引擎应从它抽象而来。 - 27-example-dev-company-walkthrough.md — 参考场景走查，把架构在一家具体公司 上跑一遍数（各阶段 JSON 形态、fan-out/fan-in 图、成本估算 ~44 次调用、 按阻塞程度排序的 8 个断点清单），作为实现靶子与端到端验收场景。 - 27-naming-conventions.md — 统一命名规范 {作用域}-{职能}。消歧三种 benchmark （skill- / agent- / task-）；OKR 体系正名（goal → okr，第 1 层 Goal → Objective）； 规划类统一为 orggraph-planning / workgraph-planning / brd-prd-sdd-planning。 - 27-p3-p4-work-graph-console.md — P3/P4 合并设计：Work Graph 执行引擎（支持 启动/下一步/暂停/停止/重试，手动与自动共用同一 advance 原语）+ 执行控制台页面。 重写 27-p2-org-graph.md 至 v0.4：Org Graph 从「静态汇报结构」重定位为 「company 级别生成的 workflow」，与 Work Graph 同构（condition/edge_kind 执行流边）， 两层共用同一套 schema、执行引擎与画布组件。org_graph_edges 从未写入过数据， 可直接 DROP 重建，零迁移负担；hire() 不再需要 reportsTo（图整体规划整体写入）， P2 对 company-service.js 的侵入缩至零。 同步修正总纲至 v0.3：Org Graph/Work Graph 术语定义、§3.1 架构图、§3.3 整节； 标注 P1 已实现（226489d）；P6「DevLoop 收编」从「可选」改为「应前置」。 修正三处过期陈述：P1 已实现（非设计稿）、runProject 已完整实现（非 501）、 UnitsDAG.vue 已实现 Kahn 分波 DAG 渲染（画布应扩展而非重写）。 并记录一处待处理冲突：graph-service.js:44 已落地的全量唯一索引与 P2 需要的 部分唯一索引冲突，实现 T1 时必须先 DROP。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>