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>

README.md

@@ -21,3 +21,5 @@ docs/
 [实施记录](docs/records/2026-09-29-implementation.md) · [设计方案](docs/proposals/2026-09-29-system-skeleton-design-and-plan.md)
 
 规范基线：Development-Guidelines（Dev 仓 `deps/development-guidelines`）。
+
+相关方案：[RDM 功能、实现与计划矩阵及整改方案 r1（2026-10-12）](docs/proposals/2026-10-12-rdm-function-implementation-plan.md)——RDM 全系统缺口矩阵与 U1–U9 工作包。

docs/proposals/2026-10-11-collaboration-storage-and-distribution.md

@@ -8,10 +8,10 @@ product_contract_source: ce-plan-bootstrap
 
 # 多人协作存储与分布式演进方案 - Plan
 
-修订：r1；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：方案获批发布，实施自首选增量 U1+U2 启动；业务实施/迁移/压测/部署仍为 NOT_RUN，逐项以实施任务卡为准。
+修订：r2.3；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：U1–U7 **代码与测试已合入**（Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164)；Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442)；闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等）。正确性 A1–A7 与 B1 已绿（CI/SELF）。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**（见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)）。2026-10-12 用户决定不做容量重放；同日 B6 pgbench、C4 断连、C5 库恢复已有本机 SELF（见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)）。2026-10-13 未配置对象存储时的上传 panic 已修，C5 工件恢复 K4 重测为 SELF 通过。**SELF≠GATE/REPLAY**，双主机 C3 未做——**仍不放行第二实例承接写请求**。
 需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
-需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-11（Asia/Shanghai）。
-关联任务：Dev `.task/feature-collaboration-storage-plan.md`（方案任务，已发布）；后续 U1+U2 实施由独立任务承接。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-13（Asia/Shanghai）。
+关联任务：方案与 U1–U7 实施卡已归档；容量收尾见 Dev `.task/feature-u7-capacity-wrap-measure.md`。放行检查单：Dev `docs/release-multi-instance.md`。
 正文中的源码路径以 Agent-System-Dev 为根；工作包中的 `internal/` 简写指 `modules/backend/internal/`；文内相对链接以本文为根。
 
 ## 1. 推荐结论与边界
@@ -246,8 +246,8 @@ SQLite 本身支持可靠事务与多人经同一应用访问；WAL 提升读写
 
 必需观测：API P95/P99与预期/非预期错误，DB pool wait/连接数/慢查询/锁等待，队列长度/最老年龄，run 租约/过期写拒绝/未知副作用，SSE cursor lag/补查次数，Redis 错误与降级，检索耗时/召回抽样，备份时间与恢复结果。日志只记录 request/run/owner 的安全标识，不记录 DSN、密钥或文档正文。
 
-当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认；容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
+r1 为方案与 SELF 调查记录。r2 起：U1–U7 代码与测试已合入且正确性 CI 绿。r2.1：本机双实例 contract 容量窗口（ladder / 60m / 2h）SELF 全过，见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。r2.2：用户于 2026-10-12 明确不做容量重放；同日完成 B6 pgbench、C4 PG/Redis 断连、C5 物理备份与 pg_dump 恢复的本机 SELF，见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)。C4 通过。C5 的库恢复通过（RPO 64 秒，RTO 4 秒），工件上传在未配置对象存储时 panic，K4 失败，产品代码未改。r2.3：2026-10-13 在 store 边界把带类型的空对象存储当作未配置并回落本地目录；同日 C5 重测 K1–K7 均为 SELF 通过（RPO 65 秒，RTO 3 秒，K4 五个工件 sha256 一致且跨用户拒绝）。本地 SELF 不能冒充 GATE/REPLAY 放行；双主机仍缺。部署与第二实例写流量仍未授权。
 
-方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
+方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
 
-首选下一增量是 **U1 + U2 的详细实施与测试合同**：固定目标实例与 PG 测试环境，解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行；不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。
+首选下一增量不要自动开工。剩余放行门槛是：独立 REPLAY，或把 C4/C5 快速档接入 CI 形成 GATE（需平台准入）；以及 C3 双主机（需第二台机器）。2026-10-13 的上传修复与 K4 SELF 重测不替代这两项。GATE/REPLAY 与 C3 未齐前，不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。

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-fast-slow-channel-display-u1-plan.md

@@ -0,0 +1,252 @@
+---
+title: 快慢通道展示 U1 实施计划
+date: 2026-10-12
+revision: r1
+status: approved
+owner: weichen
+execution: implementation
+parent: 2026-10-12-fast-slow-channel-display.md@r1.1
+---
+
+# 快慢通道展示 U1 实施计划 r1
+
+> **For agentic workers:** 按本计划逐工作项实施；每项先写失败测试再改实现。规格依据主方案 [r1.1](2026-10-12-fast-slow-channel-display.md)。阶段 5 已于 2026-10-12 经用户「开始」批准；批准不等于推送/合入授权。
+
+**Goal:** 统一后台任务真实状态语义，用 L1 精炼骨架替换「原始指令占主视图」，使失败不再显示为完成，并为后续 U2 快照契约留下兼容字段草图。
+
+**Architecture:** 服务端在建卡/终态时写入精炼 Body 与正确 `CardStatus`；UI 按状态灯/状态词渲染；旧 `done+danger` 客户端兼容映射为失败。不引入持久 `TaskSnapshot`、不按任务路由 `agent.progress`、不发布阶段 findings（属 U2/U3）。
+
+**Tech Stack:** Go（Core/Backend）、React+TypeScript（UI/Frontend）、既有 ActivityCard / UINode / cardsvc 事件流。
+
+**Spec:** [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md) §4 R03-a、§7.1、§10.1、§14 U1 出口白名单。
+
+## Global Constraints
+
+- 首批仅 U1；禁止顺手实现 U2/U3 范围（材料内容 hash、持久快照、检查点摘要、HITL 双入口完备）。
+- 颜色/圆角/字号只消费 `@ui/tokens.css`；动效只用 `mk-*`；折叠用 Collapsible。
+- 证据经 `CMD=… make evidence` 写入任务卡；声明通过须标 SELF/GATE。
+- 跨仓顺序：Core（若有契约）→ Backend → UI → Frontend → Dev gitlink 组合 `make test`。
+- 现有「停止」按钮语义不在本增量改名为「仅停前台」；不暴露暂停/独立取消/续跑。
+
+## Review Focus
+
+1. 失败卡若仍为 `done`，用户会当成成功收纳——须 `CardFailed` 或等价失败灯。
+2. 建卡若仍塞入 task 原文，用户会把指令当进度——须 L1 骨架。
+3. 材料去重若仍只认 `CardDone`，改为 `CardFailed` 后可能卡死重试门禁——须同步测试。
+4. 快通道在登记前说「已启动」——须与真实登记/开跑事件对齐。
+5. `CurrentTaskCard`（plan/todos）与后台 progress 卡同目标叠卡——U1 须定义合并或降噪规则，避免双标题。
+
+---
+
+## 0. 范围与非目标
+
+### 纳入（映射需求）
+
+| 需求 | U1 验收子集 |
+|---|---|
+| R01 | 简单问答无空进度卡；复杂任务短答可含已确认范围与后台真实状态 |
+| R02 | 已登记任务有稳定卡对象；未登记不显示「已启动」 |
+| R03-a | L1 骨架 + 诚实无发现占位；不验收运行中真实发现 |
+| R08 | 失败 ≠ 成功灯；状态词「执行失败」 |
+| R10 | 完成卡骨架（结论/要点/缺项/入口）；完备来源与版本定位可留 U3 |
+| R13 | 守护测试通过；状态不只靠颜色（沿用 StatusLamp 形状） |
+
+### 排除
+
+见主方案 §14「明确排除」。另：不改 `CancelRun` 父句柄行为；不改 Surface 抢占策略（属 U2/U4）。
+
+### 与 CurrentTaskCard 的合并规则（U1）
+
+- 后台 `CardKindProgress` 卡是慢通道权威对象。
+- 若同一会话同时存在前台 `plan`/`todos` 的 `CurrentTaskCard` 与后台 progress 卡：**右栏「工作」优先列出 progress 卡**；`CurrentTaskCard` 仅在无后台 progress 卡且 plan/todos 非空时展示。
+- 不在 U1 把 plan steps 写入后台卡 Body。
+
+---
+
+## 1. 工作项与文件
+
+### W1 — Core：精炼摘要契约草图与旧卡映射说明
+
+**Files:**
+- Modify: `modules/core/activity.go`（若增加可选字段）或新增 `modules/core/task_summary.go`
+- Test: `modules/core/activity_test.go` 或同目录新测
+
+**内容（最小）：**
+
+```go
+// TaskSummaryView 是 U1 写入 ActivityCard.Body 的权威语义草图；
+// 完整 TaskSnapshot（findings/revision/streamScope）留待 U2。
+type TaskSummaryView struct {
+	Title       string // 业务动宾短标题
+	Focus       string // 正在做什么，≤2 行
+	FindingsNote string // U1：无成果时固定诚实文案；有结构化 findings 属 U3
+	Remaining   string
+	NextStep    string
+	OutcomeLine string // 完成后的结论一行；运行中可空
+}
+```
+
+可选：在 `ActivityCard` 增加 `Summary *TaskSummaryView \`json:"summary,omitempty"\``；**Body 仍为旧客户端回退投影**，新客户端优先读 Summary。若为降低跨仓面，U1 可仅约定 Body 的 Markdown/KV 形状而不加字段——但须在 Core 注释或本计划冻结 Body 键名：
+
+| KV 键 | 含义 |
+|---|---|
+| 状态 | 排队中 / 进行中 / 已完成 / 执行失败 |
+| 正在做 | Focus |
+| 当前发现 | FindingsNote（U1 占位或完成后要点摘要） |
+| 剩余 | Remaining |
+| 下一步 | NextStep |
+
+- [ ] 冻结 Body 键名或 `Summary` 字段二选一，写入 Core 并单测序列化往返
+- [ ] 文档注释标明 findings[] 属 U2/U3
+- [ ] Commit：`docs(core): freeze U1 task summary body contract`
+
+### W2 — Backend：建卡/终态状态与精炼 Body
+
+**Files:**
+- Modify: `modules/backend/internal/runmgr/runmgr.go`（`createBackgroundCard` ~1942、`promoteQueuedCard` ~1970、`finishBackgroundCard` ~1992）
+- Modify: `modules/backend/internal/runmgr/material_test.go`（及同类依赖 `CardDone+danger` 的测试）
+- Test: 新增 `modules/backend/internal/runmgr/background_card_test.go`
+
+**当前问题（源码）：**
+
+```go
+// create：Body 首节点 = truncate(task, 400)
+// finish：SetStatus(..., CardDone, tone) 且失败 tone=danger、状态行仍写「已完成」
+```
+
+**目标行为：**
+
+```go
+func backgroundRunningBody(focus string, kv [][2]string, statusLabel string) []core.UINode {
+	return []core.UINode{
+		{Type: core.UIMarkdown, Markdown: "尚无阶段结论，正在读取材料"},
+		{Type: core.UIKV, KV: append(append([][2]string(nil), kv...),
+			[2]string{"状态", statusLabel},
+			[2]string{"正在做", focus},
+			[2]string{"当前发现", "尚无阶段结论"},
+			[2]string{"剩余", "待任务进展后更新"},
+			[2]string{"下一步", "继续处理已登记工作"},
+		)},
+	}
+}
+
+// finish 成功：CardDone + tone ok；状态「已完成」；Markdown = 结论骨架
+// finish 失败：CardFailed + tone danger；状态「执行失败」；保留已有可读摘要
+```
+
+- [ ] 失败测试：`finishBackgroundCard` 在 `err != nil` 时 `Status==CardFailed` 且 Body 状态键 ≠「已完成」
+- [ ] 失败测试：`createBackgroundCard` Body Markdown 不含原始 task 长指令（可用固定长 task 断言不出现）
+- [ ] 实现最小改动；`promoteQueuedCard` 只更新状态键为「进行中…」
+- [ ] 更新 `material_test`：成功路径仍等 `CardDone`；失败/重试路径认 `CardFailed` 或释放 `materialActive`
+- [ ] 快通道诚实：spawn/登记路径日志与用户可见文案——仅在 `Create` 成功后可称「已登记」；仅在子 run 启动后可称「进行中」（检查 `spawnBackground*` / material 入口提示，必要时改 system 提示片段；**不做**阶段发现生成）
+- [ ] Commit：`fix(backend): map background card fail to CardFailed and use L1 body`
+
+### W3 — UI：状态灯与旧卡兼容
+
+**Files:**
+- Modify: `modules/ui/src/ActivityCardView.tsx`（`StatusLamp`）
+- Test: 既有 UI 测试或新增 `ActivityCardView` 测例；跑 `design-guard.test.ts`
+
+**目标：**
+
+```tsx
+// done → 完成灯；failed → 失败灯（已有）
+// 兼容：status===done && tone==='danger' → 按失败灯展示，title「执行失败（兼容）」
+```
+
+- [ ] 失败测试：`done+danger` 渲染失败形状灯，不渲染 `lamp-ok`
+- [ ] 实现兼容映射；不新增裸色值
+- [ ] `pnpm test` / 仓内 UI 测试目标通过
+- [ ] Commit：`fix(ui): treat done+danger progress cards as failed`
+
+### W4 — Frontend：工作区排序与空卡
+
+**Files:**
+- Modify: `modules/frontend/src/components/Workbench.tsx`（`CurrentTaskCard` 展示条件）
+- Modify: 若 Inbox 过滤依赖 status，核对 `store.ts` 对 `failed` 的分区（完成区 vs 进行中）
+- Test: 前端既有测试或最小组件测
+
+**目标：**
+
+- 存在 `kind===progress && status===active`（或排队文案）时隐藏与同会话抢注意力的空 `CurrentTaskCard`（按 §0 合并规则）
+- `failed` 卡进入可收纳/结果区逻辑与 `done` 区分（失败可收纳但不显示成功语义）
+- 简单问答路径不因误触发材料整理产生空卡——若属既有路由，仅加回归断言「无附件无后台登记时 progress 卡数为 0」
+
+- [ ] 实现合并规则
+- [ ] 回归：无后台任务时 plan 仍可显示
+- [ ] Commit：`fix(frontend): prefer progress cards over duplicate CurrentTaskCard`
+
+### W5 — Dev 组合与文档收口
+
+**Files:**
+- Modify: Dev gitlink（Core/Backend/UI/Frontend 精确 SHA）
+- Modify: 实施任务卡证据段；主方案进展指针（若本增量合入时）
+- Test: 工作区根 `make test`、`make build`
+
+- [ ] 各组件 PR 顺序合入或同批组合验证
+- [ ] Dev `make test` + `make build`；evidence 写入
+- [ ] 更新主方案「规划进展」：U1 实施状态（仅在真实合入后）
+
+---
+
+## 2. 测试与环境
+
+| 层 | 命令/方法 | 证明什么 |
+|---|---|---|
+| 单元 | Backend `go test ./internal/runmgr/…`；Core 序列化；UI StatusLamp | 状态映射、Body 骨架、兼容灯 |
+| 守护 | UI/Frontend `design-guard.test.ts` | 无新增裸色值/私有 keyframes/行内字号 |
+| 组合 | Dev `make test`、`make build` | gitlink 组合可编译可测 |
+| 手工冒烟（SELF） | 本地起服务：发材料看建卡；制造子任务失败看灯；简单问答无空卡 | U1 白名单场景 |
+| 真实模型阶段成果 | **NOT_RUN / 不在 U1** | — |
+| 浏览器窄屏全矩阵 | **NOT_RUN / 属 U4** | — |
+
+被测对象：各仓 PR HEAD；组合声明须含精确 SHA。
+
+---
+
+## 3. 完成条件
+
+1. U1 出口白名单全部可判定项有 SELF 或 GATE 证据。
+2. R03-a 有测例；无人用「五问完整」拒绝 U1。
+3. 材料整理去重/重试在 `CardFailed` 下仍可再次登记（或文档说明与测例固定行为）。
+4. 无 U2/U3 范围代码混入同一变更集（审 Diff）。
+
+---
+
+## 4. 停止与回退条件
+
+- 失败状态与存储不一致（卡显示失败但去重门禁认为仍在跑，或相反）→ 停止合入，修 W2/材料门禁。
+- 新旧客户端之一崩溃或空白卡 → 回退 Summary 字段改动，保留 Body 回退投影。
+- 发现实现滑入持久快照/检查点摘要 → 拆出变更，不进本 PR。
+- DESIGN 守护失败 → 先改令牌消费再继续。
+
+回退策略：回退受影响展示映射与 Body 生成；不删除已保存 run 结果。
+
+---
+
+## 5. 依赖顺序与责任
+
+```text
+W1 Core 契约（可选字段或 Body 键冻结）
+  → W2 Backend 建卡/终态
+  → W3 UI 灯兼容
+  → W4 Frontend 工作区
+  → W5 Dev gitlink + 组合测试
+```
+
+责任人：实施阶段指定；需求/评审：weichen。
+
+预估：单增量跨 4 仓，以状态映射 + Body 重排为主，不含模型评测费用。
+
+---
+
+## 6. 计划评审状态
+
+| 项 | 状态 |
+|---|---|
+| 关联方案 | r1.1 设计已批准；首批仅 U1 |
+| 本实施计划 | **已批准**（2026-10-12，用户「开始」） |
+| 业务代码 | 实施中：`feature/fast-slow-display-u1` |
+| 推送/PR/合入 | 未授权（完成自检后另请） |
+
+首选动作已执行：`make task-start NAME=feature/fast-slow-display-u1`，按 W1→W5 推进；设计任务卡可在文档 PR 合入后 `task-close`。

docs/proposals/2026-10-12-fast-slow-channel-display.md

