docs: define code queue model routing policy

docs/reference/code-queue-supervision.md

@@ -41,6 +41,19 @@
 
 当一个指挥机需要突发创建大量 Code Queue 任务时，submit 默认应串行或接近串行。为了避免控制面在确认任务前被打爆，可以使用短本地锁或短延迟，尤其是在低内存主机上。目标是保持任务创建可观测且稳定，而不是最大化瞬时入队吞吐。
 
+## 模型和成本路由
+
+MiniMax/OpenCode runner 的可用性是 Code Queue 的主要能力方向之一。它不是可选实验项，而是控制 GPT-5.5 成本、扩大并发吞吐、让简单任务不占用高成本模型的基础设施能力。
+
+指挥官派单时应按任务难度、风险和验收成本选择模型：
+
+- 低风险、边界清晰、可用文件/命令/commit 直接验收的任务，优先分配给 MiniMax/OpenCode，例如只读调查、文档初稿、表格整理、轻量 CLI contract、局部测试补齐和小范围样板代码。
+- 中等复杂度、需要跨文件判断但不触碰生产运行态的任务，可以在 MiniMax 可用且已有成功样本后尝试分担；prompt 必须更窄，验收证据必须更具体。
+- 高风险任务继续优先使用 GPT-5.5，例如生产部署、凭证和网络变更、Code Queue/backend-core 运行态修复、跨模块架构调整、复杂回滚、以及最终质量裁决。
+- MiniMax 任务不得降低验收标准。指挥官必须核验它声称读取的文件、执行的命令、远端 commit、测试输出和 live 证据；对推测、遗漏、伪造或把失败写成成功的情况，应拆小重派或改用 GPT-5.5。
+
+MiniMax 路由策略的前置条件是 runner live smoke 稳定通过，并且失败能被结构化归类。若 MiniMax/OpenCode 本身不可用，相关修复归入 Code Queue 运行态维护线；在修通前，不应用 MiniMax 承担会阻塞主交付链路的任务。
+
 ## GitHub Issue 和 PR 使用
 
 GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。聊天上下文、Code Queue final response 和指挥简报可以帮助恢复现场，但不能替代 issue 中的可检索记录。指挥简报自身也按 issue 主体维护，当前入口是 GitHub issue #24；后续只更新 #24 正文，不在评论区追加，且所有时间统一使用北京时间。