宜博 / lemonboss

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

Conflicts:
	system/agents/ceo/agent.md
	system/agents/ceo/soul.md

- 7 个 soul.md/agent.md 的 dream 受管区块更新（agent-creator/ceo/master/orggraph-planning），2026-09-02 跨公司经验沉淀
- h3-video-prompt agent v6 轮次训练产物（hunt/digest/evolve）+ SKILL.md/agent.md 同步更新

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

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

真实回归暴露"认领后没有触发源"的真问题，讨论后发现"认领"（pull，CAS
抢占）要解决的"多方竞争同一条任务"场景根本不存在——只有 CEO 一个人拍板
要不要派、派给谁。CEO 心跳统一发现+直接派发（push）成本更低，还能顺带
控制派发节奏，不需要认领。

删除：claimSubtask/unclaimSubtask（work-graph-db.js）、POST /claim、
POST /unclaim（company.js）、CLAIMABLE_WORK_ROLES 白名单、
claimable/claimed 两个 status 值、claimed_at 列。

改名：subtask_kind 的 'claimable_work' → 'decomposed_work'
（materializeClaimableSubtasks → materializeDecomposedSubtasks），
"认领"这个词不再准确，物化出的行现在就是普通 draft task。

新增：
- triggerSubtaskPlanning 加递归防护（task.parent_task_id 非空直接跳过）
  ——设计 v2 时发现的真实漏洞：CEO 对子任务调 /enqueue 会默认
  withSubtaskPlanning=true，不挡会对已经是"第几步"粒度的子任务再拆一层。
- createDecomposedWorkGraph：现造一张两节点轻量 work graph
  （impl=org-coder、validate=org-validator，agent_call 不是 subgraph），
  跳过公司完整 org graph 的 brd/prd/sdd 规划仪式——subtask-planning 已经
  把"怎么做"拆到这个粒度了，再走一遍纯属重复劳动。含一条没有真实验证过
  的假设（org-coder/org-validator 裸调用会不会读不到预期上下文），如实
  写在代码注释和文档里。
- enqueueTaskRun 按 subtask_kind 选图：decomposed_work 走轻量图，
  普通 task 行为不变（回归测试覆盖）。
- ceo/heartbeat.md、tools.md 补了巡检 decomposed_work 草稿 + 判断节奏
  + 调用现成 /enqueue 的指令。

测试：删除 task-pool-claim.test.js（随 v1 代码作废），新增
task-decomposition-dispatch.test.js（12 条），更新
task-decomposition-validator-gate.test.js 措辞。全量单测 1191 条，
1189 passed（唯二失败与本次改动无关），零残留 CLI 子进程。

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>

新增两条经验：阻塞任务事件驱动唤醒需周期性兜底扫描、校验失败重试边应指回产出方而非上游规划方。

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

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

实现路径：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

test/integration 类节点从不产出一个能被 indexNodeOutputs() 认作
kind='log' 的文件（落盘的都是 coder.log/test.log，归入 kind='artifact'），
required 的 log 契约永远无法满足，把节点卡进 missing_required_input
死循环。33 号文档修过一次模板文件，但 workgraph-planning agent 实际
照抄的是 tools.md 里一份没同步更新的旧范例，同一个坑复现（snakegame-co
T-mtfh2kuf-7c31）。这次把底线收到 declareEdgeContract 唯一落库口，
不再依赖每个模板/每次 LLM 规划都记得写对；顺带同步 tools.md 范例。

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

之前几轮全量跑一直有 3 个失败，当时判断是环境耦合/pre-existing、跟本次改动无关就没细查，
这次逐个真查了一遍，三个都是真 bug：

- system/agents/sdd-planning/SKILL.md：Evolve 训练产出从 train/evolve/SKILL.md 提升到
  生产位置时，"训练依据"引用的相对路径没跟着调整（少了 train/ 前缀），指向了不存在的
  system/agents/hunt/、system/agents/digest/；真实文件其实在同一个 agent 自己的
  train/hunt/、train/digest/ 下，补前缀即可。

