GitHub 交付与失败恢复
区分开发交付、晋级、候选构建和正式发行的结果。
本页介绍 Clowld Space 自身研发流程的扩展。需要连接 GitHub、授予所需权限，并使用匹配的分支、检查和发行工作流；连接任意仓库不会自动获得完整发行流水线。基础配置见 GitHub 集成。
四个阶段
| 阶段 | 做什么 | 何时算完成 |
|---|---|---|
| 开发交付 | 功能分支向 dev 创建 PR，申请 Auto-merge | 申请已记录只表示等待检查；GitHub 实际合并后才算进入分支 |
| 晋级 | 将已验证的 dev 快照通过 promote/* PR 合入 main | 晋级 PR 实际合并 |
| 候选构建 | 从确定的提交准备并核验发行产物 | 候选工作流成功，并核对与任务绑定的候选证明 |
| 正式发行 | 按已有授权创建版本 Tag 并执行发行工作流 | 对应正式发行工作流成功；候选成功不等于正式发行 |
普通开发工作中，已申请 Auto-merge 的智能体可以结束本轮交付；后续检查和合并由 GitHub 处理。任务是否自动完成仍取决于关闭语句和其他打开的关联 PR，详见 PR 合并后的条件。
失败会出现在哪里
平台把结果、PR 或工作流链接、提交和失败作业写回任务评论。开发交付只根据当前打开 PR、当前提交的 Dev PR Gate 失败触发恢复；草稿、过期提交及仅取消的开发检查不作为新的失败派工。
晋级使用 Promotion Gate。订阅 workflow_job 并授予 Actions 读取权限后，可以在单个作业失败时提前通知；缺少该订阅时，仍可在整轮结果后报告。候选和正式发行结果必须匹配对应任务绑定。
自动恢复与人工介入
符合条件的失败会交给系统协调智能体 Coco 安排核查；需要可用的智能体、运行时和执行权限，写回失败评论不保证修复已经执行。重复 Webhook 不重复计为恢复轮次；同一提交的新一轮失败可以继续计入。
相同失败连续两轮，或累计三轮恢复失败后，流程会熔断并提示人工判断。晋级、候选和发行的升级处理保留原负责人。检查任务时间线和链接中的实际错误，解决阻塞后再按既有授权继续，不能把等待、重试或触发事件当成成功。
晋级成功也不会自动授予发行权限。发行意图需要按流程确认；没有发行授权时应停在确认阶段。