Agent-System-Documents/docs/proposals/2026-10-13-rdm-settings-members-duties-perms-increment.md

title, date, type, execution, artifact_contract, product_contract_source

title	date	type	execution	artifact_contract	product_contract_source
RDM 设置归属、成员、文档职责与权限矩阵完善增量方案	2026-10-13	feature	code	rdm-increment-plan/v1	legacy-requirements

RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1

负责人：weichen；编制：ZCode；核对日期：2026-10-13（北京时间）。 上游方案：2026-10-12 RDM 功能、实现与计划矩阵及整改方案（下称"总案"），本增量承接其本稿 U3、U4、U6，涉及职责一致性的部分衔接 U5。

评审状态：2026-10-13 用户评审通过（同意方案及技术评审意见），并授权按本方案实施（P1–P8 两批推进；正式验收与清理回收节点保留人工确认）。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。

Goal Capsule

以现有 RDM 实施总案的一个完整增量，先厘清设置归属和服务端权限，再补齐搜索、选择、职责分配与权限矩阵交互，保证界面显示、保存结果和实际执行一致。终点：创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存，且服务端边界（受管设置、成员校验、原子职责变更、权限范围）全部经真实请求验证。

非目标：不扩展飞书集成、组织架构、多角色叠加或全量文档生成工程。

一、当前实现与需要补齐的内容

方面	当前源码情况	本次需要完成
设置归属	项目设置展示完整 schema；用户、项目设置都能覆盖模型等配置	设置作用域、管理员系统设置入口、写入与最终生效值双重约束
成员管理	手填账号；已有分页账号目录，但只有账号和有效态	账号／姓名搜索、提示选择、下拉浏览、专业角色过滤、明确的项目身份修改
文档职责	手填文档 ID 和人员账号；主要读取提交快照	文档搜索／列表／树选择、当前职责回填、项目成员选择、提交校验
权限查看	已有单成员权限解释表	单成员详情与多人矩阵、中文标签、项目动作范围、上限内配置
一致性	存在职责目标未校验成员、职责更新与审签失效分步执行等缺口	服务端统一校验、原子变更、版本冲突、撤权及历史保全

对应实现锚点：Frontend src/components/ProjectSettingsModal.tsx、src/components/adminRdmSections.tsx；Backend internal/settings/settings.go（覆盖链 defaults → system → user → project）；RDM plugins/rdm/plugin.go、internal/perms/perms.go、internal/rdmapp/docsubmission.go。

二、设置归属与界面结构

沿用现有设置入口和 SettingsShell，项目设置收敛为四个页面：

页面	内容
项目设置	真正属于本项目的共享配置与协作规则
项目成员	成员搜索、添加、项目身份调整、移除
文档职责	文档查找、职责查看与分配、相关审签状态
项目权限	单成员权限详情、成员权限矩阵、允许范围内的配置

系统管理中补齐“模型与服务配置”，承接主模型、轻量模型、Embedding、Rerank、模型密钥与 Tavily 等系统配置；Agent 工具限制、系统插件、全局专业角色和权限上限也归系统管理。个人设置只保留个人偏好。

实施时需要处理三个层面：

• 展示范围：设置描述携带允许作用域、管理资格、生效时机；项目页面只消费项目项。
• 写入范围：用户／项目 API 拒绝写入系统受管项，包括嵌套字段和点路径形式，插件设置也遵守同一规则。
• 实际生效：旧用户／项目覆盖值不能继续影响系统模型；个人画像的模型路由及个人模型密钥也必须纳入受管校验，堵住其他覆盖入口。

另外，当前“项目设置”实际上按“用户＋项目”保存（Backend Effective(owner, projectID)，project scope 物理存储在各 owner 名下）。需要区分：

• 共享项目业务配置：以项目为权威，同一项目不同成员读取一致。
• 个人在该项目中的偏好：继续属于个人。

跨会话读取必须保留本人会话的隐私边界，不能因项目配置共享而开放其他成员的私聊、上传原件或个人草稿。

三、成员管理交互

采用一个可搜索的人员选择器，同时支持输入、提示选择和下拉浏览，不为每种途径增加独立页面。

添加流程：打开人员选择器 → 输入账号或姓名，或浏览候选 → 可按专业角色过滤 → 选择人员 → 设置项目身份 → 添加。

具体行为：

