宜博 / lemonboss

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

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>

并行的 agent 重构那条线同步来的，已核实三个函数都在：
- agent-locator.js  missingBodyDefinition()   判什么算没填完
- graph-service.js  promoteDraftIfComplete()  转正动作
- graph-service.js  isUngraduatedStatus()     hire() 挡人的判据

关键是最后一个只挡 draft / training 两个状态，不是「≠ active 就挡」。
库里有 36 个本体的 status 是 enabled/idle/ready/trained，按「不等于
active」判会被全部误判成没填完 —— 这个坑已经被踩过一次。

取值域的唯一持有者是 graph-service，不要在别处复述 —— 与本文档
§六.3 记的 canDispatch 教训（前端复述了一份取值域还多写一个
blocked，导致公司失败一次后再也下不了任务）是同一个病。

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

另一条工作线正在做 agent 目录结构重构（system/templates 并入
system/agents），约 900 个变更尚未提交。逐条核实交集：

好消息 —— 本文档引用的全部函数/常量（settleRun / markRunReady /
stopRun / defaultPlanWorkGraph / PLAN_MAX_ROUNDS /
writeTaskGoalArtifact / reportRunOutcome / ACTIVE_ROOT_RUN_STATUS /
saveTaskMeta / getAggregatedTasks）在 650 行改动后全部存活，五条
行为性结论逐条复验仍成立，work-graph-db.js 完全没被碰（第二轮
复核最关键的那批发现不受影响）。27-P3/P4 那条「只写函数名不写
行号」的体例在这里直接兑现了价值。

坏消息 —— §四.9 有一条写反了，已纠正并留档：
- system/templates/ 彻底取消，本体落 system/agents/task-planning/
- _registry.json 不再是数据源头（seedAgents 直接 readdirSync 扫
  目录当真相，registry 只按 id 补 benchmark_score），所以「不登记
  会把 CI 跑红」不成立 —— 建目录才是关键动作，登记是可选的
- 真正的闸门是新增的「毕业」判据：agent.md + soul.md 非空且不带
  _base 骨架哨兵，否则 status 停在 draft、hire() 返回
  body_not_ready。「先建骨架后填」的中间态雇不进公司
- 本体正文路径三条硬规矩（cwd 深度 3）：自身文件 ../../、仓库根
  ../../../../../、交付物必须用 $W 绝对路径。写错全都不报错、
  只静默降级 —— 静默故障家族的最新成员

排期影响：批 1 照常（work-graph-db.js 无人触碰）；批 2 的
task-planning 本体等重构落地后再建，否则要按旧形态做一遍再改；
批 5 开工前重新核 agent-chat.js（+455 行）。

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

companyService.get 已经在读这个文件，零新增读路径；建表要多一张表、
一套读写、一次迁移，而目前公司级配置项只有这一个。涨到 3 个以上时
再考虑建表。

这是 P3C 最后一个开放问题，§十一 至此全部关闭。

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

R-20.6：
1. 退役 /api/goals 与 /api/company/:cid/goals 两个 OKR 别名，确认执行
2. goal 级验收仍用 org-validator，在 goal 层再调一次同一个本体。
   不复用 task 级结论 —— 两次验的是基数不同的东西：task 级问
   「这一个 task 的 task-goal 达成没有」，goal 级问「N 个 task
   合起来人要的东西做出来没有」。单 task 的 goal 跳过这次调用。
   goal 状态机加 failed，判词落 goals.verdict
3. 预算先不考虑，不做 goal 级闸门；但 planning_tokens /
   validation_tokens 两个记账字段保留 —— 它们不是闸门，是让
   goal 层那两次 agent 调用的花费可见
4. queued 开放改 depends_on。当初担心的「改完位次怎么算」不成立：
   queuePosition 只按 priority→seq→created_at 排，depends_on 决定
   的是够不够格出队，两者正交
5. 两套任务体系统一到 tasks 表，新增 §十二（批 5）

定案 5 核实出一个反直觉的前提：两套不是并列的，新体系的回调链路
长在旧体系身上 —— reportRunOutcome 收敛后调的正是
/api/agent/task/report。所以「删掉另一套」= 删存储与会话反推
（system/tasklog + TaskService.getAggregatedTasks），不能删入口
与回调：/task/dispatch 的 URL 与请求体写在 tools-base.md 里，
改它等于同时改所有 agent 的提示词。

tasks 表为此吸收三个字段（executor / assignee_agent_id /
parent_task_id）：agent 派单与 graph 执行的载体确实不同，
硬说成一回事是骗自己；调度器只管 executor='graph'。
顺带修好：派单去重从扫目录变一条 SQL，两套 T- id 合一。

开放问题 2/4/6/7 全部关闭，只剩 5（max_parallel 放哪）。

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

上游失败时下游自动转 blocked 已定案，开放问题里还留着同一个问题
的疑问句 —— 这正是「代码改了、文档停在上一轮」那类漂移。

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

R-20.5 四条：
1. task-planning agent 提进 v1（原计划 v2 人手拆）。产出一律 draft
   清单，人确认编辑后才下达 —— 那一步是唯一一道成本闸门，
   拆出 5 条 task 就是 5 份 DEFAULT_TASK_BUDGET
2. 并行仍留批 4，v1 只排队（max_parallel_tasks=1，唯一索引不动）
3. manual 任务不参与自动出队：startRun(manual) 只点亮入口就停下等
   /next，而 run 已经是 running 占着坑，自动拉起会堵死队头
4. 上游失败 → 下游自动推导为 blocked 并标红，给「重跑上游」和
   「强制放行」两个出路。blocked 每次 tick 重算而不落死，
   上游重跑成功后下游自己回 queued

定案 1 牵出一处新缺陷：task-planning 跑在 goal 层、任何 run 存在
之前，它烧的 token 没有预算池可扣 —— 正是 defaultPlanWorkGraph
注释里点名的「隐形的一半花费」在 goal 层的新实例。上一轮刚以
「零消费方」为由砍掉的 goal 级预算字段，以记账字段 planning_tokens
的形式回来（闸门仍不做）。

链路照抄 defaultPlanWorkGraph 不另造：调 agent → 校验 → errors
原样回喂，最多 3 轮；3 轮不过降级成 1 条同描述的 task，绝不能把
goal 卡在 planning。新本体必须与 _registry.json 登记同 commit，
否则 template-refs.test.js 当场把 CI 跑红（§八.21 有前科）。

验收 19-24 新增：拆分正常 / 失败降级 / 记账 / 不该花钱的路径不花钱
/ 上游失败下游标红且可恢复。

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

逐条对着代码核初稿，最要命的一条是基础事实搞错了：

- createRun 在建行的事务里就按 readDefGraph 把 graph_run_nodes 全插好了。
  初稿三处基于「queued run 没有节点行、进去就是空指针」的论证全部作废。
  真实情况是 queued run 与 ready run 在数据上只差 run_status 一个字段，
  所以「靠没有节点行自然报错」那道想象中的防线根本不存在，
  唯一的闸门是 advanceOne 里 run_status !== 'running' 那一句，必须加断言钉死。

由此派生出一个既存、但被排队从毫秒窗口放大成必然事件的缺陷：
节点行在 createRun 时快照，而 getRunState 每次读都取当前定义。
排队期间点「重新规划组织」→ 新节点没有 run 行 → 出队即卡死。
补 syncRunNodesToDef，出队前对齐。

其余六处：
- 出队原语写错：markRunReady 把 from 写死成 planning，复用不了；
  正解是 updateRunStatus(runId,'queued','ready') 这一条条件更新
