宜博 / lemonboss

## 批 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>

队列与调度（§五.1）：
- 下达任务不再因「公司已有 active root run」吃 409，改为建 queued run + queued task
  排队；出队走 updateRunStatus 的 CAS + BEGIN IMMEDIATE 准入事务，触发挂在
  transitionRun 这个唯一漏斗上，60s sweep 兜底。
- 依赖已不可能满足的排队任务就地推导成 blocked，且每次 tick 重算不落死，上游重跑
  成功后能原路解开。

恢复路径（批 3 复核 F1/F2）：三条恢复转换的 from 全在活跃集之外，撞坑满时退回队列而不是
永远躺在 blocked；退不回去的裸 run 干净拒绝，不留半截状态。

控制台三处可见性修复 —— 症状全是纯视觉、不报错、git status 干净：
1. 顶栏墙钟恒 `now - started_at`，没有终点。一条昨晚就 blocked 的 run 第二天还在涨到
   「16h 58min」，而那是页面上唯一的时间信号 —— 「已经停了等人处置」被显示成了
   「还在跑再等等」，这两件事需要的动作相反。终点改取 run.updated_at，并标「已停」。
2. 越界日志只报「留下 N 处改动」，文件清单躺在 timeline.ndjson 里翻不到。判罚就是按
   这份清单下的，而人要判断「这真是 agent 写的吗」唯一的依据就是路径（并行的开发会话
   改宿主仓库会被算到当时在跑的节点头上，那是误判，看一眼就知道）。改为列出 entries。
3. run 收敛成 blocked 时只把 task 写成 blocked、不写原因，任务列表那一行只剩一个橙色
   的「挂起」，必须逐层点进 org 图 → work 图 → 节点详情才知道发生了什么。改为把
   「卡在哪个节点 + 什么 fail_reason + 判词摘要」写进 tasks.blocked_reason。
   原因绝不带 UPSTREAM_BLOCK_PREFIX —— 带了会被调度器当成依赖推导出的 blocked 自动
   推回 queued，而这类 blocked 本来就等着人处置（守卫在 task-blocked-reason.test.js）。

测试：126 文件 / 1201 用例全绿。

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>

把「人类提的一个需求」与「机器执行的一件活」拆成两级。这不是新概念：
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>

28 号把本体根从 system/templates/ 搬到 system/agents/，agent-locator 就是
为了当这个路径的唯一持有者而建的。但搬完之后仓库里仍有 13 处自己拼这个路径，
等于 locator 只是多了一份副本、没有真正收敛：

  server/routes/company.js            9 处（6 个 TEMPLATES_DIR + 3 个 DATA_DIR，
                                          同一文件里只有 1 处用了 locator）
  server/services/task-service.js     1 处
  server/src/core/skill-config-loader.js  1 处
  server/src/core/devloop/loop-controller.js  1 处
  scripts/extract-agent-prompts.js    1 处

危害不是「不好看」，而是下一次再搬时改 12 处、漏 1 处：漏掉的那处指向一个
不存在的目录，而本仓库读这类路径几乎都包在 fs.existsSync() 守卫里 ——
目录没了不报错，只是静默跳过。这个形状刚在 scripts/demo-harness-company.js
上实测过（base 本体没挂上，demo 跑出来的 agent 没有四段式骨架，脚本照常打印成功）。

局部变量名保留不动（TEMPLATES_DIR / DATA_DIR / SYSTEM_AGENTS_DIR / agentsRoot /
OUT_DIR），只把取值改成 locator.AGENTS_ROOT —— 名字是局部别名，无害；
「路径这个事实」则收敛成一处，下次再搬只改 agent-locator.js。

新增 server/tests/unit/agents-root-single-holder.test.js 锁住这条不变式：
扫 server/ packages/ scripts/ 下所有源码，禁止 path.resolve/join 自己拼
「以 ../ 开头、以 system/agents 结尾」的字面量。带「样本非空」前置断言，
防止扫描路径写错时退化成永远通过。改坏一处实测能精确点名到文件行号。

