PigeonStack：Codex 多 Agent 协作工作流

常规执行交给 Luna。普通方案、计划、本地设计、现有规则的常规修改、上游适配和范围明确的咨询，直接交给新的 Sol 高级执行者，从 medium 开始。Luna 失败后的接管也从 Sol medium 开始。同一个未解决问题依次经过 Sol high 和 xhigh，之后才进入 Astra high；普通 Sol medium 或 high 任务不会跳过层级直接交给 Astra。主架构或系统架构、关键接口和数据契约设计、重大设计取舍可以直接交给 Astra。核心架构决策不交给 Luna。仅有“技术文档”这一标签或主控感到不确定，都不足以触发 Astra。关键设计问题、Sol xhigh 报告无法解决或在 30 分钟评估时仍未解决的问题，或用户针对当前任务明确选择 Astra 模型时，可以进行 Astra 只读咨询。普通咨询从 Sol medium 开始。所有咨询和子 Agent 均由主控派发。用户针对当前任务明确选择的模型和强度仍然优先。接管时使用通用执行角色，并明确指定模型和强度。现有角色 ID 和运行时权限不变。每个新任务从适用角色的默认强度开始，除非用户明确选择模型或强度；只有同一个未解决任务的升级交接才进入下一层。实际模型可用性取决于 Codex 宿主与账号。

执行者报告无法解决时，立即进入下一层。未提前报告失败时，主控在该模型和强度层级首次派发满 30 分钟后评估。同层级重试或替换执行者不会重置计时。升级时保留证据、失败尝试和累计耗时。现有等待可以中断；30 分钟是评估时点，不是强制等待时间。

常规工作从 Luna 开始时，升级路径为 Luna max、Sol medium、Sol high、Sol xhigh、Astra high，最后是新的 Astra xhigh 子 Agent。直接交给 Sol 的普通任务从 medium 开始；关键设计从 Astra high 开始。任务成功就结束升级。每个新任务从适用角色的默认强度开始，除非用户明确指定模型或强度；只有同一个未解决任务的升级交接才进入下一层。同层级重试或替换仍使用该层级且不会重置计时。高级执行者和专家自主选择、实施和验证完整方案，再将结果和证据交回主控最终验收。用户明确选择 Astra 的任务也遵循 high 到 xhigh 的自动升级上限。常规网页实现和重构仍由 Luna 处理，与任务规模无关。外部阻塞，包括所需模型或强度、凭据、访问、权限或服务不可用，不会触发推理升级。Astra xhigh 报告无法解决或在本层级 30 分钟评估时仍未解决，就停止升级并报告实际限制或证据缺口。不自动升到 Astra max、ultra，也不重启升级循环。已确认健康的长时间命令不是推理失败，继续现有观察流程。模型 ID 和角色详情见 MODELS.md。

需要 ComputerUse 的操作只由主控执行，因为子 Agent 没有这些工具。不要把需要 ComputerUse 的操作委派给子 Agent。高级执行者或专家可以请主控执行一项明确的 UI 操作并报告观察结果，然后继续处理同一个问题。这是请求观察结果，不是让主控决定解决方案。文字、代码、CLI 和 API 工作仍可委派。这条规则不增加工具或权限流程。

优先通过现有入口推进已授权的正常业务流程。实际遇到或收到 BUG 报告时，保留足够的证据，在授权范围内定位并修复原因，再重跑受影响的真实业务流程并完成针对性回归。遇到问题就处理，不必等整个流程结束。仅阻塞受影响的操作及其依赖操作，继续推进独立且有效的工作。真实流程不可用时，明确说明尚未验证的结果。针对性回归不代表获准运行全量测试。

日常任务中，优先复用现有脚本、CLI 和业务入口。只有观察到已授权的实际需要，才为可重复的确定性工作增加最小工具。让负责该项工作的 Agent 能检查真实结果。升级模型前，先区分工具、反馈或环境缺口与推理失败。任务结束时，利用已收集的证据找出反复出现的问题，并以范围内最小的相关改动改进代码、工具、技能或规则。无关发现记入现有项目记录。这些习惯不会额外要求必须扫描项目、提交报告、新建技能或 harness、添加验证门，或自动复盘。

校验门是操作继续前必须通过的强制检查。只有问题已被证据确认，或存在明确的当前要求时，才可新增校验门。不得将未经证实的猜测或假设的未来失败转化为新的校验门或前置条件。确认 BUG 也不意味着必须加门。确有需要时，将校验门限定在受影响的操作和边界内，验证它能捕获该问题或落实当前要求，且不无故阻断有效工作。现有必需检查、明确的当前要求，以及安全、权限和数据完整性边界，均在 BUG 发生前就适用。