宜博 / lemonboss

自动模式的驱动原语 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>

## 前置：存量记忆的搬家（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>

29-DREAM §四 的五步里先落两步。

## 步骤 4：本体定义文件的 git 历史闸门（决策 B.3）

用户定案：soul.md / agent.md **直接落盘**，但写之前必须确认这份文件已经在
git 历史里 —— 别导致直接修改而没有历史。

definition-write-gate.js 两条判据都满足才放行：
① 文件被 git 跟踪；② 该文件没有未提交改动。
判不出来（不在仓库 / git 不可用）一律拒绝 —— fail-closed。

**为什么是「拒绝并报告」而不是「脏就先替它提交一把」**：后者看着更顺手，
但那正是本仓库记过的一类事故 —— 多会话共用同一个 worktree（27-P3C §15.4）。
一份未提交的改动很可能是**另一个会话正在写的东西**，替它提交等于把别人的
半成品写进 main 且署错名。把「要不要提交」留给人。

守卫 5 例，含「拒绝时必须给出下一步」那条 —— 撞上闸门的人（或 agent）
要能照着做，否则只能猜。

## 步骤 1：memory.md 的自动写入不再冒充「关键事实」

原实现取任务与结果的第一行、砍到 80/100 字符，写进 `## 关键事实`。
那不是提炼，是搬运 + 截断。实测产物（cto/_global/memory/memory.md）：

    - [2026-08-20] [SYSTEM HEARTBEAT] → 🔧 [TOOL_CALL] Bash (ID: toolu_01RsQ3gh...)

**工具调用 id 被当成了「关键事实」**，而 memory.md 会被注入每一轮提示词。
28 §5.6b 点名的错误版本是「自动把原文写进共享 SKILL.md」——
这套已经是那个错误的单公司版，只是还没跨公司共享所以还没造成泄漏。

改法：
· 换段 —— 自动写入落到「原始记录（未提炼）」，`## 关键事实` 只由提炼产物填。
  读的人和 agent 一眼分得清「日志」和「结论」；这一段同时是 dream 的输入面。
· 滤掉确定的噪声（工具调用标记 / 空结果 / 只有心跳标记的任务），
  但**不猜「哪条重要」**——猜重要性需要理解内容，那是 dream 的活，
  在这里做等于把提炼下放到一个正则里。
· 不再截成半句：上限放宽到 200 并取完整第一行。截断残渣读起来像事实、
  其实缺主语，比不留更坏。

⚠️ 踩到一条：噪声判据初版有「任务与结果都短于 8 个字符就丢」。那是按英文长度
想出来的阈值 —— 中文 8 个字是一句完整的话，实测「结果甲甲甲甲甲」（7 字）
整条被丢。已删该规则。**凡是拿长度当信息量代理的判据，先问一句这是按哪种文字算的。**

全量：143 文件 / 1310 测试全绿。

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

28-followups §1.1 一直是「方向已定、设计未定」。这份把取舍摆出来并记下拍板结果。

## 先看清原料：它现在是脏的（全部实查，不是推测）

· **写进 memory 的不是「事实」，是截断的日志行**。appendToMemoryMd 的全部逻辑是
  「取第一行、砍到 80/100 字符」。cto/_global 的实际内容里，三条「关键事实」是
  `🔧 [TOOL_CALL] Bash (ID: toolu_01RsQ...)` —— 工具调用 id。
  §5.6b 点名的错误版本是「自动把原文写进共享 SKILL.md」；**现在这套已经是那个错误的
  单公司版**，只是还没跨公司共享，所以还没造成泄漏。
· 长期记忆是一个 3000 字符的滚动窗口，没有按重要性保留的机制。
· 96 个「公司态目录」里混着 train/ workspace/ 和**带时间戳的测试残留**
  （tmp-w7-*-1786986291739-*、qroute-co-13/14）。dream 第一步「枚举所有公司」
  现在没有可靠答案 —— 可靠的答案在 company_agents 表里，目录只能用来定位文件。
· 75 份 memory.md 里只有 7 份有非模板内容。**dream 现在几乎没有原料。**

## 四条拍板（2026-08-20）

A 去敏 = 独立判定 agent + 写作要求。失效方向是「少沉淀」不是「泄漏」——
  两种错代价不对称时判据偏向贵的那侧，与 P3B §八 FAILING_VERDICTS 同一条经验。
B 落点 = memory/ 与 SKILL.md 都写，**必要时迭代 soul.md / agent.md**。
C 触发 = 定时每日一次。
D 顺序 = 上游修复与 dream 一起做。

## B 把范围扩大了，随之而来的约束单列一节

「本体只有一份」意味着写 agent.md / soul.md 影响**所有雇了它的公司**，
而不是提炼出这条经验的那一家。所以四个落点按可逆性分层，并记了四条硬约束：
· agent.md 有一处 2000 字符截断 —— **作用点要说准**：那是给规划 agent 看的
  「角色定义摘录」（graph-engine.js:915），agent 自己那条装配链不截断。
  判据因此是「保证前 2000 字符仍然自足」，不是「不许追加」。
  （初稿我按记忆写成「装配时只读前 2000 字」，查了代码才改对。）
· 这四个里三个是 git 跟踪的**定义**，不是运行态 —— dream 改它们会进 git status。
· 毕业闸门读这些文件，写坏会让本体雇不进任何公司。
· 必须能分别回滚：经验写坏只影响上下文，agent.md 写坏影响所有公司。

## 还没定的

决策 D（提炼质量怎么评）；B.2 里「定义文件直接写还是走提案」——
我建议走提案并写进了推进步骤，但那是建议不是拍板。

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

## 病症（真跑实测）

2026-08-20 那条 run 的 timeline 里，**每个节点**的产物索引写入都失败：

    node.output | 产物索引写入失败 contract.json: UNIQUE constraint failed: index 'idx_graph_files_path'
    node.output | 产物索引写入失败 sdd.md:       UNIQUE constraint failed: index 'idx_graph_files_path'

19 次 agent 调用、每次两三个文件，无一成功。

## 根因：加了新索引、没删旧索引

产物索引加「版本」之前，唯一索引是无条件的
`UNIQUE(company_id, COALESCE(task_id,''), rel_path)`。加版本之后建表块换成了
带谓词的 idx_graph_files_current（WHERE superseded_by IS NULL），**但没人删旧的那条** ——
`CREATE ... IF NOT EXISTS` 只管不重复建，不会删已有的。

于是 recordFile 那套「先把旧行 superseded_by 指向新行、再插新行」的版本化写法
在存量库上整个失效：旧索引不认 superseded_by，同路径第二行直接撞。
而重试恰恰会让同一条 rel_path 被产出第二次。

## 失效方向：静默

writeFileIndex 把 recordFile 的抛降级成一条 timeline，**节点照样 success**。
后果是产物索引在任何有重试的 run 上都不全 —— 而下游节点正是靠这份索引
按 kind 找上游产物。不报错、不影响测试、git status 干净。

## 为什么没有任何测试照到

新建库压根没有那条索引（建表块里早就只剩 current 那条），**只有存量库会踩**。

这是同一类问题的**第三次**（tasks 加列的索引顺序、墙钟锚点迁移、这次）。
判据固定成一句话：**凡是碰 schema，「存量库重启」那条路必须单独走一遍。**

## 修 + 验

迁移里一句 DROP INDEX IF EXISTS idx_graph_files_path。
守卫 graph-files-stale-index.test.js 走存量库重启那条路，并验版本化语义没被削弱
（同路径两行、当前版本恰好一条、旧行指向新行）。反向验过：不删就红。

