08.交付与回执：把结果带回原反馈者

1.让结果回到最初提出问题的人

开发者通常能看到PR和部署记录，原群用户却不一定知道它们。因此，交付流程还需要回答：该把什么结论，送回哪个可信来源，怎样知道发送结果？

HiveFlow用真实来源关联把准确仓库和Issue绑定到原反馈来源，再用稳定的交付标识核对同一次结果。公开摘要只包含适合该群的必要结论。

这项安排分别保存业务完成和通知状态。合并、部署、验收、消息受理、平台确认与用户已读，各自有自己的证据。

新Issue创建成功并读回后，群入口应在原请求仍有效时及时建立长期来源关联，核验真实桥接的确认。不能等跨天交付完成才回头猜原来的群。

这份关联由桥接私有状态维护，指向唯一原来源。它不会因为另一个群也讨论同题，就允许转发那边的内容或把结果改投过去。

如果关联建立失败，事项仍然可能已经登记。此时照实给登记答复，并说明长期来源未确认；不能因为工单有链接就承诺以后一定可以回群。

Issue是统一交付事实的主记录，关联PR沿用同一稳定deliveryId。这个字段用于识别同一次交付，不因超时、恢复或重试另造一个编号。

离线校验器可以判断结构，无法证明记录里的测试、作者、部署和验收真实。消费者仍要交叉核对真实工具返回的事实，并重新审阅公开摘要。

只有PR待审时，不写最终完成记录。没有PR的任务也不能伪造一个PR，而要在可信本人通道核验实际完成范围，再按已有规则处理。

新交付默认在原任务范围内，通过既有HTTP回执入口查询可信来源和发送状态，最终条件满足后将必要脱敏摘要回原群。调用方不指定任意收件群，也不从Issue正文取得网络配置。

先核对交付、验收与同一交付标识

确认可信原来源，审阅允许公开的摘要。

再查状态已确认跳过，处理中跟进

只有从未尝试、没有未知操作且条件满足时提交一次。

遇到未知停止通知并报告缺口

不换标识、受众或路径重发；通知结果与业务交付分别记录。

无有效绑定时，已经完成的交付正常结束并注明通知未发。无法区分缺绑定还是准入失败时，写“未能确认”，不能把未知说成确实没有。

既有交付可能已经选择PR完成评论唤醒dots，由dots核验后通知原群。这条路径与新的默认HTTP路径要避免重复使用。

共享交付标识和去重记录有助于核对，但不能阻止所有参与者同时操作，也不能保证外部动作恰好执行一次。参与者仍须遵守发送前核验和未知停止规则。

accepted表示服务已经持久接收或识别了同一交付；pending或sending表示已受理后等待或处理中；wecom_ack表示企微平台确认；它们都不能证明用户已读。

not_found只表示该交付标识无记录。只有确认从未尝试、没有未知操作，而且最终条件满足时，才可能提交一次；不能换新标识得到not_found后绕过原未知结果。

unknown、冲突、超时或拒绝都要求先核验。改正文、换群、换路径或换标识，不会使原来的不确定消失。

摘要回答三个问题：什么问题已经得到怎样的处理，依据是什么，使用者还需要知道什么限制。

合成示例：

关于导出只到第一页的问题，约定环境中的修复已完成，按原操作验收已包含筛选范围内的全部结果。尚未验证的其他使用场景没有计入本次通过范围。

实际表述必须来自真实证据。私有源码、内部地址、群身份、凭据、原始日志和私人评审正文不随摘要发出，Issue里已经写过也不等于可原样转发。

最终报告可以说明“业务交付完成，原群回执未确认”，并列具体缺口。这不会触发重新开发、撤销已完成结果或擅改事项状态。

在允许的本人通道可提供一份适合转发的脱敏摘要，由本人自行决定是否手工发送。提供摘要、本人确认已转发、桥接确认和用户已读分别记录，不把其中一项冒充另一项。

后续仅补正式记录或关单时，已经确认的原回执不再重发。需要真实通知验证时也不重复已完成事项，不为凑成功制造新的测试工单或补绑历史来源。