交付与审核标准
按序操作
- implementation/config/docs 变更使用 fresh-base branch 和 MR，记录 target/base/head、changed files、外部 CI、residual risk 与 next gate。
- Agent review 可负责代码质量和合同检查；required CI 与运营门禁不能取消。
- 普通 MR merge 不触发 Plane 发布；递增版本并同步 CHANGELOG 的 Plane MR merge 是自动发布触发，后续 TEST/PROD 健康仍须由流水线证明。
- Plane 发布只以 GitLab CI、Harbor、GitOps MR 与 Argo CD 形成可审核的交付事实。
- 自动 fix/review/CI 循环必须有 attempt 与 wall-clock 上界；达到上界后失败，不在运行中扩大权限。
- Plane 版本发布依次通过 protected tag、TEST 验收、PRODUCTION exact-head MR CI/merge 与运行观察；credential/permission 变更、runtime activation 和 production data 操作遵守各自 owning gate。
- DSH/Worker 可以交付 source MR 或业务结果，但不是 Plane release operator、observer 或 fallback。
编排实现原则
代码负责身份绑定、阶段顺序、外部副作用、等待与终态判定；Agent 承担实施与语义审核。 创建 Agent 直接使用 DSH 原生 API，稳定岗位配置复用原生 preset。编排不维护岗位工具白名单或 逐工具读写分类，工具可用不代表操作已经授权；owning 能力继续执行自己的操作守卫。 详见 Automation 编排编写原则。
完成与停止
只有同一 release identity 的 source、tag pipeline、TEST acceptance、PRODUCTION MR 和 PROD runtime health 全部闭合，才能宣布发布完成。中间阶段、等待态、失败或 rollback 态不得表述为成功。