生产库已实跑验证：删索引后同路径连产两次不再抛，graph_files 24 行未受影响
（备份 /tmp/graph.sqlite.pre-idxdrop）。

全量：141 文件 / 1300 测试全绿。

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

28-followups §3.1。**审计结论与那条待办原来的写法不一样，两列要分开处理。**

## source_kind：删

与 origin 一一映射（global_agent↔builtin / company_hired↔created），
实查生产库 76 行零例外。全仓唯一读侧是 migrate() 里那条 origin 回填，
而那是给「origin 列出现之前写下的行」用的一次性迁移。

顺序：**先回填、再删列**，两步都用 hasColumn 守着（幂等）。反过来做不报错 ——
库能开、测试能过，只是那几行 origin 悄悄是错的。守卫
source-kind-drop-migration.test.js 走存量库重启那条路，专门钉这个顺序，
反向验过：弄反立刻红。

写侧散在 3 处生产 INSERT + 35 个测试文件。批量改的时候正则误伤了 4 处
（吃掉了 JS 默认参数、位置占位符、ON CONFLICT 的赋值行），逐个修回并复查了 diff ——
**这种跨几十个文件的机械改动，靠「全量跑一遍」兜底比靠正则写得对更可靠**。

## legacy_path：不能删，它还没死

原待办说「所有读取点都已改成从 id 推导」——那半句对新行成立，对存量行不成立：
· 新行 legacy_path 恒等于 system/agents/{id}（确实冗余）；
· **存量行里存着批次 4 之前的公司侧路径**，而 graph-seed-service 判「悬空行 / 孤儿行」
  靠的正是这个路径指向的目录还在不在。从 id 推导出来的路径永远指向 system/agents/，
  那条判据会整个失效。

实查生产库：76 行里还有 2 行是老路径（org-planner / org-coder 指着已不存在的
data/companies/mycompany/agents/）—— 正是这条判据要认出来的那种行。

退出条件写进了 graph-db.js 的建表注释（不只留在文档里）：
库里不再有 legacy_path <> 'system/agents/' || id 的行。

## 顺带记一条：getDb() 会就地迁移生产库

删列那次，生产库的列是被一条**查状态用的**一行 node -e 删掉的 ——
服务当时没重启，人也没打算迁移。结果是对的（幂等；与备份逐行核对 76 行一致、
origin 全部按映射回填正确），但「读一下状态」不该顺手改 schema 这件事值得知道。
闸门只挡测试进程，故意不挡普通脚本（挡了服务自己也起不来）。
注释里给了只读的正确姿势。

全量：140 文件 / 1299 测试全绿。

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

## 验收 4：从「静态成立」变成真的跑过一次

原状态是 🟡「静态成立，未真跑」—— 人读代码把
fixture verdict → FAILING_VERDICTS → readNodeProduct → callAgentNode 判 fail
这条链读通了，但没有任何一次真跑或真链路证据。

现在 graph-real-chain-smoke ⑥ 走完整条：fixture 产出 verdict="attributed"
→ 节点 fail、fail_reason=input_underspecified、沿 fail 边点亮下游、
判词落在**下游节点**行上（判词的载体是「点亮它的那次状态转换」，不是失败节点自己）。
反向验过：verdict 改成 passed 立刻红。

写 fixture 时踩到一条值得记的：fail_reason 是封闭域 ATTRIBUTION_REASONS，
第一版编了个 contract_invalid，被**按设计降级成 null** 并留一条 timeline ——
引擎不认识的归因一律不信。判据没错，是 fixture 错。

## 验收 2 / 8：由 2026-08-20 那次真跑验掉（§六ter）

· 2 —— 19 次真 agent 调用之后 `git status --porcelain` 完全为空，交付物都在项目根内。
  这正是 §六bis「后半被并行 agent 打破」那条的干净环境重验。
· 8 —— 判据取「它引用了只可能来自提示词的内部 id」：triager 判词原文写着
  「org-coder-impl 私有目录 rn_96a8cd696dcc 下只有 _research.md」，
  rn_96a8cd696dcc 是 graph_run_nodes.id，agent 没有别的途径知道它。

## 验收 9：产出端通了，消费端没等到那个形状

真跑里 triager **确实产出了两半地址**（orgNode + workNode）——
这一条本身有分量：27-P3/P4 §八.22 第 13 处记的正是「引擎四环全通，
但产出方 agent.md 里根本没有这个键」，那半条现在通了。

紧接着「忽略跨层地址」那条**不是缺陷，是判据在正常工作**：这次回退发生在
work 层内部，edge.to 本身就是 agent_call 节点，已是最细粒度，没有跨层可言。
缺的是**那个形状**：一次 org 层回退边、且目标是 subgraph 节点。

别把「机制没验」和「机制没有」混为一谈 —— 定点重置的逻辑侧有
graph-cross-layer-address.test.js 三例注入式覆盖，缺的只是真跑里发生过一次。

## 顺带

· template-verdicts 的样本非空那条补 ENOENT 容忍。它扫**活目录**，
  而 graph-real-chain-smoke 会在 system/agents/{aid}/{cid}/ 下建了又清运行态 ——
  文件在「列出名字」和「读它」之间消失是正常的。walk() 与 violations() 早就容忍了，
  只有这一处漏了，实测偶发红过一次。**扫活目录的守卫，每一处读都要容忍 ENOENT。**
· 真跑 timeline 里发现一条未修的：每个节点的产物索引写入都撞
  UNIQUE idx_graph_files_path 失败并被降级成日志（重试时同路径再写一次）。
  后果是 files.json 产物索引在有重试的 run 上静默不全 —— 归 P4 一起处理，记在 §六ter。

全量：139 文件 / 1297 测试全绿。

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

agent_call 与 subgraph 是**两段不同的默认实现**（defaultAgentExecutor /
defaultPlanWorkGraph），各有各的 onAcpEvent 累加、各有各的守卫开关分支。
上一轮只覆盖了前者，「规划子图」那半条链仍然是零真实覆盖。

现在走完：defaultPlanWorkGraph → AgentManager → ClaudeCliProtocol(mock)
→ extractPlannedGraph 解析回复 → createWorkGraphSafely → 建子 run。

断言两处假 planner 天然绕开的接线：
· 子 run 的定义确实来自 fixture 那张图（节点名 / systemAgentId 逐个对）
· 规划那一轮烧的 token 也进了预算 —— 走的是 defaultPlanWorkGraph 自己那条
  onAcpEvent，与 agent_call 那条不是同一段代码
③ 的守卫断言补上 subgraph 分支的正反对照。

新增 fixture workgraph-planning.json：图 JSON 同时放进 chunks 与 result
（mock 下 output 取哪一半由 AgentManager 决定，不该由 fixture 来赌）。

反向验过：抽掉 fixture 里的图 JSON、或把它的 usage 归零，对应用例分别变红。

**覆盖边界写在用例注释里**：跳过 resolvePlanningAgentName 里的按需 hire
（预塞一行 company_agents）—— hire 要一条真实公司记录，那条路径另有
company-hire-org-layer.test.js 盯着；这条 smoke 验的是规划链路，不是招聘。

全量：139 文件 / 1296 测试全绿。

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

## 一、W7「零边图」不是待办 —— 它早修了，是注释在骗人

`company-service.js` 的判据注释仍写着「判据用**有没有边**」，并留着一段
「已知残留：单 org node 的最小图没有边，判据③不生效……真跑到那一步再看」。

**那个残留在 `58a2865`（08-17）就修掉了**：`orgGraphMembership` 现在的主判据是
`authored_by='planner'` 的节点存在（「orggraph-planning 提交过一张图」的直接证据，
零边也认），边数降为存量行的回落判据；守卫 `company-hire-org-layer.test.js` 的
`CO_ZEROEDGE` + `W7-fix` 两条盯着。

