docs: add code queue minimax routing guard
This commit is contained in:
Codex
@@ -43,16 +43,41 @@
|
||||
|
||||
## 模型和成本路由
|
||||
|
||||
MiniMax/OpenCode runner 的可用性是 Code Queue 的主要能力方向之一。它不是可选实验项，而是控制 GPT-5.5 成本、扩大并发吞吐、让简单任务不占用高成本模型的基础设施能力。
|
||||
MiniMax/OpenCode runner 的可用性是 Code Queue 的主要能力方向之一。它不是可选实验项，而是控制 GPT-5.5 成本、扩大并发吞吐、让简单任务不占用高成本模型的基础设施能力。但 MiniMax 幻觉和伪造证据风险显著高于 GPT-5.5，因此只能承接低权限、低风险、低 blast radius 且可用外部证据复核的任务。
|
||||
|
||||
指挥官派单时应按任务难度、风险和验收成本选择模型：
|
||||
MiniMax 路由策略的前置条件是 runner live smoke 稳定通过，并且失败能被结构化归类。#30 只证明 dev smoke 已有成功证据；生产 rollout 仍按受控节奏推进，指挥官不能假设 prod MiniMax 已可用。若 MiniMax/OpenCode 本身不可用，相关修复归入 Code Queue 运行态维护线；在修通前，不应用 MiniMax 承担会阻塞主交付链路的任务。
|
||||
|
||||
- 低风险、边界清晰、可用文件/命令/commit 直接验收的任务，优先分配给 MiniMax/OpenCode，例如只读调查、文档初稿、表格整理、轻量 CLI contract、局部测试补齐和小范围样板代码。
|
||||
- 中等复杂度、需要跨文件判断但不触碰生产运行态的任务，可以在 MiniMax 可用且已有成功样本后尝试分担；prompt 必须更窄，验收证据必须更具体。
|
||||
- 高风险任务继续优先使用 GPT-5.5，例如生产部署、凭证和网络变更、Code Queue/backend-core 运行态修复、跨模块架构调整、复杂回滚、以及最终质量裁决。
|
||||
- MiniMax 任务不得降低验收标准。指挥官必须核验它声称读取的文件、执行的命令、远端 commit、测试输出和 live 证据；对推测、遗漏、伪造或把失败写成成功的情况，应拆小重派或改用 GPT-5.5。
|
||||
`codex submit --dry-run` 是派单前的轻量 preflight。它只输出 `routingRecommendation`，帮助指挥官看到推荐 runner/model、风险信号和缺失的 prompt guard；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m2.7` 仍由指挥官显式决定。
|
||||
|
||||
MiniMax 路由策略的前置条件是 runner live smoke 稳定通过，并且失败能被结构化归类。若 MiniMax/OpenCode 本身不可用，相关修复归入 Code Queue 运行态维护线；在修通前，不应用 MiniMax 承担会阻塞主交付链路的任务。
|
||||
MiniMax/OpenCode 可承担任务必须同时满足这些条件：
|
||||
|
||||
| 类型 | 适用边界 | 必须证据 | 不可越界 |
|
||||
| --- | --- | --- | --- |
|
||||
| 只读调查 | 查找文件、梳理现有实现、列出候选入口、对比文档口径 | 文件路径、行号、命令输出摘要 | 不得把 issue 内容当唯一输入，不得声称读取了无法验证的远端状态 |
|
||||
| 中文文档初稿或长期参考补丁 | `docs/reference/`、`AGENTS.md` 索引、一句话摘要、表格治理规则 | diff、文档位置、轻量格式/grep 检查 | 不写流水账，不改 release/v1 runtime |
|
||||
| 轻量 CLI dry-run/preflight | 只读或 dry-run 输出、contract test、参数校验、错误分类 | dry-run JSON、contract test、`bun` 脚本验证 | 不改 runtime 调度核心，不触碰生产服务 |
|
||||
| 局部测试补齐 | 单文件或小范围 contract/unit test，覆盖明确回归 | 测试命令、失败前提、通过输出 | 不跑 heavy check、E2E、Playwright |
|
||||
| 小范围样板代码 | 非共享核心、可快速 review、可用类型检查或 dry-run 验证 | 修改文件、轻量类型/脚本验证、commit | 不跨多服务，不改凭证、网络、部署或数据库 |
|
||||
| 数据整理和看板候选草案 | 生成 #20/#24 更新草案、任务表、验收 checklist | 草案 diff、来源列表、人工待审标记 | 不直接替代指挥官审阅，不自动清空未读任务 |
|
||||
|
||||
GPT-5.5/Codex 必须承担这些任务：
|
||||
|
||||
| 类型 | 原因 | 验收重点 |
|
||||
| --- | --- | --- |
|
||||
| Code Queue/backend-core/provider-gateway/k3sctl-adapter 运行态修复 | 运行面错误会影响调度、观测和恢复路径，MiniMax 误判成本高 | 多信号诊断、轻量 contract、必要时 dev 验证；不隐式 prod rollout |
|
||||
| 跨模块架构或共享契约调整 | 需要理解系统边界、兼容性和长期演进 | 文档、代码、测试和回滚边界一致 |
|
||||
| CI/CD、artifact、deploy、release/v1 治理 | 易影响发布真相和稳定维护线 | dry-run/plan、commit-pinned 证据、release governance 一致 |
|
||||
| 安全、凭证、网络、egress/proxy 变更 | 涉及 secret 泄漏、访问路径和外部服务 | 不输出 token，最小权限，结构化失败 |
|
||||
| 复杂 bug 修复和最终质量裁决 | 需要辨别不完整证据、伪造、隐藏失败 | trace/output/commit/test 交叉验证 |
|
||||
| 生产部署方案设计或回滚方案 | 生产 blast radius 高，即使只写方案也需高可信推理 | 明确非目标、授权点、验证和回滚 |
|
||||
|
||||
只能由人工或指挥官处理的任务包括：真实生产重启、Code Queue backend 重建、运行中任务 interrupt/cancel、密钥读取或轮换、数据库手工写入、破坏性 Git 操作、强制回滚、把完成未读任务批量标记已读、以及任何需要用户授权的高风险恢复动作。这类任务可以让 worker 起草方案或 checklist，但执行权不下放给 MiniMax，也不应下放给普通 GPT worker，除非用户明确授权并给出边界。
|
||||
|
||||
MiniMax prompt 必须自包含：目标、背景、写入范围、禁止动作、验证命令、final response 字段都要写进 prompt；GitHub issue 只能作为辅助引用，不能作为唯一来源。禁止使用“读取 issue 后按里面做”这类 prompt。若确实需要 issue 内容，指挥官先把关键需求、约束和验收点摘入 prompt，再附 issue URL。
|
||||
|
||||
MiniMax 风险控制必须固定包含：禁止 prod/重启/密钥/DB 写入；禁止 release/v1 runtime 修改；禁止 heavy check/E2E/Playwright，除非任务明确改为 GPT-5.5 且用户授权；必须给出可验证证据，包括修改文件、命令、测试输出、commit 和未覆盖风险；完成后保持未读，由指挥官用 `codex task <taskId>` 审阅后再单独 `codex read <taskId>`。
|
||||
|
||||
对 MiniMax 的验收不能看 final response 自述。指挥官至少核验 diff、commit 是否在声明目标分支可 fetch、轻量验证命令是否真实存在、输出是否和任务范围匹配；遇到推测、遗漏、伪造证据或把失败写成成功时，先拆成更小任务或改派 GPT-5.5。
|
||||
|
||||
## GitHub Issue 和 PR 使用
|
||||
|
||||
@@ -111,7 +136,7 @@ Runner preflight 优先使用执行面诊断入口：
|
||||
bun scripts/cli.ts codex pr-preflight --remote --issue 20
|
||||
```
|
||||
|
||||
该命令经 backend-core 稳定 `code-queue` proxy 访问 D601 scheduler 的 `/api/runtime-preflight`，报告 scheduler/runner 环境里的 `GH_TOKEN`/`GITHUB_TOKEN` 覆盖、工具、Git worktree、GitHub egress、repo/issue/PR 只读探测和可选 push dry-run。缺少 env token 时必须返回 `ok=false`、`runnerDisposition=infra-blocked` 和 `tokenCoverage.missing=["GH_TOKEN","GITHUB_TOKEN"]`，因为 provider dev container 只能转发 scheduler 已经拥有的 token。
|
||||
该命令经 backend-core 稳定 `code-queue` proxy 访问 D601 scheduler 的 `/api/runtime-preflight`，报告 scheduler/runner 环境里的 `GH_TOKEN`/`GITHUB_TOKEN` 覆盖、工具、Git worktree、GitHub egress、repo/issue/PR 只读探测和可选 push dry-run。需要复核 PR body/创建命令 guard 时追加 `--pr-create-dry-run --pr-create-dry-run-head <head>`；该 guard 只执行 dry-run，不创建 PR。缺少 env token 时必须返回 `ok=false`、`runnerDisposition=infra-blocked` 和 `tokenCoverage.missing=["GH_TOKEN","GITHUB_TOKEN"]`，因为 provider dev container 只能转发 scheduler 已经拥有的 token。
|
||||
|
||||
本地 runner preflight 示例：
|
||||
|
||||
@@ -182,6 +207,8 @@ D601 artifact registry 的 systemd unit inactive 不等于 D601 全局离线。
|
||||
|
||||
每次新增 Code Queue 任务、补发 follow-up task，或处理一批完成未读任务后，都必须同步更新 GitHub 总看板 issue `#20` 的正文主表；如果发生实质态势变化，还要同步更新指挥简报 issue `#24` 的正文。看板更新应反映当前任务分布、关键 blocker 和粗略进度，不要只改聊天上下文或只改单个 issue，而让总态势图落后于实际调度状态。
|
||||
|
||||
MiniMax 成本路由接入 #20 看板时，#20 的每个 Code Queue 任务行都应显式保留推荐或实际 runner/model、风险等级、验证证据和审阅状态。推荐列的语义只来自指挥官判断或 `codex submit --dry-run` 的 `routingRecommendation`，不能来自 worker 自评。MiniMax 任务在 #20 中必须先保持“待指挥官审阅”状态；只有指挥官核验 diff、commit、轻量验证和未越界后，才更新为已验收并执行 `codex read <taskId>`。若 dry-run 给出 `commander-human-only` 或 GPT-5.5 recommendation，#20 不应把该任务降级给 MiniMax；若必须降级，必须在看板 progress 中写明人工接受的风险和额外审阅动作。
|
||||
|
||||
## 指挥工作流
|
||||
|
||||
对每个活跃任务，按顺序评估四件事：
|
||||
|
||||
Reference in New Issue
Block a user