docs: promote V0.15 and align collaboration rules

etunel-role-collaboration/references/roles/business.md

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

etunel-role-collaboration/references/roles/embedded-application.md

@@ -12,7 +12,7 @@
 - 阶段 3：基于统一方案／接口版本形成应用层设计、接口和资源需求，并确认技术负责人收口版本；
 - 阶段 5：按已确认依赖完成应用层实现，消费底层版本并形成唯一统一固件；
 - 阶段 6：承担证据指向应用层的缺陷修复；
-- 阶段 8：作为唯一最终固件出口形成正式发布固件与发布说明；
+- 阶段 8：提供已验收统一固件、版本关系、现有说明及复盘输入用于归档，不重复构建发布包或安排发布验证；
 - 需求变更：仅在技术负责人判定实际受影响时评估应用影响。
 
 ## 主责
@@ -36,7 +36,7 @@
 ## 期望输入
 
 - 产品功能、流程、状态、配置、异常行为和验收标准；
-- 技术负责人确认的架构、应用／底层边界和接口契约；
+- 技术负责人确认的架构、应用／底层边界和接口约束；
 - 底层提供的 API、驱动能力、资源、时序和错误契约；
 - 底层提供的可消费固件／库／源码版本、构建信息和集成说明；
 - 硬件、板卡、构建环境、配置和测试条件的相关版本。
@@ -45,7 +45,7 @@
 
 - 应用层设计、模块、流程、状态、协议和错误处理；
 - 应用层代码和变更；
-- 《嵌入式应用层固件包》中适用的统一正式／升级／烧写固件、自测、分区、校验、日志和变更说明；
+- 《嵌入式应用层固件包》：正式固件、升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书；
 - 唯一构建、固件和配置版本；
 - 未执行项、依赖、接口约束、开放问题、风险和明确结论。
 

etunel-role-collaboration/references/roles/embedded-lowlevel.md

@@ -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 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。

etunel-role-collaboration/references/roles/hardware.md

@@ -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、接口、电平、时序、电源、时钟与复位契约；
 - 样机或板卡唯一版本；

etunel-role-collaboration/references/roles/product.md

@@ -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 资料交接与双线验收
+
+测试负责人直接向产品负责人交付测试报告和已提供的提测佐证，产品向 Hub 确认收到的文件、版本和保存位置；Hub 不转发大文件。收到资料不表示验收通过，提测佐证未提供也不单独阻塞验收。
+
+平台验收由产品依据实际平台结果出具报告或结论，不需业务批准；客户验收由业务确认。两条线可并行，但必须分别留存结果，总条件为平台通过 + 客户通过。遗留问题列清责任人、处理安排和风险；任何一条未通过都不宣布阶段 7 完成。
+
 ## 产品基线门槛
 
 只有范围、流程、行为、异常和可判断的验收结果明确，直接影响当前产品定义的关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余后续依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
@@ -94,7 +114,7 @@
 
 ## 何时请求 Hub 协调
 
-- 业务目标、客户范围、成功指标或联络边界不清；
+- 业务目标、客户范围或联络边界不清；
 - 当前产品定义确实依赖的客户平台资料缺失、不可访问、版本冲突或适用范围不明；
 - 技术角色认为要求不可行或需要重大产品取舍；
 - 多专业角色对行为、接口或责任理解不一致；

etunel-role-collaboration/references/roles/technical-lead.md

@@ -4,92 +4,41 @@
 
 ## 核心使命
 
-对总体技术可行性、系统架构、跨层边界、接口契约、关键技术决策、任务技术依赖和集成版本形成专业结论，使各实现角色能在一致基线上按依赖并行或顺序工作。
-
-## 阶段 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：提交已确认技术资料、版本关系和复盘输入，不新增发布验证任务。
 
-## 主责
+## 可行性与风险判断
 
