宜博 / lemonboss

独立试验节点，不接入任何真实公司/图。真实 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>

run_b962ea87f58f 卡在 wallclock_ms 耗尽的锚点未结清问题上，需要人工追加预算
才能继续。extendBudget 只增不减、只加到已配额的维度上，追加时顺带结清卡死的
墙钟锚点（否则 startRunSync 一启动就把挂起时长记进新预算里）。

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

30 号文档记录的真实事故：org-coder-test 被上游 missing_required_input 打回后，
产出的是「建议重跑 org-coder-validator」的诊断文件而不是正常测试结果，引擎把诊断文件里
的 infra_flake 标记当成了这个节点自己的执行结果——infra_flake 原地重跑故意不烧
attempt/backward_count（"这不是节点的错，不该烧它的重试额度"），代价是它是唯一没有
熔断线的失败路径，真撞上了一次每轮产出雷同、永不停止的死循环，眼看着把任务预算耗光。

新增 graph_run_nodes.infra_flake_count 列，只在 infra_flake 原地重跑时累加，真正发起
新一轮真实派发（bumpNodeAttempt）时清零；连续判 infra_flake 超过硬顶（3，与
LOOP_HARD_CAP_EDGE 同量级）就不再原地重跑，改判 blocked 交给人工——不猜该走哪条
fail 边（infra_flake 这个取值域通常没人给它连边）。新增回归测试锁死"永不恢复的
infra_flake 在硬顶后停止重跑"这条行为，graph-engine 相关 10 个测试文件 94/94 通过。

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

招聘自动训练与「重新训练」按钮都是给 org-innovator 发消息、由它去执行训练，
所以对话记录一直落在 org-innovator 的会话库里，而不是被训练的那个 agent 自己——
conversationId 里带目标 agent 的名字只是命名巧合，容易让人在错的 agent 页面下找不到记录
（今天实测：手工模板训练页删除前产生的一条记录就复现过这个问题）。

- company.js /hire：训练 conversationId 提前算好并通过 res.json 带回给前端
  （不再等 setTimeout 回调里才生成，那时响应早发完了）
- CompanyDashboard.vue 重新训练按钮：发完请求立即 window.open 到正确的
  /agent/org-innovator/{convId}
- CompanyDashboard.vue 招聘弹窗：雇佣触发自动训练时，弹窗给出可复制的正确链接
  （不自动开新标签页——这条训练要等 agent-creator 先写完定义，立刻打开大概率是空的）

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>

24h 的"取消超时"曾是刻意为之，但代价是子进程已产出终态判词、仅 session/result
消息迟迟不来时，sendPrompt() 的 promise 没有任何兜底会挂到 24h 耗尽
（T-mt5esage：T-mt5d3mi9-57cf 卡 50+ 分钟才被 COO 心跳巡检发现，且已连续 3 次）。

收紧到与 process-guard.js FRESH_DEFAULTS.maxMs(10min) 同一量级：对话态 8min
（无工具执行理应持续有 token 流），工具执行态 15min（跑测试/构建允许更长静默）。
补测试复现"tool_use 开始后无输出"场景，验证 15min 兜底生效而非 24h。

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

POST /:cid/tasks -> enqueueTaskRun 入队时从未写过 assignee_agent_id，
COO 心跳巡检靠 tasks.assignee_agent_id(the "to" field) 判断任务有没有
人接手，读到永远的 NULL 就把正常跑图的任务误报成孤儿任务
(本周已发生两次：T-mt25asz4、T-mt5d3mi9-57cf)。

- enqueueTaskRun 入队时补写占位哨兵 'org-graph'（GRAPH_TAKEOVER_ASSIGNEE）
- settleTaskFromRun 收敛时用 COALESCE 兜底，只在仍为空时补，不覆盖
  派单式任务（agent-chat dispatch 流程）已经写好的真实 assignee
- TASK_PATCH_COLUMNS 补上 assigneeAgentId，否则 updateTask 写不进这列

T-mt5dkvjm

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

侧栏 170px 太窄看不全 agent 名字，改成 260px 并把名字从省略号截断
改成允许换行；顶部加搜索框按 name/id 过滤列表，点击过滤结果复用
已有的 switchAgent() 跳转逻辑，不用额外写定位/滚动代码。

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>