- graduation-criteria-reality.test.js：断言死等 code-planner 的状态回到 'active'，但
  该本体的 config.json 早已从曾经踩坑的 "training" 改成了真正毕业态的 "enabled"——
  seedAgents() 把 DB 同步成 'enabled' 是设计如此（同为毕业态，不是降级），不该被判失败。
  改成用 isUngraduatedStatus() 判断"没被打回未毕业域"，不再钉死具体状态值；顺手把
  graph-seed-service.js 里那句会随源码变化过期的注释也改成不点名具体值。

- graph-engine-extend-budget.test.js：一颗时间炸弹——用硬编码绝对时间戳
  '2026-08-23T05:23:52.886Z' 模拟"卡住很久了"，但被测代码真的调 Date.now() 算经过时长，
  写这条用例时"经过时长"确实超过 2h 上限、又低于追加后的 6h 上限；现在真实时间已经过去
  178 小时，连追加后的上限都超了，测试注定要红，跟被测代码毫无关系。改成
  Date.now() - 3小时 相对计算，不再随时间推移漂移。

全量 vitest 131/131 文件、1089/1089 用例通过。

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

冲突在 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>

Conflicts:
	system/agents/innovator-evolver/agent.md
	system/agents/innovator-evolver/soul.md
	system/agents/master/agent.md
	system/agents/master/soul.md
	system/agents/org-innovator/agent.md
	system/agents/org-innovator/soul.md

第 11 轮真跑：给 org-evolve 规划验收节点时，按名字语义匹配选了 benchmark-validator
（"对评分结果做验收判决"），但该本体硬编码读 artifacts/goal-benchmark.json（只有
planner.json 的 goal-benchmark 节点才产），Hunt→Digest→Evolve 链路里没有这个节点，
两轮都判 blocked。benchmark-validator / testdata-validator / validator-triager 不是
通用验收工具，是 validator.json 骨架专属、绑定任务级共享契约文件的本体。

workgraph-planning/agent.md 加第三条硬规则：判据从"名字像不像"改成"这条链路里有没有
节点产 goal-benchmark.json/acceptance.json"。deliverable.json 的 whenToUse 补上"自带
自评分收敛逻辑的节点也不需要外部验收节点"例外条款并点名这次事故。

第 12 轮真跑验证：org-evolve 的规划记录原文引用新条款选中 deliverable.json，
backward_count=0，评分 83/行业均线 78 收敛，全流程干净跑完。41 号文档收尾——
11 轮真跑挖出的 6 个独立缺陷全部修复并逐条验证生效。

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

核心修复：indexNodeOutputs() 此前只扫节点私有目录，不扫项目根——但引擎自己的写入边界
明确允许交付物写项目根，导致内容型交付物节点（产出写进项目根时）永远进不了 R-19 产物
索引，下游 needs 声明永远查不到实例。新增 readDeclaredProduces()：agent 可在
contract.json 里显式声明 produces:{kind: 绝对路径}，校验（绝对路径/落在项目根或私有目录内/
文件真实存在）通过才登记，不满足就整个 kind 判「没产出」，不静默放过。全局提示词
（describeArtifactContract）同步更新，所有 org/work 节点自动学到这个新字段。

新增 org-hunt / org-digest / org-evolve 三个 graph 原生 agent（方法论抄
innovator-hunt/digest/evolver，协议原生兼容 graph 引擎），配套新增 work-graph-templates
的 deliverable.json（内容型交付物骨架，不引入验证 agent）。11 轮真实试跑挖出并修复 5 个
独立缺陷（详见 41 号文档问题 7）：建公司自动规划与手写图的竞态、work-graph 模板库缺内容型
交付物骨架、验收节点任务描述范围溢出、两个规划 agent（orggraph-planning/workgraph-planning）
的路径口径写错、以及上述 R-19 索引缺口。最终产出与原生 FDE 对比：内容骨架可迁移、质量不
打折，但可靠性差距悬殊。

