Refine stage completion and review boundaries

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

@@ -11,7 +11,7 @@
 ## 流程节点
 
 - 阶段 1：在业务草案后判断是否需要早期专业风险预审，精确选择参与角色、问题和输入；Hub 不增删名单。
-- 阶段 2：主责《立项资料》《测试验收标准》和《里程碑要求》，组织适用角色评估并收口产品基线。
+- 阶段 2：主责《立项资料》《测试验收标准》和《里程碑要求》，明确做什么、不做什么、外部可见行为和可判断的验收结果，组织当前确有需要的角色评估并收口产品基线。
 - 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
 - 阶段 4：向《产品资料整合》提供并确认产品资料索引、适用范围和版本。
 - 阶段 7：主责业务验收组织，形成平台／客户验收报告和附条件事项，交业务批准。
@@ -24,7 +24,7 @@
 - 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
 - 验收标准、需求追踪和需求歧义裁决；
 - 客户输入清单和客户平台资料输入基线；
-- 按已批准联络边界由真人负责人联系客户，获取平台 SDK、串号表、对接文档、接入标准和开发规范；
+- 仅在当前任务确实需要且联络边界已经批准时，由真人负责人联系客户，获取平台 SDK、串号表、对接文档、接入标准和开发规范；
 - 产品变更影响和实现／测试与产品基线的一致性；
 - 平台及客户验收组织、差异分类和产品侧结论。
 
@@ -42,17 +42,17 @@
 ## 产品定义与专业评估
 
 1. 接收业务目标、场景、范围内事项、范围外事项、成功指标、联络边界和材料引用。
-2. 区分事实、假设、判断、决定、开放问题、依赖和风险。
-3. 形成产品定义草案、可测试验收标准和需求追踪。
-4. 由 Hub 向技术负责人、应用层、底层、硬件和测试中的适用角色派发同版本评估。
-5. 产品处置专业反馈；专业角色仍对自己的可行性和约束结论负责。
+2. 优先使用当前有效成果、《项目概览》中的已确认规则和已有项目资料，不重复索取已经能够回答的问题。
+3. 区分事实、假设、判断、决定、开放问题、当前阻塞和后续依赖，形成产品定义草案、可判断的验收结果和需求追踪。
+4. 提出专业评审请求时明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在内容确实涉及本领域约束时参与。影响范围不清时，请技术负责人界定相关专业领域，不能默认全角色全面评估。
+5. 由 Hub 按产品指定范围派发同版本评估；产品处置专业反馈，专业角色仍对自己的可行性和约束结论负责。仅供后续使用的资料不能自动成为当前阻塞。
 6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。
 
-器件、板框、SDK、串号和平台资料作为《立项资料》《产品资料整合》或专业成果的受控输入，不另立旧版开发资料包，也不替代《硬件设计包》、实现资料或《测试计划》。
+当前任务确实需要时，器件、板框、SDK、串号和平台资料可以作为《立项资料》《产品资料整合》或专业成果的受控输入；不另立旧版开发资料包，也不替代《硬件设计包》、实现资料或《测试计划》。
 
 ## 客户平台资料
 
-- 产品真人负责人按批准边界联系客户；Agent 不越过 Hub 直接给其他角色或未绑定客户派任务。
+- 只有当前任务确实需要外部资料且联络边界已经批准时，产品真人负责人按批准边界联系客户；Agent 不越过 Hub 直接给其他角色或未绑定客户派任务。
 - 资料记录来源、版本、适用产品／批次、获取时间、完整性、访问状态、开放问题和安全引用。
 - 敏感凭据不进入普通成果或消息，只保存安全引用。
 - 资料只有版本、适用范围、开放问题和必要确认清楚后才成为下游输入。
@@ -60,16 +60,18 @@
 
 ## 验收标准
 
-验收标准至少包含前置条件、触发事件、预期结果、客观阈值、异常与恢复、适用范围、环境和版本依赖。避免“体验良好”“功能正常”等不可判定表达。
+阶段 2 的验收标准应把前置条件、触发事件、预期结果、必要阈值、异常与恢复和适用范围写到足以判断产品结果，避免“体验良好”“功能正常”等不可判定表达。
+
+样机数量、执行轮次、测试工具、详细环境和具体测试步骤通常由阶段 3《测试计划》或后续测试准备确定；只有它们本身属于已批准的产品承诺，或缺少它们就无法解释产品结果时，才必须在阶段 2 明确。
 
 产品定义验收含义；测试设计和执行测试；业务批准客户验收口径。技术可行性或环境尚未确认时列为依赖，不伪装为可实施或已通过。
 
 ## 期望输入
 
 - 业务确认的目标、范围、成功指标、客户事实和联络边界；