system/templates/ 已在 28 号文档的合并里并入 system/agents/，「模板」作为独立
数据概念已经消失；确认后手工 CRUD 页面（创建/改名/删除骨架、触发生成与训练、
传 skill 文件、provision）也已经没人用，一并下线：

- 前端：删 AppNav「Templates」菜单项、/templates 路由、TemplateAgents.vue
- 后端：company.js 删掉只服务于该页面的写接口（PATCH/DELETE/POST /templates、
  generate/train/skills-upload/provision/files 系列），保留 GET /templates
  （CompanyDashboard 招聘弹窗和 CLI `company templates` 命令仍依赖它列出可招角色）
- CLI：bin/lemon.js 删 `template create`/`template train`（调用的是被删接口）
- 修正两处过时注释（company-service.js / graph-service.js）：不再声称
  buildAgentDefinitionBrief 有两个调用方，/hire 是唯一派单点
- work-layer-body-paths.test.js 同步更新断言（2 处调用方 → 1 处）

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

_scanConversationsDir 塞进 list 的字段是 conversationId，getTaskTimeline
过滤时却读 c.convId（始终 undefined），传进 _extractTaskId 后
convId.includes(...) 直接抛 TypeError，导致 /api/tasks/:id/timeline
每次调用都 500，前端任务详情页因此看不到任何日志。

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

此前只有人类对话路径 agent-chat.js 会写 memory.md，图执行的验收反馈从不进
memory.md，Dream 天天扫全是空转。runClaimedNode 结算后新增 recordNodeOutcomeMemory
桥接点，只在真派发（isRealDispatch）且 systemAgentId 对应本体已雇佣（bodyDir 存在）
时才记一行 success/fail 摘要，避免测试夹具/假 executor 用例把假地址写进真实
system/agents/ 目录。memory-service.appendToMemoryMd 补 mkdirSync，因为这条新调用方
不像既有的 saveSessionSummary 那样先建过 memory/ 目录。

从原本混在墙钟看门狗改动里的工作区 diff 中拆出，两个特性互不相关。

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

manual 模式没人点「下一步」、auto 驱动循环随进程重启丢失时，run_status='running'
的 run 再也不会触发 checkBudget，wallclock_ms 超时无人发现（实例：T-msx6toej 卡
135 小时才被人工揪出）。新增 sweepWallclockBudgets + 60s 兜底定时器
startWallclockWatchdog，复用既有 checkBudget/suspendRunTree 路径，接入点在
index.js DISABLE_BACKGROUND_AGENTS 早退之前。

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>

补记 commit fadb6fa 的实现记录：证据闸门选了"拦截"不是"降级"（降级等于还是采信
了分数，只是换个说法）；goal-benchmark.json schema 完全不用改，evidence 早就是
benchmark-validator/agent.md 教的既有字段，只是从没被 goal-contract.js run 读过，
让 runBenchmark 多看一眼姊妹判词文件即可，没有发明新格式；C 的实现只更新了真正
写分数/证据的 benchmark-validator，不是最初以为的 coder/unit-tester。

§三推进顺序标注全部完成，并记录了样本量不足的遗留风险（只有一次真实回归验证过
证据闸门，关键词表覆盖度与拦截后的连带影响都还没有大量数据支撑）。

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>

补记 commit bab675c 的实现记录：按"第一版先做前者"落地（blocked 等人工，
装配自愈留后续），以及中途把测试套件炸穿 75 个用例又收窄回来的完整过程——
根因是 missingBodyDefinition 查真实文件系统，测试夹具的假 systemAgentId
天然"缺失"，改法是借用已有的 boundaryGuardApplicable 判据（只在真实执行器
下生效），不是发明新判据。

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

runClaimedNode 派发真实调用之前，先查一次 agentLocator.missingBodyDefinition
(systemAgentId)——此前这个判据只在招聘/建公司路径上被查过，图执行的核心路径
从没查过：本体因任何原因（装配没跑完、手工改坏、迁移遗留）仍是空骨架时，引擎
会原样把它当正常本体派发一次真实调用，静默产出一份没有角色指导支撑的结果
（真实样本见 34 号文档 §五：unit-tester 顶着 _base 骨架跑完了一整条真实任务）。

