宜博 / lemonboss

_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>

新增 join-status.js（+ .check.js 可运行检查，web/ 不在 vitest include 里，
同款手法照抄 io-model.check.js）：resolveJoinWait/joinWaitLabel，判据与引擎
activateSuccessTargets/allIncomingSatisfied 同源——只看 forward 的 success
入边，backward/fail 边不算「等待对象」。只有 2+ 条入边的真 fan-in 才出徽标，
单一入边的普通顺序等待不加噪声。

WorkGraphCanvas.vue：pending 节点在等哪几个上游时画一枚「⏳done/total」徽标，
悬停看完整明细（谁 success / 谁还在 running / 谁 fail 了）。

nextNodeId（单数）→ nextNodeIds（数组）：advanceBatch（27-P4 T4）一次最多
认领 max_concurrency 个 ready 节点，并行分支下真实会被同批拾取的可能是好几个，
标一个会误导。这个 prop 之前在全仓库没有任何调用方真正传值（NEXT 徽标从未
渲染过），顺手把它接上：GraphRunPane 按 run.max_concurrency 截取候选，
手动模式仍显示单数提示，自动模式显示批量提示。

并行运行中的多节点高亮不需要新代码——.dot.running/.node.running 已经是
按每个节点各自状态渲染，多个节点同时 running 时天然一起亮，这条在 T4/T6
落地时就已经生效。

验证：join-status.check.js 6 条断言全过；`npm run web:build` 编译通过、
零告警。没有做的：没有起真实浏览器点一遍——搭一张真的并行 fan-in 图需要
起完整服务 + 建公司 + 跑真图，这次没做，逻辑侧的验证到 check.js + 编译为止。

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

T5 任务表行标完成，补一段实现记录（桩子设计、block_reason 列、
resumeBillingClearedRuns、advanceBatch 的第二个排序 bug）。

顺带记一笔过程：写 T5 期间发现 work-graph-db.js 被另一个会话同时编辑
（重写 validateFailFallback），用 git diff 生成的 patch 只保留自己的 hunk
（git apply --recount --cached）避免带上对方未完成的改动，再用一次性
worktree 单独验证后才提交。留着这条经验：共享工作目录下 commit 前先
git diff 走查一遍要提交的文件，别假设自己改的文件里只有自己的改动。

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

新增 graph-engine-billing-gate.test.js（7 条）：
- 未注入 billingGateFn 时零影响
- advanceOne / advanceBatch 欠费时都正确挂起（reason=billing-arrears，
  block_reason 落库，节点停在 ready 没被 claim）
- startRunSync「启动」清空 block_reason
- resumeBillingClearedRuns 正确恢复已清零的 run、放过仍欠费的 run，
  且支持按 companyId 限定扫描范围
- advanceBatch 排序回归用例：已收敛（零 ready 节点）只是恰好预算/欠费也耗尽的
  run，正确收敛到 completed，不会被误判成挂起

隔离验证：临时 worktree 里单独跑（graph-engine.js/work-graph-db.js 当前正被
另一个会话同时编辑 fail-fallback-edge 规则，工作区里混着两份改动，跑全量套件
会被那边未完成的改动带崩；这条测试只依赖已提交的 T3-T5 代码，临时 worktree
里跑通即可确认与那份改动无关）。

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

先搭桩子，不接真实计费接口（用户明确选择：真实欠费判据依赖计费系统那边确认，
现在只把可插拔的挂载点和恢复机制先落地，接口确认后再换真实实现）。

新增：
- setBillingGate(fn)：与 setAgentExecutor/setPlanWorkGraph 同款注入模式，未注入
  时 checkBilling 恒返回「未欠费」，对现有行为零影响。
- checkBilling 挂进 advanceOne 与 advanceBatch，紧跟 checkBudget 之后——两者是
  不同维度的门（任务级预算池 vs 账户级欠费），不合并成一个判据。
