Refine stage completion and review boundaries

2026-09-03 10:20:27 +08:00
parent af8596a8a2
commit 76cb0846d4
19 changed files with 114 additions and 63 deletions
@@ -21,7 +21,7 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 ## 先定义产出要求

-正式执行任务派发时明确：
+正式执行任务的产出和完成条件只来自“本阶段必须完成”的内容。后续阶段处理和当前不需要的内容可以登记，但不能自动成为当前成果、任务完成条件或门禁。“本阶段完成约定”不能替代正式成果的适用性判断、受控跳转或《成果豁免申请》。派发时明确：

 1. 正式成果或成果包名称及唯一主责角色；
 2. 每项最低内容、适用子项和协作边界；
@@ -75,6 +75,8 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 负责人确认表示当前负责人实际查看本次结果并确认可以作为该角色正式提交。至少记录确认人、时间、文件或版本、范围和附带条件。AI 不得自行声称已获确认；模拟项目只确认模拟材料的使用和流程推进，不证明模拟值真实。

+负责人确认随对应文件、版本、适用范围和附带条件继续有效。Hub 归档、移动或引用同一成果不需要重新确认；只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。另一角色对该成果作新的专业评估时，仍须取得该角色自己的负责人确认。
+
 ## 不适用、延期与成果豁免

 - 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
@@ -94,7 +96,7 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读

 角色可以提交职责内有价值的额外文件，说明它与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。

-Hub 可以将其纳入成果索引。若改变范围、接口、角色责任、基线、排期、正式成果或验收，先走《变更申请》，不能静默生效。
+Hub 可以将其作为支持材料保存。额外文件不会自动成为正式成果、增加当前完成条件、制造新阻塞或激活下游依赖。若确实需要改变范围、接口、角色责任、基线、排期、正式成果或验收，先由有权负责人批准并走《变更申请》，不能静默生效。

 ## 事实、判断和证据

@@ -106,10 +108,16 @@ Hub 可以将其纳入成果索引。若改变范围、接口、角色责任、

 代码、固件、硬件、配置、设计、计划或报告给出足以识别对象的版本或引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口、板卡、BOM、ECO、构建或环境的匹配关系和下游约束。

-新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。
+文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时，才创建新版本并按需要重新确认。只更新任务状态、转交说明或排版，生成内容相同的重复副本，或补充不改变结论的过程说明，不升正式版本；有复盘价值时写入阶段记录。不得为排版或状态更新覆盖已经接受的文件。代码、固件、硬件、配置和构建物继续遵循本领域版本规则，实际对象或构建发生变化时必须能区分版本。
+
+新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。成果索引为每项成果明确一个当前有效版本，下游默认只接收该版本；历史版本和过程材料不参与当前完成判断，除非被明确恢复为有效版本。

 ## Hub 校验边界

 Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。

+成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。
+
+成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。
+
 向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
@@ -99,6 +99,8 @@ Hub 对每条入站消息选择：

 消息结算、排队和送达不代表任务、成果、阶段或项目完成。

+成果已经按 [成果与完成判定](artifacts-and-evidence.md) 被 Hub 接受并归档后，后续任务记录异常不撤销成果，也不要求成员重复制作或提交；Hub 单独记录并说明运行时异常。尚未实际收到或校验成果时，不能用消息状态继续推进。本文件不为此设计额外重试、去重或队列逻辑。
+
 ## 附件

 直接使用当前消息正文和内嵌内容。仅当消息明确列出附件且为当前任务必要输入时，调用 `mcp__etunel__etunel_receive_message` 获取所需附件。Hub 收到成果文件后按 [项目文件与进度留档](project-files-and-progress.md) 归档；不要为探测队列或重复确认而读取。
@@ -6,7 +6,7 @@

 成员按以下顺序处理：

-1. 检查任务和本会话已有的已确认资料；
+1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件；
 2. 一次向当前负责人列清缺什么、用途、影响和建议来源；
 3. 负责人能回答时记录来源、时间、范围和条件后继续；
 4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
@@ -42,6 +42,8 @@ Hub 有登记答案时直接补足；没有时只向实际信息所有者角色

 正式阻塞用简明中文说明原因、已完成成果、负责人沟通、线下协调、影响、需要谁采取什么动作以及恢复条件。

