# 异常与协调

出现缺失信息、错投、职责冲突、阻塞、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 Agent 跨角色通信都经 Hub；现阶段没有成员直连。

## 缺失信息

成员按以下顺序处理：

1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件；
2. 一次向当前负责人列清缺什么、用途、影响和建议来源；
3. 负责人能回答时记录来源、时间、范围和条件后继续；
4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
5. 线下结果回到本角色会话，经负责人确认；
6. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题或具体阻塞。

Hub 有登记答案时直接补足；没有时只向实际信息所有者角色创建必要查询或任务。取得确认结果后返回原任务，不广播无关角色。

## 结果不完整

- 原任务目标不变；Hub 只列缺失成果、内容、证据、版本、自审或确认。
- 已经有效的部分保留，不要求无关重做；未完成部分由 Hub 派发关联的后续任务。
- 补齐后按原要求重新校验。
- Hub 不用推测补专业结论，也不为一个格式问题增加虚假评审层。
- 影响进度或具有复盘价值的退回按 [项目文件与进度留档](project-files-and-progress.md) 记录。

## 错投与职责冲突

成员保留本角色已完成部分，向 Hub 说明错投或越界内容、影响和建议责任方。Hub 按决定权路由：

- 目标、业务范围、优先级、资源、组织授权和最终业务风险接受：业务；
- 产品行为、需求含义、用例与验收标准：产品；
- 总体架构、跨层接口、技术取舍、依赖与集成：技术负责人；
- 应用逻辑、状态机、应用协议和应用服务：嵌入式应用层；
- BSP、Bootloader、驱动、RTOS、系统服务和 HAL：嵌入式底层；
- 电路、PCB、器件、BOM、电源、信号、热和板卡：硬件；
- 测试计划、环境、用例、证据、缺陷复验与质量结论：测试；
- 已登记自定义领域：按其职责契约，不隐式夺取默认角色权责。

跨多个领域时，技术负责人界定接口和依赖；每项后续任务仍只有一个主责角色。

## 阻塞与异常提醒

正式阻塞用简明中文说明原因、已完成成果、负责人沟通、线下协调、影响、需要谁采取什么动作以及恢复条件。

缺口只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才是当前阻塞。提出方必须指明受影响的本阶段必需项和“为什么现在必须解决”；仅供后续阶段使用的资料登记为后续依赖，不阻塞当前阶段。

- Hub 评估关键路径；不受影响的任务继续。
- Hub 主动提醒当前主责和实际关联角色，提供问题、证据、影响、原流程位置、所需回应和期限；不机械通知全体角色。
- 能由一个角色解决时只派该角色；多个独立问题可以形成波次。
- 没有现成责任人时提醒当前负责人线下找能解决问题的人。
- 需要用户、业务、项目发起人或重大争议决定时，Hub 负责人介入。
- 阻塞解除后由 Hub 派发新的恢复或返工任务。

新发现的安全、合规或可能造成不可逆损失的风险尚待确认时，Hub 可以先暂停受影响工作，并立即请求对应专业负责人和 Hub 负责人判断；无关任务继续。确认后把结论写入本阶段完成约定和项目记录，再由有权方决定解决、延期、接受风险或恢复工作，不能让未经核实的担忧永久阻塞整个项目。

Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞；正常排队和等待不是阻塞。阻塞发生和解除都更新项目进度与阶段记录。

## 复杂线下会议与会议决定记录

普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞时：

1. Hub 准备问题包和结论结构，不主持专业裁决；
2. 当前主责角色的负责人组织线下会议；
3. 参与者把各自专业结论带回对应角色会话，完成负责人确认；
4. 当前主责角色汇总一份《会议决定记录》，包括参与角色、问题、证据、各专业确认、统一结论、适用范围、版本、不同意见、风险、行动项、责任人和期限；
5. 当前主责角色向 Hub 提交记录及参与方确认引用，其他角色不重复提交整份记录；
6. Hub 只校验来源、确认、版本、证据、冲突和可执行性，登记并留档后从原阻塞点恢复；
7. 结论改变正式基线时转入《变更申请》。