- 唯一索引冲突是 throw 不是 changes=0，初稿的错误处理只覆盖一半
- 触发点枚举本身是漏的：stopRun 与预算耗尽→blocked 两条最常见的
  释放路径都不走 settleRun。改为挂在唯一漏斗 transitionRun 上，
  一个钩子覆盖全部路径（枚举法在这里靠不住，而漏的症状是静默的）
- report_to 只活在请求闭包里，排队后回调链路静默断掉 → 必须落库
- okr_node_id 逐 task 下发会反复覆写同一个 OKR 节点，
  done 会被后来的 failed 翻掉 → task 的 run 一律不带 okr_node_id
- manual 任务占着 running 等人点「下一步」，会永久堵住队头
  → 不参与自动出队

补漏：存量回填脚本（不做的话批 1 反而让历史任务更看不见）、
任务级 rerun 与节点级 retry 的命名撞车、queuePosition 排序口径
必须与调度器同源、砍掉没有消费方的 goals.budget_json。

错误结论留档不删（§三 ⚠️ 块 / §五.1 / §九.1 开头）——
它们是最容易再犯一次的那类。验收从 12 条涨到 19 条。

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

控制台走查暴露的「一个 company 只能有一个任务」，根因不是并发约束，
是「人类提的需求」和「机器执行的单元」被压在同一条 root graph_run 上。

三个实地核实的前提，让这次不是发明新概念：
- 27-NAMING §四 早就定义了 goal 1 : task N 的基数
- graph_runs.goal_id / task_id 两列早就在，company.js 注释也写着
  「三者基数不同不可混用」—— 但全仓库没有任何写入方，goal_id 是悬空外键
- G- 前缀已被 OKR 正名释放；/api/goals 与 /api/company/:cid/goals 这两个
  OKR 向后兼容别名全仓库零调用方，可以退役后把路径要回来

设计要点：
- goals / tasks 两张新表 + graph_runs 新增 run_status='queued'
- queued 的唯一理由是把出队的并发临界区交给既有唯一索引兜底：
  idx_graph_runs_one_active_root 覆盖 ready/running/paused 而不覆盖 queued，
  超发会被索引直接拒绝，不需要应用层的「先查后插」
- 排队推翻了 P3「拒绝而不排队」的定案，但那条定案的理由（没有出队 worker =
  静默丢任务）今天仍成立，所以调度器的四个触发点是功能主体而非收尾
- 已下达的描述冻结：入队即写 task-goal.json 并被 describeTask 消费，
  改库不改 artifact 会让两份对不上，两份都改等于篡改审计输入
- 现有 T-${Date.now().toString(36)} 在「一个 goal 批量建 N 个 task」下
  同毫秒必撞，且 tasks.id 是主键 —— 改用仓库既有约定的 4hex 后缀

R-20 四条定案回记至 27-requirement.md。

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

第六次真 CLI 冒烟 gapClosed=true：org 层契约落库 4 行（此前恒 0），
且那段文字真的进了 workgraph-planning 收到的提示词（52677 字节，第 746 行起）。

## workflow 四路并行的产出

- **org 层两半一起接**（关键顺序）：先接读回方 buildPlanningPrompt 的 ③bis 段
  （org 边入边 → 上游绝对路径；出边 produces → 「你规划的子图必须有节点产出这些」），
  再接声明方 orggraph-planning 模板。只补模板的话就是又一次「声明了没人读」——
  org 图节点全是 subgraph，而 describeInputs 对 subgraph 直接返回空。
  resolveInboundLines 从 describeInputs 抽出共用，两侧口径物理上不可能漂移。
- **清掉 404 死路径**：模板三处教的 POST /api/company/:id/work-graphs 从未注册。
  真跑复验：agent 侧零调用，改为按新 Step 7 写项目根绝对路径，还自己 require
  validateWorkGraph 预检了一遍才交回，round=1 一次过。
- **四张骨架补 produces/needs**：从「靠模板文字施压」变成结构保证，每张过规则 6。
  真跑里 agent 照抄了 planner.json 并跟着任务删掉 sdd 节点——是改编不是复制。
- **graph-seed 顺序依赖**：靠生产代码里已有的 GRAPH_SEED_ROOT 缝隙指向冻结快照。
  不是「跑几次都绿」结案：构造了原先必红的 churn，修前 12 次 3 红、修后 15 次 0 红。

## 我自己收的 4 条 major + 1 条 minor（都在 graph-engine.js）

复验挖出「引擎自己拼的提示词在教 agent 做模板明令禁止的事」，同一条提示词里对立：
1. 「已自行落库成功时回一行 workGraphId: wg_xxx」vs 模板「你永远拿不到真的 wg_ id，
   永远别写」。agent 没有任何受支持的落库途径，写出来必是编的，而 extractPlannedGraph
   优先匹配那个形状、查库查不到就整轮作废。删掉邀请，保留引擎解析真实 wg_ 的能力。
2. 内联图示例的边一个 produces 都没有——agent 唯一见过的「边长什么样」是零声明的。
3. 「端点尚未上线」暗示将来会上线，于是它还想去试一次。改成「不存在、也不会上线」。
4. indexNodeOutputs 收集 declared 不按 role 过滤，把出边的 needs 当成本节点的产出。
   Chrome 走查实测：产品需求文档.md 落成 artifact，下游 prd 输入变 ⚠️。
   更坏的一面是错标（brd_notes.md 命中中继 needs[brd] → 归因给错的产出方）。
   1ea9efa 加的 role 列，这里正是它存在的理由。
5. (minor) contract.prev.json（retryNode 的契约快照）被索引成 artifact 噪声。

新增 guard：引擎提示词不许与模板对立（静态读源码，剔掉注释行——
第一版把「解释为什么不许说某句话」的注释也扫进去了，量错了对象）。

测试 850 全绿（83 文件），既有断言未改。5 处变异精确变红后逐字还原。
Chrome 走查确认控制台正常分支（此前只验过降级分支）：契约药丸、绝对路径、
needs 中继说明、tab 上的 ⚠️ 计数全部渲染，零 console 报错。

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

第五次真 CLI 冒烟（gapClosed=true）暴露的两条，都是「这轮成立是侥幸」型。

1) indexNodeOutputs 靠文件名定 kind
   真跑成立纯属 brd 节点恰好把文件命名成 `brd.md`。换写 `业务需求文档.md`
   就落成 kind=artifact → 下游入边声明的 brd 查不到实例 → 提示词退化成
   「⚠️ 索引里查不到实例」，即刚关掉的断点换个形式重现。agent 给产物起中文名
   是完全正常的行为，不该由它决定索引对不对。
   改成两遍：先按文件名认领，再在**一对一无歧义**时（还差一个 kind 没人产、
   正好还剩一个认不出的文件）按声明认领。有歧义不猜 —— 猜错比留 artifact 更坏，
   错的 kind 让下游读到一份不是它要的文件，artifact 只是查不到、会如实报 ⚠️。

2) describeInputs 任务级共享不去重
   真跑里 brd 与 prd 两个节点各写了一份 contract.json，都是 kind=contract，
   于是往后每个节点的提示词里「contract（任务级共享）」逐个累加。节点一多是噪声，
   且给 agent 两个同类路径等于把一个我们自己都没定的选择推给它。
   按 kind 保留最新那份，与沿边那一半的 byKind.set 同口径。
   ponytail 标了根因（节点私有目录的文件也会按文件名落成 task-shared 的 kind）
   与真正的修法（任务级产物只认 tasks/{taskId}/），后者要动 R-9.3 现有语义，
   归到那条线一起定。

测试 829 全绿（+3），既有断言未改。4 处变异精确变红后逐字还原。
含 verify agent 回填的 §4.6「第五次真 CLI 冒烟」小节。

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

R-19.A 把 declareEdgeContract 的调用方补上之后，inboundContracts 终于非空，
「沿边传递」这类数据流在真跑里生效了（真实规划 agent 自己在边上写出了
produces/needs 声明）。本次收掉它留下的三个缺口。