补充说明：system/agents/{ceo,innovator-evolver,master,org-innovator}/{agent,soul}.md 是
本会话开始前已存在的 dream 自编辑改动，随本次提交一并收进去，不属于本次改动范围。

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

排查「前端刷新不及时/没有打字机效果」发现现状已是 SSE，不需要换 WebSocket，
真正缺的是三件独立的事：

- 打字机平滑：后端把 ACP chunk 按 10 字符切片再发 SSE，前端用定时器队列
  （agentChatEvents.js 的 createTypewriterQueue）匀速吐出，抹平网络突发。
- 打断并发送：执行中解锁输入框，新增 ⤴ 按钮与 ⏹ Stop 视觉区分；stop 端点
  改为轮询确认 agentChatLocks 真正释放（3 秒预算）再返回 cleaned 字段，
  前端据此决定直接发送还是走"强制发送"兜底。顺手修了一个真实并发漏洞：
  同一 agentId + 同一 convId 的并发请求过去完全没有闸门，只是一直靠前端
  textarea 的 disabled 属性侥幸没被触发。
- 串台加固：把 handleEvent 分发逻辑抽成不依赖组件实例的纯函数
  （agentChatEvents.js），补上 9b1c3f1 那条不变式的回归测试。

已用真实 Claude CLI 会话（非 mock）在浏览器里验证打字机效果、打断并发送
全流程、以及纯 Stop 无回归。

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

按 39 号设计文档落地 ceo 常驻监督：company.js 的 goals/tasks 端点
放行内部令牌自环调用，POST /tasks 支持 draft 模式（agent 自主提任务
不再立刻烧预算），ceo 补雇进公司创建流程；task-settle 新增事件驱动
唤醒 + 30 分钟兜底轮询；graph-engine 的回退熔断收敛时顺手回写一条
draft task，形成"卡住 → 自动/ceo 判断 → 重新规划"闭环。

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

- system/agents/deep-research/: 新 Agent 本体（agent.md/prompt.md/soul.md/config.json）
  及 train/hunt 调研结论（knowhow_v1 + sources_v1.json，含 sha256 信源母本）
- h3-video-prompt: train/digest、train/hunt、train/evolve 的 v2/v3/v4 全套训练产物，
  SKILL 升级 v0.5.0（习语甲/乙分轨 + prompt/block/clarify 三轨计分）
- org-innovator: docs/ SKILL 模板库与 soul.md 更新（外网访问 SOP R1-R5、lark-cli 能力）
- master / innovator-digest / innovator-evolver / innovator-hunt: 本体文件更新
- packages/agent-core/base/common/tools-base.md: 收录 lark-cli 入口与「搜得到≠读得到」边界
- bin/lark-cli: 飞书 CLI 入口脚本（wrapper）
- .gitignore: 排除 .pnpm-store/、.env.bak*（防密钥入库）、train/hunt/sources_raw/
  与 train/evolve/_v*_artifacts/（中间产物沿用既有裁决，只留磁盘）

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

dream-distiller/dream-screener 定时任务的自动产出，全部落在 <!-- dream:begin/end --> 受管
区块内，区块外内容未改动。覆盖 agent-creator/coo/cto/innovator-digest/innovator-evolver/
innovator-hunt/org-innovator/orggraph-planning 共 8 个本体，纯新增无删改。

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

独立试验节点（parent_id: null，不接入任何真实公司/图，不碰生产 system/agents/unit-tester/），
四段式训练全部完成：真实基线 32.2 分（不合格）→ Hunt 挖出 7 条现状缺口 → Digest 建出 7 维度
benchmark_v1.md → Evolve 产出可执行操作手册 SKILL.md，独立样本压力测试拿到 94.4 分，
超过 80 分目标线。