• 输入账号支持精确匹配；姓名、账号支持模糊检索。
• 未输入时显示分页候选；选择器内提供“全部专业角色／系统工程师／软件工程师……”筛选。
• 候选显示“姓名、账号、专业角色”；同名人员通过账号区分，姓名为空时使用账号。
• 已加入人员标记“已加入”，避免重复添加造成隐式身份变更。
• 最终提交稳定账号标识，不能直接提交搜索文字。
• 成员表分别展示“专业角色”和“项目身份”，不混用两者。

项目身份使用“项目负责人／项目成员”等中文名称。成员行提供明确的“调整项目身份”和“移除”操作；继续保护最后一位负责人。

服务端复用已有 rdm.account.list，补齐受限的姓名搜索、精确账号校验和专业角色摘要。不能直接把管理员用户列表或包含全部账号绑定的角色管理接口开放给项目负责人。

角色筛选只帮助找到人员；项目负责人不能借此修改账号的全局专业角色。账号有效状态必须来自基座实际能力，不能把当前简单的 valid=true 当作完整的账号停用机制。

四、文档查找与职责分配

2026-10-15：本节的职责页交互（文档清单加选中详情、章节级入口、整文审签）已被 文档职责矩阵整改 r2 取代。成员校验、版本冲突、 在途审签确认和历史保全仍然有效。下文保留作被取代前的记录。

文档职责页面采用“文档清单＋选中文档的职责详情”：

• 上方提供统一搜索框，支持文档 ID 精确检索、标题精确／模糊匹配。
• 支持文档列表与树形浏览；阶段、文档类型、未分配／已分配、审签状态可用于筛选。
• 树形视图忠实呈现当前文档结构，只有文档节点可以作为职责分配对象，章节不能误作 docId。
• 搜索、列表和树选择共用同一目录与选中状态。
• 结果显示名称、阶段／类型、职责概况和状态；ID 保留为辅助定位信息。

已有文档树查询属于审计面，不能降低它的授权规则来供选择器使用。应补齐专用的职责管理元数据读面：

• 有职责分配权的管理者可以读取必要的管理元数据。
• 普通成员只获得其有权查看的文档范围。
• 标题、数量、筛选结果和树节点均在服务端过滤，避免通过搜索泄露不可见资源。

选中文档后，立即读取并回填当前职责，包括尚未提交过审签的文档。当前职责与“某轮提交冻结的职责名单”分别展示，不能混为一份数据。

人员选择规则：

职责	选择方式	约束
编制人	搜索、下拉、专业角色过滤	单选
审核人	搜索、下拉、专业角色过滤	多选，至少一人
批准人	搜索、下拉、专业角色过滤	单选

**所有候选只能来自当前项目成员。**保存时服务端再次校验账号、项目成员关系、对象归属、操作资格和职责版本；文档级（rdm.review.assign.doc）、章节级（rdm.review.assign）及旧命令入口均遵守同一规则。

保留编制、审核、批准互异的规则。专业角色筛选不自动授予文档职责；管理权也不自动获得代编、代审或代批资格。

职责变更需要补齐以下行为：

• 在途审签受影响时，先显示受影响轮次与“需要重新提交”的提示。
• 明确确认后，职责更新、在途审签失效和事件记录原子完成。
• 保留旧冻结名单、审核记录和已批准历史，不把旧票带入新轮次。
• 无变化保存保持幂等；并发修改返回明确冲突。
• 移除仍承担当前职责的成员前，展示受影响文档并引导处理，防止留下无人可执行的职责。

总案要求的批量分配放在同一文档清单中：勾选文档、预览统一职责方案、确认提交。首版采用有界批次，任一文档校验失败则整批不写入，并列出原因。

五、单成员权限与多人矩阵

“项目权限”提供两个视图，共享同一服务端权限解释：

视图	默认行为	用途
按成员查看	普通成员查看自己；管理者可搜索其他成员	查看具体权限、配置来源和拒绝原因
权限矩阵	管理者查看成员×项目动作	比较成员权限，发现缺失或差异

矩阵支持成员搜索、专业角色／项目身份过滤、分页及权限分组。点击单元格可展开解释，显示角色默认、管理员上限、项目覆盖及结果。

项目覆盖使用三态：沿用角色默认／项目内允许／项目内禁止。管理员上限禁止的动作不能通过项目覆盖授予；“恢复默认”需要实际撤销覆盖，不能用一个布尔值模拟。

权限目录必须明确动作所属范围：

内部标识	显示名称	所属范围
project.create	创建项目	系统角色权限，项目页面不出现
member.manage	管理项目成员	项目
duty.assign	分配文档职责	项目
stage.advance	推进项目阶段	项目
doc.read	读取文档	项目动作，具体文档仍须授权
doc.write	编制与编辑文档	项目动作，仍受职责和状态限制
knowledge.publish	发布项目知识	项目

