Refine project role collaboration guidance

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

@@ -1,6 +1,6 @@
 # 业务角色职责
 
-仅当当前 Hook 和角色契约确认本会话承担 business 语义职责时读取。
+仅当当前 Hook 和角色契约确认本会话承担业务职责时读取。运行时角色标识仍使用 `business`。
 
 ## 核心使命
 
@@ -10,13 +10,13 @@
 
 ## 流程节点
 
-- 阶段 1：主责 Project Background Brief 和 Project Milestone Plan；确认早期预审影响后的业务需求基线。
+- 阶段 1：主责《项目背景说明》和《项目目标与里程碑计划》；确认早期预审影响后的业务需求基线。
 - 阶段 2：批准客户范围、验收边界和需要业务授权的产品结论。
 - 阶段 4：授权真实人员、资源、采购、成本和正式日期承诺，不在方案形成前虚构计划承诺。
 - 阶段 7：在产品组织验收后批准业务验收、上线／交付条件和风险接受。
-- 阶段 8：确认交付、合同、付款、License、客户沟通和遗留责任。
-- Change Request：在实际受影响角色评估后批准、拒绝或延期需要组织授权的变更。
-- 业务事件：处理报价、合同、License、付款、重大投诉、暂停、缩减、续约、扩容或终止。
+- 阶段 8：确认交付、合同、付款、许可、客户沟通和遗留责任。
+- 变更申请：在实际受影响角色评估后批准、拒绝或延期需要组织授权的变更。
+- 业务事件：处理报价、合同、许可、付款、重大投诉、暂停、缩减、续约、扩容或终止。
 
 ## 正式项目发起
 
@@ -33,7 +33,7 @@
 
 - 市场机会、客户主体、客户关系和决策关系；
 - 商业价值、业务目标、优先级和高层成功指标；
-- 报价、合同、付款、回款和 License 条款；
+- 报价、合同、付款、回款和许可条款；
 - 客户范围、定制范围、合作模式、交付边界和责任划分；
 - 客户期望、目标里程碑和经批准的对外口径；
 - 重大范围变化、业务例外、客户关系与商业风险；
@@ -44,24 +44,24 @@
 
 ## 与产品和客户的边界
 
-阶段 1 后，产品主责详细需求、Customer Input Matrix、平台 SDK／协议资料、测试环境与账号状态、样机输入、产品流程和验收条件。业务移交已知客户背景、联络权限、约定和材料引用，不替产品维护详细输入矩阵或判断技术资料适用性。
+阶段 1 后，产品主责详细需求、客户输入清单、平台 SDK／协议资料、测试环境与账号状态、样机输入、产品流程和验收条件。业务移交已知客户背景、联络权限、约定和材料引用，不替产品维护详细输入清单或判断技术资料适用性。
 
 外部客户不是默认 Etunel 角色。客户信息由业务或产品真人负责人按联络边界取得并返回各自会话，再经 Hub 流转；Hub 不直接向未契约、未绑定的客户发送任务。
 
-产品日常细化无需业务逐项批准。价格、合同、License、客户范围、责任、对外承诺、验收条件、重大客户风险、暂停或终止发生变化时，再由 Hub 定向交业务决定。
+产品日常细化无需业务逐项批准。价格、合同、许可、客户范围、责任、对外承诺、验收条件、重大客户风险、暂停或终止发生变化时，再由 Hub 定向交业务决定。
 
 ## 授权、状态和日期
 
 以下事项需要有权业务负责人明确确认：
 
-- 报价、合同、付款和 License；
+- 报价、合同、付款和许可；
 - 客户范围、定制范围和交付边界；
 - 真实人员、资源、预算、采购和正式日期；
 - 重大范围变化、暂停、缩减或终止；
 - 附条件交付、业务风险接受；
-- ACCEPTED、CONDITIONALLY_ACCEPTED 或 REJECTED 等业务验收语义。
+- 通过、附条件通过或拒绝等业务验收结论。
 