追加一轮 Round 2 复测（round2_verification.md）：Evolve 阶段两处修正（D2 固定模板要求"不采信"
锚点词、D5(a) 可复现性核对）落到 SKILL.md 之后从未重新打分，94.4 分测的其实是被淘汰的 Round 1
草稿。复测拿两份样本验证：①对已用过的样本做假设性套用，98.0 分，确认 D2 修正干净有效，同时
发现 D5(a) 有 rubric 自身的结构性天花板（"全新任务非中断恢复"场景最高只能到 4 档，与修正力度
无关）；②对一份此前从未打过分的真实样本做非假设性打分，90.4 分（优秀档），过程中还纠正了上一轮
一处未经核实的事实错误（误判某样本缺配套 _research.md/_plan.md，实际齐全）。

按用户明确要求本轮不做 Deploy：config.json 的 status 仍是 training、benchmark_score 仍是 null，
生产 system/agents/unit-tester/ 未被触碰，训练产物等待人工审查后决定是否合并。

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

三者是 heartbeat-service 里唯一 enabled=true 的系统级 Agent 本体，
不管有没有公司雇佣都会挂心跳定时器（每 5/10 分钟打一次），跟公司数据无关。
当前没有实际公司在运作，先关掉避免空转。

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

- Hunt→Digest→Evolve→Deploy 全流程，8场景测试均分98.71/最低97，status enabled
- 飞书标杆文档访问受阻(登录墙)，改用 MiniMax 官方 GitHub 仓库原文替代，如实记录在 train/fde_report.md

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

coder/config.json 长期停在 status:training，从没真正毕业，也从没做过 FDE 训练——是这次
"哪些 agent 该训"排序里排第一的节点，因为它是实际写代码、决定最终产品质量天花板的执行节点。

独立试验 coder-methodology-trial 训练产出（89.6/100，及格线65/目标线80）已手工合并进
agent.md 四段式生命周期：RESEARCH 阶段新增两张必建清单（接口契约锚点表 + SDD明确禁止清单）；
EXECUTE 阶段新增"三支自问"机械动作（踩中禁止项/SDD未提及/引入新标识符，各自怎么处理写死）；
VERIFY 阶段新增信号词检查（判定依据出现"代码走查/规则推导"等字样即不算数，必须真跑命令）+
可重放性三要素检查 + 一页纸自检表。全部配了真实历史反例：p-cgfdcr 的 currentScrollTarget
状态变量偏离 SDD 却未留痕、p-v82tpc 独立验证时新发现的 header→nav 语义标签改动未标注。

诚实说明（agent.md 开头 + soul.md 原则7/8 都写了，别在别处混说）：89.6 是这套操作手册的
文本质量分，训练全程没有真的把 SKILL.md 喂给一次真实 coder 会话跑任务再打分，回答的是
"手册写得够不够具体"，不回答"照做真的能拿多少分"——这是训练报告自己指出的方法论局限，
不是自谦，照抄保留，避免后续把这个数字误用成"已验证的执行可靠性分"。

coder-methodology-trial 完整训练材料（agent.md/soul.md/SKILL.md/train/{hunt,digest,evolve}）
随本次一并提交。

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

org-planner/agent.md 原来固定要求 workgraph-planning 只能画 brd/prd/sdd/benchmark/
validator 五节点链，不管任务是不是需要外部信息支撑。现在把"必须交出 brd/prd/sdd/
acceptance 四份"重新定义为交给 org-coder 的固定契约，但产出这四份东西的中间步骤不再
写死——按信号词（调研/竞品分析/市场行情 → web-search/deep-research 类节点；视频/广告
投放素材 → video-search 类节点；对接XX API/拉取实时数据 → api-integration 类节点）
明确授权在 brd 之前插入调研类节点，产出喂给 brd/prd/sdd。

顺手删掉了一段从未被真正执行过的死代码：文件里原有"四段式生命周期 RESEARCH→PLAN→
EXECUTE→VERIFY / task transition 命令行流转"的执行脚本，是把 org-planner 当成会被
直接派单执行的单体 agent 来写的，跟当前"org 层节点永远是 nodeKind:'subgraph'，实际
由 workgraph-planning 规划子图执行"的架构对不上，从来没跑过。

