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