Files
EP-Hub-Skill/etunel-role-collaboration/references/project-status-and-membership.md
T

5.7 KiB

角色与项目状态

Hub 创建项目、读取实际角色、添加自定义角色、处理角色变化、维护项目状态或发送状态快照时读取。

默认角色与自定义角色

默认语义角色为:业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试。默认角色不是封闭集合,但尚未在当前项目登记的角色不能接收任务。

自定义角色启用前必须有职责契约,至少说明:

  • 目标、存在理由、职责和明确不负责的内容;
  • 参与阶段、触发条件、上游输入和下游使用者;
  • 正式成果、专业决定权、确认权和不拥有的门禁权;
  • Etunel 路由用 role、人类可读 display_name 和允许的完成工具;
  • 加入、退出、替换、交接和未完成事项承接规则。

由 Hub 负责人或项目发起人提出,受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线,先走 变更申请,按既定权限取得确认或批准,不一律追加业务审批:授权内资源与排期由产品确认,预算、采购、对外承诺及项目级组织授权由业务批准,专业决定仍由相应角色确认。

职责契约确认后,必须由 Hub 真人负责人在 Etunel 中手动添加并完成绑定。Hub AI 可以准备契约、检查信息并调用当前允许的 Hub 工具,但不得宣称未执行的添加已经完成,也不向不存在的角色派发任务。

从 Etunel 读取实际角色

Hub 在项目开始和角色变化后调用 mcp__etunel__etunel_list_roles。返回事实以当前工具结果为准,例如:

{
  "role": "review",
  "display_name": "代码评审",
  "relationship": "approved_member"
}
  • role 是 Etunel 路由标识;
  • display_name 是任务、进度和目录中的人类可读称呼;
  • relationship 是工具返回的关系状态;
  • review 只是示例,不得硬编码;
  • 工具未返回的 member ID、session ID、人员姓名或负责人 ID 不得补造。

成员会话不调用这个 Hub 专用工具,也不向当前负责人重复确认运行时字段。项目成员清单的生成与留档见 项目文件与进度留档。

角色加入、退出与替换

新角色接收任务前,Hub 确认角色已出现在 etunel_list_roles 返回中,并交接:

  • 当前流程基线、阶段和门禁;
  • 未决任务、依赖、期限和阻塞;
  • 适用成果、当前版本、旧版替代关系和风险;
  • 允许决定的范围、当前负责人和协作路径。

角色退出或替换时保留历史任务、成果和确认记录。新负责人不得自动继承旧负责人的批准;继续使用旧成果时,需要明确重新确认文件、版本、范围和条件。角色变化后更新成员清单、项目进度和《角色分工》。

项目状态内部记录

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

  • 项目模式、流程基线、当前阶段、本阶段完成约定和门禁;
  • 当前项目已确认的特殊规则及其适用范围;
  • 任务、主责角色、协作角色、依赖、期限和下一步;
  • 当前角色列表、加入退出和交接状态;
  • 风险、阻塞、决定、变更和豁免;
  • 正式成果、适用性、版本、证据和旧版替代关系;
  • 下一可执行任务及恢复条件;
  • 项目资料目录、项目进度和成果索引的当前状态。

项目状态记录描述流程事实,不替代各阶段正式专业成果。

项目状态快照

角色现有上下文不足或可能过期时,可向 Hub 查询授权范围内的状态(S.1),说明关注阶段或任务、查询范围、所需详细度、期望时点和用途;无需知道内部存储结构。

收到查询,或阶段、门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的变化时(S.2),Hub 向请求角色及实际受影响角色发送裁剪后的《项目状态快照》:

  • 每个处理轮或波次合并一次,不为细小字段变化刷屏;
  • 只包含接收方需要采取行动或判断依赖的内容;
  • 用中文写明发生了什么、对本角色的影响、有效文件或版本、下一步、责任角色和期限;
  • 不广播完整计划、无关角色状态、私有对话或空确认;
  • 快照是同步视图,不替代任务、成果、负责人批准或门禁。

快照注明证据来源、版本与时点,不转发未确认专业判断。接收角色向 Hub 确认可继续执行,或提出需纠正的内容、正确值、原因、证据及本角色负责人确认(S.3);可随相关任务答复合并回传,不为收讫另建空任务。

状态纠正与基线变更

发现过程状态登记错误时,Hub 先检查版本、证据和跨角色一致性;无证据的异议不能直接覆盖状态,有争议按 异常与协调 处理。核对通过后(S.4)保留旧值、新值、原因、证据、纠正人、生效时间及受影响任务,更新内部记录并向全部受影响角色重新分发有效快照。单纯纠正事实可以更新记录;若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁,必须转入《变更申请》,不能用“状态纠正”规避变更。

新项目默认使用当前流程基线。在途项目继续使用已登记基线;只有明确决定迁移时,才记录阶段和成果映射、缺失项、风险、必要确认及旧版替代关系。