线索来自并行会话（它在准备改 company.js 时发现同一文件里 7 份定义）。
实际比它看到的更多：它只查了 TEMPLATES_DIR，同文件另有 3 个 DATA_DIR、
另外 3 个文件各 1 处。

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>

## 为什么加

「输入输出」tab 把产物的绝对路径摆出来了，但那是服务器本地路径 —— 浏览器里点不开，
走查时只能靠肉眼确认「路径长得对」，而真正要确认的是「这份 brd.md 里写了什么、
下游读到的是不是它」。

## 前端

新增 web/src/components/graph-console/FilePreviewModal.vue，输入/输出两处路径
改成可点按钮。渲染三档：.md 走 marked（已是既有依赖，没新增包）、.json 重新缩进、
其它原文。两处刻意的选择：
- .json 解析失败时**退回原文**并说明，不替它藏起来 —— 产物 json 写坏了本身就是要看的信息
- 超过 512KB 时后端回 truncated，界面如实说「不是完整内容」，不装作读全了
output_ref 那一行不做成可点：它是目录不是文件。

后端没有新造端点：复用现成的 GET /api/company/:cid/files/content，它的根目录正是
data/companies/<cid>，而 graph_files.rel_path 本来就是相对公司根的，正好对上。

## 修掉六处路径越界（真漏洞）

company.js 里 3 个 GET + 3 个 PUT（templates / company / workspace）用的是同一个写法：
    if (!absPath.startsWith(safeBoundary)) → 403
「一个目录名是另一个的前缀」时它会放行：
    cid = co-a，path = ../co-a-evil/company.json
    → abs = .../data/companies/co-a-evil/company.json
    → startsWith('.../data/companies/co-a') === true → 放行
于是公司 co-a 能读 co-a-evil 的文件；PUT 那三处是同一缝隙上的跨公司**写**。
抽 resolveInside() 用 path.relative 判断，六处共用一份（复制六份判据迟早会漂）。
新增 7 条用例走真 HTTP 验，PUT 那条断言的是**文件没被改**而不只是响应码。

## 顺带修掉一个被你的实际使用触发的 bug

跑全套时 graph-seed-service 的对账用例红了，报
`org_graph_nodes WHERE company_id='mycompany' expected 10 / actual 9`。
不是并发偶发 —— 单跑也红。原因：seedCompanyAgents 对 type='meta-bootstrap' 的角色
是 continue（既不落 org_graph_nodes 也不落 system_agents），而 verifyCounts
复算期望值时把 agents[] 全算进去。mycompany 的 10 个角色里 orggraph-planning
正是 meta-bootstrap → 差 1。

也就是说：**界面上点一遍新建公司就会踩到**。这条缺陷上一轮就被预告过
（当时那个 agent 说「不在我的独占文件里」没修），今天被真实使用兑现了。
修法是让 verifyCounts 复用同一个 isMetaBootstrap 判据，不复制那个 type 判断。
新增独立测试文件（不并进 graph-seed-service.test.js —— 往它的 hermetic 夹具里
加角色会连带改既有断言），用 GRAPH_SEED_ROOT 自建最小夹具。

那个文件里第二条用例是刻意的：只断言「对账干净」时，seed 一个都没种也会“通过”，
两种原因症状相同。第一版就是这么错的 —— 我误以为 runStartupSeed 会种公司角色
（它只做 reconcile + 全局 agent + 模板），是第二条断言把「夹具没种」和
「过滤没生效」分开的。

## 验证

871 全绿（87 文件）。3 处变异精确变红后逐字还原
（startsWith 回退 → 精确打红跨公司读/写两条；verifyCounts 去掉过滤 → 打红对账条）。
拿运行中的实例 + 用户真实公司 mycompany 走查过：读到真实 brd.md 内容，
`../idearun/company.json` 与 `/etc/hosts` 均 403。web:build 通过。

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>

真实建公司验证时发现的两个串联问题——只有起真服务才暴露得出来，
工作流的集成 agent 全程没起过服务，测试也覆盖不到。