@@ -0,0 +1,517 @@
+---
+title: 快慢通道展示与动态工作摘要方案
+date: 2026-10-12
+revision: r1.1
+status: design-approved
+owner: weichen
+execution: design-only
+---
+
+# 快慢通道展示与动态工作摘要方案 r1.1
+
+状态：**方案设计已批准（阶段 4）**。需求依据：用户要求改善快慢通道的内容、排版与直观性，让慢通道执行期间持续呈现精准、精炼且有工作价值的状态、发现、摘要和总结。
+
+批准依据：2026-10-12 用户确认评审结论计划并指示按该计划落地文档修订与 U1 实施计划；批准范围覆盖四层阅读、任务卡骨架、动态回投规则、U1→U2→U3→U4 顺序及**首批仅 U1**。本修订相对 r1 增加 R03 增量切分与 U1 出口白名单。业务代码实施仍须另批阶段 5 实施计划后启动。更新日期：2026-10-12（北京时间）。需求与评审负责人：weichen；实施负责人在实施阶段指定。
+
+## 1. 推荐方向与成功标准
+
+采用**对话推进工作、任务卡持续更新、结果按需展开**的方案。快通道负责即时理解、当前可回答的结论和必要确认；慢通道负责持续处理材料、研究、分析、生成及检查，并把当前工作成果逐步汇总给用户。两者共享任务与事实，不形成两份独立聊天记录。
+
+用户应当可以在一个视野里回答五个问题：
+
+1. 这项工作现在处于什么状态？
+2. 已经完成什么、目前知道什么？
+3. 这些发现对我的任务有什么影响？
+4. 还缺什么、下一步准备做什么？
+5. 是否需要我做决定或补充材料？
+
+默认阅读只需一行状态和一张紧凑任务卡。深入查看时可看到阶段成果、依据和执行记录。正式交付后直接给出结论、关键要点、限制与文件入口。
+
+设计的初始验收目标：代表性用户看到默认视图后，10 秒内可正确回答状态、主要发现、是否需处理三个问题；这个目标是**待验证的可用性指标**，不是当前体验已经达标的声明。
+
+## 2. 当前实现依据及差距
+
+本次依据本地固定源码核对，来源为 SELF。启动基线为 Dev `4bf6e4a0cf8b509320d54de2a6a41c5abb2f5bba`；任务同步后读取的 Dev HEAD 为 `3496d1af37827dc536559ed5bbfe23c381c329cd`，其包含同步基线 `dec25692c247c8923b0f9396c8f674aefec47521`。
+
+组件：Backend `dcc180dcad2489a170edca154e39e335220854f1`、Core `89f3906c390027512ef47b5333088c3d3a019e84`、Frontend `d01a3ebd819da29bf7e7dd06e74c92ef34231774`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`。Documents 写作分支从单独获取的 `origin/main=52bf525ef8750999e5e7dbff0b2decac5b1155f7` 建立，未改变受测业务组件。源码审阅原始记录见 Dev 任务卡 `.task/feature-fast-slow-display-design.md` 的 source-audit 收据。本轮未开展真实模型、浏览器或部署验证；以下“已有”只表示源码中存在相应机制。
+
+| 已有源码机制 | 位置 | 与本需求相关的差距 |
+|---|---|---|
+| 快通道是当前对话回合，慢通道是后台子任务；同会话后台槽位上限 3 | Backend `internal/runmgr/runmgr.go` 的 `spawnBackgroundOpts`、`startBackgroundSlot` | 缺少统一面向用户的任务概览；通道不是用户可切换的速度档位 |
+| 带附件可自动启动材料整理；无文字/大材料可预启动，小材料有结束兜底；支持排队 | Backend `internal/runmgr/material.go` | 已有入口应复用；当前材料键仅由文件名与解析字数生成，同名等长更新可能复用旧结果。启动信息不等于材料已经读完 |
+| 进度卡创建时放入最多约 400 字任务正文和“执行中”状态 | Backend `internal/runmgr/runmgr.go:1942` | 用户主要看到任务说明和指令，不能据此理解实际进度 |
+| 完成时替换卡身；成功/失败统一置 `done`，用 tone 区分 | 同文件 `finishBackgroundCard`；UI `src/ActivityCardView.tsx:23` | 执行期间缺少成果投影；失败卡可能带“完成”灯，业务结果与卡收纳状态混在一起 |
+| `agent.progress` 发布子任务文本前约 80 字及“调用工具”消息 | Backend `internal/runtime/sub_loop.go:208` | 原始文本片段不具备稳定摘要语义，也没有结构化来源和成果完整性 |
+| `agent.progress` 写进单个 `live.agentNotes`；`touchLive` 维护单个 LiveState | Frontend `src/store.ts:514`、`:986` | 需避免后台进展串入当前对话回合；缺少按任务持久维护的独立展示投影 |
+| 会话/项目事件流、卡片更新事件及断线重放契约已有；客户端读取 seq | Core `events.go`；Frontend `src/api.ts:192` | 客户端 `Math.max` 推进游标本身不等于拒绝旧帧；新投影必须显式处理去重、顺序和恢复 |
+| 三栏“上下文 / 对话 / 工作与文件”、HITL、工件预览、Surface 已有 | Frontend `Workbench.tsx`、`Conversation.tsx`、`store.ts`；Core `activity.go` | 需要在现有落位整合，不增加第四栏；Surface 更新当前有自动打开预览行为，后台更新应控制抢占 |
+| 后台完成结果在会话空闲时启动汇报回合 | Backend `deliverNotices` | 结果就绪与汇报已送达需要分开；用户不应因前台忙而误以为任务尚未完成 |
+| 取消子 run 的现有路径还会尝试取消父句柄 | Backend `CancelRun` | 不直接提供承诺独立取消、暂停或重试的按钮 |
+
+由源码推导的主要原因：运行事件、任务卡和最终回复之间缺少一层稳定的**用户工作摘要**。只调整卡片样式不能补齐这些信息。
+
+## 3. 方案选择与边界
+
+| 方案 | 收益 | 代价与限制 | 结论 |
+|---|---|---|---|
+| 直接把慢通道日志流到卡片 | 改动较少、容易看到活动 | 原始指令与工具输出增多；难提炼发现；并发时噪声更大 | 作为执行记录层，不作为默认视图 |
+| 快慢通道各有一份完整对话流 | 两条执行线直观 | 重复回复、重复确认、用户需要拼接上下文；占用阅读空间 | 不采用 |
+| 统一任务摘要 + 同一卡片更新 + 对话关键回投 | 结论可读、状态可见、细节可追溯 | 需要结构化成果与持久投影 | **推荐** |
+
+范围包括信息架构、快通道内容、慢通道摘要、状态语义、更新策略、来源与恢复、UI 组件适配。通用基座提供任务、发现、来源与动作能力；文档审签、业务风险等级等由下游提供适配，不写进基座。
+
+本轮不执行业务代码修改、模型实验、迁移、重启或部署。候选设计中的新契约、持久化和操作能力均为待批准内容。本方案不依赖 Generative UI 插件启用才能工作；结构化任务卡提供基础体验，Surface 可用于适合的成果展示。
+
+## 4. 需求与可判定验收
+
+以下为已批准方案范围内的需求表。P0 是核心闭环，P1 是增强项。首批实施仅覆盖 U1 出口白名单中的子集；“纳入候选”不等于该子集已获实施授权。
+
+| ID | 需求 | 优先级 | 可判定验收条件 | 依赖/处理 |
+|---|---|---|---|---|
+| R01 | 快通道首先给用户可用的即时答复 | P0 | 简单问答无空任务卡；复杂任务短答能说明已确认范围、当前可回答内容及后台工作 | 既有对话；U1 纳入 |
+| R02 | 所有已登记后台任务都有稳定可见对象 | P0 | 排队、运行、结束都定位到同一任务；未登记时不显示“已启动” | 任务登记；U1 纳入 |
+| R03 | 默认卡呈现当前工作、发现与剩余项 | P0 | 见下方 R03 增量切分；完整五问仅在 U3 验收 | R02；按增量切分 |
+| R04 | 阶段成果动态更新且不重复刷屏 | P0 | 有可用阶段成果时及时更新同一卡；选定长任务验收至少两个真实成果检查点；短任务可直接完成，普通更新不新增对话消息 | 事件投影；U2/U3 |
+| R05 | 事实、分析判断和待确认内容可区分 | P0 | 关键发现可定位依据；尚未核实的推断带限定；不得以模型自报覆盖工具实际结果 | 来源契约；U2/U3 |
+| R06 | 并行任务不会互相污染状态或正文 | P0 | 3 个后台任务与前台回合同时活动，各任务标题、发现和终态归属正确 | 按任务路由；U2 |
+| R07 | 等待用户的动作明确且双入口一致 | P0 | 对话/右栏提交任一入口后另一个同步更新；重复点击只执行一次 | 既有 HITL/动作；U3 |
+| R08 | 成功、部分结果、失败、中断明确区分 | P0 | 失败不显示成功灯；部分结果标明缺项；未保存的结果不显示“已交付” | 结果契约；U1 纳入 |
+| R09 | 断线/刷新不丢失成果，也不伪造状态 | P0 | 重连可恢复阶段摘要；重复/乱序事件不回退；连接异常不改写业务终态 | 持久快照；U2 |
+| R10 | 完成回投精炼且可取回产物 | P0 | 显示结论、最多 3 个默认要点、缺项、文件入口；定位真实文件且版本明确 | 工件/通知；U1 骨架，U3 完备 |
+| R11 | 右栏关闭与窄屏时主要能力完整 | P0 | 不打开右栏即可读摘要、看依据、处理确认、打开文件 | 对话内展开；U4 |
+| R12 | 更新尊重正在阅读的内容 | P0 | 不自动切文件、不夺取焦点、不把用户滚回底部；展开与阅读位置保留 | 更新策略；U2/U4 |
+| R13 | 视觉与可访问性符合 DESIGN.md | P0 | 令牌、Collapsible、MotionKit 守护通过；键盘可达；状态不只靠颜色 | UI/Frontend；U1 纳入 |
+| R14 | 摘要成本受控，摘要失败不影响任务 | P0 | 不按 token 调用摘要模型；预算耗尽仍有真实阶段状态与既有发现 | 发布策略；U3 |
+| R15 | 修改任务要求可解释地衔接 | P1 | 新要求明确“尚未生效/已用于后续任务”；不假称已改变在跑任务 | 新任务/输入确认；U4 |
+| R16 | 合适成果可以切换对比、清单或报告 | P1 | 比较任务给差异表；审查给问题清单；插件关闭仍能读取核心摘要 | 可选 Surface；U4 |
+| R17 | 每次尝试与结果采用状态可追溯 | P0 | 新尝试不覆盖旧失败；生成、用户认可、正式发布三者独立显示 | task/attempt/result；U2 |
+| R18 | 跨任务发现有总览且不重复计数 | P1 | 同一来源同一发现合并引用；冲突并列呈现，关联到各自任务 | 稳定发现 ID；U4 |
+
+### R03 增量切分（定稿）
+
+完整 R03「运行卡无需展开即可回答第 1 节五问」不得用单一增量字面验收。切分为：
+
+| 子集 | 归属 | 可判定出口 |
+|---|---|---|
+| R03-a | U1 | 默认卡采用固定 L1 骨架（标题+状态、正在做什么、当前发现区、剩余/下一步）；无阶段成果时诚实显示「尚无阶段结论…」；不把原始任务指令当作进度正文；**不**要求运行中出现真实业务发现 |
+| R03-b | U2 | 活动行与覆盖/剩余可随确定性事件持续更新；刷新/重连后骨架与活动状态仍可读 |
+| R03-c | U3 | 带来源的 1–3 条阶段发现；运行中即可回答五问中的「知道什么 / 影响 / 还缺什么」 |
+
+项目符合度：R01–R18 与对话优先、服务端权威、通用基座定位相符；其中 R02–R09、R14、R17 需要契约及实现调整，R15/R16/R18 的完整能力需进一步设计。运行可行性尚未验证。
+
+## 5. 信息架构与阅读层级
+
+维持三栏。左侧提供项目、会话、材料上下文；中间负责对话、关键进展和决定；右侧“工作”集中当前任务与待处理事项，“文件”负责既有唯一预览入口。
+
+| 层级 | 默认展示 | 用户目的 | 展开方式 |
+|---|---|---|---|
+| L0 一行概览 | 前台状态、后台任务数量、待处理数量 | 一眼判断是否忙、是否需要行动 | 点击对应任务或待处理项 |
+| L1 工作摘要 | 目标、状态、正在做什么、1–3 条重要发现、剩余项、必要动作 | 快速理解并继续工作 | 当前任务卡；对话内同对象锚点 |
+| L2 阶段与依据 | 阶段成果、发现列表、覆盖范围、未决事项、来源 | 检查判断、准备评审 | 在原位置用 Collapsible 展开 |
+| L3 执行记录 | 工具调用、可授权查看的参数/输出、事件、错误详情 | 排障和审计 | “执行记录”，默认折叠、按阶段分组 |
+
+默认先提供 L0/L1；不同时展开所有任务。正在查看文件时，工作更新只改变概览及未读提示。右栏收起时，中栏任务锚点可展开 L1/L2/L3，关键功能不依赖右栏。两处共享同一 taskId 和服务端快照，不分别生成摘要。
+
+右栏顺序：**需要你处理 → 当前正在查看的任务 → 其他进行中/排队 → 新结果 → 已收纳历史**。置顶任务保留位置；普通更新不因时间变化反复重新排序。排序规则只负责注意力，不改变执行优先级。已有“当前任务卡”的计划/待办融入同一概览，避免再叠一张同目标卡。
+
+### 5.1 桌面示意
+
+下列内容均为设计示例，不是真实运行结果。
+
+```text
+上下文                 对话                             工作 | 文件
+项目 / 会话            收到 3 份材料，已登记材料整理任务    需要你处理 0
+材料与历史             我会先核对事实和差异，再给摘要      材料整理 · 进行中
+                       [材料整理 · 已有 2 条阶段发现]      正在核对：需求与会议结论
+                                                        当前发现
+                       你：先重点看验收要求                • 3 项需求缺少验收条件
+                       助手：补充尚未作用于在跑整理         • 上线日期存在两种表述
+                       [以此重点创建后续分析任务]           剩余：核查评审意见
+                                                        下一步：整理待确认事项
+                       …                                [查看依据] [阶段与记录]
+                       后台 1 项 · 无需你处理
+                       [输入消息                          ]
+```
+
+中栏进展锚点只给一条高价值提示，不复制右栏全文。新目标通过新任务或已有受支持的输入动作落实，不默认承诺能动态改写在跑任务。
+
+## 6. 快通道内容规范
+
+### 6.1 不同场景怎样回复
+
+| 场景 | 默认回复 | 后台信息 |
+|---|---|---|
+| 简单问答、短文本修改 | 先给答案，必要时给短依据或结果 | 无实际后台任务则不显示通道卡 |
+| 发送材料、任务尚未登记 | “收到 3 份材料，正在准备整理”及已确认的接收/解析信息 | 不提前声称“已启动” |
+| 材料任务已登记 | “已登记材料整理，完成后给出事实、差异与待确认事项” | 显示排队或运行真实状态 |
+| 有明确分析/生成目标 | 一句话复述目标 + 当前能回答的内容 + 本次处理范围 | 实际启动后显示相应任务 |
+| 用户追问后台知道了什么 | 基于最新快照给 2–3 条已发布发现，标出仍在核查的部分 | 不重复启动同一工作 |
+| 发现阻塞/需要决定 | 直接说问题、对结果的影响及所需输入 | 复用同一个确认对象 |
+| 后台结束 | 结论 → 关键要点 → 限制/缺项 → 产物或下一动作 | 回投当前结果版本 |
+
+“每份材料一句概览”只在已有解析或阶段成果能够支持时给出。快通道尚未读到材料正文时，给文件清单和整理范围即可，不由文件名推断业务结论。
+
+### 6.2 精炼但有用的内容骨架
+
+短答默认 2–5 行；复杂结论默认一段总括、最多 3 个要点和一个主要动作。字数是初始排版预算，不硬截关键风险、金额、日期、否定条件或来源。
+
+示例：
+
+> 已收到需求说明、会议纪要和评审意见，材料整理任务已进入队列。整理会先核对关键事实、冲突与待办。你可以继续补充希望重点关注的问题。
+
+有阶段成果后的示例：
+
+> 目前发现 3 项需求缺少验收条件；两份材料中的上线日期不一致。评审意见仍在核查，完整结论尚未形成。你现在可以先确认上线日期的权威来源。
+
+避免空泛重复“我正在深入分析”“请耐心等待”。工具名、系统提示词、模型自我描述不进入默认业务回复。无需用户决定时，不为了显得主动而硬加问题或三个无依据建议。
+
+## 7. 慢通道任务卡与阶段摘要
+
+### 7.1 运行中固定骨架
+
+1. **标题与状态**：业务动宾短标题，如“核对三份材料”“生成需求说明”；状态词独立显示。
+2. **正在做什么**：一句业务阶段说明，最多两行。如“核对需求条目与评审结论”。
+3. **当前发现**：默认 1–3 条，按对目标的影响排序；每条表达“发现 + 意义”，有来源入口。
+4. **剩余与下一步**：一句说明尚未覆盖部分及接下来处理内容。
+5. **操作与时间**：只有真实可用的主动作；注明最近成果更新时间，耗时为次要信息。
+
+任务刚开始时，“当前发现”显示“尚无阶段结论，正在读取材料”，不制造空白占位成果。无需用户操作的任务明确“无需你处理”，而非放一个不可执行的“继续”按钮。
+
+```text
+核对三份材料                              进行中
+正在核对需求与会议决定
+
+当前发现
+• 3 项需求缺少验收条件，暂无法判定是否可验收  [来源]
+• 上线日期存在两种表述，需要确定权威版本    [来源]
+
+已覆盖：需求说明、会议纪要的目标章节
+剩余：评审意见中的变更记录
+下一步：整理冲突与待确认事项
+最近成果更新 14:32                 [查看阶段与依据]
+```
+
+“已覆盖”必须来自已确认处理的章节、工具返回或有效检查点。解析完成与分析完成分开显示；“读过一份文件”不能自动计为该文件已全部分析。数量与统计只能来自可数、可去重的对象。
+
+### 7.2 有工作价值的阶段成果
+
+每次阶段发布应至少带来一个用户能利用的变化：确认事实、揭示差异、形成可用初稿、发现缺项、完成检查、给出必要决定。普通“调用工具”只更新活动状态和执行记录，不算业务成果。
+
+| 工作类型 | 推荐业务阶段，按实际任务选用 | 默认最有价值的内容 | 最终呈现 |
+|---|---|---|---|
+| 材料整理 | 接收/解析 → 提取事实 → 核对差异 → 汇总 | 核心事实、共同结论、冲突、待办 | 短摘要 + 重要发现 + 来源 |
+| 研究检索 | 明确问题 → 查找来源 → 对照证据 → 形成判断 | 已找到的依据、尚缺的证据、判断如何变化 | 结论 + 对比/依据 |
+| 方案/需求分析 | 提取约束 → 检查覆盖 → 比较取舍 → 整理建议 | 缺项、约束、关键取舍及影响 | 建议 + 清单/对比 |
+| 文档生成 | 确认范围 → 编排结构 → 生成草稿 → 校验保存 | 结构已定、待补材料、草稿状态、检查结果 | 精炼结论 + 正式工件入口 |
+| 审查验证 | 确定对象 → 执行检查 → 归纳问题 → 汇总结果 | 会阻塞交付的问题、证据、未覆盖项 | 问题清单 + 实际检查结果 |
+
+阶段不固定为所有任务必经的四步。检索/检查可能迭代回到前一阶段；通过阶段 ID 与版本记录，不以动画线性前进。没有领域阶段数据时降级为“读取材料 / 使用工具 / 整理结果”等确定性活动描述，不凭计时自动切阶段。
+
+### 7.3 成果不是思维链
+
+发布公开工作摘要、工具确认的事实、可交付的阶段产物和待确认问题，不把隐藏推理、系统提示词、原始任务提示或未完成 token 片段包装成发现。执行记录仅展示真实已有且当前用户有权限查看的记录；“展开”不意味着获得额外权限。
+
+## 8. 精炼、来源与结论修订
+
+### 8.1 发现的表达与排序
+
+发现由一句结论和一句影响组成，通常合为一行：“指标定义不同，两个方案的达成率不能直接比较”。排序优先级为：需要用户决定的事项、会改变当前建议的风险、与用户目标直接相关的事实、其他背景信息。
+
+去重按稳定 findingId 及来源版本处理；同一事实由两个任务发现时，展示一次并保留两条依据。差异表、审查清单按内容结构选择，不把所有成果强塞进统一长 Markdown。
+
+### 8.2 用户可理解的结论标签
+
+| 内容类型 | 展示文案 | 发布要求 |
+|---|---|---|
+| 材料直接记载的内容 | “材料记载” | 指向文件版本与位置；不等于事实已被外部验证 |
+| 工具检查直接确认的结果 | “已核对” | 指向具体检查对象和真实结果；本地/独立/受信来源保留对应证据等级 |
+| 基于若干来源推导的建议 | “分析判断” | 提供依据，说明影响结论的假设 |
+| 尚有关键缺口的判断 | “初步判断” | 显示缺口、覆盖范围；不得写成最终结论 |
+| 需要人决定的口径/事实 | “待确认” | 给明确问题和影响，并关联确认入口 |
+
+这些标签描述内容性质，不提升 SELF/REPLAY/GATE 信任等级。不显示没有校准依据的“可信度 95%”。重要来源失效时保留历史结论，当前摘要标“依据已更新，需重新核查”。
+
+### 8.3 来源定位与修订
+
+来源至少包含项目/会话归属、文件或工件 ID、版本或内容摘要、可用定位信息及发布事件。优先页码、章节、段落；现有解析器没有页码时显示章节/片段，不编造定位。权限失效显示“当前无法访问该来源”，摘要权限同步重新检查，不以历史缓存继续泄漏内容。
+
+输入复用身份必须包含实际内容摘要：优先原始文件内容 hash 与解析版本，缺少原始 hash 时至少包含实际解析文本 hash、解析版本与相关处理配置，不能仅用文件名和字数当版本。保留既有附件路由，但不同内容不得复用旧任务成果。当前材料键校正作为 U2 来源修订的前置依赖，可用关联修复增量交付；旧卡无法证明内容一致时仅作历史结果，不自动认定本次输入已经整理。材料键等兼容凭据应保留在受控元数据与旧客户端回退投影中，用户默认卡身不展示内部键。
+
+发现具有稳定 ID、有效状态与版本：当前有效 / 已修正 / 已撤回 / 已被替代。后续推翻早先发现时，摘要替换当前有效项，阶段历史留一条“此前判断已修正”并给原因、影响和新依据。若曾需要用户据此行动，必须发一次有意义的更正提醒。
+
+### 8.4 任务结束后的内容
+
+```text
+材料整理已完成
+结论：当前材料可用于需求草稿，仍有 2 项关键口径需确认
+
+• 核对出 3 项缺少验收条件的需求
+• 上线日期冲突，需要项目负责人确认
+• 评审意见的 2 条调整尚未反映到需求说明
+
+范围：已覆盖三份材料的可解析文本；图片附件未纳入
+[查看完整摘要]   [查看来源]   [确认交付物]
+```
+
+生成文件不代表用户已认可或文档已审签。另显示交付状态：草稿已保存 / 等待评审 / 已认可 / 已发布；正式状态只采用业务宿主确认结果。检查未执行时写“未检查”，不以“已生成”代替“已验证”。示例中的完成与发现仍为设计数据。
+
+## 9. 动态更新、通知与阅读稳定性
+
+### 9.1 更新来源与频率
+
+采用两条信息路径：**确定性活动状态**来自任务登记、工具开始/结束、等待用户、存储结果等事件；**业务摘要**来自显式阶段成果或对已完成结果的受控压缩。模型只提交摘要候选，服务端校验来源、覆盖范围、版本与终态后发布。
+
+| 变化 | 更新位置 | 初始调度策略 |
+|---|---|---|
+| 入队、执行开始、等待用户、失败/结束 | L0 + 原任务卡 | 持久化成功后立即发布；在线端到端目标 p95 ≤2 秒，待测 |
+| 工具开始/结束、活动描述变化 | 原卡的活动行 + L3 | 同任务合并高频变化，普通视觉更新最多每秒一次 |
+| 新阶段成果、建议发生实质变化 | 原卡 L1/L2 | 检查点发布；连续普通成果可在 8–15 秒窗口合并，首条有效成果不必等待窗口 |
+| 必须用户决定、关键风险、更正重要结论 | 对话提示 + 原任务卡 | 绕过普通摘要窗口；同一事件幂等提示一次 |
+| 没有新业务成果 | 活动行/连接提示 | 保留已有摘要；不自动追加“仍在分析”消息 |
+| 多任务相继完成 | 各卡 + 合并完成汇报 | 原卡先显示结果；父会话空闲再合并汇报，不阻塞结果可读 |
+
+时间参数是初始设计值，实施后通过可用性与性能验证调整，不是实时性已经达标的结论。执行日志收集不按视觉节流丢弃；合并的是显示更新和重复语义通知。
+
+### 9.2 控制摘要成本
+
+优先由当前执行器在自然检查点提交简短成果；必要时才另行压缩已完成的工具结果或阶段文本。不按每个 token、每个工具调用或每个定时 tick 运行新模型。
+
+候选边界：单任务最多 6 次额外摘要模型调用；普通额外摘要最小间隔 15 秒；最终主任务的结果汇总属于执行预算，仍受已有整体预算控制。费用上限在实施评审时与模型、材料范围一起批准。预算耗尽或摘要生成失败时，保留已发布发现并继续显示真实活动；不阻塞主任务，不伪造阶段成果。
+
+阶段成果发布应由运行时检查点驱动，不能只依赖模型自觉调用工具。没有可安全提取成果的长单次模型调用期间，只展示已确认活动与最近成果时间。若任务需要持续提供发现，可在不改变业务结论前提下拆成有产出的处理批次；这些提示词/行为改动需真实模型前后对照。
+
+### 9.3 不打断阅读
+
+用户阅读历史消息时不自动滚动；输入中不夺取焦点；正在看文件时不自动切“工作”或打开另一文件。出现新结果显示“1 项结果已更新”，由用户点击查看。用户主动等待的首次前台产物可沿用既有打开策略，但后台卡更新与 Surface 更新默认不抢占预览。
+
+同一卡片稳定 DOM 与区块 ID；不逐字重打整段摘要。更新相应段落并可轻标“新”，保留展开、选择、滚动和置顶。屏幕阅读器只播报阶段结束、关键发现和需要处理；不播报每个日志增量。减少动态效果时不播放状态动效。
+
+### 9.4 用户继续对话与调整要求
+
+后台任务运行时，对话依然可用；前台忙时沿用现有输入排队语义，并明确“消息待发送”。追问“现在发现了什么”读取已发布快照，无需新派任务。
+
+当前不假定在跑任务可动态接收新要求。补充内容应说明它将用于后续回合/新任务；如用户希望据此重新分析，创建关联的新尝试并保留原结果。未来可支持安全的任务输入修订，但必须有服务端确认“已接收并生效”后才显示生效。
+
+### 9.5 确认双入口的提交反馈
+
+对话与右栏按同一 confirmationRef 维护提交状态。点击后两处同步显示“提交中”并暂时禁用，收到服务端成功确认后才显示“已处理”。明确拒绝或提交失败时保留原问题、选项和错误原因；服务端返回已处理/版本过期时刷新共同对象，不能继续提交旧选项。
+
+请求超时或连接中断不能证明动作未执行，先显示“确认结果待核实”并查询既有动作记录，不盲目重复执行。重试使用同一幂等请求标识和相同参数；参数已改变则按新动作重新检查。前端不得以一个入口关闭为另一个入口业务完成的依据。
+
+## 10. 状态、异常与操作能力
+
+把三个维度分开：执行状态、成果完整性、连接状态。卡片的收纳/已读状态属于第四个展示维度，不驱动业务终态。
+
+### 10.1 执行状态
+
+| 状态 | 用户文案 | 说明与动作 |
+|---|---|---|
+| preparing | 准备中 | 只确认接收范围；持久登记后进入 queued/running |
+| queued | 排队中 | 队列已确认；只有服务器提供可信位置时显示序号，不给虚构等待时间 |
+| running | 进行中 | 显示真实阶段及最新有效发现 |
+| waiting_input | 需要你确认/补充 | 显示问题、影响、选项；无超时契约则不暗示自动继续 |
+| succeeded | 已完成 | 执行及必要结果保存均成功；是否满足全部用户要求由成果维度说明 |
+| failed | 执行失败 | 原因、影响、已保留内容和真实可用的恢复方式 |
+| cancel_requested / cancelled | 正在停止 / 已停止 | 仅在支持相应控制契约时暴露操作；请求送达不等于停止确认 |
+| interrupted | 执行中断 | 显示最后已保存检查点；恢复动作通过既有服务端支持判断 |
+
+这些是候选展示语义，不宣称 Core 已具备全部同名枚举。`waiting_input` 映射现有 waiting_hitl 等明确状态；旧后台卡 `done + danger` 要由 run 终态与 tone 映射为失败。没有可靠 run 对应时使用保守文案“任务已结束，结果状态待核对”，不解析任意正文来推断成功。
+
+成果完整性采用 complete / partial / none，并列出已覆盖和未覆盖范围。生成内容已经保存但汇报尚未送达时，显示“结果可查看，稍后在对话汇报”。交付保存失败时不能标“已交付”；可保留可读摘要并显示保存失败。
+
+### 10.2 连接与恢复
+
+在线 / 重连中 / 当前状态未核实只影响连接提示。60 秒没有新**成果**不等于执行失活；可显示“最近成果更新于…”，不能仅凭此声明失败。若要展示执行存活，须来自运行时心跳/执行所有权确认，另记录 lastActivityAt；现有源码没有已核实的通用任务存活契约，本方案将其作为新增设计。
+
+断线期间保留最后已确认结果，停止“实时”声明。重连先取得带流游标的快照，再重放游标之后事件；历史保留不足时重新获取完整快照。服务重启导致 run interrupted 时，依据真实终态显示中断；是否可恢复、恢复是否可能重放副作用由既有恢复能力决定，UI 不自动重试。
+
+### 10.3 按能力显示操作
+
+基础动作：查看摘要、查看来源、查看阶段/执行记录、处理既有确认、打开已保存文件、收纳结果。动作带服务端能力和禁用原因；UI 不根据模型写出的按钮名自行分发。
+
+暂停、独立取消、续跑、自动重试、改变在跑任务优先级不作为首期承诺。后台运行卡隐藏“关闭”式歧义动作，只提供折叠；收纳只影响历史呈现，不停止执行。现有输入区“停止”仍绑定现有前台能力；若其真实影响范围包含其他运行，必须如实说明，不能在本方案中改名为“仅停前台”而不修复契约。
+
+失败提示采用“问题 + 影响 + 已保留内容 + 下一动作”。例如：“评审意见未能解析，本轮只完成其余两份材料；已保存两份摘要。请补充可解析版本后重新核对。”有保存凭据才声明已保存。
+
+## 11. 多任务协作与领域展示
+
+一个用户目标下的任务组只给一份整体概览，各后台任务保持独立摘要。后台上限沿用当前 3 个槽位，队列与入场等待按运行时确认展示，不另造默认无限并发。
+
+总览优先突出阻塞与结论：“材料核对、竞品检索已完成；方案整理等待你确认预算”。只有明确可数的工作项才显示“2/3 项已完成”；这个比例不代表剩余时长或模型完成度。不能用工具次数、token 数或耗时估算百分比。
+
+并行发现经规则合并引用，冲突同时展示：“来源 A 写 6 月上线；来源 B 写 7 月，尚未确认权威口径”。完成任务先稳定保存成果再通知；父会话忙时新结果可读，业务汇报待空闲，多个结果可合并为一条简短汇报。去重键包括任务、尝试和结果版本，防止通知回合再派发原工作。
+
+领域可通过通用内容种类输出事实、差异、缺项、待办、建议和结果引用。RDM 类场景可由下游提供“受影响文档、验收条件缺项、审签状态”等内容与动作；基座不把材料整理“完成”解释为业务文档“已批准”。领域内容缺失时降级到通用摘要，不构造业务状态。
+
+## 12. 视觉与排版规范
+
+严格消费根 DESIGN.md，保持冷静、紧凑、内容优先的工作台。沿用用户此前选择的浅色克制方向，同时适配已有深色/墨绿主题。主题、字号与布局属于既有能力，实施不另造皮肤体系。
+
+| 元素 | 排版建议 | 规则 |
+|---|---|---|
+| 任务标题 | 基准字号、中等字重，状态靠右 | 优先业务名称，完整标题可换行；不挤满任务 ID |
+| 当前工作行 | 基准字号，主文本或次级文本 | 动宾语句；不重复标题或“慢通道”标签 |
+| 发现 | 基准字号；每条一至两行，3 条以内默认可见 | 保留影响与关键限定；来源紧邻对应发现 |
+| 范围、下一步、更新时间 | caption/sm 标尺；使用可读次级文字色 | 关键状态不能用 faint |
+| 进度 | 有数据时用步骤清单与真实数量 | 无百分比/ETA 表盘；活动用既有 mk-sweep/mk-breathe |
+| 动作 | 每张卡最多一个主动作，查看类为 ghost/链接 | 无需处理时不硬凑按钮 |
+| 长表/完整报告 | 详情/文件阅读档 | 默认卡只留摘要；宽表按需横向阅读 |
+
+卡内用 8/12/16 的重复间距；通过标题、段落和表面层级组织，避免一层卡套一层卡。圆角只用既有令牌，折叠统一 `@ui` Collapsible，状态动画只用 `mk-*`。所有图形状态同时有状态词与可访问名称。颜色不能替代状态语义。
+
+桌面沿用可拖三栏，右栏工作宽 280–560、文件阅读宽 420–1100 的现有规范。窄屏优先保留对话与 L0，任务摘要内联展开；文件仍通过同一预览对象打开。长文件名、中文长标题、18px 用户字号、320px 宽度都不得丢失必要动作。不得靠把全卡文字缩到 11px 解决拥挤。
+
+运行卡与完成卡沿用相同结构：结束后移除活动动效，当前工作区变为最终结论，保留来源与缺项。不要整张卡消失后另造结果卡造成位置跳变。最终文件卡的显示遵守 DESIGN.md：执行期仅说明草稿/保存状态，正式可打开交付物在结束并确认保存后出现；中途检查点文字可读，但不伪装成最终交付物。
+
+## 13. 技术设计：确定性状态 + 可验证摘要
+
+### 13.1 职责
+
+| 层 | 职责 | 不承担的职责 |
+|---|---|---|
+| Core | 定义任务摘要、发现、来源、动作能力的共享契约 | 不生成领域结论 |
+| Runtime | 提供真实执行阶段、工具结果、检查点和摘要候选 | 不自行宣告权限/存储/最终成功 |
+| Backend | 服务端权威投影、校验、持久化、事件发布与通知 | 不把模型叙述当执行证据 |
+| Frontend store | 按 task/run 与事件作用域更新同一快照 | 不由计时编造进度，不分别生成两套摘要 |
+| UI | 纯展示，稳定折叠/排版/动作事件 | 不直连模型，不拥有业务异步状态 |
+| Documents | 本方案、内容规范、验收与关联记录 | 不承担运行状态 |
+| 下游/插件 | 提供领域成果与受控丰富视图 | 不替代基座任务状态与权限 |
+
+优先在既有 runmgr/card/store 链路补齐投影，不另建进度微服务或独立状态仓。后台与前台按 runId 路由，前台消息仍用现有 live；后台进度使用按任务键控的结构化快照，防止共用单个 live 正文。
+
+### 13.2 候选数据形状
+
+以下是契约草图，字段名在 Core 设计评审时固定，不是可直接执行的 API。
+
+```text
+TaskSnapshot
+  taskId, projectId, conversationId, sourceMessageId
+  parentTaskId?, attemptId, runId?       # 排队时可以尚无 runId
+  revision, streamScope, sourceSeq
+  title, goal, inputRevision
+  executionState, outcomeCompleteness
+  phase { id, label, observedAt }
+  focus, coverage, remaining, nextStep
+  findings[] { id, text, impact, kind, status, sources[], revision }
+  actions[] { id, capability, enabled, reason?, confirmationRef? }
+  resultRefs[] { artifactId?, surfaceId?, version, availability }
+  lastActivityAt?, lastMeaningfulUpdateAt
+  deliveryState, error?
+
+ClientViewState                         # 展示偏好，不改业务状态
+  taskId, collapsedSections, pinned, readRevision, scrollAnchor
+  connectionState
+```
+
+taskId 在排队前持久登记并关联同一张卡；runId 表示一次实际执行，attemptId 区分新尝试。旧失败和新尝试不互相覆盖。readRevision 与 dismissed/收纳分离，用户读过不意味着执行已完成。
+
+为兼容旧客户端，ActivityCard 可添加可选结构化摘要字段并保留 Body 的精炼回退投影；旧客户端看 Body，新客户端用结构化内容。核心信息的唯一权威仍是服务端快照；不得用独立 JSON、Markdown 和 Surface 各维护一份互不核对的业务状态。Body 与 Surface 是从同一快照派生的展示。
+
+### 13.3 发布与恢复流程
+
+```text
+真实运行事件/阶段成果
+  → 运行时语义映射与摘要候选
+  → 服务端校验：归属/执行对象/来源/权限/版本/长度
+  → 原子保存快照 revision 与对应投影事件
+  → 既有 card.updated 会话流发布
+  → 前端按作用域 seq、taskId 和 revision 更新
+  → L0/L1/L2 同步呈现
+  → 关键变化进入幂等通知；L3 保留执行记录
+```
+
+持久化与事件写入须原子一致；优先使用既有事务/持久事件机制，若当前 cards API 不能支持原子更新，先补齐内部事务入口。终态正文、状态、tone 应作为同一快照发布，避免先出现失败正文后仍亮成功灯。不能只靠客户端临时合并掩盖持久状态不一致。
+
+消费顺序按**会话流或项目流各自游标**；不同流的 seq 不可比较。重复事件不二次通知，旧 revision 不覆盖新快照；出现游标间隙先对账/重放，不仅执行 `max(seq)` 后跳过未知事件。会话切换隔离响应，迟到事件按归属放回缓存或丢弃，不能写到新会话。
+
+快照读取返回与其一致的重放水位；获取期间继续到来的事件需缓冲并在快照后顺序应用。排队、启动、最终保存、通知待发送均可刷新恢复；不得只把动态发现放在内存 `agentNotes`。恢复与副作用规则与既有服务恢复方案衔接，本次不建立第二套恢复执行器。
+
+**重启对账不能把展示快照当作执行队列。** 当前等待后台槽位的 bgQueue 仅在内存，无 runId 的排队卡不在既有 run 恢复扫描范围。U2 启动对账须区分“可读历史快照”与“已确认重新拥有执行者”：没有可信持久入队凭据或执行所有者的 queued 任务转为 interrupted，并同步旧卡回退状态与材料去重状态，显示“排队任务未恢复，未开始执行”，不自动重派。只有既有执行系统确认队列恢复后，才可继续显示排队并允许晋升；首次增量不承诺队列自动续跑。
+
+### 13.4 生成式成果与普通任务卡
+
+已有 Surface 可用于对比表、报告页、审查清单；基础状态、风险提示、确认与失败始终由确定性组件呈现。后台 Surface 更新只提示“结果页已更新”，不自动切预览；需要在现有 Surface 投影策略中区分前台主动呈现与后台更新。
+
+插件禁用或页面渲染失败时，任务摘要仍可读，来源和基本动作仍可用。Surface 的动作继续走现有受控命令能力，不从摘要文本或外部材料解析可执行命令。
+
+## 14. 落地顺序与 U1 出口白名单
+
+下表是已批准的分期顺序。**首批锁定仅 U1**；U1 业务代码须另批 [U1 实施计划](2026-10-12-fast-slow-channel-display-u1-plan.md) 后方可启动。各增量的具体文件、迁移、运行材料与费用以对应实施计划为准。
+
+| 增量 | 关联需求 | 范围与依赖 | 出口 |
+|---|---|---|---|
+| U1 统一状态与精炼内容 | R01/R02/R03-a/R08/R10（骨架）/R13 | Core/UI/Frontend/Backend；旧卡兼容及状态映射；L1 骨架重排；去除原始提示词默认展示 | 见下方 U1 出口白名单 |
+| U2 持久动态任务投影 | R04（活动投影）/R05（结构）/R06/R09/R12/R17/R03-b | 依赖 U1；材料内容版本身份校正前置；Core 契约 → Backend 快照/事务/事件及无 runId 排队重启对账 → Frontend 按任务路由 → UI 动态渲染；运行时确定性阶段 | 并发、刷新、重连、乱序和终态一致；阶段活动持续更新；无执行凭据的排队任务不得永久显示排队 |
+| U3 有价值的阶段成果 | R03-c/R04/R05/R07/R10（完备）/R14 | 依赖 U2；Runtime 检查点、来源、候选摘要、通知去重；优先材料整理，再研究/生成/审查 | 选定长任务至少两个真实成果检查点；短任务可直接完成；事实、判断、缺项可分；必要动作闭环 |
+| U4 场景与可用性完善 | R11/R12/R13/R15/R16/R18 | 依赖 U3；多任务总览、修订提醒、窄屏、可选 Surface、领域适配；未支持控制能力仍不暴露 | 典型场景完成真实浏览器及用户评审；精炼度与可用性目标有实际记录 |
+
+跨仓以 Core 类型权威优先；Backend vendored Core、Frontend/UI 消费固定提交；Dev 推进精确 gitlink，组合测试后评审。视觉规则变动需要与 DESIGN.md 配套；只消费既有令牌时不为本任务无故新增色板。
+
+### U1 出口白名单（定稿）
+
+**须交付并可判定**
+
+- 排队 / 进行中 / 已完成 / 执行失败 状态词与状态灯一致；失败使用失败语义（不得再以「完成」灯表示失败）
+- 建卡默认 Body 为 L1 骨架，不以原始任务指令（≤400 字截断）作为主视图
+- 无阶段成果时显示诚实占位：「尚无阶段结论，正在读取材料」或等价文案
+- 完成卡骨架：结论 → 最多 3 要点 → 范围/缺项 → 产物入口（有则显示）→ 必要下一动作
+- 简单问答不产生空进度卡；仅登记成功才说「已登记」，仅实际开跑才显示「进行中」
+- 旧卡兼容：历史 `done + danger` 在新客户端映射为失败展示，不崩溃
+- DESIGN.md / 令牌 / Collapsible / `mk-*` 相关守护通过
+
+**明确排除（不得用 U1 验收）**
+
+- 运行中真实业务发现、来源定位、检查点驱动摘要（R03-c / U3）
+- 按 `taskId` 持久 `TaskSnapshot`、revision/seq 对账、材料内容 hash 身份（U2）
+- 无 runId 排队任务重启 → interrupted 对账（U2）
+- HITL 双入口提交中 / 超时未知 / 幂等闭环完备（U3）
+- 窄屏完整能力、多任务总览、Surface 增强、修订提醒（U4）
+- 暂停 / 独立取消 / 续跑等未支持控制能力
+
+合并 U1+U2 为基础投影批须**另行明确批准**；即便合并，阶段发现仍属 U3。
+
+## 15. 验收、证据与失败判据
+
+所有下面的运行场景为**计划验收，NOT_RUN**。示例数据只用于评审排版，不当作真实链路通过证据。
+
+| 用例 | 关联需求 | 关键观察 |
+|---|---|---|
+| A01 三个附件、无文字直接发送 | R01–R05/R10 | 已确认接收 → 同卡排队/运行 → 有成果则发布 → 完成摘要与选择；选定长材料验证两个真实成果检查点，短材料可直接完成；不重复派发 |
+| A02 小材料加明确分析要求 | R01/R02/R04 | 即时答复与现有兜底路由一致；不声称尚未登记的任务已运行 |
+| A03 三个后台任务 + 前台对话 + 第四任务排队 | R02/R06/R09 | 各任务归属正确；排队晋升复用 ID/卡；前台正文不串后台 token |
+| A04 部分解析失败/无可解析文本/材料超预算 | R03/R05/R08 | 显示已覆盖、缺项与影响；解析与分析完成不混同；无法分析则不生成假摘要 |
+| A05 用户追问与补充重点 | R01/R07/R15 | 读取当前快照；新要求生效范围明确，未实现动态输入时不假承诺 |
+| A06 早期发现被推翻、来源文件更新 | R05/R17/R18 | 当前结论修正、历史可追溯；重要更正通知一次；同名等长内容更新不得命中旧材料结果；过期版本不覆盖最新 |
+| A07 断网、刷新、换会话、重复/乱序事件 | R06/R09/R12 | 保留最后快照；恢复水位一致；状态不回退；旧会话数据不写入新会话 |
+| A08 模型失败、预算耗尽、摘要不可用、服务中断 | R08/R09/R14 | 正确显示失败/中断；包含无 runId 的排队任务重启后对账及材料去重释放；基础状态与既有成果仍可读；无自动副作用重试 |
+| A09 前台忙时后台完成、通知重投 | R04/R10/R17 | 结果卡先可读；汇报待空闲；重投不重复通知或派任务 |
+| A10 同确认双入口与重复点击 | R07/R11 | 提交中、成功、拒绝、超时未知、过期/已处理响应都一致；重复点击只执行一次；右栏关闭也可处理 |
+| A11 文件正被阅读、Surface 后台更新/插件关闭 | R11/R12/R16 | 不抢焦点、不切文件；插件关闭核心任务卡不缺失 |
+| A12 未授权跨项目/用户来源、读权限撤销 | R05/R09 | 新摘要、来源与历史缓存无越权；只显示许可范围内内容 |
+| A13 文件保存失败、文件已更新/已移除 | R08/R10/R17 | 不出现虚假可打开工件；版本与保存状态准确；有可读摘要不等于已保存文件 |
+| A14 320/390/736/1024/1440 宽度与用户字号档 | R11/R13 | 无页面级横向溢出，必要动作可达，键盘/屏幕阅读/减少动效符合规范 |
+
+验证分三层：契约与投影测试确认状态/顺序/并发；真实模型任务前后对照确认阶段成果质量；真实浏览器与用户任务确认排版和工作价值。不能用 mock 进度验证真实模型发布了有用摘要。
+
+行为改动按 policy/delivery.md 真实模型要求执行：固定候选组合、同材料同任务前后对照、记录模型/参数/费用/失败及来源。正式检查使用 `make evidence` 写入 precheck、task-sync 和相关测试原始输出；Dev CI 在 PR HEAD 上的 `make test`、`make build` 作为 GATE，作者本地记录仍为 SELF。设计文档检查不代替这些运行验证。
+
+可用性记录至少覆盖三类任务：材料整理、分析审查、文档生成。请代表性用户完成第 1 节三问并定位一条来源、处理一次确认、找到一份结果；记录完成时间与错误。精炼度以“是否漏掉关键限定/风险、是否能支持下一步工作”评判，不能只统计字数变短。
+
+实施停止/回退条件：发现状态串任务或越权内容；终态与存储不一致；修订导致当前有效结论丢失；摘要循环显著超预算；关键确认被折叠藏起；真实模型阶段成果持续无依据。先回退受影响展示/摘要增量，保留原执行与已保存结果，按实际影响重审。
+
+## 16. 评审与当前进展
+
+| 项目 | 当前状态 |
+|---|---|
+| 当前源码核对 | SELF；固定对象与输出在任务卡；不等于运行验收 |
+| 需求拆解 / 需求评估 / 需求表 / 方案设计（阶段 1–4） | **已通过**（2026-10-12，对象版本 r1.1；评审人 weichen；依据：用户确认评审结论计划并指示落地） |
+| 实施计划（阶段 5） | U1 计划见 [u1-plan](2026-10-12-fast-slow-channel-display-u1-plan.md)；**待用户批准该计划后**方可启动业务代码 |
+| 辅助设计审阅 | 七个视角 SELF 辅助分析已纳入 r1；不提升为 REPLAY/GATE |
+| 业务实施、真实模型实验、运行与浏览器验收 | NOT_RUN |
+| 推送、PR、合入、部署 | 本方案任务未执行；文档推送/PR 须另获授权 |
+
+本次推进的是快慢通道用户展示设计，不改变现有附件路由和生成式 UI 规划的批准状态。与既有恢复/团队存储方案的重叠仅为消费其执行终态、权限与恢复能力；新增持久字段和事务入口须评审后协调，不自行修改其他任务的主记录。
+
+辅助审阅覆盖一致性、范围、可行性、设计、产品、对抗与安全七个视角（其中一致性/范围、设计/产品/对抗/安全分别由同一子代理分析，并非七名独立审阅者）。采纳并自行核对后修订五类问题：两次成果检查点只用于代表性长任务；新增要求的生效文案不误导；确认双入口补提交与未知结果状态；材料版本复用需实际内容身份；无 runId 排队任务重启时不能假装仍有执行者。
+
+r1.1 相对 r1 的定稿修订：R03 切分为 a/b/c；U1 出口白名单与排除项写入 §14；首批锁定仅 U1。摘要次数/窗口与性能数字仍为候选参数。**设计批准不等于实施授权**；批准 U1 实施计划后另开实施任务，本设计任务不自动启动写代码。

docs/proposals/2026-10-12-generative-ui-usage-and-evaluation.md

@@ -77,7 +77,14 @@ Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」
 - 工作区：前端「任务页面」容器显示最新页（pin/follow 测试覆盖）。
 - 收据：Dev 任务卡 feature/generative-ui-u7-acceptance（SELF；CI GATE 随发布 PR）。
 
-### 已知边界与后续项
+### 现场体验驱动的修复记录
+
+| 日期 | 症状 | 修复 | PR |
+|---|---|---|---|
+| 2026-10-12 | `POST /api/surfaces/{id}/actions` 对无确认卡的 committed 动作 panic（nil Card） | dispatcher 空指针守卫 | Backend#173 |
+| 2026-10-12 | `system.intent` button 动作恒报 missing text | action data 键上浮到命令 params | Backend#174 |
+
+## 已知边界与后续项
 
 - 自动触发 opt-in：settings `plugins.generative-ui.autoPresent`（默认关；须同时
   Surface activation）；语义事件 + 预算≤3/时 + 冷却≥60s；设计见
@@ -86,7 +93,9 @@ Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」
   不嵌套分发；提案 `2026-10-12-generative-ui-bclass-help-intent.md`）；其余仍逐条评审。
 - 人类可用性对照以 owner 实际使用替代（2026-10-11 用户裁定），本轮体感「初步不错」，
   小问题另行修复。
-- 部署与运行验收按独立授权推进。
+- 部署与运行验收：本机 `prod` 实例已登记（`scripts/svc.sh prod`，`--auth on`，
+  PG `pg1/prod`，来源 `dev@c76f2bb`+后端 nil-card 修复）；验收覆盖启禁、present、
+  B/C 类动作、项目聚合、未登录 401。
 
 ## 三、结论
 

docs/proposals/2026-10-12-rdm-function-implementation-plan.md

@@ -0,0 +1,539 @@
+---
+title: RDM 功能、实现与计划矩阵及追溯审计和权限闭环整改方案
+date: 2026-10-12
+type: fix
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 功能、实现与计划矩阵及整改方案 r1
+
+负责人：weichen；编制：Codex；核对日期：2026-10-12（北京时间）。
+本稿供人工评审，尚未批准实施。此次仅研究、读取运行元数据与保存报告；未实施业务代码、操作业务数据库、执行测试、部署或重启。
+
+保存说明：Dev 首次启动检查因 Backend 的 `index.lock` 返回 `SHARED_WORKSPACE_BUSY`。按 `AGENTS.md` 任务启动门禁，不创建项目 worktree、不写共享检出；报告暂存为独立交付文件。入仓时由项目 owner 排除共享写入冲突后，在登记任务 worktree 保存到 Documents proposals，并更新 INDEX/PROJECT 的入口。此次没有修改这些入口。
+
+### 发布补记（2026-10-12 入仓时）
+
+本稿冻结观察之后的运行时变化（独立于上文，不回改冻结记录）：
+
+- dev 槽位部署时序（北京时间）：14:54 `rdm@310c3fe` → 15:50 回滚普通基座 `dev@4bf6e4a`（根页此时已 200 服务 React 资产）→ 16:37 刷新为 `dev@0d224ff`（权威 main 组合，backend=5e8ada7 / frontend=cc233fe，plugins 目录无 RDM 插件）。「根页 404 与缺少嵌入产物一致」的判断已被 main 组合现状超越；RDM 组合产物与门控验收仍开放（U1/PR #450 线）。
+- 本稿 U2 执行端问题表第 1-5 行与第 7 行前半已按本方案在 Agent-System-RDM 合入（PR #251/#254/#256/#258，红测先行，CI 绿）；第 6 行归 U4、第 7 行后半归 U5、第 8 行待私域语义设计。行号引用基于冻结源码 1ee2b300，合入后有所漂移。
+
+## Goal Capsule
+
+使创建者能在实际使用的 dev 服务中管理项目成员与文档职责，使管理员能创建专业角色并配置权限，使编制、审核、批准人员完成同一份文档的审签，并能从实际页面追溯来源、操作与历史。
+
+复用现有 RDM 项目、成员、权限、两树一网与审签组件，先修组合产物及执行端缺口，再接现有项目设置、系统管理与文档工作区，最后按真实账号验收。完整目标仍覆盖全部 34 UR、68 SR、10 F，不以本次五个问题修好替代全系统交付。
+
+本稿终点为可评审矩阵和方案。实施、真实账号测试、数据迁移、部署及正式验收各在对应授权后进行。当前用户请求未授权这些动作。
+
+## Product Contract
+
+### 来源与权威
+
+1. 本轮用户报错及补充：访问 `localhost:8788`，58880 是 FRP 映射，实例为 dev；要求核对全系统，重点追溯审计、三权、项目成员、系统角色、权限矩阵。
+2. RDM `docs/requirements/README.md:15-32` 规定的 V2.2 正文与 U0/Q 裁定；重点 `01-用户需求与系统需求.md`、`03-产品设计方案.md`、`08-核心数据模型-两树一网.md`、`10-实施推进方案-基座与下游二次开发.md`。
+3. RDM 原始用户补充 `docs/materials/meeting-sources/user-supplement.txt` 和 `user-design-ideas.txt`；原始内容用于解释需求，不反向覆盖较新裁定。
+4. Documents `docs/proposals/2026-10-11-rdm-final-target-completion.md`、模板子方案、两树一网追溯展示方案；主计划与任务卡存在历史批准记录，页首残留“待评审”不能单独否定批准。本次整改路线仍需评审。
+5. RDM `docs/records/2026-10-11-requirements-evidence-matrix.md` 是逐条维护入口；Documents 副本是旧附件。`2026-10-12-final-acceptance-ledger.md:39-53` 全量运行验收仍为 NOT_RUN。
+
+UR-21（系统角色权限）、UR-22（项目和成员）、UR-24（文档三权）均为本期 P0 已定需求，不能再解释为尚未决定是否做。管理权不赋予代编、代审、代批权；文档编制唯一、批准唯一、审核至少一人，三种职责互异。项目创建者在平台上限内覆盖项目权限。私聊、原件和个人草稿私有，受控文档按职责或显式授权读取。
+
+### 核对对象及证据边界
+
+| 对象 | 固定版本 / 观察 |
+|---|---|
+| Dev | `8c1edbebece8212ec8c0cd9e646b4b0592b1503d`；研究初始为 `72f6a679`，期间由其他任务更新 |
+| Backend / Frontend | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` / `cc233fec908d0f8c12193042942b94ad68508091` |
+| Documents / UI | `9d9b1523c87dc4ba178d143a8b966a77be9b320b` / `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700` |
+| RDM 本地源码 | `1ee2b300a9c898ef5b9e2febafa6b0f2eb871c15` |
+| dev 当前 RDM 部署来源 | `310c3fe42fec2416b8b1e1e72e00ad2e53b58130`；相对 1ee2b300 仅四个 pins 与任务卡变化，本文 RDM 业务行号仍适用 |
+| dev 当前进程文件摘要 | `420654002eb0cdc28ce9d90a8d258f215192dee78ff74195db2b2657b3fe3fff`；2026-10-12 15:04:37 核对 |
+| 服务访问 | user 确认 58880→8788；本轮直接 GET 8788 根路径为 404，未登录 GET `/api/commands` 为 401 |
+| 对照实例 | 9015 的命令清单有 enabled 的 inspect 命令；这是另一实例，不能作为 dev 通过依据 |
+
+15:24:29收尾刷新：Dev主检出由其他任务推进至 `0d224ffcab82cab7def2c0b0cc36d2e6d02ce3dd`，Documents至 `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`；RDM业务源码、Backend、Frontend、dev部署来源及进程摘要均与上表一致。8788根页仍404，未登录命令清单仍401。新收据 `runtime-refresh-receipt.json` 保留该时间点，不覆盖15:04的调查收据；本文RDM需求与业务判断仍以固定1ee2b300为对象。
+
+源码阅读、运行登记、HTTP GET 与本稿审阅均为 SELF；没有复核 GATE/独立 REPLAY，不作业务 PASS 判定。完整命令输出由 `make evidence` 保存为随附收据，未手工重构。测试文件存在只表示已有测试资产。
+
+### 追溯审计故障结论
+
+2026-10-12 **14:50:06.701 北京时间** 的 `unknown or disabled command` 是命令总线 `Resolve` 阶段失败（Dev Backend `internal/cmdbus/cmdbus.go:252-254`），服务将 rejected 映射为 HTTP 400（`internal/server/server.go:1012-1014`）。该阶段尚未进入 RDM 的项目/审计权限判断；放宽权限不能注册一个不存在的命令。
+
+同一 dev 的部署历史显示：13:38:38 启动 `dev@4bf6e4a` 普通基座，14:50:48 停止，14:54:49 启动 `rdm@310c3fe`。用户确认访问这台服务。基座入口仅 import 基座 app；RDM `main.go:18-23` 才 import `plugins/rdm`，后者 `plugin.go:17-21,173-179` 注册命令。因此，故障时**正式前端暴露了研发审计入口，而同实例运行普通基座、没有 RDM 命令**，有部署历史和组合根源码支撑。
+
+此后其他任务已切换部署，不意味着审计运行验收完成：当前 8788 根页 404，命令清单需有效登录才能核对。本轮未借用账号、创建凭证或发送会写审计回执的业务 POST，未重现当前登录态下 capabilities 调用；历史故障定位与当前修复验收分开记录。
+
+现有 Frontend 已增加七命令门控及人话错误，见 `src/workspaces.ts:22-36`、`src/store.ts:794-801`、`src/rdmErrors.ts:16-24`。仍有三项接线缺口：
+
+- RDM `Makefile:39-40` 只 Go build；Dev `scripts/svc.sh:1446-1464,1594-1600` 对 RDM 也只构建 Go 并复制独立 `web/`。更新 frontend pin 没有构建及嵌入 React dist；Backend `web/embed.go` 要求构建前具备 dist。当前根页 404 与缺少嵌入产物一致。
+- `AdminZone.tsx:37,67-71` 的声明管理分区没有消费七命令门控；插件注册失败允许保留部分能力（Backend `internal/app/compiled.go:198-202`），所以“插件列表有 rdm”仍不足以证明审计页可用。
+- 错误分类把 403 和 401 都解释成登录失效；实际已登录但无权限时应展示权限拒绝。原始 receipt.reason 要保留。
+
+密码字段未处于 form 的浏览器提示是独立问题，不会造成命令注册失败。React 主动改密、登录及强制改密已有 form 修复；RDM 独立 web 的令牌 password 仍位于普通 div。修复有源码记录，当前浏览器验证 NOT_RUN。
+
+### Requirements：本次整改验收要求
+
+| ID | 用户可见行为 | 原需求映射 | 判据 |
+|---|---|---|---|
+| R1 | 同一正式入口加载匹配的研发前端与 RDM 后端 | UR-08/25，SR-D1/D6/G3/G5 | 登录后七命令齐备并可查询有数据项目；无 RDM 时不出现可进入后即 400 的页面 |
+| R2 | 创建者在项目设置添加、移除、调整成员 | UR-22，SR-G9/G10 | 选择有效系统账号，加入后同 projectId 可见；最后负责人保护；撤权立即影响现有访问 |
+| R3 | 管理员创建/停用专业角色、分配账号并设默认和上限 | UR-21，SR-G6/G7/G8 | 自定义角色持久化；重启保留；项目设置不得扩大系统上限 |
+| R4 | 系统和项目矩阵解释实际允许/拒绝 | UR-17/21，SR-G2/G6/G7/G8 | 同一动作矩阵结果与 API/命令/工具/后台执行一致，能显示默认、上限、覆盖与原因 |
+| R5 | 创建者按文档分配编制、审核、批准 | UR-24，SR-C7/G9 | 有效项目成员、三种职责互异；资格不足明确说明；无职责任务保持可见等待 |
+| R6 | 三个人完成固定整文版本审签 | UR-24/25，SR-C3/C7/C8/D6/G3/G5 | 非编制不可改正文；审核可批注/驳回；所有审核完成才批准；旧票不能签新正文 |
+| R7 | 图、历史、导出及文档读取符合当前授权 | UR-08/23/25/33，SR-D/G/N4 | 合法职责人员能读自己的文档；跨项目/私域不可见；审批与导出是同一固定快照 |
+| R8 | 界面、对话、工具、卡片访问同一对象与执行服务 | UR-10/16/27/28，SR-E/F，F-06 | 右栏关闭仍可完成支持的动作；模型不能伪造身份或自动签字；撤权及迟到结果不旁路 |
+
+### 功能、实现、缺口与计划矩阵
+
+“已有”仅描述固定源码中的能力；“UI 缺口”指正式用户路径未闭合。除特别列出的只读观察，全表运行验收 NOT_RUN。U 编号均带方案名称，避免“追溯展示 U3”和“完整目标 U3”混用。
+
+| 功能域及需求 | 当前已有实现 | UI/对话与执行缺口 | 后续工作与现有计划归属 |
+|---|---|---|---|
+| 项目身份/成员：UR-22；G9/G10 | 全局研发项目、生命周期、成员持久表、成员可见同项目目录；局部 #203 | 项目设置无成员页；有效账号目录及可信宿主映射未闭合；新旧成员守卫不同；建项与owner写入非原子 | 本稿 U3/U6；完整目标 U2 |
+| 角色/权限：UR-21/17；G2/G6-G8 | 12 动作、全局 cap、项目成员 override；cap∩默认/覆盖 | 角色固定 admin/owner/member；没有专业角色CRUD或完整矩阵；多个业务入口绕过 cap | 本稿 U2/U4/U6；完整目标 U3 |
+| 三权/版本：UR-24/25；C3/C6-C8 | 文档职责默认及章节覆盖 #205；章节审签；持久提案、整文内容快照 #217 | 没有分配页；schema 与可信身份互斥；审签仍按章节；非编制写入、审核驳回、整文批准快照未闭合 | 本稿 U2/U5/U6/U7；完整目标 U3/U8，模板子案 U3-U5 |
+| 资料接收/解析：UR-01-04/18；A1-A5/B1-B7 | 原件、三态相关性、MD/TXT/DOCX、快慢处理；台账私域 #209；锚点 #211 | PDF/表格/PPT/图片未完整接线；三个附件无文字实测、60秒反馈及10分钟级管道没有实际签收 | 完整目标 U5/U9/U14；在本稿 U8 衔接 |
+| 结论/冲突：UR-07/26/34；B8/B9/B11/B12 | 提议确认、词面冲突、指定冲突对关闭与水位修复 #215 | 完整候选组、文档依据/项目结论两层裁决、来源变更影响与通知闭环未充分完成 | 完整目标 U6；本稿 U8 衔接 |
+| 模板/全文档：UR-05/15；C1/C2 | 69 类型 catalog #207；正文 registry 仍4模板、3文档类型 | 目录登记不是全部模板；结构/格式/发布版及XLSX、全量生成审签导出未验收 | 完整目标 U7→U8→U16；本稿 U8 衔接 |
+| 对话生成：UR-10/11/12/16；E1-E6/F1-F5 | 模型 compose、持久提案、原子采纳、整文内容快照 #217/#219 | 全动作自然语言及工具投影缺失；依据完整性、差异采纳与真实模型/用户链待验证 | 本稿 U7；完整目标 U8/U9 |
+| 私域/项目协作：UR-23；G11-G13/N4 | 基座owner会话隔离；上传及确认资源约束 #209 | 同项目草稿/原件/受控文档全读面、Host检索、明确只读分享与撤权需贯通 | 本稿 U2/U4/U5；完整目标 U3/U5/U9 |
+| 追溯/审计/历史：UR-08/25；D1/D5/D6/G3/G5 | 两树、一般网/合规网、原子事件、inspect和导出；追溯展示 #195/#197/#201/#213 | 用户dev曾未组合RDM；新产物无React根页；Host审计覆盖仍缺；四链/完整矩阵实际展示未全部接线 | 本稿 U1/U7/U8；完整目标 U4/U11/U14、F-09 |
+| 需求/风险/合规：UR-09/33；D2/D7-D11 | 控制节点/候选边/确认 #231、req→graph #233、UR→SR及需求快照 #235 | 真实风险→措施→验证及SOUP、六维分解、四链业务录入、专家校准及真实交付尚待验证 | 完整目标 U11/U14；本稿 U8 衔接 |
+| 法规双通道：UR-13/14；F3 | #236已实际HTTP抓取候选、摘录核对、快照；“只模型URL”旧结论过期 | 真实权威素材、失败/冲突/版本场景及首批模板法规闭环仍未签收 | 完整目标 U12；本稿 U8 衔接 |
+| 快慢任务/卡片：UR-27/28/29/30；B10/E/F | 卡片/小队；slow保存原文且可重新入队 #219 | slow台账未保存project/owner，恢复入队传空项目；取消/恢复/重新授权、同源卡片与模型结果需闭合 | 本稿 U7/U8；完整目标 U9/U13 |
+| 阶段/结项：UR-06/17；C5/G2 | 阶段序列、三级门禁、close/只读 #226 | 主要检查章节无版本/正文“待确认”；阶段适用文档、批准快照、验证过期、N/A和旧确认缺失 | 完整目标 U10；本稿 U8 衔接 |
+| 团队存储/执行/运维：G16/N1-N5 | PG方言 #224、迁移 #242、sandbox #244、备份发布/长驻工具 #248；Dev存储组合#446于收尾已合入 | dev实际使用档位未核；RDM多实例租约/恢复、容量、故障/回滚验收未签收；复用Dev已交付存储能力 | 完整目标 U13/U14；衔接存储/恢复总案 |
+| 自举/完整交付：UR-19；G4 | U14台账骨架 #246 | R1-R15与九层验证仍NOT_RUN，不能由局部merge宣称“系统完成” | 本稿 U8；完整目标 U14 |
+| 飞书/变更/遗留扩展：UR-20/31/32；G1/G14/G15/D4/F-01-F-10 | 目标和依赖有记录 | 飞书、完整变更引擎、细粒度分享、权重、代码集成、遗留决策、难度机制仍后续；后移不等于取消 | 完整目标 U15；F-06→U9/U14，F-09→U11/U14，F-10待用户标准模板 |
+
+覆盖口径：SR 分组 A5/B12/C8/D11/E6/F5/G16/N5，共68；UR34、F10的逐条定位见附录。项目能力、实际UI、工具路径、部署与验收应各列证据，避免一个“完成”字段盖住五种状态。
+
+### 已静态确认的执行端问题
+
+| 问题 | 固定源码定位 | 必要修正 |
+|---|---|---|
+| 审签接口无可成功参数组合 | RDM `plugin.go:500-501,509-510,518-519` 强制 reviewer/actor/approver；`:1461-1462,1488-1489,1515-1516` 拒绝这些字段；Backend `cmdbus.go:384-402` 检查required | schema删除身份输入，只认认证actor，项目/固定提交对象必需；补真实总线和HTTP测试 |
+| 新旧成员命令绕过不同约束 | RDM `projects_api.go:317-380` 新路径不查member.manage上限；`plugin.go:2212-2245` 旧路径直接Remove；`members.go:54-59` UPSERT可降级最后owner | 所有入口共用服务，原子保持最后owner、归档状态、账号有效性与上限 |
+| 配置的建项权限未作用于创建 | RDM `plugin.go:2041-2054` 仅检Actor非空，ActProjectCreate没有接入 | 按专业角色有效权限判建项，不能一律管理员限定或一律认证即可 |
+| doc.write不等于编制职责 | RDM `plugin.go:2510-2536,2581-2588` 仅通用写动作；`doctree.go:152-168` 仅状态守卫 | 所有生成/编辑/采纳/改来源写入口再查本文档编制职责 |
+| 阶段只读约束未接业务读面 | RDM `perms_api.go:80-100` AuthorizeDocRead生产路径未消费 | 列表、详情、搜索、导出、Host及恢复统一资源授权 |
+| 角色/上限模型维度不足 | RDM `perms.go:42-55,70-94,310-324` 固定默认，cap主键仅action | 持久专业role的默认/上限，解释有效权限，不只在UI加checkbox |
+| 审核人不能驳回，职责可换人继承旧审核 | RDM `review.go:243-245,276-279` 读当前职责，ReviewCard未冻完整职责；`:111-119,141-149` 可覆盖职责 | 冻结整文提交的职责/策略版本；改职责使受影响审核失效；审核人可驳回，编制撤回独立 |
+| 草稿列表未按个人/文档资格过滤 | RDM `draftproposal.go:135-150` 无actor；`plugin.go:2567-2578` 仅doc.read | 私人提案按owner；受控文档按职责/明确授权；分页/计数同样过滤 |
+
+上述为源码确定或静态路径推导，没有在真实账号下重跑。现有 `plugins/rdm/three_sig_test.go:18-25,73-75` 构造Actor并直接调handler，未走登录和总线。函数名“RealAccounts”不能提升为真实账号验收。
+
+## Planning Contract
+
+### KTD1. 组合产物与正式入口
+
+推荐 RDM 产品用固定 pins 的 React 前端与 RDM Go 组合二进制形成正式产物，复用 Backend embed 的公开构建机制。RDM构建必须构建frontend→装入backend/web/dist→Go编译；不能只升级gitlink。构建在独立物化目录完成：从固定pins复制/物化基座组件，以Frontend既有frontend/ui邻接布局构建，将dist写入该目录中的Backend，再由隔离构建映射消费；RDM仓的pins检出保持只读，不把产物或源码修补写进pins。发布清单记录 RDM/backend/frontend/ui SHA、dist摘要、二进制摘要和能力契约版本。构建/安装阶段拒绝声明“完整Web产品”但缺index/bundle的产物。
+
+独立 `RDM:web/` 留作历史诊断入口，退出正式产品唯一流程，迁移前明确旧链接兼容和私有访问策略。若用户选择独立静态React+API部署，则同样固定双产物清单、同源反代与认证；这是部署形态备选，不能复用旧斜杠工作台宣称正式管理界面已完成。
+
+### KTD2. 一套执行端授权及项目身份
+
+账号、认证、平台管理员和通用资源执行边界由基座维护；研发项目/成员、专业角色、领域动作、职责与文档状态由 RDM 维护。公开扩展不足时沿 RDM 的四要素扩展申请，禁止导入基座internal或修改pins源码。
+
+新旧命令、UI、工具、后台恢复都调用同一 RDM 应用服务。平台账号目录只提供授权管理所需的最小公开身份/有效状态与分页，不提供私聊/原件；`AdminProvider.IsAdmin` 已有，不能再当缺失能力重建。创建者、当前owner、RDM域管理员、平台管理员各保留来源，审计能力不自动升级成绑定/成员写权。RDM项目创建与初始负责人必须同事务；Host映射检查双方资格并可恢复重试，不能以复制个人项目解决共享身份。
+
+现有公开EXT-8仅接主体和projectId，HTTP自有工件命中不咨询回调，共享列表按整项目放行；因此本稿U9先提供通用资源级公开授权契约及消费接线。可信资源类型/ID、资源属主、项目和动作由执行端解析，RDM只作领域判定；注册新策略后，域内自有/共享读取、列表、检索、Host及下载均执行同一判定，不能仅在RDM命令handler加守卫。未注册的普通基座保持既有行为；RDM受控产品若缺必要契约，禁止启用扩大共享读取的旧回退。衔接已有协作存储KTD13动作授权，复用当前内部项目动作槽，补资源维度及公开注册，而非再造平行授权器。
+
+读路径不修复业务数据。授权检查覆盖每个请求与资源，未知身份/关键能力默认拒绝；这与现有规范及 [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) 一致。本文更细的项目和职责规则来自已批准需求。
+
+### KTD3. 专业角色与矩阵
+
+区分四个对象：平台管理身份、项目管理关系、专业角色、文档职责。用户界面的 ADMIN/USER、成员表的owner/member以及文档三权不是专业角色CRUD。
+
+专业角色在系统范围建定义，保存稳定roleId、名称、停用状态、版本、动作默认、动作上限及账号关联。owner/member继续表示项目关系，roleId不写入members.role字段。管理员设置每角色上限；负责人只在许可的成员/项目范围覆盖。首版每账号一个生效专业角色，避免未经确认采用多角色叠加；未来多角色规则另行评审。
+
+有效权限在服务端计算：平台硬禁止 ∩ 角色上限 ∩（项目显式覆盖或角色默认）∩ 资源关系/阶段/状态/职责。文档签字资格还要求当前有效成员、已分配职责、互异历史、固定提交轮次；指派职责本身不解除上限。矩阵显示最终结果和第一拒绝原因，UI不重新计算。
+
+旧cap转换为同等限制，固定默认映射到兼容内置角色，旧override不被扩大。变更前干跑列出有效权限差异；同级迁移不得扩大有效权限。新角色或权限新授予由有权管理员明确执行。新增schema迁移需向前迁移及恢复方案，不能把旧二进制直接启动在不兼容新库上。
+
+### KTD4. 整文三权与历史保全
+
+一份受控文档对应一组编制/审核/批准。项目设置提供文档清单与批量分配入口；项目默认职责规则如需提供，须单独定义生效/覆盖语义，不能悄悄把成员的通用角色当所有文档职责。章节可分配贡献工作，正式整文签字不采用章节覆盖改变整文责任。
+
+整文提交冻结：文档ID、有序章节集合及版本、整文内容、模板版本、依据快照、编制/全体审核/批准人、职责版本、策略版本、提交轮次和完整内容摘要。现有整文内容快照可复用，需补这些治理字段并绑定审批、历史和导出。未知事件版本或不可还原必须报错。
+
+签字取可信actor，HTTP不能传reviewer/approver替代主体。智能体可以准备正文、修改提案、批注建议和待提交操作；人的审核/批准须由该人的认证会话确认，模型无自动签字权。审核人可批注/通过/驳回但不改正文；编制撤回单列。职责变更、撤成员、改正文/依据/模板使受影响待审结果失效，不能换职责让原作者自审同一提交。已批准历史保留，下一正式版本重新审签。
+
+旧章节审签作为历史证据保全，不聚合成“整文已批准”；迁移时对活动轮次作显式处理，首个整文版本重新签署。没有明确规则时暂停有关旧轮次，不静默迁移票据。
+
+### KTD5. 现有界面与对话接线
+
+沿三栏：左侧项目/会话，中间对话，右侧工作/文件。系统管理新增“角色”“权限”；现有项目设置新增“成员”“项目权限”“文档职责”；文档预览/工作卡提供“编制、审核、批准”状态及动作。审计仍用四入口并补受控链/矩阵；不新增独立控制台或第二预览。
+
+项目设置读取 `canManageMembers/canConfigurePermissions/canAssignDuties` 等实际能力，普通成员可读自身资格但不可管理。系统角色、账号全局专业角色关联和全局上限由平台有权管理员配置；项目成员页显示该关联并管理项目成员关系，不授予创建者修改账号全局专业角色的权限。RDM域管理员的业务管理范围保留，是否可改平台上限不从审计兜底权限推断。矩阵分“角色×动作”和“项目成员×动作”，职责清单则“文档×编制/审核/批准”，避免一个表混淆三种对象。
+
+所有页面共享单一能力状态所有者；七命令门控同时约束工作区、声明管理分区和已挂载页面。退出登录、切项目、能力撤销应作废旧结果。请求generation/seq处理快速对象切换与历史查询；计数缺失显示“未提供”，失败不显示空数据。401/403、能力缺失、参数/状态冲突、服务失败分别呈现并保留原receipt。
+
+对话和工具投影使用原子领域动作、真实project上下文及typed CommandResult；高危命令带conversationId和确认卡上下文。自然语言解析出的用户/项目名称仅作查找候选，最终使用稳定ID并校验。不把手写斜杠或登记handler当自然语言能力已就位。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart LR
+  UI[系统管理 / 项目设置 / 文档工作区] --> C[同源命令与确认回道]
+  Chat[对话 / 工具 / 工作卡] --> C
+  C --> I[基座可信身份与当前项目]
+  I --> A[RDM统一动作与资源授权]
+  A --> P[项目 / 成员 / 专业角色策略]
+  A --> D[文档职责 / 整文提交 / 审签]
+  D --> E[原子事件 / 正式快照]
+  P --> E
+  E --> R[审计 / 历史 / 合规 / 导出读面]
+  R --> A
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> 等待分配
+  等待分配 --> 编制中: 指派有效三权
+  编制中 --> 审核中: 编制人提交整文快照
+  审核中 --> 待批准: 所有审核人通过
+  审核中 --> 编制中: 驳回 / 撤回 / 快照失效
+  待批准 --> 编制中: 驳回 / 撤回 / 快照失效
+  待批准 --> 已批准: 指定批准人确认
+  已批准 --> 编制中: 新内部修订
+```
+
+```mermaid
+sequenceDiagram
+  actor Creator as 创建者
+  actor Writer as 编制人
+  actor Reviewer as 审核人
+  actor Approver as 批准人
+  participant Service as 统一文档服务
+  Creator->>Service: 分配有效成员及职责
+  Writer->>Service: 提交固定整文 / 版本 / 职责 / 策略
+  Reviewer->>Service: 认证身份审核同一提交轮次
+  Service->>Service: 校验全部审核及当前授权
+  Approver->>Service: 认证身份批准该提交
+  Service-->>Writer: 正式版本与固定快照导出
+```
+
+## Implementation Units
+
+本稿U1-U9为整改任务包，按依赖安排；不同于既有方案U号。U9为审阅补入的公开契约前置，编号不重排。责任角色为后续立项时指定的Dev组合owner、RDM实施者、Frontend实施者和独立审阅者。本轮不代指具体执行人。工作量是待排期的估计区间，不是工期承诺，项目数据量/迁移规模核定后更新。
+
+| 本稿工作包 | 依赖 | 优先级 | 交付内容 | 粗估工作量 | 对应完整目标总案 |
+|---|---|---|---|---|---|
+| U1 | 无 | P0 | 正式产物/根页/审计入口与实例证据 | 2-4人日 | U4/U11/U14及追溯展示补闭环 |
+| U9 | 无；与U1并行 | P0 | 公开资源/账号/宿主资格契约及基座消费接线 | 4-7人日 | X1/X2、U2/U3及存储KTD13 |
+| U2 | U9发版与RDM升pins；schema局部修正可提前 | P0 | schema、统一执行端与私域安全收口 | 3-5人日 | U2/U3/U8 |
+| U3 | U2；账号目录扩展 | P0 | 项目成员/唯一身份/有效账号闭环 | 3-5人日 | U2 |
+| U4 | U2/U3 | P0 | 专业角色与解释矩阵 | 4-7人日 | U3 |
+| U5 | U2/U3/U4 | P0 | 整文三权与批准快照 | 6-10人日 | U3/U8 |
+| U6 | U3/U4；职责页依赖U5 | P0 | 系统/项目管理页面 | 4-6人日，可与服务契约后并行 | U2/U3/U8 |
+| U7 | U5/U6 | P0 | 对话/卡片、审计完善、真实用户闭环 | 4-7人日 | U8/U9/U11/U14 |
+| U8 | 对应已有基础及U7 | P1并保持既定需求优先级 | 全系统余量、模板/法规/阶段/团队验收 | 各子任务另估 | U5-U16 |
+
+### U1. 固定产品组合并恢复审计正式入口
+
+**Requirements：** R1/R7；**责任：** Dev组合owner＋RDM构建owner。**Files：** RDM `Makefile`、`scripts/pack-release.sh`；Dev `scripts/svc.sh`、`modules/backend/web/embed.go`（复用机制）、Frontend `src/store.ts`、`src/workspaces.ts`、`src/components/AdminZone.tsx`、`src/components/RdmAuditWorkspace.tsx`、`src/rdmErrors.ts`。
+
+**Approach：** 先基于现有实例历史保留故障证据，固定RDM+四pins+实际bundle+二进制和数据绑定。补 pinned React embed构建与产物完整检查；统一全部入口能力门控、可见失败和错误分类。插件必要注册失败不能静默声明完整产品可用，可让启动拒绝或标为不可用，但不可留下可点击的半套管理面。正式环境切换需批准，备份和恢复与已有svc方案衔接。
+
+**Tests：** 扩展 Frontend `test/workspaces.test.ts`、`test/rdm-errors.test.ts`、`e2e/plain-base.playwright.ts`、`e2e/rdm-audit.playwright.ts`；Backend `internal/app/compiled_list_test.go`、`internal/server/compiled_list_test.go`；新增RDM `scripts/rdm-product-smoke.sh`（拟建），验证实际产物而非Vite预览。
+
+- 基座无RDM、只注册部分、命令disabled、声明分区残留：均不自动发失败审计请求；已开页面能转不可用态。
+- 构建后真实根页200及JS/CSS匹配固定frontend SHA；缺dist拒绝作为完整Web安装；清洁重构建不能借旧dist成功。
+- 有效登录后dev命令清单及capabilities成功；创建者/域管理员/纯平台管理员分别查询各自可审计范围；外部账号拒绝。
+- 403权限拒绝与401过期文案不同；query失败保留reason；密码form警告独立回归。
+
+**完成条件：** 实际8788及FRP入口能加载同一批准产物并查询有数据项目；没有以9015对照或health代替。工作树和CI的验证身份仍按SELF/GATE/REPLAY区分。
+
+### U2. 修复命令契约并统一授权服务
+
+**Requirements：** R2/R4/R6/R7/R8；**依赖：** U9的公开契约、基座发布和RDM升pins，schema修正可先独立交付。**责任：** RDM实施者，公开扩展由Dev责任人承接。**Files：** RDM `plugins/rdm/plugin.go`、`internal/rdmapp/perms_api.go`、`projects_api.go`、`draft.go`、`draftproposal.go`、`internal/domain/doctree.go`、`review.go`；Dev公开契约与执行端消费者按U9先交付。
+
+**Approach：** 先写真实注册总线/HTTP用例捕获schema身份矛盾，删除客户端签字身份字段。梳理全部命令、工具、上传、下载、Host和恢复路径；新旧成员命令兼容别名调用同一服务。统一动作+资源+状态守卫，归档/结项禁止新业务写；草稿列表及聚合计数按可见性过滤。合法用户职责可读文档，不错误要求全项目审计权。
+
+**Tests：** RDM `plugins/rdm/three_sig_test.go`、`internal/rdmapp/perms_test.go`、`resource_authz_test.go`；新增 `plugins/rdm/command_bus_contract_test.go`（拟建，消费公开extension启动/注册路径，不导入Backend internal）。
+
+- 不提供身份字段的合法approve/reject/final能通过schema；伪造字段、空project、错对象所属项目拒绝。
+- 各别名在禁member.manage、归档、最后owner更新/移除时结果一致；并发变动不移除最后owner。
+- reviewer/approver/普通成员/管理员无编制职责时各内容写入口拒绝；指定编制且动作上限允许时可写。
+- 禁阶段、私有草稿/原件、撤权后的旧卡/任务/下载均拒绝；过滤后的分页/计数不泄漏。
+
+**完成条件：** 建立入口×动作×身份×资源矩阵，直接handler单测之外有真实总线/HTTP正负例。
+
+### U3. 项目成员与可信账号目录
+
+**Requirements：** R2/R5；**依赖：** U2。**Files：** RDM `internal/members/members.go`、`internal/rdmapp/projects_api.go`、`plugins/rdm/plugin.go`；Dev公开身份/账号目录扩展申请与相应Host实现；Frontend `src/api.ts`。
+
+**Approach：** 研发项目和初始owner原子写，Host一对一映射双方授权核对。有权管理者分页查找最小有效账号，添加/调整/移除均按权限及生命周期；创建者事实保持不可改，owner变动不伪造创建者。幂等请求记录稳定operationId及策略版本，成功后加入账号看到同一项目并新建私有会话。
+
+**Tests：** RDM `internal/members/members_test.go`、`internal/rdmapp/sysproj_test.go`；基座账号/Host扩展新增契约测试（路径立项时固定）。
+
+- 非有效账号/停用账号不能加；非管理者查不到全系统用户目录；搜索和分页只返回必要字段。
+- 双用户同名建项、owner写失败、Host绑定失败/恢复、绑定他人宿主项目均不留下可用的错误项目。
+- 最后owner改为member、旧命令强制member、并发移除均守不变量。
+- 加入→同ID可见→私有对话；移除→现有会话/模型读取/导出立即受限，历史操作保留。
+
+**完成条件：** 真账号项目生命周期闭环，身份目录、领域项目与宿主映射有固定公开契约。
+
+### U4. 专业角色与可解释权限矩阵
+
+**Requirements：** R3/R4；**依赖：** U2/U3。**Files：** RDM `internal/perms/perms.go`、`internal/rdmapp/perms_api.go`、`plugins/rdm/plugin.go`；拟新增 `internal/perms/roles.go`、角色/关联迁移及解释DTO。Frontend渲染由U6承接。
+
+**Approach：** 按KTD3建持久专业角色、版本及账号关联；角色CRUD、默认/上限更新、项目覆盖、解释读面都调用统一evaluator。平台管理员信任来源经Host，不接受param.isAdmin。矩阵查询按管理范围过滤，返回动作目录、默认、上限、覆盖、有效值及来源/拒绝原因，资格变化使旧许可立即失效。
+
+**Tests：** 扩展RDM `internal/rdmapp/perms_test.go`；拟新增 `internal/perms/roles_test.go`、`plugins/rdm/roles_contract_test.go`。
+
+- 创建自定义角色、关联账号、修改/停用/重启，结果持久且内置系统身份不可经角色CRUD伪造。
+- default允许+cap禁止+override允许仍拒绝；撤上限后旧override即时失效；负责人不能改全局角色上限。
+- 矩阵解释与实际业务调用逐动作一致，doc.read与audit.read、assign与approve不混用。
+- 旧数据迁移干跑和故障回滚、停用角色仍有引用的处理、同版本并发编辑冲突可见。
+
+**完成条件：** 角色能实际创建并影响执行，不是仅显示固定三个标签；矩阵不靠浏览器推算。
+
+### U5. 固定整文三权与正式版本
+
+**Requirements：** R5/R6/R7；**依赖：** U2/U3/U4。**Files：** RDM `internal/domain/review.go`、`doctree.go`、`eventlog.go`、`replay.go`、`internal/rdmapp/draftproposal.go`、`review`应用服务、`docx.go`、`plugins/rdm/plugin.go`；拟新增整文submission及annotations实体/迁移。
+
+**Approach：** 复用持久提案与整文快照，补KTD4冻结字段、轮次、事件与审批状态。提交/批注/通过/驳回/撤回/批准共用固定提交对象，数据与事件同事务。无职责等待可见；分配时查当前账号、项目、动作资格和互异。批准读/导出固定快照，不从current章节拼装。
+
+**Tests：** `internal/domain/review_test.go`、`internal/rdmapp/docduties_test.go`、`plugins/rdm/three_sig_test.go`、现有提案/重放/导出测试；拟新增 `internal/domain/document_submission_test.go`。
+
+- 至少三份独立账号：作者提交、多审核缺一拒批、审核驳回、批准批注及批准；作者/管理者代审拒绝。
+- 改正文/依据/模板/职责、撤成员、换批准人使受影响旧票失效；换名字/职责不能洗掉原作者历史。
+- 章节贡献分配不改变整文签字人；旧章节PASS不聚合为整文PASS；旧活动轮次迁移有显式结果。
+- 旧卡签新版本、并发审签、重复提交、事件写失败、重启恢复、未知schema及历史水位查询均有可判定结果。
+- 正式DOCX及合规导出与批准正文/模板/来源/职责摘要一致，新内部修订保留旧正式版。
+
+**完成条件：** 整文状态机及三个真实身份完整签署，管理权和签字权分离，全部写入入口遵守编制职责。
+
+### U6. 补齐系统管理与创建者项目设置
+
+**Requirements：** R2-R6；**依赖：** U3/U4；文档职责依赖U5。**Files：** Frontend `src/components/AdminZone.tsx`、`adminSections.tsx`、`ProjectSettingsModal.tsx`、`TaskSidebar.tsx`、`src/api.ts`、`src/store.ts`；复用UI `src/SettingsShell.tsx`；拟新增RdmRolesSection/RdmPermissionMatrix/RdmMembersSection/RdmDutiesSection组件。
+
+**Approach：** 使用现有入口和SettingsShell。角色表支持创建/修改/停用；系统矩阵支持默认/上限解释；项目成员页支持账号选择及角色关联；项目矩阵只允许上限内override；文档职责页列文档状态、编制/审核/批准与资格不足原因。未分配不伪装有流程。异步对象单一所有者；全部样式和折叠按DESIGN令牌/原语。
+
+**Tests：** 扩展Frontend `test/workspaces.test.ts`及相关组件测试；拟新增 `test/rdm-management.test.tsx`、`e2e/rdm-management.playwright.ts`；执行Frontend/UI design-guard与必要构建。
+
+- 纯创建者而非管理员能看到并完成项目管理；普通成员不可配置；平台角色管理入口与领域项目管理按实际能力展示。
+- 角色创建→系统矩阵→成员添加→项目覆盖→职责分配，刷新/重启保留且readback来自服务端。
+- 同名账号、停用账号、空清单、服务器拒绝、409并发、断网未知结果时有明确状态，不乐观写成成功。
+- 禁止上限勾选不能通过手造请求保存；所有异步取消/切项目/撤权状态一致；键盘、对比度及主题可用。
+
+**完成条件：** 用户指出的四项缺失功能均在既有入口可操作，服务端同一规则强制执行。
+
+### U7. 对话、审签工作卡与审计读面
+
+**Requirements：** R1/R6/R7/R8；**依赖：** U5/U6。**Files：** RDM `plugins/rdm/plugin.go`、意图/工具声明、`internal/rdmapp/inspection.go`、卡片/任务接线；Frontend `src/api.ts`、`src/components/RdmAuditWorkspace.tsx`、工作卡组件。
+
+**Approach：** 将已有原子命令公开为合法工具/意图，带真实当前项目和确认上下文；读状态和写动作同对象。模型只准备签字，用户认证确认执行。审计页补完整分页、另一端关系判定、不可还原/未提供状态、generation处理。Host审计覆盖和领域事件区分，补真实四链/矩阵、导出进度与下载，而不声称当前四页签已覆盖全部合规展示。
+
+**Tests：** Frontend `e2e/rdm-audit.playwright.ts`及管理e2e；RDM `plugins/rdm/intents_test.go`、`internal/rdmapp/u3_inspection_test.go`、导出/任务测试；新增真实对话与审核/批准卡回道用例。
+
+- 按钮和对话完成同一成员/职责对象，返回同operationId归因；工具传Actor、伪造project或旧卡均拒绝。
+- 右栏关闭仍可读取状态并完成允许的用户确认；真实审核与批准始终属于相应人的认证会话。
+- 快速对象A→B、项目切换、不同历史seq并发、撤权事件与迟到响应，不显示旧对象或旧权限正文。
+- 数据多于首屏能分页，读失败与空数据分开，缺count非零；关联另一端正确；事件水位与正式快照一致。
+- dev+FRP真实入口完成角色→成员→职责→整文审签→追溯→固定导出，账号不能全都兼管理员。
+
+**完成条件：** 用户可见完整首批业务链和负例有真实账号、浏览器、固定制品证据；局部单测不是替代。
+
+### U8. 回填全系统矩阵并推进剩余能力
+
+**Requirements：** 全部原UR/SR/F；**依赖：** 按完整目标总案，不新增平行编号权威。**Files：** RDM `docs/records/2026-10-11-requirements-evidence-matrix.md`、`2026-10-12-final-acceptance-ledger.md`、`docs/requirements/10-实施推进方案-基座与下游二次开发.md`；Documents完整目标/模板/追溯/存储/恢复方案入口。
+
+**Approach：** 保存旧快照和真实收据，新增当前SHA实现/剩余/部署/验收列。优先以下切片，逐包立项和评审：
+
+1. 完整目标U9：slow持久project/owner/输入版本与授权恢复；取消、状态读取和卡片同源，先补恢复可信项目断点。
+2. U5/U6/U12：完整格式解析与锚点、发布补偿、共享检索、两层结论裁决；复用#236真实抓取，真实法规双通道为竞品模板前置。
+3. U7/U8/U16：首批建议书/竞品分析真实闭环后扩展所有69模板及报价XLSX，逐类登记模板内容/格式版本与验收。catalog不能结项。
+4. U11/U10：真实需求/风险/措施/验证生产与四链，阶段适用文档/批准/合规/过期门禁，固定对象推进及结项。
+5. U13/U14：复用Dev存储/恢复在途任务，领域PG/多实例租约与故障恢复、容量、迁移及发布包，最终九层验证和用户上线签收。
+6. U15：F-01到F-10保留owner/依赖/状态；F-06/F-09已纳入当前链，F-10待用户标准模板，不隐式取消后续目标。
+
+**Tests：** 延用各总案列出的直接测试，并落实 `make test`/`make build`、发布制品实测、需求到收据映射。每个子任务立项时冻结样本、数据档位、具体命令和验收环境；上述远期任务不以本稿粗粒度条目直接启动未授权实验。
+
+**完成条件：** 112条都有当前对象与证据状态、责任包；已合入局部能力不会重复重建，旧过期缺口不继续冒充现状。所有最终需求仅在真实证据或用户明确取消/替代裁定后闭合。
+
+### U9. 先交付通用公开授权和身份契约
+
+**Requirements：** R2/R4/R5/R7/R8；**依赖：** 无，可与U1并行。**责任：** Dev Backend公开扩展owner；RDM提出/验收契约。**Files：** Dev Backend `pkg/extension/extension.go`、`pkg/extension/host.go`、`internal/app/compiled.go`、`hostcaps.go`、`internal/server/server.go`、`internal/store/content.go`及相应资源/共享检索授权测试；Documents沿既有扩展申请主记录补四要素。RDM消费发布tag并更新pins，不在pins内改代码。
+
+**Approach：** 契约输入包括认证主体、动作、资源类型/ID、真实资源属主和项目，字段从受信存储/执行上下文生成，不能接受body自报资源归属。资源策略安装后对RDM域内所有访问权威，包括owner自有命中和共享读取；列表/统计/检索候选逐项过滤，SSE/下载/模型上下文注入在当前权限下重验。角色/职责/原件可见性仍由RDM判定，基座不硬编码RDM状态机。兼容使用可选注册能力与版本声明，旧普通基座行为保持；RDM缺该必需能力时停止共享启用而非整项目回退。
+
+同包冻结最小账号目录及宿主项目资格读面：授权项目管理者只获得可选账号的稳定身份/有效态，不获得完整系统用户管理权限；Host项目查验包含存在性、当前主体管理/绑定资格和实例域。复用已存在AdminProvider、项目共享/会话公开扩展，只补缺少字段与检查。
+
+交付顺序为扩展申请评审→基座实现与提供者/消费者契约验证→基座发版→RDM升pins/公开能力检查→U2/U3消费；发版按仓库人工双钥匙，由用户执行。本轮不创建发布或迁移。下游只使用公开符号，真实命令总线测试走公开启动/注册与HTTP，不跨internal边界。
+
+**Tests：** 扩展Backend `internal/server/resource_authz_test.go`、`internal/app/compiled_authz_test.go`及Host/检索测试；RDM新增公开契约消费测试，衔接U2真实HTTP负例。
+
+- 同一项目中A私有原件和B获授权文档，列表/详情/内容/下载/搜索/摘要/模型上下文仅返回获许可对象，私域owner自有命中也不绕过受控文档职责。
+- 撤销角色、成员、分享后旧任务及已开流在新输出/使用边界重验；拒绝/错误/未知资源元数据不变成放行，私聊始终owner隔离。
+- 假projectId、假资源属主、跨实例宿主ID、绑定他人项目均被执行端解析/资格检查拒绝。
+- 未注册时普通基座兼容；RDM旧公开契约缺失时明确拒启受控共享；提供者发版和消费者固定pins组合都有证据。
+
+**完成条件：** 不经RDM命令入口的HTTP/Host/检索也遵守同一资源策略，U2/U3可以在不修改基座internal或pins源码的前提下完成私域/项目绑定要求。
+
+## Verification Contract
+
+正式启动前处理共享锁的owner现场，在相应项目各自通过precheck、从权威main建立worktree和任务卡；不删除他人锁兜底。文档、源码、迁移、测试、部署各有授权范围。阶段内可迭代，跨阶段按Dev `policy/delivery.md` 人工评审，用户沉默不是授权。
+
+验证必须包含三层：模块/公开契约；真实注册总线+认证HTTP；固定正式产物+浏览器用户链。命令语义与服务端拒绝优先，不能用直接handler返回或一张页面截图替代。
+
+最小账号集：平台管理员、RDM域管理员、项目创建者/负责人、编制人、审核人（多审核时至少两人）、批准人、普通成员、外部用户。可以在不冲突场景复用账号，但审计兜底和三权签字用例必须拆开；两个独立项目和私有素材，禁止把所有账号均设管理员让负例失效。
+
+| 层级 | 计划检查 | 判定 |
+|---|---|---|
+| 规范/门禁 | 启动precheck、验收/审核/合入各task-sync、共享写入owner核对 | 同步对象和任务范围有收据；本轮共享BUSY不掩盖 |
+| RDM | `make test`；真实cmdbus/HTTP契约；角色/成员/整文事务及回放 | 选中用例且全部必要正负例有输出，非零用例或SKIP不算PASS |
+| Dev组合 | `make test`+`make build`，检查精确pins和被测工作树 | CI PR HEAD为GATE；本地仅SELF；公开扩展兼容及组合构建均核实 |
+| UI | design-guard、相关组件、实际固定产物的管理/审计/三权浏览器流程 | 有用户动作及可见结果；不能只跑Vite测试而遗漏embed产物 |
+| 部署 | 固定dev制品、manifest、数据身份、同源/FRP入口、登录及七命令 | 新旧时点分开；根页200与有数据查询；启动健康不替代业务验收 |
+| 持久/故障 | 并发成员/签字、撤权、断连未知结果、事件失败、重启/备份恢复 | 无越权或半事务，操作有可对账身份；真实DB档位与恢复对象明确 |
+| 审核 | 独立审阅者先重放最小集，再读作者SELF；核对CI身份/链接/SHA | 本稿Agent审阅不代替正式REPLAY/GATE、人审和上线签收 |
+
+完成声明的precheck/task-sync/测试三段输出由evidence写入任务卡；产出物引用任务卡/原收据。本轮仅保存调查与precheck收据，不补写业务测试输出。业务测试、真实模型、迁移、重启、部署、当前登录态审计验收均NOT_RUN。
+
+## Definition of Done
+
+本稿交付：矩阵覆盖全部原需求、故障因果链有固定对象/运行历史、五个问题分别定位到已有与缺口、方案有依赖/模块/测试/验收/兼容及停止条件，报告可审阅并保存。没有要求或宣称此轮实施。
+
+首批整改验收：在实际dev及FRP入口，管理员建角色/配置上限，创建者管理成员/覆盖项目权限/分配文档职责，真实三权完成整文审签，审计历史和导出一致；越权/撤权/旧卡/旧版本负例成立。源码、CI、组合、部署、用户验收分别签收。
+
+全系统C1：完整目标U1-U14及U16全部对应证据齐备；C2额外包含U15最终扩展或用户明确裁定，不把后续备案当已实现。新报告只记录当前差距，不修改旧收据或取消需求。
+
+停止条件：权威需求改变；必要公开扩展不兼容；实际制品/数据身份无法确定；迁移权限扩大或旧审签票迁移规则不明；跨出当前批准范围或共享写者未退出。先保存证据/现场，提交受影响设计评审，不以临时放宽权限继续。
+
+## 待人工评审与下一步
+
+建议优先批准**本稿U1：正式产品构建及审计实际入口**，U9公开契约并行；U2可先在隔离工作区建立schema失败用例，完整资源授权出口依赖U9发版/升pins。上述首批工作不依赖69模板全量完成。随后U3/U4固定服务契约，U5整文三权与U6页面接线按依赖并行，U7交付用户完整流程。
+
+需评审的新增技术选择：RDM组合二进制嵌入React正式入口；RDM专业角色首版单角色；旧cap/角色映射不扩大权限；整文签字替代章节级正式签字并保全历史。项目级批量职责默认若需要，另定义应用范围与显式覆盖，不把它作为此次分配每文档职责的隐藏前置。
+
+这些是待批准设计，不重问是否实现角色/成员/权限/三权。正式实施负责人、隔离测试环境和部署切换窗口在批准启动时登记。此次独立报告入仓仍待共享门禁解除，未创建提交或PR。
+
+## Appendix
+
+随附文件 `source-runtime-receipt.json` 为make evidence原始调查收据，`precheck-receipt.json` 为启动拒绝收据；`readonly-probe.py` 为可复核只读命令脚本。报告审阅记录另保留；同一次作者侧子代理检查仍为SELF。
+
+### 逐条需求定位与计划索引
+
+以下只携带现有权威矩阵ID、摘要与既有工作包，原文位置相对RDM `docs/requirements/01-用户需求与系统需求.md`。摘要可能被原矩阵截断，完整语义以原文为准。历史矩阵中的“源码状态”列不复制，当前实现/缺口以本稿功能域表及固定源码为准；每行运行结论均为NOT_RUN。
+
+| 原ID | 权威摘要 | 既有完整目标工作包 | 原文行 | 当前运行验收 |
+|---|---|---|---|---|
+| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传，对不支持格式仅提醒不阻断 | U5/U9/U14；G9/G10/G15 | 437 | NOT_RUN |
+| SR-A2 | 上传不强制附带文字指令；无指令时进入默认"记忆构建"流程（见 SR-B 系列），不输出制式化"未识别需求"回复 | U5/U9/U14；G9/G10/G15 | 438 | NOT_RUN |
+| SR-A3 | 支持单文件、多文件批量上传，并记录来源渠道（Web/飞书/其他）与上传人 | U5/U9/U14；G9/G10/G15 | 439 | NOT_RUN |
+| SR-A4 | 上传后 60 秒内输出第一阶段反馈（相关性结论 + 初步阶段归类）；完整入库允许后台异步完成 | U5/U9/U14；G9/G10/G15 | 440 | NOT_RUN |
+| SR-A5 | 入库完整性保障：解析失败、部分内容不可解析或入库异常时，必须显式告知用户并在入库记录中标记，原始文件永久保留可取回；禁止静默降级或静默产出残缺结果（教训来源：旧版曾发生报价单 Excel 数据丢失、P… | U5/U9/U14；G9/G10/G15 | 441 | NOT_RUN |
+| SR-B1 | 对每份上传资料输出相关性判定（相关 / 存疑 / 无关）及判定依据；存疑时必须挂起并向用户请求确认，确认前不入库 | U5/U6；G9/G10 | 447 | NOT_RUN |
+| SR-B2 | 对资料进行结构化解析，保留章节/页/表格级锚点，锚点在后续所有引用与追溯中可用 | U5/U6；G9/G10 | 448 | NOT_RUN |
+| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项"，映射结合项目当前所处阶段；支持一片段映射多阶段 | U5/U6；G9/G10 | 449 | NOT_RUN |
+| SR-B4 | 每个切片附带结构化标签（JSON）：阶段、工作事项、主题、可行性维度（技术/市场/注册）、关联需求 ID、来源、上传时间、置信度；并生成一句话描述（description） | U5/U6；G9/G10 | 450 | NOT_RUN |
+| SR-B5 | 支持"两速入库"：快速通道（打标签 + 摘要 + 入库）先行返回，慢速通道（细切片、嵌入向量化）后台补齐，状态对用户可见 | U5/U6；G9/G10 | 451 | NOT_RUN |
+| SR-B6 | 入库完成后向用户输出勾连总结：本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节，以显式清单呈现 | U5/U6；G9/G10 | 452 | NOT_RUN |
+| SR-B7 | 会议纪要类资料按同一管道处理，并可抽取"结论 / 待办 / 待确认"三类条目 | U5/U6；G9/G10 | 453 | NOT_RUN |
+| SR-B8 | 笔记树内一致性检测：同一主题簇下多个切片的陈述不一致（如多人表述冲突）时，系统检测冲突 + 记录入追溯网（何时/何人/何节点/何操作）+ 通知触发冲突的用户 + 挂起待裁决；智能体不自行处理冲突，裁决… | U4/U6；G11 | 454 | NOT_RUN |
+| SR-B9 | 并发更新冲突避免与及时提示：多人几乎同时更新同一树节点时，系统忠实记录全部操作入追溯网，冲突以候选子节点组并存挂起，智能体不自行处理冲突；裁决集中在编制人发起编制时经 HITL 完成（裁决两层，规则同… | U4/U6；G11 | 455 | NOT_RUN |
+| SR-B10 | 任务快慢双速：对用户任务按快慢双速模式执行——快通道同步短链路即时反馈（如上传文档→相关性判断→相关给概要/不相关给理由＋相似文档供选择），慢通道小队（subagent）后台深度执行（逐页解析、建节点… | U9/U13；G15 | 456 | NOT_RUN |
+| SR-B11 | 结论节点：结论作为笔记树的节点类型保存（结论入树）；结论节点与切片同受 08 R1–R5 硬规则约束（append-only、软删除、结构事件日志、可重建）；结论节点与其依据切片/来源的关联入追溯网。… | U6；G11 | 457 | NOT_RUN |
+| SR-B12 | 总结触发：何时生成阶段总结交模型自主判断（不设固定阈值）——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档（HITL 确认）；保留人工触发入口（用户明确指令触发）；上传后先快速摘要反馈、后… | U6；G11 | 458 | NOT_RUN |
+| SR-C1 | 内置可配置的研发体系文档树（阶段 → 文档 → 章节），每章有内容要求说明；文档树对应设计开发控制程序，商务对接与策划合并为同一阶段 | U7/U8/U16；G7/G8 | 464 | NOT_RUN |
+| SR-C2 | 体系文档模板集中注册、版本化管理；模板与阶段/文档节点的关联可配置，不与具体工作流实例硬绑定。模板策略：本期按当前已有模板设计与完善；标准模板待系统完成并通过测试后由用户补充（E-T3，后续目标 F-… | U7/U8/U16；G7/G8 | 465 | NOT_RUN |
+| SR-C3 | 文档生命周期状态机：草稿 → 评审中 → 已基线 →（变更中）→ 新版本基线；基线文档不可被直接修改 | U4/U8/U10；G6/G8/G17 | 466 | NOT_RUN |
+| SR-C4 | 新切片填充文档章节前，与该章节现有内容比对，输出三分类结论：新增 / 更新 / 冲突；更新与冲突均需用户确认后生效 | U4/U8/U10；G6/G8/G17 | 467 | NOT_RUN |
+| SR-C5 | 缺项分析仅在两种触发条件下输出：文档提交评审时、项目申请推进阶段时；上传节点禁止输出缺项提示 | U10/U11；G14 | 468 | NOT_RUN |
+| SR-C6 | 每次文档内容变化生成版本记录，可查看任意两版本差异及差异来源切片 | U4/U8/U10；G6/G8/G17 | 469 | NOT_RUN |
+| SR-C7 | 三权分立流程规则：编制/审核/批准三权异人（编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人）；编制发起唯一；审核/批准仅可批注与通过/驳回，不可修改正文或发起编写；提交审核即锁定；驳回回… | U3/U8；G6/G17 | 470 | NOT_RUN |
+| SR-C8 | 批准后修改的处理：本期路径＝撤回重审（D-12：撤回后修改并重新升版审批）＋影响提示（沿追溯网列出受影响范围给人看，不走流程，见 SR-D3）；松散管理取向，但审计链不断（08 R1/R2/R5 不动… | U3/U8；G6/G17 | 471 | NOT_RUN |
+| SR-D1 | 建立并持久化双向追溯网络：资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例；每条边记录类型、来源（人工/规则/模型候选）与置信度 | U11/U14；G12/G17 | 477 | NOT_RUN |
+| SR-D2 | 需求条目化管理：用户需求与系统需求大表，字段含状态（草稿/已评审/已基线）、版本、关联文档与法规；支持增删改与批量导入 | U11/U14；G12/G17 | 478 | NOT_RUN |
+| SR-D3 | 新内容入库触发变更检测：与已评审条目比对，不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示（V2.1 增补）：批准后修改或引用内容变化时，系统沿追溯网列出受影响范… | U6/U11；G11/G16 | 479 | NOT_RUN |
+| SR-D4 | 变更流程闭环（变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭，全程留痕）：整体后移，不作为本阶段系统实现目标——变更流程走公司内部管理流程，移入后续目标备案 F-02（《10… | U15/F-02；G14 | 480 | NOT_RUN |
+| SR-D5 | 任一需求可导出完整追溯链报告；无法匹配进体系的资料进入"待裁定"清单，提醒用户处理 | U11/U14；G12/G17 | 481 | NOT_RUN |
+| SR-D6 | 追溯主体扩展：追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片，保证所有信息细节的准确性与可追溯性 | U4/U8/U11；G8/G17 | 482 | NOT_RUN |
+| SR-D7 | 完整合规追溯模型（权威定义见 08 第十六章）：15 类受控节点（含危害/风险控制措施/设计确认/设计转换/变更）＋11 类合规边（两端=节点 ID@版本，模型仅候选、人工确认转正）＋四条链视图（13… | U11/U14；G12/G17 | 483 | NOT_RUN |
+| SR-D8 | 需求分类与分解框架：用户需求与性能需求分到不同文档；先确认用户需求再分解系统需求；系统需求按六维度分类（功能/交互/安全/运输包装/维护/合规）；智能体可从法规反推部分系统需求，但不完全依赖智能体；先… | U11/U14；G12/G17 | 487 | NOT_RUN |
+| SR-D9 | 风险登记册追溯：危害（HAZ）与风险控制措施（RCM）入网；每个 RCM 同时登记为需求并必须被验证（verifies 边）；每个危害至少被一项 RCM mitigate；措施-危害-验证三向可查（术… | U11/U14；G12/G17 | 484 | NOT_RUN |
+| SR-D10 | 验证结果绑定被测版本：VR 记录对应用例与被测对象版本；被测版本≠当前基线版本时系统报「验证过期」并列入缺口；设计确认（VAL）必须追溯到用户需求 | U11/U14；G12/G17 | 485 | NOT_RUN |
+| SR-D11 | SOUP 组件登记与追溯：软件组成项（含 SOUP）入网为架构项，其需求分配与验证沿用同一边模型 | U11/U14；G12/G17 | 486 | NOT_RUN |
+| SR-E1 | 意图识别分层：规则层（仅限整句完全匹配的高频确定性短指令）→ 语义层 → LLM 层；规则层不得单独触发高风险操作 | U2/U8/U9/U10；G1/G8/G14/G15 | 493 | NOT_RUN |
+| SR-E2 | 规则层命中必须通过上下文校验（上一轮存在对应的待确认事项）才可执行；无上下文时降级为普通对话 | U2/U8/U9/U10；G1/G8/G14/G15 | 494 | NOT_RUN |
+| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成，卡片明示操作对象与后果 | U2/U8/U9/U10；G1/G8/G14/G15 | 495 | NOT_RUN |
+| SR-E4 | 支持意图分类（查询 / 编写 / 命令 / 讨论）与意图切换识别；编写类意图需命中目标文档并确认后执行 | U2/U8/U9/U10；G1/G8/G14/G15 | 496 | NOT_RUN |
+| SR-E5 | 简单询问即时回答；复杂任务先给出执行计划与预计耗时，执行中提供进度反馈 | U2/U8/U9/U10；G1/G8/G14/G15 | 497 | NOT_RUN |
+| SR-E6 | 对话完备路径：从立项到结项的全部状态变更操作（创建项目、提交评审、批准变更、阶段推进、导出、结项等）均可通过对话指令驱动，页面/按钮不是任何步骤的唯一入口；高风险操作的对话路径终点为对话流内联确认卡（… | U2/U8/U9/U10；G1/G8/G14/G15 | 498 | NOT_RUN |
+| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行：骨架显式定义步骤序列与返回检查节点，角色在骨架内有限自主 | U8/U9/U13；G8/G15/G18 | 504 | NOT_RUN |
+| SR-F2 | 每个角色显式声明：职责、可用工具白名单、禁区；角色提示词作为受控资产版本化管理 | U8/U9/U13；G8/G15/G18 | 505 | NOT_RUN |
+| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道，结果附引用来源；冲突时以权威来源为准并提示 | U12；G13 | 506 | NOT_RUN |
+| SR-F4 | 长任务后台异步执行，进度可查询、完成有通知；不得阻塞对话主线程 | U8/U9/U13；G8/G15/G18 | 507 | NOT_RUN |
+| SR-F5 | 执行任务时自动组装上下文：项目当前状态、相关记忆切片、目标文档模板、近期对话；上下文构成可解释 | U8/U9/U13；G8/G15/G18 | 508 | NOT_RUN |
+| SR-G1 | 飞书集成：智能助手可加入群聊，支持群内对话、收文件、推送反馈与通知。本期不做飞书功能（J-11），本条与 UR-20 一并后移 → F-01 | U15/F-01；外部依赖 | 514 | NOT_RUN |
+| SR-G2 | 基于角色与项目阶段的权限控制（ABAC），阶段转换需满足准入准出条件并留痕。判定维度（角色 × 项目 × 阶段 × 动作）保留；权限主数据裁决（J-10，R2 关闭）：本期系统内建最小权限系统（管理员… | U2/U3；G3/G4 | 515 | NOT_RUN |
+| SR-G3 | 全量审计日志：上传、入库、更新、变更、确认、生成等动作均可审计 | U4/U11；G5/G17 | 516 | NOT_RUN |
+| SR-G4 | 系统以自身研发项目为首个运行实例（自举元项目），自身需求与体系文档由本系统管理 | U14；G19 | 517 | NOT_RUN |
+| SR-G5 | 结构追溯：笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值；删除一律软删除（tombstone）；追溯边有"候选 → 生效 → 废止"全生命周期；支… | U4/U11；G5/G17 | 518 | NOT_RUN |
+| SR-G6 | 系统管理员与系统级设置：全局唯一管理员拥有所有权限；仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数（工具调用轮数/工具权限等）、系统级插件管理、用户/角色的… | U2/U3；G3/G4 | 519 | NOT_RUN |
+| SR-G7 | 角色管理：角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人；角色可分配给用户（如项… | U2/U3；G3/G4 | 520 | NOT_RUN |
+| SR-G8 | 权限覆盖优先级——上限内覆盖（J-05，原存疑关闭）：管理员设定角色默认权限与权限范围上限（最底层约束）；项目负责人（创建者）在该范围内调整项目成员权限；项目内配置可覆盖角色默认配置，但不得突破管理员… | U2/U3；G3/G4 | 521 | NOT_RUN |
+| SR-G9 | 项目负责人权限：项目创建者即项目负责人，拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | U2/U3；G1/G2 | 522 | NOT_RUN |
+| SR-G10 | 项目唯一性与成员自动可见：同名项目全系统唯一；用户被添加为项目成员后，其界面自动出现该项目，并可直接开始项目工作（新建对话等） | U2/U3；G1/G2 | 523 | NOT_RUN |
+| SR-G11 | 对话隐私：用户之间的对话互相不可见，仅本人可见本人与智能体的对话；智能体会话/中间过程默认互不可见（J-06，原存疑关闭），协作全部经两树一网项目共享层；用户分享分层（整个项目/会话/部分会话）的精细… | U3/U5/U9；G4/G5/G10 | 524 | NOT_RUN |
+| SR-G12 | 文档分享：上传者可将文档分享给指定成员/部分成员/全部项目成员；被分享者只读、不可编辑；被分享文档进入接收者上下文，支撑其后续对话中查看并基于这些文档对话 | U3/U5/U9；G4/G5/G10 | 525 | NOT_RUN |
+| SR-G13 | 上下文时间权重：本期最小实现——检索与注入排序新内容优先；替换/冲突场景走 J-02 人裁决（SR-B8/SR-B9）。可配置时间权重衰减模型（权重数值、配置粒度）移入后续目标 F-04（J-07，优… | U5/U15/F-04；G10 | 526 | NOT_RUN |
+| SR-G14 | 飞书项目对接适配（接口层四项功能：产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接；飞书角色权限映射读取）：本期不做飞书功能，整条移入后续目标备案 F-01（J-11）；保留设计预留说… | U15/F-01；外部依赖 | 527 | NOT_RUN |
+| SR-G15 | 虚拟人账号（企业账号下为智能体创建固定账号持有文档/文件夹访问权限；授权范围、审批与定期审计流程待明确，《10》Q-04）：随飞书对接整体后移，移入后续目标备案 F-01（J-11） | U15/F-01；外部依赖 | 528 | NOT_RUN |
+| SR-G16 | 代码执行安全：多用户共享部署在隔离执行档就位前，以启动级硬关闭禁用执行原语（run_shell/run_python/register_artifact 及内核执行配置），用户设置不得覆盖（基座已交付… | U13；G18 | 529 | NOT_RUN |
+| SR-N1 | 性能：上传首轮反馈 < 60 秒；单文档完整入库（后台）< 10 分钟；追溯链查询 < 3 秒 | U14；G18/G19 | 535 | NOT_RUN |
+| SR-N2 | 可维护性：模块边界清晰、依赖单向；任一核心功能（如文档入库）可在 5 分钟内定位到对应代码模块；支撑每周代码审查机制 | U1/U14；G19 | 536 | NOT_RUN |
+| SR-N3 | 可解释性：每个入库、更新、变更动作给出依据（来源切片、命中标签、比对结果） | U4/U5/U8；G10/G17 | 537 | NOT_RUN |
+| SR-N4 | 部署与数据：支持本地化部署；法规知识库本地存储；项目数据按项目隔离 | U2/U3/U13；G5/G18 | 538 | NOT_RUN |
+| SR-N5 | 模型无关性：大模型通过抽象层接入，可替换（当前为 MiniMax，不绑定） | U9/U13；G8/G18 | 539 | NOT_RUN |
+| UR-01 | 自由上传 | U5/U9/U14 | 547 | NOT_RUN |
+| UR-02 | 相关性把关 | U5/U6 | 548 | NOT_RUN |
+| UR-03 | 自动归纳入库 | U5/U6/U9/U14 | 549 | NOT_RUN |
+| UR-04 | 及时反馈 | U2/U5/U6/U8/U9/U10/U13/U14 | 550 | NOT_RUN |
+| UR-05 | 渐进式清晰 | U4/U7/U8/U10/U16 | 551 | NOT_RUN |
+| UR-06 | 缺项提示时机 | U10/U11 | 552 | NOT_RUN |
+| UR-07 | 冲突与变更 | U4/U6/U8/U10/U11/U15 | 553 | NOT_RUN |
+| UR-08 | 严格可追溯 | U4/U5/U6/U8/U10/U11/U14 | 554 | NOT_RUN |
+| UR-09 | 需求条目化 | U6/U11/U14 | 555 | NOT_RUN |
+| UR-10 | 模糊澄清 | U2/U4/U5/U6/U8/U9/U10 | 556 | NOT_RUN |
+| UR-11 | 一键生成文档 | U2/U8/U9/U10/U13 | 557 | NOT_RUN |
+| UR-12 | 主动提问 | U2/U5/U6/U8/U9/U10 | 558 | NOT_RUN |
+| UR-13 | 外部查询入库 | U5/U6/U8/U9/U12/U13 | 559 | NOT_RUN |
+| UR-14 | 法规双通道 | U12 | 560 | NOT_RUN |
+| UR-15 | 商务策划贯通 | U7/U8/U16 | 561 | NOT_RUN |
+| UR-16 | 显式确认 | U2/U8/U9/U10 | 562 | NOT_RUN |
+| UR-17 | 阶段门禁权限 | U2/U3/U4/U11 | 563 | NOT_RUN |
+| UR-18 | 会议纳入记忆 | U5/U6 | 564 | NOT_RUN |
+| UR-19 | 自举 | U14 | 565 | NOT_RUN |
+| UR-20 | 协作平台接入 | U15 | 566 | NOT_RUN |
+| UR-21 | 系统角色与权限管理 | U2/U3 | 567 | NOT_RUN |
+| UR-22 | 项目成员与协作 | U2/U3 | 568 | NOT_RUN |
+| UR-23 | 文档分享与上下文注入 | U3/U5/U9/U15 | 569 | NOT_RUN |
+| UR-24 | 三权分立文档流程 | U3/U8 | 570 | NOT_RUN |
+| UR-25 | 版本全量保留与来源追溯 | U4/U8/U10/U11 | 571 | NOT_RUN |
+| UR-26 | 并发更新冲突避免与提示 | U4/U6 | 572 | NOT_RUN |
+| UR-27 | 快慢处理与任务拆解展示 | U9/U13 | 573 | NOT_RUN |
+| UR-28 | 简易看板 | U4/U6/U8/U10/U11 | 574 | NOT_RUN |
+| UR-29 | 难度分级与降级使用 | U8/U9/U13/U14/U15 | 575 | NOT_RUN |
+| UR-30 | 对抗验证机制 | U8/U9/U13/U14/U15 | 576 | NOT_RUN |
+| UR-31 | 飞书项目对接 | U15 | 577 | NOT_RUN |
+| UR-32 | 代码管理工具集成 | U15 | 578 | NOT_RUN |
+| UR-33 | 法规合规追溯 | U11/U14 | 579 | NOT_RUN |
+| UR-34 | 结论沉淀与阶段总结 | U6 | 580 | NOT_RUN |
+| F-01 | 飞书对接全套（渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联） | U15/F-01 | 643 | NOT_RUN |
+| F-02 | 变更流程引擎（七步闭环、变更单、完整影响分析） | U15/F-02 | 644 | NOT_RUN |
+| F-03 | 用户分享分层（整个项目/会话/部分会话）与智能体可见性的精细设计 | U15/F-03 | 645 | NOT_RUN |
+| F-04 | 可配置上下文时间权重衰减模型 | U15/F-04 | 646 | NOT_RUN |
+| F-05 | 代码管理工具集成（GitLab token 只读拉取、需求-版本-缺陷关联） | U15/F-05 | 647 | NOT_RUN |
+| F-06 | 看板与卡片流的界面统一（随原型 V2.3） | U9/U14 | 648 | NOT_RUN |
+| F-07 | 会议遗留问题组（Q-01/02/03/07/10/13/14 等，《12》问题 8 组）；其中 Q-02 经晚会部分裁决（C-03，见 §7.1） | U15/F-07 | 649 | NOT_RUN |
+| F-08 | 难度分级评估表与降级机制的落地细化（UR-29 保留 P1，实施细节备案） | U15/F-08 | 650 | NOT_RUN |
+| F-09 | 追溯网可视化（先功能后展示，暂缓） | U11/U14 | 651 | NOT_RUN |
+| F-10 | 标准模板替换：本期按当前已有模板设计与完善；待系统完成并通过测试后，由用户补充标准模板（取代晚会 T2「今晚下载官方模板替换」，不执行） | U16＋U15/F-10 | 652 | NOT_RUN |

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

@@ -7,10 +7,13 @@ execution: code
 product_contract_source: ce-plan-bootstrap
 ---
 
-# 服务重启与全量数据恢复方案 r2
+# 服务重启与全量数据恢复方案 r3
 
-确认状态：待人工评审。当前交付为源码调查、方案与实施/验收计划；业务实施、故障注入、部署、运行验收均为 NOT_RUN。
+确认状态：原 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 新增已于 2026-10-12 批准。
 需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。
 主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
 
@@ -34,20 +37,26 @@ product_contract_source: ce-plan-bootstrap
 
 ## 2. 当前事实及重点差距
 
-本次源码基线：Dev `5e57029b439e5690f28dc6002f9784f0b08920eb`；Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `aaced8796bb45d151833e12bc1cc17fc5090ef6d`；Documents `23e2276905eaf3d5b266a5218a53a12a38321284`。来源为 SELF·源码观察，原始命令和输出由 Dev `make evidence` 写入本任务卡；风险是源码推断，不是已重现事故。
+本轮源码基线：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（任务元数据提交）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。草案独立 Documents 基线 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，未推进 Dev gitlink。原 r2 对象为历史，不用于证明当前运行行为。
+来源为 SELF·只读观察；原始脱敏命令和运行输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。故障表现为源码推导，故障／恢复／耐久性验收 NOT_RUN。
+最终 Dev 同步基线 `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9` 已纳入主干的 svc 实例内存态修复和 Documents 指针 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`；Backend／Frontend 未变。旧 gitlink 是启动时点，本轮仅同步权威上游，未推进本轮草案组合或重复实现该修复。
 
 | 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
 |---|---|---|
