145 lines
13 KiB
Markdown
145 lines
13 KiB
Markdown
# 异常与协调
|
|
|
|
出现缺失信息、错投、职责冲突、阻塞、超时、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 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. 结论改变正式基线时转入《变更申请》。
|
|
|
|
会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认或关键分歧仍未解决时，保持原流程阻塞并明确升级项。登记结论后，Hub 向原流程及关联角色说明恢复点、后续动作和新时限，不以会议记录替代正式成果。
|
|
|
|
## 超时提醒与升级
|
|
|
|
确认或任务超过约定时间时（X.6），Hub 发起升级通知，而不只是更新状态：
|
|
|
|
1. 核对原约定及当前事实，列明逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。
|
|
2. 专业事项定向交对应角色；项目级组织授权事项交业务。接收角色与本角色真人负责人内部确认后，统一向 Hub 回复决定、条件及处理安排。
|
|
3. 测试结果或成果豁免仍由 Hub 对应真人项目负责人作原定决定，不能因超时改由业务或 AI 代批；授权内资源与排期仍交产品确认。
|
|
4. Hub 登记回复并按原流程检查恢复条件；未取得必要确认或问题未解除时，保持等待确认或阻塞，不把沉默、逾期或新期望时间视为批准、延期已获准或任务完成。不受影响的任务继续。
|
|
|
|
时限沿用已确认计划或请求，不自行规定固定催办频率、启动定时器或重造运行时提醒机制。没有约定时间时先澄清，不能凭空认定逾期。
|
|
|
|
## 缺陷与返工
|
|
|
|
1. 测试创建并持续维护《缺陷清单》，记录 bug 条目、状态、模块、责任人，并保留定位、修复与复验所需的被测版本和证据。
|
|
2. 测试与相关负责人共同商议解决缺陷的责任人及协作边界；根因边界不清时，技术负责人提供系统边界、版本关系或架构影响判断，不代替共同商议。Hub 不自行归因或指定责任人。
|
|
3. 责任角色先向 Hub 返回原因与修复计划（F6.4）；Hub 登记共同确认的责任人和唯一主责角色，向责任角色派发修复任务，并把确认结果同步给测试维护缺陷清单（F6.5）。相关缺陷可组成修复包，独立角色可形成修复波次。
|
|
4. 实现角色按派发任务提交修复成果和版本、角色自测、影响与必要变更说明，不替测试提交或维护清单。
|
|
5. 底层修复先经 Hub 交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。即使不修改固件，应用层也须确认旧固件对新硬件仍有效，并更新匹配记录。
|
|
6. 回归版本通过 Hub 校验，必要时由技术负责人确认版本矩阵后，Hub 以统一固件、版本矩阵、缺陷清单及必要变更说明派发回归；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验。此处技术确认按需触发，不增加每轮必审；阶段 5 最终提测版及阶段 6 初始准入仍须技术负责人确认。
|
|
7. 只有测试可以确认缺陷已经复验或关闭；实现角色和 Hub 无权替换或关闭测试记录。
|
|
|
|
测试已完成且无缺陷时仍提交功能测试报告和零缺陷清单，直接进入最终结果人工确认，不安排空修复任务。退回或修复形成新结果后按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 重新确认，才能检查正式验收准入。
|
|
|
|
产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。
|
|
|
|
## 变更申请
|
|
|
|
任何改变已确认范围、方案、任务、正式成果、角色职责、接口、版本、排期或门禁的事项都走正式变更：
|
|
|
|
1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
|
|
2. 产品、技术负责人、实际受影响实现或自定义角色和测试分别评估；
|
|
3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
|
|
4. 授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时再由业务批准、拒绝或延期，其他专业决定仍由有权角色确认；
|
|
5. 取得适用权限的确认或批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；拒绝或延期则维持原基线；
|
|
6. 未取得必要确认或批准不得边评估边实施，也不得用状态纠正规避变更。
|
|
|
|
只联系真正受影响角色，不固定全角色参与。变更决定记录授权依据、有权角色及负责人、决定时间；受影响文件、新旧版本与项目状态同步更新并按阶段留档。
|
|
|
|
## 成果豁免
|
|
|
|
必须提交的正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起《成果豁免申请》。已标为选填的成果无需仅因未提交而办理豁免，也不得据此阻塞；已确认必须执行的测试或承诺不会因报告选填自动取消。必需成果的不适用、延期、跳过或空文件都不能替代正式豁免。Hub 校验申请后，所有成果豁免必须由项目负责人（项目Hub对应真人负责人）明确批准或拒绝，Hub AI 只登记与执行；不再设置独立下游征询、意见回传和业务高影响确认环节，所需事实与影响在申请中补齐。批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。
|
|
|
|
## 受控跳转、暂缓与回退
|
|
|
|
正常正式推进应先取得目标阶段需要的成果和确认。流程验证、紧急协调或负责人明确要求时，也可以在存在缺口的情况下跳转、回退或暂缓，但这只是改变当前流程位置，不代表缺失门禁已经通过：
|
|
|
|
- 记录发起人、原因、时间、现阶段、目标位置、复用成果及版本、未满足项、影响、风险、批准和恢复点；
|
|
- 使用当前运行时支持的真实跳转、回退或暂缓状态；任何正式要求未被成果覆盖时都不能伪装成门禁通过；
|
|
- Hub 负责人确认；影响授权范围内的资源与排期时取得产品确认，涉及预算、采购、对外承诺或业务范围时取得业务批准，质量、验收或其他专业结论由相应有权角色确认；
|
|
- 下游明确知道缺失基线和风险；记录后续补齐任务、责任角色和恢复条件；固定成果确认无需补做时另走成果豁免。
|
|
|
|
按 [项目文件与进度留档](project-files-and-progress.md) 保留来源阶段与目标阶段记录，不移动或覆盖旧成果。跳转是流程状态，不是专业批准，也不保证可以发布。
|
|
|
|
## 模拟与流程验证项目
|
|
|
|
只有用户明确对整个项目启用模拟后可使用：
|
|
|
|
- 可以使用真实已知数据和为流程验证构造的数据，清楚区分真实与模拟；
|
|
- 模拟值影响结论时，相关成果整体标记为模拟；
|
|
- 可以按明确指令临时跳过或进入后续节点，并记录假设、风险和恢复项，不让门禁卡死流程验证；
|
|
- 负责人确认的是模拟使用和流程推进，不是数据真实性；
|
|
- 不静默切回正式模式，不让模拟结论进入客户承诺、真实测试或生产发布；
|
|
- 结束状态只能表达“模拟完成”，不能表达真实关闭、发布、客户验收或生产就绪。
|
|
|
|
模拟文件和阶段记录必须明确标注，不能混入正式成果目录中的当前有效版本。
|
|
|
|
## 真实授权事项
|
|
|
|
需要真实授权时，Hub 提供事实、选项、建议、影响和最晚决定点。授权范围内的资源与排期调整交产品确认，可同步业务；涉及预算、采购、对外承诺、业务范围、项目暂停或取消时交有权业务负责人或项目发起人批准。未决定前保持真实等待或阻塞，不解释为默认批准。
|
|
|
|
## 信息披露
|
|
|
|
Hub 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品负责人按授权取得并回到对应角色会话；客户未作为已定义职责且已绑定的角色时，Hub 不直接派发 Etunel 任务。
|