宜博 / lemonboss

51 号文档阶段 A 上线后发现：CEO 心跳自主立项建出的草稿（split:false）其实自动带 1 条
draft task，dispatch 技术上立刻能跑，原以为的"零 task 闸门"并不存在——安全性曾经完全靠
ceo/tools.md 里"不许自己调 dispatch"这一句提示词约束，没有代码层面的东西挡着。

POST /goals/:goalId/dispatch 新增判断：created_by==='ceo' 且 updated_at===created_at
（自建成后从没被 PATCH 过）直接 409。复用既有时间戳字段代理"有没有人碰过"，不加新列——
已知简化（ponytail 注释标了天花板：分不清"真审过"和"随手碰一下"，精确区分需要专门的
reviewed_at 列，留给阶段 B）。

task-queue-routes.test.js 新增两条用例：未审阅的 ceo 草稿 dispatch 409、PATCH 一次后放行；
human/未填 created_by 的草稿不受影响。相关四个测试文件 84 条用例 + 全量 unit 套件跑过，
无回归（4 个不相关的预存在失败：工作区不干净的环境闸门 + 两个与本次改动无关的仓库卫生检查）。

51 号文档 §四/七/八、docs/README.md 索引同步更新。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ

公司没有任何 active/draft/planning goal 时，CEO 心跳原本会在第一步查询就拿到空列表、
直接回复"心跳正常"，永久停摆、没有信号升级给人类。心跳清单加一步空转检测，命中后走
使命前置闸门（company-context.md 的"公司使命"是"待定义"就拒绝立项、转人工）+ 去重 +
POST /goals(split:false, created_by:'ceo') 建草稿，CEO 到此为止、不自己调 dispatch。

起服务实测（不只是读代码）推翻了设计草稿阶段的两处判断：GET /goals 不支持逗号分隔多状态
查询、也不支持按 created_by 过滤（改客户端过滤）；split:false 建出的草稿其实自动带 1 条
draft task、dispatch 技术上立刻能成功，不存在"零 task 逼人工审批"这道代码闸门——阶段 A
的安全性因此完全押在 tools.md 里"不许自己调 dispatch"这条提示词约束上，是当前最脆弱的
一环，见 51 号文档 §四。

未改任何路由/服务层代码，纯 agent 人设文档改动。阶段 B（CEO 自动 dispatch + guardrail +
公司级开关）留白未实现。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AWsH2YBwBWTsQggPaPbsKJ

DevLoop 本质是 loop workflow（L1/L2/L3 三层嵌套，PM→Architect→Coder→Tester→
Integrator→Triager 六个固定角色），已被 27 号系列的 graph workflow（org graph +
work graph，graph-engine.js）严格覆盖——loop 只是 graph 的一个退化形状。
用户评估 27 号总纲原计划的 P6（DevLoop 收编）后拍板：不做迁移，直接整体退役。

决策记录、评估过程、退役范围与保留项详见 docs/done/system-design/52-devloop-retirement.md。

删除：
- 后端：routes/devloop.js、src/core/devloop/、services/devloop/ 下除
  path-resolver.js/doc-store.js 外的全部文件、src/tools/devloop/、
  server/public/devloop-status.html、两个 server 入口的 /api/devloop 挂载
- 前端：views/DevLoop*.vue（4）、components/devloop/（12）、router 里的 4 条路由
- system/agents/devloop-{pm,architect,coder,tester,integrator,triager}/（6 个本体）
  + _registry.json 对应条目
- server/tests/devloop/（21 个测试文件）+ 1 处跨文件断言（route-auth-gate.test.js）
- fixtures/devloop-mock/ 下 DevLoop 专属 fixture + fixtures/devloop-mock-scenarios/
- 8 个 DevLoop 专属人工验证脚本（phase1-5-verify.js 等）→ 归档
- package.json 的 spec:extract/spec:check、scripts/git-hooks/pre-commit
  （唯一职责是校验已归档的 docs/prd/newfunction）

保留（仍被 27 号系列现役代码依赖，文件顶部已加说明）：
- server/services/devloop/path-resolver.js（graph-engine.js 项目根分配用）
- server/services/devloop/doc-store.js（hashContract 被 graph-engine.js/
  goal-contract.js 复用）
