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

etunel-role-collaboration/references/project-lifecycle.md

@@ -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 重复收存；模拟项目只能记录模拟完成。