用途
orch-pipeline 是 orch-* 技能家族背后的共享编排引擎。orch-* 技能本身只是薄封装：它们不重新实现任何工作，而是对请求进行分类、选择本流水线中哪些阶段运行，并把每个阶段委派给已有的 ECC 智能体或命令。本文件即该流水线本身。
应调用操作技能（如 orch-add-feature、orch-fix-defect 等），而不是直接调用本引擎；本文件是这些技能指向的参考。
何时使用
- 每当某个 orch-* 操作技能运行时被间接加载。
- 仅在向该家族新增操作，或调整共享阶段、门控、智能体映射时直接阅读。
操作家族
| 技能 | 操作 | 触发条件 | 第一步 |
|---|---|---|---|
| orch-add-feature | feature | 能力尚不存在 | 研究并规划新切片 |
| orch-change-feature | tweak | 能工作，但期望行为不同 | 修改现有行为及其测试 |
| orch-fix-defect | fix | 已损坏；行为错误 | 先复现为失败测试，再修复 |
| orch-refine-code | refactor | 行为不变，结构改进 | 在保持测试通过的前提下重构 |
| orch-build-mvp | mvp | 从设计/规格文档引导 | 摄取文档 → 垂直切片 |
这些封装组合而非替换已有的 ECC 命令：/feature-dev、/plan、/code-review、/build-fix、/refactor-clean、/gan-build，以及 tdd-workflow 技能。orch-* 家族在它们之上增加了共享的规模分类器和两道门控，从而用一个统一框架一致地覆盖全部五种操作。
第 0 步 — 规模分类（合理定级）
仪式感随影响范围伸缩。对请求按三个信号打分，取任一信号达到的最高层级，并用一行说明结果，以便用户覆盖：
| 层级 | 涉及文件 | 新依赖 / 契约 | 设计歧义 | 运行的阶段 |
|---|---|---|---|---|
| trivial | 1 个，几行 | 无 | 无——改动显而易见 | 4 → 5 → 6 |
| small | 1 个文件 / 1 个函数 | 无 | 读完代码即清晰 | (1 轻量) → 4 → 5 → 6 |
| standard | 2–5 个文件 | 可能新增内部模块 | 有一个真实选择要做 | 1 → 2 → 4 → 5 → 6 |
| large | 多个 / 跨切面 | 新外部依赖、公共 API 或规格文档 | 多个未决问题 | 1 → 2 → (3) → 4 → 5 → 6 |
阶段 0（Intake）始终运行，故未列入上表的掩码列。决胜规则：任何触及安全触发条件（见下）或公共 API / 契约的改动，无论文件数量多少，至少为 standard。
各阶段
每个阶段都进行委派——不在内联完成工作。
- Intake — 复述请求。对于 orch-build-mvp，读取规格/设计文档并提取范围、已锁定决策和功能列表。
- Research & Reuse — 依据 rules/common/development-workflow.md：先 gh search repos / gh search code，再 Context7 / 厂商文档，再包注册表，最后 Exa。优先采用经过验证的实现，而非全新代码。
- Plan — 委派给 planner 智能体（结构性决策用 architect / code-architect）。输出按薄垂直切片排序的 task_list。→ GATE 1。
- Scaffold — 仅 orch-build-mvp：搭建第一个端到端切片。
- Implement (TDD) — 通过 tdd-guide 智能体（或 tdd-workflow 技能）驱动每个任务：红 → 绿 → 重构。遵守该操作的第一步规则。
- Review — code-reviewer 智能体 / /code-review。只要 diff 触及安全触发条件（见下），就加入 security-reviewer。
- Commit — 约定式提交（feat: / fix: / refactor: / …），每个逻辑块一次。→ GATE 2。
两道门控
该家族是受门控的，而非自主运行：
- GATE 1 — 在 Plan 之后。呈现 task_list；在用户批准前不编写实现代码。
- GATE 2 — 在 Commit 之前。呈现 diff 摘要和建议的提交信息；在用户确认前不提交。
门控之间的一切流程无需停顿。
智能体 / 命令映射
| 阶段 | 主要 | 回退 / 升级 |
|---|---|---|
| Intake / 理解 | code-explorer | 在 tweak、fix 或 refactor 前追踪现有路径 |
| Plan | planner | 结构性决策用 architect、code-architect |
| Implement | tdd-guide（或 tdd-workflow 技能） | 构建中断时用 build-error-resolver / /build-fix |
| Review | code-reviewer / /code-review | 语言审查器（python-reviewer、typescript-reviewer 等） |
| Security | security-reviewer | — |
| MVP 内循环 | /gan-build "<brief>" --skip-planner | 驱动 gan-generator → gan-evaluator；调整 --max-iterations / --pass-threshold |
将语言审查器与仓库匹配（参见仓库自身的 CLAUDE.md）。
安全审查触发条件
当 diff 触及以下任一项时，引入 security-reviewer：认证或授权、用户输入处理、数据库查询、文件系统路径、外部 API 调用、密码学、或机密 / 凭据。（依据 rules/common/security.md。）
交接产物
流水线不携带隐藏状态——规划文档即交接：
- task_list（来自 Plan）驱动 Implement 循环。
- 较大工作还可能按 rules/common/development-workflow.md 在仓库 docs/ 下产出 PRD / architecture / system_design。
- 审查发现（CRITICAL / HIGH）必须在 Gate 2 前解决。
验证
- 规模层级已说明且与实际工作相符
- Gate 1（计划）和 Gate 2（提交）均被遵守
- 当且仅当触及安全触发条件时运行了 security-reviewer
- 提交为约定式，且限定于一个逻辑变更
- 新增 / 变更行为有测试；覆盖率 ≥ 80%，依据 rules/common/testing.md