Commit cdcb4ea419ce4428ed6cc1f315332d8899a91322

Authored by yibo
1 parent 25bdfca1

refactor(naming): 按 R-15.3 把图节点命名从领域轴改为层级轴

命名轴从「业务领域」({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>
docs/todo/system-design/27-e2e-task-execution-flow.md
... ... @@ -92,14 +92,14 @@ P2 å·²ç»è®¾è®¡äº†ï¼š`system/org-graph-templates/{dev,content,ops}.json` 模æ¿å
92 92  
93 93 **状æ€**:📠概念已在 27 å·æ–‡æ¡£ §3.4 å®šä¹‰ï¼Œæ‰§è¡Œå¼•æ“Žè§ [27-P3/P4](./27-p3-p4-work-graph-console.md),**但 planning agent 本身未设计**
94 94  
95   -ä½ ä¸¾çš„ä¾‹å­ `brd-planning → prd-planning → sdd-planning → benchmark → testdata → code-planner-validator → loop-validator`,与 DevLoop 的实际链路高度é‡åˆï¼š
  95 +ä½ ä¸¾çš„ä¾‹å­ `brd-planning → prd-planning → sdd-planning → benchmark → testdata → planner-validator → loop-validator`,与 DevLoop 的实际链路高度é‡åˆï¼š
96 96  
97 97 | 你的节点 | DevLoop 对应物 | çŠ¶æ€ |
98 98 |---|---|---|
99 99 | brd / prd | PM Agent 产出多页 PRD 站点(`sdd-model.md` M-3) | ✅ 已实现 |
100 100 | sdd | Architect 产出 SDD(MVCP 四页)+ `units.json` | ✅ 已实现 |
101 101 | benchmark / testdata | Architect åŒæ­¥äº§å‡º `integration/spec.json`(M-6) | ✅ 已实现 |
102   -| code-planner-validator | Architect çš„ self-check + L2 gate 判定 | ✅ 已实现 |
  102 +| planner-validator | Architect çš„ self-check + L2 gate 判定 | ✅ 已实现 |
103 103 | loop-validator | Loop-Validator(27 å· Â§3.5)/ BugTriager | 📠27 å·æœªå®žçŽ°ï¼›DevLoop 版 ✅ 已实现 |
104 104  
105 105 💡 **值得注æ„**:DevLoop çš„ `loops-l2.md` å·²ç»å°±ã€Œè°æ¥å†™éªŒæ”¶æ ‡å‡†ã€åšè¿‡ä¸€æ¬¡æ˜¾å¼çš„æ–¹æ¡ˆé€‰åž‹ï¼ˆA/B/C 三选一),并选了 **A:由 Architectï¼ˆè®¾è®¡è€…ï¼‰åœ¨ç”Ÿæˆ SDD æ—¶åŒæ­¥äº§å‡º `integration/spec.json`**,明确å¦å†³äº† **C:由 Integrator(执行者)自己写测试**,ç†ç”±æ˜¯ã€Œå®¹æ˜“写一个永远会通过的 trivial testã€ã€‚ä½ çš„æµç¨‹è®© planner 阶段产出 benchmark/testdataã€è®©åŽé¢çš„ validator é˜¶æ®µæ¶ˆè´¹å®ƒï¼Œæ­£å¥½ç¬¦åˆæ–¹æ¡ˆ A çš„æ€è·¯â€”—**è®¾è®¡è€…å®šæ ‡å‡†ã€æ‰§è¡Œè€…ä¸å®šæ ‡å‡†**。这æ¡å·²ç»è¢«è®ºè¯è¿‡çš„原则应该在通用层继承下æ¥ã€‚
... ... @@ -290,7 +290,7 @@ DevLoop 就这个问题åšè¿‡æ˜¾å¼å†³ç­–(`loops-l2.md` 方案 A/B/C),选æ
290 290 ✅ **§å一 的三节点设计天然符åˆè¿™æ¡åŽŸåˆ™**:`goal-benchmark` / `-test-data` / `-test-script` 三个 agent 与真正写代ç çš„ coder 是**完全ä¸åŒçš„ system agent**,产出者和被验收者分离,ä¸å­˜åœ¨"自己给自己出考题"的激励问题。
291 291  
292 292 âš ï¸ **但仿œªè§£å†³"标准写错了"这一层**。缓解手段有两个,建议都è¦ï¼š
293   -1. work graph 里的 `code-planner-validator` 节点承担一项明确èŒè´£â€”—审"这套验收标准是å¦å¯åº¦é‡ã€æ˜¯å¦è¦†ç›–åŽŸå§‹éœ€æ±‚ã€æ˜¯å¦å­˜åœ¨å¹³å‡¡é€šè¿‡çš„æ¼æ´ž",而ä¸åªæ˜¯å®¡ PRD/SDD 本身。
  293 +1. work graph 里的 `planner-validator` 节点承担一项明确èŒè´£â€”—审"这套验收标准是å¦å¯åº¦é‡ã€æ˜¯å¦è¦†ç›–åŽŸå§‹éœ€æ±‚ã€æ˜¯å¦å­˜åœ¨å¹³å‡¡é€šè¿‡çš„æ¼æ´ž",而ä¸åªæ˜¯å®¡ PRD/SDD 本身。
294 294 2. ä¿ç•™äººå·¥ sign-off(DevLoop L3 çš„åšæ³•)作为最终关å¡ï¼Œè‡³å°‘在 v1 阶段ä¸è¦å…¨è‡ªåŠ¨é—­çŽ¯ã€‚
295 295  
296 296 ### 7.4 并行与现有ä¸å˜é‡å†²çª
... ... @@ -431,15 +431,15 @@ benchmark / test data / test script **䏿˜¯ç³»ç»ŸåŸºç¡€è®¾æ–½ï¼Œæ˜¯ work graph
431 431  
432 432 **ç”± planning agent 在规划 work graph 时动æ€å†³å®šåŠ å“ªå‡ ä¸ª**——å¯ä»¥ä¸‰ä¸ªéƒ½åŠ ã€åªåŠ ä¸€ä¸ªã€æˆ–æŸç§ç»„åˆã€‚这使得"è¦ä¸è¦åŠ éªŒæ”¶èŠ‚ç‚¹ã€åŠ å“ªä¸ª"æˆä¸º work graph è§„åˆ’çš„ä¸€ç­‰å†³ç­–ï¼Œè€Œä¸æ˜¯å›ºå®šæ¨¡æ¿ã€‚
433 433  
434   -例:`code-planner` 这个 org node çš„ work graph å¯èƒ½é•¿æˆ
  434 +例:`org-planner` 这个 org node çš„ work graph å¯èƒ½é•¿æˆ
435 435  
436 436 ```
437 437 brd-planning → prd-planning → sdd-planning ─┬→ goal-benchmark ──â”
438   - ├→ goal-test-data ──┼→ code-planner-validator → loop-validator
  438 + ├→ goal-test-data ──┼→ planner-validator → loop-validator
439 439 └→ goal-test-script ┘
440 440 ```
441 441  
442   -三个验收节点之间**æ— ä¾èµ–,å¯å¹¶è¡Œ**(fan-out),汇åˆåˆ° `code-planner-validator`(fan-in)。这正好是 §7.4 fan-out 能力的第一个真实用例。
  442 +三个验收节点之间**æ— ä¾èµ–,å¯å¹¶è¡Œ**(fan-out),汇åˆåˆ° `planner-validator`(fan-in)。这正好是 §7.4 fan-out 能力的第一个真实用例。
443 443  
444 444 ### 11.2 三者必须产出统一的「验收契约ã€
445 445  
... ...
docs/todo/system-design/27-example-dev-company-walkthrough.md
... ... @@ -58,11 +58,11 @@
58 58 ```jsonc
59 59 // org_graph_nodes + org_graph_edges 的等价视图
60 60 {
61   - "nodes": ["code-planner", "code-coder", "code-validator"],
  61 + "nodes": ["org-planner", "org-coder", "org-validator"],
62 62 "edges": [
63   - { "from": "code-planner", "to": "code-coder", "condition": "success", "edge_kind": "forward" },
64   - { "from": "code-coder", "to": "code-validator", "condition": "success", "edge_kind": "forward" },
65   - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edge_kind": "backward" }
  63 + { "from": "org-planner", "to": "org-coder", "condition": "success", "edge_kind": "forward" },
  64 + { "from": "org-coder", "to": "org-validator", "condition": "success", "edge_kind": "forward" },
  65 + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edge_kind": "backward" }
66 66 ]
67 67 }
68 68 ```
... ... @@ -79,9 +79,9 @@ curl -X POST http://localhost:3010/api/company/auto-illust/org-graph -d @/tmp/or
79 79  
80 80 # 2. 按拓扑åºé€ä¸ªæ‹›è˜ï¼ˆæ³¨æ„:P2 v0.4 èµ· hire ä¸å†éœ€è¦ --reportsTo,
81 81 # 图的结构已在第 1 步整体写入,招è˜åªè´Ÿè´£å»º agent 目录)
82   -node bin/lemon.js company hire --id auto-illust --role code-planner
83   -node bin/lemon.js company hire --id auto-illust --role code-coder
84   -node bin/lemon.js company hire --id auto-illust --role code-validator
  82 +node bin/lemon.js company hire --id auto-illust --role org-planner
  83 +node bin/lemon.js company hire --id auto-illust --role org-coder
  84 +node bin/lemon.js company hire --id auto-illust --role org-validator
85 85 ```
86 86  
87 87 三个角色在 `system/templates/` 里都没有åŒåæ¨¡æ¿ â†’ `hire()` 返回 `needs_training` → è§¦å‘æ—¢æœ‰çš„ agent-creator + innovator åŸ¹å…»æµæ°´çº¿ï¼ˆ`company.js:917-940`,已实现)。
... ... @@ -108,24 +108,24 @@ node bin/lemon.js company hire --id auto-illust --role code-validator
108 108 任务ä¸éœ€è¦å¦å»ºä¸€å¼ é¡¶å±‚图——**阶段 2 生æˆçš„ org graph 本身就是这家公å¸çš„ workflow**,任务直接在它上é¢è·‘:
109 109  
110 110 ```
111   -[code-planner] --success--> [code-coder] --success--> [code-validator]
  111 +[org-planner] --success--> [org-coder] --success--> [org-validator]
112 112 ↑ │
113 113 └────fail(backward)──┘
114 114 ```
115 115  
116   -从入度为 0 的节点(`code-planner`)开始执行。`execution_mode` 由用户选:`manual`ï¼ˆæ¯æ­¥ç‚¹"下一步")或 `auto`(一路跑到底)。å‡è®¾é€‰ `auto`。
  116 +从入度为 0 的节点(`org-planner`)开始执行。`execution_mode` 由用户选:`manual`ï¼ˆæ¯æ­¥ç‚¹"下一步")或 `auto`(一路跑到底)。å‡è®¾é€‰ `auto`。
117 117  
118 118 ---
119 119  
120   -## 阶段 5 · code-planner çš„ Work Graph(Level 1)
  120 +## 阶段 5 · org-planner çš„ Work Graph(Level 1)
121 121  
122   -`code-planner` 这个 org node 被激活,它先调 **workgraph-planning agent** 规划自己这一层的图。
  122 +`org-planner` 这个 org node 被激活,它先调 **workgraph-planning agent** 规划自己这一层的图。
123 123  
124 124 **规划结果**——注æ„三个验收节点是**动æ€é€‰è¿›æ¥çš„**([27-E2E](./27-e2e-task-execution-flow.md) §å一):
125 125  
126 126 ```
127 127 brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ───â”
128   - └→ goal-test-script ─┴→ code-planner-validator → loop-validator
  128 + └→ goal-test-script ─┴→ planner-validator → loop-validator
129 129 ```
130 130  
131 131 **planning agent 的选择ç†ç”±**(这是它è¦åœ¨è§„划时说清楚的):
... ... @@ -156,15 +156,15 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ──â”
156 156 }
157 157 ```
158 158  
159   -**两个并行验收节点是 fan-out 的第一个真实用例**——它们之间无ä¾èµ–,å¯ä»¥åŒæ—¶è·‘,汇åˆåˆ° `code-planner-validator`。🔴 这会撞上 `CONVENTIONS.md` §12ã€Œä»»æ„ (pid, agent) åŒæ—¶åªå…许 1 个 runningã€å’Œ SessionPool çš„ key å¤ç”¨ï¼ˆè§ [27-E2E](./27-e2e-task-execution-flow.md) §7.4)。
  159 +**两个并行验收节点是 fan-out 的第一个真实用例**——它们之间无ä¾èµ–,å¯ä»¥åŒæ—¶è·‘,汇åˆåˆ° `planner-validator`。🔴 这会撞上 `CONVENTIONS.md` §12ã€Œä»»æ„ (pid, agent) åŒæ—¶åªå…许 1 个 runningã€å’Œ SessionPool çš„ key å¤ç”¨ï¼ˆè§ [27-E2E](./27-e2e-task-execution-flow.md) §7.4)。
