Merge remote-tracking branch 'origin/main' into feature/layered-python-env

Why: 8788 could not render docx because the sandbox hides host site-packages and there is no request path for extra packages. The proposal fixes the design before the implementation lands.
Evidence: SELF — proposal written from the cnv_7936c0a799ff transcript and the existing exec-deps-dir code path.
Impact: Documents only. Index lists the proposal as pending review, not approved.
Refs: docs/proposals/2026-10-15-layered-python-env.md
Co-authored-by: Cursor <cursoragent@cursor.com>

docs/proposals/2026-10-11-rdm-final-target-completion.md

@@ -501,3 +501,7 @@ stateDiagram-v2
 原始来源：S:35–76 与 D:75–88；RDM requirements/README、00、01/03/04/08/09/10；U0、V2.2 已批准裁定。矩阵中给出每条需求的原文位置。
 设计依赖：两树一网展示方案 r1、多人存储方案 r1、模板对话生成方案及 69 类资产盘点。涉及 API 的名称均为候选设计，正式符号由公开契约申请确定。
 本轮没有联网核验法律或标准条款，也没有声称系统已符合任何特定法规；本方案讨论项目既定需求、数据追溯与实现验收。
+
+## 2026-10-13 项目成员闭环增量
+
+用户复现宿主项目成员保存成功、成员登录不见项目且不能建对话，已批准针对 U2/U3/U5 的方向与阶段 1–9 连续推进。具体实施主记录为 [系统项目、成员工作入口与私域协作闭环 r1.1](2026-10-13-system-project-membership.md)，验证/组件/PR/CI 结果在关联 Dev 任务卡维护。当前实现候选已覆盖统一项目、全局名称、成员个人会话、领域分片、私域与发布知识，以及旧项目显式修复；组合验收与正式 tag 消费仍推进中，不据此声明全部 U2/U3/U5 或总目标完成。部署、8788 数据修复与清理仍未授权。

docs/proposals/2026-10-11-rdm-two-trees-trace-audit-integration.md

@@ -9,7 +9,7 @@ product_contract_source: ce-plan-bootstrap
 
 # RDM 两树一网集成、完善与追溯审计展示方案
 
-修订：r1（2026-10-11 并入用户裁定）；确认状态：用户评审通过（2026-10-11，需求拆解至实施计划五阶段一并，含 KTD4 双层管理员裁定）；推进状态：U1–U5 全部实施并合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11）；管理区「项目追溯与审计」入口经通用声明机制补齐（扩展面 2.9.0 Registry.AddAdminZone；Backend #165、Frontend #63/#64、RDM #240、Dev #414，2026-10-12；rdm.audit 分区随 rdm 插件声明，区内能力仍由 rdm.inspect.* fail-closed）；管理页插件清单另合并编译插件条目（Dev #404，2026-10-12）。U6（团队存储）独立后续；运行验收属部署环境。
+修订：r1（2026-10-11 并入用户裁定）；确认状态：用户评审通过（2026-10-11，需求拆解至实施计划五阶段一并，含 KTD4 双层管理员裁定）；推进状态：U1–U4 已合入。U5 的 #213 只交付了导出工件生命周期，水位重放、报告三段、草稿门和页面入口仍在进行（RDM #301、Frontend #73、Dev #488，2026-10-12，未合入）。管理区「项目追溯与审计」入口经通用声明机制补齐（扩展面 2.9.0 Registry.AddAdminZone；Backend #165、Frontend #63/#64、RDM #240、Dev #414，2026-10-12；rdm.audit 分区随 rdm 插件声明，区内能力仍由 rdm.inspect.* fail-closed）；管理页插件清单另合并编译插件条目（Dev #404，2026-10-12）。U6（团队存储）独立后续；运行验收属部署环境。
 需求负责人：weichen；方案编制：Codex；实施负责人：待实施立项时指定。
 来源：2026-10-11 用户要求检查两树一网现状，并设计简单直观的项目追溯、审计展示；同轮明确选择“完善 RDM，并补齐必要的基座能力”。
 目标仓：Agent-System-RDM；下文 `RDM:` 路径相对于该仓，`Dev:` 路径相对于 Agent-System-Dev；所有建议接口名均为候选契约。
@@ -331,7 +331,8 @@ U1 同批接通旧客户端的项目选择和命令封装，并解析可信会
 验证：导出中途有新写入不改变已固定内容；历史来源软删除仍可按授权追溯；未归属/缺失事件可见；跨项目下载、过期下载、权限撤销均拒绝。
 完成条件：同一版本在 UI 与报告中结论一致，并有正式 GATE/REPLAY 证据。
 
-进展（2026-10-11，RDM PR #213 merge 1dce69d）：U5 已实施合入——`export_artifact.go` 导出工件生命周期（`rdm_export_artifacts` 表＋磁盘存储＋sha256 完整性＋24h 过期）；`rdm.inspect.export.{create,status,download}` 三命令（审计面授权、截止水位固定、跨项目绑定拒绝、下载重鉴权）；导出文件名携带 `wm<seq>` 水印标记。U1–U5 五个实施单元全部完成，进入部署验收阶段。
+进展（2026-10-11，RDM PR #213 merge 1dce69d）：#213 只交付了导出工件生命周期——`rdm_export_artifacts`、三条 `rdm.inspect.export.*` 命令、截止水位被记录、文件名带 `wm<seq>`。导出内容当时仍读实时世界，报告没有三段，页面没有导出入口。
+进展（2026-10-12，未合入）：RDM #301 补水位重放、三段、草稿门和遮蔽；Frontend #73 与 Dev #488 补概览导出区。这些 PR 的 CI 结论以各自 HEAD 的作业为准，本文不把本地测试写成 GATE。
 
 ---
 

docs/proposals/2026-10-12-service-restart-data-recovery.md

@@ -9,10 +9,11 @@ product_contract_source: ce-plan-bootstrap
 
 # 服务重启与全量数据恢复方案 r3
 
-确认状态：原 r2 批准记录保留（Dev PROJECT.md 记录 2026-10-12 五阶段批准）；**r3 本轮增补待人工评审**。本轮仅调查、修订方案及本地文档核查，不代签历史批准，不授权业务实施、账户变更、迁移、故障注入、部署、推送或合入。
+确认状态：原 r2 批准记录保留。**r3 新增（R11/R12、KTD13–KTD15、U8）于 2026-10-12 已批准**，当时授权连续推进到 PR 可合入；该历史批准不代替当前交付准入。合入按现行规范由智能体执行。
+U8 进展（2026-10-12，未合入）：Backend #183 与 Dev #482；旧记录在 `ef66bfb` 上记有 vet-and-test success（历史 SELF 引用，非本轮 GATE）。Dev 侧在允许 `app → instanceguard` 与 `instanceguard → store` 两条架构边后的提交是 `4464255`，该 HEAD 的 CI 以作业结论为准，不在本文升为 GATE。
+r3.1＝同日增补 D1/D2/D3（部署根治；编号避开本案 U1–U8）。映射：D1 补 U1 身份消费缺口，D2 补 U6 部署回退，D3 补 U7 真实组合门禁。确认状态：用户 2026-10-12 授权按实施计划连续推进到 PR 可合入；D1–D3 仍供人工评审，不因 U8 批准而代签。
 修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。
-r3＝同日根据 dev 8788 账户故障续查刷新源码／运行事实，保留 R1–R10、KTD1–KTD12、U1–U7；补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值，未宣称实测达标。
-r3.1＝同日增补 D1/D2/D3（部署根治；编号避开本案 U1–U8）。映射：D1 补 U1 身份消费缺口，D2 补 U6 部署回退，D3 补 U7 真实组合门禁。确认状态：用户 2026-10-12 授权按实施计划连续推进到 PR 可合入；本节新增条款仍供人工评审，不代签 r3 其余未批内容。
+r3＝同日根据 dev 8788 账户故障续查刷新源码／运行事实，保留 R1–R10、KTD1–KTD12、U1–U7；补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值，未宣称实测达标。上述 r3 新增已于 2026-10-12 批准。
 需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。
 主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
 
@@ -331,13 +332,13 @@ T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合
 
 实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。
 
-下一任务建议为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
+r3 编制期的历史下一任务建议（不是当前批准状态）为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
 
 ## 10. 全系统完成条件
 
 只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
 
-本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+编制期历史交付状态止于**待审核方案**；当前批准与进展见页首及第 11 节。批准不等于全系统恢复已验收，不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
 
 ## 11. D1/D2/D3 部署根治补充（r3.1）
 

docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md

@@ -9,9 +9,10 @@ product_contract_source: ce-plan-bootstrap
 
 # svc 统一部署与一次性登录 Key 方案 r3
 
-确认状态：**r1 原批准保留；r2 增补已随 #87 合入（其评审状态以正文与审阅记录为准，不因合入视为已批准）；r3 登录恢复实施记录待人工评审**。r1 的批准记录为 2026-10-12 用户「批准，继续推进」（五阶段及 U1/U4 规格，允许对应实施和 PR）。本轮用户要求仔细调研、详细方案并「继续」，覆盖方案修订及本地文档准备，不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。
+确认状态：**r1 原批准保留；r2 新增（R13–R15、KTD11–KTD14、U7）的 2026-10-12 批准记录保留；r3 登录恢复实施记录待人工评审**。r2 的批准来自原状态任务 Documents #89（来源提交 `b8df6f3c2a3180b06c61d2303bbfea9a3914f186`），不由 #87 的合入推定。2026-10-14 用户已明确授权智能体接管 Dev #489/#488/#486，继续验证、试行、合入及清理；本轮全部合入由智能体执行，不扩展到部署、共享数据库或其他未纳入任务。
+U7 进展（历史记录，2026-10-12，未合入）：Backend #185 与 Dev #486 的旧候选曾记录 CI success，来源为旧任务记录，不能放行本轮候选。原 U7/U8 候选都占用迁移 28；本轮须同步后按当前主干已用版本顺延，保留主干已有迁移与账户保护。账户 U5 的登录恢复接线见 r3 与 §11；账户 U8 消费审计按其独立范围推进，不由 U7 批准代签。
 修订记录：r1＝2026-10-12 草案经源码复核后定稿（四项取舍采纳；补齐 §6 合同；对齐恢复方案 KTD 与已合入的 recovery U1 实例身份）；同日获批并进入推送与 U1/U4 实施。
-r2＝同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口；保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号，补充 R13–R15、KTD11–KTD14、U7/U8，并细化 U5。新增内容未批准；不以原批准记录代签新增范围。
+r2＝同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口；保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号，补充 R13–R15、KTD11–KTD14、U7/U8，并细化 U5。保留原 r2 批准记录，不以该批准代签其他新增范围。
 r3＝2026-10-13 用户提交《登录流程方案》并指示「按此方案实施」——该指示即登录恢复范围的实施批准；当日实施合入（Backend #187、Frontend #76、Dev #504），合同定稿于 Dev `docs/svc-deploy/2026-10-13-login-recovery-contract.md`，实施记录见 §11。r3 为实施记录与三裁定回写，不改动 R/KTD/U 编号语义。
 需求来源：2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口（二进制与源码、环境准备、无初始密码开户与账户恢复），并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人：weichen；编制：Cursor Agent。
 主记录：本文；任务卡：Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。
