宜博 / lemonboss

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

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

改名：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>

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>