Agent-System-Documents/docs/proposals/2026-10-13-identity-role-permission-plan.md

title, date, type, execution, artifact_contract, product_contract_source

title	date	type	execution	artifact_contract	product_contract_source
用户、职位角色与分层权限统一设计及实施计划 r1	2026-10-13	refactor	code	ce-unified-plan/v1	legacy-requirements

用户、职位角色与分层权限统一设计及实施计划 r1

负责人：weichen；编制：Codex；更新时间：2026-10-13（北京时间）。 确认状态：本轮两项用户裁定已确认；完整需求表、架构调整、迁移与实施计划待人工评审。 推进状态：源码调研与方案编制；业务修改、业务测试、数据库迁移、部署及运行验收均为 NOT_RUN。 本文是本次改造的唯一方案主记录；任务卡与索引引用本文，不复制推进状态。

Goal Capsule

让管理员按企业职位管理人员与能力，让创建者在自己的项目管理成员和文档责任，并让用户清楚知道自己能操作什么、为什么可以或不可以。 复用现有账号、职位角色、项目成员、权限解释与整文审签能力，修正作用域混用，再补齐资料、搜索、单对象配置与批量矩阵。 本轮交付终点为完整方案及分阶段计划，业务实施与运行操作需取得对应阶段授权。

用户已明确选择：系统管理员管理账号、角色与权限上限，访问他人项目业务内容需要明确授权；首期支持一人多职，每个项目明确选用该用户的哪些职位角色。 这两项决定来自本轮对话，完整方案仍为待评审草案。

---

Product Contract

Problem Frame

当前存在四种概念：系统账号、企业职位、项目管理关系、文档编制／审核／批准职责。 它们在部分命名、管理入口和授权函数中混用，导致项目设置权限能够进入全局管理、管理员自动获得业务访问、角色停用或换岗后权限不一致。 改造的重点是统一权限语义和执行端判定，同时把配置权、作用域和具体资源责任说清楚。

“系统权限、角色权限、项目权限”是同一套权限模型的不同配置来源与作用范围。 角色是能力模板，系统权限是系统范围的动作，项目权限是限定到一个项目的授权。 文档三权进一步确定谁对某个版本履行哪项职责。

Sources and Current Evidence

权威顺序采用 RDM docs/requirements/README.md：最新用户指示 → 当前 U0/Q 裁定与权威需求正文 → 当前矩阵 → 未被取代的旧设计 → 原始会议。 .tmp 原件作为设计来源保留，不回写历史原稿。 本轮优先阅读 .tmp/Discussion-Meetings/2026-10-08_12-24/Outputs/11-角色与权限管理方案.md，并与 01／03／08 系列、RDM 当前需求和后续计划交叉核对。

对象	本轮读取的固定版本	证据边界
Dev 源码基线	3fb8210f6495a78e70a67af3661bdfe9c00fb9de	本地源码与启动检查，SELF
Dev Backend	dc736e339d01c59e658abc63c81909059bd6ea02	本地源码，SELF
Dev Frontend	dcd2699933eff51c06193cac7beb15c3d20a01ff	本地源码，SELF
Documents / UI	05c13a42b14d70f878cc8a51c543e018a7f7a663 / 0da2e3acd6c8ae8957825b64ddb54b250c0979c0	文档与设计约束
RDM	255f9cba0c9e6f981fbff66142be92532d5c5f2d	本地源码，SELF

RDM 自己的 Backend／Frontend pins 与 Dev 组合不同，不能把某一工作树的能力视为另一组合已部署的能力。 命令、对象与脱敏输出由任务卡的 evidence 收据保存；本稿的源码事实不等于部署重现、GATE 通过或正式验收。

已核实的源码情况	对方案的影响	源码位置，路径以所列仓为根
已有独立职位角色、多账号可绑定同一角色；账号当前只能绑定一个角色	扩展已有模型，支持多职、描述和编辑	RDM internal/perms/roles.go
用户资料没有电话、邮箱、工号等；公开目录仅 owner＋valid	账号资料和受控目录必须有 Backend 公开契约	Backend internal/store/auth.go、pkg/extension/extension.go、internal/app/hostcaps.go
角色／全局上限／管理员移交复用 project.settings	首批拆开系统动作与项目动作	RDM internal/rdmapp/perms_api.go 中 AuthorizeGlobal、roleAdminGate
域管理员和基座超管在多处自动读取项目、审计、导出、原件或草稿	同步修订所有业务读面，取消身份式业务放行	RDM perms_api.go、runtime.go、upload.go、draftproposal.go
owner 跳过职位上限；角色停用回落内置 member；换岗后遗留 override 可跳过未配置动作的角色上限	采用完整授权链，覆盖创建者、停用与换岗负例	RDM perms_api.go 中 evalPerm、internal/perms/roles.go
“权限矩阵”是单成员有效权限解释；角色页每次编辑一个动作	保留解释能力，补可编辑角色矩阵与成员矩阵	Frontend src/components/adminRdmSections.tsx
用户、角色、三权候选主要手输 owner／docId；入口依赖 isAdmin	接受服务端能力与目录查询结果，使用稳定 ID 选择	Frontend adminSections.tsx、adminRdmSections.tsx、AdminZone.tsx
基座建项接口与 RDM 建项命令的门禁不同	统一产品入口；区分宿主项目与研发项目后封闭旁路	Backend internal/server/server.go；RDM plugins/rdm/plugin.go

Requirements

需求编号仅用于本方案，不替换原有 UR／SR 编号。

身份、职位与人员查找

