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
