Record the approved settings amendments and stage 6 review

Why: The user approved on 2026-10-14 both r1.1 stage 4 amendments
(explicit per-path source selection replacing the last-write default,
and the fail-closed project settings authorizer callback) together with
the stage 6 implementation candidate, so pending-review markers in the
plan and the contract record no longer matched reality.

Evidence: User review message recorded in the proposal's new review
conclusion section with the reviewed object versions (Documents
62c2e234, Dev 3336bcbe, RDM 931fc4c3); no command execution involved.

Impact: Plan r1.1 and contract record r0.3 now state approval; the base
release stays a user-owned dual-key action and stage 7 formal
acceptance follows the approved release dependency.

Refs: .task/feature-rdm-settings-completion.md in Agent-System-Dev and
Agent-System-RDM.

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

@@ -7,13 +7,15 @@ artifact_contract: rdm-increment-plan/v1
 product_contract_source: legacy-requirements
 ---
 
-# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1
+# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1（附 r1.1 修订，2026-10-14 评审通过）
 
 负责人：weichen；编制：ZCode；核对日期：2026-10-13（北京时间）。
 上游方案：[2026-10-12 RDM 功能、实现与计划矩阵及整改方案](2026-10-12-rdm-function-implementation-plan.md)（下称"总案"），本增量承接其本稿 U3、U4、U6，涉及职责一致性的部分衔接 U5。
 
 评审状态：2026-10-13 用户评审通过（同意方案及技术评审意见），并授权按本方案实施（P1–P8 两批推进；正式验收与清理回收节点保留人工确认）。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。
 
+2026-10-14 增补的 r1.1 为两项阶段 4 修订，**已于 2026-10-14 获用户人工评审通过**（连同阶段 6 实施候选一并批准；依据见文末「评审核查记录」之后的评审结论）。r1.1 不改变 P1–P8 范围或正式验收门禁。
+
 ## Goal Capsule
 
 以现有 RDM 实施总案的一个完整增量，先厘清设置归属和服务端权限，再补齐搜索、选择、职责分配与权限矩阵交互，保证界面显示、保存结果和实际执行一致。终点：创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存，且服务端边界（受管设置、成员校验、原子职责变更、权限范围）全部经真实请求验证。
@@ -236,8 +238,29 @@ product_contract_source: legacy-requirements
 | 职责目标未校验成员 | `rdmReviewAssign` handler 注释“数据，非身份”——按 G1-5 旧裁定绕过成员校验；**本方案 P4 推翻该裁定，属规则变更，在 P1 契约中记录** |
 | 职责更新与审签失效分步 | 文档级 assign 先写职责再调 `InvalidateActiveDocSubmission`，两步顺序非原子；**章节级 assign 完全未接失效** |
 