ID	需求与可判定验收条件	来源
R1	角色是独立职位对象，有稳定 ID、名称、可选描述、状态和版本；改名不改变人员身份或历史	本轮用户；SR-G7
R2	同一职位可关联多人；一人可关联多个职位；项目只采用明确选定的有效绑定，新增职位不自动扩张既有项目	本轮用户裁定；当前概念模型
R3	姓名、电话、邮箱、工号、部门与备注均可选；全部留空仍能建号；资料不成为登录凭证或授权主键	本轮用户
R4	支持精确与模糊搜索、字段选择、状态／职位等过滤、分页与同名辨识；最终授权对象是稳定用户 ID	本轮用户
R5	系统管理者可维护账号资料；本人可编辑非授权资料；项目选人只获得必要目录投影，无权读取完整联系方式或凭证	本轮用户；隐私边界

系统与项目授权

ID	需求与可判定验收条件	来源
R6	系统设置、用户管理、角色管理、策略管理与建项采用明确系统动作；项目权限编辑不能写入系统动作	SR-G6/G7/G8；本轮用户
R7	系统管理员无项目／资源授权时不能读取他人业务正文、原件、草稿、业务审计、导出、搜索命中或模型上下文	本轮管理员裁定；修订旧跨项目审计口径
R8	A 创建者不能凭 A 的管理权管理 B；创建事实固定，负责人接替采用明确委任记录	SR-G9/G10
R9	创建者在本项目管理成员、覆盖权限与分配三权；项目覆盖可覆盖角色默认，但不能突破平台和角色上限	SR-G8/G9
R10	多角色按完整授权路径合成；平台禁止、项目明确拒绝与资源限制不能被另一角色绕过	本轮多职裁定；SR-G2/G8
R11	角色停用、解绑、换岗、上限收紧、账号停用和成员移除及时撤权；遗留覆盖不能复活旧权	当前源码缺口；SR-G8/N4
R12	同一动作的 UI、HTTP、命令、工具、任务恢复与最终提交遵循同一服务端判定；未知或失败状态拒绝	SR-G2；U0 D1

配置体验与文档职责

ID	需求与可判定验收条件	来源
R13	单角色编辑与角色×权限矩阵是同一数据的两种视图，支持分组、精确／模糊搜索、过滤与批量草稿	本轮用户
R14	单成员编辑与成员×权限矩阵共享草稿；显示继承／授予／拒绝、角色默认、上限、最终结果与原因	本轮用户；SR-G8
R15	批量保存有具体差异、影响预览、版本冲突保护、原子提交和审计；隐藏行不丢草稿，不逐格即时落库	配置完整性与当前缺口
R16	每份受控文档编制一人、批准一人、审核至少一人，三类人员互异；候选必须是有效成员并具备对应能力上限	SR-C7/G9
R17	职位能力只提供资格；实际编写、审核、批准同时检查具体职责、文档状态与冻结版本；管理权不代签	SR-C7/C8；U0 D2/D5
R18	私聊、私人原件与个人草稿保持私有；项目知识由明确提交／发布产生；受控文档按职责或明确授权读取	SR-G11/G12；U0 D3
R19	权限变化同步影响已开页面、旧卡、Surface、下载、检索、SSE 和后台任务；迟到事件不能恢复权限	SR-G2/G11/N4；根 AGENTS.md
R20	保留用户／项目／角色稳定标识与历史；迁移输出旧→新差异，不把旧管理员全权转成永久业务授权	持久化与兼容要求

Confirmed Decisions and Scope

管理员业务访问边界已经用户选择确认（session-settled: user-directed — chosen over 管理员自动获得全部项目业务访问: 业务访问需要明确授权；Governs R7）。 首期多职及项目明确选用已经用户更正确认（session-settled: user-directed — chosen over 每人仅一个生效职位: 用户改为采用多职建议；Governs R2/R10）。

本次覆盖用户资料、职位模型、系统／项目授权、配置界面、文档职责与读取授权、Agent 同源执行、迁移及验收。 飞书／SSO、组织树与岗位继承、全自动任命／签字、全量模板补齐、整个工作流引擎重建和外部权限服务采购不纳入本次。 本次修订需要更新 RDM 权威需求与相关方案，但 .tmp 历史稿保留。

---

Planning Contract

KTD1. 数据职责与统一入口

建议把通用账号资料、职位定义、用户—职位绑定、系统动作授权及平台／角色上限集中到 Backend 的通用身份与授权服务。 RDM 负责项目成员、项目选用角色、项目覆盖、资源归属、阶段状态和文档三权，注册领域动作及资源策略；UI 和 Agent 消费同一公开服务。 用户主身份沿用基座稳定 ID 与现有 owner 映射，不另建账号；RDM 历史 owner 标识保留。

这是对现行“专业角色主表在 RDM”的明确架构调整建议，须在方案阶段评审，不能借旧 U0 D1 当作已经批准。 集中通用职位定义可以让账号管理、建项与项目业务共同消费一份授权事实，并避免两个角色台账同步漂移。 RDM 专有的职责与状态规则仍留在 RDM，基座只知道注册动作、约束及判定协议。 下游通过正式公开扩展及固定版本消费，禁止修改 pins 源码或导入 Backend internal。

主要备选：保留 RDM 角色主表并让基座经公开策略提供者查询。 该路径减少角色数据搬迁，但系统管理动作会依赖领域插件及其可用性；若采用，必须冻结单一权威、插件缺失时拒绝策略和根管理恢复通道，不能再建第二套独立职位表。 不推荐仅补 UI：它不能解决已经存在的服务端 scope 混用。

KTD2. 概念模型

