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
@@ -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 应用层、底层和硬件按依赖推进；底层先交应用层合版，统一固件只由应用层输出。