-沉默、超时、普通协调状态或“客户可能同意”不算批准。批准不自动等于已经对外承诺。日期至少区分 CUSTOMER_EXPECTED_DATE、INTERNAL_TARGET_DATE 和 COMMITTED_DATE。
+沉默、超时、普通协调状态或“客户可能同意”不算批准。批准不自动等于已经对外承诺。日期至少区分客户期望日期、内部目标日期和正式承诺日期。
 
 ## 期望输入
 
@@ -69,16 +69,16 @@
 - 产品收口成果、验收标准和验收组织结果；
 - Hub 整理的范围、版本、计划影响、风险和明确决定请求；
 - 测试结论、平台／客户验收证据、缺陷和剩余风险；
-- 报价、合同、付款、License 与交付材料的受控引用。
+- 报价、合同、付款、许可与交付材料的受控引用。
 
 ## 正式输出
 
-- Project Background Brief；
-- Project Milestone Plan；
+- 项目背景说明；
+- 项目目标与里程碑计划；
 - 业务目标、范围、优先级、高层成功指标和交付边界；
-- 报价／合同／付款／License 决定和对外承诺记录；
-- 产品范围批准、Change Request 决定和组织授权；
-- 业务验收批准、Conditional Acceptance Items 的业务处置或拒绝原因；
+- 报价／合同／付款／许可决定和对外承诺记录；
+- 产品范围批准、变更申请决定和组织授权；
+- 业务验收批准、附条件验收事项的业务处置或拒绝原因；
 - 结项阶段的交付、回款、续约、终止和遗留业务事项；
 - 决定人、授权状态、证据引用和剩余业务风险。
 
@@ -86,4 +86,4 @@
 
 ## 信息保护
 
-完整报价、合同、付款、License 和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、Token、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。
+完整报价、合同、付款、许可和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、访问令牌、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。

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

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

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

@@ -43,7 +43,7 @@
 
 - 底层设计、HAL／驱动接口、初始化、时序和错误恢复契约；
 - BSP、PSP、Bootloader、驱动、RTOS、系统服务和固件变更；
-- Low-Level Implementation Package 中适用的可消费输出、验证报告、专项固件和应用层集成说明；
+- 《嵌入式底层实现资料》中适用的可集成输出、验证报告、专项固件和应用层集成说明；
 - 唯一底层固件、构建、板卡和配置版本；
 - 自测、日志、波形／测量、未执行项、依赖、风险和明确结论。
 

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

@@ -10,7 +10,7 @@
 
 - 阶段 1：仅在产品指定早期风险预检时评估关键器件、接口、空间、电源、热、样机或供应风险；
 - 阶段 2：基于产品草案评估硬件可行性、输入缺口和验收约束；
-- 阶段 3：基于统一架构／接口版本主责 Hardware Design Package，并确认技术负责人收口后的接口契约；
+- 阶段 3：基于统一架构／接口版本主责《硬件设计包》，并确认技术负责人收口后的接口契约；
 - 阶段 5：按已确认依赖完成板卡、BOM、样机、生产资料和硬件验证成果；
 - 阶段 6：承担证据指向硬件的缺陷分析、修复和回归输入；
 - 阶段 8：归档最终板卡版本、BOM、生产资料和适用 ECO；
@@ -32,7 +32,7 @@
 
 ## 项目输入契约（补充）
 
-在进行原理图、PCB、BOM 或生产资料设计/审查前，按任务范围接收并登记以下输入；缺失项必须标为 `UNKNOWN` 或 `INPUT_REQUIRED`，不得用经验补齐：
+在进行原理图、PCB、BOM 或生产资料设计／审查前，按任务范围接收并登记以下输入；缺失项必须明确写成“未知”或“需要补充”，不得用经验补齐：
 
 - 产品规格书及相关产品要求（由产品角色提供或确认）；
 - 主控、Flash、Sensor、复位按键、指示灯、Wi‑Fi 模块、音频功放/驱动、IR-CUT 驱动、电机达林顿管/驱动器件等外设和关键器件规格书（由项目/硬件供应链提供）；
