06.事项状态：评审、进度和正式登记

1.一个“待处理”说不清全部事情

一项需求可能已经采纳，但没有实施授权；一项故障可能正在只读调查，但尚未进入正式台账；代码已经合并，业务验收仍可能没有完成。

把这些事实压成一个状态，会让使用者误以为采纳就是开工，让负责人误以为关闭就是已经上线，也让工具难以判断下一步。

HiveFlow分别描述评审状态、处理进度和正式登记身份，再另外核验实施授权与交付证据。

三个维度可以同时成立。例如：“已采纳（待实施授权）＋Ready＋未关联正式事项”，表示方向和验收已明确，负责人认可价值，但不能据此开始开发。

status:Unregistered只表示没有关联正式事项，不是“尚未评审”，也不是一种处理进度。

下面是对现有取值的解释，正式定义仍由HFL-005维护。

这是一组描述实际进展的取值，不要求每项工作机械走过所有状态。重复事项、暂缓事项和普通维护可能有不同路径，仍要留下明确承接或结束依据。

故障调查在原有只读许可内就可以进行，不需要先取得代码修改授权。如果显示In Progress，文字应说明当前在调查什么，避免让用户以为开发已经开始。

同理，已采纳但等待执行许可的事项不能仅为显得有进展而改成开发中。状态应描述发生的事实，而不是团队希望它尽快发生的事情。

用户看到的公开摘要还需要符合当前受众范围。私有决定原话或内部操作详情不会因为状态可公开就一起公开。

GitHub Issue编号与仓库中的ISSUE-xxxxxx属于不同标识。相同数字不能证明二者对应，必须查到真实映射。

已经关联的事项，其正式处理进度以正式台账为准。在相应授权内单向同步到GitHub中按约定维护的摘要，不能用GitHub里的临时文字反向覆盖台账。

独立评审字段保留在自己的位置。更新采纳状态时，要保留正式摘要、登记身份、原反馈和无关标签，不把整份正文覆盖成另一套模板。

提交、PR、合并、部署和验收是可以核验的交付事实，不需要再为它们新增一串平行进度标签。

有这些依据后，任何接手者都能判断真实剩余项，而不是看到Issue仍open就从头再做。

暂缓保留实际处理进度，在获准位置说明恢复条件；条件未知就保留未知，不虚构时间表，也不自行创建提醒。

不采纳只说明评审决定。负责人如果仅批准更新对应评审字段，工具就不能顺便追加评论、改标签、关闭Issue或更新正式台账。

完整交付的授权明确包含必要正式记录与本单关单，并且约定验收满足时，按仓库规则准确收尾。关单结果要独立读回；写入未知先查原结果，不重复操作。

可以用一句并列事实代替术语堆叠：

这项需求已经采纳，目标和验收已经整理清楚；当前尚未获准实施，也还没有关联正式事项记录。

或者：

修改已合并并部署到约定环境，导出验收通过；正式记录已更新，原群回执仍待确认。

这种表达同时保留进展和限制。读者不用理解所有内部字段，也能知道接下来还差什么。