-| 数据库绑定 | `scripts/svc.sh:1373` 已统一解析 dbref/DSN/config；裸启动、restart/deploy 停前预检已接入 | 自定义 data/plugins 在参数重建时可能漂移；临时环境配置无法保证下次存在；配置多次逐键更新有崩溃中间态 |
-| 服务生命周期 | svc 管理 agent/static/postgres；PostgreSQL 复用 pgdata；分发仓有单应用 systemd 模板 | svc 没有服务组依赖恢复与持久启动意图；无统一进程组监管；不管理 Redis 类型 |
+| 数据库绑定与身份 | svc 统一解析已接线；manifest/marker 和 Backend DB identity 已存在；manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env；自定义根和 legacy/direct 启动需要完整核验；identity 不等于活动服务独占锁 |
+| 服务生命周期 | svc 已有 desired/autostart、recover、watchdog timer；PG 优先拉起 | 没有完整服务组依赖／单一进程组监管；不管理 Redis 类型；登记版本与实际二进制可能不一致 |
 | 启动与停机 | 启动对账开放 run；优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前；HTTP停机超时可跳过flush；无所有worker等待；子代理 cancelled 可覆盖 interrupted |
 | 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消；子代理先派生再写文件标记；notice消费非事务且绕过PG会话占用 |
 | 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease，终态有fencing；额度有持久表 | 续租只有定义未接入生产调用；15分钟租约可过期；额度无崩溃回收；不能据此宣称安全接管 |
 | 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行，kill窗口丢命令；跨实例取消入队缺conversation；Surface失败仍可清pending且仅扫100条 |
 | 工具副作用 | Native Session已有tool intent/result转录、安全重放判定；Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义；Native的未知效果被写成工具错误后仍可继续模型，尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 |
