-
实现路径：task-planning 判断是否 itemized（硬规则 5 开例外让 LLM 写这 一个字段）→ org-planner 收尾把 acceptance.md 物化成子任务 → coder-validator 用新工具 task subtask-result 逐条上报，settleNode() 新增闸门强制核对 子任务全部 completed 才认这一轮 success。 - work-graph-db.js: tasks 加 acceptance_mode 列，createTask 支持 parentTaskId（复用既有列），新增 settleSubtaskResult 条件更新 - graph-engine.js: maybeMaterializeItemizedSubtasks（org-planner 结算 success 后物化子任务，agent_call/subgraph 两种形态都认，subgraph 场景 扫子 run 全节点找 acceptance.md，找不到优雅降级不阻塞主产出）； coder-validator 判 success 前新增子任务完整性闸门 （ENGINE_FAIL_REASONS.SUBTASKS_INCOMPLETE） - task-planning.js / company.js: acceptance_mode 字段透传链路 - bin/lemon.js: 新增 task subtasks / task subtask-result 两个子命令 - coder-validator/agent.md、task-planning/agent.md: 对应提示词更新 真实回归验证过（新建公司走完整链路），过程中发现两个跟本次改动无关的 预存在问题：一次瞬时的 produces_missing 误判（重试即愈）、一个结构性的 writesArtifacts 产出闸门不匹配 bug（另立 44 号文档记录，未修复）。 全量单测 1120/1123 通过，3 个失败与本次改动无关（git stash 验证过）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
-
队列与调度（§五.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>
-
goal 从「人写一句话」变成「agent 拆成一张 task DAG、人确认后下达」， 收敛时由 org-validator 在 goal 层再验一次。 ## 交付 - task-planning 本体（毕业判据实测通过：agent.md + soul.md 一次写完、 不带 _base 哨兵、路径按 cwd 深度 3 实算核对） - 拆分链路：3 轮 errors 原样回喂 → 不过就降级成 1 条同描述 task， goal 绝不卡在 planning；token 记 goals.planning_tokens - goal 级 org-validator 验收：≥2 条 task 全 completed 才调，单 task 跳过， 有 failed 直接 failed 不调（省一次真花钱的调用） - 控制台四栏 + GoalTaskPane 两级树 + 两步表单（拆分中给逃生口） - 中断恢复：启动时补跑验收与汇报 ## 三条跨进程竞态，全部用真探针实跑复现后才判定修好 1. runGoalSplit 无条件把 goal 写回 draft，抹掉逃生口刚下达的 active —— 而触发它的正是表单自己推荐的那个逃生口。后果是一个正在烧钱的 goal 显示成「草稿」，且从此永不收敛（OKR 不写、上级不唤醒、无日志） 2. CAS 把最终态提前写进库，验收窗口内重启即丢，且 verdict=NULL 与 「单 task 合法跳过」形态相同，查不出来 → 占位判词 + 启动重推 3. 认领语句 SET verdict=RESUMING WHERE verdict IN (PENDING, RESUMING) —— 写进去的值就在 WHERE 里，changes 恒为 1。而函数注释白纸黑字 写着「认领写的是另一个占位值」。注释是对的，代码没兑现。 实测：org-validator 调 2 次 / OKR 写 2 条 / token 双记 → claim 带唯一 token + 时间戳租约，回写条件更新决胜，主路径同闸门 ## 与设计正文的偏离（已记进文档 §十四） 拆分后 goal 落 draft 而非 active（active 的语义已被 markGoalDispatched 钉死为「已下达」）；mode 三级继承对显式 tasks[] 同样生效；占位判词不出 API；新增 planning_error / reported_at 两列，后者迁移带回填（否则升级后 第一次启动会把历史终态 goal 全部重报一遍）。 ## 过程 四轮 26 个 agent，复核报出 22 条缺陷，其中 6 条是修复自己引入的。 第四轮修完挂了 3 条测试，全是测试在钉住缺陷本身 —— 其中一条的注释 写着「模拟进程死后重启」，构造的却是新鲜占位值：注释描述 A 场景、 代码构造 B 场景、断言按 A 场景写。 全量：118 文件 / 1112 测试全绿，web:build 通过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
把「人类提的一个需求」与「机器执行的一件活」拆成两级。这不是新概念： 27-NAMING §四 早就定义了 goal 1 : task N，graph_runs.goal_id / task_id 两列从 P3 起就一直在写，却没有任何表接得住 —— 本次补上那两张缺席的表。 ## 交付 - goals / tasks 两张表 + CRUD + depends_on 环检测 + ID 生成器 T-{base36}-{4hex}：原格式同毫秒必撞，而 tasks.id 是主键， 「一个 goal 拆 N 条 task」是循环建行，撞了就是 500 - goal / task 全套端点；POST /:cid/tasks 向后兼容（不带 goal_id 自动 建 goal）；退役 /api/goals 与 /:cid/goals 两个 OKR 别名（零调用方） - 终态回写 + goal 收敛 + OKR 写一次：钩子挂在唯一漏斗 graph-run-sse.transitionRun 上，而不是枚举路径 —— stopRun 与 「预算耗尽 → blocked」两条最常见的释放路径都不走 settleRun， 枚举一次漏一次。goal 收敛用 CAS 闸门，并行完成的 N 个 task 只有 一个赢家做不可重放的副作用（写 OKR / 唤醒上级） - blocked 在 task/goal 两层都不是终态：它是「挂起等人介入」， 与 completed/failed/cancelled 不同类。否则预算耗尽后加预算恢复、 跑完，两次条件更新静默命中 0 行，最终 run=completed 而 task=blocked/goal=failed/OKR=failed 永久对不上（实跑复现过） - goal 级是唯一汇报出口：删掉 run 级 reportRunOutcome（零其它调用方）， 1 goal:1 task 形态下它会把上级 agent 就同一件事唤醒两次 - dispatch 挑第一条可跑的 draft，而不是恒取 seq 最小那条 —— 否则「第 1 条依赖第 2 条」这种合法输入会让 goal 永远下达不了 - 路径缺陷：writeTaskGoalArtifact 不认 GRAPH_RUNS_DIR 而读侧认， 设了 env 就写进 A 处、从 B 处读，describeTask 拿到 null 后静默退回 兜底文案「执行图节点任务」；三处模块加载时快照改为调用时读 - 存量回填脚本（幂等 + --dry-run）：不做的话批 1 反而让历史任务 更看不见 —— 正是本批要修的问题的反向放大 ## 过程 三轮多 agent 编排 + 每轮对抗复核，共报出 19 条缺陷（10 条首轮实现的、 4 条第二轮修复引入的、5 条判定为非问题）。全部已修并有用例覆盖。 新增测试 4 个文件，含不变式测试 runs-root-single-holder（凡是声明了 GRAPH_RUNS_DIR 覆盖的模块，该覆盖必须真的被用到）。 全量：116 文件 / 1057 测试全绿。 ## 未做（属批 2-5） task-planning 与 goal 级 org-validator 验收（批 2）、调度器与 run_status='queued'（批 3）、并行（批 4）、两套任务体系统一（批 5）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>