注释没跟着改，于是它把读的人**引向一个已经修好的缺陷**去重修一遍 —— 我就是这么被
带偏的：读到那段注释就没再往 `orgGraphMembership` 里跟，还据此往待办清单里写了一条。
这是「指路牌失效」那一族，和 CLAUDE.md 死链同型，只是方向相反（那边指向不存在的东西，
这边描述已不存在的洞）。

判据的措辞也改了：**「成型」的判据在 graph-service.orgGraphMembership()，不在这里**，
免得下一个人照注释理解。P3B 文档与 docs/README.md 的对应条目一并更正。

## 二、还上「真实路径 smoke 进 CI」那笔欠账的一半（27-P3/P4 §十 硬规矩 2）

原话是「凡是靠注入点验的能力，都要有一条真实路径的 smoke 进 CI 才算验收完成 ——
这条欠账仍未还」。此前唯一走真实路径的 `scripts/real-pm-smoke.js` 要真 API 额度、
人工跑、而且验的是 DevLoop 不是图执行。

做法是把「真 LLM」和「真代码路径」拆开：**只把最外层的 CLI 子进程换成 fixture 回放**，
setAgentExecutor / setPlanWorkGraph 一个都不调。链路完整走
advanceOne → defaultAgentExecutor → AgentManager → ClaudeCliProtocol
→ onAcpEvent → 落盘 → readNodeProduct → settleNode → spendBudget → 边界守卫。

三条断言各盯一处**假 executor 天然绕开**的接线：
· ① mock/files 真的落到节点产物目录（假 executor 直接 return，这一环整个不存在）
· ② token 用量真的从 session/result.usage 数进预算 —— **就是 §六 验收 10 卡了两轮的那一维**
· ③ boundaryGuardApplicable 在这条路径上为真（注入假 executor 时它恒为假，
     那条唯一有实际后果的分支实际零覆盖）；带反向对照，注入后必须变假

反向验过：断掉①的落盘、断掉②的累加，对应用例分别变红。

为此改了一处 mock：session/result 的 usage 原来硬编码 {input:0,output:0}，
现在 fixture 可指定（缺省仍是 0，既有 fixture 行为一个字不变）。
**不改这一处，token 那一维在 CI 里永远产不出数** —— 验收 10 当初就是卡在这儿。

**没还清的部分写在文档里，别当成还清了**：真 LLM 仍进不了 CI；
subgraph 那一支（defaultPlanWorkGraph）仍只有注入式覆盖；
多节点 / 回退边 / 熔断没进这条 smoke，它只推一个节点。

afterAll 清掉真实链路建出的公司态目录（gitignore 挡着不进库，但留着会让别的
用例遍历 system/agents/ 时多扫一份）。

全量：139 文件 / 1295 测试全绿。

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

## 移进 done/

· 27-p3c-goal-task-model.md —— 五批实施完毕，§15.5 / §16.8 的后续项也全部收掉。
  新增 **§十七**：欠账清单对账、边界守卫从「乱扣帽子」改成「留证据不判罚」、
  测试污染生产图库（第四次踩同一族，但换了个方向进来）、那条卡了两天的 run，
  以及 **§17.5 真跑验收** —— org-planner-sdd/benchmark/validator 全 success、
  work run completed、父节点自动拉回、org-coder 起实现层子图、
  org-coder-validator 判 fail 走回退边打回 impl（loopCount 1）。
  **返工闭环第一次由真 agent（不是注入的假 executor）走通。**

· 27-p3c-batch3-handover.md —— 四条复核结论全修完、§五 那条 run 已解开，
  §七 待办全部打勾。从待办转为**事故记录归档**：§六 那几条多会话协作规则是真踩出来的。

两份的相对链接都已重指（done/ ↔ todo/ 跨目录），no-dead-path-references 守卫通过。

## 留在 todo/ 的，状态说清楚

· 27-graph-agent-architecture.md —— 状态行校准。那一行是别人判断「能不能搬 done」的依据。
· 27-p3b-real-run-runway.md —— 加状态行：验收 7 ⛔ 真跑不成立（readme-writer 混进
  org graph，**未修**）、2/4/8/9 未在干净环境验。缺陷② 的**根因**今天修了，
  但特意写明「**根因修了不等于验收点验了**」—— 不然下一个人会照着状态行当成验过。
· 27-p3-p4-work-graph-console.md —— 在索引里写明留 todo 的原因：
  §十 那笔「真实路径 smoke 进 CI」的欠账未还。
· 28-followups.md —— §3.3 标已修（含「GET /info 的 404 闸门仍没修，别当成修过」）；
  §五 守卫表加两行（graph-db-prod-guard / heartbeat-company-scoped），
  并补第七条的来历。

## docs/README.md

索引补上新增的 done 条目与 P3B / 28-followups 行，主线说明改成
「当前未完成的是哪几件」——原来只说完成了什么，读的人得自己推。

全量：138 文件 / 1292 测试全绿。

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

记三件这一批换来的东西：

§16.5 第 3 步怎么做到不碰契约：dispatch 的九步副作用里只有第 ⑧ 步是存储，
把 saveTaskMeta/loadTaskMeta 变成表的适配器、其余八步一行不动，URL 与请求体
形态天然不可能变。字段落点的三个判断也记了（objectiveId 可推导所以不存、
sourceConvId 零读取方所以删、没选 JSON blob 因为 R-19.2 否过那个形态）。

§16.6 删掉的是「猜」不是「记录」：122 行的三策略启发式换成 parent_task_id
显式记录；getTaskTimeline 保留，树从表来、正文仍读 agent 的一手会话记录。

§16.7 两次「测试全绿 ≠ 没坏」：routes/tasks.js 漏改（没有测试走那条路）、
控制台栏宽（构建/单测/探针都不会报）。与 §16.2 那个「存量库一启动就炸」
（测试能覆盖但没人写）合起来是一条经验 —— 新建库的路径、纯逻辑的路径由单测
天然覆盖；「存量数据」「真实接口」「肉眼可见」这三类必须另外安排人走一遍。

§16.8 留了三条：tasklog 目录改名待做、tools-base.md 的端口仍是 3000（实际
3010，已真咬过人）、TaskTimeline.vue 的两处字段语义变了。

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

记两条这一批换来的东西：

1. 加列时把 CREATE INDEX 写进建表块，会让**所有存量库一启动就炸** ——
   建表块先于迁移块执行，存量库上 CREATE TABLE IF NOT EXISTS 是 no-op，
   索引引用的那一列还不存在。而新建库（单测默认路径）完全正常。
   由此得到一条可复用的规矩：凡是加列，必须同时测「存量库重启」那条路 ——
   新建库的路径由每个单测天然覆盖，存量库那条没人走，而生产上只有存量库。

2. 回填沿用原 taskId 而不是新发：conversations/task-{taskId} 是目录名、
   汇报链路按它查找、summary 里互相引用。换 id 等于把引用全断掉，
   而回填的目的恰恰是别让历史消失。

并记下第 3 步动手前的前提：/task/dispatch 的 URL 与请求体印在
tools-base.md 里（所有 agent 的工具说明），一个字不能改；而 agent-chat.js
在 8-19 被另一个会话大改过，预研写在那之前，所以要重新读现状再动手。

顺带记一处过期且已咬过人的：tools-base.md 印的是 localhost:3000，
实际端口是 3010 —— 回填出来的派单正文里有人手写「端口 3010，不是 3000」
在纠正它。

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