1. 地址错误：orggraph-planning 是被 hire 进公司的，住在
   data/companies/{id}/agents/ 下，寻址必须是 `{companyId}:orggraph-planning`。
   原代码请求裸名 /api/agent/orggraph-planning/chat → 404 Agent not found，
   agent 从未被触发，公司永远停在空壳状态。

2. 失败被静默吞掉：fetch 只在网络层出错时 reject，4xx/5xx 不会 reject，
   所以原来的 .catch() 从头到尾没打印过任何东西。补 res.ok 检查 + 成功日志，
   这类"地址写错"的问题以后能第一时间看见。

修复后端到端验证通过（临时公司 p2-verify，验证完已清理）：
- POST /create → company.goal 落盘、orggraph-planning 被招聘且因 meta-bootstrap
  被正确排除在 org graph 外
- 日志出现 "✅ 已触发 p2-verify:orggraph-planning" + ACP 会话创建
- 30 秒内 agent 产出 4 节点 5 边的图并完成 4 个角色招聘
- agent 选中 dev.json 且**扩充**出模板没有的 code-tester（goal 要求带单测），
  并在规划记录里明确排除了 content.json 的歧义（"Markdown/HTML 是被处理的
  数据格式，不是要产出的内容作品"）——模板作为"起点集合"的设计意图成立
- 产出的图实跑 validateGraph 通过四项校验
- 四个角色 config.json 均为 inheritedFrom=base（元 agent 继承路径生效），
  system_agents 里 scope='company' + owner_company_id 正确
- orggraph-planning 收尾后 heartbeat.enabled=false，正确休眠

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

用 9 个并行 agent 按「文件独占」划分实现 P2 的 T1-T9（T0 已于 2255f09 完成）。
详见 docs/todo/system-design/27-p2-org-graph.md §五。

阶段 A · 数据层
- graph-db.js: org_graph_nodes 加 status/reports_to_node_id（PRAGMA 探测后 ALTER，
  幂等）；全量唯一索引换成 WHERE status='active' 的部分索引，使「fire 后重新 hire
  同角色」可行；org_graph_edges 重建为执行流边（condition/edge_kind/status）
- graph-service.js: ensureOrgGraphNodeIndex 同步改建部分索引，且 upsertOrgGraphNode
  的 ON CONFLICT 必须写成 ON CONFLICT(company_id, role_name) WHERE status='active'
  —— SQLite 的冲突目标要与部分索引谓词逐字对应，否则整条 INSERT 直接失效
- org-graph-service.js（新）: validateGraph 四项校验 + writeGraph/patchGraph/
  getGraph/removeNode，事务化，节点软删除级联失效相关边
- routes/company.js: 四个端点 POST/PATCH/GET /org-graph + POST /org-graph/replan；
  /create 接入自动招聘 orggraph-planning + 异步触发（失败降级为空壳公司）；
  /fire 接入节点软删除

阶段 B · 自动生成
- system/org-graph-templates/{dev,content,ops}.json + README：三张三段式骨架
  （规划→执行→验收，验收失败回退到执行节点），角色名遵循 {domain}-{职能}
- system/templates/orggraph-planning/：新 system agent（type='meta-bootstrap'），
  含 §4.1 八步工作流
- company-service.js: 模板不存在时从 system/templates/base/ 元 agent 继承骨架
  （自动带 RESEARCH→PLAN→EXECUTE→VERIFY 四段式）+ agent-creator 填充，
  新建 agent scope='company'。这是 27-E2E §八bis 元 agent 继承的落地点

阶段 C · 展示
- CompanyDashboard.vue: 组织流程拓扑链渲染 + 空态降级 + 环深度保护

并行编排中发现并修复的三处（均不在原任务划分内）：
- AppNav.vue 建公司表单缺 goal 输入框 —— T0 只改了后端，前端表单没同步，
  company-goal 实际传不进来。这是上一轮 T0 的遗漏
- graph-seed-service.js 会把 type='meta-bootstrap' 的 orggraph-planning 塞回
  org graph，与 hire() 的 guard 不一致
- graph-agent-p1-acceptance.test.js: hire 未知角色的返回从 needs_training 改为
  hired_from_base（T5b 的行为变更），断言同步