+缺口只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才是当前阻塞。提出方必须指明受影响的本阶段必需项和“为什么现在必须解决”；仅供后续阶段使用的资料登记为后续依赖，不阻塞当前阶段。
+
 - Hub 评估关键路径；不受影响的任务继续。
 - Hub 主动提醒当前主责和实际关联角色，提供问题、证据、影响、原流程位置、所需回应和期限；不机械通知全体角色。
 - 能由一个角色解决时只派该角色；多个独立问题可以形成波次。
@@ -49,6 +51,8 @@ Hub 有登记答案时直接补足；没有时只向实际信息所有者角色
 - 需要用户、业务、项目发起人或重大争议决定时，Hub 负责人介入。
 - 阻塞解除后由 Hub 派发新的恢复或返工任务。

+新发现的安全、合规或可能造成不可逆损失的风险尚待确认时，Hub 可以先暂停受影响工作，并立即请求对应专业负责人和 Hub 负责人判断；无关任务继续。确认后把结论写入本阶段完成约定和项目记录，再由有权方决定解决、延期、接受风险或恢复工作，不能让未经核实的担忧永久阻塞整个项目。
+
 Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞；正常排队和等待不是阻塞。阻塞发生和解除都更新项目进度与阶段记录。

 ## 复杂线下会议与会议决定记录
@@ -20,12 +20,19 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认
 2. 使用当前 Etunel 绑定，不从文档示例、聊天或记忆猜测角色与会话信息。
 3. 调用 `mcp__etunel__etunel_list_roles` 读取实际角色，用 `role` 路由，用 `display_name` 面向人显示；不要求负责人核对内部 ID。
 4. 按 [项目文件与进度留档](project-files-and-progress.md) 建立目录、成员清单、项目概览和初始进度。
-5. 在途项目继续使用已登记流程基线，除非取得明确迁移决定。
-6. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
+5. 从《项目概览》读取当前项目已经确认的特殊规则；只登记有权负责人明确确认的内容，并持续沿用到同一决定权人修改或取消，不在每项任务中重复询问。
+6. 在途项目继续使用已登记流程基线，除非取得明确迁移决定。
+7. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
+
+## 启动阶段并明确完成约定
+
+进入每个阶段时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”：本阶段必须完成、后续阶段处理、当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只需在与本角色负责人正常对齐时确认或纠正自己的部分，不另发全员确认任务。涉及业务范围、客户承诺或组织授权时，再取得业务确认。
+
+新问题只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才可成为本阶段阻塞。提出问题的角色必须说明对应的当前必需项和“为什么现在必须解决”；仅供后续使用的资料登记为后续依赖。

 ## 规划任务与波次

-按 [项目生命周期](project-lifecycle.md) 找出依赖已满足、当前确有必要的任务：
+按本阶段完成约定和 [项目生命周期](project-lifecycle.md) 找出依赖已满足、当前确有必要的任务：

 1. 每项任务确定唯一主责角色、任务名称、协作角色、输入、产出和完成条件。
 2. 同一角色、同一输入基线、紧密相关且共同交付的工作可以合并为一个任务包。
@@ -40,7 +47,7 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认
 正式执行任务使用简明中文说明：

 - 要完成什么，为什么现在做；
- 当前阶段、必要背景、有效上游成果和版本；
+- 当前阶段、本阶段完成约定、必要背景、有效上游成果和版本；
 - 本次范围、不需要处理的内容、依赖、接口、限制和风险；
 - 要提交的具体文件或成果包及最低内容；
 - 证据、版本、下游用途、完成条件和期限；
@@ -56,8 +63,8 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认
 现阶段成员 Agent 之间不能直接通信。需要另一角色输入时：

 1. 来源角色先问自己的负责人，把仍缺内容合并后交 Hub；
-2. Hub 先查已登记事实，有答案就直接返回最少必要内容；
-3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；
+2. Hub 依次检查当前有效成果、《项目概览》中的已确认规则和项目已有资料，有答案就直接返回最少必要内容；
+3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；只有当前确实需要且联络边界已批准时，才由相应真人负责人联系外部；
 4. 目标角色完成专业自审和负责人确认后交 Hub；
 5. Hub 校验并登记，再把确认结论和成果引用返回来源角色；
 6. 跨角色讨论本身不是正式项目事实，只有经有权角色确认并登记的结论才能被下游依赖。
@@ -74,6 +81,8 @@ Hub 只检查角色、必填内容、成果、版本、证据、负责人确认
 - 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
 - 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。

