# ORC 阶段路由 ORC 是薄路由器,只负责意图映射、依赖、静态档位和结构化状态汇总。它不判断版本号、 实现方案、发布风险或产物策略;领域步骤、授权检查和完成标准由下游 Skill 自己决定。 ## 路由表 | 阶段 | 下游 Skill | 包含 | 不包含 | |------|------------|------|--------| | `code` | `$ack` | 功能、缺陷、重构、测试、三角色验证闭环,以及用户明确要求的普通非发布 PR/MR | 版本发布、单独上传产物 | | `release` | `$manage-release` | 版本号、release worktree/分支、release PR/MR、合并、tag、Forge Release、恢复发布 | 普通非发布 PR/MR、构建或上传 DEB/Docker | | `deb` | `$builder` | DEB 构建、契约校验、上传与仓库可见性 | 源码 tag、Docker 镜像 | | `docker` | `$builder` | Docker/OCI 构建、push、digest 与平台验证 | 源码版本生命周期、DEB | 没有匹配项时不要临时扩写某个 Skill 的职责,也不要让 ORC 自己模仿领域流程。报告缺少 的能力,由用户决定直接执行、安装新 Skill 或另行设计。 路由只依据用户明确表达的目标。缺少目标版本、revision、产物目标或授权停止点时,保留 为未指定并交给下游 Skill;只有缺少创建 task 所必需的项目或阶段身份时才建立 decision gate。不得为了填满 worker prompt 而分析代码、推断版本或设计执行方案。 ## 拆分规则 1. 先从用户请求提取最终结果,再拆出真正需要的阶段;不要因为安装了某个 Skill 就 自动增加发布或上传。 2. 为每个阶段锁定输入:项目、worktree、源 commit/tag、版本、目标和用户授权的最远 写操作。 3. 同一领域的连续动作保留在一个下游任务中。例如版本号、release PR、合并和 tag 属于一个 `manage-release` 生命周期,不拆成多个互相争抢状态的 worker。 4. 只有输入 revision 完全相同且互不修改同一工作树时,才并行执行 DEB 与 Docker。 5. 普通代码改动进入 ACK。若项目尚未初始化 ACK,`code` 阶段停在前置条件,不由 ORC 静默初始化。 6. `code` 阶段默认停在 ACK `verified`;用户明确要求普通 PR/MR 时最多到 `review_ready`。worker prompt 必须禁止继续执行版本发布、DEB、Docker 或部署。 ## 常见 DAG 完整交付: ```text code ($ack) -> release ($manage-release) -> deb ($builder) -> docker ($builder) ``` 只从当前 commit 构建产物: ```text deb ($builder) || docker ($builder) ``` 仅发布源码版本: ```text release ($manage-release) ``` 依赖不是固定模板,但 ORC v2 不拆分一个 `manage-release` 生命周期。若项目要求在打开 release PR 与合并之间插入 DEB/Docker gate,当前 task 粒度无法安全表达该中间里程碑; 在打开 PR 前建立 decision gate 并报告该流程暂不支持,不得用循环依赖或两个 release worker 临时拼接。 ## Worker prompt 契约 每个 worker prompt 至少包含: - 第一条指令显式调用唯一的下游 Skill,例如 `Use $manage-release ...`。 - 阶段目标与明确的非目标。 - 项目/worktree、输入 commit/tag 和前置阶段的可核对结果。 - 用户已经授予的最远动作;未授权动作明确禁止。 - 要求遵循项目 Agent 指令和下游 Skill 自身的停止条件。 - 完成证据,以及通过 live dispatch preamble 回报 `worker_done` 的要求。 - `code` prompt 还必须写明 ACK 停止点是 `verified` 或普通 PR 的 `review_ready`,并禁止 ACK 路由版本、DEB、Docker 或部署动作。 不要把 ORC 的 profile、路由器内部规则或其它下游 Skill 注入 worker。worker 只需要 当前阶段、对应 Skill 和必要依赖结果。