验证（独立复核，非 agent 自述）：
- npm run test:unit 676 passed / 63 files（基线 652，+24 为新增的 org-graph 用例）
- npm run web:build 通过
- 三个模板 JSON 实跑 validateGraph 全部通过；四类非法图各自被对应 rule 拒绝；
  writeGraph→getGraph→removeNode 级联验证通过（删中间节点后 3 条边全部失效）

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>

四处写 _registry.json 的地方都用 JSON.stringify(registry, null, 2) 直接落盘，
不带末尾换行。文件在仓库里是带换行的，导致任何一次 hire()/depositTemplate()/
模板增删改之后，git diff 都会多出一行 "\ No newline at end of file" 的噪音，
把真实的数据变更淹掉。

写入点：
- company-service.js:374  depositTemplate()
- company-service.js:824  _updateTemplateUsedCount()
- routes/company.js:86    PATCH /templates/:templateId
- routes/company.js:120   DELETE /templates/:templateId

同时提交一次真实的运行时数据变更：qa-judge usedCount 7 → 8。

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

1. Workspace page: left file tree + right detail/editor panel
   - File info: name, path, size, created/modified timestamps
   - Three view modes: Code / Preview / Edit with save
   - HTML files auto-open in Preview tab (sandboxed iframe)

2. Backend APIs:
   - GET/PUT /:companyId/workspace/files (list + content + save)
   - PUT /:companyId/files/content (company file save)

3. Navbar: removed Skills/Jobs/Pipeline, added Workspace
4. All nav links open in new tabs (target=_blank)

- Added inline editing for template description and type fields
- Implemented Delete Template functionality (removes both file system and registry entry)
- Added confirmation safeguards for the destructive delete action

Architecture fix for long-running tool execution:

1. ClaudeCliProtocol: Two-tier idle timeout
   - Chat mode: 45s (detect API hang/silent rate limit)
   - Tool execution mode: 5min (Bash long tasks like pip install)
   - Automatically switches on tool_use_start / content_block_stop events

2. Provision API: POST /templates/:templateId/provision
   - Runs shell commands directly via child_process.exec
   - Bypasses Claude ACP entirely (no idle timeout issue)
   - 10min per-command timeout, security blocklist
   - Frontend button with prompt for custom commands

3. Template UI: Added 🔧 安装依赖 button (teal)

- Moved data/system/ → system/ (agents, templates, skills, data, workspace)
- Updated all server route/service path references
- Updated all script path references
- Updated all documentation references
- Restructured .gitignore for cleaner system/ vs data/ boundary

system/ = platform-shared assets (system agents, template library)
data/ = tenant-specific company instance data

…aruncreate skill paths

- Upload skill files to .claude/skills/ (Claude Code ACP reads from here)
- Add conversation type filter (user/callback/task/train) to AgentChat
- Parse messages.log for richer conversation history display
- Fix idearuncreate template & company agent skill directory structure
- Add adm-zip dependency for ZIP extraction
- Add fs/path top-level requires in company.js

- Add TaskTimeline.vue: two-pane dashboard with task list + message timeline
- Add task-service.js: aggregate cross-agent conversations into task tree
  - 4-strategy parent-child inference (explicit meta, time-overlap, conv→tpl, master→T)
  - Read messages.log for full tool call details (not just history.json)
- Add tasks.js API routes: GET /api/tasks, GET /api/tasks/:taskId/timeline
- Mount /api/tasks in agent-server.js
- Add 'Task Logs' nav entry in AppNav.vue after Templates
- Support taskId in URL (/tasks/:taskId?) for sharing/bookmarking
- Add --parent flag to CLI task dispatch for explicit parentTaskId
- Auto-detect parentTaskId in task/dispatch from sender's active task
- Add --instructions flag to template train CLI command
- Update master tools.md with new parameters

- Updated `POST /api/company/create` to create an empty shell without bootstrapping CXO/HR automatically.
- Updated `master/agent.md` instructions so Master Agent handles all Template library hirings.
- Renamed 'MasterBot' navigation link to 'System Agents'.
- Updated AgentChat sidebar to only show System Agents when accessed via the System Agents link.