本体不完整时：新 fail_reason='body_not_ready'（与招聘路径的同名状态同义），
不扣预算（没有调用发生，"一次调用一定发生了"这条记账理由不成立）、不起边界
守卫、走正常的选边/兜底/熔断路径（不发明第二套重试语义）。

只在 agentExecutor === defaultAgentExecutor 时生效（与 boundaryGuardApplicable
同一判据）——第一版忘了这条，把全仓库几百个用假 systemAgentId + 注入假 executor
的用例全部判成 body_not_ready，跑单测直接炸穿 75 个用例；加上这条判据后收窄回来，
只在真会起 CLI 的路径上生效。

只查 agent_call 节点：subgraph 节点的 systemAgentId 不是即将被直接调用的本体，
它派发的是 workgraph-planning 去规划子图。

新增 graph-engine-body-not-ready.test.js（4 例）+ 更新
graph-engine-fail-reason.test.js 的取值域断言（五个→六个）。全量单测
1004/1004 通过。

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

用户问"任务结果差是 agent 能力、架构、还是 graph workflow 问题"，这份文档是
书面复盘：按发生顺序分四类——图/模板设计缺陷（31/33 号，已修）、招聘装配可靠性
bug（32 号已知问题的新样本）、一个复盘时新发现的架构缺口（missingBodyDefinition
完整性闸门只在招聘路径上调用，graph-engine.js 的执行核心路径 advanceOne 一次
都没查，本体不完整时没有第二道防线，静默拿空提示词跑真实 LLM）、agent 能力
（不是问题，两次订正过"没工具做不到"的误判，且有正面即兴发挥的例子）。

结论：主要是架构问题 + 一个具体可靠性 bug，不是模型能力问题。

提出两档改进方案供讨论：
  低成本（建议直接做）——把完整性闸门接进图执行前置检查（提案 A）、
    控制台展示验收证据可见性（提案 B，纯 UI 不改行为）
  大改动（建议先讨论优先级）——标准化视觉验收工具（提案 C）、
    引擎级证据闸门（提案 D）

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

§5.1 原来断言"没有浏览器工具，物理上做不到"，复盘时对照 p-bkhylu 的 org-coder
（同样只有 bash/read_file/str_replace(+write_file)，没有专门的浏览器工具）却
真跑出了 Playwright + headless Chromium 测试，才发现这个判断错了：仓库自带
playwright 依赖，bash 里 `node verify.mjs` 沿目录树能 require 到仓库根的
node_modules，这条路今天的 coder/unit-tester 同样走得通。

真正的差异不是工具权限，是 unit-tester 的 agent.md 从未填充过（32 号文档那类
问题）、没有任何角色指导，而 org-coder/coder-validator 都是正常填充过的成熟
本体。根因从"平台缺工具"改判为"这次没有指导 agent 主动想到"，是一个不一样、
也更能采取行动的结论。

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

对比 e2e-demo 现有的三个项目根：
  p-v82tpc（今天的回归任务）—— 静态正则解析文本，零浏览器
  p-bkhylu（"做一个 lemonai 官网"）—— 真实 Playwright + headless Chromium：
    六档视口量 scrollWidth/clientWidth、getComputedStyle 量字号、手算 WCAG 对比度、
    禁 JS/reduce-motion 验证、整体挪到 /tmp 用 file:// 重开验证可移植性
  p-v1mpcl（31 号文档那条原始卡住任务）—— 无验证，任务在验收前就被取消

p-bkhylu 的 DELIVERY.md 里那句"未采信自证脚本，符合 SDD §0/§2 I-4 验收独立性
要求"，搜遍 system/、docs/ 都找不到这条规则——它是那次任务的 sdd-planning 会话
自己写进那次 SDD 的，不是仓库级别的通用约束。也就是说三条任务里，要不要认真
验证、认不认自证脚本，完全取决于哪次任务规划时 agent 会话恰好这么想，没有系统
保证。这就是 34 号文档 §三"影响面"判断的实锤：任务显示"已完成"与"真的达成
原始需求"之间的落差，目前只能靠运气。

