技术负责人依据产品定义基线，结合阶段 2 已有评审结论组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。测试提交测试计划，无问题时由项目Hub汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先经项目Hub转交相关角色确认，由测试修订计划后再汇总确认。
技术负责人依据产品定义基线，结合阶段 2 已有评审结论组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试依据同一产品基线，对方案和接口约束完成多轮确认。测试提交测试计划，无问题时由项目Hub汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先经项目Hub转交相关角色确认，由测试修订计划后再汇总确认。
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F3.1–3.3 | 阶段 2 门禁通过，产品定义基线有效。 | 项目Hub ↔ 技术负责人/协作角色 | 按主责角色分别形成的正式成果草案：技术负责人输出 软硬件接口契约；总体技术方案、架构决策记录为选填。测试按任务编制 测试计划，包含测试标准、测试用例范围、测试项，并在 F3.7 提交。 协作输入：硬件完成接口与约束确认。 输入内容：阶段2三类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录（如有）、设计范围和时限。 | 方案设计不得依赖尚未形成的 项目计划；所有设计必须引用同一产品基线。 | 开启并行方案设计。 |
| F3.4 | 嵌入式应用层需要新的资源、HAL 或协议。 | 嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人 | 修订对象：软硬件接口契约；已提供的总体技术方案、架构决策记录。 提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。 | 不得绕过契约直接约定。 | 可能触发契约修订。 |
| F3.5 | 嵌入式底层依赖引脚、电平、器件或时序。 | 嵌入式底层 → 项目Hub → 硬件 / 技术负责人 | 修订对象：软硬件接口契约；已提供的架构决策记录。 提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。 | 涉及既有板卡时引用明确版本；新设计注明约束版本。 | 冲突时阻塞相关设计。 |
| F3.6 | 器件、PCB、电源、空间或热约束影响方案。 | 硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品 | 关联或修订成果：软硬件接口契约；必要时同步修订已提供的 总体技术方案、架构决策记录。 过程记录：硬件约束与接口确认。 提交内容：限制、替代方案、成本、性能和交期影响。 | 器件替换不得静默发生。 | 更新接口与约束确认；改变正式基线时走变更申请。 |
| F3.1–3.3 | 阶段 2 门禁通过，产品定义基线有效。 | 项目Hub ↔ 技术负责人/协作角色 | 按主责角色分别形成的正式成果草案：技术负责人按需提供总体技术方案、架构决策记录。测试按任务编制 测试计划，包含测试标准、测试用例范围、测试项，并在 F3.7 提交。 过程记录：技术负责人提交设计要点与待确认接口约束，各相关角色完成接口与约束确认。 输入内容：阶段2三类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录（如有）、设计范围和时限。 | 方案设计不得依赖尚未形成的 项目计划；所有设计必须引用同一产品基线。 | 开启并行方案设计。 |
| F3.4 | 嵌入式应用层需要新的资源、HAL 或协议。 | 嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人 | 过程记录：接口需求及确认结果。 关联或修订成果：已提供的总体技术方案、架构决策记录。 提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。 | 接口调整经项目Hub转交相关角色确认，不得私下约定。 | 更新接口确认结果；改变正式基线时走变更申请。 |
| F3.5 | 嵌入式底层依赖引脚、电平、器件或时序。 | 嵌入式底层 → 项目Hub → 硬件 / 技术负责人 | 过程记录：接口与硬件约束确认。 关联或修订成果：已提供的架构决策记录。 提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。 | 涉及既有板卡时引用明确版本；新设计注明约束版本。 | 冲突时阻塞相关设计。 |
| F3.6 | 器件、PCB、电源、空间或热约束影响方案。 | 硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品 | 关联或修订成果：必要时修订已提供的总体技术方案、架构决策记录。 过程记录：硬件约束与接口确认。 提交内容：限制、替代方案、成本、性能和交期影响。 | 器件替换不得静默发生。 | 更新接口与约束确认；改变正式基线时走变更申请。 |
| F3.7 | 测试已形成测试计划，或识别出不可测试项、环境/治具缺口。 | 测试 → 项目Hub；无问题时汇总给技术负责人；有缺口时定向转交相关角色确认 | 正式成果：测试计划，包含测试标准、测试用例范围、测试项。 存在缺口时附带：不可测试项、环境/治具缺口、影响、依据及需要相关角色确认的问题。 确认回传：相关角色经项目Hub返回确认结果，测试据此修订测试计划；涉及接口或验收标准时同步对应主责角色修订。 | 无问题时无需等待缺口确认；项目Hub只汇总和中继，不代替专业角色确认。测试仍主责计划编制与修订，技术负责人经 F3.8–F3.9 确认测试计划。影响本阶段门禁的缺口应先关闭；验证期需跳转时，由负责人明确记录决定。 | 无问题：进入 F3.8–F3.9 汇总确认；有缺口：先定向确认、修订，再返回该确认路径。 |
| F3.8–3.10 | 专业评审完成。 | 项目Hub ↔ 技术负责人；项目Hub ↔ 各相关角色 | 最终确认成果：软硬件接口契约、测试计划的内部确认版本，以及已提供的选填成果（总体技术方案、架构决策记录）。 附带内容：角色确认、保留风险、证据引用和统一版本关系。 | 测试计划仍由测试编制和维护，技术负责人确认其与整体方案、接口及实施依赖一致；相关角色按本领域完成最终确认。每个确认绑定同一版本；选填成果未提供不阻塞本阶段；成员角色之间不直接通信。 | 全部确认并登记为正式基线后进入阶段 4 项目规划。 |
| F3.8–3.10 | 专业评审完成。 | 项目Hub ↔ 技术负责人；项目Hub ↔ 各相关角色 | 最终确认成果：测试计划的内部确认版本，以及已提供的选填成果（总体技术方案、架构决策记录）。 附带内容：方案与接口确认结果、保留风险、证据引用和统一版本关系。 | 测试计划仍由测试编制和维护，技术负责人确认其与整体方案、接口及实施依赖一致；相关角色按本领域完成最终确认。每个确认绑定同一版本；选填成果未提供不阻塞本阶段；成员角色之间不直接通信。 | 全部确认并登记为正式基线后进入阶段 4 项目规划。 |
三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进；硬件先取得并核对器件规格书和结构板框图，形成并确认硬件设计包后再据此实施；固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，项目Hub维护其与硬件版本的唯一映射。
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F5.1 | 阶段 4 项目规划门禁通过。 | 项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件 | 待产出成果：嵌入式应用层固件包、嵌入式底层实现资料、硬件设计包、硬件实现资料。 输入与任务：阶段3已确认的必需成果及已提供的选填成果、阶段4 项目计划（项目任务计划）、角色分工、项目风险，以及任务、输出格式、依赖和期限。 硬件额外输入：F5.2 所列器件规格书和结构板框图。 | 三方必须使用相同契约和项目计划版本；硬件输入未齐时先补齐资料，不阻塞其他依赖已满足的任务。 | 依赖已满足的实现任务并行启动。 |
| F5.2–5.3 | 硬件已取得并核对 F5.2 所列输入资料，形成或修订硬件设计包；后续发布样机、板卡、BOM 或 ECO。 | 硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试 | 前置输入：项目实际使用的外设器件和关键器件规格书、结构板框图（主要器件位置和禁止限制区域），具体清单见本阶段 F5.2 硬件资料要求。 正式成果：硬件设计包与硬件实现资料，分别登记版本。 硬件设计资料（纳入硬件设计包）：原理图；PCB 源文档；贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）；接口定义。先由硬件负责人确认，再经项目Hub中继技术负责人及受影响角色完成技术与接口确认。 实现资料：引用已确认的硬件设计包文件索引和版本，不重复提交原理图、PCB 源文档、贴片资料或接口定义。仅补充实施记录（板卡/样机制作、装配与返修情况）、调试记录（板级调试、测量证据、已知问题与处置）和版本记录（板卡/样机/批次标识、BOM/ECO 修订号、与底层/应用固件/配置/接口契约的版本关系及替代关系）。 | 所需输入资料未齐备或版本未核对时，先经项目Hub补齐，不得提交正式硬件设计包或硬件实现资料；设计包确认前不得投板或以未确认设计推进样机制作；没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。 | 输入缺失时阻塞相关硬件任务；影响接口、底层或应用固件时阻塞受影响任务。 |
| F5.4–5.5 | 嵌入式底层已形成硬件功能测试报告，BSP 与 PSP 输出路径可访问且版本明确。 | 嵌入式底层 → 项目Hub → 嵌入式应用层 | 正式成果：嵌入式底层实现资料 当前版本。 必需内容：硬件功能测试报告；BSP 输出路径；PSP 输出路径。 选填内容：WiFi 设备定频测试固件。 附带信息：输出版本、适配板卡、BOM/ECO、配置和接口契约版本，以及必要的应用层集成说明、已知限制和风险。 | BSP/PSP 路径必须指向可访问的实际输出；硬件功能测试报告记录底层已执行的硬件功能测试，不代替测试角色的整机质量结论。WiFi 设备定频测试固件为非必选项，未提供不阻塞合版、提测或阶段推进，也无需另行豁免；提供时标明 TEST_UTILITY_ONLY，仅用于专项测试，不得作为最终提测或发布固件。 | 项目Hub登记必需成果后，将 BSP/PSP 可消费版本交嵌入式应用层合版。 |
| F5.6 | 嵌入式应用层收到已登记的嵌入式底层可消费版本。 | 嵌入式应用层 → 项目Hub | 正式成果候选：嵌入式应用层固件包。 提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、zn_debug文件、Changelog、串口使能证书，以及应用/底层/板卡/契约版本链。 | 必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。 | 进入软硬件联调候选。 |
| F5.7 | 引脚、时序、资源、器件或协议冲突。 | 角色 → 项目Hub → 技术负责人 | 过程记录：实现冲突记录。 关联成果：受影响的 硬件设计包、硬件／底层／应用实现成果 和 接口契约；提交冲突、证据、版本、影响和建议。 | 项目Hub立即冻结受影响版本。 | 等待技术裁决或契约新版本。 |
| F5.8–5.10 | 统一固件候选和硬件候选均已提交，联调问题已经关闭。 | 项目Hub ↔ 嵌入式应用层 / 硬件 / 技术负责人 | 最终确认成果：嵌入式应用层固件包、硬件实现资料；引用已确认的 硬件设计包 和已集成的 嵌入式底层实现资料。 过程记录：版本矩阵、集成记录、集成批准；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。 | 最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。 | 确认后由项目Hub将该唯一固件版本交给测试。 |
| F5.1 | 阶段 4 项目规划门禁通过。 | 项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件 | 待产出成果：嵌入式应用层固件包、嵌入式底层实现资料、硬件设计包。 输入与任务：阶段3已确认的必需成果及已提供的选填成果、阶段4 项目计划（项目任务计划）、角色分工、项目风险，以及任务、输出格式、依赖和期限。 硬件额外输入：F5.2 所列器件规格书和结构板框图。 | 三方必须使用相同的方案设计基线和项目计划版本；硬件输入未齐时先补齐资料，不阻塞其他依赖已满足的任务。 | 依赖已满足的实现任务并行启动。 |
| F5.2–5.3 | 硬件已取得并核对 F5.2 所列输入资料，形成或修订硬件设计包；后续发布样机、板卡、BOM 或 ECO。 | 硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试 | 前置输入：项目实际使用的外设器件和关键器件规格书、结构板框图（主要器件位置和禁止限制区域），具体清单见本阶段 F5.2 硬件资料要求。 正式成果：硬件设计包，登记明确版本。 硬件设计资料（纳入硬件设计包）：原理图；PCB 源文档；贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）；接口定义。先由硬件负责人确认，再经项目Hub中继技术负责人及受影响角色完成技术与接口确认。 | 所需输入资料未齐备或版本未核对时，先经项目Hub补齐，不得提交正式硬件设计包；设计包确认前不得投板或以未确认设计推进样机制作；没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。 | 输入缺失时阻塞相关硬件任务；影响接口、底层或应用固件时阻塞受影响任务。 |
| F5.4–5.5 | 嵌入式底层已形成硬件功能测试报告，BSP 与 PSP 输出路径可访问且版本明确。 | 嵌入式底层 → 项目Hub → 嵌入式应用层 | 正式成果：嵌入式底层实现资料 当前版本。 必需内容：硬件功能测试报告；BSP 输出路径；PSP 输出路径。 选填内容：WiFi 设备定频测试固件。 附带信息：输出版本、适配板卡、BOM/ECO、配置及适用的接口定义版本，以及必要的应用层集成说明、已知限制和风险。 | BSP/PSP 路径必须指向可访问的实际输出；硬件功能测试报告记录底层已执行的硬件功能测试，不代替测试角色的整机质量结论。WiFi 设备定频测试固件为非必选项，未提供不阻塞合版、提测或阶段推进，也无需另行豁免；提供时标明 TEST_UTILITY_ONLY，仅用于专项测试，不得作为最终提测或发布固件。 | 项目Hub登记必需成果后，将 BSP/PSP 可消费版本交嵌入式应用层合版。 |
| F5.6 | 嵌入式应用层收到已登记的嵌入式底层可消费版本。 | 嵌入式应用层 → 项目Hub | 正式成果候选：嵌入式应用层固件包。 提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、zn_debug文件、Changelog、串口使能证书，以及应用/底层/板卡版本链及适用的接口定义版本。 | 必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。 | 进入软硬件联调候选。 |
| F5.7 | 引脚、时序、资源、器件或协议冲突。 | 角色 → 项目Hub → 技术负责人 | 过程记录：实现冲突记录。 关联成果：受影响的硬件设计包、嵌入式底层实现资料、嵌入式应用层固件包及相关接口约束；提交冲突、证据、版本、影响和建议。 | 项目Hub立即冻结受影响版本。 | 等待技术裁决及相关设计、接口约束更新。 |
| F5.8–5.10 | 统一固件候选和硬件候选均已提交，联调问题已经关闭。 | 项目Hub ↔ 嵌入式应用层 / 硬件 / 技术负责人 | 最终确认成果：嵌入式应用层固件包、硬件设计包；引用已集成的嵌入式底层实现资料。 过程记录：版本矩阵、集成记录、集成批准；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。 | 最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。 | 确认后由项目Hub将该唯一固件版本交给测试。 |
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F6.1–6.2 | 技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。 | 项目Hub ↔ 测试 | 测试输入：嵌入式应用层固件包、硬件实现资料、已集成的 嵌入式底层实现资料、版本矩阵、测试计划。 必需成果草案：功能测试报告、缺陷清单。 选填成果：可靠性测试报告、专项测试报告、提测佐证。 提测佐证内容（选填）：平台要求的视频、截图、log材料。 佐证提交方式：提供时只向项目Hub登记文件索引、版本和交付状态；文件由测试直接交付产品，F7.1 确认接收。 | 测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。 | 启动测试并更新测试状态。 |
| F6.1–6.2 | 技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。 | 项目Hub ↔ 测试 | 测试输入：嵌入式应用层固件包、硬件设计包、已集成的 嵌入式底层实现资料、版本矩阵、测试计划。 必需成果草案：功能测试报告、缺陷清单。 选填成果：可靠性测试报告、专项测试报告、提测佐证。 提测佐证内容（选填）：平台要求的视频、截图、log材料。 佐证提交方式：提供时只向项目Hub登记文件索引、版本和交付状态；文件由测试直接交付产品，F7.1 确认接收。 | 测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。 | 启动测试并更新测试状态。 |
| F6.3 | 测试发现缺陷或测试异常并形成可追踪记录。 | 测试 → 项目Hub → 实际相关角色 | 提交与更新成果：测试主责的《缺陷清单》。 分发内容：缺陷编号、现象、状态、模块、版本、环境、用例、复现、证据、影响、风险、优先级和回归要求。 商议结果：缺陷责任人、主责角色、协作角色及处理时限。 | 测试与实际相关角色的负责人共同商议解决缺陷的责任人，每项缺陷明确一名责任人和一个主责角色。项目Hub只登记已确认的分工并路由，不自行指定责任人；跨层技术问题由技术负责人提供判断依据，需求含义由产品澄清。分歧未收敛时按 E.1–E.4 协调。 | 确认缺陷责任分工后，建立定向修复或专业澄清任务。 |
| F6.4–6.5 | 相关负责人已共同确认缺陷责任人，责任角色收到缺陷任务。 | 责任角色 / 技术负责人 / 产品 → 项目Hub → 测试 | 过程记录：确认的责任人、主责与协作角色、原因分析、修复计划或技术／产品决定，包含影响、修复方案、风险、修复成果计划、期限、需重测范围和证据。 测试动作：引用已确认的责任分工与修复输入，更新《缺陷清单》的责任人、状态和回归要求。 | 实现角色不直接替换或关闭测试主责的《缺陷清单》；“无法复现”“符合设计”或“不修复”必须带理由与证据；责任人调整仍需相关负责人共同确认。 | 阻断缺陷使阶段阻塞；等待修复成果和目标版本复验。 |
| F6.6–6.8 | 应用修复、嵌入式底层修复或硬件 ECO 已提交。 | 责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试 | 实现角色修订成果：嵌入式应用层固件包、嵌入式底层实现资料或硬件实现资料。 提交给测试的缺陷输入：原因分析、修复计划、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围；测试引用后更新《缺陷清单》。 硬件 ECO 额外内容：新旧板卡／PCB／BOM／ECO 差异、受影响批次、返工／回退方式、板级验证证据、底层驱动／HAL 兼容评估、应用固件有效性确认和新版本矩阵。 | 实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。 | 形成唯一可回归的固件与硬件版本矩阵，并由测试复验。 |
| F6.9 | 统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。 | 项目Hub → 测试 | 回归输入：更新后的 嵌入式应用层固件包、相关 嵌入式底层实现资料／硬件实现资料、缺陷清单、版本矩阵。 过程记录：回归任务，包含修复范围、受影响用例和时限。 | 旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。 | 执行定向回归。 |
| F6.6–6.8 | 应用修复、嵌入式底层修复或硬件 ECO 已提交。 | 责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试 | 实现角色修订成果：嵌入式应用层固件包、嵌入式底层实现资料或硬件设计包。 提交给测试的缺陷输入：原因分析、修复计划、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围；测试引用后更新《缺陷清单》。 硬件 ECO 额外内容：新旧板卡／PCB／BOM／ECO 差异、受影响批次、返工／回退方式、板级验证证据、底层驱动／HAL 兼容评估、应用固件有效性确认和新版本矩阵。 | 实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。 | 形成唯一可回归的固件与硬件版本矩阵，并由测试复验。 |
| F6.9 | 统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。 | 项目Hub → 测试 | 回归输入：更新后的 嵌入式应用层固件包、相关 嵌入式底层实现资料／硬件设计包、缺陷清单、版本矩阵。 过程记录：回归任务，包含修复范围、受影响用例和时限。 | 旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。 | 执行定向回归。 |
| F6.10 | 阻断缺陷清零且必需成果及其测试依据齐全。 | 测试 → 项目Hub | 最终确认成果：功能测试报告、缺陷清单的负责人确认版本。 已提供时一并确认：可靠性测试报告、专项测试报告、提测佐证。 附带内容：质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。 | 测试内部确认状态必须记录；剩余风险必须有接受方；选填成果未提供不作为门禁阻塞项。提测佐证提供时只登记索引、版本和测试负责人确认，无需向项目Hub上传大文件。 | 门禁通过并留档后开启验收。 |
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F8.1–8.2 | 阶段 7 平台验收和客户验收均已通过。 | 项目Hub ↔ 实际相关角色 | 收集资料：各阶段正式成果的当前有效版本、必要过程记录、变更记录、项目进度、成果索引和对应确认。 实现资料：已验收的应用层统一固件、被集成的底层版本、硬件设计包、硬件实现资料及匹配版本关系。 | 沿用已确认成果，不重新要求制作同内容文件；实际未参与的角色不虚构成果。测试直接交付产品的资料保留文件索引和产品接收确认，项目Hub无需收存或重复转交大文件。 | 形成结项资料清单与缺口清单。 |
| F8.1–8.2 | 阶段 7 平台验收和客户验收均已通过。 | 项目Hub ↔ 实际相关角色 | 收集资料：各阶段正式成果的当前有效版本、必要过程记录、变更记录、项目进度、成果索引和对应确认。 实现资料：已验收的应用层统一固件、被集成的底层版本、硬件设计包及匹配版本关系。 | 沿用已确认成果，不重新要求制作同内容文件；实际未参与的角色不虚构成果。测试直接交付产品的资料保留文件索引和产品接收确认，项目Hub无需收存或重复转交大文件。 | 形成结项资料清单与缺口清单。 |
| F8.3 | 各阶段资料与验收记录已收集。 | 项目Hub ↔ 产品 / 业务 | 核对内容：产品确认的平台验收报告或结论、业务确认的客户验收通过报告、遗留问题清单。 承接信息：未关闭问题、风险、责任人、期限和后续跟进方式。 | 只核对已有双线验收结果，不重新给平台增加业务批准；遗留事项必须已关闭或有明确承接。 | 确认结项范围与后续责任。 |
| F8.4–8.5 | 项目事实、阶段成果及主要问题已整理。 | 项目Hub → 实际相关角色 → 项目Hub | 复盘输入：目标完成情况、计划与实际偏差、协作与质量问题、有效经验和改进建议。 输出：各角色确认的复盘结论与改进项，汇入《流程闭环总结》。 | 复盘基于已有事实和记录，不把未执行的验证写成已完成；改进项说明责任人和跟进安排。 | 完成项目复盘并形成可跟进的改进项。 |
| F8.6 | 资料收集、验收核对和项目复盘完成。 | 项目Hub → 归档库 | 正式成果：结项资料归档、变更记录、结项报告、流程闭环总结。 汇总内容：最终资料索引、有效版本、阶段确认、验收结论、复盘经验、改进项与遗留责任。 | 保留历史版本和引用，不以完整聊天记录代替项目档案；选填成果未提供不作为归档阻塞项。 | 形成可追溯的结项包。 |