@@ -233,13 +234,15 @@ flowchart LR
 
 凭据规则：独立前缀；只存摘要；用途 `activate`|`recover`；状态未使用/已消费/已撤销/已过期；密码变更后旧恢复凭据不可再用。符合 [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 与 [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)；保留现有 CSRF 校验。
 
-## 9. 风险与未授权范围
+## 9. r2 编制期历史记录：风险与当时未授权范围
 
-- 实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
+本节与第 10 节保留 r2 编制时点的原始边界，不表述本轮当前状态。当前批准、接管与交付范围见页首及 Dev #486；登录恢复实施记录见第 11 节。历史 NOT_RUN 保持原对象范围，部署及共享数据库操作仍须另行授权。
+
+- 编制时点的实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
 - 本轮交付终点：r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录；以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准，不推进 Dev gitlink、不推送／建 PR；启动／同步工具的任务元数据提交单独记录。
 - 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
 
-## 10. 规划进展与下一步
+## 10. r2 编制期历史记录：规划进展与当时下一步
 
 - r1 已批准；U1/U4 基础实现存在于当前固定源码，完整浏览器／故障／运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
 - 首选下一任务（待授权）：恢复方案 U8 的 SQLite 服务隔离＋本案 U7 账户一致性；先消除共享测试数据和不可归因密码变化，再落实 U5。U2/U3 保持后续。

docs/proposals/2026-10-13-iam-i1-acceptance.md

@@ -0,0 +1,52 @@
+# IAM I1 阶段 7 正式测试与验收候选
+
+日期：2026-10-13（北京时间）；负责人：weichen；测试执行：Codex；状态：用户已通过阶段 7。正式代码 Review、PR、CI、合入和部署分别记录，不由本页代签。
+
+用户在本会话回复“确认”，对应 Dev `4af5956`、Documents `064d4b5`、RDM `70e27b08` 的阶段 7 报告及下述明确缺项。按 Dev `policy/delivery.md` 进入智能体负责的阶段 8–9；同步后的新组合须重新验证与独立 Review。工作区清理、部署和 U3–U9 仍需各自授权。
+
+## 批准与范围
+
+用户回复“批准”，对应 [阶段 6 实施交付](2026-10-13-iam-i1-review.md) 的 Documents c023551、RDM b93908e、Dev 72ed8b4。批准原版本保留，恢复同步后的测试版本另列。本次按已获批 [统一方案 r1](2026-10-13-identity-role-permission-plan.md) 的 I1＝U1–U2 及 [权限合同](2026-10-13-iam-i1-permission-contract.md) 验证当前公开命令/API边界；不关闭 R1–R20 全部目标，不实施 U3–U9，不操作现有服务、生产数据库或真实账号。
+
+恢复处理包括：Dev Documents 同步冲突保留上游项目成员规划及三份 I1 批准文档原文；RDM 采用上游 `rdm.project.member.set-role` 合法命令 ID，保留 I1 身份包装。没有恢复旧权限旁路，没有变更 RDM pins；所有失败、恢复、同步收据保留。
+
+## 固定对象与完整收据
+
+| 对象 | 固定版本及结果 | 原始记录 |
+|---|---|---|
+| Dev 集成组合 | `10789653f989da6dc8a5ecc72d996dc2764208db`，同步目标 `ee9b437b22b49f96e1bc65f79417b22e8e82a37c`；`make test` 退出 0 | Dev 任务卡 SELF 收据 `ea7b77587b568d968594b0cb90c5362cab27d8eab1492da8cdea14d74e43d11d` |
+| RDM 完整组合及 HTTP | `70e27b08c65d8e966a11b1d30723414ec3e36f8e`，同步目标 `6c689caa1fa271c2a16174427df51a9b8919c4e0`；`make test`＋真实 HTTP＋产物/测试摘要检查退出 0 | RDM 任务卡 SELF 收据 `6e684a9047e43b0bdafbc71604ab5debe06bf437d1e3c95c4169d310f11d70c0` |
+| 独立最小重放 | `/root/i1_phase7_review` 未参与源码修改；先在 `58a23f8c` 重跑 39 个顶层 TestIAMI1，再审查作者材料并重跑最终 HTTP 10 组；退出 0 | 已导入 RDM 卡的完整 SELF 工具收据 `6bbb0f747e41c28d3c2327c587e162072a69495573def6f97a6d1657eb0b0d76`、`c7edde369566552acf4060500985a4a80ea004af80455446de9a215f64f89587`；工具标签不自行升级 |
+| RDM 二进制 | SHA256 `93aabc13041cf5a5c5636ebd0c88979a4d0f6fd0f79ba1272defc75176a75d81`；从实际组合产物运行，没有使用 Vite 或仅源码模拟 | `bin/PRODUCT_MANIFEST.json` 与上述工具收据 |
+| HTTP helper | SHA256 `a7d1d3260f4a62f0cb14b91339506419e9be306f2d0e3f7c74a6e77e76a458d4` | RDM `.task/artifacts/iam-i1-http-acceptance.py`；代码与测试材料已提交 |
+
+RDM 固定 Backend `0f192a481388184df39f81c28b0587a7e16ec3ca`、Frontend `4965de269a441a7df02b46d8533067f044e79b8b`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`；前端 dist 摘要为 `13acbec506086fe8`。Dev 新组合与 RDM 产品各自固定、各自检查；不能用 Dev 新接口存在证明旧 RDM pins 已消费其能力。后续只记录文本的提交不改变这些行为对象；最终记录提交及工作树检查另见任务卡。
+
+完整命令输出由 evidence 工具保存于两个任务卡，本文只提供判据和结果摘要，不转写输出、不提升来源等级。测试本地来源为 SELF；用户批准、受信 CI、平台账号独立批准及部署各自独立。
+
+## 需求到证据
+
+| I1 要求 | 正常／异常／边界判据 | 当前结果与测试 |
+|---|---|---|
+| R6/R12 系统与项目作用域 | 合法管理员创建/配置/任命角色成功；获 A 的 project.settings 者可改 A 名称，但全局 role/cap/admin transfer 被权限拒绝；body 伪造 actor/owner 不改变认证身份 | PASS；注册命令 TestIAMI1＋真实 Bearer HTTP，先检查命令已注册，再要求权限原因，不把未知命令或 schema 拒绝计通过 |
+| R7/R8 管理资格不授 B 业务访问 | /api/me 明确实际平台管理员身份；A 创建者且管理员对 B 的成员、权限、归档和审计操作拒绝，当前项目清单不显示 B；合法角色获授者可建 B | PASS；真实新实例 /api/commands/{id}＋项目/审计相关 Go 正反例 |
+| R9 创建者也受硬 cap | 已确认 Alice 在 A 的 doc.write 允许并有 allow 覆盖；保留 default=true，只关闭 cap；实际高危命令确认后因上限拒绝 | PASS；HTTP 隔离 cap 变量；Go 创建者 cap、平台 cap、未知角色动作与读策略故障等边界 |
+| R11 停用/换岗/旧覆盖 | 旧 doc.write allow 后换到未定义该动作角色，执行及解释拒绝；停用前 doc.read 允许，停用后消失，执行/矩阵均显示已停用原因 | PASS；HTTP 精确原因与前后矩阵＋TestIAMI1；没有借其他已存在拒绝原因替代停用测试 |
+| R18 私人原件/草稿与读取范围 | 真实 held 原件仅上传者可确认；管理员与未知 batch 获相同不透明拒绝且无实际 B 项目或文件信息；私人候选、差异、快照、审核状态、聚合读面/模型输入按当前 owner/阶段/grant 判定 | PASS；真实 HTTP 上传确认＋SQLite/已注册命令实际正文和持久状态负例；本次不声称完整 U5/U6 资源职责模型已实现 |
+| R12/R18 幂等回执和 outbox | 操作/项目/主体/资源不匹配 opID 不返回他人回执；合法重放保留；outbox 归属与业务在同 Tx 写入，仅送到实际 owner Host，未知旧归属保持 pending | PASS；TestIAMI1 实际回执和 SQLite 状态＋既有原子/失败重试回归 |
+| 注册和组合回归 | 当前 set-role 等命令 ID 正确注册并保留身份校验；根页为实际 React embed、未认证命令 401；RDM 29 项 Web、全部 Go；Dev 治理、公开边界/pins、库、Core、Backend、Frontend/UI、命令检查 | PASS；两套 make test 及当前产物真实 HTTP；不把 HTML 获取等同于浏览器交互验收 |
+
+## HTTP 测试过程及独立复核
+
+实际 HTTP 使用全新临时 SQLite、三名合成主体和随机 API Key；平台首位管理员在其他开户之前由可信 CLI 建立，/api/me 核验其真实身份。服务仅绑定随机回环端口，强制关闭执行工具，环境不继承 DSN、服务实例绑定或模型密钥，HTTP 禁用代理。真实私有会话和确认卡到最终回执的路径执行高危命令；native 项目仅为确认上下文，不作为 RDM project.create 政策的通过证据。测试结束只终止自己的 PID；成功临时场景回收，失败场景保留用于诊断，不修改既有实例。
+
+初次 HTTP 在未经过高危确认流程时拒绝，该结果没有被计为权限通过；补齐确认路径后重验。首位管理员创建顺序错误同样保留失败证据，不关闭原防接管机制。独立审阅又指出停用/默认与 cap 的两处测试假阳性风险；已分别加停用前后读权及原因检查、保留 default/allow 只关 cap。最终独立 HTTP 重跑 10 组通过，审阅范围内无剩余 Critical/Important。
+
+## 缺项、兼容边界与验收决定
+
+- 全产品浏览器交互和真实模型任务级前后对照：NOT_RUN。本轮 I1 没有业务 UI 实现，已规划出口为直接命令/API与当前回归；完整浏览器及 Agent 闭合属后续单元。工具描述真实模型对照仍是明确缺项：本轮未建立固定模型/配置/任务集/费用范围，mock 与 HTTP 不能替代模型行为。补救为另行明确测试条件后执行任务级对照，在后续 Agent/全产品验收前闭合；不能计 PASS。
+- PostgreSQL、多实例、在途后台最终提交 epoch、账号有效态/恢复、多职位/项目选用及完整三权：本轮完整验收未执行；按 U3–U9 依赖和各自授权推进，不迁移生产 DB。
+- 已批准的 I1 默认拒绝保留：无范围证明的 whole-prefix 知识撤销和公共全量自举拒绝；没有可信 Host 项目证明/资源分类的共享读取拒绝；audit.read 不随管理员或创建者自动授予；旧未知归属 outbox 不推测 owner。恢复这些能力须新公开提供者/消费者合同，不由此次测试擅自补接口或改 pins。
+- PR/受信 CI/GATE、正式阶段 8 Review、合入、部署及工作区回收：NOT_RUN。独立提前审阅和本地重跑不代替平台条件。
+
+原提交给用户的阶段 7 决定范围：固定 I1 U1–U2 的命令/API边界与回归结果，以及上述明确缺项/既定兼容限制。提交时结论为“本地测试已通过，待人工验收”；用户随后回复“确认”，已在页首记录为阶段 7 通过。原长期方向及下一任务仍为获批方案 I2/U3，需另行授权，当前不启动。

docs/proposals/2026-10-13-iam-i1-permission-contract.md

@@ -0,0 +1,193 @@
+# IAM I1 权限边界与公开扩展合同 r1
+
+负责人：weichen；编制：Codex；更新时间：2026-10-13。
+依据：[用户、职位角色与分层权限统一方案 r1](2026-10-13-identity-role-permission-plan.md)
+（Documents `a088809`，原文 SHA256 `39b8e9a6e078dc509bd80118c1807ce6ed23e4466e5902b51f4bfa255d55c0a1`）。
+用户已批准该方案并授权 I1＝U1–U2，原实施终点为本地人工评审；阶段 6、7 已分别获用户“批准”“确认”。当前按 Dev policy/delivery.md 进入智能体 Review、PR、CI 与合入，状态及固定对象见[验收记录](2026-10-13-iam-i1-acceptance.md)。迁移、部署、工作区清理及后续增量未授权。
+本合同为 U1 产物，冻结已批准语义与提供者／消费者责任；新增公开接口仍须对应模块实现、固定版本及合同验证，不能据此宣称能力已提供。
+源码、业务测试及运行验收结果以 I1 任务卡的工具收据为准；本文不复制测试结果。
+
+## 1. 当前增量与最终目标
+
+最新用户裁定取代旧“管理员拥有全部业务权限”“创建者不受职位 cap”“每人仅一个生效职位”的现行解释。
+历史会议、原方案、旧批准记录和 `.tmp` 原件保留；旧结论只用于解释历史行为。
+系统管理员管理系统与授权主数据；读取他人业务内容必须有具体项目和资源授权。
+职位支持一职多人、一人多职，项目明确选用有效职位绑定；新任命不自动增加既有项目权限。
+通用职位、绑定、默认／上限与系统授权迁至 Backend 是已批准设计；RDM 保留项目成员、项目选用绑定、项目覆盖、资源及文档职责／状态。
+
+| 层 | I1 范围 | 后续范围 |
+|---|---|---|
+| 文档 U1 | 需求裁定、动作目录、角色 cap、隐私、公开扩展申请与验收合同 | 按固定公开版本补提供者／消费者验证 |
+| 执行端 U2 | 在现有 RDM 单绑定和旧管理台账上收口可达越权路径；实际结果另见任务卡 | 账号有效态、受控目录及恢复能力 U3；通用职位与多绑定 U4；项目明确选用 U5 |
+| UI／Agent／迁移 | 不以文档保存证明能力已就位 | 矩阵、统一工具、完整撤权与数据迁移分别按 U7–U9 授权实施 |
+
+I1 的 legacy 单绑定适配不是最终多职模型：旧账号至多一个专业角色，项目尚无显式 bindingId 集合。
+已有绑定必须先检查角色有效态、动作定义与 cap，再计算默认／项目覆盖；停用或失效不能回落为无绑定成员默认。
+未绑定旧会员的关系默认只能作为已登记的 legacy 兼容来源，仍受平台 cap、项目关系和资源限制；不能伪装成新的职位绑定或最终模型的资格证明。
+U4/U5 迁移后无有效选用绑定的业务动作默认拒绝；迁移差异须单独评审，不在 I1 静默改造数据。
+旧 RDM 管理台账在 I1 仅为明确系统管理动作的兼容来源，不能生成项目成员关系、业务 grant 或资源 bypass；`Host.IsAdmin()` 同样不能代替业务授权。
+I1 还将当前分发 Host 的平台管理员身份显式适配为上述四项受保护系统动作；必须同时满足认证 actor 与 Host.Owner 一致，不接受 body 的管理员声明，也不把该适配扩展到其他未知动作或业务动作。细粒度系统 grant 的通用权威仍属 U4。
+
+## 2. 动作目录与配置主体
+
+scope 由受信 `ActionMeta`／权限注册表确定，不接受请求自报 scope，不按字符串前缀推断。
+系统动作只消费系统来源；项目动作限定实际项目；资源读取还须匹配实际资源、分类与读取动作。
+下表为 I1 稳定动作合同。“后续”项仅冻结目录，当前尚未提供相关接口。
+
+| actionId | scope | 配置／执行主体 | 附加边界 |
+|---|---|---|---|
+| `system.roles.manage` | system | 受保护系统管理者 | 角色创建／编辑／停用／读取；不能经项目覆盖获取 |
+| `system.roles.assign` | system | 受保护任命者 | 任命在可委派上限内；不能间接授予受保护系统权限 |
+| `system.policy.manage` | system | 受保护策略管理者 | 平台 cap 与权限政策；保护最后有效管理者 |
+| `system.admin.transfer` | system | 当前有移交资格的系统管理者 | 明确移交目标；旧 `rdm.perm.transfer` 映射此门禁 |
+| `project.create` | system | 有明确系统／职位建项 grant 的有效用户 | 创建者管理 cap 资格见 §3；不接受项目 allow |
+| `project.archive` | project | 目标项目的合法管理者 | 保留稳定 ID；纠正旧目录误标的 system scope |
+| `project.settings` | project | 目标项目创建者／委任管理者或合法获授者 | 仅本项目设置与覆盖；不能进入全局角色、cap 或管理员移交 |
+| `member.manage` | project | 本项目合法管理者 | 成员及选用角色管理；不得替他人做本人受限重选 |
+| `duty.assign` | project | 本项目合法分配者 | 候选有效成员＋对应资格 cap＋三权异人；分配不代签 |
+| `stage.advance` | project | 有阶段推进 grant 的成员 | 阶段准入准出、当前状态 |
+| `doc.read` | project | 有读取 grant 的成员 | 文档阶段范围＋受控正文职责／明确资源授权 |
+| `doc.write` | project | 有编制资格的指定编制人 | 具体文档、当前状态、冻结版本；不因管理权取得 |
+| `doc.publish` | project | 有发布资格及对应职责的成员 | 固定整文版本及已批准状态，不替代批准签字 |
+| `review.participate` | project | 有评审资格的指定审核／批准人 | 按具体职责决定可执行动作；只能批注及通过／驳回 |
+| `trace.edit` | project | 有追溯编辑 grant 的成员 | 文档层／项目层裁定范围与状态分别检查 |
+| `knowledge.publish` | project | 有发布 grant 的成员 | 明确提交／发布；不能借发布读取私人原件 |
+| `audit.read` | project | 有明确业务审计 grant 的当前成员 | 独立于正文读取；当前角色动作 cap、平台 cap 与范围均满足 |
+| `system.settings.read`／`system.settings.write`及设置子项 | system，后续目录 | 对应系统管理者 | 模型、插件、Agent、检索等设置分项授权 |
+| `system.users.view`／`create`／`edit`／`disable`、`credential.recover` | system，后续目录 | 对应账号管理者／恢复提案者 | 编辑资料不能改管理员资格；恢复见 §6 |
+| `permission.manage`、`knowledge.read`、`trace.read`、`document.read`／`export`、业务审计导出 | 后续目录，project | 按注册元数据和当前业务关系 | 当前 `doc.*` 等 ID 不静默重命名；新增需公开版本映射 |
+
+`audit.read` 是 I1 新独立项目动作：必须由合法项目管理者在上限内明确授予，或来自明确配置的角色默认 grant；管理身份本身不提供审计 grant。
+非成员 admin、仅持 `Host.IsAdmin()` 的主体、无审计 grant 的创建者、cap 已收紧的旧获授者均拒绝。
+系统安全日志只披露必要安全动作、结果及不透明对象标识，不能包含业务正文、文件名、项目名、内容摘要或完整业务差异；业务审计仍走 `audit.read`。
+
+| 旧入口／元数据 | I1 兼容规则 |
+|---|---|
+| `rdm.role.create`／`action`／`disable`／`list` | 命令 ID 保留，系统门禁改为 `system.roles.manage` |
+| `rdm.role.assign` | 命令 ID 保留，系统门禁改为 `system.roles.assign` |
+| `rdm.perm.cap` | 命令 ID 保留，系统门禁改为 `system.policy.manage` |
+| `rdm.perm.transfer` | 命令 ID 保留，系统门禁改为 `system.admin.transfer` |
+| 旧 `project.archive` scope=system | 目录版本标记改为 project；具体项目重验；旧系统覆盖写法不继续接受 |
+| `project.settings` 作为全局门禁 | 不兼容保留；项目 grant 不被翻译成系统 grant |
+| 未登记 ID、旧示例 `admin.transfer`／`business-audit.read` | 不是隐式别名；拒绝执行／写入，采用上表稳定 ID 或显式版本映射 |
+
+## 3. cap、创建者资格与撤权
+
+最终系统动作路径为：有效账号 ∩ 受信系统动作 ∩ 平台允许范围 ∩ 受保护规则 ∩ 明确系统 grant 或完整系统职位默认路径；项目覆盖不能参与。
+最终项目动作对每个有效且本项目选用的 binding 建立完整路径：
+
+`有效成员／管理关系 ∩ 已定义动作 ∩ 平台 cap ∩ 本职位 cap（含范围） ∩ 项目覆盖／当前默认 ∩ 资源关系 ∩ 阶段／状态 ∩ 文档职责`。
+
+至少一条完整路径允许才放行，不拼接不同职位的 grant 与资源范围；平台禁止、项目明确 deny 和资源禁止对所有路径生效。
+`allow` 只能替换默认 grant，不能创造未配置动作或越 cap；`deny` 阻断该成员该项目该动作的全部路径；`inherit` 使用当前默认。
+停用、解绑、换岗、cap 收紧、账号停用和成员移除后重验当前资格；遗留 allow 不能复活旧权。
+创建者关系只提供本项目管理默认，其有效角色 cap 与平台 cap 仍先验；A 创建者不能管理 B，不能读取私人资源或代签。
+
+建项前校验创建者角色组合具备 `project.settings`、`member.manage`、`duty.assign` cap 资格；这些角色 default 可关闭，由创建者关系提供项目内管理默认。
+最终创建项目、创建者成员关系及所选 binding 在同一领域事务落地；宿主绑定以可恢复状态和幂等对账处理。
+已有项目遇 cap 收紧保留 `createdBy` 与历史归属，阻断受影响动作并说明等待重新任命；不能扩大 cap 恢复管理。
+
+受限“重新选择本人项目职位”是后续独立动作，不复用 `project.settings`：仅当前有效负责人本人，从账号当前有效任命中明确选取具备管理 cap 的 binding，按项目当前版本确认。
+仅此动作可使用尚未被本项目选用的任命；它不改变负责人、不恢复遗留 allow、不清除 deny、不授予资源读取或三权。
+系统任命者不能代选；无合格任命时保持等待。项目内移除最后负责人须保护实际可操作管理资格；系统必要撤权不因这一保护而被阻止。
+
+## 4. 资源、正文与审计读取合同
+
+认证 actor、资源真实 owner／projectId／resourceId／分类来自执行端受信上下文；客户端标识只能定位对象，不能授予访问。
+本人的私聊、私人原件和个人草稿属于私人资源；在当前账号有效且资源确属本人时按自有资源规则读取，不因放在项目下变为受控正文。
+受控文档正文即使物理由本人生成，也须具体文档职责或明确资源授权、当前项目资格及当前 cap；真实 owner 相等不绕过受控规则。
+审核／批准职责仅开放送审正文与明确关联材料，不开放未分享原件、私聊或私人草稿；分享只授予指定资源的只读能力，不授予编写或签字。
+项目知识只由明确提交／发布产生；成员身份不意味着私人资源或所有受控正文全量可读。
+历史签字、职责与事件保留；历史内容读取依旧使用当前授权，时间点重建不恢复当时权限。
+读取、下载、列表、搜索、stream、模型上下文均遵循同一分类和当前判定；裁剪列表后再返回数量／分页，拒绝不得泄露存在性。
+I1 现有项目聚合审计 DTO 含正文预览，故除 `audit.read` 外还必须具备当前完整项目 `doc.read`；阶段范围受限者不能通过全项目聚合审计取得范围外正文，按资源裁剪的细粒度审计由 U5 完善。具体文档导出检查该文档的 `doc.read` 和阶段范围，不把审计 grant 当成导出 grant。
+I1 私人 pending/rejected 草稿仅提案人可读与决定；知道 proposalId、拥有项目管理权或文档职责都不能采纳／拒绝他人私稿。已采纳正文仍按当前文档读取授权逐项过滤。原件批次确认只限上传者本人，管理台账可披露经当前管理授权限定的业务元数据，不能因此读取或确认私人原件。
+
+## 5. 公开扩展：现有能力与四要素申请
+
+以下现有公开面是 I1 原合同的 Backend `0f192a481388184df39f81c28b0587a7e16ec3ca` 快照，参考 `pkg/extension/extension.go`、`host.go` 与 `surface.txt`，不导入 Backend internal。
+该快照的 `SurfaceVersion=2.11.0-experimental` 源码声明不是部署或消费者可用性证明，也不代表后续主干能力；同步后的组合必须重新核对提供者及消费者实际固定版本。
+
+| 现有能力 | 提供者／消费者 | 足够性与边界 |
+|---|---|---|
+| EXT-18 `AdminProvider.IsAdmin()`／`Request.HostProjectID` | Backend 分发 Host → RDM | 平台管理身份与宿主项目定位；不能证明系统分项授权、账号有效态、RDM 项目关系或业务访问 |
+| EXT-19 `AccountLister.ListAccounts(cursor, limit)`，`AccountEntry{Owner,Valid}` | Backend → 授权目录消费者 | 最小身份目录，非资料页；不提供姓名、联系方式、多职绑定或写权；缺能力不允许新增产品路径无校验继续 |
+| EXT-8b `ResourceAuthzQuery`／`ResourceAuthorizerV2`／注册口 | Backend 构造受信查询 → RDM 提供策略 → Backend 执行 | 现有六要素为 actor/action/resourceType/resourceId/owner/projectId；读取专用，V2 对域内读权威（含自有命中）；未注册的 V1 回落不能替代 I1 必需的资源限制 |
+
+以下是 U1 冻结的公开扩展申请四要素，符号为合同草案，I1 不新增导出实现、不更改 surface 版本。
+
+| 申请 | 场景 | 希望的公开符号／路径 | 现有注册点为何不足 | 兼容方式 |
+|---|---|---|---|---|
+| IAM-P 政策与动作目录 | UI／命令／工具需查询 scope、cap、有效绑定、权限解释与版本；角色通用权威迁移后供 RDM 同源判定 | 可选 `PermissionCatalogProvider`、`AuthorizationProvider`；公开目录／判定／解释与授权管理预览提交服务 | `IsAdmin` 只有布尔身份；`ActionMeta` 在 RDM 内部；EXT-8b 仅资源读，无法供系统管理或管理写入事务使用 | 新可选接口及版本化 DTO；旧 Host 不加必实现方法；RDM legacy 适配与新权威切换分别固定版本 |
+| IAM-D 受控人员目录 | 项目选人需要稳定身份、有效态和最小辨识字段，系统资料管理需独立授权 | 可选 `AccountDirectoryProvider` 与版本化查询／投影 DTO；既有 EXT-19 保留 | `AccountEntry` 仅 owner+valid，没有字段权限、搜索模式、可披露辨识资料及多职；私自扩展所有账号资料会扩大披露 | 新可选接口；旧 `ListAccounts` 不改变返回隐私范围；不得向旧消费者塞入联系方式 |
+| IAM-R 资源与当前政策上下文 | 跨原件／草稿／正文／审计分类，查询当前 policy／duty epoch，撤权影响读面与后台提交 | 新版资源查询／决策 DTO 及可选政策上下文提供者；保留 `ResourceAuthorizerV2` | 六要素无分类、职责／版本／epoch；bool 返回不能携带可披露原因与版本，读适配器不能承担写入事务 | 新版本资源接口或明确 DTO 增补；禁止未知字段零值放行，必需提供者缺失即拒绝；版本协商与双读仅作诊断 |
+| IAM-C 账号本人恢复 | 管理者只能提出恢复，账号本人经独立证明才能取得可兑换设密能力 | 公开恢复提案／本人确认／兑换回执合同，隔离恢复凭据与业务会话 | `IsAdmin`、目录、资源授权均不提供本人证明或安全凭据交付，不能用个人资料代替 | 新路径／可选能力，不向普通管理员交付目标账户可兑换 Key；旧不满足证明的线上路径明确拒绝 |
+
+| DTO | 必须冻结的字段与版本语义 |
+|---|---|
+| `PermissionDescriptor` | `actionId`、`label`、`description`、`scope`、`resourceTypes`、`group`、`conditions`、`delegationLevel`、`risk`、`descriptorVersion`；稳定 ID 不随改名变化，新增项默认拒绝 |
+| 授权查询／解释 | 受信 actor、actionId、资源定位与实际归属、当前状态／版本、选用 binding；输出 allow/deny、可披露 reason、来源链、`authorityEpoch`；解释只限本人或有权管理对象 |
+| 目录查询／投影 | 稳定 userId／owner、valid、获授权姓名／登录名／工号／职位投影、cursor/limit、精确／模糊模式及字段／状态过滤、`directoryVersion`；未授权字段不返回、不参与匹配；电话、邮箱、部门、备注只在独立授权资料面披露 |
+| 管理 patch／预览 | 固定对象 ID、expectedVersion、authorityEpoch、patch 摘要、幂等键；预览不代替提交授权，非法对象／越 cap／冲突整体拒绝；跨模块写入不冒充单库事务 |
+| 资源决策扩展 | 受信分类（私人／发布知识／受控正文／业务审计）、resourceVersion、policyVersion、dutyVersion、authorityEpoch 与决策原因；缺失或不认识分类拒绝，禁止请求自报归属 |
+
+目录 r1 的 scope 修订不能只改显示标签；执行端必须同时拒绝错误作用域写入。公开版本须同时登记导出面快照、版本号、变更表、提供者／消费者合同及固定组合。
+缺必需能力、未知动作／字段／状态、政策读取失败、归属不一致、过期版本、失效绑定均 fail-closed；不能用 `Host.IsAdmin()`、缓存 allow、V1 粗粒度授权或手填 owner 兜底。
+通用迁移前 legacy 台账只在其声明范围使用；迁移时保留 userId／owner／roleId／projectId／createdBy，禁止双主写入，不生成旧管理员的永久业务 grant，回滚不复活旧越权。
+
+## 5a. 当前公开能力缺口的 I1 处理
+
+以下是 U2 收口所需的默认拒绝策略，不是后续能力已实现声明；本地候选的实际验证见 I1 评审记录。
+
+- 未归属事件盘点、归属迁移、全量 outbox 队列必须另有 owner 批准的精确资源范围。I1 的 `Runtime.SetLegacyAccessAuthorizer` 为实例内受信集成点，查询绑定 actor/action/project/seq；不存在用户自授命令，不持久化、不跨重启继承。无提供者或提供者失败即拒绝。迁移另检查目标 `knowledge.publish`。
+- 当前 `Host.KnowledgeDelete` 仅能删当前 owner 的整个插件前缀，不能限定项目。`rdm.knowledge.revoke` 先验证目标项目 `knowledge.publish`，再明确拒绝执行，不能借 A 项目 grant 删除 B 项目索引。
+- `rdm.init` 当前实现读服务器路径并写全量未归属域，公开命令拒绝；可信本地 CLI/bootstrap 仍需操作授权。本轮不另造公开目录读取和项目初始化能力。
+- Host↔RDM 绑定须证明两个项目的管理资格；旧映射行与请求中的 HostProjectID 都不是此证明。I1 的实例内受信 Host 项目授权集成点必须绑定 actor/action/两个实际项目，缺失即拒绝绑定、解绑及基于映射的共享访问。旧映射不自动升级成授权证明。
+- 现 Backend `project/list` 授权成功后会返回项目下全部 owner 工件元数据，缺少逐资源 owner 裁剪，I1 拒绝此聚合共享。项目级 search 无发布分类证明时也拒绝跨 owner 检索；自有私人资源的具体读取路径保留。
+- 项目聚合 DTO 尚无安全的按阶段裁剪投影时，要求当前完整 `doc.read`；章节/文档接口按实际对象检查阶段。业务审计另需显式 `audit.read`。后续安全裁剪不得用 UI 隐藏代替执行端检查。
+- 新 outbox 回执以事务内 `rdm_audit_outbox_scope` 记录实际 project/owner，只送入对应 owner 的 Host；旧未知归属回执保持 pending，禁止按下一调用者猜测归属。该关联表为新增领域元数据，无历史自动归属，本轮未执行生产数据库变更。
+- status/resume/cancel 按私人批次的真实 owner 判定；恢复另检查当前项目写权及生命周期，取消仅保留本人停止私人任务的能力。opID 重放必须绑定操作、项目、主体与实际资源，冲突不能返回另一资源回执。
+
+| 扩展申请补充 | 场景 | 希望的公开符号／路径 | 现有注册点不足 | 兼容方式 |
+|---|---|---|---|---|
+| IAM-K 项目级知识撤销 | 合法 A 项目发布者仅撤销 A 已发布资源 | 可选项目/资源限定的知识撤销 DTO 与提供者；实际命名待模块评审 | EXT-9 whole-prefix 删除跨同一 owner 多项目；无可靠逐 ref 删除契约 | 新可选公开接口，旧缺失拒绝；固定提供者/消费者版本，不改 pins 猜测能力 |
+| IAM-H 宿主项目管理证明与资源裁剪 | 绑定需双方管理证明，共享读取需当前项目授权与实际资源分类 | 受信 Host 项目授权查询/证明及逐件资源投影提供者；实际命名待模块评审 | EXT-18 仅给当前 actor 的管理员位与项目定位；EXT-8b project/list 是整面 bool，无逐件过滤 | 新可选契约、权威对象与版本；旧映射只作定位，缺失默认拒绝；RDM 私有受信适配不能冒充 Backend 公共实现 |
+
+## 6. 账号恢复证明与交付
+
+普通管理员仅发起恢复提案；本人须使用管理员不能单方改写或取得的既有有效会话确认，或预先建立的本人恢复证明，才取得可兑换设密能力。
+姓名、电话、邮箱、工号均为可选资料，不自动成为恢复证明；新证明建立或更换不能由恢复提案管理员单独完成。
+无独立本人验证条件时拒绝线上恢复，不向普通管理员签发可兑换的目标账户 Key；异常人工恢复由另行批准的 owner 操作处理。
+恢复能力限制为一次消费、目标账号、设密用途与有效期，不生成业务会话；消费后本人使用正式凭证重新认证。
+本合同不证明恢复实现已具备；U3须验证“管理员提出恢复后自行设密接管业务身份”负例，旧路径未收口前 R7 不得闭合。
+
+## 7. 验收矩阵与证据边界
+
+R1–R20 到 RDM 原 UR／SR 的映射由 RDM `docs/proposals/2026-10-13-iam-i1-contract-adoption.md` 维护，原需求 ID 不重新编号。
+
+| 判据 | I1 文档核对 | 行为验收归属 |
+|---|---|---|
+| 系统动作不可由项目 override 或 `project.settings` 获取 | §2逐动作 scope／旧命令映射 | U2：普通成员合法本项目设置成功，全局角色／cap／移交拒绝 |
+| 创建者仍受有效角色 cap，遗留覆盖不越界 | §1／§3 | U2：创建者 cap=false、角色动作未定义、停用／换岗及旧 allow 负例 |
+| 管理员无业务身份旁路，审计独立授权 | §2／§4 | U2：admin／Host.IsAdmin 非成员及无 audit grant 拒绝；合法成员 audit grant∩cap 正例 |
+| 私人资源与受控正文分开 | §4／EXT-8b 消费边界 | U2 可达路径；U5/U6 统一资源及职责、当前版本完整验收 |
+| 一职多人、一人多职、项目明确选用 | §1／§3／IAM-P | U4/U5：新任命不扩既有项目、解绑再任命不复活、完整路径不拼接 |
+| 账号目录敏感投影与本人恢复 | §5／§6 | U3：未授权字段不匹配／不返回；管理员不能取得本人兑换凭据 |
+| 冻结文档轮次、撤权与迟到事件 | §3／§4／IAM-R | U6/U8：当前职责与 cap 重验；旧卡／Surface／SSE／后台最终提交拒旧 |
+| 单权威迁移、版本兼容、完整组合 | §1／§5 | U4/U9：旧→新差异、双主拒绝、当前固定提供者／消费者和制品验收 |
+
+U1 只检查文档差异、链接、动作与 scope 一致性、R1–R20 追溯及原方案摘要保持；无行为变更，不运行业务测试。
+本地检查来源为 SELF；审核与正式验收须按任务规则同步对象、独立重放并核验 GATE／REPLAY 身份及 SHA。
+公开实现、业务测试、浏览器、真实模型、数据库迁移、服务运行、部署与正式验收均不能用本合同的保存结果代替。
+
+## 8. I1 宿主改名投影的已批准修订（2026-10-13）
+
+用户已批准[委任改名契约修订与修复计划 r1](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/src/commit/4ee4eb99a95460d6660f05a67181357b67e2e956/docs/proposals/2026-10-13-iam-i1-host-projection-amendment.md)，批准对象原文摘要为 `3eee5714cce974ce13229b3e184bc3aa763a5e0819fdf7dcf088dafe68b1ed2a`。正文维护在 RDM 一处；批准状态与实际实现、测试、Review、CI 和合入分开记录。
+
+合法项目 `project.settings` 可以委任改名；现有 `ProjectHost` 的管理修改保持 owner-only。RDM 仅对这一动作建立受信的单目标投影适配：先以实际认证 actor 判定当前项目设置权及状态，再核对域／宿主绑定／物理项目的完整身份，只用受信创建者的 scoped Host 执行该 hostID 的改名。不借创建者身份重新授权，不把投影句柄返回或传入其他业务动作；无需额外 `doc.read`，私人读取和 Native work 不扩权。
+
+首次改名要求 ready；失败恢复必须对应同事务持久的改名意图、同一主体／项目／host／创建者／目标与版本，并再次检查实际 actor 的当前资格。未知 failed/create 不恢复，未就绪时读／work 仍拒绝。该元数据只属于 RDM 项目投影，不修改旧账号或项目身份，不实施生产迁移，也不冒称完整跨库 epoch。
+
+命令与 HTTP lifecycle 都使用原请求 Host 审计实际操作者。Backend 审计的 `Actor=plugin:rdm` 继续表示插件来源；业务 actor 由受信 Host.Owner 和审计 evidence.actor 记录。命令保留既有 DTO，HTTP 保留 core.Project 及公开元数据的脱敏设置；不得带出物理 owner 的原始管理设置。
+
+本修订不新增 Backend 公开符号或放宽其 owner-only 管理规则。正式通过须覆盖合法委任及无读取权管理、cap／停用／非成员、实际归属变化、失败／重启／未知恢复、两入口审计和真实 HTTP；未通过当前组合验证时不能声称 I1 完成。

docs/proposals/2026-10-13-iam-i1-review.md

@@ -0,0 +1,73 @@
+# IAM I1 实施候选与人工评审记录
+
+负责人：weichen；实施协调：Codex；日期：2026-10-13；状态：阶段 6 已由用户批准；阶段 7 测试候选已形成，待用户验收。原阶段 6 对象与收据保留，最新状态见下方批准记录及验收报告。
+
+本页维护已批准统一方案 I1 的实际进展；原方案原文摘要保持不变。本轮只执行 U1–U2，交付终点为“给我评审”，不启动后续增量。
+
+## 批准对象与当前候选
+
+- [统一方案 r1](2026-10-13-identity-role-permission-plan.md)：用户已批准并授权 I1＝U1–U2；原文 SHA256 `39b8e9a6e078dc509bd80118c1807ce6ed23e4466e5902b51f4bfa255d55c0a1`，Documents `a088809` 保存原批准快照。
+- [I1 权限合同 r1](2026-10-13-iam-i1-permission-contract.md)：稳定动作与 scope、角色／平台 cap、独立业务审计、隐私及公开扩展申请。提供者缺失默认拒绝，合同文档不能证明接口已提供。
+- RDM 初始 R0：`b1fe932883d2a55f0373bb0930950da3d12d2b5e`；同步后的 main：`2f1a36f55a4979262e386150af26085d4d15b2a1`，包含职责批量分配与权限覆盖删除。两项注册冲突已保留主干功能并接入身份包装；组合结果须重新测试。
+- RDM 已独立审阅的行为候选：`dfb9c407858173ba501a623631c17643bd1985b5`（代码截至 `4e3d7665e973838b77d6e81164b8d70540de907d`，后者之后仅同步任务卡；之后旧测试断言／import与证据记录继续收口）。最终收据与记录提交可能前进，测试有效性按行为文件／组件是否变化核对。
+- [Dev 任务卡](/home/weichen/projects/Agent-System-Dev-wt-feature-iam-i1-permission-boundaries/.task/feature-iam-i1-permission-boundaries.md) 与 [RDM 任务卡](/home/weichen/projects/Agent-System-RDM-wt-feature-iam-i1-permission-boundaries/.task/feature-iam-i1-permission-boundaries.md) 保存启动、红测、失败、同步、绿测完整工具输出，来源均为本地 SELF。
+
+## 本次行为变化
+
+| 边界 | 候选中的具体变化 | 对应要求 |
+|---|---|---|
+| 系统与项目 | role/cap/任命/移交走独立受保护系统 action；项目 settings 不能授予这些动作；当前 actor 必须匹配 Host.Owner。新增 unset 也检查注册项目 scope、实际成员与当前管理权 | R6/R8/R12 的 I1 部分 |
+| 当前资格与 cap | 创建者、管理者与成员均受平台 cap；已绑定职位先检查存在／有效／动作定义与 cap；停用、换岗及旧 allow 不能回落或越界。矩阵解释与执行共用评估器 | R9/R11 的当前单绑定部分 |
+| 项目业务访问 | 去掉域管理员和 Host.IsAdmin 的跨项目业务旁路；项目清单按当前成员关系；归档仍可由合法 archive 权限恢复，其他业务写入拒绝 | R7/R8/R11 的 I1 部分 |
+| 业务审计 | 新独立 audit.read，平台 cap 初始关闭，关系默认不授予；实际授权成员还须当前完整 doc.read。聚合审计含正文预览，不能借阶段受限读权读全项目 | R7/R18 的 I1 部分 |
+| 正文读取与导出 | 章节／文档按真实对象检查阶段；标题导出只接受唯一匹配、按同一解析目标授权与生成；差异、审核状态、法规快照检查阶段／真实项目归属。无法安全阶段裁剪的聚合 DTO 要求完整读权 | R12/R18 的 I1 部分 |
+| 私人原件与草稿 | pending/rejected 私人提案只允许提案人查看／采纳／拒绝，采纳还验编制职责；上传原件只允许本人确认；管理上传视图为元数据；历史上传清单不跨项目混入 | R18 的当前可达路径 |
+| 私人批次 | status/resume/cancel 先按真实 owner 判定；私有与不存在统一不透明拒绝；恢复另验当前 doc.write／成员关系／职位／cap／生命周期，不能凭旧属主身份重新入队；本人停止私人流程保留 | R11/R12/R18 的当前入口 |
+| 模型输入与写回结果 | draft.compose 发模型前需要目标正文读取范围；结论确认在返回 stored text 前需完整 doc.read。写权不能代替读权 | R12/R18 的当前入口 |
+| 回执归属 | opID 使用 JSON 元组绑定操作／项目／主体／资源，短路与事务内重放一致，旧不可信 key 拒绝。outbox 新回执以同事务关联真实项目与 owner，只送入对应 Host；旧未知归属项保留 pending | R12/R18/R20 的当前入口 |
+
+完整多职位、项目明确选用绑定、账号有效态、恢复证明、三权全模型、政策 epoch 与所有后台最终提交撤权均未在 I1 实现。这里的 R 行不是完整 R1–R20 关闭声明。
+
+## 验证与证据
+
+U1 为规范文本更新：核对本地链接、17 个稳定 action/scope、R1–R20 追溯、批准原文摘要及固定 RDM 初始基线的 08 核心 R1–R5；无业务行为，不制造文本单元测试。
+U2 先运行真实临时 SQLite 与已注册命令负例，再修改实现并保留相应合法流程。旧测试中期待 admin 跨项目、停用角色回落、他人代确认等断言按批准合同修正，正常路径仍通过真实授权夹具运行；没有删除失败用例以绕过测试。
+
+| 检查 | 当前结果 | 证据边界 |
+|---|---|---|
+| 初始负例与审阅补漏 | 已真实复现并记录；红测保留 | 包含越权写入、实际正文／原件元数据回执、未知归属写入与跨 owner 审计投递；编译失败与夹具失败也保留，不冒充行为证据 |
+| 新回归与相关旧流程 | 通过（SELF）；独立重跑 39 个顶层 I1 回归 | 工具记录命令、HEAD、dirty 摘要与完整输出；本轮编译失败、夹具失败和“no tests to run”均保留，不计为行为通过 |
+| RDM make test | 通过（SELF），对象 ef075bd1 | 完整收据 ab592b80c858543f…见 RDM 任务卡：组合产品构建、29 项 Web 检查、Go 全量均退出 0；不包含部署／生产数据验收 |
+| Dev make test／文档检查 | 已通过（SELF），对象 0ab70b0c；最终文档记录后的对象另见任务卡 | 完整收据 b12914e5136cc405…见 Dev 任务卡；含工作树、gitlink、治理、模块／UI／命令组合检查，本任务未改业务 UI。最终文字记录收口后按固定 gitlink 再核验，新增收据由工具记录，不复制输出 |
+| 独立提前源码审阅与 focused 重放 | 通过，39 组顶层回归全部通过（本地） | 审阅者 /root/i1_security_review 未参与源码写入；对象 dfb9c407，独立重跑命令与完整 SELF 工具收据见 RDM 任务卡；不是用户批准、平台账号独立批准或受信 CI |
+| 正式验收／CI／浏览器／真实模型／生产迁移／部署 | NOT_RUN | 模型注册描述已按实际拒绝边界改写；未建立本轮固定模型任务级前后基线，测试使用 mock Host，不能声称模型行为通过。正式阶段应固定模型／配置／任务集，补真实对照及浏览器链路 |
+
+## 必须审阅的兼容影响
+
+1. 新 audit.read 初始不授予任何人。合法系统管理者先开平台上限，角色有资格后由合法项目管理者授予业务审计；此前 admin／创建者自动审计行为停止。
+2. KnowledgeDelete 只能按当前账号整插件前缀删除，故项目 revoke 明确拒绝，等待项目／资源限定公开接口；公开 rdm.init 也因读服务器目录并写全量未归属域而拒绝，可信本地操作保留。
+3. Host↔RDM 绑定、解绑及映射共享读取需可信双方项目授权提供者；当前未安装生产提供者，缺失默认拒绝。project/list 的整批私人工件元数据共享关闭；现项目级跨 owner search 缺发布分类证明也拒绝。自有资源具体读取和明确的 RDM 项目知识读面保留；不是完整共享 RAG 已验收声明。
+4. 存量未归属盘点／迁移／全量 outbox 状态需独立范围授权；实例内可信集成不是用户自授接口，重启不继承。旧未知归属 outbox 保留 pending，新增关联表仅处理之后的可证明来源；不推测历史 owner、不丢记录。本轮未变更生产 DB。
+5. 有阶段范围的用户无法读取尚未安全裁剪的全项目聚合 DTO；后续应逐对象投影与重算计数。失效绑定和旧不可信 opID 回执拒绝，不能把兼容回退当作当前资格。
+
+这些限制是避免当前公开契约不足扩大授权的 I1 处理；正式产品恢复对应能力需固定提供者／消费者的新公开版本与独立正反例，不能靠当前平台管理员位补足。
+
+## 进展与下一步
+
+U1 权限合同与需求追溯已完成；U2 当前 RDM 可达路径整改、本地组合自检和独立提前复审已完成，等待用户阶段 6 评审。独立提前源码复审已通过；后续测试记录更新必须确认生产源码与此对象等价。未推送、未创建 PR、未合入、未部署，保留两个独立工作区及全部失败收据。
+
+首选下一任务为已规划 I2/U3：账号可选资料、受控人员目录与本人恢复证明。推荐理由是先建立可信身份／有效态与安全恢复边界，随后才能实施 Backend 通用角色和多绑定 U4。前置条件：用户批准 I1 实施结果并另行授权 U3；核对已有账号目录实现，复用最小 EXT-19 边界；公开提供者先审接口，不能绕过 pins。预期产物：资料全空合法、字段授权搜索不泄漏、项目目录只投影获准辨识字段、普通管理员不能获取目标本人可兑换设密能力的真实负例及成功本人流程。此建议不启动新任务。
+
+公开 Host 能力缺口另有 IAM-H／IAM-K 申请；可与 U3 的公开提供者工作协调，恢复共享／撤销前先完成固定契约，不以设计文档存在放行。
+
+## 实施调用与单元记录
+
+实施引擎为 native Codex，委派单元为权限合同、初始负例、旧测试对齐、幂等隐私补漏与独立提前审阅；无外部模型路由绑定／回退／detached run，实际服务模型未独立证明。source_kind=plan，source_digest 为上方批准原文摘要；plan_checkpoint 为 Documents a088809。行为单元 U2 的原始红→绿观察保存于当时工具收据，不能从最终 diff 重构；U1 为非行为文档核对。单位 canonical commit 和完整 changed_files 由所属仓的当前分支与任务卡追溯。此本地交付跳过推送、PR、CI与合入 shipping tail。
+
+Dev 同步 main 到 143e636736 后随主干物化 Backend 15566f9a、Core 5773e740、Frontend c294835f、UI 2c4322ef；本任务相对该 main 只改变 Documents、PROJECT 导航与任务卡。RDM 产品仍按自身 pins 固定 Backend 0f192a48、Frontend 4965de26、UI bfecf8b5，未自行推进 pins；两套组合的检验与状态分开，不用 Dev 测试证明 RDM 的提供者能力。
+
+## 阶段 6 人工批准（2026-10-13，北京时间）
+
+用户在本页 c023551 对应的实施候选与兼容影响交付后回复“批准”。阶段 6 实施与自检结论：通过；对象为 Documents c023551、RDM b93908e、Dev 72ed8b4。该结论不代签尚未完成的阶段 7 验收，也不启动后续 U3–U9 或生产部署。恢复时已有主干推进，正式测试将固定同步后的对象，报告正常／异常／边界／回归证据与缺项，再请求用户验收；原获批对象和所有早期失败收据保留。
+
+阶段 7 当前产物：[正式测试与验收候选](2026-10-13-iam-i1-acceptance.md)。上述阶段 6 测试与缺项记录为当时快照；新的真实 HTTP 结果、独立重跑及仍未执行项目以阶段 7 报告和工具收据为准。

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

@@ -0,0 +1,574 @@
+---
+title: 用户、职位角色与分层权限统一设计及实施计划 r1
+date: 2026-10-13
+type: refactor
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: 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](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart TB
+  U[用户及多个职位绑定] --> I[基座身份与通用授权服务]
+  C[系统动作与权限目录] --> I
+  R[角色默认与角色上限] --> I
+  P[项目成员 所选绑定 项目覆盖] --> D[统一判定]
+  I --> D
+  A[资源归属 明确分享 文档职责] --> D
+  S[阶段 文档状态 当前版本] --> D
+  D --> E[HTTP 命令 工具 任务提交与读取]
+  D --> X[有效权限解释与矩阵]
+```
+
+```mermaid
+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. 文档三权与读取范围
+
+复用现有整文审签，不建立另一套审批引擎。
+项目创建者通过统一服务选择有效项目成员，系统验证职位资格与文档三权异人要求，再记录真实分配者和受指派人员。
+审核人可多人，全部指定审核人通过后才允许批准；审核／批准只能批注和通过／驳回，不能修改正文。
+审核与批准人员因实际职责可读提交审阅的正文和明确关联材料；这不开放私人对话、未分享原件或私人草稿。
+共享授权只增加规定资源的读取能力，不转为编写或签字资格。
+
+审签轮次冻结正文版本、职责版本与政策版本；人员停用、解绑、移除或权限收紧后，待处理轮次进入明确等待／失效状态，重新指派及提交。
+历史已完成的签字和操作者身份保留，不因换岗改写；历史内容读取仍使用当前授权。
+批准后修改采用既定撤回重审＋影响提示；职责替换不能清洗同一版本实际编制者的记录。
+未分配三权的文档显示等待分配，并阻断受控编写／提交，不回落为全成员可写。
+
+```mermaid
+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 丢弃过期响应，失败时清空对应旧能力。
+
+```mermaid
+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 功能与实现整改方案](2026-10-12-rdm-function-implementation-plan.md)、[RDM 完整交付方案](2026-10-11-rdm-final-target-completion.md)、[两树一网追溯审计方案](2026-10-11-rdm-two-trees-trace-audit-integration.md) 与 [账户和登录 Key 方案](2026-10-12-svc-unified-deploy-and-login-key.md)。
+本轮管理员决定将修订前述审计方案的跨全部项目业务审计放行口径，以及权威 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
+
+```mermaid
+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，先批准本次权限边界与公开合同，再实施已有可达授权路径的收口。
+这项建议不自动启动业务任务；完整用户资料与矩阵设计已有后续依赖和验收，不会在首批完成后遗漏。

docs/proposals/2026-10-13-merge-queue-implementation-plan.md

@@ -0,0 +1,336 @@
+# 最终验证与合入调度 Implementation Plan r1
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use `executing-plans` for native execution or `subagent-driven-development` when that method is selected. Read the specification and this plan; implement and verify one work item at a time. Checkboxes describe required steps; current progress and fixed objects are recorded in the Dev task card.
+
+**Goal:** 减少多个就绪分支因其他正常合入而反复同步、解决冲突和重跑最终 CI，同时保证实际合入候选通过既有检查。
+
+**Architecture:** 开发并行；同一目标由一个明确协调者安排最终同步至合入核验的串行窗口。首版使用源码外 Gitea 调度 Issue、幂等同步和分级恢复入口；保留现有 workflow 及平台准入，不建设自动调度 daemon。
+
+**Tech Stack:** 现有 Bash/Git 任务脚本、Python 标准库 evidence 工具、Makefile、unittest 临时真实仓库夹具、Gitea PR/Actions。
+
+**Spec:** Agent-System-Dev `policy/merge-queue.md` r1（本地来源提交 `913b214f2826a50b3dab65f79d9ebf83e84f2519`）；Development-Guidelines `standards/merge-queue.md` 与 `templates/merge-queue.md`（本地候选提交 `606f21db99b971aae82c2348a9b7959e6aa2060c`，draft.11）。两项来源尚未推送/合入，不生成不可访问的远端源码链接。
+
+**Status:** approved（阶段 5）；编制日期 2026-10-13（Asia/Shanghai）；负责人 weichen。用户在本计划 r1@ba4044d57e38d0887dd425d052abf26b20a28bf4 交付后回复「批准」，按推荐的原生方式实施。源码与自检已在 Dev 任务分支推进，证据和当前对象以任务卡为准；平台所有者操作及真实三任务 CI 试行 NOT_RUN。
+
+**Document baseline:** Documents `origin/main=5a06acf7cded07797ec4ebfea42c89331359b0bb`。本计划正文只维护于 Documents；任务进度、命令证据和批准依据仍以 Dev 任务卡为准。
+
+## Global Constraints
+
+- 共同起点及最终交付实际同步最新目标保留；正式验收、审核、合入仍分别核验新鲜度与候选身份。
+- 一个目标最多一个交付窗口，覆盖最终同步、正式验证、必要复审、合入及真实内容核对。
+- 队列更新、CI 链接和候选固定后的本地收据位于被测源码之外；不能向 main 提交调度心跳或状态。
+- 当前 HEAD 的全部必需 CI 必须实际通过；不复制旧绿色状态，不把跳过必需作业当通过。
+- 人工阶段结论、独立 Review、SELF/REPLAY/GATE 的身份边界不变。入队与领取不是批准或新的工作授权。
+- 修改治理脚本必须执行 `make test-governance`；跨仓指针推进前执行 Dev `make test`，最终精确 HEAD 的平台 CI 另核验。
+- 首版人工预算沿用规格：无进展 20 分钟、窗口 90 分钟、已知基础设施失败最多额外重试一次、等待队列每 30 分钟复查。实际 runner 容量及长期预算在试行前核验。
+- 分支保护变更由 Agent 准备、用户确认并亲手执行；本计划不授权绕过保护、改写历史或发布版本。
+- 不隐式 stash/reset/强推，不覆盖组件 feature 分支，不丢失现有收据或他人现场。
+
+## Review Focus
+
+1. 同步已经完成，但为记录再创建提交：U1 对有任务卡的真实仓库重复调用，断言 HEAD、索引和卡片不变。
+2. LOCAL_READY 被当作可启动新任务或可合入：U2 覆盖启动拒绝、严格恢复拒绝、未知远端及脏现场继续阻断。
+3. evidence 写回任务卡后才确认候选，或最终 SHA 仍指向记录提交之前：U1 核对输出真实 HEAD，U3 对源码外收据流程核对前后身份。
+4. 队列 Issue 被误认为互斥锁，或失联协调者被盲目接管：U4/U6 分别检查 manual 登记、旧执行者退出确认和未知结果对账。
+5. 分支 CI 绿色但其语义组合、组件或平台必需检查无效：U4/U5/U6 覆盖外部推进、组件版本不回退、精确对象与真实拒绝路径。
+
+## 1. 范围、决策及来源核对
+
+### 本增量
+
+U1–U3 为可在隔离仓库验证的任务与证据改进；U4 将已批准条文和实际能力接到交付入口；
+U5 准备并验证平台准入条件；U6 在已授权真实任务上试行。实施顺序固定 U1 → U2 → U3 → U4 → U5 → U6。
+三个源码单元完成后可先提交实施产物供阶段 6 评审；模式切换需 U4/U5 条件齐备，不能把脚本通过当线上启用。
+
+首版不修改 `.gitea/workflows/ci.yaml` 的触发、必需作业或检查上下文。节省重复最终 CI 的方法是：
+其他就绪分支不因 main 前进推送同步提交；当前窗口分支完成所有必要记录后只推送固定最终候选。
+现有开发提交仍可能运行完整 CI，首版不声称已自动区分轻重检查或能抢占 runner。
+后续 workflow 分流、自动原子领取和执行端 fencing 单独立项，不能为完成本计划顺手建设。
+
+### 已确定的选择
+
+| 决策 | 采用方式与理由 |
+|---|---|
+| 调度方式 | 人工首版：一份共享 Issue、一个协调者；与已批准规格一致，先控制实际推进顺序 |
+| 同步方式 | 保留 merge 历史；只有目标尚未包含时发生同步写入，同基线节点只核验 |
+| 启动/恢复 | 新任务和默认交付模式仍严格；仅既有合法任务可以显式选择局部恢复 |
+| 收据格式 | 本增量保留 schema 1 及原始校验和；局部模式由真实 precheck 输出及验证用途区分，不随意添加 snapshot 字段 |
+| 固定后证据 | 使用已有 RECEIPT 捕获模式，不增加冻结数据库或签名协议；manual 流程每个节点核对实际对象 |
+| 独立审核 | 建议原生逐项实施，末尾按现有交付规范安排独立 Review；编制时仅为计划，尚未启动审阅/实施代理 |
+
+### 编制时实现基线（源码观察 SELF）
+
+| 路径/符号 | 本次确认的行为 | 对计划的约束 |
+|---|---|---|
+| Dev `scripts/task.sh:cmd_sync` | 先获取目标并检查/物化组件；有任务卡时每次追加记录并提交；输出 head 在记录提交前取值 | U1 必须消除无变更提交，并输出记录完成后的 HEAD |
+| Dev `scripts/task.sh:cmd_precheck` | 远端失败为 REMOTE_UNVERIFIED；脏现场为 SHARED_WORKSPACE_BUSY；落后为 SYNC_REQUIRED | U2 不整体改成 READY，保持默认严格 |
+| Dev `scripts/evidence.py:validate_precheck` | 只接受真实 precheck 命令、READY、成功及固定源/目标；用于 task-start | 新任务不能消费局部恢复收据 |
+| Dev `scripts/evidence.py:read_receipt/validate_snapshot` | schema 1 和 snapshot 字段集合严格校验，允许可选 capture_note | 无必要不改 wire schema；历史收据不重写 |
+| Dev `scripts/evidence.py:main/write_receipt` | RECEIPT 模式已存在，绝对未用路径、0600、完整输出、before/after；默认模式写任务卡 | U3 复用能力，最终窗口明确选择源码外路径 |
+| Dev `scripts/zcode/write_guard.py:check_location` | 检查目标实际仓库及分支，未读取 precheck 收据或判断目标落后 | 不把当前守卫描述为阶段/新鲜度强制闸；保留分支检查与负例 |
+| Dev `.gitea/workflows/ci.yaml` | PR/main push 触发 test、test-pg、svc-realcombo；checkout 核对固定 SHA 与仓库 allowlist | 不凭 queue label 跳过检查；不能直接复制此 workflow 到临时仓当作合法等价 CI |
+
+以上为编制时源码观察；当前能力与执行进展见任务主记录及固定候选的 PR/源码外收据。源码单元实施前再次读取实际符号，记录新的 base/head；行号变动不改变接口选择。
+平台配置、runner 容量和在途任务用当场记录核验，不复用旧观察作当前准入证明。
+
+## 2. 公共入口与兼容约定
+
+以下是本计划拟新增或调整的接口；编制时均未声明已实现，当前状态以任务主记录及其固定候选证据为准。
+
+| 入口 | 默认/输入 | 结果及兼容 |
+|---|---|---|
+| `make task-sync` | 正常严格同步；来源仍为权威 origin/目标 | 保留 `[synced]`；完整 sync_base、最终 tested_head、checked_at，追加 changed=0/1；未变不提交卡片 |
+| `make precheck` | `TASK_WORK_MODE=delivery` 默认；可显式 local | delivery 保留 READY/SYNC_REQUIRED；local 仅既有登记任务输出 LOCAL_READY，不称可合入 |
+| `make task-resume PRECHECK_RECEIPT=...` | 复用登记任务；TASK_WORK_MODE 与 precheck 一致 | 验证相应用途的原始收据后原样导入，不建分支、不后台同步 |
+| `make task-start` | 始终用途 start、严格 READY | 无视外部试图选择局部验证用途的参数；LOCAL_READY 必须拒绝 |
+| `VALIDATE_RECEIPT_PURPOSE` | evidence 内部验证用途；默认 start | start、resume-delivery、resume-local 三值；未知值拒绝，两个任务入口显式设置用途 |
+| `RECEIPT=... CMD=... make evidence` | 既有捕获接口 | 保留 schema 1、原命令状态、完整脱敏输出及来源 SELF；固定候选期间路径在当前 checkout 与 Git 元数据之外 |
+
+`LOCAL_READY` 是局部工作的检查结果，不能提升为交付准入。旧的 schema 1 收据和 READY 输出继续可读。
+`VALIDATE_RECEIPT_PURPOSE` 不传给被测命令子进程，避免改变测试环境；不能由它改变来源等级。
+
+## 3. 工作项
+
+### U1：同步幂等化及最终对象输出（R1/R2，MQ3/MQ4）
+
+**Files（Dev 仓）：** Modify `scripts/task.sh`；Test `tests/test_task.py`；对应说明在 U4 同步。
+
+**Interfaces:** 消费 `fetch_target`、`check_worktree` 和原任务卡；产出第 2 节的 `[synced]` 协议。
+
+- [ ] 在现有 `TaskLifecycleTests` 中补有任务卡的夹具。使用已有 `self.git/self.worktree`，记录实际 R0，不创建假测试证据：
+
+```python
+def record_task_card(self, wt):
+    branch = self.git(wt, "branch", "--show-current").stdout.strip()
+    r0 = self.git(wt, "rev-parse", "origin/main").stdout.strip()
+    card = wt / ".task" / (branch.replace("/", "-") + ".md")
+    card.parent.mkdir(exist_ok=True)
+    card.write_text(
+        f"# {branch}\n状态：进行中；owner：Lifecycle Test\n"
+        f"- 权威仓：fixture；目标分支：main；R0（initial_base_sha）= {r0}\n"
+        f"- 工作区：{wt}（worktree）；分支：{branch}\n"
+    )
+    self.git(wt, "add", str(card.relative_to(wt)))
+    self.git(wt, "commit", "-m", "Record fixture task")
+    return card
+
+def test_sync_same_base_preserves_head_and_card(self):
+    wt = self.worktree()
+    card = self.record_task_card(wt)
+    head = self.git(wt, "rev-parse", "HEAD").stdout.strip()
+    content = card.read_bytes()
+    for _ in range(2):
+        result = self.task(wt, "sync")
+        self.assertEqual(self.git(wt, "rev-parse", "HEAD").stdout.strip(), head)
+        self.assertEqual(card.read_bytes(), content)
+        self.assertEqual(self.git(wt, "status", "--porcelain").stdout, "")
+        self.assertIn("changed=0", result.stdout)
+        self.assertIn(f"tested_head={head}", result.stdout)
+```
+
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_task.py' -k sync -v`，确认当前无变更提交行为导致新例失败，再改实现。
+- [ ] 同步前检查父仓未保存内容和活动操作；脏父仓/子仓拒绝，不自动 stash。成功 fetch 后区分祖先检查的 0、1 和其他错误。
+- [ ] 已包含目标时仍核对/物化必要组件，未变则不追加卡片、不提交；未包含时保留 merge、冲突处置和一次必要记录。记录提交完成后再读取最终 HEAD 输出。
+- [ ] 补新增目标成功纳入、重复调用保持 HEAD/索引/卡片、输出等于实际最终 HEAD、脏父仓/子仓/离线拒绝、组件 feature 分支保留和冲突不误报成功的测试。复用原组件夹具和已存在负例。
+- [ ] 重跑上述直接检查，输出经 evidence 保存；按本仓四段提交格式保存此单元，不捎带其他任务文件。
+
+### U2：既有任务局部恢复与严格准入分开（R1/R5，MQ4）
+
+**Files（Dev 仓）：** Modify `scripts/task.sh`、`scripts/evidence.py`、`Makefile`；Test `tests/test_task.py`、`tests/test_evidence.py`、`tests/test_write_guard.py`；独立恢复集成场景放 `tests/test_task_recovery.py`，复用原真实 Git 夹具。
+`scripts/zcode/write_guard.py` 的现有分支级规则保留；无已证实兼容问题时不改它。
+
+**Interfaces:** 使用 TASK_WORK_MODE 和第 2 节验证用途；`task-resume` 验证后复用 IMPORT_RECEIPT，不建立新工作区。
+
+- [ ] 先补局部模式与默认严格模式的对照测试：
+
+```python
+def test_local_precheck_allows_existing_clean_task_behind_target(self):
+    wt = self.worktree()
+    self.record_task_card(wt)
+    head = self.git(wt, "rev-parse", "HEAD").stdout.strip()
+    self.advance_remote()
+    strict = self.task(wt, "precheck", check=False)
+    self.assertNotEqual(strict.returncode, 0)
+    self.assertIn("SYNC_REQUIRED", strict.stdout)
+    local = self.task(wt, "precheck", check=False,
+                      env=self.env | {"TASK_WORK_MODE": "local"})
+    self.assertEqual(local.returncode, 0, local.stdout)
+    self.assertIn("[verdict] LOCAL_READY", local.stdout)
+    self.assertEqual(self.git(wt, "rev-parse", "HEAD").stdout.strip(), head)
+```
+
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_task.py' -k precheck -v`，确认新例失败。新任务入口仍消费严格收据。
+- [ ] local 只允许登记的合法任务 worktree/分支/任务卡，原 R0 必须仍是当前任务及权威目标的祖先；无卡、集成分支、错误归属、异常历史均拒绝。允许已知落后，不允许脏现场、活动操作、组件漂移、远端未知。
+- [ ] `validate_precheck` 增加用途参数，由任务入口显式选择。保留命令、原始输出、源 HEAD、common_dir 等校验；start/resume-delivery 仍要求严格 READY 与当前目标一致。
+- [ ] 测试夹具显式清理 TASK_WORK_MODE/VALIDATE_RECEIPT_PURPOSE，再由目标用例注入，避免开发终端环境污染默认严格模式的测试。
+- [ ] resume-local 接受实际 LOCAL_READY；收到同一来源任务的历史观察后重新 fetch 核对当前目标及 R0，目标正常前进不要求改写原收据或同步分支。读取失败、源 HEAD 变更或 R0 不适用拒绝，两个观察的来源与对象分别记录。
+- [ ] 补 LOCAL_READY 不能 task-start、不能严格恢复、用途未知拒绝、伪造任意命令拒绝、收据串仓/损坏拒绝、旧 READY 兼容、局部恢复不改 HEAD、已知目标前进与异常历史的对照。写守卫原有 main/detached/软链接拒绝测试继续通过，不宣称它已校验阶段批准。
+- [ ] 执行上述 precheck 检查及 `test_evidence.py`、`test_write_guard.py` 的 unittest discover；记录实际输出后提交此单元。
+
+### U3：候选固定前后使用不同证据保存位置（R2/R3，MQ3/MQ4）
+
+**Files（Dev 仓）：** Modify `policy/governance.md` 的证据流程；Test `tests/test_evidence.py`；同步任务卡模板说明于 U4。
+现有 `scripts/evidence.py` 的捕获/导入协议复用；本单元不改 schema，也不增加冻结状态库。
+
+**Interfaces:** RECEIPT 捕获、IMPORT_RECEIPT 导入、真实 snapshot；只有源码外记录满足固定后的流程。
+
+- [ ] 用已有 `tests/test_evidence.py` 的真实仓库夹具补完整使用流程：捕获到仓外唯一路径，断言卡片字节、HEAD、索引不变，校验原始命令输出、before/after 和 0600；重复目标拒绝，旧收据原样导入且幂等。
+
+以下用例放入既有 `EvidenceTests`，复用已核对的 `self.git/self.capture/self.card/self.receipt`：
+
+```python
+def test_fixed_candidate_capture_preserves_checkout(self):
+    self.git("add", ".task/main.md")
+    self.git("commit", "-qm", "Save fixture card before validation")
+    head = self.git("rev-parse", "HEAD")
+    card = self.card.read_bytes()
+    index = self.git("ls-files", "--stage")
+    data = self.capture("printf 'fixed candidate check\\n'")
+    self.assertEqual(data["before"]["head"], head)
+    self.assertEqual(data["after"]["head"], head)
+    self.assertEqual(data["output"], "fixed candidate check\n")
+    self.assertEqual(self.git("rev-parse", "HEAD"), head)
+    self.assertEqual(self.git("ls-files", "--stage"), index)
+    self.assertEqual(self.card.read_bytes(), card)
+    self.assertEqual(self.git("status", "--porcelain"), "")
+    self.assertEqual(self.receipt.stat().st_mode & 0o777, 0o600)
+```
+
+- [ ] 这项是既有能力的流程回归，允许先通过，不伪造“新增机制失败”结果。执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_evidence.py' -v`。
+- [ ] 固定前流程：同步 → 所有必要本地检查及任务卡收据 → 保存/提交卡片 → 核对干净组合 → 读取最终 HEAD → 推送并记录当前 CI 对象。
+- [ ] 固定后流程使用以下既有接口，候选 SHA/组件/相关配置由调度尝试引用；路径须位于 checkout 和 Git 元数据之外：
+
+```bash
+RECEIPT=/tmp/mq-attempt-unique-check.json CMD="make test-worktree" make evidence
+```
+
+每个调用使用新的未占用路径，例中 unique 由执行者替换为该次尝试唯一名称。命令期间若对象变了，保留实际新旧对象和输出，不作为固定候选通过依据，返回 preparing 或退出整改。
+- [ ] 未通过必要检查、未保存内容或新增提交时建立新尝试；既有最终 CI 不能沿用。合入/清理之后再按既有授权闭合，原始收据不能补写成预期输出。
+- [ ] 文档与直接回归记录保存后提交；能力矩阵将此登记为 manual 流程＋现有工具捕获能力，不宣称 OS 级冻结保护。
+
+### U4：将窗口接到实际交付规则及单一记录（R1–R5，MQ1/MQ2/MQ5/MQ6）
+
+**Files：** Guidelines 已有 draft.11 候选；Dev Modify `AGENTS.md`、`PROJECT.md`、`policy/delivery.md`、`policy/governance.md`、`policy/merge-queue.md`、`policy/adoption.md`、`policy/tool-adaptation-matrix.md`、`scripts/task.sh` 的任务卡模板；Test `tests/test_task.py` 的模板行为；Documents 保留本计划及索引。
+
+**Interfaces:** 通用正文固定 SHA＋项目采纳记录；一份实际平台调度 Issue；原任务卡只引用 entry_id/attempt_id。
+
+- [ ] 按既有规范完成 Guidelines 文档 Review 与 PR 交付；Dev 采纳实际合入的完整 SHA，不能直接引用本地候选提交作为远端已交付事实。父仓指针正式推进前完成组合 `make test`。
+- [ ] 根入口只路由到权威条文，修改 AGENTS.md 前应用 writing-for-agents；阶段 7–9 的核验职责不删，改为同一窗口内对象未变只核验。U1–U3 的入口和恢复语义同步到采纳记录、模板与矩阵。
+- [ ] 文档先记录 approved/pending-activation；只在 U5 准入条件满足、协调者和记录建立后切换 active。源码改进可先交付，不由指针更新或本地测试替代上线切换。
+- [ ] 在已获该动作授权的实施阶段建立一份 Gitea 调度 Issue，复制通用模板，填写实际协调者、目标、现有写入者清单、CI 预算与接管者；没有协调者则不开放领取。
+- [ ] 所有正常合入者、闭合 PR、机器人和紧急通道按记录安排。manual 状态由协调者串行修改；Issue 无原子领取能力，不能用编辑成功证明互斥。窗口失联先对账，确认旧执行者停止后交接。
+- [ ] CI 首版按可用资源和实际运行状态安排当前最终候选，不自动取消其他任务、改 runner 配置或建立定时自动化；30 分钟复查由协调者负责。
+- [ ] 模板核对必含记录位置、entry_id、attempt_id、固定对象及实际结果引用。治理脚本/模板变更完成后执行 `CMD="make test-governance" make evidence`，正式交付另核验精确对象的全部 CI。
+
+### U5：平台条件准备及所有者验证（R3/R5，MQ4/MQ8）
+
+**Files（Dev 仓）：** Modify `policy/platform-admission.md`、`policy/tool-adaptation-matrix.md`；必要事实更新经当场验证写 `policy/facts.md`。
+
+**Interfaces:** 现有 Gitea 分支保护、PR head 状态/运行、所有者亲手执行；不新增本地合入权威。
+
+- [ ] 当场读取当前 main、保护配置、合法固定 PR 的状态上下文及运行身份；输出经 evidence 脱敏保存。旧 SELF 观察仅作定位。
+- [ ] 准备保留禁直推与陈旧候选保护、要求实际全部必需 PR 检查的具体配置和恢复步骤；从当次状态确认完整名称，不只保留历史 test 上下文。批准数和身份策略不随本计划擅自调整。
+- [ ] 与所有者确认隔离验证对象与影响范围；Agent 不自行变更分支保护。用户亲手执行后，取得缺检查、失败检查、陈旧候选、无权推进被拒及合法候选可合入的实际结果。
+- [ ] 临时平台仓可验证保护机制，但其 fixture CI 不能宣称覆盖 Dev 的完整业务组合。现有 Dev workflow 有仓库 allowlist，不修改 allowlist/凭据范围来让临时仓冒充 Dev；Dev 精确 HEAD 的实际 CI 另核验。
+- [ ] 已知无法验证的能力标 NOT_RUN/manual；原子准入条件未满足时不切换新模式。自动接管的旧代次拒绝不是人工首版的通过断言，留待后续执行端实现。
+- [ ] 回填真实对象、身份、运行/拒绝链接及 GATE/REPLAY；仅 API 配置成功仍为观察，不标 enforced。
+
+### U6：三个真实任务的受控试行与复盘（R1–R5，MQ1–MQ8）
+
+**Files：** Dev 创建 `tests/test_merge_queue_trial.py`（仅本地临时仓库场景）；Documents 试行后创建 `docs/records/2026-10-13-merge-queue-trial.md`，实际日期不同则用真实日期；状态仍以各任务/调度记录为准。
+
+**Interfaces:** U1–U5 的命令、调度记录和平台入口；不同目标/跨仓依赖使用已有任务授权，不新建业务需求。
+
+- [ ] 隔离真实 Git 夹具覆盖 A/B/C 共同 R0，按窗口顺序最终同步、检查、合入；断言每条目第一次最终同步后重复核验不产生提交，后继不被要求提前同步。该测试的执行次数不冒充真实 Actions CI 次数。
+
+新文件复用已有夹具对象，不继承整套 TestCase，避免旧测试被重复发现。下面固定正常路径；故障用例在同一类内复用该夹具：
+
+```python
+import unittest
+import test_task as lifecycle
+
+class QueueTrialTests(unittest.TestCase):
+    def setUp(self):
+        self.fixture = lifecycle.TaskLifecycleTests(methodName="runTest")
+        self.fixture.setUp()
+        self.addCleanup(self.fixture.doCleanups)
+
+    def test_sequential_delivery_does_not_sync_waiting_branches(self):
+        f = self.fixture
+        branches = ["feature/a", "feature/b", "feature/c"]
+        worktrees = {}
+        waiting_heads = {}
+        for branch in branches:
+            wt = f.root / branch.replace("/", "-")
+            f.git(f.repo, "worktree", "add", "-b", branch, str(wt), "origin/main")
+            f.record_task_card(wt)
+            name = branch.split("/")[1]
+            (wt / name).write_text(name + "\n")
+            f.git(wt, "add", name)
+            f.git(wt, "commit", "-m", "Add independent fixture change")
+            worktrees[branch] = wt
+            waiting_heads[branch] = f.git(wt, "rev-parse", "HEAD").stdout
+        f.advance_remote()
+        for position, branch in enumerate(branches):
+            wt = worktrees[branch]
+            f.task(wt, "sync")
+            candidate = f.git(wt, "rev-parse", "HEAD").stdout
+            f.task(wt, "sync")
+            self.assertEqual(f.git(wt, "rev-parse", "HEAD").stdout, candidate)
+            self.assertEqual(f.git(wt, "status", "--porcelain").stdout, "")
+            f.git(f.repo, "merge", "--no-ff", branch, "-m", "Merge fixture candidate")
+            f.git(f.repo, "push", "origin", "main")
+            for waiting in branches[position + 1:]:
+                self.assertEqual(f.git(worktrees[waiting], "rev-parse", "HEAD").stdout,
+                                 waiting_heads[waiting])
+```
+
+- [ ] 注入冲突、已知失败、紧急插队、目标外部推进、依赖未满足和未知合入结果，核对允许继续的健康对照；不同目标互不阻塞，组件组合不回退。
+
+本地自动用例证明 Git/脚本行为；Issue 状态、失联交接及平台结果未知的处置由受控操作清单和实际对账记录验证，不因本地测试通过而宣称人工流程已自动互斥。
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_merge_queue_trial.py' -v` 和 `make test-governance`；回归实际 stdout/对象，不制造 GATE 标签。
+- [ ] U5 条件满足且用户批准试行后，由协调者选择三个已经获实施/合入授权且就绪的真实任务；不足三个时保留待试行，不为凑数生成生产 PR，也不干预未纳入的任务。
+- [ ] 记录每个尝试的实际最终同步次数、全部 CI 尝试/运行耗时、因目标移动废弃的运行、等待时长、恢复次数及真实结果。区分开发 CI、最终 CI 和 main 合入后 CI，不能只统计省下的一类。
+- [ ] 正常顺序交付的验收目标是没有因其他正常排队任务的合入而废弃最终 CI；整改、插队等另计。无可比历史数据时只报告本次观察，不给节省百分比。
+- [ ] 人工评审试行结果后决定继续/调整/回退。回退先停止领取、对账活动合入，再恢复旧流程；保留全部记录，不删除未知结果历史。
+
+## 4. 验证、交付与停止条件
+
+| 对象 | 最小验证 | 结果权威 |
+|---|---|---|
+| U1 | 有卡片的重复同步、新目标、真实最终 SHA、父子仓/网络/冲突保护 | 本地 SELF；正式交付补对应 GATE/REPLAY |
+| U2 | 严格/局部对照、启动/恢复用途、历史收据、分支守卫负例 | 同上 |
+| U3 | 原始仓外捕获、固定身份、原样导入、无重复写入 | 同上；不把流程约定标工具冻结 |
+| U4 | 权威条文、采纳、模板、全部写者/协调者安排及 make test-governance | 规范批准与命令证据分别记录 |
+| U5 | 实际缺检查/失败/陈旧/无权拒绝及合法路径 | 固定对象的 GATE/REPLAY，配置观察不替代 |
+| U6 | 临时真实 Git 故障/健康对照＋真实三任务与全部 CI 成本 | 临时测试 SELF，实际平台运行 GATE，人工验收另记 |
+
+每个源码单元只提交其拥有文件。所有完成声明保留 precheck、task-sync 与直接相关检查的工具收据；
+新对象需重新判断结论，固定后收据位于源码之外。验收、Review、合入分别遵循当时仍有效的门禁，不抢先使用未启用的新语义。
+Docs、Guidelines、Dev 各仓 PR 和实际合入 SHA 分别核验；文档计划合入不授权执行所有者操作或启动业务试行。
+
+停止条件：需求/契约或优先顺序变化，原 R0 不再适用，现场归属不明，当前平台/CI 身份无法核验，
+用户批准缺失，或实际合入结果未知。只暂停受影响范围；符合授权的其他局部工作继续。
+
+## 5. 自审与完成定义
+
+| 规格要求 | 计划覆盖 |
+|---|---|
+| 调度对象、记录和共同基线 | U2/U4/U6 |
+| 最终同步至核验串行窗口 | U1/U4/U6 |
+| 源码外证据及真实候选 | U1/U3/U5 |
+| CI 分配、去重与结果适用性 | U4/U5/U6；首版明确现有 workflow 不分流 |
+| 依赖、插队、失败与恢复 | U4/U6；自动接管明确不在首版 |
+| 采纳、能力登记与回退 | U4/U5/U6 |
+
+计划通过评审后，U1–U3 可以开始隔离实施；U4–U6 依前置条件推进。
+源码已实现、规范已采纳、平台已核验、模式已切换、三任务试行通过分别记录，不用一个“完成”代替。
+计划编制时源码与平台试验均 NOT_RUN；编制检查仅覆盖计划来源、路径、链接、状态和需求覆盖。
+
+实施续办：U1–U3 在 Dev 任务分支实现并保留实际验证收据；U4 的规则/模板和待启用 Issue #518 已准备；
+U5 仅完成只读观察、配置与恢复材料；U6 临时真实 Git 场景已运行，真实 CI/业务试行仍待 U5 和相应批准。
+当前源码/自检不从历史计划推断，统一回链
+Dev `.task/feature-merge-queue-policy-draft.md` 的完整对象与原始输出。
+
+建议采用原生逐项实施：三个源码单元紧密依赖同一套任务/evidence 接口，由一个写者修改更易保持兼容。
+实施产物和计划仍需既有人工阶段评审；最终代码 Review 按仓库职责安排独立审阅，不由作者自签。

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

@@ -81,6 +81,10 @@ product_contract_source: legacy-requirements
 
 ## 四、文档查找与职责分配
 
+> 2026-10-15：本节的职责页交互（文档清单加选中详情、章节级入口、整文审签）已被
+> [文档职责矩阵整改 r2](2026-10-15-rdm-duty-matrix-rework.md) 取代。成员校验、版本冲突、
+> 在途审签确认和历史保全仍然有效。下文保留作被取代前的记录。
+
 文档职责页面采用“**文档清单＋选中文档的职责详情**”：
 
 - 上方提供统一搜索框，支持文档 ID 精确检索、标题精确／模糊匹配。
@@ -162,9 +166,9 @@ product_contract_source: legacy-requirements
 | P2 系统设置闭环 | Core 设置描述、Backend 设置 API／存储／生效链／模型及密钥解析；系统管理入口 | P1；**基座发版与 RDM/Dev 升 pins**（见评审补充 1） | 系统受管项只能由有权管理员配置，旧个人／项目值不能覆盖 |
 | P3 人员与成员接口 | 扩展公开账号搜索；RDM 专业角色摘要、成员查询、项目身份调整与提交校验 | P1；姓名来源核实（见评审补充 3） | 账号／姓名／角色过滤同源，添加与身份调整明确分离 |
 | P4 文档与职责接口 | 专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动 | P1、P3 | 跨项目／非成员指派被拒，职责与审签变更全成或全败 |
-| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员／文档适配 | P1，接线依赖 P3、P4 | 三类使用场景共享交互，无自由文本误提交 |
+| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员适配。文档职责页的文档选择器改由 r2 三视图承接 | P1，接线依赖 P3、P4 | 人员选择共享交互，无自由文本误提交。职责页交互见 r2 |
 | P6 权限解释与矩阵 | RDM 项目动作目录、单人／批量解释、覆盖三态、来源与拒绝原因 | P1、P3 | 矩阵与执行规则一致，系统动作无法写入项目覆盖 |
-| P7 项目设置集成 | 重构现有项目页，连接四个页面、能力状态、读取回填与保存结果 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程 |
+| P7 项目设置集成 | 重构现有项目页，连接设置、成员与权限页。文档职责页改为 r2 的三视图，不再包含整文审签 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程。职责页验收以 r2 为准 |
 | P8 迁移与组合验收 | 旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填 | P2—P7 | 需求到证据闭合，无越权、隐私泄露或数据丢失 |
 
 前端主要改动落在现有 `ProjectSettingsModal`、`adminRdmSections`、`rdmManagement`、`api` 和 `store`；按业务拆分成员、职责及权限组件，避免继续扩大一个管理组件文件。

docs/proposals/2026-10-13-system-project-membership.md

@@ -0,0 +1,84 @@
+# 系统项目、成员工作入口与私域协作闭环 r1.1
+
+状态：用户 2026-10-13 已批准方向并授权阶段 1–9 连续推进；实现与隔离验证进行中。发布版本、部署、8788 数据修复及工作区清理不在本次授权内。
+
+本增量补齐总案 [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md) 的 U2，以及 U3/U5 与项目成员协作直接相关的边界。需求来源为 2026-10-13 用户复现和 `.tmp` 会议补充中“同名项目唯一、加入后可见且能新建对话、会话私有、每项目共享两树一网”。这不是模板全量迁移或三权流程重设计。
+
+## 已定位的问题
+
+8788 的成员添加记录已保存，但用的是宿主项目 ID；该 ID 没有领域注册或宿主绑定。列表和对话创建的共享适配器因此拒绝它。新建项目走宿主 owner 表，而成员管理、两树一网走领域表，缺少统一生命周期。会话列表还只检查宿主 owner，领域的名称 UNIQUE 也没有覆盖宿主创建入口。
+
+r1.1 增量：合并现行主干的成员 Picker、职责目录和权限矩阵，并闭合其独立重放发现的首次提交、渲染确认、迟到响应、职责幂等和持久版本问题；范围仍为本次成员与私域协作。
+
+运行制品仅有短来源标记，不能把当前源码视为其已证明的组件组合。只读现场证据、对象 SHA 和完整脱敏输出保存在 Dev 本任务卡，不在本文复制命令输出或线上数据。
+
+## 职责与公开契约
+
+RDM 保持项目、成员、职责与领域数据权威。Backend 管认证、宿主技术投影、私人会话/工件和通用资源执行边界。Frontend 只消费服务端身份与状态。
+
+```mermaid
+flowchart LR
+    U[认证用户] --> P[统一项目应用服务]
+    P --> D[RDM 项目与成员]
+    P --> H[宿主一对一投影]
+    H --> C[按用户归属的个人会话和原件]
+    D --> W[按项目分片的两树一网]
+    W --> K[成功发布的知识切片]
+    K --> R[当前项目的授权检索与模型上下文]
+```
+
+基座扩展申请的四要素：
+
+| 要素 | 结论 |
+|---|---|
+| 场景 | 统一产品项目创建/改名/归档，验证映射两端，并允许项目成员创建个人会话 |
+| 公开能力 | 可选 `extension.ProjectHost`、`ProjectLifecycle`、`ProjectLifecycleRegistry`；复用 `/api/projects` 与其会话路径；资源查询追加可选 `Source` |
+| 现有能力不足 | 只读 V1/V2 不承担生命周期、跨库初始化和动作授权；原 Host 没有项目技术投影与管理验证接口；仅项目布尔或已知切片 ID 不能证明索引行仍是发布来源 |
+| 兼容 | 保留必需 Host/Registry 接口；新能力经可选接口注册。未注册生命周期保留通用基座行为。RDM 产品缺该能力拒绝注册，防止悄然回到宿主个人项目路径 |
+
+`ProjectHost` 由执行端按认证主体构造；投影修改和管理查找保持 owner 限制，共享 metadata 经过授权和脱敏。`ProjectLifecycle` 的 List/Create/Rename/Archive/Work 是完整注册的一组回调，公共项目入口委托给它。客户端传入的 projectId 或 `rdm.projectId` 均是定位符。
+
+## 项目身份、名称和恢复
+
+- 领域项目、名称保留和创建者负责人同库事务提交。跨库投影使用确定的宿主 ID 和持久 `provisioning/failed/ready` 映射；失败重试保持身份，不持有领域事务跨宿主调用。
+- 本增量名称为去首尾空白后的精确名称；数据库唯一保护覆盖不同账号和并发。改名、归档后保留旧名归属。Unicode/大小写归一没有在本增量自动引入。
+- 所有产品创建、改名、归档路径使用应用服务；归档保存会话、原件和数据，不能继续新工作。管理重试可定位未完成映射，但仍须 owner/动作检查。
+- 新绑定验证真实宿主的存在和当前主体管理资格；既有绑定的 metadata/工作还验证物理宿主 owner 与映射创建者相符，不能只信映射存在。
+- 现有孤立宿主项目通过 `rdm.project.adopt` 先预览、再显式 apply；保留宿主 ID 和 owner，将成员关系移到领域根。不能凭名称猜测已有领域身份，不把未归属历史默认搬入新根。
+
+## 共享与私域
+
+| 数据 | 默认边界 |
+|---|---|
+| 个人会话/消息/原件/附件 | owner 私有；成员加入不使其对其他成员可读 |
+| 个人 pending/rejected 草稿 | 仅提案人；管理角色及其他职责不自动取得正文 |
+| 受控正文、差异与导出 | 当前项目成员身份、阶段/动作及有效章节或文档职责；审计许可不代替正文许可 |
+| 已采纳提案的本人不可变历史 | 本人自己的原始提案可保留；其他人读取受控内容走职责 |
+| 树结构、元信息、快照哈希 | 项目协作所需的结构视图；不能用元信息入口夹带正文预览 |
+| 历史正文预览 | 当前有效权限，不从历史重放恢复已撤销的职责 |
+| 原件台账、待处理数量 | 当前 actor 在目标项目的条目；管理角色不自动得全员原件视图 |
+| 项目发布知识 | 成员、明确领域根、成功发布台账、当前撤销代际与存活切片共同授权 |
+
+发布切片保留其 ID、owner、原件锚点，索引 `ProjectID` 为领域 ID，来源为 `plugin:rdm:published`。跨 owner 查询还检查实际存储行的 `Source`；手工/私人来源不能借已知切片 ID 绕行。撤销代际阻止已排队或在途任务重新授予共享。替换按 owner、精确项目（含空 ID）、ref、插件命名空间隔离。
+
+会话使用宿主 ID；HTTP、Host 和模型上下文通过服务端 provider 的可信 metadata 解析领域检索范围。每个实际知识对象再经过 V2，不能先按错误 ID 查空，也不能把 private 候选截断置于授权之前而隐藏合法结果。
+
+## 界面与执行
+
+沿用现有侧栏与项目设置，不新增管理屏。服务端 metadata 提供平面的 `rdm.projectId` / `rdm.state`，领域命令用 canonical ID，通用会话接口保留宿主 ID。未就绪项目不能回退创建默认项目；归档/关闭项目仍能读成员、权限和审签状态，不能新工作或修改。
+
+账号切换使所有待返回的列表、工件、卡片和工作续接失效。执行在确认后、排队恢复以及写入前重验当前权限，撤权后的 HITL 回复不能产生工件或恢复执行。
+
+项目 SSE 的历史重放和实时发送也必须按对象过滤。旧上传卡没有可信共享声明，不能因加入成员而暴露文件名、解析器或预览。权限从实际卡片/运行归属取值；明确共享由内部发布入口写入与 channel、seq、type 和 payload hash 绑定的声明，客户端 payload 不授予共享。未知或损坏证明拒绝，跳过私域事件仍推进扫描游标，保留未注册基座兼容。此为内部事件数据约束，不增加下游必需接口。
+
+职责保存先校验对象、三权、成员及版本；无变化不使在途轮次失效，仅实际变更生效前执行既有失效规则。职责版本随事件持久化，旧载荷按实际角色变化重建；写入失败不修改内存职责。
+
+## 验证与交付
+
+追溯：R1 名称→并发/碰撞/旧名保留；R2 身份→真实创建/失败重试/物理 owner/绑定；R3 成员→真实登录、同 ID 项目、个人对话；R4 项目分片→两项目隔离；R5 私域→所有查询/预览/台账/模型上下文及撤权；R6 旧数据→显式预览/幂等修复/保留；R7 真实组合→浏览器、真实模型任务对照、独立 Review 和当前 HEAD CI。
+
+测试原始输出由 evidence 工具写入任务卡，来源分开。单测、桩适配器、源码存在均不作为用户流程已完成的证明。当前完整运行/CI结果在任务卡维护，不在本文预写 PASS。
+
+RDM README/AGENTS 要求合入前回到基座 tag pin；开发期采用隔离 modfile组合验证。发布新 tag 属用户亲手执行的高后果操作，必须先形成已评审且 CI 通过的具体基座候选。tag、合入、部署、运行库修复和清理分别核验，不能合并成一个“完成”。
+
+下一步：完成本增量的组合验收与 tag 消费闭环；随后建议由用户授权在 8788 部署精确组合，并预览/修复已确认的孤立项目。未知历史归属、名称碰撞或身份不一致保留现场交人工裁定。

docs/proposals/2026-10-14-dhf-template-generation-plan.md

@@ -0,0 +1,313 @@
+---
+title: DHF 模板接入 RDM 文档生成管线 - Plan
+type: feat
+date: 2026-10-14
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+origin: 2026-10-11-rdm-template-dialog-generation.md
+execution: code
+---
+
+# DHF 模板接入 RDM 文档生成管线 - Plan
+
+## 批准与实施进展（2026-10-14 后续附注）
+
+本节记录批准后的状态；下方 r0.1 主文保留批准前评审快照，原对象 SHA256 为 `f99e1424a9bb86f68ad6de91657102a36004c61fb0f36c8427e913d9e0cf9643`。主文中的“草案”“待批准”“本轮 NOT_RUN”指当时状态，不代表今日仍未获实施授权。
+
+- owner 已批准 r0.1 的需求、方案和实施计划并授权 U1–U6 按阶段推进，另批准 E1-R1 隔离追加试验。U1 当前增量已走完阶段 6–10：阶段 6/7 获 owner 人工结论，独立 Review 闭合整改，最终 HEAD 的 GATE 与独立重放核验记录在案，三份交付 PR 均已合入。
+- RDM 已封装 44 个逻辑原件，owner 分别接受项目建议书、F01、F02、DI 四份确切四哈希包（内容与版式接受，正式发布授权仍未给出）；全部 44 项仍 `needs-review`，正式发布数 0。E1/E1-R1 使 14 DOC 均有转换候选，但逐项 Word 保真 **NOT_PASSED**；其余 40 项待包级裁定。F01/F02 的正式类型/存量字典升级及 U2–U6 真实产品流程仍未完成。
+- U1 当前增量的终态以归档任务卡为准：Dev 仓 `.task/archive/feature-dhf-template-pipeline-plan.md`（随 Dev #542 归档合入）。合入记录：[Documents #102](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/102) merge `9062445db808`、[RDM #365](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/365) merge `57d2214feb0a`、[Dev #540](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/540) merge `11aa76a3bc1c`，三个 main 树各自与受测 head 一致。U1 剩余 40 项包级裁定、14 DOC 保真对照、类型合同与 U2–U6 按本方案顺序继续；此前 WIP/待整改表述与旧 GATE 不再作为放行依据。
+- **2026-10-14 收口（本轮）**：批量 1–5 包级裁定获 owner「全部按推荐」批复并落档（RDM `docs/records/dhf/package-review-decision-2026-10-14.md`）；其余 DOC 11 份（#377）与 DOCX 17 份（#381）四哈希候选包合入，44/44 具备候选包；owner 同轮授权 catalog 翻转，#383 将 44 项全部置 `published`＋confirmed＋绑定四哈希＋issues 全清。U5 交付命令接线与实例播种随 #385 落地，真实产品二进制全链路试点 PASS；U6 逐项验收矩阵随 #387 完成——44/44 入账＝41 PASS＋2 EXPECTED_BLOCKED（F01/F02 字典门禁，owner 裁定暂缓）＋1 EXPECTED_LIMITED（无槽位确认报告，空填充 fail-closed 拒绝实测），0 FAIL；过程中修复 F05/F06 封面双层嵌套缺陷并补登记 11 个批量裁定 docType。卡片 #379/#382/#384/#386/#388/#390/#392 全部归档，RDM main `c5ea0f5`。交接文档 [u6-replay-handoff.md](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/src/branch/main/docs/records/dhf/u6-replay-handoff.md) 固化 owner 侧三项动作：①部署发布包＋三用户真实试点（回传导出 Word SHA256 与审签元数据）；②独立审阅者以一键驱动 `scripts/dhf-u6-replay.sh` 完成 R1–R4 重放并签署（作者 SELF 试运行全绿，审阅者重跑方为 REPLAY）；③提供带附件/页眉页脚的真实原件路径以启动 U4。独立 REPLAY 与真实环境试点完成前，本方案 DoD 的「试点交付/全量交付」两项维持 owner 阻塞态。
+
+修订 r0.1；需求负责人 weichen；方案编制 Codex；各仓实施负责人待立项指定。
+本文件是 DHF 接入专项的评审草案，授权终点为源码/资产调查、方案和计划文档、记忆归档。
+需求取舍、设计、实施和测试计划仍须按 Dev `policy/delivery.md` 逐阶段评审；本文不授予业务实施、转换试验、迁移、发布或部署权限。
+文件路径以目标仓为准：`Dev:` 为 Agent-System-Dev，`RDM:` 为 Agent-System-RDM，`Frontend:` 为 Agent-System-Frontend；无前缀为 Documents 仓。
+
+## Goal Capsule
+
+用户能在 RDM 项目对话中，按提供的 DHF 标准模板编制文档，取得内容有依据、格式可核查、审签版本一致的 Word 文件。
+采用现有 RDM 模板、两树一网、持久提案和三权流程，补齐 Word 资产解析、固定绑定和模板填充导出。
+本批最终覆盖 Dev `.templates/DHF 文件模板/` 全部 44 份逻辑资产；试点成功只代表试点完成。
+首选下一步是评审范围及解析试验 E1；E1 的 DOC 保真结果是全量接入的前置条件。
+
+---
+
+## Product Contract
+
+### Summary
+
+将 44 份 Word 原件转为可审核发布的模板包，使其内容结构、填写规则和原始版式共同约束文档生成。
+先用真实 DHF 项目建议书完成一条用户闭环，再按文档族接入全部资产；设计输入规格书和验证确认报告同时作为结构与示例语义的压力样本。
+登录恢复为已收官基线；本专项不把部署增强或账户恢复重新列作遗留实现项。
+
+### Problem Frame
+
+RDM 当前注册量不能代表标准模板可用量。
+已有模板选择、章节实例化和导出器缺少共同的模板身份，新增 Word 文件后仍可能生成错误用途的正文，或者丢失原件的表格与排版。
+模板中的示例测试结果和签署意见还可能被误当作本项目已经发生的事实。
+
+### Current State
+
+本轮源码/资产观察为 SELF，业务测试、DOC 转换、真实模型、浏览器验收、CI 和部署均为 NOT_RUN。
+调查对象：Dev R0 `add097d06137c4912a4ed9279e98ca353e4e4cf1`；RDM `6fcb256205c2384abed35d3b6ab96ca7216e9297`；Documents 草案从本轮 SSH/API 同值的 main `7bd4e17827d4c7c88647bf3c9199c495b60cb107` 建立。
+RDM 正式产品的 Frontend gitlink 与实际检出均为 `eb2d6d32f9323094d568bc9d80b4e5ed4f0af25b`；该源码基线用于定位当前预览行为，不代表组合浏览器验收。
+Dev 固定 Documents 的 `a7ff466…` 与本轮 Documents main 不同；本轮只保存规划，不推进 gitlink，未来集成须处理两条历史及规范差异。
+源码/资产原始输出与完整 SHA 由 Dev 任务卡的 evidence 段记录；以下是静态分析，不是运行通过声明。
+
+| 对象 | 当前事实 | 接入含义 |
+|---|---|---|
+| DHF 原件 | 44 份：30 DOCX、14 DOC，7 阶段；41 个不同 SHA256 | 同内容不同阶段仍保留独立逻辑用途 |
+| RDM 目录 | 69 个 docType，73 项 registry：4 定制 Markdown＋69 骨架 | 骨架含“内容要求待补”，不算 69 份标准正文已迁入 |
+| Word 原件 | RDM 未跟踪 DOC/DOCX 原模板 | 需要可脱离 Dev 工作目录的正式资产包 |
+| 现有解析 | DOCX 主要读 document.xml，DOC 不支持 | 不能用文本抽取代替完整内容和版式解析 |
+| 模板选择 | Compose 按适用列表首项选 key；rd_proposal 首项为 weekly-report | 必须消除注册顺序决定正文用途 |
+| 结构实例化 | 独立 structure YAML 建文档/章节，无公开的按模板实例化命令 | 模板发布、文档创建与生成入口需要接成一条路径 |
+| 固定版本 | Doc/Section/Version 未存真实模板绑定；提交的 TemplateVersion 实为字典版本 | 当前快照无法证明 Word 模板身份不漂移 |
+| 审签与提案 | 有事务采纳、幂等、持久提案及整文三权 | 扩展既有机制，不重写审批和项目权限 |
+| DOCX 导出 | 新建最小 OOXML，不消费原件版式；未按指定整文审批轮次导出 | 需要原模板填充和批准快照再现 |
+| 用户入口 | 自然语言写文档 intent 用错 docType 且仅查询模板；正式 Web 使用 Frontend pin | 真实对话、工具 schema 与正式 React 产品均需验证 |
+
+资产阶段分布：商务 1、策划 3、设计输入 15、设计输出 9、设计验证 8、设计转换 3、设计确认 5。
+四份输出/验证/转移/确认评审原件字节相同，但不能合并为一份逻辑模板。
+候选适配为 32 份映射既有类型、12 份新增或细分用途待评审；不等同于批准新增 12 个类型。
+
+### Requirements
+
+资产与内容约束：
+
+| ID | 要求 | 可判定验收条件 | 来源 |
+|---|---|---|---|
+| R1 | 44 份原件逐份登记来源、用途、版本和状态 | 每个路径有完整 hash 和处置；重复内容保留逻辑用途；未验证项不可标可用 | 本轮范围；TT-T01/T04 |
+| R2 | 保留真实多级结构、表格、填写规则与关键版式 | 对照每份原件无关键静默丢失；DOC 的解析/转换差异有人工裁定 | TT-T01/T02；现有模板方案 R3/R11 |
+| R3 | 示例、说明、占位符与固定文本分别处理 | 无真实证据时不预填验证成功、样本量或签署；模板内产品示例不进入项目事实 | 原件填写说明；原方案 R6 |
+| R4 | 模板用途和项目适用性明确 | 选择显式正文模板；计划/报告、验证/确认用途不混用；不适用部分注明理由 | TT-T03；原方案 R1/R3 |
+
+生成与受控交付：
+
+| ID | 要求 | 可判定验收条件 | 来源 |
+|---|---|---|---|
+| R5 | 新实例及历史内容固定实际模板身份 | templateId/version 与原件、结构、渲染包的完整 hash 可复核；升级不改旧版本 | TT-T04；原方案 R3/R9 |
+| R6 | 用户能从项目对话创建或更新模板文档 | 真实认证总线到实例化、生成、提案、采纳；歧义先澄清；总结请求不触发写入 | 原方案 R2/R7/R13 |
+| R7 | 生成和下载遵守现有项目、资源和文档职责 | 仅指定编制人生成/采纳；检索与模型输入授权；恢复、撤权及下载再次核验 | 原方案 R4/R9/R11 |
+| R8 | 模板、正文、依据和审签使用同一冻结对象 | 旧卡片/并发/模板退役均不能覆盖新内容；正式导出读取指定批准快照 | 原方案 R5/R7/R8/R9/R11 |
+| R9 | 完成状态以实际 Word 与用户流程验收为准 | 每个发布模板至少一个正常样例及一个空缺/冲突样例；44 份全部有结果 | 原方案 R12；TT-V01–03 |
+
+### Scope Boundaries
+
+本专项承接在途 `feature/rdm-two-trees-latest-templates` 的 TT-T01–04，依赖其 TT-D01–04 的递归结构、结构提案和版本保护。
+该任务已形成阶段 2 评估；本轮读取的记录仍待人工评审，不把其文字升级为实施批准。
+两个任务只能有一处权威模板/内容块契约和一份 44 资产台账；实施立项前指定契约 owner，按共同 R0 分工，禁止各做一套树或升级机制。
+原两树一网任务其余需求继续由其主记录维护，本专项的聚焦不削减那 28 项完整范围。
+
+### Deferred to Follow-Up Work
+
+未提供新标准原件的其余 37 个既有类型保留兼容和明确状态；不以本批 44 份宣称覆盖全部 69 类型。
+历史报价 XLSX 不在本批 Word 接入范围；全局项目字典扩展、默认成员工作上下文、完整审计展示继续归原两树专项。
+`-open-existing` 修复和 U2/U3 部署增强保持独立新需求。
+旧项目批量改绑、运行库迁移和上线需独立方案与授权，本轮不启动。
+
+### User Flow
+
+用户在可信项目对话中提出“按 DHF 模板生成项目建议书”；系统确认目标文档、用途和已发布模板。
+已有同类文档时展示更新目标；缺职责时等待负责人分配，由指定编制人接续。
+模板不适用、资料不足或用途歧义时保留待处理状态，不能退回任意骨架继续生成。
+生成任务使用已固定且有权使用的项目依据，返回逐块内容、来源、差异和缺项；编制人采纳后才形成内部版本。
+审核和批准绑定整文快照；草稿与正式版可区分地预览/下载，正式 Word 从指定批准快照和固定模板包生成。
+
+---
+
+## Planning Contract
+
+### Key Technical Decisions
+
+KTD1. 将原件、结构合同、渲染包组成同一个不可变模板发布版本；登记阶段/用途、适用规则和来源谱系。
+原件永久保存；DOC 转换产物是派生件，记录转换器版本/配置及产物 hash。
+默认模板只能从人工确认的显式绑定取得；语义版本比较替代字符串最大值，骨架显示“待标准模板”，不得混成已发布 DHF。
+共享模板/默认绑定治理沿用[原模板方案 KTD1](2026-10-11-rdm-template-dialog-generation.md#ktd1-template-contract-and-authority)的获批仓库发布边界；本专项不开放运行时模板管理权限。
+
+KTD2. Word 在资产准备阶段规范化为 DOCX，运行时不新增 LibreOffice 服务依赖。
+先复用在途 E1 的隔离试验，验证 DOC→DOCX 的可行性与损失；不得直接把 DOC 二进制当字符串或重命名扩展名。
+建议方法受官方格式与转换接口支持，但本批保真尚未验证：[MS-DOC 格式](https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-doc/ccd7b486-7881-484c-a137-51170af7cc22)、[LibreOffice 转换参数](https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html)、[格式过滤器](https://help.libreoffice.org/latest/en-US/text/shared/guide/convertfilters.html)。
+E1 先检验用户需求、软件测试用例、采购技术说明三种 DOC 样本，再覆盖全部 14 份；失败项保留未验证，不能降低 R2。
+本轮 PATH 未找到 LibreOffice/soffice；固定工具版本、隔离环境和试验授权仍是前置条件。
+E1 使用独立转换器 profile、只读原件和隔离临时输出，禁用宏、外部内容加载和网络；转换进程不得访问用户凭证或运行库。
+
+KTD3. 结构合同采用原两树专项的递归内容块，模板只定义其约束和 Word 槽位映射。
+块具有稳定 ID、层级、顺序、填写语义、字段/重复行/合并关系、依据需求、适用性和附件引用；显示标题不作为身份。
+解析综合样式继承、outlineLvl、自动编号、正文顺序和表格关系，人工确认其业务含义。
+蓝字、斜体、黑字只是分类线索；预填的 IQ/OQ/PQ 成功、样本量 22 和“同意”意见必须按 R3 处理。
+
+KTD4. 扩展现有领域对象、事件 payload 和 replay，固定模板绑定及每次生成的内容/依据基线。
+增加 RDM 领域的按模板实例化与生成编排入口；既有 compose/propose/adopt 适配到同一约束，不建立第二个提案或审批库。
+实例化事务创建文档、内容块和模板绑定；确认/采纳使用预期版本、opId 幂等和事务内复验。
+生成任务保存输入清单与候选，失败可恢复；恢复重新验证权限及模板可用性，缺少依赖时返回明确待处理结果。
+
+KTD5. DOCX 采用固定原模板包的槽位填充渲染，结构化内容是业务正文权威。
+保留原件的封面、页眉页脚、样式、编号、图片和非填充部件，确定性填充已标记的段落/单元格/重复行。
+发布检查识别会自动读取外部内容的关系；派生渲染包禁止保留外链图片加载，普通引用链接保持可审查的文本/超链接语义。
+本批《原材料进货检验规范》的图片同时有内嵌 rId11 和外链 rId12；派生包保留内嵌图片，移除 rId12 关系及对应 r:link，原件不变，处置进入差异台账。
+只有外链而无可保全本地内容时阻止发布，不能静默删图或自动下载补齐。
+原模板包不得直接把示例结论保留为实例结果；签署区域只映射真实审签元数据，不生成手写签名。
+提交快照冻结真实模板 binding、内容块/章节版本、依据和渲染器版本；导出明确选择草稿或某一批准快照，不能读取各章当前最新版拼装。
+批准 Word 首次生成后，字节、完整 hash、固定输入与精确批准快照持久关联，随批准历史保留；现有短期导出工件的 24 小时寿命不能作为该文件的保留策略。
+采用 RDM 自有的受控导出产物仓储，复用现有文件/hash 完整性机制，下载权限使用 `doc_export_visibility.go` 的受控正文授权，区分短期导出和批准历史文件；下载链接可短期失效，批准文件不能因此删除。
+批准后排队生成并保存该交付物，生成失败不回滚已批准的文档状态，文件状态保持待生成或失败；固定输入的幂等重试保存完整文件及关联后才可声明文件就绪。
+同一快照再次取得文件返回原批准字节；首次生成或获准重建只能使用可执行的固定渲染版本，相关模板包/槽位映射缺失、原件 hash 不符或旧渲染路径不可执行时明确阻塞，禁止自动改用新版渲染器。
+软件升级和例行清理必须保全批准文件及关联；结构化内容仍是业务权威，存档 Word 是对应快照的固定交付物。
+现有仅含字典版本的历史快照不补造模板身份；继续按旧导出路径提供并标明历史格式，不能宣称新 DHF 保真。
+
+KTD6. RDM 持有领域模板与生成/导出逻辑，Frontend 持有正式用户界面。
+对话、工具及工作区消费同一服务端对象和状态；修正错误 intent 参数，并公开合法的模板绑定和提案 schema。
+正式产品必须检验 Frontend 发布版本和 RDM pins 的组合；仅修改 RDM `web/app.js` 不算正式产品交付。
+按 Dev DESIGN 复用三栏、卡片与唯一文件预览，界面消费令牌和已有原语；文档纸面保留原件自己的字体和颜色。
+预览明确区分页式视图、版式降级的内容视图和无法读取；页式渲染失败时显示“版式预览不可用，当前仅展示内容”，保留同一 Word 文件的下载入口供核对，不把内容视图当作格式验收。
+仅当已批准路径无法由公开扩展点实现时，向基座提交四要素扩展申请；禁止改 RDM pins 或导入 Backend internal。
+
+### High-Level Technical Design
+
+以下图示规定权威和流向；具体类型名、函数及路径由实施时确定。
+
+```mermaid
+flowchart LR
+  O[44份只读原件] --> N[DOC规范化与差异核对]
+  N --> T[固定模板包: 原件/结构/槽位]
+  T --> I[可信项目与按模板实例化]
+  K[授权知识与原文版本] --> G[逐块生成和校验]
+  I --> G
+  G --> P[持久提案和差异]
+  P --> A[编制人采纳: 事务/CAS]
+  A --> S[整文提交/审核/批准快照]
+  T --> E[固定模板填充导出]
+  S --> E
+  E --> F[同一文件预览和下载]
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> Imported
+  Imported --> NeedsReview: 结构/语义/版式待确认
+  NeedsReview --> Published: 资产评审通过
+  NeedsReview --> Blocked: 关键丢失或用途不明
+  Blocked --> NeedsReview: 有依据的修正
+  Published --> Retired: 受控退役
+```
+
+```mermaid
+sequenceDiagram
+  actor A as 编制人
+  participant C as 对话/工具
+  participant R as RDM领域服务
+  participant D as 事务与事件库
+  participant E as Word导出
+  A->>C: 指定项目/目标/模板
+  C->>R: 可信主体与明确绑定
+  R->>D: 实例化及生成输入快照
+  R-->>A: 候选、差异、缺项与来源
+  A->>R: 采纳固定提案
+  R->>D: 权限/版本复验，原子提交
+  Note over R,D: 三权审签后冻结整文及真实模板
+  A->>R: 导出指定批准快照
+  R->>E: 固定内容与模板包
+  E-->>A: 经授权的文件预览/下载
+```
+
+### Dependencies and Open Questions
+
+实施启动阻塞项：本轮范围与取舍评审、在途两树任务契约 owner、44 份逐项阶段/type/用途映射、E1 授权与 DOC 保真结果、原件内容分类及导出槽位合同。
+特别是 F02《验证确认报告》虽位于设计验证目录，正文是过程 IQ/OQ/PQ 确认，须由业务负责人裁定用途，不按目录自动映射。
+导出关键版式以 R2 为底线；允许的字体替代和跨 Office 分页差异在 E1/样例评审中逐项确认，不承诺像素一致。
+源模板中的企业信息、示例产品名和标识需人工分类为企业固定项或项目替换项；无人确认时保持待发布。
+具体 helper 名称、序列化细节和测试夹具目录由实施者确定；不得用这些细节延后上述业务裁定。
+
+---
+
+## Implementation Units
+
+以下 U-ID 只属于本专项；均为待批准工作，不代表 E1 或任何业务实施已启动。
+
+### U1. Asset Contract and Conversion Proof
+
+覆盖 R1–R4；先与 TT-T/TT-D 的 owner 固定共享契约与台账。
+Files：RDM `internal/rdmapp/templates/`、`templates.go`、`templates_embed.go`；新增 `docs/records/dhf/` 台账及 `template_asset_contract_test.go`（拟定）；Dev 原件保持只读。
+产物为 44 份完整谱系、用途/适用性映射、内容分类、保真差异台账和已评审结构/槽位规范。
+先用项目建议书 DOCX 完成内容模型；设计输入规格书及 F02 报告校验多级结构与示例语义，复用 E1 覆盖全部 DOC。
+验证场景：损坏/加密/不支持对象拒绝发布；重复 hash 不吞用途；混合标题/编号正确；黑字假结论不能成为项目结果；每个 DOC 关键差异有判定；外链图片处置后内嵌图完整且导出无自动外部内容读取。
+出口：44 份处置明确，全部 14 DOC 方法可核验；未通过资产保持阻塞，不能进入全量发布。
+
+### U2. Published Template Binding and Instantiation
+
+依赖 U1 共享契约；覆盖 R1/R4/R5/R8。
+Files：RDM `templates.go`、`structure.go`、`internal/domain/doctree.go`、`payloads.go`、`replay.go`、`plugins/rdm/plugin.go`；新增 `dhf_template_instance_test.go`（拟定）。
+增加发布模板包与明确默认用途，原子创建文档/块/真实模板 binding；内容块复用 TT-D，不按标题去重代替身份。
+验证场景：v2/v10 选择、周报与建议书同 docType、缺包/hash 错误、退役、重复创建、跨项目、更名同名章、失败回滚及重启重放；模板升级不会覆盖旧实例。
+出口：无 Dev 源码目录的构建制品可实例化试点模板；新对象与历史对象有明确兼容路径。
+
+### U3. Evidence-Based Generation and Confirmed Adoption
+
+依赖 U2；覆盖 R3/R6–R8。
+Files：RDM `compose.go`、`draft.go`、`draftproposal.go`、`plugins/rdm/plugin.go`；扩展 `compose_test.go`、`draftproposal_test.go`、`plugins/rdm/intents_test.go`。
+修正 intent 和总线 schema；按块要求组织有权依据，结构化生成并校验，复用持久提案/事务采纳；同时落实 Compose 的指定编制人门禁。
+验证场景：真实自然语言请求从正确模板到提案；无资料、示例黑字、适用条件冲突均诚实留缺；未分配职责、非编制人和私人未发布资料拒绝；并发采纳、重复点击、取消、断连/恢复及撤权结果可查且不重复生效。
+出口：项目建议书有固定来源的完整候选和内部版本；无证据的测试/验证字段仍空缺或注明未执行。
+
+### U4. Approved Snapshot and Word Fidelity
+
+依赖 U2/U3；覆盖 R2/R3/R5/R8/R9。
+Files：RDM `docsubmission.go`、`docx.go`、`doc_export_visibility.go`、`export_artifact.go`、领域快照 payload/replay；扩展 `docx_test.go`、`plugins/rdm/doc_submission_test.go`；新增 `dhf_docx_fidelity_test.go`（拟定）。
+冻结真实模板及渲染版本，补整文快照选择；实现原 OOXML 槽位填充、重复行和附件映射及批准 Word 持久关联，旧导出语义独立兼容。
+验证场景：审核中改正文被拒、提交后模板更新/退役、批准后当前章变化、历史批准轮次重导出、槽位重复/缺失、长表格跨页、合并关系、编号、图片、页眉页脚、中文字体、非法 XML；无真实签署不填意见；下载撤权立即拒绝。
+跨版本验收：旧版批准/导出→超过短期工件 TTL→升级并更换渲染实现→取得同一轮次 Word，字节 hash 与原批准文件一致；下载仍按当前权限判断。原批准文件损坏或丢失且固定渲染版本不可执行时明确阻塞，不生成外观相近的新文件冒充历史产物。
+故障验收：生成失败不改变审批结论；写文件与关联记录部分失败不发布就绪文件，重启后可查并幂等恢复；文件下载采用正文职责权限，普通审计权不扩大文件读取范围。
+出口：三用户完成试点审签，Word 内容/依据与批准快照相同，关键版式对照通过；ZIP 非空或可打开仅为辅助检查。
+
+### U5. Formal Product Path and Offline Package
+
+依赖 U3/U4；覆盖 R6/R7/R9。
+Files：RDM `scripts/build-product.sh`、`scripts/pack-release.sh`、`templates_embed.go`、`templates_embed_test.go`；Frontend `src/previewsetup.ts`、真实对话卡片/文件预览/API 与相关浏览器用例（其余路径实施前按当前发布版定位）。
+统一包内模板路径、读取路径和 hash 校验；对话与辅助工作区复用同一任务/提案/快照，交付正式 Frontend 版本后由 RDM 正常消费。
+验证场景：真实 auth-on 两项目三用户，关闭右栏完成编制，刷新/重启/撤权/旧卡片；脱离源码运行同一制品，资产缺失/摘要错误拒绝；原模板字体/颜色在预览保留；页式渲染失败明确降级，完全无法读取显示错误及下载入口；证明浏览器使用精确 Frontend SHA。
+出口：项目建议书在正式产品完成全流程，固定组合 CI 与独立重放齐备；静态工作台或桩测试不能替代。
+
+### U6. Complete All DHF Families
+
+依赖 U1–U5 试点通过；覆盖 R1–R9。
+Files：RDM 模板包、registry、映射台账及每文档族的内容/Word 回归样例，复用 U1 的唯一资产台账。
+顺序为策划/输入→输出→验证/确认→商务/转换及剩余评审；DOC 规范化与 DOCX 内容整理可在同一契约下并行，发布仍逐批评审。
+每份模板至少运行一个有材料的完整样例和一个缺证据/冲突样例；报告类只使用实际提供的验证记录，不能生成执行记录。
+出口：44 份逐资产结果齐全，声明可用者通过真实生成/采纳/审签/导出；未解决项显式保留，本目标不能标全量完成。
+
+---
+
+## Verification Contract
+
+验证在后续批准的阶段执行；本轮只能做原件/源码阅读和文档一致性检查。
+实施期先补关键链路的行为测试，再扩展原有实现；正式验收遵循 Dev evidence、精确组件 SHA、CI GATE 与独立 REPLAY 门禁。
+
+| 证据层 | 对象与方法 | 硬判据 |
+|---|---|---|
+| 资产 | 44 份路径、原件/派生/结构/渲染 hash、DOC 差异和业务分类 | 44/44 可追溯；原件不变；关键结构/语义/格式无静默丢失 |
+| 领域 | RDM 模板/实例/提案/审签/事件重放测试 | 固定绑定、CAS/幂等、失败全回滚、历史再现，负向越权为零 |
+| 真实总线 | 意图→schema→认证主体→实例化/生成/采纳/导出 | 用合法 docType/templateRef；工具暴露参数和处理器一致 |
+| 模型行为 | 固定真实素材、原件和任务，人工审核正文与引用 | 不编造事实、样本量、执行记录、结论或签署；缺项明确 |
+| Word | OOXML 核对＋真实 Office/LibreOffice 打开＋人工原件对照＋升级后历史文件重取 | 内容/表格/合并/编号/图片/页眉页脚/关键样式与固定快照一致；批准历史文件不受短期 TTL 清理 |
+| 正式浏览器 | 真实 auth-on 三用户两项目、对话/卡片/预览/下载、重启/撤权 | 完整用户流程，文件可读可下载，职责/私域隔离有效 |
+| 安装制品 | 固定 RDM/Frontend/Backend pins 与模板包，源码外运行 | 无 cwd 依赖；读/打包路径同值；错包拒绝，不回退到骨架 |
+
+RDM 的现有 `make test`、product build、模板/提案/审签测试用于回归；Frontend 使用相关浏览器测试；Dev 有 gitlink 改动时执行组合 `make test` 和 `make build`。
+正式以各 PR 当前 HEAD 的必需 CI 为准；原件盘点 SELF、模型自评和历史绿色 CI不能代替当前验收。
+生成耗时、费用和人工修订量先建立试点基线，再确认目标；本轮不编造工期或质量评分。
+
+## Definition of Done
+
+规划交付：范围、源码基线、44 资产特点、技术决策、依赖、工作包、验证和阻塞项可审查；未批准及未执行阶段明确。
+试点交付：真实 DHF 项目建议书在正式产品，经三用户完成生成/采纳/审签/按快照 Word 导出，精确组合证据齐备。
+全量交付：U6 达到 44 份逐资产验收，原两树任务的共同契约和台账同步；试点或 registry 数量不能替代。
+上线交付：另行确认实例、制品和迁移范围，按批准窗口部署并运行验收；本方案完成不等于上线。
+
+## Appendix
+
+主要源码：RDM `internal/rdmapp/templates.go`、`templates_gen.go`、`templates_embed.go`、`structure.go`、`parse.go`、`compose.go`、`draftproposal.go`、`docsubmission.go`、`docx.go`、`plugins/rdm/plugin.go`、`scripts/build-product.sh`。
+本轮资产证据索引：[44 份原件的路径/hash/结构特征及源文件摘要](../records/2026-10-14-dhf-assets.json)；完整命令输出以 Dev 任务卡 evidence 为准。
+上游来源：[原模板生成方案](2026-10-11-rdm-template-dialog-generation.md)、[最终目标方案](2026-10-11-rdm-final-target-completion.md)、[两树一网方案](2026-10-11-rdm-two-trees-trace-audit-integration.md)及在途 `feature/rdm-two-trees-latest-templates` 阶段 1/2 记录；旧“四模板”盘点只作历史。
+登录收官来源：Dev `docs/svc-deploy/2026-10-13-login-recovery-contract.md` 的最后一项为“完成”，PR #516 已合入；owner 于 2026-10-13 自行在浏览器确认通过，密码不经 Agent。本轮不重做该验收。

docs/proposals/2026-10-14-merge-queue-manual-phase2-implementation-plan.md

@@ -0,0 +1,113 @@
+# Dev main 第二轮 manual 合入调度实施与测试计划
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让第二轮三个已授权真实任务在同一人工窗口中按序完成最终同步、审核、CI 与智能体合入，同时把所有已知 Dev main 写入及失败退出记录在唯一调度 Issue；正常排队推进不使等待分支反复重跑最终 CI。
+
+**Architecture:** 保留现有 Gitea 分支保护、三项 PR 检查和 `task-sync`；Dev `policy/` 仅说明项目采纳、写者覆盖、记录字段及停止条件。Issue #518 是动态窗口唯一来源，原任务卡保留授权与阶段结论。只读对账从实际 main PR/合入列表反查 #518 的先前领取与事后释放；无原子锁、无自动调度服务。
+
+**Tech Stack:** Git/Gitea 1.27 API、Dev `make precheck`/`make evidence`/`make task-sync`、Markdown 规范与 JSON 收据、现有 `.gitea/workflows/ci.yaml`。
+
+**Spec:** [已批准的阶段 4 设计](2026-10-14-merge-queue-manual-phase2.md)，Documents PR #104（合入 `8e3b5b0d2838f89430683ec731a15b32b4fa5eae`）；[首轮报告](../records/2026-10-14-merge-queue-trial.md)与 Dev #518 是历史与动态证据，不能以本计划代替实时回读。
+
+## Global Constraints
+
+- 范围仅为 Dev 仓库 ID=29、`refs/heads/main`；普通、闭卡、紧急和机器人目标写入都纳入同一记录。组件仓按自身目标协调。
+- 第二轮样本为**随后实际就绪的三个已授权真实任务**；闭卡单列。#482、#512、#537 不因本计划自动取得接管或合入授权。
+- 现有 Gitea 保护、必需检查、CI workflow 和 runner 全局配置保持不变；最终 PR HEAD 的 `test`、`test-pg`、`svc-realcombo` 均须取得真实 GATE。
+- 采用单一协调者维护的 `manual` 窗口。Issue 编辑、评论、`content_version` 和本地锁都不是平台原子互斥；旧执行者未确认退出时不得接管。
+- 无进展 20 分钟、单窗口 90 分钟、已知基础设施失败最多额外重试一次、队列每 30 分钟复核；领取前当场核对 runner 容量。
+- 阶段 5–7 依 `policy/delivery.md` 分别取得人工结论；阶段 8–9 由智能体审阅、核验精确 HEAD 与平台准入并合入。阶段 5 批准不等于第二轮已启用。
+- 所有通过断言区分 GATE、REPLAY、SELF；本地输出经 `make evidence` 写入，固定后收据置于源码外；未知结果先读回，不盲目重复副作用请求。
+
+## Review Focus
+
+1. **已知写者仍从另一入口推进 main：**任务 2 的对账应查到实际合入但缺先前领取，暂停新领取并标记受影响候选失效。
+2. **Issue 中只有事后补记：**任务 2 的对账应区分先前领取与事后释放；#539 不能被算作合格覆盖。
+3. **候选固定后内容或 base 变化：**任务 3 的核验应建立新尝试，并拒用旧 Review/CI；同基线重复 `task-sync` 应保持 HEAD 不变。
+4. **合入响应未知或协调者失联：**任务 3 应先回读 PR/main 并保持 `reconciling`，确认前执行者退出后才释放/交接。
+5. **没有三个已就绪任务：**任务 4 应保持 `waiting`，不接管 #482/#512 或制造生产 PR，不把缺样本写为通过。
+
+| 设计验收 | 计划中的主要验证 |
+|---|---|
+| M2-1 | 任务 2 入队字段、任务 4 三个真实任务与等待期间最终 CI 清单 |
+| M2-2 | 任务 2 的逐合入只读对账、任务 4 每次 main 推进后的覆盖核对 |
+| M2-3 | 任务 3 的同基线无变更与变更后新尝试重放 |
+| M2-4 | 任务 3 的精确 HEAD 三项 GATE/智能体合入、任务 4 的每任务对象记录 |
+| M2-5 | 任务 4 对正常排队造成的最终 CI 废弃数和所有 CI 成本分类 |
+| M2-6 | 任务 2/3 的异常决策表与任务 4 的自然退出/`NOT_RUN` 记录 |
+
+---
+
+### Task 1: 固定实施范围与 Dev 规范入口（M2-1、M2-3）
+
+**Files:**
+- Modify: Dev `policy/merge-queue.md` 的状态、项目调度记录、启动与同步、采纳顺序及验收表。
+- Modify: Dev `policy/adoption.md` 中合入调度采纳行。
+- Modify: Dev `policy/tool-adaptation-matrix.md` 的 A10/A11 行。
+- Read only: Dev `AGENTS.md`、`policy/delivery.md`、`policy/governance.md`、Guidelines 固定版 `standards/merge-queue.md`。
+
+**Interfaces:** 仅细化已固定通用规范，不改 `task-sync`、`make evidence` 或 CI 接口。规范链接指向 Documents 阶段 4 设计和 #518；`policy/adoption.md` 区分“规范已合入”“第二轮待启用”“manual 能力”；A10 说明 Issue 协作与平台准入的不同强度。
+
+- [ ] 在 Dev 当前 main 创建未占用收据路径，运行下列启动门禁并确认 READY；按输出读必读规范。新任务用同一收据建独立工作区，记录 R0 与写者归属；若任务已登记则在原 worktree 改用 `make task-resume PRECHECK_RECEIPT="$mq_receipt"`，不重复开卡。BUSY、SYNC_REQUIRED、REMOTE_UNVERIFIED 先排除。
+
+  ```bash
+  mq_receipt="/tmp/mq-phase2-stage6-precheck-$(date -u +%Y%m%dT%H%M%SZ)-$$.json"
+  RECEIPT="$mq_receipt" CMD='make precheck' make evidence
+  make task-start NAME=feature/merge-queue-manual-phase2 PRECHECK_RECEIPT="$mq_receipt"
+  ```
+- [ ] 对照当前 Dev main、Guidelines gitlink、#518 与已合入设计。把 `policy/merge-queue.md` 首轮“本轮三个任务待完成”“本分支”等已过期时态改为历史结果，把第二轮规则明确标为 `approved/pending-activation`，并逐项写明 `ready_at`、`queue_entered_at`、`attempt_id`、`initial_base_sha`、`source_head_sha`、`sync_base_sha`、`frozen_head_sha`、组件/检查定义、Review 与 GATE、实际合入/释放。动态值只在 #518，不复制静态队列表。
+- [ ] 在 `policy/adoption.md` 与 A10/A11 中指向同一设计及项目规则：保留首轮原始证据范围；第二轮标 `manual`、`pending-activation`，不可升级成 `enforced` 或声称自动互斥；现有源码外收据能力保持原样。
+- [ ] 检查 `AGENTS.md` 与 `policy/delivery.md` 对合入窗口及阶段 7–9 的指向。若现有入口已覆盖，只记录无需修改；若确有入口断链，按文档范围补链接并将变化列入 Review。
+- [ ] 运行 `git diff --check`、Markdown 相对链接检查和规则一致性检查：阶段 5 批准后尚未启用、缺写者覆盖时必须保持 waiting、三个必需检查没有删减。若动到治理脚本或任务卡模板，另运行 `CMD='make test-governance' make evidence`；纯文档不制造新脚本测试。
+- [ ] 将本单元源码与 SELF 检查收据写入原任务卡并提交；阶段 6 人工评审前不把 #518 标为第二轮 active。
+
+### Task 2: 建立 #518 入队模板与只读覆盖对账（M2-1、M2-2、M2-6）
+
+**Files:**
+- Modify: Dev `policy/merge-queue.md` 的记录示例、写者覆盖、异常与暂停规则。
+- Prepare then update after Stage 6 approval: Gitea Dev Issue #518 正文的第二轮入口与追加式评论模板；不建立第二份队列状态文件。
+- Save outside source: 每次只读 Gitea API 对账的原始脱敏 JSON/`make evidence` 收据；必要结论只引用对象和链接。
+
+**Interfaces:** #518 条目至少包含 `entry_id`、目标、PR/任务卡、owner/协调者、授权与阶段版本、依赖、`queue_entered_at`、`ready_at`、状态；领取评论补 Task 1 的 attempt 字段；释放评论补实际 PR/main SHA、合入结果及 GATE 链接。`ready_at` 未知标 `NOT_MEASURED`，不足条件标 `blocked`。
+
+- [ ] 只读查询 Dev 当前 main SHA、开放 PR、仓库协作者、可写工作区 owner、机器人/webhook/workflow 入口、#518 正文与评论，生成带观察时间和对象 SHA 的 SELF 清单；无法查到的写者类别标“未核验”，不推断不存在。
+- [ ] 在 Task 1 规范中给出普通、闭卡、紧急、机器人共同的入队/领取/释放字段，规定 `blocked` 不占窗口；跨仓组件未就绪不占 Dev 窗口。未知来源与旧执行者未退出必须暂停或 `reconciling`，不得靠 20 分钟超时接管。
+- [ ] 固定只读对账步骤：枚举观察区间内实际合入 Dev main 的 PR/merge SHA；逐个在 #518 找**合入前**同目标同 attempt 的领取和**合入后**释放；同时反查 Issue 中仍占用但 PR 已关闭/合入的窗口。分列“合格、仅事后补记、未找到、结果不明”，保留 API 原始响应与分页范围。
+- [ ] 用 [阶段 4 SELF 快照](../records/2026-10-14-manual-phase2-source-audit.json) 回放对账口径：#539 属“仅事后补记”，#540/#542 能找到领取/释放，其余七个仅可记“在该次 #518 观察中未找到”；不得倒推出其他渠道绝无协调。源记录更新后另取实时快照，不用历史快照证明当前覆盖。
+- [ ] 将模板与覆盖清单先作为 Dev PR/任务卡可审附件；Stage 6 人工确认后才更新 #518 的**待启用**入口。写入前读回 `content_version` 与活动窗口，遇到别人更新先重算差异；请求结果未知先 GET 对账，不重复 PATCH/POST。
+- [ ] 当场向每位**已知目标写者**核实采用同一窗口的确认；未确认类别逐项留记录。没有全体已知写者覆盖，不转 active、不领取三个样本。人工确认不等于 Gitea 执行端隔离。
+
+### Task 3: 用现有门禁交付 Dev 规则并验证异常边界（M2-3、M2-4）
+
+**Files:**
+- Modify: Task 1/2 的 Dev 规则差异及原任务卡（仅在候选固定前）。
+- Save outside source: 最终 precheck、task-sync、直接相关检查、Review 和 CI 的原始收据及对象索引。
+
+**Interfaces:** 复用 `make task-sync`、`make evidence`、Gitea PR/Actions 与现有分支保护；不新增自动队列或跳过 CI 的入口。
+
+- [ ] 在阶段 6 人工通过后，正式测试前对 Dev 规则 PR 执行一次 `make task-sync`，处理真实冲突、确认组件不回退，先写完任务卡和需提交证据，再固定并推送 PR HEAD。若有脚本/模板改动跑 `make test-governance`，Dev 组合按变更影响跑 `make test`/`make build`，由 `make evidence` 保存完整 SELF 输出。
+- [ ] 在临时真实 Git 场景复核同 base/head 重复 `task-sync` 的 HEAD、索引和组件不变；目标前进或候选内容变时，新 attempt 的 base/head 与旧 CI/Review 不同，旧结果不能放行。若本增量未改同步脚本，引用现有治理回归并做最小重放，不重复整个历史试行。
+- [ ] 用只读或隔离模拟验证异常决策表：未登记 main 推进→暂停及候选失效；合入 API 超时/断连→`reconciling` 并先读 PR/main；代码/Review 失败→当前条目 blocked 并安全释放；未发生真实生产故障的路径只标模拟或 `NOT_RUN`。
+- [ ] 阶段 7 人工审阅固定候选与测试映射后，由智能体完成阶段 8 Review 与影响重放；阶段 9 合入前再次同步核对最新 base/head/组件及当次要求的 GATE 身份、SHA、三项结果。合入请求固定 `head_commit_id` 且 `force_merge=false`，回读 PR/main 树与合入 SHA。若候选改变，重新测试及受影响评审，不沿用旧绿灯。
+- [ ] 把实际阶段 6/7/8/9 结果及 GATE/REPLAY/SELF 来源写入原任务记录；规则 PR 合入并不自动启用第二轮任务窗口。
+
+### Task 4: 第二轮启用、三任务试行与收口（M2-1–M2-6）
+
+**Files:**
+- Update dynamically: Gitea Dev Issue #518 与每个**原任务**的任务卡/PR。
+- Create after actual observation: Documents `docs/records/<实际日期>-merge-queue-manual-phase2-trial.md`；与 #518 互链，不复制动态队列状态。
+- Update only after result review: Dev `policy/adoption.md`、`policy/tool-adaptation-matrix.md` 的实际能力和状态（若有变化）。
+
+**Interfaces:** Task 2 的 #518 模板；每个任务原有人工阶段与接管授权；固定 PR HEAD 的三项 GATE；智能体合入入口。此任务不承担其他任务业务代码实现。
+
+- [ ] 在规则 PR 合入、#518 模板已登记、已知目标写者确认覆盖、无活动/未知窗口、runner 容量当场核验后，由负责人审阅启用条件与当前清单，再把第二轮从 `pending-activation` 切为 `manual active`。缺任何条件保持 `waiting`，继续独立局部开发。
+- [ ] 只让三个**实际就绪且已有自身实施/合入授权**的任务依 `queue_entered_at`/`ready_at` 顺序入队；协调者在领取前核对原卡阶段结论、PR head、依赖、组件与其他写者退出。#482/#512 只有重新满足这些条件才可参与，不能因本计划自动接管。
+- [ ] 每次领取后按 Task 3 固定并通过当前 HEAD 必需检查、Review 与人工阶段结论，智能体串行合入并释放；闭卡 PR 使用独立窗口，成本单列。每 30 分钟复查等待队列，记录 runner 等待与人的依赖/准备等待；时间缺失记 `NOT_MEASURED`。
+- [ ] 每次 main 实际推进后运行 Task 2 只读覆盖对账；发现未登记合入、并行窗口、对象不符、旧执行者未退出接管或来源伪造时立即暂停新领取，先核清受影响候选和写者。未知合入结果不重发 POST。已合入成果不自动回退。
+- [ ] 三项完成或触发停止条件时，按 M2-1–M2-6 列每个真实任务的最终 base/head、同步/新尝试原因、Review、GATE、合入树、开发/最终/main push/组件/闭卡 CI 次数与耗时、废弃原因；仅正常已登记顺序推进造成的最终 CI 废弃数作为目标指标。没有可比历史基线时不报告节省百分比，未发生的退出路径记 `NOT_RUN`。
+- [ ] 用户评审第二轮报告后决定继续 manual、调整预算、停止或另立自动准入；仅实际合入与经核验的能力可更新 Dev 采纳/矩阵。阶段 10 的安全回收按工作区 owner 和 `task-finish` 现场检查执行，任务闭合经有授权的 `task-close` 与智能体 PR 合入；保留所有原始收据。
+
+## Stage 5 decision and stop rule
+
+2026-10-14，负责人 weichen 在本任务会话中对 Documents 草稿 PR #105 的计划稿 `28c4ceb17315e1bb06f8e39c8407eb525effb8fe` 回复“通过阶段 5”，并选择由当前智能体逐项实施。批准覆盖本计划的阶段 6 候选编制与自检，不替代阶段 6–7 的人工结论，也不等于 #518 第二轮 active。任何实施中发现原子互斥、角色隔离或执行端 fencing 被要求为通过条件，应停止扩围并回到阶段 4 重设计，不能靠文字提升 `manual` 能力。

docs/proposals/2026-10-14-merge-queue-manual-phase2.md

@@ -0,0 +1,74 @@
+# Dev main 合入调度第二轮 manual 扩围设计
+
+状态：**阶段 4 方案设计与[阶段 5 实施计划](2026-10-14-merge-queue-manual-phase2-implementation-plan.md)均已通过；阶段 6 实施待评审**。2026-10-14，负责人 weichen 在本任务会话中对 Documents 草稿 PR #104 的规范稿 `aa4d372f01d0473928c570aa69c09ca771f2de45` 明确回复“通过阶段 4”，随后对 PR #105 的计划稿 `28c4ceb17315e1bb06f8e39c8407eb525effb8fe` 回复“通过阶段 5”，选择由当前智能体实施。这些批准不等于启用第二轮窗口或接管其他任务。执行协调者须在每个窗口明确登记。本文只设计 Dev 仓 `refs/heads/main` 的下一轮人工调度，不启用自动队列。
+
+主记录：[Dev 调度 Issue #518](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/issues/518)；既有规则：[Development-Guidelines 固定版合入调度](https://git-home.u1680832.nyat.app:30319/weichen/Development-Guidelines/src/commit/2f5b19872be2a4597838a4131ad75d1be089ee5e/standards/merge-queue.md)、[Dev 项目细化](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/src/branch/main/policy/merge-queue.md)；首轮结果：[三任务试行报告](../records/2026-10-14-merge-queue-trial.md)。本稿为下一轮范围与验收设计；动态队列状态只维护在 #518，不复制第二份任务进度表。
+
+## 1. 评审结论与问题
+
+首轮 #489、#488、#486 在同一协调者下顺序合入，每个真实任务只有一次最终 PR CI，三项各自合入后的 main CI 另计；没有因首轮正常顺序合入废弃的最终 CI。首轮报告将 MQ1、MQ5–MQ7 的未覆盖部分及自动原子领取、旧执行者拒绝列为部分满足或 `NOT_RUN`，不得据此宣布全仓自动约束已就位。
+
+2026-10-14 22:13（Asia/Shanghai）对 #518 当前正文/评论和 Dev PR #539–#548 的只读 API 对照（[SELF 观察快照](../records/2026-10-14-manual-phase2-source-audit.json)，原始本机文件 `/tmp/mq-manual-expansion-audit-20261014.json`）显示：这十个 PR 均已合入；[#540](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/540)、[#542](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/542) 有窗口领取与释放记录；#539 只有合入后的事实记录；其余七个在当前 #518 正文与所返回的评论中找不到对应 PR 的窗口记录。这是**记录覆盖缺口**，不等于断言这些合入未经其他人工协调。它使“所有 Dev main 写入者都受同一 manual 窗口控制”的结论无法成立。
+
+[#537](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/537) 曾取得旧候选绿色 GATE，但 Stage 8 审阅判为 `NOT READY`，窗口释放，后由用户取消且 PR 未合入；该例证明 CI 与人工阶段结论须分别核验。[#542](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/542) 的归档文字变化使旧候选作废，run 3100 不能放行新 head，run 3107 才属于实际合入对象。两者是应保留的正常失败/恢复事实，不计为“因正常排队 main 移动而浪费的 CI”。
+
+目前 Dev 开放 PR 只有 #482 与 #512：#482 非草稿但落后 main、平台回读不可合入；#512 为草稿。两者的既有绿色状态均属于旧对象，且未取得本轮写者接管确认。因此**当前没有可直接领取的第二轮任务**，不得为凑满数量生成生产 PR、自动同步它们或把队列扩围理解为接管授权。
+
+平台当前只读回读（SELF）：Dev `main` 禁直推/强推，拒绝落后分支，要求三个 PR 检查上下文 `ci / test`、`ci / test-pg`、`ci / svc-realcombo`，管理员不可绕过合入。它仍不能区分共用账号下的人与智能体，也未把 #518 的窗口写入变成原子锁或执行端 fencing。本轮不变更保护、批准数、CI workflow 或 runner 全局设置。
+
+## 2. 目标、范围与非目标
+
+**目标：**在保留人工阶段评审和现有平台准入的前提下，将首轮单一协调者的经验扩展为可供多个已授权任务 owner 依次使用的 **manual** 窗口；在候选固定后减少因正常排队合入而造成的无效同步和完整 CI；准确统计没有节省的成本与退出案例。
+
+**范围：**仅 Dev 仓库 ID=29、托管实例 `git-home.u1680832.nyat.app:30319` 的 `refs/heads/main`。普通 PR、任务卡闭合、紧急和机器人目标写入均须出现在同一调度记录；不同组件仓按各自目标协调。候选任务原卡仍是需求、授权、阶段和证据的主记录。第二轮以随后实际就绪的三个已授权真实任务为观察样本，闭卡 PR 单列成本与窗口，不充作三个业务任务。
+
+**非目标：**自动优先级、合并列车、批量/预测合并、复制旧 CI 状态、降低必需检查、调整分支保护、发布/部署、代替其他任务 owner 编写业务代码。#482、#512 和已取消的 #537 不因本设计自动变为就绪或重新授权。
+
+取舍：立即把所有 PR 宣称为受控 manual，管理成本最低，却与七条找不到 #518 窗口记录的实际合入不符；只点名三个任务而放任其他 main 写入，不能解决等待者因外部推进失效的问题；直接建设自动队列需要真实原子领取和执行端旧代次拒绝，超出用户选择的 manual 范围。本设计选择先确认已知写者覆盖与记录完整性，再接收三个真实就绪任务；覆盖不足时诚实标记并暂停，保留以后另立自动机制的边界。
+
+## 3. 第二轮 manual 协议
+
+### 3.1 入队与覆盖
+
+任务 owner 在最终同步之前登记目标仓库/分支、任务卡与 PR、授权范围及阶段结论、源 HEAD、依赖/组件、现有写者和预计最小重放集。`ready_at` 只在依赖已落主干、必要人工结论与写者排他确认均齐备时记录。尚缺任一条件的条目标 `blocked`，可以继续自己的局部开发，不领取窗口；入队不要求提前合入不断移动的 main。组件仓未交付时不占 Dev 窗口，也不持有一个目标窗口等待另一个目标。
+
+第二轮启用前，协调者核对当时的开放 PR、可推进 main 的工作区 owner、仓库协作者、机器人/webhook 和 workflow 入口，并取得**已知目标写者**采用同一窗口的确认。普通、闭卡、紧急及机器人合入均须走 #518；仍有未接入写者时如实登记其范围，不能声明全写者覆盖，也不能保证等待任务免于外部 main 移动。
+
+协调者按就绪时间与已批准的紧急理由安排顺序，领取前读回 #518、实际 Dev main/PR、分支保护和 runner 资源。#518 的当前窗口字段只写一个目标尝试；评论保留追加式时间线。领取后再读回核对，无匹配或发现另一执行者时停止。Issue 的 `content_version`、本地锁和评论均**不等于平台原子互斥**；本模式依靠明确写者遵约和受保护分支的最终准入。协调者换手时须确认前执行者退出及未知合入结果，不能凭 20 分钟超时自动接管。
+
+### 3.2 固定、检查与合入
+
+一个窗口以 `attempt_id` 标识：`target`, `owner/coordinator`, `claimed_at`, `last_progress_at`, `initial_base_sha`, `source_head_sha`, `sync_base_sha`, `frozen_head_sha`, 组件清单、检查定义、Review 对象、GATE 运行与真实结果。新增 `ready_at` 与 `queue_entered_at`，使任务等待时间和 runner 等待时间分开计算；时间未知时记 `NOT_MEASURED`，不倒推填造。
+
+窗口领取后执行一次真实 `task-sync`，处置冲突、物化已合入组件并完成应提交的任务卡/收据；此时才固定父仓候选。目标未变的验收、Review、合入节点只做同基线核验，不生成记录提交或重复完整 CI。最终 CI 仍由现行 workflow 在**固定 PR HEAD**上运行 `test`、`test-pg`、`svc-realcombo`；独立 Review、人工阶段结论与 CI 分别审查。合入前再次核对最新 base/head、组件、保护和三个 GATE 作业身份与结果；智能体使用固定 `head_commit_id`、`force_merge=false` 经 PR 合入，回读实际 main 树、合入 SHA、组件和后续 main push CI。
+
+源 HEAD、目标 base、组件、检查定义或相关环境改变时建立新尝试，并按影响补测/复审。旧结果保留其对象范围；不为减少 CI 次数制造绿色状态。开发期 CI、最终 PR CI、合入后 main CI、组件 CI 和闭卡 CI 分开统计。
+
+### 3.3 失效、异常与未登记推进
+
+发现 #518 未登记的 main 推进时，协调者先读回目标、PR、运行和活动窗口；将受影响的固定候选标失效，记录缺口来源与对象，暂停本轮新领取，待写者覆盖和影响范围核清后恢复。不得把“记录中没有”推断为平台阻断已生效。代码或 Review 失败、依赖不满足、需要人工决定超时：保存现场与原始证据，受影响条目 `blocked` 并安全释放；其它目标和局部开发继续。合入请求超时、断连或结果不明：保持目标 `reconciling`，查询 PR/main 真实状态；未确认旧执行者退出前不重发有副作用的请求，也不移交窗口。
+
+预算沿用首轮：无进展 20 分钟、单窗口 90 分钟、已知基础设施失败最多额外重试一次、等待队列每 30 分钟复核一次。领取前重新核对当时 runner 容量，不把首轮的 capacity=12 当作永久事实；资源不足先等待，不在窗口中空占名额。预算变化必须在实际成本复盘后另行评审。
+
+## 4. 验收、观察和停止条件
+
+| ID | 可判定条件 | 证据与边界 |
+|---|---|---|
+| M2-1 | 第二轮的三个真实任务均有原卡授权、阶段结论、owner 确认和先行组件；等待期间不为追 main 重跑最终 CI | 每任务原 R0、入队/就绪/领取时间、固定 base/head、源外收据；缺任务时保持等待，不制造 PR |
+| M2-2 | 每次 Dev main 实际合入在 #518 可找到同对象的先前领取和事后释放；闭卡、紧急、机器人同样登记 | 以实际 main merge/PR 列表对照 Issue 正文/时间线；遗漏即覆盖失败，不能声称“全写者受控” |
+| M2-3 | 稳定候选同基线重复 `task-sync` 不改 HEAD；对象变化拒用旧 Review/CI | 独立重放及精确运行 SHA；本轮记录每次新尝试原因 |
+| M2-4 | 三个真实任务各自取得当前 HEAD 三项必需 GATE 后由智能体合入，实际树与候选一致 | PR/run/job/actor/runner 链接及合入后 main 回读；平台仍是最终准入 |
+| M2-5 | 正常已登记任务顺序合入造成的最终 CI 废弃数为 0；候选整改、外部推进和基础设施失败另计 | 完整列出开发、最终、main push、组件、闭卡运行次数/耗时与废弃原因；无可比基线不报告节省百分比 |
+| M2-6 | 自然发生的 blocked/withdrawn/reconciling 均如实记录并安全处理；某类未发生则标 `NOT_RUN` | 不制造生产故障凑数；#537 历史可作设计参考，不冒充第二轮执行 |
+
+若有未登记 main 合入、并行窗口、对象不匹配仍合入、伪造来源、旧执行者未退出即接管，立即暂停扩围并先对账；这是试行停止条件，不自动回退已经合入的成果。三个条目及闭卡均核验后形成第二轮报告，人工评审是否保持 manual、调整预算或另立自动准入项目。本轮即使全部满足，也只证明声明范围内的**人工协作**；自动锁、所有角色的执行端隔离和旧代次 fencing 继续 `NOT_RUN`。
+
+## 5. 采纳顺序与阶段 4 决定
+
+1. 阶段 4 已由用户按规范稿 `aa4d372` 批准；智能体完成本设计的 Review 与 Documents PR 合入。阶段 5 计划获批前不改 Dev 规则/Issue 状态，不领取新任务。
+2. 另编实施/测试计划：对账 `policy/merge-queue.md`、`policy/adoption.md`、`policy/tool-adaptation-matrix.md` 的首轮历史快照与当前动态入口，确定 #518 第二轮条目模板和只读合入覆盖核对方法；有脚本变更时运行 `make test-governance`。规范源码、项目采纳及 Issue 记录分别标阶段，不把计划写入视作已启用。
+3. 经计划阶段评审后，按 Dev 首次 precheck、独立工作区、Review、当前 HEAD CI 与智能体 PR 合入流程交付必要规范更新。高后果保护变更若将来必要，仍由用户亲手执行，本设计不要求该动作。
+4. 各真实任务 owner 在自己的授权与阶段下自愿入队；协调者确认全写者覆盖、同目标唯一窗口和资源，再领取。当前 #482/#512 不满足这一步。
+5. 第二轮达到三个真实任务或触发停止条件后，按本设计 M2 指标复盘；由用户作继续、调整或回退的阶段决定。
+
+**阶段 4 决定：**用户已批准以“先补全 Dev main 合入记录覆盖、后接收三个真实就绪任务”的受控扩围作为第二轮设计，遗漏目标推进立即暂停、现有预算不变、闭卡单列成本，当前无就绪任务时保持 `waiting`。这一决定只批准设计；#518 与仓库规则的第二轮启用仍受阶段 5–7 评审及实际写者覆盖核验约束。

docs/proposals/2026-10-14-svc-plugin-compose-deploy.md

@@ -0,0 +1,80 @@
+# svc 插件组合部署（--with）方案 r1
+
+状态：**待评审**。日期：2026-10-14。负责人：weichen。
+任务卡：Dev `.task/feature-svc-plugin-compose.md`。
+需求来源：部署时用交互或参数选择把哪些插件与基座编译成同一个二进制服务，并在服务中激活这些插件。
+
+## 1. 范围
+
+做：
+
+- 每次 `svc.sh` 的 agent deploy 可以选择零个或多个已登记插件。
+- 被选中的插件与 `--from` 指定的 Dev 基座编译成一个仍名为 `agent-system` 的二进制。
+- 部署后校验这些插件已注册且命令面处于启用；失败走现有 release 回退。
+- 插件清单来自 Dev 仓 `plugins/registry.json`，不自动发现。
+
+不做：
+
+- 不做 sidecar，不把插件部署成独立服务。
+- 不让插件自带基座 pin。基座就是本次 `--from` 的 Dev 提交；对不上就构建失败并报原因。
+- 第一版最多一个带静态工作台（`web`）的插件。
+- 不删除旧的 `--from rdm`。它仍用 RDM 仓自己的 `pins/` 构建，与 `--with` 互斥。
+
+## 2. 步骤 0 试验结论（不留代码）
+
+2026-10-14 在 `/tmp/svc-compose-spike` 复制当前 Dev 的 backend 模块，空白导入
+`agent-system-rdm/plugins/rdm`（指向 `~/.cache/agent-system-svc/rdm-src`），
+`go mod edit -require/-replace` 后执行 `CGO_ENABLED=0 go build -mod=mod`。
+
+- 构建成功。产物约 40MB，`version` 仍是基座的 `agent-system 0.1.0-dev`。
+- `go version -m` 显示主模块 `agent-system-backend`，依赖 `agent-system-rdm v0.0.0`。
+- 二进制内可见 `rdm.project.create` 与 `rdm.ping`。
+- 聚焦依赖（`golang.org/x/*`、`github.com/jackc/*`、`modernc.org/sqlite`、`gopkg.in/yaml`）版本无变化。
+- 新增模块只有 `agent-system-rdm`、`github.com/kr/text`、`github.com/rogpeppe/go-internal`。
+- 默认 `-mod=readonly` 会拒绝更新 `go.mod`/`go.sum`，组合构建必须使用 `-mod=mod`。
+- 依赖模块自己的 `replace` 不生效，插件按主模块（Dev 基座）解析 `agent-system-backend`。这正是“基座以 Dev 提交为准”所要的结果。
+
+试验目录是一次性的，不进入任何仓库。
+
+## 3. 行为
+
+### 3.1 选择
+
+- `--with rdm,foo` 选择插件；`--with rdm@<sha>` 钉住单个插件提交；`--with none` 明确不带插件。
+- 标准输入是终端且没有 `--with` 时，按登记表给出编号勾选。默认勾选上次 `svc.env` 的 `plugins=`；第一次默认不选。回车接受默认，`none` 清空。
+- 非交互且没有 `--with`：沿用上次选择，没有则不带插件。已有脚本和 CI 的行为不变。
+- `--dry-run` 打印基座提交和每个插件的提交，不构建。
+- `--from rdm` 与 `--with`（除 `none`）互斥。`--from release` 不能再注入插件。
+
+### 3.2 构建
+
+1. 物化 Dev 提交的隔离 worktree，并完成前端构建，使嵌入资源就绪。`--from local` 不改主检出的 `go.mod`：把 backend 模块复制到 `runtime/.worktrees/` 再构建。
+2. 每个插件使用独立源仓缓存（`~/.cache/agent-system-svc/plugin-<id>`，`repoEnv` 可覆盖克隆地址）并物化 worktree。
+3. 在这份一次性 backend 副本里生成 `cmd/agent-system/zz_plugins_gen.go`（空白导入 `entryPackage`），并用 `go mod edit` 增加 `require` 与 `replace`。
+4. `go build -mod=mod` 产出 `agent-system`。基座的 `version`、身份和 `user` 等子命令保持不变。
+5. 测试可设 `SVC_COMPOSE_STUB=1`，跳过真实 `go build`，只记录插件选择。这不是生产路径。
+
+### 3.3 激活与记录
+
+- `GET /api/plugins` 与 `GET /api/registry` 的 `compiled` 列表必须包含每个所选插件。
+- `GET /api/commands` 中该插件 `commandPrefix` 下至少有一条 `enabled` 命令。
+- 插件在而命令全部禁用时，用与设置播种相同的临时管理员 key 调用 `POST /api/plugins/{id}/enabled`，再复查。失败则 `svc_rollback_deploy`。
+- `svc.env` 写 `plugins=id@sha,id@sha`。`source` 形如 `dev@<sha>+rdm@<sha>`。release 目录的 `release.json` 带同一 `plugins` 字段。
+- `update` 把基座升到远端最新，并原样带上已记录的 `--with`，不再询问。`recover` 只拉起已有二进制，不重新选择。
+- 插件 id 集合变化（含从无到有、从有到无）与源种类变化一样，需要 `--allow-source-switch`。只改提交不需要。
+
+### 3.4 工作台
+
+登记表里 `web` 非空的插件，沿用现有伴生 static 服务（`<name>web`）。多于一个带 `web` 的插件直接拒绝。
+
+## 4. 跨仓
+
+- Backend：`extension.InProc` 增加可选 `HostOptions` 与 `CLI`。布尔默认按“任一为 true”合并，不覆盖显式 serve 旗标。`GET /api/registry` 增加 `compiled`。
+- RDM：`plugins/rdm` 在 `InProc` 上声明 `HostOptions`（含关闭上传自动索引、会话卡镜像、执行原语）和 `-bootstrap-admin` 钩子。RDM 自己的 `main.go` 继续可用，旧 `--from rdm` 不依赖这次钩子。
+- Dev：`scripts/svc.sh`、`plugins/registry.json`、`docs/svc.md`、`help plugins`、`tests/test_svc_plugins.py`，并推进 backend 与 documents 的 gitlink。
+
+## 5. 验收
+
+- 登记、选择、换源门禁、dry-run、stub 部署与激活走 `tests/test_svc_plugins.py`。
+- Backend 的合并与 CLI 钩子走 `go test ./pkg/extension/`。
+- 真实 `go build` 组合（Dev 提交 + RDM 提交）在步骤 0 已证实可编译。带网络的完整 `svc deploy --with rdm` 与 `make test-lifecycle` 不在本增量的 stub 套件里，未在本机再跑时标 NOT_RUN。

docs/proposals/2026-10-15-layered-python-env.md

@@ -0,0 +1,108 @@
+# 分层 Python 环境方案 r1
+
+状态：待评审（收录不是批准）。编制：2026-10-15。
+触发：dev 8788 会话 `cnv_7936c0a799ff` 中，智能体无法把已有 Markdown 摘要渲染成 docx，并向用户报告「没有 Python 对应的包」。
+
+## 1. 已核实的故障（不是「缺包」本身）
+
+8788 的 `run_python` / `run_shell` 跑在 bwrap 沙箱里（只读根、`--tmpfs /home`、`--unshare-net`）。同一台宿主机的 `~/.local` 里其实已经有 python-docx、lxml、openpyxl、python-pptx。失败来自四件事叠在一起：
+
+1. **依赖层没有接线。** 代码已有 `--exec-deps-dir`（F3），但 `scripts/svc.sh` 与 8788 的启动参数都没有传入它。沙箱把 `/home` 遮掉之后，`~/.local` 不可见。
+2. **解释器解析到会被遮掉的路径。** 服务进程的 `PATH` 里 linuxbrew 在 `/usr/bin` 之前，`python3` 被解析成 `/home/linuxbrew/.linuxbrew/bin/python3`。沙箱里这条路径不存在，`run_python` 得到 `exit=127`。
+3. **工具说明指向一条走不通的安装路径。** `run_python` 描述和 `base.deliverables` 都写「缺库先 `pip install --user`」。沙箱断网、根只读、家目录是空 tmpfs，这条命令必然失败。
+4. **没有向系统申请包的通道。** 智能体只能探测、报错、让用户选择，再派一个后台任务去轮询一个永远不会出现的依赖。
+
+同一次会话里还有多次模型网关 `401 invalid_api_key`。那是密钥问题，不在本方案范围内。
+
+## 2. 目标
+
+每个工作区和沙箱都能直接使用系统提供的 Python 能力（解释器 + 办公与数据处理基础包），不必各自新建虚拟环境。某个工作区需要额外的包时，向系统申请；系统决定装不装，并只把结果挂给这个工作区。
+
+成功标准：
+
+- 沙箱内 `import docx, openpyxl, pptx` 成功，`python3 -m housestyle.build` 能产出通过结构自检的 docx。
+- 两个工作区要同一包的不同版本时，互不影响，基础层版本不变。
+- 沙箱仍然断网。安装只发生在宿主侧的构建器里，并且只接受带哈希的预编译 wheel。
+- 白名单内的包自动批准；白名单外、要改基础层版本、体积超限、用户上传的 wheel，弹审批卡。sdist 与黑名单直接拒绝。
+
+## 3. 不采用的两条路
+
+- **每个工作区一个 venv。** 贵的是重复下载、解析和安装，不是 venv 目录本身。同样的包会被装很多遍。
+- **所有包装进一个可变的系统环境。** 一个工作区的需求会改变所有工作区的行为，版本冲突无法隔离，也无法复现「当时用的是哪一套包」。
+
+## 4. 采用的结构
+
+所有环境层不可变，按内容哈希命名，按会话挂载。系统只新增层，不改已经发出去的层。
+
+```text
+<envroot>/                      默认 runtime/envs/，各服务实例共享
+  python/cpython-<ver>/         系统托管的 CPython（只读）
+  python/current -> 上述目录
+  layers/base-<hash>/site-packages
+  layers/x-<hash>/site-packages 扩展层：相对基础层的增量闭包
+  layers/iso-<hash>/site-packages  完整隔离层：仅在审批通过「覆盖基础层版本」时使用
+  wheelhouse/                   按 sha256 去重的 wheel
+  locks/<hash>.json
+  catalog.json                  白名单、黑名单、单包体积上限
+  current -> layers/base-<hash>
+  bin/pip                       垫片：提示改用 python_env，不以安装成功退出
+```
+
+层键 = 锁文件内容 + Python 标签 + 平台的哈希。同一份需求在任何工作区都命中同一层。
+
+基础层由系统策划，首批为：python-docx、openpyxl、python-pptx、lxml、Pillow、numpy、matplotlib、pypdf、reportlab、markdown、pdfplumber，以及它们的传递依赖。名单可以在评审时增减；锁文件在第一次 `env ensure` 时生成并应入库，之后构建按锁复现。
+
+解释器优先使用托管前缀（python-build-standalone 的 install_only 包）。下载失败时，退化为用系统 `python3 -m venv` 做一份唯一的托管前缀，并在 `python/SOURCE` 里写明这是退化，不是每个工作区各做一份。沙箱里的 `python3` 永远是这个前缀的绝对路径；找不到托管前缀时才用 `/usr/bin/python3`，不再走会落到 `/home` 下的 `PATH` 查找。
+
+## 5. 一次执行如何看到这些包
+
+沙箱参数在 `--tmpfs /home` 之后，只读挂载：托管解释器前缀（如果它位于会被 tmpfs 遮住的路径上）、基础层、该会话绑定的扩展层。`PATH` 固定为 `<托管 bin>:<envroot>/bin:/usr/local/bin:/usr/bin:/bin`，不再继承宿主 `PATH`。`PYTHONPATH` 是这些层再加上 house-style。`PIP_NO_INDEX=1`。
+
+扩展层与基础层来自同一次以基础层为约束的解析，每个发行名只有一个版本，所以叠放顺序不影响导入。隔离层例外：它替换基础层，而不是叠在上面，用来满足「这个工作区必须要 numpy<2」这类与基础层冲突的需求。
+
+## 6. 申请（工具 `python_env`）
+
+动作：`status`、`request`、`wait`。
+
+- `status` 返回基础层包清单、本会话已绑定的层、未完成的申请。
+- `request` 带包规格或工作区内的 `.whl`。解析以基础层锁为约束（等价于带 constraints 的 `pip install --dry-run --report`）。分级：
+  - 全部在白名单内、纯 wheel、未超体积：自动批准并构建。命中已有层时只是多挂一个目录。
+  - 白名单外、要覆盖基础层已固定的版本、超体积、用户上传的 wheel：写入 `exec_env_requests`，发一张选择卡（批准 / 拒绝；覆盖基础层版本时多一个「建隔离层」）。系统管理员或该会话的属主可以批。决定写入 `audit_events`。
+  - 只有 sdist、命中黑名单、解析失败、哈希不符：拒绝，并说明原因。
+- 构建在宿主侧进行：`--only-binary=:all:`，校验 sha256，只用解包 wheel，不执行 setup.py。这是唯一有网络的步骤，并且不在沙箱里。
+- 构建完成后把层 ID 写进 `exec_env_bindings`。下一次 `run_python` / `run_shell` 挂上这些层。`wait` 在短超时内轮询申请状态。
+
+## 7. 三个顾虑如何被挡住
+
+- **成本。** 基础层覆盖常见办公和数据场景。wheel 与层按哈希缓存，第二个工作区要同一套包时不再下载、不再解析。
+- **冲突。** 不存在共享的可变环境。冲突需求要么被拒绝并说明卡在基础层的哪一个版本，要么经审批得到一份只属于该会话的隔离层。基础层哈希不变。
+- **包都堆进系统环境。** 基础层只放策划过的包。扩展层按会话绑定，其他会话看不见。升级基础层生成新的 `base-<hash>` 并移动 `current`；已经绑定旧基础层的会话保持不动，直到显式 rebase。
+
+## 8. 安全
+
+- 沙箱断网、根只读、家目录遮蔽，这些都不放宽。
+- 不在宿主上执行第三方构建脚本。
+- 只挂当前会话绑定的层。
+- 申请记录含会话、包、wheel 哈希、批准人。
+- 任务封存时应能读到基础层哈希与层 ID（绑定表就是这份清单）。
+
+## 9. 实施切片
+
+- **P0** 解释器与 `PATH` 不再指向会被沙箱遮住的 linuxbrew；`svc.sh` 在环境根存在时传入 `AGENT_SYSTEM_EXEC_ENV_ROOT` 与基础层 `AGENT_SYSTEM_EXEC_DEPS_DIR`；工具说明与提示词改为 `python_env`，去掉 `pip install --user`；配置了依赖层时启动做真实导入探针。
+- **P1** 环境根、锁、层、wheelhouse、托管解释器，以及 `agent-system env ensure|lock|gc|doctor|rebase|python`。
+- **P2** 表 `exec_env_requests`、`exec_env_bindings`，工具 `python_env`，分级审批，pip 垫片，按会话挂载。
+- **P3** 管理区「Python 环境」页（层、申请、批准/拒绝、rebase、gc、上传 wheel）。
+
+## 10. 验收
+
+- `sandboxArgv` 覆盖多层只读挂载、固定 `PATH`、`PIP_NO_INDEX`。
+- 离线解析夹具：冲突、白名单、sdist 拒绝、哈希不符。
+- 有 bwrap 时：沙箱内能导入层里的模块，`pip` 垫片给出申请指引，外网不可达。
+- 两个会话分别要 `foo==1` 与 `foo==2`，各得一层，基础层哈希不变。
+- 在基础层可用时，`housestyle.build` 产出的 docx 通过既有 OOXML 结构自检。
+
+## 11. 已定与未定
+
+已定（2026-10-15 对话）：白名单内自动批准，其余弹审批卡；解释器由系统托管，而不是长期绑死宿主 `/usr/bin/python3`。
+
+未定，留在评审：基础层最终包名单是否增减；审批人除系统管理员和会话属主外，是否还要接项目角色。本实施先只认系统管理员与会话属主，避免在基座里发明第二套项目角色判断。

docs/proposals/2026-10-15-rdm-duty-matrix-rework.md

@@ -0,0 +1,48 @@
+---
+title: 文档职责矩阵整改
+date: 2026-10-15
+type: feature
+execution: code
+artifact_contract: rdm-duty-matrix/v1
+product_contract_source: legacy-requirements
+---
+
+# 文档职责矩阵整改 r2
+
+负责人：weichen；编制日期：2026-10-15。
+本记录是文档职责整改的唯一主记录。它取代
+[r1 增量方案](2026-10-13-rdm-settings-members-duties-perms-increment.md)
+第四节，以及该方案 P5、P7 中“文档职责页”的交互；r1 的设置归属、成员、权限矩阵与其余工作包继续有效。
+
+候选分支 `feature/rdm-settings-completion` 里的文档职责界面暂停合入。系统设置、成员选择、权限矩阵和已落地的后端安全能力不在本暂停范围内。本任务从当时的 `origin/main` 另起兄弟分支 `feature/rdm-duty-matrix`，不把该候选当作父分支。
+
+## 四项领域裁定
+
+1. 职责只到文档级。项目设置不再新增章节级职责；历史章节审签只读保留。
+2. 项目设置只分配已有受控文档的编制、审核、批准职责。不创建文档、不从模板生成、不提交审核、不审核通过、不驳回、不终批。
+3. 每份文档恰好一名编制、至少一名审核、恰好一名批准。同一人在同一文档上只担一个职责。审核可以有多人。
+4. 与文档职责完全一致的旧章节覆盖可以归并为文档级。同一文档下章节人员不一致的，列出清单，由项目负责人逐文档确认，不自动覆盖。
+
+项目负责人可以分配职责，但不因负责人身份自动成为编制、审核或批准人。当前职责与已冻结的审签名单分开保存；修改当前职责不改写已批准版本和历史名单。
+
+姓名来源仍按 r1 评审补充第 3 条待证。本页用账号标识展示，不把未证实的姓名字段写进契约。
+
+## 契约
+
+读：`rdm.duty.matrix`。`view` 为 `member`、`document` 或 `matrix`。筛选在分页之前。文档页上限 20。响应给出文档完整性、`dutyVersion`、章节覆盖数、在途轮次、成员资格、单元格 `none|author|reviewer|approver`，以及当前操作人是否可分配。单元格只投影当前文档级职责。没有 `duty.assign` 的调用直接拒绝，避免矩阵列头泄露不可见文档。
+
+写：唯一入口仍是每份文档的完整目标，`rdm.review.assign.doc` 与 `rdm.review.assign.doc.batch`（1–20 项，整批原子）。带 `expectedDutyVersion` 与 `confirmInvalidation`。`rdm.review.assign` 只返回“章节级职责已停用，请在文档级设置”。
+
+预览：`rdm.duty.preview` 与写载荷相同，只读返回替换对象、在途失效和缺人原因，不写数据。保存时服务端重新校验。
+
+迁移：`rdm.duty.legacy.scan` 只读；`rdm.duty.legacy.apply` 只清除与文档职责完全一致的章节覆盖。
+
+## 三视图
+
+按人员、按文档、成员×文档矩阵共享同一份服务端数据和同一份未保存草稿。单元格由文档三权反推。把唯一编制或批准改成其他值可以继续编辑，但在指定接替人前不能保存。替换已有编制或批准时提示“将替换某某”，保存时一次替换。窄屏不压缩整张矩阵，改走前两个视图。一次保存最多 20 份文档。请求带递增序号，过期响应丢弃。写入结果未知时重读，不自动重放。
+
+页面顶部写明：本页只分配已有文档的职责，不创建或生成文档。
+
+## 验收
+
+单文档三权恰好、多审核人、一人一责、三视图草稿一致、替换提示与原子替换、缺人禁止保存、成员失效保存被拒、版本冲突、批量整批失败不写、影响预览与历史不变、无私密文档列头泄露、无创建/生成/审签按钮、迟到响应不覆盖、design-guard、`make test` 与 `make build`。部署和真实账号浏览器验收另行授权。

docs/proposals/INDEX.md

@@ -4,8 +4,17 @@
 本索引负责导航与差异提示，规划正文、批准范围和验收条件仍以链接的主记录及其批准版本为准。
 合入授权不批准新方向、不调整里程碑范围、不启动新的业务任务。
 
+待评审（收录不是批准）：[svc 插件组合部署（--with）方案 r1](2026-10-14-svc-plugin-compose-deploy.md)；
+[分层 Python 环境方案 r1](2026-10-15-layered-python-env.md)（8788 无法生成 docx 的环境层；白名单自动批准，其余审批）。
+
 ## 先看哪一份
 
+- [IAM I1 权限边界与公开扩展合同 r1](2026-10-13-iam-i1-permission-contract.md)：
+  依据已批准的[用户、职位角色与分层权限统一方案 r1](2026-10-13-identity-role-permission-plan.md)
+  （Documents `a088809`）冻结系统／项目／资源边界、管理员无业务 bypass、创建者 cap、独立 `audit.read` 与公开扩展四要素。
+  2026-10-13 已授权 I1（U1–U2）；多职、通用角色迁移、资料目录、矩阵及完整运行验收仍按后续单元推进，不以合同保存宣称已交付。
+  实际进展与证据见 [I1 实施候选与评审记录](2026-10-13-iam-i1-review.md)，用户实施评审及[阶段 7 验收](2026-10-13-iam-i1-acceptance.md) 已通过，当前进入智能体 Review、PR、CI 与合入。
+
 - [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md)：
   运行卡呈现状态、已完成工作、当前发现与剩余项；四层阅读、阶段成果、来源、异常恢复及 U1–U4。
   2026-10-12 方案设计已批准（阶段 1–4）；首批仅 U1；[U1 实施计划 r1](2026-10-12-fast-slow-channel-display-u1-plan.md) 待阶段 5 批准；业务实施和运行验收 NOT_RUN。
@@ -172,7 +181,13 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
 
 ## 2026-10-13 规划补充
 
-- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md)：承接总案 U3/U4/U6（衔接 U5）的完整增量——设置作用域与受管项、可搜索人员选择器、文档清单＋职责分配、单成员/多人权限矩阵与三态项目覆盖；含服务端一致性修复（职责目标成员校验推翻 G1-5 旧裁定、职责变更与审签失效原子化）与 P1–P8 工作包。**2026-10-13 用户评审通过并授权实施**（两批推进；正式验收与清理回收保留人工节点）；P1 契约随本稿固定，P2 基座契约扩展按总案发版顺序排队。
+- [最终验证与合入调度实施计划 r1](2026-10-13-merge-queue-implementation-plan.md)：阶段 5 已于 2026-10-13 经用户「批准」确认，原生逐项实施；U1–U3 源码与自检在 Dev 任务分支推进，U4 待启用记录及规则已准备，U5 平台所有者操作与 U6 真实三任务 CI 试行仍 NOT_RUN。实际对象、证据和进度回链 Dev 任务卡，不把本索引当第二进度权威。
+
+- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md)：承接总案 U3/U4/U6（衔接 U5）的完整增量——设置作用域与受管项、可搜索人员选择器、单成员/多人权限矩阵与三态项目覆盖；含服务端一致性修复。**2026-10-13 用户评审通过并授权实施**。第四节及 P5/P7 的文档职责页交互已被下方 r2 取代，其余部分继续有效。
+
+## 2026-10-15 规划补充
+
+- [文档职责矩阵整改 r2](2026-10-15-rdm-duty-matrix-rework.md)：项目设置只分配已有文档的编制、审核、批准；按人员、按文档、成员×文档三视图共享一份草稿。章节级新指派停用，有歧义的旧章节职责逐文档确认。2026-10-15 按实施方案执行；部署与真实账号验收未授权。收录不把其余未完成增量自动标成已验收。
 
 ## 2026-10-12 规划补充
 
@@ -184,8 +199,12 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
 
 - [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md)：对应 P3/MS3，源码已有部分实现；优先补项目绑定、创建者/管理员读取隔离与历史完整性，再接统一展示。用户确认范围为 RDM 与必要基座能力；r1 已获用户评审通过（2026-10-11，五阶段一并，含 KTD4 双层管理员裁定）。U1–U5 全部实施合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11；超管槽待基座能力接线，见 RDM 仓 U1 基座扩展申请）。U6 团队存储独立后续；运行验收属部署环境。
 
-- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md)：69 类旧资产、4 个当前注册模板的盘点及生成闭环设计；待评审，实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认（2026-10-11），其余方案与实施仍待评审。
+- [DHF 模板接入 RDM 文档生成管线 r0.1](2026-10-14-dhf-template-generation-plan.md)：用户于 2026-10-14 批准本方案并启动实施。RDM 的首批资产合同与 44 份原件目录已在独立任务分支保存；14 份 DOC 均有自动转换候选，E1 内容与版式保真仍待人工评审，正式模板发布数为 0。真实《项目建议书》的结构/槽位评审候选已形成；U1 整体、U2–U6 用户流程、正式验收与部署尚未完成。与在途两树任务沿用同一 TT-T/TT-D 契约；每阶段仍按既有人工评审门禁推进。
+
+- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md)：69 类旧资产、2026-10-11 四个注册模板的历史盘点及生成闭环设计；待评审，实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认（2026-10-11），其余方案与实施仍待评审；2026-10-14 资产和源码刷新见 DHF 专项。
 
 - [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md)：本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界；覆盖 34 UR／68 SR／10 F、全部69类模板及现有XLSX，当前源复核 RDM d8d7e743。总体方案待评审，实施/迁移/运行验收 NOT_RUN；模板方案为子方案。
 
 - [工作台界面重设计 r0.2](2026-10-12-work-companion-ui-design.md)及[实施计划 r1](2026-10-12-work-companion-ui-plan.md)：对话优先、渐进任务摘要、窄屏与单一状态投影；已获本次连续实施授权。
+
+- [系统项目、成员工作入口与私域协作闭环 r1.1](2026-10-13-system-project-membership.md)：2026-10-13 已批准方向及阶段 1–9 连续推进；统一生命周期、成员个人会话、每项目两树一网与私域权限；组合验收/CI/tag 消费推进中，部署和线上修复未授权。

docs/records/2026-10-14-dhf-assets.json

@@ -0,0 +1,589 @@
+{
+  "source": "SELF",
+  "dev_sha": "add097d06137c4912a4ed9279e98ca353e4e4cf1",
+  "rdm_sha": "6fcb256205c2384abed35d3b6ab96ca7216e9297",
+  "rdm_frontend_sha": "eb2d6d32f9323094d568bc9d80b4e5ed4f0af25b",
+  "rdm_frontend_preview_sha256": "0f53735a5b58d4c7c545ceb56ce02d0305af47f379f16d92295323a68dd5f13d",
+  "summary": {
+    "count": 44,
+    "formats": {
+      "docx": 30,
+      "doc": 14
+    },
+    "unique_content": 41,
+    "phases": {
+      "0. 商务阶段": 1,
+      "1. 策划阶段": 3,
+      "2. 设计输入阶段": 15,
+      "3. 设计输出阶段": 9,
+      "4. 设计验证阶段": 8,
+      "5. 设计转换阶段": 3,
+      "6. 设计确认阶段": 5
+    }
+  },
+  "assets": [
+    {
+      "source": ".templates/DHF 文件模板/0. 商务阶段/0.1初始要求申请表.docx",
+      "format": "docx",
+      "bytes": 17137,
+      "sha256": "eb9d287014911a18c5589a0b9e7b7f63ad535178cf7cf29a3a269dcf46118391",
+      "tables": 2,
+      "gridSpan": 0,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/1. 策划阶段/1.1、731QCP29-F01 项目建议书 02.docx",
+      "format": "docx",
+      "bytes": 25114,
+      "sha256": "3f54f060d9c528e3fd4e7b7c606f352fbabe9488a25ad95a7341fa7901518b29",
+      "tables": 2,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/1. 策划阶段/1.2、731QCP29-F02 设计开发计划任务书 02.docx",
+      "format": "docx",
+      "bytes": 36248,
+      "sha256": "d152b0b4d2bb1aa30c60aaec19e331a05a552d7d119f5a6f4cc4177f163159fb",
+      "tables": 7,
+      "gridSpan": 6,
+      "vMerge": 106,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/1. 策划阶段/1.3、731QCP29-F07 设计开发（策划）评审记录 02.docx",
+      "format": "docx",
+      "bytes": 26043,
+      "sha256": "d6f3cca9c3c1f7ed1ea60322c5435f8410d6cf7ca2096b04a367fc8255ee1330",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.10.1、731QCP29-F13 配置管理计划 02.docx",
+      "format": "docx",
+      "bytes": 58902,
+      "sha256": "94e8e7fc868d76c62199fdeb30ea0aab7db3c58a36ef94aef15d629f4930b11a",
+      "tables": 5,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.10.2、软件维护计划模板.docx",
+      "format": "docx",
+      "bytes": 166962,
+      "sha256": "76fc4d4fddecc04e533aceb930aab9b82f4956c6bf5fb3d04f19150003c7932e",
+      "tables": 2,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/footer2.xml",
+        "word/footer3.xml",
+        "word/footer4.xml",
+        "word/footer5.xml",
+        "word/footer6.xml",
+        "word/header1.xml",
+        "word/header2.xml",
+        "word/header3.xml",
+        "word/header4.xml",
+        "word/header5.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.11.1、731QCP29-F16设计输入规格书模版.docx",
+      "format": "docx",
+      "bytes": 68678,
+      "sha256": "3fef2ed7d0aa5e0ac8c01b92571b0ce9dbe3a8191a06d7a79d799fb62fe5e613",
+      "tables": 17,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.12、731QCP29-F05 设计开发输入清单 02.docx",
+      "format": "docx",
+      "bytes": 20681,
+      "sha256": "de990de6bf13e4c692a9664719f508cf2d34765b14ddd77fbb58879c99dee6da",
+      "tables": 2,
+      "gridSpan": 4,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.13、RDDHF0213-xxxx产品系统设计方案.doc",
+      "format": "doc",
+      "bytes": 419499,
+      "sha256": "8168ea37c7ca5f32f5d57527d0c8ff5c2d583998167e30ed713937c95e9e82d4",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.14、731QCP29-F07 设计输入评审记录.docx",
+      "format": "docx",
+      "bytes": 28675,
+      "sha256": "a3677cb06a3946769e501f906669f57c4cd21769109ad5e27697d76320fa8686",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.1、731QCP29-F14 用户需求模板.doc",
+      "format": "doc",
+      "bytes": 115712,
+      "sha256": "2f9c6795f81188797018ef7e2ba4c7e693db0f3fabaa2eb5a9478fb2e2b1a6ac",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.2、RDDHF0202-xxxx 医疗器械法规和标准清单.docx",
+      "format": "docx",
+      "bytes": 29384,
+      "sha256": "2b36daeedc8c54a7975ece49102d279584bb80a5ff262912db2941edf009feec",
+      "tables": 3,
+      "gridSpan": 5,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.3、RDDHF0203-xxxx 同类产品不良事件信息.docx",
+      "format": "docx",
+      "bytes": 29958,
+      "sha256": "f7cd69b08c1ec1bea04ec8a30aaa54f6d8bed90a6e9544c3b9264341ac299edc",
+      "tables": 3,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml",
+        "word/header2.xml",
+        "word/header3.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.4、731QCP29-F15 系统需求规格书模板.doc",
+      "format": "doc",
+      "bytes": 119296,
+      "sha256": "b58d1b900c951f8c20b5f301cb75e072a91c98ab3d71b172128b51dc84c8bff3",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.5、731QCP29-F07 需求评审记录表.docx",
+      "format": "docx",
+      "bytes": 27823,
+      "sha256": "102ed2b6418b51b383de97a735b8a183d025af9da139152d92715e44ba860b1b",
+      "tables": 6,
+      "gridSpan": 42,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.6、731QCP29-F03 风险管理计划 02.docx",
+      "format": "docx",
+      "bytes": 31626,
+      "sha256": "0c1484d6b29595077c9b60e08a69c73d008216744e7df59f83c0e7054f1e51c9",
+      "tables": 7,
+      "gridSpan": 8,
+      "vMerge": 13,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.7.3、731QCP29-F04 风险管理报告 02.docx",
+      "format": "docx",
+      "bytes": 29910,
+      "sha256": "d4f18eb817dae8b655715c6832b591299d0e5c7c1196e777cf9e48e79b4f3544",
+      "tables": 6,
+      "gridSpan": 8,
+      "vMerge": 13,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.8、731QCP29-Fxx 软件开发计划-模板.doc",
+      "format": "doc",
+      "bytes": 300544,
+      "sha256": "2dee0e085113adc4868546b2469eab89c076b6c8613417b3897e975a2adb4e29",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/2. 设计输入阶段/2.9、软件需求规格书模板.docx",
+      "format": "docx",
+      "bytes": 48903,
+      "sha256": "aa12be2b8158439c91b77df5a90fd2d71aa658186e37332c54a6766b572b4a30",
+      "tables": 10,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.12、原材料进货检验规范-模版.docx",
+      "format": "docx",
+      "bytes": 995696,
+      "sha256": "34608b520ebff384cdb613818271a04d3e7fc9a71da693cdd51550ab0b38bf0c",
+      "tables": 18,
+      "gridSpan": 124,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/footer2.xml",
+        "word/header1.xml",
+        "word/header2.xml"
+      ],
+      "linked_images": [
+        {
+          "part": "word/document.xml",
+          "link": "rId12",
+          "embed": "rId11"
+        }
+      ]
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.15、产品技术要求.doc",
+      "format": "doc",
+      "bytes": 16896,
+      "sha256": "b787295c6c66089cb0895a1f9ebd77058091bb85355910f84d014613470b2512",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.17、731QCP29-F06 设计开发输出清单 02.docx",
+      "format": "docx",
+      "bytes": 22792,
+      "sha256": "f53a2f271bf2782ab12cba1f26a141d5560e7e7aa905a0a74b46b10bbf43e84b",
+      "tables": 1,
+      "gridSpan": 4,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.18、731QCP29-F07 设计输出评审记录.docx",
+      "format": "docx",
+      "bytes": 28214,
+      "sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.6.2、软件详细设计模板.docx",
+      "format": "docx",
+      "bytes": 51735,
+      "sha256": "e1089b1de6d2c06e5468adfa7f28b9cfaa13b3382f299e9e0af204543d221c20",
+      "tables": 30,
+      "gridSpan": 0,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.8、RDDHF0213-xxx采购技术说明-结构&硬件.doc",
+      "format": "doc",
+      "bytes": 7791188,
+      "sha256": "77fd422be6f37632052d47a05490312a8e36098eceb6d529653f59dde8fe51ef",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.9.1、731QCP29-Fxx 工艺流程图模板.doc",
+      "format": "doc",
+      "bytes": 199173,
+      "sha256": "1d702e1cdbdca52fe7957b01d13f15f77d447d78498a78e332d4646e27ee014c",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/3.9.2、RDSOP00xx-00xx xxx作业指导书.docx",
+      "format": "docx",
+      "bytes": 6312572,
+      "sha256": "e2d5e596ee1fa24ddd4166f41575167ed054451beb6fdbd1d1bccd15a709ef48",
+      "tables": 7,
+      "gridSpan": 1,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/footer2.xml",
+        "word/footer3.xml",
+        "word/header1.xml",
+        "word/header2.xml",
+        "word/header3.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/3. 设计输出阶段/731QCP33-F01 软件可追溯性分析报告 02.docx",
+      "format": "docx",
+      "bytes": 24006,
+      "sha256": "23d6402dc8511a1ed7815082cc00822f9d62e3b74509bd75302987bfdf538f8a",
+      "tables": 3,
+      "gridSpan": 4,
+      "vMerge": 10,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/24.产品有效期验证.doc",
+      "format": "doc",
+      "bytes": 144292,
+      "sha256": "425e993090eb84c5a88fbc6fe2d664d788d4879a7e173bd8a235b6aa0589311d",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/41.软件单元测试用例-模板.doc",
+      "format": "doc",
+      "bytes": 57249,
+      "sha256": "02f41e0770380332105851d620fbcfc470dbef93d2e7fa55c4b1dad441a7fcc0",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/42.软件集成测试用例-模板.doc",
+      "format": "doc",
+      "bytes": 60369,
+      "sha256": "1a373f9bec235d6771fceec15341c858412737298fad696dd68cb9bf262a5dec",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/43.软件系统测试用例-模板.doc",
+      "format": "doc",
+      "bytes": 60915,
+      "sha256": "22b211453d734668bd8b6a5948a5612ec93bde41838ee0fe0535551124566062",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/49. 软件配置管理报告-模板.doc",
+      "format": "doc",
+      "bytes": 63121,
+      "sha256": "243993a6ab53b475139afbeef04c9be0d593956bb2ae4e90f77c22b2e38b0063",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/731QCP29-F07 设计验证评审记录.docx",
+      "format": "docx",
+      "bytes": 28214,
+      "sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/731QCP29-F08 设计开发验证记录 02.docx",
+      "format": "docx",
+      "bytes": 24111,
+      "sha256": "c5b84546e647259f25b9445358ff93ecf61e047075d83a87b1f0f928df32f69a",
+      "tables": 1,
+      "gridSpan": 14,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/4. 设计验证阶段/756QCP26-F02 验证确认报告 V03-.docx",
+      "format": "docx",
+      "bytes": 42712,
+      "sha256": "f5bbe7816e79a62e7bbbf297014be98a63b9ec306999a09723bef1a78d60b3fd",
+      "tables": 12,
+      "gridSpan": 2,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/footer2.xml",
+        "word/header1.xml",
+        "word/header2.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F04 风险管理报告 02.docx",
+      "format": "docx",
+      "bytes": 31234,
+      "sha256": "8a17e5b4cff1d4a7d51a8ee5d4cc6b5e4da9c91f3a501cbe91bc3409d3f7b0b9",
+      "tables": 6,
+      "gridSpan": 8,
+      "vMerge": 13,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F07 设计转移评审记录.docx",
+      "format": "docx",
+      "bytes": 28214,
+      "sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F09+试产总结报告+03-20250730.docx",
+      "format": "docx",
+      "bytes": 31901,
+      "sha256": "7600083fa8675a95f2365267801cb3d712bcb0d0534b49371bf12c2abda9a66b",
+      "tables": 4,
+      "gridSpan": 23,
+      "vMerge": 30,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/header1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/6. 设计确认阶段/53. 使用错误评估报告-模板zlx.doc",
+      "format": "doc",
+      "bytes": 136224,
+      "sha256": "75cafe0c4c26edb2d9430f3c9839c5217106acdb5f205f12dcf3d728a67f5ed8",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/6. 设计确认阶段/731QCP29-F07 设计确认评审记录.docx",
+      "format": "docx",
+      "bytes": 28214,
+      "sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
+      "tables": 5,
+      "gridSpan": 35,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/6. 设计确认阶段/731QCP29-F11 设计开发确认记录 02.docx",
+      "format": "docx",
+      "bytes": 23026,
+      "sha256": "d01ff3c568416c81d7729fe35c4fe0820513dcbf74e2e33c3a6bf7db1453d609",
+      "tables": 1,
+      "gridSpan": 9,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/header1.xml",
+        "word/footer1.xml"
+      ],
+      "linked_images": []
+    },
+    {
+      "source": ".templates/DHF 文件模板/6. 设计确认阶段/756QCP20-F01 计算机软件确认报告 02.doc",
+      "format": "doc",
+      "bytes": 114176,
+      "sha256": "45e57b363abf14a19e6ef26af23f33b42095e68c1516f1af13f7b73f1f21050d",
+      "header_hex": "d0cf11e0a1b11ae1"
+    },
+    {
+      "source": ".templates/DHF 文件模板/6. 设计确认阶段/756QCP26-F01 验证确认方案 V03-.docx",
+      "format": "docx",
+      "bytes": 44029,
+      "sha256": "525b2c40d74e09318188216b1cbc3d62ca410cdb55008fa7996ed9bdbc36e3f0",
+      "tables": 14,
+      "gridSpan": 33,
+      "vMerge": 0,
+      "headers_footers": [
+        "word/footer1.xml",
+        "word/footer2.xml",
+        "word/header1.xml",
+        "word/header2.xml"
+      ],
+      "linked_images": []
+    }
+  ],
+  "rdm_source_sha256": {
+    "internal/rdmapp/templates.go": "3defc58f0e20dc15d8cee9d846da0d998ca3caf659af2cca2603b6d8f1741419",
+    "internal/rdmapp/templates_gen.go": "8d4a68a31b69ab1834e66acc583211614d8177d23e1844bd4aa61c98ff57547c",
+    "internal/rdmapp/templates_embed.go": "26c940d94639b283fec2add2f2312931321d0bc0cd5e6ebb95c3c3b1c4f188c1",
+    "internal/rdmapp/compose.go": "b2da219785cbf44ee53d1408e56628f44619c8dd93fb4415f2daa9013b591349",
+    "internal/rdmapp/structure.go": "116a25bf5e76f940f54ba67b87b855c5953b944a4ca4f088953766a35563fa86",
+    "internal/rdmapp/parse.go": "9db5e576496b60f54b6be1c6601df14b776075edefd1f712bc78d22d86bb4dc3",
+    "internal/rdmapp/draftproposal.go": "85c638e9ac5b8c9c81974af6eb33b8e86053d3997ab718169a64cd987d1376a6",
+    "internal/rdmapp/docsubmission.go": "e8070350ad794b46d226cba3acb9ff78bfed58113f766cf845d194bb6f3d686f",
+    "internal/rdmapp/docx.go": "7ed609f658cc31ad216464fcea5dbdaa4e25cb56b3de205bc464e9848964db3d",
+    "internal/rdmapp/export_artifact.go": "07a1a4fe537674e1413e38425a36af3c02e29c9e041f6478f96c45769328b2ce",
+    "internal/rdmapp/doc_export_visibility.go": "e4fd051ffb643ae3f002b797ee4175b8b3b2a698012c411021492cab372e7580",
+    "plugins/rdm/plugin.go": "25382894886fef7e9015d254fc416766d9cd7ce355671c088d2c34b0870a2eb8",
+    "scripts/build-product.sh": "70041237df111f064257a8ba95e463de1db6c734d71a77f0f20efa3fa812de97",
+    "scripts/pack-release.sh": "ebeb2b6728fb964aa9983c07e022b52e11be7d2efb76c5bbb6941ce13547d360"
+  },
+  "business_test": "NOT_RUN",
+  "doc_conversion": "NOT_RUN"
+}