34 号文档 §四 checklist 全部查完，状态行同步更新。

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

之前把这条 run 手动 patch required=0 + 重试推到 completed 那次操作，其实就是
"用真实回归任务验证 org-coder-validator 不再假阳性 blocked" 这条的证据，回来补记
（唯一没走到的是"由 workgraph-planning 全新规划一张图"这一环，端到端证据仍缺）。

复查了 validator.json 的 needs:[{kind:'artifact',required:false}]：不是同类潜伏
问题，是刻意设计——它验的 artifact 由另一张图产出，靠任务级共享索引找，
不依赖这条边的声明，required:false 与 33 号的 log 声明成因完全不同。

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

34 号文档追加调查（§五）：
- coder-validator（预置 active 本体）的 agent.md 通篇是代码/契约正确性验证协议
  （npx vitest run + 抓假绿五件套），压根不涉及视觉/交互检查；这次任务新招的
  coder/unit-tester 两个本体 toolPolicy 都只有 bash/read_file/str_replace，
  没有浏览器/截图工具——goal-benchmark.json 的 evidence_hint 要求"打开浏览器"，
  在给定工具权限下物理上做不到，不是 agent 偷懒。
- 但也不是纯粹空手套白狼：data/companies/e2e-demo/projects/p-v82tpc/tests/
  unit-tester.check.js 是一份真实可运行的零依赖静态断言脚本，对维度 1-3 的检查
  （字号比例真解析 CSS clamp() 算出数字、三个卖点区块标题顺序、锚点跳转/平滑滚动）
  与浏览器版本基本等价甚至更精确；维度 4/5（响应式断点、资源完整性）的静态版本
  明显更弱，会放过断点内样式写错、本地资源路径错误这类情况。

顺带发现：这份脚本很可能是 unit-tester 在提示词完全没有测试方法论指导的情况下
自己想出来的——它的 agent.md 还是没填充过的 _base 原始骨架（隔壁 coder 正常填充
过），是 32 号文档"招聘装配没填充完"那类问题的又一个真实样本（发生在方案 B
修复提交 6a18379 落地前 1 小时，是旧行为的证据，不是新机制的回归；新机制下
会不会正常完成，仍未验证）。32 号文档 §四追加第 6 条记录这次样本。

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

用户反馈：控制台原来只能逐个节点点「输入输出」tab 看产物，缺一个全局入口。
新增 TaskFilesPanel.vue，挂在页头，跨节点/跨 run 一次性列出这个任务的全部产物。

做的时候发现分两类、且第二类之前完全没覆盖：
  · 节点产出索引（graph_files，按 company+task 检索）——规划笔记/日志/契约快照
  · 项目根（W2 ensureProjectRoot，data/companies/{cid}/projects/{pid}/）——
    真实交付物代码写的地方，跨节点共享，indexNodeOutputs 从不扫它

后端补 readProjectRootRecord 导出 + GET /api/graph-runs/:id 挂 projectRoot 字段；
项目根的文件列表复用已有的 GET /:companyId/files（此前零调用方），不新开列目录端点。
新增 graph-run-route-io.test.js 两例（分配前 null、分配后原样透传 + 幂等）。

顺带订正 34 号文档：当时断言"index.html 从未被写出来"是错的——真实网站文件
其实在项目根里，只是没查那个目录。34 号文档 §零 记录了订正过程，问题收窄成
"validator 有没有真的做过浏览器级检查"（仍未解决，留待下次）。

全量单测 1000/1000 通过。

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

真实回归任务 T-mt2r6fz0-125b 走到 completed 后回查产出，发现 org-coder-impl
从未写出任何 HTML/CSS/JS 文件（只有 _plan.md/_research.md/coder.log），但
org-coder-validator 给六个维度全打了 100 分。goal-benchmark.json 的
evidence_hint 里五个维度明确要求"打开 index.html/浏览器开发者工具检查"，
这份评分显然没有真的执行过这些检查——是一次没有证据支撑的评分，不是
"查过但判错"。

不是 31/33 号修复引入的新问题，是那两次修复让这条本会一直卡死的任务真的跑到
completed 之后，才把这个一直存在的验收缺口暴露出来。只记现象与证据，根因
（提示词缺前置检查？validator 没有可用的浏览器/文件工具？是不是这次新招聘
本体特有的一次性现象）留给下次调查，这次不深挖。

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