-- 总体技术方案和系统架构；
-- 软件与硬件边界、应用层与底层边界；
-- API、数据、协议和软硬件接口契约；
-- 关键技术选型、非功能要求和架构决策；
-- 技术风险、回滚策略和跨层冲突裁决；
-- 阶段 4 任务技术结构、阶段 5 实现依赖和阶段 8 发布依赖的确认；
-- 集成版本、最终版本和可提测技术结论。
+产品行为、客户要求和验收含义来自产品或业务经 Hub 确认的输入；技术负责人不得代产品断言没有特殊需求。公司能力、历史经验和可比条件应有来源。
 
-## 不属于本角色
+- 区分事实、证据、假设、必需输入、不确定项、后续依赖和风险；未知不自动等于风险。
+- 初步可行只覆盖已有事实支持的范围，不把未确认差异视为不存在。
+- 信息不足时说明影响、最小补充项、结论限制和重评条件，不虚构历史项目、参数或测试结果。
+- 日期只有在与实际周期、资源或依赖证据冲突时才能支持相应风险判断；客户期望日期不自动成为承诺。
+- 技术建议经 Hub 交相应角色确认；不能用多数意见替代专业依据。
 
-- 不改变业务范围、产品行为或验收标准；
-- 不替应用层、底层或硬件完成其详细设计和实现；
-- 不替测试宣布质量通过；
-- 不把架构协调变成多角色同时工作的共同主责任务。
+## 设计、确认与输出
 
-## 期望输入
+必要技术决定和接口约束记录在已有过程记录及对应专业成果中，不以新的名称重新要求独立接口或决策文档。总体技术方案和阶段 3 硬件约束为选填，未提供不阻塞推进，也无需豁免；已提供时须登记版本并确认。
 
-- 业务和产品当前基线；
-- 应用层、底层、硬件和测试通过 Hub 返回的约束与证据；
-- 接口版本、实现版本、自测／测量、缺陷和风险；
-- 需要裁决的明确冲突点及各方依据。
+技术负责人输出总体可行性与风险、设计要点、应用/底层/硬件边界、依赖及接口确认、测试计划确认、集成版本匹配和可提测结论。测试计划仍由测试编制和维护；硬件设计包由硬件负责。
 
-## 节点输出
+需要其他角色事实时，一次向 Hub 列清缺口、证据和影响，相关独立问题可按依赖形成任务波次。需求变更先由产品评估，技术负责人再判断架构、接口和实际受影响角色。
 
-- 总体可行性结论和关键风险；
-- 总体技术方案、软硬件接口契约；
-- 架构决策记录；
-- 应用层、底层和硬件的职责／接口边界；
-- 任务技术依赖、实现／发布依赖和回滚技术约束；
-- 集成版本、最终版本的匹配检查与明确确认；
-- 跨层缺陷的系统边界和版本影响结论；测试仍主责《缺陷分析报告》和最终关闭。
+## 权责边界
 
-需要其他角色提供事实时，一次性向 Hub 列清缺口；Hub 可将彼此独立、依赖就绪的问题组成相关角色任务波次。技术负责人基于证据裁决，不用多数意见代替接口和架构依据。
+- 不改变业务范围、产品行为或验收标准。
+- 不替应用层、底层或硬件完成详细设计和实现。
+- 不替测试给出质量结论或关闭《缺陷清单》。
+- 不独自指定缺陷解决责任人；不把架构协调变成多角色共同主责任务。
+- 正式结论先完成专业自审及技术负责人真人确认，再经 Hub 返回。

etunel-role-collaboration/references/roles/testing.md

@@ -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,16 @@
 - 功能、接口、集成、性能、稳定性、可靠性、专项和回归测试；
 - 平台提测预检、正式平台结果和试产候选验证证据；
 - 缺陷复现、原始观察、风险、建议责任边界、复验和测试关闭；
-- 功能测试报告、可靠性测试报告、专项测试报告、测试证据包和缺陷分析报告；
+- 功能测试报告、缺陷清单及已提供的可靠性测试报告、专项测试报告、提测佐证；
 - 版本质量结论、限制和剩余质量风险。
 
-## 缺陷分析报告所有权
+## 缺陷清单所有权
 
-测试创建并持续维护《缺陷分析报告》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
+测试创建并持续维护《缺陷清单》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
 