160 160  
161   -`code-planner-validator` çš„èŒè´£ä¸åªæ˜¯å®¡ SDD,还è¦å®¡**验收标准本身**(§7.3):这套 test_data 覆盖了原始需求å—ï¼Ÿæœ‰æ²¡æœ‰å¹³å‡¡é€šè¿‡çš„æ¼æ´žï¼Ÿ
  161 +`planner-validator` çš„èŒè´£ä¸åªæ˜¯å®¡ SDD,还è¦å®¡**验收标准本身**(§7.3):这套 test_data 覆盖了原始需求å—ï¼Ÿæœ‰æ²¡æœ‰å¹³å‡¡é€šè¿‡çš„æ¼æ´žï¼Ÿ
162 162  
163 163 ---
164 164  
165   -## 阶段 6 · code-coder çš„ Work Graph(Level 1)+ 并行å­å›¾ï¼ˆLevel 2)
  165 +## 阶段 6 · org-coder çš„ Work Graph(Level 1)+ 并行å­å›¾ï¼ˆLevel 2)
166 166  
167   -`code-coder` org node æ¿€æ´»ï¼ŒåŒæ ·å…ˆè°ƒ planning agent。它读到上一阶段的 SDD,把工作拆æˆä¸‰ä¸ªå¯å¹¶è¡Œçš„ unit:
  167 +`org-coder` org node æ¿€æ´»ï¼ŒåŒæ ·å…ˆè°ƒ planning agent。它读到上一阶段的 SDD,把工作拆æˆä¸‰ä¸ªå¯å¹¶è¡Œçš„ unit:
