-
前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败， 只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。 补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列 文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、 system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用 （agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的 description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
界面走查（真 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> -
命名轴是「节点在哪一层图里」，把散落的老 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>
-
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-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>