-| 文件与备份 | blob临时写+rename；工件元数据在DB；SQLite在线备份；svc有pg_dump | 覆写文件与更新元数据不是同一原子提交；未显式fsync；DB备份不含上传、工件、工作区、转录、配置/版本 |
+| 文件与备份 | blob temp+rename、SQLite 一致性快照、pg_dump 已存在；Native 转录 Write→Sync；manifest 有原子同步链 | 工件原文先覆写再更新 DB，无不可变版本；agent 快照缺权威 manifest，PG 和文件快照不是同一恢复点 |
+| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接；数据库事务可排队 | 无跨进程活动服务独占；恢复扫描全部开放 run，第二个服务可打断第一服务；不具备 PG 的会话执行租约 |
 
-当前登记元数据显示 dev 绑定 `pg1/agent`，部署制品的 Backend revision 与上述Backend一致；这只证明登记和制品元数据。**实际运行进程的数据库身份、全栈恢复、数据耐久性尚未实测，不能写为PASS。**
+2026-10-12 17:37:03（Asia/Shanghai）实际 dev 进程打开 `runtime/dev/data/agent-system.db`，DB marker 为 `sqlite`，运行 Backend `5e8ada7`；没有登记 PG 绑定。候选 rdmcand 已停止且登记来源与实际文件版本不符。前一轮共享数据观察是历史风险线索，不冒充当前双进程事实。**实际文件／marker 已核对，不等于全栈恢复或断电耐久性 PASS。**
+
+当前 PG 事件总线已有真重连、分页追赶和周期补查，Native 已接持久工具转录；这些基础不重复建设。SQLite 应用连接未显式声明 synchronous；诊断连接 PRAGMA 不能证明应用配置，见 R12。
+18:14:09（Asia/Shanghai）重新实测：外部流程已将 rdmcand 拉起于独立数据根，实际 DB inode 与 dev 不同且制品／登记版本一致；dev 仍打开原库、账户最后设密时间未前进。当前共享现场已缓解；U8 的剩余任务是强制运行时防误用和隔离验收，不重复执行已完成的人工分根。完整停机／恢复和锁能力仍 NOT_RUN，本轮没有改变服务或数据。
 
 旧报告中“DSN重启丢失”“迁移DDL与版本分开提交”“通知仅内存”等问题已有源码改进，本案只验证并复用这些基础，不把旧缺陷重新列成新建设。
 
