Files
EP-Hub-Skill/etunel-role-collaboration/references/exceptions-and-coordination.md
T

9.5 KiB

异常与协调

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

缺失信息

成员按以下顺序处理:

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

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

结果不完整

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

错投与职责冲突

成员保留本角色已完成部分,向 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. 未批准不得边评估边实施,也不得用状态纠正规避变更。

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

成果豁免

固定正式成果不适用时,按 成果与完成判定 发起《成果豁免申请》。不适用、延期、跳过、口头同意或空文件都不能替代正式豁免。

受控跳转、暂缓与回退

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

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

项目文件与进度留档 保留来源阶段与目标阶段记录,不移动或覆盖旧成果。跳转是流程状态,不是专业批准,也不保证可以发布。

模拟与流程验证项目

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

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

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

真实授权事项

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

信息披露

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