宜博 / lemonboss

  • fix(graph-engine): 44 号写共享区产出闸门永假 + 41 号 infra_flake 忽视 target_node（两处真 bug） ...
    a4b24893 
    44 号：writesArtifacts 节点产出闸门永远打不过
- goal-benchmark 按设计把产物写进 root run 共享 artifacts/ 目录（三个节点合成同一份
  acceptance.json，天然不可能落在某节点私有目录），但 unsatisfiedRequiredProduces 的
  R-19 逃生口 readDeclaredProduces 的 allowedRoots 只认节点私有目录 + 项目根，够不到
  共享区——这条契约在当前实现下无论 agent 表现多好都无法通过。
- 修法（44 号文档方案 1，改动面最小）：allowedRoots 加入 runRootDir(run)/artifacts/；
  goal-benchmark 的 agent.md/tools.md 补上"写完共享产物后在自己节点私有目录声明一份
  contract.json"这一步。
- 回归：graph-files-index.test.js 新增用例 ⑭。

41 号：routeFailure 的 infra_flake 分支完全无视 target_node
- 30 号文档记录过一次真实死循环：节点自称 infra_flake 并点名 target_node，引擎原来
  一律原地重跑该节点自己，从不看 target_node。
- 修法（最保守方案，用户确认）：新增 infraFlakeTargetEdge——target_node 只有在图上
  真有一条从本节点出发的 backward fail 边指向那个节点时才生效，命中就改走正常的
  backward 边路由（计入 backward_count/双层熔断），不再享受"原地重跑、只受
  infra_flake_count 约束"的免账本待遇；没命中维持原有行为。
- 重要澄清：这条修复堵不住 30 号文档那次真实事故——事故里点名的目标是下游节点，
  而 org-graph-service.js 规则 4（backward-labeled）从图结构上就不允许 backward 边
  指向非祖先，那次事故本来就不是"有边不认"，是"诊断内容在打图结构不允许表达的
  主意"，已经靠 INFRA_FLAKE_HARD_CAP 熔断收敛，不在这条修复范围内。
- 回归：graph-engine.test.js 的 infra_flake describe 块新增两条用例。

44 号文档移入 done/，41 号清单项相应更新，43 号文档的交叉引用一并修正。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CwGcvMfUcgCcweN5vjhTkn
    yibo authored
     
    Browse File »
  • 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 »