对象	核心字段／关系	权威
User / Profile	稳定 userId、owner 映射、账号有效态；可选姓名、电话、邮箱、工号、部门、备注；profileVersion	Backend
Role	roleId、名称、描述、状态、roleVersion、创建／变更主体	Backend，拟迁移现有 RDM 角色
UserRoleBinding	bindingId、userId、roleId、有效态、任命主体／时间、版本；支持多对多	Backend
PermissionDescriptor	稳定 actionId、中文名、说明、scope、资源类型、分组、条件、委派级别、风险与版本	Backend 注册表，RDM 注册领域项
RolePermission	roleId＋actionId、默认 grant、cap、允许的资源范围；default 范围不得超 cap	Backend
SystemGrant	明确系统动作授予与上限；受保护管理员／策略管理授权独立记录	Backend
Project / Membership	稳定 projectId、固定 createdBy、当前负责人委任；成员身份、明确选用的 bindingId、版本	RDM
ProjectOverride	项目＋成员＋动作的 inherit／allow／deny，以及资源范围收缩、版本	RDM
ResourceGrant	资源稳定 ID、类型、真实属主、项目、分类、明确接收者／职责、只读范围、撤销版本	资源 owner；统一公开判定
DocumentDuty / Round	文档职责、冻结正文／职责／策略版本、轮次与真实操作者	RDM

这些是逻辑模型，具体表名与迁移编号在实施时确定。 删除有引用的用户和角色采用停用／归档，保留审计身份；无引用对象才允许物理删除。 同名职位的规范化重复检查独立于显示名；同名人员允许存在，工号与联系方式不作为强制唯一标识。 可选资料做长度与格式校验，空值合法；电话仅按明确规则规范化，避免错误匹配。

KTD3. 权限目录与系统权限

权限目录的 scope 由受信注册表确定，不能凭动作字符串前缀或请求体自报作用域。 旧 actionId 通过版本化映射兼容，作用域冲突的旧项不继续接受写入。

权限类别	动作示例	谁能配置／怎样生效
系统设置	system.settings.read／write，model／plugin／agent 设置子项	具备对应系统管理权者；平台策略限制
用户管理	system.users.view／create／edit／disable；credential.recover 单列	分项授权；普通资料编辑不允许改管理员资格
职位管理	system.roles.manage／assign	管理职位与普通任命；不能越可委派上限
高权限管理	system.policy.manage／privileges.manage；admin.transfer	受保护动作；项目覆盖和普通职位任命不可间接获得
创建项目	project.create，scope=system	有效系统／职位 grant；选定产品与创建者角色上下文
项目管理	project.settings、member.manage、permission.manage、duty.assign、stage.advance／archive	具体项目创建者或明确委任；受 cap 与状态约束
项目内容	knowledge.read／publish、trace.read／edit、business-audit.read／export	项目关系、角色范围和资源关系同时满足
文档动作	document.read／export、author／review／approve 等资格项	能力资格＋具体文档职责／授权＋状态

管理员徽标由受保护系统授权产生，职位名称叫“管理员”不会改变其权限。 首期保留至少一个有效策略管理者与安全恢复通道；并发撤销最后管理者必须在事务中拒绝。 普通角色管理者不能编辑受保护权限，也不能给自己或别人任命超出其可委派范围的角色。 系统管理员不自动加入项目，不自动获得业务统计或业务审计。 系统安全日志仅披露必要的账号、安全动作、结果与不透明对象标识，不含业务正文、文件名、项目名称、内容摘要或完整历史差异。 访问业务审计采用对应项目的明确授权，与正文授权分别显示。

KTD4. 单一权限判定与多角色合成

输入由认证会话、受信资源存储和实际执行上下文组成：主体、动作、资源类型／ID、真实项目／属主、当前版本与当前状态。 请求体里的 actor、owner、projectId 不能替代受信归属；资源与项目不一致时拒绝。 服务端返回 allow／deny、来源链、拒绝原因及 authorityEpoch，UI 不重新计算权限。 解释接口只能解释调用者自己或其有权管理的对象，不能成为探测他人资料的旁路。

系统动作只读系统授权来源，不接受 ProjectOverride。 其有效值为当前有效账号、平台允许范围、对应受保护规则，以及明确 SystemGrant 或一条完整的系统职位默认授权路径；不依赖项目所选职位，也不接受项目 allow 作为系统授权来源。 项目动作先确认成员／创建者／明确委任与资源归属，再对每个有效且本项目选用的职位绑定建立完整候选路径：

角色动作已定义且启用 ∩ 角色 cap（含范围） ∩ 平台 cap ∩ 项目 grant/默认 ∩ 资源关系 ∩ 阶段/状态 ∩ 文档职责。

对具体动作，至少一条完整路径通过才允许。 一个角色的动作授权不能与另一个角色的资源范围拼接；角色 cap=false 只关闭该角色的路径，平台禁止、项目明确 deny 和资源禁止对全部路径生效。 项目 override=allow 仅替换默认 grant，不能创造不存在的动作、突破任一 cap 或跳过资源关系。 override=deny 阻断该成员在该项目对此动作的全部角色路径；inherit 使用当前有效默认。 多个角色可共同授予不同动作，但一次动作必须有完整证据来源。

加入项目时明确选择该用户的有效 bindingId；只有一个有效角色可预选，多角色需明确选择。 新任命角色不自动加入已有项目；解绑后旧 binding 立即无效，重新任命产生新 binding，旧项目配置不自动复活。 停用角色没有回落授予；无有效角色仅保留显式最小账号自助能力，业务动作拒绝并说明缺少资格。 新增权限默认拒绝；读取策略失败、缺元数据、未知动作或必需提供者缺失时拒绝。

