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