+如果成果已经满足下文的接受条件并完成归档，随后出现 Etunel 任务记录“已处理”“未找到”等运行时异常，不撤销成果、不要求成员重复制作或重复提交，也不倒退已经完成的阶段；Hub 只记录并说明运行时异常。文件尚未实际收到、无法访问或尚未校验时，不能用消息状态代替成果继续推进。本 Skill 不规定队列、重试或去重实现。
+
 消息关联所需的 `message_id` 和 `correlation_id` 只放在工具参数中，不要求负责人手工提供或复述。

 ## 校验、留档与下一步
@@ -87,6 +96,10 @@ Hub 检查：
 - 模拟数据没有进入正式事实；
 - 与其他有效成果没有未处理冲突，且未越权。

+只有实际收到并能访问成果、来源角色正确、成果与当前任务及输入基线一致，并且必要版本、证据、自审和负责人确认满足要求时，Hub 才能选择“接受”。选择后必须在同一处理轮完成文件归档、成果索引更新并明确说明接受结论；这些动作全部完成后，成果才成为当前有效版本。附件刚送达、成员说“已完成”或消息显示“已处理”都不能单独视为接受。
+
+同一文件、版本、适用范围和附带条件已经有有效负责人确认时，Hub 直接沿用，不再要求重复确认。只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。
+
 校验后用中文明确选择：

 1. 接受：归档成果和版本，更新成果索引、项目进度、依赖和下一任务。
@@ -96,6 +109,8 @@ Hub 检查：

 任务包只有全部必需产出满足才整体完成。项目文件、进度和阶段记录按 [项目文件与进度留档](project-files-and-progress.md) 更新。

+当“本阶段必须完成”的事项和门禁全部满足，且成果、确认、索引、进度和阶段小结已经留档时，Hub 及时结束本阶段并启动下一阶段，不因可选完善或后续资料尚未提前收齐而继续追加当前阶段任务。下一阶段需要的资料由该阶段按需获取。
+
 ## 项目状态与同步

 Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时，每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》，不广播完整计划。规则见 [角色与项目状态](project-status-and-membership.md)。
@@ -116,7 +131,7 @@ Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下
 ## 阶段控制要点

 - 阶段 1 业务草案后，产品按需选择早期风险预审角色；Hub 不增删名单。
- 阶段 2 可向适用专业角色形成评估波次，由产品收口。
+- 阶段 2 由产品明确评审角色和具体问题；测试检查产品结果是否可判断，其他专业角色按实际影响参与，最后由产品收口。
 - 阶段 3 先由技术负责人形成方案与接口草案，再向适用设计角色形成波次，最后由技术负责人收口统一版本。
 - 阶段 4 Hub 基于已确认方案形成计划；技术负责人确认技术结构，只向有缺失或冲突的角色定向询问，业务授权真实资源和日期。
 - 阶段 5 应用层、底层和硬件按依赖推进；底层先交应用层合版，统一固件只由应用层输出。
@@ -35,7 +35,7 @@ Hub 调用 `mcp__etunel__etunel_list_roles` 后，按目标 `role` 找到对应

 ## 提问、结果和阻塞

-缺信息时一次说明：缺什么、为什么需要、缺失会影响什么、建议向谁获取、现在还能继续什么。不要逐句追问。
+缺信息时一次说明：缺什么、为什么现在需要、会影响本阶段哪项成果或决定、建议向谁获取、现在还能继续什么。只供后续阶段使用的信息明确写成后续依赖，不要逐句追问或把它说成当前阻塞。

 返回结果时先说结论，再列成果文件、关键验证、仍未解决的问题和下一步。专业细节放在成果文件中，不把大段日志粘到聊天正文。

@@ -22,7 +22,7 @@
 - 要提交哪些文件或结果，做到什么程度算完成；
 - 期限、风险、下游用途和需要负责人判断的事项。

-一次列出当前能预见的信息缺口。负责人确认理解、补足输入或明确可以开始后再执行。不要复述运行时 ID、英文状态和内部字段；详细写法见 [人类可读沟通](human-readable-communication.md)。
+同时理解 Hub 给出的本阶段完成约定，并在本角色范围内核对哪些是本阶段必须完成、哪些留到后续、哪些当前不需要。一次列出当前能预见的信息缺口。负责人确认理解、补足输入或明确可以开始后再执行。不要复述运行时 ID、英文状态和内部字段；详细写法见 [人类可读沟通](human-readable-communication.md)。

 ## 执行本角色任务