168 168  
169 169 ```
170 170 ┌→ [md-parser] → [unittest] ─â”
... ... @@ -193,9 +193,9 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ──â”
193 193  
194 194 ---
195 195  
196   -## 阶段 7 · code-validator org node + 三级æ¢å¤
  196 +## 阶段 7 · org-validator org node + 三级æ¢å¤
197 197  
198   -`code-validator` 激活,消费阶段 5 产出的 `acceptance.json`:
  198 +`org-validator` 激活,消费阶段 5 产出的 `acceptance.json`:
199 199  
200 200 | 验收项 | æ‰§è¡Œæ–¹å¼ | çŠ¶æ€ |
201 201 |---|---|---|
... ... @@ -203,15 +203,15 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ──â”
203 203 | `test_data` | 喂样本比对实际输出 | 🔴 åŒä¸Š |
204 204 | `benchmark` | 本次为 null,跳过 | — |
205 205  
206   -**å‡è®¾ `no-h2` 这个 case 一直过ä¸äº†**,而且已ç»åœ¨ L1 打回 code-coder é‡å†™ 3 次ã€L2 釿–° planning 1 次,ä»ç„¶å¤±è´¥ã€‚
  206 +**å‡è®¾ `no-h2` 这个 case 一直过ä¸äº†**,而且已ç»åœ¨ L1 打回 org-coder é‡å†™ 3 次ã€L2 釿–° planning 1 次,ä»ç„¶å¤±è´¥ã€‚
207 207  
208 208 此时进入你æè¿°çš„第三级 —— **L4 · 迭代 system agent**([27-E2E](./27-e2e-task-execution-flow.md) §八):
209 209  
210 210 1. 判定这是**能力缺陷**而éžç²—心错误(`qa-judge` 的三分类:粗心错误 / 设计缺陷 / **能力缺陷** → `RETRAIN_REQUIRED` + `capability_gaps[]`。🔴 å议已定义在 `qa-judge/agent.md:223-333`,但没有程åºåŒ–调用入å£ï¼‰
211   -2. è§¦å‘ **L4-company**([27-E2E](./27-e2e-task-execution-flow.md) §八):**åªè¿­ä»£ `code-coder` 在 auto-illust 这家公å¸çš„记忆分区**(`companies/auto-illust/`ï¼‰ï¼Œè‡ªåŠ¨è¿›è¡Œã€æ— éœ€äººå·¥ç¡®è®¤â€”—因为爆炸åŠå¾„å°±é™åˆ¶åœ¨è¿™ä¸€å®¶å…¬å¸å†…,改å了也波åŠä¸åˆ°åˆ«äººã€‚
212   -3. 回到 L1 é‡è·‘ → å†åˆ° code-validator 验è¯
  211 +2. è§¦å‘ **L4-company**([27-E2E](./27-e2e-task-execution-flow.md) §八):**åªè¿­ä»£ `org-coder` 在 auto-illust 这家公å¸çš„记忆分区**(`companies/auto-illust/`ï¼‰ï¼Œè‡ªåŠ¨è¿›è¡Œã€æ— éœ€äººå·¥ç¡®è®¤â€”—因为爆炸åŠå¾„å°±é™åˆ¶åœ¨è¿™ä¸€å®¶å…¬å¸å†…,改å了也波åŠä¸åˆ°åˆ«äººã€‚
  212 +3. 回到 L1 é‡è·‘ → å†åˆ° org-validator 验è¯
213 213  
214   -**注æ„这里ä¸ä¼šç¢° `coder` çš„ general 本体**。如果这次失败暴露的是 `code-coder` 通用能力上的短æ¿ï¼ˆä¸åªæ˜¯æœ¬å…¬å¸åœºæ™¯ç‰¹æœ‰çš„),那属于 **L4-general**:它ä¸åœ¨ä»»åŠ¡å¾ªçŽ¯é‡Œå‘生,而是等当日的 **agent dream æµç¨‹**——由 master agent 或人工触å‘,汇总当天所有公å¸çš„æˆåŠŸ/失败ç»éªŒï¼Œç»Ÿä¸€è’¸é¦ä¸€æ¬¡ general 本体,走 git 版本化以便回滚。这个拆分ä¿è¯äº†"为修一个任务而改ååå®¶å…¬å¸å…±ç”¨ agent"这件事在架构上ä¸å¯èƒ½å‘生。
  214 +**注æ„这里ä¸ä¼šç¢° `coder` çš„ general 本体**。如果这次失败暴露的是 `org-coder` 通用能力上的短æ¿ï¼ˆä¸åªæ˜¯æœ¬å…¬å¸åœºæ™¯ç‰¹æœ‰çš„),那属于 **L4-general**:它ä¸åœ¨ä»»åŠ¡å¾ªçŽ¯é‡Œå‘生,而是等当日的 **agent dream æµç¨‹**——由 master agent 或人工触å‘,汇总当天所有公å¸çš„æˆåŠŸ/失败ç»éªŒï¼Œç»Ÿä¸€è’¸é¦ä¸€æ¬¡ general 本体,走 git 版本化以便回滚。这个拆分ä¿è¯äº†"为修一个任务而改ååå®¶å…¬å¸å…±ç”¨ agent"这件事在架构上ä¸å¯èƒ½å‘生。
215 215  
216 216 **âš ï¸ è¿™é‡Œå°±æ˜¯ §7.1 说的熔断失效风险**:L4 迭代完之åŽå¦‚æžœ L1/L2 的计数器é‡ç½®ï¼Œ"迭代 agent → é‡è·‘ → å†è¿­ä»£"å¯ä»¥æ°¸è¿œå¾ªçŽ¯ã€‚æ‰€ä»¥å¿…é¡»æœ‰ä¸€ä¸ª**跨层级共享ã€åªå¢žä¸å‡çš„任务级总预算**:
217 217  
... ... @@ -231,10 +231,10 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ──â”
231 231 |---|---|
232 232 | orggraph-planning + æ‹› 5 个角色(其中 2 ä¸ªèµ°åŸ¹å…»æµæ°´çº¿ï¼‰ | ~8 |
233 233 | Level 0 任务图规划 | 1 |
234   -| code-planner:workgraph-planning 1 + brd/prd/sdd-planning 3 + 验收 2 + code-planner-validator 1 + loop-validator 1 | 8 |
235   -| code-coder:workgraph-planning 1 + 3 unit ×(code+test) 6 + 1.5 次é‡è¯• ~4 + integrate 1 + int-test 1 + judge 1 | ~14 |
  234 +| org-planner:workgraph-planning 1 + brd/prd/sdd-planning 3 + 验收 2 + planner-validator 1 + loop-validator 1 | 8 |
  235 +| org-coder:workgraph-planning 1 + 3 unit ×(code+test) 6 + 1.5 次é‡è¯• ~4 + integrate 1 + int-test 1 + judge 1 | ~14 |
236 236 | L2 一轮修å¤ï¼ˆtriage + 改 SDD + reset åŽé‡è·‘ 2 unit) | ~7 |
237   -| code-validator + L4 一次迭代 | ~6 |
  237 +| org-validator + L4 一次迭代 | ~6 |
238 238 | **åˆè®¡** | **~44 次** |
239 239  
240 240 ç²—ä¼° **$8-15ã€å¢™é’Ÿ 40-90 分钟**(并行åŽï¼‰ã€‚这个é‡çº§ä¸‹ï¼Œ"自动模å¼ä¸€é”®è·‘到底"必须在å¯åŠ¨å‰æŠŠé¢„ä¼°æˆæœ¬å‘Šè¯‰ç”¨æˆ·ã€‚
... ... @@ -248,7 +248,7 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ──â”
248 248 | # | 断点 | 出现阶段 | 对应设计 |
249 249 |---|---|---|---|
250 250 | 1 | `qa-judge` 没有程åºåŒ–调用入å£ï¼ˆåˆ¤å†³æ— æ³•驱动任何自动动作) | 5, 6, 7 | [27-E2E](./27-e2e-task-execution-flow.md) §11.3 |
251   -| 2 | code-validator 节点的验收执行能力(跑 test_script / å–‚ test_data)未实现 | 5, 7 | §11.3 |
  251 +| 2 | org-validator 节点的验收执行能力(跑 test_script / å–‚ test_data)未实现 | 5, 7 | §11.3 |
252 252 | 3 | 「用户 → å…¬å¸ã€ä»»åС入å£ä¸å­˜åœ¨ | 3 | §三 阶段 3 |
253 253 | 4 | **P2 çš„ org graph 边模型需从 `reports_to` 改为 `success`/`fail` 执行æµè¾¹** | 2, 4 | §五定案 + [27-P2](./27-p2-org-graph.md) v0.4 修正 |
254 254 | 5 | fan-out 并行撞 CONVENTIONS §12 ä¸å˜é‡ + SessionPool key å¤ç”¨ | 5, 6 | §7.4 |
... ...
docs/todo/system-design/27-graph-agent-architecture.md
... ... @@ -60,7 +60,7 @@
60 60 │ Company: {companyId} │
61 61 │ │
62 62 │ Org Graph(company 级 workflow,建公司时生成)│
63   - │ [code-planner] --success--> [code-coder] │
  63 + │ [org-planner] --success--> [org-coder] │
64 64 │ ↑ │ │
65 65 │ └──── fail(backward) ───┘ │
66 66 │ │
... ...
docs/todo/system-design/27-naming-conventions.md
... ... @@ -46,20 +46,71 @@
46 46  
47 47 ---
48 48  
49   -## 三、Org node agent —— `{domain}-{职能}`
  49 +## 三、图节点 agent —— 按**所在图的层级**命名(R-15.3 定案)
50 50  
51   -org graph 上的节点 agent,一律带领域前缀:
  51 +命名轴是**节点在哪一层图里**,不是它属于哪个业务领域。
52 52  
53   -| id | 职责 |
54   -|---|---|
55   -| `code-planner` | 开发领域:规划阶段的 org node |
56   -| `code-coder` | 开发领域:实现阶段的 org node |
57   -| `code-validator` | 开发领域:验收阶段的 org node |
58   -| `content-planner` / `content-writer` / `content-validator` | 内容领域的同构三段 |
  53 +### 3.1 两层节点名
  54 +
  55 +| 层级 | 节点名规则 | 例 |
  56 +|---|---|---|
  57 +| **Org Graph 节点** | `org-{职能}` | `org-planner` / `org-coder` / `org-validator` / `org-innovator` |
  58 +| **Work Graph 节点** | `{父 org 节点全名}-{职能}` | `org-coder-validator` / `org-planner-validator` |
59 59  
60   -**不允许**裸用 `planner` / `coder` / `validator` —— 它们必须能被一眼看出属于哪个领域,否则跨领域公司(既做开发又做内容)会立刻撞名。
  60 +三个 org-graph 模板因此首尾同名,只有中段职能不同——差异在于**中间做什么**,规划和验收本身不分领域:
61 61  
62   ----
  62 +```
  63 +dev.json org-planner → org-coder → org-validator
  64 +content.json org-planner → org-writer → org-validator
  65 +ops.json org-planner → org-monitor → org-validator
  66 +```
  67 +
  68 +**为什么不按业务领域**(v0.2 曾定为 `code-planner` / `content-planner`,已作废):一家公司的 org graph 只有一套节点,领域信息由 company 本身承载。同一个 `org-planner` 服务开发型还是内容型公司,靠 [27-E2E](./27-e2e-task-execution-flow.md) §八bis 的**元 agent 继承 + 公司/角色记忆分区**区分行为。按领域命名会让 agent 池随「领域数 × 职能数」膨胀,同一种能力无法跨领域复用经验。
  69 +
  70 +### 3.2 节点名 ≠ 本体名(R-15.3 新增的命名轴)
  71 +
  72 +**这是本规范此前完全缺失的一条轴**,不区分会直接导致 agent 本体被无谓复制:
  73 +
  74 +| | 例 | 带前缀? |
  75 +|---|---|---|
  76 +| **system agent 本体** | `planner-validator` / `coder-validator` / `org-validator` | ❌ 不带 |
  77 +| **org graph 节点** | `org-planner` / `org-coder` / `org-validator` | ✅ 带 `org-` |
  78 +| **work graph 节点** | `org-coder-validator` / `org-planner-validator` | ✅ 带父节点全名 |
  79 +
  80 +落到 schema 上就是两个字段([27-P3/P4](./27-p3-p4-work-graph-console.md) §四.A):`node_name` 存节点名(图内唯一),`system_agent_id` 存本体名(跨图复用)。
  81 +
  82 +**为什么本体不带前缀**:禁止裸用 `validator` 的理由是「一家公司内两个节点不能重名」——该理由针对**节点**,不针对**本体**。本体若被迫带领域前缀,`coder-validator` 会复制成 `org-coder-validator` / `content-coder-validator` 多份,与 [27-P1](./27-p1-virtual-reference.md)「同一份本体、多处引用、各自私有语境」直接冲突。
  83 +
  84 +### 3.3 三个 validator 是三个独立本体
  85 +
  86 +`planner-validator` / `coder-validator` / `org-validator` 验的东西本质不同——规划产物 / 代码 / 整个任务达成,是**不同能力**,不是同一能力的不同语境。§八bis 的「不特化」原则针对的是同一能力在不同 org node 下,与本条不冲突。
  87 +
  88 +两级验收的分工:
  89 +
  90 +| | 节点名 | 验什么 | 失败退到哪 |
  91 +|---|---|---|---|
  92 +| **org 层** | `org-validator` | 整个任务达成了吗 | 退回某个 org node,**整张 work graph 重跑** |
  93 +| **work 层** | `org-{X}-validator` | 这个 org node 自己的产出合格吗 | 退回本张 work graph 内的某个节点 |
  94 +
  95 +`org-validator` 本身是一个 org node,按定义有自己的 work graph,`benchmark-validator` / `testdata-validator` 就是这张 work graph 的节点——落在已有的递归模型里,引擎不加分支。
  96 +
  97 +### 3.4 存量 system agent 的归位
  98 +
  99 +按同一规则把散落的老 agent 归到它实际所处的层级:
  100 +
  101 +| 旧名 | 新名 | 依据 |
  102 +|---|---|---|
  103 +| `innovator` | **`org-innovator`** | `type='cxo'`,是 org graph 层的节点 |
  104 +| `hunter` | **`innovator-hunt`** | `retrain-pipeline.js:161`,innovator work graph 第 1 阶段 |
  105 +| `digester` | **`innovator-digest`** | 同上第 2 阶段(行 179,输入是 hunter 产出) |
  106 +| `evolver` | **`innovator-evolver`** | 同上第 3 阶段(行 196);行 231 明写 `steps: ['re_hunt','re_digest','evolve']` |
  107 +
  108 +**这顺带解决了 6 个命名冲突 id**(27 号文档 §七)——重命名后 `system/agents/` 与 `system/templates/` 下不再有同名目录。剩两个单独判断:
  109 +
  110 +- `agent-creator`:与 `orggraph-planning` 同属**基础设施角色**,不是任何图上的节点,不加前缀,保持原名。
  111 +- `evolver-youtube-crawler`:针对单个 skill 特化的 evolver 实例,按规则应为 `innovator-evolver-youtube-crawler`,名字过长且疑似一次性产物,**待定**,暂不改名。
  112 +
  113 +> ⚠️ §3.4 的四个重命名**尚未落到代码**,需要一次迁移(目录改名 + `system_agents` 表 + `retrain-pipeline.js` 等引用点)。§3.1-3.3 的新命名已应用于文档与 `system/org-graph-templates/`。
63 114  
64 115 ## 四、验收产物 —— `goal-{类型}`
65 116  
... ... @@ -208,10 +259,14 @@ task_id TEXT, -- 形如 &#39;T-xxx&#39;,system/tasklog/{taskId}.json
208 259  
209 260 | 不要用 | 要用 |
210 261 |---|---|
211   -| `planner` | `code-planner` / `content-planner` / … |
212   -| `validator` | `code-validator` / `content-validator` / … |
  262 +| `planner` | `org-planner`(节点)|
  263 +| `validator` | 节点:`org-validator` / `org-{X}-validator`;本体:`org-validator` / `{X}-validator` |
213 264 | `planning` | `orggraph-planning` / `workgraph-planning` / `brd-planning` / `prd-planning` / `sdd-planning` |
214 265 | `org-graph-creator` | `orggraph-planning` |
  266 +| `innovator` | `org-innovator` |
  267 +| `hunter` | `innovator-hunt` |
  268 +| `digester` | `innovator-digest` |
  269 +| `evolver` | `innovator-evolver` |
215 270 | `benchmark`(裸用) | `skill-benchmark` / `agent-benchmark` / `goal-benchmark` |
216 271 | `test-data` / `test-script`(裸用) | `goal-test-data` / `goal-test-script` |
217 272 | `goal` / `goals`(指 OKR 体系时) | `okr` |
... ...
docs/todo/system-design/27-p2-org-graph.md
... ... @@ -23,7 +23,7 @@ v0.1-v0.3 把 Org Graph 建模为**陿€æ±‡æŠ¥ç»“æž„**:节点是角色引用ï
23 23 |---|---|---|
24 24 | 生æˆè€… | `orggraph-planning` agent | `workgraph-planning` agent |
25 25 | ç”Ÿæˆæ—¶æœº | å»ºå…¬å¸æ—¶ï¼Œä¸€æ¬¡ | æ¯ä¸ª org node 接到任务时 |
26   -| èŠ‚ç‚¹æŒ‡å‘ | org node agent(`code-planner` 等) | system agent 引用 |
  26 +| èŠ‚ç‚¹æŒ‡å‘ | org node agent(`org-planner` 等) | system agent 引用 |
27 27 | 边的语义 | **执行æµ**:`condition ∈ {success, fail}` | **执行æµ**:åŒå·¦ |
28 28 | 执行引擎 | [27-P3/P4](./27-p3-p4-work-graph-console.md) çš„åŒä¸€å¥— | åŒå·¦ |
29 29  
... ... @@ -146,9 +146,9 @@ v0.2/v0.3 设计的 `hire(companyId, roleName, {reportsTo})` **ä¸å†éœ€è¦**。
146 146 ```jsonc
147 147 {
148 148 "nodes": [
149   - { "id": 12, "roleName": "code-planner", "systemAgentId": "code-planner", "status": "active" },
150   - { "id": 13, "roleName": "code-coder", "systemAgentId": "code-coder", "status": "active" },
151   - { "id": 14, "roleName": "code-validator", "systemAgentId": "code-validator", "status": "active" }
  149 + { "id": 12, "roleName": "org-planner", "systemAgentId": "org-planner", "status": "active" },
  150 + { "id": 13, "roleName": "org-coder", "systemAgentId": "org-coder", "status": "active" },
  151 + { "id": 14, "roleName": "org-validator", "systemAgentId": "org-validator", "status": "active" }
152 152 ],
153 153 "edges": [
154 154 { "from": 12, "to": 13, "condition": "success", "edgeKind": "forward" },
... ... @@ -185,7 +185,7 @@ if (bootstrap.status === &#39;hired_from_template&#39;) {
185 185  
186 186 **ä¸è‡ªå·±å†™æ¸²æŸ“逻辑** —— org graph 与 work graph åŒæž„,直接å¤ç”¨ [27-P3/P4](./27-p3-p4-work-graph-console.md) T3 çš„ç”»å¸ƒç»„ä»¶ï¼ˆå…¶æœ¬èº«åˆæ˜¯æ‰©å±•自既有的 `web/src/components/devloop/UnitsDAG.vue`,已实现 SVG + Kahn 分波布局 + 状æ€ç€è‰² + 点击下钻)。
187 187  
188   -这也æ„å‘³ç€ **P2 çš„å‰ç«¯å·¥ä½œä¾èµ– P3 的画布组件先åšå‡ºæ¥**。若想让 P2 独立上线,å¯ä»¥å…ˆåœ¨ Company Dashboard 用一个纯文本的拓扑åºåˆ—表å ä½ï¼ˆ`code-planner → code-coder → code-validator`),等 P3 ç”»å¸ƒå°±ç»ªå†æ›¿æ¢ã€‚
  188 +这也æ„å‘³ç€ **P2 çš„å‰ç«¯å·¥ä½œä¾èµ– P3 的画布组件先åšå‡ºæ¥**。若想让 P2 独立上线,å¯ä»¥å…ˆåœ¨ Company Dashboard 用一个纯文本的拓扑åºåˆ—表å ä½ï¼ˆ`org-planner → org-coder → org-validator`),等 P3 ç”»å¸ƒå°±ç»ªå†æ›¿æ¢ã€‚