- 欠费挂起复用现成的 suspendRunTree（预算耗尽走的同一条路），只是 reason 换成
  'billing-arrears'。suspendRunTree 加 reason/summary 参数，并把 reason 写进新增的
  graph_runs.block_reason 列（欠费清零后的自动恢复扫描要按它过滤，不用解析 timeline
  文本）；startRunSync「启动」时清空这一列。
- resumeBillingClearedRuns()：欠费清零后的自动恢复触发器——今天从 blocked 恢复靠
  人手点「启动」，欠费清零不会有人去点，这个函数补上「扫一遍 block_reason=
  billing-arrears 的 blocked root run，欠费真清了就代它点启动」。调度触发源
  （webhook/轮询）留给计费接口接通之后再定。

顺手修了一个 advanceBatch 的排序 bug：budget/billing 门必须在「确认真有 ready
候选」之后才查，跟 advanceOne 的既有顺序一致——反过来会把一个已经收敛、只是
恰好预算也花完了的 run 误判成「挂起」而不是正确收敛到 completed。

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

自动模式的驱动原语 advanceTree 里 advanceOne 换成 advanceBatch：树上「最深
active run」的选取逻辑不变，但推进这一步现在能一次并发 claim 一批 ready 节点，
而不是每 tick 只推一个。核实过 advanceTree/runAuto 的返回值全仓库只被读 .ok，
不依赖 .node/.results 的具体形状，不需要兼容层。

顺带抓到并修了一个真 bug：advanceBatch 的 no-ready-node / taken-by-other 分支
原来写的是 ok:true，跟 advanceOne 用 result() helper 的惯例（这两种情形一律
ok:false）不一致。不修的话接进 runAuto 后，一个已经收敛的 run 会被自动循环
一路空转到 maxSteps 才停——旧测试从没对已收敛的 run 连续调 advanceBatch，
所以这条一直没被撞出来。

新增两条测试：ok:false 语义与 advanceOne 对齐（直接绕开引擎构造边界状态）；
runAuto/advanceTree 端到端确实吃到并行（用真实 setTimeout 延迟证明并发窗口
重叠，不是同步假象）。全量 vitest 147 文件 / 1350 用例，零回归。

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

planner 骨架（brd→prd→sdd→goal-benchmark→validator）复现：三个 planning 节点
声明了 produces 却没真落盘，executor 没抛异常就被引擎判 success；goal-benchmark
的入边 needs:[brd,prd,sdd] 只用来拼提示词里的 ⚠️ 提示，agent 视而不见照样产出
合法 acceptance。下游 validator 永远读不到三份文档，backward 重试撞循环硬顶后
只能人工兜底。

settleNode 判 success 之前新增两道闸门（均只对 agent_call 节点生效，subgraph/org
节点的契约由子 work run 自己的节点过闸）：
- unsatisfiedRequiredProduces：声明的 required produces 一个候选文件都没落盘 →
  fail_reason=produces_missing，不再放行
- requiredInputsMissing：声明的 required needs 在 graph_files 里查不到实例 →
  fail_reason=missing_required_input，不采信 agent 自报的 success

两者都只判「有没有」，不判「分类对不对」——ambiguous 归类留给下游 ⚠️ 提示词处理，
避免把「写了东西但引擎猜不出对应哪个 kind」误判成没执行。

包含此前已完成但未提交的 27-P4 T3（graph_runs.max_concurrency 落库）及配套
advance-batch 测试。

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

只做了这一件事，没有跟着做「dream 改成 org/work graph 来跑」——两者被
单独评估过：org/work graph 是单公司作用域（org graph=公司级 workflow，
work graph=公司内某任务的节点图），dream 却是跨公司扫描，套进去要么破坏
作用域假设要么得新开图类型；且 graph 引擎自带的验收机制（goal-contract
benchmark/test-script）判的是「产物过没过验收脚本」，对「经验提炼得对
不对」这种自由文本判断没有对应机制——不管套不套 graph 都得单独设计
rubric，是同一件事。用户明确只要 REST/控制台这一半。