@@ -33,20 +33,23 @@
 5. 未执行验证说明原因和影响，不虚构构建、测试、设备结果或人类意见。
 6. 发现范围、接口、版本、角色责任、日期或验收变化时不静默修改基线，提交 Hub 走《变更申请》。
 7. 产出完成前不频繁发进度；只有必要补充、正式阻塞或 Hub 明确要求的关键状态才发送非终态消息。
+8. 发现后续阶段会需要的资料时向 Hub 登记，但不自动扩大当前任务，也不把它写成当前阻塞。

 ## 信息不足与跨角色输入

 按以下顺序处理：

-1. 检查任务和本会话已有的已确认输入。
+1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件。
 2. 一次向当前负责人列出缺什么、用途、影响和建议来源。
 3. 负责人能提供则记录来源、范围、时间和条件后继续。
 4. 负责人无法提供时，提醒其线下联系能解决问题的人；讨论结果回到本会话。
-5. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组问题，写明建议的信息所有者和当前还能继续的范围。
+5. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组问题，写明建议的信息所有者、它影响哪项当前必需内容、为什么现在需要，以及当前还能继续的范围。
 6. Hub 返回后核对来源角色、确认状态、成果版本、适用范围和风险，再继续任务。

 不要逐句追问或绕过 Hub。普通问题默认一问一答；复杂异常按《会议决定记录》流程处理。

+只有缺失内容直接导致本次成果无法形成、完成条件无法判断、本角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才报告当前阻塞。仅供后续阶段使用的资料作为后续依赖返回，不阻塞本任务。
+
 ## 专业自审与负责人确认

 正式结果至少让 Hub 找到：
@@ -41,6 +41,12 @@ Hub 在项目开始时建立：

 默认角色目录使用稳定的中文角色名。自定义角色使用 `etunel_list_roles` 返回的 `display_name`，去除目标文件系统不允许的字符；没有参与的角色不创建空目录。不得把文件散放到 `项目资料/` 根目录。

+## 项目概览与已确认规则
+
+`00-项目管理/项目概览.md` 保存项目名称、模式、流程基线、目标和当前项目已经确认的特殊规则。每条特殊规则写清内容、适用范围、决定权角色或负责人、确认依据和生效时间；Hub 只能登记有权负责人明确确认的内容，不能把自己的推断写成规则。
+
+项目规则持续有效，直到同一决定权人明确修改或取消。各角色只确认自己决定权内的规则：产品确认产品行为和验收边界，业务确认业务范围、客户联络和正式承诺，Hub 负责人确认其权限内的流程处理，专业角色确认本领域限制；改变既有正式基线时仍按《变更申请》处理。
+
 ## 项目成员清单

 项目创建完成、首个正式任务派发前，Hub 调用 `mcp__etunel__etunel_list_roles`。角色增加、替换或关系变化后重新查询。每次把同一份返回快照保存为：
@@ -57,14 +63,16 @@ Hub 在项目开始时建立：
 - 有复盘价值的草案、退回材料、问题说明、会议决定、变更、豁免和阻塞资料放入 `过程记录/`。
 - 普通问答、空确认、重复副本和没有改变行动的临时文件不留档。
 - 已接受版本不得覆盖。新版本保留旧版，并在 `成果索引.md` 写明当前有效版本、旧版及替代关系。
+- 文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时才创建新版本。状态、转交、排版、相同副本和不改变结论的过程说明不升正式版本；有复盘价值时写入阶段记录。代码、固件、硬件、配置和构建物仍按本领域规则区分实际版本。
 - 固件、源码包、设计源文件等有既定文件名的技术成果保留原文件名，通过版本目录或成果索引区分版本。
 - `成果索引.md` 至少写明中文成果名、阶段、主责角色、文件位置、版本、确认状态、当前适用性和被替代关系。
+- 每项成果只标记一个当前有效版本。下游默认只接收该版本；旧版和过程材料继续留存，但不参与当前完成判断，除非被明确恢复为有效版本。

 ## 项目进度与阶段记录

 `00-项目管理/项目进度.md` 是当前状态快照，使用简洁中文说明：当前阶段、已完成事项、正在进行事项、实际阻塞、下一步、责任角色和更新时间。

-每个阶段的 `阶段记录.md` 按时间追加有复盘价值的事件：任务波次开始、成果接收、影响进度的退回、阻塞与解除、重要决定、变更、门禁和阶段交接。每条记录写清发生了什么、相关文件、影响和下一步，不转存完整聊天或大段日志。
+每个阶段开始时，在 `阶段记录.md` 写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要；它不是新的正式成果。此后按时间追加有复盘价值的事件：任务波次开始、成果接收、影响进度的退回、阻塞与解除、重要决定、变更、门禁和阶段交接。每条记录写清发生了什么、相关文件、影响和下一步，不转存完整聊天或大段日志。

 在以下事件后更新：