189 189  
190 190 ### 4.6 `system/org-graph-templates/`
191 191  
... ... @@ -197,16 +197,16 @@ if (bootstrap.status === &#39;hired_from_template&#39;) {
197 197 "id": "dev",
198 198 "label": "å¼€å‘型公å¸",
199 199 "whenToUse": "目标包å«å®žçްæŸä¸ªäº§å“/功能ã€éœ€è¦è·‘代ç å¼€å‘-测试循环时优先å‚考",
200   - "nodes": ["code-planner", "code-coder", "code-validator"],
  200 + "nodes": ["org-planner", "org-coder", "org-validator"],
201 201 "edges": [
202   - { "from": "code-planner", "to": "code-coder", "condition": "success" },
203   - { "from": "code-coder", "to": "code-validator", "condition": "success" },
204   - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" }
  202 + { "from": "org-planner", "to": "org-coder", "condition": "success" },
  203 + { "from": "org-coder", "to": "org-validator", "condition": "success" },
  204 + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" }
205 205 ]
206 206 }
207 207 ```
208 208  
209   -åŒç†æä¾› `content.json`(`content-planner → content-writer → content-validator`)ã€`ops.json`。
  209 +åŒç†æä¾› `content.json`(`org-planner → org-writer → org-validator`)ã€`ops.json`。
210 210  
211 211 设计è¦ç‚¹ï¼š
212 212  
... ...
system/org-graph-templates/README.md
... ... @@ -17,9 +17,9 @@ JSON 文件,**䏿”¹ä»»ä½•代ç **ã€‚åŒæ ·ï¼Œæ¨¡æ¿é‡Œçš„角色ååªæ˜¯*建è
17 17  
18 18 | 文件 | id | 适用 | 节点链 |
19 19 |---|---|---|---|
20   -| `dev.json` | `dev` | 交付å¯è¿è¡Œä»£ç  | `code-planner → code-coder → code-validator` |
21   -| `content.json` | `content` | 交付给人读/看的内容 | `content-planner → content-writer → content-validator` |
22   -| `ops.json` | `ops` | 让已有系统æŒç»­æ­£å¸¸è¿è½¬ | `ops-planner → ops-monitor → ops-validator` |
  20 +| `dev.json` | `dev` | 交付å¯è¿è¡Œä»£ç  | `org-planner → org-coder → org-validator` |
  21 +| `content.json` | `content` | 交付给人读/看的内容 | `org-planner → org-writer → org-validator` |
  22 +| `ops.json` | `ops` | 让已有系统æŒç»­æ­£å¸¸è¿è½¬ | `org-planner → org-monitor → org-validator` |
23 23  
24 24 ä¸‰å¼ å›¾åŒæž„:**规划 → 执行 → 验收**,验收失败回退到执行节点é‡åšã€‚
25 25  
... ... @@ -30,10 +30,10 @@ JSON 文件,**䏿”¹ä»»ä½•代ç **ã€‚åŒæ ·ï¼Œæ¨¡æ¿é‡Œçš„角色ååªæ˜¯*建è
30 30 "id": "dev", // 必填,与文件ååŒå(ä¸å« .json)
31 31 "label": "å¼€å‘型公å¸", // 必填,给人看的中文å
32 32 "whenToUse": "……", // 必填,LLM é€‰åž‹çš„å”¯ä¸€ä¾æ®ï¼Œå†™æ¸…楚适用场景 + 典型信å·è¯ + 与其他模æ¿çš„区别
33   - "nodes": ["code-planner", "code-coder", "code-validator"],
  33 + "nodes": ["org-planner", "org-coder", "org-validator"],
34 34 "edges": [
35   - { "from": "code-planner", "to": "code-coder", "condition": "success" },
36   - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" }
  35 + { "from": "org-planner", "to": "org-coder", "condition": "success" },
  36 + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" }
37 37 ]
38 38 }
39 39 ```
... ...
system/org-graph-templates/content.json
1 1 {
2 2 "id": "content",
3 3 "label": "内容型公司",
4   - "whenToUse": "公司目标(company-goal)指向「持续产出面向人阅读/观看的内容」,交付物是文章、脚本、文案、视频稿、报告,验收方式是人(或 validator agent)按选题契合度、事实准确性、风格一致性打分时,优先参考本模板。典型信号词:写作、选题、公众号/小红书/YouTube、文案、剧本、翻译、周报。注意与 dev 的区别:这里没有「跑一遍就知道对不对」的自动化验收,因此 content-validator 的 fail 回退边尤其重要,改稿循环是常态。",
5   - "nodes": ["content-planner", "content-writer", "content-validator"],
  4 + "whenToUse": "公司目标(company-goal)指向「持续产出面向人阅读/观看的内容」,交付物是文章、脚本、文案、视频稿、报告,验收方式是人(或 validator agent)按选题契合度、事实准确性、风格一致性打分时,优先参考本模板。典型信号词:写作、选题、公众号/小红书/YouTube、文案、剧本、翻译、周报。注意与 dev 的区别:这里没有「跑一遍就知道对不对」的自动化验收,因此 org-validator 的 fail 回退边尤其重要,改稿循环是常态。",
  5 + "nodes": ["org-planner", "org-writer", "org-validator"],
6 6 "edges": [
7   - { "from": "content-planner", "to": "content-writer", "condition": "success" },
8   - { "from": "content-writer", "to": "content-validator", "condition": "success" },
9   - { "from": "content-validator", "to": "content-writer", "condition": "fail", "edgeKind": "backward" }
  7 + { "from": "org-planner", "to": "org-writer", "condition": "success" },
  8 + { "from": "org-writer", "to": "org-validator", "condition": "success" },
  9 + { "from": "org-validator", "to": "org-writer", "condition": "fail", "edgeKind": "backward" }
10 10 ]
11 11 }
... ...
system/org-graph-templates/dev.json
1 1 {
2 2 "id": "dev",
3 3 "label": "开发型公司",
4   - "whenToUse": "公司目标(company-goal)指向「做出/改进一个软件产品、功能、脚本、API、工具」,交付物是可运行的代码,验收方式是跑测试或跑起来看结果时,优先参考本模板。典型信号词:实现、开发、重构、修 bug、写接口、上线某个功能、做一个 App/网站/CLI。若公司同时还要产出内容或做运维,本模板可与 content.json / ops.json 组合,把本图作为主干、另一张图接在 code-validator 之后。",
5   - "nodes": ["code-planner", "code-coder", "code-validator"],
  4 + "whenToUse": "公司目标(company-goal)指向「做出/改进一个软件产品、功能、脚本、API、工具」,交付物是可运行的代码,验收方式是跑测试或跑起来看结果时,优先参考本模板。典型信号词:实现、开发、重构、修 bug、写接口、上线某个功能、做一个 App/网站/CLI。若公司同时还要产出内容或做运维,本模板可与 content.json / ops.json 组合,把本图作为主干、另一张图接在 org-validator 之后。",
  5 + "nodes": ["org-planner", "org-coder", "org-validator"],
6 6 "edges": [
7   - { "from": "code-planner", "to": "code-coder", "condition": "success" },
8   - { "from": "code-coder", "to": "code-validator", "condition": "success" },
9   - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" }
  7 + { "from": "org-planner", "to": "org-coder", "condition": "success" },
  8 + { "from": "org-coder", "to": "org-validator", "condition": "success" },
  9 + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" }
10 10 ]
11 11 }
... ...
system/org-graph-templates/ops.json
1 1 {
2 2 "id": "ops",
3 3 "label": "运维型公司",
4   - "whenToUse": "公司目标(company-goal)指向「让一个已经存在的系统/流程持续正常运转」,交付物不是新造物而是一次处置动作 + 一份现状证据,验收方式是核对指标是否回到阈值内时,优先参考本模板。典型信号词:监控、值班、巡检、告警、故障处理、数据同步、定时任务、成本治理、SLO/可用性。与 dev 的区别:dev 的循环是「写了再测」,ops 的循环是「动了再观察」——ops-monitor 既执行处置也采集处置后的真实指标,ops-validator 判断指标是否达标,不达标则打回 ops-monitor 换一种处置继续观察。",
5   - "nodes": ["ops-planner", "ops-monitor", "ops-validator"],
  4 + "whenToUse": "公司目标(company-goal)指向「让一个已经存在的系统/流程持续正常运转」,交付物不是新造物而是一次处置动作 + 一份现状证据,验收方式是核对指标是否回到阈值内时,优先参考本模板。典型信号词:监控、值班、巡检、告警、故障处理、数据同步、定时任务、成本治理、SLO/可用性。与 dev 的区别:dev 的循环是「写了再测」,ops 的循环是「动了再观察」——org-monitor 既执行处置也采集处置后的真实指标,org-validator 判断指标是否达标,不达标则打回 org-monitor 换一种处置继续观察。",
  5 + "nodes": ["org-planner", "org-monitor", "org-validator"],
6 6 "edges": [
7   - { "from": "ops-planner", "to": "ops-monitor", "condition": "success" },
8   - { "from": "ops-monitor", "to": "ops-validator", "condition": "success" },
9   - { "from": "ops-validator", "to": "ops-monitor", "condition": "fail", "edgeKind": "backward" }
  7 + { "from": "org-planner", "to": "org-monitor", "condition": "success" },
  8 + { "from": "org-monitor", "to": "org-validator", "condition": "success" },
  9 + { "from": "org-validator", "to": "org-monitor", "condition": "fail", "edgeKind": "backward" }
10 10 ]
11 11 }
... ...
system/templates/orggraph-planning/agent.md
... ... @@ -37,7 +37,7 @@
37 37 | 字段 | 含义 | 你怎么用 |
38 38 |---|---|---|
39 39 | **`goal`(company-goal)** | 这家公司**要达成什么** | **规划的主依据**。图的形状由它决定 |
40   -| `description` | 这家公司**是干什么的** | 背景信息,用来消歧和定领域前缀 |
  40 +| `description` | 这家公司**是干什么的** | 背景信息,用来消歧、决定中段执行节点的职能 |