1) role 落库（第 14 次「四环漏一环」）
   normalizeContracts 产出 role，declareEdgeContract 入参没有它、表也没这列 ——
   产生 → 传递(丢) → 落库 → 读回。后果不止是控制台不精确：规则 6（data-contract）
   靠「有人 needs 但没人 produces」判错，只存 kind 就没法从库里重算，而
   patchGraph 第 5 步的重新校验读的正是库 —— 增量 PATCH 又恰恰是
   「此前满足的 needs 失去产出方」的唯一发生地，校验偏偏在最该生效的通道上失效。
   - graph_edge_contracts 加 role 列（CHECK + 老库 ALTER 后回填 produces：
     NULL 在规则 6 里既不算产出也不算需求，会误拒一张合法的图；闸门宁可漏判不可错拦）
   - 两层调用点透传 role；readGraph 把 contracts 读回来并递进 validateGraph

2) 控制台三字段（前端在、后端没喂）
   GET /api/graph-runs/:id 补 edges[].contracts / companyRoot / taskFiles，
   否则 R19-C 那三块界面整块降级：声明和索引都在库里，界面上看不见。
   contracts 只在非空时出现，与 failReason 同一个约定。

3) 收拢 companyRootDir/taskDirRel 镜像
   goal-contract.js 里那份镜像靠注释约定「与 graph-engine 逐字同构」维持，
   控制台路由成为第三个调用方时这个约定就不成立了。抽到 company-paths.js，
   GRAPH_RUNS_DIR 改为调用时读（原先两个模块各自在加载时快照，
   加载顺序不同会算出不同的根）。goal-contract 那条「镜像漂了就报警」的用例
   按其自身预告改成比函数返回值。

测试 826 全绿（+11：role 8 / 路由 3），既有断言未改。
11 处变异逐一验证精确变红后逐字还原；其中一条断言初版在 fixture 上永远自洽
（图里没有无声明的边），补了一条无声明的边才真正有判别力。

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

第四次真跑的断点：org-planner-prd 失败，它自己的归因原话是
「不是上游没产出，是它的产出**结构上到不了我手上**」。核实属实 ——
上游 brd.md / contract.json 落在**节点私有目录**，prd 的提示词只有它自己的私有目录
+ 只读 artifacts/，而 brd--success-->prd 这条边**不携带任何文件引用**。
边一直只承载控制流（condition/edge_kind/fail_reason），R-4 要的「边的输入输出」
被落成了从 output_ref **推断**的 UI 展示、没有实体，而推断的那一端下游读不到。

## 定案（27-REQ R-19）

- 建 sqlite 表而不是 files.json：JSON 会重演 _registry.json 的并发重写与 git 冲突
  （本轮刚被它咬过，W13 只能把 usedCount 挪去另一个被 ignore 的文件）
- **两类数据流都要**：纯边绑定表达不了 R-9.3 的「planner 生成、validator 执行」——
  org graph 是 planner→coder→validator，acceptance 跳过 coder，这两点之间没有边
- workspace 根**代码推导不入库**：存绝对路径会烂，W13 清的那 10 条 legacy_path
  悬空行就是这个病。表里只存相对公司根的路径
- 路径走 tasks/{taskId}/，不走 workspace/：后者语义是「Agent 自治领地、框架不干预」
  （06-沙盒自治），与「框架管着、可检索的交付物区」是两种所有权
- 契约(kind)与实例(path)分规划时/运行时两阶段 → 引擎可在节点跑之前校验
  「你声明要吃 brd，但上游没人产 brd」，这类图结构错误此前只能等跑到那步才发现

## 实现

work-graph-db：graph_files（实例）+ graph_edge_contracts（契约）两张表。
graph_files 的当前版本走**部分唯一索引** WHERE superseded_by IS NULL ——
与 idx_org_graph_nodes_company_role_active 同一模式：要「同键只有一个活的」
又要留历史，条件得写进索引而不是靠删行。API：recordFile / findFiles /
declareEdgeContract / edgeContracts / inboundContracts / rebuildFilesFromNodes。

graph-engine 两侧都接：
- 输入侧 describeInputs：按**入边声明的 kind** + **本 task 共享产物** 查实例，
  把绝对路径拼进提示词。声明了却查不到的**明说缺哪个 kind**，不静默省略。
  刻意不是「注入一句『索引在某文件，自己去检索』」—— 那仍靠 agent 自觉拼路径，
  真跑已证明它拼不出来；引擎直接递到手上，不给它猜的机会
- 产出侧 indexNodeOutputs：节点 success 时登记落盘文件，kind 先看出边声明、
  再按文件名兜底；attempt-*.json 是引擎自读的归因文件，不当产物登记

文档：27-REQ 新增 R-19（四条，含两段原话）；27-P4 §4.6 按定案重写
（原「公司根一个 files.json」作废）。

测试 788/788 全绿。后续（下一轮）：规划侧声明契约、goal-contract 路径归并、
前端「输入输出」tab 展示解析结果、真 CLI 复验 prd 能拿到输入。

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

## W11 最后一块：agent 侧的假承诺

方案 (b) 此前只把 agent-chat.js 的空转喊出来了 —— 那是喊给**运维**听的。
而 agent 读的是 system/templates/base/agent.md，那一侧还写着：

- 开场「你当前默认只被挂载了 meta-research 这个元技能」—— 那个包不存在，没挂载过
- 阶段三「*系统给你换上 meta-execute 技能时，你才会拥有修改核心文件的破坏性权限*」
  —— **纯假承诺**：权限自始至终由 config.json 的 cli.toolPolicy 决定，与 phase 无关，
  而 base/config.json 从 RESEARCH 第一秒就给了 bash 与 str_replace

**一个以为自己被拦着的 agent，比知道没人拦它的 agent 更危险。**

改成如实表述：开场加一段说明「技能包不存在、换装不会发生、权限全程不变、
四段式真正给的是上下文隔离而不是权限隔离」；三处「换上 X 技能」改成
「记忆已清空，你手上只有 <artifact>」；阶段三那句改成「写入权限从第一阶段起
就没变过 —— 前三步不落盘是纪律要求，不是系统给你的限制」。

至此 (b) 才算闭合：运维侧有告警、agent 侧不再被误导、文档侧记清了根因。

## 自动模式真跑：跑出一个结构性缺口

关看门狗后自动模式接管（pause → start{mode:auto}，运行中的 run 要先暂停才能切模式），
它自己把 brd 之后的节点接上跑。结果：

- brd → success（产出 brd.md + contract.json）
- prd → **fail(impl_bug)**，run 收敛 blocked，预算 calls 3/100 tokens 52,096
- worktree 零污染（与跑前逐行一致）

prd 自己的归因说清了原因，而且是对的：**它拿不到上游的产出**。
brd 的 brd.md / contract.json 躺在**它自己的私有目录**里，
而共享区 artifacts/ 只有 project-root.json 与 task-goal.json ——
同一张 work graph 内部**上游→下游没有任何数据通路**。

这不是引擎 bug，是 §四.A.5 设计里只做了「跨 org node 走 artifacts/ 共享区」，
没做「同图内相邻节点怎么把 contract 交出去」：CONVENTIONS §12 的隔离原则是
「下游只能看到上游的契约、看不到实现」，但契约被写进了私有目录，
下游同样读不到；而写 artifacts/ 是只给验收契约产出者的特权动作。

W12 补完在这一轮同时得到验证：fail_reason=impl_bug 落库，概览 tab 显示
「[归因产出] impl_bug」+ 完整 remediation_note，不再是「失败、无原因」。

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

测试 786/786 全绿（76 文件，起点 760/72），未改任何既有断言。

