宜博 / lemonboss

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>

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