41 41  
42 42 两者不是一回事,别混。`goal` 是「三个月内做出一个能跑的短视频自动剪辑工具」,
43 43 `description` 是「一家做 AI 视频工具的公司」——**前者定图,后者定语气**。
... ... @@ -81,8 +81,8 @@ node bin/lemon.js company templates
81 81 你**被明确允许**:
82 82  
83 83 - **裁剪**:模板三个节点,这家公司只需要两个 → 砍掉一个
84   -- **替换**:`code-coder` 换成更贴合的既有模板角色
85   -- **组合**:既做开发又做内容 → 以 dev 为主干,把 content 的链接在 `code-validator` 之后
  84 +- **替换**:`org-coder` 换成更贴合的既有模板角色
  85 +- **组合**:既做开发又做内容 → 以 dev 为主干,把 content 的链接在 `org-validator` 之后
86 86 - **新造**:判断需要一个模板库里根本没有的角色 → 直接写进图里(Step 7 会自动建它)
87 87  
88 88 你**不被允许**:
... ... @@ -94,7 +94,7 @@ node bin/lemon.js company templates
94 94 **图的基本形状**(三份模板都是这个同构骨架,你的图通常也应该是它的变形):
95 95  
96 96 ```
97   -{domain}-planner --success--> {domain}-{执行} --success--> {domain}-validator
  97 +org-planner --success--> org-{执行职能} --success--> org-validator
98 98 ^ |
99 99 +---------- fail --------------+
100 100 (edgeKind: backward)
... ... @@ -171,21 +171,21 @@ curl -s -X POST http://localhost:3010/api/company/&lt;公司ID&gt;/org-graph \
171 171 ```jsonc
172 172 {
173 173 "nodes": [
174   - { "roleName": "code-planner", "systemAgentId": "code-planner" },
175   - { "roleName": "code-coder", "systemAgentId": "code-coder" },
176   - { "roleName": "code-validator", "systemAgentId": "code-validator" }
  174 + { "roleName": "org-planner", "systemAgentId": "org-planner" },
  175 + { "roleName": "org-coder", "systemAgentId": "org-coder" },
  176 + { "roleName": "org-validator", "systemAgentId": "org-validator" }
177 177 ],
178 178 "edges": [
179   - { "from": "code-planner", "to": "code-coder", "condition": "success" },
180   - { "from": "code-coder", "to": "code-validator", "condition": "success" },
181   - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" }
  179 + { "from": "org-planner", "to": "org-coder", "condition": "success" },
  180 + { "from": "org-coder", "to": "org-validator", "condition": "success" },
  181 + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" }
182 182 ]
183 183 }
184 184 ```
185 185  
186 186 - `systemAgentId` 可省略,省略时默认等于 `roleName`。
187 187 - `edgeKind` 省略时默认 `forward`。
188   -- 节点也可以直接写成字符串 `"code-coder"`,等价于 `{roleName:"code-coder"}`。
  188 +- 节点也可以直接写成字符串 `"org-coder"`,等价于 `{roleName:"org-coder"}`。
189 189  
190 190 #### ⚠️ 返回 400 怎么办:读懂 errors,自己修,重试
191 191  
... ... @@ -222,9 +222,9 @@ curl -s http://localhost:3010/api/company/&lt;公司ID&gt;/org-graph
222 222 顺序重要——它让 `data/companies/<公司ID>/agents/` 的创建顺序与执行顺序一致,便于排查。
223 223  
224 224 ```bash
225   -node bin/lemon.js company hire --id <公司ID> --role code-planner --type executor --name "研发规划"
226   -node bin/lemon.js company hire --id <公司ID> --role code-coder --type executor --name "研发实现"
227   -node bin/lemon.js company hire --id <公司ID> --role code-validator --type executor --name "研发验收"
  225 +node bin/lemon.js company hire --id <公司ID> --role org-planner --type executor --name "研发规划"
  226 +node bin/lemon.js company hire --id <公司ID> --role org-coder --type executor --name "研发实现"
  227 +node bin/lemon.js company hire --id <公司ID> --role org-validator --type executor --name "研发验收"