@@ -65,6 +74,8 @@ product_contract_source: ce-plan-bootstrap
 | R8 | 停机与就绪 | 停机先拒绝新工作再排空；全部worker、sidecar和工具子进程收口；错误不跳过后续清理；ready反映业务可用 |
 | R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同；备份恢复到新目标并完成业务/权限/文件对账；不在普通启动覆盖现库 |
 | R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 |
+| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时；直接二进制、路径别名和 legacy 入口同样受保护；账户短事务 CLI 不启动第二运行时；测试实例使用独立根 |
+| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略；文件和目录同步覆盖权威对象；DB/文件持久失败不能确认成功；未实测的断电 RPO 保持候选 |
 
 覆盖“所有数据”需要先完成数据归属清单：除Backend业务表，还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性；无法证明可恢复的必需插件阻塞全系统签收，不能只恢复Backend便宣称全部完成。
 
@@ -114,6 +125,12 @@ flowchart TB
 
 systemd的顺序依赖不能替代DB可用性检测；需真实探测，且明确依赖断开后的重连/恢复政策。监管策略参考systemd官方[service契约](https://github.com/systemd/systemd/blob/main/man/systemd.service.xml)与[进程组停止契约](https://github.com/systemd/systemd/blob/main/man/systemd.kill.xml)。
 
+KTD13. **SQLite 活动服务锁由 Backend 强制。** 在迁移和启动 run 对账之前按实际 DB／数据资源取得 OS advisory lock，持有至运行时退出；覆盖规范化路径和文件别名。marker/PID 不替代锁，SIGKILL 后由 OS 释放。合法账户 CLI 只核验同实例和兼容 schema 后做 DB 短事务，不启动 Manager；迁移独立维护。锁文件丢失或 DB 替换导致身份改变时拒绝自动续跑，不能新建可绕过的锁继续。
+
+KTD14. **初始化与事故后缺库分开。** 已登记实例启动和运维先验证预期库／marker，缺失则阻塞；显式 init 才允许创建。SQLite 可靠档明确 WAL＋FULL 并核验每个连接；PG 核验实际 fsync/synchronous_commit/full_page_writes 等，不用诊断连接默认值证明应用配置。[SQLite WAL](https://www.sqlite.org/wal.html)、[PostgreSQL WAL](https://www.postgresql.org/docs/current/runtime-config-wal.html)。
+
+KTD15. **manifest 单一权威与派生视图修复。** 复用现有 temp→fsync→rename→dirsync；读侧直接消费 manifest 或验证派生 revision。manifest 提交后、svc.env 派生前崩溃可重新生成视图，不能按旧派生配置换库。未知制品能力、登记／实际版本不符报告并拒绝危险操作，不猜测。
+
 ## 5. 启停流程与恢复政策
 
 ### 5.1 启动和优雅停止
@@ -127,6 +144,7 @@ sequenceDiagram
   C->>D: 校验manifest、数据身份与操作锁
   C->>C: 启动归本组管理的依赖并探测
   C->>A: 启动固定版本
+  A->>A: SQLite取得活动服务锁；PG按既有执行所有权合同
   A->>D: 校验schema、文件与恢复候选
   A->>W: 完成插件/权限/预算/工作区全部装配
   A->>D: 分类认领、对账未知效果、恢复命令与额度
@@ -138,6 +156,7 @@ sequenceDiagram
   W-->>A: bounded join与子进程结果
   A->>D: 持久化恢复意图、flush、收口许可/所有权
   A->>D: 关闭存储
+  A->>A: 释放本进程SQLite活动服务锁
   A-->>C: 停机结果（含未完成原因）
   C->>C: 复核进程组消失；逆序停止独占依赖
 ```
@@ -178,7 +197,7 @@ stateDiagram-v2
 
 `recovering/hold`在这里是目标业务语义，**不是声称现有Core枚举已支持**。过渡可用恢复账本表达；若新增公开状态，Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留，不强改成成功。
 
-用户侧复用现有任务状态、对话卡和管理员恢复入口，显示恢复原因、进度和允许动作；SSE按持久seq补发并丢弃旧事件，页面刷新重载权威快照。断连或无增量不能推断任务完成。实施界面前重读根DESIGN.md并遵循UI令牌、Collapsible和单异步状态所有者规则。
+用户侧复用现有任务状态、对话卡和系统管理区，显示恢复原因、进度和动作。当前只有管理员恢复 API 基础，Frontend 对账接线待 U4 实施，不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件，刷新重载权威快照；断连不推断完成。实施界面先读 DESIGN.md，遵守令牌、Collapsible和单异步状态所有者。
 
 ## 6. 全量数据与组合备份
 
@@ -193,12 +212,16 @@ stateDiagram-v2
 
 普通启停不从备份还原；数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行，禁止start自动覆盖当前数据。
 
+当前 agent backup 只复制 svc.env、history 和 data（逐 SQLite 一致性导出），不含权威 manifest，在线非 DB 文件与 DB 没有统一快照时点；它是数据目录快照，不是完整恢复包。当前 pg_dump 默认在 runtime 子目录，完整包及副本须放在数据／runtime 生命周期之外；生成时使用受限临时目录，校验成功后原子发布完成标记。半成品不列作恢复点，完成且验证的新备份存在前不执行保留策略删除。
+
 首期备份取得明确停写窗口：关闭准入、排空或隔离在途操作、停止全部相关写者，核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致；写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点，manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。
 
 恢复到新目标首先处于隔离验证模式，不启动任务调度/副作用，也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离：可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离；不得为此擅自轮换共享凭据。生成新的恢复权威代次，并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏；旧实例不可联系不能当作停止证明。无法核实则保持副作用hold，只开放受权的数据核验。
 
 同时对账恢复点至故障/隔离完成期间的外部效果：它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对，将已确认动作登记到恢复账本，确认安全后逐项解锁；不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。
 
+灾难恢复另设安全状态门禁：开放正常认证前作废备份中的全部会话和未使用登录 Key，防止已注销／消费的凭据复活。恢复点后的改密、长期 Key 撤销、角色／成员／插件授权变更与独立受信记录核对；缺记录或无法证明当前有效性时，相关主体／资源保持鉴权隔离，有权 owner／运维重新建立凭据或确认授权后开放。新执行 epoch 不代替认证撤销。普通启停／更新不执行此规则；普通账户恢复保留集成 Key 的合同也不允许灾难恢复盲目启用旧 Key。
+
 PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续WAL，不能用pg_dump冒充其基础备份，依据[PostgreSQL备份与PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)。SQLite使用现有一致性备份接口，不能在线只复制.db遗漏WAL。文件内容先耐久发布再提交DB引用，备份保留覆盖恢复点所需的对象版本。
 
 备份副本及密钥与原数据同级保护：加密、专用受限目录/角色、异机或异故障域副本、保留期限与清理owner；密钥须独立可恢复。拟定每日日常备份、持续WAL、每月及重大升级前恢复演练，频率按批准的RPO与数据量固定。实际恢复须验证登录、跨项目隔离、历史文档与附件、任务/HITL、工件下载和插件业务链；恢复时间从故障触发开始计时。
@@ -211,12 +234,16 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 
 ### U1. 实例与数据恢复身份
 
+当前 manifest／DB identity 基础已在源码，既有合同见 Dev `docs/recovery/u1-identity-manifest.md`；本轮只规划消费缺口、派生修复和显式 init/restore，不重复建立身份层。
+
 对应R2/R3/R9；无前置。范围：`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。
 做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口；保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归，再改解析器。
 验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统；更换二进制路径/程序版本或以不同cwd调用svc后，DB identity、数据/工件/工作区根与插件组合保持一致（对应R2更换程序/cwd条款）。使用真实PG特有测试记录核对，桩测试只能辅助。
 
 ### U2. 服务组与进程监管
 
+当前 recover/watchdog/desired 已有首切片，余量为服务组、依赖 readiness、唯一监管与完整操作恢复，不再记为全部未实现。
+
 对应R1/R8；依赖U1。范围：svc组编排、可选Redis适配、分发仓`deploy/agent-system.service`及安装接线、新增隔离服务组故障测试。
 按KTD3/KTD4建立依赖图、desired state、可恢复lifecycle operation与单一监管；加入boot/start/exe身份与进程组校验。必需/可选、受管/外部资源由manifest决定。首次切监管在明确停机窗口完成，失败回到原监管且不形成双启动。
 验收：全组停止后启动；先PG后应用；主动stop保持停止；kill自动退避恢复；主机重启按策略恢复；PID复用、残留子进程、端口冲突、依赖启动失败、不透明外部DB均正确拒绝/报告；不得停止其他服务组的共享依赖。
@@ -231,6 +258,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 
 对应R4/R5/R7；依赖U3，并复用U5所有权接口；U4/U5作为同一安全交付批次，完整性验收前不开放自动续跑。范围：runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。
 落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围；若新增recovering/hold为公开状态，设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表，作为设计评审前提。
+Frontend 接线复用任务／对话卡和系统管理区：有权 owner/admin 查看具体 operation、未知原因和证据引用，提交已完成 receipt、未执行终态及旧请求隔离证明，或明确放弃。提交防重复，失败保留输入与原因，成功重载权威状态；Backend 按 operation 权限／版本／epoch 裁决，不以当前整 run release API 代替逐项对账。浏览器验收覆盖发现 hold→对账→剩余步骤恢复，拒绝越权和「放行即重跑」，不新增页面。
 验收：排队/主run/子run/HITL/索引各类任务kill并两次恢复；工具“完成外部动作、结果未提交”只hold不重做；查询暂未发现但外部请求稍后完成时不发送第二次请求；幂等目标使用同operation key；Native pending intent只由统一账本决策，不生成普通错误后绕过hold；确认一个operation完成后执行剩余必要步骤，不假结算整run；未知工具默认隔离；撤权后禁止续跑；无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源，未跑标NOT_RUN。
 
 ### U5. 所有权、额度、命令、通知与投影闭环
@@ -244,6 +272,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 对应R3/R7/R9；依赖U1/U3，恢复账本完整验收依赖U4/U5。范围：blobstore/content、workspace与checkpoint、插件恢复适配合同、svc deploy/update/backup、分发仓安装、备份manifest与restore测试。
 按KTD11发布不可变版本，扫描缺失/孤立对象；登记全部插件/下游存储；按第6节生成一致恢复点、保护副本、恢复到新目标；候选完整构建后切版本，保留兼容上一组合。
 验收：对象写后DB提交前kill；覆盖发布过程中kill；日志尾截断/文件缺失保留现场；备份恢复后原文hash/权限/插件链一致；恢复新目标后旧实例复活仍不能产生外部效果，未完成旧写路径隔离时新目标不调度；恢复点后已发生的外部效果对账完成前保持hold；升级ready失败可在兼容条件下回退；不兼容schema拒绝程序自动回退；数据回退不静默丢新写入。
+另覆盖恢复点后注销会话、消费／撤销登录 Key、撤销集成 Key、改密与撤回角色／项目／插件权限：恢复旧包后旧会话和登录 Key 不再有效，无法证明有效的长期 Key／授权保持隔离；owner 正常确认后的新凭据可用。与普通重启原密码保持分别签收。
 
 ### U7. 故障验收与交付放行
 
@@ -253,11 +282,28 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 
 建议交付批次：A=U1/U2/U3（可靠启动及安全停机，自动任务续跑关闭）；B=U4/U5（安全自动续跑与命令闭环）；C=U6/U7（文件耐久性、灾难恢复及全系统签收）。只交付A不能宣称完成用户的全部需求。
 
+### U8. SQLite 活动服务隔离与既有存储门禁
+
+覆盖 R2/R3/R6/R11/R12，复用 U1 身份；近期优先于自动恢复和共享库测试。范围：Backend `internal/app/app.go`、`internal/store/store.go`、`internal/store/system_identity.go`、新增 `internal/instanceguard/`（拟定）；Dev `scripts/svc.sh`、`docs/svc.md`。锁只控制活动服务运行时，CLI 身份／schema 合同由[账户方案](2026-10-12-svc-unified-deploy-and-login-key.md) U7 负责。负责人待实施批准时指定。
+依赖：既有 U1；联合确认 service／CLI／migration 模式，先刻画原例和别名冲突，再实现；不直接把当前 dev 数据迁往 PG。
+测试：新增 Backend `internal/instanceguard/guard_test.go`，扩展 `internal/store/system_identity_test.go`；Dev 新增 `tests/test_svc_storage_ownership.py`，复用 `tests/test_svc_identity.py`。新增路径为计划。
+T8-1：两个独立进程同时启动同 SQLite，只有一个进入迁移／恢复；第二个明确拒绝，第一个 run/HITL 不变。
+T8-2：直接二进制、legacy、符号链接和可构造的文件别名不能绕过；真实 DB 替换／锁根丢失被识别。
+T8-3：活动服务 SIGKILL 后合法同实例可重启，OS 释放锁；主动停止不被 watchdog 错拉起。
+T8-4：服务运行期间合法账户 CLI 可提交短事务；错实例／缺库拒绝、不建目录、不 migrate；迁移不与活动服务并发。
+T8-5：更换端口、cwd、程序版本保持同一资源；测试候选默认独立根，显式指定共享根也不得绕过保护。
+T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合同核验，磁盘满／写失败不返回成功。
+环境：独立 SQLite 根与端口、真实 PG 独立库回归；双进程和 kill 禁止在当前 dev/candidate 执行。全部 T8 当前 NOT_RUN。
+
+近期批次 A0=U8＋账户方案 U7/U5：先稳定数据归属和账户链路；另行授权后完成 dev 原账户正常登录／重启／更新验收，见账户方案 §7。A/B/C 保留；U4/U5 联合验收后才开放自动续跑，A0 不代替全量恢复。
+
 ## 8. 验证合同
 
 | 故障/操作 | 最小判据 | 对应需求 |
 |---|---|---|
 | `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 |
+| SQLite 双进程、直接启动、别名、锁释放 | 第二活动服务在迁移／run对账前拒绝；合法 CLI 可用；kill 后同实例可重启 | R2/R6/R11 |
+| 实际 DB 耐久档、权威文件发布点、磁盘满 | 参数来自应用连接；确认结果已耐久；失败不发布成功；旧版本可读 | R3/R7/R12 |
 | 应用SIGTERM/SIGKILL/OOM | 持久数据完整；安全工作可恢复；额度无永久占用；无残留写者 | R3/R4/R6/R8 |
 | PG停止/重启、断连或提交响应丢失 | 不切SQLite；不假接受；按幂等记录对账；重连后可用 | R2/R3/R5 |
 | 主动stop与异常退出、监管/编排中途kill | 主动停止不拉起；异常按running意图恢复；操作重复安全 | R1/R2/R8 |
@@ -280,16 +326,59 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 
 本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。
 
-调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。**U1/U2启动实施前必须人工二选一**：(a) 以`feature/svc-autorecover`为实施载体，把本案r2作为其需求与方案来源填入该任务卡后按其流程推进；(b) 记录原因后放弃或合并该任务卡，由本案派生的独立任务实施；两任务不得同时充当svc启动/监管改动的权威，该归属决定与首批实施范围一并报批；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。
+原 r2 的 svc-autorecover 二选一属于历史启动现场；当前 recover/watchdog 和 U1 身份已有源码，不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管／RDM UI／端口回收任务，避免重复修改入口。RDM／插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。
 
 备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
 
 实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。
 
-下一任务建议为U1并同步审查U3生命周期缺口：先保证再次启动绝不换库、换数据根或假就绪，再接监管和自动续跑。预计产物为兼容manifest合同、数据归属清单、隔离真实PG恢复回归与生命周期设计；进入实施前人工批准本案的需求、设计和首批测试范围。后续数据库备份、systemd安装、部署/启停与故障实验分别按授权执行。
+r3 编制期的历史下一任务建议（不是当前批准状态）为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
 
 ## 10. 全系统完成条件
 
-只有在所有启用的必需服务/插件被纳入清单、R1–R10均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
+只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
 
-本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+编制期历史交付状态止于**待审核方案**；当前批准与进展见页首及第 11 节。批准不等于全系统恢复已验收，不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+
+## 11. D1/D2/D3 部署根治补充（r3.1）
+
+编号 D1/D2/D3 只属于本补充，避免与本案 U1–U8 重名。已合入且不再重做：Dev #474（按实例重置身份变量、停旧前候选门禁、update 走 manifest 迁移、普通启动只验证）、Backend #180（`pkg/identity`）、RDM #276（identity 子命令与未知位置参数退出）、Dev #477（backend pin 到含 #180 的 `acabb85`）。
+
+### 11.1 现场快照与 rdmcand 数据归属（SELF，2026-10-12T13:39:21Z）
+
+快照目录（在线 `sqlite3 .backup` / RDM `VACUUM INTO`，未停服务）：
+
+- `runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z`
+- `runtime-backups/{dev,rdm1,rdmcand}/domain-20261012T133921Z`
+
+只读核对副本，未移动任何业务数据。rdmcand 在 `2026-10-12T06:51:14Z`–`10:02:40Z` 使用 `runtime/dev/data`。该窗口内：
+
+- dev 库的会话、消息、事件均不落在窗口内。最后一条消息时间 `06:50:43Z`，早于 rdmcand 挂上该目录。会话与用户属于 dev（owner `weichen`、`genui-smoke`）。
+- 窗口内仅有 13 条 `command_audit`，全部是 `rdm.inspect.*`，owner `weichen`，没有领域事件。
+- 三份 `rdm.db` 的 `events` 均为 0。dev 的领域库更大（含权限表，schema_version=6），rdm1/rdmcand 的领域库只有字典与 schema 行。
+- rdm1/rdmcand 的 `agent-system.db` 只有 `2026-10-12T13:19:47Z` / `13:20:12Z` 由候选门禁写入的身份行，没有业务行。
+
+处置（未执行，需逐项授权）：不把 dev 的会话或领域库迁到 rdmcand。没有一份应属于 rdmcand 的历史领域数据需要回迁，因此不触发身份 `adopt` 重审。rdm1/rdmcand 当前库是空壳加已建立的身份行。
+
+### 11.2 D1 身份流程收尾
+
+对应 U1 的消费缺口。完成条件：
+
+- 身份 CLI 只打开既有库：不建文件、不建目录、不迁移。`agent_system_identity` 表（v27 起，列冻结为 instance_id/dbref/schema_version/created_at）缺失则拒绝并提示受控迁移。比本二进制更旧或更新的 schema，只要该表仍在，verify 仍可读。
+- verify 输出带 `schema_version`。DSN 走 `AGENT_SYSTEM_DSN` 或权限恰好 0600 的 `--dsn-file`；`--dsn` 保留并告警。
+- 能力文档一份 JSON，经 `version --json` 与 `identity capabilities` 输出。探测只跑 `version --json`，在空目录、清空环境、超时内执行。非 JSON 视为无能力。
+- 顶层未知子命令 exit 2，不以 `-` 开头才拦截，避免落入 serve。
+- manifest `identity.db_marker`：`fresh` | `pending` | `established`。新实例首次部署目标目录必须为空，启动建库后 ensure 变为 established。领养时有能力且库已存在则 ensure，否则 pending。pending 只在库文件存在时补齐，不迁移。established 缺行或不匹配时，start/restart/deploy/update/recover/init 全部拒绝；唯一修复入口是显式 `adopt --confirm <instance_id>`，并先打印库大小、关键表行数和最近写入时间。
+- `svc_lifecycle` 是 start/restart/deploy/update/recover 的共同入口。update 与 recover 逐服务以 `env -i` 启动子进程，不传入 `AGENT_SYSTEM_*`。serve 使用显式环境，并写入 0600 的 `serve.env` 供裸启动与 recover 复用。
+
+### 11.3 D2 切换事务
+
+对应 U6 的部署回退。制品进入 `runtime/<name>/releases/<rid>/`，`current` 用临时符号链接加 `mv -T` 切换。`bin`/`plugins`/`htdocs` 改为指向 `current/` 的稳定链接。切换日志 `deploy-journal.json`（0600）先写 phase 再执行。失败回到上一版本并恢复原期望运行态，不覆盖业务库。schema 不兼容时在停旧服务前拒绝。前进迁移必须 `deploy --migrate-schema --confirm <instance_id>` 且先 backup，日志标记 forward-only。能力文档增加 `schema.target` 与 `schema.compatFloor`；每条迁移登记是否破坏旧版读取，漏登记则测试失败。
+
+### 11.4 D3 真实组合门禁
+
+对应 U7 的故障验收入口，范围限于部署生命周期。Dev 用 `tests/integration/lifecycle/rdm.pin` 固定 RDM SHA（当前、上一版、无 identity 的旧版）。CI test-pg 按 pin 取固定 SHA，白名单加入 RDM 及其 pins。`make test-lifecycle` 缺 PG、源码或制品即失败，不静默跳过。桩测试不能代替该门禁。RDM 登录入口与账户 CLI 的 DSN 退出命令行依赖账户方案 U7/U5；未就绪的项保持 NOT_RUN，D3 不得标完成。
+
+### 11.5 验收
+
+缺一项则对应增量保持未完成：双向混合批次身份不串用；无 manifest 时 deploy/update/recover 一致；无能力、缺行、不匹配在停旧前拒绝且不建库；两次裸重启及换端口、换版本、换目录后身份不变；构建失败、启动即退、健康超时、工作台失败可回滚；切换中断后登记与制品一致；真实 PG 绑定与多实例检查通过且凭据不进命令行、日志和证据；RDM 页面、登录、领域命令和原有数据可验证，不能只看 HTTP 200。

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

@@ -0,0 +1,291 @@
+---
+title: svc 统一部署与一次性登录 Key 方案
+type: feature
+date: 2026-10-12
+artifact_contract: ce-unified-plan/v1
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# svc 统一部署与一次性登录 Key 方案 r3
+
+确认状态：**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 批准记录，不以该批准代签其他新增范围。
+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 根目录为基准。
+
+## 1. 目标与成功边界
+
+**目标：在干净或既有机器上，用同一套 `svc` 入口完成二进制或源码部署、按档准备依赖，并通过后端账户能力完成无初始密码开户与账户恢复；一次性登录 Key 只能兑换设密受限会话，完成设密前不能访问业务数据。**
+
+必须区分三类能力：
+
+| 能力 | 结果 | 非目标 |
+|---|---|---|
+| 统一安装 / 升级 | 指定版本或提交物化为可切换候选；切换后实例身份、DB、数据根与账户不变 | 不接管共享 PostgreSQL；不因发现端口而认领外部服务 |
+| 环境检测与准备 | `doctor` 只报告；`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建；工具链版本读自所选提交或发布清单 |
+| 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key；原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户；不迁移业务归属；普通找回默认不撤销长期集成 Key |
+
+与 [服务重启与全量数据恢复方案](2026-10-12-service-restart-data-recovery.md) 的关系：
+
+- **复用** KTD1–5、KTD12：持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。
+- **复用** 已合入的 recovery U1（Dev #415）：`runtime/<name>/manifest.json`、启动身份校验、`svc init`、原子写路径（见 Dev `docs/recovery/u1-identity-manifest.md`）。
+- **本方案新增**：部署来源统一（binary/source）、doctor/env prepare、账户生命周期与一次性登录 Key、安装入口与双轨收敛。
+- 命名区分：**账户恢复 Key** ≠ **服务数据恢复**。
+
+## 2. 当前事实及重点差距
+
+本轮 source 基线（SELF）：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（增加任务元数据）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；Dev 固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。本轮 Documents 草案从其独立权威 main `1048e7c6afc2bb4efc541e68575c3fb2669ee332` 起步；与 Dev 固定版相比，两份目标方案正文没有上游差异。Dev gitlink 未推进。原 r1 基线只作历史，不用于当前能力判断。
+
+2026-10-12 17:37:03（Asia/Shanghai）的只读运行观察和启动／同步命令，原始脱敏输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。这是 SELF 观察，不是登录、故障或恢复验收，后者均 NOT_RUN。
+最终同步基线为 Dev `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9`：主干另已推进固定 Documents 至 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，并修复 svc 批量操作的 PIDCHECK/EXEC 等内存态串用；本轮未重复该修复，也未推进本轮 Documents 草案 gitlink。Backend／Frontend 固定 SHA 未变；上述初始基线和17:37观察保留历史时点，不冒充最终 HEAD。
+
+| 对象 | 已存在的基础 | 尚需补齐 |
+|---|---|---|
+| 部署来源 | `deploy --from local\|dev\|release\|rdm`；dev/rdm 独立缓存物化；release 读本地 Releases 仓并校验 sha256 | 远程下载/离线导入；统一 `install`；release@ver 钉扎（现 `sort -V\|tail -1` 取最大版本，见 `scripts/svc.sh` `resolve_release`） |
+| 部署生命周期 | 预检失败不停机；预检通过后 **先停再构建**；无程序备份/自动回滚 | 候选获取与校验全程不停旧服务；缺摘要硬失败；迁移后回退独立判断 |
+| 实例身份 | recovery U1：manifest + marker + init；`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置；缺绑定拒绝，禁止回落 `./data` |
+| 环境 | 端口/`flock`/pg 工具链按需检查；文档列前提 | `doctor` / `env prepare`；无 `flock` 时不得放行冲突操作（现状直通） |
+| 账户 CLI | Backend 已有 create/reset-password/list/issue-login-key/revoke-login-key/bootstrap-admin；svc 已接 `user` 且附加 OpenExisting | 顶层／专题帮助未列账户入口；OpenExisting 仍 migrate；账户路径未完整验证 DB identity；参数回显及 argv 凭据需整改 |
+| 登录凭据 | 长期 `api_keys` 与独立 `login_keys` 已分离；一次性 Key 原子兑换为短期受限会话 | 原子开户＋签发、统一密码变更及审计仍有缺口；不能把基础实现等同于整体验收 |
+| 强制改密 | Backend 已有受限会话和 must-change 中间件，强制设密成功销毁会话并要求重新登录 | Frontend 仍只有密码／长期 Key 两个入口，未接兑换及 sessionScope/reloginRequired；设密后直接 onDone 与后端不兼容 |
+| 安装双轨 | Dev `svc deploy` 多实例；Releases `install.sh` 系统 systemd | 统一部署计划；`install.sh` 薄封装或明确遗留 |
+
+命题裁定（源码复核）：
+
+1. 长期 API Key 是 show-once plaintext，不是 single-use；一次性登录 Key 是独立类型，当前代码已区分。
+2. r1 所记「无统一改密门」已被 U4 源码覆盖，不能继续作为待建能力；普通改密／管理员重置仍缺统一事务及旧恢复 Key 作废，见 `modules/backend/internal/server/accounts.go:208`、`modules/backend/internal/store/auth.go:244`。
+3. `scripts/svc.sh:1503` 已实现 user 转发，但帮助未列；`modules/backend/internal/app/app.go:743` 的账户插入和 Key 签发分别提交，不能采信注释中的「同事务」。
+
+### 2.1 dev 8788 事件与归因边界
+
+用户明确故障对象为 dev（127.0.0.1:8788）。17:37 的实际进程打开 `runtime/dev/data/agent-system.db`，数据库 marker 为 dev 的 SQLite 身份；该现场没有使用 PostgreSQL，不能沿用旧报告的 pg1/agent 描述。
+
+| 只读对象（北京时间） | 账户身份 | 最后设密时间 | 与 live 摘要比较 |
+|---|---|---|---|
+| 12:35:03 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
+| 14:50:37 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
+| 17:37 的 live | 同一账户，must-change=0 | 16:03:20 | 当前值 |
+
+比较仅输出时间、状态及相等性，不输出摘要或凭据。它证明字段重写，不证明明文改变；随机盐使同一明文的重新散列也可能不同。未发现正常启动／更新／迁移 up／设置播种自动覆盖既有密码的路径；现有 audit_events 只有 Surface 事件，无法归因此次写入。另有已消费恢复 Key，但其消费时间不能证明之后哪次设密由它触发。
+
+前一轮观察到 dev 与候选 rdmcand 指向同一数据根；17:37 候选处于停止，因此历史共享不写成该时点双进程事实。18:14:09 续查时，外部流程已将候选重新启动于独立的 `runtime/rdmcand/data/agent-system.db`，实际文件 inode 与 dev 不同，登记和制品版本相符；dev 最后设密时间仍为16:03:20。这缓解了当前共享现场，不能代替 Backend 防误用锁或完整验收。历史共享说明跨实例影响范围，不证明某次更新主动改密；本轮未执行这些现场变更。
+
+本轮不进行真实账户登录尝试或再次重置来验证旧密码；故障重放仅在脱敏、独立数据副本上执行。首批完成还需另行授权的 dev 原账户正常登录验收，见 U5／U8 合同；该验收不在 live 进行 kill、并发或故障注入。历史操作者归因仍未证实，新增审计不能反向补造旧事件。
+
+## 3. 需求合同
+
+| ID | 范围 | 要求与可判定验收 |
+|---|---|---|
+| R1 | 安装入口 | `doctor` / `install` / 兼容 `--from` 生成同一部署计划；二进制无需 Go/Node；源码固定提交且子模块组合可核验 |
+| R2 | 实例身份 | 启停、升级、开户、签发 Key 命中同一 store 与 data 根；缺失/不符拒绝；与恢复案 R2/manifest 一致 |
+| R3 | 切换安全 | 构建/下载/摘要失败时旧服务继续；程序+插件+前端作为版本组合切换；固定版本不得被「最大版本」替代 |
+| R4 | 存储档 | team 默认 PG+auth；`existing` / `managed-local` / `local(SQLite)` 显式选择；PG 失败不回落 SQLite |
+| R5 | 开户 | 无初始密码；角色明确；创建与激活 Key 同事务；同名冲突不覆盖 |
+| R6 | 账户恢复 | 精确命中既有账户；不改密码/不吊销会话/不改业务数据于签发时；保持 owner/角色/成员关系 |
+| R7 | 一次性 Key | ≥256bit、只存摘要、activate\|recover、默认 TTL 30min、状态机、原子兑换、专用 POST body |
+| R8 | 受限会话 | 仅身份查询、设密、退出；业务/下载/SSE/admin/插件拒绝；普通 `must_change` 同样服务端限制 |
+| R9 | 设密事务 | 写 hash、清待激活/待改密、作废未用恢复凭据、失效相关会话同事务；成功后销毁受限会话并要求密码重新登录 |
+| R10 | 集成 Key | 普通找回默认保留长期 API Key；失陷恢复显式 `--revoke-all-credentials` |
+| R11 | 首次管理员 | 仅核验为新实例（无用户且无历史业务标记）；事务防并发；不得因「未发现管理员」接管有数据环境 |
+| R12 | 证据 | 验收绑定固定源码/制品摘要/环境；SELF/REPLAY/GATE 分源 |
+| R13 | 可发现与兼容 | 完整／短帮助、help user、实例 user --help 和文档列出实际账户能力；不支持的制品在调用前拒绝；帮助／探测不建库、不迁移、不启动服务 |
+| R14 | 账户稳定与审计 | 普通启停／更新不隐式重置；密码变更、恢复凭据／会话处理及成功审计原子提交；记录 actor、入口、实例、operation 与时间，不记录密码、摘要或 Key 明文 |
+| R15 | 运维既有库 | 账户操作核验预期库和实例；读操作不建库或 migrate；schema 不兼容明确拒绝，迁移走独立入口；CLI 参数和日志不暴露凭据 |
+
+## 4. 技术决策（KTD）
+
+KTD1. **部署方式只决定程序来源，不决定数据位置。** binary ↔ source 可切换；切换保持 DB、数据根、账户与 instance_id。
+
+KTD2. **账户规则只在 Go 后端。** 脚本调用实例对应版本的 CLI；不直接改用户表。
+
+KTD3. **一次性登录凭据独立于长期 `api_keys`。** 专用表与兑换 API；普通 Bearer、SSE `?key=`、长期 Key 路径均拒绝。
+
+KTD4. **受限会话为独立 scope。** 默认 10 分钟；allowlist 仅 me / 设密 / logout。
+
+KTD5. **团队安装默认 PostgreSQL；存储选择显式。** 与恢复 KTD5、`config.Tier=team` 一致。
+
+KTD6. **一次性 Key 默认 30 分钟**（可配置建议范围 5–120 分钟）；审计记实际 TTL。
+
+KTD7. **激活/恢复设密成功后必须重新密码登录**（销毁受限会话、清 cookie）。普通主动改密可保留「要求原密码」路径；激活路径不要求原密码。
+
+KTD8. **普通账户恢复默认保留长期集成 Key；失陷显式撤销全部凭据。** 两种情况均保留业务数据。
+
+KTD9. **候选校验完成前不停旧服务**；切换短窗；schema 迁移后能否自动回退旧程序另行判断，失败不自动用备份覆盖业务库。
+
+KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端；Releases `install.sh` 变为薄封装或文档降级为遗留，禁止第三套生命周期。
+
+KTD11. **能力声明与帮助同源，但后端仍是执行权威。** 新制品提供无副作用的结构化能力声明；旧制品仅按已验证版本兼容，未知形态拒绝。禁止尝试未知子命令或靠 strings 包含某词推断能力。保留 reset-password 的直接重置语义，不偷偷改成签发恢复 Key。
+
+KTD12. **统一密码与开户事务。** 严格唯一 INSERT；散列计算在事务外，事务内重新核验权限／账户版本。主动改密、CLI／管理员重置、恢复设密共同执行密码＋标志＋旧登录 Key 作废＋规定会话处理＋审计。普通路径保留集成 Key，失陷模式按 KTD8 明确撤销；失败全部回滚。
+首次管理员按实例串行，不能只依赖 owner UNIQUE：PG 锁定既有实例身份行，SQLite 使用立即事务，取得串行权后重新核验无用户、无历史业务；引导与能改变此前置条件的开户共用串行点。管理员、激活 Key 和审计共同提交；marker 缺失时由显式 init 处理，账户命令不得补建身份。
+
+KTD13. **审计可归因，运维不隐式迁移。** 成功审计与变化同事务；失败记录注明未提交；HTTP actor 来自已认证会话，CLI 记录受信 OS 运维 UID／身份来源，不接受调用方填写的 actor 作为证明。实例身份和操作 ID 实填。既有库读命令只校验兼容性；迁移另行批准和执行。
+
+KTD14. **凭据只经安全输入和单次交付。** 优先无回显输入／stdin／受保护文件，DSN 不传 argv。serve 已消费 AGENT_SYSTEM_DSN，账户 CLI 的等价安全输入需在 U7 显式接入并以能力声明核验，不能假定当前 user flags 已读取环境。非交互输出独占创建 0600 文件，日志／evidence 只记凭据 ID。提交后交付失败按 operation 查询，再撤销／重发；库存摘要不能重新打印旧明文，不把重试当首次创建。
+
+## 5. 职责划分与接口示例
+
+| 部分 | 负责 |
+|---|---|
+| `svc.sh` | doctor、env prepare、获取制品、构建、实例配置、生命周期、调用账户 CLI |
+| 后端 CLI | 创建账户、签发/撤销一次性 Key、核验目标库、OpenExisting、操作审计 |
+| 后端认证 | 原子消费 Key、受限会话、设密事务、中间件限制 |
+| 登录页 | 输入一次性 Key、设密、过期/重发提示；遵循 `DESIGN.md` |
+| 发布制品 | 版本、平台、摘要、组件版本、能力声明 |
+
+拟新增 CLI（当前脚本尚不支持；兼容 `--from` 保留）：
+
+```bash
+./svc.sh doctor --mode binary --tier team
+./svc.sh install prod --mode binary --version <固定版本>
+./svc.sh install prod --mode source --repo <仓库> --ref <固定提交>
+./svc.sh prod deploy --mode binary --version <固定版本>
+./svc.sh prod user create --owner alice --role user
+./svc.sh prod user issue-login-key --owner alice --purpose recover
+./svc.sh prod user list
+./svc.sh prod user revoke-login-key --id <凭据编号>
+```
+
+Linux 服务账户与应用账户分开管理。
+
+## 6. 规格合同（实施前必须写进 U1/U4，否则返工）
+
+1. 独立凭据类型 + `POST` body 兑换 API。
+2. 会话 scope / 中间件 allowlist；覆盖 `must_change` 普通首登。
+3. 设密接口分型：受限会话不校验原密码；普通改密继续要求原密码；同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。
+4. 密码未设置状态：`password_hash` 可空或 sentinel；`VerifyLogin` 拒绝未设密；创建 = 用户行 + 激活 Key 同事务。
+5. CLI `OpenExisting`：目录/DB 不存在则失败；账户运维默认只校验兼容 schema，不 migrate；迁移独立执行。配套 U1 v0.2 候选同此合同，原 requireCompatible 自动 migrate 是历史实现。
+6. `release@<ver>` 必须解析到该版本目录；缺摘要硬失败。
+7. 部署：获取/构建/校验不停旧服务；组合切换；迁移后回退独立判断。
+8. `install` 与 `--from` 同一计划；双轨收敛（KTD10）。
+9. 首次管理员仅新实例；事务防并发。
+10. 凭据交付：交互 stdout 一次 / 非交互 `chmod 600` 文件；日志与 evidence 只记凭据 ID；随机密码路径首期可并存但默认无密码 + Key。
+11. 无 `flock` 时拒绝冲突生命周期与账户操作（收紧现状「直通」）。
+
+详细设计（正文在 Dev 仓，随本任务分支提交）：
+
+- U1：`docs/svc-deploy/u1-instance-account-binding.md`
+- U4：`docs/svc-deploy/u4-one-time-login-key.md`
+
+## 7. 增量与完成门槛
+
+| 增量 | 主要范围 | 完成条件 |
+|---|---|---|
+| **U1** 实例—账户绑定补齐 | 账户 CLI 读实例 manifest；OpenExisting；锁缺失拒绝；install 骨架对接既有 identity | 开户/签发命中同一 store；错误 data/DSN 拒绝；与 recovery U1 字段对齐 |
+| **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署；固定版本与摘要可核验；修复 release 钉扎 |
+| **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验；幂等；不接管共享服务；binary 不装 Go/Node |
+| **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密；受限会话无法调业务 API；并发兑换单胜 |
+| **U5** 脚本与登录页接线 | 账户帮助、无副作用能力探测、凭据安全交付、Login/设密页 | 新建与恢复走通；设密后清受限会话并返回密码登录；不支持的产品明确拒绝；DESIGN.md |
+| **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档；故障注入；浏览器 + 真机；治理回归 |
+| **U7** 账户事务与稳定性补齐 | 原子开户／引导、统一改密与撤销、审计、只读兼容打开 | 并发建号不覆盖；中断无半状态；旧恢复 Key 失效；身份缺失不改库；升级保持登录能力 |
+| **U8** 实例运维核验与凭据诊断 | 账户状态／事件查询、绑定和制品诊断；补齐 U1 身份消费 | 可定位合法变更来源、识别错库／失效会话／错误 Key 类型；只展示非秘密元信息 |
+
+**当前 U1/U4 基础已在源码中，近期优先 U7 和 U5，并与恢复方案 U8 隔离保护协调。** U7 先冻结后端账户事务／审计及能力声明合同；U5 随后完成浏览器与脚本；U8 诊断复用其记录。U2/U3 保留后续，不让通用安装器阻塞 dev 账户稳定。各仓从共同批准基线起独立任务；Backend → Frontend → Dev 组合，正式组合验证后才推进 gitlink。
+
+### U7 近期实施与验证合同
+
+覆盖 R5/R6/R9/R10/R11/R14/R15；依赖既有 U1/U4，实施负责人待指定。
+范围（相对于 Backend）：`internal/store/auth.go`、`internal/store/login_keys.go`、`internal/store/platform.go`、`internal/app/app.go`、`internal/server/accounts.go`、`cmd/agent-system/main.go`；迁移目录仅在 schema 需要时改动。
+先刻画现有显式改密、重置及建号行为，再修复并发与中断窗口。账户校验、禁止隐式 migrate、严格 INSERT 和统一密码事务是单一后端实现，脚本不直接写表。
+
+现有测试参考 `internal/store/login_keys_test.go`、`internal/server/login_key_test.go`、`auth_e2e_test.go`；新增 `internal/store/account_lifecycle_test.go` 与真实 PG 跨进程用例（路径相对于 Backend）。
+T7-1：两个独立进程同名开户，只有一个账户／激活 Key 成功，败者不改变胜者角色、密码和成员。
+T7-2：开户、Key 签发、改密、会话处理、审计提交各故障点，最终只见完整旧态／新态；输出失败但提交未知时按 operation 查询。
+T7-3：普通改密、临时重置、恢复设密后旧未用 Key 都不可兑换；长期集成 Key 按 R10 保留／撤销。
+T7-4：读命令命中旧 schema、缺库、错 marker 均拒绝且不 DDL／建库；两个独立进程以不同 owner 并发首次引导单胜，另覆盖引导与普通开户竞争；有历史业务而无用户时拒绝。
+T7-5：普通重启、两次更新、SIGTERM/SIGKILL 后测试账户原密码仍验证成功，账户权限及成员不变；不以摘要是否变化替代密码可用性。
+执行环境：独立 SQLite 副本、真实 PostgreSQL 独立库、独立端口；不在当前 weichen 账户上故障注入。所有 T7 用例当前 NOT_RUN。
+
+### U5／U8 近期接线与验证合同
+
+U5 覆盖 R7/R8/R9/R13/R15，依赖 U7 对外字段合同；范围 `scripts/svc.sh`、`docs/svc.md`、Frontend `src/api.ts`、`src/auth.ts`、`src/components/LoginPage.tsx`、`src/App.tsx`。复用现有登录／设密页，类型明确消费 sessionScope、passwordSet、reloginRequired；恢复 Key 不写持久浏览器存储或 URL。
+同一登录页保留默认账号密码入口，增加「激活／恢复 Key」入口并说明只用于设密；长期 API 密钥入口标清集成用途。错类型提示指向正确入口，切换清输入，更新初始密码旧说明，不新增独立恢复页面。
+刷新／兑换响应不确定时先查询会话，有效受限会话恢复设密；会话不存在且 Key 已消费／过期时提示联系账户管理员重发，返回「激活／恢复 Key」入口。无密码账户不得被引导用旧密码登录。
+测试参考 `tests/test_svc_user_binding.py`、Frontend `test/auth.test.ts`、`e2e/changepw-form.playwright.ts`；新增 Dev `tests/test_svc_user_help.py`、Frontend `e2e/login-key.playwright.ts`（计划文件）。
+T5-1：完整／短／专题／实例帮助覆盖六个账户命令，并均无 DB／目录／服务副作用。
+T5-2：旧产品和 RDM 不支持账户 CLI 时在执行前拒绝；stdout 单次交付，stderr／进程参数／history 无秘密；两类 Key 双向填错有正确引导且切换清输入。
+T5-3：激活／恢复完成兑换→设密→重新密码登录；刷新／响应丢失先核会话；Key 已消费而会话失效时经管理员重发的新 Key 可以续办；过期、重复兑换、CSRF 错误有准确提示。
+T5-4：受限会话无法访问业务／下载／SSE／admin／插件；设密成功后不得因直接 onDone 误放行。
+U8 覆盖 R2/R14/R15，依赖 U7 审计；在 `user info`／账户事件查询（拟新增）展示实例、设密时间、凭据类型及状态。错误配置、注销、Key 失效与密码错误分别诊断，普通登录错误不泄漏他人账户信息。CLI/HTTP 两入口产生可追溯同一 operation 记录；历史无审计事件保持未知。
+
+首批 dev 原账户闭环（NOT_RUN）：实现及隔离验证通过后，另行确认运行验收窗口／实例／版本，由 owner 在浏览器输入已知密码，检查原 user ID、角色、成员及原数据访问。若确实不能登录，明确恢复授权后才签发恢复 Key，保持账户和业务归属；不能为验收先重置能用的密码。随后在授权窗口验证普通重启及两次受控更新后原账户仍可登录。密码不交给 Agent、不进入证据；本轮不操作 live。
+
+### 必须覆盖的验收场景（摘要）
+
+干净机器二进制安装；源码固定提交与子模块；两种部署互切后数据不变；构建/摘要/配置失败旧服务可用；PG 身份不符拒绝且不回落 SQLite；无密码开户且不覆盖既有；同 Key 并发兑换仅一次成功；受限会话拒业务/SSE/admin；消费后建会话失败与设密中途失败无半完成态；恢复前后业务与权限对账；SQLite 与真实 PG；治理回归；源码测试不代替浏览器与真机。
+
+额外钉住：`release@v` 多版本不得装成更高版本；账户 CLI 不得回落默认 `./data`。
+
+## 8. 一次性 Key 流程
+
+```mermaid
+flowchart LR
+  A["创建账户或签发恢复 Key"] --> B["输入一次性 Key"]
+  B --> C["后端原子消费"]
+  C --> D["仅允许设置密码的短期会话"]
+  D --> E["设置并确认新密码"]
+  E --> F["作废恢复凭据及相关旧会话"]
+  F --> G["使用新密码正常登录"]
+```
+
+凭据规则：独立前缀；只存摘要；用途 `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. r2 编制期历史记录：风险与当时未授权范围
+
+本节与第 10 节保留 r2 编制时点的原始边界，不表述本轮当前状态。当前批准、接管与交付范围见页首及 Dev #486；登录恢复实施记录见第 11 节。历史 NOT_RUN 保持原对象范围，部署及共享数据库操作仍须另行授权。
+
+- 编制时点的实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
+- 本轮交付终点：r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录；以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准，不推进 Dev gitlink、不推送／建 PR；启动／同步工具的任务元数据提交单独记录。
+- 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
+
+## 10. r2 编制期历史记录：规划进展与当时下一步
+
+- r1 已批准；U1/U4 基础实现存在于当前固定源码，完整浏览器／故障／运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
+- 首选下一任务（待授权）：恢复方案 U8 的 SQLite 服务隔离＋本案 U7 账户一致性；先消除共享测试数据和不可归因密码变化，再落实 U5。U2/U3 保持后续。
+- 前置：审核新增 R13–R15、U7/U8 及 U5 更新，明确实现和隔离测试范围／owner；实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区；正式组合、gitlink 推进与运行验收未执行。
+
+## 11. r3 实施记录：登录恢复流程（2026-10-13）
+
+授权：用户 2026-10-13「按此方案实施」（会话指示，覆盖登录恢复范围的实施与合入；
+代码 Review 与 PR 合入按 Dev `policy/delivery.md` 由智能体执行）。
+
+### 三项裁定（对 r2/U5 合同的分歧，用户按新方案裁定）
+
+| 分歧 | r2 表述 | r3 裁定 |
+|---|---|---|
+| 登录页长期 API 密钥入口 | 保留并标注集成用途 | 移除日常登录入口；程序化客户端直接带 Authorization 头 |
+| 管理员网页恢复方式 | 直接设置新密码 | 改为签发一次性登录 Key（旧 HTTP 端点兼容保留，仅前端 UI 下线） |
+| must-change 首登会话 | full 会话 + 动态拦截 | 登录即建 `set_password_only` 受限会话，`me.sessionScope` 统一驱动设密门 |
+
+### 已合入（2026-10-13）
+
+- Backend #187（`f103540d`）：迁移 v28（`users/sessions.auth_version` + `account_events` 审计）；
+  管理员 `POST/GET /api/admin/users/{owner}/login-keys`、`DELETE .../login-keys/{id}`；
+  改密事务内复验会话与认证版本；登录会话创建绑定认证版本（竞态窗口关闭）；
+  主动改密/管理员与 CLI 重置统一单事务；兑换入口按 IP 退避；TLS 下 Secure cookie。
+- Frontend #76（`0655bc3`）：登录页双入口（密码默认 + 一次性 Key，移除 `ask_`）；
+  设密门免当前密码、成功后回登录页（消费 `reloginRequired`）；刷新按 `sessionScope` 恢复门；
+  用户管理改签发/撤销 Key（明文仅一次）。
+- Dev #504（`268ef29`）：合同文档 + 组件 pin。
+
+覆盖判定：R7/R8/R9 及 U5 的浏览器接线主体已实现；U7 的登录恢复事务部分已实现，
+**原子开户/引导、CLI 凭据安全交付与 PG 锁串行仍未实施**，U7 不得据此记完成。
+
+### 验收证据
+
+- GATE：Dev #504 HEAD CI 三作业（test / test-pg / svc-realcombo）success；Backend #187 CI success。
+  test-pg 即真实 PostgreSQL 运行本任务 store 测试（含 100 并发兑换单胜、登录竞态）。
+- SELF（收据，绑定 Dev HEAD `268ef29`）：真实浏览器全流程验收 PASS——
+  `login-key.playwright.ts` + `changepw-form.playwright.ts` 于隔离 auth-on 实例
+  （`serve --data /tmp/lr-e2e-data --auth on`，二进制 backend=467718a+frontend=9fc7da2）：
+  管理员签发 → 只输 Key 兑换 → 免旧密码设密 → 新密码登录进工作台 → 同 Key 重复兑换被拒。
+  收据 sha256：`be7ae9a2…`（验收）、`b3a9e691…`（终态）。用例文件待 Dev 工作区解封后入库。
+
+### 遗留（另行任务与授权）
+
+SSE 存量长连接断流通知；`e2e/login-key.playwright.ts` 入库与 Dev pin；U7 余量；
+部署与 live 账户验收。详见合同文档「遗留项」。

docs/proposals/2026-10-12-work-companion-ui-design.md

@@ -0,0 +1,176 @@
+---
+title: 面向非专业用户的工作台整体界面重设计
+revision: r0.2
+status: approved-for-continuous-implementation
+date: 2026-10-12
+owner: weichen
+scope: requirements-and-design
+implementation: implemented
+delivery: tracked-in-dev-task-record
+project-record: persisted
+---
+
+# 工作台整体界面重设计 r0.2
+
+用户在评审 r0.1 后明确授权“开始实施直到完成”。本稿 r0.2 保留已选设计，并通过本次独立任务连续实施、验证、Review 与合入。已有快慢通道执行方案的其他增量不由界面授权自动扩大。
+
+## 1. 设计目标
+
+让不懂命令、脚本、模型和代理的用户，通过表达目标、提供材料、查看结果、完成必要确认来推进工作。
+
+默认界面回答三件事：现在在做什么，已经得到什么，下一步是否需要我处理。用户能够只用对话完成主要工作，也能在需要时展开工作摘要、阅读文件、核对依据。
+
+用户明确要求：不要过于复杂；以辅助工作为中心；渐进、多层级展示；减少命令和脚本细节；大气、现代、简约、美观、易用。
+
+本稿的场景假设：主要工作包括材料整理、分析比较、问题审查和文档生成，兼顾日常问答。业务领域的具体审批和发布入口按当前服务端能力提供。
+
+## 2. 推荐形态与备选
+
+推荐**渐进展开的三栏工作台**。左侧找项目与历史，中间通过对话推进工作，右侧按需处理工作或文件。普通问答默认收起右栏，复杂工作时提供概览；用户手动收起后不因普通更新反复打开。
+
+| 形态 | 适用和取舍 | 本稿选择 |
+|---|---|---|
+| 渐进三栏 | 对话入口清晰，复杂任务可展开，文件有稳定位置 | 推荐 |
+| 纯对话 | 学习成本低；长文件、并行工作和多次确认容易淹没在历史消息中 | 作为轻量状态 |
+| 总览仪表盘 | 跨任务监控方便；默认要求用户理解更多指标和导航 | 仅在确有项目总览需求时另审 |
+
+不单独建设快通道页、慢通道页或后台管理页。新增功能先判断能否放进现有对话、工作和文件入口。
+
+## 3. 界面布局
+
+**左栏：上下文。** 项目身份集中出现一次；新建对话、最近对话、搜索；文件和已启用的领域工作区放底部；账户与个人设置沉底。管理员操作只由管理员入口提供。
+
+**中栏：推进工作。** 当前对话标题；用户的目标和材料；助手的结论、简短说明、必要动作；输入区上方一条工作状态。附件入口始终易找。权限设置保留清晰入口，展开说明其实际含义；初次使用采用现有默认值，不暗中扩大授权。
+
+**右栏：工作 / 文件。** 工作按需要你处理、当前关注的工作、其他进行中或排队、新成果排列。完成历史收纳后仍可找回。文件负责列表、预览、编辑和下载；全屏阅读是同一个预览的放大。来源点击也进入同一预览对象，定位能力不足时说明定位范围。
+
+左栏约 200–240，工作右栏约 320–420，中央弹性。正式落地继续消费已有拖拽宽度和文件阅读档规则。空间不足时先隐藏辅助栏；手机显示一个主视图，工作和文件按需打开，并有明确返回对话入口。
+
+## 4. 渐进展示层级
+
+| 层级 | 显示内容 | 打开方式 |
+|---|---|---|
+| L0 概览 | 后台工作数量、必要确认、新成果 | 一条状态行或小徽标 |
+| L1 摘要 | 业务目标、真实状态、当前工作、最多 3 条重要发现、缺项、下一步 | 当前任务卡或对话锚点 |
+| L2 依据与范围 | 阶段结果、来源、覆盖范围、未决问题和结论更正 | 原位置展开 |
+| L3 执行记录 | 按工作阶段分组的动作、结果和有权限查看的诊断信息 | 明确点击执行记录 |
+
+默认 L0/L1，不展开所有任务。必要确认、重要限制和失败影响不能藏在 L2/L3。L3 不是模型内部思考的展示入口，也不改变日志和来源的访问权限。
+
+示例任务卡：
+
+> 整理三份项目材料 · 进行中  
+> 正在核对：会议结论与需求说明  
+> 当前发现：上线时间出现两种说法；3 项需求缺少验收条件  
+> 待核查：评审意见中的补充要求  
+> 查看依据与范围
+
+没有阶段成果时诚实显示“尚无阶段结论，正在读取材料”。以上业务发现是示例数据，当前 U1 骨架并不证明已经具备真实阶段发现发布能力。
+
+## 5. 快慢通道的连续体验
+
+用户界面主要使用“助手正在处理”“后台继续整理”等业务语言。快通道是当前对话回合，慢通道是后台工作，不是由用户选择的快慢速度档位。
+
+| 时刻 | 用户看到的内容 | 表述边界 |
+|---|---|---|
+| 发消息或材料 | 接收结果、可先回答的内容、接下来处理的范围 | 已选文件不等于上传成功；解析不等于分析完成 |
+| 任务登记或排队 | 同一工作对象显示已登记、排队中 | 登记成功才能说已登记；未开跑不能写进行中 |
+| 工作进行中 | 当前工作、真实阶段结果、缺项 | 没有可信进度就不显示百分比或预计完成时间 |
+| 用户继续输入 | 后台继续工作时可继续对话；前台忙时说明消息排队 | 发送不等于即时执行，不承诺已改变正在跑的任务 |
+| 有新成果 | 更新原卡；重要结果提供一条对话通知 | 不逐条回投工具动作，不把所有任务复制成另一条聊天流 |
+| 等待用户 | 操作、范围、影响和明确选择 | 等待、执行、生成、用户认可和正式发布分开 |
+| 完成或失败 | 结论、最多 3 个要点、范围或缺项、文件和下一步 | 保存失败不得声称已交付；部分完成不能冒充完整结果 |
+
+后台更新不切换用户正在读的文件，不抢焦点，不把历史阅读强行滚到底部。状态恢复期间保留最后已知内容并注明“正在重新连接，最新进展待确认”。
+
+## 6. 按工作选择展示形式
+
+统一骨架保持稳定，内容形态随任务改变。默认由工作目的决定，用户无需先学习或配置一种展示模式。
+
+| 工作 | 默认成果形式 | 进一步展开 |
+|---|---|---|
+| 简单问答 | 一段结论，必要说明 | 依据与例子 |
+| 材料整理 | 主要结论、问题和缺项 | 材料覆盖清单、来源 |
+| 方案比较 | 一条建议、关键差异表 | 判断依据、取舍和适用条件 |
+| 问题审查 | 按影响排列的问题清单 | 原文、影响、处理建议 |
+| 文档生成 | 草稿文件、完成范围、需要评审的事项 | 文件预览与后续修订 |
+| 多步骤流程 | 当前阶段、已完成阶段、必要动作 | 阶段结果与历史 |
+| 用户确认 | 简明操作说明、影响、选择 | 参数与诊断详情 |
+
+图表仅在数量、趋势或关系能帮助判断时使用；可理解的短表不升级成图表。生成式任务页面作为可选增强，关闭插件后仍能通过任务卡、文字和文件读到主要结果。领域审批不能成为所有基座任务的固定步骤。
+
+## 7. 等待确认与异常
+
+确认卡先写操作及影响，例如“依据三份材料新增 1 份项目草稿，保留原件，不对外发送”。涉及覆盖、发送、发布或权限变化时，关键对象和影响必须在默认层显示。避免只有“是否执行”而没有范围。
+
+对话和右栏操作同一确认对象。提交中阻止重复提交；已处理同步更新；超时显示“正在核实处理结果”，查清后再允许后续动作。示例稿只演示本地状态同步，不证明服务端幂等和恢复。
+
+异常表述使用“发生了什么 → 对结果的影响 → 用户可以做什么”。例：“评审意见未能读取；已整理另外两份材料，完整结论尚未生成；可补充清晰版本或先讨论已有结果”。错误代码、脚本与输出置于授权可读的详情。动作只按服务端当前能力显示；未核验的暂停、独立取消、续跑、自动重试不进入默认设计。
+
+## 8. 视觉规则
+
+沿用 DESIGN.md 和 @ui/tokens.css：灰白表面阶梯、单色反色主按钮、发丝边框、克制语义色；清晰的标题与正文层级；常用信息保持可读，不以缩小字号装下所有内容。
+
+大气来自稳定分栏、整齐对齐、合理阅读行长和区块间距；简约来自减少同时出现的内容。没有营销式大标题、装饰渐变、速度表盘、满屏彩色卡片或默认工具日志。
+
+字型走 --fs-ui-*，界面字号可调。状态同时有文字和形状。折叠消费 @ui Collapsible，动效只用 mk-* 并响应减少动效。交互稿复制固定 UI 令牌，实际使用当前 Collapsible 源码与 MotionKit，不新建颜色和动效体系。
+
+## 9. 当前依据与依赖
+
+本轮只读源码核对，来源 SELF；没有对生产或当前 dev 服务作功能验收。
+
+| 对象 | 固定提交 | 核对点 |
+|---|---|---|
+| Dev | 4d362537d0e8755a03b1757b5bad92779a064b33 | DESIGN.md、policy/delivery.md、既有规划 |
+| Frontend | 1edd872c554f666ba43353da7e6f0605ecec311b | Workbench.tsx、Conversation.tsx、Workspaces.tsx |
+| Backend | acabb85e2ae970f834defae916c7539d0a47993d | spawnBackgroundOpts、CancelRun、createBackgroundCard、finishBackgroundCard |
+| UI | 83e80f5648649c3cc070f4dbc6bf118996828ae8 | tokens.css、Collapsible.tsx、motion.css |
+| Documents | 3cc6438030803b8e2355d2867766e9654203f265 | 快慢通道展示 r1.1 及 U1 实施计划 |
+
+当前读到的源码已有三栏“工作 / 文件”、前台忙时输入排队、后台并行限制、排队工作、精炼卡片骨架以及失败 CardFailed 映射。这里只说明源码形状，不推断已部署与运行表现。
+
+与既有方案衔接：`modules/documents/docs/proposals/2026-10-12-fast-slow-channel-display.md` 是快慢通道摘要与异步投影的已有主记录；本稿补充整体交互与各种成果形式，不另起一套状态或快照契约。U2/U3/U4 的真实阶段发现、持久恢复、确认闭环和窄屏完善继续以原记录及后续批准为准。
+
+## 10. 实施需求
+
+以下为本次界面实施与验收范围；实现消费真实已有能力，不伪造尚未发布的阶段发现。
+
+| ID | 需求 | 优先级 | 可判定的验收方向 |
+|---|---|---|---|
+| UI01 | 对话能完成主要工作 | P0 | 关右栏仍能读摘要、核对依据、处理确认、打开成果 |
+| UI02 | 普通问答保持轻量 | P0 | 无后台工作时不生成空任务卡和空进度条 |
+| UI03 | 默认内容可支持下一步 | P0 | 用户能说明当前工作、结果范围、必要下一动作 |
+| UI04 | 快慢通道连续展现 | P0 | 前后台并行、排队和完成状态归属正确且不重复刷屏 |
+| UI05 | 四层渐进阅读 | P0 | 默认无命令日志，关键限制和确认不被折叠藏起 |
+| UI06 | 成果按目的呈现 | P1 | 整理、比较、审查和生成各能支持对应工作判断 |
+| UI07 | 状态与动作忠实 | P0 | 不伪造进度，不暴露未支持控制，不把失败显示成功 |
+| UI08 | 同一文件同一预览 | P0 | 对话、来源、文件列表均进入同一预览位置 |
+| UI09 | 确认结果一致 | P0 | 双入口、重复点击、超时未知和已处理均有一致表现 |
+| UI10 | 阅读稳定 | P0 | 普通后台更新不抢焦点、换文件或改阅读位置 |
+| UI11 | 窄屏和大字可用 | P0 | 320/390/736/1024/1440 及 18px 字号必要动作可达 |
+| UI12 | 遵守设计系统 | P0 | 令牌、Collapsible、MotionKit、对比度守护符合规范 |
+| UI13 | 能力与权限匹配 | P0 | 未启用领域入口不显示；摘要与来源不绕过访问控制 |
+
+最终产品验收场景：三个附件无文字发送；前后台并行及排队；确认双入口；完整/部分/失败结果；查看来源与文件；刷新和断线；新对话；窄屏、大字、键盘及减少动效。r0.1 设计评审时，真实模型、真实后端和真实浏览器任务验收均为 NOT_RUN；实施期结果见第 13 节，示例交互稿不能代替验收。
+
+## 11. 落地次序建议
+
+1. **整体界面与文案。** 在既有三栏和 U1 上整理默认内容、必要操作和阅读路径。优先确定 UI01–UI03/UI05/UI08/UI12；不在此增量改变后台执行契约。
+2. **动态工作摘要。** 接续既有快慢通道 U2/U3，在真实快照与检查点之上显示业务发现、范围和恢复状态；避免另外安排重复任务。
+3. **成果形式与适配。** 衔接 U4，完成比较、审查、可选任务页面、窄屏和具体领域入口。先用结构化文字/表格，再增强生成式展示。
+
+r0.1 布局与展示已获连续实施授权，当前按 r1 计划交付界面。完成本增量后的首选衔接仍是既有快慢通道 U2/U3 的真实阶段发现与恢复验收；需先核对其在途任务和批准范围，不能由本界面任务重复启动或改变路由。
+
+## 12. 授权与实施记录
+
+来源：2026-10-12 用户在本聊天评审 r0.1 后指示“开始实施直到完成”。模式 authorized-continuous；阶段 1–10 在本稿界面范围内连续推进，平台门禁和高后果双钥匙保留。启动检查从已登记干净 Dev 检出捕获，后由 make task-start 创建 feature/work-companion-ui，并导入原始 SELF 收据。保护主检出的 Frontend 更新与其他任务现场。
+
+实施计划见 [r1](2026-10-12-work-companion-ui-plan.md)；进展和原始证据仅维护于 Dev .task/feature-work-companion-ui.md。PR、CI、Review、合入与部署分别记载，不因本授权预先标为通过。
+
+## 13. 实施进展与能力边界
+
+2026-10-12：渐进任务卡、轻量对话/输入、响应三栏和单一异步状态投影已形成可审阅候选。SELF 验证包括 Frontend 210 与 UI 155 单元测试、类型/设计守护/knip、Dev make test 与 make build；现有 Playwright 11 个展示场景、6 个移动导航场景及隔离 HTTP/MockRunner 2 个真实接口链路场景通过。原始命令、精确对象和完整输出以 Dev 任务卡为准，测试成功不推断已经合入或部署。
+
+原始独立代码 Review 已完成，必要问题均已有整改候选；最终精确版本复审、组合 CI 与合入进展只维护在 Dev 任务主记录，方案正文不复制第二份交付状态。UI 仓原 CI 在下载 GitHub action 时失败，交付补充改用既有平台固定 SHA 检出和 Node22 镜像，保留原测试；安全和规范 Review 及实际平台结果均须记录。
+
+动态摘要只消费系统发布的真实内容：缺少阶段发现时显示诚实占位，不生成示例百分比、ETA 或虚构成果。真实模型阶段发现质量 NOT_RUN，后台自动路由和模型提示词未在本增量修改。旧运行服务未更新；最终组合、Review、GATE 和本任务安全收口以 Dev 主记录为准。

docs/proposals/2026-10-12-work-companion-ui-plan.md

@@ -0,0 +1,154 @@
+# Work companion interface implementation plan r1
+
+> **For agentic workers:** Implement in independent units with ce-work native workers; the orchestrator owns integration, evidence, commits, Review and Gitea delivery. Use test-first coverage for behavior changes. User authorization: “开始实施直到完成”; continuous execution is limited to the approved interface design.
+
+**Goal:** Deliver the approved simple, modern, progressive workbench through real project, conversation, activity-card, confirmation and file APIs.
+
+**Architecture:** Keep the three existing pane responsibilities. Project existing ActivityCard bodies into readable summaries in the UI library; Frontend integrates them into conversation and work panes. Preserve server authority and harden event, query and action races in the one Frontend store. No new task executor, model routing, database schema or UI vocabulary is required.
+
+**Tech Stack:** React 19, TypeScript, existing @ui Collapsible/MotionKit/tokens, Vitest, Playwright, Go backend with existing API and SSE.
+
+**Spec:** [Approved interface design](2026-10-12-work-companion-ui-design.md), UI01–UI13; [existing fast/slow design](2026-10-12-fast-slow-channel-display.md), U1 skeleton and applicable presentation rules. Dynamic model-generated findings remain dependent on the existing U2/U3 work; this interface renders real available content and an honest placeholder otherwise.
+
+## Global constraints
+
+- Settled user decision: three pane workbench, conversation first, “工作 / 文件” in the same right pane, one preview object.
+- Settled user decision: concise default content and progressive depth; necessary confirmation and outcome limits stay visible.
+- Colors/radii/type consume @ui/tokens.css, type uses --fs-ui-*, motion only mk-*, folds use Collapsible.
+- No percentage, ETA, pause, independent cancel, resume or retry buttons unless supplied by a verified server action.
+- State is derived from real cards, runs, files and responses; no prototype example data enters production.
+- Model internal thinking and command parameters/output do not occupy the normal reading layer.
+- Main checkout and other task worktrees are protected. All owned changes live in feature/work-companion-ui.
+- Evidence uses the Dev make evidence tool. Local checks are SELF; current PR HEAD CI is GATE.
+- Component branches are based on their authoritative origin/main. Dev is based on R0 4d362537d0e8755a03b1757b5bad92779a064b33.
+- No deployment/restart of existing services, data migration, credentials or branch-protection changes.
+
+## Review focus
+
+1. Older SSE frames or delayed queries must not replace newer cards or inject data into a different conversation/project.
+2. Replay of a currently running conversation must still reconstruct its live output while duplicates are dropped.
+3. A confirmation submitted through either view must block duplicate submission and represent unknown results honestly.
+4. Closing auxiliary panes and opening files must leave necessary work and confirmation paths accessible at 320px and 18px UI type.
+5. New background results must not take over an existing file, focus or reading position; result summaries must retain failure and coverage limits.
+
+## U1 — Progressive activity cards and work groups
+
+**Own files:** UI src/ActivityCardView.tsx, src/InlineConfirmCard.tsx, src/InboxList.tsx, src/index.ts, src/ui.css, new src/activitySummary.ts, src/ProgressCardBody.tsx and focused UI tests. Do not change generated contracts or tokens.
+
+**Consumes:** Existing ActivityCard/UINode and DocBridge; U1 body keys 状态/正在做/当前发现/剩余/下一步. Unknown words remain supported by the generic renderer.
+
+**Produces:** Existing ActivityCardView remains source-compatible; export activitySummary/cardStatusLabel/groupActivityCards as pure projections. CardViewCallbacks and InlineConfirmCallbacks may add `actionState?: (card: ActivityCard) => 'submitting' | 'unknown' | undefined`; existing callbacks remain optional. Core vocabulary is unchanged.
+
+- [ ] Add tests for queued and running labels, modern failed and legacy done+danger, no-findings placeholder, internal material keys hidden by default, real document nodes still reachable, and confirmation buttons disabled for submitting/unknown.
+- [ ] Run the focused Vitest tests before production edits; record expected red assertions through evidence.
+- [ ] Build the projection with literal canonical body keys and card states; never interpret arbitrary output as a new execution fact.
+- [ ] Render L1 summary first, remaining body and source/range information in Collapsible, diagnostic metadata behind a nested explicit record entry. Known failure/remaining/next-step content must remain visible.
+- [ ] Keep unknown/legacy bodies intact in the generic detail renderer. Tables, structured lists and document references retain their current renderer.
+- [ ] Group unpinned work as needs-action, active, results, history, preserving order inside each group. Pinned items remain stable.
+- [ ] Simplify chrome; use text plus status shape and existing neutral surfaces.
+- [ ] Verify full UI suite, tsc and design/contrast guards; hand off files and red/green evidence without committing.
+
+Example behavioral expectation:
+
+```ts
+const queued = { ...card, status: 'active', body: [{ type: 'kv', kv: [['状态', '排队中'], ['材料键', 'mk_private']] }] }
+expect(cardStatusLabel(queued)).toBe('排队中')
+expect(groupActivityCards([completed, pending, queued]).map(g => g.key)).toEqual(['needs-action', 'active', 'results'])
+```
+
+## U2 — Conversation, input and inline work reading
+
+**Own files:** Frontend src/components/Conversation.tsx, src/components/ProcessTimeline.tsx, src/messageparts.ts if required by process policy, new src/components/ConversationWork.tsx, new src/companion-conversation.css, focused conversation/messagepart tests. Do not edit styles.css, App, Workbench or store.
+
+**Consumes:** Existing store fields and actions; existing UI ActivityCardView/Collapsible/DocBridge, including the additive actionState callback. The orchestrator supplies state.cardActionStates.
+
+**Produces:** ConversationWork renders current cards from the same store in an inline Collapsible; default ordinary Q&A has no empty progress. Component CSS imports live in the owned component file.
+
+- [ ] Add failing behavior tests for normal Q&A without progress, task summary reachable while right pane is closed, progress record folded by default, failure/limits visible, and process final answer outside its fold.
+- [ ] Replace command-oriented empty states with goal/material prompts and three optional natural-language examples that fill input rather than trigger hidden work.
+- [ ] Simplify header; keep execution profile, cross-reading and session settings inside a clearly labeled settings fold, preserving existing behavior and consent.
+- [ ] Keep add-materials and send visible; move permission selector into operation settings without changing its effective value. Explain queue state and upload failures in user language.
+- [ ] Show a light continuity line from real runs/cards with confirmed counts; inline work uses the same cards/actions as the work pane.
+- [ ] Fold tool parameters and output even during running by default; keep a compact real phase label and preserve manual expansion. Do not display model internal thinking as ordinary content.
+- [ ] Protect scroll reading and reset compose/expanded context correctly on conversation switches; do not remove artifact or rewind capabilities.
+- [ ] Verify focused tests and the integrated Frontend suite; hand off files and evidence without committing.
+
+Example behavioral expectation:
+
+```ts
+expect(showProcessInline(live, true)).toBe(false)
+expect(showProcessInline(live, false)).toBe(true)
+// Render real ConversationWork with zero cards: no progress object is produced.
+// Render with a real active progress card: summary is present independent of rightCollapsed.
+```
+
+## U3 — Responsive shell and context navigation
+
+**Own files:** Frontend src/App.tsx, src/components/TopBar.tsx, src/components/TaskSidebar.tsx, new src/companion-shell.css, new src/workbenchLayout.ts and focused shell/layout tests. Do not edit store, Conversation, Workbench, shared styles.css or UI.
+
+**Consumes:** Existing leftCollapsed/rightCollapsed/rightTab/previewExpanded and store pane/file operations. May add only local ephemeral responsive state, not another asynchronous task owner.
+
+**Produces:** Desktop three pane layout; narrow screen one active pane with clear contextual return actions, using the same Workbench/PreviewPane objects. Export a pure layout selector if a decision is needed for tests.
+
+- [ ] Write failing behavioral tests for single-pane navigation, restoring conversation, expanded file reading, and no hidden-only essential operation.
+- [ ] Match the approved calm prototype through spacing and type hierarchy, preserving canonical palette and default existing theme preferences.
+- [ ] Keep project identity on the left, conversation identity central, work/files on the right. Rename primary creation to 新建对话 where it actually creates a conversation.
+- [ ] Reduce duplicate permanent chrome; retain project creation/search/account/admin/available workspace paths.
+- [ ] Adapt to 320/390/736/1024/1440; hide/return controls remain keyboard- and touch-accessible. Do not let stored pane widths force horizontal overflow.
+- [ ] Keep file expansion as one preview enlargement, not another overlay or fourth pane.
+- [ ] Verify layout tests and report desktop/mobile screenshots after integration; hand off owned files without committing.
+
+## U4 — One state owner, safe updates and confirmation feedback
+
+**Own files:** Frontend src/store.ts, new src/eventProjection.ts if a pure helper is useful, src/components/Workbench.tsx, src/components/PreviewPane.tsx only when integration requires it, focused store tests. Orchestrator implements this unit.
+
+**Consumes:** Existing SSE event identity/seq/runId, conversation detail resumeSeq/lastSeq, cards API, project events, cardAction and resolveHITL APIs.
+
+**Produces:** Store `cardActionStates: Record<string, 'submitting' | 'unknown'>`; both work and inline confirmation callbacks read this same map. Current session/project cursors and query generation checks remain in one store.
+
+- [ ] Add red tests for duplicated and stale cards; delayed conversation/project list queries after switching contexts; foreground replay versus background agent notes; duplicate action submission; unknown response followed by a server query; new Surface while reading a file.
+- [ ] Guard event application by current context and per-stream applied sequence. Live replay uses its own replay cursor and never re-applies older card/plan/status projection effects.
+- [ ] Guard asynchronous queries by their requested context and generation/sequence so slow snapshots do not wipe newer events or another context's state.
+- [ ] Suppress background progress in foreground token output; update actual runs/cards instead of creating an unrelated LiveState.
+- [ ] Lock confirmation/action submission by card or HITL identity before awaiting. Clear on observed server outcome. Unknown results remain disabled until read-only reconciliation determines the current state; do not blindly resend an effect.
+- [ ] Show submitting and unknown feedback at both entrances. Preserve all server-supplied actions and their original scope.
+- [ ] Leave current file/Surface selection and explicit pane preference intact on background updates; show a small new-result cue rather than auto-opening.
+- [ ] Default new users to a light, compact conversation layout with right pane closed; keep saved theme/layout choices and explicit file opening.
+- [ ] Verify focused store tests, integrated Frontend tests, and browser cross-view flows.
+
+Example behavioral expectations:
+
+```ts
+store.applyEvent({ ...newerStatus, seq: 12 })
+store.applyEvent({ ...olderStatus, seq: 11 })
+expect(store.getState().cards[0].status).toBe('done')
+// Hold the first action response; call through the second view and assert one API request.
+// Resolve or query the real returned card and assert both views leave submitting together.
+```
+
+## U5 — Integration, browser acceptance and delivery
+
+**Own files:** Dev DESIGN.md, PROJECT.md, task card and exact gitlinks; Documents design/plan/index and delivery record; Frontend e2e/work-companion.playwright.ts and isolated browser fixtures if required; external screenshots and receipts.
+
+- [x] Record authorization and implementation units; retain original startup evidence unchanged.
+- [x] Integrate all workers, inspect owned paths and contracts, run authoritative focused tests, and commit logical component changes with Why/Evidence/Impact/Refs bodies.
+- [x] Update DESIGN §9.6 and information architecture to the approved progressive behavior; no palette changes are planned, so do not change canonical token values merely to create a paired diff.
+- [ ] Run make task-sync through evidence at acceptance, review and merge checkpoints; resolve any parent/component conflicts without altering unrelated owner work.
+- [x] Pin exact committed component revisions and run Dev make test plus make build through evidence.
+- [x] Browser checks: normal conversation; three selected attachments; background task plus foreground input/queue; pending confirmation through either entrance; done/failed/partial results; real file preview; reading preserved during update; duplicate/stale updates; refresh/switch; all five widths and 18px type.
+- [x] UI fixture-driven browser cases validate presentation only. Use an isolated real backend/browser smoke for API wiring, file/confirmation/card persistence where feasible. No mock model findings are reported as live-model acceptance.
+- [ ] Run required simplification and independent code review; fix findings, re-run affected checks, and record reviewer/object identity.
+- [ ] Push component branches, create and attach Gitea PRs, verify their current HEAD required CI and merge in dependency order. Update Dev pins to merged revisions, verify combination CI at current Dev HEAD, Review and merge Dev PR.
+- [ ] Fold/close only this task card under continuous authorization. Preserve or safely reclaim only owned workspace artifacts. Do not modify active main checkout state for other tasks.
+
+## Definition of done
+
+UI01–UI13 are mapped to observed source/tests/browser outcomes or an explicit inherited capability limit; no prototype fixture enters product state. All changed components compile and relevant tests pass. Current-head mandatory CI is verified before merge. Review findings are closed. The actual merged Dev combination and saved evidence are recorded. Existing running services remain unchanged; deployment is a separately identified operation.
+
+Continuous authorization covers implementation, verification, reversible isolation, documentation, commit/push/PR, agent Review/merge and task-specific safe closure. Stops apply to genuine scope changes, unowned content collisions, missing current-head platform gates and high-consequence dual-key operations. These conditions do not require re-approval of routine already-authorized work.
+
+## Delivery status
+
+2026-10-12: U1–U4 implementation candidates are integrated; U5 local combination and browser checks passed as SELF evidence. Original independent review is complete; the required fixes are implemented and locally verified. Final fixed-version review, current-head platform CI/merge and safe closure are tracked only in the Dev task main record; this plan does not maintain a second delivery-status copy. Code review may produce small corrective iterations; each has its own fixed object and relevant replay. The UI CI bootstrap repair is required to run the retained checks, not a waiver of them. Actual merged versions and final verification remain recorded in the Dev task card; no existing service is deployed by this task.
+
+2026-10-12 corrective candidate: UI0da2e3a / Frontend43d1933. SELF: UI155 and Frontend210 tests with type/knip checks, 11 presentation plus6 mobile-navigation browser cases,2 isolated realHTTP/MockRunner cases. The live attachment case now proves exact upload→send→persist associations across reload. The review repairs cover source links, per-option context, real browser scroll/focus, terminal reconciliation, action feedback ownership, explicit preview intent, latest outcomes and visible public explanations. These are interface and state-projection corrections; no live-model routing, prompt or existing-service deployment change. Final delivery facts are recorded in the linked Dev PR/task archive.

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

@@ -0,0 +1,247 @@
+---
+title: RDM 设置归属、成员、文档职责与权限矩阵完善增量方案
+date: 2026-10-13
+type: feature
+execution: code
+artifact_contract: rdm-increment-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1
+
+负责人：weichen；编制：ZCode；核对日期：2026-10-13（北京时间）。
+上游方案：[2026-10-12 RDM 功能、实现与计划矩阵及整改方案](2026-10-12-rdm-function-implementation-plan.md)（下称"总案"），本增量承接其本稿 U3、U4、U6，涉及职责一致性的部分衔接 U5。
+
+评审状态：2026-10-13 用户评审通过（同意方案及技术评审意见），并授权按本方案实施（P1–P8 两批推进；正式验收与清理回收节点保留人工确认）。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。
+
+## Goal Capsule
+
+以现有 RDM 实施总案的一个完整增量，先厘清设置归属和服务端权限，再补齐搜索、选择、职责分配与权限矩阵交互，保证界面显示、保存结果和实际执行一致。终点：创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存，且服务端边界（受管设置、成员校验、原子职责变更、权限范围）全部经真实请求验证。
+
+非目标：不扩展飞书集成、组织架构、多角色叠加或全量文档生成工程。
+
+## 一、当前实现与需要补齐的内容
+
+| 方面 | 当前源码情况 | 本次需要完成 |
+|---|---|---|
+| 设置归属 | 项目设置展示完整 schema；用户、项目设置都能覆盖模型等配置 | 设置作用域、管理员系统设置入口、写入与最终生效值双重约束 |
+| 成员管理 | 手填账号；已有分页账号目录，但只有账号和有效态 | 账号／姓名搜索、提示选择、下拉浏览、专业角色过滤、明确的项目身份修改 |
+| 文档职责 | 手填文档 ID 和人员账号；主要读取提交快照 | 文档搜索／列表／树选择、当前职责回填、项目成员选择、提交校验 |
+| 权限查看 | 已有单成员权限解释表 | 单成员详情与多人矩阵、中文标签、项目动作范围、上限内配置 |
+| 一致性 | 存在职责目标未校验成员、职责更新与审签失效分步执行等缺口 | 服务端统一校验、原子变更、版本冲突、撤权及历史保全 |
+
+对应实现锚点：Frontend `src/components/ProjectSettingsModal.tsx`、`src/components/adminRdmSections.tsx`；Backend `internal/settings/settings.go`（覆盖链 `defaults → system → user → project`）；RDM `plugins/rdm/plugin.go`、`internal/perms/perms.go`、`internal/rdmapp/docsubmission.go`。
+
+## 二、设置归属与界面结构
+
+沿用现有设置入口和 `SettingsShell`，项目设置收敛为四个页面：
+
+| 页面 | 内容 |
+|---|---|
+| 项目设置 | 真正属于本项目的共享配置与协作规则 |
+| 项目成员 | 成员搜索、添加、项目身份调整、移除 |
+| 文档职责 | 文档查找、职责查看与分配、相关审签状态 |
+| 项目权限 | 单成员权限详情、成员权限矩阵、允许范围内的配置 |
+
+系统管理中补齐“模型与服务配置”，承接主模型、轻量模型、Embedding、Rerank、模型密钥与 Tavily 等系统配置；Agent 工具限制、系统插件、全局专业角色和权限上限也归系统管理。个人设置只保留个人偏好。
+
+实施时需要处理三个层面：
+
+- **展示范围**：设置描述携带允许作用域、管理资格、生效时机；项目页面只消费项目项。
+- **写入范围**：用户／项目 API 拒绝写入系统受管项，包括嵌套字段和点路径形式，插件设置也遵守同一规则。
+- **实际生效**：旧用户／项目覆盖值不能继续影响系统模型；个人画像的模型路由及个人模型密钥也必须纳入受管校验，堵住其他覆盖入口。
+
+另外，当前“项目设置”实际上按“用户＋项目”保存（Backend `Effective(owner, projectID)`，project scope 物理存储在各 owner 名下）。需要区分：
+
+- **共享项目业务配置**：以项目为权威，同一项目不同成员读取一致。
+- **个人在该项目中的偏好**：继续属于个人。
+
+跨会话读取必须保留本人会话的隐私边界，不能因项目配置共享而开放其他成员的私聊、上传原件或个人草稿。
+
+## 三、成员管理交互
+
+采用**一个可搜索的人员选择器**，同时支持输入、提示选择和下拉浏览，不为每种途径增加独立页面。
+
+添加流程：打开人员选择器 → 输入账号或姓名，或浏览候选 → 可按专业角色过滤 → 选择人员 → 设置项目身份 → 添加。
+
+具体行为：
+
+- 输入账号支持精确匹配；姓名、账号支持模糊检索。
+- 未输入时显示分页候选；选择器内提供“全部专业角色／系统工程师／软件工程师……”筛选。
+- 候选显示“姓名、账号、专业角色”；同名人员通过账号区分，姓名为空时使用账号。
+- 已加入人员标记“已加入”，避免重复添加造成隐式身份变更。
+- 最终提交稳定账号标识，不能直接提交搜索文字。
+- 成员表分别展示“专业角色”和“项目身份”，不混用两者。
+
+项目身份使用“项目负责人／项目成员”等中文名称。成员行提供明确的“调整项目身份”和“移除”操作；继续保护最后一位负责人。
+
+服务端复用已有 `rdm.account.list`，补齐受限的姓名搜索、精确账号校验和专业角色摘要。**不能直接把管理员用户列表或包含全部账号绑定的角色管理接口开放给项目负责人。**
+
+角色筛选只帮助找到人员；项目负责人不能借此修改账号的全局专业角色。账号有效状态必须来自基座实际能力，不能把当前简单的 `valid=true` 当作完整的账号停用机制。
+
+## 四、文档查找与职责分配
+
+> 2026-10-15：本节的职责页交互（文档清单加选中详情、章节级入口、整文审签）已被
+> [文档职责矩阵整改 r2](2026-10-15-rdm-duty-matrix-rework.md) 取代。成员校验、版本冲突、
+> 在途审签确认和历史保全仍然有效。下文保留作被取代前的记录。
+
+文档职责页面采用“**文档清单＋选中文档的职责详情**”：
+
+- 上方提供统一搜索框，支持文档 ID 精确检索、标题精确／模糊匹配。
+- 支持文档列表与树形浏览；阶段、文档类型、未分配／已分配、审签状态可用于筛选。
+- 树形视图忠实呈现当前文档结构，只有文档节点可以作为职责分配对象，章节不能误作 `docId`。
+- 搜索、列表和树选择共用同一目录与选中状态。
+- 结果显示名称、阶段／类型、职责概况和状态；ID 保留为辅助定位信息。
+
+已有文档树查询属于审计面，不能降低它的授权规则来供选择器使用。应补齐专用的职责管理元数据读面：
+
+- 有职责分配权的管理者可以读取必要的管理元数据。
+- 普通成员只获得其有权查看的文档范围。
+- 标题、数量、筛选结果和树节点均在服务端过滤，避免通过搜索泄露不可见资源。
+
+选中文档后，立即读取并回填**当前职责**，包括尚未提交过审签的文档。当前职责与“某轮提交冻结的职责名单”分别展示，不能混为一份数据。
+
+人员选择规则：
+
+| 职责 | 选择方式 | 约束 |
+|---|---|---|
+| 编制人 | 搜索、下拉、专业角色过滤 | 单选 |
+| 审核人 | 搜索、下拉、专业角色过滤 | 多选，至少一人 |
+| 批准人 | 搜索、下拉、专业角色过滤 | 单选 |
+
+**所有候选只能来自当前项目成员。**保存时服务端再次校验账号、项目成员关系、对象归属、操作资格和职责版本；文档级（`rdm.review.assign.doc`）、章节级（`rdm.review.assign`）及旧命令入口均遵守同一规则。
+
+保留编制、审核、批准互异的规则。专业角色筛选不自动授予文档职责；管理权也不自动获得代编、代审或代批资格。
+
+职责变更需要补齐以下行为：
+
+- 在途审签受影响时，先显示受影响轮次与“需要重新提交”的提示。
+- 明确确认后，职责更新、在途审签失效和事件记录原子完成。
+- 保留旧冻结名单、审核记录和已批准历史，不把旧票带入新轮次。
+- 无变化保存保持幂等；并发修改返回明确冲突。
+- 移除仍承担当前职责的成员前，展示受影响文档并引导处理，防止留下无人可执行的职责。
+
+总案要求的批量分配放在同一文档清单中：勾选文档、预览统一职责方案、确认提交。首版采用有界批次，任一文档校验失败则整批不写入，并列出原因。
+
+## 五、单成员权限与多人矩阵
+
+“项目权限”提供两个视图，共享同一服务端权限解释：
+
+| 视图 | 默认行为 | 用途 |
+|---|---|---|
+| 按成员查看 | 普通成员查看自己；管理者可搜索其他成员 | 查看具体权限、配置来源和拒绝原因 |
+| 权限矩阵 | 管理者查看成员×项目动作 | 比较成员权限，发现缺失或差异 |
+
+矩阵支持成员搜索、专业角色／项目身份过滤、分页及权限分组。点击单元格可展开解释，显示角色默认、管理员上限、项目覆盖及结果。
+
+项目覆盖使用三态：沿用角色默认／项目内允许／项目内禁止。管理员上限禁止的动作不能通过项目覆盖授予；“恢复默认”需要实际撤销覆盖，不能用一个布尔值模拟。
+
+权限目录必须明确动作所属范围：
+
+| 内部标识 | 显示名称 | 所属范围 |
+|---|---|---|
+| `project.create` | 创建项目 | 系统角色权限，项目页面不出现 |
+| `member.manage` | 管理项目成员 | 项目 |
+| `duty.assign` | 分配文档职责 | 项目 |
+| `stage.advance` | 推进项目阶段 | 项目 |
+| `doc.read` | 读取文档 | 项目动作，具体文档仍须授权 |
+| `doc.write` | 编制与编辑文档 | 项目动作，仍受职责和状态限制 |
+| `knowledge.publish` | 发布项目知识 | 项目 |
+
+这个范围划分同时约束矩阵读面和覆盖写面：**不能只是隐藏 `project.create`，服务端也必须拒绝在项目中配置它。**
+
+权限名称、项目身份、来源、状态及拒绝原因统一使用人类可读文案。内部标识只保留在按需展开的技术详情中。
+
+同时核对每项权限与真实操作门禁。例如当前项目归档还有创建者／域管理员条件，矩阵解释必须反映真实条件。矩阵中的“允许编制文档”也不能意味着能修改项目内所有文档。
+
+普通成员自查权限的条件收敛为“当前有效项目成员”，避免文档读取权限被收回后，连自身权限与原因也无法查看。
+
+## 六、技术划分与实施工作包
+
+基座负责身份、基本资料、受管设置机制与通用契约；RDM 负责项目成员、专业角色、权限策略及文档职责；Frontend 负责业务交互；UI 仓提供通用选择器原语。
+
+| 工作包 | 内容与主要范围 | 依赖 | 完成条件 |
+|---|---|---|---|
+| P1 契约与需求固定 | 设置作用域、项目动作目录、人员／文档候选 DTO、能力与版本语义；更新关联方案 | 无 | 本次五项要求都有稳定验收条件，四类身份／角色／职责概念明确 |
+| P2 系统设置闭环 | Core 设置描述、Backend 设置 API／存储／生效链／模型及密钥解析；系统管理入口 | P1；**基座发版与 RDM/Dev 升 pins**（见评审补充 1） | 系统受管项只能由有权管理员配置，旧个人／项目值不能覆盖 |
+| P3 人员与成员接口 | 扩展公开账号搜索；RDM 专业角色摘要、成员查询、项目身份调整与提交校验 | P1；姓名来源核实（见评审补充 3） | 账号／姓名／角色过滤同源，添加与身份调整明确分离 |
+| P4 文档与职责接口 | 专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动 | P1、P3 | 跨项目／非成员指派被拒，职责与审签变更全成或全败 |
+| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员适配。文档职责页的文档选择器改由 r2 三视图承接 | P1，接线依赖 P3、P4 | 人员选择共享交互，无自由文本误提交。职责页交互见 r2 |
+| P6 权限解释与矩阵 | RDM 项目动作目录、单人／批量解释、覆盖三态、来源与拒绝原因 | P1、P3 | 矩阵与执行规则一致，系统动作无法写入项目覆盖 |
+| P7 项目设置集成 | 重构现有项目页，连接设置、成员与权限页。文档职责页改为 r2 的三视图，不再包含整文审签 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程。职责页验收以 r2 为准 |
+| P8 迁移与组合验收 | 旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填 | P2—P7 | 需求到证据闭合，无越权、隐私泄露或数据丢失 |
+
+前端主要改动落在现有 `ProjectSettingsModal`、`adminRdmSections`、`rdmManagement`、`api` 和 `store`；按业务拆分成员、职责及权限组件，避免继续扩大一个管理组件文件。
+
+目前 Dev 与 RDM 固定的 Backend 版本存在能力差异。实施时必须按公开契约推进相关版本，再完成组合验证，不能因为独立 RDM 仓已有某个接口就假定 Dev 组合可直接使用。
+
+## 七、界面与异步状态要求
+
+按根目录 `DESIGN.md` 实施，复用现有令牌、动效、设置外壳和折叠原语。
+
+- 一种对象只有一个主要选择路径，搜索和浏览在同一选择器完成。
+- 姓名、文档名为主要信息，账号和 ID 为辅助信息。
+- 下拉支持键盘移动、确认、关闭；审核人多选使用清晰标签。
+- 加载、空结果、权限不足、接口未装配、查询失败分别呈现。
+- 切项目、切文档、改筛选时清除不适用的选中项和结果；迟到响应不能覆盖当前对象。
+- 异步状态只有一个所有者，按请求代次／事件顺序丢弃过期结果。
+- 保存后读取服务端结果；网络断开且结果未知时先核对状态，避免盲目重放。
+- 未保存改动提供轻量离开提示；需重启的设置明确显示待生效，不能统一宣称即时生效。
+- 窄屏按成员查看权限，矩阵可横向浏览，不压缩成不可读的小格子。
+
+## 八、迁移、验证与交付安排
+
+旧配置先做脱敏盘点，列出配置路径、来源和冲突状态。不能任取某个用户／项目的模型配置提升为全系统配置。先确定并验证系统配置，再启用受管策略；旧值保留受保护的恢复依据，退出生效链。
+
+旧项目内 `project.create` 覆盖退出项目策略，保留历史依据。历史职责、审核与批准记录保留；无效的当前职责列入修复清单，不自动替换人员。
+
+正式验收至少覆盖：
+
+| 验收场景 | 预期结果 |
+|---|---|
+| 项目与个人设置写入系统模型项，包括手造请求 | 拒绝；旧覆盖也不影响运行结果 |
+| 账号、姓名、下拉、专业角色过滤查找成员 | 能找到并选择稳定账号；同名不会误选 |
+| 重复添加已有负责人、并发修改最后负责人 | 不发生隐式降级，不破坏负责人约束 |
+| 文档 ID、标题、列表、树查找 | 指向同一文档；章节及其他项目对象不能误提交 |
+| 搜索后人员被移出项目，再保存职责 | 服务端拒绝 |
+| 职责变更中途失败 | 职责、审签状态与事件完整回滚 |
+| 单成员详情与多人矩阵对照实际操作 | 结果与原因一致；具体资源限制清晰 |
+| 项目覆盖授予超上限动作或 `project.create` | 拒绝；恢复默认真正生效 |
+| 快速切项目／文档、断网、迟到响应 | 不显示旧对象数据，不误报成功 |
+| 同项目多成员使用、刷新及重启 | 共享配置一致，个人会话与原件仍私有 |
+
+验证分为领域与契约测试、真实 SQLite／PostgreSQL 集成、真实身份浏览器流程，以及 Dev 精确组合的 `make test`、`make build`。浏览器需要覆盖非管理员项目负责人、普通成员、互异的编制／审核／批准人员及两个项目；不能用全管理员账号代替权限验收。
+
+分两批形成可审查实现：先完成 P1—P4、P6 的服务端边界与契约，再完成 P5、P7 和 P8 的交互及组合验收。界面设计可在第一批同时评审。
+
+## 评审补充（2026-10-13 技术评审并入，随方案一并批准）
+
+1. **P2 显式依赖基座发版。** 受管设置机制是基座（Backend/Core）公开契约扩展，按总案交付顺序走“扩展申请评审→基座实现→基座发版→RDM/Dev 升 pins→组合验证”。P2 完成条件在原基础上追加：基座版本已发、pins 已升、Dev 组合 `make test` 通过。
+2. **项目共享配置的存储迁移规则。** 当前 project scope 物理存储在各 owner 名下；改为“以项目为权威”需要：新项目作用域存储、存量多 owner 副本的合并策略（默认规则：同键取最近写入时间，冲突清单列出不自动合并的键并交项目负责人裁定）、旧键退出生效链并保留只读恢复依据。P8 交付物含迁移清单与执行记录。
+3. **姓名来源与账号停用能力须先过 facts。** 基座账号目录当前明确“不含姓名/联系方式”。P3 的姓名搜索依赖基座账号模型是否存有姓名/显示名字段；P1 契约先定姓名来源（基座扩契约，或 RDM 专业角色档案补姓名）。账号停用机制现状同样按 `policy/facts.md` 登记验证，未证实前不把 `valid=true` 当作停用语义。
+
+## 顺序裁定（2026-10-13）
+
+本增量按自身 P1→P8 顺序推进；P2 的基座契约扩展按总案 369 行发版顺序执行，与总案 U1/U9 残余项的交织在扩展申请评审时统一排队，不因本增量跳过 U1（正式产物）与 U9（公开授权契约）的既有优先级。
+
+## 评审核查记录（2026-10-13，源码 3fb8210 / RDM 255f9cb）
+
+评审对方案“当前源码情况”逐项核查，全部属实：
+
+| 声明 | 证据 |
+|---|---|
+| 项目设置按“用户＋项目”保存 | Backend `settings.go` `Effective(owner, projectID)`，project scope 以 owner 为键 |
+| user/project 覆盖可改模型设置，无受管拦截 | 同上覆盖链，无“系统受管”概念 |
+| 成员手填账号 | `adminRdmSections.tsx` RdmMembersSection |
+| 账号目录仅 owner+有效态 | RDM `rdm.account.list` 描述“owner+有效态；不含姓名/联系方式” |
+| 职责手填 docId 与账号 | RdmDutiesSection placeholder |
+| 已有单成员权限解释表 | `rdm.perm.check`（动作/生效/来源/原因），前端默认自省 |
+| 权限标识与所属范围 | RDM `internal/perms/perms.go:21-31`，`project.create` 注释即“全局动作” |
+| 职责目标未校验成员 | `rdmReviewAssign` handler 注释“数据，非身份”——按 G1-5 旧裁定绕过成员校验；**本方案 P4 推翻该裁定，属规则变更，在 P1 契约中记录** |
+| 职责更新与审签失效分步 | 文档级 assign 先写职责再调 `InvalidateActiveDocSubmission`，两步顺序非原子；**章节级 assign 完全未接失效** |
+
+## 主记录与推进
+
+- 主记录：本文件（唯一正文）；任务卡 `.task/feature-rdm-increment-settings-duties.md` 承载需求表、证据与阶段结论。
+- 来源：`.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`（原始用户补充）、2026-10-13 会话评审。
+- 下一步：P1 已随本稿固定；按两批顺序进入 P2（基座受管设置契约扩展申请）与 P3/P4/P6 服务端实现。

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,21 @@
 本索引负责导航与差异提示，规划正文、批准范围和验收条件仍以链接的主记录及其批准版本为准。
 合入授权不批准新方向、不调整里程碑范围、不启动新的业务任务。
 
+待评审（收录不是批准）：[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。
+
 Generative UI 方向已收口（U1–U7 全部落地，2026-10-12）：[使用说明与评测记录](2026-10-12-generative-ui-usage-and-evaluation.md)（final）；
 主记录 [r2](2026-10-10-generative-ui-plugin.md) 与 [U5 动作范围 r2](2026-10-11-generative-ui-u5-action-scope.md) 保留为过程权威。
 
@@ -166,14 +179,32 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
 后续维护：主案或任务变化时先更新其唯一主记录，再更新这里的导航和核验快照。
 更换 Docs/Dev 基线后重新核对 PR、版本与在途任务；新的索引状态不自动产生实施授权。
 
+## 2026-10-13 规划补充
+
+- [最终验证与合入调度实施计划 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 规划补充
 
-- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。**2026-10-12 用户批准 r2（五阶段一并）**；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7；U2 首切片已由 svc-autorecover 任务合入 main（PR #396/#401，2026-10-11），余量按 KTD1/KTD2 对齐后续增量。
+- [svc 统一部署与一次性登录 Key 方案 r1](2026-10-12-svc-unified-deploy-and-login-key.md)：将 `svc.sh` 增强为二进制/源码统一部署入口，并补齐无初始密码开户与账户恢复；一次性登录 Key 只能兑换设密受限会话。r1 含源码复核与四项取舍定案；复用恢复方案 KTD 与已合入的 recovery U1（Dev #415）。**2026-10-12 已批准**（五阶段+U1/U4 规格）；r2 增补经 #87 合入；**2026-10-13 r3：登录恢复流程按用户「按此方案实施」批准并合入**（Backend #187 / Frontend #76 / Dev #504，浏览器验收 PASS；三裁定与实施记录见 §11）。规格与合同见 Dev `docs/svc-deploy/`。
+
+- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。**2026-10-12 用户批准 r2（五阶段一并）**；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7；U2 首切片已由 svc-autorecover 任务合入 main（PR #396/#401，2026-10-11）；U1 实例身份已合入（Dev #415，2026-10-12），余量按 KTD 对齐后续增量。
 
 ## 2026-10-11 规划补充
 
 - [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-12-lesson-http-multi-instance-vs-manager-tests.md

@@ -0,0 +1,11 @@
+# 经验：库级 Manager 测试通过 ≠ 跨实例 HTTP 路径正确——进程级黑盒才能抓住短路
+
+- 状态：validated（三条缺陷均在 U7 双进程验收中复现、修复并入 CI 回归）
+- 触发条件/检索词：多实例 / 跨实例 HITL / cancel / 命令总线 / Manager 层单测 / HTTP 黑盒 / 假成功 200 / conversation_id 空 / 落卡短路命令 / U5 vs U7
+- 根因与来源：协作存储 U5 用真库直接调 `runmgr.Manager` 覆盖争抢/围栏/命令语义，**绕过 HTTP handler**。U7 `tests/integration/multi-instance/` 起两个真实 `serve` 进程共享 PG 后抓出三条生产路径缺陷（均已有 backend 回归）：① HITL resolve 在非执行实例先把卡标 resolved，命令 fallback 的 `!card.Resolved` 判定被跳过，执行者永远等不到答案；② 跨实例 cancel 命令 `conversation_id` 传空串，消费侧执行权 JOIN 永不命中；③ `CancelRun` 在非执行实例无句柄时返回 nil，HTTP 层 200「假成功」吞掉命令路径。库级绿与进程级红可以同时为真。
+- 下次应做的检查：凡涉及「任意 API 实例发起、执行实例消费」的能力（取消、HITL、命令、租约接管），验收矩阵须含 **至少一条双进程 HTTP/SSE 黑盒**（或等价：经真实 handler + 命令总线落库再消费），不能只用 Manager/Store 直调冒充跨实例已过。写回归时优先钉住「非执行实例的 HTTP 状态码与执行者观测到的最终状态」成对断言。
+- 验证方法与防护：已落实——Dev `make test-multi-instance`（CI `test-pg` 必跑）覆盖跨实例读/SSE/409/HITL/取消/崩溃恢复/重启不变量；三条缺陷各有 backend 回归测试。建议保持：新增跨实例命令路径时先加进程级场景再声称 U5/U7 完成。
+- 适用与不适用：适用多实例共享权威存储、命令经 DB/总线投递的架构；不适用纯单实例本地句柄路径，也不替代库级语义单测（二者互补）。
+- 尚缺证据/防护：双主机（跨机网络）C3 与正式容量窗口不在本教训范围内；本条只固定「测试层级」缺口。
+- 复核人、日期、版本：weichen，2026-10-12；依据 Dev 放行检查单 A6/C1 与 `tests/integration/multi-instance/README.md`「已实测发现并修复的缺陷」
+- 替代/退役条件：若跨实例命令路径全部强制经同一 HTTP→命令总线集成测试门禁，且历史三条回归仍绿，可将本条降为参考；不得在无门禁时退役。

docs/records/2026-10-12-u7-capacity-window-report.md

@@ -0,0 +1,55 @@
+# U7 容量测量窗口报告（SELF，2026-10-12）
+
+来源标注：**SELF**（本机隔离栈执行；非 CI GATE、非独立 REPLAY）。不得单独据此放行第二实例写流量或双主机部署。
+
+## 1. 环境与被测对象
+
+| 项 | 值 |
+|---|---|
+| 主机 | Linux，32 逻辑 CPU，122 GiB RAM（约 98 GiB available），磁盘 1.9T/余 1.1T |
+| k6 | v2.3.0（Homebrew 固定位 `/home/linuxbrew/.linuxbrew/bin/k6`） |
+| 拓扑 | 双 `serve` 进程共享隔离 PG（`u7load`），`--tier team --auth on --mock --disable-exec-tools` |
+| Dev HEAD（任务分支测量时） | `b6f78b503ee2e3d6f71663d5330a18adbe743239`（ladder/s60 证据点；s2h 同工作区续跑） |
+| Backend gitlink | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` |
+| Documents gitlink（测量时） | `8d0810bd35f4934e0ad37fb96d7bab6d7a732473` |
+| 入口 | Dev `tests/load/collaboration/run_load.sh --seed contract --instances 2` |
+
+## 2. 数据集（B5 contract）
+
+每段窗口独立灌库（编排脚本每次 `DROP/CREATE u7load_app`，无法跨次复用）：
+
+| profile | results 目录 | messages | knowledge | seed 耗时 |
+|---|---|---|---|---|
+| ladder | `tests/load/collaboration/results/20261012-064730/` | 1 000 000 | 100 000 | ≈12.0 s |
+| sustained60m | `…/20261012-070510/` | 1 000 000 | 100 000 | ≈14.5 s |
+| sustained2h | `…/20261012-081025/` | 1 000 000 | 100 000 | ≈11.2 s |
+
+拓扑：10 seed 用户 × 5 项目 × 10 会话；约 10% knowledge `owner=''`（共享基座）；**未**写入 `knowledge_vectors`。
+
+## 3. 负载结果（阈值：读 P95≤300ms、P99≤1s、失败率≤0.1%；SSE P95≤1s；dup_seq=0）
+
+| profile | 读 P95 | 读 P99 | fail_rate | checks | expected_contention | SSE A p95 | SSE B p95 | dup_seq | orphan runs |
+|---|---|---|---|---|---|---|---|---|---|
+| ladder（10→30→100，~12m） | 15.5 ms | 44.3 ms | 0 | 134922/0 | 549 | 17.5 ms | 33.0 ms | 0 | 0 |
+| sustained60m（~60m @30 VU） | 3.9 ms | 6.5 ms | 0 | 504399/0 | 69 | 5.7 ms | 4.4 ms | 0 | 0 |
+| sustained2h（~2h @30 VU） | 6.2 ms | 13.5 ms | 0 | 1008771/0 | 477 | 3.9 ms | 4.2 ms | 0 | 0 |
+
+命令（每段）：
+
+```bash
+tests/load/collaboration/run_load.sh --seed contract --profile <ladder|sustained60m|sustained2h> --instances 2
+```
+
+原始产物（gitignore，留在任务 worktree `results/<ts>/`）：`k6-summary.json`、`sse-probe-a.json` / `-b.json`、`seed-manifest.json`、`invariants.txt`。任务卡经 `make evidence` 写入阈值复核脚本输出（SELF）。
+
+## 4. 结论与边界
+
+- **容量合同（B2/B3/B5/B4/C2）本机 SELF 全过**：阈值与不变量满足建议合同；数字绑定上表 SHA 与 results 目录。
+- **仍不放行第二实例写**：检查单要求 CI GATE 或独立 REPLAY 才用于放行；本报告仅为 SELF。C3 双主机、C4/C5 运维演练、B6 pgbench 未做。
+- **不承诺跨机/生产容量**：mock 模型、同机双进程、NVMe/本机 PG；换硬件或真实模型须重测。
+
+## 5. 建议下一步
+
+1. 独立审阅者 REPLAY 最小集（至少 `ladder --seed contract --instances 2`）后，方可讨论双进程写放行。
+2. 用户指定第二主机后跑 C3。
+3. 排期 C4/C5 运维演练；可选 B6 pgbench 只读基线。

docs/records/2026-10-12-u7-ops-drill-report.md

@@ -0,0 +1,100 @@
+# U7 运维演练与数据库基线报告（SELF，2026-10-12）
+
+来源标注：**SELF**（本机隔离栈执行；非 CI GATE、非独立 REPLAY）。用户 2026-10-12 决定不做容量重放。不得据此放行第二实例写流量。
+
+## 1. 被测对象
+
+| 项 | 值 |
+|---|---|
+| Backend gitlink | `8e509775d39d1455b69be44803037faa7af844b4` |
+| B6 Dev HEAD | `b2e129ab3f3bdf222f16040fcd0513872d0e2a3c` |
+| C4 Dev HEAD | `308f33665eb2dfaf9ae661e87df8898c3c2ecb3a` |
+| C5 Dev HEAD | `792574692609d9bfdf113e2dc5af6f43c9a176dd` |
+| 主机 | 32 逻辑 CPU，122 GiB RAM；演练开始时 load average 见各 `host.txt` |
+| 入口 | `tests/load/collaboration/run_pgbench.sh`；`tests/ops/run_fault_drill.sh`；`tests/ops/run_backup_drill.sh` |
+
+原始输出在测量 worktree 的 `results/`（gitignore），不入库。任务卡 evidence 为 SELF。
+
+## 2. B6 pgbench
+
+结果目录 `tests/load/collaboration/results/pgbench-20261012-131948`。隔离实例 `u7bench`，scale 100，每档 60 秒，`-M prepared`。`max_connections=100`，`superuser_reserved_connections=3`，100 客户端封顶为 95。六档失败事务均为 0。
+
+| 模式 | 客户端 | tps | P50 | P95 | P99 |
+|---|---|---|---|---|---|
+| select-only | 10 | 535646 | 0.018 ms | 0.024 ms | 0.030 ms |
+| TPC-B 类 | 10 | 18798 | 0.339 ms | 0.673 ms | 5.560 ms |
+| select-only | 30 | 952115 | 0.026 ms | 0.057 ms | 0.078 ms |
+| TPC-B 类 | 30 | 52224 | 0.493 ms | 1.002 ms | 1.777 ms |
+| select-only | 95 | 904708 | 0.087 ms | 0.180 ms | 0.417 ms |
+| TPC-B 类 | 95 | 50607 | 1.041 ms | 3.361 ms | 18.106 ms |
+
+主机不空闲。这是数据库参考基线，没有业务阈值，也不替代容量窗口。
+
+## 3. C4 断连
+
+结果目录 `tests/ops/results/fault-20261012-142734`。PG 18991，应用 18990/18992，Redis 18993。
+
+| 判据 | pg-stop | pg-kill |
+|---|---|---|
+| F1 有界失败、进程仍在 | 过 | 过 |
+| F2 不回落 SQLite，新进程拒绝就绪 | 过 | 过 |
+| F3 恢复后两侧各 5 次写入 | 过，RTO 不到 1 秒，未重启应用 | 同左 |
+| F4 失败 requestId 重放恰好一条 | 过 | 过 |
+| F5 dup_seq=0、seq 无洞、无非终态 run | 过 | 过 |
+
+Redis 限额 20 次/分钟，两实例各突发 40 个读：
+
+| 判据 | 结果 |
+|---|---|
+| G1 共享限额 | 放行 20、429 为 60、其他错误 0 |
+| G2 断连 | 放行 40、429 为 40、其他错误 0；已确认写入仍在 |
+| G3 只拉起 Redis | 放行回到 20；`rl:*` 均有过期时间 |
+| G4 | 发现：日志看不到降级计数 |
+| G5 | 发现：Redis 不通时新进程拒绝启动 |
+
+`runtime.redisAddr` 没有调用者可写的产品入口。演练用 SQL 写入默认 owner `local` 的 `user` 设置，并保留 mock。
+
+## 4. C5 备份与恢复
+
+结果目录 `tests/ops/results/backup-20261012-153441`。源 PG 18994，恢复目标 18997。合同数据量 seed 约 12 秒。
+
+| 判据 | 结果 |
+|---|---|
+| K1 备份有效 | 过。`failed_count=0`，`archived_count=80`，`pg_verifybackup` 与 `pg_restore --list` 退出码 0 |
+| K2 RPO≤5 分钟 | 过。64 秒 |
+| K3 RTO≤60 分钟 | 过。4 秒。恢复后登录、列项目、读会话均为 200 |
+| K4 工件与权限 | **FAIL**。五次上传都没有拿到工件编号 |
+| K5 不变量 | 过。dup_seq=0，seq 无洞；恢复后消息/事件/知识/run 计数与故障前一致（消息 1 000 120）；非终态 run 为 0 |
+| K6 逻辑恢复 | 过。`pg_restore` 退出码 0，约 4 秒；计数等于 dump 时快照（消息 1 000 000，知识 100 000） |
+| K7 权限与泄密 | 过。备份目录 700、文件 600；结果文本里没有连接串。静态加密与凭据演练记 N/A。归档和数据在同一块盘，没有模拟存储全毁 |
+
+恢复后的计数与故障前一致，说明已提交的标记都在。64 秒是最后一条成功标记的确认时间到故障时刻的间隔；窗口末尾有的写入因为会话仍被 mock run 占用而没有落库。
+
+K4 的原因在源应用日志：未设置 `BLOBSTORE_S3_ENDPOINT` 时，`NewS3FromEnv` 返回空的 `*S3`。这个空指针被放进 `blobstore.Store` 接口后不再等于 nil，`finishOpen` 不会回落本地目录，上传在 `blobstore.(*S3).Put` 空指针 panic。产品代码未改。因此工件 sha256 和跨用户拒绝没有测成。代码里本地后端的 `content_path` 是绝对路径；这次没有成功上传，所以没有用恢复后的下载来核验。
+
+同日另一次恢复（`backup-20261012-150713`）在数据目录复制之后起不来，因为 socket 路径超过 107 字节。正式这次把 socket 放到 `/tmp/u7bk-18997`。
+
+## 5. 放行（2026-10-12 当时）
+
+B6、C4 为 SELF 通过。C5 的库恢复为 SELF 通过，工件恢复失败。第二实例写流量仍不放行。
+
+当时还没做、该任务不启动的三项：
+
+- 独立 REPLAY，或把 C4/C5 的快速档接进 CI 成为 GATE（需要平台准入）。
+- C3 双主机。
+- 上传在未配置对象存储时 panic，需要单独的产品修复后才能重测 K4。
+
+## 6. 2026-10-13 K4 重测
+
+上传 panic 已在 store 边界修复：带类型的空对象存储（未设置 `BLOBSTORE_S3_ENDPOINT` 时的 `(*S3)(nil)`）视为未配置，回落本地工件目录。已构造的对象存储保持不变。Backend 提交 `46073d30`，Dev 被测头 `a83588dd`，backend gitlink 同为 `46073d30`。
+
+重跑入口仍是 `tests/ops/run_backup_drill.sh`。结果目录 `tests/ops/results/backup-20261013-013354`（SELF）。原始结果另存于仓外 `/home/weichen/projects/u7-k4-retest-preserved-20261013`。
+
+| 判据 | 结果 |
+|---|---|
+| K1–K3、K5–K7 | 过。RPO 65 秒，RTO 3 秒。`pg_verifybackup` 与 `pg_restore --list` 退出码 0，逻辑恢复约 5 秒，恢复后计数与故障前一致 |
+| K4 工件与权限 | **过**。5 个工件 `checked=5`、`missing=0`、`mismatch=0`。跨用户访问项目和工件均为 404 |
+
+`content_path` 仍是绝对路径，快照继续还原到原目录。静态加密、凭据演练和整盘损坏仍是 N/A。
+
+第二实例写流量仍不放行。剩下的门槛是独立 REPLAY 或经平台准入后的 C4/C5 CI 快速档，以及 C3 双主机。

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”在这三项中成立；没有可比历史基线，**不报告节省百分比**。自动模式须另行建设并验证原子持久领取、执行端旧代次拒绝、角色覆盖和异常接管，不能从本轮人工遵约推导已具备。扩大试行与预算调整留待用户阶段评审决定；本报告不替代该决定。