-
前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败， 只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。 补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列 文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、 system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用 （agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的 description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
46 号文档 Phase 4：decomposed_work 子任务的父子生命周期管理。 - 父任务被 subtask-planning 成功拆分后让位给子任务（新状态 decomposed）， 取消自己排队中的完整 org graph run - 父任务预算按拆出的步数均分给每条子任务 - 父子终态汇总（settleParentTaskIfAllChildrenDone），子任务全部完成后 自动结算父任务并联动 goal 收敛 - 同父子任务独立并发坑位（上限 3），判据钉在 updateRunStatus 的唯一准入 事务里，不占用公司级 max_parallel_tasks 槽位 - 前端（Phase 5）：decomposed 状态样式 + 子任务进度展示，复用已有的 parentTaskId 通用树形逻辑，未改后端接口 真实回归当场撞出一个几乎必现的真缺陷：markTaskDecomposed 原本只认父任务 还是 queued，但 task-scheduler 抢坑是毫秒级、subtask-planning 是数十秒的 真实 LLM 调用，等它拆完时父任务几乎必然已经 running，接管必然失败，而 stopRun 依然会把真实在跑的 org graph 取消掉。已修复（接管条件放宽 + 调整先接管再取消的顺序）并用真实公司数据验证；同父并发坑位也用真实数据 确认生效（两条子任务真实同时 running 20+ 分钟）。 回归过程中牵出一个独立缺陷：org-validator 对同一种 benchmark 契约判断 不稳定（5 次里 1 次误把源码路径当 --target 判 target_not_json，反手把 责任推给 subtask-planning）。根因是 decomposed_work 轻量图当时只有一条 前进边、没有失败边，validator 判 fail 后无路可退。已补 validate --fail--> impl 退回边（复用引擎已验证过的 backward_count 双层硬顶 + remediation_note 反思闭环），新增 3 条单测覆盖边形状、真实退回重试、硬顶熔断三个场景。 全量单测 1229/1231 通过（2 个失败改动前即存在、与本次无关）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh
-
44 号：writesArtifacts 节点产出闸门永远打不过 - goal-benchmark 按设计把产物写进 root run 共享 artifacts/ 目录（三个节点合成同一份 acceptance.json，天然不可能落在某节点私有目录），但 unsatisfiedRequiredProduces 的 R-19 逃生口 readDeclaredProduces 的 allowedRoots 只认节点私有目录 + 项目根，够不到 共享区——这条契约在当前实现下无论 agent 表现多好都无法通过。 - 修法（44 号文档方案 1，改动面最小）：allowedRoots 加入 runRootDir(run)/artifacts/； goal-benchmark 的 agent.md/tools.md 补上"写完共享产物后在自己节点私有目录声明一份 contract.json"这一步。 - 回归：graph-files-index.test.js 新增用例 ⑭。 41 号：routeFailure 的 infra_flake 分支完全无视 target_node - 30 号文档记录过一次真实死循环：节点自称 infra_flake 并点名 target_node，引擎原来 一律原地重跑该节点自己，从不看 target_node。 - 修法（最保守方案，用户确认）：新增 infraFlakeTargetEdge——target_node 只有在图上 真有一条从本节点出发的 backward fail 边指向那个节点时才生效，命中就改走正常的 backward 边路由（计入 backward_count/双层熔断），不再享受"原地重跑、只受 infra_flake_count 约束"的免账本待遇；没命中维持原有行为。 - 重要澄清：这条修复堵不住 30 号文档那次真实事故——事故里点名的目标是下游节点， 而 org-graph-service.js 规则 4（backward-labeled）从图结构上就不允许 backward 边 指向非祖先，那次事故本来就不是"有边不认"，是"诊断内容在打图结构不允许表达的 主意"，已经靠 INFRA_FLAKE_HARD_CAP 熔断收敛，不在这条修复范围内。 - 回归：graph-engine.test.js 的 infra_flake describe 块新增两条用例。 44 号文档移入 done/，41 号清单项相应更新，43 号文档的交叉引用一并修正。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CwGcvMfUcgCcweN5vjhTkn
-
按 39 号设计文档落地 ceo 常驻监督：company.js 的 goals/tasks 端点 放行内部令牌自环调用，POST /tasks 支持 draft 模式（agent 自主提任务 不再立刻烧预算），ceo 补雇进公司创建流程；task-settle 新增事件驱动 唤醒 + 30 分钟兜底轮询；graph-engine 的回退熔断收敛时顺手回写一条 draft task，形成"卡住 → 自动/ceo 判断 → 重新规划"闭环。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
-
30 号文档记录的真实事故：org-coder-test 被上游 missing_required_input 打回后， 产出的是「建议重跑 org-coder-validator」的诊断文件而不是正常测试结果，引擎把诊断文件里 的 infra_flake 标记当成了这个节点自己的执行结果——infra_flake 原地重跑故意不烧 attempt/backward_count（"这不是节点的错，不该烧它的重试额度"），代价是它是唯一没有 熔断线的失败路径，真撞上了一次每轮产出雷同、永不停止的死循环，眼看着把任务预算耗光。 新增 graph_run_nodes.infra_flake_count 列，只在 infra_flake 原地重跑时累加，真正发起 新一轮真实派发（bumpNodeAttempt）时清零；连续判 infra_flake 超过硬顶（3，与 LOOP_HARD_CAP_EDGE 同量级）就不再原地重跑，改判 blocked 交给人工——不猜该走哪条 fail 边（infra_flake 这个取值域通常没人给它连边）。新增回归测试锁死"永不恢复的 infra_flake 在硬顶后停止重跑"这条行为，graph-engine 相关 10 个测试文件 94/94 通过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
## 起因 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>