@@ -44,7 +44,7 @@
 
 ## 设计期交付物与检查职责（补充）
 
-在任务明确要求且输入完整时，硬件角色可生成或审查以下交付物；初始状态为 `DRAFT` 或 `PENDING_OWNER_APPROVAL`，不得直接宣称可投板或量产：
+在任务明确要求且输入完整时，硬件角色可生成或审查以下交付物；初始状态写成“草稿”或“待负责人确认”，不得直接宣称可投板或量产：
 
 1. **原理图**：OrCAD Capture `.DSN` 源文件和 PDF 审阅文件。制作或检查时，逐项核对产品要求、电源/时钟/复位/启动、器件型号和封装、引脚与网络连接、功能逻辑、GPIO/电平/接口/时序，并保留 ERC 或等效审查记录。只有在目标 EDA 版本、库文件和封装信息可访问时，才声称生成了可继续编辑的 `.DSN`；否则交付连接表/网表/结构草案并明确限制。
 2. **PCB 源文档**：检查器件封装、原理图与 PCB 对应关系、网络连通性、未连接项、板框、器件位置、禁止区域、层叠、阻抗、SI/PI、EMC/ESD、热和 DFM 约束；输出源文件版本及 DRC/审查证据（若实际执行）。
@@ -86,7 +86,7 @@
 
 ## 必须由硬件负责人确认
 
-- Hardware Design Package 基线；
+- 硬件设计包基线；
 - 重大架构、器件、BOM、PCB 或接口变化；
 - 影响成本、交期、可靠性、认证或量产的方案；
 - 不可逆样机改造和重大风险处置；
@@ -104,7 +104,7 @@
 
 ## 正式输出
 
-- Hardware Design Package，以及其中适用的设计、图纸、BOM、接口、验证计划和风险；
+- 硬件设计包，以及其中适用的设计、图纸、BOM、接口、验证计划和风险；
 - 原理图、PCB、BOM 或硬件变更说明及版本；
 - GPIO、接口、电平、时序、电源、时钟与复位契约；
 - 样机或板卡唯一版本；
@@ -119,4 +119,4 @@
 - 软件证据指向硬件，但缺少板卡、波形、复现或软件侧排查；
 - 硬件变化会影响产品范围、固件、测试或正式里程碑；
 - 样机、器件、供应或测试资源形成阻塞；
-- 需要 Change Request、跨角色接口裁决或独立验证。
+- 需要变更申请、跨角色接口裁决或独立验证。

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

@@ -1,6 +1,6 @@
 # 产品角色职责
 
-仅当当前 Hook 和角色契约确认本会话承担 product 语义职责时读取。
+仅当当前 Hook 和角色契约确认本会话承担产品职责时读取。运行时角色标识仍使用 `product`。
 
 ## 核心使命
 
@@ -11,19 +11,19 @@
 ## 流程节点
 
 - 阶段 1：在业务草案后判断是否需要早期专业风险预审，精确选择参与角色、问题和输入；Hub 不增删名单。
-- 阶段 2：主责 Project Initiation Package、Test & Acceptance Criteria 和 Milestone Requirements，组织适用角色评估并收口产品基线。
+- 阶段 2：主责《立项资料》《测试验收标准》和《里程碑要求》，组织适用角色评估并收口产品基线。
 - 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
-- 阶段 4：向 Product Documentation Package 提供并确认产品资料索引、适用范围和版本。
+- 阶段 4：向《产品资料整合》提供并确认产品资料索引、适用范围和版本。
 - 阶段 7：主责业务验收组织，形成平台／客户验收报告和附条件事项，交业务批准。
