分配与责任

Asset

ADP-PLN-FEAT-DOC-0042

Feature

work-item-assignment-and-responsibility

领域

plane-core

作用域

application-level

文档状态

draft

产品生命周期

active

文档 Owner

DOC

事实源

canonical-docs

工程 Owner

PLN

Development Ready

not-ready

更新

2026/10/14

FEATURE DEVELOPMENT PACKAGE

工程就绪状态

工程 Owner：PLN · 仓库：PLN

BLOCKED

development · not ready

• ×原子需求与验收
• ×设计与工程合同
• ×代码与仓库定位
• ×里程碑与工作包
• ×验证计划
• ✓无阻断决策

verification · not ready

• ×Development Ready 已通过
• ×验收标准已覆盖
• ×正式测试已登记
• ×Fixture 与环境已定义
• ×测试规格已物化到正式测试

release · not ready

• ×Verification Ready 已通过
• ×实现修订可定位
• ×发布证据已登记
• ×兼容与迁移已定义
• ×Runbook 与回滚已定义

查看阻断项（5）

• Development Ready 缺少：原子需求与验收
• Development Ready 缺少：设计与工程合同
• Development Ready 缺少：代码与仓库定位
• Development Ready 缺少：里程碑与工作包
• Development Ready 缺少：验证计划

查看完整 readiness查看关联资产

功能目标

为 Work Item 表达一个或多个有效 human assignees，并把创建人、默认负责人、部门动态视图、阶段责任人与 Automation service identity 保持为不同、可解释的责任关系。

功能结论

主题	当前结论
用户	Project Admin/Member 当前可编辑 human assignees；Project Admin 配置 default assignee；部门 Dispatcher/Agent 选择属于独立目标合同。
入口	Work Item 详情“负责人”多选控件、inline edit；Project 设置中的 default assignee；部门视图和分析按 assignee 部门归集或快照消费，不在 Work Item 上新增负责部门入口。
可见结果	工作项显示零个、一个或多个 human assignees；无显式 assignee 时创建流程可使用有效 default assignee。
当前系统保证	当前 serializer 只保留同一 Project、active、role >= Member 的 assignee；关系通过 IssueAssignee 保存。
明确不做	assignee 不等于 created_by、阶段责任人、Department Lead、Producer approval、logical AI Agent 或 Automation service identity；旧 responsible_department 不再作为 active Work Item 责任关系。
权威 owner	本页拥有人类 assignee 与 responsibility partition；部门视图和分析由各自页面拥有，Automation service identity 由 Automation 合同拥有。

当前落地状态、已批准合同与差距

• 当前落地状态：Plane Issue 支持多 assignee；Work Item 详情使用 Project member 多选。创建时未传有效 assignee，Project default assignee 有效则自动建立 IssueAssignee。
• 已批准合同：Work Item 的 active 责任关系以 human assignees 为核心；部门视图从 assignee 的当前主部门派生。Plane 不把 Automation service identity 当作 human assignee 或 executor selector；human assignment 变化不能启动、重试、取消、重开或改变 Symphony 执行。
• 当前差距：当前 serializer 通过 queryset 过滤无效 assignee id，可能静默丢弃 Guest/inactive/跨 Project candidate；目标错误合同尚未批准。
• 当前差距：human-only 选择器应过滤 active AI/bot accounts，但当前 Issue serializer 的 assignee 过滤未见 bot identity 条件，需要 implementation/TEST 补证。
• 当前差距：旧负责部门 active surface 需要按 clean-break 清理；assignee at-risk、部门工作项解释、当前阶段责任和分析事实由部门子页补齐，不应写成当前已落地 UI。
• 后续交付：先固定 human assignee 候选与错误语义，再让部门工作项、分析按 assignee 与有效阶段责任的当前部门或事件快照消费，最后验证 human identity 与 Automation service identity 的职责分区。

责任关系分区

关系	基数	当前/目标	Owner
created_by	1	当前只读审计 actor	属性
human assignees	0..N	当前已落地	本页
Project default assignee	0..1	当前创建默认值	项目管理，本页消费
assignee department view	0..N；由当前 human assignees 主部门派生	planned dynamic view	部门工作项路由
analytics department snapshot	0..N；业务事件发生时冻结 assignee 主部门	planned metric fact	部门分析
legacy responsible_department	historical only；不作为 active input/output/fallback	clean-break	部门工作项路由
Producer/reviewer/approver	按 workflow	独立人类决策轴	审核与审批 pages
delivery stage responsibility	按业务环节保留实际人类责任	所有保留类型按原生状态解析当前责任；保留人类决定	Issue 阶段责任流