## 本轮三件新东西，全部经真 CLI 验证

W12 补完 · 失败原因四环打通
- 引擎自判的失败（executor 抛异常、边界越界、子 run 无归因）现在也落
  graph_run_nodes.fail_reason，不再只有 agent 归因产出的才有值
- 概览 tab 展示「[引擎判定] boundary_escape」+ 终端样式 excerpt，
  取不到 fail_reason 时回落 output_excerpt，并标明来源
- 真跑实查：两行 fail_reason='boundary_escape' 都在库里，
  产生→传递→落库→读回四环在真 CLI 下走通

W13 · 运行态文件根治（守卫误判的根因）
- 17 个 todo.md / plan.md / scheduled_tasks.json git rm --cached + gitignore；
  源码（agent.md/config.json/soul.md/tools.md）一个未碰，模板本体仍跟踪
- _registry.json 的 usedCount 挪进已忽略的 data/template-usage.json
- 真跑验收：整轮（agent-creator、Master 各一次真 CLI、3 次 hire）结束时
  worktree git status 与基线逐字相同，_registry.json 零 diff

单步进度感 · 真 CLI 一个节点 3-7 分钟
- 画布卡片秒表 + 详情面板常驻条「运行中 2m40s · 最近事件 …（2m40s 前）」
- 不做假进度条：引擎不知道 agent 还要多久
- 顺手修 NodeDetailPanel 不跟 SSE 走（否则秒表也不会动）

W9 失败上下文进提示词、W10 跨层地址两半、W11 Hot Swap 显式告警同批完成。

## 真跑结论：链路更长，但「work 节点 → success」仍未跑到

走到：orggraph-planning 落图自雇 → agent-creator 补定义 → workgraph-planning
真跑规划 + **先雇后提交**（W5/W6 再次成立）→ 子 run 起来 → work 节点 RUNNING
→ 7m19s 后 fail。两层原因叠加，都与 W1-W14 无关：

1. **新缺陷**：agent-manager.js:324 把 idleTimeoutMs 硬编码 120s，
   readme-writer 通读源码静默超 2 分钟被掐死（动笔前就死了）。
   同进程 ClaudeCliProtocol 早把自己的 idle 上限放到 24h，
   stream-executor 的 JSDoc 默认值写的是 30 分钟 —— 这里把两者都压掉一个数量级；
   且 ...options 透传的 idleTimeoutMs 会被下一行覆盖，调用方无法覆写。
2. **并行 agent 污染**：retrain-watchdog 每 5 分钟唤起的 Master 在同一工作树里
   改了两个源文件，被守卫 git status 差集算到该节点头上 → 额外署 boundary_escape。
   这是 W3「拦不住」第 5 条第一次真实发生。

顺带记一笔：这一轮任务是 **LemonBoss 自己的 Master 自主下的单**，
走的正是 POST /api/company/:id/tasks，它还自行诊断出了上面那个 idle timeout
并动手改（引用了未定义的常量，是坏的）。

## 已知未修（下一轮）

- idleTimeoutMs 硬编码 120s —— 「work 节点 → success」跑不通的唯一技术原因
- W7 在**零边最小图**上失效：判据③要求存在 active org_graph_edges，
  零边图上三条判据全落空，work 层本体被写进 org_graph_nodes。
  服务层那 9 例测试造的都是有边的成型图，正好绕开这个形状
- 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含：
  一家公司只要失败过一次，控制台上就再也下不了第二个任务（后端其实放行）
- 真跑期间工作树里不能有第二个 agent 活动，否则守卫判罚不可信 —— 应写进真跑规程

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

真 CLI 冒烟（worktree 隔离，PORT 3010）九轮来首次把 work 节点跑起来：
orggraph-planning 真跑 3 分钟自主裁成单 org node 零边图 → workgraph-planning
第 1 轮产出合法图 → **自己按 Step 6 把 brd-planning / planner-validator 雇进公司**
（W5/W6 核心验收成立，且 W7 判据生效、两者都没写进 org_graph_nodes）→
第一个 work 节点 brd-planning 真起 CLI 子进程，产出 brd.md / contract.json /
attempt-0.json 全部落在 run 目录内。图内预算仅 2 次调用 / 13998 tokens（上限 15）。

W5/W6 · workgraph-planning 自雇：撤掉「你不招人也不辞人」，Step 6 加招聘环节，
  写死「先雇、再提交图」的顺序，给出失败分级与幂等要求
W7 · work 层招聘不写 org_graph_nodes：按 type 与 work graph 骨架点名两条判据区分层级，
  P2 「hire org 角色 → org graph 出现该节点」的语义保持不变
W8 · 控制台「规划组织结构」按钮（抽成 ReplanOrgGraphButton.vue，带过渡态与秒表），
  接 POST /:companyId/org-graph/replan（该端点此前无任何前端调用方）；
  新增 fixtures/devloop-mock/orggraph-planning.json
W12 · 节点失败留痕：node.output 带 output_excerpt、新增 node.error 事件。
  真跑当场救场——守卫误判那条归因正是靠它才查得出来，
  换成之前看到的只有「节点 fail、无原因、无痕迹」

测试 753/753 全绿（71 文件，起点 736/68）。

已知未修（下一轮）：子 run 转终态不回写父 node_run 导致任务永久卡死；
applyBoundaryGuard 用整仓 git diff 判归属会把并行 agent 的写算到当前节点头上；
W12 的 fail_reason 未落库（概览 tab 仍为空）；POST /:cid/tasks 无前端调用方。

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

测试 736/736 全绿（68 文件，起点 719/66，净增 17 条，未改任何既有断言）。

W1 · seed 接进启动流程 + 悬空行回收
- server/index.js 与 agent-server.js 均在 listen() 前调 runStartupSeedSafely()
  （幂等、失败降级记日志、不挡服务启动）
- seedTemplates() 此前**没有任何运行时调用方**，只有测试与手动脚本引用，
  于是 system/templates/ 新增本体永远进不了 system_agents，而
  work_graph_nodes.system_agent_id 是指向该表的外键
- 占位 id 回收：legacy_path 已失效的 company_hired 行改为可被 template 就地转正，
  保留行 id 以保外键。此前 seedTemplates 遇占用即 skip，导致污染不可逆：
  lookupSharedAgentMd 恒 null → hire 静默退回全量拷贝 → 模板改动对已雇公司不生效
- 生产库实查：company_hired 0 行（原 10 条悬空全清）、template 45、
  verifyCounts().ok=true、foreign_key_check 空

W2 · 项目根分配（四环闭合）
- ensureProjectRoot 复用 path-resolver.allocateProjectRoot（sandbox 模式）
- 分配 → 进 agent_call 与 planning 两处提示词 + callAgent metadata
  → 落 artifacts/project-root.json（wx 独占）→ readProjectRootRecord 读回
- 子 run 经 createRun 继承 root_run_id，跨层共享同一项目根
- 核实 data/companies/ 在 .gitignore 内，故项目根内的合法写入不会被 W3 守卫误报

W3 · 产出边界守卫（部分，文档如实标注）
- 真 CLI 是子进程直接写盘，引擎拦不住，守卫只能拒收结果、不能回滚
- 7 条「拦不住」的情形逐条列明；文档自述「在 cwd 隔离做掉之前，
  真跑仍应在可丢弃的工作副本里做」

W4 · 修验收 fail-open（性质严重）
- benchmark-validator / testdata-validator 的 Step 表教 agent 写 verdict:"fail"，
  而引擎 FAILING_VERDICTS={attributed,inconclusive} 不含它 → 契约非法的产物
  被判 success 放行。失效方向是放行不是拦截