## 批 4：解除「一家公司同时只有一个 active root run」
- DROP idx_graph_runs_one_active_root（建表块删掉 + 迁移块显式 DROP，
  CREATE ... IF NOT EXISTS 对存量库不生效）
- max_parallel_tasks 从 company.json 调用时读（不是模块加载时快照，
  否则改配置要重启才生效且不报错）；缺省 1、非法回落 1 并留声、硬上限 20
- 准入判据「从活跃集外进入活跃集」按额度计数

**生死线用 8 个真进程并发抢坑实测**（不是纸面论证）：max=1/2/3/5 四组，
每组恰好抢到 max 个、库里活跃数 = max，落选进程各吃 40 次 RunSlotBusyError，
零 other 错误。唯一索引没了之后，准入事务是真守卫。

## 批 3 对抗复核的四条遗留
- N1 🔴 cancelQueuedRun 的前提被批 3 自己的 requeueBlockedRootRun 改没了：
  queued 的 run 现在可以是跑过一半的。探针实测取消后子 run 残留
  paused/stop_requested=0 —— 那条 running 的子 run 继续调 agent 烧 token。
  改为无条件走 engine.stopRun
- L1 ⚠️ 恢复路径对 manual 只兑现一半：注释写着「T1 永远回不来这个后果因此
  消失」，但调度器故意不碰 manual → 退回队列后没人接。定案：「manual 不自动
  出队」约束的是首次起跑的授权，已被人亲手起过的不算新授权。
  判据用 attempt>0 而不是 started_at —— 后者会被 requeue 清成 NULL，
  恰好在需要它的那一刻是空的（实测踩过）
- N2 🟠「退回队列」对用户完全不可见：200 + ok:true + 按钮全灰 + 图消失 +
  一句「节点状态一律 pending」的假提示。加 notice 明说
- N3 🟠 isSlotRaceError 把 InvalidTransitionError 当竞态吞掉，而探针证伪了
  那条注释：被推走时条件更新返回 0 不抛，真正抛它的只有「调用方声明了非法
  转换」。删掉该分支，让它吵起来

四条里三条是同一个模式：注释承诺的前提被本轮自己的改动改没了，注释还留着。
文档 §十三.3 / §十四.4 已就这个模式立过两次案，这是第三、四、五次。

## 文档
§十五 实施记录，含 §15.4 一次流程事故：87b776c 由第三方会话在对抗复核完成
前误提，提交说明的「1201 用例全绿」压在一份尚未通过复核的代码上。

全量：128 文件 / 1240 测试全绿，web:build 通过。

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

起因是「全量测试偶发挂一条」。查下来既不是回归、也不是那 45 个孤儿进程（它们 CPU 早归零、
不再写任何东西），而是**还活着的心跳在测试扫描 system/agents/ 的同时往里建目录**：

    locator.taskDir() 的落点是 system/agents/<agent>/<companyId>/<taskId>，
    运行态目录落在本体目录里属既定设计；但心跳每 5 分钟建一个新的
    （cto/_global/ 已 263 个子项且在涨），于是扫描 system/agents/ 的守卫测试
    （no-dead-path-references 那一类）会撞上瞬时竞态：列到了目录名，进去时那一层还没写完。

症状是偶发假失败、重跑就好 —— 这类最费人，因为第一反应总是去怀疑自己刚改的代码。

改法：server/index.js 启动的那个 setTimeout 块里，恰好装着全部「会自己起 agent 的东西」
（两处中断恢复 + 任务队列扫描 + 两路心跳），所以一条早退就够，不必在五个地方各加一个判断。

    DISABLE_BACKGROUND_AGENTS=1 bash start.sh

实测：127 文件 / 1226 用例全绿，跑前跑后 cto/_global 子项数都是 263。

**验证它生效不能只看日志里的 ⏸** —— 那只证明代码走到了早退。硬判据是目录数前后相等，
也就是真的没有东西在写。文档 §七 把这条写成了可粘的三行。

排掉的两个坑，都记在文档和 .env.example 里：

1. `.env` 里不能给这个键赋空值。start.sh 是 `set -a; source .env` 加载的，.env 里只要
   存在同名键（哪怕空的）就会盖掉命令行传进来的 =1，而且不报错。所以 .env.example 里
   它只以注释形式出现 —— 一个「示例文件顺手写全」的习惯会直接让开关失效。

2. 开关生效后 `[TaskQueue] 🚀 已启动` 仍会打印，那是另一个模块：services/task-queue.js
   （ArenaSK 时代 /api/claude-chat 的队列，routes/claude-chat.js 模块加载时起），
   和批 3 的 services/task-scheduler.js 同名不同物。它的心跳只扫内存里的 this.tasks，
   不碰 system/agents/，不是干扰源。名字撞车，容易误判成开关没生效。

文档同步：
  - docs/done/claude-cli-session-leak.md §七 重写（原文写的是「得让测试隔离，或跑前停心跳」，
    现在后者已实现，改成开关的用法 + 硬判据 + 上面两个坑）；原第 2 条降为 §七之二
  - CLAUDE.md 测试命令块加一行（这是找「怎么跑测试」的人真正会看的地方）
  - docs/README.md 索引行补上开关

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

泄漏被修过一次（310a2b2 / 3e718aa），修完照样漏。第二次排查发现原因不是修错了，而是：

    系统里有两个互相独立的会话池，上一次只修了其中一个；而被修的那个，还漏了一条分支。

    池 A  routes/agent-chat.js 的 sessions       ← /api/agent/:id/chat，含两路心跳
    池 B  src/core/session-pool.js 的 SessionPool ← AgentManager.callAgent，图执行 / DevLoop

两者没有任何共享代码，回收逻辑各写各的。这个结构性事实此前没有任何一处记着，
所以第二个人查到同一个症状时会重走一遍全程 —— 这份文档就是为了让第三个人不必再走。

正文八节，除了两个洞各自的成因与修法（b0b2b62 / 2092a2e），有三处是排查方法而非结论：

§三 按 cwd 第三层判断孤儿归属的对照表。两个池子都把 cwd 下沉到运行态目录，
     `_global` / `_no-task` 是 agent-locator 的保留缺省值、两边都会出现，不能靠它区分。

§四 为什么上一版守卫是瞎的。dropSession 和 closeSession 都会让会话从池子里消失，
     黑盒探针两种情况都返回 false —— 差别只在子进程死没死，而那是探针看不见的维度。
     选探针要问的不是「能不能测出正确行为」，而是「能不能区分正确行为和这个具体的错误行为」。

§八 三步定位脚本，外加一条：先确认跑着的服务器进程是什么时候启动的，再去看代码。
     本次排查中，正在跑的实例比修复 commit 早 18 秒启动，代码里有的修复它并没有。

线上验证（PID 63099，13 分钟窗口两轮心跳）：触发 5 / 完成 5 / 回收 5，峰值子进程 3、稳态 0。
17:13:32 那个 3 正是泄漏时代的签名（cto+coo+qa-judge 同秒触发），清理前那批孤儿一个都不回收，
现在 30 秒内全部释放。窗口内没有失败心跳，所以 2092a2e 那条 catch 路径是靠单测的变异检验
保证的、不是靠线上观察 —— 文档 §六 里写明了，没算成已验证。

docs/README.md 同步加索引条目（no-dead-path-references 守卫 4 条全绿）。

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

lemonboss-78 已补齐 §二 的 4 条（均带探针实跑证据），§七 第一条待办随之过期。
把它勾掉，并把 N1/L1/N2/N3 各自拆成一条待办，附优先级判断：
N1（取消排队留下还在烧 token 的孤儿子 run）是唯一有直接金钱成本的一条。