- GET /api/company/templates/:id/logs scans system agent conversations
- Logs stored in system agents (agent-creator/innovator), NOT in template dir
- Template directories stay clean for copying
- Collapsible log cards with status, time, message count, and output summary
- Auto-poll during generate/train actions (10s/15s intervals)

- POST /api/company/templates: scaffold new template via AgentScaffold
- POST /api/company/templates/:id/generate: trigger agent-creator to write definitions
- POST /api/company/templates/:id/train: trigger innovator FDE training pipeline
- PUT /api/company/templates/:id/files/content: save template file content
- TemplateAgents.vue: create form, action buttons, editable preview, status banner

- CompanyDashboard Goals Tab: upgraded from flat list to full OKR tree view
  with progress bars, node hierarchy, status animations, owner/priority badges
- ClaudeCliProtocol: added --effort flag support (low=disable thinking)
- agent-chat.js: per-agent effort config from config.json cli.effort
- .gitignore: exclude data/companies/, apiconversation/, agent memory/tasks
- New views: TemplateAgents, JobsPanel, PipelineEditor, SkillsMarket
- docs/architecture-v5.md: added decision #13 (thinking control)

- System agents: 只保留 master (data/system/agents/master)
- Templates: 所有可复用 agent 模板 (data/system/templates/)
- Companies: 公司创建时自动部署 5 个元 Agent (innovator/hunter/digester/evolver/agent-creator)