- org-validator 的审计字段 verdict → audit_verdict：它与 work 层判词写同一路径
  （nodes/<nodeRunId>/attempt-<n>.json），此前只靠「该节点恰好是 subgraph」
  才没被 readNodeProduct 当判词读，属隐患藏在巧合里
- 新增防线 template-verdicts.test.js，从 graph-engine.js 源码取
  FAILING_VERDICTS / ATTRIBUTION_REASONS 扫全部模板；经三次变异验证有效
  （改回 "fail" / 改回 verdict / 造 "ok" 均变红并报精确行号）

真 CLI 冒烟未执行，两条理由（终验 agent 自行判断，符合任务给的门槛）：
① W3 按其自身文档明确「不是沙箱」且要求真跑在可丢弃副本里做，而当前是主仓库、
   持有未提交交付物、且有并行 agent 在写，W3 自述的误判项必然触发；
② 断点已零成本静态证明：getAgentConfig 解析裸名只查 system/agents/、
   从不查 system/templates/，resolveAgentName 不做按需 hire，实测 prd-planning /
   sdd-planning / benchmark-validator / testdata-validator / validator-triager /
   org-validator 全部 throw「Agent not found」。花 $3-8 复现已知断点无意义。
故「做完这四件就能真跑」不成立，真跑挪到 W5/W6 之后。

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

界面走查（真 server + HTTP + 真 AgentManager，底层 mock 协议）已把
manual 模式全流程点通：org 节点起子图 → 下钻 work graph → 单步 →
第 3 步触发回退（徽标 0/3→1/3、run 级 1/5 双层计数同时可见）→
归因记录与 remediation_note 完整送达 → 收敛后父节点结算、左栏前移。

mock 侧补两处缺失接线（都是「四环漏一环」，非新功能）
- ClaudeCliProtocol._sendMockPrompt 按 agent 类型查 fixture：图执行侧的
  agent 名带公司前缀（resolveAgentName 返回 {cid}:{id}），fixture 不该
  按公司复制一份。DevLoop 侧名字不含冒号，行为不变
- graph-engine.defaultAgentExecutor 接住 mock/files 事件：此前只有
  DevLoop 的 loop-controller 接，图执行侧没接，于是 mock 下
  readNodeProduct 永远找不到 attempt-{n}.json，validator 系节点恒 blocked。
  写入限制在节点产物目录内，越界丢弃并留痕

新增 5 份 P3 fixture（workgraph-planning / prd-planning / sdd-planning /
coder-validator / validator-triager），coder-validator 用 sequence 演示
一次回退。图必须放 chunks 不能只放 result——callAgent 的 output 来自
流式 chunks，session/result 的文本不进 output。

控制台入口：CompanyDashboard 加「🕸️ 执行控制台」按钮（路由早已注册，
此前无任何入口，只能手敲 URL）。

scripts/p3-demo-setup.js：手工测试准备脚本（雇人+写图+起 run），头部
写明它是两个已知缺口的绕行，缺口修好后第 1 步即可删。

_registry.json 补齐 6 条本体登记（brd/prd/sdd-planning、goal-benchmark、
benchmark/testdata-validator）——同轮新增的 template-refs 防线测试正是
因为缺这 6 条而变红，防线抓到了「交付与报告不符」。

文档
- 27-REQ R-18：招聘归 workgraph-planning（方案 a）、停用 mock 改真 CLI
- 27-P3B 真实运行前置（新增）：11 个工作项分三批，含现状核实 10 条证据
  （seedTemplates 无运行时调用方、10 条悬空 company_hired 行、
   FAILING_VERDICTS 不含 "fail" 导致验收假放行等）

测试 719/719 全绿（66 文件）。

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

按 docs/README.md 既有约定（done/ 放「已实现/当前有效」），把两份已落地的
阶段设计文档移入 done/system-design/：

- 27-p1-virtual-reference.md  P1 虚拟引用寻址，commit 226489d
- 27-p2-org-graph.md          P2 Org Graph，70a4727 + f20d0d8，真实建公司端到端验证过

用 git mv 保留历史（R098 / R087）。移动断掉的 33 处相对链接已全部修复：
moved 文件内的出向链接改 ../../todo/system-design/，todo/ 下 6 个文件的入向链接
改 ../../done/system-design/。全 docs/ 扫描无断链。

README 此前严重过时——只列了 2 份 27 文档，实际已有 11 份。本次补全 todo/ 表格，
每份标注状态与作用（总纲 / 需求源头 / 命名规范 / 端到端 / 参考场景 /
P3+P4 已实现 / 验收契约 / P4 设计中），并在 done/ 表格补上 P1、P2 两行。

■ 刻意没有移动 27-p3-p4-work-graph-console.md
它虽然已实现（c3abf4a），但文档正被另一进程持续修改（工作区 M 状态）。
移动会打断它的编辑路径，等它收尾后再归档。

■ 三份文件的链接修复留在工作区未提交
27-naming-conventions.md / 27-p3-p4-work-graph-console.md / 27-requirement.md
里，我的链接修复与另一进程的在途编辑混在同一文件中，单独拆分风险大于收益。
工作区内容是正确的（链接已指向新路径），会随它下次提交一并带上。

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

■ 关于编号
原「P4 回退 + Loop-Validator」已并入 P3 实现完毕（c3abf4a：双层熔断、五项结构
校验含 fail-fallback-edge、三层暂停级联、contract_hash 重试判据）。本文档回收
这个空出来的编号，装 P3 明确排除、现在成为最大能力缺口的内容。

■ 核心：fan-out 并行
P3 把图结构和 join 语义都做好了，唯独没做并行本身：
- graph-engine.js:1078 出边评估「所有入边满足才置 ready」——fan-in join 正确
- graph-engine.js:908  拾取 SQL 是 LIMIT 1——三个并行分支只会一个个串行跑掉

设计为 advanceBatch(runId, {maxConcurrency})，不新增第二个推进原语：
手动模式 maxConcurrency=1 时行为与今天的 advanceOne 完全一致，P3 已有调用方
和测试不用改；自动模式一次拾取整批。批量拾取必须在一个事务里一次性置 running，
否则两个并发 advanceBatch 会拾取到重叠集合。

■ 走查发现的关键事实：隔离挂载点已经存在
session-pool.js:29 的 getKey(agentName, agentConfig, workDir, scope) 签名里
早就预留了 scope 参数，但第 45 行实际调用时没传。所以「同一 agent 多实例隔离」
这个并行前置条件的改动量比预想小得多——用 graph_run_nodes.id 作 scope 即可。

连带要放宽 CONVENTIONS §12 第一条不变量：(pid, agent) → (pid, agent, scope)。
这是 P4 里唯一要动 DevLoop 规格的地方，且 _spec/ 是生成物，必须改 HTML 后跑
npm run spec:extract。该放宽同时是 P6 的前置——DevLoop runProject 波内串行
（loop-controller.js:609 注释「串行跑」）正是被同一条不变量挡住的。

■ 产物统一目录 + files.json
这是此前提出但一直未实现的需求。按 task 分目录
data/companies/{cid}/tasks/{taskId}/，根目录 files.json 作统一检索索引，
由引擎在产物落盘后自动追加（不靠 agent 自觉写，否则索引必然漂移），
并支持从 graph_run_nodes 行 rebuild。与 output_ref 不重复：后者是节点级指针，
前者是公司级聚合视图，由前者派生。

■ 三个阶段，C 完全独立
A 隔离(T1-T2) → B 并行(T3-T6,T10)；C 产物索引(T7-T9) 与 A/B 无依赖，可最先做。

并发上限对齐 plan-cost-concurrency.md §④ 的既有数字（run≤5 / 公司≤3 /
单机≤20 session），不另立一套。

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

