feat: 按 V0.16 统一角色协作 Skill 与 Hook 提醒

2026-09-08 09:42:05 +08:00
1 parent 08793151e1
commit 163f655cd0
@@ -8,16 +8,20 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 | 阶段 | 正式成果 |
 |---|---|
-| 1 业务需求 | 项目背景说明；项目目标与里程碑计划 |
-| 2 产品定义 | 立项资料；测试验收标准；里程碑要求 |
-| 3 方案设计 | 总体技术方案；软硬件接口契约；硬件设计包；架构决策记录；测试计划 |
-| 4 项目规划 | 项目计划；项目风险；角色分工；产品资料整合；项目状态内部记录 |
-| 5 软硬件实现 | 硬件实现资料；嵌入式底层实现资料；嵌入式应用层固件包 |
-| 6 测试验证 | 功能测试报告；可靠性测试报告；专项测试报告；测试证据包；缺陷分析报告 |
-| 7 业务验收 | 平台提测通过报告；客户验收通过报告；附条件验收事项 |
-| 8 发布结项 | 结项资料归档；变更记录；结项报告；流程闭环总结 |
+| 1 业务需求 | 项目背景说明；客户里程碑要求 |
+| 2 产品定义 | 立项资料（含平台 SDK、个参资料）；测试验收标准；里程碑要求；项目风险 |
+| 3 方案设计 | 测试计划；总体技术方案（选填） |
+| 4 项目规划 | 项目计划；角色分工；项目状态内部记录 |
+| 5 软硬件实现 | 硬件设计包；嵌入式底层实现资料；嵌入式应用层固件包 |
+| 6 测试验证 | 功能测试报告；缺陷清单；可靠性测试报告（选填）；专项测试报告（选填）；提测佐证（选填） |
+| 7 平台/客户验收 | 平台验收报告或结论；客户验收通过报告；遗留问题清单 |
+| 8 复盘结项 | 结项资料归档；变更记录；结项报告；流程闭环总结（项目复盘） |

-角色自定义文件可以作为支持材料、内部材料或额外成果，但不能替代适用的正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、《测试证据包》或《缺陷分析报告》，不另立正式成果类别。
+不单列软硬件接口契约、架构决策记录、硬件实现资料、产品资料整合、测试证据包或缺陷分析报告。项目风险由产品在阶段 2 汇总并维护，相关专业角色提供风险意见，后续阶段引用而非重复创建。必要接口确认、技术决定、实施或调试事实留在已有过程记录及实际成果中，不通过改名重新增加独立交付物。具体内容和责任见 [项目生命周期](project-lifecycle.md) 及对应角色职责。
+
+选填成果和选填栏目未提交不阻塞阶段推进，无需另行豁免；已提交时仍需版本登记和相关负责人确认。阶段 3 的硬件器件、PCB、电源/信号/热及接口约束为选填；阶段 5 硬件输入及设计包仍按本阶段要求交付。WiFi 设备定频测试固件亦为选填，仅用于专项测试。已批准的必测范围仍需执行，文件选填不能用来掩盖未验证结论。只有仍属必需的成果需要不适用/豁免时，才走后述豁免流程。
+
+角色额外材料不能替代必需正式成果，也不能自动成为门禁。功能测试报告写测试结论（通过/不通过）、用例执行结果和 bug log；无法形成结论时说明阻塞，不伪造通过。缺陷由测试维护在《缺陷清单》中，责任人由实际相关负责人共同确认。

 ## 先定义产出要求

@@ -57,7 +61,7 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 3. 成果生命周期；
 4. 成果适用性；
 5. 阶段与门禁；
-6. 测试结论；
+6. 测试结论（通过/不通过；无法判定时单独说明阻塞状态）；
 7. 业务验收结论；
 8. Etunel 消息或钉钉通知状态。

@@ -77,6 +81,18 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 负责人确认随对应文件、版本、适用范围和附带条件继续有效。Hub 归档、移动或引用同一成果不需要重新确认；只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。另一角色对该成果作新的专业评估时，仍须取得该角色自己的负责人确认。

+## 测试结果的项目负责人确认
+
+测试专业结论、测试结果提交完成、正式验收准入是三个不同判断。测试负责人确认专业结果后，还必须由 Hub 请求项目负责人（项目 Hub 对应的真人负责人）实际确认；此人不是新增 Agent 角色，不能由 Hub AI、测试 AI 或通知状态代替。
+
+1. 测试执行完成，阻断缺陷清零、必需成果与测试依据齐全、剩余风险有接受方，并完成专业自审及测试负责人确认后，向 Hub 返回功能测试报告、缺陷清单及已提供的选填成果信息（F6.10），标记“待项目负责人确认”，不宣称正式提交完成。大文件保留可查索引，不因人工确认而增加整包上传要求。
+2. Hub 核对当前版本、必需成果、质量结论和剩余风险，再请求自己的真人负责人确认（F6.11）。记录真实的确认或退回意见（F6.12），包括确认人、时间、成果与被测版本、范围、附带条件和可查依据。
+3. 明确确认且完成登记后，才算该版本测试结果提交完成；仍须满足测试质量门禁，才能进入正式平台/客户验收。人工确认不能将不通过改成通过，不能取消必测范围、缺陷复验或双线验收。
+4. 未回复、仅送达、已读、测试负责人单方确认、工具显示任务完成或协调消息结算，都不算此人工确认。Hub 保持“待项目负责人确认”，不伪造已批准；这不是 Etunel 的新机器枚举。
+5. 被退回时，测试补充材料，必要时回到相关修复、合版与独立复验，再重新提交确认。测试结果或被测版本实质变化必须重新经过 F6.10–F6.12；旧确认不能覆盖新版本。相同版本、范围与条件的有效确认可追踪复用，不为索引移动或排版重复审批。
+6. 测试已完成且无缺陷时，从 F6.2 直接到 F6.10，再经过 F6.11–F6.12；仍提交功能测试报告和零缺陷清单，不创建无必要的修复任务。无缺陷不等于未执行必测项也可跳过。
+7. 在最终确认前，可以依据真实的阶段性结果协调缺陷与修复，但不得据此宣布最终提交完成或正式进入验收。工具使用和技术任务结算见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
+
 ## 不适用、延期与成果豁免

 - 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
@@ -84,13 +100,14 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 - 延期和正式豁免都不等于不适用。
 - 适用内容缺失不能靠空文件或虚假“通过”穿过门禁。

-《成果豁免申请》由成果主责角色提出，提供成果名称、阶段、不适用原因、替代证据、下游影响、风险和负责人确认。Hub 识别受影响角色与门禁：
+《成果豁免申请》由成果主责角色提出，写明成果名称、阶段、不适用原因、事实证据、替代方案、下游影响、风险及负责人确认。流程为：
+
+1. Hub 校验发起资格、资料结构和可豁免性，缺口退回补正，不自行作最终批准或拒绝。
+2. 项目负责人（项目Hub对应的真人负责人）依据申请、证据、替代方案和影响，明确批准或拒绝。所有成果豁免均须此人工决定，不能以低影响、沉默、形式校验或 AI 推断代替。
+3. Hub 登记决定人、时间、范围、基线、附加条件和失效条件；批准后分发豁免记录，拒绝或未获确认时仍需该成果。
+4. 不再设置独立的下游征询、意见回传或业务高影响确认环节；必要的事实和影响写在申请中，缺少时补正，不凭空补造意见。
+5. 决定只适用于当前项目、阶段和基线。不可豁免要求不能借本流程绕过；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足，不能替代测试结果的项目负责人确认。条件变化时重新评估。

-1. 受影响角色负责人确认不会产生需求、接口、实现、测试、发布或审计缺口；
-2. 低影响且无专业争议时，Hub 可以完成形式审查、批准和登记；
-3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
-4. 只有正式豁免记录完整，才满足对应门禁；
-5. 条件变化使成果重新适用时，撤销豁免并恢复为必需。

 ## 额外产出

@@ -116,8 +133,10 @@ Hub 可以将其作为支持材料保存。额外文件不会自动成为正式

 Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。

-成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。
+阶段 6 测试大文件按可访问索引校验并保留确认记录，不要求 Hub 收存原文件；阶段 7 按下述产品直交收讫规则处理。除此之外，成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。

-成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。
+成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未按适用交付方式收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。
+
+阶段 7 正式验收前须已完成上述项目负责人确认及测试质量门禁。测试报告及已提供的提测佐证按已确认的负责人直接交付路径处理：测试保管原文件，产品确认接收，Hub 登记文件名、版本、保存位置、测试负责人确认、项目负责人确认引用和产品接收确认，不要求大文件上传或转发。此前关于 Hub 实际收件、附件及本地归档的通用要求不强制适用于这条交付路径；必须能追踪实际文件与接收状态，不能只凭消息已处理宣布交接完成。

 向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
@@ -64,7 +64,7 @@ Hub 已有登记答案时一次补足；没有时才创建必要的跨角色查

 ## 经 Hub 的跨角色中继

-跨角色交流必须是：来源成员 → Hub → 目标成员 → Hub → 来源成员。
+成员 Agent 跨角色交流必须是：来源成员 → Hub → 目标成员 → Hub → 来源成员。阶段 7 的测试报告和实际提供的提测佐证由测试负责人直接交产品负责人，这是人类文件交付，不新增成员 Agent 直连工具；Hub 仅登记资料索引、测试确认与产品收讫确认。

 - Hub 忠实保留问题、适用范围和来源，不替任一角色作专业改写；
 - 目标角色返回前完成专业自审和负责人确认；
@@ -76,7 +76,7 @@ Hub 已有登记答案时一次补足；没有时才创建必要的跨角色查

 ## 成员完成或阻塞

-调用 `mcp__etunel__etunel_complete_task` 前，成员确认指定成果、证据、版本、期限状态、专业自审、负责人确认和明确结论都已包含，并通过 `attachment_paths` 发送实际文件。
+调用 `mcp__etunel__etunel_complete_task` 前，成员确认指定成果、证据、版本、期限状态、专业自审、负责人确认和明确结论都已包含，并按适用交付方式通过 `attachment_paths` 发送实际文件或提供已约定的可访问索引。阶段 6 测试大文件保留索引、版本、位置及测试确认，供 Hub 和其真人负责人实际查看，不要求整包上传；索引不可访问则补齐访问条件。阶段 7 已按负责人直交方式交付的测试报告和提测佐证，只向 Hub 返回资料名称、版本、保存位置、测试确认与产品收讫确认，不要求重复上传大文件；其余任务仍按实际附件要求完成。

 调用 `mcp__etunel__etunel_report_blocked` 时，用简明中文说明：

@@ -88,6 +88,14 @@ Hub 已有登记答案时一次补足；没有时才创建必要的跨角色查

 成员只能结束自己的任务。Hub 不能代成员完成或阻塞；成员不能结算 Hub 的协调消息。

+## 测试提交与工具结算的区别
+
+测试用现有工具把经本角色负责人确认的技术结果交给 Hub，请求项目负责人确认，不能等待 Hub 尚未收到的结果被批准后才首次发送。依据实际任务意图及当前 schema 使用补充/请求或任务返回工具，不新增审批 API、参数或运行时状态。
+
+如果技术执行任务通过 `mcp__etunel__etunel_complete_task` 返回结果，其工具终态仅结算该技术任务，不表示最终测试提交已经完成。Hub 仍须按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 保持正式提交待确认，取得明确人工决定并登记后，才检查验收准入。若当前任务本身要求等待审批，先用 `mcp__etunel__etunel_send_to_hub` 返回结果与确认请求，不提前宣称该任务完成。
+
+零缺陷、消息已处理、协调结算及通知送达均不能跳过人工确认。阶段 7 真人直交不改变这一准入条件。
+
 ## Hub 处理成员入站

 Hub 对每条入站消息选择：
@@ -99,7 +107,7 @@ Hub 对每条入站消息选择：

 消息结算、排队和送达不代表任务、成果、阶段或项目完成。

-成果已经按 [成果与完成判定](artifacts-and-evidence.md) 被 Hub 接受并归档后，后续任务记录异常不撤销成果，也不要求成员重复制作或提交；Hub 单独记录并说明运行时异常。尚未实际收到或校验成果时，不能用消息状态继续推进。本文件不为此设计额外重试、去重或队列逻辑。
+成果已经按 [成果与完成判定](artifacts-and-evidence.md) 被 Hub 接受并归档后，后续任务记录异常不撤销成果，也不要求成员重复制作或提交；Hub 单独记录并说明运行时异常。尚未按适用交付方式收到或校验成果时，不能用消息状态继续推进；阶段 7 直交资料按产品收讫与索引规则判断，不要求 Hub 收到原文件。本文件不为此设计额外重试、去重或队列逻辑。

 ## 附件

@@ -27,8 +27,8 @@ Hub 有登记答案时直接补足；没有时只向实际信息所有者角色

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

- 目标、业务范围、优先级、资源、组织授权和最终业务风险接受：业务；
- 产品行为、需求含义、用例与验收标准：产品；
+- 目标、业务范围、优先级、预算、采购、对外承诺、组织授权和最终业务风险接受：业务；
+- 产品行为、需求含义、用例与验收标准、授权范围内的资源与排期：产品；
 - 总体架构、跨层接口、技术取舍、依赖与集成：技术负责人；
 - 应用逻辑、状态机、应用协议和应用服务：嵌入式应用层；
 - BSP、Bootloader、驱动、RTOS、系统服务和 HAL：嵌入式底层；