路径修复:
- agent-chat.js: /list 扫描路径修正 (system/agents + companies/*/agents)
- agent-manager.js: 动态 agent 查找路径修正
- skill-config-loader.js: 修正 agents root
- pipeline-service.js: pipelines 输出到 companies/{id}/pipelines/
- billing.log: 移至 companies/{id}/logs/ 下

Skills 标准化:
- 所有 template agent 建立 .claude/skills/main_skill/SKILL.md
- company-service._copyTemplate() 新增 .claude/ 目录复制
- innovator SKILL.md v3.0: 移除旧 l3-hunt/l2-digest 命名
- 清理重复 agent_creator, 统一为 agent-creator

清理:
- 移除 data/agents, data/workspace, data/logs, data/goals 旧目录
- 清除所有未使用的 DATA_DIR 声明
- 清除 template 中的 conversations/logs/memory 运行态数据

Phase A - Company Bootstrap 自举:
- 新增 _company_bootstrap/manifest.json 模板
- company create 时自动部署 CEO/CTO/COO/HR 四名核心骨干
- 自动启动公司 + 2s后向CEO dispatch战略启动令
- 支持 skipBootstrap 参数跳过自举

Phase B - HR 大一统 (招留管退):
- 新增 hr 模板（agent_creator 的进化体）
- HR 具备完整生命周期管理：招聘/技能装配/监控/辞退
- HR 具备模板发现能力（lemon company templates 查看可用模板如 scrapling_crawler）
- CTO 模板重写：不再亲自 hire，全部通过 task dispatch 向 HR 下发招聘需求单
- CEO 模板更新：确认 Bootstrap 已部署骨干，委派时强调 CTO→HR 招聘链
- 新增 POST /company/:id/fire API（停心跳→归档→更新名单）
- 新增 CLI: lemon company fire / lemon company templates

- Added async orchestration in `/company/:id/hire` when no template is found.
- Triggers Agent-Creator to write definition files based on scaffold.
- Searches Arena (skillDb) for 3 basic skills matching the role and injects them.
- Dispatches Innovator to run FDE pipeline and evaluate initial capabilities.

- Agent names are clickable links to chatbot page
- Action button group per agent: heartbeat ▶/⏹, 💬 Chat, 📋 Skills, 🎓 Train
- Expandable skills panel shows agent's loaded skills
- Train button sends instruction to CEO to arrange Innovator training
- Backend: GET /api/company/:id/agents/:agentId/skills API

- Add Company Overview tab as default landing page
- Show company info: status, uptime, agent count, heartbeat status
- Start/Stop company buttons (activate/deactivate all agent heartbeats)
- Per-agent heartbeat controls: interval dropdown, start/stop buttons
- Backend APIs: GET status, POST start/shutdown, PUT/POST agent heartbeat
- Track startedAt timestamp for uptime calculation
- Update CEO agent.md with mandatory 5-step startup workflow
- Fix company nav to default to overview tab

Phase 3 反馈进化闭环:

1. DataSourceService (运营数据接入):
   - 新增 datasource-service.js: 抽象适配器模式
   - MockAdapter: 模拟运营数据 (开发调试)
   - FileAdapter: 从本地 JSON 文件读取数据
   - 可扩展: 预留 WechatAdapter/DouyinAdapter 接口
   - API: GET /data/metrics, /data/trending, /data/attribution

2. 归因分析引擎:
   - analyzeAttribution(): 自动对比两个时间段指标
   - 计算变化百分比和趋势方向
   - 自动提取显著变化维度并生成洞察文本
   - API: GET /api/company/:id/data/attribution

3. Know-how 自动更新 (memory-service.js):
   - 新增 updateAgentKnowhow() 函数
   - autoReflect 产出的 patterns/lessons 自动写回 SKILL.md
   - 在 SKILL.md 末尾维护'经验教训(自动沉淀)'段落
   - 保留最近 20 条记录，自动清理过旧条目
   - 闭环: Agent执行 → 反思 → 经验写入SKILL → 下次读取改进行为

Phase 2 改进:

1. 工作日历系统 (ScheduleService):
   - 新增 schedule-service.js: 公司级日程管理
   - 支持按小时调度、按周几过滤、时区感知
   - 心跳触发时自动检查到期 slots 并触发 Agent
   - 执行去重（同日同 slot 不重复触发）
   - CRUD API: GET/POST/PUT/DELETE /api/company/:id/schedule/slots
   - CLI: schedule add / schedule list

2. 告警通道 (Alert Channel):
   - Pipeline 步骤超时自动告警 Master Agent
   - 心跳异常自动告警 Master Agent
   - _sendAlertToMaster() 统一告警接口

3. CEO → Pipeline 自动生成:
   - CEO 模板从 3 步升级为 5 步工作流
   - 新增 Step 2: Pipeline JSON 设计（含 loop/cron/steps 结构)
   - 新增 Step 4: OKR 创建
   - Pipeline 设计输出为 CTO 搭建流水线的蓝图

4. Master 晨会日报:
   - 每天 08:00 自动生成全公司运营日报
   - 包含公司状态、Pipeline 运行、OKR 进度、Agent 活跃度
   - 自动推送给 Master Agent
   - 防重复机制（每天只生成一次）

5. Pipeline 驳回信息注入:
   - 驳回步骤被心跳重新触发时，__rejection 信息注入 prompt
   - 让 Agent 知道被驳回的原因和重做次数
   - 替换原有 curl 汇报指令为 task report CLI

Phase 1 核心改进:

1. Pipeline↔Task 系统打通:
   - task/report 回调自动推进 Pipeline 步骤
   - findActiveRunStep() 按 agentId 定位活跃步骤
   - 扫描所有公司的 Pipeline Runs 实现跨公司桥接

2. Pipeline 循环执行:
   - 新增 pipeline.loop 配置项
   - Run 完成后自动启动下一轮 (最大 maxLoops=365)
   - loopCount 计数器追踪循环轮次

3. COO 质量门控:
   - 新增 rejectStep() 驳回方法，含驳回历史记录
   - POST /api/agent/task/reject API 端点
   - POST /api/company/:id/pipelines/runs/:runId/reject 路由
   - node bin/lemon.js task reject CLI 命令
   - 驳回后自动唤醒 Agent 重做，注入改进意见

4. COO 模板全面强化:
   - agent.md: 4维度评分体系、质量审核流程图
   - soul.md: 性格、价值观、决策原则
   - tools.md: 新增 task reject 核心工具
   - heartbeat.md: 结构化巡检清单 + 升级规则