命名轴是「节点在哪一层图里」，把散落的老 agent 归到它实际所处的层级：

  innovator → org-innovator      type='cxo'，是 org graph 层的节点
  hunter    → innovator-hunt     innovator work graph 第 1 阶段
  digester  → innovator-digest   第 2 阶段（输入是 hunt 产出）
  evolver   → innovator-evolver  第 3 阶段

依据：retrain-pipeline.js 的 stepConfigs 就是按 hunter → digester → evolver 顺序
跑的，行 231 明写 steps: ['re_hunt','re_digest','evolve'] —— 这三个本来就是
innovator 的 work graph 三阶段，只是名字没体现出来。

■ 迁移（scripts/migrate-agent-naming.js，--dry-run + 幂等可重跑）
- 8 个目录（system/agents/ + system/templates/），用 git mv 保留历史
- system_agents 表 4 行的 id 与 legacy_path
- 公司实例目录与 company.json.agents[]（本次无公司雇过这四个，实际 0 条）

■ 代码引用点（5 处，手工改）
- retrain-pipeline.js: stepConfigs 的 agent 字段 ×3、agentToStep 映射的 key ×3、
  call_sub_agent 的 evolver 判断
- agent-chat.js: agent 列表过滤里的 innovator
- company.js: 模板训练触发的 agentId

■ 刻意不动的三类同形异义（改了会坏）
1. skill 内部子目录名 {skillDir}/hunter/knowhow.md —— 那是 hunt/digest/evolve
   三阶段的产物目录约定，与 agent 名同形但不同义。涉及 open-api.js:402、
   retrain-pipeline.js:148/374、evolution-loop.js:178、sync-skills.js 的 INTERNAL_DIRS
2. skill 命名空间白名单 —— skill-dir-manager.js 的 CORE_SKILLS、
   migrate-trained-skills.js 的 SYSTEM_SKILLS，那里的 'innovator' 指同名 skill
3. conversations/ 与 system/tasklog/ 下的历史记录 —— 运行态数据，不改写历史

evolver-youtube-crawler 按 §3.4 列为待定，迁移脚本按精确目录名匹配，未误伤。

这四个重命名顺带解决了 27 号文档 §七 挂了很久的 6 个命名冲突 id —— 重命名后
system/agents/ 与 system/templates/ 下不再有同名目录（只剩 agent-creator 与
evolver-youtube-crawler 两个，前者是基础设施角色按规则不改名）。

验证：npm run test:unit 693 全绿（64 files）；test-company-e2e 114/114；
迁移脚本二次执行 dirs=0 dbRows=0 skipped=8（幂等）。

未触碰另一进程正在进行的 P3 文件（graph-engine.js / graph-run-sse.js /
work-graph-db.js / 27-p3-p4-work-graph-console.md / 27-requirement.md）。

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

按 27-p3-p4-work-graph-console.md v0.3 实现，三轮开发+校验后测试全绿
（693/693，P2 26/26、DevLoop 230/230 未被打破，web:build 干净）。

服务层
- work-graph-db.js  定义层(work_graph_*) + 运行时层(graph_runs/graph_run_nodes/
  graph_run_loop_records) 五张表；状态转换表照 unit-registry 模式；
  复用 org-graph-service 四项校验 + 新增第五项 fail-fallback-edge
- graph-engine.js   advanceOne 幂等原语；agent_call / subgraph 两种 executor；
  手动与自动共用同一原语；双层熔断（单边 loop_count + 按 root_run_id 共池的
  backward_count）；任务级预算挂 root run；三层暂停/停止级联；
  重试按 contract_hash unchanged 判据
- graph-run-sse.js  按 run_id 广播，状态转换+timeline+SSE 三者原子化
- goal-contract.js  验收契约格式与执行器（R-15.6 验收先行）

引擎泛化（R-15.4）：org graph 与 work graph 走同一套 advanceOne，
定义层两套、运行时层一套，三层下钻用 parent_run_id 链。

R-16 失败归因：validator-reflection 专职归因节点；fail_reason 多边路由
（精确匹配→兜底边→死路）；子 run 收敛透传 success/fail + fail_reason +
remediation_note 三值；infra_flake 不烧任何计数。

路由 / 前端 / 模板
- routes/graph-run.js 八个端点；company.js 任务入口
- WorkGraphCanvas.vue 扩展 UnitsDAG（subgraph 角标、backward 虚线曲线、
  N/3 循环徽标、异常流程视觉降权）；GraphConsole.vue 三栏 + 四 tab 详情
- 五个新 agent 模板：validator-reflection / org-validator / planner-validator /
  coder-validator / workgraph-planning

命名统一（R-15.3 + NAMING §三）：org 节点改为 org-{职能}，
三个 org-graph 模板末节点收敛到 org-validator；org_graph_edges 加 fail_reason
列并把唯一索引补上该列（避免精确边与兜底边互相吞掉）。

三轮校验修掉的主要缺陷：subgraph 重跑不起新子 run 导致永久死锁；
SSE/timeline 零调用方；org 侧 fail_reason 写入被丢弃；fail-fallback-edge
只做了一层；backward_count 跨 run 树重置架空熔断外层；
seedEntryNodes 误点亮只有 fail 入边的节点。

已知缺口见后续提交：remediation_note 仅在 backward 边落库、
total_tokens 预算维度无生产方。

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

命名轴从「业务领域」({domain}-{职能}) 改为「所在图的层级」：
  org graph 节点   org-{职能}              org-planner / org-coder / org-validator
  work graph 节点  {父 org 节点全名}-{职能}  org-coder-validator

三个模板因此首尾同名，只有中段职能不同——规划和验收本身不分领域：
  dev      org-planner → org-coder   → org-validator
  content  org-planner → org-writer  → org-validator
  ops      org-planner → org-monitor → org-validator

■ NAMING §三 补上此前完全缺失的一条轴：节点名 ≠ 本体名
R-15.3 指出的关键区分。禁止裸用 validator 的理由是「一家公司内两个节点不能
重名」，该理由针对节点、不针对本体。本体若被迫带前缀，coder-validator 会复制成
org-coder-validator / content-coder-validator 多份，与 P1「同一份本体、多处引用、
各自私有语境」直接冲突。落到 schema 上就是 node_name / system_agent_id 两个字段。

同时写入 §3.3（三个 validator 是三个独立本体，验的东西本质不同，与 §八bis
「不特化」原则不冲突）与 §3.4（存量 agent 归位：innovator→org-innovator、
hunter→innovator-hunt、digester→innovator-digest、evolver→innovator-evolver，
依据是 retrain-pipeline.js 里三者就是 innovator work graph 的三阶段）。
§3.4 顺带解决 27 号文档 §七 挂了很久的 6 个命名冲突 id。

■ 代码层已改
system/org-graph-templates/{dev,content,ops}.json + README、
system/templates/orggraph-planning/{agent.md,tools.md}

■ 代码层未改（已在 §3.4 末尾标注）
§3.4 的四个存量 agent 重命名需要单独一次迁移（目录改名 + system_agents 表 +
retrain-pipeline.js 等引用点），本次未做。

验证：三张模板图改名后实跑 validateGraph 仍全部通过四项校验；
npm run test:unit 676 全绿；test-company-e2e 114/114。

未触碰 27-p3-p4-work-graph-console.md（另一进程正在做 P3 开发，且其中命名已符合
R-15.3）与 27-requirement.md（原文照搬文档）。

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

R-16（归因由专职 subagent 做，回退边多条）：
- §四.D.2.2 归因改为 org-validator work graph 内的 validator-reflection
  专职节点，与 DevLoop 的 Integrator/BugTriager 分工同构；给出四类
  fail_reason 取值与 DevLoop 四分类的对照
- §四.D.0 子 run 收敛改为透传三值（success/fail + fail_reason +
  remediation_note），归因结论才能穿透子 run 边界供父层选边