+## 阶段 4 修订 r1.1（2026-10-14 编制，2026-10-14 人工评审通过）
+
+### 旧项目配置冲突的来源选择
+
+r1 评审补充 2 已批准“同键取最近写入时间”为默认合并规则。实施核查发现旧 `(owner, project)` 设置行没有逐键修改时间；行或快照时间不能证明每个键最后由谁写入。若按该时间自动决定来源，就会把无法证明的先后顺序当作数据事实，可能覆盖另一成员的项目策略。
+
+候选修订：先按项目和路径列出旧副本及脱敏冲突状态，不自动选择冲突值。有权配置该项目的人在预览中逐路径选来源；观察记录绑定操作者、项目、来源和目标版本，应用时重新鉴权、复验记录与版本，并在事务中写入共享项目配置。旧行保留作只读恢复依据，受管系统项和个人秘密不自动提升为共享配置。无冲突路径也须在预览中明确来源，不能把行时间冒充逐键时间。失败不部分迁移；相同观察重试保持幂等。生产迁移及正式验收尚未执行。
+
+备选是补造逐键时间或以固定成员优先级自动覆盖；前者没有历史依据，后者会静默丢弃其他成员选择，因此本候选采用显式裁定。用户于 2026-10-14 评审通过本修订：以逐路径显式来源选择替代 r1 评审补充 2 的“同键最近写入”默认规则；生产迁移仍 **NOT_RUN**，待正式组合验收时按本修订执行。
+
+### 项目设置写入的公开授权合同
+
+共享配置改为以项目为权威后，Backend 必须由宿主项目判断读者和配置者。现有 `ResourceAuthorizerV2` 只覆盖资源读取，`ProjectLifecycle.Work` 只说明成员可工作，二者均不能推断项目设置写权限。候选增设可选的 `ProjectSettingsRegistry.RegisterProjectSettingsAuthorizer`，由与项目生命周期相同的提供者按受信 actor、宿主 projectID 和读／写动作作出判定；缺失提供者或拒绝均失败关闭，HTTP 请求不能自报其他主体或项目来绕过。
+
+该公开扩展点保留旧插件兼容：未注册回调的插件不能因此获得共享项目设置能力；基座其他个人／系统设置仍走原有各自授权。用户于 2026-10-14 评审通过该模块职责与接口；正式基座扩展发版仍属高后果操作，按双钥匙由用户亲手执行，随后 RDM/Dev 升正式 pins 并做组合验收。具体请求、版本和失败语义见 [接口与验证记录](../records/2026-10-14-rdm-settings-completion-contract.md)（当前 r0.3；受评版本 r0.2）。本阶段只完成源码与隔离 SELF 自检，没有发布版本或升级正式 pins。
+
+## 评审结论（2026-10-14）
+
+评审人：weichen（用户）。评审对象：Documents 主方案 r1.1 两项修订（受评提交 `62c2e2347e7656ee5a07900d77968ecbea415bbd`）、接口记录 r0.2、阶段 6 实施候选（Dev 任务 HEAD `3336bcb` 组件组合，RDM `931fc4c33aceb7105b319a886d6ee817896200fd`）。用户结论：“请分别评审：①以逐路径显式选择来源替代旧配置‘最近写入’规则；②新增缺失即拒绝的项目设置授权回调；③阶段 6 实施候选。……评审通过，推进下一阶段。”三项均记为**通过**；阶段 7 正式测试与验收据此进入，其人工节点仍按 `policy/delivery.md` 保留给用户。
+
 ## 主记录与推进
 
-- 主记录：本文件（唯一正文）；任务卡 `.task/feature-rdm-increment-settings-duties.md` 承载需求表、证据与阶段结论。
+- 主记录：本文件（唯一方案正文）；历史任务卡 `.task/archive/feature-rdm-increment-settings-duties.md` 仅保留原增量记录，当前完成性修复由 Dev/RDM 同名 `feature-rdm-settings-completion` 任务卡承载证据与阶段结论。
 - 来源：`.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`（原始用户补充）、2026-10-13 会话评审。
-- 下一步：P1 已随本稿固定；按两批顺序进入 P2（基座受管设置契约扩展申请）与 P3/P4/P6 服务端实现。
+- 当前进展：P1–P8 的源码候选及阶段 6 SELF 自检记录在 Dev/RDM 同名任务卡；r1.1 的两项阶段 4 修订和阶段 6 产物已于 2026-10-14 获用户评审通过。基座正式发版、RDM 正式 pin 升级、阶段 7 正式验收与后续 Review／合入尚未完成。
+- 下一步：按本方案的发版依赖进入阶段 7 正式测试与验收：先由用户按双钥匙完成基座公开扩展发版，RDM/Dev 升正式 pins 后执行正式组合验收（含生产迁移预演决策、真实多身份浏览器与真实模型任务级对照）；发布版本的双钥匙边界不变。

docs/records/2026-10-14-rdm-settings-completion-contract.md