任何 UI 都必须用不同标签和区域展示这些关系，不能用同一个“负责人”头像推断全部责任。

Human assignee 候选与流程

1. 用户打开 assignee 多选，候选应来自同一 Project 的 active Project membership。
2. 当前 serializer 要求 role >= Member，因此 Guest 不进入 human assignee 结果；目标合同还应排除 active bot/AI identity。
3. 用户提交完整 assignee id list；服务端复验 Project、active status、role 与 identity type。
4. 创建时，如果显式列表为空或无有效值，当前实现可能应用 Project default assignee；显式“清空”与“未提供字段”需要产品级区分。
5. 更新关系时保留 activity/audit；成员随后失效或调岗不应改写历史，当前 assignment 应显示 invalid/at-risk 并进入显式处理。
6. 部门工作项视图只能从 active Project membership 范围内的 human assignees 派生部门命中，但不能因此创建 access 或修改 human history。

数据、API 与一致性

human assignment 使用 Issue 与 User 的多对多 IssueAssignee 关系，带 Project/Workspace 与审计字段。目标稳定合同至少要求：

• candidate API 和 mutation 使用同一 eligibility policy revision；
• assignee id 去重，跨 Workspace/Project、inactive、Guest、bot 返回逐项 rejected reason；
• omission、empty list 和 null 的含义明确，避免意外应用 default 或清空；
• 更新使用 Work Item revision 或等价条件写；
• member removal、role downgrade、department transfer 与 access revoke 产生可解释 risk，不静默换人；
• bulk assignment 返回逐项结果与同一 policy/version，不把部分成功误报为全成功。

跨层依赖

• 成员与访问提供 active Project membership eligibility，不由 assignment 创建权限。
• 部门工作项路由拥有 assignee 主部门动态归集、部门工作项解释字段、空态与 at-risk。
• Automation service identity 和 executor 不属于 human assignee 候选；人类 assignee 不由 Automation 或 service identity 写入。
• Issue 阶段责任流定义 非 Epic 业务环节的人类 responsibility；Task 的人工开始沿用当前负责人默认规则，自动化开关开启即委托 Symphony；责任与执行身份分开，阶段推进不得改写 IssueAssignee。

异常与停止条件

• 跨租户、inactive/non-member、Guest、bot human candidate 或权限不足时 fail closed，并返回候选级原因。
• Project 无有效候选时保持 unassigned/blocked，不自动授予访问或选择无权限用户。
• Project membership 失效或调岗造成资格变化时不静默重分；标记风险并要求显式 handoff。
• 执行中改变 human assignee 不启动、重试或取消会话，也不重开工作项。关闭委托撤销后续执行，Issue 取消由保留的人类业务动作完成；Symphony 按当前委托和原生状态收敛。

验证与权威来源

• Web assignee 控件：apps/web/core/components/issues/issue-detail/sidebar.tsx
• Issue serializer：apps/api/plane/app/serializers/issue.py
• Issue/assignment model：apps/api/plane/db/models/issue.py
• Project membership model/API：apps/api/plane/db/models/project.py、apps/api/plane/app/views/project/member.py
• 前端权限：apps/web/core/components/issues/issue-detail/root.tsx

真实验收需覆盖零/一/多 assignee、default、显式清空、Guest/inactive/bot、并发、成员失效、部门动态视图/快照消费，以及 Automation service identity 不进入 human assignment 或触发 execution。

待决策问题

1. 创建请求未提供 assignee_ids 与显式空列表，是否都应用 Project default assignee？
2. 无效候选是整体拒绝还是逐项拒绝；UI 如何展示 rejected reason？
3. 成员失效后是保留并标 at-risk，还是移除当前 assignment 但保留独立历史？

部门相关与承担关系

部门工作项另按创建/订阅展示相关事项；承担事项只按 assignee 与当前有效 human 阶段责任去重。阶段责任不要求同时为 assignee；部门归属不授予项目访问或验收权限。部门审批已退役，原生状态与专业/测试验收继续生效。