Files
EP-Hub-Skill/etunel-role-collaboration/references/project-status-and-membership.md
T
2026-09-02 11:44:52 +08:00

70 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 成员与项目状态
创建 WORK_ID、建立成员映射、添加或替换角色、维护 Project Status Record、纠正状态或向角色同步状态时读取。
## 默认角色与自定义角色
默认语义角色为:业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试。默认角色不是封闭集合,但尚未在当前项目登记的角色不能接收任务。
自定义角色启用前必须有角色契约,至少说明:
- 目标、存在理由、职责和 non-goals;
- 参与阶段、触发条件、上游输入和下游消费者;
- 正式成果、专业决定权、确认权和不拥有的门禁权;
- semantic role、实际 role ID、role member ID、session ID 和 human owner
- 加入、退出、替换、交接和未完成事项承接规则。
由 Hub 负责人或项目发起人提出,受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线,先走 Change Request 并取得业务批准。
角色契约确认后,必须由 Hub 真人负责人在 Etunel 中手动添加并完成实际绑定。Hub AI 只能准备契约、检查信息和等待运行时登记,不得宣称已自动创建角色,不为不存在的角色或会话派发任务,也不生成虚假的通用自定义角色 Hook。
## 身份与成员映射
- semantic role 表示业务、产品、测试等职责语义;实际 role ID 表示当前项目中的角色实例。
- role member ID 或 member ID 表示实际成员;session ID 表示绑定会话;human owner 表示该会话的真人负责人。
- 同一 Codex 账户在同一项目原则上只承担一个 semantic role。
- 同一角色可以有多个账户或会话,但每个 SUBTASK_ID 必须明确唯一主责角色和主责成员。
- Hub 只向主责成员及确有必要的协作成员提供任务切片,不向同角色所有会话广播。
创建 WORK_ID 时立即建立过程成员登记和会话映射。阶段 4 再把实际成员、职责、任务主责、协作和交接关系正式化为 Role Assignment。
## 加入、退出与替换
新成员接收任务前,先确认身份与角色,并交接:
- 当前流程基线、阶段和门禁;
- 未决任务、依赖、期限和阻塞;
- 适用成果、当前版本、supersedes 关系和风险;
- 允许决定的范围、human owner 和协作路径。
成员退出或替换时保留历史角色、任务、成果和确认记录。新成员不得自动继承旧成员的人类批准;需要继续使用时,由新负责人明确重新确认适用文件、版本、范围和条件。
## Project Status Record
Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记录;阶段 4 将其正式化为 Project Status Record,此后版本化维护。至少覆盖:
- 项目模式、流程基线、当前阶段和门禁;
- 任务、主责成员、协作角色、依赖、期限和下一步;
- 成员与会话映射、加入退出和交接状态;
- 风险、阻塞、决定、变更和豁免;
- 正式成果、生命周期、适用性、版本、证据和 supersedes
- 下一可执行任务及其恢复条件。
Project Status Record 记录流程事实,不替代各阶段正式专业成果。
## 裁剪状态快照
阶段/门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的关键变化时,Hub 向实际受影响的角色发送 Project Status Snapshot
- 每个处理轮或波次聚合一次,不为每个细小字段变化刷屏;
- 只包含接收方需要采取行动或判断依赖的状态切片;
- 写明当前有效版本、发生了什么、对本角色的影响、下一步、责任方和期限;
- 不广播完整计划、无关角色状态、私有对话或空 ACK;
- 快照是同步视图,不替代任务、成果、批准或门禁。
## 状态纠正与基线变更
发现过程状态登记错误时,保留旧值、新值、原因、证据、纠正人和生效时间。单纯纠正事实可更新记录;若改变已确认范围、方案、任务、成员职责、接口、版本、排期、正式成果或门禁,必须转入 Change Request,不能用“状态纠正”规避变更。
新 WORK_ID 默认使用当前流程基线。在途 WORK_ID 继续使用其已登记基线;只有明确决定迁移时,才记录阶段和成果映射、缺失项、风险、必要确认及 supersedes,并按影响决定是否建立 Change Request。