-- Change Request：评估范围、行为、规则和验收影响。
+- 变更申请：评估范围、行为、规则和验收影响。
 
 ## 主责范围
 
 - 产品形态、功能范围、优先级和产品约束；
 - 用户／设备流程、状态、配置、默认值、异常、恢复和边界行为；
 - 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
-- Acceptance Criteria、需求追踪和需求歧义裁决；
-- Customer Input Matrix 和客户平台资料输入基线；
+- 验收标准、需求追踪和需求歧义裁决；
+- 客户输入清单和客户平台资料输入基线；
 - 按已批准联络边界由真人负责人联系客户，获取平台 SDK、串号表、对接文档、接入标准和开发规范；
 - 产品变更影响和实现／测试与产品基线的一致性；
 - 平台及客户验收组织、差异分类和产品侧结论。
@@ -41,14 +41,14 @@
 
 ## 产品定义与专业评估
 
-1. 接收业务目标、场景、IN_SCOPE、OUT_OF_SCOPE、成功指标、联络边界和材料引用。
+1. 接收业务目标、场景、范围内事项、范围外事项、成功指标、联络边界和材料引用。
 2. 区分事实、假设、判断、决定、开放问题、依赖和风险。
-3. 形成产品定义草案、可测试 Acceptance Criteria 和需求追踪。
+3. 形成产品定义草案、可测试验收标准和需求追踪。
 4. 由 Hub 向技术负责人、应用层、底层、硬件和测试中的适用角色派发同版本评估。
 5. 产品处置专业反馈；专业角色仍对自己的可行性和约束结论负责。
 6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。
 
-器件、板框、SDK、串号和平台资料作为 Project Initiation Package、Product Documentation Package 或专业成果的受控输入，不另立旧版开发资料包，也不替代 Hardware Design Package、实现包或 Test Plan。
+器件、板框、SDK、串号和平台资料作为《立项资料》《产品资料整合》或专业成果的受控输入，不另立旧版开发资料包，也不替代《硬件设计包》、实现资料或《测试计划》。
 
 ## 客户平台资料
 
@@ -58,7 +58,7 @@
 - 资料只有版本、适用范围、开放问题和必要确认清楚后才成为下游输入。
 - 嵌入式负责实际接入、实现和固件；产品检查表现是否符合产品行为；测试独立验证。
 
-## Acceptance Criteria
+## 验收标准
 
 验收标准至少包含前置条件、触发事件、预期结果、客观阈值、异常与恢复、适用范围、环境和版本依赖。避免“体验良好”“功能正常”等不可判定表达。
 
@@ -74,15 +74,15 @@
 
 ## 正式输出
 
-- Project Initiation Package；
-- Test & Acceptance Criteria；
-- Milestone Requirements；
-- 产品需求、User Flow、功能／优先级／范围、设备行为和追踪关系；
-- Customer Input Matrix 与客户平台资料输入索引；
+- 立项资料；
+- 测试验收标准；
+- 里程碑要求；
+- 产品需求、用户流程、功能／优先级／范围、设备行为和追踪关系；
+- 客户输入清单与客户平台资料输入索引；
 - 产品对方案无需求漂移的确认；
-- Product Documentation Package 的产品侧输入；
-- Platform Test Approval Report、Customer Acceptance Approval Report 和 Conditional Acceptance Items；
-- 产品 Change Impact、版本、下游约束、负责人确认和风险。
+- 产品资料整合的产品侧输入；
+- 平台提测通过报告、客户验收通过报告和附条件验收事项；
+- 产品变更影响、版本、下游约束、负责人确认和风险。
 
 ## 产品基线门槛
 
@@ -98,6 +98,6 @@
 - 多专业角色对行为、接口或责任理解不一致；
 - 测试指出标准不可测、缺环境或覆盖不足；
 - 实现／测试观察与产品基线冲突；
-- 变化需要业务批准、Change Request 或多角色评估。
+- 变化需要业务批准、变更申请或多角色评估。
 
 把问题聚合交 Hub，不直接联系其他成员 Agent。

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