## REST（server/routes/dream.js，挂 /api/dream）

路由本身没有新业务逻辑，全部委托给已测过的 dream-service.js：
GET /agents（总览）、GET /agents/:id（详情，含定义文件可写性 + 经验
审计）、POST /agents/:id/run（手动跑一次，dryRun 只看有没有新原料不
起 LLM）、POST /sweep + GET /sweep/status（全量扫描后台跑 + 轮询，内存
态并发锁防止连点两下）。

## 控制台（web/src/views/DreamConsole.vue，路由 /dream）

一个表格 + 两个弹窗：本体列表（详情/跑一次/dry-run）+ 全量扫描按钮
（15 秒轮询状态）。导航栏加 🌙 Dream 入口。

## 验证

server/tests/unit/dream-routes.test.js 4 例，monkeypatch 掉
dream-service 导出对象上的六个函数（不走真文件系统，不误扫真仓库
76 个本体），只验路由层自己的逻辑：端点接线、sweep 并发锁状态机。

真起服务器打了真数据：GET /agents/innovator-evolver 正确报
SKILL.md 因没进 git 历史而不可写、经验审计吐出上次真跑沉淀的 4 条
经验及原文；dry-run 正确报 no-new-material，没多花一次 LLM 调用。
浏览器里走了一遍列表→详情→dry-run，与直接打 API 结果一致。

955 个单测全绿。

文档：29-dream-design.md §5.7 记录实现与「为什么不做 graph 化」的
理由；28-followups.md / docs/README.md 同步更新 dream 现状。

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

按任务表逐条 grep 代码，发现这份文档落后于实现相当多：

· **T1 已完成**（P3C §15.5-2）：SessionPool.maxSessions + scope key，两条守卫盯着。
· **T3 后半已完成**（P3C 批 4）：单 active root run 的唯一索引已 DROP，
  换成四步事务内准入（BEGIN IMMEDIATE → 重读 → 计数 → 条件更新），8 进程实测零超发。
· **阶段 C 整个已完成，但形态换了**：产物索引做成了 graph_files **表**而不是 files.json。
  表比文件多拿到两样：部分唯一索引保证「同一路径只有一个当前版本」，
  superseded_by 让历史版本可共存。守卫 graph-files-index.test.js 七条。
· 产物也早就按 run/node 分目录了（runs/{rootRunId}/nodes/{nodeRunId}/），
  §3.6 里「按 agent 分目录、同一 agent 不同任务混在一起」那条已不成立。

§3.6 那两个 ❌ 改成校准块 —— 保留原文（它记录了当时的判断依据），
但当前状态以校准块为准。

**真正剩下的只有阶段 B**：max_concurrency 列、advanceBatch、三层额度取小、
并行执行与部分失败降级，以及 T10 的控制台可视化。

> 这是「文档落后于代码」的又一例。判断一个阶段还剩多少工作量时，
> **先照着任务表逐条 grep 代码**，别照文档估 —— 照文档估会把已完成的三项当成待办。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

## 决策 D：能自动查的自动查，不能自动查的把回查成本降到几秒

「这条结论对不对」机器判不了，需要理解内容 —— **不假装有自动判据**。
能自动做的只有两件，两件都做了：

① **引用真伪可以自动查**：提炼产物的 sources 必须都出自这一轮真喂进去的原料，
   编一个出处直接拒（前置闸门，连去敏判定都不用调）。
   编了出处的经验是「无法验证」最危险的形态 —— 人抽查时顺着一个不存在的指针放弃，
   然后**默认它是真的**。
② **auditDistilled()**：把每条结论与它引用的原料原文并排列出来，
   指针悬空标 null（原料被清理过 / 出处是编的）。

真跑那 4 条实测：**8 条引用全部取得回原文**，模型没编出处。
⚠️ auditDistilled 的输出**不是质量分**，别当成那个用。

