宜博 / lemonboss

T-mtratkfb（源自 T-mtraluo2 系统性缺陷评估的缺口一）：unsatisfiedRequiredProduces
在 contract.json 缺失时退化成「私有目录里随便有个非元数据文件就算数」(hasCandidates)，
而 _base/agent.md 四段式生命周期（RESEARCH→PLAN→EXECUTE→VERIFY，全仓库几十个角色共用）
第一阶段就会落 `_research.md`，比真正的交付物早得多——org-coder 只做到 RESEARCH 就能
用这份笔记骗过闸门被判 success（复现：run_fe5a50b4e836，项目根空目录、节点私有目录
只有 _research.md，却被判 success）。

修复：candidates 过滤掉 `_` 前缀文件（全仓库通用的阶段性私有笔记命名约定，真交付物
从不用这个前缀，不会误杀合法产出）。

回归测试：graph-files-index.test.js 新增④c，按 run_fe5a50b4e836 的真实文件状态复现
（只写 _research.md），先反向验证过——去掉过滤条件时该用例确实 FAIL（status 变
success），加回后 PASS（status 变 blocked / produces_missing）。

缺口二（impl↔validate 图缺 fail/backward 边）已在 8b1e7fb6 一并修复
（createDecomposedWorkGraph 补了 validate --fail--> impl 退回边，task-decomposition-
phase4.test.js 三条新测试覆盖边形状/真实退回重试/硬顶熔断），本次未重复改动，仅确认
其单测仍全绿。

全量单测 1636/1638 通过（2 个失败 env-example-secrets / test-id-stability 与本次
改动无关，revert 后依旧失败，确认是改动前既有缺陷）。

复现样本 run_fe5a50b4e836 的图定义创建于两处修复落地之前（13:39 vs 8b1e7fb6 的
17:09），结构上永久缺 backward 边，无法靠新代码自愈；建议由 COO 走正常回收流程
（取消该 blocked 子任务，让父任务 T-mtradxxu-b112 重新派发一次子任务，新图会走
已修复的 createDecomposedWorkGraph）而不是热改这一条历史数据。

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

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

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

真实起 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

验证 46 号文档 Phase 3 v2（CEO 心跳发现并派发子任务）时，触发 CEO 心跳
直接撞上 401——company-heartbeat-service.js 的 _sendAgentChat 和
heartbeat-service.js 的 _triggerHeartbeat 都在自环调用
POST /api/agent/:agentId/chat（agent-chat.js 挂了 requireAuthOrInternal），
但两处都没有带 INTERNAL_TOKEN_HEADER——company.js/task-settle.js 的同类
自环调用早就在带，这两处漏了。

失败只落一行 console.warn，界面上什么都看不出来，影响的不只是 CEO 心跳：
两套心跳系统（per-agent 的 heartbeat-service 和公司级的
company-heartbeat-service，含它驱动的 pipeline/schedule 触发）都受影响。

按现成模式补上内部令牌头。全量单测 1189 passed（唯二失败与本次改动
无关），修完真实验证 CEO 心跳能正常跑完整段推理会话。

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

真实回归暴露"认领后没有触发源"的真问题，讨论后发现"认领"（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

真实公司走完完整链路（物化→认领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'，区分 43 号
文档的验收条目物化和 Phase 3 的可认领工作项物化，共用一张表不新开）+
claimed_at 列（批 6 迁移，ALTER ADD COLUMN，纯增量向后兼容）。

- work-graph-db.js：createTask 新增 subtaskKind/status 参数 + 校验；
  claimSubtask/unclaimSubtask 是全仓库第一个真正的"认领（pull）"CAS 写入
  （之前 assignee_agent_id 全部写入点都是"派发 push"，没有先例可抄，照抄
  claimQueuedTask 的 changes 判据）；materializeClaimableSubtasks 把
  subtask-planning 的 steps[] 物化成可认领子任务，两阶段建法处理
  depends_on_hint 的前向引用，幂等，与 acceptance_item 物化互不干扰。
- graph-engine.js：settleNode 的 SUBTASKS_INCOMPLETE 硬闸门收窄成只查
  subtask_kind='acceptance_item'——这是必须同步改的一步，不收窄的话新物化
  的 claimable_work 行会让所有开了 subtask-planning 的 task 验收判定失控
  （已用回归测试固定住这个场景）。maybeMaterializeItemizedSubtasks 的
  createTask 调用同步打上 subtask_kind='acceptance_item'。
- subtask-planning.js：triggerSubtaskPlanning 写完 artifact 后立刻物化
  claimable_work 子任务，不等 org-planner 跑完。
- company.js：taskView 补 subtaskKind/claimedAt；GET /tasks 加 subtaskKind
  过滤（?subtaskKind=claimable_work&status=claimable 就是可认领池查询）；
  新增 POST .../claim、POST .../unclaim 两个端点，角色白名单先写死
  ['org-coder']（不做能力匹配，系统里没有结构化角色能力字段）。认领成功
  同时把 executor 改成 'agent'，复用既有的 executor='agent' 派单闭环
  （/task/report 上报生命周期），不需要碰 graph-engine 的调度模型。

新增 task-pool-claim.test.js（23 条：DB 层校验/CAS/物化 + 路由层白名单/
并发/放弃）；task-decomposition-validator-gate.test.js 补一条回归测试
（claimable_work 子任务不影响 acceptance_item 的验收判定）+ 更新既有用例
显式打 subtaskKind；task-decomposition-materialize.test.js 补
subtask_kind 落库断言。全量单测 1202 条，1200 passed（唯二失败与本次改动
无关、改动前即存在）。

