• 实现路径: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
    yibo authored
     
    Browse File »

  • 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>
    yibo authored
     
    Browse File »