# 成员与项目状态

创建 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。