3.3 状态机：生命周期管理

每个任务都有一个生命周期。AI Context Workspace 用一套简单的状态机来管理它。

六个状态：

pending → in_progress ↔ paused
in_progress/paused → completed
completed → in_progress (返工)
pending/in_progress/paused → cancelled
completed/accepted-review/cancelled → archived

pending（待处理）——任务已创建，但还没开始。适用于任务拆分后等待执行的情况。

in_progress（进行中）——正在执行。这是任务的主要状态，大部分时间都在这里。

paused（暂停）——因为阻塞、等待外部输入或优先级调整而暂停。暂停不是放弃，是"暂时不做"。

completed（完成）——任务执行完毕，交付物已产出。但 completed 不等于"可以归档"，还需要通过 Review 门禁。

cancelled（取消）——任务不再需要。取消不需要 Review，但需要记录取消原因。

archived（已归档）——最终状态。任务通过 Review（PASS 或被接受的 REVIEW）后归档，或取消后归档。归档后不再修改，只可查阅。

状态机不是为了管控，而是为了恢复上下文。

想象一下：你半年后回到一个项目，打开 artifacts/index.json，看到：

• 任务 A：in_progress
• 任务 B：paused
• 任务 C：archived (completed)

三行信息，你就知道：A 正在做，B 等着继续，C 已经完成。不需要问任何人，不需要读任何文档。这就是状态机的价值——让 AI 和人都不需要靠记忆理解当前局面。

状态转移的门禁

不是所有转移都允许。比如：

• completed 不能直接变成 archived，必须通过 Review（PASS 或 REVIEW+接受）
• archived 不能回到 in_progress，如果需要继续，创建新任务，用 parentArtifactId 关联
• paused 不能直接 completed，必须先回到 in_progress

这些门禁不是官僚主义。它们是为了防止状态不一致。比如一个任务标记为 completed，但没有 Review 结论，那它到底是真完成了还是只是写完了代码？

状态机很轻，但很关键。

它不要求你填一堆字段，不要求你写日报周报。它只要求你在任务状态变化时更新一个 JSON 文件里的一个字段。这个操作一秒就能完成，但它带来的信息透明度是巨大的。