真实测试验证：给一个"调研竞品YouTube广告 + 对接定价API拉实时数据 + 产出竞争分析报告"
的任务，workgraph-planning 真的规划出了 7 节点图（比标准 5 节点多两个调研节点），
其中 pricing-api-integrator 是全新按 hired_from_base 分支现场造的本体，经 agent-creator
+ FDE 训练流水线异步补全（96.00分），随本次一并提交。

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

code-planner：status training→enabled，benchmark_score 96.35（行业基准82+14.35），
六节输出模板与53判据写作规则落进 SKILL.md。

sdd-planning：benchmark_score 89.3，新增两处「深挖」小节——接口契约的可独立复现性
四类雷区（自证式验收/结论句代替实测值/风格描述无上限/占位内容也能通过）+
data_shapes 字段约束与业务术语映射规则，随附完整 hunt/digest/evolve 训练材料。

goal-benchmark：补一条自查项——pass_threshold 落档不能和 rubric 里"不达标"的文字
描述用同一个分数区间，否则及格线形同虚设（2026-08-23 抽查 3/5 样本命中此模式）。

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

独立试验节点，不接入任何真实公司/图。真实 Hunt→Digest→Evolve 训练"planner.json
五节点该不该裁"这类元规划判据，2 轮收敛 100/100（真实基线 34 分不合格，同义反复式
判据 15 分反而更低）。训练自验证时发现两处真实结构漏洞（裁 brd 遗留失效 backward 边、
S5 复用门在当前仓库数据下无法触发），均已如实记录并给出兜底方案。判定表已手工套进
生产 workgraph-planning/agent.md（见上一条提交）。

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

在 agent.md Step 4 加了具体的裁剪判据（对应训练出的 SKILL.md：S1-S5 五个复杂度信号 +
G2/G3 两道门 + planner.json 五节点逐个判定表），替换掉之前只有"你可以裁剪"这句孤立授权
（真实回归验证过只打 34/100，不合格）。同时补上训练自验证时发现的真实结构漏洞——裁掉
brd 会留下一条指向不存在节点的失效 backward 边，连带修正清单写进了裁剪判据里。

Step 5 的规划记录模板新增"1.5 复杂度信号取值"一节，为 G3 复用门积累历史数据（当前
仓库还没有任何历史记录标注过信号取值，这道门会一直走 fallback，直到开始积累）。
soul.md 加一条对应工作原则：裁剪判据要具体，同义反复式判据（"任务简单就裁"）训练
验证过反而只有 15 分，比不判断还糟。

1411/1414 测试通过（3 个失败是其他自主进程遗留、与本次改动无关的既有问题）。

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

两个独立的小修复，都是这次 e2e 回归 + 用户讨论"workgraph-planning 该怎么训练"时发现的：

1. workgraph-plan-<taskId>.md 撞名：一个任务里 org-planner/org-coder/org-validator
   各自调 workgraph-planning 一次、各自的规划记录却共用同一个文件名，落在同一个项目根下，
   后写的原样覆盖先写的——真实撞见过（org-planner 当时的规划记录被 org-validator 覆盖，
   事后一个字都找不回来）。改成 workgraph-plan-<taskId>-<宿主orgNode节点名>.md。

2. subgraph 节点结算 → workgraph-planning 自己的 memory.md 桥接：阶段一的
   recordNodeOutcomeMemory 明确排除了 subgraph 节点（那是给 agent_call 记的），导致
   workgraph-planning 每次规划出的图最终跑得好不好，完全没有可积累的历史——这正是它
   "允许裁剪却没有具体判据"这个问题一直无法通过真实反馈自我改进的原因之一。新增
   recordWorkgraphPlanningMemory，在 subgraph 节点结算时把结果记进 workgraph-planning
   （全局唯一规划本体，不是宿主 org node 自己的身份）的 memory.md，只在真实规划
   （planWorkGraph===defaultPlanWorkGraph）时记，避免测试夹具污染真实目录。