228 228 ```
229 229  
230 230 每条命令的返回都要看:
... ... @@ -295,9 +295,9 @@ curl -s -X PUT http://localhost:3010/api/company/&lt;公司ID&gt;/agents/orggraph-plan
295 295  
296 296 | ❌ 不要用 | ✅ 要用 |
297 297 |---|---|
298   -| `planner` | `code-planner` / `content-planner` / `ops-planner` |
299   -| `validator` | `code-validator` / `content-validator` |
300   -| `writer` | `content-writer` |
  298 +| `planner` | `org-planner` / `org-planner` / `org-planner` |
  299 +| `validator` | `org-validator` / `org-validator` |
  300 +| `writer` | `org-writer` |
301 301  
302 302 新领域自己起前缀(`design-` / `sales-` / `data-` / `growth-`…),前缀用**小写英文单词**,
303 303 整个 id 只允许小写字母、数字和连字符。
... ...
system/templates/orggraph-planning/tools.md
... ... @@ -40,10 +40,10 @@ node bin/lemon.js company templates
40 40 **先写文件**(用文件写入工具写 `/tmp/orggraph-<公司ID>.json`,单行紧凑 JSON):
41 41  
42 42 ```jsonc
43   -{"nodes":[{"roleName":"code-planner"},{"roleName":"code-coder"},{"roleName":"code-validator"}],
44   - "edges":[{"from":"code-planner","to":"code-coder","condition":"success"},
45   - {"from":"code-coder","to":"code-validator","condition":"success"},
46   - {"from":"code-validator","to":"code-coder","condition":"fail","edgeKind":"backward"}]}
  43 +{"nodes":[{"roleName":"org-planner"},{"roleName":"org-coder"},{"roleName":"org-validator"}],
  44 + "edges":[{"from":"org-planner","to":"org-coder","condition":"success"},
  45 + {"from":"org-coder","to":"org-validator","condition":"success"},
  46 + {"from":"org-validator","to":"org-coder","condition":"fail","edgeKind":"backward"}]}
47 47 ```
48 48  
49 49 **再发送**:
... ... @@ -58,7 +58,7 @@ curl -s -X POST http://localhost:3010/api/company/&lt;公司ID&gt;/org-graph \
58 58  
59 59 | 字段 | 说明 |
60 60 |---|---|
61   -| `nodes[].roleName` | 必填,角色名,同一公司内唯一。也可直接写成字符串 `"code-coder"` |
  61 +| `nodes[].roleName` | 必填,角色名,同一公司内唯一。也可直接写成字符串 `"org-coder"` |
62 62 | `nodes[].systemAgentId` | 可省略,省略时默认等于 `roleName` |
63 63 | `edges[].from` / `to` | **用角色名**,不是数字 id(图还没落库,你手里没有 id) |
64 64 | `edges[].condition` | `"success"` \| `"fail"`,必填 |
... ...