arena

Arena

分发约定。 扇出前先阅读 provider-dispatch.md。已配置的值是带有提供方限定符的描述符，而非主机原生模型名称。父级直接启动原生和外部通道；子级不会自行路由。在 Codex 上，通过 codex-tools.md 解析剩余的 Claude 工具名称。

启动任何任务前，先创建一份待办清单，为每个阶段（Frame、Fan out、Cross-judge、Pick、Graft、Verify）各列一项。

Phase A：Frame

每个候选方案都会收到相同的提示词，因此提示词就是约定。

1. 说明每个候选方案要产出的制品。
2. 拟定评分标准，列出 3-6 项具体且可评分的标准，用于衡量当前任务是否成功。这是 Phase D 中挑选者使用的工具。候选方案只能看到任务。
3. 选择执行器。当前运行环境的 pstack 模型清单中若有 arena runners，则使用它。否则使用其角色默认值，每个条目对应一个执行器。当 Arena 涵盖多个设计方向时，增加执行器数量。如果工作侧重生成而非判断，则重复使用同一描述符 N 次。按照 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择合适的工作力度。
4. 为每个候选方案指定独立的输出位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能。

Phase B：Fan out

通过 provider-dispatch 约定，在一个扇出阶段启动全部 N 个通道。原生通道使用后台子 Agent。外部通道使用直接启动的后台进程，并保留任务／会话句柄；不得使用前台调用，也不得让子 Agent 监管子进程。向每个通道提供任务、共享依据的路径、自身的输出路径，并要求其产出制品和一份简短理由，说明考虑过哪些备选方案以及舍弃了哪些方案。

外部通道只有在回执显示 complete，且包含匹配的 provider-report 或 Codex 的精确 pinned-argv 证据时才计入；原生通道则只有在工具调用记录返回所分配模型的结果时才计入。如果候选方案失败，则以 N-1 个候选方案继续，并在综合记录中注明确切的退出情况。绝不能悄悄用另一个提供方替代它。

Phase C：Cross-judge

Phase B 的所有候选方案完成后，从当前运行环境 pstack 模型清单的 arena cross-judge pool 中选择评审描述符；若清单中没有，则使用上述执行器默认值。优先选择与父级和可能作为基础的候选方案不同的提供方。通过 provider contract 分派一名只读评审。评审会看到评分标准和以路径标签标记的候选方案，对每项标准进行评分，并给出带理由的基础方案建议。评审会与你在 Phase D 中的阅读并行运行。候选方案仍在编写时不要分派评审。

Phase D：Pick a base

选定基础方案前，逐一通读所有候选方案。按照评分标准逐项评分，不要凭整体感觉判断，并与交叉评审的结果进行比较。双方对基础方案意见一致，即可确认选择。若意见不一致，说明其中一方存在偏见，或评分标准含糊不清。作出决定前，先阅读双方的理由。

选择最便于未来维护者扩展且不会破坏不变量的基础方案。如果两个方案难分高下，则遵循 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。

阶段 E：移植

再次逐一检查每个落选候选方案，找出值得移植到基础方案中的内容；通常每个候选方案只移植一两项，而不是大部分内容。按照 redesign-from-first-principles 原则技能的要求，手动融入每项移植内容，确保结果在同一套思维模型下保持连贯。不要机械地复制粘贴。

如果候选方案都收敛到同一种形式，这就说明它们高度一致。记录下来，并交付这个共识方案。无需移植。如果候选方案之间差异很大，说明阶段 A 的要求不够明确。重新界定问题并重新运行，而不是对这些差异取平均。

阶段 F：验证

按照 prove-it-works 原则技能的要求，像验证其他输出一样验证综合后的产物。如果验证发现竞技场未发现的问题，说明阶段 A 有误（重新界定问题并重新运行），或者某个候选方案发现了问题，而你漏掉了相应的移植内容（返回阶段 E）。不要敷衍了事。

输出

一个综合后的产物，以及一份简短的综合说明，注明基础方案及其选择原因、交叉评审者的判定、每项移植内容及其来源候选方案、被拒绝的内容及原因、任何趋同或退出情况，以及验证结果。