顺带提一条给 lemonboss-78 判断的提议：「注释承诺的前提被本轮自己的改动改没了、
注释还留着」这个模式已经第三次立案（§十三.3 / §十四.4 / 本次），
第三次或许不该再只当个案记。提议不代表已立案。

只提交本文件；docs/README.md 与 docs/done/claude-cli-session-leak.md
是 lemonboss-89 的在途工作，未动。

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

lemonboss-68 写交接文档时只确知 1 条，其余 3 条刻意留「待补」而不是
凭二手转述硬写 —— 那个判断是对的，记错了反倒会变成新的事实来源。
这里由批 3 作者按 17:00 那次对抗复核的原文补齐，每条都有探针实跑证据。

四条：
- N1 🔴 取消排队留下还在烧 token 的孤儿子 run（唯一有直接金钱成本的）
- L1 ⚠️ 恢复路径对 manual 不成立（调度器故意不碰 manual，于是坑空着没人接）
- N2 🟠「退回队列」对用户完全不可见（200 + 按钮全灰 + 图消失 + 一句假提示）
- N3 🟠 isSlotRaceError 的判据注释被探针证伪，且吞真错误不打日志

其中 3 条是同一个模式：注释承诺的前提被本轮自己的改动改没了，注释还留着。
27-P3C §十三.3 / §十四.4 已就这个模式立过两次案，这是第三次。

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

87b776c 把 lemonboss-78 还在等对抗复核的批 3 提进了 main（提交者是我，未经作者同意），
复核随后给出 4 条问题。这份文档记下：时间线、main 上各笔提交的归属与状态、
那笔提交说明里「1201 用例全绿」的更正、待决策项，以及这次踩实的多会话协作规则。

顺带把最初那条卡住的 run（T-msyu6u9b-939c，boundary_escape 误伤）的诊断与
界面重跑步骤一并留档 —— 它至今没动，等工作区收敛干净才能跑。

只提交本文件，其余 13 个在途文件原样留在工作区未动。

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

goal 从「人写一句话」变成「agent 拆成一张 task DAG、人确认后下达」，
收敛时由 org-validator 在 goal 层再验一次。

## 交付
- task-planning 本体（毕业判据实测通过：agent.md + soul.md 一次写完、
  不带 _base 哨兵、路径按 cwd 深度 3 实算核对）
- 拆分链路：3 轮 errors 原样回喂 → 不过就降级成 1 条同描述 task，
  goal 绝不卡在 planning；token 记 goals.planning_tokens
- goal 级 org-validator 验收：≥2 条 task 全 completed 才调，单 task 跳过，
  有 failed 直接 failed 不调（省一次真花钱的调用）
- 控制台四栏 + GoalTaskPane 两级树 + 两步表单（拆分中给逃生口）
- 中断恢复：启动时补跑验收与汇报

## 三条跨进程竞态，全部用真探针实跑复现后才判定修好
1. runGoalSplit 无条件把 goal 写回 draft，抹掉逃生口刚下达的 active ——
   而触发它的正是表单自己推荐的那个逃生口。后果是一个正在烧钱的 goal
   显示成「草稿」，且从此永不收敛（OKR 不写、上级不唤醒、无日志）
2. CAS 把最终态提前写进库，验收窗口内重启即丢，且 verdict=NULL 与
   「单 task 合法跳过」形态相同，查不出来 → 占位判词 + 启动重推
3. 认领语句 SET verdict=RESUMING WHERE verdict IN (PENDING, RESUMING)
   —— 写进去的值就在 WHERE 里，changes 恒为 1。而函数注释白纸黑字
   写着「认领写的是另一个占位值」。注释是对的，代码没兑现。
   实测：org-validator 调 2 次 / OKR 写 2 条 / token 双记
   → claim 带唯一 token + 时间戳租约，回写条件更新决胜，主路径同闸门

## 与设计正文的偏离（已记进文档 §十四）
拆分后 goal 落 draft 而非 active（active 的语义已被 markGoalDispatched
钉死为「已下达」）；mode 三级继承对显式 tasks[] 同样生效；占位判词不出
API；新增 planning_error / reported_at 两列，后者迁移带回填（否则升级后
第一次启动会把历史终态 goal 全部重报一遍）。

## 过程
四轮 26 个 agent，复核报出 22 条缺陷，其中 6 条是修复自己引入的。
第四轮修完挂了 3 条测试，全是测试在钉住缺陷本身 —— 其中一条的注释
写着「模拟进程死后重启」，构造的却是新鲜占位值：注释描述 A 场景、
代码构造 B 场景、断言按 A 场景写。

全量：118 文件 / 1112 测试全绿，web:build 通过。

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

手工扫了两轮，扫出的是三类会持续复发的失真，不是零星笔误：
  ① package.json 里 12 处引用指向从未在 git 历史存在过的文件（server/src/cli/auto-dev.js 一族）
  ② CLAUDE.md 的 docs/ 那行列了 5 个文件名，文档移进 done/ 之后全成死链
  ③ 数据存储整节把两个不同的 data 根当成一个写，server/conversations/ 这个路径根本不存在

共性是**不报错、不影响测试、git status 干净**，只有照着做的人（或 agent）撞墙才发现。
而 CLAUDE.md 是每个会话都会加载进上下文的文件 —— 写错等于把错误信息直接灌给每一个后来者。

四条扫描：
  - CLAUDE.md 里的仓库路径都存在
  - CLAUDE.md 里出现的每条 npm run 都在 package.json 里（守反方向：删脚本忘改文档）
  - package.json 的 scripts / bin / main 指向的文件都存在
  - docs/README.md 的相对链接都指向真实文件

判据刻意窄（本仓库有过「防线被整条注释掉」的教训）：路径只认「以仓库顶层目录开头 + 含 /」，
且跳过 gitignored 的 —— 那是运行态产物（web/dist/、data/companies/、skills/），在干净机器上
本来就不存在，缺席不是文档错误；这与 no-stale-templates-path.test.js 用的是同一条判据。
上下文里的相对片段（_base/、todo/future/）、glob、<repo>/… 示意写法一律不判。

四条各带「样本非空」下限断言（当前 26 路径 / 16 script 名 / 6 入口引用 / 22 链接），
下限取当前值一半左右：正则一写错就会以「零违例」全绿，那和没有这条测试是一回事。

验证：把同一套判据跑在旧 revision 的文件内容上（只读 git，不碰工作区）——
  3e718aa：路径 ❌3 条、入口 ❌10 条
  d6214f8：路径 ❌4 条、入口 ❌10 条
  HEAD   ：全绿
顺带修掉自己写的一处假路径占位符（`data/xxx` → 「以 `data/` 开头的路径」），
文档里本来就不该出现假路径。

28-followups 守卫清单补到第六条，并写明后两条与前四条的形状差异。
npm run test:unit 1061/1061 绿。

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

新增 §十三，体例照 27-P3/P4 §十：设计正文不改写，只在这里与实现对账，
冲突处以实施记录为准（正文是设计时的判断，本节是跑出来的事实）。

记了与设计的四处偏离，其中两处是设计正文写错了：

① blocked 在 task/goal 两层都不是终态。正文 §四.3 把它与
   completed/failed 并列画成终态，实现时实跑复现出后果：预算耗尽后
   加预算恢复、跑完，两次条件更新静默命中 0 行，最终 run=completed
   而 task=blocked/goal=failed/OKR=failed 永久对不上。RUN_TRANSITIONS
   里 blocked: ['running','stopped'] —— 对 run 它是可恢复态，
   reviveParentFromChild 还会自动拉回。

