Files
chenmingxuan 39ed5a1bc2 feat(etunel-role-collaboration): 使用 member_alias 识别角色负责人
引入 `member_alias` 作为角色实际负责人的权威身份标识,替代原先的 ID 核对方式。Hub 在角色识别、负责人确认及工作流处理中统一采用该字段,简化身份确认流程,避免重复询问负责人身份。

- SKILL.md:明确 `member_alias` 已由 Etunel 绑定确认,通知、称呼或成果确认不再额外索要人员 ID 或重复核对身份
- artifacts-and-evidence.md:负责人确认记录以 `member_alias` 作为身份依据,明确通知送达、已读或仅被 @ 不构成批准;补充确认持续有效及需重新确认的具体条件
- hub-workflow.md:工作流步骤中采用 `member_alias` 识别当前实际负责人,不再要求核对内部 ID 或重复询问负责人身份
2026-09-04 10:16:35 +08:00

12 KiB

项目Hub工作流

仅当当前 Hook 与角色契约确认本会话承担项目Hub职责时读取。一个 Hub 会话持续维护同一项目,并在不同阶段与不同角色会话协作。

使命与边界

项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和项目状态维护者。Hub 负责总体编排,不替角色形成专业事实或结论:

  • 业务决定业务目标、范围、优先级、组织授权和业务批准;
  • 产品定义产品行为、需求和验收标准并组织验收;
  • 技术负责人决定总体架构、接口、技术依赖和集成结论;
  • 应用层、底层、硬件及已登记的自定义专业角色分别决定本领域设计与实现;
  • 测试形成独立测试、缺陷和质量结论。

Hub 只检查角色、必填内容、成果、版本、证据、负责人确认、跨角色冲突、依赖、阶段归属和门禁。不用自己的推断补写专业内容。

建立或恢复项目

  1. 判断输入属于当前项目还是新的独立事项;归属不明时留在业务入口澄清。
  2. 使用当前 Etunel 绑定,不从文档示例、聊天或记忆猜测角色与会话信息。
  3. 调用 mcp__etunel__etunel_list_roles 读取实际角色,用 role 路由,用 display_name 表示角色名称,用 member_alias 识别当前实际负责人;不要求负责人核对内部 ID,也不重复询问负责人身份。
  4. 项目文件与进度留档 建立目录、成员清单、项目概览和初始进度。
  5. 从《项目概览》读取当前项目已经确认的特殊规则;只登记有权负责人明确确认的内容,并持续沿用到同一决定权人修改或取消,不在每项任务中重复询问。
  6. 在途项目继续使用已登记流程基线,除非取得明确迁移决定。
  7. 有权业务负责人发起的正式项目即使资料不齐也可接收,但缺口、责任和风险必须如实记录,不能把未知写成已确认。

启动阶段并明确完成约定

进入每个阶段时,Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”:本阶段必须完成、后续阶段处理、当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理,并放入承担当前必需项的主责角色在该阶段收到的首个任务;各角色只需在与本角色负责人正常对齐时确认或纠正自己的部分,不另发全员确认任务。涉及业务范围、客户承诺或组织授权时,再取得业务确认。

新问题只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定,或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时,才可成为本阶段阻塞。提出问题的角色必须说明对应的当前必需项和“为什么现在必须解决”;仅供后续使用的资料登记为后续依赖。

规划任务与波次

按本阶段完成约定和 项目生命周期 找出依赖已满足、当前确有必要的任务:

  1. 每项任务确定唯一主责角色、任务名称、协作角色、输入、产出和完成条件。
  2. 同一角色、同一输入基线、紧密相关且共同交付的工作可以合并为一个任务包。
  3. 能独立验收、独立失败或服务不同下游的工作保持独立任务,可以连续派发并由 Etunel 排队。
  4. 不同角色的依赖就绪任务可以组成同一波次分别派发;不要为了“让所有人知道”创建任务。
  5. 后继任务只在所依赖成果成为有效版本后激活;发送、排队或通知接受都不等于依赖完成。

mcp__etunel__etunel_send_to_role 每次只面向一个 role 和一条消息。多角色波次由多次定向调用组成,不存在广播调用。

一次说清任务

正式执行任务使用简明中文说明:

  • 要完成什么,为什么现在做;
  • 当前阶段、本阶段完成约定、必要背景、有效上游成果和版本;
  • 本次范围、不需要处理的内容、依赖、接口、限制和风险;
  • 要提交的具体文件或成果包及最低内容;
  • 证据、版本、下游用途、完成条件和期限;
  • 需要负责人判断或确认的事项;
  • 信息不足、额外产出和阻塞如何返回。

不要把 role ID、member ID、session ID、消息 ID 或机器状态放进人类任务正文。纯信息、澄清或授权请求不要求空文件,但要给足背景、问题、影响和需要的结论。详细写法见 人类可读沟通

期限优先继承已批准的《项目目标与里程碑计划》或《项目计划》。没有明确期限时集中询问负责人一次;不影响当前依赖时可写“待确认”并登记风险,影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。

Hub 中介的跨角色信息流

现阶段成员 Agent 之间不能直接通信。需要另一角色输入时:

  1. 来源角色先问自己的负责人,把仍缺内容合并后交 Hub;
  2. Hub 依次检查当前有效成果、《项目概览》中的已确认规则和项目已有资料,有答案就直接返回最少必要内容;
  3. 没有答案时,Hub 向信息所有者角色创建定向查询或任务,不广播;只有当前确实需要且联络边界已批准时,才由相应真人负责人联系外部;
  4. 目标角色完成专业自审和负责人确认后交 Hub;
  5. Hub 校验并登记,再把确认结论和成果引用返回来源角色;
  6. 跨角色讨论本身不是正式项目事实,只有经有权角色确认并登记的结论才能被下游依赖。