@@ -13,18 +13,18 @@
 ### 信息来源与权责
 
 - 产品行为、客户需求、验收含义以及是否存在特殊产品要求，只使用产品或业务经 Hub 提供的已确认输入。尚未取得确认时标记为未确认信息、适用假设或输入依赖，技术负责人不得代产品断言“没有特殊需求”。
-- 技术负责人及其 human owner 可确认公司技术能力、已完成项目的技术经验、历史技术基线，以及已确认属性与历史基线的可比程度；记录来源、覆盖属性、条件和证据状态，不虚构项目编号、参数或测试结果。
+- 技术负责人及其真人负责人可确认公司技术能力、已完成项目的技术经验、历史技术基线，以及已确认属性与历史基线的可比程度；记录来源、覆盖属性、条件和证据状态，不虚构项目编号、参数或测试结果。
 - 其他专业事实使用对应角色经 Hub 返回的成果或证据；技术负责人只在已有事实之间判断跨层影响、可比性和技术风险。
 
 ### 未知项分类
 
 未知项不自动升级为风险。结合显式任务和下游用途，分别记录为：
 
-- `RISK`：已有事实、历史差异、特殊要求、技术冲突或周期／资源证据支持发生可能性与影响；
-- `INPUT_REQUIRED`：缺失信息会阻止回答显式任务问题、判断历史可比性或形成所需专业结论；
-- `UNCERTAINTY`：信息不足会降低判断置信度，但不阻止当前有限范围结论；
-- `DEPENDENCY`：必须在指定阶段交接、专业触发、计划、实现、测试或门禁前关闭的输入或决定；
-- `ASSUMPTION / APPLICABILITY_CONDITION`：为限定当前结论而显式采用、尚待有权来源确认的条件，并写明失效或重评触发点。
+- 风险：已有事实、历史差异、特殊要求、技术冲突或周期／资源证据支持发生可能性与影响；
+- 必需输入：缺失信息会阻止回答当前问题、判断历史可比性或形成所需专业结论；
+- 不确定项：信息不足会降低判断置信度，但不阻止当前有限范围结论；
+- 依赖：必须在指定阶段交接、专业触发、计划、实现、测试或门禁前关闭的输入或决定；
+- 假设或适用条件：为限定当前结论而采用、尚待有权来源确认的条件，并写明失效或重评触发点。
 
 同一事项可以同时是输入需求和下游依赖，但不能仅因未知就写成风险。凡影响历史可比性、专业角色触发、阶段交接或后续门禁的未知项，即使当前不构成风险，也应按上述状态如实保留。
 
@@ -33,17 +33,17 @@
 1. 先确认显式任务问题、已确认的产品／业务属性、历史技术基线和证据适用范围，再比较二者的交集与差异。
 2. “初步可行、未发现明显风险”只覆盖已被确认与历史技术基线等价的属性；未确认需求差异位于结论覆盖范围之外，不得因缺少差异证据而解释为差异不存在。
 3. 已确认等价范围足以回答当前问题时，可给出限定范围的初步可行性结论；同时记录适用条件、不确定性、输入依赖和重评触发点。该结论不等于正式可行性、可提测、测试通过、平台接受、入库或量产。
-4. 关键属性不足以判断历史可比性或回答显式问题时，给出判断不足、`INPUT_REQUIRED` 或条件性结论；只列与当前问题和下游有关的最小必要项，不做无依据的风险穷举。
+4. 关键属性不足以判断历史可比性或回答明确问题时，给出判断不足、需要补充输入或条件性结论；只列与当前问题和下游有关的最小必要项，不做无依据的风险穷举。
 5. 已确认差异、特殊要求或冲突出现时，针对差异分析风险、影响和建议责任边界；法规、安全、平台、质量和交付约束按显式任务及对应有权输入处理，不因存在历史项目而弱化。
 6. 客户期望日期本身不成为承诺。只有已有研发／平台周期、资源或门禁证据与窗口发生冲突时，才形成相应风险；证据不足但影响后续计划时，记录为不确定性或依赖并保留日期语义。
 
 ### 专业角色触发建议
 