这个范围划分同时约束矩阵读面和覆盖写面：不能只是隐藏 project.create，服务端也必须拒绝在项目中配置它。

权限名称、项目身份、来源、状态及拒绝原因统一使用人类可读文案。内部标识只保留在按需展开的技术详情中。

同时核对每项权限与真实操作门禁。例如当前项目归档还有创建者／域管理员条件，矩阵解释必须反映真实条件。矩阵中的“允许编制文档”也不能意味着能修改项目内所有文档。

普通成员自查权限的条件收敛为“当前有效项目成员”，避免文档读取权限被收回后，连自身权限与原因也无法查看。

六、技术划分与实施工作包

基座负责身份、基本资料、受管设置机制与通用契约；RDM 负责项目成员、专业角色、权限策略及文档职责；Frontend 负责业务交互；UI 仓提供通用选择器原语。

工作包	内容与主要范围	依赖	完成条件
P1 契约与需求固定	设置作用域、项目动作目录、人员／文档候选 DTO、能力与版本语义；更新关联方案	无	本次五项要求都有稳定验收条件，四类身份／角色／职责概念明确
P2 系统设置闭环	Core 设置描述、Backend 设置 API／存储／生效链／模型及密钥解析；系统管理入口	P1；基座发版与 RDM/Dev 升 pins（见评审补充 1）	系统受管项只能由有权管理员配置，旧个人／项目值不能覆盖
P3 人员与成员接口	扩展公开账号搜索；RDM 专业角色摘要、成员查询、项目身份调整与提交校验	P1；姓名来源核实（见评审补充 3）	账号／姓名／角色过滤同源，添加与身份调整明确分离
P4 文档与职责接口	专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动	P1、P3	跨项目／非成员指派被拒，职责与审签变更全成或全败
P5 通用选择器	UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员适配。文档职责页的文档选择器改由 r2 三视图承接	P1，接线依赖 P3、P4	人员选择共享交互，无自由文本误提交。职责页交互见 r2
P6 权限解释与矩阵	RDM 项目动作目录、单人／批量解释、覆盖三态、来源与拒绝原因	P1、P3	矩阵与执行规则一致，系统动作无法写入项目覆盖
P7 项目设置集成	重构现有项目页，连接设置、成员与权限页。文档职责页改为 r2 的三视图，不再包含整文审签	P2—P6	创建者、普通成员、职责人员均有对应可用流程。职责页验收以 r2 为准
P8 迁移与组合验收	旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填	P2—P7	需求到证据闭合，无越权、隐私泄露或数据丢失

前端主要改动落在现有 ProjectSettingsModal、adminRdmSections、rdmManagement、api 和 store；按业务拆分成员、职责及权限组件，避免继续扩大一个管理组件文件。

目前 Dev 与 RDM 固定的 Backend 版本存在能力差异。实施时必须按公开契约推进相关版本，再完成组合验证，不能因为独立 RDM 仓已有某个接口就假定 Dev 组合可直接使用。

七、界面与异步状态要求

按根目录 DESIGN.md 实施，复用现有令牌、动效、设置外壳和折叠原语。

• 一种对象只有一个主要选择路径，搜索和浏览在同一选择器完成。
• 姓名、文档名为主要信息，账号和 ID 为辅助信息。
• 下拉支持键盘移动、确认、关闭；审核人多选使用清晰标签。
• 加载、空结果、权限不足、接口未装配、查询失败分别呈现。
• 切项目、切文档、改筛选时清除不适用的选中项和结果；迟到响应不能覆盖当前对象。
• 异步状态只有一个所有者，按请求代次／事件顺序丢弃过期结果。
• 保存后读取服务端结果；网络断开且结果未知时先核对状态，避免盲目重放。
• 未保存改动提供轻量离开提示；需重启的设置明确显示待生效，不能统一宣称即时生效。
• 窄屏按成员查看权限，矩阵可横向浏览，不压缩成不可读的小格子。

八、迁移、验证与交付安排

旧配置先做脱敏盘点，列出配置路径、来源和冲突状态。不能任取某个用户／项目的模型配置提升为全系统配置。先确定并验证系统配置，再启用受管策略；旧值保留受保护的恢复依据，退出生效链。

旧项目内 project.create 覆盖退出项目策略，保留历史依据。历史职责、审核与批准记录保留；无效的当前职责列入修复清单，不自动替换人员。

正式验收至少覆盖：