创建者关系提供本项目管理默认，仍经过其有效角色 cap 和平台 cap，不能自动读私域或代签。 建项前检查创建者角色组合具备本项目设置、成员管理与三权分配的 cap 资格，避免建成无法管理的项目；role default 可关闭这些动作，由创建者关系提供项目内默认。 已有项目遇 cap 收紧时保留归属，阻断受影响动作，并向授权管理者显示需要调整任命的原因。 为避免唯一负责人换岗后无法重新选用职位，提供受限的“重新选择本人项目职位”动作：仅当前有效负责人本人，可从其账号当前有效任命中显式选择具备平台和项目管理 cap 资格的 binding，并按当前项目版本确认保存。 仅该动作可使用尚未被项目选用的当前任命；普通项目动作仍只使用项目已选用的 binding。 它只修复本人在本项目的角色选择，不改变项目负责人、不恢复旧 allow 覆盖、不清除明确 deny，也不授予资源读取或三权；完成后普通动作重新经过完整判定。 角色任命者只能处理系统任命，不能代选项目职位；没有合格任命时项目保持等待，不能扩大 cap 恢复。 项目内移除／降权最后负责人时保护实际可操作的管理资格，而不仅计数 owner 关系；系统 cap 收紧造成的暂停则明确记录与提示，不能阻止管理员执行必要撤权。 创建项目、创建者成员关系与所选 binding 在同一领域事务落地；宿主绑定采用可恢复状态与幂等对账，失败不能留下可使用的无负责人项目。

判定、解释与所有入口共同调用该服务。 设计采用最小权限、默认拒绝和每次请求重验，也结合项目关系与资源状态；依据 OWASP Authorization Cheat Sheet。

High-Level Technical Design

flowchart TB
  U[用户及多个职位绑定] --> I[基座身份与通用授权服务]
  C[系统动作与权限目录] --> I
  R[角色默认与角色上限] --> I
  P[项目成员 所选绑定 项目覆盖] --> D[统一判定]
  I --> D
  A[资源归属 明确分享 文档职责] --> D
  S[阶段 文档状态 当前版本] --> D
  D --> E[HTTP 命令 工具 任务提交与读取]
  D --> X[有效权限解释与矩阵]

flowchart TB
  Q[受信主体与资源定位] --> A{账号 动作与归属有效}
  A -->|否| N[拒绝并给出可披露原因]
  A -->|是| B{系统动作}
  B -->|是| C[系统来源与受保护权限检查]
  B -->|否| D[项目资格与硬限制检查]
  D --> E[逐角色建立完整路径]
  E --> F[资源 职责 状态 版本检查]
  C --> G{当前授权通过}
  F --> G
  G -->|否| N
  G -->|是| H[允许 在提交或输出边界再检查]

KTD5. 文档三权与读取范围

复用现有整文审签，不建立另一套审批引擎。 项目创建者通过统一服务选择有效项目成员，系统验证职位资格与文档三权异人要求，再记录真实分配者和受指派人员。 审核人可多人，全部指定审核人通过后才允许批准；审核／批准只能批注和通过／驳回，不能修改正文。 审核与批准人员因实际职责可读提交审阅的正文和明确关联材料；这不开放私人对话、未分享原件或私人草稿。 共享授权只增加规定资源的读取能力，不转为编写或签字资格。

审签轮次冻结正文版本、职责版本与政策版本；人员停用、解绑、移除或权限收紧后，待处理轮次进入明确等待／失效状态，重新指派及提交。 历史已完成的签字和操作者身份保留，不因换岗改写；历史内容读取仍使用当前授权。 批准后修改采用既定撤回重审＋影响提示；职责替换不能清洗同一版本实际编制者的记录。 未分配三权的文档显示等待分配，并阻断受控编写／提交，不回落为全成员可写。

stateDiagram-v2
  [*] --> WaitingDuty
  WaitingDuty --> Drafting: 指派有效三权
  Drafting --> Reviewing: 编制人提交固定整文版本
  Reviewing --> Drafting: 驳回或撤回
  Reviewing --> Approving: 全部指定审核通过
  Approving --> Drafting: 驳回或撤回
  Approving --> Approved: 指定批准人签字
  Approved --> Drafting: 撤回并开启新版本
  Reviewing --> WaitingDuty: 职责或必要资格失效
  Approving --> WaitingDuty: 职责或必要资格失效

KTD6. 查找与配置界面

沿用系统管理区、项目设置和文档入口，遵守 Dev DESIGN.md，不新增无用途的权限仪表盘。

1. 系统管理 → 用户：可搜索列表、职位／状态过滤、用户详情；详情显示可选资料、职位绑定、系统能力及来源。创建账号不要求填写人员资料。
2. 系统管理 → 角色与权限：角色列表＋名称／描述／状态／绑定人数；选中角色后编辑默认与上限，也可切角色×权限矩阵。系统级受保护项按操作者资格显示。
3. 项目设置 → 成员与权限：选人、选择项目生效职位、项目覆盖；单成员视图与成员×权限矩阵共用草稿，显示最终解释。
4. 文档现有入口 → 三权：文档×编制／审核／批准矩阵与单文档选择器；候选范围、资格不足、多人审核及冻结状态直接说明。

精确搜索按选定字段规范化后完全匹配，稳定 ID／登录名优先；模糊搜索首期采用包含匹配和明确的前缀排序，不默认增加拼音／向量／模型识人。 搜索资料范围遵循目录权限；被禁字段既不返回，也不参与未经授权的匹配，防止通过命中数量探测联系方式。 过滤包括权限 scope、分组、默认／上限／最终允许、继承／覆盖、职位与账号状态、当前修改；精确／模糊与过滤可以组合。 共享“职位”不代表可查看所有同职位人员的私密资料。 同名候选显示姓名（如有）、登录名、职位与工号的授权投影；人名不清楚时必须选择具体对象，模糊匹配不能直接完成任命。