@@ -0,0 +1,65 @@
+# 项目设置完成性修复：接口与验证记录 r0.3
+
+本记录承接已批准的 `../proposals/2026-10-13-rdm-settings-members-duties-perms-increment.md` r1 及 r1.1（两项阶段 4 修订于 2026-10-14 获用户评审通过，权威结论见该方案「评审结论」节），不改变 P1–P8 和 R1–R5 的交付范围。当前是阶段 7 输入的已批准候选，正式验收、发布、部署与清理均不由本记录代签。
+
+修订：r0.3（2026-10-14）仅更新评审状态与阶段表述；r0.2 为受评接口记录版本，合同内容不变。
+
+当前权限边界遵循已合入的 `../proposals/2026-10-13-iam-i1-permission-contract.md`：系统管理身份不代替业务成员、动作、资源或文档职责授权；停用角色不回落为无绑定默认。
+
+## 恢复与完成性差距
+
+恢复前共享检出只有 Documents/Guidelines 的已保存提交漂移。核对内部无未提交文件、detached HEAD、当前提交已在登记历史保存之后，恢复登记 gitlink、快进本任务收尾分支并物化新 Documents。随后 Dev 启动检查返回 READY，独立任务为 `feature/rdm-settings-completion`；初始主干 R0 是 `add097d06137c4912a4ed9279e98ca353e4e4cf1`。RDM 独立任务同名，初始 R0 是 `6fcb256205c2384abed35d3b6ab96ca7216e9297`。
+
+旧任务的归档与通过叙述保留为历史。当前源码核对发现角色过滤、文档搜索/树、共享配置和模型/密钥其他覆盖入口缺项；旧接受脚本场景 9 没有执行检查、场景 10a 只比较 UI 默认值。这些内容不能证明原方案完整完成，新的验证必须检查真实动作和结果，不修改旧收据。
+
+## P2 基座公开扩展申请与候选合同
+
+场景：项目成员应读取同一业务配置；只有目标项目的合法配置者可以修改。个人在项目中的偏好仍须私有。
+
+现有 `ResourceAuthorizerV2` 的公开合同只覆盖读取，不能将其复用为项目配置写授权。`ProjectLifecycle.Work` 是成员工作资格，不是配置资格。新增可选 `ProjectSettingsRegistry.RegisterProjectSettingsAuthorizer`；回调别名为 `func(context.Context, actor, projectID string, write bool) error`。主体和宿主项目 ID 由执行端解析，不能由请求自报；提供者必须与项目生命周期提供者一致，缺失或拒绝时失败关闭。
+
+这是一项向后兼容的可选公开能力，候选扩展面为 `2.13.0-experimental`。RDM 以窄接口消费，不修改 `pins/`，不导入 Backend 私有包，不用反射或缓存的他人 Host 身份恢复授权。新基座发版与组合采用仍是完成条件；发版双钥匙由用户执行。
+
+设置描述的归属词汇为 `system`、`user`、`project`、`project-personal`。空的旧插件 scope 仅保留个人兼容，不能推断共享策略资格。模型、运行参数、系统工具与插件目录属于系统；交付物默认样式等项目业务配置共享；主题、个人指令与跨会话个人开关不变成全员共享。
+
+公共接口候选：
+
+| 接口 | 合同 |
+|---|---|
+| `GET /api/settings` | 仅个人 schema/default/user |
+| `GET /api/settings?project=<宿主ID>` | 共享 schema/default/project、projectRevision、projectCanConfigure；个人项目偏好另列 personalSchema/personalDefaults/personalUser/personalProject |
+| `PUT /api/settings/project/<宿主ID>` | `{values,expectedRevision,unset?}`；只更新明确变更的项目叶子，旧版本 409 |
+| `PUT /api/settings/project/<宿主ID>/personal` | 私有合并补丁；声明的非秘密叶子 null 表示移除覆盖 |
+| `GET /api/settings/system` | 系统 schema/default/system、systemRevision；管理员保护 |
+| `PUT /api/settings/system` | `{values,expectedRevision,unset?}`；管理员保护与版本比较 |
+| `PUT /api/settings/user` | 个人合并补丁；声明的非秘密叶子 null 表示移除覆盖 |
+
+`unset` 只接受当前作用域已声明的非秘密叶子；父路径、未知路径、内部策略、重复或与 values 重叠的路径拒绝。未修改的掩码不提交；秘密撤销显式写空字符串，不能通过移除让旧部署凭据恢复。画像模型路由、个人服务密钥、环境 AuthRef 与所有运行解析同样受系统边界约束。
+
+## P3/P4/P6 领域合同
+
+人员检索共用 query/match/roleId/projectRole/cursor/limit；姓名缺失回退账号，重名使用稳定账号区分，过滤后分页。`rdm.role.options` 仅返回有资格使用的角色名称和 ID，不下发全部绑定账号或权限上限。
+
+成员目录返回当前成员的姓名、有效性、专业角色及请求者的实际管理能力。缺失账号目录时有效性是未知，不伪造有效。职责资格还须对应动作的上限；专业角色筛选不授予身份或职责。
+
+文档目录/树共用同一受授权裁剪的检索结果；仅文档节点可提交 docId。当前职责与冻结名单分别返回。文档、章节和批量写入均要求 expectedDutyVersion，实际作废在途审签还要求 confirmInvalidation；无版本、缺账号校验或不合资格的旧命令同样拒绝。变更、作废、事件全成或全败，历史名单保留。
+
+章节沿用文档默认职责时，`expectedDutyVersion` 的有效值随文档默认版本变化；单独指派后则随章节版本变化。当前只读与写入使用同一数值：继承为 `2 × 文档职责版本`，覆盖为 `2 × 章节职责版本 + 1`，两类数值互不混淆。该值由事件重放结果计算，不迁改既有职责或历史审签。原始版本继续保存在领域事件中；客户端必须读取当前职责，不能假定新章节版本恒为 0。
+
+成员移除先读取 `rdm.project.member.impact`，只给该成员职责关系的必要元数据；没有正文或职责目录权限不因此获得全项目目录。实际移除重新检查影响与最后负责人，并与成员删除/事件写入同事务。
+
+项目权限只返回项目动作；系统创建权限不混入项目矩阵或项目覆盖。解释返回 defaultAllowed/capAllowed/override 与可读来源/原因；控制组件消费请求者真实能力，不从被查询成员身份推算。项目动作允许不代表任意文档读取或签字资格。
+
+## P8 迁移与验证边界
+
+迁移清单只返回来源、路径与状态，不返回秘密值或摘要。旧表没有逐键更新时间，不能伪造“最近写入”权威；冲突必须明确裁定。显式预览选择生成受保护、绑定主体与项目的观察记录，应用时重新鉴权、核对来源与目标版本、保留旧行、原子写目标与结果；相同观察重试幂等。系统迁移只采用管理员明确提供的新值，不自动提升他人的私有凭据。
+
+配置来源/目标在同一存储事务中检查；跨数据库的身份与业务授权回调在进入操作时独立核验，不声称它们属于同一个 SQL 事务。模板的实际使用仍重验实时资源授权。
+
+隔离 PostgreSQL 自检复现了两个实例之间的旧职责覆盖、移除新职责人员，以及两个进程同时降级负责人。RDM 项目写事务读取同一个可序列化数据库快照中的领域事件和成员策略；序列化冲突返回错误，客户端重读状态，不盲目重试写入。此处只证明对应隔离用例，不能推断所有跨数据库状态已原子化。
+
+验证包含领域/公共契约红测、SQLite/PostgreSQL 事务和竞争、真实 React 浏览器机制、隔离实例完整行为、Core/UI/Frontend/Backend/RDM 精确组合。mock/接口 fixture 只证明相应机制，不能替代真实组合、模型任务级证据、正式验收或当前 HEAD CI。
+
+实施与自检的实际对象、命令、输出及剩余项维护在 Dev/RDM 同名任务卡和源码外原始收据；本记录不手抄命令输出、不提升 SELF 为 REPLAY/GATE。未执行的正式验证保持 NOT_RUN。
+
+本轮旧验收脚本的首次实施前 RED 曾在两项负例中对默认 8788 使用测试身份尝试准备流程；旧脚本没有保存各请求响应码，因此是否发生写入无法由该次收据确认。原始收据保留在 `/tmp/rdm-settings-acceptance-red-20261014.json`。新验证入口要求显式隔离地址、保护文件和有效真实文档，不把请求失败或未执行的浏览器场景报告为通过；隔离业务实例的完整运行仍待后续固定组合。