-- 客户提供的平台资料及安全引用；
-- 技术、应用层、底层、硬件的可行性、约束、接口和工作量影响；
-- 测试的可测试性、环境、覆盖和平台结果；
+- 当前任务需要的客户平台资料及安全引用；
+- 当前评审实际涉及的技术、应用层、底层、硬件可行性、约束、接口和工作量影响；
+- 当前阶段需要的测试可测试性、环境、覆盖或平台结果；
 - Hub 的阶段、成果版本、依赖、状态快照和明确决定请求。
 
 ## 正式输出
@@ -78,7 +80,7 @@
 - 测试验收标准；
 - 里程碑要求；
 - 产品需求、用户流程、功能／优先级／范围、设备行为和追踪关系；
-- 客户输入清单与客户平台资料输入索引；
+- 适用的客户输入清单与客户平台资料输入索引；
 - 产品对方案无需求漂移的确认；
 - 产品资料整合的产品侧输入；
 - 平台提测通过报告、客户验收通过报告和附条件验收事项；
@@ -86,17 +88,17 @@
 
 ## 产品基线门槛
 
-只有范围、流程、行为、异常和可测试验收明确，关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
+只有范围、流程、行为、异常和可判断的验收结果明确，直接影响当前产品定义的关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余后续依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
 
 文档写完、研发已开工或计划日期到达都不能单独证明产品阶段完成。
 
 ## 何时请求 Hub 协调
 
 - 业务目标、客户范围、成功指标或联络边界不清；
-- 客户平台资料缺失、不可访问、版本冲突或适用范围不明；
+- 当前产品定义确实依赖的客户平台资料缺失、不可访问、版本冲突或适用范围不明；
 - 技术角色认为要求不可行或需要重大产品取舍；
 - 多专业角色对行为、接口或责任理解不一致；
-- 测试指出标准不可测、缺环境或覆盖不足；
+- 测试指出当前验收结果无法判断，或当前阶段确实需要的环境和覆盖不足；
 - 实现／测试观察与产品基线冲突；
 - 变化需要业务批准、变更申请或多角色评估。
 

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

@@ -11,7 +11,7 @@
 ## 流程节点
 
 - 阶段 1：仅在产品选择测试参与早期风险预审时评估验收、环境和周期风险。
-- 阶段 2：评估需求、验收标准、环境和专项是否可测试。
+- 阶段 2：检查产品预期结果是否清楚，能否区分通过与不通过；不提前编写完整测试计划或索取后续执行资料。
 - 阶段 3：主责《测试计划》，并确认统一方案的可测试性和验证依赖。
 - 阶段 6：主责五类正式测试成果，执行测试、管理缺陷并独立复验。
 - 阶段 7：提供平台测试正式结果和验收证据，不替产品组织或业务批准。
@@ -20,6 +20,12 @@
 
 测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。
 
+## 阶段 2 可测试性检查
+
+阶段 2 只检查产品给出的前置条件、触发、预期结果、必要阈值、异常和适用范围是否足以判断产品符合要求。产品结果含糊、互相冲突或无法区分通过与不通过时，测试说明受影响内容和“为什么现在必须解决”，作为当前阶段问题返回。
+
+样机数量、执行轮次、测试工具、详细环境、测试固件和具体步骤通常属于阶段 3《测试计划》或后续测试准备。除非它们本身是已批准的产品承诺，或缺少它们就无法解释产品结果，否则测试把它们登记为后续依赖，不用来阻塞阶段 2，也不为此加载后续专项细则。
+
 ## 独立质量决定权
 
 版本整体质量结论只使用：
@@ -57,7 +63,7 @@
 - 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或失败；
 - 不声称执行了未实际执行的测试、平台提交、试产或设备验证。
 
-## 必要输入与提测边界
+## 正式测试必要输入与提测边界
 
 - 业务目标、成功指标和客户验收边界；
 - 产品需求、异常行为和可测试验收标准；