矩阵不是一张无限扩展的大表：按分组及分页显示，固定对象标签，提供单元格说明和键盘导航。 单角色视图的 default 与 cap 两列，成员视图的 inherit／allow／deny，与最终“允许／拒绝”的只读结果有明确区分。 过滤隐藏项不清空草稿；“全选”只选当前明确列出的结果，服务端提交固定 ID 清单与选择数量，不能把模糊查询直接当成授权范围。

KTD7. 批量变更、撤权与 Agent

所有配置走“草稿 → 差异及影响预览 → 提交确认 → 服务端重验 → 原子写入与审计回执”。 预览绑定操作者、对象 ID、策略版本及 patch 摘要；它不能作为跳过提交授权的凭证。 一批多个角色／成员的修改采用 expectedVersion／authorityEpoch 与事务，任一非法对象、越上限或冲突均不部分提交。 跨 Backend 与 RDM 的一项业务变更不伪装成单库原子事务；按明确 owner 分开提交，显示实际状态和可恢复步骤。 超时结果标为未知，以幂等键查询事务回执，避免重复授权或错误声称失败。

权限 epoch 的权威落在存储和服务端判定；进程通知用于使缓存尽快失效，通知丢失不能继续使用旧授权。 HTTP／检索／下载在输出边界检查当前权限；任务入队、恢复、使用资源和最终提交分别检查；持续流在新输出前重验并在撤权后终止受影响订阅。 已经交付到客户端或既有模型上下文的内容无法追回，撤权会清除应用缓存并阻断后续读取、工具执行和结果披露；对含已撤数据的模型运行终止并重新构造上下文。

UI、对话、Agent 工具共用权限目录查询、候选选择、解释、预览与提交 primitives。 沿用公开命令总线，但明确声明工具投影和风险级别；管理写入经宿主的人类确认，模型不能确认自己的授权提案或签署三权。 管理区发起的确认使用现有确认卡／弹层能力，并提供可发现的返回路径；不能只报“请到对话确认”而丢掉当前草稿。 异步状态只由一个 store 管理，按 actor＋project＋对象版本＋request generation＋seq 丢弃过期响应，失败时清空对应旧能力。

sequenceDiagram
  participant H as 人类管理者
  participant UI as 单对象或矩阵视图
  participant API as 公开授权服务
  participant DB as 权威存储
  H->>UI: 选择固定对象并修改草稿
  UI->>API: 请求差异和影响预览
  API->>DB: 读取当前版本与授权
  API-->>UI: 返回具体变更和拒绝原因
  H->>UI: 确认变更
  UI->>API: patch 版本 幂等键
  API->>DB: 重验并事务写入与审计
  API-->>UI: 完成 冲突 拒绝或未知结果

Compatibility and Migration

迁移必须保持账号 owner／userId、roleId、projectId、createdBy、资源标识及历史签字身份。 既有单角色绑定导入一个有效 binding；项目只选用该绑定，不自动加入新增角色。 旧 profile 字段映射到可选资料；未知资料留空，不推断人员姓名或联系方式。 现有两套管理员身份仅映射为明确的系统动作来源，不生成全项目业务 grant；旧 owner 的正文默认、停用回落与遗留越 cap 覆盖列为权限收缩差异。

角色权威迁移采用版本化清单与冻结写窗口：导出带来源版本及摘要的角色／绑定／cap，导入 Backend 后核对数量、稳定 ID、逐项范围和所有引用，再切换消费者。 禁止双主写入；过渡 RDM 旧管理命令转发新权威服务或明确只读，旧表只保留可核对历史。 冻结期间不能取得一致快照时停止迁移，不做无事务的跨库复制。

先在隔离副本执行迁移与双评估，输出用户×项目×动作的旧→新差异；双评估只用于记录，新算法上线时只有一个执行权威。 扩权项必须有明确新授权；收缩项逐项列出原因和处理人，不能为消除差异恢复旧越权。 生产迁移前完成备份及恢复演练、固定程序／配置／数据身份，按发布和迁移授权切换。 回滚不得重新启用身份式业务全权或复活撤销记录；不能满足这一条件时进入维护／拒绝状态，先修复迁移或程序。 账号恢复需修订既有账户方案的信任与交付合同，防止管理员拿一次性 Key 设密后接管业务身份；一次性本身不满足 R7。 普通管理员仅发起恢复提案，账号本人须使用管理员不能单方改写或取得的既有有效会话确认或预先建立的本人恢复证明，才能取得可兑换设密能力。 可选姓名、电话、邮箱和工号只是人员资料，不自动成为恢复证明；新证明的建立或更换不能由发起恢复的管理员单独完成。 若没有独立本人验证条件，线上恢复拒绝，不向普通管理员交付可兑换的目标账户 Key；异常人工恢复采用另行批准的 owner 操作，不纳入普通角色管理权限。 U1 冻结证明与交付合同，U3 消费已批准能力并验证该负例；既有恢复命令未收口前不能宣称 R7 完成。

Dependencies and Existing Work

本方案衔接 RDM 功能与实现整改方案、RDM 完整交付方案、两树一网追溯审计方案 与 账户和登录 Key 方案。 本轮管理员决定将修订前述审计方案的跨全部项目业务审计放行口径，以及权威 SR-G6 的“所有权限”表述；旧批准记录保留，新候选条款须按本方案评审和切换。 账户方案中恢复 Key 可交付给签发者的既有口径同样需要按 R7 修订；对已有业务账号不能只保留短时设密限制。 多职选择将修订 10-12 方案的首版单角色建议。 U0 D2/D3/D5 的管理不代签、私域与冻结整文规则继续作为约束。