@@ -71,14 +71,16 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞

 ## 缺陷与返工

-1. 测试创建并持续维护《缺陷分析报告》，记录被测组合、环境、复现、期望与实际、证据、风险、建议责任边界、复验和状态。
-2. 根因边界不清时由技术负责人确认系统边界、版本关系或架构影响；Hub 不自行归因。
-3. Hub 向实际责任角色派发修复任务；相关缺陷可以组成修复包，独立角色可以形成修复波次。
-4. 实现角色提交根因分析、修复计划、修复成果和版本、角色自测、影响与建议回归范围。
+1. 测试创建并持续维护《缺陷清单》，记录 bug 条目、状态、模块、责任人，并保留定位、修复与复验所需的被测版本和证据。
+2. 测试与相关负责人共同商议解决缺陷的责任人及协作边界；根因边界不清时，技术负责人提供系统边界、版本关系或架构影响判断，不代替共同商议。Hub 不自行归因或指定责任人。
+3. 责任角色先向 Hub 返回原因与修复计划（F6.4）；Hub 登记共同确认的责任人和唯一主责角色，向责任角色派发修复任务，并把确认结果同步给测试维护缺陷清单（F6.5）。相关缺陷可组成修复包，独立角色可形成修复波次。
+4. 实现角色按派发任务提交修复成果和版本、角色自测、影响与必要变更说明，不替测试提交或维护清单。
 5. 底层修复先交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。
-6. 技术负责人确认新版本组合后，测试在目标组合独立复验。
+6. 技术负责人确认新版本组合后，Hub 以统一固件、版本矩阵、缺陷清单及必要变更说明派发回归；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验。
 7. 只有测试可以确认缺陷已经复验或关闭；实现角色和 Hub 无权替换或关闭测试记录。

+测试已完成且无缺陷时仍提交功能测试报告和零缺陷清单，直接进入最终结果人工确认，不安排空修复任务。退回或修复形成新结果后按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 重新确认，才能检查正式验收准入。
+
 产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。

 ## 变更申请
@@ -88,7 +90,7 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞
 1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
 2. 产品、技术负责人、实际受影响实现或自定义角色和测试分别评估；
 3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
-4. 需要组织授权的变更由业务批准、拒绝或延期；
+4. 授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时再由业务批准、拒绝或延期，其他专业决定仍由有权角色确认；
 5. 批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；
 6. 未批准不得边评估边实施，也不得用状态纠正规避变更。

@@ -96,7 +98,7 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞

 ## 成果豁免

-固定正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起《成果豁免申请》。不适用、延期、跳过、口头同意或空文件都不能替代正式豁免。
+必须提交的正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起《成果豁免申请》。已标为选填的成果无需仅因未提交而办理豁免，也不得据此阻塞；已确认必须执行的测试或承诺不会因报告选填自动取消。必需成果的不适用、延期、跳过或空文件都不能替代正式豁免。Hub 校验申请后，所有成果豁免必须由项目负责人（项目Hub对应真人负责人）明确批准或拒绝，Hub AI 只登记与执行；不再设置独立下游征询、意见回传和业务高影响确认环节，所需事实与影响在申请中补齐。批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。

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

@@ -104,7 +106,7 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞

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

 按 [项目文件与进度留档](project-files-and-progress.md) 保留来源阶段与目标阶段记录，不移动或覆盖旧成果。跳转是流程状态，不是专业批准，也不保证可以发布。
@@ -124,7 +126,7 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞

 ## 真实授权事项

-真实人员、资源、预算、采购、业务范围、正式日期、项目暂停或取消需要授权时，Hub 提供事实、选项、建议、影响和最晚决定点，向有权业务负责人或项目发起人请求决定。未决定前保持真实等待或阻塞，不解释为默认批准。
+需要真实授权时，Hub 提供事实、选项、建议、影响和最晚决定点。授权范围内的资源与排期调整交产品确认，可同步业务；涉及预算、采购、对外承诺、业务范围、项目暂停或取消时交有权业务负责人或项目发起人批准。未决定前保持真实等待或阻塞，不解释为默认批准。

 ## 信息披露

@@ -7,7 +7,7 @@
 项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和项目状态维护者。Hub 负责总体编排，不替角色形成专业事实或结论：

 - 业务决定业务目标、范围、优先级、组织授权和业务批准；
- 产品定义产品行为、需求和验收标准并组织验收；
+- 产品定义产品行为、需求和验收标准，在阶段 2 汇总并维护项目风险，确认授权范围内的资源与排期并组织平台、客户两部分验收；
 - 技术负责人决定总体架构、接口、技术依赖和集成结论；
 - 应用层、底层、硬件及已登记的自定义专业角色分别决定本领域设计与实现；
 - 测试形成独立测试、缺陷和质量结论。
@@ -56,7 +56,7 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认

 不要把 role ID、member ID、session ID、消息 ID 或机器状态放进人类任务正文。纯信息、澄清或授权请求不要求空文件，但要给足背景、问题、影响和需要的结论。详细写法见 [人类可读沟通](human-readable-communication.md)。

-期限优先继承已批准的《项目目标与里程碑计划》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。
+期限优先继承已批准的《客户里程碑要求》《里程碑要求》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。

 ## Hub 中介的跨角色信息流

@@ -81,7 +81,7 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认
 - 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
 - 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。

-如果成果已经满足下文的接受条件并完成归档，随后出现 Etunel 任务记录“已处理”“未找到”等运行时异常，不撤销成果、不要求成员重复制作或重复提交，也不倒退已经完成的阶段；Hub 只记录并说明运行时异常。文件尚未实际收到、无法访问或尚未校验时，不能用消息状态代替成果继续推进。本 Skill 不规定队列、重试或去重实现。
+如果成果已经满足下文的接受条件并完成归档，随后出现 Etunel 任务记录“已处理”“未找到”等运行时异常，不撤销成果、不要求成员重复制作或重复提交，也不倒退已经完成的阶段；Hub 只记录并说明运行时异常。文件尚未按适用交付方式收到、无法访问或尚未校验时，不能用消息状态代替成果继续推进；阶段 7 直交资料按下文收讫规则登记。本 Skill 不规定队列、重试或去重实现。

 消息关联所需的 `message_id` 和 `correlation_id` 只放在工具参数中，不要求负责人手工提供或复述。

@@ -96,7 +96,9 @@ Hub 检查：
 - 模拟数据没有进入正式事实；
 - 与其他有效成果没有未处理冲突，且未越权。

-只有实际收到并能访问成果、来源角色正确、成果与当前任务及输入基线一致，并且必要版本、证据、自审和负责人确认满足要求时，Hub 才能选择“接受”。选择后必须在同一处理轮完成文件归档、成果索引更新并明确说明接受结论；这些动作全部完成后，成果才成为当前有效版本。附件刚送达、成员说“已完成”或消息显示“已处理”都不能单独视为接受。
+阶段 6 测试大文件以可访问索引、版本和确认依据办理校验及真人确认，不要求重复上传；阶段 7 按下文直交收讫规则登记。除此之外，只有实际收到并能访问成果、来源角色正确、成果与当前任务及输入基线一致，并且必要版本、证据、自审和负责人确认满足要求时，Hub 才能选择“接受”。选择后必须在同一处理轮完成适用的文件归档、成果索引更新并明确说明接受结论；这些动作全部完成后，成果才成为当前有效版本。附件刚送达、成员说“已完成”或消息显示“已处理”都不能单独视为接受。
+
+阶段 7 的测试报告及实际提供的提测佐证由测试负责人直接交产品负责人。Hub 登记资料名称、版本、保存位置、测试确认和产品收讫确认，不接收或转发大文件，也不以重复上传 Hub 作为门禁。产品确认资料可访问且与索引一致；资料尚未收到或不可访问时只登记缺口，不能写成收讫。未要求提供的选填材料不阻塞阶段。

 同一文件、版本、适用范围和附带条件已经有有效负责人确认时，Hub 直接沿用，不再要求重复确认。只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。

@@ -115,30 +117,39 @@ Hub 检查：

 Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时，每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》，不广播完整计划。规则见 [角色与项目状态](project-status-and-membership.md)。

