feat: 定版 V1.0 并同步模板复用规则与角色 Hook

2026-09-08 18:23:00 +08:00
1 parent 163f655cd0
commit ff9a4eeb89
@@ -43,8 +43,8 @@ Etunel 负责当前角色和会话绑定。不要向负责人询问或复述 rol
 只读取当前工作需要的引用：

 - Hub：先读 [Hub 工作流](references/hub-workflow.md)。
- 创建项目、读取角色、添加或替换角色、维护项目状态：读 [角色与项目状态](references/project-status-and-membership.md)。
- 选择阶段、正式成果、任务波次或交接：读 [项目生命周期](references/project-lifecycle.md)。
+- 创建项目、读取角色、添加或替换角色、查询或纠正项目状态：读 [角色与项目状态](references/project-status-and-membership.md)。
+- 选择阶段、正式成果、任务波次、交接或结项改进跟进：读 [项目生命周期](references/project-lifecycle.md)。
 - 成员：先读 [成员通用工作流](references/member-workflow.md)，再只读当前角色文件：
  - [业务](references/roles/business.md)
  - [产品](references/roles/product.md)
@@ -55,7 +55,8 @@ Etunel 负责当前角色和会话绑定。不要向负责人询问或复述 rol
  - [测试](references/roles/testing.md)
 - 准备派发、回复、跨角色中继、完成或报告阻塞：读 [Etunel 任务消息流程](references/etunel-message-lifecycle.md)。
 - 定义或校验成果、状态、版本、证据、额外产出或豁免：读 [成果与完成判定](references/artifacts-and-evidence.md)。
- 缺信息、错投、阻塞、会议决定、返工、变更、流程跳转或模拟：读 [异常与协调](references/exceptions-and-coordination.md)。
+- 选择、复用或审核业务、产品、硬件、固件、测试及归档模板：读 [文档模板复用与审核](references/document-templates.md)，再按实际任务定位原件；模板不自行改变职责、正式成果或门禁。
+- 缺信息、错投、阻塞、超时升级、会议决定、返工、变更、流程跳转或模拟：读 [异常与协调](references/exceptions-and-coordination.md)。
 - 编写给负责人、角色或群组的任务、提问、结果和状态消息：读 [人类可读沟通](references/human-readable-communication.md)。
 - 创建项目资料目录、保存成员清单、归档成果、更新进度或阶段记录：读 [项目文件与进度留档](references/project-files-and-progress.md)。
 - 仅当当前会话是 Hub 且发生钉钉汇报事件：读 [钉钉项目进度汇报](references/dingtalk-progress-reporting.md)。
@@ -23,6 +23,14 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 角色额外材料不能替代必需正式成果，也不能自动成为门禁。功能测试报告写测试结论（通过/不通过）、用例执行结果和 bug log；无法形成结论时说明阻塞，不伪造通过。缺陷由测试维护在《缺陷清单》中，责任人由实际相关负责人共同确认。

+## 测试选填材料的提交决定
+
+《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目负责人（项目Hub对应真人负责人）确认是否提交，Hub 登记决定和适用范围并同步测试、产品；已有仍有效的决定直接沿用，不为每个任务重复询问。未确认时只标明提交选择待确认，不由 AI 默认为必交或擅自批准不交，不新增阶段门禁或独立审批文件。
+
+决定不提交时，不因缺少这三类文件阻塞推进或要求另行豁免；决定提交时按约定交付并核对实际版本、负责人确认与接收状态，不把尚未提供写成已收。此规则只针对这三类测试成果，不扩大为所有选填栏目均须审批。
+
+平台模板中的“必填截图”“提交长稳报告”等文字，不自动升级为内部通用提交门禁；测试说明实际平台要求及影响，经 Hub 取得上述真人决定。决定是否提交材料不等于平台已接受、验收已通过，也不能免除已批准的必测范围或必要质量依据。正式测试结果仍走下文的项目负责人确认。
+
 ## 先定义产出要求

 正式执行任务的产出和完成条件只来自“本阶段必须完成”的内容。后续阶段处理和当前不需要的内容可以登记，但不能自动成为当前成果、任务完成条件或门禁。“本阶段完成约定”不能替代正式成果的适用性判断、受控跳转或《成果豁免申请》。派发时明确：
@@ -86,7 +94,7 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 测试专业结论、测试结果提交完成、正式验收准入是三个不同判断。测试负责人确认专业结果后，还必须由 Hub 请求项目负责人（项目 Hub 对应的真人负责人）实际确认；此人不是新增 Agent 角色，不能由 Hub AI、测试 AI 或通知状态代替。

 1. 测试执行完成，阻断缺陷清零、必需成果与测试依据齐全、剩余风险有接受方，并完成专业自审及测试负责人确认后，向 Hub 返回功能测试报告、缺陷清单及已提供的选填成果信息（F6.10），标记“待项目负责人确认”，不宣称正式提交完成。大文件保留可查索引，不因人工确认而增加整包上传要求。
-2. Hub 核对当前版本、必需成果、质量结论和剩余风险，再请求自己的真人负责人确认（F6.11）。记录真实的确认或退回意见（F6.12），包括确认人、时间、成果与被测版本、范围、附带条件和可查依据。
+2. Hub 核对当前版本、必需成果、质量结论和剩余风险，再请求自己的真人负责人确认（F6.11）。记录真实的确认或退回意见（F6.12），包括确认人、时间、成果与被测版本、范围、附带条件和可查依据，并向测试同步登记结果及后续动作。
 3. 明确确认且完成登记后，才算该版本测试结果提交完成；仍须满足测试质量门禁，才能进入正式平台/客户验收。人工确认不能将不通过改成通过，不能取消必测范围、缺陷复验或双线验收。
 4. 未回复、仅送达、已读、测试负责人单方确认、工具显示任务完成或协调消息结算，都不算此人工确认。Hub 保持“待项目负责人确认”，不伪造已批准；这不是 Etunel 的新机器枚举。
 5. 被退回时，测试补充材料，必要时回到相关修复、合版与独立复验，再重新提交确认。测试结果或被测版本实质变化必须重新经过 F6.10–F6.12；旧确认不能覆盖新版本。相同版本、范围与条件的有效确认可追踪复用，不为索引移动或排版重复审批。