现有 feature/admin-notes-repair 涉及管理样式与角色勾选同步；其他 RDM 工作区有审计／导出／pins 相关任务。 这些仅依据本地任务记录和分支阅读，不代表本轮已经核验远端 PR 或 CI。 实施启动时查询最新权威 base/head、实际公开契约、已合入内容和在途负责范围，复用有效改动，避免平行修改同一管理页面与审签引擎。 基座公开扩展的实现、兼容验证及固定版本消费是 U4/U5 的依赖；发布版本仍由用户按高后果双钥匙执行。

---

Implementation Units

以下均为待批准工作项；U 编号带本方案名称使用，避免与其他方案的 U 编号混淆。 文件范围以指定仓根目录为基准；标“新增”的文件为规划位置，实施可按项目模块规范调整。

U1. 冻结需求、权限目录与公开扩展合同

目标：将本轮两项裁定和 R1–R20 落到权威需求、动作 scope、通用服务／领域规则边界及公开提供者／消费者合同。 依赖：人工确认本方案需求与 KTD1；负责人为产品负责人和基座／RDM 模块 owner。 文件：RDM docs/requirements/01-用户需求与系统需求.md、03-产品设计方案.md、08-核心数据模型-两树一网.md；Documents 相关方案与扩展申请；Backend pkg/extension/extension.go 合同草案。 方法：冻结权限目录、敏感字段投影、系统管理恢复条件、账号本人恢复证明与凭据交付、项目创建与角色 cap 关系、公开版本兼容和旧命令映射。 验证：文档差异与链接核对、动作×scope×配置主体表逐项评审；本单元不实施业务，也不制造业务测试 PASS。 出口：阶段 1–5 对应产物和人工结论齐备，明确选择通用角色权威位置后才能进入其实施。

U2. 收口现有系统与项目越权路径

目标：先修 R6–R12/R18 的当前路径，为后续迁移建立安全基线。 依赖：U1 对动作与边界的批准；RDM 执行端 owner 负责。 文件：RDM internal/rdmapp/perms_api.go、runtime.go、upload.go、draftproposal.go、plugins/rdm/plugin.go；测试扩展 plugins/rdm/roles_test.go、draft_visibility_test.go、internal/rdmapp/perms_test.go、u1_auth_test.go、resource_authz_test.go。 方法：系统管理使用独立资格；清除自动业务 admin 放行；先验证角色动作存在和 cap，再考虑覆盖；停用不回落更宽默认；创建者走相同硬约束。 执行方向：以当前源码触发方式先建立会失败的公开执行负例，避免仅测试新帮助函数。

测试场景：

• 普通角色获 project.settings 后，全局 cap、角色管理、admin 移交仍拒绝。
• A 创建者改 B 的成员、权限、职责和归档均拒绝；矩阵解释一致。
• 管理员未获 B 业务授权，正文／业务审计／原件／私人草稿／导出均拒绝。
• 先设 allow 覆盖，再换到未配置该动作角色，当前执行与解释均拒绝。
• 停用受限角色不新增权限；owner 遇 cap=false 同样拒绝；有效合法成员仍可执行原有合法动作。

出口：直接 API／命令负例与正常回归闭合；不得宣称完整迁移或最终产品已验收。

U3. 基座账号资料、有效态与受控目录

目标：实现 R3–R5/R11，提供真实人员查找而不复制账号。 依赖：U1 目录及系统管理合同；Backend owner 负责。 文件：Backend internal/store/auth.go、迁移、internal/server/accounts.go、internal/app/hostcaps.go、pkg/extension/extension.go；新增账号资料／有效态测试及扩展 internal/app/account_lister_test.go、服务器账户测试。 方法：资料 CRUD 与停用有明确系统资格；目录查询按系统管理／项目选人／职责候选投影字段，分页稳定；停用同步终止会话与能力。

测试场景：

• 姓名电话邮箱工号均空成功建号；填写和清空资料不改身份。
• 两名同名用户精确按 ID／登录名正确选定；模糊结果要求再次选择对象。
• 项目选人未经联系方式权限不能按电话号码探测命中，不能批量导出完整目录。
• 本人改备注不能改角色、管理员位或有效态；停用账号不能继续操作或作为三权候选。
• 管理员持有 credential.recover 仍不能取得目标用户可兑换凭据或正常登录能力；无本人验证条件时恢复拒绝；管理员改可选资料不能改变恢复证明。
• SQLite 与 PostgreSQL 的空值、格式、分页和并发版本冲突行为一致。

出口：公开提供者／消费者契约验证及后台真实目录数据闭合。

U4. 通用职位、多职、默认与上限及原子批量服务

目标：实现 R1/R2/R6/R10/R13/R15/R20。 依赖：U1、U3、U2 安全基线；Backend 与 RDM owner 共同负责迁移窗口。 文件：Backend 新增 internal/authz/ 通用目录、角色、binding、版本与系统授权存储和测试；公开扩展与注册面；RDM internal/perms/roles.go 和 perms_api.go 兼容转发；新增 internal/authz/roles_test.go、policy_batch_test.go 和迁移测试；RDM plugins/rdm/roles_test.go 消费契约。 方法：KTD1–KTD4/KTD7；保留 roleId；用户绑定多职；角色默认与上限范围成对校验；保护高权限任命与最后管理者；预览及提交均授权。

测试场景：

• 一个职位绑定两人，同一人绑定两个职位；编辑说明不影响用户／项目 ID。
• 默认 grant 超 cap、未知动作、停用角色任命、无权编辑受保护项均拒绝。
• 一角色有动作无目标范围，另一角色有目标范围无该动作，组合仍拒绝。
• 批量里一对象非法或版本冲突，全部不写；同一幂等请求只生成一次变更及审计。
• 旧单角色数据导入保持 ID／绑定，双主写入被阻断；失败迁移恢复不复活撤权。

