# system/org-graph-templates/

Org Graph（公司级 workflow）的**骨架模板库**。

每个 `*.json` 是一种公司类型的执行流图起点。建公司时 `orggraph-planning` agent 会 `ls` 本目录、逐个读取、
对照各自的 `whenToUse` 选型，再结合公司目标（company-goal）与 `node bin/lemon.js company templates`
给出的可招角色清单，裁剪 / 替换 / 组合出这家公司真正的 org graph。

> 设计依据：[docs/todo/system-design/27-p2-org-graph.md](../../docs/todo/system-design/27-p2-org-graph.md) §4.6
> 命名规范：[docs/todo/system-design/27-naming-conventions.md](../../docs/todo/system-design/27-naming-conventions.md) §三

**这是起点集合，不是穷举枚举。** 模板不是代码里的 `switch(type)`——加一种公司类型只需往本目录扔一个
JSON 文件，**不改任何代码**。同样，模板里的角色名只是*建议*，`orggraph-planning` 必须核实是否真有可招模板，
没有则走「从 `system/templates/base/` 元 agent 继承 + `agent-creator` 填充」的分支。

## 当前模板

| 文件 | id | 适用 | 节点链 |
|---|---|---|---|
| `dev.json` | `dev` | 交付可运行代码 | `code-planner → code-coder → code-validator` |
| `content.json` | `content` | 交付给人读/看的内容 | `content-planner → content-writer → content-validator` |
| `ops.json` | `ops` | 让已有系统持续正常运转 | `ops-planner → ops-monitor → ops-validator` |

三张图同构：**规划 → 执行 → 验收**，验收失败回退到执行节点重做。

## 文件格式

```jsonc
{
  "id": "dev",                    // 必填，与文件名同名（不含 .json）
  "label": "开发型公司",           // 必填，给人看的中文名
  "whenToUse": "……",              // 必填，LLM 选型的唯一依据，写清楚适用场景 + 典型信号词 + 与其他模板的区别
  "nodes": ["code-planner", "code-coder", "code-validator"],
  "edges": [
    { "from": "code-planner",   "to": "code-coder",     "condition": "success" },
    { "from": "code-validator", "to": "code-coder",     "condition": "fail", "edgeKind": "backward" }
  ]
}
```

- `condition`：`"success"` | `"fail"`，边的语义是**执行流**（上游出这个结果时流向下游），不是汇报关系。
- `edgeKind`：`"forward"`（默认，可省略）| `"backward"`。**指向拓扑序更早节点的边必须显式标 `backward`**。

## 加一个新模板

1. 新建 `system/org-graph-templates/{id}.json`，按上面的格式填。
2. **角色名遵循 `{domain}-{职能}`**（27-NAMING §三）。禁止裸用 `planner` / `coder` / `writer` / `validator`
   ——跨领域公司会立刻撞名。新领域自己起前缀（如 `design-` / `sales-` / `data-`）。
3. **避开这 6 个命名冲突 id**：`agent-creator` / `digester` / `evolver` / `evolver-youtube-crawler` /
   `hunter` / `innovator`。它们在 `system/agents/` 与 `system/templates/` 下同名但内容可能不同步，
   引用了会产生「该读哪份 agent.md」的歧义。
4. `orggraph-planning` 这类基础设施 agent **不要**出现在图里——它规划图，但自己不是图上的节点。
5. 人工验算 27-P2 §3.3 的四项校验（写入 API 也会校验，但模板先自查能省一轮 LLM 重试）：

   | # | 规则 | 怎么自查 |
   |---|---|---|
   | 1 | **无环**（只看 `forward` 边） | 把所有 `backward` 边划掉，剩下的边必须能排出拓扑序 |
   | 2 | **恰好一个入口** | 只数 `forward` 边的入度，入度为 0 的节点必须**恰好一个** |
   | 3 | **全可达** | 从入口沿 forward 边 BFS，必须覆盖 `nodes` 里每一个节点，不许有孤立节点 |
   | 4 | **回退边显式标注** | 任何 `to` 在拓扑序上早于 `from` 的边，必须带 `"edgeKind": "backward"` |

6. 自验 JSON 能解析：
   ```bash
   node -e "['dev','content','ops'].forEach(f=>JSON.parse(require('fs').readFileSync('system/org-graph-templates/'+f+'.json','utf-8')))"
   ```