125 lines
8.1 KiB
Markdown
125 lines
8.1 KiB
Markdown
# 异常与协调
|
||
|
||
出现缺失信息、错投、职责冲突、阻塞、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 Agent 跨角色通信都经 Hub；现阶段没有成员直连。
|
||
|
||
## 缺失信息
|
||
|
||
成员按以下顺序处理：
|
||
|
||
1. 检查任务和本会话已有的已确认资料；
|
||
2. 一次向本角色负责人列清缺什么、用途、影响和建议来源；
|
||
3. 负责人能回答时记录来源、时间、范围和条件后继续；
|
||
4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
|
||
5. 线下结果回到本角色会话，经本角色负责人确认；
|
||
6. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题或正式阻塞。
|
||
|
||
Hub 有登记答案时直接补足；没有时只向实际信息所有者角色创建必要查询或任务。取得确认结果后返回原任务，不广播无关角色。
|
||
|
||
## 结果不完整
|
||
|
||
- 原任务目标不变；Hub 只列缺失成果、字段、证据、版本、自审或确认。
|
||
- 已终态任务使用关联的新 SUBTASK_ID 补齐；有效部分保留，不要求无关重做。
|
||
- 补齐后按原契约重新校验。
|
||
- Hub 不用推测补专业结论，也不为一个格式字段增加虚假评审层。
|
||
|
||
## 错投与职责冲突
|
||
|
||
成员保留本角色已完成部分，向 Hub 说明错误身份／成员、越界内容、影响和建议责任方。Hub 按决定权路由：
|
||
|
||
- 目标、业务范围、优先级、资源、组织授权和最终业务风险接受：业务；
|
||
- 产品行为、需求含义、用例与验收标准：产品；
|
||
- 总体架构、跨层接口、技术取舍、依赖与集成：技术负责人；
|
||
- 应用逻辑、状态机、应用协议和应用服务：嵌入式应用层；
|
||
- BSP、Bootloader、驱动、RTOS、系统服务和 HAL：嵌入式底层；
|
||
- 电路、PCB、器件、BOM、电源、信号、热和板卡：硬件；
|
||
- Test Plan、环境、用例、证据、缺陷复验与质量结论：测试；
|
||
- 已登记自定义领域：按其角色契约，不隐式夺取默认角色权责。
|
||
|
||
跨多个领域时，技术负责人界定接口和依赖；每项后续任务仍只有一个主责角色和成员。
|
||
|
||
## 阻塞与异常提醒
|
||
|
||
正式阻塞说明原因、已完成成果、负责人沟通、线下协调、影响、需要谁采取什么动作以及恢复条件。
|
||
|
||
- Hub 评估关键路径；不受影响的任务继续。
|
||
- Hub 主动提醒当前主责和实际关联角色，提供问题、证据、冲突点、影响、原流程位置、所需回应和期限；不机械通知全体角色。
|
||
- 能由一个角色解决时只派该角色；多个独立问题可形成波次。
|
||
- 没有现成责任人时提醒当前负责人线下找能解决问题的人。
|
||
- 需要用户、业务、项目发起人或重大争议决定时，Hub 负责人介入。
|
||
- 阻塞解除后，终态任务使用关联的新 SUBTASK_ID。
|
||
|
||
Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞；正常排队和等待不是阻塞。
|
||
|
||
## 复杂线下会议与 Meeting Decision Record
|
||
|
||
普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞时：
|
||
|
||
1. Hub 准备问题包和结论模板，不主持专业裁决；
|
||
2. 当前主责角色的真人负责人组织线下会议；
|
||
3. 参与者把各自专业结论带回对应角色会话，完成角色负责人确认；
|
||
4. 当前主责角色汇总一份 Meeting Decision Record，至少包含参与角色、问题、证据、各专业确认、统一结论、适用范围、版本、不同意见、风险、行动项、责任人和期限；
|
||
5. 当前主责角色向 Hub 提交该记录及参与方确认引用，其他角色不重复提交整份记录；
|
||
6. Hub 只校验身份、确认、版本、证据、冲突和可执行性，登记后从原阻塞点恢复；
|
||
7. 结论改变正式基线时转入 Change Request。
|
||
|
||
会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认时仍保持阻塞。
|
||
|
||
## 缺陷与返工
|
||
|
||
1. 测试创建并持续维护 Defect Analysis Report，记录被测组合、环境、复现、期望／实际、证据、风险、建议责任边界、复验和状态。
|
||
2. 根因边界不清时由技术负责人确认系统边界、版本关系或架构影响；Hub 不自行归因。
|
||
3. Hub 向实际责任角色派发修复任务；相关缺陷可形成修复包，独立角色可形成修复波次。
|
||
4. 实现角色提交 Root Cause Analysis、Fix Plan、修复成果和版本、角色自测、影响与建议回归范围。
|
||
5. 底层修复先交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。
|
||
6. 技术负责人确认新版本组合后，测试在目标组合独立复验。
|
||
7. 只有测试可把 Defect Analysis Report 更新为 VERIFIED／CLOSED；实现角色和 Hub 无权替换或关闭。
|
||
|
||
产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。
|
||
|
||
## Change Request
|
||
|
||
任何改变已确认范围、方案、任务、正式成果、成员职责、接口、版本、排期或门禁的事项都走正式变更：
|
||
|
||
1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
|
||
2. 产品、技术负责人、实际受影响实现／自定义角色和测试分别评估；
|
||
3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
|
||
4. 需要组织授权的变更由业务批准、拒绝或延期；
|
||
5. 批准后创建新基线，保留旧版本和 supersedes，重开受影响阶段、成果、任务和门禁；
|
||
6. 未批准不得边评估边实施，也不得用状态纠正规避变更。
|
||
|
||
只联系真正受影响角色，不固定全角色参与。
|
||
|
||
## 成果豁免
|
||
|
||
固定正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起 Artifact Waiver。NA、DEFERRED、SKIPPED、口头同意或空文件都不能替代 WAIVED。
|
||
|
||
## 正式项目的受控跳转、暂缓与回退
|
||
|
||
正式项目只有在已有正式成果实际覆盖目标阶段并取得必要角色确认时才能受控跳转：
|
||
|
||
- 记录发起人、原因、时间、现阶段、目标位置、复用成果及版本、未满足项、影响、风险、批准和恢复点；
|
||
- 使用当前运行时支持的真实受控跳转、回退或 DEFERRED 状态；任何正式要求未被既有成果覆盖时都不能通过门禁，也不得用 BYPASSED_WITH_RISK 代替；
|
||
- Hub 负责人确认；影响范围、日期、资源、成本、质量、验收或专业结论时取得业务和相关角色确认；
|
||
- 下游明确知道缺失基线和风险；固定成果确实无需补做时另走 WAIVED。
|
||
|
||
跳转是流程状态，不是专业批准，也不保证可发布。
|
||
|
||
## 模拟／流程验证项目
|
||
|
||
只有用户明确对整个 WORK_ID 启用模拟后可使用：
|
||
|
||
- 可使用真实已知数据和为流程验证构造的数据；关键值标记 REAL 或 SIMULATED；
|
||
- 模拟值影响结论时，相关成果整体标记 SIMULATION_ONLY；
|
||
- 可按明确指令临时跳过或进入后续节点，并记录 BYPASSED_WITH_RISK、假设、风险和恢复项，不让门禁卡死流程验证；
|
||
- human owner 确认的是模拟使用和流程推进，不是数据真实性；
|
||
- 不静默切回正式模式，不让模拟结论进入客户承诺、真实测试或生产发布；
|
||
- 结束状态只能是 SIMULATION_COMPLETED，不能写 CLOSED、RELEASED、CUSTOMER_ACCEPTED 或 PRODUCTION_READY。
|
||
|
||
## 真实授权事项
|
||
|
||
真实人员、资源、预算、采购、业务范围、正式日期、项目暂停或取消需要授权时，Hub 提供事实、选项、建议、影响和最晚决定点，向有权业务负责人／项目发起人请求决定。未决定前保持真实等待或阻塞，不解释为默认批准。
|
||
|
||
## 信息披露
|
||
|
||
Hub 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品真人负责人按授权取得并回到对应角色会话；客户未作为已契约且已绑定角色时，Hub 不直接派发 Etunel 任务。
|