settleTaskFromRun 只写 status/finished_at，不清 blocked_reason —— 任务卡住时
noteTaskBlockedReason 写过的那句「节点 xxx 卡住（...）」会一直挂在 tasks 行上，
哪怕后来 run 真的恢复跑完转 completed。界面上因此出现「已完成」绿色状态旁边
还留着一句刺眼的红字，容易被读成还在报错。

真实复现：T-mt2r6fz0-125b 手动推过熔断点后 org run 收敛到 completed，
任务列表却仍显示 org-coder 卡住的旧归因文本。手动清了这条任务的残留数据，
代码层面在 settleTaskFromRun 的 UPDATE 里一并置 NULL——task 进终态时
「为什么卡着」这句话本来就该失效，不管进的是 completed/failed/cancelled 哪一种。

扩展了 goal-task-acceptance.test.js 里"预算耗尽→恢复→跑完"那条既有用例，
断言 blocked_reason 在完成后确实被清空。全量单测 998/998 通过。

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>

用真实 LLM 起了一条新任务（G-mt2r62ia-73af/T-mt2r6fz0-125b）回归验证 83afecb 的修
复：org-planner-sdd 自判失败后沿新补的兜底边自动回退 3 次、零人工介入，最终收敛到
completed，补上 31 号文档 §六此前用确定性测试代替的那步真实验收证据。

顺带在 org-coder 子图撞见一个独立的新 bug：inboundContracts()/requiredInputsMissing()
不按 role 过滤 graph_edge_contracts，把同一条边上声明的 produces（源节点自己产出什么）
也当成目标节点的必需输入，导致 org-coder-validator 被 missing_required_input 反复假阳
性 blocked（agent 自己判定 passed，引擎却强改成 fail）。已定位根因、写清复现证据与建议
修法，记在 33-needs-gate-role-filter-bug.md，留给下次实施。

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

状态行从"评估完成，未实施"改成"方案 B 已实施"。§四风险/未决问题里原来的
4 条逐条补上实施时的实际决策：
- SessionPool 并发复用的真实后果仍未实测，但改用了不需要知道答案的设计
  （拿锁成功才调用，从设计上不会触发这个场景）
- 互斥锁选型定为抽共享模块（agent-session-lock.js），不新起一把
- 失败标记定为本体目录下的哨兵文件，不碰 system_agents.status
- 第 4 条（三处同构缺口）原样保留未决

新增第 5 条：实施时发现的连带效果——hire 路由第 1 步改 await 之后，第 3 步的
setTimeout(5000) 变成多余延迟，刻意没有顺手删掉，记录下来给以后处理。

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

company.js 的 hire 路由原来用一发 fetch(...).catch(...) 回环自己去触发 agent-creator
填新角色的定义文件——fire-and-forget，.catch 只接网络层错误，agent-creator 撞车时
（另一次调用正占着它）/api/agent/:agentId/chat 返回 429，被原样当成"成功"吞掉。
新角色因此永久停在 base 空壳 + status=training，唯一痕迹是一行 console.error（且这行
在 429 场景下根本不会触发）。

新增两个模块：
- agent-session-lock.js：从 agent-chat.js 抽出的共享互斥锁存储（纯数据结构，Map +
  超时常量），agent-chat.js 的路由与 hire 路由现在用同一把锁。不能各起一把——
  SessionPool.getOrCreate() 不检查上一次调用有没有跑完，两条路径分开维护锁的话，
  各自都以为自己没有并发，会把第二轮 prompt 发进一个还在处理中的 CLI 会话
  （未定义行为，比现在的"被拒绝丢弃"更危险，见 32 号文档 §二方案 B）。
- agent-body-filler.js：同进程直接调 AgentManager.callAgent，替掉 HTTP 回环。
  拿到锁才发起调用，锁被占用时等一等重试（最多 3 次，5s/15s 退避），重试耗尽在
  本体目录写一个哨兵文件 .body_fill_failed.json（不动 system_agents.status /
  config.json.status——那两个字段还有 draft→active 毕业逻辑在读，改取值域风险
  大于收益）。