出口：角色与绑定只有一个权威来源，系统动作与新旧公开消费者结果一致。

U5. 项目角色选择、覆盖和统一资源读取

目标：实现 R2/R7–R12/R14/R18/R19。 依赖：U3/U4 与公开版本就位；RDM 项目 owner、Backend 资源接口 owner 配合。 文件：RDM internal/members/members.go、internal/projects/projects.go、internal/rdmapp/projects_api.go、perms_api.go、runtime.go、plugins/rdm/plugin.go；Backend 项目 API、internal/server/resource_authz_test.go、resource_authz_consumption_test.go、internal/app/resource_authz_v2_test.go；RDM member_guards_test.go、resource_authz_test.go、perms_test.go。 方法：加入和建项保存明确 binding；项目覆盖只操作本项目；资源策略消费完整 action/type/id/owner/project；列表、计数、检索、历史和导出均过滤；宿主项目和领域项目稳定绑定。

测试场景：

• 新增用户职位不改变已有项目；项目选择新增 binding 后才生效。
• 解绑再重新任命不能自动恢复旧项目选择／旧覆盖。
• 唯一负责人解绑后重新任命合格职位，可经受限入口由本人明确重选并恢复管理；普通管理员、前负责人或 cap 不足者不能代修复，也不能借此读资源或恢复旧 allow。
• 项目明确 deny 在另一角色可 grant 时仍拒绝；allow 超所有可用 cap 拒绝。
• 创建者可以管理本项目，不能读私聊或未分享原件；无管理资格建项不留下可使用半成品。
• 篡改 projectId、资源 ID、owner 以及使用基座直连建项／下载／检索不能绕过域策略。
• 策略提供者错误、缺失或权限通知丢失时拒绝；分页与数量不泄露被过滤对象。

出口：HTTP／Host／命令／模型上下文的直接入口均有同一作用域和资源边界。

U6. 三权资格、冻结轮次及真实分配者审计

目标：实现 R16/R17/R18，复用已有整文审签能力。 依赖：U4/U5；RDM 文档模块 owner 负责。 文件：RDM internal/domain/review.go、internal/rdmapp/docsubmission.go、draft.go、plugins/rdm/plugin.go；扩展 write_duty_stage_test.go、整文审签测试和职责候选测试。 方法：统一分配服务检查有效账号、项目成员、选用职位、cap 与异人；审计记录真实操作者；轮次冻结与资格撤销处理按 KTD5。

测试场景：

• 跨项目、停用、非成员和 cap 不足候选拒绝；编制／审核／批准同人拒绝。
• 多审核人未全部通过时批准拒绝；旧票不能签新正文。
• 管理员／创建者未被指派不能代编、代审、代批；审核人能读提交正文但不能读取未分享原件。
• 在途撤权或换职责使待处理轮次失效；历史已签版本和主体保留。
• 分配者与受指派编制人不同，审计 actor 是真实分配者。

出口：一份整文由真实三个职责完成与拒绝链，资格解释和执行一致。

U7. 用户、角色、项目权限与三权界面

目标：实现 R4/R5/R13–R16，形成完整管理操作路径。 依赖：U3–U6 相应服务合同稳定；Frontend／UI owner 负责。 文件：Frontend src/components/adminSections.tsx、adminRdmSections.tsx、AdminZone.tsx、rdmManagement.ts、api.ts、store.ts；复用 test/rdmroles-reject.test.ts，新增角色矩阵／成员矩阵／目录与三权交互测试；沿用两个仓的 design-guard.test.ts。 方法：KTD6/KTD7；先整合在途管理页面改动；消费服务端权限目录与 capabilities，共用草稿模型，选择稳定 ID。

测试场景：

• 单角色与矩阵产生等价 patch；过滤和翻页不丢草稿；全选范围与预览一致。
• 姓名同名但登录名不同不误选；资料空值正确展示；无资格者看到明确拒绝原因。
• 两窗口并发编辑返回冲突并保留草稿；等待确认／已完成／结果未知分开显示。
• 快速切项目／角色／搜索词，迟到结果不能覆盖新目标；403 不被当成登录失效或永久加载。
• 明暗主题、键盘导航、焦点、窄屏及广告过滤环境可用；令牌和折叠原语门禁成立。

出口：真实用户通过既有页面完成建号／任命／项目选人／覆盖／三权，没有手填 ID 的必要主流程。

U8. Agent 同源工具、撤权与后台提交

目标：实现 R12/R19，并验证 UI 与对话动作 parity。 依赖：U4–U7；命令总线与运行时 owner 负责。 文件：RDM plugins/rdm/plugin.go 工具声明和描述、任务资源使用／提交位置；Backend internal/cmdbus/、internal/runmgr/、公开策略集成测试；Frontend 卡片／Surface／能力 store 相关测试。 方法：查询、解释、预览和提交用同一 primitives；对角色／项目／三权写操作使用宿主确认；任务恢复与新输出重验，终止含已撤数据的运行。

测试场景：

• 同一动作 UI／命令／工具的允许、拒绝、审计和对象一致，模型不能伪造 actor 或确认自己的提案。
• 入队后撤权、恢复旧任务、确认旧卡、使用旧 Surface 均不能提交。
• 已开 SSE／下载／检索遇撤权终止后续读取，权限通知丢失仍由当前存储判定拒绝。
• 含已撤资料的模型上下文不被继续使用或披露，恢复从新授权上下文开始。
• 真实模型能查询候选、解释权限和请求人确认；遇歧义人名停止在选人步骤。

出口：mechanism 测试与适用真实模型任务级验证分别留证，不用 mock 代替模型验收。