② goal 级是唯一汇报出口，reportRunOutcome 已删除（零其它调用方）。
   1 goal:1 task 形态下 run 级与 goal 级会把上级就同一件事唤醒两次。
   from 的口径同时修正为实际交付者（terminalAgentId 搬进
   org-graph-service 当唯一持有者），不再用 created_by ——
   那是「谁下的单」，默认字面量 'human'，下游会静默落空。

③ dispatch 挑第一条可跑的 draft，连带补上 PATCH 改 seq —— 原先 409
   的 hint 写着「改依赖或 seq」，而那个端点从不读 body.seq。

正文里三处提到 reportRunOutcome 的地方一并标注：§四.7 加了「本节写于
实施之前」的前置说明，§十二（批 5）的前提改成「函数换了、依赖关系
没变」—— A 的回调链路仍长在 B 身上，只是出口从 company.js 的 run 级
换成了 task-settle 的 goal 级。

过程也记了：三轮编排 21 个 agent，对抗复核报 19 条，其中 4 条是
第二轮修复自己引入的。结论：对抗复核不能只做一轮 —— 修复和实现
一样会出错，而且更隐蔽，它长得像在解决问题。

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

把「人类提的一个需求」与「机器执行的一件活」拆成两级。这不是新概念：
27-NAMING §四 早就定义了 goal 1 : task N，graph_runs.goal_id / task_id
两列从 P3 起就一直在写，却没有任何表接得住 —— 本次补上那两张缺席的表。

## 交付
- goals / tasks 两张表 + CRUD + depends_on 环检测 + ID 生成器
  T-{base36}-{4hex}：原格式同毫秒必撞，而 tasks.id 是主键，
  「一个 goal 拆 N 条 task」是循环建行，撞了就是 500
- goal / task 全套端点；POST /:cid/tasks 向后兼容（不带 goal_id 自动
  建 goal）；退役 /api/goals 与 /:cid/goals 两个 OKR 别名（零调用方）
- 终态回写 + goal 收敛 + OKR 写一次：钩子挂在唯一漏斗
  graph-run-sse.transitionRun 上，而不是枚举路径 —— stopRun 与
  「预算耗尽 → blocked」两条最常见的释放路径都不走 settleRun，
  枚举一次漏一次。goal 收敛用 CAS 闸门，并行完成的 N 个 task 只有
  一个赢家做不可重放的副作用（写 OKR / 唤醒上级）
- blocked 在 task/goal 两层都不是终态：它是「挂起等人介入」，
  与 completed/failed/cancelled 不同类。否则预算耗尽后加预算恢复、
  跑完，两次条件更新静默命中 0 行，最终 run=completed 而
  task=blocked/goal=failed/OKR=failed 永久对不上（实跑复现过）
- goal 级是唯一汇报出口：删掉 run 级 reportRunOutcome（零其它调用方），
  1 goal:1 task 形态下它会把上级 agent 就同一件事唤醒两次
- dispatch 挑第一条可跑的 draft，而不是恒取 seq 最小那条 ——
  否则「第 1 条依赖第 2 条」这种合法输入会让 goal 永远下达不了
- 路径缺陷：writeTaskGoalArtifact 不认 GRAPH_RUNS_DIR 而读侧认，
  设了 env 就写进 A 处、从 B 处读，describeTask 拿到 null 后静默退回
  兜底文案「执行图节点任务」；三处模块加载时快照改为调用时读
- 存量回填脚本（幂等 + --dry-run）：不做的话批 1 反而让历史任务
  更看不见 —— 正是本批要修的问题的反向放大

## 过程
三轮多 agent 编排 + 每轮对抗复核，共报出 19 条缺陷（10 条首轮实现的、
4 条第二轮修复引入的、5 条判定为非问题）。全部已修并有用例覆盖。
新增测试 4 个文件，含不变式测试 runs-root-single-holder（凡是声明了
GRAPH_RUNS_DIR 覆盖的模块，该覆盖必须真的被用到）。

全量：116 文件 / 1057 测试全绿。

## 未做（属批 2-5）
task-planning 与 goal 级 org-validator 验收（批 2）、调度器与
run_status='queued'（批 3）、并行（批 4）、两套任务体系统一（批 5）。

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

承接 310a2b2 的两个遗留：

① 四类被错标成心跳
   company-heartbeat-service._sendAgentChat 给五类调用（心跳巡检 / Pipeline 步骤 /
   日程 / 告警 / 日报）无差别打 isHeartbeat:true，于是对话列表里全都显示成
   「⏱️ 自主心跳巡检」、meta.type 一律 'heartbeat'。改成显式传 kind，五类各自标注。
   isHeartbeat 仍然发，但只对真心跳为真，老消费方行为不变。

② 310a2b2 让 Pipeline 重试变成了冷启动
   Pipeline 步骤的 convId 是 `pipeline-{runId}-step-{i}`，被驳回重做时**复用同一个**。
   310a2b2 按 isHeartbeat 一刀切回收，等于每次重试都要走 buildPrompt 场景 C 重注入历史。
   现在回收策略挂在 CALL_KINDS 表上，判据只有一条：**convId 会不会被下一轮复用** ——
   会复用的（pipeline / 人类对话）留着走 TTL，不复用的（心跳 / 日程 / 告警 / 日报）跑完即回收。
   不按「是不是后台调用」分：五类后台调用里 pipeline 就是要留的那一类。

守卫补到 12 条（原 3 + kind 标注 5 + 回收策略 4）。对 310a2b2 跑过：8 红 4 绿。
convId 一律用固定字面量而非拼时间戳 —— 撞上 test-id-stability 那道防线后按它的判据改的，
固定之后第二次跑还顺带走了「复用已有对话」那条分支。

文档：
  - CLAUDE.md 注意事项加一条（新增会话创建路径时必须同时定回收路径，附症状与守卫位置）
  - 28-followups 守卫清单补第五条，并把「前四条守单一持有者」与第五条「守资源生命周期」
    的形状差异写明；顺手修掉表格已有 4 行、结尾却仍写「这三条」的失配
  - .env.example 补 AGENT_SESSION_IDLE_MS

全量单测 667/667 绿。重启后 /api/health 正常，心跳照常挂载。

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

27-P3C 批 1 沉淀的不变式测试，与前三条守的是同一件事：同一个事实
只能有一处持有者。断言的是「凡是把 process.env.GRAPH_RUNS_DIR 绑到
标识符上的模块，那个标识符必须在代码里真正被用到」。

来历一并记下：goal-contract.js 里曾有一行 RUNS_ROOT，注释写着
「与 graph-engine.RUNS_ROOT 是同一个变量（测试隔离在用）」，全文件
却零引用。声明了意图、代码不兑现的常量比没有更容易骗人 —— 读的人
会据此认为该模块认这个覆盖，然后写侧写进临时目录、读侧去仓库里找，
两个方向都静默错位。

四条共有的「样本非空」前置断言仍是重点：扫不到文件时这类测试会以
「零违例」的形式全绿，那正是它自己变成零调用方的方式。

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

主文档新增 §11.4b，记 dd319bb 那轮清掉的内容与「不清会怎样」：
四份本体提示词、三个 skill js、两份图模板 README 的 CI 防线规则、
DevLoop PRD 13 份 HTML（连带重生成的 52 份 _spec + manifest + search-index）。

其中两条值得单独记：
- innovator-hunt/collect_seed.js 是真 bug 且已发作过 —— 裸相对路径相对 cwd 解析，
  在 agent 自己目录下造出一棵野生嵌套树。
- DevLoop PRD 写的 system/templates/devloop-pm.md 根和形状都错
  （实际是 system/agents/{agentName}/prompt.md），由此推出一条方法论：
  批量替换字符串时，替换的正确性取决于替换后的整体是否成立，
  而不是被替换的那一段是否过期。