- fixtures/devloop-mock/ 目录本身（graph-engine 真实链路测试共用这批 fixture）

归档到 docs/_archive/devloop-prd-2026-09-17/：docs/prd/ 整站、build-manifest.json、
5 个 PRD 抽取脚本、8 个人工验证脚本。

顺带修正：work-graph-skeletons.test.js 的占位符不再依赖已删除的 devloop-* 本体；
CLAUDE.md/docs/README.md 全面同步；no-dead-path-references.test.js 揪出的两处
死链接（brace-expansion 写法、历史路径未加归档说明）已修。

全量 vitest（1403 passed，3 条与本次改动无关的既有失败）、web:build、真实
server 启动（含 graph-seed 自愈：自动清理了库里残留的 devloop-* system_agents 行）
均已验证。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU

前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败，
只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。

补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列
文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、
system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用
（agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的
description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU

27-p3-p4-work-graph-console.md 功能与测试覆盖均已完整（四条硬规矩仅剩真 LLM
进不了 CI 这条本质限制），按已有先例（27-P4/27-P3B）移入 done/。

同步修正的引用范围比预期更广，一并处理：
- docs/todo/ 与 docs/done/ 下引用该文档的设计文档（相对路径深度不同，分别处理）
- system/agents/*/agent.md、tools.md 里指向设计文档的引用（cwd 深度 3 的
  ../../../../../ 相对路径，agent-md-refs.test.js 会校验这些链接真实可解析）
- system/agents/_registry.json 的 description 字段、work-graph-templates/README.md
- server/ 源码里指向设计文档路径的注释（graph-engine.js 等）

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU

隔离 worktree + 真 Claude CLI 探针：CompanyService.create() 建一家有真实
company.json 但从未雇过 workgraph-planning 的公司，建最小 subgraph 节点
work graph 并驱动一步。resolvePlanningAgentName 的按需 hire 真实触发并成功
（区别于 27-P3B §六quater 那次因公司无 company.json 而降级回裸名的反例），
随后按公司作用域名正确寻址、workgraph-planning 真实规划出子 work graph。

四条硬规矩第 2 条现在只剩 (a) 真 LLM 进不了 CI 这条本质限制，(b)(c) 均已还清。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU

代码修复：
- SessionPool 的 scope 参数从未真正从 graph-engine 传到 AgentManager，导致 fan-out
  场景下同一 agent 的并发调用会撞会话键；补上生产接线（graph-engine.js/agent-manager.js）
- advanceTree 改成 Promise.allSettled 并发推进兄弟子 run（原来只推最深的一个）
- graph-real-chain-smoke.test.js 补齐多节点/回退边/双层熔断的真实链路覆盖

真实验证：
- 27-P3B 最后一条验收（org 层回退边指向 subgraph 节点）用隔离 worktree 真实 Claude CLI
  跑通并记录证据（§六quater）
- 27-P3B 正文里 W5/W6/W7/W9 的"仍未验"备注核实后发现均已被此前的真跑验过，只是没回填；
  W8（重新规划组织按钮）此前确实没验过，本轮用隔离 worktree + 真实浏览器点击补验

文档收口：
- 27-P3B、27-P4 两份文档功能与验收均已完整，移入 docs/done/，更新全部交叉引用
- T5（账户欠费门真实计费接口）按用户决定移入 docs/todo/future/，不阻塞收口
- 订正两处过期判断：graph_edge_contracts.role 列早已落库、CONVENTIONS.md 非 spec:extract 生成物

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU

用一个全新 goal（三个独立字符串工具函数）补跑，拿到了此前唯一缺的直接证据：
两条子任务真实 completed 后，父任务被 settleParentTaskIfAllChildrenDone 正确
自动结算成 completed；同一批里两条无依赖子任务再次被观察到真实并发运行。

至此 Phase 4 四项机制（父任务让位/预算均分/父子终态汇总/同父并发坑位）全部
在真实条件下拿到过直接证据，不再只是单测覆盖。

顺带清理：测试公司 p2verify0902 里此前两次因回归脚本 bug 失败留下的旧数据
（G-mtn5q2r7-786b、G-mtn5tvih-bed4）已通过正式归档接口清理，本轮新数据保留
作为最新证据。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh

46 号文档 Phase 4：decomposed_work 子任务的父子生命周期管理。

- 父任务被 subtask-planning 成功拆分后让位给子任务（新状态 decomposed），
  取消自己排队中的完整 org graph run
- 父任务预算按拆出的步数均分给每条子任务
- 父子终态汇总（settleParentTaskIfAllChildrenDone），子任务全部完成后
  自动结算父任务并联动 goal 收敛
- 同父子任务独立并发坑位（上限 3），判据钉在 updateRunStatus 的唯一准入
  事务里，不占用公司级 max_parallel_tasks 槽位
- 前端（Phase 5）：decomposed 状态样式 + 子任务进度展示，复用已有的
  parentTaskId 通用树形逻辑，未改后端接口

真实回归当场撞出一个几乎必现的真缺陷：markTaskDecomposed 原本只认父任务
还是 queued，但 task-scheduler 抢坑是毫秒级、subtask-planning 是数十秒的
真实 LLM 调用，等它拆完时父任务几乎必然已经 running，接管必然失败，而
stopRun 依然会把真实在跑的 org graph 取消掉。已修复（接管条件放宽 +
调整先接管再取消的顺序）并用真实公司数据验证；同父并发坑位也用真实数据
确认生效（两条子任务真实同时 running 20+ 分钟）。

回归过程中牵出一个独立缺陷：org-validator 对同一种 benchmark 契约判断
不稳定（5 次里 1 次误把源码路径当 --target 判 target_not_json，反手把
责任推给 subtask-planning）。根因是 decomposed_work 轻量图当时只有一条
前进边、没有失败边，validator 判 fail 后无路可退。已补 validate --fail-->
impl 退回边（复用引擎已验证过的 backward_count 双层硬顶 + remediation_note
反思闭环），新增 3 条单测覆盖边形状、真实退回重试、硬顶熔断三个场景。

全量单测 1229/1231 通过（2 个失败改动前即存在、与本次无关）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh

由 dream 机制自动提炼跨公司经验并刷新 ceo 的 agent.md/soul.md 经验区块，
本次内容涵盖：状态字段自相矛盾判读、预算耗尽假阳性识别、批量阻塞告警回溯
依赖链、已知问题重复告警的处置、协作方专属工具越权代劳的边界、父任务终态
汇总缺陷的识别模式。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Mq8rViHp8xuj6zTy76hh

对照 Google Antigravity「Teamwork」多智能体框架博客文章，产出两份设计
讨论文档（均标注"不代表已拍板"）：

- 49号：纠正27号P4「真并行」现状认知（阶段A/B/C早已实现，又一次「文档
  落后于代码」）；给验证严谨度问题提两个方向——benchmark段证据要求泛
  化（建议推进）、陷阱注册表落点定案为独立文件 known_pitfalls.md；实地
  核实"验收路径引导到test_script段"的工作量后结论是不做，撞上
  test_script.path 解析根不含项目根的结构性冲突。

- 50号：竞争候选+对抗批评+综合的详细设计草稿，critic/synthesis 强制
  分离的依据是仓库真实事故（qa-judge 早期评判+判决合一导致过一次无限
  循环，20次调用/31分钟才熔断）；量化了N路候选的预算超支风险。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UP1omSsXkyGhopHvWeSnyy

48 号文档补做收口：调研另外三条任务创建路径（task-planning/
org-planner 的 acceptance_item 物化/人类快速派单）是否需要同款
acceptance_contract 强绑定,结论是不需要——都走完整 org graph,
workgraph-planning 的 benchmark 节点"不可裁"约定已天然保证契约存在,
强行加会与 task-planning 的极简边界、快速派单的零 LLM 定位冲突。

顺带梳理 todo/system-design 下已完成的文档,移入 done/:
31/32/34/43/45/47 号（含此前漏收录进索引的 32 号文档),并修正
因搬家产生的相对路径死链（44号/46号 对 43/47 号的引用)。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UP1omSsXkyGhopHvWeSnyy

真实起 org-coder → org-validator 跑完 46号文档 Phase 3 v2 当初卡死的那条
轻量图链路（重新建了一条全新任务，subtask-planning 真实分解、真实 enqueue），
org-validator 最终判词 fail_reason=null，确认不再 input_underspecified。

过程中撞见两个纯属验证方法论本身（非代码）的坑：①没起真实 API 服务导致
org-coder 的 CLI 工具调用连续 infra_flake；②agent 子进程与驱动脚本不同源，
LEMON_INTERNAL_TOKEN 对不上导致 401。两次都被真实 agent 自己的诊断日志
准确点破根因。最终把驱动脚本改成同进程内 require server/index.js 解决。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

subtask-planning 每个 step 新增 acceptance 字段（benchmark 段格式），createTask
强制 decomposed_work 子任务必须带验收契约并用 goal-contract.validateContract 校验，
enqueueTaskRun 起轻量图前把契约落进新 run 的 artifacts/acceptance.json——解决
46号文档 Phase 3 v2 真实回归撞见的 org-validator 死锁（轻量图没有 org-planner
产出契约，退无可退）。

真实起 subtask-planning agent 验证时发现设计稿的字段形状假设有误（真实产出是
benchmark 段本身，不是三段式 wrapper），已按真实产出修正代码与文档，并用那次
真实调用的原始输出跑通完整链路验证。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

承接46号文档 Phase 3 v2 真实回归发现的 org-validator 死锁：验收契约
产出被硬绑在"公司完整 org graph 一定会跑到 org-planner"这个假设上，
轻量子任务图不满足这个假设就退无可退。

讨论收敛：消费端（validator 只认结构化契约、不自由判断）保持硬约束，
产出端从"锁死在 org-planner 一个角色"改成"每个 task/subtask 创建时
1:1 必须带一份验收契约"（tasks 表新增字段 + createTask 统一校验）。
本轮范围收在 subtask-planning/decomposed_work 这条链路，task-planning/
org-planner/人类快速派单三条创建路径留到以后单独讨论。

盘点了完整的验收契约生态（acceptance.json vs acceptance.md vs
goal-benchmark.json 三者的区别、11 个相关 agent 里谁真正产出谁只消费）
和需要改动的 agent/代码清单。46号文档、docs/README.md 索引同步更新。

只是设计文档，未写代码。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

真实 CEO 心跳发现并派发 decomposed_work 子任务，递归防护、依赖阻塞都
验证生效。org-coder 在没有 brd/prd/sdd 的轻量图里产出质量真实达标
（正确的单位换算实现 + 完整边界测试），但 org-validator 卡在硬依赖的
acceptance.json 上（只有 org-planner 会产出）——轻量图执行没问题，
验证这一半有真实的结构性缺口，摆了三个方向留给下一步讨论。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

标记 v1 详细设计/实现记录为废弃（原样保留，不删——是决策过程的第一手
记录：真实回归暴露认领没有触发源的真问题，才推翻重来）。补 Phase 3 v2
章节：CEO push 派发的讨论过程、落地清单、一条没有真实验证过的假设
（org-coder/org-validator 在轻量图里没有 brd/prd/sdd 上游产物时表现
如何）、还没做真实端到端回归的说明。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

真实公司走完完整链路（物化→认领CAS→/task/report 状态转正确），机制本身
工作正常。但发现：①认领后没有任何触发源通知 org-coder，纯数据库状态
变更，没人会主动发现/认领可认领子任务；②/task/report 不是干净的状态
回写端点，会自动触发 selfChat 回调唤醒 to 指定的 agent（真实起一个带
文件读写工具的新 CLI 会话），且它是与 org/work graph 完全独立的非 graph
协议（agent-chat.js 的 /task/dispatch↔/task/report），不挂在任何图节点上。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

记录落地清单、必须同步改的坑（settleNode 闸门收窄）、认领后复用
executor='agent' 派单闭环这处化简确认按设计落地。如实记一次意外：排查
SQL 模板字符串反引号语法错误时，一句没设 GRAPH_DB_PATH 的 node -e
require 顺手对本地 data/graph.sqlite 跑了一次批 6 迁移——核实过是纯增量
ALTER ADD COLUMN，102 条既有行无损，但记下来提醒自己语法检查也该走隔离
环境。真实端到端回归（尤其认领后 org-coder 自己怎么干这一段）还没做，
留给用户后续决定。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

跟用户对齐关键架构决定：可认领子任务复用 tasks 表（新增 subtask_kind
字段区分 'acceptance_item'/'claimable_work'，不新开表）。

设计中定位两处要点：
- 必须同步改的坑：settleNode 的 SUBTASKS_INCOMPLETE 硬闸门要收窄成只查
  subtask_kind='acceptance_item'，否则新物化的 claimable_work 行会让所有
  开了 subtask-planning 的 task 验收判定失控。
- 重要化简：认领成功后直接复用现成的 executor='agent' 派单闭环（认领人
  自己搞定、自己 /task/report 上报），不需要给 graph-engine.js 加认领
  调度层，比文档原先设想的"改动面最大的一条"轻得多。

只是设计，未写代码。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

46 号文档 Phase 2 真实端到端回归（真实公司 p2verify0902 + 真实 goal/task/
Claude CLI）第一次跑就复现一个真缺陷：原始打分用「交集计数、>0 就算命中」，
一条长任务描述几乎必然跟经验库里的高频工程词汇偶然重合几个 bigram，导致
一个贪吃蛇任务被"验证修复要重新触发流程"这类无关的工程经验污染成
reasoning_source=memory，压过了本该触发的 deep research 分支。

改成 containment ratio（命中词数 / 经验块自身词数，对经验块归一化而不是
对查询归一化），阈值用真实噪音案例（~3%-4%）和合成相关案例（~16%-32%）
校准。补回归测试固定复现这次真事故场景。修完重启服务用第二条真实任务
（Markdown 转 HTML 工具）重新验证：reasoning_source 正确变成
deep_research，两轮调用（subtask-planning → org-hunt → subtask-planning）
真实跑通，全程零残留 CLI 子进程。46 号文档补了真实回归记录，包括一个
如实记录的局限：org-hunt 那次调用没有工具调用痕迹，更接近"多问一个角色
的第二意见"而非真的做了外部检索。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

subtask-planning 改成两段式：先查 experience-lookup（扫已雇 agent 的 dream
沉淀经验，关键词打分）拼进提示词，agent 自评 confidence；经验为空或
confidence low 时触发 deep-research（图外直接调用 org-hunt 轻量提示词，
不套用其训练场景三件套契约，默认关闭，需 ENABLE_DEEP_RESEARCH=1）。
reasoning_source/experience_refs/research_used 增补进 subtask-plan.json，
向后兼容旧注入桩。

范围收窄：不做"历史同类 goal 检索"（需要语义检索基础设施）；Phase 3-5
（任务池认领/子任务预算/看板 UI）涉及核心调度引擎范式级改动，另起设计。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H85SS5hVC4u1PbVhjmrhH8

47号：itemized 子任务物化在当前 workgraph-planning 常见子图形状下因 acceptance.md
永远产不出来而形同虚设；maybeMaterializeItemizedSubtasks 新增兜底，缺失时改读
已被 44 号文档证实稳定产出的 goal-benchmark.json 的 dimensions[]。

46号 Phase 1：新 agent subtask-planning，钩在 enqueueTaskRun（显式 opt-in，只在
goal 批量下达/单条 task 下达两处触发，保住 quick task 零 LLM 调用的既有保证）；
产物写共享 artifacts/subtask-plan.json，复用 R-19.3 任务级共享索引对接下游。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

真实事故：h3video 公司 h3-story-draft 节点卡在 status=running，背后 CLI 会话已死但服务器
进程没重启，开机一次性孤儿扫描/goal-task 巡检/wallclock 看门狗均看不到，ceo 被转发问题后
绕过引擎自己拉会话，陷入死循环。

- sweepStaleRunningAgentCalls + startStaleAgentCallWatchdog：运行时长超阈值（默认 25 分钟）
  的 agent_call 节点判 infra_flake 原地重跑，5 分钟一次巡检，挂进 server/index.js
- ceo/tools.md 补 force-fail 端点（已有，未改代码）的使用文档 + 禁止自拉会话的规则
- ceo/heartbeat.md 同步更新"不用管的"一节

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WjFL1nfPDqZnJeuskYHwvs

Snapshot-then-stop race in stopRun() left child runs created after the
snapshot outside the stop scope; add auto-mode guard rejecting manual
/next on execution_mode='auto' runs (source of the concurrent-advance race).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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

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

回应"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

昨晚做完 42 号文档 Phase 2-4 之后忘了同步 docs/README.md 索引，还停在
"Phase 1 已实现，Phase 2-4 待开工"。这次一并把两份文档从 todo/ 挪进
done/（39 号 P1-P5、42 号 Phase 1-4 均已实现，符合仓库自己的归档约定），
索引表挪到对应位置，两处过期描述改成完工状态。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

org-coder 等 9 个角色（含 _base 骨架模板）的四段式阶段流转靠调
bin/lemon.js task transition，打到 agent-chat.js 的 /task/transition——
这个端点靠自己的 sessions Map 找会话，work graph 节点场景下找不到，
阶段流转静默跳过，中间产物不进任何跨节点共享的轨迹。

调研确认范围后选了最保守的实现：不改 bin/lemon.js 的 CLI 签名、不碰
agent-chat.js（当天正被另一个并行会话实时编辑，风险太高）。关键发现
是 --artifact 参数本来就是 .../runs/{rootRunId}/nodes/{nodeRunId}/...
形状的路径，两个 ID 已经现成编码在里面，不需要给子进程塞新环境变量，
不需要改一个字的 agent.md 提示词。

bin/lemon.js 在原有调用之外 best-effort 追加一次 POST
/api/graph-runs/phase-note，新端点从 artifact 路径解出两个 ID，
校验 run 真实存在后调 emitEvent() 追加 timeline 记录，只追加不碰
graph_run_nodes/graph_runs 任何一行——不影响 needs/produces 契约。
P0 拦截/OKR 更新两段旧逻辑维持原样，新端点是独立的第二条路径，不是
迁移。

新增测试 4 例，全量测试 1503/1506，零回归（剩余失败全部来自另一个
并行会话进行中、还未提交的工作）。42 号文档 Phase 1-4 全部完工。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

39 号文档 P5 落地的是"配了 company.json.target_dir 就生效"这一半，
"人怎么把这两个字段填进去"此前只能手工编辑 company.json。

复用已存在的 PUT /api/company/:companyId（companyService.update()），
没有新建端点。新增 target_dir/target_mode 分支，校验直接调
path-resolver.validateLinkedTarget（39 号文档 P5 抽出来的共享函数，
和 graph-engine.js 运行时校验同一份判据）：合法路径写入成功、敏感
路径黑名单拒绝、linked-new 非空目录拒绝、linked-existing 不存在拒绝，
校验失败路由层转 400；传空字符串清空配置；不传 target_mode 默认
linked-existing，与 graph-engine.js 的 readCompanyTargetConfig 同口径。

前端：CompanyDashboard.vue 概览 tab 加一张配置卡片，本地表单状态
不直接双向绑定 selectedCompany，保存失败不会冲掉用户刚打的字。

新增测试 8 例，npm run web:build 编译通过。**未做真实浏览器点击
验证**——服务器上有其它并行会话真实在跑的 agent 进程，这次没有重启
服务器（42 号文档 §二记过一次"重启杀掉别人真实进程"的教训），文档
里标记了这个已知缺口。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

39 号文档 §四.4 拍板"ceo 全权自主 enqueue，但 max_parallel_tasks /
DEFAULT_TASK_BUDGET / goal 级 org-validator 这几道闸门必须照样拦住
它"，落地时没补这条测试。这次补上，走 ceo 实际会用的通路（draft:true
+ created_by:'ceo' → /enqueue），不抄近道直接摆数据库行：

1. 坑满时 ceo 建的任务排队，不插队。
2. 预算给 0，checkBudget 照样判耗尽，created_by 不改变结果。
3. ceo 建的两条 task 挂同一个 goal，全 completed 后 goal 级验收只调一次。

全量测试 1486/1490，零回归。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

冲突在 docs/README.md：并行会话在真实端到端测试里发现 boss agent（39 号文档）还有
三个单测没覆盖的真问题，把 39 号重新留在 todo/ 并拆出 42 号跟进文档；与我这边把
39 号挪进 done/ 的判断冲突——采纳对方判断（39 号文档物理路径挪回 todo/system-design/，
докс/README.md 用对方更新的行 + 补 42 号一行），因为他们是基于更新的真实测试结果。

顺带把 29-dream-design.md 这次会话移到 done/ 后遗漏的引用修掉：
system/agents/{dream-distiller,dream-screener}/agent.md、
server/{routes/dream.js,services/dream-service.js}、
server/tests/unit/dream-routes.test.js 六处 docs/todo/system-design/29-dream-design.md
路径改成 docs/done/system-design/29-dream-design.md（no-dead-path-references.test.js /
agent-md-refs.test.js 两条守卫测试之前没扫到这几处，这次真跑测试才暴露）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

29-dream-design / 33-needs-gate-role-filter-bug / 35-validation-rigor-and-body-readiness-proposal /
39-boss-agent-task-supervision / 40-agent-chat-streaming-interrupt 逐份核实状态确认已完成
（后两份状态行本身滞后于代码，已在上一提交订正），按维护说明从 docs/todo/system-design/
挪到 docs/done/system-design/，docs/README.md 的 todo/done 两张表同步更新。

顺带修复 4 处指向这 5 份文档的相对路径引用（28-followups / 31-work-graph-fail-fallback-coverage /
34-validator-scored-without-real-deliverable / 41-graph-vs-fde-reliability-discussion），
文件搬家后原来的同目录相对链接会失效，改成 ../../done/system-design/ 的正确相对路径。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

服务器重启会杀死正在跑的 graph 节点背后的真实进程，但 graph_run_nodes.
status 永远停在 running（ceo 的两条唤醒路径都只认 blocked，对这个状态
完全不可见）——39 号文档真跑复盘撞出来的坑，这次补上。

1a：graph-engine.js 新增 sweepOrphanedRunningNodes(cutoffIso)，复用
routeFailure 的 infra_flake 分支（不发明新状态），server/index.js 在
本次进程启动时刻挂一次开机扫描，排在其余「补一次全量扫描」钩子之前。

1b：新增 forceFailNode() + POST /:id/nodes/:nodeId/force-fail，补上
retry 端点管不到 running 节点这个缺口——人工/ceo 判定"这个真的救不
回来了"时的手动出口，转 fail 后交给既有失败路由处理，不发明新路径。

新增测试 12 例（graph-engine-orphan-sweep.test.js 4 例、
graph-run-force-fail.test.js 8 例），全量测试 1483/1487，零回归。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

上一条 commit 只带了纯改名（git rename detection），文件内标题、
39 号文档的两处引用、docs/README.md 的索引更新都漏提交了（git add
命令里混了一个已经改名走的旧路径，报错后整条 add 没生效）。这次补全。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

两份文档文件名不同、内容不冲突，但编号巧合容易读混。改名 + 更新
39 号文档里的两处引用 + 补 docs/README.md 索引（39 号状态同步成
已实现，42 号补一条索引）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9

P1-P5 落地后做了一次真实端到端测试（建公司→下 goal→ceo 监督→真实跑出
一个 Playwright 验证 5/5 通过的贪吃蛇游戏）。1469 个单测全绿，这次真跑
却测出至少三个单测没覆盖到的真问题：服务器重启会让 in-flight 节点变
僵尸且无人能自动发现、graph-run.js 鉴权缺口（已在另一个 commit 修过）、
规划/反思轨迹没有统一可追溯位置。

39 号文档新增「七、真跑复盘」记录技术缺口和过程教训；41 号文档把复盘
沉淀的待办拆成四个 phase 的开发计划（卡住恢复闭环 → 闸门穿透性回归
测试 → target_dir 配置入口 → timeline 承接规划轨迹），按优先级排开工
顺序。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9