## 任务态清理（28 §5.6）

四道判据全过才删：① 公司在 company_agents 名册里；② 目录名在**任务态白名单**里；
③ mtime 早于 N 天（默认 14）；④ run_* 对应的 run 已到终态。默认 dry-run。

**第 ② 条是踩出来的**：第一版写成黑名单（「不在保护名单里的都算任务态」），
dry-run 直接选中了 trend-scout-global/idearun/venv 和 youtube-crawler/idearun/data
—— 一个 Python 虚拟环境、一个数据目录，都在**真公司**底下，都不是任务态。
**删错不可逆，留着最多占磁盘 —— 判据必须是「认得出才删」，不是「不认识就删」。**

读不到名册时一家公司都不认（fail-closed），守卫里单独钉了这条。
公司态（memory/ conversations/）永远走「不许清」那条分支 —— 那是 dream 的唯一原料，
删掉不可再生（28 §5.6b）。

实跑 30 天窗口：待删 0，跳过 955（556 还新 / 74 不在名册 / 60 公司态 / 11 白名单外）。

全量：145 文件 / 1338 测试全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

## 定时：每日一次，挂在 DISABLE_BACKGROUND_AGENTS 早退之后

dreamSweep 串行扫所有本体，**不并发**：每轮可能起两次 LLM 调用，
几十个本体并发 = 同时拉起几十个 claude 子进程 —— 这个代价本仓库付过
（2h43m 漏出 82 个进程 / 17.5 GB，28-followups §五 第五条）。慢一点没有代价。

空转保护在 dreamOnce 里，所以「76 个本体全扫一遍」的实际成本是 76 次目录读。
定时器 unref —— 少了它，短命进程会被 24 小时的 timer 吊住不退出。
只挂定时**不立刻跑一轮**：启动那刻跑没有额外收益，反而让每次重启都烧一遍。

一个本体抛异常不拖垮整轮，但**必须留下是谁抛的**，否则现场只看到「今天没沉淀」，
查不出是没原料还是一直在抛。

## 定义文件：受管区块 + 三道闸门

形状是一对 `<!-- dream:begin/end -->` 之间的**受管区块**，区块外一个字节不碰。
自由追加会让「哪些是人写的、哪些是 dream 写的」几轮之后再也分不开，
而分不开就没法分别回滚。区块整体重写还顺带**幂等** —— 同一批经验重复跑不会越写越长。

三道闸门，缺一不写：
① definition-write-gate：当前内容必须已在 git 历史里（你定的前置条件）；
② **agent.md 的前 2000 字符必须仍然自足** —— 规划 agent 只看这一段
   （graph-engine.js:915 的「角色定义摘录」），改了等于悄悄换掉它读到的画像；
③ 写完复核毕业闸门，不过就**立刻还原** —— agent.md 写坏会让本体雇不进任何公司。

任何一道不过：不写，并把原因逐个文件返回（`definitions[]`）。**不写不该是静默的。**

## 测试上又纠了自己一次

三条新用例第一版是「在测试里比对形状」而不是真调 —— 和上一轮同一个毛病。
改成对**真被 git 跟踪且干净**的本体（dream-screener）走真路径：
真写、验区块外字节不变 / 幂等 / 毕业闸门仍过，finally 还原并断言还原干净。
agent.md 那条同理真调，验「不写 + 理由点名前 2000 字符 + 一个字节都没动」。

dreamSweep 加 agents 参数，让错误隔离那条能真调而不是真扫 76 个本体。

全量：144 文件 / 1330 测试全绿，仓库干净。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

## 前置：存量记忆的搬家（19 文件 / 269 行）

写入侧上一轮改了，但**存量不会自己搬家**。实查现有 `## 关键事实` 里
**没有一条真事实** —— 全是重复心跳行、工具调用 id、和以 `...` 开头的半句。
而 memory.md 会被注入**每一轮**提示词，这些东西一直在冒充事实。