docs/records/2026-10-14-manual-phase2-source-audit.json

@@ -0,0 +1,210 @@
+{
+  "source": "SELF",
+  "observed_at_utc": "2026-10-14T14:13:54.776253+00:00",
+  "repo": "weichen/Agent-System-Dev",
+  "main_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
+  "queue_issue": 518,
+  "issue_content_version": 34,
+  "issue_updated_at": "2026-10-14T13:41:21Z",
+  "active_window": "- 当前窗口：无（mq-dev-20261014-537-01 因独立 Stage 8 Review 的三项 Important 整改与安全设计重审，于 2026-10-14T06:06:23.872984+00:00 主动释放）。旧固定 head=6a2f7cd3e610a263b6348efe9084e386dc88f30c / base=4f84c2e1630cd0311643529fae1c3a99f1dd5d64 的 GATE run3076/3077、阶段7人工批准均只对应旧对象；PR #537 已按用户撤销指示关闭，迁移专用远端与本地分支已删除；该任务不再排队。旧 GATE 和阶段结论仅为历史记录。",
+  "branch_protection": {
+    "enable_push": false,
+    "enable_force_push": false,
+    "block_on_outdated_branch": true,
+    "enable_status_check": true,
+    "status_check_contexts": [
+      "ci / test (pull_request)",
+      "ci / test-pg (pull_request)",
+      "ci / svc-realcombo (pull_request)"
+    ],
+    "required_approvals": 0,
+    "block_admin_merge_override": true
+  },
+  "post_trial_prs": [
+    {
+      "number": 539,
+      "merged": true,
+      "merge_sha": "d40579ed7fe3bbca68d3c6fcd1bce6707688d59e",
+      "merged_at": "2026-10-14T06:40:54Z",
+      "head_sha": "3b0e100fba149dbb29066c2ca3d2a74bbe1d4443",
+      "issue_body_ref": false,
+      "issue_comment_refs": [
+        {
+          "id": 6017,
+          "created_at": "2026-10-14T06:42:12Z",
+          "head": "<!-- facts-539-merge-record-20261014T0700Z -->"
+        }
+      ]
+    },
+    {
+      "number": 540,
+      "merged": true,
+      "merge_sha": "11aa76a3bc1c5047791f9a2de154e451634b6567",
+      "merged_at": "2026-10-14T08:08:07Z",
+      "head_sha": "889f64f88167a5314ebfa42a41f9c7a57f91b404",
+      "issue_body_ref": false,
+      "issue_comment_refs": [
+        {
+          "id": 6025,
+          "created_at": "2026-10-14T07:02:56Z",
+          "head": "<!-- dhf-u1-stage7-wip-20261014-01a137f8 -->"
+        },
+        {
+          "id": 6059,
+          "created_at": "2026-10-14T08:04:24Z",
+          "head": "<!-- mq-dev-20261014-dhf-u1-01-claim -->"
+        },
+        {
+          "id": 6066,
+          "created_at": "2026-10-14T08:09:12Z",
+          "head": "<!-- mq-dev-20261014-dhf-u1-01-release -->"
+        },
+        {
+          "id": 6097,
+          "created_at": "2026-10-14T08:32:38Z",
+          "head": "<!-- mq-dev-20261014-dhf-cardclose-01-claim -->"
+        }
+      ]
+    },
+    {
+      "number": 541,
+      "merged": true,
+      "merge_sha": "d23fb4363dcc0a206e71e47f9cd23a644c7e1c70",
+      "merged_at": "2026-10-14T07:33:18Z",
+      "head_sha": "221afaeb169b826ecd38567296319c20c0e94b18",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 542,
+      "merged": true,
+      "merge_sha": "7e9ebdea5055a63c713ccc0fb1f938ffe35a6b9d",
+      "merged_at": "2026-10-14T08:46:12Z",
+      "head_sha": "60d48e0580a36b2e6f93c77bb1edbe9bd0be342e",
+      "issue_body_ref": false,
+      "issue_comment_refs": [
+        {
+          "id": 6097,
+          "created_at": "2026-10-14T08:32:38Z",
+          "head": "<!-- mq-dev-20261014-dhf-cardclose-01-claim -->"
+        },
+        {
+          "id": 6106,
+          "created_at": "2026-10-14T08:35:39Z",
+          "head": "<!-- mq-dev-20261014-dhf-cardclose-02-replacement -->"
+        },
+        {
+          "id": 6117,
+          "created_at": "2026-10-14T08:47:12Z",
+          "head": "<!-- mq-dev-20261014-dhf-cardclose-02-release -->"
+        }
+      ]
+    },
+    {
+      "number": 543,
+      "merged": true,
+      "merge_sha": "da93edf23408ca871ae489ac2123e10734c24413",
+      "merged_at": "2026-10-14T09:24:42Z",
+      "head_sha": "deac1025f1810d7a535c44a16dd6368eb652c979",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 544,
+      "merged": true,
+      "merge_sha": "2dbe11c5d970e7d6a71d0ce1a00eb399bfbbd427",
+      "merged_at": "2026-10-14T09:00:43Z",
+      "head_sha": "b926c701f261995b6e1acabf277bbfdfa47829ca",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 545,
+      "merged": true,
+      "merge_sha": "c8eead49c5e68b2e295927c0e82cc57bcb04bad5",
+      "merged_at": "2026-10-14T09:10:29Z",
+      "head_sha": "00b35c5e6f5e0a0bc8072ff5c8c56378e6641d85",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 546,
+      "merged": true,
+      "merge_sha": "3538d40f45ad5a7c779426eb3322f79751db380c",
+      "merged_at": "2026-10-14T09:40:57Z",
+      "head_sha": "4a15fa0ceadf716fb93cc2966f099f3915b5f9d9",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 547,
+      "merged": true,
+      "merge_sha": "bcf225d0b981dcd69f8c736010c69b6a92d04341",
+      "merged_at": "2026-10-14T09:53:34Z",
+      "head_sha": "8522502e6e6db7a438a8f6fd391e1aa334c7a161",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    },
+    {
+      "number": 548,
+      "merged": true,
+      "merge_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
+      "merged_at": "2026-10-14T10:05:47Z",
+      "head_sha": "b89dd1c20ef4aa5c93a144f00e722a81dee87a50",
+      "issue_body_ref": false,
+      "issue_comment_refs": []
+    }
+  ],
+  "open_prs": [
+    {
+      "number": 512,
+      "draft": true,
+      "mergeable": false,
+      "head_sha": "89125b8dda5f8f988a8a760ed64bf00827e1de5c",
+      "base_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
+      "title": "[WIP] Deliver progressive U2/U3 work with reliable sourced checkpoints"
+    },
+    {
+      "number": 482,
+      "draft": false,
+      "mergeable": false,
+      "head_sha": "d5e8d6ab7a368f08b29e968b6f65f8898f2b28f5",
+      "base_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
+      "title": "Pin the SQLite activity guard and document its refusals"
+    }
+  ],
+  "selected_runs": [
+    {
+      "run": 3088,
+      "head_sha": "6463ef430640c56940b82776adb504ee272f030c",
+      "status": "completed",
+      "conclusion": "success",
+      "started_at": "2026-10-14T07:02:04Z",
+      "completed_at": "2026-10-14T07:09:41Z"
+    },
+    {
+      "run": 3092,
+      "head_sha": "889f64f88167a5314ebfa42a41f9c7a57f91b404",
+      "status": "completed",
+      "conclusion": "success",
+      "started_at": "2026-10-14T07:49:37Z",
+      "completed_at": "2026-10-14T07:58:00Z"
+    },
+    {
+      "run": 3100,
+      "head_sha": "7dd8d0f52ed930fbcabc05f5c4b1fb2b41b10bc5",
+      "status": "completed",
+      "conclusion": "success",
+      "started_at": "2026-10-14T08:28:25Z",
+      "completed_at": "2026-10-14T08:43:31Z"
+    },
+    {
+      "run": 3107,
+      "head_sha": "60d48e0580a36b2e6f93c77bb1edbe9bd0be342e",
+      "status": "completed",
+      "conclusion": "success",
+      "started_at": "2026-10-14T08:33:36Z",
+      "completed_at": "2026-10-14T08:45:31Z"
+    }
+  ]
+}

