13.附录A：术语、状态和常见问题
1.先分清几个常用词
本附录用于阅读时查词。执行中的字段、允许操作和精确条件，以各章末尾所列规范为准。
| 词语 | 在HiveFlow中表示什么 | 容易误解的地方 |
|---|---|---|
| 反馈 | 使用者提出的现象、问题或期望 | 不一定需要开发，也不一定需要建单 |
| 事项 | 需要持续跟踪的一件问题或需求 | 不是一整段聊天，也不是标题相似的一组任务 |
| Issue | GitHub中的事项记录 | 编号不能直接当成正式台账编号 |
| 采纳 | 负责人认可这件事值得做 | 不单独授予实施、部署或通知权限 |
| 实施授权 | 允许围绕明确目标，在指定范围内采取行动 | 不是对整个项目永久放开权限 |
| 交付终点 | 本次答应做到的最后一步 | PR待审与完整交付的终点不同 |
| PR | Pull Request，即供审阅和合并的改动请求 | 创建PR不等于改动已被接受或已经部署 |
| 验收 | 按约定条件核实原目标是否满足 | 测试脚本成功不能代替全部业务验收 |
| 正式登记 | 按照项目规则建立正式事项身份及其映射 | GitHub建单不自动完成正式登记 |
| 原来源 | 最初反馈发生的已确认会话和受众 | 不能用另一个群或相似聊天替代 |
| 回执 | 把允许公开的处理结果送回原来源 | 受理、平台确认、用户收到和已读分别记录 |
| 桥接 | 在工具或消息渠道之间传递允许的信息 | 不决定业务授权，也不证明业务验收通过 |
| 原生自动化 | 使用已有开发工具的定时任务能力 | 任务存在不等于已获准执行任何Issue |
| 受控采纳记录 | dots向Codex交接单项决定的固定私有记录 | 不是谁都可以写入的指令入口 |
| 认领 | 某次真实运行按条件占用这一项有效决定 | 本地打一个标记不等于服务端写入已生效 |
| 运行身份 | 识别实际执行实例的可核验标识 | 不能临时编造一个名字来通过认领 |
| 工作树 | 同一Git仓库中的独立工作目录 | 有独立目录不代表同一事项可以重复开发 |
| 源码快照 | 固定版本的源码副本及其索引 | 不证明运行环境已经部署这个版本 |
| 幂等 | 重复请求仍指向同一动作或结果，避免重复造成外部变化 | 不是发生超时后随意换一个编号重发 |
| 未知结果 | 现有证据不足以确认动作成功或失败 | 不能按失败处理并直接重试 |
2.三个状态家族不要混用
事项状态：描述业务事实
评审状态回答“是否采纳”，处理进度回答“推进到哪里”，正式登记身份回答“是否已进入正式台账”。三个维度可以独立变化，实施授权另行核验。
处理进度沿用八态：Reported（待确认）、Triage（待分流）、Ready（待处理）、In Progress（处理中）、Verification（待验证）、Closed（已关闭）、Not Planned（不处理）、Duplicate（重复）。
例如，“已采纳＋Ready＋未关联正式事项”并不矛盾：方向清楚、认可价值，但仍可能缺实施授权和正式登记。
采纳记录状态：描述一次交接
idle是空闲且执行关闭；pending是待认领；claimed是已认领；completed表示到达所选模式终点；blocked是已知受阻；unknown是结果尚不能确定；cancelled是认领前已经取消。
记录里的completed不能代替Issue的Closed，也不能代替验收。PR待审模式完成后，Issue通常还没有达到完整交付终点。
通知状态：描述消息传输
回执接口的accepted表示受理，pending和sending表示仍在处理，wecom_ack表示取得对应平台确认。not_found只描述该次查询没有找到记录，unknown表示结果不能确定。
这些状态都不能单独证明用户已读，也不能反过来修改研发验收结果。精确查询和恢复条件见第8章及HFL-007。
3.常见问题
HiveFlow是一个机器人吗？
HiveFlow首先是一套协作方法和执行规则。实际接入可以包含群助手、dots、Codex、GitHub和桥接服务。某个机器人只是其中一个入口，换了显示名或聊天界面不会自然获得新的权限。
它与ACDL有什么区别？
ACDL回答研发工作怎样形成清楚的需求、设计、实施、评审和交付依据。HiveFlow回答反馈怎样进来、谁决定做、如何把决定交给执行者、怎样把结果带回。一次研发可以同时使用两者，不能用其中一个绕开另一个。
我在群里说“帮我修一下”，会立即改代码吗？
不会仅凭群内请求取得开发授权。接收方可以在已有权限内调查、补问和登记。是否实施由可信负责人的决定及有效范围确定。
我回复“采纳”，是不是又要确认一遍？
先看原来的授权。如果只有价值判断，仍缺实施范围；如果本人已经批准有效的有界配置，新采纳又满足全部选单和认领条件，就可以在该范围内推进，不为同一目标的例行步骤反复确认。当前业务自动执行尚未启用。
Issue创建后，还是云端Dots负责开发吗？
蜂巢当前以Issue作为研发交接点，后续由Director的MacMini上的Codex承接。Director可以手动发起，也可以先批准并启用本机原生定时配置。dots可以保留源头采纳和群沟通，但不逐步调度本地研发；具体手动任务不需要返回dots重批。
手动只能提交PR，定时才是完整交付吗？
两组选择互相独立。手动和定时都可以选择PR待审，也都可以选择完整交付。PR待审完成后需要Director再介入一次处理合并、部署；完整交付则在有效完整授权内连续推进。定时配置当前仍未启用业务执行。
Director到底要介入几次？
只统计MacMini研发阶段，手动PR待审通常是启动1次、PR后再1次；手动完整交付通常是启动授权1次。有效定时配置内无需逐单手动发起，但PR待审仍需每单在PR后介入1次，完整交付不增加例行确认。源头采纳、配置准备、本人验收和例外另计，详见第3章次数对照。
一个缺陷可以先登记，再继续调查吗？
可以在符合建单条件时登记，但建单不是停止调查的理由。事实仍需追踪，已知证据、未知原因和补充信息应持续区分；咨询或尚未证明需要代码修改的问题，也不能一律变成开发任务。
为什么有了GitHub Issue，还要正式编号？
两者承担不同责任。Issue便于协作跟踪，正式编号用于项目要求的正式记录。只有核验映射后才能同步，不能因数字恰好相同就当成同一事项。也不能为每个普通维护动作强造一套正式对象。
PR待审之后，能直接告诉群用户已经修好了吗？
应说明“已准备修改，正在等待审阅”。这个终点还没有证明改动已经合并、部署或验收，因此不发送最终可用回执。
完整交付是否保证所有场景都测过？
完整交付要满足事先约定的必要验收，并披露实际范围。没有测过的浏览器、账号、设备或数据规模不能写成通过；必要检查缺失时不能宣布完成。约定范围以外的限制也应准确说明。
业务已经验收，但群消息失败了，还要重新开发吗？
不需要。保存业务结果，单独处理通知问题。只有原来源可信且通知条件满足，才能沿规定路径继续；结果未知先核查原动作，不换路径、换群或换身份重发。
可以把HTTP回执改成另一种消息接口吗？
不能在同一交付中因等待或超时自行切换。当前规定的HTTP与PR→dots路径按已确认条件选择，结果未知时先核验原路径。新通道接入涉及新的外部写操作，应先按仓库授权规则处理。
定时任务会扫描所有已采纳事项吗？
不会。明确清单只执行原批准事项；新采纳模式只考虑有效配置启用后符合条件的新决定，并完成受控记录核验与认领。不能回扫历史已采纳或已交付事项，也不能在一种选单方式不可用时自行回退到另一种。
暂停之后，之前发出的部署或消息会被撤回吗？
暂停阻止的是能够安全停止的后续动作。已经发出的外部调用可能继续完成，所以需要分别核实定时任务、取消请求、原运行和外部结果，不能承诺一句暂停就收回所有变化。
重启后可以新开一个任务从头做吗？
先查原运行、工作树、PR、部署和回执。确认已经完成的部分应复用，仍然未知的部分保留未知。恢复依赖原事实与仍有效的授权，不能借重启绕过认领或重新获得权限。
现在到底能用到什么程度？
规范、模板和离线检查已经形成，已有手动交付及单次原来源回执的实践。它们不能证明全部环境、重启恢复、不同来源和自动链路都通过。实际接入状态按第12章区分文档、模拟和现场证据，网站也应保留这种区别。
阅读本手册就足够执行了吗？
本手册帮助理解。真实任务仍从HFL-001按intake、review或delivery路线加载所需规范，并读取目标仓库的规则、当前版本和实际配置。网站与手册都不能替代这一步。
本章依据
- HFL-003：责任、授权与交付模式
- HFL-005：事项状态
- HFL-007：通知状态
- HFL-010：交接状态
- HFL-019：证据与未验收范围