scripts/migrate-memory-raw-section.js 把它们搬进「原始记录（未提炼）」。
先 dry-run 再 --apply，改前逐个 .bak（这些是 gitignore 的运行态，没有 git 历史兜底）。

判据刻意窄：只搬 `- [YYYY-MM-DD] … → …` 这一种形状（旧自动追加的唯一形状）。
**搬错比留错更坏** —— 留下最多多一条噪声，搬错是把人写的东西降级成日志。

## 真跑：innovator-evolver，40 条原料

    { "distilled": 4, "accepted": 4, "rejected": [] }   耗时 114s

四条产出都做到了抽象：yt-dlp / Invidious → 「本地下载工具 → 备用镜像源」；
scorer.js / SKILL_v1.md / system/templates/... 一个都没出现。

**顺着 sources 抽查过**（可追溯的第一次实际用途）：4 条引用全部对得上原料。
「按关键词覆盖率打分会被刷到虚高分」那条引了 #21/#22/#27/#28，而 #27 原文正是
「从零重写，采用 expected_output 逐 case rubric + dimCeil 上限机制，杜绝 coverage-based」。
**它是跨 4 条记录归纳出来的**，不是逐条改写 —— 正是「一次调用吃掉全部原料」
那个选择要换来的东西。

## 闸门单独验过：零拒绝 ≠ 闸门有效

真跑里 4 条全过，说明去敏闸门**一次都没触发**。所以单独喂了三条给 dream-screener 真跑：
· 含公司名+域名+绝对路径 → false，理由点名「域名 lemonai.ai 和绝对路径 /Users/…」
· 心跳日志原文摘录 → false，理由点名「原文搬运」「工具调用 ID 可关联到具体运行实例」
· 干净的抽象经验 → true

三条判据都按 agent.md 写的那样生效，**且拒绝理由都点到了具体是哪几个字** ——
那是 agent.md 里明确要求的。

## 空转保护实跑

第二次调用（原料没变）：{"skipped":"no-new-material"}，一次 agent 调用都没起。

## 还没做的

定时挂载（决策 C）、写定义文件（SKILL.md / soul.md / agent.md）、
决策 D（质量怎么评 —— §5.5 那次抽查是**人工**顺着 sources 回查的，不是自动的）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

## 两个本体（都过得了毕业闸门）