- §四.D.2.1 熔断改为双层计数：单边 loop_count 防同路径死循环，新增
  run 级 backward_count 防"换个借口继续退"——多条回退边各自计数会把
  硬顶架空成 3xN；infra_flake 不烧任何计数
- §三.7 写入前校验新增第五项 fail-fallback-edge（强制兜底边）
- schema：graph_runs 加 backward_count
- 任务表加 T13/T14，验收标准加 9b/9c/9d
- skill_defect 属 L4，v1 保留归因取值但动作降级为挂起等人工

base agent 四段式（新增 §九bis）：
- 核实后原表述"已强制一套四段式生命周期"只对一半
- Context Flush / P0 事前阻断阀 / OKR 联动确实在跑
- Hot Swap 换技能包静默失效：system/skills/ 目录不存在，
  agent-chat.js:1908 的 existsSync 守卫使其空转且不报错
- 后果：EXECUTE 才拿破坏性权限只剩 prompt 话术约束，无机制保障
- phase 参数无取值/顺序校验，且被直接拼进文件路径

需求文档：补回 R-15.1 全文、R-15.4 后半、R-15.5、R-15.6 及速查表
对应行（此前被误回滚丢失），新增 R-16 条目。R-15.3 的命名表保留
NAMING §三 重写后的版本，未还原旧版。

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

- §八.1 单一入口：R-13.4 已定案，标记关闭，保留放宽条件的论证供将来参考
- §八.3 建公司耗时：实测约 30 秒（非几十秒到几分钟的估计）；补充说明前端
  空态未真正区分「规划中」与「确实无图」，是刻意简化
- §八.5 前端画布：已按占位形态交付，不阻塞 P2

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

11 个任务（T0-T9 含 T5b）此前只有一句话的顺序说明，没有阶段概念。按依赖收敛为：
- A 数据层（T1→T2→T3、T7、T9）：纯后端不起 LLM，可手工建图/校验/读
- B 自动生成（T4→T5→T5b→T6）：引入 orggraph-planning，建公司自动出图
- C 展示（T8）：Dashboard 渲染，还依赖 P3 画布组件

每阶段给出可验收标准，且阶段间可停——A→B 即可看到端到端效果，C 可后延。
T0（company-goal）已于 2255f09 实现，是 B 的前置，不计入阶段。

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

company-goal / task-goal 按作用域命名，subagent-goal 按执行者命名，轴不一致。
统一为 subtask-goal。

27-REQ R-13.1 的原话引用保留提出时的用词「subagent-goal」不改写——原文照搬
文档不参与批量替换（这是上一轮误改 R-10 原话引用留下的规矩）。新增 R-14 记录
本次定名及其与 R-13.1 的关系。

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

起因：逐条比对 27-REQ 的原话与 P2 v0.4，发现四处偏离，其中两处是设计悄悄
改变了原意。本次修正并落定。

代码（P2 §五 T0）：
- company.json 新增 goal 字段（company-goal），create({id,name,goal,description})
- POST /api/company/create 与 update() 同步支持
- 修的是一个实打实的遗漏：R-6 原话是"写入 company 的目标和描述"（两个字段），
  而 create() 一直只有 description。orggraph-planning 规划流水线的主依据本该是
  company-goal，此前根本拿不到。

文档定案（R-13）：
- R-13.1 goal 三层递归：company-goal / task-goal / subagent-goal，与"验收逐层
  递归"对应。澄清 R-12 说的"唯一的那个 goal"其实是 task-goal；三个验收 agent
  保持通用不按层级拆分。记录一处待定：subagent-goal 按执行者命名，与另两个的
  作用域命名轴不一致（按轴应为 subtask-goal）。
- R-13.2 公司类型完全由 orggraph-planning 推断 —— 这条**推翻了我自己记的一个
  缺陷**：审计时我把"不加 type 枚举字段"记为擅自偏离原话，实际那正是所需，
  当前设计无需改动。
- R-13.3 新 agent 从 system/templates/base 元 agent 继承骨架（自动带四段式
  RESEARCH→PLAN→EXECUTE→VERIFY）+ agent-creator 填充，而非直接走 needs_training
  全量培养；新建一律 scope='company'；innovator 训练是可选后置步骤。
  这是 R-9.2"所有 node agent 由元 agent 继承生成"在 P2 的落地点（新增 T5b）。
- R-13.4 org graph 强制单入口，原 open question 关闭。

顺带修掉 P2 的一处内部不一致：§六 承诺"提供手动触发 orggraph-planning 的端点"
给存量公司补图，但 §四.3 API 表和 §五 任务表都没有。已补 POST …/org-graph/replan。

另更正 R-11 中"代码层未执行"的过期表述——OKR 正名已于 74ea1ff 实施完毕。

回归：npm run test:unit 652 例全绿。

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

代码层：
- server/services/goals.js → okr-service.js；GoalsService → OkrService
  · this.goalsDir → okrDir，目录 goals/ → okr/
  · ID 前缀 G- → O-；落盘文件 goal.json → objective.json
  · updateGoal → updateObjective，_nextGoalId/_saveGoal 等同步改名
  · parseNodeId 层级名 ['Goal','Objective','KeyResult','SubTask']
    → ['Objective','KeyResult','SubTask','SubTask']（OKR 无 Goal 这一层）
- server/routes/goals.js → okr.js；:goalId → :objectiveId
- 7 处调用点同步：index.js / agent-server.js / agent-chat.js / company.js /
  company-heartbeat-service.js / prompt-builder.js / test-company-e2e.js
- 前端 OkrDashboard.vue / CompanyDashboard.vue 切到 /api/okr（前后端命名终于一致）
- bin/lemon.js 新增 okr create/add-node/list/status