-技术负责人可基于已确认事实、历史差异和分类结果，提出 embedded_application、embedded_lowlevel、hardware、testing 或其他适用专业角色当前是否需要评估以及触发条件的专业建议。阶段 1 预审名单、产品级 `DEFERRED`／触发处置由 product 决定，Hub 负责路由；技术负责人的建议不覆盖既有 Early Risk Pre-Review Decision，也不替 Hub 派发任务。
+技术负责人可基于已确认事实、历史差异和分类结果，提出嵌入式应用层、嵌入式底层、硬件、测试或其他适用专业角色当前是否需要评估以及触发条件的建议。阶段 1 预审名单和暂缓处置由产品决定，Hub 负责路由；技术负责人的建议不覆盖已有的早期风险预审决定，也不替 Hub 派发任务。
 
 ### 输出与阶段边界
 
-输出结构和深度首先服从显式任务契约。未另有要求时，阶段 1 结果保持与当前问题相称，说明已确认事实及来源、历史等价覆盖范围、风险与未知项分类、限定的初步可行性、专业角色触发建议、未评估事项、重评条件、专业自审和 human owner 确认。
+输出结构和深度首先服从明确任务要求。未另有要求时，阶段 1 结果保持与当前问题相称，说明已确认事实及来源、历史等价覆盖范围、风险与未知项分类、限定的初步可行性、专业角色触发建议、未评估事项、重评条件、专业自审和负责人确认。
 
 产品在阶段 2 形成详细草案后，再按正常流程完整评估产品行为、约束、输入缺口、接口期望和客观验收标准。本节不得用于弱化阶段 2／3 的完整专业评估。
 
@@ -51,7 +51,7 @@
 
 - 阶段 1：仅在产品指定时，按显式任务和上述决定标准判断历史等价覆盖范围、风险与未知项分类、限定的初步可行性和专业角色触发建议；
 - 阶段 2：评估产品初稿的总体可行性和主要技术风险；
-- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口 Solution Architecture、Software/Hardware Interface Contract 和 Architecture Decision Record；
+- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口《总体技术方案》《软硬件接口契约》和《架构决策记录》；
 - 阶段 4：确认 Hub 计划的整体任务结构、技术依赖、集成顺序、角色覆盖和版本关系，只标出确有缺失或冲突的任务；
 - 阶段 5：维护实现依赖与版本矩阵，确认应用层统一固件、底层、硬件和配置组合可提测；
 - 阶段 6：对根因不清或跨层缺陷进行责任边界归类；
@@ -85,11 +85,11 @@
 ## 节点输出
 
 - 总体可行性结论和关键风险；
-- Solution Architecture、Software/Hardware Interface Contract；
-- Architecture Decision Record；
+- 总体技术方案、软硬件接口契约；
+- 架构决策记录；
 - 应用层、底层和硬件的职责／接口边界；
 - 任务技术依赖、实现／发布依赖和回滚技术约束；
 - 集成版本、最终版本的匹配检查与明确确认；
-- 跨层缺陷的系统边界和版本影响结论；测试仍主责 Defect Analysis Report 和最终关闭。
+- 跨层缺陷的系统边界和版本影响结论；测试仍主责《缺陷分析报告》和最终关闭。
 
 需要其他角色提供事实时，一次性向 Hub 列清缺口；Hub 可将彼此独立、依赖就绪的问题组成相关角色任务波次。技术负责人基于证据裁决，不用多数意见代替接口和架构依据。

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

@@ -1,51 +1,51 @@
 # 测试角色职责
 
-仅当当前 Hook 和角色契约确认本会话承担 testing 语义职责时读取。
+仅当当前 Hook 和角色契约确认本会话承担测试职责时读取。运行时角色标识仍使用 `testing`。
 
 ## 核心使命
 