company.js 的 hire 路由第 1 步从 fire-and-forget 换成 await，顺带让第 2/3 步
（技能注入、5 秒后触发 Innovator 训练）拿到"agent-creator 真的写完了"这个保证——
第 3 步原来的 setTimeout(5000) 靠的是"假设 5 秒内写完"，现在这个假设不再需要，
但没有顺手删掉那个 setTimeout（不在这次修复范围内，留着无害）。hire 接口本身
仍是异步的，调用方还是立即拿到 training 状态，没有改成同步等待完成。

agent-chat.js 的锁声明改成从共享模块 require，行为逐字不变——用现有 5 个
agent-chat 相关测试文件（36 条）验证过零回归。

新增 agent-body-filler.test.js（6 条）：首次成功、重试后成功、锁被占用时等待
重试、重试耗尽写失败标记、成功后清掉上一轮的失败标记、只释放自己抢到的锁
（不误删第三方在途期间抢到的新锁）。用 vi.useFakeTimers() 控制重试等待，
不用真等 5s/15s。

全量 npx vitest run：151 文件 / 1384 用例，零回归。

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

config.json 的 name 字段是工位显示名（如 org-coder 显示成"实现节点"、
coder 显示成"实现"），Overview 页 Agent 表格和 System Agents 侧边栏此前
只渲染 name、不带 id，导致界面上看不出某个显示名对应哪个 work graph
节点绑定的 system_agent_id。后端接口本就返回 id 字段，这里只是补上前端展示。

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

用户追问「这个方案能解决什么问题」，发现文档原来把这个信息拆在§三要点和§四
风险里，没有对照着讲清楚。补一张表：撞车丢请求/卡死不可见两条真解决了，
agent-creator 真的坏了/主动通知人/另外两处同构缺口/hire 接口异步体验这几条
明确没解决——避免看完方案高估它的覆盖范围。

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

承接 30-task-delegation-reliability-gaps §2.1（现状调研，未拍板）。评估了两条候选：

方案 A（改走 POST /api/agent/task/dispatch）不成立：深挖发现它最终也是走
selfChat() 回环 HTTP 自己，撞上 agent-creator 单会话锁时同样吃 429、同样不
检查响应状态码——跟现在的 fire-and-forget fetch 是同一条失败路径，没有多任何
重试保护，唯一价值是任务表里多一条可查询的行（可观测性不是可靠性），且语义
错位（内部装配动作会被包装成用户可见的派单任务）。

方案 B（company.js 直接同进程调 AgentManager.callAgent）方向对，但评估中发现
一个原始方向没提到的真实风险：SessionPool.getOrCreate() 只判断连接在不在，
不判断上一次调用有没有跑完——绕开 HTTP 直接并发调用会被复用到同一个还在处理
中的会话上，两条 prompt 塞进一条 stdio 管道，行为未定义，比现在"第二个请求被
429 丢弃"更危险。因此推荐方案明确写成「同进程调用 + 自己的互斥锁 + 有限重试 +
失败落地为可查询状态」，不是简单的「同进程调用 + 重试」。

文档状态：评估完成，未实施。互斥锁选型、失败标记落点等留给实施阶段决定。

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

## 问题 1：work 节点只有 agent.md 进提示词

graph-engine 驱动 work 节点走 PromptBuilder.build()，只读 protocol + agent.md +
companyContextPath + user.md/memory.md/近期记忆。交互式的 agent-chat.js
（buildSystemPrompt）另有一条独立实现，会读 soul.md/identity.md/tools.md/
heartbeat.md/OKR 目标/hippocampus 检索/main_skill/SKILL.md/其它 skills——两条链路
从未同步过。静默到什么程度：agent 照样跑、照样成功，只是少了人格/工具约束/长期
记忆检索，没有任何报错能看出原因。

新增 identity-context.js，抽出 agent-chat 那份逻辑里「读哪些文件」的等价实现（不
读 agent.md/user.md/memory.md/近期记忆——那五样已经被 PromptBuilder 覆盖，避免
重复），接进 PromptBuilder.build() 的非 SKILL.md 分支（scoped skill 那类不是完整
身份，不适用）。用户明确选择「全量对齐」：soul/identity/tools/heartbeat/OKR/
hippocampus/skills 一次性全补，不做裁剪版。