验收场景	预期结果
项目与个人设置写入系统模型项，包括手造请求	拒绝；旧覆盖也不影响运行结果
账号、姓名、下拉、专业角色过滤查找成员	能找到并选择稳定账号；同名不会误选
重复添加已有负责人、并发修改最后负责人	不发生隐式降级，不破坏负责人约束
文档 ID、标题、列表、树查找	指向同一文档；章节及其他项目对象不能误提交
搜索后人员被移出项目，再保存职责	服务端拒绝
职责变更中途失败	职责、审签状态与事件完整回滚
单成员详情与多人矩阵对照实际操作	结果与原因一致；具体资源限制清晰
项目覆盖授予超上限动作或 project.create	拒绝；恢复默认真正生效
快速切项目／文档、断网、迟到响应	不显示旧对象数据，不误报成功
同项目多成员使用、刷新及重启	共享配置一致，个人会话与原件仍私有

验证分为领域与契约测试、真实 SQLite／PostgreSQL 集成、真实身份浏览器流程，以及 Dev 精确组合的 make test、make build。浏览器需要覆盖非管理员项目负责人、普通成员、互异的编制／审核／批准人员及两个项目；不能用全管理员账号代替权限验收。

分两批形成可审查实现：先完成 P1—P4、P6 的服务端边界与契约，再完成 P5、P7 和 P8 的交互及组合验收。界面设计可在第一批同时评审。

评审补充（2026-10-13 技术评审并入，随方案一并批准）

1. P2 显式依赖基座发版。 受管设置机制是基座（Backend/Core）公开契约扩展，按总案交付顺序走“扩展申请评审→基座实现→基座发版→RDM/Dev 升 pins→组合验证”。P2 完成条件在原基础上追加：基座版本已发、pins 已升、Dev 组合 make test 通过。
2. 项目共享配置的存储迁移规则。 当前 project scope 物理存储在各 owner 名下；改为“以项目为权威”需要：新项目作用域存储、存量多 owner 副本的合并策略（默认规则：同键取最近写入时间，冲突清单列出不自动合并的键并交项目负责人裁定）、旧键退出生效链并保留只读恢复依据。P8 交付物含迁移清单与执行记录。
3. 姓名来源与账号停用能力须先过 facts。 基座账号目录当前明确“不含姓名/联系方式”。P3 的姓名搜索依赖基座账号模型是否存有姓名/显示名字段；P1 契约先定姓名来源（基座扩契约，或 RDM 专业角色档案补姓名）。账号停用机制现状同样按 policy/facts.md 登记验证，未证实前不把 valid=true 当作停用语义。

顺序裁定（2026-10-13）

本增量按自身 P1→P8 顺序推进；P2 的基座契约扩展按总案 369 行发版顺序执行，与总案 U1/U9 残余项的交织在扩展申请评审时统一排队，不因本增量跳过 U1（正式产物）与 U9（公开授权契约）的既有优先级。

评审核查记录（2026-10-13，源码 3fb8210 / RDM 255f9cb）

评审对方案“当前源码情况”逐项核查，全部属实：

声明	证据
项目设置按“用户＋项目”保存	Backend settings.go Effective(owner, projectID)，project scope 以 owner 为键
user/project 覆盖可改模型设置，无受管拦截	同上覆盖链，无“系统受管”概念
成员手填账号	adminRdmSections.tsx RdmMembersSection
账号目录仅 owner+有效态	RDM rdm.account.list 描述“owner+有效态；不含姓名/联系方式”
职责手填 docId 与账号	RdmDutiesSection placeholder
已有单成员权限解释表	rdm.perm.check（动作/生效/来源/原因），前端默认自省
权限标识与所属范围	RDM internal/perms/perms.go:21-31，project.create 注释即“全局动作”
职责目标未校验成员	rdmReviewAssign handler 注释“数据，非身份”——按 G1-5 旧裁定绕过成员校验；本方案 P4 推翻该裁定，属规则变更，在 P1 契约中记录
职责更新与审签失效分步	文档级 assign 先写职责再调 InvalidateActiveDocSubmission，两步顺序非原子；章节级 assign 完全未接失效

主记录与推进

• 主记录：本文件（唯一正文）；任务卡 .task/feature-rdm-increment-settings-duties.md 承载需求表、证据与阶段结论。
• 来源：.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt（原始用户补充）、2026-10-13 会话评审。
• 下一步：P1 已随本稿固定；按两批顺序进入 P2（基座受管设置契约扩展申请）与 P3/P4/P6 服务端实现。