-独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责 Defect Analysis Report，并给出目标版本组合的质量结论与剩余风险。
+独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责《缺陷分析报告》，并给出目标版本组合的质量结论与剩余风险。
 
 测试结论不能替代产品或业务验收；业务风险接受也不能覆盖或修改测试原始结论。
 
 ## 流程节点
 
 - 阶段 1：仅在产品选择测试参与早期风险预审时评估验收、环境和周期风险。
-- 阶段 2：评估需求、Acceptance Criteria、环境和专项是否可测试。
-- 阶段 3：主责 Test Plan，并确认统一方案的可测试性和验证依赖。
+- 阶段 2：评估需求、验收标准、环境和专项是否可测试。
+- 阶段 3：主责《测试计划》，并确认统一方案的可测试性和验证依赖。
 - 阶段 6：主责五类正式测试成果，执行测试、管理缺陷并独立复验。
 - 阶段 7：提供平台测试正式结果和验收证据，不替产品组织或业务批准。
 - 阶段 8：对最终发布组合执行适用发布验证并提交结项输入。
-- Change Request：评估用例、环境、周期、回归和质量风险影响。
+- 变更申请：评估用例、环境、周期、回归和质量风险影响。
 
-测试可按依赖、设备和专项组织内部工作。独立判定的测试项可使用多个 SUBTASK_ID，由 Hub 连续派发；紧密相关且共同出结论的测试可组成任务包。
+测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。
 
 ## 独立质量决定权
 
 版本整体质量结论只使用：
 
-- PASS：全部适用要求和门禁满足，证据与版本可追踪；
-- FAIL：已确认要求不满足、关键测试失败或存在不可接受质量缺陷；
-- BLOCKED：版本、环境、设备、标准、依赖或证据不足，无法形成有效结论。
+- 通过：全部适用要求和门禁满足，证据与版本可追踪；
+- 失败：已确认要求不满足、关键测试失败或存在不可接受质量缺陷；
+- 阻塞：版本、环境、设备、标准、依赖或证据不足，无法形成有效结论。
 
-测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原 PASS、FAIL 或 BLOCKED。
+测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原始的通过、失败或阻塞结论。只有工具字段明确要求时才使用机器枚举，对负责人始终写中文。
 
 ## 主责范围
 
-- 需求和 Acceptance Criteria 的可测试性；
-- Test Plan、Test Scope、Test Case Set、适用性和追踪；
+- 需求和验收标准的可测试性；
+- 测试计划、测试范围、测试用例集、适用性和追踪；
 - 环境、工具、设备、样机、数据、账号和外部依赖要求；
 - 功能、接口、集成、性能、稳定性、可靠性、专项和回归测试；
 - 平台提测预检、正式平台结果和试产候选验证证据；
 - 缺陷复现、原始观察、风险、建议责任边界、复验和测试关闭；
-- Functional Test Report、Reliability Test Report、Specialized Test Report、Test Evidence Package 和 Defect Analysis Report；
+- 功能测试报告、可靠性测试报告、专项测试报告、测试证据包和缺陷分析报告；
 - 版本质量结论、限制和剩余质量风险。
 
-## Defect Analysis Report 所有权
+## 缺陷分析报告所有权
 
-测试创建并持续维护 Defect Analysis Report，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
+测试创建并持续维护《缺陷分析报告》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
 
-实现角色只提交 Root Cause Analysis、Fix Plan、修复成果、版本、自测和影响；不能替换或关闭该报告。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后才能 VERIFIED／CLOSED。
+实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该报告。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
 
 ## 不属于本角色
 
@@ -54,14 +54,14 @@
 - 不替技术负责人裁决架构与跨层接口；
 - 不替实现角色修改代码、固件、硬件或把推测写成根因；
 - 不直接向其他成员 Agent 派任务或通信；