本轮明确不做：依赖顺序强制、能力匹配、graph-engine 调度模型改动、
Phase 4 的独立开发验证循环、Phase 5 看板 UI。

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

reopenRunForRetry 与 _reapStaleRunningNodes（开机孤儿清扫 + 45号文档持续性存活
扫描共用）把 run 从 blocked/ready 拉回 running 走的是裸 admitOrRequeue，不是
startRun，只改了状态从没重新挂上 runAuto 自驱动循环——手动/自动重试推一步后没人
接着推，agentRunId 仍是 null，backward 重试每次都在这里再卡一次。两处都补上
startRun 收尾那段逻辑：真的推成 running 且 execution_mode==='auto' 才挂 driver。

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

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>

System Agents/Task Logs/Quota/Dream 及公司上下文的 Overview/Team/Workspace/
SOP/任务看板/Files/Messages 共 11 处导航链接原是 <a target="_blank">，改成
router-link 保持在当前页跳转。

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

GraphChatBar.vue 里"context 变了才拼说明、没变不重复"这条逻辑原来直接写在
<script setup> 里，脱不开组件测不了。照抄 agentChatEvents.js 的先例抽成
chatContextInjection.js 的纯函数（buildOutgoingMessage/contextKey），配一份
不用挂载组件就能跑的单测，锁住这条不变式。

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

38 号文档 Phase 2 把 /api/okr 收紧成 admin-only，agent 走 CLI 调用必 401；
公司级正确入口是 POST/GET /api/company/:id/goals（requireAuthOrInternal）。
新增 --company / LEMON_COMPANY 兜底，缺省给出明确提示而非裸 401。

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

graph-console 页面底部新增可展开/收起的聊天条（GraphChatBar.vue，仿 MasterChatDrawer.vue
写的自包含最小聊天组件），直接跟公司 ceo agent 对话，不用跳去 AgentChat 整页。会话持久化在
localStorage（按 companyId 区分），刷新页面自动拉历史消息恢复。

发消息时若当前选中的 task/goal 跟上次发送时不同，会在实际发给后端的文本前拼一行上下文说明，
agent 不用用户手动复述在看哪个任务；聊天气泡里展示的仍是用户输入的原文，不被这行说明污染；
上下文不变时不重复注入。

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

真实事故：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

与 TaskBoard 页头的「执行控制台」链接对称，方便两页互跳。

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

之前排队等待（上条改动）期间前端只有通用的"思考中"，最长可能等到 60s 都看不出
是在排队还是在正常生成，容易让人以为卡死了。

- agent-session-lock.js 新增 isLockBusy(agentId)：判断此刻是不是真被占着（僵尸锁
  不算），供路由层在真正排队前 peek 一眼。
- agent-chat.js 的 /:agentId/chat：锁被占用时提前建立 SSE 连接、先发一个 queued
  事件（activeConvId + waitBudgetMs），前端能精确显示"排队等待中"；没被占用的
  常见路径完全跳过这段，不引入多余的建连时机差异。头一旦按 200 SSE 发出去就不能
  再改状态码，排队超时也改用 queue_timeout 事件收尾，不再是独立的 429 JSON 响应
  （没被占用、一开始就抢到锁的路径不受影响，仍是普通 SSE）。
- agentChatEvents.js 的 handleEvent 认识这两个新事件类型：queued 把 thinkingText
  换成带等待预算的提示；queue_timeout 跟 error 分支一样落一条可见的助手消息，
  不会像原来的静默 429 那样挂在界面上没反应。
- 相应更新 agent-chat-interrupt.test.js（断言 SSE 里真的有 queued/queue_timeout
  事件，超时分支状态码从 429 改为 200）+ agentChatEvents.test.js 新增两条用例。

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

- agent-session-lock.js 新增 acquireLockWithWait：锁被占用时按 pollMs 轮询排队等待
  AGENT_CHAT_QUEUE_WAIT_MS 预算（默认 60s），check-and-set 之间无 await，天然原子；
  等到锁释放就正常执行，等满预算仍抢不到才 429，不再"撞上就立刻拒绝"。
  内部自唤醒（TaskCallback/TaskDispatch 等 selfChat 调用）是 fire-and-forget，之前
  429 等于这次唤醒直接消失，只能靠别处巡检兜底；排队等待让大多数几秒到几十秒的
  短暂碰撞能自然衔接上。
- AgentChat.vue 的 handleSend() 之前拿到 fetch 响应后不检查 r.ok 就直接当 SSE 流读，
  非 200 响应体是普通 JSON，逐行解析全部匹配不上 event/data 前缀，被静默当空流吞掉——
  用户发的消息挂在界面上，没有任何回复也没有报错。现在先判 r.ok，非 200 时读 JSON
  错误体，429 显示"Agent 正忙，请稍后重试"，其他状态显示带状态码的错误提示。
- agent-chat-interrupt.test.js 相应更新：原来断言"并发第二个请求立刻 429"的用例
  改为断言"预算内排队等待、等到就正常执行、两次调用不重叠"，另加一条"预算耗尽仍
  抢不到锁时返回 429"的回归。

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

GoalTaskPane.vue（GraphConsole 左栏）按 parentTaskId 分层渲染，子任务
只读展示（没有独立 run，不接操作菜单）；TaskTable.vue（TaskBoard，当天
另一个并发 session 重写的表格视图）用一行「↳ 子任务·属于「…」」指回
父任务，不强行画树——它是可排序表格，硬套树形会跟排序打架。

taskView() 已在上一个提交里补上 parentTaskId/acceptanceMode 字段输出。

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

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