Chorus 中的每一项工作都属于三类实体之一：**想法（Idea）**、**提案（Proposal）** 或
**任务（Task）**。每类实体都会经历一组数量不多且固定的状态。本页按实体列出这些状态、
每个状态的含义，以及推动实体前进的动作。

想从更高层面了解整个交付流程在各阶段之间如何交接，请参阅
[工作流参考](/zh/reference/workflow/)。本页是它按实体展开的配套说明。

## 想法（Idea）

想法自身存储的状态只跟踪**需求细化（elaboration）** 阶段。一旦细化完成，想法即视为完成；
你在看板上看到的后续进展（规划、构建、验证、完成）都是从关联的提案和任务**派生**出来的，
并不存储在想法本身。

<div class="table-scroll" role="region" aria-label="想法状态" tabindex="0">

  | 状态 | 含义 | 推动前进的动作 |
  | --- | --- | --- |
  | `open` | 已创建但尚未有人接手。 | 有人认领该想法，或智能体开始细化 → `elaborating`。 |
  | `elaborating` | 需求细化进行中：智能体分轮次提出澄清问题，你逐一作答。 | 细化完成（所有问题已回答，或跳过细化）→ `elaborated`。 |
  | `elaborated` | 存储状态的终态。双方理解已确认，想法可以进入提案阶段。 | 无进一步的存储状态转移。此后的进展均为派生（见下文）。 |

</div>

### 派生进展

想法到达 `elaborated` 后，Chorus 会根据其关联提案和任务的状态，为看板计算一个展示状态。
想法不存储 `completed` 或 `closed` 状态，也无法直接设置想法的状态；它只会随着
需求细化和下游工作的推进而间接改变。

<div class="table-scroll" role="region" aria-label="想法派生状态" tabindex="0">

  | 派生标签 | 适用情形 |
  | --- | --- |
  | 规划中 | 已细化完成，但尚无已提交的提案（没有提案，或提案还是草稿）。 |
  | 审批提案 | 提案已提交，正等待你审核。 |
  | 开发中 | 提案已批准，其任务正在推进。 |
  | 验收成果 | 至少有一个任务已提交验证。 |
  | 已完成 | 提案已批准，且每个任务都已到达 `done`（或 `closed`）。 |

</div>

## 提案（Proposal）

提案是一个审核容器。它承载智能体准备好的文档草稿和任务草稿；批准提案会把这些草稿
**转为**真实的文档与任务。

<div class="table-scroll" role="region" aria-label="提案状态" tabindex="0">

  | 状态 | 含义 | 推动前进的动作 |
  | --- | --- | --- |
  | `draft` | 编写与编辑中。只有在 `draft` 状态下才能新增或修改草稿。 | 作者提交审核 → `pending`。 |
  | `pending` | 已提交，等待审核者。 | 审核者批准 → `approved`，或拒绝 → 退回 `draft`（附审核备注）。 |
  | `approved` | 已接受。其文档草稿和任务草稿被转为真实的文档与任务。 | 审核流程的终态。 |
  | `closed` | 已撤回或废弃。由它创建的任务会被关闭。 | 终态。 |

</div>

被拒绝的提案会退回 `draft`，作者可据此修订后重新提交；审核者的备注会作为修订参考保留。
只有 `draft` 或 `closed` 状态的提案才能删除。

## 任务（Task）

任务承载单个工作单元，经历执行与验证。

<div class="table-scroll" role="region" aria-label="任务状态" tabindex="0">

  | 状态 | 含义 | 推动前进的动作 |
  | --- | --- | --- |
  | `open` | 未认领、可领取。 | 有人认领或被指派该任务 → `assigned`。 |
  | `assigned` | 已有负责人但尚未开始。 | 负责人开始工作 → `in_progress`（仅当所有依赖均已解除）。 |
  | `in_progress` | 正在进行。 | 负责人提交 → `to_verify`。 |
  | `to_verify` | 工作完成、证据已提交，等待验证。 | 验证者接受 → `done`，或打回 → `in_progress`。 |
  | `done` | 已验证并完成。 | 正常流程的终态。 |
  | `closed` | 已取消，例如其提案被撤回时。 | 终态。 |

</div>

### 依赖与解除阻塞

任务之间可以相互依赖，构成一个有向无环图。**只有当上游任务到达 `done` 后，依赖它的下游任务
才会解除阻塞**（上游为 `closed` 同样视为已解除）。在此之前，下游任务无法进入 `in_progress`。
若把任务从 `to_verify` 移出到 `done` 以外的任何状态，会重置其验收标准。你可以在
[项目资源图谱](/zh/reference/resource-graph/)中查看这些依赖连线，并在任务页面的 **DAG** 视图中添加或编辑它们（见[执行任务](/zh/guides/run-tasks/)）。

:::note[智能体在做什么]
智能体会把任务从 `assigned → in_progress → to_verify` 推进，并针对每个任务的验收标准提交证据。
最终的 `to_verify → done` 验证由人（或代表人的管理员智能体）完成。这种连接如何运作，
参阅[智能体平台](/zh/reference/agents/)。
:::