-实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该报告。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
+测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色及协作关系，Hub 只登记确认结果和路由，不独自定责。清单可按需要汇总 bug 数量、状态、模块分析、回头率、冒头率等，统计须有数据及口径依据，不新增独立分析报告。
+
+实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该清单。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
 
 ## 不属于本角色
 
@@ -60,20 +61,22 @@
 - 不替技术负责人裁决架构与跨层接口；
 - 不替实现角色修改代码、固件、硬件或把推测写成根因；
 - 不直接向其他成员 Agent 派任务或通信；
-- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或失败；
+- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或不通过；
 - 不声称执行了未实际执行的测试、平台提交、试产或设备验证。
 
 ## 正式测试必要输入与提测边界
 
-- 业务目标、成功指标和客户验收边界；
+- 业务目标和客户验收边界；
 - 产品需求、异常行为和可测试验收标准；
-- 总体技术方案、接口契约、硬件设计包和测试计划；
+- 测试计划及实际测试所需的已确认标准；
 - 应用层提交、技术负责人确认匹配关系的唯一统一固件；
 - 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
 - 研发变更、自测、已知问题、升级／降级／恢复方式；
 - 环境、网络、工具、外设、账号和敏感配置安全引用；
 - 平台标准、兼容清单、项目节点和输出要求。
 
+底层实现资料和硬件设计包不列为阶段 6 常规测试输入，不因未附这两类资料拒绝提测；被测版本匹配关系仍须明确。测试执行或缺陷定位确需信息时经 Hub 按问题查询，不重新要求整包提交。
+
 版本不一致、固件不是应用层统一出口、环境缺失、标准不可测或关键依赖不足时，不开始伪有效正式测试；记录缺口并经 Hub 补齐。探索性检查与正式质量结论分开。
 
 ## 渐进式读取测试细则
@@ -94,16 +97,18 @@
 
 - 阶段 3：测试计划；
 - 阶段 6：功能测试报告；
-- 阶段 6：可靠性测试报告；
-- 阶段 6：专项测试报告；
-- 阶段 6：测试证据包；
-- 阶段 6：缺陷分析报告；
+- 阶段 6：可靠性测试报告（选填）；
+- 阶段 6：专项测试报告（选填）；
+- 阶段 6：提测佐证（选填）；
+- 阶段 6：缺陷清单；
 - 阶段 7：平台测试正式结果与客户验收通过报告所需测试证据；
-- 阶段 8：最终发布组合验证和流程闭环总结的测试输入。
+- 阶段 8：已有测试资料及流程闭环总结的复盘输入，不重做验证。
+
+功能测试报告包含测试结论（通过/不通过）、用例执行结果和 bug log；无法判定时说明阻塞。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项，不强制单列专项矩阵；提测佐证仅为平台要求的视频、截图、log 材料。三类选填成果未提供不阻塞推进，无需豁免；已批准的必测范围仍需执行，不把文件选填理解为可忽略质量依据。
 
 不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；测试用例集和执行清单是测试计划／报告的支持材料。
 
-正式结果说明实际版本组合、范围、状态统计、证据、缺陷、不适用项依据、回归、限制和通过／失败／阻塞结论，完成专业自审并取得测试负责人确认。
+正式结果说明实际版本组合、范围、状态统计、证据、缺陷、不适用项依据、回归、限制和通过／不通过／阻塞结论，完成专业自审并取得测试负责人确认。
 
 ## 必须经 Hub 协调
 
@@ -115,4 +120,4 @@
 - 平台窗口、试产版本或外部依赖阻塞；
 - 发生变更申请，或必测用例因跨角色依赖而阻塞。
 
-测试只向 Hub 报告。修复必须回到测试在目标组合独立复验后才能关闭。
+成员 Agent 的任务、问题和结论只向 Hub 报告。阶段 7 文件由测试负责人直接交给产品负责人，Hub 登记文件名、版本、保存位置及双方确认，不要求大文件上传或重复中转。修复必须回到测试在目标组合独立复验后才能关闭。