Guide

审核流程

This workflow guide reflects the current review contract used by upstream integrators.

Create task: /api/review/agent/tasks
Submit decision: /api/review/tasks/:taskId/decision
Patch rework: /api/review/agent/tasks/:taskId/elements

Breaking workflow contract

Review tasks now start from structured upstream bodyCandidates. Review decisions can carry manualOverrides, and any returned bodyDraft must declare sourceBodyCandidateId.

There is no compatibility layer for the previous upstream schema.

Migration

What changed for upstream systems

The review workflow now depends on round-trippable candidate ids and explicit decision overrides.

When an upstream system creates a task, it must provide body candidates as structured records with id, outline, focuses, and content.

When an admin submits a decision, the API can capture edits that do not come directly from the selected task fields via manualOverrides.

If a decision returns a body draft, it must remain traceable to one upstream candidate through sourceBodyCandidateId.

Lifecycle

任务生命周期

线上仓库和路由处理器实际使用的状态流转。

任务创建后处于 `pending_review`。

任务详情会保留上游提供的结构化正文候选、审核最终采用的 `selections`，以及审核员的 `manualOverrides` 审计信息。

审核动作成功后，任务会进入 `approved` 或 `rejected_rework`。

发布任务成功排队并完成后，任务最终进入 `published`。

Task creation precondition

POST /api/review/agent/tasks should be treated as invalid unless each submitted body candidate already has a stable upstream id and the full structured candidate payload.

Review decisions

审核动作

Use the decision endpoint with the updated payload contract, even if the autogenerated endpoint schema below still shows an older shape.

`approve_and_publish` 会审核通过并排队一个 `triggerMode: 'auto_after_approval'` 的发布任务。

`approve_without_publish` 只完成审核通过，不创建发布任务。

`reject_rework` 会将任务退回返工；空 `rejectedElements` 表示整单驳回，非空时仍需提供对应的 `lockedSelections`。

Decision actionstext

POST /api/review/tasks/:taskId/decision

approve_and_publish -> approve and enqueue publish work
approve_without_publish -> approve without creating a publish job
reject_rework -> send the task back for targeted rework

Decision payload additions:
- manualOverrides is supported
- selections.bodyDraft.sourceBodyCandidateId is required when bodyDraft is present

Required decision semantics

Include a complete selection set for the fields your reviewer is finalizing.
Use manualOverrides for reviewer-authored adjustments that should survive downstream processing.
If selections.bodyDraft is present, include selections.bodyDraft.sourceBodyCandidateId.

Rework

返工语义

返工状态如何保留已经通过的内容。

Rejected elements 表示仍需继续审核的部分。

Locked selections 用于锁定已通过内容，避免后续编辑误改。

Rework looptext

/api/review/tasks/:taskId/decision with action=reject_rework
GET /api/review/tasks/:taskId
PATCH /api/review/agent/tasks/:taskId/elements
/api/review/tasks/:taskId/decision after open rework items are resolved

Candidate id stability matters

Rework remains easier to reconcile if the upstream system keeps candidate ids stable across retries. Review payloads can then continue to point to the same logical source candidate.

Assets

Local upload versus shared library

Review workflows that involve images now need to distinguish between local uploads and shared library browsing.

Use POST /api/assets/upload when the upstream system needs to upload a local image file for this review task.

Keep using /api/assets when the reviewer is browsing or selecting from the shared material library.

Next reading

Use the task and decision reference pages for request examples that match the updated contract.

认证说明

审核相关接口的代理令牌与管理员会话认证约定。

发布流程

发布任务如何排队、重试和完成。

What changed for upstream systems

任务生命周期

审核动作

返工语义

Local upload versus shared library

Related pages