-
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
-
## 第 6 步：调度器只管图任务（一行判据，但漏了是静默的） listQueue / deriveQueueBlocks / sweep 三处都加 executor='graph'。 派单任务虽然也进 tasks 表，但它的执行载体是「直接起一次 agent 对话」， 由 /task/dispatch 自己触发。漏这一条的后果：调度器拿一条根本没有 run 行的 task 去出队 → syncRunNodesToDef 判空 → abandonRun → **把一条正在被 agent 执行的派单收成 cancelled**。守卫用例把它摆成「最像可出队」的样子 （queued + auto + 无依赖），只有 executor 这一维拦得住它。 ## 第 5 步：GET /api/tasks 改读表，删掉 122 行的会话反推 原来的 getAggregatedTasks 是启发式：扫全部 agent 的 conversations，按会话 id 里的 T-xxx 归组，再用三条策略（meta 的 parentTaskId / from agent 的活跃会话 时间包含 / master conv 的标题相似）**猜**父子关系。猜出来的树没法验证对错， 而且每次请求都要遍历所有 agent 的会话目录 —— route 那 10 秒缓存就是为它加的。 现在父子关系是 tasks.parent_task_id，派单时就显式写下来了，不用猜。 task-service.js 391 行 → 236 行；_inferParentChild / _loadTaskMetas / TASK_META_DIR 一并删除（改完就是零调用方）。 **getTaskTimeline 保留**，但来源拆清楚：任务树从表来（parent_task_id， 可验证），时间线正文仍从 agent 的 conversations/ 扫 —— 那是一手记录， 没有替代品。删掉的只是「从会话反推任务树」那一半，不是会话本身。 两处口径变化（写在代码注释里）： - agents：原来是「会话里出现过的 agent 集合」，现在是「谁派的 + 派给谁」。 对派单任务这两者本来就是同一件事 - conversationCount：原来是扫出来的文件数，现在是「有没有起过执行会话」(0/1)。 为一个列表字段遍历所有 agent 的会话目录，正是这次要去掉的那笔开销； 真要看内容走 /api/tasks/:taskId/timeline，那条仍读一手记录 ## 漏改一个消费方，真打接口才发现 routes/tasks.js 自己还在算 t.conversations.length，而 conversations 是会话 反推那套的产物、已随之删除 → 500「Cannot read properties of undefined」。 测试没覆盖这条路（它只在真跑接口时才走到）。已改成用 t.conversationCount。 真打验证：GET /api/tasks 返回 17 条、12 个字段齐全 —— 条数比改前多， 因为测试跑出来的派单现在也进表了，这本身就是「存储真的换了」的证据。 全量：132 文件 / 1257 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
## 批 4：解除「一家公司同时只有一个 active root run」 - DROP idx_graph_runs_one_active_root（建表块删掉 + 迁移块显式 DROP， CREATE ... IF NOT EXISTS 对存量库不生效） - max_parallel_tasks 从 company.json 调用时读（不是模块加载时快照， 否则改配置要重启才生效且不报错）；缺省 1、非法回落 1 并留声、硬上限 20 - 准入判据「从活跃集外进入活跃集」按额度计数 **生死线用 8 个真进程并发抢坑实测**（不是纸面论证）：max=1/2/3/5 四组， 每组恰好抢到 max 个、库里活跃数 = max，落选进程各吃 40 次 RunSlotBusyError， 零 other 错误。唯一索引没了之后，准入事务是真守卫。 ## 批 3 对抗复核的四条遗留 - N1 🔴 cancelQueuedRun 的前提被批 3 自己的 requeueBlockedRootRun 改没了： queued 的 run 现在可以是跑过一半的。探针实测取消后子 run 残留 paused/stop_requested=0 —— 那条 running 的子 run 继续调 agent 烧 token。 改为无条件走 engine.stopRun - L1 ⚠️ 恢复路径对 manual 只兑现一半：注释写着「T1 永远回不来这个后果因此 消失」，但调度器故意不碰 manual → 退回队列后没人接。定案：「manual 不自动 出队」约束的是首次起跑的授权，已被人亲手起过的不算新授权。 判据用 attempt>0 而不是 started_at —— 后者会被 requeue 清成 NULL， 恰好在需要它的那一刻是空的（实测踩过） - N2 🟠「退回队列」对用户完全不可见：200 + ok:true + 按钮全灰 + 图消失 + 一句「节点状态一律 pending」的假提示。加 notice 明说 - N3 🟠 isSlotRaceError 把 InvalidTransitionError 当竞态吞掉，而探针证伪了 那条注释：被推走时条件更新返回 0 不抛，真正抛它的只有「调用方声明了非法 转换」。删掉该分支，让它吵起来 四条里三条是同一个模式：注释承诺的前提被本轮自己的改动改没了，注释还留着。 文档 §十三.3 / §十四.4 已就这个模式立过两次案，这是第三、四、五次。 ## 文档 §十五 实施记录，含 §15.4 一次流程事故：87b776c 由第三方会话在对抗复核完成 前误提，提交说明的「1201 用例全绿」压在一份尚未通过复核的代码上。 全量：128 文件 / 1240 测试全绿，web:build 通过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
队列与调度（§五.1）： - 下达任务不再因「公司已有 active root run」吃 409，改为建 queued run + queued task 排队；出队走 updateRunStatus 的 CAS + BEGIN IMMEDIATE 准入事务，触发挂在 transitionRun 这个唯一漏斗上，60s sweep 兜底。 - 依赖已不可能满足的排队任务就地推导成 blocked，且每次 tick 重算不落死，上游重跑 成功后能原路解开。 恢复路径（批 3 复核 F1/F2）：三条恢复转换的 from 全在活跃集之外，撞坑满时退回队列而不是 永远躺在 blocked；退不回去的裸 run 干净拒绝，不留半截状态。 控制台三处可见性修复 —— 症状全是纯视觉、不报错、git status 干净： 1. 顶栏墙钟恒 `now - started_at`，没有终点。一条昨晚就 blocked 的 run 第二天还在涨到 「16h 58min」，而那是页面上唯一的时间信号 —— 「已经停了等人处置」被显示成了 「还在跑再等等」，这两件事需要的动作相反。终点改取 run.updated_at，并标「已停」。 2. 越界日志只报「留下 N 处改动」，文件清单躺在 timeline.ndjson 里翻不到。判罚就是按 这份清单下的，而人要判断「这真是 agent 写的吗」唯一的依据就是路径（并行的开发会话 改宿主仓库会被算到当时在跑的节点头上，那是误判，看一眼就知道）。改为列出 entries。 3. run 收敛成 blocked 时只把 task 写成 blocked、不写原因，任务列表那一行只剩一个橙色 的「挂起」，必须逐层点进 org 图 → work 图 → 节点详情才知道发生了什么。改为把 「卡在哪个节点 + 什么 fail_reason + 判词摘要」写进 tasks.blocked_reason。 原因绝不带 UPSTREAM_BLOCK_PREFIX —— 带了会被调度器当成依赖推导出的 blocked 自动 推回 queued，而这类 blocked 本来就等着人处置（守卫在 task-blocked-reason.test.js）。 测试：126 文件 / 1201 用例全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>