# 编排器的引入与"分级编排"边界

**日期**：2026-06-08
**影响范围**：新增 light-orchestrator、ROUTER.md、CONVENTIONS.md、a02 memory-pm 协作

## 背景

Light 的"组合调用链路"原本只写在 ROUTER.md 里当文字描述，没有运行时约束——模型实际跑大任务时可能跳步、漏检查点、或没过 self-review 就交付。调研 ARS 时看到它的 10 阶段状态机 + 强制检查点 + Material Passport 解决的正是这个问题。

## 决策

- 新增常驻技能 **light-orchestrator**：把声明式链路升级为可执行 pipeline——规划阶段、调用技能、卡检查点、维护产物台账。它只调度，不亲自干活。
- 检查点分两类：**决策点 🧑**（用户选分支）+ **确认点 ✓**（机器先验、用户确认）。诚信门不达标默认阻断，最多 2 轮整体返修，仍不达标转"已知局限"如实记录。
- 产物台账固定存 `.light/passport.yaml`，纳入 a02 memory-pm，支持中断续跑。
- **关键边界——分级编排**：大任务（跨 ≥3 阶段 / "全流程"）才上完整 pipeline；轻任务（改摘要、画一张图、查引用）直接单技能，常驻闸门照常后台跑即可。

## 理由

ARS 的检查点非常重（10 阶段每阶段都卡），适合它"纯学术论文"的窄场景。Light 场景更杂，很多是轻任务，若一律套重流程会把简单需求拖死。所以引入编排器的同时必须设"分级"这条边界：**编排是为了在复杂任务里防跳步，不是为了给所有任务加仪式**。判据写进 SKILL：这个任务需要跨技能交接产物吗？需要才编排。

不照搬 ARS 的"每阶段强制检查点"全量套用，正是上一篇 [ars-borrow-boundary](2026-06-08-ars-borrow-boundary.md) 复核问题的应用——检查点机制是普适诚实底线（照学），但"卡多重、卡多密"是 ARS 窄定位的产物（按 Light 的宽场景重新裁剪）。

## 复核问题

下次有人想给某个轻任务也套 pipeline，或想加新的强制检查点时，先问：

> **这个关卡是在防真实的跨阶段风险（跳步、漏验、静默带病推进），还是只是在加仪式感？**

只防真实风险的关卡才留；为编排而编排的一律砍。宁可少编排，不可为编排而编排。