ponytail：没有反过来改 agent-chat.js 去调用这份共享实现——两处现在是「同构但
独立」的两份代码。agent-chat.js 是长期稳定的高频路径，为这次修复去动它风险和
收益不成比例，见 identity-context.js 头注的升级路径。

## 问题 2：org node 角色定义截断到 2000 字，切没切完全不可见

describeRoleDefinition 给 workgraph-planning 的角色定义摘录一直硬切前 2000 字
（有意为之，规划要的是「职能」不是全文）。但切没切、切掉了多少，规划 agent
一无所知——agent.md 写得长一点、职能说明排在后半段，这句关键描述可能根本没
进提示词，且没有任何信号。截断上限不变，改成截断时附一句 ⚠️ 提示 + 完整路径，
给它一条自己去读全文的退路。

## 测试

identity-context.test.js（10 条）：文件读取的每个条件分支、OKR/hippocampus
只在有 agentId 时才查、OKR 抛错不拖累其它内容、skills 目录扫描排除 main_skill。
两个依赖（OkrService/retrieveRelevantPlans）用直接换 CJS module.exports 属性
的手法隔离——本仓库服务层是纯 CommonJS，vi.mock 对嵌套 require() 链路不生效
（实测踩过），且这两个依赖没有 env 覆盖点，真实路径不能进单测。

describe-role-definition-truncation.test.js（3 条）：截断/不截断/本体不存在
三种情况，用真实 system/agents/ 下的 zz- 前缀临时本体（locator.bodyDir 没有
env 覆盖点，只能顺着真实路径走），afterEach 清理不留痕迹。

全量 npx vitest run：150 文件 / 1378 用例，零回归。

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

## 起因

e2e-demo 真实任务卡住：org-planner-sdd 自己判 input_underspecified
并点名 org-planner-prd，但这张图里 sdd 没有任何 fail 出边——精确匹配、
兜底边两条路都接不住，节点直接 blocked，靠人工点了「重试」才续上。

## 根因

fail-fallback-edge 校验（27-P3/P4 §三.7 第五项）只在节点已经画了别的
fail 边时才检查兜底边齐不齐。一条 fail 边都没有的节点完全不受约束——
workgraph-planning/agent.md 原文明说这是「合法设计」。但系统里所有本体
共用 _base 的四段式协议，VERIFY 阶段任何 agent_call 节点都可能自判
失败，不止专职判词节点。四个骨架模板审计后发现 6 个中间节点存在同一个
漏洞（sdd 只是撞上的那一个）。

## 决策

除图的唯一入口节点外，每个节点必须留一条兜底边（判据是 forward 入度，
不是节点名字模式）。org 层暂不动——node 全是 subgraph 类型，失败来源
机制不同，且套用同一条规则会让三个 org 模板立刻不合法，属于 27-p3b
「验收9」还没收口的链路，留给那边一起做。

中途发现无条件收紧会炸 46 个用例/13 个文件（createWorkGraph 被大量
测试当成建最小图的通用工具）。改法是加 strict 开关，默认关闭（行为
不变），只在 workgraph-planning 真实提交图落库的那个唯一入口
（createWorkGraphSafely）打开。

## 改动

- work-graph-db.js / graph-engine.js：新规则 + strict 开关
- planner.json / executor-fanout.json：补 6 条兜底边
- workgraph-planning/agent.md：约束三等四处措辞同步
- 新增单测：strict 模式 7 例 + 真实链路回归用例（真实引擎代码+真实
  DB+只换最外层 CLI 子进程，复现 sdd 自判失败后引擎自动路由到 prd，
  全程零 retryNode 调用）——比重跑一次真实任务更严格，可回归、进 CI

978/978 单测通过。需求与决策记录见
docs/todo/system-design/31-work-graph-fail-fallback-coverage.md。

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

任务表 T10 标完成；三个阶段表（A/B/C）现在全绿；顶部版本行、开篇摘要、
T11（没有单独立项，测试随各任务同批写掉）一并更新，别再让文档滞后于代码。

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