mo-orchestrate-orca

通过 Orca 编排功能

只有当用户明确指定 mo-orchestrate-orca 时才启动；通用的实现、规划或审查请求不会触发此生命周期。

完整阅读功能生命周期、 后端契约、 可移植审查协议、 Orca 原生机制、 已确认外部工作的路由、 方法论反馈和 目的与架构契约。 确定一个 Orca 二进制文件，并阅读其版本匹配且内容非空的 orchestration 和 orca-cli 指南。

用户要求编排的会话就是编排器。未设置 orchestrator 角色不会阻止启动，也不是询问此会话应使用哪个模型的理由； 禁止使用 --force，也禁止切换到其他模型代际。在某角色的已验证空闲时间 低于方法论规定的阈值时，保持其终端活跃；超过阈值后，优先使用新会话。

通过捆绑的 scripts/mo-models.mjs --show --project <root> 读取角色选择；必须使用用户确切批准的值，绝不选择模型、 effort、placement 或 posture 的备用选项。验证原生提供方身份验证、 账户新鲜度，以及一次实际启动，并确保请求的身份与生效的身份一致。 只有公开验证过的常规 Agent 提示词才可接收任务字节，绝不信任 UI 或 shell。

使用标题 <feature>:orchestrator、<feature>:executor、 <feature>:review:<vendor> 和 <feature>:e2e:<n>。在推理过程中 保留准确的 Run/task/Dispatch/terminal 标识，不要将其存入状态存储。启动 actor 前，记录项目注册项/资源；每个 actor 都必须留在同一个 Orca 项目中， 清理操作只能涉及精确归属的增量。

此生命周期也可从普通 shell 运行。判断放置位置只依据一个条件：终端自身的句柄。 如果存在 ORCA_TERMINAL_HANDLE，且 orca terminal read --terminal "$ORCA_TERMINAL_HANDLE" --screen --json 可读取，则表示在终端内；如果该变量不存在，或读取遭拒，则表示在终端外。 Shell 所在位置不是第二个判断依据：位于已注册工作树内的目录并不拥有终端， 而 Orca 创建的终端无论位于哪个目录都会保留其句柄。不带句柄的终端读取会解析 为工作树当前聚焦的终端，而非调用方的终端；--terminal 只接受运行时签发的 句柄，绝不接受相对名称；两者都不能用于判断放置位置。此时，工作树选择器应为 id:<repo>::<path> 或 path:<path>，绝不使用 current 或 active；创建 Run 时不带 --from， 等待时使用 check --run <id> --wait，且不设置协调器标题。如果没有 watchdog 监测此会话，只需说明一次已接受该限制——到达限制后将停止工作，直到有人类返回—— 然后继续。只有用户要求 watchdog 时才检查 watchdog 辅助程序、jq 和 flock；届时若缺少这些工具，属于普通的类型化缺口；启动 watchdog 仍是 人类操作边界。临时规格、简报草稿和中间协调器文件应存放在项目的 .orca/ 中； 如果 .orca/ 未被忽略，不要在受版本控制的路径中写入临时文件，并返回 needs_attention。 无法回答准备就绪问题的项目就尚未准备就绪，而此技能不会为其做准备。使用随附的 scripts/mo-knowledge-layer.mjs --candidate <sha> 读取每个确切 SHA 的知识层，并保留其单行输出。not_enabled 表示项目没有需要补齐的知识层：仅从 G0、GC、G1 和 G2 中删除 MO-BACKLOG/1 闭环证明。G1 和 G2 的远程 HEAD 一致性、G2 的 CI 证据以及所有其他门槛仍然适用。needs_attention 表示项目已有或曾部分声明相关内容，但缺少 MO-BACKLOG/1 命令、papercut 文档或标识符历史门槛；应按原样报告 helper 给出的原因和 missing= 字段，运行设置技能仍由人类自行决定。在接收迁移写入任何内容之前，先读取已提交的 HEAD 所对应的知识层，这样 needs_attention 请求就会在没有 spec、ledger 或 executor 的情况下结束。

对于 enabled，在接收迁移之后、实质性工作之前，通过项目的 MO-BACKLOG/1 命令运行 G0。唯一的热态 executor 负责所有产品/spec 编辑、回归测试、不变量注释和连贯提交。编排器不得检查或编辑产品代码。executor 的任务要求其在每次交接前按照方法论进行清洁室自我审查：由仅收到规格、diff 和候选 SHA 的子 Agent 给出 PASS；自身发现问题时使用同一个热态子 Agent；在你或审查者提出发现后使用新的子 Agent。将 executor 的 self_review_unavailable 视为其 harness 给出的类型化答复，绝不能视为 PASS；不要自行运行自我审查。

每次运行使用一个全局阻塞等待器：仅 executor 运行时为 600000 ms，审查者/E2E 运行时为 300000 ms。按确切句柄拆分消息，处理完整事件批次，在静默超时后重新挂起，不作说明；传输失败后只允许在同一等待配置下重试一次。

首次深入审查及后续修复时调用 mo-review-orca。仅通过已验证的 pair 路径/大小向 executor 提供两份不可变报告；收到确切的 Review-Handoff-Ack 后再清理。让修复审查者保持热态，并使用全新的最终同 SHA pair。公开更新只包含候选项、pair 判定和作者提交的 P0–P3 数量总和。

Meta-O 技能、参考资料或脚本中经确认的阻碍属于 ISS-16：搜索此技能的 metadata.repository 所指向的仓库，在匹配项上发表评论，或创建一个已清理信息的 Issue，绝不可写入其他位置。若没有该字段，就没有明确的接收方，应将观察结果作为 needs_attention 提交给人类。worker 通过一条普通的 Methodology-Friction: 消息向你报告阻碍；在 eval 或 E2E 运行中，不得在任何外部位置写入内容。

对于经确认的范围外技术缺陷，使用随附的 Issue 路由决策表： 只有在所有权得到验证后，才路由至项目/上游；使用明确且完整的限制搜索开放和已关闭的问题，然后按照相同的封闭策略重新读取并清理最终标题以及私有 file-safe 正文中的每个允许字段。使用原生 gh/glab。根因和负责人均已确定的技术 Issue 已预先授权；凭据、产品争议、订阅、不可逆或影响未知的操作，以及 watchdog，仍属于人类决策范围。写入效果未知时绝不重试。 在候选版本的干净检出中，于前台运行项目声明的 QC，注明命令及其退出码，并针对适用场景调用 mo-e2e；审查者绝不运行测试、代码检查工具或 QC。在知识采集并移除已实现的规范后，要求对准确的候选版本执行 GC。创建任何由 Agent 负责的 MR/PR 前，立即运行 G1 并验证远程源代码头部相同。合并前，立即运行 G2：闭合证明、远程头部、CI-Coverage/1 covered，以及每个覆盖范围内 CI QC 作业的成功运行记录，且其打印的检出 SHA 等于候选版本；然后将提供方写入绑定到该头部／所需策略。任何其他覆盖结果、缺失或失败的运行记录、其他检出 SHA，或不受支持的集成候选证明，都属于 needs_attention；本地已证明的候选版本仍会交付，但 Agent 绝不会在缺少这些 CI 证据的情况下合并。

只有当同一个未更改的完整 SHA 具备 QC、两份最新且供应商各异的 PASS 报告、适用的 E2E，并且知识层处于 enabled 状态时 GC 结果为空，才可返回。否则如实返回 needs_attention。结束时绝不能留有未确认的报告、未解决的待办、外部清理事项或必须回答的问题。

Meta-O 调用

• mo-review-orca
• mo-e2e