真实回归暴露"认领后没有触发源"的真问题,讨论后发现"认领"(pull,CAS
抢占)要解决的"多方竞争同一条任务"场景根本不存在——只有 CEO 一个人拍板
要不要派、派给谁。CEO 心跳统一发现+直接派发(push)成本更低,还能顺带
控制派发节奏,不需要认领。
删除:claimSubtask/unclaimSubtask(work-graph-db.js)、POST /claim、
POST /unclaim(company.js)、CLAIMABLE_WORK_ROLES 白名单、
claimable/claimed 两个 status 值、claimed_at 列。
改名:subtask_kind 的 'claimable_work' → 'decomposed_work'
(materializeClaimableSubtasks → materializeDecomposedSubtasks),
"认领"这个词不再准确,物化出的行现在就是普通 draft task。
新增:
- triggerSubtaskPlanning 加递归防护(task.parent_task_id 非空直接跳过)
——设计 v2 时发现的真实漏洞:CEO 对子任务调 /enqueue 会默认
withSubtaskPlanning=true,不挡会对已经是"第几步"粒度的子任务再拆一层。
- createDecomposedWorkGraph:现造一张两节点轻量 work graph
(impl=org-coder、validate=org-validator,agent_call 不是 subgraph),
跳过公司完整 org graph 的 brd/prd/sdd 规划仪式——subtask-planning 已经
把"怎么做"拆到这个粒度了,再走一遍纯属重复劳动。含一条没有真实验证过
的假设(org-coder/org-validator 裸调用会不会读不到预期上下文),如实
写在代码注释和文档里。
- enqueueTaskRun 按 subtask_kind 选图:decomposed_work 走轻量图,
普通 task 行为不变(回归测试覆盖)。
- ceo/heartbeat.md、tools.md 补了巡检 decomposed_work 草稿 + 判断节奏
+ 调用现成 /enqueue 的指令。
测试:删除 task-pool-claim.test.js(随 v1 代码作废),新增
task-decomposition-dispatch.test.js(12 条),更新
task-decomposition-validator-gate.test.js 措辞。全量单测 1191 条,
1189 passed(唯二失败与本次改动无关),零残留 CLI 子进程。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8