· dream-distiller —— 把一批原始记录提炼成可复用经验，交 ```json 数组
  {title, body, sources}；没有值得留的就交 []。
· dream-screener —— 逐条判「这条能不能给别家公司看」，交 {shareable, reason}。

**决策 A 的独立性写在两处，缺一不可**：
· 代码层：判定**一条一次调用**，提示词里只放 title + body，**不放原料**；
· 本体层：dream-screener/agent.md 明写「你看不到原料，也看不到是哪家公司
  —— 这是故意的」。守卫里有一条专门断言这句话在 —— 否则下一个人会顺手把原料
  塞进提示词「让它判得更准」，而那恰好把独立性拆掉了。

soul.md 也承担判据的一半：screener 的人格写的是「你是一道闸门，不是审稿人。
审稿人的本能是帮它改好，闸门的本能是不确定就不放」。

## 两处失效方向都是硬的

· 提炼取不出 JSON → **抛**，不是静默返回空。「产出格式坏了」和「没提炼出东西」
  是两件事，混为一谈会让前者以后者的形式永远藏下去 ——
  每天显示「今天没经验可沉淀」，而真相是解析一直在失败。
· 判定解析不了 / shareable 不是布尔（比如给了字符串 "true"）→ 判否，
  并把原文片段带进 reason，让人看得出是「判否」还是「判炸」。

## 纠了自己两次

① 测试第一版把解析与失效分支**在测试里重抄了一遍**再断言 —— 那是在验一份复制品，
   代码改了它照样绿。改成加一条 setDreamAgentCaller 缝，只换掉「真起 CLI」那一层，
   解析、判空、失效方向全走真代码。
② agent.md 的相对引用按 **cwd 深度 3**（{aid}/{cid}/{taskId}/）解析，不是按文件
   自身位置 —— 仓库根是 ../../../../../。我按文件位置写了 ../../../，
   agent-md-refs.test.js 当场判红。**守卫替我抓的，不是我自己发现的。**

## 还没做的，写进文档 §5.4（别当成 dream 上线了）

· 定时挂载没做（决策 C 说每日一次）：现在只有 dreamOnce(agentId) 这个可调用单元，
  没挂调度、没 REST 入口。
· 还没写定义文件：只写本体根的 memory/experience.md（纯经验积累，删掉无副作用）。
  三个 git 跟踪的定义留给下一步，闸门与 definitionWritability() 已就位，
  缺的是「往里写什么、写成什么形状」那半边设计。
· **没有一次真 CLI 验收**：CI 里换掉的是 callDreamAgent 那一层，验的是解析与失效方向，
  不是模型写得好不好。两个本体的提示词**至今没有被任何模型读过** ——
  这正是 P3B W4 记过的形态（mock 从不读提示词）。
· 决策 D（提炼质量怎么评）仍未定；可追溯是它的便宜起步，不是替代品。

全量：144 文件 / 1323 测试全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

## 步骤 2：「有哪些公司」只认 company_agents 表

system/agents/{aid}/{cid}/ 是**约定不是校验**。实查 96 个二级目录里混着
train/ workspace/ 和带时间戳的测试残留（tmp-w7-*-1786986291739-*）。
拿目录枚举公司 = 把测试夹具当经验原料喂给提炼 agent。

改成查表，另补保留段 _global（全局 agent 的运行态落点，没人「雇」它所以不在表里）。
**目录从此只用来定位文件，不用来枚举公司。**
守卫里真造了 train/ 和 tmp-w7-* 两个目录，断言它们不进原料。

## 空转保护：水位线按「条数」不按 mtime

实查 75 份 memory.md 只有 7 份有非模板内容 —— 每日跑起来绝大多数 agent 没有新原料。
不拦的话每天几十次「读完发现没东西」的 LLM 调用在烧钱。

**判据用条数而不是 mtime**：mtime 会被任何一次无关写入推动（例如别处重写整份
memory.md），条数只在真的多出记录时增长。用 mtime 的话，空转保护会在
「文件被碰过但内容没变」时失效。

## 决策 A 的失效方向写进代码

去敏判定 agent **抛异常也算拒绝**，并把「为什么」写进 rejected[]。
否则现场只看到「少了一条」，查不出是判否还是判炸。
「少沉淀一条经验」与「泄漏一次机密」代价不对称，判据必须偏向贵的那一侧。

## 步骤 5：可追溯

每条原料带 source（{公司}:memory.md#{行号}），提炼产物落盘时把 sources
写进 experience.md 的引用行。没有它，dream 的产出无法验证对错 ——
与 FDE 那边「LLM 自己汇报分数」是同一个问题。

## 步骤 3 还差什么（写在文档 §5.3，别当成做完了）

编排 / 空转 / 闸门 / 落盘 / 可追溯都跑通了（6 例守卫），
**缺两次真 agent 调用的默认实现**：提炼 agent 与去敏判定 agent 的本体还不存在。
默认实现现在是一句显式 throw（「尚未接线」）而**不是静默返回空** ——
静默返回空会让调用方以为「跑了但没提炼出东西」，那是本仓库反复出现的失效形态。

也还没写定义文件：writeDistilled 目前只写本体根的 memory/experience.md
（纯经验积累，删掉无副作用）。三个 git 跟踪的定义留给下一步，
definitionWritability() 已能报出「现在能不能写、不能写是为什么」。

全量：144 文件 / 1316 测试全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>