coliseum-orchestrator

用途

Coliseum Orchestrator 用于执行“grain-to-coliseum”转换。用户给出一个“grain”——表面极简、含义密集的提示——系统将其扩展为一个“coliseum”：一组并行的自主工作分配，每个分配自包含，派发给领域专家子代理后无需回头询问意图。

该协议编码的工作单元不是任务、系列、流、负载或循环，而是一个自主工作分配：范围 + 参数 + 成功标准 + 交接信封，携带足够上下文使接收方独立执行。Coliseum 是这些分配的集合，沿 grain 隐含的领域维度并行展开。

主要能力

• 自主读取 grain：默认自行读取，不向用户提问。内部推断字面表面、隐含范围、禁止动作、命名约束、派发预算，并写入 grain-context.md。
• 扇出门禁：在进入阶段 1 前检查 grain 是否具有至少 3 个真正独立的维度。若否，拒绝协议并建议用户改用单次直接请求。
• 四阶段流程：
  1. dimension-surfacing → phase-1-dimensions.md
  2. assignment-composition → phase-2-assignments.md
  3. coliseum-dispatch → phase-3-dispatch-log.md
  4. coliseum-reconciliation → phase-4-composed-whole.md
• 防乒乓门禁：由 pingpong-detector 代理在阶段 2 与 3 之间强制运行，确保每个信封自包含，不会导致接收方回头提问。失败时最多重组 2 次，第三次失败则附带风险标注后派发。
• 并行派发：默认并行，顺序派发需有真实依赖并书面说明理由。
• 调和而非拼接：阶段 4 将并行返回合并为连贯整体，明确解决冲突，不静默丢弃任何返回。

使用方式

调用该编排器时，用户发出一个 grain 并期望得到 coliseum。也可单独调用各阶段技能：仅需维度分析时调用 dimension-surfacing；维度已命名时调用 assignment-composition；分配已组合时调用 coliseum-dispatch；返回已收集时调用 coliseum-reconciliation。

工作目录默认锚定为 <cwd>/coliseum-runs/<grain-slug>-YYYY-MM-DD/，若不可写则回退到 ~/coliseum-runs/<grain-slug>-YYYY-MM-DD/。

阶段 0 后目录包含 grain-context.md；四阶段完成后包含 grain-context.md、phase-1-dimensions.md、phase-2-assignments.md、phase-3-dispatch-log.md、phase-4-composed-whole.md 以及 returns/ 下的各分配返回文件。

适用场景

当用户发出的提示很小但范围明显很大，且可拆分为多个独立维度时，调用此编排器。若 grain 形状为单一任务、序列、叙事或单次解释性工作，则不应运行阶段 1–4。

限制

• 拒绝玩乒乓：若分配会导致接收方回头提问，必须修正信封。
• 拒绝扁平化维度：若两个维度互为转述，在阶段 1 合并。
• 拒绝在可并行时顺序派发。
• 拒绝拼接返回：阶段 4 必须调和冲突。
• 子代理路由为建议性，不保证子代理类型之间存在专业能力差异。
• 阶段 0 仅在 grain 存在不可约歧义时允许向用户提出单个问题。

参考材料

• references/assignment-anatomy.md
• references/why-not-task-series-stream.md
• references/parallel-dimensions.md
• references/handoff-envelope-spec.md

在不确定信封充分性或维度独立性时应阅读这些材料。