会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认时仍保持阻塞。

## 缺陷与返工

1. 测试创建并持续维护《缺陷分析报告》，记录被测组合、环境、复现、期望与实际、证据、风险、建议责任边界、复验和状态。
2. 根因边界不清时由技术负责人确认系统边界、版本关系或架构影响；Hub 不自行归因。
3. Hub 向实际责任角色派发修复任务；相关缺陷可以组成修复包，独立角色可以形成修复波次。
4. 实现角色提交根因分析、修复计划、修复成果和版本、角色自测、影响与建议回归范围。
5. 底层修复先交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。
6. 技术负责人确认新版本组合后，测试在目标组合独立复验。
7. 只有测试可以确认缺陷已经复验或关闭；实现角色和 Hub 无权替换或关闭测试记录。

产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。

## 变更申请

任何改变已确认范围、方案、任务、正式成果、角色职责、接口、版本、排期或门禁的事项都走正式变更：

1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
2. 产品、技术负责人、实际受影响实现或自定义角色和测试分别评估；
3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
4. 需要组织授权的变更由业务批准、拒绝或延期；
5. 批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；
6. 未批准不得边评估边实施，也不得用状态纠正规避变更。

只联系真正受影响角色，不固定全角色参与。变更决定、受影响文件和新旧版本按阶段留档。

## 成果豁免

固定正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起《成果豁免申请》。不适用、延期、跳过、口头同意或空文件都不能替代正式豁免。

## 受控跳转、暂缓与回退

正常正式推进应先取得目标阶段需要的成果和确认。流程验证、紧急协调或负责人明确要求时，也可以在存在缺口的情况下跳转、回退或暂缓，但这只是改变当前流程位置，不代表缺失门禁已经通过：

- 记录发起人、原因、时间、现阶段、目标位置、复用成果及版本、未满足项、影响、风险、批准和恢复点；
- 使用当前运行时支持的真实跳转、回退或暂缓状态；任何正式要求未被成果覆盖时都不能伪装成门禁通过；
- Hub 负责人确认；影响范围、日期、资源、成本、质量、验收或专业结论时取得业务和相关角色确认；
- 下游明确知道缺失基线和风险；记录后续补齐任务、责任角色和恢复条件；固定成果确认无需补做时另走成果豁免。

按 [项目文件与进度留档](project-files-and-progress.md) 保留来源阶段与目标阶段记录，不移动或覆盖旧成果。跳转是流程状态，不是专业批准，也不保证可以发布。

## 模拟与流程验证项目

只有用户明确对整个项目启用模拟后可使用：

- 可以使用真实已知数据和为流程验证构造的数据，清楚区分真实与模拟；
- 模拟值影响结论时，相关成果整体标记为模拟；
- 可以按明确指令临时跳过或进入后续节点，并记录假设、风险和恢复项，不让门禁卡死流程验证；
- 负责人确认的是模拟使用和流程推进，不是数据真实性；
- 不静默切回正式模式，不让模拟结论进入客户承诺、真实测试或生产发布；
- 结束状态只能表达“模拟完成”，不能表达真实关闭、发布、客户验收或生产就绪。

模拟文件和阶段记录必须明确标注，不能混入正式成果目录中的当前有效版本。

## 真实授权事项

真实人员、资源、预算、采购、业务范围、正式日期、项目暂停或取消需要授权时，Hub 提供事实、选项、建议、影响和最晚决定点，向有权业务负责人或项目发起人请求决定。未决定前保持真实等待或阻塞，不解释为默认批准。

## 信息披露

Hub 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品负责人按授权取得并回到对应角色会话；客户未作为已定义职责且已绑定的角色时，Hub 不直接派发 Etunel 任务。