向后兼容（不破坏任何现有调用方）：
- /api/goals/* 与 /api/company/:cid/goals/* 全部保留为别名，与新路径同时挂载
- task dispatch/report 同时接受 objectiveId(新) 与 goalId(旧)，写入时两字段都留
- bin/lemon.js 保留 goal * 命令别名

迁移脚本 scripts/migrate-goals-to-okr.js（npm run okr:migrate）：
- 目录 data/{,companies/*/}goals/ → okr/；条目 G-xxx → O-xxx
- 改写 objective.json 的 id / nodes 的 key / children 数组、_index.json、
  progress.json 的 goalId、history.log 文本、system/tasklog/*.json 的 goalId+nodeId
- --dry-run 预演；幂等；迁移前自动备份为 *.bak-goals（已加入 .gitignore）
- 处理一个反直觉边界：OkrService 构造函数会自动 mkdir 目标目录，"okr/ 已存在"
  不等于"已迁移过"——只要服务被 require 过一次就留下空壳。用 isEmptyOkrDir()
  区分空壳与真实数据，空壳移除后继续迁移。这个 bug 是在 fixture 上验证时发现的。
- 同样在 fixture 上发现并修掉：nodeId 的值漏改写、tasklog 迁移不幂等

验证：新增 server/tests/unit/okr-service.test.js（7 例，覆盖新命名工作正常 +
迁移纯函数的 ID 改写）；全量 npm run test:unit 652 例全绿。

范围说明：NAMING §五 的 benchmark 三分（skill-/agent-/goal-）本轮未动代码——
该节自身的建议就是存量保持现状、只对新增代码强制前缀，因为 benchmark_runs 等表
服务于线上 Arena 排行榜，改表名/路由是另一次独立迁移。
§二-四 的新 agent id 尚不存在实体，待 P2/P3 实现时按规范创建。

已知遗留（非本次引入）：server/scripts/test-company-e2e.js 早已失效——它按
data/{id}/ 找公司，而 company-service 用的是 data/companies/{id}/，在 HEAD 版本
同样全部断言失败。本次只同步了其中的 OKR 命名，未修这个路径问题。

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

改名：task-benchmark / task-test-data / task-test-script
   → goal-benchmark / goal-test-data / goal-test-script

理由（推翻此前"验收标准跟着一次 task 执行走"的论证）：关键区分是基数。
一个人类需求描述 = 1 个 goal，是验收的边界；而 goal 在图中会分解出 N 个 task
（并行分支、下钻的 sub agent）。验收回答的是"人类想要的东西做到了没有"，
这是 goal 级判定；挂在 task 上会导致"以哪个 task 的验收为准"无法回答。

NAMING §一 作用域表补入 goal / task 两行及其基数定义；§四 重写选型理由；
§六 增加与 §四 的辨析注（OKR 从 goal 解放后，goal 被重新赋予"人类需求"新义）。

连带：
- acceptance.json 的键改为 goal_id
- work_graphs schema 补 goal_id，与 okr_node_id / task_id 并列（三者基数不同，
  分别是 1 / 长周期归属 / N，不能用单一字段表达）
- 新增 27-REQ R-12 记录本次决策及其推翻关系

修复上一轮的一处失误：全局改名误改了 27-REQ 中的原话引用（R-10 一度被改成
"goal-benchmark 或者 goal-benchmark"）。原文照搬文档不得被批量替换触及，已还原。

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

此前 27 系列全部是对用户需求的转述与结构化解读，原话一句都没留存
（搜 "judge-loop-jump"、"元 agent 架构来继承生成" 等关键短语均 0 命中）。
转述会漂移，出现"当初到底怎么说的"争议时缺少可回溯的依据。

格式与定位对齐仓库既有惯例 docs/prd/newfunction/_spec/requirement.md
（DevLoop 的原始需求页："用户提出的需求原话照搬，再做结构化解析"）。

内容：11 条需求原话逐条照搬（R-1..R-11），含笔误一律保留
（validtor / syste agent / intergration / fin in / object-key result），
每条标注落在哪份文档的哪一节，附"需求 → 设计落点"速查表。

同时记录三处关键推翻关系，便于回溯设计演变：
- R-7 推翻了"benchmark/test data 是系统基础设施"的误读
- R-9.1 推翻了 P2 v0.1-v0.3 的静态汇报结构建模及 A/B/C 三个折中方案
- R-9.4 使跨公司污染风险及其三个缓解方案全部作废

另澄清 27-EXAMPLE 的「配图工厂」是为走查虚构的场景，非用户原始需求。

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

新增四份文档：

- 27-e2e-task-execution-flow.md — 跨阶段总览：建公司 → 下达任务 → org graph
  逐节点执行 → work graph 规划与循环 → 验收收敛。核心发现：这套流程 70-80%
  已在 docs/prd/newfunction/_spec/ 里被完整设计（DevLoop 的 L1/L2/L3 三层循环、
  BugTriager 四分类归因、分级预算熔断、contract_hash 闸门），DevLoop 实为本
  架构唯一跑通的参考实现，通用引擎应从它抽象而来。
- 27-example-dev-company-walkthrough.md — 参考场景走查，把架构在一家具体公司
  上跑一遍数（各阶段 JSON 形态、fan-out/fan-in 图、成本估算 ~44 次调用、
  按阻塞程度排序的 8 个断点清单），作为实现靶子与端到端验收场景。
- 27-naming-conventions.md — 统一命名规范 {作用域}-{职能}。消歧三种 benchmark
  （skill- / agent- / task-）；OKR 体系正名（goal → okr，第 1 层 Goal → Objective）；
  规划类统一为 orggraph-planning / workgraph-planning / brd-prd-sdd-planning。
- 27-p3-p4-work-graph-console.md — P3/P4 合并设计：Work Graph 执行引擎（支持
  启动/下一步/暂停/停止/重试，手动与自动共用同一 advance 原语）+ 执行控制台页面。

重写 27-p2-org-graph.md 至 v0.4：Org Graph 从「静态汇报结构」重定位为
「company 级别生成的 workflow」，与 Work Graph 同构（condition/edge_kind 执行流边），
两层共用同一套 schema、执行引擎与画布组件。org_graph_edges 从未写入过数据，
可直接 DROP 重建，零迁移负担；hire() 不再需要 reportsTo（图整体规划整体写入），
P2 对 company-service.js 的侵入缩至零。

同步修正总纲至 v0.3：Org Graph/Work Graph 术语定义、§3.1 架构图、§3.3 整节；
标注 P1 已实现（226489d）；P6「DevLoop 收编」从「可选」改为「应前置」。

修正三处过期陈述：P1 已实现（非设计稿）、runProject 已完整实现（非 501）、
UnitsDAG.vue 已实现 Kahn 分波 DAG 渲染（画布应扩展而非重写）。
并记录一处待处理冲突：graph-service.js:44 已落地的全量唯一索引与 P2 需要的
部分唯一索引冲突，实现 T1 时必须先 DROP。

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

- New docs/README.md indexes the tree: done/ (shipped features + reference manuals),
  todo/ (current focus — Graph Agent architecture), todo/future/ (deprioritized
  roadmaps: FDE pipeline todo list, stale v1.1 milestones, harness engineering
  proposal — orthogonal to the Graph Agent work, not blocking it)
- Move completed/reference docs into docs/done/ (LEMONBOSS-SYSTEM-DESIGN, architecture-v5,
  claude-code-cron, open-api-manual, qa_judge_req, task_timeline_design, user-guides/,
  system-design/01-26 minus the three moved to todo/future/) — verified against actual
  code (qa-judge template, Task Timeline route/service/view) before filing as done
- Fix the two TOC links in LEMONBOSS-SYSTEM-DESIGN.md that would otherwise point at the
  old paths after the move
- docs/todo/system-design/27-graph-agent-architecture.md: add the P2 Org Graph doc link
  in the roadmap table and 关联文档 section
- Add docs/todo/system-design/27-p2-org-graph.md (P2 requirements & design, drafted in
  parallel while P0/P1 landed)

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

hire() now checks system_agents (source_kind='template') before provisioning a new
company agent: if the role has a shared template row, skip copying agent.md and
instead let AgentManager.getAgentConfig()/PromptBuilder.build() resolve the prompt
from the shared legacy_path at call time, with per-company context assembled from a
new company-context.md. Roles without a template row (including the 6 ids that exist
in both system/agents/ and system/templates/, e.g. evolver-youtube-crawler) fall back
to the existing full-copy behavior unchanged.

- server/services/graph-service.js (new): lookupSharedAgentMd(), upsertOrgGraphNode()
- server/services/company-service.js: hire() reference-mode branch, _provisionReferenceAgent()
- server/src/core/agent-manager.js: getAgentConfig() resolves prompt/companyContextPath
- server/src/core/prompt-builder.js: build() concatenates company-context.md
- unit + integration tests covering all 6 acceptance criteria from
  docs/todo/system-design/27-p1-virtual-reference.md §6, including a regression test
  against the real idearun:evolver-youtube-crawler naming-collision case

Full regression suite (587 tests) passes; independent adversarial review found 0
blocking/major issues.

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

Adds server/services/graph-db.js (new data/graph.sqlite: system_agents,
org_graph_nodes, org_graph_edges) and graph-seed-service.js, which scans
system/agents/, system/templates/, and data/companies/*/company.json into
seed rows without touching company-service.js's existing hire/copy path.

Real repo data diverged from the design doc's original estimates (8 not 10
global agents; 39 not 34 template dirs; system/agents/ and system/templates/
turn out to share 6 ids describing the "same" agent from two different
files) — documented in docs/todo/system-design/27-graph-agent-architecture.md
section 7 for P1/P2 to resolve.

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