宜博 / lemonboss

  • docs: 43 号文档实现记录 + 44 号文档（writesArtifacts 产出闸门缺陷） ...
    22d93c88 
    43 号文档补上 Phase 0-4 的实现记录，含一处架构订正（org-planner 在 org
层永远是 subgraph，真跑数据核实后钩子改成扫子 run 全节点）。

44 号文档是真实回归验证 43 号文档时意外发现的独立缺陷：goal-benchmark
按设计把产物写进 root run 共享 artifacts/ 目录，产出闸门只查节点私有
目录，writesArtifacts:true 这个字段全仓库零代码读取——这条契约在当前
实现下结构性地打不过，不是偶发。很可能正是 snakegame-co 参考任务里
goal-benchmark/planner-validator 显示 skipped 的真实原因。只记录诊断，
未修复，留了两条候选修法。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
    yibo authored
     
    Browse File »
  • docs(43号): goal 分解粒度需求 + 方案定案 + 技术实现计划 ...
    5c7e5ce8 
    回应"org-planner 出 brd/prd/sdd 后，任务看板能不能展示成 task/sub-task
树，coder-validator 按清单逐条开发验收"。原话照搬 + 结构化复述 +
现状调研（parent_task_id 只服务于 Agent Chat 派单流程、task-planning
人设明确拒绝按检查项拆 task、org-planner 没有建任务工具）。

三轮讨论定案：goal→task 流水线自建父子机制、先只拆验收（开发仍整体
完成）、要不要拆交给 task-planning 判断、任一子任务 fail 父任务即
fail、子任务复用 tasks.status 状态语义。

技术实现计划 Phase 0-4 逐条核实代码形态，含两处订正（org-validator/
coder-validator 是不同 agent；org-planner 产出的验收清单是 acceptance.md
不是 acceptance.json）和一个待验证风险（acceptance.md 在真实回归里
从未被用上，Phase 2 落地前需先确认可靠性）。尚未开工。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
    yibo authored
     
    Browse File »