Refine stage completion and review boundaries

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

@@ -5,6 +5,9 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成
 ## 通用推进原则
 
 - 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
+- 每个阶段开始时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只在与本角色负责人对齐时确认或纠正自己的部分，不为此另开全员确认任务。
+- 角色提出新缺口时，必须说明它直接影响哪项本阶段成果、完成条件或决定，以及为什么现在必须解决。后续使用但不影响当前判断的资料只登记为后续依赖，不能阻塞当前阶段。
+- 本阶段门禁满足、成果和确认留档后，Hub 及时结束本阶段并启动下一阶段。不要等待后续阶段的全部资料提前齐备；新阶段根据自己的任务按需取得输入。
 - 每项任务只有一个主责角色和一个可以独立判断的结果。
 - 主责草案、专业角色评估或设计、主责收口的依赖不可颠倒；同一基线上的独立任务可以形成波次。
 - 正式结果必须有指定成果、版本、证据、专业自审和负责人确认。
@@ -37,11 +40,13 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成
 
 ### 正常任务链
 
-1. 产品基于阶段 1 基线形成产品定义草案、详细客户输入和可测试验收标准。
-2. Hub 以同一草案版本向适用的技术、实现、硬件和测试角色派发专业评估；依赖独立时可以形成波次。
-3. 各角色只返回本领域可行性、约束、缺口、风险和建议，不代产品改需求。
-4. 产品处置反馈、解决需求冲突并收口产品基线。
-5. 业务批准客户范围、验收边界和需要组织授权的结论。
+1. 产品优先使用阶段 1 基线、项目已确认规则和已有资料，明确产品做什么、不做什么、外部可见行为以及如何判断结果符合要求，形成三类正式成果草案；只补当前阶段确实需要的客户输入，不提前收齐后续设计、实现、测试或生产资料。
+2. 产品在评审请求中明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在产品内容确实涉及本领域约束时参与。影响范围不清时，可先由技术负责人界定相关专业领域，不能因此默认让所有角色全面评估。
+3. Hub 以同一草案版本按产品指定范围定向派发；依赖独立时可以形成波次，但不得自行增加评审对象或专业问题。
+4. 各角色只返回本领域对当前产品定义的可行性、约束、缺口、风险和建议，并说明是否直接影响本阶段完成约定；不代产品改需求，也不把后续阶段的完整资料要求变成当前阻塞。
+5. 测试在本阶段判断预期结果是否清楚、可区分通过与不通过；样机数量、执行轮次、工具和详细环境通常留到《测试计划》或后续测试准备，除非它们本身是已批准的产品承诺。
+6. 产品处置反馈、解决需求冲突并收口产品基线。
+7. 业务批准客户范围、验收边界和需要组织授权的结论。
 
 ### 正式成果
 
@@ -49,11 +54,11 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成
 - 测试验收标准
 - 里程碑要求
 
-客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料可以作为包内内容或支持输入，不另立旧版开发资料包。
+客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料在当前产品定义确实需要时，可以作为包内内容或支持输入；不另立旧版开发资料包，也不因后续阶段可能使用而要求阶段 2 全部收齐。
 
 ### 门禁
 
-产品行为、范围、异常边界、接口期望和客观验收标准明确；关键专业约束已处置；产品负责人确认，业务完成范围批准。
+产品行为、范围、异常边界、确有需要的接口期望和可判断的验收结果明确；直接影响当前定义的关键专业约束已处置；产品负责人确认，业务完成范围批准。已经登记的后续依赖不妨碍阶段交接，下一阶段启动后按需取得资料。
 
 ## 阶段 3：方案设计