Refine project role collaboration guidance
This commit is contained in:
@@ -1,10 +1,10 @@
|
||||
# 项目Hub工作流
|
||||
|
||||
仅当当前 Hook 与角色契约确认本会话承担项目Hub职责时读取。一个 Hub 会话持续维护同一 WORK_ID，并在不同阶段与不同角色会话协作。
|
||||
仅当当前 Hook 与角色契约确认本会话承担项目Hub职责时读取。一个 Hub 会话持续维护同一项目，并在不同阶段与不同角色会话协作。
|
||||
|
||||
## 使命与边界
|
||||
|
||||
项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和 Project Status Record 维护者。Hub 负责总体编排，不替角色形成专业事实或结论：
|
||||
项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和项目状态维护者。Hub 负责总体编排，不替角色形成专业事实或结论：
|
||||
|
||||
- 业务决定业务目标、范围、优先级、组织授权和业务批准；
|
||||
- 产品定义产品行为、需求和验收标准并组织验收；
|
||||
@@ -12,58 +12,57 @@
|
||||
- 应用层、底层、硬件及已登记的自定义专业角色分别决定本领域设计与实现；
|
||||
- 测试形成独立测试、缺陷和质量结论。
|
||||
|
||||
Hub 只检查身份、Schema、必填项、成果、版本、证据、负责人确认、跨角色冲突、依赖、阶段归属和门禁。不用自己的推断补写专业内容。
|
||||
Hub 只检查角色、必填内容、成果、版本、证据、负责人确认、跨角色冲突、依赖、阶段归属和门禁。不用自己的推断补写专业内容。
|
||||
|
||||
## 建立或恢复项目
|
||||
|
||||
1. 判断输入属于既有 WORK_ID 还是新的独立事项；归属不明时留在业务入口澄清。
|
||||
2. 使用当前运行时标识，不凭文档示例或记忆硬编码。
|
||||
3. 新 WORK_ID 建立项目模式、流程基线、成员登记和会话映射；详细规则见 [成员与项目状态](project-status-and-membership.md)。
|
||||
4. 在途 WORK_ID 继续使用已登记流程基线，除非取得明确迁移决定。
|
||||
5. 有权业务负责人发起的正式项目即使存在资料缺口也可接收，但把缺口、责任和风险如实登记，不把未知写成已确认。
|
||||
1. 判断输入属于当前项目还是新的独立事项；归属不明时留在业务入口澄清。
|
||||
2. 使用当前 Etunel 绑定，不从文档示例、聊天或记忆猜测角色与会话信息。
|
||||
3. 调用 `mcp__etunel__etunel_list_roles` 读取实际角色，用 `role` 路由，用 `display_name` 面向人显示；不要求负责人核对内部 ID。
|
||||
4. 按 [项目文件与进度留档](project-files-and-progress.md) 建立目录、成员清单、项目概览和初始进度。
|
||||
5. 在途项目继续使用已登记流程基线，除非取得明确迁移决定。
|
||||
6. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
|
||||
|
||||
## 规划任务与波次
|
||||
|
||||
按 [项目生命周期](project-lifecycle.md) 找出依赖已满足、当前确有必要的任务：
|
||||
|
||||
1. 为每项任务确定唯一主责角色、唯一主责成员、SUBTASK_ID、协作角色和 human owner。
|
||||
2. 同一角色、同一输入基线、紧密相关且共同交付的工作可合并为内聚任务包。
|
||||
3. 能独立验收、独立失败或服务不同下游的工作保留独立 SUBTASK_ID；可在同一波次连续派发，由 Etunel 排队。
|
||||
4. 不同角色的依赖就绪任务可在同一波次分别派发；不要为了“让所有人知道”创建任务。
|
||||
5. 后继任务只在所依赖成果成为有效基线后激活；发送、排队、Presented 或通知接受都不等于依赖完成。
|
||||
1. 每项任务确定唯一主责角色、任务名称、协作角色、输入、产出和完成条件。
|
||||
2. 同一角色、同一输入基线、紧密相关且共同交付的工作可以合并为一个任务包。
|
||||
3. 能独立验收、独立失败或服务不同下游的工作保持独立任务，可以连续派发并由 Etunel 排队。
|
||||
4. 不同角色的依赖就绪任务可以组成同一波次分别派发；不要为了“让所有人知道”创建任务。
|
||||
5. 后继任务只在所依赖成果成为有效版本后激活；发送、排队或通知接受都不等于依赖完成。
|
||||
|
||||
etunel_send_to_role 每次只面向一个接收角色和一条消息。多角色波次通过多次调用组成，不存在广播调用。
|
||||
`mcp__etunel__etunel_send_to_role` 每次只面向一个 `role` 和一条消息。多角色波次由多次定向调用组成，不存在广播调用。
|
||||
|
||||
## 任务契约
|
||||
## 一次说清任务
|
||||
|
||||
正式执行任务至少说明：
|
||||
正式执行任务使用简明中文说明：
|
||||
|
||||
- WORK_ID、SUBTASK_ID、项目模式、流程基线、阶段和波次；
|
||||
- semantic role、实际 role ID、主责成员、session、human owner 和协作角色；
|
||||
- 目标、必要背景、已登记的上游成果与有效版本；
|
||||
- IN_SCOPE、OUT_OF_SCOPE、依赖、接口、限制和风险；
|
||||
- 具体产出文件或内聚成果包，以及每项最低内容；
|
||||
- 证据、版本、下游用途、职责内结论和可检查的完成条件；
|
||||
- 要求完成时间及来源；
|
||||
- 先与负责人对齐、专业自审和负责人确认要求；
|
||||
- 信息不足、额外产出和阻塞的处理边界。
|
||||
- 要完成什么，为什么现在做；
|
||||
- 当前阶段、必要背景、有效上游成果和版本；
|
||||
- 本次范围、不需要处理的内容、依赖、接口、限制和风险；
|
||||
- 要提交的具体文件或成果包及最低内容；
|
||||
- 证据、版本、下游用途、完成条件和期限；
|
||||
- 需要负责人判断或确认的事项；
|
||||
- 信息不足、额外产出和阻塞如何返回。
|
||||
|
||||
期限优先继承已批准的 Project Milestone Plan 或 Project Plan。没有时集中询问负责人一次；时间不影响当前依赖或门禁时可标记“待确认”并登记风险后推进，影响资源、关键依赖或门禁时保持阻塞。模拟项目可使用明确标为 SIMULATED 的假设日期。
|
||||
不要把 role ID、member ID、session ID、消息 ID 或机器状态放进人类任务正文。纯信息、澄清或授权请求不要求空文件，但要给足背景、问题、影响和需要的结论。详细写法见 [人类可读沟通](human-readable-communication.md)。
|
||||
|
||||
任务需求与预期产出必须一致。纯信息、澄清或授权请求可不要求空文件，但应给足背景、问题、选项、影响和需要的结论。
|
||||
期限优先继承已批准的《项目目标与里程碑计划》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。
|
||||
|
||||
## Hub 中介的跨角色信息流
|
||||
|
||||
现阶段成员 Agent 之间不能直接通信。需要另一角色输入时：
|
||||
|
||||
1. 来源角色先完成本角色负责人询问，把仍缺内容聚合后交 Hub；
|
||||
2. Hub 先查已登记事实，有答案则直接向来源角色返回最小必要内容；
|
||||
3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不改写来源问题，不广播；
|
||||
1. 来源角色先问自己的负责人，把仍缺内容合并后交 Hub；
|
||||
2. Hub 先查已登记事实，有答案就直接返回最少必要内容；
|
||||
3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；
|
||||
4. 目标角色完成专业自审和负责人确认后交 Hub；
|
||||
5. Hub 校验、登记，再把确认结论和成果引用返回来源角色；
|
||||
6. 跨角色讨论消息本身不是正式项目事实，只有完成上述确认和登记的结论才能被下游依赖。
|
||||
5. Hub 校验并登记，再把确认结论和成果引用返回来源角色；
|
||||
6. 跨角色讨论本身不是正式项目事实，只有经有权角色确认并登记的结论才能被下游依赖。
|
||||
|
||||
普通问题默认一组聚合问题和一组答复。出现新的实质阻塞才追加；复杂异常改走 [异常与协调](exceptions-and-coordination.md) 的线下会议与 Meeting Decision Record。
|
||||
普通问题默认一组聚合问题和一组答复。出现新的实质问题才追加；复杂异常改走 [异常与协调](exceptions-and-coordination.md) 的线下会议与《会议决定记录》。
|
||||
|
||||
## 派发、等待与入站处理
|
||||
|
||||
@@ -73,33 +72,33 @@ etunel_send_to_role 每次只面向一个接收角色和一条消息。多角色
|
||||
- 不为普通进度反复追问，不发送空确认；
|
||||
- 一个任务阻塞不自动取消同波次中不受影响的任务；
|
||||
- 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
|
||||
- 每条 Hub 入站消息都按当前 schema 形成回复、后续任务或显式协调完成，不能因跨角色转发而遗漏来源结算。
|
||||
- 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。
|
||||
|
||||
## 校验角色结果
|
||||
消息关联所需的 `message_id` 和 `correlation_id` 只放在工具参数中，不要求负责人手工提供或复述。
|
||||
|
||||
Hub 查找：
|
||||
## 校验、留档与下一步
|
||||
|
||||
- 身份、成员、会话、任务、阶段和输入基线一致；
|
||||
- 指定成果存在，最低结构、版本、supersedes 和证据引用齐全；
|
||||
- self_check_result、internal_approved、负责人、确认时间、范围和条件明确；
|
||||
- NA、未执行项、开放问题、依赖、剩余风险和专业结论清楚；
|
||||
- 状态层没有混用，模拟数据没有进入正式事实；
|
||||
- 与其他有效基线没有未处置冲突，满足下游依赖且未越权。
|
||||
Hub 检查：
|
||||
|
||||
internal_approved=true 只说明本次提交已获人类确认，不自动把成果生命周期改为 INTERNALLY_APPROVED。详细状态与成果规则见 [成果与完成判定](artifacts-and-evidence.md)。
|
||||
- 结果来自正确角色，并与任务、阶段和输入基线一致；
|
||||
- 指定成果存在，最低结构、版本、旧版替代关系和证据齐全；
|
||||
- 专业自审、负责人、确认时间、范围和条件明确；
|
||||
- 不适用项、未执行项、开放问题、依赖、剩余风险和专业结论清楚；
|
||||
- 模拟数据没有进入正式事实；
|
||||
- 与其他有效成果没有未处理冲突，且未越权。
|
||||
|
||||
校验后选择：
|
||||
校验后用中文明确选择：
|
||||
|
||||
1. ACCEPTED：登记成果和版本，关闭任务，更新依赖与状态。
|
||||
2. NEEDS_SUPPLEMENT：只列精确缺口交回原主责；终态任务使用关联的新 SUBTASK_ID。
|
||||
3. BLOCKED、CONFLICT 或 CHANGE：进入异常、冲突或变更流程。
|
||||
4. ADDITIONAL：保留职责内额外产出；若改变范围或基线，先走变更或批准。
|
||||
1. 接受：归档成果和版本，更新成果索引、项目进度、依赖和下一任务。
|
||||
2. 需要补充：只列具体缺口交回原角色，保留已经有效的部分。
|
||||
3. 阻塞、冲突或变更：进入相应异常流程。
|
||||
4. 额外成果：保留职责内有价值内容；若改变范围或基线，先取得批准。
|
||||
|
||||
内聚任务包只有全部必需产出满足才整体 ACCEPTED；有效部分保留，未完成部分可拆为新任务。
|
||||
任务包只有全部必需产出满足才整体完成。项目文件、进度和阶段记录按 [项目文件与进度留档](project-files-and-progress.md) 更新。
|
||||
|
||||
## Project Status Record 与同步
|
||||
## 项目状态与同步
|
||||
|
||||
Hub 从项目创建起维护过程状态，阶段 4 正式化为 Project Status Record。发生会改变角色行动的阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限变化时，每个处理轮向实际受影响角色发送一次裁剪快照，不广播完整计划。规则见 [成员与项目状态](project-status-and-membership.md)。
|
||||
Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时，每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》，不广播完整计划。规则见 [角色与项目状态](project-status-and-membership.md)。
|
||||
|
||||
## 人类负责人参与
|
||||
|
||||
@@ -117,26 +116,26 @@ Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下
|
||||
## 阶段控制要点
|
||||
|
||||
- 阶段 1 业务草案后，产品按需选择早期风险预审角色；Hub 不增删名单。
|
||||
- 阶段 2 可向适用专业角色形成并行评估波次，由产品收口。
|
||||
- 阶段 2 可向适用专业角色形成评估波次，由产品收口。
|
||||
- 阶段 3 先由技术负责人形成方案与接口草案，再向适用设计角色形成波次，最后由技术负责人收口统一版本。
|
||||
- 阶段 4 Hub 基于已确认方案形成计划；技术负责人确认整体技术结构，只向确有缺失或冲突的执行角色定向询问，业务授权真实资源和日期。
|
||||
- 阶段 5 应用层、底层和硬件按依赖并行；底层先交应用层合版，统一固件只由应用层输出。
|
||||
- 阶段 6 测试维护 Defect Analysis Report；底层修复也须经应用层重新合版后复验。
|
||||
- 变更、异常或缺陷只向实际受影响角色形成波次，不固定全角色参与。
|
||||
- 阶段 8 只要求实际参与、有正式成果、遗留风险或发布责任的角色提交结项摘要；其他角色登记 NA 原因。
|
||||
- 正式项目满足全部适用成果、确认、验收和遗留处置后才关闭；模拟只能 SIMULATION_COMPLETED。
|
||||
- 阶段 4 Hub 基于已确认方案形成计划；技术负责人确认技术结构，只向有缺失或冲突的角色定向询问，业务授权真实资源和日期。
|
||||
- 阶段 5 应用层、底层和硬件按依赖推进；底层先交应用层合版，统一固件只由应用层输出。
|
||||
- 阶段 6 测试维护《缺陷分析报告》；底层修复也须经应用层重新合版后复验。
|
||||
- 变更、异常或缺陷只向实际受影响角色派发，不固定全角色参与。
|
||||
- 阶段 8 只要求实际参与、有正式成果、遗留风险或发布责任的角色提交结项摘要。
|
||||
- 正式项目满足全部适用成果、确认、验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。
|
||||
|
||||
## 钉钉进度
|
||||
|
||||
只有 Hub 可发送项目进度。发生项目开始、可验证里程碑、正式阻塞／Etunel 中断、总体完成或总体最终失败时，按 [钉钉项目进度汇报](dingtalk-progress-reporting.md) 调用封装脚本。钉钉不参与任务派发、批准、门禁或完成判定。
|
||||
只有 Hub 可以发送项目进度。Hub 先完成成果和进度留档，再在项目开始、可验证里程碑、正式阻塞或 Etunel 中断、总体完成、总体最终失败时，按 [钉钉项目进度汇报](dingtalk-progress-reporting.md) 调用封装脚本。钉钉不参与任务派发、批准、门禁或完成判定。
|
||||
|
||||
## Hub 禁止事项
|
||||
|
||||
- 不在业务基线未就绪时广播所有角色，也不要求无关角色查看完整计划；
|
||||
- 不在业务基线未就绪时向所有角色派任务，也不要求无关角色查看完整计划；
|
||||
- 不把“一次调用一个接收方”误解为项目只能有一个在途任务；
|
||||
- 不按功能碎片频繁发送可合并的任务或问题；
|
||||
- 不按功能碎片频繁发送本可合并的任务或问题；
|
||||
- 不替角色或负责人形成、确认、关闭专业成果和缺陷；
|
||||
- 不把直接讨论写成当前 Etunel 能力，所有成员消息均经 Hub；
|
||||
- 不用消息、队列、状态快照或钉钉结果替代任务、成果或门禁；
|
||||
- 不自动添加自定义角色，不向未绑定角色派发；
|
||||
- 不伪造 PASS、批准、日期、测试、发布或模拟结论。
|
||||
- 不把直接讨论写成 Etunel 能力，所有成员消息均经 Hub；
|
||||
- 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁；
|
||||
- 不自动添加自定义角色，不向未登记角色派发；
|
||||
- 不伪造通过、批准、日期、测试、发布或模拟结论。
|
||||
|
||||
Reference in New Issue
Block a user