使用指南
发布流程
发布任务如何排队、重试和完成。
- 手动发布接口
- /api/review/tasks/:taskId/publish-jobs
- 重试接口
- /api/review/tasks/:taskId/publish-jobs/:jobId/retry
- 审批接口
- /api/review/tasks/:taskId/decision
当前发布模型
发布不再经历 `queued` 或 `publishing` 中间状态。管理员触发后，接口会在当前请求内直接执行发布，并把结果记录为一次成功或失败的发布记录。
前置条件
审批通过前提
只有已审核通过的任务才能手动触发直接发布。
只有任务处于 approved，且当前审核结果已经具备可发布快照时，才允许发起发布。
approve_and_publish 会在审批通过后立即执行一次自动发布。
approve_without_publish 则允许管理员稍后通过 publish-jobs 手动触发直接发布。
状态门槛
`POST /api/review/tasks/:taskId/publish-jobs` 只对尚未发布的 `approved` 任务有效。
手动发布
创建发布任务
基于当前审核确认内容生成快照，并在当前请求内直接执行发布。
POST /api/review/tasks/:taskId/publish-jobs 会基于当前任务选中内容和正文草稿生成快照，并在当前请求内直接执行手动发布。
接口成功后会在任务上新增一条 succeeded 或 failed 的发布记录。
直接执行发布text
POST /api/review/tasks/:taskId/publish-jobs
无需请求体。返回结果
接口会返回最新任务记录；其中 `publishJobs` 会新增一条成功或失败的发布记录。
重试
重试失败任务
基于最近失败记录的原始快照，立即执行一次重试发布。
POST /api/review/tasks/:taskId/publish-jobs/:jobId/retry 会基于失败记录快照立即执行一次新的重试发布。
重试接口要求源任务状态为 failed，且所属审核任务仍保持 approved。
重试失败发布text
POST /api/review/tasks/:taskId/publish-jobs/:jobId/retry
源记录必须是 failed。重试护栏
只有当源发布记录为 `failed`，且任务当前仍处于 `approved` 时，重试接口才会继续执行。
快照
发布任务生命周期
发布记录只保留最终结果态 failed 与 succeeded。
发布不再暴露 queued 或 publishing 中间状态；每次触发都会直接落成一条最终结果记录。
只有在记录成功发布结果后，审核任务本身才会进入 `published`。
为什么重试复用原始快照
失败重试复用的是原失败记录的快照，而不是当前任务里后续可能被修改过的 selections。这样可以保证同一次发布尝试链路对应的是同一份内容版本。
延伸阅读
下一步建议阅读
继续查看认证说明和审核流程，确认发布前的权限边界与上游数据来源。