vault: add ECC v2.0 orch-* family + team orchestration notes

4 - Resources/Claude-Code/ECC orch- 编排家族与 v2.0 团队编排.md

@@ -0,0 +1,203 @@
+---
+created: "2026-06-18"
+type: resource
+tags: [resource, claude-code, ECC, orchestration, multi-agent, orch-pipeline, dynamic-workflow, team-orchestration]
+source: "https://github.com/affaan-m/ECC"
+---
+
+# ECC orch-* 编排家族与 v2.0 团队编排
+
+> 本笔记补的是 **ECC v2.0.0(2026-06-09)新增**的编排层。早期编排笔记停在 2026-04,覆盖的是 `/orchestrate`(已退役)、`/multi-*`、GSD、devfleet、自治循环。这一篇专门讲 **`orch-*` 家族、`plan-orchestrate`、团队编排(Kanban)、动态工作流**,以及 2.0 的"操作员系统"理念。
+>
+> 相关:[[ECC 编排实战手册]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]]、[[Everything Claude Code 完整指南]]、[[Everything Claude Code Agent 编排模式]]
+
+---
+
+## 1. `orch-*` 家族 —— 把单会话流程产品化
+
+`/orchestrate` 退役后,ECC 2.0 用 **`orch-*` skill 家族**取而代之。这不是 5 个独立流程,而是 **5 个薄包装(thin wrapper)共用一个引擎 `orch-pipeline`**。包装层只做三件事:给任务**分级**、决定**跑哪几个阶段**、把每个阶段**委派**给现成的 ECC agent/命令。**它不重新实现任何东西**(`/feature-dev`、`/plan`、`/code-review`、`/build-fix`、`/refactor-clean`、`/gan-build`、`tdd-workflow` 都是被它编排的)。
+
+### 五个操作 = 五种任务意图
+
+| skill | 操作 | 触发条件 | 默认尺寸 | 第一步(关键) |
+|-------|------|---------|---------|--------------|
+| `orch-add-feature` | feature | 能力**还不存在** | standard | 先写**新**失败测试 → 实现 |
+| `orch-fix-defect` | fix | 行为**坏了** | small | 先写**回归**失败测试 → 修 |
+| `orch-change-feature` | tweak | 行为在但**不符合期望** | small | 先改**现有**测试到新规格 → 改实现 |
+| `orch-refine-code` | refactor | 行为不变、**结构**改善 | standard | 先确认测试绿 → 重构 |
+| `orch-build-mvp` | mvp | 从 design/spec **文档引导** | large | 读文档 → 切薄竖切片(vertical slices) |
+
+> 选错入口没关系:引擎会先分级,small/trivial 的 feature 会自动塌缩成 `4→5→6`。
+
+### 共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线
+
+七个阶段(Phase 0 永远跑):
+
+- **0 Intake** —— 复述请求;MVP 还要读 spec 抽 scope/锁定决策/功能清单
+- **1 Research & Reuse** —— `gh search repos/code` → Context7/官方文档 → 包仓库 → Exa;**优先采用现成实现**
+- **2 Plan** —— 委派 `planner`(结构性改动用 `architect`/`code-architect`),产出 `task_list`(薄竖切片排序)→ **GATE 1**
+- **3 Scaffold** —— 仅 MVP:立起第一个端到端切片
+- **4 Implement (TDD)** —— 走 `tdd-guide`/`tdd-workflow`:red→green→refactor,遵守该操作的"第一步"规则
+- **5 Review** —— `code-reviewer`/`/code-review`;碰安全触发器加 `security-reviewer`
+- **6 Commit** —— conventional commit,每个逻辑块一个 → **GATE 2**
+
+### 核心设计:仪式随"爆炸半径"缩放(right-sizing)
+
+Step 0 按三个信号(改动文件数 / 是否引入新依赖或契约 / 设计模糊度)取**最高**那一档:
+
+| Tier | 文件 | 新依赖·契约 | 模糊度 | 跑哪些阶段 |
+|------|------|------------|--------|-----------|
+| trivial | 1、几行 | 无 | 改动显而易见 | 4 → 5 → 6 |
+| small | 1 文件/函数 | 无 | 读完代码就清楚 | (1 轻量) → 4 → 5 → 6 |
+| standard | 2–5 文件 | 可能新内部模块 | 一个真实选择 | 1 → 2 → 4 → 5 → 6 |
+| large | 多/横切 | 新外部依赖、公开 API、spec 文档 | 多个开放问题 | 1 → 2 → (3) → 4 → 5 → 6 |
+
+> 平局打破:碰**安全触发器**或**公开 API/契约**的,无论文件多少,**至少 standard**。
+
+### 两道人类门(gated, not autonomous)
+
+1. **GATE 1(Plan 之后)** —— 先给 `task_list`,用户批准前**不写实现代码**
+2. **GATE 2(Commit 之前)** —— 先给 diff 摘要 + 提交信息,用户确认前**不提交**
+
+两门之间一路不停。这正是 `orch-*` 与全自治循环([[Autonomous Loops 自主循环模式]])的根本区别:**有人在环**。
+
+### 阶段→agent 映射
+
+| 阶段 | 主用 | 兜底/升级 |
+|------|------|----------|
+| Intake/理解 | `code-explorer` | tweak/fix/refactor 前先 trace 现有路径 |
+| Plan | `planner` | `architect`、`code-architect`(结构性) |
+| Implement | `tdd-guide` / `tdd-workflow` | 构建炸了用 `build-error-resolver`/`/build-fix` |
+| Review | `code-reviewer` / `/code-review` | 语言专属 reviewer(python/typescript-reviewer…) |
+| Security | `security-reviewer` | — |
+| MVP 内循环 | `/gan-build "<brief>" --skip-planner` | 驱动 `gan-generator`→`gan-evaluator` |
+
+安全触发器(任一即拉 `security-reviewer`):认证授权、用户输入、DB 查询、文件路径、外部 API、加密、密钥凭据。
+
+> 与 `/feature-dev` 的区别:`/feature-dev` 是这套流程的**独立版**;`orch-add-feature` 通过共用 `orch-pipeline` 引擎(分级器 + 两门),让 trivial 功能能右尺寸到 `4→5→6`,并和家族其余操作保持一致。
+
+---
+
+## 2. `plan-orchestrate` —— 把计划文档翻译成 agent 链
+
+**纯生成,不执行**。输入一份多步计划(PRD/RFC/implementation plan),输出**每步一条可直接粘贴**的 `/orchestrate custom` 调用。三件事:
+
+1. **检测 ECC 安装模式** —— plugin 形态命令是 `/everything-claude-code:orchestrate`、agent 是 `everything-claude-code:<name>`;legacy 形态是 `/orchestrate`、`<name>`。**一份输出里不混用两种**。
+2. **拆步骤**(六级优先:显式编号 `## Step N` > 表格 Step 列 > `---` 分隔的动词块 > 否则每个 H2 一步)
+3. **打标签 + 选 agent 链**(12 个触发词 → 默认链):
+
+| 标签 | 默认 agent 链 |
+|------|--------------|
+| `design` | `planner,architect` |
+| `impl` | `tdd-guide,<lang>-reviewer` |
+| `impl+security` | `tdd-guide,<lang>-reviewer,security-reviewer` |
+| `impl+db` | `tdd-guide,database-reviewer,<lang>-reviewer` |
+| `refactor` | `architect,refactor-cleaner,<lang>-reviewer` |
+| `migration` | `architect,tdd-guide,<lang>-reviewer` |
+| `build` | `<lang>-build-resolver` |
+| `security` | `security-reviewer,<lang>-reviewer` |
+| `test` | `tdd-guide,e2e-runner` |
+| `db` | `database-reviewer,<lang>-reviewer` |
+| `docs` | `doc-updater` |
+| `loop` | `loop-operator` |
+
+输出含:全步骤总表、每步详情块(意图 + 选链理由 + 可粘贴命令)、批量执行块。
+
+---
+
+## 3. 团队编排 —— Agent Kanban
+
+### `team-agent-orchestration`:把 agent 当队友
+
+核心:agent 要有**显式 owner、scope、状态、合并门**。用 Agent Kanban 让并行工作可见。
+
+**列(及退出标准)**:Backlog(写好验收) → Ready(分配 owner+分支/worktree) → Running(有 handoff 产物+改动文件) → Review(测试/diff/风险通过) → Merged。另有 Blocked(blocker 有 owner+下一步)、Archived。
+
+**工作项 schema**(关键字段):`id / title / owner / state / branch / worktree / acceptance[] / merge_gate / handoff`。
+
+**控制面板(control pane)应暴露**:活跃工作项及状态、owner/harness/分支/worktree/心跳、handoff/测试/PR 链接、按 owner 分组的 blocker、**按 gate 而非感觉判断的合并就绪度**、可复用工作流候选。
+
+> 关键口号:**merge gate, not hope gate**(用门判断能否合并,而不是凭希望)。
+
+### `team-builder`:按需组队
+
+交互菜单从可用 agent 里拼并行团队。流程:`claude agents` 发现 agent → 按领域分组菜单 → 接受编号("1,3")或名字("security + seo") → **上限 5 个**(再多边际递减) → 用 Agent 工具 `subagent_type: general-purpose` 并行 spawn → 汇总(各 agent 输出 + 一致/冲突/建议)。
+
+> 注意:用**并行 Agent 工具调用**(各自独立做事),不是 TeamCreate(那是给 agent 之间对话用的)。
+
+---
+
+## 4. `dynamic-workflow-mode` —— 为任务现造载体
+
+让 agent 能**生成/改造工作流**,而不只执行静态命令。何时启用:任务需要自定义 loop/评估器/爬虫/fixture 生成器/watcher/dashboard;多个 agent 要同一可重复流程(但还没沉淀成 skill);需要持久 handoff 产物、eval 证据或操作员批准。
+
+**决策树**:一次性 → 内联;输入会变的重复任务 → 建**任务局部载体(task-local harness)**;跨队友/跨仓库重复 → **抽成共享 skill**;有外部状态/排队/审批 → 先加控制面板可见性;有安全风险 → 加 eval 门 + 人类合并门。
+
+**抽成共享 skill 的条件**(满足 ≥2):多会话/仓库/团队重复出现、需要特定语言/工具/安全顺序、失败反复发生、输入输出契约稳定、能受益于控制面板/状态板/团队 handoff。
+
+**每类工作最便宜的可靠 eval 门**:代码 → 聚焦测试+lint+覆盖率+一条集成路径;UI → 浏览器冒烟+截图+溢出/报错检查;agent 工作流 → fixture transcript / 带预期路由的种子工作项;研究/内容 → 来源中立的 brief + claim 清单;集成 → dry-run 命令 + 配置校验 + 无密钥扫描。
+
+---
+
+## 5. v2.0 编排理念:操作员系统(operator system)
+
+ECC 2.0 的论点:agent 工具正从"单人聊天窗"走向**团队编排系统**(看板、控制面板、动态工作流、eval 门、共享 skill)。三层架构:
+
+1. **Meta-harness** —— 可移植的 skills/rules/hooks/MCP 约定/发布门/eval/安全证据
+2. **专属 ECC agent** —— 一个**操作** ECC 资产的 agent(不只把它们当静态指令读)
+3. **控制面板 / agentic IDE** —— 把 session/队列/skill/记忆/证据/发布/团队工作流变成**可观测**的操作员界面
+
+提炼出的几条编排原则(可单独当 zettel 看,见 [[20260618073140 编排即排序门控与委派]]):
+
+1. **编排 = 排序 + 门控 + 委派**(不是新 AI):价值在系统化排序、两道门、委派给被验证过的 agent。
+2. **仪式随爆炸半径缩放**:trivial 跳过 Research/Plan;large 才上全套 + 安全审查。(同样体现在 Ralphinho 的 tier 分层、`parallel-execution-optimizer` 的"只在写面不冲突处并行"。)
+3. **权威随领域走**:Codex=后端权威、Gemini=前端权威、Claude=代码主权(所有落盘);跨域意见仅供参考。(见 [[ECC 编排替代方案 (orchestrate 迁移)]] 路线 D)
+4. **并行必须有可观测的合并门**:每个并行单元都要有 owner、分支/worktree、验收、证据(测试/截图)、merge gate。
+5. **可复用的资产是工作流,不是答案**:一次性答案会扔;证明答案可用的任务局部载体有价值;多团队复用的共享 skill 才是制度资产。
+6. **控制面板胜过隐藏的聊天输出**:"谁拥有这张卡、改了什么、什么失败、什么通过、什么能合并"才是操作员真正需要的。
+
+---
+
+## 6. 这一层在整张编排图里的位置
+
+| 你要的 | 用 | 出处 |
+|--------|-----|------|
+| 单任务全流程、要分级 + 两道人类门 | `orch-add-feature` / `orch-fix-defect` / `orch-change-feature` / `orch-refine-code` | skill |
+| 从 design/spec 文档起 MVP | `orch-build-mvp` | skill |
+| 把一份 PRD/RFC 翻成可粘贴的 agent 链 | `plan-orchestrate` | skill(纯生成) |
+| 多 agent 并行 + 看板可见性 + 合并门 | `team-agent-orchestration` | skill |
+| 按需从可用 agent 拼并行小队(≤5) | `team-builder` | skill |
+| 给任务现造 loop/评估器/dashboard | `dynamic-workflow-mode` | skill |
+| 全自治长跑循环 | 见 [[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]] | — |
+| 跨 harness/tmux 并行 | 见 [[ECC 编排实战手册]]、[[dmux 多Agent并行编排]] | — |
+
+---
+
+## 来源(直接读取的仓库文件)
+
+- `skills/orch-pipeline/SKILL.md`(共用引擎:5 操作、Step 0 分级表、7 阶段、两门、agent 映射、安全触发器)
+- `skills/orch-add-feature/SKILL.md` 及 `orch-fix-defect/`、`orch-change-feature/`、`orch-refine-code/`、`orch-build-mvp/`
+- `skills/plan-orchestrate/SKILL.md`(安装模式检测、拆步、12 标签链)
+- `skills/team-agent-orchestration/SKILL.md`(Kanban 列、work item schema、control pane)
+- `skills/team-builder/SKILL.md`、`skills/dynamic-workflow-mode/SKILL.md`
+- `skills/parallel-execution-optimizer/SKILL.md`
+- `docs/architecture/cross-harness.md`、`docs/architecture/platform-value-loop.md`、`docs/business/team-agent-orchestration-content-pack.md`
+- `CHANGELOG.md`(2.0.0 Added: "orch-* orchestrator skill family and dynamic workflow team orchestration")
+
+---
+
+## Related
+
+### Resources
+- [[ECC 编排实战手册]]
+- [[ECC 编排替代方案 (orchestrate 迁移)]]
+- [[Autonomous Agent Harness 自主代理框架]]
+- [[Autonomous Loops 自主循环模式]]
+- [[Ralphinho RFC-DAG 编排模式]]
+- [[dmux 多Agent并行编排]]
+- [[Everything Claude Code 完整指南]]
+
+### Zettelkasten
+- [[20260618073140 编排即排序门控与委派]]
+- [[Everything Claude Code Agent 编排模式]]
+- [[Everything Claude Code 多服务编排详解]]