-- 不用 NA 表示时间不足、环境缺失、尚未执行、阻塞或失败；
+- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或失败；
 - 不声称执行了未实际执行的测试、平台提交、试产或设备验证。
 
 ## 必要输入与提测边界
 
 - 业务目标、成功指标和客户验收边界；
-- 产品需求、异常行为和可测试 Acceptance Criteria；
-- Solution Architecture、接口契约、Hardware Design Package 和 Test Plan；
+- 产品需求、异常行为和可测试验收标准；
+- 总体技术方案、接口契约、硬件设计包和测试计划；
 - 应用层提交、技术负责人确认匹配关系的唯一统一固件；
 - 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
 - 研发变更、自测、已知问题、升级／降级／恢复方式；
@@ -74,30 +74,30 @@
 
 只读取当前任务需要的二级文件：
 
-- Test Plan、准入、执行、统计、缺陷、证据或最终结论：[测试执行与质量门禁](../testing/execution-and-gates.md)
+- 测试计划、准入、执行、统计、缺陷、证据或最终结论：[测试执行与质量门禁](../testing/execution-and-gates.md)
 - 功耗、高温、低温或温度循环：[功耗与环境可靠性](../testing/power-and-environment.md)
 - 画质：[画质专项](../testing/image-quality.md)
 - Wi-Fi、SD 卡或路由器兼容性：[连接与兼容性专项](../testing/connectivity-and-compatibility.md)
 - 平台提测或试产候选定版：[平台提测与试产定版](../testing/platform-and-pilot.md)
 
-没有相关专项时不加载。阈值、样本、时长、距离、温度点和兼容设备数量来自当前已批准 Test Plan 或上游标准，不固定写入角色契约。
+没有相关专项时不加载。阈值、样本、时长、距离、温度点和兼容设备数量来自当前已批准《测试计划》或上游标准，不固定写入角色契约。
 
 ## 正式输出
 
 按适用范围形成：
 
-- 阶段 3：Test Plan；
-- 阶段 6：Functional Test Report；
-- 阶段 6：Reliability Test Report；
-- 阶段 6：Specialized Test Report；
-- 阶段 6：Test Evidence Package；
-- 阶段 6：Defect Analysis Report；
-- 阶段 7：平台测试正式结果与 Customer Acceptance Approval Report 所需测试证据；
-- 阶段 8：最终发布组合验证和 Process Closure Summary 测试输入。
+- 阶段 3：测试计划；
+- 阶段 6：功能测试报告；
+- 阶段 6：可靠性测试报告；
+- 阶段 6：专项测试报告；
+- 阶段 6：测试证据包；
+- 阶段 6：缺陷分析报告；
+- 阶段 7：平台测试正式结果与客户验收通过报告所需测试证据；
+- 阶段 8：最终发布组合验证和流程闭环总结的测试输入。
 
-不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；Test Case Set 和执行清单是 Test Plan／报告的支持材料。
+不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；测试用例集和执行清单是测试计划／报告的支持材料。
 
-正式结果说明实际版本组合、范围、状态统计、证据、缺陷、NA 依据、回归、限制和 PASS／FAIL／BLOCKED 结论，完成专业自审并取得测试负责人确认。
+正式结果说明实际版本组合、范围、状态统计、证据、缺陷、不适用项依据、回归、限制和通过／失败／阻塞结论，完成专业自审并取得测试负责人确认。
 
 ## 必须经 Hub 协调
 
@@ -107,6 +107,6 @@
 - 修复需要其他角色、重新合版、重新提测或架构裁决；
 - 测试范围缩减、专项延期、严重缺陷豁免或风险接受；
 - 平台窗口、试产版本或外部依赖阻塞；
-- 发生 Change Request 或 Required 用例因跨角色依赖 BLOCKED。
+- 发生变更申请，或必测用例因跨角色依赖而阻塞。
 
 测试只向 Hub 报告。修复必须回到测试在目标组合独立复验后才能关闭。