@@ -79,7 +87,9 @@ Etunel 的排队、送达、普通回复和空确认本身不触发留档。

 ## 阶段交接、跳转与回退

-正式阶段交接前，Hub 确认适用的必要成果已保存、版本可识别、负责人确认已记录、成果索引已更新，并在来源阶段写入阶段小结。小结说明完成内容、有效文件、未决项、风险、门禁结论和下一阶段。
+正式阶段交接前，Hub 确认本阶段必须完成的适用成果已保存、版本可识别、负责人确认已记录、成果索引已更新，并在来源阶段写入阶段小结。小结说明完成内容、有效文件、未决项、后续依赖、风险、门禁结论和下一阶段。
+
+本阶段门禁通过并完成上述留档后，Hub 及时结束本阶段并启动下一阶段，不等待未来阶段的全部资料提前齐备。下一阶段根据实际任务按需索取自己的输入；可选完善和后续依赖不能继续占用已经完成的阶段。

 跳转、回退、暂缓或返工时：

@@ -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：方案设计

@@ -53,7 +53,8 @@ Hub 在项目开始和角色变化后调用 `mcp__etunel__etunel_list_roles`。

 Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记录；阶段 4 将其正式化为《项目状态内部记录》，此后版本化维护。至少覆盖：

- 项目模式、流程基线、当前阶段和门禁；
+- 项目模式、流程基线、当前阶段、本阶段完成约定和门禁；
+- 当前项目已确认的特殊规则及其适用范围；
 - 任务、主责角色、协作角色、依赖、期限和下一步；
 - 当前角色列表、加入退出和交接状态；
 - 风险、阻塞、决定、变更和豁免；
@@ -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 协调

 - 业务目标、客户范围、成功指标或联络边界不清；
- 客户平台资料缺失、不可访问、版本冲突或适用范围不明；
+- 当前产品定义确实依赖的客户平台资料缺失、不可访问、版本冲突或适用范围不明；
 - 技术角色认为要求不可行或需要重大产品取舍；
 - 多专业角色对行为、接口或责任理解不一致；
- 测试指出标准不可测、缺环境或覆盖不足；
+- 测试指出当前验收结果无法判断，或当前阶段确实需要的环境和覆盖不足；
 - 实现／测试观察与产品基线冲突；
 - 变化需要业务批准、变更申请或多角色评估。

@@ -11,7 +11,7 @@
 ## 流程节点

 - 阶段 1：仅在产品选择测试参与早期风险预审时评估验收、环境和周期风险。
- 阶段 2：评估需求、验收标准、环境和专项是否可测试。
+- 阶段 2：检查产品预期结果是否清楚，能否区分通过与不通过；不提前编写完整测试计划或索取后续执行资料。
 - 阶段 3：主责《测试计划》，并确认统一方案的可测试性和验证依赖。
 - 阶段 6：主责五类正式测试成果，执行测试、管理缺陷并独立复验。
 - 阶段 7：提供平台测试正式结果和验收证据，不替产品组织或业务批准。
@@ -20,6 +20,12 @@

 测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。

+## 阶段 2 可测试性检查
+
+阶段 2 只检查产品给出的前置条件、触发、预期结果、必要阈值、异常和适用范围是否足以判断产品符合要求。产品结果含糊、互相冲突或无法区分通过与不通过时，测试说明受影响内容和“为什么现在必须解决”，作为当前阶段问题返回。
+
+样机数量、执行轮次、测试工具、详细环境、测试固件和具体步骤通常属于阶段 3《测试计划》或后续测试准备。除非它们本身是已批准的产品承诺，或缺少它们就无法解释产品结果，否则测试把它们登记为后续依赖，不用来阻塞阶段 2，也不为此加载后续专项细则。
+
 ## 独立质量决定权

 版本整体质量结论只使用：
@@ -57,7 +63,7 @@
 - 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或失败；
 - 不声称执行了未实际执行的测试、平台提交、试产或设备验证。

-## 必要输入与提测边界
+## 正式测试必要输入与提测边界

 - 业务目标、成功指标和客户验收边界；
 - 产品需求、异常行为和可测试验收标准；