新增 3 条回归测试，graph-engine 相关测试文件全绿。

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

在 prd-planning/agent.md 加了「描述性语言扫描」+「内容深度下限」+「业务度量翻译」三段
具体操作（对应 36 号文档训练出的 SKILL.md Step 4/5），soul.md 加一条对应工作原则。
用同一个 e2e-demo 首页任务重新跑了一次端到端回归验证：新 PRD 把"大图/简洁大气"等形容词
逐条翻译成量化规则，最终产出的 index.html/style.css 精确对应这些数值（视觉元素
min-height:320px、区块间距 96px/56px 等），文案不再卡在"非空"这条线——训练效果在
真实任务里得到验证。

回归过程中发现一个新的、独立于本次改动的引擎缺陷：org-coder-test 被反向打回后产出
「建议重跑 org-coder-validator」的诊断文件，引擎把诊断文件里的 infra_flake 标记当成
了这个节点自己的执行结果，导致原地重跑但从不路由到诊断建议的目标节点，陷入没有熔断线
的确定性死循环。记进 30 号文档，留待后续修复。

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

新建独立试验节点 prd-methodology-trial，走真实 Hunt→Digest→Evolve 训练 PRD 撰写方法论：
2 轮 Small Loop 提前收敛（96/97 分，真实基线 50 分），用三个真实历史项目反推验证方法论
有效，Deploy 范围限定在该独立节点，未触碰生产 prd-planning。结论：FDE 对方法论类角色
确实管用，但收敛速度/验收严谨度依赖任务书里显式写明的自纠正要求，非免人工黑盒。

过程中连带修复同一个 2026-08-16 改名批次（innovator→org-innovator 等）遗留的 5 处死链：
company.js 两处硬编码调用、CompanyDashboard.vue「重新训练」按钮，以及四个本体各自
config.json 内部 id 字段从未随目录改名同步更新，导致 /api/agent/list 展示层用假 id
显示成死卡片。顺手修了 AgentScaffold 默认 tools.md 模板一处裸相对路径缺陷（对应
agent-md-refs.test.js 里已登记多时的已知缺陷）。

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

用户问"当前 company 用到的所有 agent 骨架是不是都完整"，顺手全量核对了一遍
e2e-demo 实际会用到的 18 个本体（org 层三个 + 三张 work graph 骨架的全部节点 +
四个元规划本体），揪出两处：

- unit-tester：这次真实回归测试撞见过的那个空骨架（32/34/35 号文档记录的样本），
  agent.md/soul.md/SKILL.md 三份全是没填充过的 _base 原始内容。照 coder 的规格
  （同一张 executor.json 骨架的实现节点）写了一份对应的自测节点定义——四段式细则、
  网页/代码两类产物的检查手段选择（网页类点名用 scripts/visual-acceptance-check.mjs，
  不许用正则解析文本冒充浏览器检查）、数据契约、硬规矩。

- org-coder：完全独立于本次回归测试撞见的一处更早的缺口——soul.md 从 8/18 创建
  agent.md 起就没写过，这个本体已经在多个真实任务里跑过。照它自己 agent.md 里
  "实现节点"这个身份定位、比着 coder/soul.md 的规格补上，顺带记了一句它是跨公司
  共享本体（P1 虚拟引用），别把单个公司的业务细节写进去。

agentLocator.missingBodyDefinition() 核对过，18 个本体全部通过。全量单测
1012/1012 通过（本身不涉及后端逻辑改动，只是确认没有连带影响）。

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

e2e-demo 公司真实回归任务（T-mt2r6fz0-125b，31/33 号文档验证用）跑 org-coder
支线时新招的两个本体，system/agents/ 是全部 agent 本体的唯一目录，理应入库。