+## 测试最终提交与验收入口
+
+测试结果到达后先按 [测试结果的项目负责人确认](artifacts-and-evidence.md#测试结果的项目负责人确认) 处理：测试专业自审与本角色负责人确认不是最终提交完成。Hub 请求自己的真人负责人确认并记录当前版本的明确决定；未确认或退回期间，不接受为已完成的最终提交，不开放正式验收。相同有效确认可沿用，结果或版本实质变化重新确认。
+
+无缺陷路径仍需功能测试报告和零缺陷清单，并从 F6.2 转 F6.10–F6.12，不派空修复任务。待最终确认前可以协调真实缺陷和修复，不能把这个等待设置为缺陷沟通的前置阻塞。
+
 ## 人类负责人参与

 Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下情况介入：

+- 测试最终结果的明确确认或退回；记录对应成果与被测版本，不以测试负责人确认或消息状态代替；
 - 真实节点跳转、暂缓、回退、流程迁移或带风险绕过；
+- 所有成果豁免的批准或拒绝：项目负责人即 Hub 对应的真人负责人，Hub AI 只校验和登记，不自行决定；不再单设下游征询及业务确认流程；
 - 启用、变更或结束模拟模式；
 - 自定义角色需要在 Etunel 中手动添加、替换或移除；
 - 门禁争议、重大跨角色冲突或专业权责无法消解；
 - 重大进度、成本、质量、安全或交付风险；
 - 正式阻塞经现有负责人和线下协调仍无法解决。

-真实人员、资源、预算、采购、范围、日期、暂停、取消或组织级风险接受由业务或项目发起人按权限授权。
+授权范围内的资源与排期由产品确认，确认后的计划可以同步业务；涉及预算、采购、对外承诺、业务范围、暂停、取消或组织级风险接受时，由业务或项目发起人按权限批准。

 ## 阶段控制要点

- 阶段 1 业务草案后，产品按需选择早期风险预审角色；Hub 不增删名单。
- 阶段 2 由产品明确评审角色和具体问题；测试检查产品结果是否可判断，其他专业角色按实际影响参与，最后由产品收口。
- 阶段 3 先由技术负责人形成方案与接口草案，再向适用设计角色形成波次，最后由技术负责人收口统一版本。
- 阶段 4 Hub 基于已确认方案形成计划；技术负责人确认技术结构，只向有缺失或冲突的角色定向询问，业务授权真实资源和日期。
- 阶段 5 应用层、底层和硬件按依赖推进；底层先交应用层合版，统一固件只由应用层输出。
- 阶段 6 测试维护《缺陷分析报告》；底层修复也须经应用层重新合版后复验。
+- 阶段 1 形式校验后分发业务成果评审版本；产品与业务确认需求基线即可进入产品定义，不设固定早期风险预检环节。
+- 阶段 2 由产品明确评审角色和具体问题并收口；立项资料包含平台 SDK、个参资料，结构板框图在本阶段选填；产品汇总技术、时间及其他风险，维护阶段 2《项目风险》。
+- 阶段 3 由技术负责人汇总方案与测试计划；测试无问题时交 Hub 汇总确认，存在不可测试项或环境、治具缺口时，Hub 先路由相关角色确认。总体技术方案及阶段 3 硬件约束选填，未提供不阻塞；不要求独立接口契约或架构决策记录。
+- 阶段 4 Hub 拆分任务并整理工时评估、实际排期；技术负责人确认技术结构，只对问题任务定向询问，产品确认授权范围内的资源与排期。本阶段成果仅项目计划、角色分工、项目状态内部记录；引用阶段 2 项目风险，不另要求产品资料整合。
+- 阶段 5 硬件取得器件规格书和结构板框图后提交四类硬件设计资料；不另设《硬件实现资料》。底层提交硬件功能测试报告、BSP/PSP 输出路径，WiFi 定频固件选填；统一固件只由应用层输出。
+- 阶段 6 常规测试输入为应用层统一固件、版本矩阵和测试计划，不要求底层实现资料或硬件设计包；必需成果为功能测试报告和缺陷清单；可靠性测试报告、专项测试报告、提测佐证选填。相关负责人共同商议缺陷责任人后，Hub 登记并派发；底层修复须经应用层重新合版后复验。
+- 阶段 7 按平台、客户两部分验收，可按条件并行；平台由产品出具报告或结论，客户验收由业务确认，两部分均通过才放行。测试资料按直交与收讫规则处理。
 - 变更、异常或缺陷只向实际受影响角色派发，不固定全角色参与。
- 阶段 8 只要求实际参与、有正式成果、遗留风险或发布责任的角色提交结项摘要。
- 正式项目满足全部适用成果、确认、验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。
+- 阶段 8 收集已有资料、复盘和结项，不新增冒烟或其他测试；只要求实际参与、有正式成果或遗留责任的角色提交结项输入。
+- 正式项目满足全部必需成果、确认、双重验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。

 ## 钉钉进度

@@ -6,10 +6,11 @@

 当前 Hook、Etunel 角色契约和入站任务已经确定本会话代表的角色。不要向负责人确认 role ID、member ID、session ID 或消息 ID。

- 正式任务从 Hub 接收，正式结果只交 Hub。
+- 正式任务从 Hub 接收，正式结果和确认通过 Hub 登记；阶段 7 测试负责人直交产品资料按下述例外处理。
 - 现阶段 Etunel 不支持成员间直接通信；不得直接向其他成员 Agent 派任务、索取结论或建立私下依赖。
 - 跨角色问题先合并交 Hub，由 Hub 定向中继并返回已确认结论。
 - 人类负责人可以线下找相关人员；讨论结果必须回到负责该专业结论的角色会话，经负责人确认后再交 Hub。
+- 阶段 7 测试报告和实际提供的提测佐证由测试负责人直接交产品负责人；测试与产品分别把交付、收讫确认及资料索引交 Hub，不重复上传大文件，也不建立成员 Agent 直连。
 - 不向钉钉发送项目进度；需要群组可见性时把成果、状态或阻塞交给 Hub。

 ## 接收任务后先和负责人对齐
@@ -64,10 +65,12 @@

 只有负责人实际查看并确认后，才能把结果作为本角色正式提交。模拟模式的确认只表示同意用已标明的模拟材料推进，不证明数据真实。

+测试最终提交还有项目负责人确认门禁，见 [成果与完成判定](artifacts-and-evidence.md#测试结果的项目负责人确认)。测试先把经本角色负责人确认的结果交 Hub 发起人工确认，不能自行宣布提交完成。阶段 7 正式验收须使用已获此确认且质量门禁满足的版本。
+
 ## 返回与终态

 - 任务仍可继续且只需 Hub 补充：调用 `mcp__etunel__etunel_send_to_hub` 一次提交聚合请求。
- 全部必需产出完成、自审完成且负责人确认：调用 `mcp__etunel__etunel_complete_task`，用 `attachment_paths` 附上实际成果文件。
+- 全部必需产出完成、自审完成且负责人确认：调用 `mcp__etunel__etunel_complete_task`，按当前 schema 用 `attachment_paths` 附上适用成果文件；阶段 6 测试大文件可返回可访问索引、版本、位置及测试确认，不以整包上传为门槛。阶段 7 直交资料另返回产品收讫确认，不重复附大文件。
 - 任务无法继续，且原因、已尝试协调、影响、所需决定和恢复条件明确：调用 `mcp__etunel__etunel_report_blocked`。

 工具需要的 `message_id` 或 `correlation_id` 来自 Etunel 入站消息，只放在工具参数中，不要求负责人核对。补充、返工或阻塞解除后等待 Hub 派发新任务，不复用已经结束的消息。工具细则见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
@@ -1,12 +1,12 @@
 # 项目文件与进度留档

-Hub 创建项目资料目录、保存角色文件、维护成员清单、更新进度、完成阶段交接、跳转、回退或结项时读取。Etunel 负责附件传输，本文件只约束收到文件后的项目内整理和可追踪性。
+Hub 创建项目资料目录、保存角色文件、维护成员清单、更新进度、完成阶段交接、跳转、回退或结项时读取。Etunel 负责其附件传输，本文件只约束项目内整理和可追踪性；阶段 7 测试负责人直交产品资料的例外见下文。

 ## 责任边界

 - 各角色负责形成、检查并提交自己的专业成果文件。
 - Hub 负责接收后校验、按阶段归档、维护成果索引和项目进度，不改写角色专业内容。
- 必要成果文件未保存、不可访问或无法确认版本时，不宣布正式阶段交接完成。
+- 必要成果文件未在适用位置保存、不可访问或无法确认版本时，不宣布正式阶段交接完成；阶段 7 直交资料以产品收讫、可访问确认及 Hub 索引为准。
 - 目录整理不是新的专业评审。模拟、受控跳转、回退或暂缓可以继续，但必须先记录缺失项、原因、风险和恢复条件。
 - 不强制项目使用 Git。项目已有 Git 时可正常提交，但 Git 提交不是阶段门禁。

@@ -27,10 +27,12 @@ Hub 在项目开始时建立：
 ├── 04-项目规划/
 ├── 05-软硬件实现/
 ├── 06-测试验证/
-├── 07-业务验收/
-└── 08-发布结项/
+├── 07-平台客户验收/
+└── 08-复盘结项/
 ```

+以上为新建项目的目录名称；在途项目沿用已有目录并在索引注明阶段对应关系，不为改名移动历史文件。
+
 每个实际发生工作的阶段按需建立：

 ```text
@@ -45,7 +47,7 @@ Hub 在项目开始时建立：

 `00-项目管理/项目概览.md` 保存项目名称、模式、流程基线、目标和当前项目已经确认的特殊规则。每条特殊规则写清内容、适用范围、决定权角色或负责人、确认依据和生效时间；Hub 只能登记有权负责人明确确认的内容，不能把自己的推断写成规则。

-项目规则持续有效，直到同一决定权人明确修改或取消。各角色只确认自己决定权内的规则：产品确认产品行为和验收边界，业务确认业务范围、客户联络和正式承诺，Hub 负责人确认其权限内的流程处理，专业角色确认本领域限制；改变既有正式基线时仍按《变更申请》处理。
+项目规则持续有效，直到同一决定权人明确修改或取消。各角色只确认自己决定权内的规则：产品确认产品行为、验收边界及授权范围内的资源与排期，业务确认业务范围、客户联络、预算、采购和对外承诺，Hub 负责人确认其权限内的流程处理，专业角色确认本领域限制；改变既有正式基线时仍按《变更申请》处理。

 ## 项目成员清单

@@ -68,6 +70,14 @@ Hub 在项目开始时建立：
 - `成果索引.md` 至少写明中文成果名、阶段、主责角色、文件位置、版本、确认状态、当前适用性和被替代关系。
 - 每项成果只标记一个当前有效版本。下游默认只接收该版本；旧版和过程材料继续留存，但不参与当前完成判断，除非被明确恢复为有效版本。

+## 测试最终提交的确认留档
+
+按 [测试结果的项目负责人确认](artifacts-and-evidence.md#测试结果的项目负责人确认)，在阶段记录和成果索引中区分“测试执行完成”“待项目负责人确认”“确认完成/退回”，记录当前报告、缺陷清单及被测版本、真人决定、时间、范围和依据。这些是可读业务记录，不新增 Etunel 枚举。未确认不能登记为最终提交完成或正式验收准入；新结果或版本需重新确认，历史确认保留。
+
+## 阶段 7 测试资料直交
+
+测试负责人把测试报告及实际提供的提测佐证直接交产品负责人，不经 Hub 转发。资料可以保留在项目已授权的存储位置，Hub 在成果索引登记名称、版本、位置、测试确认、项目负责人确认引用及产品收讫确认；产品确认可访问且与索引一致。Hub 留存索引和确认记录即可，不为归档再要求上传或复制大文件。未提供的选填佐证不产生缺件门禁；需要但尚未收到的资料必须如实登记，不能以一条“已完成”消息代替收讫。
+
 ## 项目进度与阶段记录

 `00-项目管理/项目进度.md` 是当前状态快照，使用简洁中文说明：当前阶段、已完成事项、正在进行事项、实际阻塞、下一步、责任角色和更新时间。
@@ -4,7 +4,7 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成

 ## 通用推进原则

- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
+- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 平台/客户验收 → 复盘结项。
 - 每个阶段开始时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只在与本角色负责人对齐时确认或纠正自己的部分，不为此另开全员确认任务。
 - 角色提出新缺口时，必须说明它直接影响哪项本阶段成果、完成条件或决定，以及为什么现在必须解决。后续使用但不影响当前判断的资料只登记为后续依赖，不能阻塞当前阶段。
 - 本阶段门禁满足、成果和确认留档后，Hub 及时结束本阶段并启动下一阶段。不要等待后续阶段的全部资料提前齐备；新阶段根据自己的任务按需取得输入。
@@ -18,191 +18,93 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成

 ## 阶段 1：业务需求

-### 正常任务链
+1. 业务形成《项目背景说明》《客户里程碑要求》，明确业务对象、目标与范围，完成自查及业务负责人确认后提交。
+2. Hub 校验文件、版本、证据与跨来源冲突，将评审版本交产品；仅有形式错误或冲突时退回业务。
+3. 产品与业务经 Hub 澄清并分别确认同一需求基线。确认后 Hub 登记、留档并向产品分发，启动阶段 2。
+4. 不再设置早期风险预检请求、预检任务路由和预检结果回传的固定流程，不把它们作为进入产品定义的条件。

-1. 业务形成待评审的业务草案，澄清背景、客户目标、价值、范围、优先级、合作边界、成功指标和目标里程碑。
-2. 产品判断是否需要早期专业风险预审，并精确选择角色、问题和必要输入。
-3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
-4. 产品整理预审影响，业务负责人确认阶段 1 基线。
+背景说明区分对接客户与最终客户，预期价值、订单及预计销售额为选填，不要求成功指标。客户里程碑包含提测、入库时间，小批量试产和量产时间为选填。客户期望日期不自动成为正式承诺；具体栏目见 [业务职责](roles/business.md)。

-### 正式成果
-
- 项目背景说明
- 项目目标与里程碑计划
-
-早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。
-
-### 门禁
-
-有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。
+门禁：产品与业务确认同一需求基线，形式问题与影响该基线的冲突已处理，产品具备继续定义的输入。

 ## 阶段 2：产品定义

-### 正常任务链
+1. 产品基于业务基线形成《立项资料》《测试验收标准》《里程碑要求》《项目风险》草案；立项资料纳入平台 SDK、个参资料，具体组成见 [产品职责](roles/product.md)。
+2. 产品明确专业评审角色、问题、范围和期望输出。测试检查产品结果是否可判断；技术负责人组织可行性评估，应用层、底层与硬件按实际影响评估专业约束。
+3. Hub 定向分发同版本资料；各角色返回本领域结论、缺口和风险，不代产品改需求。
+4. 产品汇总专业角色意见，维护《项目风险》（技术风险、时间风险、其他风险），并处理反馈、确认产品基线；业务批准客户范围与验收边界。结构板框图在本阶段选填；后续硬件任务需使用时再补齐，不提前阻塞产品定义。
+5. 测试验收标准包含平台测试用例、客户验收测试用例和验收标准。里程碑要求包含提测、客户验收时间，试产与量产时间为选填。

-1. 产品优先使用阶段 1 基线、项目已确认规则和已有资料，明确产品做什么、不做什么、外部可见行为以及如何判断结果符合要求，形成三类正式成果草案；只补当前阶段确实需要的客户输入，不提前收齐后续设计、实现、测试或生产资料。
-2. 产品在评审请求中明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在产品内容确实涉及本领域约束时参与。影响范围不清时，可先由技术负责人界定相关专业领域，不能因此默认让所有角色全面评估。
-3. Hub 以同一草案版本按产品指定范围定向派发；依赖独立时可以形成波次，但不得自行增加评审对象或专业问题。
-4. 各角色只返回本领域对当前产品定义的可行性、约束、缺口、风险和建议，并说明是否直接影响本阶段完成约定；不代产品改需求，也不把后续阶段的完整资料要求变成当前阻塞。
-5. 测试在本阶段判断预期结果是否清楚、可区分通过与不通过；样机数量、执行轮次、工具和详细环境通常留到《测试计划》或后续测试准备，除非它们本身是已批准的产品承诺。
-6. 产品处置反馈、解决需求冲突并收口产品基线。
-7. 业务批准客户范围、验收边界和需要组织授权的结论。
-
-### 正式成果
-
- 立项资料
- 测试验收标准
- 里程碑要求
-
-客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料在当前产品定义确实需要时，可以作为包内内容或支持输入；不另立旧版开发资料包，也不因后续阶段可能使用而要求阶段 2 全部收齐。
-
-### 门禁
-
-产品行为、范围、异常边界、确有需要的接口期望和可判断的验收结果明确；直接影响当前定义的关键专业约束已处置；产品负责人确认，业务完成范围批准。已经登记的后续依赖不妨碍阶段交接，下一阶段启动后按需取得资料。
+门禁：产品确认方案、业务批准范围，直接影响产品定义的约束和可判断的验收标准完整；仅属于后续阶段的依赖如实登记。

 ## 阶段 3：方案设计

-### 正常任务链
+1. 技术负责人依据产品基线及阶段 2 已有评审结论，提交设计要点、待确认接口约束和风险；不得依赖尚未形成的《项目计划》。
+2. Hub 向相关角色分发设计任务。应用层设计业务模块与应用接口；底层设计 BSP、驱动、RTOS、HAL；硬件约束（器件、PCB、电源、信号、热及接口）为选填，提供时按本领域确认；产品确认需求不偏离。
+3. 测试编制并提交《测试计划》，包含测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，Hub 先转交相关角色确认，再由测试修订计划并汇总。
+4. 技术负责人确认方案、接口及测试计划；相关角色确认本领域可实施性、可验证性及同一版本关系。

-1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的《项目计划》。
-2. Hub 以同一方案和接口版本向适用角色形成设计波次：
-   - 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
-   - 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
-   - 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
-   - 测试：测试计划、环境、策略、覆盖、可测试性和通过标准；
-   - 产品：确认方案没有需求漂移。
-3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
-4. 受影响角色分别确认本领域约束与统一版本一致。
+正式成果为《测试计划》和选填的《总体技术方案》。不单列软硬件接口契约或架构决策记录，也不在此阶段要求硬件设计包。必要决定、接口约束及确认保留在已有过程记录中，不能仅换名重新要求独立成果文件。总体技术方案和本阶段硬件约束未提供不阻塞推进，无需豁免；已提供时完成相应版本登记和确认。阶段 5 所需硬件前置输入与设计包不受此选填设置影响。

-### 正式成果
-
- 总体技术方案
- 软硬件接口契约
- 硬件设计包
- 架构决策记录
- 测试计划
-
-技术负责人主责《总体技术方案》《软硬件接口契约》和《架构决策记录》；硬件主责《硬件设计包》；测试主责《测试计划》。
-
-### 门禁
-
-方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。
+门禁：方案已确认、接口可实施、需求不偏离、测试可验证，测试计划经技术负责人确认；测试仍负责计划编制与维护。

 ## 阶段 4：项目规划

-### 正常任务链
+1. Hub 基于产品基线和已确认方案形成《项目计划》《角色分工》《项目状态内部记录》，并引用阶段 2 产品维护的《项目风险》。
+2. 项目计划包含任务拆分（工时评估）和实际排期。技术负责人先确认任务技术结构、顺序和依赖。
+3. 仅对有疑点的任务定向询问执行角色的工期、资源、输入输出及风险，不要求全员重新确认整份计划。
+4. 产品确认授权范围内的资源与排期；涉及预算、采购或对外承诺时再由业务批准。
+5. Hub 向相关执行角色分发依赖就绪的任务；确认后的计划与排期可同步业务，不把同步回执当成额外批准门禁。

-1. Hub 基于已确认方案形成《项目计划》《项目风险》《角色分工》《产品资料整合》和《项目状态内部记录》草案。
-2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
-3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
-4. Hub 收口计划和状态记录；业务授权真实人员、资源、采购、成本和正式日期。
-5. Hub 向相关主责角色下发依赖就绪的任务切片。
+角色分工明确职责、任务主责与协作、加入退出替换及交接；每项任务只有一个主责角色。不另设《产品资料整合》成果，任务按需引用已有立项资料、方案确认记录和成果索引。项目风险在阶段 2 形成，后续新增风险由相关角色经 Hub 交产品维护，不重新创建阶段 4 风险成果。创建期内部状态在本阶段正式化。

-### 正式成果
-
- 项目计划
- 项目风险
- 角色分工
- 产品资料整合
- 项目状态内部记录
-
-项目创建时由 Etunel 提供的角色事实和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或重复确认。
-
-### 门禁
-
-每项计划任务有主责角色、输入、输出文件、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可以执行。
+门禁：技术结构及问题任务已确认，产品确认资源与排期，必要的业务授权完成，首批依赖就绪任务可以执行。

 ## 阶段 5：软硬件实现

-### 正常任务链
+1. Hub 按已确认的产品、方案、项目计划和角色分工，向应用层、底层、硬件分发依赖就绪任务。
+2. 硬件开始设计前取得并核对实际使用的外设和关键器件规格书、结构板框图；缺失时经 Hub 向上游资料责任角色补齐，仅阻塞受影响硬件任务。具体器件清单见 [硬件职责](roles/hardware.md)。
+3. 硬件提交《硬件设计包》：原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义。硬件负责人先确认，再经 Hub 向技术负责人及受影响角色确认和分发。
+4. 不要求单独《硬件实现资料》成果；前置资料是输入，不是硬件产出。版本矩阵、实施或调试事实按实际任务留在已有过程记录，不另立重复交付物。
+5. 底层提交《嵌入式底层实现资料》：硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件选填。Hub 登记后将 BSP/PSP 可消费版本交应用层合版。
+6. 应用层形成唯一《嵌入式应用层固件包》，包含正式/升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书。
+7. 接口、器件或资源冲突经 Hub 交技术负责人确认；统一固件与硬件候选就绪时启动联调（F5.8），不以最终提测版本已提交作为启动条件。
+8. 联调问题关闭后，应用层才提交最终提测固件（F5.9）；技术负责人核对最终版本矩阵并确认固件与硬件匹配、可提测（F5.10）。

-1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
-2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
-3. 底层向 Hub 提交可消费的底层版本和集成说明；Hub 交应用层合版。
-4. 应用层解决集成问题并作为唯一出口形成《嵌入式应用层固件包》。
-5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
-6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。
-
-### 正式成果
-
- 硬件实现资料
- 嵌入式底层实现资料
- 嵌入式应用层固件包
-
-版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。
-
-### 门禁
-
-适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。
+门禁：适用成果齐备，技术负责人确认最终固件与硬件版本匹配且可提测。底层不得直接向测试交最终固件；定频测试固件选填且仅作专项测试工具，不作为正式提测或发布固件。

 ## 阶段 6：测试验证

-### 正常任务链
+1. 测试接收应用层统一固件、版本矩阵和测试计划，按已批准范围执行并形成结论。
+2. 必需成果：《功能测试报告》《缺陷清单》。选填成果：《可靠性测试报告》《专项测试报告》《提测佐证》；未提供不阻塞推进，无需豁免，已提供时完成相应确认。
+3. 功能报告包含测试结论（通过/不通过）、测试用例执行结果及 bug 的 log 日志。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项；提测佐证为平台要求的视频、截图、log 材料。
+4. 测试提交《缺陷清单》，不提交独立缺陷分析报告。测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色和协作关系。Hub 只登记确认结果并路由，不自行定责。
+5. 责任角色向 Hub 返回原因与修复计划（F6.4）；Hub 向责任角色派发修复任务，同时把确认结果同步给测试维护同一缺陷清单（F6.5），不将回传与派发混为一个方向。
+6. 实现角色按任务提交修复成果和版本、自测与影响。底层修复经应用层重新合版；硬件 ECO 完成底层兼容评估、应用有效性确认及版本矩阵更新。F6.6 的修复交付不另贴缺陷清单成果标签，清单仍由测试维护。
+7. Hub 派发回归（F6.9），输入统一为“统一固件、版本矩阵、缺陷清单及必要变更说明”；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验、维护缺陷状态并给出质量结论；实现角色不得替换或关闭清单。
+8. 阻断缺陷清零、必需成果与测试依据齐全且剩余风险有接受方后，测试自审并取得测试负责人确认，再交 Hub（F6.10），Hub 请求项目负责人（Hub 对应真人负责人）确认（F6.11），明确确认或退回后登记（F6.12）；确认后才算完成提交。详见 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认)。
+9. 测试已完成且无缺陷时，F6.2 → F6.10 → F6.11 → F6.12；仍提交功能测试报告、零缺陷清单，不创建无必要的修复任务。

-1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
-2. 测试依据《测试计划》和《测试验收标准》执行功能、可靠性、专项和回归验证。
-3. 测试创建并维护《缺陷分析报告》；缺陷由 Hub 向实际责任角色形成修复波次。
-4. 实现角色提交根因分析、修复计划、修复成果、版本、自测和影响，不能替测试关闭缺陷报告。
-5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
-6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。
+选填文件不等于可以跳过已批准的必测范围；必需测试结果仍须可追踪，不能把未测写成通过。大文件由测试保管并登记索引，阶段 7 直接交产品，不强制向 Hub 上传。底层实现资料和硬件设计包不列为常规测试输入，不因未附这两类资料拒绝提测；具体测试或定位确需信息时经 Hub 按问题查询，不重新要求整包提交。

-### 正式成果
+门禁：阻断缺陷清零，必需成果与测试依据齐全，测试负责人确认质量结论和剩余风险，Hub 已取得并登记项目负责人对该版本测试结果的明确确认。人工确认只完成提交，不改变测试结论或替代验收；未确认、被退回或新版本未重新确认，不进入正式验收。

- 功能测试报告
- 可靠性测试报告
- 专项测试报告
- 测试证据包
- 缺陷分析报告
+## 阶段 7：平台验收与客户验收

-质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。
+1. 先确认阶段 6 质量门禁及 F6.12 项目负责人确认已满足。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，文件不经 Hub 转发。产品向 Hub 确认接收文件及版本；Hub 只登记索引、确认和交付状态。收到资料不等于验收通过。
+2. 流程先展示平台验收、再展示客户验收；各自输入就绪时可以并行，不把平台完成一律作为客户验收启动条件。
+3. 平台验收由产品组织，依据实际平台结果出具《平台验收报告或结论》，不需要业务批准平台结果。
+4. 客户验收由产品组织，客户反馈由有联络权限的业务或产品真人负责人取得；《客户验收通过报告》须由业务确认。
+5. 平台和客户问题共用同一份《遗留问题清单》，标明来源、对应版本、责任人、处置和状态；F7.3 更新平台问题，F7.5 更新客户问题，F7.10 汇总核对两条线的结论和同一清单。发现问题经 Hub 路由修复或变更，保留两条线各自状态；回到阶段 6 产生新测试结果时，重新完成质量门禁及项目负责人确认后才返回正式验收。

-### 门禁
+总门禁是平台验收通过 + 客户验收通过，两项缺一不可。不能用平台通过、内部测试通过、资料已收或单方确认替代双线通过；问题与风险有明确承接。

-测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试明确给出通过、失败或阻塞。测试通过不替代业务验收。
+## 阶段 8：资料归档与复盘结项

-## 阶段 7：业务验收
+1. Hub 向实际参与角色收集各阶段有效成果、必要过程记录、变更、项目进度、成果索引及确认。沿用已验收版本，不重复制作同内容资料。
+2. 核对产品确认的平台结果、业务确认的客户结果及遗留问题；不重新给平台结果增加业务批准。
+3. 各角色提交基于事实的复盘输入：目标完成、计划偏差、协作与质量问题、经验和改进建议。Hub 汇入《流程闭环总结》。
+4. Hub 形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，业务确认结项。
+5. 本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题时回到相应阶段处理，不能冒充已完成。

-### 正常任务链
-
-1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示或试用和差异处置。
-2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品负责人按联络边界取得，并返回对应角色会话。只有已经定义职责并由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
-3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
-4. 产品形成验收报告和附条件事项；业务批准验收结论、上线或交付条件和业务风险接受。
-
-### 正式成果
-
- 平台提测通过报告
- 客户验收通过报告
- 附条件验收事项
-
-不适用的平台或客户验收成果按不适用或《成果豁免申请》规则处理，不能用内部测试自动替代。
-
-### 门禁
-
-平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。
-
-## 阶段 8：发布结项
-
-### 正常任务链
-
-1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布或结项任务：
-   - 应用层输出唯一最终发布固件和发布说明；
-   - 底层归档实际被集成的版本和接口信息；
-   - 硬件归档板卡、BOM、生产资料和适用 ECO；
-   - 技术负责人确认最终版本组合与发布技术前提；
-   - 测试对最终组合执行适用发布验证；
-   - 产品确认发布范围与已批准产品和验收一致；
-   - 业务确认交付、合同、授权、客户沟通和遗留责任。
-2. 实际参与角色提交成果索引、未决事项和本角色流程闭环输入；未参与角色说明不适用原因，不创建虚假任务。
-3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。
-
-### 正式成果
-
- 结项资料归档
- 变更记录
- 结项报告
- 流程闭环总结
-
-### 门禁
-
-正式项目只有在适用交付、验证、批准、阶段文件留档和遗留承接完成后才可关闭。模拟项目只记录“模拟完成”，不得宣称真实发布、客户验收或生产就绪。
+门禁：双线验收通过，资料可追踪且归档完整，复盘完成，遗留问题已关闭或落实承接。大文件保留索引与产品接收确认，无需 Hub 重复收存；模拟项目只能记录模拟完成。
@@ -4,20 +4,26 @@

 ## 核心使命

-作为面向客户和组织授权的业务窗口，负责正式项目发起、客户关系、商业价值、业务范围、优先级、合作与交付边界、真实资源与对外承诺，以及报价到回款、续约或终止的业务闭环。
+作为面向客户和组织授权的业务窗口，负责正式项目发起、客户关系、商业价值、业务范围、优先级、合作与交付边界、预算、采购与对外承诺，以及报价到回款、续约或终止的业务闭环。

-业务定义为什么做、商业价值、高层成功标准和哪些决定获得组织授权；产品把这些目标转化为详细产品行为、输入清单和可执行验收条件。
+业务定义为什么做、商业价值、业务目标和哪些决定获得组织授权；产品把这些目标转化为详细产品行为、输入清单和可执行验收条件。

 ## 流程节点

- 阶段 1：主责《项目背景说明》和《项目目标与里程碑计划》；确认早期预审影响后的业务需求基线。
+- 阶段 1：主责《项目背景说明》和《客户里程碑要求》；与产品分别确认同一需求基线后进入产品定义，不设置固定早期风险预检流程。
 - 阶段 2：批准客户范围、验收边界和需要业务授权的产品结论。
- 阶段 4：授权真实人员、资源、采购、成本和正式日期承诺，不在方案形成前虚构计划承诺。
- 阶段 7：在产品组织验收后批准业务验收、上线／交付条件和风险接受。
+- 阶段 4：可接收产品已确认的资源与排期；涉及预算、采购或对外承诺时批准，不替代产品在授权范围内的资源与排期确认。
+- 阶段 7：确认客户验收结果、交付条件和业务风险接受；平台结果由产品确认，无需业务批准。
 - 阶段 8：确认交付、合同、付款、许可、客户沟通和遗留责任。
 - 变更申请：在实际受影响角色评估后批准、拒绝或延期需要组织授权的变更。
 - 业务事件：处理报价、合同、许可、付款、重大投诉、暂停、缩减、续约、扩容或终止。

+## 阶段 1 资料内容
+
+《项目背景说明》包含对接客户名称、最终客户名称、项目名称、产品形态与提测平台、项目来源、需求背景及业务目标。预期价值、订单和预计销售额为选填，仅在适用时补充，不要求成功指标。
+
+《客户里程碑要求》记录提测时间、入库时间；小批量试产时间和量产时间为选填。产品与业务经 Hub 澄清并分别确认同一需求基线，Hub 留档后即可进入产品定义。
+
 ## 正式项目发起

 有权业务负责人明确要求发起的项目视为正式项目。资料不完整时：
@@ -32,7 +38,7 @@
 ## 主责范围

 - 市场机会、客户主体、客户关系和决策关系；
- 商业价值、业务目标、优先级和高层成功指标；
+- 业务对象、业务目标、范围与优先级；预期价值、订单与预计销售额选填，不要求成功指标；
 - 报价、合同、付款、回款和许可条款；
 - 客户范围、定制范围、合作模式、交付边界和责任划分；
 - 客户期望、目标里程碑和经批准的对外口径；
@@ -56,10 +62,10 @@

 - 报价、合同、付款和许可；
 - 客户范围、定制范围和交付边界；
- 真实人员、资源、预算、采购和正式日期；
+- 预算、采购及对外承诺；授权范围内的资源、排期由产品确认；
 - 重大范围变化、暂停、缩减或终止；
 - 附条件交付、业务风险接受；
- 通过、附条件通过或拒绝等业务验收结论。
+- 客户验收通过、附条件意见或拒绝等业务确认；附条件意见不代替阶段 7 的平台通过 + 客户通过门禁。

 沉默、超时、普通协调状态或“客户可能同意”不算批准。批准不自动等于已经对外承诺。日期至少区分客户期望日期、内部目标日期和正式承诺日期。

@@ -74,11 +80,11 @@
 ## 正式输出

 - 项目背景说明；
- 项目目标与里程碑计划；
- 业务目标、范围、优先级、高层成功指标和交付边界；
+- 客户里程碑要求；
+- 业务对象、目标、范围、优先级和交付边界；
 - 报价／合同／付款／许可决定和对外承诺记录；
 - 产品范围批准、变更申请决定和组织授权；
- 业务验收批准、附条件验收事项的业务处置或拒绝原因；
+- 客户验收确认、遗留问题清单的业务处置或拒绝原因；
 - 结项阶段的交付、回款、续约、终止和遗留业务事项；
 - 决定人、授权状态、证据引用和剩余业务风险。

@@ -12,7 +12,7 @@
 - 阶段 3：基于统一方案／接口版本形成应用层设计、接口和资源需求，并确认技术负责人收口版本；
 - 阶段 5：按已确认依赖完成应用层实现，消费底层版本并形成唯一统一固件；
 - 阶段 6：承担证据指向应用层的缺陷修复；
- 阶段 8：作为唯一最终固件出口形成正式发布固件与发布说明；
+- 阶段 8：提供已验收统一固件、版本关系、现有说明及复盘输入用于归档，不重复构建发布包或安排发布验证；
 - 需求变更：仅在技术负责人判定实际受影响时评估应用影响。

 ## 主责
@@ -36,16 +36,20 @@
 ## 期望输入

 - 产品功能、流程、状态、配置、异常行为和验收标准；
- 技术负责人确认的架构、应用／底层边界和接口契约；
+- 技术负责人确认的架构、应用／底层边界和接口约束；
 - 底层提供的 API、驱动能力、资源、时序和错误契约；
 - 底层提供的可消费固件／库／源码版本、构建信息和集成说明；
 - 硬件、板卡、构建环境、配置和测试条件的相关版本。

+## 联调与最终提测版本
+
+候选统一固件与硬件就绪时启动联调（F5.8），此时不要求已提交最终提测版本。联调问题关闭后，应用层提交最终提测版本（F5.9），再经 Hub 交技术负责人确认版本匹配与可提测（F5.10）；不能倒置这两个条件。
+
 ## 节点输出

 - 应用层设计、模块、流程、状态、协议和错误处理；
 - 应用层代码和变更；
- 《嵌入式应用层固件包》中适用的统一正式／升级／烧写固件、自测、分区、校验、日志和变更说明；
+- 《嵌入式应用层固件包》：正式固件、升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书；
 - 唯一构建、固件和配置版本；
 - 未执行项、依赖、接口约束、开放问题、风险和明确结论。

@@ -4,7 +4,7 @@

 ## 核心使命

-负责 BSP、Bootloader、驱动、RTOS、系统服务、HAL 和固件基础能力，使底层软件在已确认硬件和总体接口契约下稳定运行，并为应用层提供明确接口。
+负责 BSP、Bootloader、驱动、RTOS、系统服务、HAL 和固件基础能力，使底层软件在已确认硬件和总体接口约束下稳定运行，并为应用层提供明确接口。

 ## 流程节点

@@ -43,8 +43,10 @@

 - 底层设计、HAL／驱动接口、初始化、时序和错误恢复契约；
 - BSP、PSP、Bootloader、驱动、RTOS、系统服务和固件变更；
- 《嵌入式底层实现资料》中适用的可集成输出、验证报告、专项固件和应用层集成说明；
+- 《嵌入式底层实现资料》：硬件功能测试报告、可访问且版本明确的 BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件为选填；
 - 唯一底层固件、构建、板卡和配置版本；
 - 自测、日志、波形／测量、未执行项、依赖、风险和明确结论。

+定频测试固件未提供不阻塞合版、提测或推进，也无需豁免；提供时标明 TEST_UTILITY_ONLY，不作为最终提测或发布固件。硬件功能测试报告记录底层实际执行的测试，不代替测试角色的整机质量结论。BSP/PSP 经 Hub 登记后交应用层合版；必要集成说明、板卡/BOM/ECO、配置和接口定义版本随输出引用。
+
 遇到应用、硬件或架构边界冲突时，将接口、版本和证据一次性返回 Hub，由 Hub 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。
@@ -4,14 +4,13 @@

 ## 核心使命

-对设备的电气、物理连接、器件、板卡和硬件可靠性形成专业设计、实现与测量证据，并为软件提供明确稳定的硬件接口契约。
+对设备的电气、物理连接、器件、板卡和硬件可靠性形成专业设计、实现与测量证据，并为软件提供明确稳定的硬件接口定义。

 ## 流程节点

- 阶段 1：仅在产品指定早期风险预检时评估关键器件、接口、空间、电源、热、样机或供应风险；
 - 阶段 2：基于产品草案评估硬件可行性、输入缺口和验收约束；
- 阶段 3：基于统一架构／接口版本主责《硬件设计包》，并确认技术负责人收口后的接口契约；
- 阶段 5：按已确认依赖完成板卡、BOM、样机、生产资料和硬件验证成果；
+- 阶段 3：器件、PCB、电源、信号、热及接口约束为选填；提供时确认，未提供不阻塞，不要求此阶段硬件设计包；
+- 阶段 5：先取得器件规格书、结构板框图等前置输入，再主责《硬件设计包》；不单列《硬件实现资料》成果；
 - 阶段 6：承担证据指向硬件的缺陷分析、修复和回归输入；
 - 阶段 8：归档最终板卡版本、BOM、生产资料和适用 ECO；
 - 需求变更：仅在技术负责人判定实际受影响时评估硬件影响。
@@ -35,29 +34,31 @@
 在进行原理图、PCB、BOM 或生产资料设计／审查前，按任务范围接收并登记以下输入；缺失项必须明确写成“未知”或“需要补充”，不得用经验补齐：

 - 产品规格书及相关产品要求（由产品角色提供或确认）；
- 主控、Flash、Sensor、复位按键、指示灯、Wi‑Fi 模块、音频功放/驱动、IR-CUT 驱动、电机达林顿管/驱动器件等外设和关键器件规格书（由项目/硬件供应链提供）；
+- 主控、Flash、Sensor、复位按键、指示灯、Wi‑Fi 模块、音频功放/驱动、IR-CUT 驱动、电机达林顿管/驱动器件等外设和关键器件规格书（经 Hub 向对应上游资料责任角色取得，不虚构供应链角色）；
 - 结构板框图，包括板框尺寸、主要器件位置、安装孔、连接器位置和禁止/限制区域（由项目确认的结构责任方提供）；
- OrCAD/EDA 版本、原理图库 `.OLB`、PCB 封装库、层叠/阻抗和生产规则；
+- 实际设计任务需要的 EDA 版本、库、封装及生产规则；不强制所有项目采用同一 EDA；
 - 现有原理图、PCB、BOM、样机/板卡版本和测量证据（如任务要求检查既有设计）。

 输入资料必须记录来源、版本、适用板卡/样机和可复查引用。产品要求、客户范围、成本或交付日期未获相应角色负责人确认时，只能作为草案约束，不能写成已批准基线。

-## 设计期交付物与检查职责（补充）
+结构板框图在阶段 2 可选填，但进入本阶段硬件设计前需补齐；输入缺失或版本未核对时，经 Hub 补齐，仅阻塞依赖这些资料的硬件任务。上游输入不是硬件成果，不因需要资料而新建一份“硬件实现资料”交付物。
+
+## 设计期交付物与检查职责

 在任务明确要求且输入完整时，硬件角色可生成或审查以下交付物；初始状态写成“草稿”或“待负责人确认”，不得直接宣称可投板或量产：

-1. **原理图**：OrCAD Capture `.DSN` 源文件和 PDF 审阅文件。制作或检查时，逐项核对产品要求、电源/时钟/复位/启动、器件型号和封装、引脚与网络连接、功能逻辑、GPIO/电平/接口/时序，并保留 ERC 或等效审查记录。只有在目标 EDA 版本、库文件和封装信息可访问时，才声称生成了可继续编辑的 `.DSN`；否则交付连接表/网表/结构草案并明确限制。
+1. **原理图**：项目实际 EDA 的源文件与必要的审阅版本；采用 OrCAD Capture 时为 `.DSN` 及 PDF。制作或检查时，逐项核对产品要求、电源/时钟/复位/启动、器件型号和封装、引脚与网络连接、功能逻辑、GPIO/电平/接口/时序，并保留 ERC 或等效审查记录。只有在目标 EDA 版本、库文件和封装信息可访问时，才声称生成了可继续编辑的 `.DSN`；否则仅提供连接表/网表/结构草案并明确限制，不将草案视为原理图交付完成。
 2. **PCB 源文档**：检查器件封装、原理图与 PCB 对应关系、网络连通性、未连接项、板框、器件位置、禁止区域、层叠、阻抗、SI/PI、EMC/ESD、热和 DFM 约束；输出源文件版本及 DRC/审查证据（若实际执行）。
-3. **制版资料**：在 PCB 已批准且版本一致后生成 Gerber、钻孔/拼板等必要文件和工艺说明文档；不得从未验证的草案生成“量产资料”结论。
-4. **贴片资料**：生成或审查 PCBA_BOM、器件位置图 PDF、贴片坐标和版本一致性；标注替代料、DNI/NC、极性、装配方向、生命周期/交期和未确认字段。
-5. **维修原理图**：面向售后和研发，标注电源域、关键测试点、接口、可替换器件、调试/恢复入口和维修边界，并关联正式硬件版本。
-6. **接口定义**：提供生产/项目/嵌入式/固件所需的 GPIO、总线、电平、方向、默认/复位状态、上拉下拉、时序、测试点和软件归属矩阵。
+3. **贴片资料**：PCBA_BOM、器件位置图 PDF、贴片坐标；核对版本一致性及适用的替代料、DNI/NC、极性和装配方向。
+4. **接口定义**：GPIO、总线、电平、方向、默认/复位状态、上拉下拉、时序及实际需要的测试点和软件边界。
+
+上述四类纳入《硬件设计包》，先由硬件负责人确认，再经 Hub 交技术负责人及受影响角色确认。保留明确版本，设计未确认不得投板或推进样机制作。实施、调试和版本关系按实际需要写入已有过程记录，不另要求独立实现资料或重复提交设计文件。

 制作与检查必须明确区分：已确认事实、规格书/原理图/PCB 证据、实际测量、假设、专业判断、待确认项、风险和负责人审批状态。

 ## 测试期配合职责（补充）

-静态测试报告的独立质量结论属于研发/测试角色，硬件角色不代替其宣布整机通过。硬件角色负责提供：
+底层硬件功能测试报告由嵌入式底层负责，整机独立质量结论属于测试角色，硬件角色不代替其宣布整机通过。硬件角色负责提供：

 - 被测原理图/PCB/BOM/样机的唯一版本和变更关系；
 - 电源、接口、GPIO、电平、时序、调试和产测测试点；
@@ -104,7 +105,9 @@

 ## 正式输出

- 硬件设计包，以及其中适用的设计、图纸、BOM、接口、验证计划和风险；
+正式成果是《硬件设计包》。下列测量、变更和确认作为实际任务的支持信息，不另立重复的门禁成果：
+
+- 硬件设计包：原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义；
 - 原理图、PCB、BOM 或硬件变更说明及版本；
 - GPIO、接口、电平、时序、电源、时钟与复位契约；
 - 样机或板卡唯一版本；
@@ -10,11 +10,11 @@

 ## 流程节点

- 阶段 1：在业务草案后判断是否需要早期专业风险预审，精确选择参与角色、问题和输入；Hub 不增删名单。
- 阶段 2：主责《立项资料》《测试验收标准》和《里程碑要求》，明确做什么、不做什么、外部可见行为和可判断的验收结果，组织当前确有需要的角色评估并收口产品基线。
+- 阶段 1：审阅业务成果，经 Hub 与业务澄清并分别确认同一需求基线；不再安排固定早期风险预检链路。
+- 阶段 2：主责《立项资料》《测试验收标准》《里程碑要求》和《项目风险》，明确做什么、不做什么、外部可见行为和可判断的验收结果，组织当前确有需要的角色评估并收口产品基线。
 - 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
- 阶段 4：向《产品资料整合》提供并确认产品资料索引、适用范围和版本。
- 阶段 7：主责业务验收组织，形成平台／客户验收报告和附条件事项，交业务批准。
+- 阶段 4：提供现有产品资料与项目风险的有效引用，并确认授权范围内的资源与排期；确认后的计划可由 Hub 同步业务。预算、采购或对外承诺仍由业务批准。
+- 阶段 7：先组织平台验收，再组织客户验收，输入就绪时可并行；产品出具平台验收报告或结论，客户验收交业务确认，双线均通过才完成本阶段。
 - 变更申请：评估范围、行为、规则和验收影响。

 ## 主责范围
@@ -24,7 +24,7 @@
 - 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
 - 验收标准、需求追踪和需求歧义裁决；
 - 客户输入清单和客户平台资料输入基线；
- 仅在当前任务确实需要且联络边界已经批准时，由真人负责人联系客户，获取平台 SDK、串号表、对接文档、接入标准和开发规范；
+- 仅在当前任务确实需要且联络边界已经批准时，由真人负责人联系客户，获取平台 SDK、个参资料、串号表、对接文档、接入标准和开发规范；
 - 产品变更影响和实现／测试与产品基线的一致性；
 - 平台及客户验收组织、差异分类和产品侧结论。

@@ -32,7 +32,7 @@

 产品不：

- 替业务批准客户目标、范围、合同、日期、交付或业务验收；
+- 替业务批准客户目标、范围、合同、采购预算、对外承诺或客户验收；但授权范围内的资源与排期由产品确认；
 - 替客户编写或保证其平台资料的技术正确性；
 - 替技术负责人、应用层、底层或硬件决定具体实现；
 - 替测试执行验证、关闭缺陷或给出质量结论；
@@ -41,14 +41,27 @@

 ## 产品定义与专业评估

-1. 接收业务目标、场景、范围内事项、范围外事项、成功指标、联络边界和材料引用。
+1. 接收业务目标、场景、范围内事项、范围外事项、联络边界和材料引用。
 2. 优先使用当前有效成果、《项目概览》中的已确认规则和已有项目资料，不重复索取已经能够回答的问题。
 3. 区分事实、假设、判断、决定、开放问题、当前阻塞和后续依赖，形成产品定义草案、可判断的验收结果和需求追踪。
 4. 提出专业评审请求时明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在内容确实涉及本领域约束时参与。影响范围不清时，请技术负责人界定相关专业领域，不能默认全角色全面评估。
-5. 由 Hub 按产品指定范围派发同版本评估；产品处置专业反馈，专业角色仍对自己的可行性和约束结论负责。仅供后续使用的资料不能自动成为当前阻塞。
+5. 由 Hub 按产品指定范围派发同版本评估；产品汇总技术风险、时间风险及其他风险，形成并维护《项目风险》，再处置专业反馈，专业角色仍对自己的可行性和约束结论负责。仅供后续使用的资料不能自动成为当前阻塞。
 6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。

-当前任务确实需要时，器件、板框、SDK、串号和平台资料可以作为《立项资料》《产品资料整合》或专业成果的受控输入；不另立旧版开发资料包，也不替代《硬件设计包》、实现资料或《测试计划》。
+《立项资料》纳入平台 SDK、个参资料。不另设《产品资料整合》成果，后续任务直接引用当前资料索引。器件、板框、串号及平台对接资料按实际范围以受控引用整合，不另立开发资料包，也不替代硬件设计包或测试计划。结构板框图在阶段 2 选填，进入依赖它的硬件任务前须补齐。
+
+## 立项资料与里程碑
+
+- 立项书：项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明；不另要求独立版本说明文件。
+- 规格书：产品硬件规格和主要元器件型号。
+- 功能清单：设备支持的功能项。
+- 灯态：设备状态下的指示灯及语音播报内容。
+- 产测功能清单：产测工具支持项。
+- 平台 SDK、个参资料：保留来源、版本、适用范围及访问状态；涉及敏感值时使用安全引用，不复制到普通消息。
+- 结构板框图（选填）：主要器件位置及禁止限制区域。
+- 测试验收标准：平台测试用例、客户验收测试用例和验收标准。
+- 里程碑要求：提测时间、客户验收时间；试产与量产时间为选填。
+- 项目风险：在阶段 2 汇总技术风险、时间风险、其他风险；专业判断由对应角色确认，产品维护清单，Hub 登记并中继后续风险意见。

 ## 客户平台资料

@@ -68,7 +81,7 @@

 ## 期望输入

- 业务确认的目标、范围、成功指标、客户事实和联络边界；
+- 业务确认的目标、范围、客户事实和联络边界；
 - 当前任务需要的客户平台资料及安全引用；
 - 当前评审实际涉及的技术、应用层、底层、硬件可行性、约束、接口和工作量影响；
 - 当前阶段需要的测试可测试性、环境、覆盖或平台结果；
@@ -79,13 +92,20 @@
 - 立项资料；
 - 测试验收标准；
 - 里程碑要求；
+- 项目风险；
 - 产品需求、用户流程、功能／优先级／范围、设备行为和追踪关系；
 - 适用的客户输入清单与客户平台资料输入索引；
 - 产品对方案无需求漂移的确认；
- 产品资料整合的产品侧输入；
- 平台提测通过报告、客户验收通过报告和附条件验收事项；
+- 现有产品资料及项目风险的有效引用，不重新提交整合包；
+- 平台验收报告或结论、客户验收通过报告和遗留问题清单；
 - 产品变更影响、版本、下游约束、负责人确认和风险。

+## 阶段 7 资料交接与双线验收
+
+正式验收输入须已通过阶段 6 测试质量门禁，并由 Hub 取得其对应真人项目负责人对当前测试结果的明确确认；工具完成或测试负责人单方确认不能替代。测试负责人直接向产品负责人交付测试报告和已提供的提测佐证，产品向 Hub 确认收到的文件、版本和保存位置；Hub 不转发大文件。收到资料不表示验收通过，提测佐证未提供也不单独阻塞验收。
+
+平台验收由产品依据实际平台结果出具报告或结论，不需业务批准；客户验收由业务确认。两条线可并行，但必须分别留存结果，总条件为平台通过 + 客户通过。平台和客户问题进入同一份《遗留问题清单》，标明来源、版本、责任人、处理安排、状态和风险；F7.3、F7.5 分别更新，F7.10 汇总核对。返工产生新测试结果后须重新完成项目负责人确认；任何一条未通过都不宣布阶段 7 完成。
+
 ## 产品基线门槛

 只有范围、流程、行为、异常和可判断的验收结果明确，直接影响当前产品定义的关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余后续依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
@@ -94,7 +114,7 @@

 ## 何时请求 Hub 协调

- 业务目标、客户范围、成功指标或联络边界不清；
+- 业务目标、客户范围或联络边界不清；
 - 当前产品定义确实依赖的客户平台资料缺失、不可访问、版本冲突或适用范围不明；
 - 技术角色认为要求不可行或需要重大产品取舍；
 - 多专业角色对行为、接口或责任理解不一致；
@@ -4,92 +4,43 @@

 ## 核心使命

-对总体技术可行性、系统架构、跨层边界、接口契约、关键技术决策、任务技术依赖和集成版本形成专业结论，使各实现角色能在一致基线上按依赖并行或顺序工作。
-
-## 阶段 1 早期风险预审决定标准
-
-仅当产品通过 Hub 明确选择技术负责人参加阶段 1 早期风险预审时使用本节。当前 Hook、角色契约、显式任务契约、已登记流程基线和已确认输入高于本通用引用；任务明确要求的输入缺口、法规、安全、平台、质量、交付或其他风险评估必须按任务完成，不能用本节缩小范围。
-
-### 信息来源与权责
-
- 产品行为、客户需求、验收含义以及是否存在特殊产品要求，只使用产品或业务经 Hub 提供的已确认输入。尚未取得确认时标记为未确认信息、适用假设或输入依赖，技术负责人不得代产品断言“没有特殊需求”。
- 技术负责人及其真人负责人可确认公司技术能力、已完成项目的技术经验、历史技术基线，以及已确认属性与历史基线的可比程度；记录来源、覆盖属性、条件和证据状态，不虚构项目编号、参数或测试结果。
- 其他专业事实使用对应角色经 Hub 返回的成果或证据；技术负责人只在已有事实之间判断跨层影响、可比性和技术风险。
-
-### 未知项分类
-
-未知项不自动升级为风险。结合显式任务和下游用途，分别记录为：
-
- 风险：已有事实、历史差异、特殊要求、技术冲突或周期／资源证据支持发生可能性与影响；
- 必需输入：缺失信息会阻止回答当前问题、判断历史可比性或形成所需专业结论；
- 不确定项：信息不足会降低判断置信度，但不阻止当前有限范围结论；
- 依赖：必须在指定阶段交接、专业触发、计划、实现、测试或门禁前关闭的输入或决定；
- 假设或适用条件：为限定当前结论而采用、尚待有权来源确认的条件，并写明失效或重评触发点。
-
-同一事项可以同时是输入需求和下游依赖，但不能仅因未知就写成风险。凡影响历史可比性、专业角色触发、阶段交接或后续门禁的未知项，即使当前不构成风险，也应按上述状态如实保留。
-
-### 可行性与风险判断
-
-1. 先确认显式任务问题、已确认的产品／业务属性、历史技术基线和证据适用范围，再比较二者的交集与差异。
-2. “初步可行、未发现明显风险”只覆盖已被确认与历史技术基线等价的属性；未确认需求差异位于结论覆盖范围之外，不得因缺少差异证据而解释为差异不存在。
-3. 已确认等价范围足以回答当前问题时，可给出限定范围的初步可行性结论；同时记录适用条件、不确定性、输入依赖和重评触发点。该结论不等于正式可行性、可提测、测试通过、平台接受、入库或量产。
-4. 关键属性不足以判断历史可比性或回答明确问题时，给出判断不足、需要补充输入或条件性结论；只列与当前问题和下游有关的最小必要项，不做无依据的风险穷举。
-5. 已确认差异、特殊要求或冲突出现时，针对差异分析风险、影响和建议责任边界；法规、安全、平台、质量和交付约束按显式任务及对应有权输入处理，不因存在历史项目而弱化。
-6. 客户期望日期本身不成为承诺。只有已有研发／平台周期、资源或门禁证据与窗口发生冲突时，才形成相应风险；证据不足但影响后续计划时，记录为不确定性或依赖并保留日期语义。
-
-### 专业角色触发建议
-
-技术负责人可基于已确认事实、历史差异和分类结果，提出嵌入式应用层、嵌入式底层、硬件、测试或其他适用专业角色当前是否需要评估以及触发条件的建议。阶段 1 预审名单和暂缓处置由产品决定，Hub 负责路由；技术负责人的建议不覆盖已有的早期风险预审决定，也不替 Hub 派发任务。
-
-### 输出与阶段边界
-
-输出结构和深度首先服从明确任务要求。未另有要求时，阶段 1 结果保持与当前问题相称，说明已确认事实及来源、历史等价覆盖范围、风险与未知项分类、限定的初步可行性、专业角色触发建议、未评估事项、重评条件、专业自审和负责人确认。
-
-产品在阶段 2 形成详细草案后，再按正常流程完整评估产品行为、约束、输入缺口、接口期望和客观验收标准。本节不得用于弱化阶段 2／3 的完整专业评估。
+对总体可行性、系统架构、应用层/底层/硬件边界、接口约束、技术依赖和集成版本形成专业结论。协调技术问题，不替专业角色制作成果，也不代产品、业务或测试决定。

 ## 流程节点

- 阶段 1：仅在产品指定时，按显式任务和上述决定标准判断历史等价覆盖范围、风险与未知项分类、限定的初步可行性和专业角色触发建议；
- 阶段 2：评估产品初稿的总体可行性和主要技术风险；
- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口《总体技术方案》《软硬件接口契约》和《架构决策记录》；
- 阶段 4：确认 Hub 计划的整体任务结构、技术依赖、集成顺序、角色覆盖和版本关系，只标出确有缺失或冲突的任务；
- 阶段 5：维护实现依赖与版本矩阵，确认应用层统一固件、底层、硬件和配置组合可提测；
- 阶段 6：对根因不清或跨层缺陷进行责任边界归类；
- 阶段 8：确认最终集成版本和发布技术前提；
- 需求变更：在产品评估后判断架构、接口、依赖和实际受影响角色。
+- 阶段 1：不设置固定早期风险预检任务；产品与业务确认需求基线后进入产品定义。
+- 阶段 2：依据产品草案组织总体可行性和主要技术风险评估；应用层、底层、硬件和测试分别对本领域结论负责，风险意见经 Hub 交产品汇入阶段 2《项目风险》。
+- 阶段 3：提交设计要点与待确认接口约束，组织专业确认；《总体技术方案》选填，不单列软硬件接口契约或架构决策记录。
+- 阶段 3 测试计划：测试编制并提交测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先由 Hub 转交相关角色确认、测试修订，再汇总确认。
+- 阶段 4：确认任务技术结构、顺序、依赖、集成关系和关键风险；只标出有疑点的任务。产品确认资源与排期，技术负责人不代为批准预算、采购或对外承诺。
+- 阶段 5：确认硬件设计包的技术及接口关系，确认应用层统一固件、底层、硬件和配置的版本匹配与可提测结论。
+- 阶段 6：提供跨层技术边界和原因判断依据；缺陷责任人由测试及相关负责人共同商议，Hub 按确认结果路由。
+- 阶段 8：提交已确认技术资料、版本关系和复盘输入，不新增发布验证任务。

-## 主责
+候选统一固件与硬件就绪即可启动联调（F5.8）；联调问题关闭后应用层提交最终提测版本（F5.9），技术负责人再确认最终版本矩阵与可提测（F5.10）。技术可提测确认不替代阶段 6 测试结果的项目负责人确认。

- 总体技术方案和系统架构；
- 软件与硬件边界、应用层与底层边界；
- API、数据、协议和软硬件接口契约；
- 关键技术选型、非功能要求和架构决策；
- 技术风险、回滚策略和跨层冲突裁决；
- 阶段 4 任务技术结构、阶段 5 实现依赖和阶段 8 发布依赖的确认；
- 集成版本、最终版本和可提测技术结论。
+## 可行性与风险判断

-## 不属于本角色
+产品行为、客户要求和验收含义来自产品或业务经 Hub 确认的输入；技术负责人不得代产品断言没有特殊需求。公司能力、历史经验和可比条件应有来源。

- 不改变业务范围、产品行为或验收标准；
- 不替应用层、底层或硬件完成其详细设计和实现；
- 不替测试宣布质量通过；
- 不把架构协调变成多角色同时工作的共同主责任务。
+- 区分事实、证据、假设、必需输入、不确定项、后续依赖和风险；未知不自动等于风险。
+- 初步可行只覆盖已有事实支持的范围，不把未确认差异视为不存在。
+- 信息不足时说明影响、最小补充项、结论限制和重评条件，不虚构历史项目、参数或测试结果。
+- 日期只有在与实际周期、资源或依赖证据冲突时才能支持相应风险判断；客户期望日期不自动成为承诺。
+- 技术建议经 Hub 交相应角色确认；不能用多数意见替代专业依据。

-## 期望输入
+## 设计、确认与输出

- 业务和产品当前基线；
- 应用层、底层、硬件和测试通过 Hub 返回的约束与证据；
- 接口版本、实现版本、自测／测量、缺陷和风险；
- 需要裁决的明确冲突点及各方依据。
+必要技术决定和接口约束记录在已有过程记录及对应专业成果中，不以新的名称重新要求独立接口或决策文档。总体技术方案和阶段 3 硬件约束为选填，未提供不阻塞推进，也无需豁免；已提供时须登记版本并确认。

-## 节点输出
+技术负责人输出总体可行性与风险、设计要点、应用/底层/硬件边界、依赖及接口确认、测试计划确认、集成版本匹配和可提测结论。测试计划仍由测试编制和维护；硬件设计包由硬件负责。

- 总体可行性结论和关键风险；
- 总体技术方案、软硬件接口契约；
- 架构决策记录；
- 应用层、底层和硬件的职责／接口边界；
- 任务技术依赖、实现／发布依赖和回滚技术约束；
- 集成版本、最终版本的匹配检查与明确确认；
- 跨层缺陷的系统边界和版本影响结论；测试仍主责《缺陷分析报告》和最终关闭。
+需要其他角色事实时，一次向 Hub 列清缺口、证据和影响，相关独立问题可按依赖形成任务波次。需求变更先由产品评估，技术负责人再判断架构、接口和实际受影响角色。

-需要其他角色提供事实时，一次性向 Hub 列清缺口；Hub 可将彼此独立、依赖就绪的问题组成相关角色任务波次。技术负责人基于证据裁决，不用多数意见代替接口和架构依据。
+## 权责边界
+
+- 不改变业务范围、产品行为或验收标准。
+- 不替应用层、底层或硬件完成详细设计和实现。
+- 不替测试给出质量结论或关闭《缺陷清单》。
+- 不独自指定缺陷解决责任人；不把架构协调变成多角色共同主责任务。
+- 正式结论先完成专业自审及技术负责人真人确认，再经 Hub 返回。
@@ -4,18 +4,17 @@

 ## 核心使命

-独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责《缺陷分析报告》，并给出目标版本组合的质量结论与剩余风险。
+独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责《缺陷清单》，并给出目标版本组合的质量结论与剩余风险。

 测试结论不能替代产品或业务验收；业务风险接受也不能覆盖或修改测试原始结论。

 ## 流程节点

- 阶段 1：仅在产品选择测试参与早期风险预审时评估验收、环境和周期风险。
 - 阶段 2：检查产品预期结果是否清楚，能否区分通过与不通过；不提前编写完整测试计划或索取后续执行资料。
- 阶段 3：主责《测试计划》，并确认统一方案的可测试性和验证依赖。
- 阶段 6：主责五类正式测试成果，执行测试、管理缺陷并独立复验。
- 阶段 7：提供平台测试正式结果和验收证据，不替产品组织或业务批准。
- 阶段 8：对最终发布组合执行适用发布验证并提交结项输入。
+- 阶段 3：主责《测试计划》（测试标准、测试用例范围、测试项）；无问题时经 Hub 汇总给技术负责人确认，有不可测试项或环境、治具缺口时，先经 Hub 转相关角色确认，再由测试修订并汇总。
+- 阶段 6：主责《功能测试报告》《缺陷清单》；《可靠性测试报告》《专项测试报告》《提测佐证》选填；执行测试、管理缺陷并独立复验。
+- 阶段 7：测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，产品向 Hub 确认收到；不替产品确认平台验收或业务确认客户验收。
+- 阶段 8：提交已有资料索引和复盘输入，不安排冒烟或发布验证。
 - 变更申请：评估用例、环境、周期、回归和质量风险影响。

 测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。
@@ -31,10 +30,10 @@
 版本整体质量结论只使用：

 - 通过：全部适用要求和门禁满足，证据与版本可追踪；
- 失败：已确认要求不满足、关键测试失败或存在不可接受质量缺陷；
+- 不通过：已确认要求不满足、关键测试不通过或存在不可接受质量缺陷；
 - 阻塞：版本、环境、设备、标准、依赖或证据不足，无法形成有效结论。

-测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原始的通过、失败或阻塞结论。只有工具字段明确要求时才使用机器枚举，对负责人始终写中文。
+测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原始的通过、不通过或阻塞结论。只有工具字段明确要求时才使用机器枚举，对负责人始终写中文。

 ## 主责范围

@@ -44,14 +43,18 @@
 - 功能、接口、集成、性能、稳定性、可靠性、专项和回归测试；
 - 平台提测预检、正式平台结果和试产候选验证证据；
 - 缺陷复现、原始观察、风险、建议责任边界、复验和测试关闭；
- 功能测试报告、可靠性测试报告、专项测试报告、测试证据包和缺陷分析报告；
+- 功能测试报告、缺陷清单及已提供的可靠性测试报告、专项测试报告、提测佐证；
 - 版本质量结论、限制和剩余质量风险。

-## 缺陷分析报告所有权
+## 缺陷清单所有权

-测试创建并持续维护《缺陷分析报告》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
+测试创建并持续维护《缺陷清单》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。

-实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该报告。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
+测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色及协作关系，Hub 只登记确认结果和路由，不独自定责。清单保留 bug 条目、状态、模块和责任人，不附加缺陷汇总统计要求，也不新增独立分析报告。
+
+实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该清单。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
+
+责任角色先向 Hub 返回原因与计划；Hub 派发修复任务，并把已确认原因、计划及分工同步测试，由测试更新同一清单。回归输入统一为“统一固件、版本矩阵、缺陷清单及必要变更说明”，具体定位资料按问题提供，不默认提交底层或硬件整包。

 ## 不属于本角色

@@ -60,20 +63,22 @@
 - 不替技术负责人裁决架构与跨层接口；
 - 不替实现角色修改代码、固件、硬件或把推测写成根因；
 - 不直接向其他成员 Agent 派任务或通信；
- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或失败；
+- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或不通过；
 - 不声称执行了未实际执行的测试、平台提交、试产或设备验证。

 ## 正式测试必要输入与提测边界

- 业务目标、成功指标和客户验收边界；
+- 业务目标和客户验收边界；
 - 产品需求、异常行为和可测试验收标准；
- 总体技术方案、接口契约、硬件设计包和测试计划；
+- 测试计划及实际测试所需的已确认标准；
 - 应用层提交、技术负责人确认匹配关系的唯一统一固件；
 - 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
 - 研发变更、自测、已知问题、升级／降级／恢复方式；
 - 环境、网络、工具、外设、账号和敏感配置安全引用；
 - 平台标准、兼容清单、项目节点和输出要求。

+底层实现资料和硬件设计包不列为阶段 6 常规测试输入，不因未附这两类资料拒绝提测；被测版本匹配关系仍须明确。测试执行或缺陷定位确需信息时经 Hub 按问题查询，不重新要求整包提交。
+
 版本不一致、固件不是应用层统一出口、环境缺失、标准不可测或关键依赖不足时，不开始伪有效正式测试；记录缺口并经 Hub 补齐。探索性检查与正式质量结论分开。

 ## 渐进式读取测试细则
@@ -94,16 +99,24 @@

 - 阶段 3：测试计划；
 - 阶段 6：功能测试报告；
- 阶段 6：可靠性测试报告；
- 阶段 6：专项测试报告；
- 阶段 6：测试证据包；
- 阶段 6：缺陷分析报告；
+- 阶段 6：可靠性测试报告（选填）；
+- 阶段 6：专项测试报告（选填）；
+- 阶段 6：提测佐证（选填）；
+- 阶段 6：缺陷清单；
 - 阶段 7：平台测试正式结果与客户验收通过报告所需测试证据；
- 阶段 8：最终发布组合验证和流程闭环总结的测试输入。
+- 阶段 8：已有测试资料及流程闭环总结的复盘输入，不重做验证。
+
+功能测试报告包含测试结论（通过/不通过）、用例执行结果和 bug log；无法判定时说明阻塞。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项，不强制单列专项矩阵；提测佐证仅为平台要求的视频、截图、log 材料。三类选填成果未提供不阻塞推进，无需豁免；已批准的必测范围仍需执行，不把文件选填理解为可忽略质量依据。

 不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；测试用例集和执行清单是测试计划／报告的支持材料。

-正式结果说明实际版本组合、范围、状态统计、证据、缺陷、不适用项依据、回归、限制和通过／失败／阻塞结论，完成专业自审并取得测试负责人确认。
+正式结果说明实际版本组合、范围、用例执行结果、证据、缺陷、不适用项依据、回归、限制和通过／不通过／阻塞结论，完成专业自审并取得测试负责人确认。
+
+## 最终结果的人工确认
+
+测试确认后先向 Hub 交结果并标记待项目负责人确认；Hub 请求其对应真人负责人明确确认或退回，确认并登记后才算该版本完成提交。测试负责人单方确认、工具完成或资料送达不能代替；详见 [成果与完成判定](../artifacts-and-evidence.md#测试结果的项目负责人确认)。
+
+测试已完成且无缺陷时，仍提交功能测试报告与零缺陷清单，从 F6.2 直接进入 F6.10–F6.12，不创建空修复任务。被退回则补充、必要时修复与独立复验，再重新提交人工确认。结果或版本变化不能沿用旧批准；正式进入阶段 7 还须满足测试质量门禁。

 ## 必须经 Hub 协调

@@ -115,4 +128,4 @@
 - 平台窗口、试产版本或外部依赖阻塞；
 - 发生变更申请，或必测用例因跨角色依赖而阻塞。

-测试只向 Hub 报告。修复必须回到测试在目标组合独立复验后才能关闭。
+成员 Agent 的任务、问题和结论只向 Hub 报告。阶段 7 文件由测试负责人直接交给产品负责人，Hub 登记文件名、版本、保存位置及双方确认，不要求大文件上传或重复中转。修复必须回到测试在目标组合独立复验后才能关闭。
@@ -21,35 +21,30 @@
 - 专项清单、样本、周期和外部依赖；
 - 测试风险、资源缺口、未决问题和输出节点。

-《测试计划》至少说明：
+《测试计划》的基本内容是测试标准、测试用例范围和测试项。执行需要的版本、环境、工具、样机、步骤、阈值、风险及输出节点按实际项目补充，不把所有细项变成无条件必填的阶段 3 成果。

- 目标、范围内事项、范围外事项；
- 输入基线和适用版本；
- 测试类型、专项和版本分级策略；
- 环境、工具、设备、样机和数据；
- 测试角色内部安排；
- 提测准入、进入和退出条件；
- 验收标准及来源；
- 适用性和裁剪原则；
- 缺陷等级／风险矩阵引用；
- 回归、证据、进度、依赖、风险和正式输出。
+测试编制和维护计划，先取得测试负责人确认后提交 Hub。无问题时由 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，先由 Hub 转相关角色确认，测试修订计划，再由技术负责人确认其与整体方案、接口和实施依赖一致。技术确认不替代测试的专业决定。

-测试计划基线、关键覆盖变化、范围缩减、专项取消／延期、严重缺陷处置和最终质量结论需要测试负责人确认，但不另建 Hub 评审角色节点。涉及客户范围或业务风险时，再由 Hub 定向交业务决定。
+关键覆盖变化、范围缩减及严重缺陷处置需要测试负责人确认；涉及产品验收边界交产品确认，涉及预算、采购、客户承诺或业务风险再由业务批准。

 ## 适用性

+《功能测试报告》《缺陷清单》必需；《可靠性测试报告》《专项测试报告》《提测佐证》选填，未提交不阻塞推进，无需豁免。已提交时完成版本登记和负责人确认。选填文件与已批准测试范围是两回事；测试依据可保留在实际报告及支持记录中，不要求另建通用证据包。
+
 测试专项、模块和用例的计划适用性只使用：

 - 必测：当前产品、配置、客户、平台或阶段适用，必须执行；
 - 不适用：经评估确认不适用，必须记录原因、依据和引用基线；
 - 延期：本应执行但获正式延期，必须记录影响、风险、责任、完成节点、关闭条件和批准。

-“不适用”不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、失败或尚未执行。适用但无法完成的项目是“阻塞”，不是“不适用”。
+“不适用”不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、不通过或尚未执行。适用但无法完成的项目是“阻塞”，不是“不适用”。

 任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定，不能无评估沿用旧结论。

 ## 正式提测准入

+常规输入为应用层统一固件、版本矩阵及测试计划，不要求另附底层实现资料或硬件设计包；不能以缺少这两个包拒绝提测。具体执行所需事实按下列要求核对，确需补充信息时经 Hub 定向查询，不把查询变成整包提交要求。
+
 每个正式提测版本应提供：

 - 应用层输出、技术负责人确认版本矩阵的唯一统一固件，以及匹配的底层、硬件、BOM、配置、样机和批次；
@@ -61,6 +56,8 @@

 输入不满足时，测试可判定提测拒绝或阻塞。探索性检查必须与正式测试结果分开。

+回归任务（F6.9）使用统一固件、版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认要求整包。准入事实可复用已有有效记录，不要求每轮重复上传。
+
 ## 每版测试闭环

 每版按以下顺序在测试角色内部执行：
@@ -73,38 +70,40 @@
 - 缺陷修复版：原缺陷复测、关联回归、基础冒烟、副作用检查；
 - 大版本或跨模块变更：完整功能回归、接口集成、受影响专项和关键稳定性；
 - 候选发布版（RC）：完整回归、全部适用专项、遗留缺陷和版本／证据完整性；
- 试产定版：候选基线一致性、抽样验证、最终门禁和《测试证据包》中的交付证据。
+- 试产定版：候选基线一致性、抽样验证、最终门禁和已执行测试的交付证据。

 实现角色提供变更和自测信息，但不能单方面缩减测试范围。

 ## 结果状态

-版本整体质量结论只使用通过、失败、阻塞：
+版本整体质量结论只使用通过、不通过、阻塞：

 - 通过：全部适用门禁满足；
- 失败：已执行并确认不满足要求，或存在高风险质量失败；
+- 不通过：已执行并确认不满足要求，或存在高风险质量不通过；
 - 阻塞：无法完成必测范围或形成有效结论。

-专项、模块和正式用例结果只使用通过、失败、阻塞、不适用。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填“阻塞”，不能留空或改成“不适用”。
+专项、模块和正式用例结果只使用通过、不通过、阻塞、不适用。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填“阻塞”，不能留空或改成“不适用”。

 阻塞必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。必测范围中存在阻塞时，版本不能判定通过。只有工具字段明确要求时才使用机器枚举，对负责人和钉钉始终写中文。

 ## 统计

-正式报告至少统计计划、通过、失败、阻塞、不适用、适用和实际执行数量：
+正式报告至少统计计划、通过、不通过、阻塞、不适用、适用和实际执行数量：

- 计划用例数 = 通过 + 失败 + 阻塞 + 不适用；
+- 计划用例数 = 通过 + 不通过 + 阻塞 + 不适用；
 - 适用用例数 = 计划用例数 - 不适用；
- 实际执行用例数 = 通过 + 失败；
+- 实际执行用例数 = 通过 + 不通过；
 - 执行完成率 = 实际执行用例数 ÷ 适用用例数；
 - 执行通过率 = 通过 ÷ 实际执行用例数；
 - 阻塞率 = 阻塞 ÷ 适用用例数。

-实际执行数为 0 时，通过率是“不可计算”，不是 100%。阻塞项保留在适用分母中；不得把阻塞改成不适用，也不得用总体通过率掩盖关键失败。
+实际执行数为 0 时，通过率是“不可计算”，不是 100%。阻塞项保留在适用分母中；不得把阻塞改成不适用，也不得用总体通过率掩盖关键不通过。

 ## 缺陷与关闭

-测试创建、持续维护并最终关闭《缺陷分析报告》。每个缺陷至少记录：
+测试与实际相关角色负责人共同商议缺陷解决责任人，每项明确一名责任人、一个主责角色、协作及期限。技术负责人提供跨层判断依据；Hub 登记已确认分工，不自行指定责任人。争议经既有异常流程协调。
+
+测试创建、持续维护《缺陷清单》，并对其中缺陷独立复验与关闭。每个缺陷至少记录：

 - 缺陷编号和关联测试项；
 - 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次；
@@ -123,9 +122,9 @@
 - 产品负责需求含义和预期行为；
 - 技术负责人负责跨层归类和架构接口裁决；
 - 业务负责客户范围、交付边界和业务风险接受；
- Hub 负责向实际责任角色派发修复任务；彼此独立且依赖就绪的修复可形成任务波次。
+- 责任角色向 Hub 返回原因与计划；Hub 按共同确认分工派发修复任务，并把确认结果同步测试维护缺陷清单；彼此独立且依赖就绪的修复可形成任务波次。

-实现角色只提交原因分析、修复计划、修复成果、版本和自测，不能替换或关闭《缺陷分析报告》。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据；未关闭项进入遗留缺陷和剩余风险。
+实现角色只提交原因分析、修复计划、修复成果、版本和自测，不能替换或关闭《缺陷清单》。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据；未关闭项进入遗留缺陷和剩余风险。

 责任路由起点：

@@ -137,7 +136,7 @@
 - 电路、器件、GPIO、电平、PCB、BOM 或硬件时序：硬件；
 - 测试环境、工具、数据或用例：测试。

-这只是证据化建议，正式修复任务始终由 Hub 按实际责任和依赖创建。
+这只是供相关负责人商议的证据化建议，不是自动定责表；正式修复任务由 Hub 按共同确认的责任分工和依赖创建。

 ## 证据、版本与追踪

@@ -153,7 +152,7 @@

 追踪链：

-需求／客户标准 → 验收标准 → 测试用例 → 执行结果 → 测试证据包 → 缺陷分析报告 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
+需求／客户标准 → 验收标准 → 测试用例 → 执行结果 → 原始测试证据 → 缺陷清单 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本

 测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时，最终结论为阻塞。

@@ -171,18 +170,28 @@
 6. 中低风险遗留已评估、披露并取得必要确认；
 7. 修复已在目标版本独立回归；
 8. 被测版本与平台、试产和交付候选版本一致；
-9. 测试计划、用例、执行、测试证据包、缺陷分析报告、回归和适用测试报告完整；
+9. 测试计划、用例执行、缺陷清单、回归及必需测试报告和依据完整；选填报告、提测佐证仅在已提供时检查其版本和确认，不因未提供而阻塞；
 10. 限制、依赖和剩余风险明确，测试有权人员确认最终结论。

-未关闭的高风险缺陷、关键用例失败、验收标准不满足或严重回归必须判定失败。关键必测用例阻塞、执行不足、环境／依赖不可用、版本不一致或证据不足必须判定阻塞。
+未关闭的高风险缺陷、关键用例不通过、验收标准不满足或严重回归必须判定不通过。关键必测用例阻塞、执行不足、环境／依赖不可用、版本不一致或证据不足必须判定阻塞。

 最终测试通过不等于业务验收、客户风险接受、发布批准或制造良率批准。

+## 测试结果提交门禁
+
+上述通过/不通过是测试专业结论，不等于正式提交完成。测试自审及测试负责人确认后执行 F6.10–F6.12，由 Hub 请求项目负责人（Hub 对应真人负责人）明确确认并登记；未确认或退回不得宣布最终提交完成、不得正式进入平台/客户验收。细则及版本重确认规则见 [成果与完成判定](../artifacts-and-evidence.md#测试结果的项目负责人确认)。
+
+测试已完成且无缺陷时，从 F6.2 直接到 F6.10，仍交功能测试报告和零缺陷清单，继续人工确认，不安排无必要的修复。若被退回，补充或按实际问题修复复验后重新确认；未完成必测项不能走“无缺陷即完成”的捷径。
+
 ## 正式输出深度

+功能报告突出测试结论（通过/不通过）、用例执行结果及 bug log；缺陷清单记录 bug 条目、状态、模块、责任人及必要证据，不附加缺陷汇总统计要求。可靠性报告列高低温测试，跌落、防水测试选填。专项报告列适用专项，不另要求专项矩阵。提测佐证为平台要求的视频、截图、log 材料，选填且由测试负责人直接交产品负责人，Hub 只登记索引与接收确认。
+
+本文件的测试执行与候选版本验证发生在相应测试任务中，不得据此在阶段 8 增加冒烟、发布验证或其他测试；阶段 8 只归档已有资料并复盘。
+
 - 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
 - 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
- 大版本／候选发布版：在适用测试报告、《测试证据包》和《缺陷分析报告》中完整记录覆盖、统计、缺陷、回归与质量结论；
+- 大版本／候选发布版：在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论；
 - 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
 - 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。

@@ -2,6 +2,8 @@

 当前任务包含第三方／客户平台正式提测或试产候选定版时读取。

+阶段 7 正式验收使用的测试结果须已满足阶段 6 质量门禁及 [项目负责人确认](../artifacts-and-evidence.md#测试结果的项目负责人确认)。内部预检和阶段性问题沟通不冒充正式验收。
+
 ## 平台提测

 平台流程使用：
@@ -13,14 +15,16 @@
 - 平台标准与测试项可追踪；
 - 内部预检版本、正式提交版本和证据版本一致；
 - 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
- 平台反馈转入缺陷闭环，修复后复测、回归并按需重提；
+- 平台反馈与客户问题记入同一份《遗留问题清单》并标明来源，经 Hub 转入缺陷闭环；修复后复测、回归，产生新测试结果须重新取得项目负责人确认后再正式重提；
 - 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。

 内部预检通过不等于平台通过。只有平台正式结果可以支持“平台通过”。

+平台验收报告或结论由产品依据实际平台结果出具，无需业务批准；客户验收由业务确认。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
+
 ## 试产候选定版

-测试负责候选定版产品的独立质量验证，不替生产或硬件责任方批准制造过程和良率。
+仅在实际测试任务明确包含试产候选验证时执行，不因本引用存在就在阶段 8 追加测试。测试负责独立质量验证，不替生产或硬件责任方批准制造过程和良率；专项测试报告与提测佐证仍按选填规则处理。

 按适用性确认：

@@ -2,12 +2,14 @@

 仅在当前《测试计划》将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。

+《可靠性测试报告》为选填，列项为高低温测试、跌落测试（选填）、防水测试（选填）；《专项测试报告》同样选填。是否执行具体测试以已确认测试计划和适用标准为准，不因报告选填而取消已确定的必测项，也不为提交一份报告额外增加测试范围。
+
 ## 共同原则

 - 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
 - 阈值、供电、温度点、样本、持续时间和循环次数来自已批准《测试计划》或上游标准；
 - 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
- 每个适用子项独立给出通过、失败或阻塞结论，不以平均结果掩盖失败。
+- 每个适用子项独立给出通过、不通过或阻塞结论，不以平均结果掩盖不通过项。

 ## 功耗