@@ -106,7 +114,7 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 2. 项目负责人（项目Hub对应的真人负责人）依据申请、证据、替代方案和影响，明确批准或拒绝。所有成果豁免均须此人工决定，不能以低影响、沉默、形式校验或 AI 推断代替。
 3. Hub 登记决定人、时间、范围、基线、附加条件和失效条件；批准后分发豁免记录，拒绝或未获确认时仍需该成果。
 4. 不再设置独立的下游征询、意见回传或业务高影响确认环节；必要的事实和影响写在申请中，缺少时补正，不凭空补造意见。
-5. 决定只适用于当前项目、阶段和基线。不可豁免要求不能借本流程绕过；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足，不能替代测试结果的项目负责人确认。条件变化时重新评估。
+5. 决定只适用于当前项目、阶段和基线。不可豁免要求不能借本流程绕过；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足，不能替代测试结果的项目负责人确认。保留原必需项和豁免记录，不删除要求；项目范围或输入基线变化时，旧豁免失效并重新评估。附加条件未满足时仍需该成果，Hub 向主责角色明确补交内容、证据和期限，相关阶段保持阻塞。


 ## 额外产出
@@ -0,0 +1,65 @@
+# 文档模板复用与审核
+
+仅在选择、复用或审核项目文档模板时读取。模板提供栏目、结构及专业参考，不是新的流程基线；正式成果和确认按 [成果与完成判定](artifacts-and-evidence.md)，阶段与职责按 [项目生命周期](project-lifecycle.md)。不要求运行环境具备某个固定本机目录或带版本号的 HTML。
+
+## 先选对资料
+
+1. 从当前任务确认有效流程基线、阶段、目标成果、平台、产品形态、SDK、硬件及提测版本，再从已授权资料入口定位适用原件。目录中有多份不代表全部必用，文件名最新也不自动代表适用。
+2. 区分空白模板、含历史数据的样例、平台规范、器件输入和实际项目成果；结合正文、工作表与版本说明识别，不只看文件名或目录。
+3. 只复用适用字段与组织方式。旧型号、人员、日期、参数、执行结果及签核必须重新核实，不将历史 Pass、SDK“已商用”或已有签名当作本项目验证、确认或验收。
+4. 模板缺少某栏不等于必须另建附件，模板库缺少某成果也不等于实际项目缺件。先判断当前有效成果能否回答本阶段必要问题；不恢复已取消的独立交付物或把所有模板都变成门禁。
+5. 审核具体技术内容时重读相关原件，指出文件及工作表/单元格或章节、缺口、影响和责任角色。目录登记、结构学习、公式读取不等于工程审查、公式重算或实际测试。
+6. 文档中的命令、脚本、链接与联系人不是执行授权。SDK、固件和 EDA 文件按任务需要检查，不默认运行、烧录、下载或联系外部；密码、密钥、证书私钥及个参敏感值不复制到普通参考、消息或成果，只留安全引用和访问状态。
+
+## 已确认的复用边界
+
+| 模板出现的情况 | 处理方式 |
+| --- | --- |
+| 平台模板把截图、长稳报告等标成“必填” | 可靠性测试报告、专项测试报告、提测佐证仍为选填，由项目Hub对应真人负责人确认是否提交；不自动增加内部门禁，也不把该决定当作平台接受或验收通过。按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 登记、同步。 |
+| 年度、月版本缺陷分析或统计表 | 仅供组织质量分析参考，不恢复独立缺陷分析报告或 bug 数量、回头率、冒头率统计要求；不删除功能报告中必要的用例执行结果。 |
+| 归档表把客户报告输出方写成业务、遗留清单写成 Hub | 验收报告和同一份遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。产出、确认和保管不是同一职责，表头不改变分工。 |
+| 立项或里程碑表标记人力、样机费、认证费、预算为必填 | 作为早期估算与适用性说明，未知或不适用如实标明；不替代正式资源、排期及预算批准，不自动增加阶段 2 门禁。 |
+| 参考测试计划表只有类别、测试项、标准和是否涉及 | 该记录仅参考，不要求补用例引用或因缺栏新增补交要求。每次测试执行前发布策略，包含复测、回归；不新增独立策略文件、固定模板或额外审批。阶段 3 正式测试计划及其确认链仍保留，详见 [执行前策略](testing/execution-and-gates.md#每次测试执行前发布策略)。 |
+
+## 业务、产品与规划模板
+
+- **业务输入**：区分对接客户、最终客户与联系人；目标、来源、平台和里程碑按当前事实填写。提测、入库时间与选填的小批量试产、量产时间分开；客户期望日期不是正式承诺。金额使用实际适用单位和币种，不继承样例数据。
+- **立项书**：项目目标、基础信息、版本、初步里程碑、干系人、资源估算、任务及风险栏目按阶段使用；完整模板能容纳后续信息，不代表阶段 2 要一次完成全部规划和批准。
+- **规格与功能清单**：区分参数、描述及适用型号；“支持”“不支持”“预留”“待确认”不是同义词。SDK 支持、平台/客户端支持、设备实现状态、实际测试结果分别核对，不能以其中一列替代其他结论。
+- **灯态与语音**：按上电、配网、升级、断网等实际设备状态检查指示灯及语音。灯态采用“配网”不意味着将账号绑定、解绑等业务功能全局改名；样表某列选填不自动改变整个成果属性，未出现语音栏也不表示项目无需澄清适用语音行为。
+- **产测功能**：参考分类、功能描述、测试内容、实现/支持状态及备注，区分设备、产测工具、客户端和 MES 边界。行号或公式生成编号不能未经确认作为稳定用例标识。
+- **SDK 与个参**：核对来源、版本、适用产品及授权访问状态；容器存在不等于内容可用，样例参数不替代实际安全配置。
+- **风险与里程碑**：按正文识别文档用途；技术、时间及其他风险由产品维护、专业角色确认，不因模板放在规划目录就改变阶段 2 的风险归属。
+- **项目工时表**：工作项、人力、工时用于估算；先核对单位和适用范围。简单工时表不能单独证明正式排期、依赖、角色分工、产品资源确认或业务预算批准已经完成。
+
+## 硬件与固件模板
+
+- **硬件前置输入**：取得实际外设、关键器件的适用规格书及结构板框图，确认主要器件位置和禁止限制区域。器件简版说明、PCB 布局或单个器件机械图不能直接代替完整适用规格或结构板框要求；不要求使用样例中的全部器件型号。
+- **硬件设计包**：按原理图、PCB 源文档、贴片资料、接口定义四类审核。贴片资料包含 PCBA_BOM、器件位置图 PDF、贴片坐标；核对 BOM 数量/位号/封装、坐标的层/方向/位置及接口引脚功能，并检查是否对应同一设计版本。不另设《硬件实现资料》输出。
+- **底层成果**：静态电气测试表可提供硬件功能测试依据，但不自动覆盖完整《硬件功能测试报告》、BSP 输出路径和 PSP 输出路径。WiFi 定频固件选填且为专项工具，不当作统一提测固件。
+- **应用固件包**：升级自测所需高低版本可以并存；明确用途及唯一最终目标版本，不能仅因两个版本文件就判为多出口，也不能把历史低版本误交为最终固件。
+- **配套与校验**：分区文件、烧写镜像、构建配置按真实用途对应，不能凭扩展名猜测。MD5 文件存在不等于完成校验，旧自测结果不等于本次通过。样例缺少 zn_debug 文件、证书或其他约定项，不自动删除流程要求；发现异常公式、断链或版本不明时只核验受影响内容，不猜测修复值。
+
+## 测试模板选择与结果复用
+
+按实际平台及当前要求选择用例家族，不把下面示例当成永久平台标准或通用必测组合：
+
+| 家族 | 选择与核对重点 |
+| --- | --- |
+| 杭研类平台用例 | 提测时间对应的有效版本；Android/Harmony、IPv6、H264/H265 等适用列分别判断。 |
+| 电信类平台用例 | SDK、室内/室外、云台/非云台、双摄等产品差异；不只按文件体积或日期选择。 |
+| 联通类平台用例 | 平台、安全、码率等实际范围；内部版本是否包含指定客户用例应按项目选择。 |
+| 内部功能用例 | 含或不含特定客户需求的版本按来源选择，不无差别合并重复库。 |
+| 可靠性、专项与兼容性 | 温度、跌落、防护、功耗、WiFi/路由器及 SD 卡等按适用范围选择；样例阈值、数量、周期不自动成为新项目要求。 |
+
+实际使用时核对用例标识与来源、模块、前置条件、步骤、期望、实际结果、执行人、日期及缺陷关联；这是理解和记录当前测试所需的信息，不要求每张参考表增加同名列或单独引用附件。旧结果必须重新执行验证，未执行、阻塞、不适用和不通过不得混淆。
+
+发现标准页、温升指导或其他引用不存在、名称不一致时，先确认有效技术依据，不自行补造阈值。平台材料是否提交遵循前述真人决定；已批准的测试范围及独立质量结论仍按 [测试执行与质量门禁](testing/execution-and-gates.md) 处理。
+
+## 归档复用
+
+归档清单可参考阶段、文档名称/编号、输出方、归档状态和备注等栏目。统一使用当前有效成果名称和实际责任，旧编号重复、历史变更记录或旧版成果名称不能直接作为新项目事实。
+
+Hub 汇总有效版本、确认与可访问索引，不把归档清单中的每一行都变成强制补交任务；三类选填测试材料沿用真人提交决定。测试大文件按真人直交和产品收讫规则处理。原件未在模板库出现，不代表实际成果免交；模板库尚无独立阶段 7 或底层模板，也不表示实际项目缺件或不通过。
+
+阶段 8 只归档、复盘和结项，不因为模板包含自测、统计或验证栏目重新执行测试。具体留档和交接见 [项目文件与进度留档](project-files-and-progress.md)。
@@ -1,6 +1,6 @@
 # 异常与协调

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

 ## 缺失信息

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

 ## 复杂线下会议与会议决定记录

-普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞时：
+普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞，或在约定时限内无法通过异步消息收敛时：

-1. Hub 准备问题包和结论结构，不主持专业裁决；
+1. Hub 准备建议参会角色、会议目的、议题、冲突点及证据、待决策项、结论结构和完成时限，不主持专业裁决；
 2. 当前主责角色的负责人组织线下会议；
 3. 参与者把各自专业结论带回对应角色会话，完成负责人确认；
 4. 当前主责角色汇总一份《会议决定记录》，包括参与角色、问题、证据、各专业确认、统一结论、适用范围、版本、不同意见、风险、行动项、责任人和期限；
@@ -67,7 +67,18 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞
 6. Hub 只校验来源、确认、版本、证据、冲突和可执行性，登记并留档后从原阻塞点恢复；
 7. 结论改变正式基线时转入《变更申请》。

-会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认时仍保持阻塞。
+会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认或关键分歧仍未解决时，保持原流程阻塞并明确升级项。登记结论后，Hub 向原流程及关联角色说明恢复点、后续动作和新时限，不以会议记录替代正式成果。
+
+## 超时提醒与升级
+
+确认或任务超过约定时间时（X.6），Hub 发起升级通知，而不只是更新状态：
+
+1. 核对原约定及当前事实，列明逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。
+2. 专业事项定向交对应角色；项目级组织授权事项交业务。接收角色与本角色真人负责人内部确认后，统一向 Hub 回复决定、条件及处理安排。
+3. 测试结果或成果豁免仍由 Hub 对应真人项目负责人作原定决定，不能因超时改由业务或 AI 代批；授权内资源与排期仍交产品确认。
+4. Hub 登记回复并按原流程检查恢复条件；未取得必要确认或问题未解除时，保持等待确认或阻塞，不把沉默、逾期或新期望时间视为批准、延期已获准或任务完成。不受影响的任务继续。
+
+时限沿用已确认计划或请求，不自行规定固定催办频率、启动定时器或重造运行时提醒机制。没有约定时间时先澄清，不能凭空认定逾期。

 ## 缺陷与返工

@@ -75,8 +86,8 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞
 2. 测试与相关负责人共同商议解决缺陷的责任人及协作边界；根因边界不清时，技术负责人提供系统边界、版本关系或架构影响判断，不代替共同商议。Hub 不自行归因或指定责任人。
 3. 责任角色先向 Hub 返回原因与修复计划（F6.4）；Hub 登记共同确认的责任人和唯一主责角色，向责任角色派发修复任务，并把确认结果同步给测试维护缺陷清单（F6.5）。相关缺陷可组成修复包，独立角色可形成修复波次。
 4. 实现角色按派发任务提交修复成果和版本、角色自测、影响与必要变更说明，不替测试提交或维护清单。
-5. 底层修复先交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。
-6. 技术负责人确认新版本组合后，Hub 以统一固件、版本矩阵、缺陷清单及必要变更说明派发回归；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验。
+5. 底层修复先经 Hub 交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。即使不修改固件，应用层也须确认旧固件对新硬件仍有效，并更新匹配记录。
+6. 回归版本通过 Hub 校验，必要时由技术负责人确认版本矩阵后，Hub 以统一固件、版本矩阵、缺陷清单及必要变更说明派发回归；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验。此处技术确认按需触发，不增加每轮必审；阶段 5 最终提测版及阶段 6 初始准入仍须技术负责人确认。
 7. 只有测试可以确认缺陷已经复验或关闭；实现角色和 Hub 无权替换或关闭测试记录。

 测试已完成且无缺陷时仍提交功能测试报告和零缺陷清单，直接进入最终结果人工确认，不安排空修复任务。退回或修复形成新结果后按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 重新确认，才能检查正式验收准入。
@@ -91,10 +102,10 @@ Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞
 2. 产品、技术负责人、实际受影响实现或自定义角色和测试分别评估；
 3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
 4. 授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时再由业务批准、拒绝或延期，其他专业决定仍由有权角色确认；
-5. 批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；
-6. 未批准不得边评估边实施，也不得用状态纠正规避变更。
+5. 取得适用权限的确认或批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；拒绝或延期则维持原基线；
+6. 未取得必要确认或批准不得边评估边实施，也不得用状态纠正规避变更。

-只联系真正受影响角色，不固定全角色参与。变更决定、受影响文件和新旧版本按阶段留档。
+只联系真正受影响角色，不固定全角色参与。变更决定记录授权依据、有权角色及负责人、决定时间；受影响文件、新旧版本与项目状态同步更新并按阶段留档。

 ## 成果豁免

@@ -77,6 +77,7 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认

 - 允许同一角色排队和不同角色独立推进；
 - 不为普通进度反复追问，不发送空确认；
+- 确认或任务超过约定时间时按 [超时提醒与升级](exceptions-and-coordination.md#超时提醒与升级) 定向处理；不因逾期默认批准，也不把项目负责人必需确认改交其他角色；
 - 一个任务阻塞不自动取消同波次中不受影响的任务；
 - 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
 - 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。
@@ -115,7 +116,7 @@ Hub 检查：

 ## 项目状态与同步

-Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时，每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》，不广播完整计划。规则见 [角色与项目状态](project-status-and-membership.md)。
+Hub 从项目创建起维护项目状态。关键变化主动同步，角色查询按范围回复；纠正请求先检查证据、版本及一致性，通过后保留历史并向受影响角色重新分发。每个处理轮合并相关快照，不广播完整计划；角色可随任务答复确认或提出有依据的纠正，不制造空任务。规则见 [角色与项目状态](project-status-and-membership.md)。

 ## 测试最终提交与验收入口

@@ -127,6 +128,7 @@ Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、

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

+- 可靠性测试报告、专项测试报告、提测佐证是否提交，按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 取得并登记决定；不将此权限扩大到所有选填栏目，也不把模板“必填”直接当成门禁；
 - 测试最终结果的明确确认或退回；记录对应成果与被测版本，不以测试负责人确认或消息状态代替；
 - 真实节点跳转、暂缓、回退、流程迁移或带风险绕过；
 - 所有成果豁免的批准或拒绝：项目负责人即 Hub 对应的真人负责人，Hub AI 只校验和登记，不自行决定；不再单设下游征询及业务确认流程；
@@ -146,9 +148,9 @@ Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下
 - 阶段 4 Hub 拆分任务并整理工时评估、实际排期；技术负责人确认技术结构，只对问题任务定向询问，产品确认授权范围内的资源与排期。本阶段成果仅项目计划、角色分工、项目状态内部记录；引用阶段 2 项目风险，不另要求产品资料整合。
 - 阶段 5 硬件取得器件规格书和结构板框图后提交四类硬件设计资料；不另设《硬件实现资料》。底层提交硬件功能测试报告、BSP/PSP 输出路径，WiFi 定频固件选填；统一固件只由应用层输出。
 - 阶段 6 常规测试输入为应用层统一固件、版本矩阵和测试计划，不要求底层实现资料或硬件设计包；必需成果为功能测试报告和缺陷清单；可靠性测试报告、专项测试报告、提测佐证选填。相关负责人共同商议缺陷责任人后，Hub 登记并派发；底层修复须经应用层重新合版后复验。
- 阶段 7 按平台、客户两部分验收，可按条件并行；平台由产品出具报告或结论，客户验收由业务确认，两部分均通过才放行。测试资料按直交与收讫规则处理。
+- 阶段 7 按平台、客户两部分验收，可按条件并行；平台由产品出具报告或结论，客户验收由业务确认，两部分均通过才放行。验收报告与同一份遗留问题清单由产品出具或更新，业务确认客户部分，Hub 汇总登记。测试资料按直交与收讫规则处理。
 - 变更、异常或缺陷只向实际受影响角色派发，不固定全角色参与。
- 阶段 8 收集已有资料、复盘和结项，不新增冒烟或其他测试；只要求实际参与、有正式成果或遗留责任的角色提交结项输入。
+- 阶段 8 收集已有资料、复盘和结项，不新增冒烟或其他测试；只要求实际参与、有正式成果或遗留责任的角色提交结项输入。改进项写明责任人和跟进安排；业务确认结项后锁定四类成果，按安排跟进遗留与改进项，不把后续措施写成已经实施。
 - 正式项目满足全部必需成果、确认、双重验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。

 ## 钉钉进度
@@ -51,6 +51,10 @@

 只有缺失内容直接导致本次成果无法形成、完成条件无法判断、本角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才报告当前阻塞。仅供后续阶段使用的资料作为后续依赖返回，不阻塞本任务。

+## 状态与超时答复
+
+收到状态快照时，确认本角色可继续执行，或携带正确值、原因、证据及负责人确认向 Hub 请求纠正；上下文过期或不足时按 [角色与项目状态](project-status-and-membership.md#项目状态快照) 查询。收到超时升级时，先与本角色负责人确认原因、影响和处理安排再统一回复 Hub；新期望时间不自动变成已批准排期，等待或逾期不等于完成。
+
 ## 专业自审与负责人确认

 正式结果至少让 Hub 找到：
@@ -83,6 +87,10 @@
 4. 等待 Hub 重新路由或完成交接，不替另一角色补写专业结论；
 5. 新负责人不自动继承旧负责人的批准，需要重新确认仍适用的成果。

+## 复盘与后续承接
+
+收到结项资料或复盘任务时，只提供本角色实际参与的已有成果、有效版本和事实依据，不重做同内容文件。复盘结论及改进项经本角色负责人确认后交 Hub，写明问题原因、措施、责任人和跟进安排，汇入《流程闭环总结》。项目关闭后按已确认安排承接遗留与改进项，不把计划措施记为已经完成；不因此新增测试或发布验证任务。完整结项条件见 [项目生命周期](project-lifecycle.md#阶段-8资料归档与复盘结项)。
+
 ## 成员禁止事项

 - 不自行切换角色或任务主责；
@@ -4,7 +4,7 @@ Hub 创建项目资料目录、保存角色文件、维护成员清单、更新

 ## 责任边界

- 各角色负责形成、检查并提交自己的专业成果文件。
+- 各角色负责形成、检查并提交自己的专业成果文件。验收报告与同一份《遗留问题清单》由产品出具或更新，业务确认客户验收部分，Hub 汇总登记；归档模板的“输出方”“保管方”不重分配这些职责，模板中有一行也不自动把选填资料变成必交。
 - Hub 负责接收后校验、按阶段归档、维护成果索引和项目进度，不改写角色专业内容。
 - 必要成果文件未在适用位置保存、不可访问或无法确认版本时，不宣布正式阶段交接完成；阶段 7 直交资料以产品收讫、可访问确认及 Hub 索引为准。
 - 目录整理不是新的专业评审。模拟、受控跳转、回退或暂缓可以继续，但必须先记录缺失项、原因、风险和恢复条件。
@@ -70,6 +70,8 @@ Hub 在项目开始时建立：
 - `成果索引.md` 至少写明中文成果名、阶段、主责角色、文件位置、版本、确认状态、当前适用性和被替代关系。
 - 每项成果只标记一个当前有效版本。下游默认只接收该版本；旧版和过程材料继续留存，但不参与当前完成判断，除非被明确恢复为有效版本。

+三类选填测试材料的提交选择按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 由 Hub 登记真人决定、适用范围及交付状态，复用阶段记录或成果索引，不新增审批文件。每次执行前发布的测试策略保留必要过程记录，不升级为独立正式成果。
+
 ## 测试最终提交的确认留档

 按 [测试结果的项目负责人确认](artifacts-and-evidence.md#测试结果的项目负责人确认)，在阶段记录和成果索引中区分“测试执行完成”“待项目负责人确认”“确认完成/退回”，记录当前报告、缺陷清单及被测版本、真人决定、时间、范围和依据。这些是可读业务记录，不新增 Etunel 枚举。未确认不能登记为最终提交完成或正式验收准入；新结果或版本需重新确认，历史确认保留。
@@ -110,6 +112,10 @@ Etunel 的排队、送达、普通回复和空确认本身不触发留档。
 5. 暂缓写明恢复条件和下一责任角色；
 6. 模拟跳转明确标注“流程模拟”，不得混入正式成果。

+## 结项归档与后续跟进
+
+Hub 按 [阶段 8](project-lifecycle.md#阶段-8资料归档与复盘结项) 汇总四类结项成果，将各角色已确认的复盘结论、改进项责任人与跟进安排写入《流程闭环总结》，遗留承接写入结项记录。业务明确确认结项后锁定《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，保留有效版本、确认人和时间。待补充的必需项未完成不关闭；关闭后按安排跟进，不覆盖已锁定成果，也不把待实施措施写为已完成。
+
 ## 与钉钉的顺序

 Hub 先完成成果校验、文件归档、成果索引和项目进度更新，再根据已留档事实发送钉钉进度。钉钉发送失败不回滚留档，也不阻塞 Etunel 主流程。
@@ -33,7 +33,7 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成
 2. 产品明确专业评审角色、问题、范围和期望输出。测试检查产品结果是否可判断；技术负责人组织可行性评估，应用层、底层与硬件按实际影响评估专业约束。
 3. Hub 定向分发同版本资料；各角色返回本领域结论、缺口和风险，不代产品改需求。
 4. 产品汇总专业角色意见，维护《项目风险》（技术风险、时间风险、其他风险），并处理反馈、确认产品基线；业务批准客户范围与验收边界。结构板框图在本阶段选填；后续硬件任务需使用时再补齐，不提前阻塞产品定义。
-5. 测试验收标准包含平台测试用例、客户验收测试用例和验收标准。里程碑要求包含提测、客户验收时间，试产与量产时间为选填。
+5. 测试验收标准包含平台测试用例、客户验收测试用例和验收标准。里程碑要求包含提测、客户验收时间，试产与量产时间为选填。模板中的人力和费用等仅作早期估算与适用性说明，不替代正式资源、排期及预算批准，不自动新增阶段 2 门禁。

 门禁：产品确认方案、业务批准范围，直接影响产品定义的约束和可判断的验收标准完整；仅属于后续阶段的依赖如实登记。

@@ -75,13 +75,13 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成

 ## 阶段 6：测试验证

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

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

-总门禁是平台验收通过 + 客户验收通过，两项缺一不可。不能用平台通过、内部测试通过、资料已收或单方确认替代双线通过；问题与风险有明确承接。
+总门禁是平台验收通过 + 客户验收通过，两项缺一不可，且对应一致的验收对象与有效版本。返工后回到受影响的验收分支，版本变化影响另一分支时，该分支也须更新确认。不能用平台通过、内部测试通过、资料已收或单方确认替代双线通过；问题与风险有明确承接。

 ## 阶段 8：资料归档与复盘结项

 1. Hub 向实际参与角色收集各阶段有效成果、必要过程记录、变更、项目进度、成果索引及确认。沿用已验收版本，不重复制作同内容资料。
 2. 核对产品确认的平台结果、业务确认的客户结果及遗留问题；不重新给平台结果增加业务批准。
-3. 各角色提交基于事实的复盘输入：目标完成、计划偏差、协作与质量问题、经验和改进建议。Hub 汇入《流程闭环总结》。
-4. Hub 形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，业务确认结项。
+3. 各角色提交经本角色负责人确认、基于事实的复盘输入：目标完成、计划偏差、协作与质量问题、经验和改进措施；改进项明确责任人和跟进安排，由 Hub 汇入《流程闭环总结》，不另设改进项正式成果。
+4. Hub 形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，业务依据归档完整性、复盘与遗留承接确认结项或返回补充清单，记录负责人确认与时间。待补充的结项必需项未完成时不关闭；确认后锁定四类结项成果，关闭项目并按安排跟进遗留与改进项。结项不代表所有后续改进已经实施。
 5. 本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题时回到相应阶段处理，不能冒充已完成。

 门禁：双线验收通过，资料可追踪且归档完整，复盘完成，遗留问题已关闭或落实承接。大文件保留索引与产品接收确认，无需 Hub 重复收存；模拟项目只能记录模拟完成。
@@ -14,7 +14,7 @@ Hub 创建项目、读取实际角色、添加自定义角色、处理角色变
 - Etunel 路由用 `role`、人类可读 `display_name` 和允许的完成工具；
 - 加入、退出、替换、交接和未完成事项承接规则。

-由 Hub 负责人或项目发起人提出，受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线，先走《变更申请》并取得业务批准。
+由 Hub 负责人或项目发起人提出，受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线，先走 [变更申请](exceptions-and-coordination.md#变更申请)，按既定权限取得确认或批准，不一律追加业务审批：授权内资源与排期由产品确认，预算、采购、对外承诺及项目级组织授权由业务批准，专业决定仍由相应角色确认。

 职责契约确认后，必须由 Hub 真人负责人在 Etunel 中手动添加并完成绑定。Hub AI 可以准备契约、检查信息并调用当前允许的 Hub 工具，但不得宣称未执行的添加已经完成，也不向不存在的角色派发任务。

@@ -66,7 +66,9 @@ Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记

 ## 项目状态快照

-阶段、门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的变化时，Hub 向实际受影响角色发送裁剪后的《项目状态快照》：
+角色现有上下文不足或可能过期时，可向 Hub 查询授权范围内的状态（S.1），说明关注阶段或任务、查询范围、所需详细度、期望时点和用途；无需知道内部存储结构。
+
+收到查询，或阶段、门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的变化时（S.2），Hub 向请求角色及实际受影响角色发送裁剪后的《项目状态快照》：

 - 每个处理轮或波次合并一次，不为细小字段变化刷屏；
 - 只包含接收方需要采取行动或判断依赖的内容；
@@ -74,8 +76,10 @@ Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记
 - 不广播完整计划、无关角色状态、私有对话或空确认；
 - 快照是同步视图，不替代任务、成果、负责人批准或门禁。

+快照注明证据来源、版本与时点，不转发未确认专业判断。接收角色向 Hub 确认可继续执行，或提出需纠正的内容、正确值、原因、证据及本角色负责人确认（S.3）；可随相关任务答复合并回传，不为收讫另建空任务。
+
 ## 状态纠正与基线变更

-发现过程状态登记错误时，保留旧值、新值、原因、证据、纠正人和生效时间。单纯纠正事实可以更新记录；若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁，必须转入《变更申请》，不能用“状态纠正”规避变更。
+发现过程状态登记错误时，Hub 先检查版本、证据和跨角色一致性；无证据的异议不能直接覆盖状态，有争议按 [异常与协调](exceptions-and-coordination.md) 处理。核对通过后（S.4）保留旧值、新值、原因、证据、纠正人、生效时间及受影响任务，更新内部记录并向全部受影响角色重新分发有效快照。单纯纠正事实可以更新记录；若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁，必须转入《变更申请》，不能用“状态纠正”规避变更。

 新项目默认使用当前流程基线。在途项目继续使用已登记基线；只有明确决定迁移时，才记录阶段和成果映射、缺失项、风险、必要确认及旧版替代关系。
@@ -53,4 +53,4 @@
 - 唯一构建、固件和配置版本；
 - 未执行项、依赖、接口约束、开放问题、风险和明确结论。

-发现底层、硬件、产品或总体架构问题时，把具体证据和所需输入返回 Hub，不直接联系对应角色 AI。底层修复须经本角色重新集成并输出新统一固件，才能进入技术版本确认和测试复验。
+发现底层、硬件、产品或总体架构问题时，把具体证据和所需输入返回 Hub，不直接联系对应角色 AI。底层修复须经本角色重新集成并输出新统一固件，交 Hub 校验、必要时由技术负责人确认版本矩阵，再交测试独立复验；不把回归技术确认设为每轮必审。硬件 ECO 即使不修改固件，本角色仍须确认旧固件在新硬件上的有效性并更新匹配记录。阶段 5 最终提测版本仍必须经过技术负责人确认。
@@ -67,6 +67,9 @@
 - 硬件相关缺陷分析、修复建议、影响范围和回归要求。

 测试输入不完整、样机/板卡版本不明或验收条件不可测时，报告具体缺口和影响，不以“静态检查通过”替代实际验证。
+
+阶段 6 硬件 ECO 经 Hub 协调底层兼容评估、应用层固件有效性确认与新版本矩阵；即使固件不变也不能省略对应确认。回归版本由 Hub 校验，技术负责人按需确认矩阵，不因本节设计期确认要求给每轮回归增加固定审批；阶段 5 设计包确认及正式基线变更的权限要求仍然适用。回归只交统一固件、版本矩阵、缺陷清单及必要变更说明，定位资料按问题提供，详见 [缺陷与返工](../exceptions-and-coordination.md#缺陷与返工)。
+
 ## 非主责边界

 硬件角色不：
@@ -55,7 +55,7 @@
 - 立项书：项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明；不另要求独立版本说明文件。
 - 规格书：产品硬件规格和主要元器件型号。
 - 功能清单：设备支持的功能项。
- 灯态：设备状态下的指示灯及语音播报内容。
+- 灯态：上电、配网、升级、网络断开等设备状态下的指示灯及语音播报内容；不因此改写实际业务的账号绑定或解绑含义。
 - 产测功能清单：产测工具支持项。
 - 平台 SDK、个参资料：保留来源、版本、适用范围及访问状态；涉及敏感值时使用安全引用，不复制到普通消息。
 - 结构板框图（选填）：主要器件位置及禁止限制区域。
@@ -63,6 +63,10 @@
 - 里程碑要求：提测时间、客户验收时间；试产与量产时间为选填。
 - 项目风险：在阶段 2 汇总技术风险、时间风险、其他风险；专业判断由对应角色确认，产品维护清单，Hub 登记并中继后续风险意见。

+立项或里程碑模板中的人力、样机费用、认证费用、预算及 WBS 只作为早期估算与适用性说明；尚未确定或不适用时如实标注。它们不提前替代正式资源、排期及预算批准，也不因表格标注“必填”或存在空白而自动增加阶段 2 门禁。后续正式资源与排期仍由产品在授权内确认，预算、采购及对外承诺由业务批准。
+
+复用字段、选择平台资料或审核历史样例时，按需读 [文档模板复用与审核](../document-templates.md)，不照搬旧型号、参数、结果或签核。
+
 ## 客户平台资料

 - 只有当前任务确实需要外部资料且联络边界已经批准时，产品真人负责人按批准边界联系客户；Agent 不越过 Hub 直接给其他角色或未绑定客户派任务。
@@ -104,7 +108,7 @@

 正式验收输入须已通过阶段 6 测试质量门禁，并由 Hub 取得其对应真人项目负责人对当前测试结果的明确确认；工具完成或测试负责人单方确认不能替代。测试负责人直接向产品负责人交付测试报告和已提供的提测佐证，产品向 Hub 确认收到的文件、版本和保存位置；Hub 不转发大文件。收到资料不表示验收通过，提测佐证未提供也不单独阻塞验收。

-平台验收由产品依据实际平台结果出具报告或结论，不需业务批准；客户验收由业务确认。两条线可并行，但必须分别留存结果，总条件为平台通过 + 客户通过。平台和客户问题进入同一份《遗留问题清单》，标明来源、版本、责任人、处理安排、状态和风险；F7.3、F7.5 分别更新，F7.10 汇总核对。返工产生新测试结果后须重新完成项目负责人确认；任何一条未通过都不宣布阶段 7 完成。
+平台验收由产品依据实际平台结果出具或更新报告或结论，不需业务批准；客户验收报告由产品出具或更新，客户验收部分由业务确认，Hub 汇总登记。两条线可并行，但必须分别留存结果，总条件为平台通过 + 客户通过。平台和客户问题进入同一份《遗留问题清单》，标明来源、版本、责任人、处理安排、状态和风险；产品在 F7.3、F7.5 分别更新平台和客户问题，Hub 在 F7.10 汇总核对产品更新的同一清单及双线确认，不替产品编写专业内容。返工产生新测试结果后须重新完成项目负责人确认；任何一条未通过都不宣布阶段 7 完成。

 ## 产品基线门槛

@@ -14,7 +14,7 @@
 - 阶段 3 测试计划：测试编制并提交测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先由 Hub 转交相关角色确认、测试修订，再汇总确认。
 - 阶段 4：确认任务技术结构、顺序、依赖、集成关系和关键风险；只标出有疑点的任务。产品确认资源与排期，技术负责人不代为批准预算、采购或对外承诺。
 - 阶段 5：确认硬件设计包的技术及接口关系，确认应用层统一固件、底层、硬件和配置的版本匹配与可提测结论。
- 阶段 6：提供跨层技术边界和原因判断依据；缺陷责任人由测试及相关负责人共同商议，Hub 按确认结果路由。
+- 阶段 6：提供跨层技术边界和原因判断依据，按需确认回归版本矩阵，不对每轮回归追加固定审批；初始提测仍须阶段 5 最终版本确认。缺陷责任人由测试及相关负责人共同商议，Hub 按确认结果路由。
 - 阶段 8：提交已确认技术资料、版本关系和复盘输入，不新增发布验证任务。

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

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

+参考测试计划表不要求补充用例引用，不因缺少独立用例范围栏新增补交门禁；阶段 3 正式《测试计划》及其确认链仍保留。每次测试执行前（含复测、回归）发布本次策略，不只在首版发布；使用现有任务或过程沟通，不新增独立正式策略文件、固定模板或额外审批，跨角色信息仍经 Hub 中继。
+
 测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。

 ## 阶段 2 可测试性检查
@@ -50,7 +52,7 @@

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

-测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色及协作关系，Hub 只登记确认结果和路由，不独自定责。清单保留 bug 条目、状态、模块和责任人，不附加缺陷汇总统计要求，也不新增独立分析报告。
+测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色及协作关系，Hub 只登记确认结果和路由，不独自定责。清单保留 bug 条目、状态、模块和责任人，不附加缺陷汇总统计要求，也不新增独立分析报告。年度、月版本缺陷统计模板仅作组织质量分析参考，不恢复 bug 数量、回头率、冒头率统计门禁。

 实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该清单。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。

@@ -71,7 +73,7 @@
 - 业务目标和客户验收边界；
 - 产品需求、异常行为和可测试验收标准；
 - 测试计划及实际测试所需的已确认标准；
- 应用层提交、技术负责人确认匹配关系的唯一统一固件；
+- 应用层提交的唯一统一固件；初始提测须技术负责人确认匹配关系，回归版本经 Hub 校验、必要时由技术负责人确认；
 - 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
 - 研发变更、自测、已知问题、升级／降级／恢复方式；
 - 环境、网络、工具、外设、账号和敏感配置安全引用；
@@ -90,6 +92,7 @@
 - 画质：[画质专项](../testing/image-quality.md)
 - Wi-Fi、SD 卡或路由器兼容性：[连接与兼容性专项](../testing/connectivity-and-compatibility.md)
 - 平台提测或试产候选定版：[平台提测与试产定版](../testing/platform-and-pilot.md)
+- 选择平台用例、复用报告或审核样例：[文档模板复用与审核](../document-templates.md)

 没有相关专项时不加载。阈值、样本、时长、距离、温度点和兼容设备数量来自当前已批准《测试计划》或上游标准，不固定写入角色契约。

@@ -106,7 +109,7 @@
 - 阶段 7：平台测试正式结果与客户验收通过报告所需测试证据；
 - 阶段 8：已有测试资料及流程闭环总结的复盘输入，不重做验证。

-功能测试报告包含测试结论（通过/不通过）、用例执行结果和 bug log；无法判定时说明阻塞。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项，不强制单列专项矩阵；提测佐证仅为平台要求的视频、截图、log 材料。三类选填成果未提供不阻塞推进，无需豁免；已批准的必测范围仍需执行，不把文件选填理解为可忽略质量依据。
+功能测试报告包含测试结论（通过/不通过）、用例执行结果和 bug log；无法判定时说明阻塞。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项，不强制单列专项矩阵；提测佐证仅为平台要求的视频、截图、log 材料。三类选填成果由项目Hub对应真人负责人确认是否提交，执行 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定)；不提交不自动阻塞推进，无需豁免，也不表示平台接受或验收通过。已批准的必测范围仍需执行，不把文件选填理解为可忽略质量依据。

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

@@ -1,6 +1,6 @@
 # 测试执行与质量门禁

-测试角色形成《测试计划》、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和响应时限由当前已批准《测试计划》定义。
+测试角色形成《测试计划》、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和响应时限依据当前已批准《测试计划》及上游标准，在每次执行前发布的测试策略中落实，不从历史模板直接继承。

 ## 三层测试契约

@@ -27,9 +27,17 @@

 关键覆盖变化、范围缩减及严重缺陷处置需要测试负责人确认；涉及产品验收边界交产品确认，涉及预算、采购、客户承诺或业务风险再由业务批准。

+## 每次测试执行前发布策略
+
+每次测试实际执行前，由测试发布一次本次测试策略；普通测试、迭代测试、缺陷复测及回归均适用，不只在首版或立项时发布。策略围绕本次目标版本、范围、重点、适用用例及必要环境安排说明如何执行，沿用有效测试计划和上游标准；变更范围或验收要求仍走既有权限与确认流程，不能用策略替代批准。
+
+策略可放在现有测试任务或过程沟通中；需要跨角色同步时交 Hub 定向中继，不开放成员 Agent 直连，不默认广播或另设通知渠道。保留实际发布内容与版本的必要过程记录，不新增独立正式成果、固定模板或每轮技术负责人审批。只编写草稿或阅读模板，不算已经发布。
+
+参考测试计划表仅供选项和标准组织参考，不要求补充用例引用，也不因缺少引用栏或独立用例范围栏新增补交要求。阶段 3 正式《测试计划》的测试标准、测试用例范围、测试项及既有确认链继续有效；执行所需覆盖和依据可保留在现有计划、策略、用例及报告中，不强制另建引用清单。
+
 ## 适用性

-《功能测试报告》《缺陷清单》必需；《可靠性测试报告》《专项测试报告》《提测佐证》选填，未提交不阻塞推进，无需豁免。已提交时完成版本登记和负责人确认。选填文件与已批准测试范围是两回事；测试依据可保留在实际报告及支持记录中，不要求另建通用证据包。
+《功能测试报告》《缺陷清单》必需；《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目Hub对应真人负责人确认是否提交，Hub 登记并同步；决定不提交不阻塞推进，无需豁免，已提交时完成版本登记和负责人确认。平台模板不自动增加内部提交门禁，真人决定也不等于外部平台已接受，见 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定)。选填文件与已批准测试范围是两回事；测试依据可保留在实际报告及支持记录中，不要求另建通用证据包。

 测试专项、模块和用例的计划适用性只使用：

@@ -47,7 +55,7 @@

 每个正式提测版本应提供：

- 应用层输出、技术负责人确认版本矩阵的唯一统一固件，以及匹配的底层、硬件、BOM、配置、样机和批次；
+- 应用层输出的唯一统一固件及匹配版本矩阵（底层、硬件、BOM、配置、样机和批次）；初始提测须技术负责人确认，回归按下述规则校验；
 - 可重复取得的安装包、固件、样机或构建物；
 - 变更清单、影响范围、研发自测、已知问题和风险；
 - 安装、升级、降级和恢复方式；
@@ -56,13 +64,13 @@

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

-回归任务（F6.9）使用统一固件、版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认要求整包。准入事实可复用已有有效记录，不要求每轮重复上传。
+回归任务（F6.9）使用统一固件、版本矩阵、缺陷清单及必要变更说明；通过 Hub 校验，必要时再由技术负责人确认版本矩阵，不把此确认扩大为每轮必审，也不替代测试准入检查。具体定位资料按问题提供，不默认要求整包。准入事实可复用已有有效记录，不要求每轮重复上传；阶段 5 最终提测及阶段 6 初始准入的技术负责人确认保持必需。

 ## 每版测试闭环

 每版按以下顺序在测试角色内部执行：

-提测准入检查 → 变更影响评估 → 本版策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总
+提测准入检查 → 变更影响评估 → 发布本次测试策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总

 按版本风险选择策略：

@@ -88,6 +96,8 @@

 ## 统计

+年度、月版本缺陷分析模板只作参考，不要求提交独立缺陷分析报告或 bug 数量、回头率、冒头率统计。下列用例执行统计用于解释实际覆盖，与已取消的缺陷汇总统计不是同一要求。
+
 正式报告至少统计计划、通过、不通过、阻塞、不适用、适用和实际执行数量：

 - 计划用例数 = 通过 + 不通过 + 阻塞 + 不适用；
@@ -20,7 +20,9 @@

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

-平台验收报告或结论由产品依据实际平台结果出具，无需业务批准；客户验收由业务确认。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
+平台验收报告或结论由产品依据实际平台结果出具或更新，无需业务批准；客户验收报告与共用遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
+
+平台用例或提交模板中的报告、视频、截图、log 要求先作为实际平台要求说明，不自动升级为内部通用必交项。《可靠性测试报告》《专项测试报告》《提测佐证》按 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定) 由项目Hub对应真人负责人确认是否提交；平台尚未接受、实际必测项未完成或正式结果未取得时仍如实说明，不把内部提交决定当成平台通过。

 ## 试产候选定版