coder/agent.md 正常填充过（角色专属内容）。

⚠️ unit-tester/agent.md 仍是未填充的 _base 原始骨架（带 LEMONBOSS_BASE_SKELETON
哨兵标记）——这正是 32/34/35 号文档反复分析的"招聘装配没填充完"问题的真实样本，
如实提交，不假装它是完整的。它已经在真实图执行里跑过一整条任务（见 34 号文档
§五），提案 A（35 号文档，commit bab675c）落地后，这类未填充本体会在图执行前
被 body_not_ready 闸门拦下，不会再静默拿空提示词跑真实调用。

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

35 号文档剩下的三个提案，彼此直接相关（C 产出 D 消费的证据，B 展示 D 算出的结果），
一次做完。

提案 D（goal-contract.js 引擎级证据闸门）：
  `runBenchmark` 新增 evidence 检测——`evidence_hint` 命中"浏览器/视口/开发者工具/
  console/network/截图"类关键词的维度，必须在 evidence.<dim> 有真实字符串支撑，
  否则该维度判不过（哪怕分数达标）。证据来源两处都认：`--target` 文件自带的
  `evidence.<dim>`，或同目录姊妹判词文件 `attempt-<n>.json` 的 `dimensions[].evidence`
  ——后者是 benchmark-validator/agent.md 早就在教的既有写法，不用 agent 多写一份。
  新增 `dimensions[].evidence_required` 字段随判决落盘。6 条新单测。

提案 C（可复用视觉验收工具）：
  新增 scripts/visual-acceptance-check.mjs，四个子命令（overflow/style/console/
  contrast），封装最常见的几类真实浏览器检查（Playwright），agent 通过 bash 直接
  调用，不用每次自己临时想办法（真实撞见过两个极端：一次真写了 Playwright 认真测，
  一次只写了正则解析文本）。配一份不进 vitest 快速循环的独立冒烟脚本（起真
  Chromium，几秒量级）。benchmark-validator/agent.md Step 2 加了引用说明。

提案 B（控制台证据可见性）：
  GET /api/graph-runs/:id 新增 benchmarkVerdicts 字段（只读 goal-contract.js 已落盘
  的判决，不重新计算）。NodeDetailPanel 概览 tab 新增"验收证据"小节：逐维度显示
  分数 + 是否有证据支撑，evidence_required 且缺证据的标 ⚠️。纯展示，不改判定逻辑。
  2 条新单测。

全量单测 1012/1012 通过；控制台功能用 Chrome 实测过（截图确认"验收证据"小节正确
渲染）。

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

org-coder-validator 在真实回归任务里被 missing_required_input 反复误判 blocked：
executor.json/executor-fanout.json 的 test/integration→validator 边声明
produces:["log"]（required 默认 true），但 test 类节点从不写出能被 indexNodeOutputs
认作 kind=log 的文件（coder.log 实际属于 impl，test 自己的 _plan.md/_research.md
认不出 kind 也没有一对一无歧义可猜），这个 kind 因此永远不会被索引到，
requiredInputsMissing 每次都判缺失——不是时序问题，是结构性、每次重试都复现的硬伤。

改成 { kind: 'log', required: false }，对齐 validator.json 已有的写法（它的
needs:artifact 早就标了 required:false）。真正必需的 needs:artifact 不变，
仍受硬闸门保护。

中途走了一段弯路：最初以为该改 inboundContracts() 按 role 过滤只留 needs，
改完单测炸了 9 个用例——大多数边只声明 produces（无配对 needs），这条链路
正是 T-mt25ecbd 产出闸门依赖的数据源，按 role 过滤会静默削弱那次修复。
已撤回（work-graph-db.js 这次只加注释，没有逻辑改动），细节记在 33 号文档。

新增回归用例 graph-files-index.test.js ⑪：produces required:false 且该 kind
从未被索引到时不拦下游成功，同边 needs:artifact(required:true) 依旧受保护。
全量单测 998/998 通过。

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