同时订正两处早于本次改造就已过期的内容（「6 个命名冲突 id」清单里四个 id
根本不存在；orggraph-planning 被告知的真相源仍是 company.json.agents[]），
并写明刻意不动的三类：历史说明 / 迁移完成的证明 / 运行态记录。

followups 新增 §五，登记本轮立起来的三条不变式测试
（agents-root-single-holder / no-stale-templates-path / repo-hygiene），
写明它们共有的「样本非空」前置断言为什么不能省，以及改动它们前要想清楚的事。
§四 那条「脚本路径需要跟着更新」已在 cd2066a 完成，改成实跑结论。

交付状态从「未 commit、未 push」更新为已推送（ca468ab..dd319bb）。

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

system/templates/ 已随 28 号改造整体并入 system/agents/，目录在磁盘和 git 里都已不存在。
但引用还散在各处，其中几处是 agent 运行时真会照着读写的：

本体提示词（读不到就静默降级，不报错）
  workgraph-planning/agent.md   system/templates/base/ ×3、模板库路径 ×1
  orggraph-planning/agent.md    同上 ×1
  orggraph-planning/tools.md    ×1
  org-innovator/agent.md        四条产出落点 system/templates/weibo-scraper/train/*

skill 代码里的硬编码目标
  evolver-youtube-crawler 的 refactor.js / mock_setup.js / evolve.js 共 4 处
  innovator-hunt/collect_seed.js —— 这处是真 bug 且已发作过：
    写的是裸相对路径 'system/templates/…'，相对 cwd 解析，于是在 agent 自己目录下
    造出一棵野生嵌套树 system/agents/innovator-hunt/system/templates/…
    现在改成由 __dirname 推导，不再依赖 cwd（cwd 已经是深度 3 的任务态目录）

图模板契约（work-graph-templates / org-graph-templates 的 README）
  CI 防线的三条规则写的还是「在 system/templates/ 下必须有目录」「在
  system/templates/_registry.json 里必须有条目」，与实际执行的检查已经对不上

DevLoop PRD（13 份 HTML + 重新生成的 52 份 _spec + build-manifest + search-index）
  写的是 system/templates/devloop-pm.md（扁平 .md）。根和形状都错：
  loop-controller.js:166 实际读的是 system/agents/{agentName}/prompt.md。
  按真实形状改，然后跑 spec:extract / extract-manifest / build-search-index 重新生成。

顺带订正两处早于本次改造就已过期的内容：
- 「避开 6 个命名冲突 id」这条约束列的 digester / evolver / hunter / innovator
  四个 id 根本不存在（早已改名），而它的理由（两个目录下各有一份、内容不同步）
  也已随合并消失。约束保留（元 agent 本来就不该进执行流），理由与清单按实际本体重写。
- orggraph-planning/agent.md 里「真相源是 company.json.agents[]」——
  28 号起真相源是 company_agents 表，company.json.agents[] 仅作兼容保留。

刻意不动的三类（改了是净损失）：
  历史说明   server/ 下解释「原来指向 X、批次 1 并进了 Y」的注释、docs/done/、tasks/
  完成证明   server/tests/ 里断言该目录已不存在的守卫
  运行态记录 未跟踪的 workspace/ conversations/ 与 train/ 下的历次训练报告

新增 server/tests/unit/no-stale-templates-path.test.js 守住活定义这一档：
扫 system/ 与 fixtures/ 下被 git 跟踪的文件（跟踪=人工维护的定义，
未跟踪=运行态产物），零例外。带「样本非空」前置断言防 git 失灵时退化成永远通过。
改坏一处实测能精确点名到文件行号。

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

并行会话指出 graph-engine.js 的 indexNodeOutputs 注释里早就写着
「goal-contract 零调用、setPlanWorkGraph 零调用、三值透传只接了读
那一半」。顺着查下去，这个模式在仓库里被记录过至少 7 处，而且证据
本身就是结论：

- graph-engine.js 跨层判据处：「（『实现在、零调用方』的第五次）」
- graph-run-route-io.test.js 文件头：「这一路踩了十几次的
  『实现在、零调用方』换个方向再来一次」
- graph-run.js:243：「等于又一次『实现在、零调用方』」
- 27-goal-contract-format.md:101：「T0 交付后有四轮时间里，全仓库
  唯一提到 goal-contract.js 的是一句注释 —— 实现完整、零调用方、
  零单测，验收 1 从未被执行过」

有人数到第五次，有人写「十几次」，然后它继续复发。这些记录证明的
不是「有这个问题」，而是「发现了也没人回来收」。

本文档的三处要求是同一个惯犯的三个实例：砍掉 goals.budget_json
（§四.1）、report_to 必须落库（§四.7 禁令二）、处理 goal-contract
那个声明了却零使用的 RUNS_ROOT（验收 12c）。写明它们是硬要求，
不是可以留到下一轮的整洁度问题。

批 1 一并加不变式测试「凡是声明了 GRAPH_RUNS_DIR 覆盖的模块，该
覆盖必须真的被用到」，形状照抄 agents-root-single-holder.test.js。
「样本非空」前置断言别省 —— 扫不到文件时会静默全绿，那正是这类
测试自己变成零调用方的方式。

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

并行会话指出我上一版归因错了，逐条复验后确认它是对的：

【纠正】runRootDir 与 companyRootDir 不是同一事实的两种拼法，是两个
不同的事实：
  runRootDir     → run 目录，覆盖态 {RUNS_ROOT}/{rootRunId}，
                   扁平即可（rootRunId 全局唯一）
  companyRootDir → 公司根，覆盖态 {RUNS_ROOT}/_companies/{cid}，
                   那层 _companies 是必须的（公司 id 不是全局唯一坐标，
                   扁平放会和 run 目录撞名）
company-paths.js 的注释本身写着「理由与 runRootDir 那处 override
一致」，作者是有意区分的。我上一版写成「三种拼法争权威、实施前先定
哪个权威」，会让批 1 实施者去做一个根本不存在的设计决策。真正错的
只有一处：writeTaskGoalArtifact 自己拼路径。修法一行级。

【新增缺陷 B】goal-contract.js:75 声明了 RUNS_ROOT、注释还写着「与
graph-engine.RUNS_ROOT 是同一个变量、测试隔离在用」——然后全文件
一次都没用过，同文件的 resolveRunDir 照旧自己拼。而且 resolveRunDir
全仓库零调用方（只有定义、exports 和一行文档）。

它今天不会出错，危害是注释在撒谎：声明了意图、代码不兑现的常量比
没有这个常量更容易骗人，第一个接上去的人直接踩。批 1 一并处理 ——
要么真的用上，要么连函数带常量删掉（零调用方，删更省）。

【验收】12b 补上必须「先设 env 再 require」的姿势要求，12c 新增。
第六个实例登记：graph-engine:84 / goal-contract:75 / graph-run-sse:34
三处都在模块加载时快照 GRAPH_RUNS_DIR，而 company-paths:14 的注释
恰恰记着相反的教训，既有测试已在为此做变通。教训在一个模块里学会
了没传出去 —— 不是事实被复述，是「事实该怎么读取」的约定只传一半。

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

并行会话把 system/agents 那一族收敛到 locator.AGENTS_ROOT 之后
（e120645，13 处跨 5 文件，我复验 3/3 通过），顺着同一个模式查
company.js 里的 data/companies 那一族，撞见一个真的分叉：

  写 company.js:writeTaskGoalArtifact
     path.resolve(__dirname,'../..','data','companies',...)   不认 GRAPH_RUNS_DIR
  读 graph-engine.js:runRootDir（describeTask / goal-contract 都走它）
     RUNS_ROOT ? path.join(RUNS_ROOT, root_run_id) : ...      认
  三 company-paths.js:companyRootDir
     runsRoot ? path.join(runsRoot,'_companies',cid) : ...    认，但形状又不同

同一个事实三种拼法。GRAPH_RUNS_DIR 一旦设上（目前只有测试在用），
写进 A 处、从 B 处读，describeTask 拿到 null 后静默退回兜底文案
「执行图节点任务」—— agent 从此拿不到真实任务描述，且没有任何报错。
goal-contract.test.js 的注释佐证读取方那套形状才是约定。

生产环境两边恰好都退到同一个默认分支，所以今天不发作。但批 1 会把
artifact 落盘点从「下达时」前移到「入队时」，正好要动这个函数 ——
修的时机就是那时。新增验收 12b 专门验它。

方法论也记一条：我第一次只 grep 了 TEMPLATES_DIR 这个名字，因此漏
掉同一文件里语义相同但叫 DATA_DIR 的 3 处。同义异名的副本按名字
grep 永远找不到，要按值 grep。

这是本文档攒到的第五个同类实例。同一个事实只能有一处持有者 ——
路径也是事实。

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

并行会话提醒 company-service.js 的 TEMPLATES_DIR 名字过期（实指
system/agents）。查调用点时发现更值得记的是 company.js：同一个
路径常量在这个文件里被重复定义了 7 次，6 处硬编码
path.resolve(__dirname,'../../system/agents')，只有 1 处用了权威
访问器 locator.AGENTS_ROOT。

这个路径 2026-08-18 刚被 agent 目录重构搬过一次 —— 下次再搬，
改 6 处漏 1 处就是静默 bug。批 1 本来就要大改 company.js（全部新
端点挂这里），顺手收敛成模块级一份，不是为改而改。

这与本文档反复点名的是同一个病：canDispatch 的取值域被前端复述过
一份、ACTIVE_ROOT_RUN_STATUS 在两个文件里逐字重复、
isUngraduatedStatus() 的取值域不许在别处复述。同一个事实只能有
一处持有者，路径也是事实。

同时登记一条刻意不做的：company-service.js 那个 TEMPLATES_DIR
改名要动 50 处、跨 6 个文件、零功能收益，不值得。留记录是为了
说明它是已知的，不是没人看见。

顺带独立复验：template-refs.test.js 4/4 通过，27-P3/P4 的
blocker 21（CI 因骨架悬空引用而红）确实已关闭。

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

刚提醒过并行会话「27-graph-agent-architecture 的状态行落后两个阶段，
会连累每一次迁移判断」，回头看自己这份也有同类问题：文档名叫 p3c、
自述「P3 收尾」，但内容已经溢出 P3 的边界。

补清楚三件事：
- 批 1-3 才是真正的 P3 收尾，是本文档主体
- 批 4（并行）归 27-P4 §一.3，那边是设计权威（§五.2 已有警示块）
- 批 5（两套任务体系统一）不属于任何既有 phase，是跨阶段技术债清理

以及最要紧的一行：五批全部未开工，0 行代码。判断能否搬 done 时
按批看，别按文档名看。

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

两处都是实测校准，不是凭印象改：

1. 27-graph-agent-architecture.md 的状态行落后两个阶段。
   原写「P2 起 📝 设计中/未实现」，实际 P2 的设计已归档在
   docs/done/system-design/27-p2-org-graph.md，P3 主体也已实现
   （27-p3b 自述「P3 主体已实现并提交 c3abf4a 起七轮，719/719 全绿」，
   27-p3-p4 有完整的 §十 实现记录 + 第六轮终验回填）。
   校准为 P0/P1/P2/P3主体 ✅、P4 📝 未实现。

   这一行是别人判断「哪些文档能从 todo 搬去 done」的依据，
   过期会连累后面每一次迁移判断，所以补了一句提醒。

2. 27-p3-p4 的 blocker 21（骨架悬空引用，CI 红）已由 28 号改造顺带关闭。
   实测：六个 id 全部登记在 system/agents/_registry.json；
   template-refs.test.js 4/4 通过（全量 999/999）。
   原文登记为「未修」的第二个隐患（_registry.json 被 usedCount 原地改写）
   也已关闭 —— usedCount 已挪到 data/template-usage.json（27-P3B W13），
   跑完真 CLI E2E 后该文件 git status 干净。
   原始记录保留备查。

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

27-P4 §一.3 的目标逐字写着「解除『一家公司同时只有一个 active
root run』约束 —— P3 v1 用一个唯一索引强制它，并行能力具备后应
放开」。本文档的批 4 在做同一件事。

划清边界：放开约束的设计归 27-P4，本文档只负责在它之上定义
「谁来排队、按什么序出队」。两边各写一版会产生两套并发守卫 ——
而这次要删的正是最后一道 DB 兜底，守卫分裂的代价特别高。

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

设计见 docs/done/system-design/28-agent-registry-unification.md。

改造前 Agent 本体散在三处（system/agents/ 11 个、system/templates/ 50 个、
data/companies/{id}/agents/ 17 个），同一个 AgentScaffold 被三个 baseDir 实例化。
后果是同一角色在 N 家公司下有 N 份互不相干的副本，模板更新不会同步；
org-coder / org-planner 这类走 hireFromBaseMetaAgent 造出来的本体
legacy_path 指回自己公司目录，永远无法被第二家公司复用。

本次：
- G1 单一注册表：system/templates/ 整体并入 system/agents/，base → _base。
  7 个同名 id 逐个裁决，被丢弃的一份归档到 docs/_archive/ 而非删除。
  source_kind(template/global_agent/company_hired) → origin(builtin/created)。
- G2 运行态下沉：CLI 的 cwd 从本体根改为 system/agents/{aid}/{cid}/{taskId}/。
  memory / conversations 落公司态 {aid}/{cid}/，按公司隔离不串。
  sessionPool 的 key 含 (companyId, taskId)，两家公司调同一 agent 不复用会话。
- G2b 产物不下沉：交付物仍落 data/companies/{cid}/，system/agents/ 只留运行痕迹。
  写入边界按链路分叉——graph 节点走节点私有目录（被 indexNodeOutputs 索引），
  chat 走公司 workspace，同一提示词里不再出现两条互斥指令。
- G3 公司只存引用：data/companies/{id}/agents/ 删除，新增 company_agents 关联表。
  不复用 org_graph_nodes——后者是执行流图，work 层本体被雇时不写它，天生覆盖不全。
- G4 缺则创建：本体缺失时从 _base 复制骨架进 system/agents/{id}/，
  agent-creator 填 agent.md/soul.md 后才从 draft 转 active（哨兵判据，
  骨架未填时哨兵仍在，不许被 hire）。产物即刻是全系统可复用的本体。

新增 server/services/agent-locator.js 收编原先散在 6 处的寻址逻辑。

边界守卫（graph-engine）的豁免从「本体根上五个文件名」放宽为整棵 system/agents/：
新本体的骨架本来就要进 git，gitignore 挡不住 ?? system/agents/{newId}/，
旧判据会把一个真正成功的招聘节点判成 boundary_escape fail。

存量迁移见 scripts/migrate-agent-registry.js（幂等，备份到 data/_migration-backup-*）。

真 Claude CLI E2E 已验证：新建公司 → orggraph-planning 自动规划 →
自动招聘 org-planner/org-coder/org-validator 三节点流水线；
data/companies/{cid}/agents/ 不存在，company_agents 4 行，
system_agents 56→56（零新建私有本体，纯复用），git status 零增量。

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