U9. 迁移演练、精确组合及正式验收

目标：闭合 R1–R20，交付单一权威的实际产品行为。 依赖：U2–U8 完成对应评审；迁移、部署和运行测试各有明确授权；集成 owner 与用户验收人负责。 文件：各仓迁移与验收记录；Dev task evidence、组合 pins 和功能规划；新增多账号权限端到端用例按仓内测试规范保存。 方法：先隔离副本、SQLite／PG 同构迁移、差异审阅和恢复演练；固定 base/head/pins/config/data identity，再在授权环境执行真实账号验证。

测试场景：

• 至少两个独立项目；系统管理员、A 创建者、B 创建者、同职位两人、一人多职、两名审核人、批准人、普通成员和无关用户。
• 完成资料／职位／系统能力／项目选择及覆盖／文档三权全过程，并逐项执行跨项目、换岗、停用、上限收紧与私域负例。
• 重启后任命／覆盖／职责与撤销保持；两实例缓存失效、并发编辑和任务恢复一致。
• 迁移 diff 无未经批准扩权；回滚保留撤权事实，不启用旧管理员业务旁路。
• 实际浏览器由最终固定产物提供；系统角色变化、公开契约、模型工具、文档正文和审计结果同一对象。

出口：用户正式验收、独立 Review、当前 HEAD 的权威 CI、合入及部署记录各自齐备；不能用其中一项替代其余。

Phased Delivery

flowchart TB
  U1[U1 需求与公开合同评审] --> U2[U2 当前授权路径收口]
  U1 --> U3[U3 用户资料与目录]
  U2 --> U4[U4 统一职位与多职服务]
  U3 --> U4
  U4 --> U5[U5 项目与资源授权]
  U5 --> U6[U6 三权资格与轮次]
  U3 --> U7[U7 管理界面]
  U4 --> U7
  U5 --> U7
  U6 --> U7
  U7 --> U8[U8 Agent及撤权全链]
  U8 --> U9[U9 迁移组合与正式验收]

建议分四个可验增量：I1=U1＋U2 的边界修正；I2=U3＋U4 的人员／职位与目录；I3=U5–U7 的项目、三权及配置体验；I4=U8＋U9 的全链和迁移验收。 各增量遵循 policy/delivery.md 的需求、方案、实施、验收人工出口；阶段内可继续调查、自检与整改。 既有公开契约只读、UI 单对象／矩阵模型设计可在依赖批准后并行；服务端迁移和同一页面写入按 owner 协调。 实施工期在 U1 完成、实际在途任务及公开版本核定后估算，不把未验证的迁移规模写成日期承诺。

---

Verification Contract

以下是后续验证计划，本轮业务结果全部 NOT_RUN。

层	验证内容	命令／环境与证据要求
文档	当前引用、需求追溯、两项裁定、规则一致性	文档 diff 与链接检查；SELF
账号与通用授权	正常／越权／停用／并发／多职／批量／迁移	Backend 相关 Go 测试与合同测试；执行时固定 SHA
RDM 领域	项目隔离、角色选用、范围、三权、私域和状态	RDM 相关 Go 测试、公开 HTTP／命令集成；make test
UI	搜索、选择、两种矩阵、确认、冲突与拒旧	Dev make test-frontend、make test-ui；固定组合实际浏览器
产品组合	基座提供者／RDM 消费者／正式前端产物	各仓和 Dev make test、make build，核对实际 pins 与制品
存储与恢复	SQLite／PG 迁移、并发、重启与多实例撤权	隔离数据与授权运行环境；最小权限真实账号集
Agent	查询／解释／确认／拒绝／恢复／资源使用	真实模型任务级测试；机制单测与模型结果分开
正式交付	同步、测试、Review、CI、合入及部署	当前 base/head；precheck／task-sync／检查输出经 evidence；GATE 运行身份＋SHA 或独立 REPLAY

本地 evidence 为 SELF，不因标签或摘要提升可信级别。 正式验收固定被测源码、组件 SHA、配置与数据身份；Reviewer 按最小重放集独立核验。 未执行、跳过、零用例或源代码存在不能写为业务 PASS。 文档保存只检查文档，不启动业务测试、数据库迁移或服务操作。

---

Definition of Done

本轮方案交付：本文包含当前差距、完整需求、明确模型与合成规则、界面方案、迁移与兼容、工作项／文件／测试／依赖和评审出口；两项用户决定有准确来源；主入口与任务卡可接续。 完整功能交付：R1–R20 均能映射至实际实现及固定对象证据，所有必要正常、异常、边界和权限负例成立；用户正式验收后按仓库规则完成独立 Review、当前 CI 与组合核验。

启动实施前需完成的评审选择：KTD1 通用职位权威迁移、创建者管理与角色 cap 的耦合和本人重选规则、受控目录可披露字段、账号本人恢复证明及交付合同，以及生产迁移／切换范围。 这些是当前草案中已给推荐方案但尚未批准的设计选择，不影响本轮方案交付，不授权实施者自行替换路线。 实施时再确定的细节：表名／迁移编号、最终 package 位置、目录分页与搜索索引阈值、通知实现和隔离环境，不改变上述产品边界。

停止条件：范围或需求改变；必要公开契约不兼容；角色数据无法取得一致快照；发现未批准扩权；实际制品／数据身份不明；在途任务 owner 冲突；越出迁移／部署授权。 发生时保存当前证据与现场，返回受影响方案或计划评审，不能放宽授权继续。

推荐下一步为评审 U1 和 I1，先批准本次权限边界与公开合同，再实施已有可达授权路径的收口。 这项建议不自动启动业务任务；完整用户资料与矩阵设计已有后续依赖和验收，不会在首批完成后遗漏。