docs/records/2026-10-14-merge-queue-trial.md

@@ -0,0 +1,51 @@
+# 合入调度首轮受控试行（2026-10-14）
+
+状态：三个真实任务已由智能体依次合入；本报告记录 **manual** 模式的实际观察。是否扩大试行、调整预算或建设自动领取，仍待用户评审。依据为[已批准的实施计划](../proposals/2026-10-13-merge-queue-implementation-plan.md) U5–U6、[Dev 项目规则](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/src/branch/main/policy/merge-queue.md)和[唯一调度记录 #518](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/issues/518)。本报告不代表发布、部署或运行服务验收。
+
+## 范围与证据口径
+
+用户授权由当前智能体接管已有的 Dev #489、#488、#486，确认三者没有其他活动写者；所有实际 PR 合入由智能体执行。Dev `refs/heads/main` 的仓库 ID=29，协调者和窗口在 #518 登记。原任务 R0 各自不同，未伪称共同启动 SHA。组件先按自身目标交付，再固定 Dev 父仓组合；等待的 Dev 源分支没有随前一个正常合入反复同步、推最终候选或跑最终 CI。
+
+证据分层：本机 `make evidence`、API 读取及隔离夹具输出是 **SELF**；`/root/merge_queue_review` 或 `/root/docs_delivery_review` 对固定对象的独立重放另记 **REPLAY**；Gitea Actions 的实际运行链接、作业身份和精确 SHA 才作为 **GATE**。原始 SELF 收据保存在各任务卡、#518 所指 `/tmp/mq-*` 路径及本轮私人状态目录；本文件只列对象、结论和索引，不转写命令输出。未执行的负例继续标 `NOT_RUN`。
+
+平台前置使用用户亲手设置的私有夹具仓库 repoID38 `main` 保护规则。用户修正字段后，Root 只读回读六字段；隔离实测缺检查、失败检查、陈旧绿色候选、匿名请求及已认证绿色候选直推拒绝，合法固定候选由智能体合入。原始 SELF 收据和独立 REPLAY 索引在 #518。该夹具证明所测入口的拒绝/合法路径，不证明 Dev 所有角色、全部写者的机器隔离或旧执行者 fencing。Dev 三项业务检查仍须逐候选运行。
+
+## 三个真实条目
+
+| 顺序 | 原任务 R0 | 先行组件 | Dev 最终 base → head | 独立 Review 与当前 HEAD GATE | 实际合入 main |
+|---|---|---|---|---|---|
+| [#489](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/489) | `cd61bbb112eea6a210a64e84f2cef00b0d64bfc1` | [Documents #89](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/89) → `7bd4e17827d4c7c88647bf3c9199c495b60cb107` | `add097d06137c4912a4ed9279e98ca353e4e4cf1` → `5e6bf4aa0546d68fb3f872158f22b2791c301a60` | `/root/docs_delivery_review` PASS；[run 3038](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3038) 三作业成功 | `f00165e8d71e4dc8ba0ceb7dc50c1a8a3deb6d60` |
+| [#488](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/488) | `99048dda1f48bccb3d5d798050d7beeea2907177` | [Frontend #73](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Frontend/pulls/73) → `5313cfad4e633d0909ed40dcdfa28a11bc1902c0`；[RDM #301](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/301) → `ef5100a020abdd8ba8712c3d15c04c28bcac6e84` | `f00165e8d71e4dc8ba0ceb7dc50c1a8a3deb6d60` → `a70de2c54a74e175ad12c8d52ac29d0bafce9491` | `/root/merge_queue_review` PASS、隔离浏览器 7/7；[run 3050](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3050) 三作业成功 | `d852c159b6b3387a2f418a42ab6d3696ac873d01` |
+| [#486](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/486) | `4d362537d0e8755a03b1757b5bad92779a064b33` | [Backend #185](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/185) → `8e80e2618eb7471dd12d5f172ff3cd23622b7d2f` | `d852c159b6b3387a2f418a42ab6d3696ac873d01` → `d805cc1697ae7f49d371a56a6a55191f00897b8c` | `/root/merge_queue_review` PASS；[run 3067](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3067) 三作业成功 | `05b997b84db26c517604c48d12676f0eb2b86e18` |
+
+三个 Dev 合入都用固定 `head_commit_id`、`force_merge=false`，合入后从远端重新读取 PR/main 并核对完整 tree 与已审候选一致；组件 gitlink 没有回退。#489 首个合入响应后的本地指针统计出错，Root 先从 PR/main 重新对账再释放窗口，未重发合入请求。#488 的独立浏览器验收使用临时二进制/私有环境，未操作 live 服务。#486 的 U7 安全审阅先发现 B1–B7，Backend 在推最终源 HEAD 前修复并以隔离 PostgreSQL 真实交叠、跨进程、SIGTERM/SIGKILL 重放；Dev 最终组合继续通过本地 `make test`、隔离 PostgreSQL/Redis `make test-backend-pg` 和 `make build` 的 SELF 检查，GATE 另见表内 run 3067。
+
+## 同步、CI、等待与恢复
+
+每条 Dev 任务对其本轮最新目标仅发生一次真实纳入；固定后同基线 `task-sync` 核验不生成提交。#489 为纠正旧启动状态，在正式窗口前完成源码/组件整改与目标纳入；这与理想的“领取窗口后才第一次纳入”不同，不能抹去。#488、#486 都在领取最终窗口后才执行 `changed=1`，随后成功的固定 HEAD 检查为 `changed=0`。#486 一次无变更检查被嵌套 Git 的短暂 `index.lock` 拒绝，未删锁；持锁操作结束后原对象复核通过。原始失败和成功收据都在 #518。
+
+| Dev PR | 目标纳入次数 | 固定后成功的无变更核验 | 本轮最终 PR CI | 作业运行时长（test / test-pg / svc-realcombo） | runner 等待 |
+|---|---:|---:|---|---|---|
+| #489 | 1（启动整改期） | 至少 3 次，均未改 HEAD | [3038](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3038)：1 次、3/3 成功 | 5:10 / 7:22 / 1:46 | 每作业 3 秒 |
+| #488 | 1（最终窗口） | 2 次，均未改 HEAD | [3050](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3050)：1 次、3/3 成功 | 5:12 / 8:42 / 1:54 | 每作业 3 秒 |
+| #486 | 1（最终窗口） | 1 次成功；另 1 次锁拒绝未推进 | [3067](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3067)：1 次、3/3 成功 | 5:01 / 7:19 / 1:54 | 每作业 3 秒 |
+
+三次最终 PR CI 共 3 个 run、9 个必需作业，**因本轮正常排队任务移动 main 而废弃的最终 run 为 0**；没有拿旧绿色检查放行新 HEAD。合入后 main push CI 单列：[run 3040](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3040) 对 #489 合入树、[run 3053](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3053) 对 #488 合入树、[run 3068](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3068) 对 #486 合入树，各自另有 3/3 作业成功；共 3 个 push run、9 个作业，不能省略这部分实际 CI 成本。3068 在 04:43:55Z 完成，精确对象为 `05b997b84db26c517604c48d12676f0eb2b86e18`。组件仓的 GATE/N/A 与 RDM #301 任务卡闭合 [PR #364](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/364) 的 CI 不计入上述 Dev 目标 run。
+
+自 2026-10-12 起查询到三个 PR 另有 13 次**试行前开发** Actions run（#489 2、#488 7、#486 4；6 成功、7 失败），其对象与本轮最终候选不同；原始只读清单 `/tmp/mq-trial-ci-history-20261014.json`。这些运行既不能当本轮最终准入，也不能归因于本轮 main 移动。runner 作业等待时间以各 GATE job 的 `created_at`→`started_at` 计算；人的准备/依赖等待没有统一的入队就绪时间戳，本轮不填造净等待时长。仅可复核首次最终同步到合入的可观测下界：#489 19:49、#488 24:20、#486 18:46；它们含测试、Review 和平台等待，不等同完整窗口耗时。三条目均未重新领取最终目标窗口；启动整改、#488 的 E2E 夹具失败、#486 的一次锁拒绝分别保留，不计成 CI 废弃或窗口接管成功。
+
+## 验收与下一步边界
+
+| 验收 | 本轮结论 | 依据及限制 |
+|---|---|---|
+| MQ1 | 部分满足 | 三任务顺序合入且后继未提前最终同步；最终 CI 0 次因正常排队合入废弃。#489 的目标纳入发生在启动整改期，严格“领取后首同步”未由该例满足。 |
+| MQ2 | manual 已登记；原子互斥 `NOT_RUN` | 单协调者与目标窗口记录有效；重复领取的执行端拒绝及旧代次 fencing 未实现/未测。 |
+| MQ3 | 本轮通过 | 三个固定对象有同基线无变更核验；#486 短暂锁失败被拒绝且重验不改 HEAD。 |
+| MQ4 | 本轮通过 | 三个最终 HEAD 各跑实际新 CI；隔离夹具的陈旧绿色候选被拒。没有把组件/旧分支检查当父仓 GATE。 |
+| MQ5 | 部分满足 | #486 活动锁阻断并自行恢复，#489/#488 源码和夹具问题在固定前整改；人工超时释放及无依赖任务并行负例 `NOT_RUN`。 |
+| MQ6 | 部分满足 | 组件先合入，后继父仓保留其他能力；紧急插队导致候选失效的真实路径 `NOT_RUN`。 |
+| MQ7 | 部分满足 | #489 合入后本地异常先对账，未重复 POST；未知请求结果与旧执行者失联接管 `NOT_RUN`。 |
+| MQ8 | manual 范围通过 | 私有夹具正负例、Dev 精确 GATE 和合法智能体合入均有对象证据；全部角色/自动 fencing `NOT_RUN`。 |
+| MQ9 | 待文档 PR Review | 权威规范、Dev 采纳、调度记录、实际 PR/运行互相链接；本报告的最终交叉检查需随文档 PR 完成。 |
+
+建议维持单协调者的 **manual** 模式，按目标串行领取，把组件准备与父仓最终 CI 分开。首次试行证明“等待分支不因正常合入反复重跑最终 CI”在这三项中成立；没有可比历史基线，**不报告节省百分比**。自动模式须另行建设并验证原子持久领取、执行端旧代次拒绝、角色覆盖和异常接管，不能从本轮人工遵约推导已具备。扩大试行与预算调整留待用户阶段评审决定；本报告不替代该决定。