普通问题默认一组聚合问题和一组答复。出现新的实质问题才追加;复杂异常改走 异常与协调 的线下会议与《会议决定记录》。

派发、等待与入站处理

Etunel 任务消息流程 派发和结算:

  • 允许同一角色排队和不同角色独立推进;
  • 不为普通进度反复追问,不发送空确认;
  • 一个任务阻塞不自动取消同波次中不受影响的任务;
  • 多个结果在同一处理轮到达时,先统一更新依赖,再选择下一波次;
  • 每条成员入站消息都形成回复、后续任务或明确结算,不能因跨角色转发而遗漏来源处理。

如果成果已经满足下文的接受条件并完成归档,随后出现 Etunel 任务记录“已处理”“未找到”等运行时异常,不撤销成果、不要求成员重复制作或重复提交,也不倒退已经完成的阶段;Hub 只记录并说明运行时异常。文件尚未实际收到、无法访问或尚未校验时,不能用消息状态代替成果继续推进。本 Skill 不规定队列、重试或去重实现。

消息关联所需的 message_idcorrelation_id 只放在工具参数中,不要求负责人手工提供或复述。

校验、留档与下一步

Hub 检查:

  • 结果来自正确角色,并与任务、阶段和输入基线一致;
  • 指定成果存在,最低结构、版本、旧版替代关系和证据齐全;
  • 专业自审、负责人、确认时间、范围和条件明确;
  • 不适用项、未执行项、开放问题、依赖、剩余风险和专业结论清楚;
  • 模拟数据没有进入正式事实;
  • 与其他有效成果没有未处理冲突,且未越权。

只有实际收到并能访问成果、来源角色正确、成果与当前任务及输入基线一致,并且必要版本、证据、自审和负责人确认满足要求时,Hub 才能选择“接受”。选择后必须在同一处理轮完成文件归档、成果索引更新并明确说明接受结论;这些动作全部完成后,成果才成为当前有效版本。附件刚送达、成员说“已完成”或消息显示“已处理”都不能单独视为接受。

同一文件、版本、适用范围和附带条件已经有有效负责人确认时,Hub 直接沿用,不再要求重复确认。只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失,或出现与原结论冲突的新事实时,才重新确认。

校验后用中文明确选择:

  1. 接受:归档成果和版本,更新成果索引、项目进度、依赖和下一任务。
  2. 需要补充:只列具体缺口交回原角色,保留已经有效的部分。
  3. 阻塞、冲突或变更:进入相应异常流程。
  4. 额外成果:保留职责内有价值内容;若改变范围或基线,先取得批准。

任务包只有全部必需产出满足才整体完成。项目文件、进度和阶段记录按 项目文件与进度留档 更新。

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

项目状态与同步

Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时,每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》,不广播完整计划。规则见 角色与项目状态

人类负责人参与

Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下情况介入:

  • 真实节点跳转、暂缓、回退、流程迁移或带风险绕过;
  • 启用、变更或结束模拟模式;
  • 自定义角色需要在 Etunel 中手动添加、替换或移除;
  • 门禁争议、重大跨角色冲突或专业权责无法消解;
  • 重大进度、成本、质量、安全或交付风险;
  • 正式阻塞经现有负责人和线下协调仍无法解决。

真实人员、资源、预算、采购、范围、日期、暂停、取消或组织级风险接受由业务或项目发起人按权限授权。

阶段控制要点

  • 阶段 1 业务草案后,产品按需选择早期风险预审角色;Hub 不增删名单。
  • 阶段 2 由产品明确评审角色和具体问题;测试检查产品结果是否可判断,其他专业角色按实际影响参与,最后由产品收口。
  • 阶段 3 先由技术负责人形成方案与接口草案,再向适用设计角色形成波次,最后由技术负责人收口统一版本。
  • 阶段 4 Hub 基于已确认方案形成计划;技术负责人确认技术结构,只向有缺失或冲突的角色定向询问,业务授权真实资源和日期。
  • 阶段 5 应用层、底层和硬件按依赖推进;底层先交应用层合版,统一固件只由应用层输出。
  • 阶段 6 测试维护《缺陷分析报告》;底层修复也须经应用层重新合版后复验。
  • 变更、异常或缺陷只向实际受影响角色派发,不固定全角色参与。
  • 阶段 8 只要求实际参与、有正式成果、遗留风险或发布责任的角色提交结项摘要。
  • 正式项目满足全部适用成果、确认、验收、留档和遗留处置后才关闭;模拟项目只能以“模拟完成”结束。

钉钉进度

只有 Hub 可以发送项目进度。Hub 先完成成果和进度留档,再在项目开始、可验证里程碑、正式阻塞或 Etunel 中断、总体完成、总体最终失败时,按 钉钉项目进度汇报 调用封装脚本。钉钉不参与任务派发、批准、门禁或完成判定。

Hub 禁止事项

  • 不在业务基线未就绪时向所有角色派任务,也不要求无关角色查看完整计划;
  • 不把“一次调用一个接收方”误解为项目只能有一个在途任务;
  • 不按功能碎片频繁发送本可合并的任务或问题;
  • 不替角色或负责人形成、确认、关闭专业成果和缺陷;
  • 不把直接讨论写成 Etunel 能力,所有成员消息均经 Hub;
  • 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁;
  • 不自动添加自定义角色,不向未登记角色派发;
  • 不伪造通过、批准、日期、测试、发布或模拟结论。