由中心协调开发流程

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

一个功能由设计、实现和评审角色推进，主协调者维护唯一当前阶段。教学状态为 designed→implemented→reviewed，每份证据绑定候选 revision-a；评审只返回“完成”但没有产物或用了旧版本时，不能直接推进。

具体做法

定义每个转移的输入、验收和负责者，让工作角色交付版本、产物、结果与未决项。协调者回读并核对当前候选，满足阶段条件才更新状态。完成、不可用、禁用、跳过和失败分别记录；评审失败继续保持未通过评审，而不是因为子任务结束就算 reviewed。共享状态由明确所有权或原子机制更新。

反例

让所有角色随意汇报完成，自行改阶段。协调者看到任何 completed 字样就从 implemented 进入 reviewed，忽略产物、旧版本或缺评审维度。

改进写法

教学协调者拥有 designed/implemented/reviewed 状态。各角色返回 artifact_path、revision、实际结果与 unresolved_items。核对 revision-a 的产物与约定检查后才推进；旧版本、不完整维度或失败评审不满足 reviewed。明确记录 unavailable/disabled/skipped，不能折算为通过。阶段更新需单一归属或原子比较，并在交接保留当前未完成条件。

为什么这样改

中心状态给各角色一个共同位置，证据门槛把工作结束与阶段通过分开。版本和缺失维度也保持可见，避免过期报告或不存在的评审借一个成功标签推进流程。

如何验证

教学缺评审产物时应停在 implemented；匹配 revision-a 的完整有效评审才进入 reviewed。修订变成 b后，a 的结果不再自动满足当前门槛。

检查状态变化与回读证据顺序一致，跳过与未可用没有被标成完成。本篇不运行实际协调器。

适用边界

状态名与阶段顺序是教学模型，来源的具体角色链与强制工具不普遍适用。多个协调者同时写入需要实际一致性控制；记账不提供授权，也不证明所有产品要求已经覆盖。