Record the U7 ops drill and advance the storage plan to r2.2

Why: B6, C4, and C5 now have same-host results, and the plan still said the ops drills were not done and that replay was the next step.
Evidence: Dev results pgbench-20261012-131948, fault-20261012-142734, and backup-20261012-153441 (SELF). The user declined a capacity replay on 2026-10-12.
Impact: Second-instance writes stay closed. K4 remains a product defect. Replay and C3 are not started.
Refs: feature/u7-ops-drills
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/guides/team-storage.md

@@ -0,0 +1,198 @@
+# 团队存储运行手册（协作存储 U1）
+
+适用范围：[协作存储与分布式方案](../proposals/2026-10-11-collaboration-storage-and-distribution.md) U1/U2
+（已批准，2026-10-11）落地后的 **team 部署档** 运维与验证。个人 `local` 档（SQLite）
+用法不变，见 [usage](usage.md)。本文是 U1 的固定部署清单、配置合同、迁移映射、
+容量合同、隔离测试方案与 KTD14 副本保护合同的单一事实源；实施状态以各任务卡为准。
+
+## 1. 目标实例与固定部署清单
+
+| 项 | 值 | 说明 |
+|---|---|---|
+| 部署形态 | svc.sh 管理的 `runtime/<name>` 实例 | 非容器；单机多实例按名隔离 |
+| 当前团队候选 | `runtime/dev`（8788，SQLite）→ 目标切 team 档 PG | 切换窗口与回退按方案 §6，须另行授权 |
+| 数据库（本机验证） | PostgreSQL 18.6 + pgvector 0.8.7（brew） | 本机验证用；正式实例待指定 |
+| 数据库（CI 门禁） | Ubuntu 24.04 apt：postgresql 16 + postgresql-16-pgvector | 版本以 CI job 输出为准 |
+| 缓存/限流 | Redis 8.10.2（本机）；CI apt redis-server | 只存可重建状态（KTD10） |
+| 应用制品 | `agent-system` 单二进制（make build） | 拷贝即运行；team 档需 `--tier team` |
+
+未知项（正式实例主机、pgvector 正式启用版本、对象存储选型）在正式切换授权前
+必须补齐；本清单不把本机验证环境当作正式部署事实。
+
+## 2. team 档配置合同（U2 已实施）
+
+启动语义（KTD1 fail-closed）：
+
+- `tier=team`：必须配置 `dsn` 且认证开启（`auth=on`；`auth=auto` 随 DSN 自动开）；
+  任一缺失**拒绝启动**。PG 打开失败**拒绝就绪**，绝不回落 SQLite。未配置执行隔离
+  （`disableExecTools` 或 `execBackend`）时启动警告（多用户开放前必须补齐）。
+- `tier=local`：SQLite；配置 `dsn` 是配置错误，拒绝启动。
+- `tier` 缺省（auto）：现状语义——`dsn` 非空走 PG，否则 SQLite。
+
+配置键（四源合并：默认 → 文件 → 环境 → 显式 CLI，与 usage §启动一致）：
+
+| 键 | env | CLI | 语义（team 档） |
+|---|---|---|---|
+| `tier` | `AGENT_SYSTEM_TIER` | `--tier` | `local` / `team` / 空=auto |
+| `dsn` | `AGENT_SYSTEM_DSN` | `--dsn` | PG 连接串；team 必填 |
+| `auth` | `AGENT_SYSTEM_AUTH` | `--auth` | team 档要求最终为 on |
+| `instance` | `AGENT_SYSTEM_INSTANCE` | `--instance` | 空=主机名:监听地址（多实例必须互异） |
+| `pgMaxOpen` | `AGENT_SYSTEM_PG_MAX_OPEN` | `--pg-max-open` | 每进程最大连接（默认 16） |
+| `pgMaxIdle` | `AGENT_SYSTEM_PG_MAX_IDLE` | `--pg-max-idle` | 每进程空闲连接（默认 8） |
+| `pgConnMaxIdleSec` | `AGENT_SYSTEM_PG_CONN_MAX_IDLE_SEC` | `--pg-conn-max-idle-sec` | 空闲回收（默认 300s） |
+| `pgConnMaxLifetimeSec` | `AGENT_SYSTEM_PG_CONN_MAX_LIFETIME_SEC` | `--pg-conn-max-lifetime-sec` | 连接寿命（默认不限） |
+| `pgQueryTimeoutSec` | `AGENT_SYSTEM_PG_QUERY_TIMEOUT_SEC` | `--pg-query-timeout-sec` | statement_timeout 秒（默认不限） |
+
+连接预算（KTD12）：预算覆盖全部 API/Worker/LISTEN/migrator/监控连接；
+100 在线用户 ≠ 100 连接。`agent-system config explain` 输出脱敏有效值
+（DSN 密码打码）。启动日志打印 `storage tier: team (dialect=postgres pool=… schema=v…)`。
+
+迁移（KTD8，U2 已实施）：DDL 与版本登记同事务（中途失败整体回滚，不存在
+「表已建、账本未记」中间态）；PG 并发迁移者按会话咨询锁串行化；SQLite 写事务
+`_txlock=immediate` 跨进程排队。库内出现比二进制新的 schema 版本时拒绝启动。
+
+## 3. 迁移映射（SQLite → PG，U4 工具消费）
+
+| SQLite 侧 | PG 侧 | 备注 |
+|---|---|---|
+| `agent-system.db`（WAL） | 同名逻辑库 | 活跃 WAL 不能只拷 `.db`；一致性备份用 VACUUM INTO |
+| INTEGER 0/1 布尔列 | BOOLEAN | v9/v10/v11 起双方言已分型 |
+| `INTEGER PRIMARY KEY AUTOINCREMENT` | `BIGSERIAL`/`SERIAL` | events、command_audit、audit_events |
+| FTS5 虚表 + 触发器 | tsvector 生成列 + pg_trgm GIN | v4；中文子串走 trigram |
+| `vec BLOB` | `BYTEA` | pgvector 类型切换在 U6，不在本映射 |
+| `<data>/artifacts/` 工件对象 | 本期仍本地目录 + PG 清单 | 共享对象存储在 U5/U9 |
+
+RDM 独立业务库与旧 Agent-System 治理库**不在**本映射内；迁移工具（U4）只处理
+Backend 库，非空目标拒绝、同快照才可续传。
+
+## 4. 容量合同（验收目标，非性能结论）
+
+方案 §3 的量化指标（100 在线 / 300 SSE / 20 执行中 Agent / P95≤300ms 等）是
+**待验证合同**。区分两个计数：**接纳的 run 数**（进入队列）与**执行许可**
+（同时真正执行，含子代理、初始全局 20、每用户 2、索引 4）；等待子代理/HITL 的
+父 run 让出执行许可、保留会话所有权。压测在 U7 执行并绑定组件 SHA 出证。
+
+## 5. 隔离测试库/目录/端口方案
+
+| 资源 | 约定 | 生命周期 |
+|---|---|---|
+| 本机 PG 实例 | `scripts/svc.sh db create collabtest --port 8897 --tag test` | svc.sh 管理；用毕 `svc.sh collabtest stop` + `rm --purge` |
+| 测试库/扩展 | 库 `agent_test`；`pg_trgm` 预装 public | 测试辅助幂等预装；CI 启动步显式预装 |
+| 用例 schema | `t_*` / `pgbus_*` 前缀，随机名 | 每用例建、Cleanup 级联删 |
+| 本机 Redis | `redis-server --port 6399 --save '' --appendonly no` | 纯内存、用毕即停 |
+| CI | job `test-pg`：apt 安装 PG16+pgvector+Redis，端口 5432/6399 | 每次 PR 必跑；缺服务失败不跳过 |
+
+本地跑真实库门禁：
+
+```bash
+export AGENT_PG_TEST_DSN="$(scripts/svc.sh db dsn collabtest --db agent_test --reveal | tail -1)"
+export AGENT_REDIS_TEST_ADDR=127.0.0.1:6399
+make test-backend-pg
+```
+
+禁止对共享/现役实例（如 `runtime/dev` 的库）跑测试；DSN 不入命令历史与任务卡。
+
+## 6. KTD14 副本保护与保留合同
+
+- 备份/导出/WAL/测试副本使用专用数据库角色（非应用角色），存放于受限目录
+  （0700，非工作区）；传输与静态备份加密，解密材料存独立受管秘密存储。
+- 保留期限：迁移演练副本用毕即删，最长 7 天；正式备份保留 30 天滚动 +
+  每月 1 份年度副本（待正式实例指定后确认）。
+- 日志/报告只留统计与哈希：不落 DSN、密钥、文档正文；测试一律用脱敏数据。
+- 恢复演练：每次演练恢复到新目标并核对应用可用与权限/文件完整性；
+  「备份命令成功」不等于可恢复。
+- 阻塞项：正式导出前，未知 owner 的数据、未定位的权威文件、缺失的保留期限
+  任一存在即阻塞（不静默继续）。
+
+## 7. 暂态 Worker 文件分类
+
+| 类 | 内容 | 处置 |
+|---|---|---|
+| 可重建 | 构建产物 `bin/`、`node_modules/`、测试数据目录、`__pycache__` | 随时删除重建 |
+| 必须迁移 | SQLite 库、`artifacts/` 工件、`.agentx/checkpoints.jsonl`、Squad FileStore/续跑标记 | U4 迁移 + 联合备份；U5 前禁止跨机接管 |
+| 只读参考 | svc.env（600）、history.jsonl | 保留在实例目录，不入副本外流 |
+
+## 8. 已知边界（诚实清单）
+
+- CLI 子命令（apikey/user 等）不校验 tier；team 档语义只在 `serve` 入口强制。
+- 迁移仍随启动执行（已原子 + 锁化）；完全独立的 migrator 入口留待 U4 工具。
+- 多实例安全**未**因此声明（R4/U5）；本档只交付单实例 team 档与真库门禁。
+- pgvector 扩展已安装 ≠ 启用；向量检索仍是应用内扫描（U6）。
+
+## 9. 执行预算与动作授权（U3 切片 2 已实施）
+
+### 执行许可（admission，R8）
+
+- 设置键：`runtime.execBudgetGlobal`（全局并发执行上限，含子代理；0=不限，
+  默认）、`runtime.execBudgetPerUser`（每租户上限；0=不限）、
+  `runtime.execQueueMax`（待执行队列上限，默认 200）。数值为容量合同初值，
+  U7 压测后调整。
+- 语义：会话回合与子代理同池计数；账本在数据库（`admission_leases`，PG 咨询
+  锁下原子清点），多实例天然共享；队列满时 API 在落库前 429（不写数据）；
+  父 run 同步等待子代理或等待 HITL 时让出执行许可、保留会话所有权，恢复
+  执行重新获取——额度占尽时父子不互等。
+- 接纳与执行分别计数：队列深度（接纳）与活跃租约（执行）是两个量，
+  诊断分别看 `Manager.QueueDepth()` 与 `store.ActiveExecutionSlots()`。
+
+### KTD13 动作授权矩阵与公开契约兼容计划
+
+矩阵（宿主侧 `server.ProjectAction`）：
+
+| 动作 | 语义 | 未注册 action-aware 时 |
+|---|---|---|
+| read | 读取项目资源（会话/消息/检索/下载） | 回落旧 EXT-8 只读适配器（兼容现网） |
+| edit | 写入与修改 | **默认拒绝** |
+| approve | 审批（HITL/命令确认） | **默认拒绝** |
+| execute | 触发执行 | **默认拒绝** |
+| admin | 管理 | **默认拒绝** |
+
+规则：action-aware 适配器（组合根注入 `SetProjectActionAuthorizer`）注册后
+对全部动作权威、出错 fail-closed；旧只读适配器不得自动获得写入能力。
+
+**公开契约兼容计划**（后续版本落地）：以版本化扩展把动作级判定并入
+EXT-8 的 `ProjectAuthz` 公开契约（新增 action 参数的变体接口 + 契约版本号），
+下游适配器按动作逐一声明能力；未声明动作保持默认拒绝，与宿主侧矩阵同语义。
+旧 bool 契约在该版本内继续可用（映射为仅 read）；Core/Host 与下游适配器
+（RDM 的 ProjectAuthz 实现）一起验收，不另建成员权威。
+
+## 10. SQLite → PostgreSQL 切换与恢复演练（U4 已实施）
+
+工具：`make build` 产出 `bin/storage-migrate`（受管迁移入口；只处理 Backend 库，
+不执行 SQLite dump 作为 PG SQL）。三个子命令：
+
+```bash
+# 1) 只读盘点：schema 版本、完整性、逐表计数、工件清单与哈希（§6.1）
+storage-migrate inventory  --source runtime/dev/data/agent-system.db \
+                           --artifacts runtime/dev/data/artifacts --out inv.json
+
+# 2) 一致性快照：VACUUM INTO（在线安全含 WAL）+ 可打开校验 + 逐表计数对账（§6.2）
+storage-migrate backup     --source runtime/dev/data/agent-system.db --out snap.db
+
+# 3) 受管迁移：目标建 schema/扩展后按行复制；身份登记 + 逐表校验和 + 终验（§6.3）
+storage-migrate migrate    --source snap.db --target "$DSN" \
+                           --migration-id <名> --artifacts runtime/dev/data/artifacts --out report.json
+```
+
+迁移身份与续传：`migration_id + source_snapshot_id（快照 SHA-256）+
+source_schema_version` 登记在目标 `migration_control`；**仅同一冻结快照可续传**
+（换快照/换身份均拒绝）；目标业务表已有数据而身份为空即拒绝（不覆盖）。
+
+校验与报告：逐表源/目标计数与主键序哈希链校验和（布尔列按目标 schema 对称
+归一）；复制后推进 SERIAL 序列；未知 owner（users 之外，''/'local' 单租户默认
+除外）阻塞迁移；报告只含计数/校验和/清单哈希——无 DSN、密钥与行正文（KTD14）。
+类型映射以目标 schema 为准（SQLite 0/1→BOOLEAN、BLOB→BYTEA、生成列不迁、
+FTS5 影子表不迁——PG 侧生成列与索引自动重建）；`admission_leases` 为运行态
+不随迁。
+
+### 切换顺序（正式窗口须另行授权；当前仅隔离演练已验证）
+
+1. 固定源制品与路径，`inventory` 盘点；指定迁移 owner、窗口、回退判据。
+2. `backup` 冻结快照（活跃 WAL 库不得只拷 `.db` 文件）。
+3. 预演：独立测试目标 PG 上 `migrate`，核对报告全绿；预演库不作为正式目标。
+4. 正式窗口：停新写 → 等待/收口在途 run（未知副作用记 recovery hold）→
+   停旧写者 → 终快照 → 空正式目标 `migrate` → 报告全绿。
+5. 单入口切 team 档冒烟（登录/项目/会话/审批/检索/下载）；fail-closed 不回 SQLite。
+6. **PG 接受新写入前**可撤回；**之后**禁直切回旧 SQLite（向前修复或专项回迁）。
+
+备份基线（正式目标启用后）：pg_dump 逻辑备份 + pg_basebackup 物理基础备份与
+WAL 归档/PITR；pg_dump 不能作 WAL 回放基础。每次演练恢复到新目标并核对。

docs/guides/usage.md

@@ -36,7 +36,7 @@ agent-system config explain [--config envs/prod.json]   # 只读诊断：逐字
 agent-system version
 ```
 
-启动参数四源合并，优先级从低到高：**内置默认 → 配置文件（`--config`，显式 JSON，无自动发现）→ 环境变量（`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`）→ 命令行**；未显式传入的命令行参数不参与覆盖，删除 override 恢复继承。字段：`addr`（监听）、`data`（工作区根目录）、`plugins`、`dsn`（空 = 嵌入式 SQLite 档，非空 = PostgreSQL 档）、`artifacts`、`auth`（auto/on/off）、`mock`；未知键与类型错误在启动时定位报错，不静默失效。
+启动参数四源合并，优先级从低到高：**内置默认 → 配置文件（`--config`，显式 JSON，无自动发现）→ 环境变量（`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`）→ 命令行**；未显式传入的命令行参数不参与覆盖，删除 override 恢复继承。字段：`addr`（监听）、`data`（工作区根目录）、`plugins`、`dsn`（空 = 嵌入式 SQLite 档，非空 = PostgreSQL 档）、`artifacts`、`auth`（auto/on/off）、`mock`；未知键与类型错误在启动时定位报错，不静默失效。team 部署档（`tier`/连接预算键）与真实数据库门禁见[团队存储运行手册](team-storage.md)。
 
 **多环境启动**——仓库自带隔离示例 `envs/{dev,test,prod}.json`（data 根与 DB 互不重叠）：
 
@@ -44,6 +44,7 @@ agent-system version
 agent-system serve --config envs/dev.json    # mock 开、./data-dev
 agent-system serve --config envs/test.json   # 127.0.0.1:8788、./data-test
 agent-system serve --config envs/prod.json   # PostgreSQL 档、auth on、独立卷
+agent-system serve --tier team --dsn "$DSN" --auth on   # team 档：缺 DSN/未认证拒绝启动，PG 故障拒绝就绪（见团队存储手册）
 AGENT_SYSTEM_CONFIG=/etc/agent-system.json agent-system serve   # 环境变量定位文件
 ```
 

docs/proposals/2026-10-07-rdm-phase-plan.md

@@ -9,6 +9,8 @@
 
 ---
 
+> 2026-10-11 补齐候选：[最终目标核对与完整交付方案](2026-10-11-rdm-final-target-completion.md)按本轮用户确认及 RDM d8d7e743 重新映射项目/隐私/三权、全部模板与 34 UR／68 SR／10 F。该方案待评审；本页历史快照和原始证据保留，不能据其旧完成声明推断最终验收。
+
 ## 1. 大方向与大目标
 
 ### 1.1 一句话目标

docs/proposals/2026-10-10-agent-delegation-routing-sandbox.md

@@ -193,9 +193,9 @@ sha256/mtime 清单复核，不可当作完整快照。
 | E1（P0 快修）✅ | F1 委派回传、F2 reasoning_split、F5 并行工具、F3 依赖层 | 无 | **已完成（2026-10-10）**：Agent-Native #42/#43/#44 + Backend #127 + Dev PR（任务卡 feature/agent-e1-parallel-fixes）。验证：F2 实测正文 0 泄漏、F3 sandbox 实测 IMPORTS-OK、F5 实测同回合并发重叠；eval 对照工具失败 19→11，未核实数字 7→12（E3 待做，见任务卡） |
 | E2 | R1 Claude 原生协议 + 缓存观测 | E1（F2 同类协议改动可同批） | dmxapi 需充值 |
 | E3 ✅ | D4 证据账本 + 数字闸门 | 无（接质量计划 P5） | **已完成（2026-10-10）**：Backend #130、Dev #311（任务卡 feature/agent-e3-evidence-gate）。标注感知豁免（分句判定）+ 两轮修正（变化才二拦）+ base.deliverables v6 数字溯源规则 + 子代理引用格式；eval 对照未核实数字 12→5（未标注 3）、工具调用 93→63 |
-| E4 | R2 角色路由 + D5 画像 | E2 | 设置与画像面 |
+| E4 ✅（R4+账本） | R2 角色路由 + D5 画像 | E2 | **R4 与账本已完成（2026-10-11，MiniMax 版）**：Backend #131–#134、Dev #315（任务卡 feature/agent-e4-escalation-ledger）——滑窗失败提醒（端到端日志实证）、检索空命中提醒、source_id 账本（83 标记）；Claude 角色档按模型指示暂缓；eval 四轮对照无恶化 |
 | E5 ✅（R3 部分） | R3+R4 路由 A/B 与升级规则 | E2–E4 | **R3 已完成（2026-10-10，MiniMax 家族版）**：Dev #313（任务卡 feature/agent-e5-model-ab）三臂对照（hs / 全M3 / hs+M3轻量）——建议默认 chat=MiniMax-M3（未标注编造 1、失败最少、时长持平、单价减半）；R4 升级规则仍待做 |
-| S0（仅记录） | §4 工作区沙箱设计定稿为独立实施任务 | 用户批准启动 | 本文即主记录 |
+| S0-1 ✅ | §4.4 首个落地形态：冻结基底 overlay + CAS 回收 + 变更摘要（--exec-workspace overlay） | 用户 2026-10-11「继续完成下一步」 | **已完成（2026-10-11）**：Backend #135/#136、Dev #318（任务卡 feature/agent-s0-workspace-overlay）——bwrap 集成 3 + live 端到端（失败零落地/新增/修改/-ws 清理）；S0-2（fs 联合读/任务级工作区/封存）待授权 |
 
 ## 6. 与既有规划的关系
 

docs/proposals/2026-10-10-generative-ui-plugin.md

@@ -0,0 +1,537 @@
+---
+title: Generative UI research and plugin proposal
+date: 2026-10-10
+type: feat
+revision: r2
+product_contract_source: user-request-and-current-source
+---
+
+# Generative UI 调研与插件方案
+
+确认状态：**三项关键取舍已由用户裁定（2026-10-11，见文末"用户裁定记录"）**；全文随发布 PR 评审。推进状态：方案成稿并进入发布评审；原型、业务实现、运行验收、部署均为 **NOT_RUN**。
+来源：2026-10-10 用户请求——先调研参考与仓库，再判断能否加入本系统，给出可随时启禁的插件方案。
+负责人：裁定与验收 weichen（用户）；方案整理与执行 Agent；更新时间：2026-10-11。
+本文是唯一主记录；任务卡引用本文。文内路径除相对链接外，均相对 Agent-System-Dev 根目录。
+用户授权本轮调研、思考和完整方案准备，不表示已批准本文的产品取舍、原型试验或后续实施。
+
+## 结论与目标
+
+**可以加入，而且当前系统已有合适基础。推荐新增独立的 Generative UI 插件，配合小范围、通用的宿主能力扩展。**
+Agent 负责决定何时需要页面、采用哪些组件、怎样排列内容与交互；宿主负责设计系统、身份权限、事实读取、渲染、动作执行和恢复。
+页面结构可以每次不同，组件实现与权限规则保持确定。
+
+首选路线：复用现有 Agent-Native、Go Backend、Core UINode 和 React UI；以版本化 Surface 表达可保存、可更新的动态页面。
+借鉴 A2UI 的组件目录与数据/交互协议，以及 json-render 的 catalog/registry 分工；首期不要求替换现有运行时或另起 Node 服务。
+外部 renderer 是否比扩展现有 UIRenderer 更划算，由受控试验决定，当前没有实际集成证据。
+
+建议先覆盖对话产出的完整阅读/分析页面，再加入交互表单与任务工作页，最后扩展到项目工作区。
+登录、项目切换、停止执行、设置和审批保留可预测的宿主入口；业务主内容可以动态组织。
+该演进顺序已于 2026-10-11 获用户确认：首试点为对话中的完整分析页（场景 1）；它不把长期目标缩减为“几个固定卡片模板”。
+
+插件首期采用**可信 Go 编译扩展 + 声明资产**（该交付方式已于 2026-10-11 获用户确认）：功能开关实时生效，安装/升级插件代码需要重新构建组合二进制并重启。
+“功能随时启禁”与“无需重启安装任意插件包”是不同能力；用户未把后者列为本期硬要求，sidecar 路线保留为备选并随实际需求重评。
+
+---
+
+## 外部调研
+
+调研日期：2026-10-10。引用来自官方文档或官方源码，说明的是当场文档/仓库状态；本轮未安装或运行这些项目。
+不以 star 数量、演示视频或作者自述推断生产可靠性；正式选依赖时仍须固定版本、审许可证与传递依赖并进行组合验证。
+
+### Generative UI 的不同层次
+
+| 类型 | Agent 实际决定什么 | 与本目标的关系 |
+|---|---|---|
+| 固定工具结果组件 | 调用什么工具、向预制组件传什么参数 | 适合起点，但单独使用不足以实现自由组织页面 |
+| 声明式生成页面 | 组件树、布局、内容重点、数据绑定与动作引用 | 本方案主路线；页面可变，执行边界明确 |
+| 可持续交互的生成工作区 | 页面随用户输入、任务进展和数据版本变化 | 本系统中期目标；需要状态、版本、权限与回放协议 |
+| 生成 HTML/JS/React 小应用 | 连组件实现和程序逻辑一起生成 | 表达力高；需独立沙箱、资源与网络边界，后续单独评估 |
+
+运行时按任务生成页面，与开发期间让 Agent 写前端代码不同。后者交付后仍可能是固定页面。
+AG-UI 这类事件协议、A2UI 这类 UI 描述协议、MCP Apps 这类嵌入式应用契约解决的层面也不同，不能互相替代。
+
+### 核心参考与采用判断
+
+| 参考/官方仓库 | 能力定位 | 本系统采用判断 |
+|---|---|---|
+| [A2UI](https://github.com/a2ui-project/a2ui) / [文档](https://a2ui.org/) | 声明式组件、Surface、数据绑定和用户动作；组件目录可映射自己的设计系统 | 最值得借鉴的协议。Go 可产生 JSON，前端可保持自身 UI。是否严格实现某版本，留给独立适配器与一致性测试 |
+| [json-render](https://github.com/vercel-labs/json-render) / [Catalog](https://json-render.dev/docs/catalog) | 为 AI 定义组件与动作词汇，由 registry 绑定真实 React 等实现 | 最值得试验的 renderer 依赖；可将目录映射到 @ui。不能未经比较就再建一套状态和渲染系统 |
+| [CopilotKit](https://github.com/CopilotKit/CopilotKit) / [AG-UI](https://github.com/ag-ui-protocol/ag-ui) | Agent 与应用之间的流式事件、状态与交互集成 | 参考工具 UI、共享状态和事件设计；现有系统已有 runtime/SSE/store，首期不整体替换。AG-UI 本身不定义完整页面布局 |
+| [Vercel AI SDK](https://github.com/vercel/ai) / [Generative UI 指南](https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces) | 工具调用与结果驱动组件渲染，应用开发者实现组件 | 很好的最小入门与工具组件范例；不是整页自主规划的全部方案，不为此把 Go 后端迁到 TypeScript |
+| [assistant-ui](https://github.com/assistant-ui/assistant-ui) / [生成 UI 文档](https://www.assistant-ui.com/docs/tools/generative-ui) | 除工具 UI 外，当前有 present 工具生成组件 JSON 树、动作注册与流式 props | 借鉴显式 present 入口；不必替换聊天壳。官方明确 renderer 不按 props schema 执行校验，仍需自己的运行时验证 |
+| [Thesys OpenUI](https://github.com/thesysdev/openui) / [现行文档](https://www.openui.com/docs) | OpenUI Lang、parser、React 流式 renderer 与自定义组件；Crayon 旧仓已转向该仓 | 作为表达能力/流式体验备选。可用自己的模型；开源 runtime 与可选 OpenUI Cloud/Gateway（原 C1）分开评估，不把开源许可等同托管服务条款 |
+| [Tambo](https://github.com/tambo-ai/tambo) | 注册 React 组件与 schema，Agent 选择组件并更新状态；包含后端编排 | 设计参考。官方已公告 Tambo Cloud 将于 2026-10-31 关闭 API，2026-11-30 删除托管数据；开源可自托管，但不建议作为新系统的默认托管依赖 |
+| [MCP Apps](https://github.com/modelcontextprotocol/ext-apps) | 工具返回交互式 UI resource，宿主通过桥接在隔离容器内嵌应用 | 适合未来插件小应用与外部工具 UI 互通；它不自动生成页面，也不代表现有 Agent-Native MCP 工具支持已具备 Apps 宿主能力 |
+
+A2UI 官方主页当前列出 v0.9.1 为 current、v1.0 为 candidate；它的 [catalog 指南](https://a2ui.org/concepts/catalogs/) 建议成熟应用围绕现有设计系统定义目录。
+已有[官方 React renderer](https://a2ui.org/reference/renderers/)；这证明有实现可供验证，不证明该版本已经在本系统构建/运行通过。
+不能混合旧 v0.8 的消息字段和新版本字段后声称协议兼容。
+json-render 的 [registry 文档](https://json-render.dev/docs/registry) 将组件实现与动作处理留在应用侧，适合本系统“生成数据、宿主执行”的边界。
+Tambo 的停服状态以[官方仓库公告](https://github.com/tambo-ai/tambo#readme)为依据，旧教程中的 Cloud 快速接入方案已不适合作为新项目默认选型。
+
+许可初筛：A2UI、json-render、AI SDK 为 Apache-2.0；CopilotKit、AG-UI、Tambo、assistant-ui、OpenUI 的当前仓库为 MIT，具体包及附带资产在锁版本时再核对。
+[MCP Apps LICENSE](https://github.com/modelcontextprotocol/ext-apps/blob/main/LICENSE) 处于 MIT 向 Apache-2.0 迁移，部分旧贡献保留 MIT，文档另有 CC-BY-4.0，不能统一简写为“任选双许可”。
+当场仓库活动检查未发现上述候选被归档；活动不等于稳定或维护承诺，Tambo Cloud 公告说明需要把代码可用与运营持续性分开判断。
+AI SDK 的 [RSC 路径仍为实验状态](https://ai-sdk.dev/docs/ai-sdk-rsc/overview)，首期没有理由为此将现有 Vite 应用迁到 Next.js/RSC。
+
+### 三条可行路线
+
+| 路线 | 优点 | 主要代价 | 结论 |
+|---|---|---|---|
+| A. 原生 UINode/Surface 插件 | 复用权限、Agent、事件流、设计系统与部署形态；无强制新服务 | 要补齐 schema 校验、版本、交互和启禁 | **首选** |
+| B. json-render/A2UI renderer 嵌入插件 | 利用现成组件目录、绑定和流式能力 | React 集成之外还需 Go 校验、动作授权、版本与状态适配；可能重复 UIRenderer | 受控试验中的挑战方案；显著减少总维护成本才采用 |
+| C. 隔离的代码生成小应用或整套平台 | 表达力最高，适合复杂专用工具 | 沙箱、网络、会话桥、制品供应链、依赖升级和审计面明显增加 | 后续独立方向，不作为首个增量 |
+
+路线 A 不是从零重造外部框架：首期范围只包含本系统用得到的有限词汇、快照、授权动作和页面容器。
+若需求发展为大量复杂表单、表达式和跨平台 renderer，重新比较 B；不要不断扩展内部 DSL 以维持最初选型。
+
+---
+
+## 当前系统的可行性依据
+
+以下为 **SELF·源码级观察**，不是运行能力验收。审计基线为 Dev `104a4142c918f7325d3a78e3e6e270e46739baea`。
+
+| 组件 | 固定 SHA |
+|---|---|
+| Core | `a253a40b8e5563119b00c4e71fb61fe0d11d6d6a` |
+| Backend | `017b40f76156905eabe8323ae2bfe800f47fb8bd` |
+| Frontend | `339a9ebc2d827eaf990346b91d36f4ad5a13f090` |
+| UI | `76d6633736a7abb36ac1ecca42fe4e6f120d0558` |
+| Agent-Native | `c348441691e8bdab784a03aa9be64d53dacff341` |
+| Documents | `3a82eec74ce6b2b548a7a943f8382d64df14316e` |
+
+| 当前源码事实 | 依据（上述固定版本） | 设计影响 |
+|---|---|---|
+| React 19、Vite 6；Core 已有 16 种有限 UI 词汇 | `modules/frontend/package.json`；`modules/core/ui.go:9-50` | 不必另换技术栈或设计系统 |
+| UIRenderer 能画 table、compare、tabs、timeline 等 | `modules/ui/src/UIRenderer.tsx:22-35` 及各 case | 动态选择和组合已有组件有基础 |
+| submit_card 的 body 仍是字符串，包装成 Markdown | `modules/backend/internal/runtime/hostbridge.go:128-148` | 当前 Agent 还不能通过这个工具输出任意结构化页面 |
+| form 没有提交回传，节点按数组 index 作为 key；table 行 action 未渲染 | `modules/ui/src/UIRenderer.tsx:22-29,73-95,184-200` | 有类型不等于完整交互；稳定 nodeId、草稿与动作桥必须补 |
+| 卡片 body 渲染未传 onAction | `modules/ui/src/ActivityCardView.tsx:66-74` | 不能只把按钮塞进 body 就声称接通动作 |
+| cardsvc 有保存与事件发布；运行管理有卡片端口 | `modules/backend/internal/cardsvc/cardsvc.go:73-139`；`internal/runmgr/runmgr.go:637-715` | 复用其分层与持久化后发布原则，避免第二条无审计通道 |
+| 上下文回灌仅取卡片顶层 markdown/kv | `modules/backend/internal/ctxasm/ctxasm.go:373-411` | 需要递归语义投影；否则下一轮 Agent 不知道页面里有哪些内容 |
+| SSE 服务端先订阅再重放并按 seq 过滤；前端没有完整拒旧/切会话保护 | `modules/backend/internal/server/server.go:375-429`；`modules/frontend/src/api.ts:189-194`、`store.ts:375-414` | Surface 投影须明确 seq、revision 与 generation 防卫 |
+| enabled 写入 owner+plugin grants，主要被 ListFor 消费 | `modules/backend/internal/server/platform_api.go:130-142`；`internal/store/platform.go:13-32`；`internal/plugins/host_v2.go:160-175` | 现有“禁用”不能当作请求/执行禁用；新能力必须服务端闭环 |
+| ESM loader 存在，但未找到实际页面挂载调用；桥未接主认证/命名事件处理 | `modules/frontend/src/pluginHost.ts:9-13`；`modules/ui/src/pluginSdk.ts:9-25` | 首期不能依赖现成 ESM 页面宿主；动态 import 也不是代码沙箱 |
+| 公开扩展可注册命令 handler，命令可 exposeAsTool | `modules/backend/pkg/extension/extension.go:34-48`；`internal/cmdbus/cmdbus.go:47-64`；`internal/app/app.go:417-422` | 插件命令可供现有 Agent 调用，无须新增任意 native executor 插口 |
+| 公开 Host 缺会话/任务完整上下文及 Surface 发布端口 | `modules/backend/pkg/extension/host.go:26-68` | 需申请最小公开契约，不能从插件导入 Backend internal |
+
+现有 context assembler 可复用消息、附件、可见知识和用户偏好；不等于已经自动读取所有项目背景。
+跨会话读取仍须满足现有开关、同项目/租户与隐私限制（`internal/runmgr/runmgr.go:934-1005`）；生成页面不能扩大数据可见范围。
+当前 `Host.Complete` 是简单 prompt→string，且主要走 owner 路由，不能当作已有 project 级结构化/流式生成接口。
+
+本轮阅读了规划索引、基座路线图、插件 v2 与扩展兼容相关记录；没有发现既有 Generative UI 专项主记录。
+2026-10-10 本轮查询 Dev/Documents/Core/Backend/Frontend/UI 的 open PR，结果均为空；这是当时快照，后续开工须重验。
+规划索引中的 Agent 质量、模型路由、RDM 扩展仍有剩余范围，不因没有 open PR 就视为全部完成或不冲突。
+
+---
+
+## 需求与用户体验
+
+### 需求表
+
+所有实施需求当前为候选，待人工确认。符合度“需调整后符合”表示本方案指出了必需宿主改动，不表示已实现。
+
+| ID | 需求与来源 | 符合度 / 优先级 | 可判定验收条件 | 处理与依赖 |
+|---|---|---|---|---|
+| R1 | 根据内容、上下文、任务、项目背景自主组织页面（用户） | 需调整后符合 / P0 | 同一组事实分别完成“比较、风险分析、进度查看”，生成不同且合适的结构；不是同模板换标题 | 纳入试点；U1/U3/U4 |
+| R2 | 以插件封装，随时启禁（用户） | 需调整后符合 / P0 | 禁用后 UI、直接 API、旧按钮、在途发布均受控；原有系统仍可用；重启后保持禁用 | 纳入首期；U2/U3/U4 |
+| R3 | 页面可追溯事实与来源（本系统约束） | 符合 / P0 | 数据值来自授权数据引用；分析结论标为生成判断；能定位材料与版本 | 纳入首期；U2/U3 |
+| R4 | 使用本系统设计系统、易用且可访问（DESIGN） | 符合 / P0 | 令牌/动效/折叠守护通过；键盘与窄屏可完成主要流程；唯一预览落位 | 纳入首期；U4 |
+| R5 | 页面可保存、刷新恢复、版本可解释（长期工作流） | 需调整后符合 / P0 | 刷新恢复已保存视图；同版本可确定渲染；断线、旧帧与切项目不串页 | 纳入首期；U2/U4 |
+| R6 | 用户继续修改页面，Agent 理解当前结构（用户目标的闭环） | 需调整后符合 / P0 | “改为对比、突出风险”生成新 revision；上下文包含结构、来源与已确认用户输入 | 纳入首期；U3/U4 |
+| R7 | 动态表单和动作，沿用权限与审批（扩展交互） | 需调整后符合 / P1 | 表单可提交、校验、重试；旧 revision/越权/重复动作受控；必要审批不能由模型伪造 | 后续增量；U5 |
+| R8 | 任务/项目工作区随阶段组织（用户长期目标） | 需调整后符合 / P1 | 当前任务可组织计划/产物/待决策信息；项目聚合符合跨会话读取权限；固定布局可恢复 | 后续增量；U6 |
+| R9 | 外部协议可演进，禁用不丢历史（可维护性） | 符合 / P1 | 固定 schema/catalog/插件版本；不兼容时静态/文本降级；旧动作不自动重放 | U2/U7 |
+| R10 | 有真实收益与成本证据（交付规范） | 符合 / P0 | 对照固定 UI 的任务成功率、耗时、事实错误、延迟和 token 成本；真实模型结果可复核 | U1/U7；当前 NOT_RUN |
+
+### 三个试点场景
+
+1. **调研和文档分析页**：比较多个方案时，Agent 组织“结论→对比表→证据→风险”；用户改问实施顺序后，调整为阶段与依赖。数据与判断分开，来源能打开原工件。
+2. **当前任务工作页**：需求阶段突出待澄清项，执行阶段突出步骤和产物，验收阶段突出验证结果与缺项。完成状态取自真实任务记录，模型不能画一个绿色标记就更改任务状态。
+3. **方案选择和需求表单**：Agent 根据缺失信息组织输入项；用户填写后形成明确的结构化输入，再触发下一轮。表单提交不自动批准其后所有业务操作。
+
+首个完整增量以场景 1 为主；保留场景 2/3 的契约扩展空间，但不要求同时交付所有交互。
+普通文本回答仍是有效结果；没有可视化价值时 Agent 应保持文本，不强行生成页面。
+
+### 页面落位与自主程度
+
+对话中的卡片是生成页面的入口与简短摘要，完整页面进入现有预览位置的 Surface 模式；全屏是同一实例的放大。
+预览区关闭时，用户仍能从对话入口打开或在对话中继续操作，遵守 DESIGN 的“右栏收起零功能缺失”。
+之后的项目工作区只是同一 Surface 的另一种打开入口，不复制另一套事实与状态。
+可以保留多份页面，活动预览只有一个；新结果不抢占用户当前打开的其他对象。同一 Surface 的入口聚合到同一实例，用户从对话引用选择历史页面。
+
+建议提供三档产品行为：关闭；按需生成；自动建议/生成。
+首期默认关闭，启用后按需触发；用户明确请求页面时直接生成，Agent 在复杂比较/时间线等任务中可自主选择组件与结构。
+自动触发只监听明确任务阶段/材料完成等语义事件，后续增量再开启；不按每个 token 或每条 SSE 事件重排页面。
+用户可以固定布局、切回原视图、重新组织；“固定布局”冻结结构，授权范围内的数据仍可更新，需显示数据时间。
+用户正在输入、选择或执行动作时，结构更新暂存并提示应用，不挪动焦点或覆盖草稿。
+
+---
+
+## 架构与关键决策
+
+### KTD1. 插件策略与宿主执行分离
+
+插件拥有组件使用策略、生成提示、布局选择、schema 修复策略、试点场景与质量评估。
+宿主拥有授权上下文、持久化、稳定渲染容器、请求鉴权、事件序列、动作执行和插件启禁。
+通用组件实现归 UI；契约归 Core；前端投影与导航归 Frontend；Backend 实现受限公开接口。
+新目录/仓库位置建议为独立 Generative UI 组件仓，在 Dev 固定组合中引用；正式建仓和最终名称待实施前确认。
+
+```mermaid
+flowchart TB
+    A[用户任务与展示偏好] --> B[既有 Agent Runtime]
+    C[宿主授权上下文与组件能力] --> B
+    P[Generative UI 插件策略与命令] --> B
+    B --> D[插件 present 命令：声明式页面]
+    D --> E[宿主校验与 Surface 服务]
+    E --> F[保存快照与事件]
+    F --> G[Frontend 唯一状态投影]
+    G --> H[SurfaceHost 与 UI Renderer]
+    H --> I[用户交互]
+    I --> J[宿主动作校验与命令总线]
+    J --> B
+    K[插件启禁与资源权限] --> C
+    K --> E
+    K --> J
+```
+
+### KTD2. 复用现有 Agent，不增加独立 UI 模型调用
+
+首选由当前工作 Agent 根据插件提供的能力目录，通过公开命令的 `exposeAsTool` 生成并提交页面规格。
+插件命令可概念性分为“读取可用展示能力/上下文”“提交或替换页面”“恢复原视图”；准确命名在接口评审中确定。
+页面规格由主 Agent 作为工具参数产生；插件负责校验与发布编排，无需默认再调用一次 `Host.Complete`。
+工具返回已接受的 Surface/revision 与语义摘要，或者带字段路径的有限校验错误；后者允许原 Agent 至多重提一次。这会增加原回合的模型轮次，必须计入成本，不能宣称零额外 token。
+因此插件可以自主组织页面，而不接管主 Agent 的对话循环、模型凭据或任务执行权。
+后续只有真实评测显示收益，才加入专用 UI planner 或轻量模型修复；届时单独定义 project 级模型路由、预算与取消接口。
+
+### KTD3. Surface 是有版本的呈现产物
+
+方向性数据模型（不是已实现接口）：
+
+| 层 | 必需内容 | 权威来源 |
+|---|---|---|
+| 身份信封 | surfaceId、owner、projectId、conversationId、sourceRunId、pluginId | 服务端分配/从当前请求绑定；模型不能自报 owner |
+| 兼容标识 | schemaVersion、catalogVersion、pluginVersion、rendererCompatibility | 已安装组件与宿主协商 |
+| 版本 | revision、baseRevision、contextVersion、activationEpoch | 服务端事务与当前授权状态 |
+| 页面 | title、稳定 nodeId、受限 layout、UINode 内容及结构 | 模型提议，服务端验证 |
+| 数据 | resourceRef、源版本、字段白名单、读取时间 | 宿主解析后的授权数据 |
+| 交互 | 服务端保存的 action binding、参数 schema、执行级别 | 命令目录与当前授权；模型仅引用允许动作 |
+| 回放 | semanticText/结构摘要、来源、生成用途、静态降级文本 | 服务端递归投影为主，不能只信模型自述 |
+
+首期采用完整、经过校验的快照原子替换，不渲染半截 JSON，不把流式 token 当作结构更新。
+revision 单调递增，更新必须带 baseRevision；版本冲突拒绝并返回当前版本，不自动覆盖他人更新。
+发布以当前身份、插件、sourceRunId、toolCallId/发布请求 ID 建幂等键，重复工具结果返回已保存 revision，不能生成重复页面；相同键但不同规格拒绝。
+复杂的流式 patch、表达式求值和跨页面组件引用均后置；若后续引入 patch，必须保留同样的原子性与版本检查。
+现有卡片保存 Surface 引用与文本摘要，不把一份可交互页面同时复制进卡片 body、工件和工作区三处。
+
+持久化建议增加宿主通用 Surface 及 revision 记录，支持现有 SQLite/PG 档位；按 owner/project/conversation 建权限索引。
+页面快照、最小 action binding 与待发事件在同一事务落盘，再由宿主事件管道发布；发布失败靠持久事件或重建快照恢复，不能只依赖内存总线。
+业务实体仍由原业务服务维护，Surface 不成为项目/任务事实的第二份数据库。
+新表采用增量迁移，默认关闭功能时不影响老路径；回退应用不删除表和用户产物。保留周期沿用所属会话/工件策略，最终清理策略随数据契约评审，不在开关中隐式删除。
+
+### KTD4. 上下文是授权后的事实快照
+
+宿主根据当前身份和请求，提供任务目的、当前会话摘要、项目允许读取的背景、指定工件、相关检索结果、用户展示偏好与允许动作目录。
+浏览器只提供关注对象 ID 和偏好，不能提交可信权限声明或任意数据库查询。
+先按权限过滤再裁剪；只按当前任务相关度取必要字段；不直接将整个项目、原始系统提示或敏感凭据塞入模型。
+材料与工具结果作为不可信数据处理，不能覆盖组件目录、开关或动作权限；页面内容里的指令不能自行触发后续动作。
+上下文快照记录源版本与裁剪情况；缓存必须包含身份、权限版本、项目/会话、源版本、catalog 和配置，不按问题文本跨用户复用。
+已有跨会话读取限制保持有效；缺少授权时只生成当前会话范围的页面，并明确范围。
+
+事实字段尽量采用宿主数据绑定，展示值由服务端解析；模型生成的解释、建议和风险判断显式属于分析内容。
+快照记录完整来源集合，包括自由文本分析的来源。读取/导出/回放时任一来源权限失效，首版拒绝整份旧快照并提供重新生成入口，不能只隐藏引用链接而继续显示泄露内容。
+下一轮上下文提供经过权限复核的结构摘要、来源和确认过的交互结果；不只回灌 markdown/kv，也不把前端未提交草稿当作用户指令。
+禁用插件时不再注入生成策略/动作能力；历史语义内容按正常授权保留为普通文本上下文。
+
+### KTD5. 组件目录约束表达，不固定页面模板
+
+首期选取已有 section、markdown、kv、list、table、compare、timeline、steps、chart-lite、doc-ref；需要时扩展受控 row/grid 布局。
+每个节点必须有稳定 ID；组件目录定义 props、嵌套、数据类型和支持的动作，禁止任意 CSS、脚本、eval、远程组件 URL。
+只允许语义尺寸/密度/强调枚举，映射 @ui tokens；新视觉规则按 DESIGN 与 UI gitlink 组合变更评审。
+渲染器采用既有 safeHtml、Collapsible 和 motion 原语；表格提供溢出与分页/截断提示，不能静默丢数据。
+未知组件或版本产生可见降级原因与文本视图；未知动作一律拒绝。不能沿用“未知节点静默消失”作为新 Surface 成功状态。
+
+初始试验上限建议：每页 200 节点、8 层嵌套、256 KiB 规格、单表首屏最多 100 行；值为待测的资源预算，不是既有性能承诺。
+同时限制字符串、数据总量、图表点数、解析时间和外部资源；图片/链接沿用宿主来源策略。
+可访问性检查覆盖标签、标题层级、键盘顺序、焦点、屏幕阅读器状态提示和 reduced-motion；不能只验证 JSON 合法。
+
+### KTD6. 动作由宿主重新授权
+
+生成的按钮不是批准。模型只能选择已允许的 action 名称/资源引用，宿主解析为当前 Surface 的 binding。
+客户端提交 surfaceId、revision、actionId、requestId 与受限表单数据；服务端重新验证当前身份、项目、插件状态、参数、资源版本与命令权限。
+简单筛选、排序、页签切换留在客户端确定逻辑，不额外调用模型；需要重组织或分析时才进入现有 Agent 回合。
+业务变更通过既有命令总线和 HITL，表单通过不扩大其授权范围。
+幂等记录绑定身份、Surface、revision、action 和请求内容；重复点击返回已有结果，未知外部结果先查询，不因超时自动重做。
+同一 requestId 但不同参数必须拒绝；重试先做当前读权限/启禁检查，再查询已有执行回执，已执行回执不能因资源版本已变化而被当作新动作重放。
+
+```mermaid
+sequenceDiagram
+    participant U as 用户
+    participant F as SurfaceHost
+    participant S as 宿主 Surface 服务
+    participant C as 命令总线
+    participant A as 既有 Agent
+    U->>F: 提交输入或点击动作
+    F->>S: revision、action、requestId、data
+    S->>S: 当前权限、启禁、参数、资源版本和幂等检查
+    alt 需要业务审批
+      S->>C: 既有审批流程
+      C-->>U: 展示真实动作与参数
+    else 允许读取或已满足审批
+      S->>C: 执行已授权动作
+    end
+    C-->>S: 确定结果或未知结果状态
+    S-->>F: 动作状态与最新投影
+    S->>A: 必要时追加已确认交互结果
+    A->>S: 新页面提议
+    S-->>F: 已保存且校验后的新 revision
+```
+
+### KTD7. 真正可验证的插件启禁
+
+新插件默认关闭，不沿用现有“缺少 grant 默认 true”的行为。适用关系是安装存在、全局允许、owner 显式启用、manifest 范围与当前资源权限的交集。
+首期采用实例总开关 + owner opt-in；project 开关可后续新增，不能允许项目设置覆盖实例禁用或扩大 manifest 范围。
+管理员可以全局禁用；用户仅在管理员允许的范围控制自己的使用。
+
+| 状态/动作 | 必须发生的行为 |
+|---|---|
+| 关闭 | 不贡献可调用工具/提示策略，不启动生成，不接受写页面与动作；原有固定 UI 可用 |
+| 启用 | 校验组件兼容与配置，建立新的 activationEpoch，按请求授权能力；不重放旧动作 |
+| 禁用请求成功返回 | 先持久化禁用并提升 epoch，再通知前端；返回后新请求、旧按钮和旧 generation 的提交都应被拒绝 |
+| 禁用时有生成在途 | 取消该 owner/plugin 的独立宿主操作，撤销发布资格；提交前再次核对 epoch 并拒绝迟到页面。共享主模型回合继续，不调用 CancelRun 取消整个主任务 |
+| 禁用时已有动作在执行 | 尚未进入执行的动作拒绝；已提交业务操作按原命令记录收尾，不能承诺撤销既成副作用；结果不明则查询恢复 |
+| 历史页面 | 权限仍有效时以宿主通用静态渲染/文本查看，动作禁用；资源权限撤销后旧快照也不能继续泄露数据 |
+| 再次启用 | 重验 schema、来源与权限，创建新 capability/binding；保留产物，不自动执行先前点击 |
+| 卸载/升级 | 功能停用与代码包移除分开；旧产物靠宿主降级；代码升级走构建兼容验证 |
+
+```mermaid
+stateDiagram-v2
+    [*] --> Disabled
+    Disabled --> Enabled: 授权启用且兼容
+    Enabled --> Generating: 当前 Agent 请求页面
+    Generating --> Ready: 校验与事务提交
+    Generating --> Fallback: 无效规格或失败
+    Ready --> Generating: 请求重组织
+    Ready --> Disabled: 禁用并撤销动作
+    Generating --> Disabled: 撤销发布并拒绝旧 epoch 提交
+    Fallback --> Generating: 有限重试或用户重试
+    Fallback --> Disabled: 禁用
+```
+
+该状态图描述呈现能力，不等同业务任务状态。历史快照存在不代表插件 Enabled。
+主 Agent 已收到的生成提示和已发生的 token 成本不能在禁用后收回；下一次能力组装移除插件策略，当前回合即使继续提议页面也会被执行端拒绝并转为文本结果。
+epoch 核对与页面提交/新动作准入必须共享可证明的事务或串行化边界，不能“先查开关、释放锁、再执行”。禁用返回是准入截止点，截止点前已准入的操作按上表在途语义处理。
+启禁守卫覆盖发现、命令分发、工具执行、上下文能力注入、Surface 读取/提交与动作；标明归属的能力不能通过另一入口绕过。
+编译插件是可信代码扩展，不是恶意第三方代码的隔离边界。sidecar 目前继承环境并使用共享 Host token 的现状，不足以承担不可信插件沙箱。
+首期只补这条能力闭环及共享执行边界；通用热重载原子化、插件市场和所有旧插件资产清理另立任务，不无限扩大本次范围。
+
+### KTD8. 一个状态所有者，明确恢复规则
+
+后端是 Surface 与业务状态权威；Frontend store 维护一份投影；UI 只渲染 props 并发出用户事件。
+表单草稿、页签与展开状态归前端按 surfaceId/nodeId 管理；提交后成为服务器确认的输入，不能同时被模型与组件局部 state 无序覆盖。
+复用主认证与 SSE 通道，不另用现有未接完整的 pluginSdk EventSource 作为第二所有者。
+事件绑定会话/项目/Surface 与 seq；前端丢弃过期 seq、旧 revision、旧页面 generation；检测缺口后获取授权快照重建。
+切项目、退出登录、撤权或禁用立即作废在途请求和可见敏感投影；不同身份不复用浏览器缓存。
+撤权阻止继续访问和重新加载，不承诺抹去用户此前已合法下载的数据；敏感快照不写入持久浏览器存储。
+普通 reconnect 不重新调用模型，先恢复已保存的快照；重新生成是用户动作或经允许的策略动作。
+
+### KTD9. 可演进但不虚报标准兼容
+
+内部首版使用系统自己的版本化 Surface + UINode 扩展，不能命名为“A2UI 兼容实现”后省略协议测试。
+未来可加 A2UI 适配器：固定协议版本与目录版本，只支持明确子集，不支持的组件/动作显式报错，不静默损失含义。
+AG-UI 仅在需要跨 Agent 框架互通时评估事件适配；MCP Apps 仅在需要外部工具应用时评估宿主资源与沙箱能力。
+三者不作为首期串联依赖；避免为了 Generative UI 同时迁移模型运行、传输与前端框架。
+
+---
+
+## 最小宿主改动与插件交付边界
+
+| 模块 | 建议变更 | 明确保留的职责 |
+|---|---|---|
+| Core | Surface/版本/节点 ID/受控布局/动作信封与兼容标识；保持旧 UINode/卡片可读 | 跨仓公开类型权威；同步 Go、TS 及契约快照 |
+| Backend public extension | 授权 ContextSnapshot、Surface 读写/发布、插件 capability/activation；按需要增加受限上下文投影扩展 | 不暴露 raw DB、完整 session、通用任意 HTTP 或事件发射器 |
+| Backend internal | 实现上述端口、执行级启禁、事务存储、事件恢复与动作鉴权 | 服务端最终授权与业务事实 |
+| UI | 稳定节点与受控布局的通用 renderer；表单事件、行操作、无障碍、降级 | 纯展示、token/motion/Collapsible/safeHtml；不持网络状态 |
+| Frontend | SurfaceHost、单一状态投影、预览落位、开关、结构更新/草稿协调 | 身份、路由、事件、用户输入草稿 |
+| Generative UI 插件 | prompts/skills、目录选择、present/revise 等命令、生成校验编排、试点策略 | 只消费公开扩展，默认随当前 Agent 生成；无独立任务事实库 |
+| Documents/Dev | 契约申请、使用说明、评测结论、精确组件组合与索引 | 方案/实现/验证/部署状态分别记录 |
+
+公开扩展优先使用新增可选能力接口或版本协商，避免给现有必实现 Host 接口直接加方法而破坏所有消费者。
+修改公开导出时更新 `SurfaceVersion`、`pkg/extension/surface.txt` 与相关兼容快照；Core/UI/Frontend/Backend 的依赖 gitlink 同步验证。
+已有命令投影可以承载 Agent 工具，因此不申请通用 native executor 注册口作为前置。
+首期不需要开放任意前端 ESM 注入；插件只输出既有/新批准的通用 UI 词汇。
+
+如果要求“下载插件包后不重启安装”，则改为隔离 sidecar + 同一 Surface 契约。
+增加独立身份、最小环境、按插件/owner capability 令牌、健康检查、取消/退出协议、版本升级与回滚；前端仍可用通用 renderer，不必加载任意 JS。
+这属于另一档交付成本，不应通过当前 `exec.Command` 与共享 token 简单包装后宣称完成。
+
+---
+
+## 分阶段计划
+
+下列为可评审的实施候选，不是已经获准执行的待办。每个增量继续按 `policy/delivery.md` 人工评审；试验结果允许回改选型和范围。
+功能代码与生产实例本轮不变。近期 U1 具体，其余单元在试验评审后细化精确 API 与数据迁移。
+
+### U1. 受控价值与选型试验
+
+- 关联 R1/R4/R10；依赖：已满足并**已执行**（2026-10-11，任务 feature/generative-ui-u1）；结果见下节“U1 结果与 r2 修订”。
+- 对象：固定当前组件 SHA，在隔离工作区用合成或获准的脱敏材料，覆盖调研比较、任务概览、需求输入三类。
+- 方法：先比较“固定 UI/文本”与“原生 UINode 动态组合”；再用少量相同样本比较 json-render/A2UI renderer 接 @ui 的复杂度与缺口。后者是 renderer 选型挑战，不另建全套后端。
+- 文件范围：专用实验目录、组件契约夹具与评测说明；全部明确为原型，不替换生产路径。
+- 试验预算：3–5 人日；30 个固定任务、每项至少 2 次模型运行；首轮最多 60 次/方案。费用上限已由用户指定为 **¥200**（2026-10-11）；模型限 MiniMax M3 与 M2.7-highspeed，材料限合成或已脱敏样本；超限即停。
+- 判据：结构选择确实随目标变化；信息来源可追溯；可通过现有设计令牌渲染；列出外部依赖节省与新增的实际代码/状态维护面。
+- 停止：出现越权数据、无法限制生成代码执行、超过预算、依赖要求替换既有 runtime，暂停该路线并提交调整。
+- 产物：A/B 结果、renderer 取舍、失败样本、建议目录与修订版方案；不是生产代码验收。
+
+### U2. 通用契约、启禁与持久化
+
+- 关联 R2/R3/R5/R9；依赖 U1 的设计评审。
+- 文件范围：`modules/core/ui.go`、Core 新 Surface 契约及对应测试；`modules/backend/pkg/extension/`、`internal/plugins/`、`internal/store/`、`internal/server/` 及对应测试/迁移。
+- 方法：先固定兼容与授权信封，再实现 owner 隔离的 Surface 存储、revision CAS、activationEpoch 和命令执行守卫；能力缺失明确拒绝。
+- 验证：旧消费者可用；关闭状态下 direct API/工具/旧 action 不绕过；并发更新有一方冲突；写快照后事件发布失败可恢复；SQLite/PG 路径一致。
+- 完成条件：最小公开契约审过，故障/拒绝路径有证据，插件能通过公开接口保存/读取页面；此时不宣称生成体验完成。
+
+### U3. 生成插件与上下文闭环
+
+- 关联 R1/R2/R3/R6；依赖 U2。
+- 文件范围：独立插件的 manifest、commands、prompts/skills、目录和测试；Backend `internal/ctxasm/` 的通用语义投影、授权快照适配及测试。
+- 方法：沿用 AddCommandHandler/exposeAsTool；当前 Agent 接收可用词汇和授权快照，产出页面参数；插件校验，宿主原子发布。解析/语义修复最多 1 次，失败回到文本，禁止无限自修复循环。
+- 验证：同素材换任务得到合适不同结构；伪造数据引用与未知动作被拒；下一轮可以解释并修改之前的 table/compare/tabs；禁用不再注入能力。
+- 完成条件：真实模型“任务→规格→保存→继续修改”闭环可回放，来源与成本被记录；不另造 Agent runtime。
+
+### U4. 只读生成页面与可恢复体验
+
+- 关联 R1/R2/R4/R5/R6；依赖 U2，最终集成依赖 U3。
+- 文件范围：`modules/ui/src/UIRenderer.tsx` 及测试、通用 Surface 展示组件、`modules/frontend/src/store.ts`、`api.ts`、预览/卡片入口、插件设置及对应组件/浏览器测试。
+- 方法：稳定 nodeId、布局语义、受控 renderer、唯一 SurfaceHost；加载/失败/回退/来源/重新组织入口；单一 store 校验 seq/revision/generation。
+- 验证：刷新/断线/切项目/迟到响应；关插件固定界面仍完整；页面未知版本可读；键盘、窄屏、暗浅主题；输入焦点与布局变化规则。
+- 完成条件：场景 1 可通过真实浏览器完整使用；此增量提供展示和重新组织，业务写动作未开放。
+
+### U5. 动态表单和动作闭环
+
+- 关联 R7，依赖 U2/U3/U4；必须先评审本阶段动作范围。
+- 文件范围：Core 动作/字段 schema、UI 表单与行操作及测试、Frontend 草稿/提交桥、Backend action service/cmdbus 适配及权限/幂等测试。
+- 方法：输入草稿由宿主管理；服务端绑定 action；必要时进入既有 HITL；失败留在当前页面并保留可恢复输入。
+- 验证：旧 revision、资源被删、撤权、关插件、双击、超时未知结果、两个标签页同时提交；无审批旁路；用户未提交输入不传给模型。
+- 完成条件：场景 3 可完成明确读取/决策动作，再逐类批准业务写动作，不能一次开放所有命令。
+
+### U6. 自适应任务与项目工作区
+
+> **2026-10-11 用户裁定**：U1–U5 已全部落地合入；U6 启动前置（「U4/U5 的收益
+> 与可靠性证据」）改为 **owner 实际体验评估**——在真实使用中启用 generative-ui
+> 插件、体验页面生成/修订/表单提交（人类可用性对照自 U1 起 NOT_RUN，本裁定即
+> 其执行方式）。体验结论（继续/调整/停止）由用户给出后再开 U6。
+
+- 关联 R8，依赖 U4/U5 的收益与可靠性证据。
+- 文件范围：Frontend workspace/任务页容器、插件上下文选择与触发策略、Backend 授权聚合适配、相关测试。
+- 方法：先当前任务，后项目；任务阶段触发有限更新；固定布局/恢复原视图；自动模式单独 opt-in。
+- 验证：不同阶段突出不同信息；任务事实不能被页面改写；私有会话不泄露；输入时不自动重排；自动触发有预算且不递归自激。
+- 完成条件：实际任务效率改善，关闭后原工作区完整，跨会话汇总授权能复核。
+
+### U7. 组合验收、兼容与交付
+
+- 关联 R2/R5/R9/R10；按每个可交付增量执行，不只在最后一次执行。
+- 文件范围：各模块相关测试、Documents 使用/评测记录、Dev 任务卡和精确 gitlink 组合；涉及治理脚本才追加治理测试。
+- 方法：先组件 PR，再组合 PR，固定 Dev SHA+组件 SHA+schema/catalog/model/profile；复放正常、异常、权限、禁用与恢复链路。
+- 验证：CI `make test`/`make build` 与独立重放；业务智能体改动附真实模型前后对照；本地 SELF 不升级为 GATE。
+- 完成条件：用户批准该增量、功能与回退均有证据、文档和开关说明完整；是否部署仍是独立授权与运行验收。
+
+粗估：U1 3–5 人日，U2–U4 首个可靠只读闭环再需约 10–18 人日，U5 约 5–8 人日，U6 约 5–10 人日。
+这些是范围估计，假设熟悉现有代码且使用可信编译插件；不含人工等待、全量外部协议兼容和不可信插件沙箱，不是交付承诺。
+
+---
+
+
+### U1 结果与 r2 修订（2026-10-11）
+
+U1 三臂对照（B=Markdown 基线 30 任务；G=M3 UINode 生成 30 任务含一次修复；G-hs=highspeed 子集 10）
+与 renderer 挑战已完成，全部材料为合成样本，总开销 ≈¥3.0（上限 ¥200）。详细数据与失败样本：
+Dev 任务卡 feature/generative-ui-u1 及其 `.task/genui-u1/report.md`（SELF 记录；随任务 PR 留 CI GATE）。
+
+关键结论与修订（构成本 r2 相对 r1 的差异）：
+
+1. **R1 结构分化成立**：同料不同目标 6/6 对照全部分化（类型多重集 Jaccard 0.17–0.50）。
+2. **生成通道硬约束（修订 KTD2）**：页面规格只能经插件命令工具参数（exposeAsTool）提交，
+   不接受聊天文本 JSON。依据：文本通道首过合法 60%/修复后 83%，终判失败全部为长中文 JSON
+   语法违纪；工具参数通道探针解析干净、仅剩可修复语义错误；`response_format` 探针无效。
+3. **目录文档要求（修订 KTD5）**：每类型附完整最小示例；按目标类别给推荐/禁用词汇
+   （实测 order/handover 目标下存在未被要求的 form/actions 超生成）；校验器升级为 schema
+   驱动、目录=提示=校验三同源（借鉴 json-render，不引入其运行时）。
+4. **模型路由（修订 KTD2）**：生成档固定 MiniMax-M3（highspeed 文本通道合法率 20%，否决其
+   生成用途；轻量步骤仍可用 highspeed）。成本实测 ¥0.067/任务（M3），可忽略。
+5. **renderer 取舍确认**：首期扩展自研 UIRenderer；json-render（0.21.0）端到端可用但组件
+   契约重且状态/动作运行时与我方重叠，记为 U5 交互期重评项；A2UI（0.13.0）导入即需 DOM 且
+   客户端 signal 绑定与 KTD4 宿主解析冲突，不推荐。
+6. **验收线移位**：首过 ≥90%/修复后 ≥98% 维持为 U3 工具通道验收线；本轮 60%/83% 记为文本
+   通道下界。稳定 nodeId 纪律良好（25/25 合法规格全提供），U2 信封先行得到支持。
+
+局限：人类可用性对照 NOT_RUN；合成材料、n=30、每任务单次采样；G-hs 有效样本 n=2 不具统计
+意义；首轮 harness token 预算缺陷已修复重跑（事故记录见报告第六节）。
+
+## 验证与评估
+
+### 试点评价方法
+
+采用相同材料、权限、模型/profile、任务和重复次数比较固定 UI/文本基线与生成 UI。
+分别记录冷启动/缓存、模型时间、验证时间、渲染时间、额外 token 与调用次数；不把缓存命中混作生成加速。
+默认观测记录规格/目录版本、耗时、字节数、token、错误码和回退原因；原始上下文、输入值与模型全文不进入普通日志，评测原始材料按既有 eval 规则保存在受控环境且不进仓。
+以下阈值为**建议评审目标**，本轮无实测结果：
+
+| 维度 | 建议目标/方法 |
+|---|---|
+| 任务有效性 | 任务成功率至少不低于基线；选定比较/梳理场景的人类中位完成耗时改善约 20% 才考虑扩大自动模式 |
+| 事实可靠性 | 验证集中的资源/数值引用可追溯；关键事实错误为 0；分析判断独立标注 |
+| 规格有效率 | 首次合法页面 ≥90%；最多一次修复后 ≥98%；最终失败 100% 有可用文本降级 |
+| 延迟 | 浏览器先给确定加载状态；本地校验+渲染 P95 目标 <300ms；模型生成单独统计。显式页面请求的初始展示等待预算为 20s，超时转文字等待/回退并撤销该次发布，不因此中断共享主 Agent 回合 |
+| 干扰 | 普通文本任务不额外调用 UI 模型；不会每个 token 重排；用户输入与焦点不丢失 |
+| 开销 | 展示额外 token、调用数、失败重试成本与收益；是否可接受在真实模型对照后决定，不先声称“更快更省” |
+| 开关正确性 | 禁用成功后所有新副作用入口拒绝；旧 epoch 页面不能提交；保留授权历史与原 UI |
+
+30 个任务的小试验用于发现问题和决策，不足以证明长期生产可靠率；报告样本量、失败数和每类任务结果，不只报百分比。
+若收益只体现在“更好看”而任务成功率/效率下降，保留按需模式，收窄场景或停止推广。
+
+### 必测故障与权限矩阵
+
+- 正常：同材料不同任务、纯文本无需页面、生成后改布局、来源打开、刷新恢复。
+- 结构：未知节点、循环/过深结构、超大表格、非法数据类型、畸形 JSON、未知 schema/catalog、非法 URL/脚本属性。
+- 权限：跨 owner/project/doc 引用、跨会话私有内容、生成后撤权、切账号/项目、直接 API 调用、伪造动作 ID。
+- 异步：重复/乱序/缺口事件、断线重放、两个标签页、旧 revision、切页后的迟到响应、保存成功但事件未发布。
+- 启禁：生成前/中/提交前禁用，动作前/审批后/执行中禁用，服务重启，重新启用，兼容版本缺失。
+- 交互：表单校验、重复提交、业务冲突、输入中更新、取消、失败后保留草稿、外部结果未知不重复执行。
+- 回退：插件完全缺失、模型不可用、预算耗尽、renderer 出错；固定 UI 和授权文本历史仍可用。
+- 回归：旧 UINode、卡片、命令、工件预览、侧栏关闭、单二进制构建、SQLite/PG、设计守护与可访问性。
+
+正式实现期按各组件 PROJECT 的命令验证，并在 Dev 精确组合运行 `make test`、`make build`。
+涉及智能体提示/工具/上下文变化时，按 `policy/delivery.md` 的真实模型任务级前后对照要求执行；mock 只能证明机制。
+证据由 `make evidence` 写入任务卡，保留 SELF/REPLAY/GATE 和固定对象，未运行项保持 NOT_RUN。
+本轮只检查方案差异、引用与链接、源码对应关系；没有运行上述功能试验或业务测试。
+
+---
+
+## 风险、待确认项与下一步
+
+| 风险 | 具体处置 |
+|---|---|
+| 页面自主性变成固定模板填充 | 用同事实不同目标的验证例证明结构变化；逐步开放组合能力，而非预设三种页面硬路由 |
+| 模型幻觉变成“业务事实” | 事实字段绑定授权源、生成判断标注、来源版本可回查；业务状态只走原服务 |
+| 自主重排破坏可用性 | 稳定宿主入口、布局固定、输入期间冻结结构、按语义事件有限更新 |
+| 声明式 schema 被误当安全边界 | 仍对资源、URL、动作、执行权限和数据泄露做服务端校验；可信插件代码另有信任边界 |
+| 禁用只藏按钮 | 执行端统一守卫、epoch 与提交前复核；直接 API 和在途测试列为必过项 |
+| 引入第二套状态/runtime | 复用主 Agent、主 SSE 和 Frontend store；外部包只在明确 renderer 边界试验 |
+| 公开接口扩大过快 | 小型能力接口、版本协商、兼容快照；不暴露内部 store，避免泛化插件市场 |
+| 外部项目快速变化 | 固定依赖版本，锁 catalog，保留适配层；Tambo Cloud 停服作为实际供应商生命周期样例 |
+
+### 用户裁定记录（2026-10-11）
+
+以下三项已由用户（weichen）裁定，原“进入试验前需确认”问题随之关闭：
+
+1. **接受“动态业务页面 + 稳定宿主入口”**：首试点为对话中的完整分析页（场景 1），随后推进任务/项目工作区。
+2. **“随时启禁”采用可信编译插件交付**：功能启禁无需重启，插件代码安装/升级需重建并重启；不要求本期免重启安装，sidecar 路线保留为备选。
+3. **试验参数**：裁定与验收负责人为用户（weichen），执行由 Agent 承担；模型限 MiniMax M3 + M2.7-highspeed；材料限合成或已脱敏样本；U1 费用上限 ¥200。
+
+注：裁定后权威 main 又合入前端三栏工作台（Dev PR #322）。本文“当前系统的可行性依据”按调研时固定 SHA 记录、不改写；U1 开工时须在新 HEAD 上重验该源码事实表。
+
+首选下一任务是 **U1 受控价值与选型试验**，不是直接实现所有宿主契约。
+其前置（批准试验范围与预算）已由 2026-10-11 裁定满足；产物为固定样本 A/B 报告、实际 renderer 取舍、失败清单与 r2 方案。
+验收依据为 R1/R4/R10 的可判定结果，随后再决定 U2–U4 的正式投入。
+U1 按独立任务启动并继续逐阶段人工评审；本文发布（推送、合入）随裁定记录一并进入 PR 评审，部署仍不在本轮范围。

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

@@ -0,0 +1,253 @@
+---
+title: 多人协作存储与分布式演进方案 - Plan
+type: refactor
+date: 2026-10-11
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# 多人协作存储与分布式演进方案 - Plan
+
+修订：r2.2；确认状态：**已批准（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)），C5 工件恢复 K4 失败。**SELF≠GATE/REPLAY**，双主机 C3 未做——**仍不放行第二实例承接写请求**。
+需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-12（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. 推荐结论与边界
+
+团队部署以 PostgreSQL 作为共享业务状态的唯一权威，pgvector 承担数据库内向量查询，Redis 承担可丢失的缓存与限流。SQLite 保留给个人嵌入式使用、离线工具及可以重建的本机状态，不承载团队共享写入或跨主机运行所有权。
+
+第一阶段交付单应用实例的可靠团队部署；第二阶段补齐执行所有权、持久命令、共享工件与事件追赶，再开放多个应用实例和 Worker。通过接口和数据归属为服务拆分做准备，当前不要求微服务化、Kubernetes、分片或引入另一套消息中间件。
+
+“不会出现错误”不能成为无条件承诺。工程目标是：在定义的故障模型下，不静默丢失已确认数据、不覆盖他人的并发更新、不产生未经识别的重复副作用、不越权；异常可发现、可追踪、可恢复。冲突可以返回明确的 409，超载可以返回 429，依赖故障可以返回 503，它们必须有清楚的重试语义。
+
+本方案是[双档存储 D17–D24](2026-09-30-dual-tier-storage-and-multitenancy.md)的候选增补，批准前不改写原已采纳决策。拟调整的是团队部署的默认与必需条件，以及 D24 原来排除的跨实例执行能力；保留个人 SQLite 档、非容器部署、现有检索契约与序号语义。
+
+## 2. 当前事实与差距
+
+源码调查基线：Dev `73c901fa341a3653d6e0826d0da3497507995482`，Backend `eda90ed310f37f7352e24a8096d932dbf320cd73`，Documents `9a46785ee0f19540c79f83b4e4544572b5217ac2`，Agent-Squad `490b0b2dfa1567cb16ff7a7230fd78e52bc2938e`，Agent-Native `c348441691e8bdab784a03aa9be64d53dacff341`。
+来源均为 **SELF·源码/本机只读观察**；没有真实并发故障重放。命令、对象 SHA 和原始输出见[调查收据](../records/2026-10-11-collaboration-storage-audit-receipt.json)，启动收据见任务卡。
+
+| 对象 | 当前可核实事实 | 方案含义 |
+|---|---|---|
+| Dev 运行实例 | `runtime/dev/bin/agent-system`、8788 端口打开 `runtime/dev/data/agent-system.db` 及 WAL；二进制 build revision 为 `017b40f76156905eabe8323ae2bfe800f47fb8bd` | 当前服务确实使用 SQLite；运行版本与上述源码基线不同，源码缺陷不冒充已在该二进制重现 |
+| 本机安装 | Homebrew 列出 PostgreSQL 18.6、pgvector 0.8.7、Redis 8.10.2 | 仅证明安装；目标 PG 实例、目标库扩展启用、角色与可用性未验证，不据此批准切换 |
+| Backend 存储 | `internal/app/app.go:105` 按 DSN 选 PG，否则 SQLite；`store/store.go:50` SQLite WAL、busy_timeout=5000、单连接；PG 池固定 16/8 | 无需重写全部存储层；需团队档显式配置、连接预算和真实 PG 测试 |
+| 已有一致性基础 | `store/dialect.go:49` PG 事务咨询锁；消息 seq 唯一约束、requestId 去重和 HITL 条件更新 | 保留并扩展，不把已有能力列作全新建设；这些能力不等于跨实例运行互斥 |
+| Run 所有权 | `runmgr/runmgr.go:1113` 用进程内 map 占用会话；`store/messages.go:120` 直接创建 run | 两实例可能各自认为空闲；需共享占用和有效执行代次 |
+| 取消与审批 | `runmgr/runmgr.go:1326,1422` 依赖本实例 active 句柄；HITL 先落卡，再查句柄 | 请求落在非执行实例时存在命令不生效或卡已处理但执行未被唤醒的风险 |
+| 跨实例事件 | `pgbus/pgbus.go` 每批通知末 seq，Listener 只 `EventAt` 取末条；断线后对原连接继续 Wait | 静态可见批内中间事件遗漏及重连缺口；`server/server.go:376` 的 SSE 重放/去重不能修复已越过的游标 |
+| schema 迁移 | `store/migrate.go:migrate` 每次 Open 执行迁移；DDL 事务提交后另行插入迁移版本 | 并发启动与两步间崩溃存在风险；切 PG 前先改为单迁移入口与原子版本登记 |
+| 向量查询 | `store/vectors.go` 读取 BYTEA，应用内计算余弦；`migrate.go` 未把向量列建成 pgvector 类型 | 安装 pgvector 不代表启用；复用 RRF 管线，分阶段改为数据库 top-k |
+| Redis | `ratelimit/ratelimit.go:65` 独立 INCR/EXPIRE，EXPIRE 错误未处理；请求异常默认放行；app 默认限额 0 | 当前只是可选共享限流，需原子窗口、鉴权/TLS配置、容量保护与可观察的降级 |
+| 本地文件 | `blobstore` 默认本地目录；Backend Squad 入口未传 Store，回落 FileStore；checkpoint 写 `.agentx/checkpoints.jsonl` | PG DSN 不会迁走这些状态；工件、执行工作区、checkpoint 要分别处理 |
+| 独立 Squad | 独立 CLI 使用 `adapters/sqlite/runstore.go` 的 `orchestration.db`；这不是 Backend 实际接线 | 不把迁移该 SQLite 文件当作 Backend 分布式改造完成 |
+| 验证 | PG/Redis 集成由 `AGENT_PG_TEST_DSN`/`AGENT_REDIS_TEST_ADDR` 控制；当前 CI YAML 没有显式准备这两种服务 | 缺变量会跳过关键测试；CI 通过不能自动证明真 PG/Redis 或双进程链路通过 |
+
+已有规划衔接：Q1 已记录 Store 收敛但仍留 platform→squad 队列桥接等余项；N3 原案与归档卡的 JournalOnly 落地不同，应以当前接线确定权威。共享权限沿用 EXT-8 授权适配器与 RDM 的成员/角色职责，不新建第二套成员模型。历史报告用于定位，不能替代当前验收。远端调查发现 Backend [#135](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/135) 正在增加 S0 工作区 overlay/frozen base/CAS apply；U5 必须复用并核对其契约，不能另造冲突的工作区实现。该 PR 尚未作为本案已合入依赖。其他被查仓当时未返回 open PR，详见收据；实施启动时重新核对。
+
+## 3. 需求与可判定结果
+
+| ID | 需求 | 优先级 | 验收条件 |
+|---|---|---|---|
+| R1 | 支持 10–100 人、多项目、多会话并行 | P0 | 在固定环境与下述负载下完成真实业务链路；容量结果绑定组件 SHA、配置和数据集 |
+| R2 | 团队数据有唯一共享权威 | P0 | 团队档无有效 PG 配置或连接失败时拒绝就绪，不自动建立本地 SQLite 继续服务 |
+| R3 | 并发提交和编辑不静默覆盖 | P0 | 同 requestId 返回同一逻辑结果；同版本竞争写入最多一个成功，其余明确冲突；不同会话并行 |
+| R4 | 跨实例运行与命令可恢复 | P1，多实例前置 | 同会话主 run 单一有效 owner；旧 epoch 写入拒绝；任意 API 实例取消/HITL 均到达执行者 |
+| R5 | 事件有序、可追赶 | P0/P1 | 批处理、掉通知、重连和慢消费者后可按游标补齐全部已提交事件；不因收到末 seq 而跳过中间事件 |
+| R6 | 项目权限在所有数据入口一致 | P0 | 读取、写入、SSE、检索、下载与工具入口均校验当前授权；撤权后的新请求无泄漏 |
+| R7 | 数据和运行状态可恢复 | P0 | SQLite→PG 演练无遗漏；备份恢复含文件与权限映射；未知副作用停在可见恢复状态，不盲目重试 |
+| R8 | 高负载下有界且可观察 | P0 | 队列、活跃 Agent、DB 连接、工具/模型请求都有上限；超载行为、等待时间和错误分类可观测 |
+| R9 | 向量检索随数据增长扩展 | P1 | 数据库 top-k 与原精确基线对照；授权过滤正确；模型/维度/版本不混用；ANN 有召回率与延迟证据 |
+| R10 | 支持未来多服务部署 | P1/P2 | 先验证两个真实 API/Worker 进程共享服务；业务表有模块 owner，后续服务通过契约操作他方数据 |
+
+R1 的人数及未来分布式方向由用户确认；下列量化指标是**建议的验收合同，待批准，不是当前性能结论**：
+
+- 基准环境建议：Linux、8 vCPU、32 GiB RAM、NVMe，记录 PG/应用的实际配额与网络；两实例验证分为同机多进程和后续双主机两种证据。
+- 阶梯负载：10→30→100 在线用户，最多 300 SSE 连接；初始全局活跃 Agent 执行预算 20（包含子代理）、每用户 2、索引任务 4。待执行队列最多 200，按用户/项目公平分配。已接纳 run 数与实际执行许可分别计数；父 run 等待子代理/HITL 时让出执行许可、保留会话所有权，恢复执行须重新获许可，避免额度用尽时父子互等。以上阈值由实测调整。
+- 数据量建议：100 万条消息/事件量级、10 万知识分块、多个项目与交叉授权用户；另测 100 万分块扩展档。记录数据分布与热点，不能只测空库。
+- 非模型普通 API：P95≤300ms、P99≤1s；SSE 持久事件可见延迟 P95≤1s；非预期失败率≤0.1%。预期限流/冲突单列，不能排除后不报告。
+- 先跑 60 分钟稳定负载，再跑 2 小时混合长稳；持续记录实际成功吞吐、排队、CPU/内存/IO、连接等待和模型配额。模拟模型用于容量基线，另保留真实模型少量全链路验证。
+- 数据正确性不变量在全部测试中零违反。数据库/Worker 故障恢复建议 RTO≤15 分钟；灾难恢复建议 RPO≤5 分钟、RTO≤60 分钟。主机/存储全毁不在单机“零丢失”承诺内；若要求该场景 RPO=0，需另行批准同步复制、故障域与可用性取舍。
+
+## 4. 技术决策与目标结构
+
+KTD1. **区分 local 与 team 部署档。** local 保留 SQLite；team 强制 PG、认证、独立实例 ID、受控工具执行和启动诊断。PG 暂时不可用时返回未就绪，不切回 SQLite。个人档不因浏览器人数变多而自动升级。
+
+KTD2. **PG 保存持久业务与调度事实。** 用户/项目/会话/消息/卡片/运行/幂等记录/命令/事件/checkpoint 元数据以 PG 为准。Redis 不成为任务完成、审批通过或永久幂等的唯一证据。初期使用同一 PG 实例和有归属的逻辑表/角色；后续拆服务时明确表的唯一写入模块，避免所有服务无约束共享整库。
+
+KTD2 的全部状态收敛以 U5 完成为界；此前有明确的单实例过渡边界，不能提前把本地状态当成缓存：
+
+| 数据 | 首期单实例团队版 | U5 后多实例版 |
+|---|---|---|
+| Backend 业务记录、幂等与恢复隔离标记 | PG 权威 | PG 权威 |
+| 尚未改造的 Squad FileStore、checkpoint、续跑标记 | 唯一实例的本地权威文件，联合备份，禁止跨机接管 | 版本/归属元数据在 PG，大内容在共享对象存储 |
+| 工件 | 本地对象目录，持久备份与 DB 清单绑定 | 共享不可变对象与 PG 发布记录 |
+| 临时执行目录 | 单实例/单 owner；先分类再清理 | owner+epoch 控制的可恢复工作区 |
+
+KTD3. **一个会话一次主执行，不同会话并行。** 推荐独立 conversation_execution 占用行，以 owner/会话唯一键、run_id、epoch、lease_until 约束；不对所有 runs 加“会话唯一”，以免禁止正常子代理。事务内完成权限检查、请求幂等、消息、主 run 和调度记录，接收成功以事务提交为准。
+
+KTD4. **短事务领取，租约与 fencing 配套。** Worker 通过 PG 行锁和 SKIP LOCKED 领取到期任务；事务提交后执行，模型/工具等待不得持有数据库事务。续租、事件追加、checkpoint、终态写入都校验 run+epoch。租约用 DB 时间，执行实例 ID 与每次启动的 generation 分开。旧 Worker 恢复后不能提交；租约过期也不等于外部命令已经停止。
+
+KTD5. **持久命令与提交事件同事务。** 取消/HITL/调度命令写入 PG inbox/outbox，带唯一 command_id、逻辑 run、执行代次与处理状态。运行级取消意图交给当前 owner，即使接受后发生接管也不能丢失；HITL 绑定稳定 gate_id+gate_version，新 owner 消费时重验 gate 与权限，过期审批明确拒绝而不静默丢弃。执行结果及确认仍须校验当前 epoch。批准数据与待投递命令原子提交，执行者幂等消费，处理确认与执行效果分别记录。关键外部动作必须有目标端幂等键、可查询凭据或人工恢复路径；超时结果未知时进入 recovering，不宣称任意工具 exactly-once。
+
+KTD6. **事件表是重放依据，NOTIFY 仅作唤醒。** 事件提交与 outbox 同事务；需要时在同事务使用 pg_notify。监听端维护每流连续 cursor，从 EventsAfter 分页追赶到通知水位；不能直接跳到末 seq。重建连接→LISTEN 生效→补查水位/积压，再转实时。增加周期补查，覆盖通知丢失、断线与通知前后竞争。只有落库事件才能发布可恢复的 SSE ID；纯瞬时进度明确可丢失，不冒充已确认业务数据。
+
+KTD7. **数据库乐观并发控制。** 项目设置、卡片、文档元数据等读改写带 version/expected_version；冲突返回 409 及新版本引用。重要唯一性/外键落在数据库，事务失败按错误类型有界重试整笔事务；提交结果未知先按幂等键查询。不能无限重试模型调用或发送动作。[PG 事务隔离与重试](https://www.postgresql.org/docs/current/transaction-iso.html)。
+
+KTD8. **数据库迁移独立于普通启动。** 单一 migrator 取得数据库锁，执行 append-only 版本；可事务化 DDL 与版本登记同事务。应用仅核对兼容版本和就绪状态。不能放入事务的在线索引变更单列可恢复运维步骤，不夹入普通迁移后声称原子。使用扩展→回填→切读写→收缩，保留兼容窗口。
+
+KTD9. **工件共享，工作区有执行 owner。** 先保留 blobstore 接口；跨主机上线前实现并验收 S3 兼容对象存储，DB 保存不可变对象键、校验和、版本与就绪状态。发布前先完整写对象再提交引用，失败孤儿可清理；删除采用标记和延迟 GC。工作区、检查点与 Squad 状态分开设计：checkpoint/调度版本入 PG，大内容入对象存储，本地工作区是受 owner/epoch 控制的暂存执行目录；需要接管时按清单恢复。共享目录和文件 rename 不能替代跨机所有权。
+
+KTD10. **Redis 只保存可恢复的加速状态。** 保留共享限流，改为 Lua 原子计数+过期或等价原子算法，键包含实例群/完整时间窗/owner，支持 ACL 凭据/TLS、连接与请求超时。故障时普通读取可降到本地保守限流；创建 Agent/昂贵工具等写入口仍受 PG admission 硬预算保护，不能无界放行。缓存带授权/内容版本，撤权同步失效或重新校验；先证明命中收益再加缓存。[Redis INCR 限流模式](https://redis.io/docs/latest/commands/incr/)、[分布式锁限制](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/)。
+
+KTD11. **pgvector 按“正确→测量→ANN”推进。** 复用现有全文+RRF+可选 rerank，先补 embedding profile/model/revision/dimension/content_hash/generation 身份，禁止同维不同模型混查；迁移为 vector 列并在 PG 做过滤和精确 top-k，再用基线对照决定 HNSW。权限适配器不能直接变成 SQL 时，由适配器提供受限授权候选集合或采用有界分批取候选+最终实时鉴权，不得无界加载所有 owner 后在内存过滤。授权过滤后的召回率单独验证；ANN 需要迭代扫描/分区等策略时以模型维度和版本实测选择。[pgvector 官方说明](https://github.com/pgvector/pgvector)。
+
+KTD12. **先管理连接池，再决定 PgBouncer。** 使 MaxOpen/Idle/IdleTime/Lifetime、查询超时可配置并输出脱敏有效值；总连接预算包含所有 API、Worker、LISTEN、migrator、监控与维护预留。100 在线用户不等于 100 DB 连接。未来接 PgBouncer transaction pooling 时 LISTEN 必须使用直连或 session pool 独立 DSN，迁移也走直连，并验证 pgx prepared statement 配置。[PgBouncer 兼容表](https://www.pgbouncer.org/features.html)。
+
+KTD13. **共享可读不等于可写或可批准。** 当前 EXT-8 `ProjectAuthz` 是只读 bool 契约。U3 先列 read/edit/approve/execute/admin 的动作授权矩阵，复用下游角色，不另建成员权威；需要共享写入时以版本化公开契约扩展 action-aware 授权，旧只读适配器不得自动获得写入能力。未配置的动作默认拒绝，Host/工具/API 均走同一授权结论；审批职责分离仍由下游规则判定。SSE 发送后续数据、异步任务开始和工件下载时重新校验当前授权，缓存失效不承担唯一安全责任。
+
+KTD14. **迁移副本按原数据敏感级别保护。** 备份、导出、WAL、工件和测试副本使用专用角色及受限目录；传输与静态备份加密，解密材料保存在独立受管秘密存储并纳入恢复演练。日志/报告只留统计与哈希，禁止正文、令牌及密钥明文；测试使用脱敏数据。U1 固定保留期限、存放位置、访问者与清理责任，未知项阻塞正式导出。正式恢复演练同时验证凭据可用性与非授权者无法访问副本。
+
+```mermaid
+flowchart LR
+  U[10–100 用户] --> G[入口与认证]
+  G --> A[API 实例 A / B]
+  A --> P[(PostgreSQL + pgvector)]
+  A --> R[(Redis 限流 / 可重建缓存)]
+  P --> W[Worker 领取任务 / 持久命令]
+  W --> P
+  W --> X[受控工具工作区 / 模型服务]
+  W --> O[(共享对象存储)]
+  A --> O
+  P --> E[事件追赶 / 本地订阅]
+  E --> U
+```
+
+```mermaid
+sequenceDiagram
+  participant C as 用户
+  participant A as 任意 API
+  participant P as PostgreSQL
+  participant W as 执行 Worker
+  C->>A: 提交 requestId / expected_version
+  A->>P: 短事务：鉴权、幂等、占用、消息、run、任务
+  P-->>A: commit / 冲突
+  A-->>C: 已受理与 runId / 明确冲突
+  W->>P: 领取任务并取得 epoch
+  W->>W: 事务外执行模型与工具
+  W->>P: 按 epoch 提交结果与事件
+  P-->>A: 唤醒后按 cursor 补齐
+  A-->>C: SSE 已提交事件
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> queued
+  queued --> running: 原子领取并分配 epoch
+  running --> waiting: 持久 HITL
+  waiting --> running: 幂等命令消费
+  running --> completed: 有效 epoch 原子结算
+  running --> recovering: 失联或副作用结果未知
+  waiting --> recovering: owner 失效
+  recovering --> queued: 已核对可安全重试
+  recovering --> interrupted: 需人工处理或不可恢复
+  queued --> cancelled: 取消命令生效
+  running --> cancelled: 执行者确认停止
+```
+
+## 5. 实施顺序与工作包
+
+每个阶段评审后再进入下阶段；以下均为待批准计划，不因写入文档取得实施授权。新测试文件标“新增”；现有测试只作为扩展入口，本次未运行。普通基座改动在 Backend；公开持久接口确需变化时才同步 Native/Squad/Core，并由 Dev 固定组合测试，不全库改造。
+
+### U1. 冻结目标、数据归属与基准环境
+
+对应 R1/R2/R7/R8。先确定目标为 Dev 团队实例及其实际发布制品，记录脱敏配置来源、DB 实例/版本/扩展、数据数量与归属、文件清单、磁盘容量、峰值和恢复目标。RDM 独立业务库、旧 Agent-System 治理库另列，不能把一次 DSN 切换宣称覆盖它们。
+范围：`runtime/dev` 部署配置（实施时核对文件位置）、`modules/backend/internal/config/config.go`、文档运行手册。
+产物：固定部署清单、迁移映射、容量合同（区分接纳与执行许可）、隔离测试库/目录/端口方案、KTD14 的副本保护与保留合同；确认暂态 Worker 文件哪些可重建，哪些必须迁移。
+验收：仅操作批准的实例和测试资源；共享数据凭据不打印；未知 owner 或未定位的权威文件阻塞迁移。测试：脱敏配置诊断及缺项校验，业务压测依后续 U7。
+
+### U2. 团队 PG 档、迁移器与真实数据库门禁
+
+依赖 U1；对应 R2/R3/R7。修改 `internal/config/config.go`、`internal/app/app.go`、`internal/store/store.go`、`internal/store/migrate.go` 及 CLI；按 KTD1/KTD8/KTD12 实施。
+CI 增加隔离原生 PG/Redis 生命周期及明确必跑标记，固定组件/扩展版本；缺少真实测试服务时该 job 失败而非跳过。
+测试：扩展 `internal/config/config_test.go`、`internal/store/store_test.go`；新增 `internal/store/migrate_atomic_test.go`。覆盖 team 缺 DSN/PG 故障拒绝启动、local SQLite 正常、两个 migrator 竞争、DDL 与账本中间崩溃、旧 schema 升级、PG bool/时间/空 JSON/唯一约束与全文扩展。
+出口：真 PG 完整 CRUD/认证/会话/SSE/检索/卡片链路通过；仅该出口不宣布多实例安全。schema 变更的组合测试与业务迁移是不同动作。
+
+### U3. 请求原子性、版本冲突与受控容量
+
+依赖 U2；对应 R3/R6/R7/R8。修改 `internal/server/server.go`、`internal/store/messages.go`、`internal/store/cards.go`、`internal/cardsvc/cardsvc.go`、设置读改写及 `internal/runmgr`。收口 KTD3/KTD7 的事务边界；保留现有 seq 约束。按 KTD10 完成 Redis 原子限流、配置与异常策略；PG 记录共享 admission 预算。按 KTD13 完成动作授权矩阵与所需公开扩展的兼容计划；涉及共享编辑时 Core/Host 与下游适配器一起验收。
+先补最小持久恢复隔离：为未知副作用记录 recovery hold，`ResumeInterruptedChildren` 等所有启动续跑入口必须跳过，人工核对后显式解除。概念状态 recovering 可以先由独立隔离记录表达；扩展 Core 枚举时走公开契约版本，不假定当前已有此状态。完整租约接管留 U5。
+测试：扩展 `internal/server/admission_test.go`、`internal/ratelimit/ratelimit_test.go`；新增 `internal/store/admission_pg_test.go`、`internal/store/card_version_test.go`、`internal/runmgr/recovery_hold_test.go`。覆盖相同请求重放、事务部分失败、同版本竞争、动作越权、子代理预算计入全局、所有父 run 占满额度后同时派生仍能前进、未知副作用重启不自动续跑、队列满、Redis 断连/恢复/键过期。
+出口：单 API 团队模式达到不变量与有界行为；不会把 20 个 Agent 配置值当作已证明容量。
+
+### U4. 可切换的迁移与恢复演练
+
+依赖 U2/U3；对应 R2/R7。新增 `modules/backend/cmd/storage-migrate/` 或等价受管运维入口，明确只处理 Backend 库；不得直接执行 SQLite dump 作为 PG SQL。迁移实例以 migration_id、source_snapshot_id、source_schema_version 固定来源，记录表级完成与最终验证完成标记；仅同一冻结快照可续传，其他非空目标拒绝。迁移报告包括每表计数、主键映射、按主键分批规范化内容校验和、外键/owner/权限检查及工件哈希。
+测试：新增迁移工具的 `main_test.go` 与 `integration_test.go`，固定脱敏 SQLite 夹具覆盖全部当前 schema、布尔/空值/时间/JSON/Unicode/二进制向量/秘密字段、幂等重复导入、缺文件、未知 owner、断点重试及目标已含数据拒绝。
+操作顺序与回退见第 6 节。出口：隔离环境迁移与恢复验证完成，由用户批准窗口后才切正式服务。
+
+### U5. 执行所有权、持久命令与共享状态
+
+依赖 U3，团队现网切换不必等待整个 U5；对应 R4/R6/R7/R10。修改 `internal/runmgr`、`internal/store/recovery.go`、`internal/squadadapter`、`internal/runtime/squad_runner.go`、`internal/blobstore`；新增 Store 的 lease/inbox/outbox 与 PG RunStore 适配器。
+按 KTD4/KTD5/KTD9 设计 Native checkpoint 接口，继续支持 local 文件实现；不把 JournalOnly 日志误当作业务上下文权威。Worker 工具沙箱与访问范围沿用现有方向，在执行端检查当前身份和 epoch。
+测试：新增 `internal/runmgr/multi_instance_test.go`、`internal/store/lease_pg_test.go`、`internal/blobstore/object_store_test.go`；扩展 `internal/runmgr/recovery_test.go`。必须启动两个真实进程：同会话争抢、不同会话并行、跨实例取消/HITL、命令提交后消费前 owner 换代、旧 gate 的审批明确失效、Worker 被杀、旧 Worker 迟到结算/写事件/写文件、失联重连、副作用结果未知、文件缺失/重复发布。
+出口：所有写入和工具副作用的失效 owner 处理有实证后，才允许第二实例承接写请求；故障状态可见，不能仅靠粘性路由。
+
+### U6. 事件追赶与数据库向量检索
+
+U6 内分三个交付切片，稳定工作包 ID 不变：事件追赶/重连修复依赖 U2，可与 U3 并行；事务 outbox 与投递闭环依赖 U5；向量 schema 与查询改造依赖 U2 迁移器及 U3 授权合同。对应 R5/R6/R9。
+事件：修改 `internal/pgbus/pgbus.go`、`internal/runmgr/events.go`、`internal/server/server.go`、Store 事件接口。扩展 `internal/pgbus/pgbus_test.go`，新增 `internal/server/sse_gap_test.go`：批次 64 条全部可见、断线补齐、通知丢失、订阅与补查竞争、1000+ 分页、慢消费者、撤权后新事件拒绝。第一切片完成只证明追赶修复，不声称 KTD6 的事务 outbox 已就位。
+向量：修改 `internal/store/vectors.go`、`internal/store/migrate.go` 与现有知识索引管线；新增 `internal/store/pgvector_test.go`。验证模型身份/维度隔离、内容更新/删除原子性、回填中重启、索引未完成可降级、中文全文混合、共享授权后 top-k、撤权、与精确检索 Recall@10 对照（建议≥0.95，待批准）。索引构建不得拖垮前台连接/IO。
+出口：先验证正确与有界，再按容量结果决定 HNSW 与缓存；绝不以 extension 存在替代查询计划/召回证据。
+
+### U7. 压测、故障验收与分布式放行
+
+依赖 U2/U3/U4；双实例验收另依赖 U5/U6。对应全部 R。首期单实例放行必须完整重放现有入口的 R6 权限矩阵（含 SSE 后续事件、共享检索、下载、Host/工具与撤权），并证明 U3 恢复隔离；不能等 U5/U6 才验证这些 P0 要求。跨实例传播与接管的新增验证随 U5/U6。新增 Dev `tests/load/collaboration/` 与 `tests/integration/multi-instance/`，由隔离测试入口负责启动/回收自己创建的资源。
+按第 3 节负载合同和第 7 节矩阵测量，记录原始 k6/pgbench、服务指标与数据不变量；pgbench 只测数据库能力，不能替代业务 API/SSE/Agent 验收。正式测试不打生产服务。
+出口：单实例团队、双进程、双主机分别出具结果；CI 身份/链接/SHA 或独立 REPLAY 可核验才用于放行。本地 SELF 只能作辅助。变更智能体行为时补真实模型前后任务级对照。
+
+远期 P2：需求达到后再拆 API/Worker/索引服务，按表归属收紧角色；引入 PG 高可用与自动故障转移、对象存储冗余、可选 PgBouncer。服务拆分与 DB 复制是两件事；Redis 集群、读副本和缓存不能替代主库一致性，读后写敏感路径保持主库读取或显式一致性令牌。
+
+## 6. SQLite → PostgreSQL 切换和恢复
+
+1. 固定源服务制品、全部数据库/文件路径与目标空库；指定迁移 owner、窗口、可接受中断和回退判据。先做只读盘点与隔离演练，不接触其他服务的数据。
+2. 为 SQLite 做一致性备份（应用已有 Backup/VACUUM INTO 或官方备份路径），同时生成工件/checkpoint/工作区清单。活跃 WAL 数据库不能只复制 `.db` 文件；检查备份可打开且内容与清单匹配。
+3. 预演使用独立测试目标 PG，由 migrator 建 schema/扩展，再按依赖顺序导入。显式保留 ID、幂等键、事件 seq、哈希/秘密、用户归属、共享范围、审批状态，调整序列值和类型。预演库不成为正式目标；所有副本遵守 KTD14。
+4. 最终窗口暂停新写与调度，等待或安全收口在途 run；无法确认外部副作用的 run 写入 U3 的持久 recovery hold。停止全部旧写者后取最终一致性快照，导入新空正式目标；按 U4 的同快照迁移身份续传。全量对账与验收抽样完成并写入完成标记后才可切入口，保留只读源备份及过渡期权威文件。目标已服务或身份不同的非空库不得覆盖。
+5. 仅一个入口切到 PG，检查版本/配置指纹、库身份与数据归属，执行用户登录、项目、会话、审批、检索、下载的冒烟；应用 fail-closed，不能故障后回 SQLite。原库不再写，不使用临时双写制造两个权威。
+6. **PG 接受新写入前**可撤回切换，确认目标未产生业务写后恢复 SQLite。**PG 接受新写入后**禁止直接指回旧 SQLite；优先保留 PG 回退兼容应用或向前修复。确需反向迁移，重新冻结写者、导出 PG 增量、对账并批准专门回迁方案。
+7. 建立 pg_dump 逻辑备份，以及 pg_basebackup（或等价物理基础备份）+ 连续 WAL 归档/PITR，并与对象存储版本/清单联合恢复；pg_dump 不能用作 WAL 回放的基础备份，保留足够不可变对象。每次演练恢复到新目标，核对应用可用与权限/文件完整性，不能把“备份命令成功”当作可恢复。
+
+SQLite 本身支持可靠事务与多人经同一应用访问；WAL 提升读写并发，但同一数据库仍只有一个 writer，且不适合多主机通过网络文件系统共享 WAL。取舍基于写负载、进程拓扑、恢复与运维目标，不用“超过某人数 SQLite 就出错”的判断。[SQLite WAL 官方文档](https://sqlite.org/wal.html)。
+
+## 7. 最小验收矩阵
+
+| 场景 | 必须观察到的结果 | 对应 |
+|---|---|---|
+| 同 requestId 并发/网络超时后重试 | 一个逻辑请求和同一 run，不重做已经确认的副作用 | R3/U3/U5 |
+| 两实例同会话不同请求 | 仅一个主执行；另一个排队或明确冲突，子代理不受错误唯一约束阻断 | R3/R4/U5 |
+| 多项目并行、热点会话、满额度父子派生 | 公平、有界；等待父 run 不阻塞子 run 获得许可，所有任务能前进或得到有界拒绝 | R1/R8/U3/U7 |
+| 并发修改同卡/设置 | 成功与冲突可辨认，无最后写入静默覆盖 | R3/U3 |
+| 在 B 提交 A 所有 run 的取消/HITL，消费前换 owner | 命令持久、唯一消费；取消随逻辑 run 生效，HITL 重验 gate 版本，卡片与 run 最终一致 | R4/U5 |
+| Worker 崩溃/暂停超过租约后恢复 | 新 owner 可受控接管；旧 epoch 不能提交；不明副作用不自动重放 | R4/R7/U5 |
+| PG 断连/提交响应丢失 | 依赖不可用有界失败；恢复按幂等记录核对，不自动切 SQLite | R2/R3/U3 |
+| Redis 断连/INCR 后崩溃 | 不改变业务事实；昂贵任务仍受硬预算；恢复无永久计数键错误 | R8/U3 |
+| 批事件/断开 LISTEN/通知丢失 | 所有已提交事件按连续 cursor 追赶，重放不跳洞 | R5/U6 |
+| 撤销成员权限/跨 owner 猜测 ID | 新请求、流后续事件与下载/检索/工具均不泄漏 | R6/U3/U5/U6 |
+| 多模型向量/过滤后 top-k | 不混模型，权限正确，召回/延迟达批准阈值 | R9/U6 |
+| 迁移崩溃/坏文件/未知 owner | 阻止切换；重试不重复导入，不隐式公开历史数据 | R7/U4 |
+| 磁盘满/备份恢复/整机失效 | 清楚拒绝写入和报警；在约定故障模型与 RPO/RTO 下恢复 | R7/U4/U7 |
+
+## 8. 工具、观测与交付
+
+本轮未安装软件、修改配置、运行迁移、重启服务或压测。brew 已有三项服务软件，当前瓶颈主要是接线与一致性机制，暂不重复安装。未来压测可通过 [brew 安装 k6](https://formulae.brew.sh/formula/k6)；PgBouncer 只在连接测量证明有必要后安装。安装授权不等于对共享数据库升级、创建扩展或变更服务的授权；执行前核对目标、版本与既有占用。
+
+必需观测：API P95/P99与预期/非预期错误，DB pool wait/连接数/慢查询/锁等待，队列长度/最老年龄，run 租约/过期写拒绝/未知副作用，SSE cursor lag/补查次数，Redis 错误与降级，检索耗时/召回抽样，备份时间与恢复结果。日志只记录 request/run/owner 的安全标识，不记录 DSN、密钥或文档正文。
+
+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 失败，产品代码未改。本地 SELF 不能冒充 GATE/REPLAY 放行；双主机仍缺。部署与第二实例写流量仍未授权。
+
+方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
+
+首选下一增量不要自动开工。剩余放行门槛是：独立 REPLAY，或把 C4/C5 快速档接入 CI 形成 GATE（需平台准入）；以及 C3 双主机（需第二台机器）。在此之前要先修上传缺陷：未设置 `BLOBSTORE_S3_ENDPOINT` 时，空的 `*S3` 被放进对象存储接口，上传 panic，C5 的 K4 因此失败。GATE/REPLAY 与 C3 未齐、K4 未重测通过前，不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。

docs/proposals/2026-10-11-generative-ui-u5-action-scope.md

@@ -0,0 +1,95 @@
+---
+title: Generative UI U5 action-scope proposal
+date: 2026-10-11
+type: feat
+revision: r2
+status: approved
+product_contract_source: generative-ui-r2-U5-clause
+---
+
+# Generative UI U5 动作范围提案（待用户评审）
+
+依据：主记录 r2《Generative UI 调研与插件方案》U5 条款「**必须先评审本阶段动作范围**」。
+本文是该评审的提案稿：给出动作分类与开放范围、审批挂接要求、明确排除项与验收条件。
+用户裁定前不实施；实施另行开任务（U5 实现）。
+
+负责人：裁定 weichen（用户）；起草 Agent；更新时间 2026-10-11。
+
+## 一、动作分类与本增量开放范围
+
+| 类 | 定义 | U5 开放范围 | 通道 |
+|---|---|---|---|
+| **A 客户端本地** | 零副作用：页签切换、折叠展开、排序筛选、复制、doc-ref 打开工件预览 | **全部开放**（U4 已具雏形） | 纯前端，不经命令总线、不审计（无副作用可审）；模型不能把 A 类标成"已执行" |
+| **B 白名单命令绑定** | 把**既有命令目录**中的命令绑定为页面动作按钮 | **机制全量建设，第一版白名单为空**（见下） | cmdbus 四入口同源分发：审计信封、参数 Schema 校验、DangerHigh 确认卡 |
+| **C 插件自身低危写** | generative-ui 表单提交落**插件自有**存储（Host.KVPut / 后台任务台账），不触发任何业务系统变更 | **开放**（场景 3「方案选择和需求表单」的实现面） | 新插件命令 `generative-ui.submit`，经同一分发/审计/幂等 |
+| **D 业务写与高危** | 业务系统写（任务/项目/工件/知识库变更、对外发布、外发消息）、DangerHigh 命令直执、跨 owner/跨项目资源、代码执行 | **全部不开放** | U6+ 逐类单独评审后按 B 类机制逐条加白 |
+
+**B 类第一版白名单为空的依据**（2026-10-11 源码事实）：当前内置命令为
+builtin.help / system.intent / conversation.create / runtime.mock / models.set /
+conversation.profile——除 help/intent 外均为中危**写**命令，不存在可安全首开的内置只读命令。
+结论：U5 交付「绑定-审计-幂等-确认」管道与测试，白名单从空起步，此后每加一条都走
+独立评审（增量为零的机制 + 可验证的拒绝路径，先把地基打牢）。
+
+## 二、审批挂接要求（映射 r2 KTD6 与现有机制，全部为既有能力复用）
+
+1. **生成的按钮不是批准**：页面动作提交 → 宿主校验（启停/epoch/revision/权限/参数）→
+   `cmdbus.Dispatch`（Entrance=button，归一入审计信封）。模型只能引用允许的 action 名称，
+   不能伪造执行结果。
+2. **DangerHigh 自动挂既有确认卡**：命中 `spec.Danger == high` 且未 Confirmed 时走现有
+   内联确认卡 + pendingStore 持久化 + Confirm 回道二次分发——**用户点卡确认是唯一批准来源**；
+   Confirmed 标志只能由卡回道置位，模型路径无法携带（红测断言）。
+3. **幂等**：requestId 由客户端生成；服务端绑定 `(owner, surfaceId, revision, actionId,
+   requestId, 参数哈希)`。重复 requestId 同参数 → 返回已有回执；同 requestId 异参数 → 拒绝
+   （对齐 KTD6）。
+4. **旧修订受控**：动作提交带 revision；revision ≠ 当前 latest → 拒绝并提示刷新
+   （旧按钮不重放）。
+5. **禁用语义**：activation 关闭后新动作 403；在途按 U2 KTD7 表（已提交业务操作按命令台账
+   收尾，不承诺撤销）。
+6. **表单草稿不进模型**：草稿由前端按 surfaceId/nodeId 管理，未提交不上传、不进
+   ctxasm（KTD4/KTD8；测试断言上下文不含未提交字段值）。
+7. **参数校验**：动作参数按命令 ParamsSchema 服务端校验（validateParams 既有），拒绝
+   越权资源引用（owner 作用域）。
+
+## 三、交付范围（实施任务的文件面，供参考）
+
+- Backend：`POST /api/surfaces/{id}/actions`（提交动作，走 surfacesvc 守卫 + cmdbus）；
+  幂等台账迁移（新表，纯增量）；genui 目录文档补 action 绑定语法与「仅允许引用宿主下发的
+  action 清单」纪律。
+- UI：UIRenderer `actions` 分支已有渲染，补 onAction 桥到宿主提交（SurfaceView 转发）。
+- Frontend：SurfaceView onAction → 动作端点；确认卡复用现有 HITL 卡 UI；
+  表单草稿本地态（提交前不外发）。
+- Core：优先零变更（action 绑定用服务端表，不扩 UINode 契约）。
+
+## 四、明确排除（本增量不做）
+
+业务实体写路径、跨会话/跨项目动作、自动触发的动作（只响应用户点击）、
+动作结果自动改写页面（回执展示后由用户或 Agent 显式重组织）、
+MCP/外部 HTTP 直连、任意命令即时全开。
+
+## 五、验收条件（R7 映射，实施任务的判定线）
+
+1. 场景 3 表单可提交、校验失败可修改重试；提交落插件台账可回读。
+2. 旧 revision / 越权 action / 重复 requestId 异参数 → 拒绝（红测矩阵）。
+3. DangerHigh 路径必须经确认卡；模型伪造 Confirmed 被拒（红测）。
+4. 用户未提交的表单字段不出现在下一轮模型上下文（测试断言）。
+5. 禁用后动作 403；A 类本地行为不受影响。
+6. 幂等重放返回相同回执（并发双击一次生效）。
+
+## 六、裁定记录（2026-10-11，用户已裁定）
+
+三点均经用户裁定**同意**（推荐项全取）：
+
+1. **分类与范围**：A 全开 / B 机制先行白名单空起步 / C 限插件自有写 / D 全关——同意。
+2. **C 类边界**：限定 KV + 后台任务台账，不建新业务事实表——同意。
+3. **确认卡 UX**：复用现有内联确认卡，不新建审批 UI——同意。
+
+本文升级为已批准范围；U5 实施按 policy/delivery.md 开任务（feature/generative-ui-u5），
+验收线以第五节为准。
+
+### 七、原裁定请求（历史留档）
+
+1. **分类与范围**：A 全开、B 机制先行白名单空起步、C 限插件自有写、D 全关——是否同意？
+2. **C 类边界**：插件自身写是否限定为 KV + 后台任务台账（不建新的业务事实表）？
+3. **确认卡 UX**：复用现有内联确认卡（不新建审批 UI）——是否同意？
+
+裁定后：U5 实施按 `policy/delivery.md` 另行开任务；本文升级为已批准范围并回填裁定记录。

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

@@ -0,0 +1,503 @@
+---
+title: RDM 最终目标核对、系统差距与完整交付方案
+date: 2026-10-11
+type: feat
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 最终目标核对、系统差距与完整交付方案
+
+修订 r1；负责人 weichen；编制 Codex；更新时间 2026-10-11（Asia/Shanghai）。
+用户已明确最终实现范围：全部文档模板、文档三权、系统级项目及独立两树一网协作；本轮进一步要求先核对目标和差距、形成详细完整方案。
+本总体方案待人工评审；业务实现、迁移、真实模型评测、浏览器验收、上线均 NOT_RUN。
+本文件承担本次最终目标补齐的统筹记录；不替代 RDM 已批准需求正文。实施负责人按各工作包立项指定，不预设已有人承接。
+下文 `RDM:` 为 Agent-System-RDM，`Dev:` 为 Agent-System-Dev，`Legacy:` 为旧 Agent-System 的仓内路径。
+
+## Goal Capsule
+
+让不同用户在同一个系统级项目内，用各自私有的对话和资料工作，通过有权限的项目知识协作，按模板完成全部体系文档的编制、审核、批准，并能追溯来源、版本、决策和验证结果。
+
+采用 RDM 领域实现与基座通用能力组合：先接通项目、权限、资料和持久运行，再完成全部文档及三权、需求和合规链、项目生命周期与交付。
+项目建议书、竞品分析仍作为第一条真实验证路径；**最终交付包含全部 69 类现有文档模板与现有报价 XLSX 资产的接入，不以两份试点或目录登记完成作为终点**。
+每个项目可按自身适用性选择文档，但平台模板覆盖不能以“不适用”替代未实施。新增模板也必须沿同一发布、生成和验收契约接入。
+
+本次三项关键口径已由用户明确，不再列为待决：系统内同名项目唯一；创建者在平台管理员上限内覆盖管理；个人聊天/原件/草稿私有，受控文档按三权及明确授权读取。
+后续遇到模块职责、权限范围、外部集成或交付顺序重大改变时按 `Dev:policy/delivery.md` 回到受影响阶段评审。后移目标逐项保留，不能无记录地消失。
+
+---
+
+## Product Contract
+
+### Authority and Confirmed Decisions
+
+权威顺序：本轮用户明确指示和澄清 → 已批准 U0 D1–D9、V2.2 Q1–Q8/D10 裁定及权威正文 → 未被取代的既有定稿条款 → 原始会议材料 → 派生摘要/旧审计快照。
+原始 ASR 与用户补充可用于查清意图；不能用旧会议草案反向覆盖较新的明确裁定。`.tmp` 原件保持不改，正式需求修订仍进入 RDM `docs/requirements/`。
+
+`RDM:docs/requirements/README.md:15–21` 明确 01/02/03/04/08/09 已于 2026-10-09 合入定稿 V2.2；05/06/07/10 未重发，但解读服从新裁定。U0 页首 proposed、部分 V2.2 正文“待评审”等是残留状态文字，不能据此宣称需求未批准。
+前一份模板生成方案对这些残留文字的判断在本次纠正；其具体实现建议依然是待评审方案。
+
+| 编号 | 用户重申与最终口径 | 与最终设计的关系及依据 |
+|---|---|---|
+| D1 | 系统可有多个不同项目；同一名称只对应一个权威项目身份，用户加入后访问同一个项目 | 符合 UR-22、SR-G10；01:312、517；用户补充 S:50 |
+| D2 | 创建者默认项目负责人，在平台管理员设置的范围和上限内管理成员、覆盖权限、分配每文档三权 | 符合 SR-G8/G9、U0 D2；用户设计意见 D:76；本轮再次确认 |
+| D3 | 每项目有独立笔记树、文档树、追溯网；成员及其智能体通过授权后的项目知识协作 | 符合 SR-G11、SR-N4、08 数据模型；S:60–61 |
+| D4 | 个人聊天、上传原件、个人草稿默认私有，受控文档只向三权人员与明确授权者开放，不自动全员共享 | 用户本轮明确确认；与 U0 D3 私域边界及 SR-C7 三权相容；SR-G12 的主动只读分享仍须明确授权 |
+| D5 | 管理权不自动包含读取私人资料、发起代编、代审、代批 | 已批准 U0 D2、V2.2 A4；S:65–72；创建者也受职责分离约束 |
+| D6 | 先项目建议书/竞品分析验证，最终扩展所有文档 | 上轮用户选择与本轮“所有文档加入并实现”；阶段顺序不缩减最终范围 |
+
+S=`Dev:.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`；D=同目录 `user-design-ideas.txt`。原文 S:35–36 提出上限内覆盖，D:75–76 的直接用户意见收敛该选择；S:40–73 同时定义项目、私聊、共享知识和三权。
+晚会原始 ASR（2026-10-08_19-36，00:37:00–00:37:21，正文段落 P329–P338）确认共同项目根，不能单独拿它证明私有权限；该部分依据以前述用户补充及本轮确认为准。
+
+### Problem Frame
+
+目前存在“基座界面里的用户项目”和“RDM 领域项目”两条没有完整贯通的路径。RDM 已实现项目表、部分权限计算和章节审签，但用户还无法通过统一界面完成研发项目管理及全部文档工作。
+多份历史任务卡把局部领域方法、测试桩或直接处理器调用概括成阶段完成，掩盖了真实入口、授权、持久恢复、资料来源和部署组合的差距。
+因此需要围绕最终用户路径重新映射证据、补齐已有实现，而不是从零重建或只补一页项目设置。
+
+### Current State
+
+本轮证据等级为 SELF：当前源码、测试资产、原始会议材料、只读进程构建元数据。未读业务数据库、未操作业务数据、未执行模型/业务测试。
+调查基线：Dev `80a518628c526fd6ddece4abeb707ab4bb0b5618`；Backend `c8d66ca3cd21b055a8605e9eb4d8e525037618a6`；Frontend `3ed10e122042a64180fb24a42d9cc6438cd2d2d6`；RDM 初查 `0081628a10ec48a36537c6eced11a57439c986fa`，本轮期间项目授权改动合入后已增量复核至 **`d8d7e7436ca501e3ae03bbea9cc60405c74b9afc`**；RDM Backend pin `421fee81c314c05530bc809e224b5d0818ec3472`，Frontend pin `84b73ab32848e623d0a0ab7ade552784dca8cf3c`。
+原始命令、固定对象和输出见 [调查收据](../records/2026-10-11-rdm-final-target-source-receipt.json)。源码基线不等于部署组合。
+
+只读观察到 Dev `runtime/dev/bin/agent-system` 正运行 Backend c8d66ca 基座入口；另有较早、位于临时或已删除工作区的 RDM 进程。用户当前访问的 URL/实例尚未核对，不能据此直接判定其浏览器所见部署了哪个产品。正式验收须固定实例、端口、二进制摘要、组件 pins 和数据根；本轮不停止或清理这些进程。
+
+| 差距 | 当前已有 | 尚未完成及影响 | 源码定位 |
+|---|---|---|---|
+| G1 项目入口 | Dev 有新建/切换/通用设置；RDM 有项目/成员命令 | Dev 创建走 owner 项目，无同名全局约束；未接研发成员/职责管理 | Dev frontend store.ts:286、ProjectSettingsModal.tsx:23；Backend store/projects.go:15 |
+| G2 唯一身份 | RDM name UNIQUE、TrimSpace、创建者字段；新增一对一 HostBinding 与映射读取 | 绑定尚缺宿主项目存在性/绑定权限核验；成员不在 ListProjectsFor 目录中，页面仍首项/默认选择；新建与负责人写入非原子 | projects/projects.go:69、89；rdmapp/projects_api.go:23–87；web/app.js:98 起 |
+| G3 权限覆盖 | 已有 cap∩override/default、12 动作；新增命令守卫，删除建项目自动引导管理员，改部署引导＋单行约束 | cap 管理仍认 RDM 台账，平台管理员可信接入未完成；专业角色/资源策略不足；doc.write 不等于编制职责；超管槽未接 | perms/perms.go:18–60、112、172、302；perms_api.go 的 AuthorizeCmd；runtime.go:172 起 |
+| G4 私域与协作 | 私有会话 owner 边界；RDM 禁止上传预索引/会话卡镜像 | EXT-8 项目布尔授权会放大到整项目工件，无法区分原件/发布快照；Host 仍 owner-only；成员上传、发布、检索不一致 | plugin.go:31；runtime.go:136；Dev server.go:1134、1199；RDM pin hostcaps.go:219 |
+| G5 两树项目分片 | WorldFor、项目事件重放；主要命令新增非空项目/动作守卫，图走审计权限，上传台账按项目过滤 | rdm.init 仍可进入全量自举写路径；仍需全入口与对象归属验证；业务读/导出与审计读须分开，原件不能仅按项目过滤 | runtime.go:81–117；plugin.go:850、879；init.go:39、52；upload.go 的 UploadsList |
+| G6 文档三权 | 章节角色异人、锁定、全员审核、正式链；生成已有通用动作权限检查 | 非文档级；指派对象未核有效账号/成员；通用 doc.write 未收紧到指定编制人；审签 schema 与可信 actor 处理仍矛盾 | domain/review.go:31、69；plugin.go 的 review 规格、rdmDraftCompose/Apply |
+| G7 模板覆盖 | 69 种 docType；旧 69 Markdown＋1 XLSX；当前 4 模板 | 仅覆盖 3 类；首项模板误选、模板可静默缺失；结构/格式/版本未统一 | 模板盘点与生成子方案 G1–G10 |
+| G8 对话生成 | Compose 实际调用模型；Draft/Apply 存在；UI 新增领域项目注入与绑定尝试 | intent 类型键错误、未投影工具；缺持久提案/整文版本；旧依据可能丢失；独立页面普通文本 cmd=null 后 startsWith 仍在 | compose.go、draft.go、plugin.go 的编写 intent/compose 规格；web/app.js:410–448 |
+| G9 解析与锚点 | 原件保留、md/txt/docx、部分表格/标题锚点 | 未接 ParseDocument；PDF/表格/演示文稿/图片未完整消费；慢切片改 slow:batch 丢原定位 | parse.go:33、346；slow.go:267 |
+| G10 统一摄取 | 上传相关性三态、纯文本公共入库终点、发布方法 | 普通 ingest 可绕过相关性；发布未带 ProjectID，失败无持久补偿；上传非空摘要占位跳过真实摘要；聊天自动沉淀未接 | ingest.go:89、122；upload.go:406–409；llm_summary.go:20 |
+| G11 结论与冲突 | 结论提议/确认、词面冲突检测、supersedes；拒绝提议已校验所属项目 | 确认提议仍按 id 查询未限定项目；固定阈值且已有结论后不再触发；无完整候选组/两层裁决；Resolve 可误关其他争议 | conclusions.go:125–135、264、310；domain/fc/collide.go:35、125 |
+| G12 需求与合规 | UR/SR 台账；15 节点/11 边、四视图、八规则、矩阵/导出 | 六维/父子分解不足；受控节点和边写方法无生产调用；只有读命令，缺真实业务生产者 | requirements.go:21；compliance.go:155；plugin cgraph commands |
+| G13 法规双通道 | 知识检索与法规声明记录 | “网络通道”用 Complete 生成 URL JSON，无实际搜索/抓取；不能作为独立网络核验 | regcheck.go:35、58–72 |
+| G14 阶段与完整性 | 部分素材数/待确认文字检查 | 项目无阶段状态；缺推进/结项用户路径；审核提交未接内容/合规缺口门禁 | projects/projects.go:17；baseline.go:82；review.go |
+| G15 长任务 | 内存队列、慢任务台账、重启标 failed | 不保存恢复所需项目/owner/原输入；不能续跑；通用快慢任务与取消恢复未闭合 | slowledger.go:31–43、74–77；slow.go |
+| G16 看板与影响 | 职责/编制状态/正文变化投影 | 来源变了而正文未变时看板无法反映；缺影响对象、责任人、解决状态的闭环 | kanban.go:26、67；todo.go |
+| G17 版本导出 | DOCX/XLSX 代码和测试 | 未按模板渲染格式、未绑定整文批准快照；合规导出正文为当前图却展示最新快照 hash | docx.go:155、298；cgraph_export.go:114 |
+| G18 团队部署与执行 | 基座 PG/Redis、预算与动作矩阵；RDM 执行硬关闭 | RDM 领域仍 SQLite；动作矩阵公开接线不足；隔离执行尚未替代禁用；缺真实 RDM 双实例与备份恢复 | RDM domain/store/store.go:21、main.go:188；Dev server.go:90 |
+| G19 完成证据 | 单测、桩 E2E、历史任务卡与 smoke | 真实三用户/两项目/模型/浏览器/安装包验收缺项；历史广义完成声明不能覆盖实际缺口 | v01_e2e_test.go:28、61、99、120；selfhost.go:130 |
+
+“部分已有”表示可复用，绝不表示运行通过；“未接通”也不应改写为“所有组件都没有”。
+RDM 数据库名唯一仅证明该源码对单数据库的精确字符串约束，尚未核实部署旧库索引；多数据库、多实例及名称规范化另需验收。
+本轮新增实现来自 RDM 项目授权 #195/#196 的提交；上传来源项目解析、批次授权及结论拒绝的项目约束也已补入。未受此次改动影响的解析、模板、语义检索、任务恢复和合规生产缺口继续有效。U2/U3 必须复用这些新能力并补闭环，不能重复建设。
+当前最高优先级之一是宿主绑定的双向权限：仅证明“我是 RDM 项目创建者”不足以绑定一个任意宿主项目。绑定前必须在宿主核验真实项目身份及调用者管理/绑定资格，并在服务端绑定可信上下文；否则已有共享读回调会扩大到不属于该主体的宿主资料。
+绑定管理不能复用只读 AuthorizeAudit（当前 canManageBinding 的回落会在未来超管接线后扩大写权）。同理，合法三权人员查看/导出自己的文档不应要求其具备整个项目审计权限；当前 doc.export 的审计守卫需要按业务资源重新分类。
+
+### Requirements and Acceptance
+
+完整逐条索引见 [34 UR／68 SR／10 F 对照矩阵](../records/2026-10-11-rdm-final-target-requirements-matrix.md)。下表以 R-ID 固定本次设计不变量，保留原 UR/SR 作为正式需求身份。
+
+| ID | 必须成立的最终行为 | 可判定验收 |
+|---|---|---|
+| R1 | 同系统项目名称与身份全局唯一 | 不同用户并发创建同名只有一个成功；加入成员看到同一 projectId；不存在按用户复制 |
+| R2 | 上限内覆盖权限，并在执行端生效 | 撤销上限后旧 override 立即不生效；页面/API/命令/工具/任务恢复均拒绝越界 |
+| R3 | 创建者可管理项目成员与每文档职责 | 项目负责人完成分配；平台全局权限不因建项目增加；职责对象必须有效且是成员 |
+| R4 | 私聊/原件/草稿私有，受控文档按职责或明确授权读取 | 同项目其他成员无法通过正文、计数、搜索、摘要、预览、下载、追溯、模型输出读取未授权内容 |
+| R5 | 每项目两树一网独立且内部按权限协作 | A 项目成员/智能体可使用 A 的发布知识，不能读取 B 项目或 A 的私有原文 |
+| R6 | 全部现有文档类型可用，模板发布后结构/格式固定 | 69 类逐份有发布模板和真实生成验收；报价 XLSX 独立验收；项目不适用不减少平台覆盖 |
+| R7 | 原件、解析、锚点、标签、知识发布可解释且可恢复 | 多格式能力分档声明；失败原件可取回；慢处理不丢页表锚点；存疑/拒绝不进共享检索 |
+| R8 | 结论、冲突、依据选择受控 | 新资料可触发结论更新；文档层选择不改变项目全局结论；裁决只关闭指定争议 |
+| R9 | 对话生成整文可修改可恢复，采纳才生效 | 模板与输入版本固定；无依据不编造；旧引用不丢；重复提交不重复写；部分采纳后整文仍一致 |
+| R10 | 文档三权完整执行 | 编制一人、批准一人、审核至少一人且互异；审核/批准不可改正文；提交锁定，全员审核后才能批准 |
+| R11 | 文档/需求/验证/风险/合规链真实生产和历史可重建 | 业务操作产生版本节点与候选边，人确认生效；导出内容/哈希/批准快照一致；无伪造验证结论 |
+| R12 | 项目有阶段、准入准出和结项 | 仅在提交审核/申请推进时执行正式缺项门禁；不合格不能推进；按固定快照决策并可追溯 |
+| R13 | 对话、卡片、工作区为同一对象的入口 | 右栏收起仍能完成任务；刷新/重启不丢；过期卡片不生效；不以假数据替代真实产物 |
+| R14 | 团队运行具备当前授权、事务一致、恢复和隔离执行 | 两项目多人并行、撤权、故障注入、备份恢复通过；禁执行仅为过渡，最终隔离后按策略开放 |
+| R15 | 全部已批准目标有去向和真实证据 | 34 UR/68 SR/10 F 无漏项；实现、测试、部署分别登记，只有显式裁决可取消目标 |
+
+### Scope and Completion Levels
+
+核心完整交付 C1：U1–U14 加 U16，覆盖项目/权限、私域与协同、全部模板、三权、资料、知识、需求合规、生命周期及团队可用性。
+最终扩展交付 C2：U15 的 F-01…F-10 各项完成或经用户明确裁定取消/替代；外部系统接入受凭据、平台授权与独立交付条件约束。
+**C1 通过不能写成所有最终目标完成。** C2 未完成的目标保留在同一矩阵，不将“后移”改成永久非目标。F-09 已有较新两树一网展示方案，应并入 U11/U14，而不继续沿用早期延期状态。
+完整方案不意味在一个大 PR 同时改完；按依赖交付，每阶段保留可回退、可独立验收的增量。
+
+---
+
+## Planning Contract
+
+### KTD1. One Project Identity
+
+推荐继续由 RDM 保存研发项目、成员、职责权威；基座提供共享项目上下文及私有会话/工件能力。用户看到的是**一个系统级项目**，宿主内部 ID 只作一对一技术映射，不能再产生每用户一个同名研发项目。
+对照备选：把研发项目权威搬入基座需重新划分领域职责，成本更大；为每位成员复制基座项目会破坏唯一身份与追溯，不采用。
+统一入口的创建/改名/归档均调用项目应用服务。RDM 产品界面不再暴露绕过该服务的独立“个人研发项目”创建路径；通用基座个人项目保留为基座模式能力，不混入 RDM 项目目录。
+复用新合入的 HostBinding 表与命令，补宿主端存在性、绑定资格和实例域校验；不能仅凭 RDM 创建者权限接受任意 hostProjectId。项目目录分为成员工作目录与受限审计目录：普通成员必须看到加入的项目，但不因看见项目获得审计权。
+
+项目对象包含稳定 ID、名称与规范化键、创建者、生命周期、权限策略版本、文档目录版本及宿主绑定。建议名称规则为去首尾空白、Unicode 规范化、拉丁字符大小写归一；展示原名，规范化键由数据库唯一约束保护。规则在迁移前用现有名称干跑确认，冲突由人裁定，禁止静默合并。
+归档保留名称与身份；删除采用受控归档/软删除，不让新项目复用同名后被误认成旧项目。名称变更的历史同样留存。
+成员可见同一项目不等于全系统用户可列出所有项目；未加入者的同名创建返回名称不可用，不泄漏成员、内容或审计。
+RDM 项目＋创建者成员角色＋名称保留在同库事务建立；跨库宿主绑定采用幂等 provisioning→ready/failed 与可恢复补偿。绑定未完成显示初始化状态，禁止继续向默认项目写入。
+业务只接受服务端从当前会话/对象解析的项目；客户端 projectId 是定位符，跨项目参数或不一致绑定拒绝。外部旧命令的空项目全量回退关闭；未归属历史仅受信迁移工具可访问。
+
+### KTD2. Policy and Duties
+
+普通业务动作的允许条件为：有效账号与项目成员身份 ∧ 平台上限 ∧ 项目 override（未设置则角色默认）∧ 资源可见范围 ∧ 适用阶段/状态 ∧ 操作所需文档职责。
+“显式拒绝”优先；平台上限收紧不需逐一改旧 override 才生效。多角色合并仍受同一上限，冲突按显式拒绝收敛，不依靠前端按钮控制。
+平台管理员维护角色、默认权限、可覆盖上限及受管配置；项目创建者/负责人只调整项目内范围。支持专业角色目录，但编制/审核/批准是**文档职责**，不等同于“工程师角色”或广义 doc.write。
+项目创建不得触发管理员引导；管理员初始化与移交走受信管理入口和事务唯一约束。既有“双层管理员”裁定用于审计可见性，不自动扩大成私人内容阅读或三权签字豁免。
+CreatedBy 固定记录创建事实；负责人变更另有显式委任/接替记录，不重写创建事实。任何接替均不能跨过管理员上限。
+权限、成员与职责变更写入审计并递增 policy/duty 版本；长任务开始、敏感读取、恢复、结果投递、提交、下载都重验。前端撤按钮不足以撤权。
+
+### KTD3. Private Data and Shared Knowledge
+
+| 资源 | 默认读者 | 共享/派生规则 |
+|---|---|---|
+| 个人会话、Agent 中间过程 | 本人 | 不自动镜像项目流；他人模型也不能间接读取 |
+| 上传原件、个人草稿 | 本人 | 文件分享只产生明确的只读授权；不因 projectId 相同开放 |
+| 项目发布知识快照 | 被授权项目成员 | 原件作者明确将选定内容发布为项目知识；可检索内容与原件权限分离，保留来源/发布版本 |
+| 受控文档正文与修订 | 指定三权人员及明确获授权者 | 角色授权随职责/状态校验；全员只读必须明确授予，不默认开放 |
+| 文档树目录、状态、待办 | 按所需最小范围 | 不通过标题、摘要、计数或引用暴露无权文档；负责人可管理职责元数据不代表可读全文 |
+| 项目审计中心 | 按已有创建者/管理员审计方案 | 私人原文、秘密和隐藏推理仍不直接出现在审计 DTO/导出 |
+
+两树一网在项目内共享其业务知识和组织结构，**不等于每个节点的所有载荷对所有成员可见**。文档树仍保存要求＋正文版本（Q8），正文节点继承文档 ACL；追溯遍历使用受限投影，不直接返回内部 payload。
+明确“提交为项目资料”只发布选定知识内容；保留的原文件仍可私人。普通上传不自动发布全文，混合/存疑材料先确认。资料作者可发布脱敏摘要/摘录并保留批准的发布快照，使其他成员能使用该快照而无需读取私人原件。
+审核所需依据应提供职责范围内的证据包：可读发布快照、明确原件授权或经确认的脱敏材料；仅有无权访问的私人引用时不能宣称证据已可核验。文档存储了私人资料的事实也属于披露，提交前必须处理发布授权。
+撤销原件分享立即停止新访问与上下文注入；已经明确发布的知识快照按其独立发布生命周期处理，不把撤销文件链接误当成回收所有已批准知识。撤回发布知识时停止新使用，标记依赖文档 stale；历史受控快照的保留与可读性分别受记录保全及当前授权控制。
+所有 HTTP、Host、索引/检索、卡片/SSE、预览下载、导出、图查询采用同一资源级决策；授权参数包含主体、项目、动作、资源类型/ID/版本、policyVersion。只读布尔项目授权无法表达这些边界，不因补齐项目 ID 就直接开放全项目工件。
+
+### KTD4. Transaction and History Foundation
+
+复用现有两树一网方案的原子事件、幂等、历史重建和 outbox，不再另造第二套事件中心。
+在领域事务内完成预期版本校验、写台账、事件批次及幂等结果；提交后更新投影。跨宿主存储操作通过幂等步骤与 outbox，提交未知时先查结果再重试。
+历史对象为 ID@version，切片原文与历史版本不可变；结构删改用软删除/取代/新事件。普通哈希用于一致性检查，不宣称具备外部防篡改或电子签名保证。
+部分更新、角色调整、关系变化、合规 stale 标记与重放对等；同一历史水位必须还原同一文档/图/职责/审批事实，未知事件版本不得静默忽略。
+旧数据先盘点归属及 ACL。旧 Agent-System 业务数据仍按 O9 不迁移；旧模板内容属于可复用资产，当前 RDM 数据必须保全，二者不得混淆。
+
+### KTD5. Source-to-Knowledge Pipeline
+
+统一上传、明确发布的对话内容、会议和外部研究的摄取契约：来源对象→私域留档→解析状态→相关性/发布决策→带锚点切片/标签→知识快照/索引→冲突与结论候选。
+接入基座公开 ParseDocument，按原件保全、文本、表格、OCR、图像描述、页表锚点逐档标能力；不支持时留原件并明确说明，不把“收到了文件”当作“完整理解了内容”。
+锚点使用 sourceId@version＋页/表/段/偏移；快慢处理沿同一解析块精化，不把锚点替换成不可回跳的 slow:batch。chunk 与 slice 是显式多对多映射。
+共享标签字典版本化，记忆侧描述标签与文档章节需求条件同源；已确认强制材料/旧有效依据不能被 topK 静默挤掉。自动分类及摘要用独立人工金标验证，不以同源样本给自己评分。
+知识发布失败留下可重试任务，不静默计零后报全部入库成功。待裁定、拒绝、撤回的资料不进入共享检索；原件取回与上传台账同样鉴权。
+
+### KTD6. Conclusions, Conflicts and Impact
+
+结论必须绑定依据和材料水位，允许随着新内容提出新结论；模型决定是否足够形成有价值总结，冷却只控制通知频率，不能让“已有结论”永久阻止更新。
+会议纪要结构化抽取结论/待办/待确认，各条带原发言或资料锚点。模型提炼不等于已批准项目事实；采纳由人完成，结果回两树一网。
+冲突对象使用明确 conflictId/groupId 和候选版本。相似度只提供检测线索，不能充当语义矛盾的证据；保留双方陈述、出处、影响与建议。
+文档层裁决选择本文档的依据；项目层裁决改变项目有效结论，由负责人或明确指定知识责任人完成。只关闭该争议，不把两个节点参与的其他争议一起关闭。
+来源、需求、测试结果或规则变化产生影响清单，指向受影响文档和负责人；正文未改变也要显示“依据有更新/验证过期”。看板与收件箱被动汇聚，对话按任务节点集中处理，不频繁插话。
+
+### KTD7. All Templates and Controlled Documents
+
+复用 [模板对话生成子方案](2026-10-11-rdm-template-dialog-generation.md) 的模板元数据、结构、检索条件、格式和发布清单，以及 Run/ContextManifest/Proposal/DocumentRevision 设计。
+完整模板台账覆盖 [69 类旧资产](../records/2026-10-11-rdm-template-inventory.md) 与报价 XLSX。逐份保留来源 SHA，拆分内容要求、格式约束和管理记录；去除旧“任务键＝模板文件名”绑定。
+模板按用途区分正文、纪要、汇报，绑定明确默认；缺模板或版本失效时拒绝“按模板生成”路径，不静默用自由文本代替。v10/v2 使用正式版本语义，不按字典序。
+首批两模板先验证闭环，随后按资产台账完整迁入。每份上线模板均需有材料的成功样本及空缺/冲突反例；不能仅通过注册表计数宣称 69 类可用。
+模板目录是组织资产，项目实例按适用性选择，但全部类型保持可配置可用。标准模板由用户后续提供（F-10），导入需差异评审及版本迁移；用户没有提供的标准模板不伪称已经替换。
+
+三权面向每份文档：编制唯一、批准唯一、审核可多人且至少一人；三者互异。所有审核人通过后才可批准；审核/批准只能批注和通过/驳回，不改正文、不发起生成。
+新文档无职责时任务停在可见“等待分配”，负责人可通过对话或管理页分配；其他成员可转交最小编制请求，不能转发其私人聊天全文。负责人可在上限内给自己分配其中一种职责，但不能同时兼任冲突职责。
+提交冻结整文版本、模板、依据、职责与策略版本。职责变更、成员撤销或正文变动使受影响的待审决定失效；不能先让本人编制，再改职责给本人审核/批准同一提交版本。历史职责/操作身份参与分离校验，角色改名不洗掉已执行事实。
+生成、人工修改、导入、旧命令、直接状态迁移必须经过同一编制与版本服务，不能从旧入口绕过。
+旧章节职责和签署作为历史保留，不能拼成“整文已批准”；启用文档级流程前明确职责并处理旧活动审签，首个整文正式版本重新审签。驳回只增加内部修订，终批才产生新正式版并建立取代关系。
+实际采纳的新旧章节组合须重新验依赖、术语、指标一致性；确认绑定该组合 hash，事务前重验版本。版本＋引用/追溯＋提案状态＋领域事件全成或全败。
+
+### KTD8. Requirements and Compliance Producers
+
+复用已有 15 类受控节点、11 类边、四链视图、八完整性规则、快照、矩阵和导出器；补真实业务生产者及写入/确认入口。
+需求台账支持批准基线要求的 UR/PR/SWR/HWR 等类型、父子分解及六维分类；保留原 UR/SR 编号兼容映射。用户需求先确认后分解，法规反推产生候选，不直接替人定需求。
+设计、风险、风险控制、测试计划/执行结果、验证、确认、设计转换、SOUP 等对象通过各自业务动作产生版本节点；字符串 LinkedSections/LinkedTests 迁为受控版本边，映射歧义保留待处理。
+模型只推荐合规关系，授权人确认转正；目标升版标 stale，不自动转移旧签名/旧验证结论。验证结果必须关联实际被测版本、执行者与证据文件；没有实际结果时仅可生成计划、空表或 NOT_RUN 草稿。
+法规双通道必须是受控知识库＋真实联网搜索/抓取的独立证据，保存 URL、取得时间、文档版本、片段锚点与可复核快照。模型生成 URL 不算网络核验；失败清楚标单通道/未核实。
+本方案使用项目已批准的合规数据模型，不作具体标准符合性认定。专家校准负责规则、链视图与交付格式，保留意见来源及版本；不以数据结构存在代替合规验收。
+
+### KTD9. Lifecycle, UI and Agent Execution
+
+项目阶段配置、文档适用目录与准入准出规则版本化；当前字典为既有种子基线，关于进一步阶段合并的旧未裁定意见不擅自生效。
+提交审核和申请推进时执行模板内容要求、缺项、职责、冲突、合规完整性门禁；有材料不等于满足要求，所有候选边也不等于冲突。可接受的不适用必须说明理由并由有权者确认。
+阶段推进/回退/结项记录固定对象集合、规则和决策；外部完整变更引擎在 F-02 交付前，当前保留撤回重审、冲突和影响提示，不能直接改批准基线。
+沿三栏工作台：左侧统一项目及私有会话；项目管理承载成员/权限/文档职责/阶段；工作区承载树、文档、追溯与看板；右侧工作/文件用于待办和唯一预览。对话与这些入口访问同一服务。
+所有业务操作均可经自然语言准备并在必要节点显式确认。查询/总结不触发写入；模糊“继续”只作用于已展示且未过期的请求。工具说明渐进注入，RDM 编制/审阅配方作为产品资产，内核保持通用。
+执行自由度遵 Q7/D10：检索、解析、归纳、候选生成可自主；三权、基线、正文生效和合规边确认受确定性门禁约束。模型不能自签或借工具权限继承管理员能力。
+
+### KTD10. Durable Jobs, Storage and Deployment
+
+Run/Step 保存发起主体、项目、输入引用、模板/提示词版本、检查点、水位、幂等键和恢复状态；模型调用不持数据库长事务。取消、审批与恢复针对同一持久对象，权限变化后拒绝续跑或投递。
+重启仅标 failed 是可观察失败，不是任务恢复。最终必须能安全续跑，或对未知副作用停在需人工确认的恢复状态；禁止无条件重放。
+复用多人存储方案已有工作：团队 PostgreSQL 为权威、Redis 可丢失、预算可配置、单实例先行。RDM 领域库、原件、知识发布、任务与检查点必须显式纳入迁移/备份，不能只设置 Backend PG DSN。
+多实例验收包括领域唯一性、事务、数据库发号、运行 owner/epoch、队列领取、事件追赶和共享工件；两个 dataDir 的宿主 smoke 不证明 RDM 多实例写入一致。
+多人隔离前继续硬禁高风险代码执行；最终交付隔离执行后端、目录/网络/资源约束和受控开放，符合 SR-G16，不以永久禁用替代能力。
+发布包必须包含 RDM 插件接线、模板/字典/提示词资产和明确组件清单；离开源码目录仍可启动。部署另设固定环境与授权，安装、升级、备份、恢复、回滚均有可执行操作说明与演练证据。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart TB
+  P[平台账号与角色上限] --> A[统一动作与资源授权]
+  C[系统级项目目录和成员] --> A
+  U[各用户私有会话 原件 草稿] --> A
+  A --> K[明确发布的项目知识快照]
+  K --> N[项目笔记树]
+  T[已发布模板及文档职责] --> D[项目文档树 要求和版本]
+  N --> G[项目追溯网 依据 决策 影响]
+  D --> G
+  A --> R[持久任务与提案]
+  N --> R
+  D --> R
+  G --> R
+  R --> H[编制确认 审核 批准]
+  H --> V[固定整文及合规快照]
+  V --> X[DOCX XLSX 可审计导出]
+```
+
+```mermaid
+sequenceDiagram
+  participant U as 编制人
+  participant S as 领域应用服务
+  participant J as 持久任务
+  participant D as 领域存储
+  participant R as 审核和批准人员
+  U->>S: 项目内编制请求
+  S->>S: 当前权限 职责 资源检查
+  S->>J: 固定模板 输入和目标版本
+  J-->>U: 进度 持久提案 差异
+  U->>S: 采纳固定提案
+  S->>D: 事务提交版本 依据 追溯
+  U->>S: 提交审核
+  S->>D: 完整性门禁并冻结整文
+  R->>S: 当前身份审签固定快照
+  S->>D: 正式版及批准记录
+  S-->>U: 可预览下载的固定版本
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> Provisioning
+  Provisioning --> Active: 项目和绑定均就绪
+  Provisioning --> Recovery: 初始化失败
+  Recovery --> Provisioning: 幂等恢复
+  Active --> StageReview: 申请推进
+  StageReview --> Active: 通过并进入下一阶段
+  StageReview --> Active: 驳回维持原阶段
+  Active --> Closing: 申请结项
+  Closing --> Archived: 准出与确认通过
+```
+
+文档状态独立为编制中→审核中→待批准→已批准；驳回回编制中，新版本获批才取代旧正式版。任务运行、文档审批与项目阶段不能合并成一个“完成”标记。
+
+### Public Contracts and Existing Plans
+
+| 契约组 | 场景与公开面候选 | 现有缺口及兼容方式 |
+|---|---|---|
+| X1 项目绑定和生命周期 | RDM 项目服务与 Host 项目上下文创建/解析/成员目录 | 现有个人项目 CRUD 无统一约束；新增可选插件适配，RDM 启用时所有入口走同一服务；通用基座模式不被偷换 |
+| X2 资源动作授权 | 身份＋项目＋action＋resourceRef＋version；HTTP/Host/检索/下载同判定 | EXT-8 只读 bool 太粗；动作矩阵尚非完整公开生产接线；版本化扩展、默认拒绝，旧读取适配器不获得写权 |
+| X3 资料发布与解析 | 原件保全、ParseDocument、知识发布/撤销、chunk 映射 | 部分能力已在基座；RDM 逐项采纳并组合验证，缺失能力才申请新面 |
+| X4 持久任务和恢复 | 受限 Host 工厂、Run/Step、取消/确认/状态事件 | 复用现有能力及团队存储路线，RDM 不保存旧 Host 凭据，不创建第二套账号 |
+| X5 工件和外部证据 | 固定文档/图快照导出、artifact 绑定、真实 web search/fetch | 输出引用不等于实际文件/网络证据；受控任务产物与可核验抓取结果走公开面 |
+
+每个缺失扩展按 RDM AGENTS 的场景、期望符号/路径、现有组合不足原因、兼容方式四要素申请；不导入 Backend internal，不修改 RDM pins 内实现。
+与 [两树一网方案](2026-10-11-rdm-two-trees-trace-audit-integration.md) 共用项目绑定/授权、事务历史和审计展示；与 [多人存储方案](2026-10-11-collaboration-storage-and-distribution.md) 共用 PG、运行所有权、预算、恢复和隔离；模板子方案为 U7/U8 的详细设计输入。
+在途核对：本轮远端查询 Dev #337 为存储迁移工具/恢复操作说明组合，#336 为 Generative UI U2，#317 为启动检查；不能把它们的未合入能力计入当前基线，也不重复立项。RDM 新增 `docs/proposals/2026-10-11-u1-base-extension-requests.md` 已提出平台身份能力与可信当前项目两项扩展，X1/X2 应承接该申请而不是再写第二份。正式立项时再次刷新在途状态。
+原 [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) 的历史进度保留，新补齐顺序批准后回填该案及 RDM requirements/10，不制造多份互相覆盖的“最终状态”。旧广义完成声明只保留为历史记录，另做需求→证据重新映射，不改写其原始收据。
+
+---
+
+## Implementation Units
+
+优先级 P0 为核心安全/正确性与用户路径，P1 为完整核心交付，P2 为外部扩展；P1/P2 不表示可永久省略。责任为仓/模块，具体 owner 在立项时明确。
+依赖顺序：U1→U2→U3；U4 与 U7 可在各自契约固定后并行；U9→U5→U6，同时 U5→U12 真实法规双通道；U7 的首批模板和 U12 就绪→U8 首批闭环→U16 全文档族推广；U8/U11 汇合到 U10（经 U8 已包含 U12）；U13 与业务开发并行收敛，最后 U14；U15 按子目标独立立项。
+
+| 单元 | 交付主题 | 主要范围 | 前置 |
+|---|---|---|---|
+| U1 | 需求、证据和组合契约 | Documents/RDM requirements 与 pins 清单 | 无 |
+| U2 | 系统级项目与管理入口 | RDM projects/members、基座项目适配、Frontend | U1 |
+| U3 | 权限上限、私域与资源授权 | RDM perms、基座资源/Host/检索边界 | U2 |
+| U4 | 原子事件、历史和旧数据归属 | RDM domain/store/eventlog/replay | U1、U2 契约 |
+| U5 | 完整资料摄取与检索 | upload/parse/ingest/fbhost | U3、U4、U9 |
+| U6 | 结论、冲突、两层裁决与影响 | conclusions/fc/kanban | U5 |
+| U7 | 全资产台账与首批模板契约 | templates/structure、资产 bundle | U1 |
+| U8 | 整文生成、三权和版本导出 | compose/draft/review/docx | U3、U4、U5、U6、U7、U9、U12 |
+| U16 | 全部文档族迁移和真实验收 | 69 模板及 XLSX、契约与样本 | U8 |
+| U9 | 持久快慢任务与对话入口 | RDM jobs/plugin、基座运行/卡片、UI | U3、U4 |
+| U10 | 项目阶段、缺项门禁与结项 | projects/baseline/review | U8、U11 |
+| U11 | 需求/风险/验证/合规生产闭环 | requirements/compliance/chainviews/exports | U3、U4、U6 |
+| U12 | 真实外部研究与法规双通道 | regcheck、公开检索/抓取能力 | U3、U5、U9 |
+| U13 | 团队存储、隔离执行和运行恢复 | RDM store、Backend/Squad/Native、发布包 | U1、U4、U9 |
+| U14 | 全量验收、自举和用户上线 | 测试、CI、部署/恢复资料 | U1–U13、U16 |
+| U15 | 最终后续目标逐项实现 | F-01…F-10 责任模块 | 各子项按下表 |
+
+### U1. Baseline and Evidence Reconciliation
+
+覆盖 R15。统一 34 UR、68 SR、10 F 的解释，明确本轮 D1–D6；修正文档状态漂移及历史测试覆盖映射，固定实际 RDM/Backend/Frontend/UI/Native/Squad 组合。
+文件：RDM requirements/README、01/03/04/08/09/10、U0/V2.2 主记录；Dev proposals/INDEX 与扩展申请；新增需求证据矩阵（本轮候选已给出）。
+方法：先评审来源和范围，再按最小契约申请/采纳 X1–X5；已有能力只补接线，不重新立项重写。U1 保留在途 PR 及 owner、版本和接受条件。
+验收：全部原编号各有最终行为/工作包/测试入口；没有历史 PASS 自动变成当前 PASS；被覆盖的旧表述有指向当前解释的入口。
+
+### U2. System Project and Management
+
+覆盖 R1/R3/R5。交付创建/改名/归档、授权目录、成员加入/移除、创建者管理、宿主绑定及用户可用项目管理页面/对话路径。
+文件：RDM internal/projects/projects.go、internal/members/members.go、rdmapp/projects_api.go、runtime.go、plugins/rdm/plugin.go；Backend store/projects.go/server 项目入口/公开适配；Frontend TaskSidebar/ProjectSettings 与 RDM 工作区。
+测试：扩展 projects_test.go、成员测试及新合入 u1_auth/u1_surface 用例；新增项目绑定和浏览器流程用例。两用户同名并发、规范化碰撞、改名碰撞、归档、创建者角色写失败、宿主绑定失败重试、绑定他人宿主项目拒绝、成员加入后同 ID 可见、非成员目录及默认项目回退拒绝。
+出口：真实用户可用统一研发项目管理；测试不能直接向数据库播种一个“已经绑定”的项目绕过创建路径。
+
+### U3. Policy, Resource Access and Privacy
+
+覆盖 R2/R3/R4/R5/R10。完成专业角色默认/上限/覆盖、文档职责分配授权、资源级读写策略与即时撤权；交付 X2 公开契约和全部生产入口接线。
+文件：RDM perms、perms_api.go、sharing.go（实际路径在实施时核对）、upload 台账/确认、plugin 守卫；Backend extension、server、hostcaps、retriever、cardsvc；新增 resource_authz_test.go、隐私浏览器用例。
+测试：上限拒绝覆盖、撤上限后旧许可失效、无效/停用/非成员职责指派拒绝；同项目私聊/原件/草稿、关键词/计数/摘要/导出不泄漏；职责读取与明确分享允许；普通三权人员可合法导出本文档而无全项目审计权；审计读取许可不能变绑定写权；撤权后 SSE/模型结果/下载立即拒绝；建项目不成为管理员。
+出口：原件私有且项目发布知识可被其他成员合法检索；HTTP 与 Host 行为一致，不出现“页面可读但模型不可读”或反向泄漏。
+
+### U4. Atomic Domain and History
+
+覆盖 R5/R8/R9/R10/R11/R14。将多事件操作、台账、幂等和 outbox 收入单一领域事务，修复投影先写、重放不对等与历史快照不完整。
+文件：RDM domain/eventlog.go、replay.go、payloads.go、store、doctree.go、tracenet.go、compliance.go；新增 transaction_fault_test.go/history_replay_test.go、迁移映射清单。
+测试：在版本、建边、职责记录、快照阶段注入失败；提交全成/全败，重试唯一；跨项目边拒绝；同水位重启前后对象/签署/stale 相同；未知事件拒绝；遗留空项目只读隔离且不自动归属。
+出口：真实持久库故障证明一致性；授权不明历史留待裁定，不以清空数据修复测试。
+
+### U5. Ingestion, Parsing and Retrieval
+
+覆盖 R4/R5/R7。统一原件、上传对象、相关性、发布、解析锚点、标签、知识索引与补偿；消费公开 ParseDocument。
+文件：RDM upload.go、parse.go、ingest.go、relevance.go、llm_summary.go、fbhost/adapter.go；公开能力差距经 Backend 扩展；测试 upload/parse/publish_consumption，新增 anchor_roundtrip_test.go。
+测试：PDF/Word/Excel/PPT/图片与文本各能力档、重名重传、损坏/大文件/解析中断、表格宽列、部分成功、私有和待裁定不发布、确认重试不重入、慢处理保留页表位置、发布失败重试、跨项目检索负例。
+出口：真实素材的原文→切片→检索→引用可回跳；性能按已批准 SR-N1 的样本规模协议测量，不用空文件证明时限。
+
+### U6. Knowledge, Decisions and Notifications
+
+覆盖 R5/R8/R11/R13。结论水位更新、会议三类抽取、冲突组、两层裁决、依据变化影响清单与低打扰通知。
+文件：RDM conclusions.go、domain/fc、pending/todo、kanban.go；新增 conflict_scope_test.go、conclusion_update_test.go、impact_notification_test.go。
+测试：已存在结论后新增资料仍可提出更新；相似但不冲突的反例；同一切片参与多个争议只关闭指定争议；编制人只改本文档选择，负责人裁定共享结论；正文未变但依据更新仍提醒；受限来源不在通知泄漏。
+出口：知识更新和文档写入是独立受控动作，用户能知道“谁改变了哪条依据、影响谁”。
+
+### U7. Template Contract and Pilot Assets
+
+覆盖 R6/R9。登记全部 69 类及 XLSX 资产；按模板子方案 U1/U2 建立公共章节结构、内容/格式约束、发布版本、默认用途、稳定 sectionKey 和 bundle，先结构化项目建议书、竞品分析两模板。
+文件：RDM docs/templates、templates.go、structure.go、domain/doctree.go；69 类台账及 XLSX 资产；template_contract_test.go/template_instance_test.go 与每模板验收样本。
+测试：台账无遗漏，首批用途匹配、v2/v10、多版本保留、模板升级迁移提案、无源代码运行和格式契约；两模板能正确实例化，不用静态检查冒充真实生成。
+出口：公共模板契约和首批两模板可供 U8 使用；其余模板标记待迁移/验收，全部完成由 U16 承接，避免 U7 与生成能力互相等待。
+
+### U8. Document Generation and Three Duties
+
+覆盖 R6/R9/R10/R11/R13。复用模板子方案 U3–U5，交付文档级职责、持久提案、完整来源、差异采纳、锁定审签、正式版本和批准快照导出。
+首批竞品分析模板含法规要点，完整验收以前置 U12 的真实双通道就绪为条件，不能用模型生成 URL 或单通道占位降低模板要求。
+文件：RDM compose.go、draft.go、domain/fb/writegate.go、domain/review.go、docx.go、plugin、编制 skill；新增 document_revision_test.go/document_duties_test.go，真实三人浏览器编制案例。
+测试：无职责等待/分配/接续；非编制人所有写入口拒绝；审核人不能改正文；审签走真实总线不传伪造身份；多审核人缺一不能批准；更换职责不能让原作者自审；旧卡/旧版本拒绝；部分采纳重验整文；撤权/并发/故障原子性；真实 DOCX 打开和引用可达。
+出口：两份试点从真实资料经真实模型和三人账号完整通过，随后 U16 全量文档族推广；有实际结果才能生成验证报告通过结论。
+
+### U16. All Document Families
+
+覆盖 R6/R9/R10/R11，依赖 U8 首批真实闭环。按原 69 类台账逐族迁移、发布和验证，现有报价 XLSX 独立交付；需求、设计、风险、测试/验证、评审等文档族全部有结果。
+文件：RDM docs/templates/registry 与全部模板、XLSX 资产/renderer、各模板结构/格式/样本测试；原件哈希与迁移差异写入台账。
+测试：每份至少一个有材料的真实生成与审签导出正例、一个空缺/冲突反例；特有表格、章节、引用、公式、格式与职责均检查。编制共同契约复用 U8，不为每份模板新写一套业务流程。
+出口：69 类均有已发布可用正文模板及对应运行证据，XLSX 实际打开检查通过。公司新标准模板另列 F-10；平台全量覆盖不得用项目内“不适用”豁免。
+
+### U9. Durable Task and Conversation Infrastructure
+
+覆盖 R7/R9/R13/R14。建立持久快慢任务、输入与检查点、取消/恢复/幂等、对话内卡与工作区同源；修正 RDM 普通文本入口和插件工具投影。
+文件：RDM slow.go/slowledger.go/plugin/web；Backend 公共任务/HostFactory/事件面；现 slow_persist_test.go 加真实恢复语义，新增 task_recovery_test.go 与对话路由用例。
+测试：跨刷新/重启/断网恢复；任务接纳后权限撤回；重复取消/确认；模型超时与外部结果未知先查询；seq 乱序丢弃；普通自然语言不触发空值异常，查询不落写任务；持久记录与页面计数同一状态。
+出口：任务失败、部分完成、待确认、恢复中均可见，后台工作不会在进程重启后仅静默丢失。
+
+### U10. Stage Gates and Project Closure
+
+覆盖 R10/R11/R12/R13。阶段配置、推进/回退/结项、文档提交门禁、条件性不适用和决策快照；与内容/合规规则共用判断结果。
+文件：RDM projects、baseline.go、review 服务、plugin；新增 stage_transition_test.go/document_submit_gate_test.go 与生命周期浏览器路径。
+测试：有资料但未满足内容要求不能提交；无关候选边不误阻断；必需验证缺失/过期阻断；合法不适用可经有权者确认；上传不催缺项；陈旧推进卡和并发阶段变更拒绝；结项后只读与受控恢复。
+出口：用户从立项到结项均可通过对话完成，不靠管理者手改状态。
+
+### U11. Requirements and Compliance End to End
+
+覆盖 R8/R11/R12/R15。实现需求分解/六维分类、风险/验证/确认/SOUP 业务录入和版本生产，合规边建议/确认、完整性规则、四链视图、审计展示与精确快照导出。
+文件：RDM requirements.go、compliance.go、cderived.go、chainviews.go、cgraph_export.go、plugin/web；新增 producer_to_graph_test.go/compliance_replay_test.go；复用既有合规测试而不只域层播种。
+测试：真实命令新增/升版需求到图、分解来源可追、候选边不能自动生效、风险控制缺验证、验证版本不一致、SOUP 标记、旧快照查询/导出相同、受限端点不泄漏、规则版本变化导致缺口重新评估。
+出口：已有读模型真正有生产数据；专家校准意见、规则版本与证据映射齐备。全图视图保持渐进，不强迫用户操作大图。
+
+### U12. Real External Evidence
+
+覆盖 R7/R11/R15 与 UR-13/14。真实法规知识库与网络双通道，外部资料入树，冲突和降级明确；模型答案与取得的网页原文分开。
+文件：RDM regcheck.go/domain/regcheck；Backend 公共搜索/抓取接入（有则复用）；regcheck_test.go 扩展真实受控来源回放及失败样本。
+测试：模型编造 URL、链接不可达、标准版本不一致、两通道冲突、仅单通道、来源权限撤回、摘录与正文不符；均不能显示双通道已核验。
+出口：每条外部结论有实际检索/获取记录、原文快照和支持关系；外网不可用时仍可工作但不伪称核验。
+
+### U13. Team Runtime and Isolated Execution
+
+覆盖 R14 与 SR-G16/SR-N1/N4/N5。复用团队存储计划，把 RDM 领域数据纳入 PG/事务/任务恢复；实现隔离执行档、资产发布包、备份恢复/迁移回滚和运行可观察性。
+文件：RDM domain/store、projects/members/perms、原件/慢任务存储；Backend/Squad/Native 对应公开边界；migrations、安装/升级清单；新增 rdm_pg_test.go/rdm_multi_instance_test.go 与隔离执行黑盒用例。
+测试：SQLite→PG 干跑/核对/失败回滚、旧库名称冲突、原件与 DB 一致恢复；双实例同名/同文档竞写、epoch 过期写入拒绝、重连追赶；执行不能越目录/越项目/读秘密/超资源；取消后子进程停止或进入明确恢复状态。
+出口：先单实例团队版通过，再开放双实例；使用脱敏固定数据集，记录容量阈值而非仅声称支持 100 人。
+
+### U14. Full Acceptance and Operational Delivery
+
+覆盖 R1–R15。逐条重放需求矩阵、全部文档、真实三用户/两项目、真实模型、真实浏览器、自举与安装包；接上固定 HEAD CI 和独立重放。
+文件：RDM docs/requirements/09、业务 E2E/fixtures、CI、release manifest、安装/回滚/恢复说明；Dev 组合记录；新增最终验收台账，不篡改历史原始收据。
+测试：上述正常/拒绝/故障全部场景；真实自举材料不能由测试临时编造“支撑资料”；全部上线模板实际打开产物；项目/私域/职责隔离、性能、重启恢复和安装包离线资产校验。
+出口：每条声明绑定命令、精确对象、输出和来源；业务完成、合入、部署、用户验收分别签收。用户当前实例在部署阶段明确选定，先备份再切换，不擅自清理旧进程。
+
+### U15. Remaining Final Goals
+
+| 原目标 | 完整路线与本轮去向 | 前置/责任与完成判据 |
+|---|---|---|
+| F-01 飞书全套 | 渠道、身份绑定、权限映射、虚拟人、文件/版本链接 | 核心授权和固定文档快照先完成；独立连接器任务固定外部租户/权限/凭据；外部回调不能绕过同一三权和资源权限 |
+| F-02 完整变更流程 | 按公司流程选择系统内流程或外部集成，七步闭环逐项有对象和状态 | 先评审业务权威及外部 owner；实施追溯的申请、影响、评审、批准、执行、验证、关闭；当前影响提示不冒充闭环 |
+| F-03 精细分享 | 保留显式授权与撤销；会话/部分会话分享仅在用户再次明确启用后开放 | 本轮私聊私有为硬默认，不能以最终扩展名义自动共享；范围、接收者、版本及撤销语义需独立批准 |
+| F-04 时间权重 | 内容新旧、版本、来源质量可配置排序，冲突仍由人裁决 | U5/U6 后，固定检索评估集及配置版本；效果对照和公平覆盖达标，不靠“越新必正确” |
+| F-05 代码工具 | GitLab 等只读代码、版本、缺陷与需求关联 | 外部仓库授权与读取契约、可验证 commit 绑定；不包含擅自写代码/推送权限 |
+| F-06 交互收敛 | 纳入 U9/U14：看板、卡片、领域工作区同源 | 单一状态所有者、刷新/事件/撤权一致、右栏关闭无能力缺失 |
+| F-07 遗留决策 | 重建 Q/O 决策台账，逐项定论或保留具体阻塞 | 不能把问题组当已确定功能；阶段划分、专家规则、对抗验证形态等按来源和裁定处理 |
+| F-08 难度与人机边界 | 评估表、任务分工建议、人工为主的降级、独立质量检查 | U7/U9 后，明确谁评估、输入和证据；高难任务不伪装全自动完成，人工意见留痕 |
+| F-09 追溯可视化 | 按 10 月 11 日已批准展示方案纳入 U11/U14 | 项目树/一跳关联/审计时间线/四链与矩阵可用且鉴权；不是继续无限延期 |
+| F-10 公司标准模板 | 用户提供后按 U7 模板发布/映射/差异迁移机制替换 | 需实际模板文件及评审责任人；旧文档版本保留，标准模板逐份真实生成验收 |
+
+这些目标没有被删除。F-01/02/03/05/07/08/10 所需外部授权、组织裁定或输入未齐时，分别记阻塞对象与责任人；核心已有能力可继续交付，但最终全范围不得提前关闭。
+
+---
+
+## Verification Contract
+
+本轮仅调查与文档验证；业务 PASS 一律不得由本方案文字推断。
+
+| 验证层 | 范围与工具入口 | 证据与退出条件 |
+|---|---|---|
+| 资产和静态 | 需求矩阵、模板契约、安装包资产 | 34 UR/68 SR/10 F/69 模板全部有去向；链接、schema、版本和文件均可核 |
+| 领域单元 | RDM `make test`、针对变更新增拒绝/边界/故障用例 | 事务/职责/版本/门禁明确正确；mock 只证明机制 |
+| 总线/公开契约 | 注册 schema→可信身份→handler→领域服务；实际工具投影目录 | 不绕过 schema、登录与权限；旧命令和 UI/API 同一行为 |
+| 持久集成 | 真实 SQLite/PG、原件/索引/任务、进程故障重放 | 无已确认数据丢失/静默重复生效/跨项目泄漏；迁移和恢复可复核 |
+| 用户全链路 | 真实三权账号及普通成员、两个项目，真实浏览器 | 立项、分配、私有上传、发布知识、生成、审签、导出、阶段推进；刷新/重启/撤权一致 |
+| 模型任务级 | 固定素材与版本，前后对照并保留真实调用 | 正确模板/来源、冲突与空缺诚实、权限不越界；人工盲审语义支持，不只看引用 ID 存在 |
+| 交付文件 | 实际 DOCX/XLSX 与 Office/LibreOffice 打开 | 内容、表格、格式、来源、签署和快照一致；报告不能编造真实测试结果 |
+| 运维与容量 | 固定环境，10→30→100 用户阶梯与故障演练 | 以已批准存储方案量化合同及 SR-N1 为准；预算和数据规模公开记录，跳过的 PG/Redis 项目不算通过 |
+| 正式准入 | RDM 与 Dev 固定组件 SHA、CI 链接/身份、独立重放 | SELF/GATE/REPLAY 分开；本地通过不能代替人工评审、平台准入或线上验收 |
+
+关键用户验收样例：
+
+1. A 创建项目，B 同名创建被拒；A 加入 B/C/D 后大家看到同一个项目，彼此会话仍不可见。
+2. 平台允许成员管理但禁止某动作，A 的项目 override 不能放大；管理员撤销上限后旧任务和旧卡片也失效。
+3. B 上传私有原件并发布一段经确认知识；C 可使用该知识而不能打开 B 的原件，D 的搜索、计数、摘要不泄漏它。
+4. A 指派 B 编制、C 审核、D 批准；B 生成，C 只能批注；D 等全部审核通过后批准，A 不能凭负责人身份代批。
+5. B 在审核中改正文、切换成审核人后自审、旧卡批准新版本、跨项目伪造 sectionId 均被服务端拒绝。
+6. 资料升级但文档未变，看板仍显示依据更新；编制人选本文档依据不自动改变共享结论。
+7. 断网/重启后恢复同一任务与提案；重复采纳只有一次内容版本；版本写入或建边失败不出现半条追溯。
+8. 已批准旧快照与当前修改并存，导出旧正式版仍得到旧内容/旧依据/旧签署；合规报告使用同一水位图和 hash。
+9. 69 类模板及报价 XLSX 分批全部真实验收；没有资料的报告不生成不存在的实验/测试结果。
+
+## Definition of Done
+
+当前方案阶段：用户关键口径准确落盘，所有原需求与后续目标有追溯映射，源码差距与运行未知分开，工作包含依赖、责任模块、文件、验收与停止条件。
+核心产品 C1：U1–U14 及 U16 对应矩阵证据全部齐备，真实项目管理、隐私协同、全部文档三权与导出运行可用；没有把历史桩测试当真实验收。
+最终目标 C2：U15 每项实现验证，或用户明确取消/替代并更新权威需求。只“已备案”或“后移”不能关闭最终目标。
+正式上线：固定目标实例和制品、完成迁移/备份/恢复/回滚验证、取得对应部署授权并通过用户运行验收；上线与代码合入分别记录。
+
+优先下一步为 U1：固化本次总体范围、修正基线/证据口径，并细化 U2/U3 的项目与资源授权公开契约。其直接解决当前用户无法管理同一项目、创建者无法完整配置三权、私域与共享层可能混用的问题。
+本轮“所有文档都加入并实现”和“三权要实现”已作为明确交付要求记录；由于同时要求先完成全系统目标核对和完整方案，本轮停在可评审总体方案，不把尚未评审的新跨仓/权限设计直接实施。
+
+### Decisions Still Required
+
+用户已确认的 D1–D6 不重复请求。仍需评审的是本总体方案的技术路线、U1–U16 分工和交付边界；实施前固定目标运行实例、团队部署档及具体负责人。
+进一步阶段合并、外部完整变更流程归属、外部系统租户/凭据、公司标准模板和专家校准结果有明确后续依赖，不阻塞当前项目/权限/模板地基工作；未齐备时不伪造完成。
+各阶段沿 `Dev:policy/delivery.md` 人工评审；若后续要求连续实施，应明确覆盖的阶段和终点，发布、保护规则变更等双钥匙边界继续保留。
+
+## Appendix
+
+原始来源：S:35–76 与 D:75–88；RDM requirements/README、00、01/03/04/08/09/10；U0、V2.2 已批准裁定。矩阵中给出每条需求的原文位置。
+设计依赖：两树一网展示方案 r1、多人存储方案 r1、模板对话生成方案及 69 类资产盘点。涉及 API 的名称均为候选设计，正式符号由公开契约申请确定。
+本轮没有联网核验法律或标准条款，也没有声称系统已符合任何特定法规；本方案讨论项目既定需求、数据追溯与实现验收。

docs/proposals/2026-10-11-rdm-template-dialog-generation.md

@@ -0,0 +1,399 @@
+---
+title: RDM 基于模板与两树一网的对话文档生成方案
+type: feat
+date: 2026-10-11
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 基于模板与两树一网的对话文档生成方案
+
+修订：r1.1，首批顺序已确认，其余方案待用户评审。需求负责人：weichen；方案编制：Codex；实施负责人：待立项指定。
+本轮授权终点是调查和方案；业务实施、模板迁移、模型试验、部署与运行验收均为 NOT_RUN。
+本文件为模板生成子方案正文；总体范围、最新现状及优先级以[最终目标完整交付方案](2026-10-11-rdm-final-target-completion.md)为准。任务记录：Dev `.task/feature-rdm-template-dialog-plan.md`。
+本案资产/代码表固定于 RDM 0081628a；本轮期间 d8d7e743 已新增项目绑定、部分命令授权和管理员引导修复，增量差距见总体方案，不再把旧表当作最新全系统状态。
+路径前缀约定：`RDM:` 指 Agent-System-RDM；`Legacy:` 指旧 Agent-System；`Dev:` 指 Agent-System-Dev。
+
+## Goal Capsule
+
+用户在项目对话中说出需要编制或更新的文档，系统选用明确版本的模板，从该项目有权使用的知识与文档中组织依据，生成可审阅、可追溯、可继续修改的草稿；编制人确认后形成内部版本，再经三权流程产生可导出的正式文档。
+
+推荐在已有 RDM 插件内补齐生成闭环，复用基座的模型、任务、卡片和工件能力。模板决定文档结构与格式；笔记树提供知识；文档树承载文档及章节版本；追溯网记录依据、派生与影响关系。
+
+本方案涵盖 69 类历史文档资产的接入路线，首批用项目建议书和竞品分析验证完整链路，再扩展全部文档。此顺序已由用户于 2026-10-11 明确确认：“先打通项目建议书、竞品分析，再扩展全部文档”；需求、设计、验证和其他文档族的后续批次仍待细化。
+实施前先评审本方案及与既有两树一网方案的任务分工；任何设计批准不自动包含迁移、发布、合入或部署授权。
+
+---
+
+## Product Contract
+
+### Problem Frame
+
+系统确实有大量历史模板，但当前 RDM 的文档类型目录、模板注册表、章节树、对话命令和导出器尚未形成一致的产品路径。
+需要解决的是“用户能在对话中可靠地编制整份体系文档”，不能以模板文件存在、命令注册或模型返回一段正文作为完成标准。
+
+### Current State
+
+调查为 SELF·源码与资产检查，未查询业务数据库、未登录应用、未做真实模型或浏览器验收。
+命令原始输出和对象 SHA 经 `make evidence` 记录于任务卡；静态控制流推导与运行结果分开。
+
+| 对象 | 本次调查基线 |
+|---|---|
+| Dev | `95992d751f0a6ea8e345109dbb6b9367d9055e92` |
+| Dev Backend | `3def5259023806a49ab84f885b7d220333cccde6` |
+| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
+| 旧 Agent-System | `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` |
+| RDM Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
+
+Dev 与 RDM 实际依赖组合不同；不能以 Dev 最新扩展已存在推断下游已接通。
+
+| 资产/能力 | 盘点结果 | 含义 |
+|---|---|---|
+| 旧 Markdown 业务模板 | 69 份：bd 7、rd 60、pm 1、tm 1 | 是可复用的历史内容资产 |
+| 旧报价 XLSX | 1 份 `templates/xlsx/cdo_quote.xlsx` | 单独登记，不并入 69 个 Markdown 文档类型 |
+| RDM 文档类型字典 | 69 个，与旧模板文件名集合一致 | 目录已迁入，不等于模板已迁入 |
+| RDM 注册模板 | 4 个，均为 v1 | 项目建议书、竞品分析、周报、评审纪要 |
+| 已绑定文档类型 | 3 个：`rd_proposal`、`bd_research`、`rd_design_plan` | 其余 66 种未绑定注册模板 |
+| RDM 自举文档树 | 10 份文档、22 个章节 | 是一个自举项目结构，不是 69 类的通用实例化 |
+| 章节生成 | `Compose` 调用 `Host.Complete` | 已有真实模型调用路径，运行质量未验证 |
+| 写入/审签/导出 | 有 apply、版本、三权域模型和 DOCX 代码 | 需补端到端契约与运行验收 |
+
+资产依据：`Legacy:templates/docs/`、`RDM:internal/domain/data/labels_seed.json:68`、`RDM:docs/templates/registry.yaml:4`、`RDM:docs/structure/rdm-self.yaml:1`。
+
+| 模板 | 绑定类型 | 当前用途与问题 |
+|---|---|---|
+| `review-minutes@v1` | bd_research、rd_design_plan | 评审纪要，不应默认替代调研/计划正文 |
+| `weekly-report@v1` | rd_proposal | 周报，不应默认替代项目建议书 |
+| `project-proposal@v1` | rd_proposal | 业务正文模板，含内容要求与排版说明 |
+| `competitive-analysis@v1` | bd_research | 业务正文模板，含内容要求与排版说明 |
+
+当前关键缺口：
+
+| ID | 源码事实或静态推导 | 对本方案的影响 |
+|---|---|---|
+| G1 | 两条编写 intent 只调用 templates.for，且传 project-proposal-v1/competitive-analysis-v1；该接口要求字典 docType（plugin.go:212–230，templates.go:127–138） | 自然语言入口参数不一致，尚不是完整编制入口 |
+| G2 | RDM 命令未声明 exposeAsTool；实际 pin 的 EXT-14 仅投影显式声明命令（pins/.../internal/cmdbus/cmdbus.go:47） | 注册命令不等于模型可调用；须核对实际工具目录与 schema |
+| G3 | Compose 模板开关可缺省；按第一个适用 key 选模板，读取失败静默返回空串（compose.go:17、63–85、150） | 可能选周报/纪要，或者无模板继续起草 |
+| G4 | 单章提示词注入整份模板；章节结构另存 YAML，文档/版本无 templateKey/version/hash（compose.go:35–47，doctree.go:29–65） | 模板、章节和历史无法一致固定 |
+| G5 | Compose 返回即时内容；apply 重新检索，固定 topK=8；skip 旧依据参与起草却不能进入 accepted，Basis 直接取 accepted（draft.go:93–108，writegate.go:158–186） | 候选漂移、旧依据丢失、无法固定确认对象 |
+| G6 | 写版本后逐条建 supports 边（writegate.go:186 起） | 中途失败可导致正文与追溯不一致；复用既有原子事件工作项 |
+| G7 | draft/compose/apply 仍可空项目回退，处理器缺少对应编制人检查（runtime.go:106，plugins/rdm/plugin.go:1645 起） | 上下文、生成和提交均须领域授权；只靠宿主 owner 不够 |
+| G8 | approve/reject/final schema 必填 reviewer/actor/approver，处理器却拒绝这些参数（plugin.go:295–320、945–1001） | 总线契约矛盾；必须从真实分发入口验证审签 |
+| G9 | 模板从工作目录或编译时源码路径读取；构建仅生成二进制（templates.go:45，prompts.go:42–52，Makefile:40） | 需验证安装包脱离源码仍能加载模板 |
+| G10 | DOCX renderer 接收标题与章节，未消费模板排版规格；导出取章节当前版本（docx.go:155、298–306） | 排版要求未兑现，正式版需绑定整文批准快照 |
+
+这些是实施前应验证和修复的具体断点，不声明现网已经复现。
+
+### Requirements
+
+| ID | 用户可见要求 | 来源 | 验收判据 |
+|---|---|---|---|
+| R1 | 对话中查询、选择并预览模板 | SR-C2、SR-E6 | 显示用途、版本、适用类型和可用状态；不混淆类型数量与模板数量 |
+| R2 | 一句话编制整文或指定章节 | UR-11、F4、SR-E4 | 确定当前项目、目标文档、操作范围及模板后进入生成任务；歧义时澄清 |
+| R3 | 文档结构来自固定模板 | SR-C1/C2、M5 | 文档绑定已发布模板版本；每章有稳定标识、内容要求、检索条件及顺序 |
+| R4 | 只使用当前有权使用的依据 | SR-G2、U0 R09/R21 | 跨项目、私人未发布、待裁定、撤销资料不能进入共享生成正文 |
+| R5 | 每段事实可回到实际来源 | UR-11、SR-D1/D6、08 R1–R5 | 引用能定位切片/结论/已有文档的准确版本与锚点，历史可复核 |
+| R6 | 缺证据明确标出，冲突由有权者裁决 | F4、SR-B8/B9、U0 D4 | 不编造内容；文档层选择不改变项目共享结论；未裁决冲突不混入有效事实 |
+| R7 | 草稿提案经确认才改正文 | F-B、SR-C4/C6 | 展示新增/更新/冲突与差异；确认对象固定；未接受内容不写入 |
+| R8 | 保留已有正文与依据，支持增量更新 | UR-05、SR-C6 | 只修改用户选择范围；保留、增加、删除的依据与最终正文一致 |
+| R9 | 编制、审核、批准职责与版本固定 | SR-C7/C8、U0 D2/D5 | 非编制人不能生成/改正文；提交锁定；审签绑定完整文档版本 |
+| R10 | 长任务可查看、取消、恢复 | SR-F4、SR-B10、U0 R21 | 刷新/重启后看到同一任务；重复点击不重复生效；失败章节不冒充整文完成 |
+| R11 | 输出可打开、下载、追溯的 DOCX | U0 R14、10 号定稿决议 | 内容、格式、引用及版本与选定草稿/正式快照一致；下载再次鉴权 |
+| R12 | 旧模板逐份纳入可管理的目录 | 03 §7、SR-C2 | 69 份都有资产处置记录；已发布/待整理/不适用分别显示，不能批量冒充可用 |
+| R13 | 对话、卡片、工作区使用同一状态 | SR-E6、U0 D7、DESIGN.md | 收起右栏仍可完成编制；陈旧卡片不能批准新内容；按 seq 丢弃旧事件 |
+
+R1–R13 为方案候选范围，人工评审均未完成。R12 的登记全覆盖与各模板运行验收是两个阶段。
+
+### User Flow
+
+示例：“用已有资料生成这个项目的设计开发任务书。”
+
+1. 从可信会话解析项目，辨认是新建、更新、只改某章还是查询；“总结一下任务书”不能触发写入。
+2. 查现有文档与职责。已有同类文档时确认更新对象，缺模板或有多个正文模板时给出可选项，不随意选第一项。新文档无职责时保留请求为“等待职责分配”；有权负责人可在对话中指定异人的编制/审核/批准角色，其他成员可提出分配请求，由负责人处理。若当前用户不是编制人，则显示当前职责并允许转交编制请求，不把原私聊全文传给他人。职责就绪后由指定编制人接续同一目标、重验权限并确认启动，负责人不自动获得编制权。
+3. 展示一张编制卡：文档名称、模板版本、章节范围、使用的资料范围、将创建草稿的效果。确认后启动任务；已明确提供的信息不重复询问。
+4. 按章准备依据，必要时集中呈现冲突双方、来源、建议及理由，由相应角色裁决。
+5. 后台逐章起草与校验；对话即时显示计划和阶段，允许继续讨论或取消。无材料章节注明待确认。
+6. 完成后提供正文预览、逐章差异、来源和未决项；编制人可要求“只重写第二章”“采用这个依据”“保留现有市场分析”。
+7. 编制人采纳所选提案后产生内部版本；提交审核时执行完整性检查并锁定完整文档版本。
+8. 审核人和批准人分别以真实身份确认。完成后可导出 DOCX，继续通过对话查看来源或发起受控修订。
+
+编制卡、冲突卡、差异采纳卡和审签卡是不同决策，不合并成一次模糊的“确认全部”。同一决策可以在对话与工作区投影，使用同一服务端对象。
+编制过程中说明空缺不等于强制补齐所有字段；沿 SR-C5，资料上传阶段不推送缺项清单，正式完整性门禁只在提交审核/申请推进阶段执行。
+
+### Scope Boundaries
+
+本期设计复用现有模板，先完成内容与格式结构化、生成和受控落盘，再分批扩大覆盖。
+标准模板替换沿 F-10，待系统测试后由用户提供；不擅自下载其他“官方模板”替代旧资产。
+不把合规边有来源等同于满足具体法规；法规结论继续走既有双通道及人工复核，本方案不作标准符合性判定。
+飞书对接、变更流程引擎、跨项目自动取材、无人审批、所有文档自动重写不纳入本次实施建议。
+最新两树一网可视化方案已单列，生成能力不等待全局大图；文档引用浏览与项目审计中心沿各自权限开放。
+
+---
+
+## Planning Contract
+
+### Alternatives
+
+| 路线 | 收益 | 代价及结论 |
+|---|---|---|
+| 复用 RDM，补齐模板/候选/整文契约 | 保留已有知识、版本、审签与追溯，职责清楚 | 推荐；先修跨层契约，再扩模板 |
+| 将旧生成系统整体搬回新系统 | 可快速得到旧模板和流程 | 会带回任务键绑定、多份目录及旧状态治理，不采用 |
+| 把整份模板和检索结果直接交模型输出文件 | 演示快 | 难保证固定依据、增量更新、三权和恢复，只能用于隔离试验 |
+
+### KTD1. Template Contract
+
+将“文档类型”“模板资产”“项目文档实例”分开管理。
+文档类型保留兼容键；模板使用 `templateId + version + hash`；文档实例使用项目内稳定 docId。
+注册表是模板权威入口，避免再增一套手写目录；缓存和索引只能由它生成。
+
+| 模板层 | 核心内容 | 执行方式 |
+|---|---|---|
+| 资产元数据 | 名称、用途（正文/纪要/汇报）、别名、适用类型、版本、生命周期、来源 SHA | 可查询、受控发布；禁止字典序判断版本新旧 |
+| 内容结构 | 稳定 sectionKey、标题层级、内容要求、表格列、条件适用、允许缺省 | 编译为文档树实例与内容校验规则 |
+| 依据规则 | 共享标签条件、资料类型、强制输入、可用结论/文档类型 | 编译检索计划；保留人工选择与审阅 |
+| 格式规格 | 页型/页边距、字体、标题编号、页眉页脚、表格、引用呈现 | 由确定性 DOCX renderer 消费，不靠模型猜排版 |
+| 发布清单 | schema 版本、资产哈希、依赖字典、审批记录、兼容范围 | 安装包自包含；运行时清楚报告缺失或不兼容 |
+
+模板生命周期建议为 draft→published→retired。模板先评审再发布，再实例化文档树；同一已发布版本不可原地改写。
+首期内置共享模板及默认绑定只由获批的仓库发布流程变更，模板发布权不继承文档编制权。普通编制人只能选择已发布版本。后续用户上传模板只形成待评审候选；运行时发布/退役/改默认的责任主体与项目或共享作用域须另行评审后开放，不能借上传模板修改其他项目规则。
+普通编制人只选已发布版本，不因生成一次文档重复审批模板。退役不删除历史快照。
+默认绑定使用“docType＋purpose＋显式 default”；候选多于一个且无明确默认则询问；用户指定模板优先，但须校验适用性。
+用户指定“按模板生成”时，模板缺失/失效须停止该路径并解释，不能静默按自由文本起草。
+更新模板不自动改已有文档；迁移章节映射、内容影响和格式变化以单独提案确认。旧文档保持原 templateRef。
+
+### KTD2. Template Migration
+
+建立 69 份历史模板的逐项台账：原路径与 SHA、对应类型、目标 key、用途、章节数、内容差异、格式要求、处置结果、发布与验收状态。
+先保全原件与哈希，再拆出正文要求、管理信息、格式约束。追溯表、签署记录、缺项登记、已有材料摘要等管理信息进入相应台账或附属视图，不直接复制成正文章节。
+模板提取可以由模型提出候选，但发布结构与章节映射须人工审核；不因 Markdown 有二级标题就认定它是合格模板。
+10 份自举文档逐份做语义映射，避免仅凭原 docType 将“实施推进方案”套成“项目建议书”。已有内容只生成映射候选，不覆盖。
+建议发布包内置受控资产 bundle；后续用户模板使用同一校验/发布协议，从受管目录或存储载入，禁止依赖编译机器的源码路径。
+
+### KTD3. Three Structures and Context
+
+每项目独立解析两树一网；共享模板通过固定版本引用，不建立跨项目业务边。
+笔记树切片及结论提供内容；文档树章节提供输出目标、既有内容及版本；追溯网提供已有依据、取代关系、冲突和受影响对象。
+
+检索先判权限和资料发布状态，再检索和排序，不能先读全库再让模型筛项目。
+章节强制依赖、现版有效依据、已选结论及其原始 basis 应完整保留；其余素材用标签、语义、图关系合并、去重和有界排序。
+语义路须传确定项目；知识 chunk 到领域切片建立稳定映射，不能同一原件只取第一个 slice。
+超出上下文预算时分章节、分资料批次处理并保留覆盖账本；不得以 topK 截断后声称“已查全部资料”。检索降级向编制人可见。
+新内容优先是排序线索，不自动推翻已生效结论；已废止、待裁定资料只能用于有权限的冲突说明，不能作为已生效事实。
+私人对话原文不因关联项目就共享。模型从对话提炼的资料须沿既有发布/相关性边界进入共享知识；私有资料确需用于共享文档时，先获得明确发布授权。
+模板、上传原文和引用资料是任务数据，不得提升为系统指令或扩大工具权限。
+
+### KTD4. Durable Generation Objects
+
+建议增加四类持久对象，字段名为设计候选，不是已发布 API：
+
+| 对象 | 固定什么 | 主要作用 |
+|---|---|---|
+| GenerationRun | 项目、文档、编制人、会话、范围、templateRef、章节基线、知识水位、模型/提示词与检索版本 | 任务进度、恢复、成本与产出可追溯 |
+| ContextManifest | 选中来源 ID/版本/hash/锚点、授权/发布依据、保留与排除集合、冲突裁决 | 解释实际给模型的材料，不保存隐藏推理 |
+| SectionProposal | sectionKey、baseVersion、结构化正文、段落引用、差异、空缺、校验结果、状态 | 供人修改/比较/采纳；不改变生效正文 |
+| DocumentRevision | 全部章节版本集合、模板与布局版本、内容/hash、依据集合、审批快照 | 固定整文审签和导出，防止“各章最新”拼装 |
+
+段落引用持久化为稳定对象引用，短编号仅用于显示，必须保留编号映射。来源包括 slice、结论及依据、受控文档版本、模板版本、明确授权的外部材料。
+引用存在性、项目归属、版本和采纳范围由服务端校验；引用能打开不证明语义支持，另用模型检查加人工抽验判断事实是否被证据支撑。
+保留旧依据、增加新依据、移除依据分别记录，最终 Basis 从实际成文引用聚合并校验。用户取消某素材后，相关事实必须删除、重写或改为未证实，不能只删脚注。
+人工修改提案后重新计算 hash 并校验；内容、选材或目标版本变化使旧确认失效。
+
+### KTD5. Generation and Human Decisions
+
+起草遵循“检索并固定输入→模型组织正文→结构/引用/冲突检查→持久提案→人工采纳”，允许模型自主拆任务和选择可用工具，受控写入口保持确定性。
+现有 Compose 和 Gate 应重构复用，修正“仅有 skip 旧依据时被视作无素材”、旧依据不能保留等路径，不另起第二条正文写入链。
+模板内容要求决定章节任务；不能把整份模板重复塞入每一章。独立章节可并行，共享术语/数据依赖按章节依赖顺序生成，最终做全篇一致性检查。
+无法证实的数据不得补成事实。临时草稿允许“待确认”标记；正式版不能含未处理的必需项，处理方式是补证、明确不适用及有权确认，不能改规则绕过。
+冲突分两层：编制人决定本文档引用哪条依据；改变项目共享结论由项目负责人或指定知识责任人裁决。后台模型不自动做这两个决策。
+
+### KTD6. Authorized Atomic Apply
+
+从可信请求身份解析 actor，不接受前端 actor/reviewer/approver 自报。所有生成、读取、确认、导出及旧命令统一经过领域授权。
+生成开始、关键读取、恢复、结果投递和最终采纳时重验项目与职责；管理员/负责人不因角色高就自动拥有文档编制权。
+apply 接收固定 proposalId、预期章节/文档版本、采纳范围和幂等键，不再重跑检索重建“当时的候选”。
+事务内验证权限、版本和引用，原子提交版本、依据/追溯边、提案状态和领域事件；提交后更新投影。跨库宿主审计通过可靠 outbox 投递。
+多章节整文采纳默认同一业务事务；用户主动选择部分采纳时，生成包含未改章节原版本的新 DocumentRevision，清楚标记剩余未采纳章节。
+部分采纳先构造实际将保存的新旧章节组合，重新校验章节依赖、共享术语及关键指标一致性；后继章节依赖未采纳的前置改动时暂停采纳，列出必须一同处理的章节供编制人选择。校验绑定该组合的 hash 与版本；事务提交前再核对版本，不能沿用整份候选曾经通过的检查。
+模型调用不占持久写锁；候选失效返回具体变化，保留提案供比较，禁止覆盖新版本或静默再生成。
+断连/超时先按幂等键查询提交结果，再决定是否重试。跨库工件生成与领域提交不冒充一个事务，以导出任务和可恢复映射协调。
+
+### KTD7. Conversation Tools and UI
+
+RDM 提供模板查询/预览、文档实例化、生成准备/启动/状态/取消、提案查看/修改/采纳、提交审核、审签与导出能力；名称和 schema 在实施契约中固定。
+先统一 docType/templateId/version 含义及 schema 与处理器身份约定，再将需要模型访问的命令显式投影到工具目录；保留确定性命令入口用于卡片与测试。
+RDM 编制 skill 提供渐进说明与编制规则，业务权限与确认不靠提示词约束。skill 的新增/变更纳入真实模型任务级对照。
+审签决策由指定人通过认证确认产生，Agent 只准备与呈递，不因用户一句模糊“继续”批准未展示的新版本。
+基座负责通用模型路由、运行/卡片、工件字节、资源授权执行；RDM 负责模板、领域项目、资料发布、两树一网、提案、三权与版本。
+公开面不足时按 RDM AGENTS 四要素提扩展申请；禁止下游导入 Backend internal 或修改 pins。
+
+界面沿 `Dev:DESIGN.md`：对话为完整主入口，右栏“工作”看任务/待办，“文件”看文档；同一工件只有一个预览落位。
+对话展示模板名/版本、章节进度、需处理事项、最终文件和来源入口，不直接倾倒 slice ID、事件 JSON 或内部工程术语。
+一个服务端对象拥有异步状态，对话与工作区只作投影；按 seq 处理事件，刷新从服务端恢复，陈旧卡片显示已过期及原因。
+UI 使用令牌、MotionKit、Collapsible 和安全 HTML 原语；无额外第四栏或新的平行预览器。
+
+### KTD8. Review and Export
+
+现有审签主要按章节实现；推荐面向用户升级为文档级职责与审签，章节审签仅作为可选内部协作步骤，不要求用户为每章重复三权操作。
+文档提交时冻结 DocumentRevision：章节版本、模板、内容要求、依据及当时职责。后续撤权或职责变化使待处理授权失效或要求重新提交，不能接续旧签名批准新版本。
+审核期间所有正文入口拒写；驳回回编制态产生新内部修订，不提前增加正式版号；原正式版在新正式版批准前仍可查看。
+旧章节职责、审签和正式版作为原始历史保留，不自动合并为文档级授权或“已批准整文”。同一旧文档的章节可能由不同人编制/批准：转入新流程前由有权负责人明确文档职责；迁移清单列出旧活动审签，经有权人确认撤回后重提，未完成该处置的文档保持旧态只读查询并暂不启用新整文流程。首个文档正式版须重新完成整文审签；历史导出明确标识为旧章节版本集合，不冒充整文批准。
+草稿导出清楚标记草稿。正式版导出只读取批准快照，不读取当前各章最新；正文、引用附录、签署元数据与格式使用同一快照。
+DOCX 由结构化内容和布局规格确定性渲染，保存 artifact 与文档版本的关联。导出生成、预览、下载分别鉴权；权限撤销后已有任务不得继续泄露结果。
+允许异步重试导出，不因文件生成失败回滚已获批准的文档状态，也不把导出文件反向作为领域内容权威。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart TB
+  U[项目对话或工作区] --> A[可信项目与角色解析]
+  A --> T[固定模板与文档目标]
+  T --> C[按章准备依据快照]
+  N[笔记树与有效结论] --> C
+  D[文档树及原版本] --> C
+  G[追溯网与冲突] --> C
+  C --> M[模型起草与确定性校验]
+  M --> P[持久提案和差异]
+  P --> H[编制人确认]
+  H --> W[原子写版本与追溯]
+  W --> R[冻结整文审核与批准]
+  R --> E[按快照生成 DOCX]
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> Preparing
+  Preparing --> AwaitingDecision: 目标或冲突待确认
+  AwaitingDecision --> Preparing: 有权人决定
+  Preparing --> Generating: 输入固定
+  Generating --> Validating
+  Validating --> Proposed: 校验通过
+  Validating --> NeedsRevision: 检查发现问题
+  NeedsRevision --> Generating: 修订受影响章节
+  Proposed --> Applied: 编制人采纳及事务成功
+  Proposed --> Stale: 依据权限或目标版本失效
+  Generating --> Failed
+  Generating --> Cancelled
+  Failed --> Preparing: 重验后恢复
+```
+
+生成运行状态与文档审批状态分开。Applied 仅表示形成内部内容版本；随后仍需“编制中→审核中→待批准→已批准”，驳回回编制中，批准绑定固定整文快照。
+取消只停止未完成任务，不撤销已经确认提交的版本；状态未知时先查事务结果。恢复重新取得受限 Host 与权限，不能序列化旧凭据或长期复用旧 Host。
+
+### Dependencies and Assumptions
+
+与 [两树一网集成方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md) 复用项目绑定/授权、原子事件、历史重放和可读引用能力，不建立第二套项目或审计服务。
+该方案文档记录已批准，不能据此声称实现已经完成；本生成方案把相关能力作为实施前置条件，是否复用已合入实现以启动时源码和证据为准。
+与 [多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md) 复用持久任务、事务与团队存储方向。RDM 仍需自己的事件/领域存储适配，不因基座使用 PG 就宣称 RDM 已支持多实例。
+近期建议单实例完成两项目隔离和三人职责验收；团队多实例单独通过并发、恢复与迁移验证后开放。
+基线更正：RDM requirements/README 已确认相关 V2.2 正文于 2026-10-09 合入定稿；正文残留“待评审”不推翻该裁定。本案新增实现契约仍待用户评审。
+
+---
+
+## Implementation Units
+
+以下为待批准的分期，U-ID 只在本方案内有效；责任模块已明确，人员在立项时确定。每阶段均按 `policy/delivery.md` 人工评审，允许阶段内根据证据迭代。
+
+### U1. Contracts and Asset Ledger
+
+目标：形成完整资产清单与可运行入口的修复设计。覆盖 R1/R2/R9/R12。
+范围：RDM templates.go、plugins/rdm/plugin.go、labels_seed.json；新增资产迁移台账、总线契约测试，复用 templates_test.go/templates_v01_test.go。
+措施：记录 69+1 旧资产；统一类型/模板键、默认用途和真实身份字段；声明工具投影；确认现有项目/权限前置工作由哪项任务交付。
+验证：两条中文编写请求匹配合法文档类型；同类型周报不抢正文模板；审签经总线可达且伪造身份拒绝；查询/总结不得生成；69 类处置无遗漏。
+出口：资产及契约评审完成；未把全部模板标为可用。无需先搬迁所有正文。
+
+### U2. Published Template and Document Instantiation
+
+目标：模板成为结构与排版的唯一版本依据。依赖 U1；覆盖 R1/R3/R12。
+范围：RDM docs/templates、rdmapp/templates.go、structure.go、domain/doctree.go、payloads.go/replay.go；新增 template_contract_test.go、template_instance_test.go、发布包资产检查。
+措施：发布生命周期、稳定章节键、固定 templateRef、显式默认、版本比较、资产 bundle；两个已有业务模板先结构化，旧自举树做映射而非覆盖。
+验证：v2/v10 顺序正确；缺模板明确失败；不同用途不误选；模板新版本不改历史文档；同名章节、可选章节、模板退役、无源码安装包启动均覆盖；普通编制人不能发布共享模板或修改其他项目默认。
+出口：从两个已发布模板产生正确文档树，内容要求与导出规格可供后续步骤读取。
+
+### U3. Context Snapshot and Durable Proposal
+
+目标：固定依据并可恢复地起草整文。依赖 U2 及项目授权/读取边界；覆盖 R2/R4/R5/R6/R10。
+范围：RDM draft.go、compose.go、fbhost/adapter.go、domain/fb/writegate.go；新增 generation.go、proposal_store.go 及相应测试，具体命名实施时固定。
+措施：持久 Run/ContextManifest/Proposal；精确来源映射；章级计划与预算；固定模型/提示词版本；空缺与冲突单列；持续进度与取消/恢复。
+验证：无素材、只有旧依据、只有冲突、多切片同原件、跨项目/私有资料、超长上下文、模型失败、检索降级、取消、重启、撤权，均有真实可观察结果。
+出口：两份文档可形成整文候选，逐段回到稳定来源，刷新和重启不丢；尚未自动写生效正文。
+
+### U4. Confirmed Atomic Document Revision
+
+目标：采纳提案后内容、版本和追溯保持一致。依赖 U3 及两树一网原子事件能力；覆盖 R5/R7/R8/R9。
+范围：RDM draft.go、domain/fb/writegate.go、doctree.go、eventlog.go、replay.go、review.go；新增 proposal_apply_test.go、document_revision_test.go、故障重放测试。
+措施：固定 proposalId、CAS、幂等、保留/新增/删除依据；整文版本清单；统一编制权限；修正文档级审签；旧入口适配同一服务。
+验证：两个标签页竞写、确认前版本变化、撤回依据、取消引用却残留事实、重复点击、写版本后建边失败、提交审核后旧卡片执行、部分采纳与整文导出一致性；只采纳后继章节而保留旧前置章节须被依赖校验拦下；迁移中同文档不同章节职责/正式版、审核中记录不得自动转成整文授权与批准。
+出口：事务全成或全败；重放还原同一版本和引用；旧候选不会覆盖新内容。
+
+### U5. Chat Workflow and DOCX Delivery
+
+目标：用户仅凭对话完成首批真实编制闭环。依赖 U4；覆盖 R2/R9/R10/R11/R13。
+范围：RDM plugins/rdm/plugin.go、编制 skill、web/app.js、docx.go；必要基座公开契约申请；新增总线全链路、浏览器与 DOCX 文件验证用例。
+措施：准备/冲突/采纳/审签卡同源状态；固定模板与章节的编制配方；文档级审批快照；草稿与正式 DOCX；文件卡复用基座预览下载。
+验证：三名真实用户分别编制/审核/批准，两项目隔离；无职责的新文档经负责人在对话分配后由指定编制人接续，非编制人只可转交；收起右栏完成全程；刷新/重启、陈旧卡片、下载撤权；实际 DOCX 标题、表格、分页、页眉页脚、引用可见且版本一致。
+真实模型对照：固定同一批素材与任务，记录改造前后正确模板选择、必需内容覆盖、引用支持、编造事实、人工修订量、耗时与失败恢复；单测/mock 不替代此项。
+出口：项目建议书和竞品分析经真实 UI 与模型完成，产物持久可见可下载；评审人独立重放。
+
+### U6. Document Families and Legacy Migration
+
+目标：按业务文档族逐批覆盖其余历史资产。依赖 U5，且每批模板先评审发布；覆盖 R3/R11/R12。
+范围：RDM 模板资产/注册表/迁移台账及模板契约回归集；参考 Legacy:templates/docs，不再依赖旧工作流实现。
+推荐顺序：用户需求与系统/软件需求→设计任务与计划→设计方案与记录→验证/确认与测试→评审/风险/其他体系文档；精确文档名和批次以 U1 台账与用户优先级确认。
+验证：每个上线模板至少一个有材料的完整生成例和一个空缺/冲突例；每类特有表格、引用及 DOCX 规则有针对性验收，不能只跑注册表计数。
+出口：69 类均有明确结果，所有声明已支持的类型通过对应验收；不适用由人裁定，未交付保留可见状态。报价 XLSX 单列，不偷换为 DOCX。
+
+---
+
+## Verification Contract
+
+测试在后续获批实施阶段执行，本轮结果全部 NOT_RUN。源码检查只能证明路径存在与静态矛盾，不能证明真实编制体验。
+
+| 层级 | 对象与方法 | 必须证明 |
+|---|---|---|
+| 资产 | 69 类迁移台账、模板契约校验、安装包 smoke | 类型/模板/默认/结构/格式一致；没有源目录依赖 |
+| 单元与领域 | RDM `make test` 的 Go 测试；模板、检索、版本、权限、状态机测试 | 正常、拒绝、边界、依据保留与失败事务行为 |
+| 总线与工具 | 真实注册表→schema→认证主体→处理器→领域服务；实际模型工具清单 | 文本入口与 UI 共用真实可达能力；审签身份无自相矛盾 |
+| 持久集成 | 实际领域存储、原子事件、重启重放、幂等与并发故障注入 | 内容/引用/审批不出现半完成；未知结果可查 |
+| 浏览器 | 真实三用户、两项目、对话＋卡片＋预览＋下载；现 `make test-web` 只作局部辅助 | 刷新、断连、重启、权限变化后结果仍正确，右栏关闭不丢操作路径 |
+| 模型行为 | 固定素材和模板的任务级前后对照、人工盲审结果 | 模板选对、事实有支持、缺项诚实、未授权内容不出现 |
+| 交付物 | 解包检查 DOCX OOXML＋实际 Office/LibreOffice 打开检查 | 正确内容、格式、表格、引用和批准快照；不能只检查扩展名 |
+| 跨仓 | 固定 RDM pins 与 Dev 公开契约 SHA，相关 CI 及独立重放 | 下游实际组合可运行，禁止用另一组组件证据替代 |
+
+首批硬判据：所选模板/version 必须正确；持久引用全部存在且在授权范围内；负向越权与静默基线覆盖为零；已声明完成的章节无未标注的证据缺口；相同幂等请求只生效一次。
+“引用存在”与“语义支撑”分别评分。测试/验证报告不得虚构执行记录、测量值或通过结论；无实际执行证据只能生成计划、空表或标注未执行的报告草稿。
+耗时、费用、引用支持率和人工修订量先建立基线，再由用户确认可接受阈值；上传首轮 60 秒指标不套用为整文生成时限。
+项目审计中心权限沿既有两树一网方案；编制人可查看完成本职责所需且有权访问的引用，不能借生成工具读取整个项目审计或他人私聊。
+证据分 SELF/GATE/REPLAY；正式验收固定对象与环境，按仓库要求经 evidence 记录，不把模型自评作为独立通过。
+
+## Definition of Done
+
+本轮方案交付：资产盘点、关键源码断点、需求与方案、分期和验收可追溯，待决事项与未执行内容明确；本地方案尚未获得人工批准。
+业务完成：U1–U5 首批真实闭环有完整证据；后续 U6 每批独立验收和发布，不把首批成功写成 69 模板全部可用。
+上线声明另需固定安装包、目标实例、迁移/恢复记录及运行验收；当前没有上线声明。
+
+建议下一任务是 U1 的契约核对与模板台账，而不是直接批量生成 69 份文档。先复核远端在途任务，和两树一网授权/事务工作项分工；本建议不启动实施。
+
+### Review Decisions
+
+请评审以下具体选择：
+
+1. 采用“RDM 内补齐闭环＋69 类资产分批接入”的路线，复用现有模板内容。
+2. 首批项目建议书、竞品分析，随后扩展全部文档——已确认（session-settled: user-approved，2026-10-11，用户对首批优先级问题的回复）。后续各文档族之间的顺序尚未确认。
+3. 以文档级版本快照进行三权审签，章节作为生成、差异与增量采纳单位。
+4. 固定模板和依据后生成持久提案，编制人确认才写入；标准模板替换仍待用户后续提供。
+
+第 2 项首批及扩展方向已确认；第 1、3、4 项及完整实施/测试计划仍待评审。本次优先级确认不构成业务实施、迁移或部署授权。计划中确定性契约与测试细节可在评审意见内迭代，改变权限/模块职责/范围时重新评审。
+
+## Appendix
+
+主要依据：
+
+- RDM:docs/requirements/01-用户需求与系统需求.md：UR-11、SR-C1–C8、SR-D1/D6、SR-E4/E6、SR-F1/F4/F5、F-10。
+- RDM:docs/requirements/03-产品设计方案.md：M5/M6/M9/M10、F4/F6、§7 旧版 69 模板处置。
+- RDM:docs/requirements/08-核心数据模型-两树一网.md：两树职责、共用标签、F-B、R1–R5、模板来源维度。
+- RDM:docs/proposals/2026-10-08-U0-baseline-and-shared-contracts.md：项目共享、三权、两层冲突裁决、固定版本和对话同源约束；其中旧源码缺口已重新核对，不原样当作当前事实。
+- Dev:DESIGN.md：对话优先、工作/文件双入口、一个状态所有者、一个预览落位。
+- 本目录 2026-10-11-rdm-two-trees-trace-audit-integration.md 与 2026-10-11-collaboration-storage-and-distribution.md：本方案的授权/事件/存储依赖；不复制作另一条实施主线。
+
+完整资产目录见 [模板资产盘点](../records/2026-10-11-rdm-template-inventory.md)。目录仅报告源码资产状态，不包含线上项目的实际文档数量。

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

@@ -0,0 +1,401 @@
+---
+title: RDM 两树一网集成、完善与追溯审计展示方案
+type: feat
+date: 2026-10-11
+execution: code
+artifact_contract: ce-unified-plan/v1
+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（团队存储）独立后续；运行验收属部署环境。
+需求负责人：weichen；方案编制：Codex；实施负责人：待实施立项时指定。
+来源：2026-10-11 用户要求检查两树一网现状，并设计简单直观的项目追溯、审计展示；同轮明确选择“完善 RDM，并补齐必要的基座能力”。
+目标仓：Agent-System-RDM；下文 `RDM:` 路径相对于该仓，`Dev:` 路径相对于 Agent-System-Dev；所有建议接口名均为候选契约。
+关联任务：Dev `.task/feature-rdm-two-trees-audit-plan.md`；本文件是本次方案唯一正文。
+
+## Goal Capsule
+
+推荐按**每项目一套笔记树、文档树和追溯网**管理，在现有 RDM 实现上补齐隔离、历史完整性和产品入口。
+项目创建者查看自己创建项目的追溯审计；RDM 域管理员与基座超管（基座 isAdmin）查看全部项目。
+管理员使用跨项目目录和筛选器进入各项目，默认不展示混合的全局关系大图。
+
+本轮只交付现状、方案和实施验收计划；方案已于 2026-10-11 获用户评审通过，业务实施与数据迁移仍须另行立项授权。
+项目独立是数据归属、授权、版本和查询范围独立，不要求每项目部署一套服务或建立一个数据库。
+先用一个项目跑通业务闭环，同时用第二项目验证隔离；管理员全项目目录与历史导出随后接入，本批默认范围为 U1–U5。
+
+---
+
+## Product Contract
+
+### Current State
+
+**结论：已经实现相当一部分，适合做集成与完善；尚不能认定为满足本次要求的完整产品。**
+
+调查基线（SELF·源码检查）：
+
+| 对象 | 固定提交 |
+|---|---|
+| Dev 集成仓 | `5771d4f1e5b692bce95eb64cc30dc9931079ad12` |
+| Dev Backend | `ea4651b1f870d84ab9b72cfa79363b3432d113b3` |
+| Dev Frontend | `3ed10e122042a64180fb24a42d9cc6438cd2d2d6` |
+| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
+| RDM 实际 Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
+| RDM 实际 Frontend pin | `84b73ab32848e623d0a0ab7ade552784dca8cf3c` |
+
+Dev 当前源码与 RDM 实际依赖不是同一组合，升级前须分别核验公开契约。
+本次没有运行业务测试、登录服务、读取业务数据库或进行浏览器验收；下列“已有”指源码存在，不能转换为“已部署/已验收”。
+命令、对象 SHA、原始输出和远端在途查询由工具保存于[调查收据](../records/2026-10-11-rdm-two-trees-source-receipt.json)；收据为 SELF，不是 GATE 或独立 REPLAY。
+
+| 对象 | 源码现状 | 本次需要补齐 |
+|---|---|---|
+| 笔记树 | `RDM:internal/domain/notetree.go` 已有骨架、切片、锚点、标签、多点挂载、软删除；树是浏览骨架，切片可多挂载 | 独立浏览和详情读取接口；完整树导航；层级与挂载一致性 |
+| 文档树 | `RDM:internal/domain/doctree.go` 已有文档、章节、正文版本与依据、状态；已有基线和审签能力 | 树式浏览、真实版本元数据、来源与变更联动 |
+| 一般追溯网 | `tracenet.go`、`rdmapp/trace.go` 已有关系生命周期、邻域、多跳和图查询 | 端点完整性、同项目约束、版本定位及统一读模型 |
+| 受控合规图 | `compliance.go`、`chainviews.go`、`cgraph_export.go` 已有受控节点、版本边、链视图、矩阵及导出 | 与一般关系网整合展示；补重放一致性和历史快照 |
+| 项目分片 | `events.project`、`WorldFor`、按项目重放已经存在 | 清除外部入口的空项目全量回退；贯通基座项目与 RDM 项目；端到端鉴权 |
+| 结构历史 | `eventlog.go`、`replay.go` 已有 seq、操作者、时间、来源、payload 和重放 | 原子批次、幂等、完整状态还原、对用户可读的时间线 |
+| 现有界面 | `RDM:web/app.js` 有基线表、章节弹层、SVG 追溯图和多跳高亮 | 缺独立笔记树、统一审计页、完整项目上下文；合规图与导出尚未接入 Web |
+| 基座审计 | `Host.Audit`、`audit_events`、`command_audit` 已有通用记录 | 缺显式项目作用域、结构事件关联、跨项目管理员查询及稳定分页 |
+
+旧 `RDM:docs/design/data-model.md` 中“当前单 World、需求无产生路径”等结论已被后续代码改变，不作为当前缺口依据。
+旧追溯网和受控合规图目前是分别维护的边集合；共用事件日志不等于已有一张覆盖所有对象的完整网。
+
+### Material Gaps
+
+以下为源码事实及控制流推导，失败/越权场景尚未动态重放。
+
+| 编号 | 问题与依据 | 影响与处理 |
+|---|---|---|
+| G1 | `runtime.go:108` 空项目返回全库重放的 `rt.World`；`plugin.go:737` 的 trace/graph/hops 未检查 actor；实际 pinned Backend 的 `compiled.go:31` 和 `cmdbus.go:228` 没有领域项目授权 | 只隐藏页面入口无法隔离；旧命令、工具、图、计数、详情、导出均须使用同一服务端策略 |
+| G2 | `web/app.js:69,170` 使用基座项目，命令不自动注入领域项目；`projects_api.go:43` 列出全部 RDM 项目 | 必须先建立项目身份绑定及授权后的目录，不能依赖前端选择器过滤 |
+| G3 | `projects.go:18` 的 CreatedBy 与 `members.go` 的 owner 角色分离；`rdm_admins` 与基座 isAdmin 分离 | 按创建者事实授权；不能用“负责人”“成员”替代创建者；审计可见性按 KTD4 双层口径（基座超管＋RDM 台账域管理员）执行，域管理员不因此获得平台管理权 |
+| G4 | `notetree.go:77` 的入库/挂载逐事件提交；`tracenet.go:67` 的 candidate/confirm 分开提交；`Retag` 等先改内存再写日志 | 中途失败可能遗留部分事件或内存/数据库不一致；先补事务批次和提交后投影 |
+| G5 | `compliance.go:170` 升版标 stale，但 `replay.go:230` 未对等重建；快照事件仅保存计数/hash；`replay.go:379` 正式版审签重建缺少时间/操作者 | 重启和历史回看可能与提交时不同；不得在修复前展示“历史已完整还原” |
+| G6 | `conclusions.go:264` 取提案只有 id 没有 project 条件；`tracenet.go:59` 未校验关系端点归属 | 全部节点、版本、提案和关系必须在同一项目作用域解析；跨项目对象拒绝 |
+| G7 | 成员/权限主要保存当前态；部分 `h.Audit` 错误被忽略；`review.go:95` 职责事件 Actor 使用受托编制人 | 补真实操作者与被操作主体分离、变更历史及可靠审计投递 |
+| G8 | `Dev:modules/backend/internal/store/platform.go:187` 审计无 project 字段；命令审计按 owner/会话读取 | 不能按 target 字符串猜项目，也不能把创建者自己的动作记录冒充整个项目审计 |
+
+### Requirements
+
+用户明确的范围与权限优先于旧方案：RDM 负责领域，基座只补通用能力（session-settled: user-directed — chosen over 所有基座项目内建两树一网：用户选择完善 RDM）。
+
+| ID | 需求 | 可判定验收条件 |
+|---|---|---|
+| R1 | 每项目独立两树一网 | A 项目查询、遍历、计数、详情、历史、导出均不出现 B 项目对象；跨项目建边被拒绝 |
+| R2 | 仅项目创建者和系统管理员查看追溯审计 | 创建者可读所建项目；RDM 域管理员与基座超管可读全部；非创建者负责人、成员、非成员均不能访问审计能力；域管理员不因此获得平台管理权 |
+| R3 | 展示来源与影响 | 任一支持的对象能查看来源、去向、版本与待确认关系，并打开有权限的证据 |
+| R4 | 操作记录直观可读 | 能回答谁、何时、改了什么、为什么、结果如何；未知信息明确标缺失 |
+| R5 | 历史真实且可重建 | 同一项目同一 seq 下，重启前后节点/关系/版本/审签/缺口一致；不可重建时明确报错 |
+| R6 | 提交与记录一致 | 单命令多事件全部提交或全部不生效；重试不重复生效；并发覆盖返回明确冲突 |
+| R7 | 简单、渐进展示 | 默认显示摘要、树和所选对象的一跳关系；不强制用户理解节点类型、内部事件码或原始 JSON |
+| R8 | 可导出可复核结果 | 导出绑定项目、截止 seq、对象版本、规则版本、身份与生成时间；文件下载再次鉴权 |
+| R9 | 复用现有能力和开发边界 | 保留 RDM 模型/计算/导出器，基座扩展经公开契约交付；无下游导入基座 internal |
+| R10 | 历史数据及私人资料有清楚边界 | 未归属记录不自动塞入默认项目；项目审计不绕过私人原文访问控制 |
+
+R2 约束项目审计中心及能返回等价审计数据的接口；普通文档阅读、协作、合法的引用展示继续遵守既有业务权限，不能顺手全部收紧为创建者专属。
+模型工具同样受调用者权限约束，不通过智能体转述绕过审计读取限制。
+
+---
+
+## Planning Contract
+
+### Key Technical Decisions
+
+以下为待评审的推荐技术决策；只有显式 session-settled 标注的用户选择已在本轮确认。
+
+- KTD1. **项目为隔离根，逻辑分区共享存储。** 查询及复合键携带实例域与 projectId；项目内对象采用稳定 ID，受控对象另带不可变版本。关系两端在同项目内解析，项目归属创建后不随意改动。共享模板/法规以固定版本引用或项目内快照进入，保留来源；第一版不建立项目 A 到项目 B 的业务边。
+- KTD2. **复用两套图，通过读适配器形成统一项目视图。** 一般事实关系与受控合规关系保留不同确认及版本规则，避免一次重写两套存储。统一对象引用包含项目、类型、ID、版本、图层，防止 ID 碰撞或把不同版本误并为一个节点。`candidate` 显示“待确认”、active 显示“已确认/已生效”、retired 显示“已废止”；stale 显示“依据版本已变更”。不将模型候选画成已生效事实。
+- KTD3. **一个服务端授权入口。** RDM 审计能力判定为“可信认证主体是 RDM 域管理员或基座超管（isAdmin），或等于项目 CreatedBy”。CreatedBy 固定；负责人调整不转移此权利。另设审计 read/export/history 能力映射，普通成员不能被项目负责人额外授予这些能力。权限异常拒绝读取，授权后的项目范围再进入存储，禁止先读全量后前端过滤。
+- KTD4. **双层管理员：基座超管保底＋RDM 台账域管理员。**（session-settled: user-directed — chosen over 两套真值完全分离与基座 isAdmin 单层直通：用户 2026-10-11 评审裁定）基座提供认证身份；基座 isAdmin 作为超管始终可查看全部项目审计，是跨项目审计的保底入口。RDM 现有唯一管理员台账继续判定域审计管理员：域管理员可读全部项目，但不因此获得平台用户/插件等管理权。基座管理区承载的 RDM 审计分区对两类管理员开放；capability 仍由服务端下发，前端只消费、不自行合并角色。历史身份不一致需显式核对，不自动提升为域管理员。普通 project.create 不自动引导域管理员；首个域管理员经受信部署引导产生，初始化唯一性由事务及数据库约束保证。台账为空、多管理员或来源不明时，域管理员路径关闭等待授权核对，超管保底路径不受影响。超管的审计访问同样落入动作审计并标记身份层级。
+- KTD5. **基座项目与 RDM 项目显式一对一绑定。** 新增受约束的 hostProjectId 映射并带实例域；查询会话/工件所属基座项目后解析到 RDM 项目。不得用项目名称或默认第一个项目推断。两库创建无法单事务时用可恢复的 provisioning→ready/failed 流程和幂等标识，绑定未就绪不开放审计。EXT-8 共享资源检查使用映射后的领域项目，但不扩大成审计授权。
+- KTD6. **项目命令原子写，事件为结构历史依据。** 在 RDM 存储事务内验证预期版本、端点归属与幂等键，一次提交整批事件、必要台账和 outbox；提交后更新内存投影。缓存失效或更新失败时重建，不暴露半新状态。关键事件落库失败则命令失败；跨库基座审计通过可靠 outbox 补送，不能用两次独立写入冒充事务。
+- KTD7. **历史按项目＋截止 seq 固定。** 可见水位只取已提交操作批次的结束 seq，时间按批次提交时间解析；显式 seq 落入批次内部时拒绝并提示可选的完整水位，不展示半次操作。保留当前全局 seq 的顺序语义，项目过滤后允许 seq 有间隙，不把它当作丢事件。快照保存完整节点/版本/边/审签/规则版本及哈希，含事件 schemaVersion；只有计数的旧快照不可作为恢复依据。未知事件版本须停止还原并说明缺口，不能静默跳过。
+- KTD8. **先沿用单实例，再与团队 PG 方案衔接。** RDM 当前领域库仍是 SQLite，基座配置 PG 不会迁移它。先修事务和项目串行写入；团队档上线前将 RDM 权威事件/台账纳入有唯一写入 owner 的 PG 存储适配。多实例需数据库发号/并发控制及缓存刷新验证，不因基座支持 PG 就宣称 RDM 支持多实例。
+- KTD9. **当前项目公开事实与私人过程分开。** 项目创建者能看项目审计，不因此得到成员私人会话/原件全文。内部重放载荷与对外审计 DTO 分离，原始 payload 不直接返回。摘要、正文、差异、历史快照和导出中的复制内容统一进行披露检查：当前来源 ACL 允许，或存在可核验的项目发布快照，方可输出。旧数据无来源/发布依据时默认遮蔽并标“来源受限/归属待核实”，不泄漏标题、摘要或路径。管理员看全部项目审计，仍不把凭证、模型隐藏推理或无关私聊放进审计输出。
+
+### Architecture
+
+```mermaid
+flowchart TB
+  U[创建者：自己项目 / 域管理员与基座超管：全部项目] --> A[认证身份 + 审计能力校验]
+  A --> P[解析当前项目绑定]
+  P --> Q[RDM统一审计读服务]
+  Q --> N[笔记树与文档树投影]
+  Q --> G[一般追溯与受控合规图适配]
+  Q --> H[事件历史与完整快照]
+  Q --> B[基座动作审计：经授权关联查询]
+  Q --> V[同一追溯审计工作区]
+```
+
+两树说明“资料怎样整理、文档怎样组织”；关系说明“依据来自哪里、影响到哪里”；审计说明“谁在什么时候作出了什么变更”。
+它们共用项目和对象身份，各回答一个问题，不要求用户先学习图数据库概念。
+
+### Data and Event Contract
+
+领域事件补足项目、operationId/requestId、真实 actor、actorType、被操作主体、对象版本、发生时间、提交 seq、原因、事件 schemaVersion，以及必要的前后差异。
+一个 operationId 关联多个结构事件和基座动作审计；前端按一次操作归组，技术明细按需展开。
+纠正错误通过新事件完成，保留更正者和原因；关系失效、软删除和权限变更不覆盖原历史。
+
+权限变更审计保留当时的政策版本/决策摘要，便于解释过去为何允许；**现在能否查看**仍按当前权限判断。
+前端自报审计只能标为客户端报告，不得伪装成服务端核实的批准或业务成功。
+普通 hash 用于校验导出/快照一致性，不宣称具备防数据库管理员篡改或电子签名保证。
+
+```mermaid
+sequenceDiagram
+  participant C as 调用者
+  participant A as RDM命令应用层
+  participant D as RDM存储
+  participant B as 基座审计
+  C->>A: 项目、操作、预期版本、幂等键
+  A->>A: 当前授权与同项目端点检查
+  A->>D: 原子提交事件批次、幂等结果、outbox
+  D-->>A: 已提交seq及结果
+  A-->>C: 业务结果与可追溯操作编号
+  A->>A: 刷新或重建项目投影
+  D->>B: outbox可靠补送关联审计
+```
+
+基座暂不可用时，已提交结构事实继续保存，动作审计显示“同步中”；恢复后幂等补送。
+关键业务规则需要同一库的证据记录才能放行时，在业务事务内保存；不将异步投递当作批准的前提已满足。
+导出需先固定截止水位、检查完整性；审计关联仍缺失时明确标为不完整，正式完整报告应阻止导出或要求用户选择带缺口的草稿。
+
+### Read Interfaces
+
+优先通过现有命令总线及页面 SDK 提供 RDM 查询，所有入口落到同一应用服务；不另建绕过权限的调试 API。
+
+| 候选读契约 | 返回内容与限制 |
+|---|---|
+| inspect.capabilities / inspect.projects | 可见项目、当前项目是否可审计、是否可跨项目；管理员全项目目录独立分页 |
+| inspect.summary | 两树规模、待确认关系、缺口、最新动作、数据截止水位；不把缺失当作零 |
+| inspect.tree / inspect.object | 树子节点分页；所选对象版本、出处、状态；只展开需要的分支 |
+| inspect.relations | 方向、图层、关系状态、版本、深度；默认一跳，后续点选扩展；有数量上限和截断提示 |
+| inspect.events | 按项目、对象、时间、操作者、动作、结果过滤，游标分页；可展开一次操作的差异 |
+| inspect.history | 固定 seq/基线下的对象、关系和当时规则；缺少重放材料返回明确不可还原状态 |
+| inspect.export | 导出同一筛选条件和截止水位；生成、取状态、下载都重新校验主体及项目权限 |
+
+分页游标绑定项目/筛选条件/排序/权限版本，不能拿 A 项目游标读 B。
+缓存、导出缓存及订阅键包含主体能力范围、项目和截止水位，撤权后不可复用旧授权结果。
+异步数据只有一个状态所有者：项目切换取消旧请求并递增 generation，过期响应丢弃；事件按 seq 去重、有序应用。
+
+### Base Extension Requests
+
+先验证现有注册点能否组合；不足部分按 RDM 的四要素扩展申请办理，保持公开面可选、向后兼容。
+
+| 场景 | 希望的通用能力 | 现有能力不足 | 兼容方式 |
+|---|---|---|---|
+| 创建者看项目内所有人的动作 | 审计 envelope 的 projectId、operationId、对象版本及按项目查询 | Host.Audit 只有 owner/action/target/evidence；按 owner 会遗漏其他成员动作 | 增加可选的结构化审计能力/接口，不直接强改所有 Host 实现；旧记录标项目未知 |
+| 宿主页面展示 RDM 审计入口 | 插件提供当前主体的审计能力和可见项目，宿主提供可信身份与项目上下文 | EXT-8 只有资源共享读取布尔判断；基座 AdminZone 仅看 isAdmin | 新增可选的动作级 capability/provider；不改变旧资源授权器含义 |
+| 私人来源与项目发布证据联动 | 已授权工件/版本链接与受限占位，导出后下载再校验 | 不能让全项目审计器任意扩大 owner-scoped Host | 复用现有工件访问契约，仅按实测缺口增加窄接口；禁止任意 owner impersonation |
+
+两树对象、边规则、合规矩阵和领域重放保留在 RDM，基座不内置这些领域表。
+
+---
+
+## Display Design
+
+### Entrances and Layout
+
+项目创建者从当前项目菜单进入“追溯与审计”；RDM 域管理员与基座超管从管理区“项目追溯与审计”进入项目目录，选定项目后复用同一页面。
+管理员选择项目后，审计工作区的项目上下文必须更新为实际被审计项目，所有请求与标题保持一致。宿主支持审计项目切换时，项目身份集中显示在宿主项目位置；宿主不能切至该项目时，审计页必须显示明确项目标题和“返回项目目录”，并避免让宿主旧项目标题被误认为审计范围。管理员目录显示项目名、创建者、最近活动、待关注数量。
+第一版为只读审计工作区，审批、确认关系和编辑仍跳回原受控业务流程，不在审计页面创造第二套写入口。
+
+页面保留四个入口：**概览、资料与文档、关联追溯、操作记录**。
+左侧按需显示笔记树/文档树导航；主区显示当前选择；对象详情在页面内展开，原件仍进入宿主唯一文件预览区。
+不叠加弹窗，不默认铺满全部节点。
+
+| 入口 | 默认看到什么 | 深入查看 |
+|---|---|---|
+| 概览 | 已收集资料、已形成文档、需要确认的关系、需要补齐的证据；最近几次重要变更 | 点击数字进入带筛选的列表；明确“统计截至…”和“不完整”状态 |
+| 资料与文档 | 笔记树：阶段→事项→主题→资料切片；文档树：阶段→文档→章节 | 同一资料多个挂载不重复计数；缺主题可显示未分类，不伪造层级 |
+| 关联追溯 | 所选对象居中，左右分别为“来源依据”和“影响对象” | 列表优先；切换为局部关系图；合规链/矩阵在此页按需切换 |
+| 操作记录 | 自然语言时间线，按一次业务操作归组 | 展开前后差异、批准依据、对象版本与技术记录 |
+
+### Human-readable Trace
+
+关系展示示意，实际节点与连线必须来自已保存数据：
+
+```mermaid
+flowchart LR
+  A[会议纪要中的原文] -->|支持| B[用户需求]
+  B -->|落实到| C[方案章节 v3]
+  C -->|由此验证| D[验证记录]
+```
+
+点选“方案章节 v3”后首先看到：这是什么、当前版本、依据哪几条材料、影响哪几项需求/验证、最近谁改过。
+缺少验证记录时显示“验证依据待补齐”，不画虚构的完整链；候选边使用虚线和文字“待确认”，不能仅靠颜色区分。
+“没有已知关联”与“尚未完成关系索引/本次查询被截断”分开呈现。
+关系被废止后可在历史模式中看到；跨版本关系明确标注版本，不让 v4 的证据替代 v3 的事实。
+
+### Audit Timeline
+
+时间线示意：
+
+- 10:32 张三将《需求说明》从 v2 更新为 v3；修改了“使用环境”章节，依据为评审纪要第 4 条。
+- 10:41 李四确认该章节与 UR-012 的关联；确认理由为“已覆盖用户场景”。
+- 11:05 王五批准 v3；点击可查看批准时的版本和证据。
+
+每条默认仅显示时间、操作者、动作、对象、结果；“查看变更”再展开前后差异与理由。
+后台归档、重试等技术事件默认归组收起，失败、拒绝、未知结果有文字说明；原始 JSON 不作为主界面。
+Actor 为真实执行者，Subject 为被分配职责或被变更权限的人，界面不混写两者。
+默认显示北京时间并注明时区，底层保留 UTC；历史模式顶部醒目标注“查看截至某时间/某基线的记录”。
+
+### Interaction Boundaries
+
+提供“当前/历史”切换，历史可选择时间或基线；从批准记录可直接打开批准时的版本。两树、关系与记录共用一个截止水位，“返回当前”恢复对象当前版本；对象已删除则显示删除说明，不切到同名对象。
+对象名称支持搜索；树节点懒加载；记录使用“加载更多”；关系默认一跳，上限和截断状态由服务端返回。
+加载、空项目、无权限、部分数据、同步中、历史不可还原、请求失败分别展示，不都渲染成“暂无数据”。
+首屏不显示 SQL、事件 opcode、内部 UUID、hash；复制技术编号放在详情中。
+推荐验收任务：创建者在三次主要点击内找到某章节的原始依据和最近修改原因；管理员能清楚确认当前查看哪个项目。
+
+实现遵循 `Dev:DESIGN.md`：颜色/圆角/字号消费 `@ui` 令牌；折叠用 Collapsible；动效只用 `mk-*`；键盘可导航，状态同时有文字与形状。
+优先在当前宿主工作区体系内以 RDM 插件页面提供，避免长期维护第二套静态工作台。
+旧 `web/app.js` 保留过渡兼容范围，但图与审计能力接同一授权服务；最终页面交付形式在 U4 固定，不能假设在途 Generative UI 已能直接承载。
+
+---
+
+## Implementation Units
+
+本批默认顺序：U1→U2→U3→U4→U5，按 `policy/delivery.md` 分增量评审。U6 是独立后续衔接项，不纳入本批完成条件。
+U1 是首选下一任务；这份方案不构成启动它的授权。
+
+### U1. 项目身份与读取授权闭环
+
+目标/需求：R1、R2、R9、R10；依赖：方案已批准（2026-10-11）、KTD4 已按双层口径裁定；剩余既有项目映射盘点在立项时完成。
+范围：`RDM:internal/projects`、`members`、`perms`、`rdmapp/runtime.go`、`projects_api.go`、`perms_api.go`、`plugins/rdm/plugin.go`、`web/app.js` 的旧客户端项目上下文；测试 `rdmapp/perms_test.go`、`sharding_test.go`、`plugins/rdm/plugin_test.go`；必要基座 capability 扩展单独申请。
+
+建立显式项目绑定；增加审计读取策略和管理员受信引导门禁；统一包裹旧/新 trace、cgraph、项目列表、历史和导出入口。
+U1 同批接通旧客户端的项目选择和命令封装，并解析可信会话/工件上下文到显式绑定；随后启用对外 projectId 必填门禁。无映射时显示“项目待绑定”，不回退全量世界。仅管理员专用迁移/调查路径能够处理未归属域，并单独留痕。
+检查结论提案、引用、关系两端和版本归属，不接受来自别的项目的 ID。
+普通文档协作仍使用原业务权限，避免用审计策略误封工作流程。
+
+验证：创建者、非创建者负责人、成员、非成员、RDM 域管理员、仅基座超管六类主体（后两类均为跨项目审计正例，域管理员访问平台管理分区须为负例）；空项目、伪造项目、跨项目对象、旧命令/模型工具绕过、撤权后的新请求与下载均有正负例。
+增加首次启动、恢复后空台账、并发初始化、普通建项目不提权的验证。
+完成条件：至少两个项目、多用户、真实认证入口下全部读取边界可复核；不依赖隐藏按钮。
+
+进展（2026-10-11，RDM PR #195 merge 05b7d1a）：U1 已实施合入——审计判定统一入口（创建者∨域管理员∨超管槽，`AuthorizeAudit`/`AuthorizeCmd`，命令面全接线，空 projectId 显式拒绝）；KTD4 双层管理员落地（`rdm_admins` 单行台账＋`-bootstrap-admin` 受信引导，`project.create` 不再自动引导）；KTD5 宿主显式绑定（`rdm_host_project_map`＋`rdm.project.bind/unbind`＋EXT-8 映射解析＋上传可信上下文解析）；项目列表按主体过滤；旧客户端 `web/app.js` 统一注入 projectId。两项基座扩展申请已随该 PR 落盘（`RDM:docs/proposals/2026-10-11-u1-base-extension-requests.md`）：超管槽在基座能力发版前保持 fail-closed，「仅基座超管」负例†待接线翻正；真实认证入口运行验收随 U4/U5 复核。
+
+### U2. 原子事件与历史还原
+
+目标/需求：R5、R6、R10；依赖：U1 的项目合同。
+范围：`RDM:internal/domain/{eventlog,notetree,doctree,tracenet,compliance,replay,persist,review}.go`、`domain/store/store.go`、`rdmapp/conclusions.go`、`upload.go` 及上传状态台账，对应 `persist_test.go`、`integrity_test.go`、`compliance_test.go`、`conclusions_test.go`、`upload_test.go`。
+
+补事件批次事务、项目内写入串行/预期版本和操作幂等；内存变更置于提交之后。
+上传原件先不可变留存，再由同一 RDM 数据库事务发布引用、状态、项目归属、切片关联、pending 关闭和幂等结果；meta.json 降为可重建镜像。上传确认/拒绝中断后按操作结果恢复，不重复入库；此项在 SQLite 首期完成，不等待 U6。
+修复升版 stale、正式版审签元数据和完整快照重放；记录成员/权限/职责变化及真实 actor。
+建立结构事件到基座审计的 outbox，显示投递状态；旧缺失事实明确为不可恢复，不能补造批准人或时间。
+
+验证：第二条/最后一条事件失败、提交后进程退出、投影刷新失败、相同请求重试、并发同版本更新；重启前后对节点/版本/边/审签/缺口深比较；旧快照与未知 schemaVersion 明确拒绝冒充完整；历史/导出截止落在批次中间时拒绝，上传发布/确认中断后状态与切片不重复、不矛盾。
+
+进展（2026-10-11，RDM PR #197 merge fe8a75b）：U2 已实施合入——`Runtime.TxProject` 事务批次（项目写锁＋tx 绑定写穿＋失败回滚并从库重建，零部分提交）；入库拆事务内核/提交后宿主侧；结论确认/拒绝与上传五步同事务（`rdm_uploads` 表为事实源，meta.json 降为镜像）；Retag 事件先行；重放保真（正式版 At/Actor 入载荷、CNode 升版重放重算 stale、cSnap 全量载荷＋旧计数快照标 CountOnly、events schema_version 未知版本停止还原）；`rdm_op_log` 幂等（结论/上传确认 opId）；`rdm_audit_outbox` 同事务入箱＋尽力投递＋`rdm.audit.status`。写串行覆盖＝事务面＋已转换命令（用户裁定口径）；进程级 kill 注入与运行验收随 U4/U5 复核。
+完成条件：命令结果、持久记录、重建投影一致，故障不造成不可解释的部分成功。
+
+### U3. 统一项目审计读服务
+
+目标/需求：R3、R4、R5、R8；依赖：U1、U2。
+范围：`RDM:internal/rdmapp/trace.go`、`baseline.go`、`cgraph_export.go`、拟增 inspection 读投影；`plugins/rdm/plugin.go`；测试 `trace_test.go`、`chainviews_test.go` 及新增 inspection 集成测试。
+
+把两树、一般关系、受控关系、结构事件和基座动作记录适配到统一对象详情及分页查询。
+为查询绑定项目、当前授权、截止水位及版本；返回覆盖状态和截断状态。
+补公开面需要的 project/operation 审计查询与能力 provider；不从字符串解析项目归属。
+
+验证：旧网和合规网的同名 ID 不冲突，历史 v3 与当前 v4 不串用；未知/受限来源在旧 payload、差异、快照及导出副本中也不泄漏；游标换项目拒绝，分页期间新增事件不重不漏；动作审计同步延迟可见。
+完成条件：无需读数据库即可通过受控接口回答来源、影响、变更与历史问题。
+
+进展（2026-10-11，RDM PR #201 merge dbc41b6）：U3 已实施合入——`inspection.go` 七面读服务（Capabilities/Summary/Tree/Object/Relations/Events/History）＋统一响应壳（键集分页＋截断＋coverage 诚实标注）；游标 base64 绑定项目（跨项目/过滤不一致拒绝）；水位＝已提交 max(seq)；双网合流（layer 标注/kind 路由不串/ver 标注）；schema v6 events.operation_id 列＋TxProject BeginOperation 归组注入；披露标记（legacy-unattributed/model-candidate）；`rdm.inspect.*` 七命令＋审计面授权。基座侧动作审计待基座扩展（申请一/二）。
+
+### U4. 项目追溯审计工作区
+
+目标/需求：R2、R3、R4、R7；依赖：U3；页面载体在本增量设计评审时固定为宿主支持的 RDM 插件工作区。
+范围：RDM 页面资源及宿主注册声明；必要时 `Dev:modules/frontend/src/components/{Workspaces,AdminZone,adminSections}.tsx`、`store.ts`、`api.ts`；交互测试沿用 frontend test/e2e 体系，旧 Web 的兼容测试留在 `RDM:web/workbench_test.mjs`。
+
+实现四入口、两树导航、对象详情、一跳关系和自然语言记录；普通用户无入口且接口拒绝。
+管理员目录按授权后的项目查询，选项目复用页面；RDM 管理 capability 不解锁其他平台管理分区。
+沿用宿主文件预览、令牌和折叠；删除/替换旧重复图入口需另列兼容清单。
+
+验证：真实浏览器完成来源查询、选择历史时间/基线并返回当前、管理员从宿主 A 打开审计 B 后标题和请求一致；模拟慢请求后快速切项目无串页；键盘、窄屏、长标题、千级节点懒加载、空/失败/受限/不可还原状态可理解。
+完成条件：用户按三次主要点击任务完成取证，并人工评审界面是否直观；业务可用与视觉通过分别记录。
+
+进展（2026-10-11，Dev PR #368 merge 7aa8fd9）：U4 已实施合入——`RdmAuditWorkspace.tsx` 四入口（概览/资料文档/关联追溯/操作记录）Dev 前端 builtin 工作区，消费 U3 `rdm.inspect.*` 七命令面；`rdmCommand` 封装（receipt 解包＋confirm-card 提示）；DESIGN.md 令牌严格合规（0 裸色值/0 行内 fontSize/0 details/0 新增 keyframes）。附带修复 U5 遗留的 PreviewPane TS 类型错误（单参/双参签名匹配）。
+
+### U5. 历史导出与正式集成验收
+
+目标/需求：R5、R8、R9、R10；依赖：U2、U3、U4。
+范围：`RDM:internal/rdmapp/{cgraph_export,docx,xlsx}.go`、页面导出入口、导出临时工件及下载授权；测试 `domain/export_test.go`、`plugins/rdm/xlsx_export_test.go` 和浏览器下载场景。
+
+复用 docx/xlsx 导出器，固定项目/版本/规则/截止 seq，补证据来源清单和完整性说明。
+导出按请求身份和范围生成，撤权后下载失败；历史受限来源不随导出泄漏。
+固定基座发布版本、RDM pins 与页面资源组合后，重放真实端到端流程。
+
+验证：导出中途有新写入不改变已固定内容；历史来源软删除仍可按授权追溯；未归属/缺失事件可见；跨项目下载、过期下载、权限撤销均拒绝。
+完成条件：同一版本在 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 五个实施单元全部完成，进入部署验收阶段。
+
+---
+
+## Deferred Integration
+
+### U6. 团队部署存储衔接（独立后续任务）
+
+本项不纳入 U1–U5 的默认实施与验收范围，另经团队存储方案授权后立项。
+目标/需求：R1、R5、R6、R9；依赖：U2，以及[多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md)适用增量。
+范围：RDM 领域 store/迁移、项目/成员/权限/结论/慢通道台账、上传原件与导出清单；基座只补通用连接/生命周期公开契约。
+
+明确 RDM SQLite 与团队 PG 的适配和备份清单，避免一半事实在 PG、一半未受保护地留在本机文件。
+先验证单实例团队档；多实例的发号、执行所有权、缓存失效与故障恢复在独立验收前保持关闭。
+本次不复制基座在途 PG 档位和迁移能力，也不把基座 PR 完成当作 RDM 迁移完成。
+
+验证：真实 PG 的隔离/事务/重放、迁移前后对象与事件数及哈希对账、备份恢复含原件；PG 不可用不静默退回空 SQLite。
+完成条件：团队部署具备明确权威存储与恢复证据；若本批仅交付单实例 SQLite，验收报告必须声明该限制。
+
+---
+
+## Migration and Delivery
+
+历史归属先做只读盘点：未归属事件、缺少项目绑定、对象依赖闭包、旧快照和私人来源。
+现有 seq 区间迁移接口不能作为任意截取的安全保证；归属以完整对象及依赖闭包为单位校验，并保留批准映射和原因。
+不把存量自动分给首个项目，不根据当前 owner 猜历史创建者。
+
+迁移前保存备份和对账清单，在隔离副本上验证，再取得共享环境迁移授权。
+采用新增字段/投影、保留原事件、按项目启用；观察期内可关闭新页面和新读取投影，但不能恢复越权的全量读取入口。
+停止条件：发现跨项目泄漏、重放不一致、无法确定历史归属、投影滞后超出可解释范围或恢复失败；保留现场和失败证据。
+
+跨仓顺序为基座扩展申请→基座实现/测试/发布→RDM 升级固定版本→RDM 集成验证→Dev 文档与组合记录更新。
+必要令牌调整按 DESIGN.md 成对关联 UI 与 Dev 组合；仅消费令牌时不制造无关令牌 PR。
+
+在途核对（本次 Gitea API 只读，SELF；实施前须刷新）：Dev #325 为团队 PG 档与迁移组合，#317 为服务启动 DSN；RDM #194 为已合入 xlsx 工作的任务卡闭合，不能重复安排 xlsx 从零实现；Backend、Documents 查询未返回开放 PR。
+关联规划为 RDM 阶段总案 P3/MS3、U0 项目共享合同、V2.2 合规图方案和上述团队存储方案；本案补充集成/授权/显示，不声称这些里程碑已验收。
+
+---
+
+## Verification Contract
+
+以下为实施时的验收计划，本轮结果均 NOT_RUN；文档自检另以任务收据记录。
+
+| 组 | 覆盖需求 | 最小可复核场景 |
+|---|---|---|
+| 授权/隔离 | R1、R2、R10 | 六类角色×两个项目；列表、统计、详情、关系、历史、工具、导出、下载、订阅均验证；普通文档协作无误封 |
+| 数据完整性 | R3、R5、R6 | 跨项目提案和边拒绝；多事件中途失败；重试/并发；重启及指定 seq 深比较；完整快照哈希 |
+| 真实业务闭环 | R3–R6 | 项目创建→纪要入库→切片→需求→章节 v1→依据变化→v2→审签→历史回看→报告；缺失链节明确显示 |
+| 可用性 | R4、R7 | 创建者找依据/变更原因，管理员选项目，键盘/窄屏/长文本，加载/失败/受限状态，过期响应丢弃 |
+| 导出 | R8、R10 | 同一 cutoff UI/报告一致；创建与下载分别鉴权；撤权/受限来源/不完整记录不泄漏或冒充完整 |
+| 组合与运行 | R9 | 固定 Backend/Core/Frontend/UI/RDM SHA；RDM 测试与构建、Dev 适用组合检查；部署后二进制身份和真实浏览器路径 |
+| 团队档（U6另行立项时） | R1、R5、R6 | 真 PG、迁移与恢复；单实例和多实例证据分别记录，无变量或无环境即 NOT_RUN/SKIP |
+
+性能建议作为待批准目标：单项目 1 万对象/5 万关系、100 万事件的样本；首屏仅取分页摘要与当前树分支；普通分页查询 P95≤1s，首屏可操作≤2s。
+记录实际硬件、数据分布、过滤条件和组件版本，不能以空库或缓存命中替代容量结论。
+正式审核先重放最小集再读作者证据；来源标记遵循 GATE/REPLAY/SELF，用户界面演示与正式验收分开。
+
+---
+
+## Definition of Done
+
+本方案阶段完成条件：现状依据可定位、原有能力不重复建设、项目和角色边界明确、展示可理解、工作项与验收对应；r1 已于 2026-10-11 经用户评审通过（五阶段一并，含 KTD4 双层管理员裁定）。
+实现阶段完成条件：R1–R10 对应证据齐备，固定组合通过正式测试和独立审核，部署与浏览器验收有独立记录；源码存在不等于完成。
+
+已裁定决策：KTD4 采用双层管理员——基座 isAdmin 超管保底＋RDM 台账域管理员（session-settled: user-directed，2026-10-11）。剩余待定决策：RDM 宿主工作区入口的具体交付契约（U4 设计评审时固定）；U6 如需提前并入本批，应另行批准范围及目标环境，默认不包含。
+推荐先批准 U1 的细化设计与测试范围；U2–U5 按依赖逐阶段评审，U6 单独立项，不把本轮范围确认当作连续实施授权。
+
+后续再考虑跨项目引用审批、全局关系图、电子签名/外部防篡改存证及复杂图分析；这些不属于首个可用闭环。

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-auto-trigger.md

@@ -0,0 +1,48 @@
+---
+title: Generative UI auto-trigger opt-in design
+date: 2026-10-12
+type: feat
+revision: r1
+status: approved
+product_contract_source: generative-ui-r2-U6-U7-boundary
+---
+
+# Generative UI 自动触发 opt-in 设计（r1）
+
+依据：主记录 r2（语义事件 / 预算 / 防自激）；收口稿已知边界；用户 2026-10-12
+计划确认「边界三项全部做」并将本表定案作为实施基线。
+
+负责人：裁定 weichen（用户，经执行计划确认）；起草 Agent；更新时间 2026-10-12。
+
+## 定案表
+
+| 项 | 定案 |
+|---|---|
+| 开关 | owner 级 settings：`plugins.generative-ui.autoPresent`，默认 `false`；**不**写入 `plugin_activation`（避免 bump epoch） |
+| 前提 | `plugin_activation(generative-ui).enabled` 为真；否则 auto 无效 |
+| 事件 | 仅：任务阶段跃迁（plan/todo 状态变化）、材料/工件完成（material notice、document artifact） |
+| 禁止事件 | per-token / 每条 SSE、`surface.updated`、动作回执、present 成功路径 |
+| 动作 | 注入 system-reminder，**只**建议调用一次 `generative-ui.present`；不自动点 actions；不改写任务事实 |
+| 预算 | 每任务（conversation）每小时 ≤3 次；耗尽写审计 `genui.auto_present_exhausted` |
+| 冷却 | 同会话自动触发间隔 ≥60s |
+| UX | 复用 U6 pin/follow；固定后新页不抢占 |
+| 门槛 | 扩大范围仍以人类效率约 +20% 为后续条件；本增量只落地最小 opt-in |
+
+## 实施面
+
+- Backend：settings schema/defaults；`genui.Auto` 闸门；runmgr 语义钩子；审计。
+- Frontend：SettingsModal 经 schema 出开关（无需专用页）。
+- Documents：本提案 + 使用说明边界条目更新。
+
+## 验收线
+
+1. 默认关：无 reminder / 无额外 present 建议。
+2. 仅 activation∧opt-in 时，材料完成 / 阶段跃迁 / document 工件可触发。
+3. surface/action/present 路径不重入。
+4. 第 4 次/小时审计耗尽并停止。
+5. 冷却内跳过。
+
+## 裁定记录
+
+用户经「Implement the plan」确认本定案表；本文 `status: approved`，实施任务
+`feature/genui-auto-trigger-optin` 按本表交付。

docs/proposals/2026-10-12-generative-ui-bclass-help-intent.md

@@ -0,0 +1,59 @@
+---
+title: Generative UI B-class whitelist — builtin.help and system.intent
+date: 2026-10-12
+type: feat
+revision: r1
+status: approved
+product_contract_source: generative-ui-u5-action-scope-r2
+---
+
+# Generative UI B 类加白提案：builtin.help / system.intent
+
+依据：[U5 动作范围 r2](./2026-10-11-generative-ui-u5-action-scope.md)「每加一条走独立评审」。
+本提案对两条命令分别裁定；实施与本提案同批合入。
+
+负责人：裁定 weichen（用户）；起草 Agent；更新时间 2026-10-12。
+
+## 授权
+
+用户 2026-10-12 计划确认：边界三项全部推进；B 类首批加白 `builtin.help` 与
+`system.intent`。交付模式：authorized-continuous（本增量实施至 Dev 合入）。
+
+## 一、builtin.help（独立裁定）
+
+| 项 | 内容 |
+|---|---|
+| 命令 id / action id | `builtin.help` |
+| 类 | B（白名单命令绑定） |
+| 危险级 | 低（只读说明，无写副作用） |
+| 参数 | 无必填 |
+| 通道 | `POST /api/surfaces/{id}/actions` → cmdbus Entrance=`button` |
+| 用途 | 页面按钮展示可用命令/入口说明 |
+| 排除项对照 | 非业务写、非跨会话、非自动触发动作、非 MCP |
+
+**裁定**：同意加白。
+
+## 二、system.intent（独立裁定）
+
+| 项 | 内容 |
+|---|---|
+| 命令 id / action id | `system.intent` |
+| 类 | B（白名单命令绑定） |
+| 危险级 | 入口本身低；**命中后嵌套分发可触达写命令**（既有 chat 行为） |
+| 参数 | `text`（string，必填） |
+| 通道 | 同上 Entrance=`button` |
+| 硬化（加白前提） | **button 入口只返回 match / candidates，禁止嵌套 `Dispatch` 目标命令**；chat/slash/api 等既有入口行为不变 |
+| 用途 | 页面上做意图探测/候选展示，不经按钮偷渡 D 类写 |
+| 排除项对照 | 嵌套业务写在 button 路径关闭；仍禁止自动触发动作、MCP、任意命令全开 |
+
+**裁定**：同意加白，前提硬化生效并有红测。
+
+## 三、实施面
+
+- Backend：`surfacesvc.AllowedActions`；`genui.ValidateActionIDs` / Catalog；`handleSystemIntent` button 只读。
+- Documents：本提案 + 使用说明 API/动作表白名单更新。
+- 红测：白名单外拒绝；help 可分发；intent button 命中写意图零副作用；chat 仍可嵌套。
+
+## 四、明确不做
+
+D 类业务写直执、扩大白名单至其他内置写命令、自动触发动作、动作结果自动改写页面。

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

@@ -0,0 +1,104 @@
+---
+title: Generative UI usage guide and U1-U6 evaluation record
+date: 2026-10-12
+type: feat
+revision: r1
+status: final
+product_contract_source: generative-ui-r2
+---
+
+# Generative UI 使用说明与 U1–U6 评测记录
+
+本文是主记录 r2（2026-10-10-generative-ui-plugin.md）的配套文档：面向使用者的启用/使用/
+禁用说明，以及 U1–U6 各增量落地后的组合评测结论。状态：**final**（方向收口稿）。
+
+## 一、使用说明（dev 实例实测口径，2026-10-12）
+
+### 启用与禁用（owner 级）
+
+```bash
+# 启用（需 API key；服务以 --auth on 运行）
+curl -X POST http://<host>/api/plugins/generative-ui/activation \
+  -H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
+  -d '{"enabled":true}'
+# 禁用（新页面/新动作/迟到提交全部拒绝；历史页面保留只读）
+curl -X POST ... -d '{"enabled":false}'
+```
+
+- 启用后 `generative-ui.present` 工具对模型可见（禁用时工具不注入）。
+- 禁用即时生效：进行中的提交按 epoch 失配被拒，已保存页面按权限保留。
+
+### 生成与修订页面（对话内）
+
+对话中说「把 X 整理成一页对比 / 报告页 / 时间线」——模型调用 present 提交声明式页面：
+- 页面自动在**文件预览区**打开；修订时说「改为按 Y 组织」，模型带 surfaceId+baseRevision 重提。
+- 表单页可直接填写并点「提交」按钮（数据落插件台账，走命令总线审计）。
+
+### 任务工作区（U6）
+
+- **工作**入口的当前任务卡下方出现「任务页面」紧凑区：默认显示最新一页；📌 固定后
+  新页面不抢占；↗ 跳转文件预览全屏。
+- 项目级跨会话聚合：`GET /api/projects/{id}/surfaces`（owner 作用域）。
+
+### API 速查
+
+| 端点 | 说明 |
+|---|---|
+| POST /api/plugins/{id}/activation | 启禁（epoch 递增） |
+| POST /api/surfaces | 提交页面（直接 API，与插件同咽喉） |
+| GET /api/surfaces/{id} | 读取整页快照（禁用后仍可读） |
+| GET /api/conversations/{id}/surfaces | 会话内页面列表 |
+| GET /api/projects/{id}/surfaces | 项目级跨会话聚合（U6） |
+| POST /api/surfaces/{id}/actions | 页面动作（白名单：generative-ui.submit、builtin.help、system.intent；后者 button 只读匹配） |
+
+## 二、U1–U6 落地与评测结论
+
+| 增量 | 交付 | 关键证据 | 结论 |
+|---|---|---|---|
+| U1 受控试验 | Documents #62（r2） | R1 分化 6/6；文本通道下界 60%/83%；工具通道探针消除语法类失败；M3 ¥0.067/页；highspeed 否决为生成档 | 方向成立，生成走工具参数通道 |
+| U2 契约/启禁/持久化 | Core #25/#26、Backend #143/#146、Dev #336 | 修订 1→2 冲突守卫、epoch 语义、事件恢复、SQLite/PG 双档 | 宿主地基就位 |
+| U3 插件与上下文闭环 | Backend #149、Dev #345 | 真实模型回放 PASS（≈¥0.08）；禁用不注入工具；语义投影回灌 | 模型可提交、可修订 |
+| U4 只读渲染与恢复 | Core #27/#28、UI #42–#45、Frontend #53、Dev #351 | 刷新恢复、revision 守卫、SurfaceView | 页面用户可见 |
+| U5 动作闭环 | Backend #155、UI #46/#47、Frontend #56、Dev #367 | 幂等同参回放/异参拒绝、DangerHigh 经确认卡不可伪造、草稿只在动作载荷 | 表单可提交且受控 |
+| U6 工作区与项目聚合 | Backend #163、Frontend #62、Dev #408 | owner 隔离/跨 owner 零可见/禁用保留；pin 固定不抢占 | 页面进工作视图 |
+
+### 现场体验驱动的修复（2026-10-11–12）
+
+用户实测反馈「页面未出现 + 同名工件 ×3」→ 三个根因逐一修复（Backend #156/#160、
+Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」引导、事件分支缺
+右栏切换、children 对象形状偏差、面板同名并列。修复后 E2E：真实模型 present 成功
+（rev 1），surfaces 表落库，前后对照成立。
+
+### U7 组合验收（2026-10-12，dev@b634a27，真实 MiniMax-M3）
+
+- 会话内：新指令「实施进度页」→ 模型自主 present（steps 步骤条、三阶段、状态正确），
+  会话 surfaces = 2（对比页 rev1 + 进度页 rev1），修订链完整。
+- 项目聚合：GET /api/projects/{id}/surfaces 返回跨会话页面（owner 作用域验证）。
+- 工作区：前端「任务页面」容器显示最新页（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；设计见
+  `2026-10-12-generative-ui-auto-trigger.md`。
+- B 类命令：已加白 `builtin.help` / `system.intent`（button 入口 intent 只读匹配、
+  不嵌套分发；提案 `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。
+
+## 三、结论
+
+Generative UI 方向按主记录 r2 的 U1–U7 全部增量落地：调研→契约→生成插件→只读渲染→
+动作闭环→工作区→组合验收，每个增量独立走组件 PR + Dev 组合 CI + 任务闭环，真实模型
+证据贯穿（试验、回放、现场 E2E）。方案收口为 final；后续按「已知边界」清单演进。

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

@@ -0,0 +1,383 @@
+---
+title: 服务重启与全量数据恢复方案
+type: fix
+date: 2026-10-12
+artifact_contract: ce-unified-plan/v1
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# 服务重启与全量数据恢复方案 r3
+
+确认状态：原 r2 批准记录保留（Dev PROJECT.md 记录 2026-10-12 五阶段批准）；**r3 本轮增补待人工评审**。本轮仅调查、修订方案及本地文档核查，不代签历史批准，不授权业务实施、账户变更、迁移、故障注入、部署、推送或合入。
+修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。
+r3＝同日根据 dev 8788 账户故障续查刷新源码／运行事实，保留 R1–R10、KTD1–KTD12、U1–U7；补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值，未宣称实测达标。
+r3.1＝同日增补 D1/D2/D3（部署根治；编号避开本案 U1–U8）。映射：D1 补 U1 身份消费缺口，D2 补 U6 部署回退，D3 补 U7 真实组合门禁。确认状态：用户 2026-10-12 授权按实施计划连续推进到 PR 可合入；本节新增条款仍供人工评审，不代签 r3 其余未批内容。
+需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。
+主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
+
+## 1. 目标与成功边界
+
+**目标：系统停止后再次启动，用户仍能访问原有数据和服务，未完成工作进入可继续或可处理的确定状态。**
+
+采用“稳定实例配置与身份、依赖编排、进程监管、持久恢复账本、一致性文件发布、组合备份与实测验收”的方案。复用现有 PostgreSQL/SQLite、运行表、事件、命令、通知和恢复隔离机制，补齐实际接线与崩溃窗口。首期落实单机完整恢复；多实例所有权沿用已有协作存储方向，不重新设计一套集群平台。
+
+必须区分三类恢复：
+
+| 故障档 | 需要达到的结果 | 数据与时间合同 |
+|---|---|---|
+| `svc stop/start/restart`、进程 SIGTERM/SIGKILL、应用 OOM | 原配置启动；持久数据完整；安全任务继续；未知副作用隔离 | 存储正常、确认结果已持久化的前提下，RPO=0；建议冷启动至业务就绪≤60秒 |
+| 主机重启、操作系统崩溃或断电，磁盘仍可用 | 数据库 WAL 恢复、文件一致性恢复、服务按既定意图启动 | 只有 DB 与文件落盘策略、底层存储满足耐久性且实测后，才承诺已确认数据 RPO=0；建议 RTO≤5分钟 |
+| 数据盘损坏、主机丢失、误删或不可逆污染 | 在新目标恢复匹配的 DB、文件、配置和版本 | 沿用协作存储案建议 RPO≤5分钟、RTO≤60分钟；如要求此档 RPO=0，另行批准跨故障域同步复制 |
+
+以上时间为**待批准的验收目标**，不是已测性能。大规模扫描与冷索引重建不要求全部在60秒内完成：必需数据对账及安全恢复决策完成后可开放API，派生索引按明确降级合同后台重建。故障超出资源预算时报告阻塞及原因，不能以假就绪满足时间指标。
+
+恢复保存的是持久业务状态、步骤和已确认结果。进程内 goroutine、模型连接及未持久化 token 不可原样复活；模型回合从持久上下文和步骤边界重建。已经接受的用户消息、排队任务、审批和取消意图必须先落库再返回接受；尚未确认的结果不能事后冒充成功。
+
+## 2. 当前事实及重点差距
+
+本轮源码基线：权威 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 是启动时点，本轮仅同步权威上游，未推进本轮草案组合或重复实现该修复。
+
+| 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
+|---|---|---|
+| 数据库绑定与身份 | 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 temp+rename、SQLite 一致性快照、pg_dump 已存在；Native 转录 Write→Sync；manifest 有原子同步链 | 工件原文先覆写再更新 DB，无不可变版本；agent 快照缺权威 manifest，PG 和文件快照不是同一恢复点 |
+| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接；数据库事务可排队 | 无跨进程活动服务独占；恢复扫描全部开放 run，第二个服务可打断第一服务；不具备 PG 的会话执行租约 |
+
+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与版本分开提交”“通知仅内存”等问题已有源码改进，本案只验证并复用这些基础，不把旧缺陷重新列成新建设。
+
+## 3. 需求合同
+
+| ID | 范围 | 要求与可判定验收 |
+|---|---|---|
+| R1 | 服务 | 启动显式服务组时，全部已启用的必需服务按依赖就绪；可选失败明确降级；主动停止不被监管误拉起 |
+| R2 | 身份 | 连续裸启停、更换端口/程序/cwd后，DB identity、数据/工件/工作区根、实例ID、认证及插件组合一致；缺配置拒绝启动 |
+| R3 | 已确认数据 | 消息、项目、成员/权限、文档、设置、插件启用/授权、任务、审批、事件、工件原文与版本在RPO=0档零遗漏；灾难档完整恢复批准恢复点内数据，并对账/报告恢复点后的缺失和外部效果 |
+| R4 | 任务 | 已接受排队任务不丢；安全任务从持久步骤继续；HITL保留稳定gate与答案；取消意图在重启/换owner后仍生效 |
+| R5 | 副作用 | started但无确定result的外部动作自动隔离；已确认动作不重做；恢复与发布验证当前权限和执行代次 |
+| R6 | 所有权 | 单一有效写者；旧进程迟到写状态/事件/工件被拒；过期额度回收；恢复本身可重复且可再次中断 |
+| R7 | 文件与派生状态 | DB引用的文件内容、版本和hash一致；损坏现场保留并报告；缓存/检索索引可从权威源重建 |
+| R8 | 停机与就绪 | 停机先拒绝新工作再排空；全部worker、sidecar和工具子进程收口；错误不跳过后续清理；ready反映业务可用 |
+| R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同；备份恢复到新目标并完成业务/权限/文件对账；不在普通启动覆盖现库 |
+| R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 |
+| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时；直接二进制、路径别名和 legacy 入口同样受保护；账户短事务 CLI 不启动第二运行时；测试实例使用独立根 |
+| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略；文件和目录同步覆盖权威对象；DB/文件持久失败不能确认成功；未实测的断电 RPO 保持候选 |
+
+覆盖“所有数据”需要先完成数据归属清单：除Backend业务表，还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性；无法证明可恢复的必需插件阻塞全系统签收，不能只恢复Backend便宣称全部完成。
+
+## 4. 技术决策与服务结构
+
+KTD1. **持久配置是启动权威，PID只是观察。** 每实例保存完整类型化manifest：service/instance ID、配置revision、desired state、服务类型与管理权、依赖、固定程序/插件/资产摘要、DB identity与凭据引用、数据/工作区/工件根、认证、监听、必需/可选属性、恢复政策。临时环境只作显式覆盖；必需字段必须能从持久值或稳定受保护引用重新解析。机密放受保护文件/秘密服务，manifest仅存引用，不把密码或DSN写进日志。
+
+KTD2. **配置整份提交，覆盖按字段合并。** 每实例和服务组串行化生命周期操作，配置以revision做CAS；候选完整解析与校验后，临时文件落盘、原子替换、目录同步。legacy迁移同样一次提交，故障留下旧版或完整新版。更改端口不隐式更改data；数据根迁移是独立操作。恢复启动发现预期DB/marker/目录丢失时阻塞，初次初始化需要明确入口，禁止新建空库掩盖数据丢失。
+
+KTD3. **svc控制期望状态，唯一supervisor管理进程。** Linux部署推荐systemd；svc兼容既有单服务入口，增加显式stack/group控制。每服务仅一个监管者，不能nohup watcher与systemd同时拉起。分发仓已有模板要接入同一manifest合同。外部/共享PG、Redis仅探测连接，不擅自启停；managed-local只管理身份已核实且归该服务组独占的资源。pgvector是PG扩展，不另造守护进程；Redis只有配置并启用时才进入依赖图。
+
+KTD4. **主动停止与异常退出分开。** stop先提交desired=stopped，再关闭服务；普通故障仅desired=running可重启。restart保留最终running意图并记录operation_id、执行阶段和恢复政策，不能因中途stop留下stopped。监管采用有界退避、重试预算与失败阻塞；错误配置不能无限重启。开机只恢复已登记且策略允许的服务。intent、operation、actual state必须分开，不能以pidfile存在视为运行。
+
+KTD5. **团队业务权威沿用PG，个人档沿用SQLite。** 团队PG失败保持未就绪，绝不切SQLite。普通重启让既有数据库完成自身WAL恢复，不导入备份。验证数据库identity/schema/权限和关键记录；SQLite恢复到预期文件并检查完整性，不能只看文件存在。断电承诺要求明确DB同步设置及底层存储合同，不把rename原子性当作落盘保证。依据：[PostgreSQL耐久性](https://www.postgresql.org/docs/current/wal-reliability.html)、[SQLite WAL](https://www.sqlite.org/wal.html)。
+
+KTD6. **恢复扫描与恢复执行分离。** 装配Store、权限、插件/工具、工作区、预算、Workflow、命令消费者与事件投递之后，才分类认领恢复任务。扫描失败或归属未知进入blocked/hold；不能吞掉错误直接ready。恢复有持久cursor/attempt和CAS，支持分批、失败重试及再次重启；禁止全库无归属盲扫并续跑其他实例的任务。
+
+KTD7. **持久执行账本统一主run、子run和后台任务。** 保持稳定logical_run_id、request_id、parent关系；每次执行用新的attempt/boot/epoch。步骤记录输入引用、已提交输出、等待原因、调度位置、恢复决策；完成记录与业务结果原子提交。现有文件修改checkpoint不是完整执行checkpoint，不能直接拿它宣称主对话/工作流可续跑。后台任务表目前仅状态登记；只恢复明确有executor的类型，其他类型进入可见unsupported/blocked，补适配后验收。
+
+KTD8. **副作用先登记，结果未知先对账。** 复用Native `runtime/session/intent.go`和生产接线`internal/runtime/llm_direct.go:245–301`，以同一call/operation ID关联现有intent/result与Backend的run/owner/epoch/hold，不能让两个恢复器各自决定重放。DB账本裁决执行和hold，转录保存完整上下文及结果投影；本地个人档同样须有持久裁决。调用外部工具前持久化operation_id、参数摘要/安全引用、授权与gate、owner/epoch、幂等类别及started；确定结果写result/receipt。启动遇到started无确定result自动hold，不能只把“副作用未知”写成普通工具错误后允许模型继续发起动作。
+
+目标支持可靠幂等键时按同一key重试；非幂等动作必须取得确定未执行的终态证据，并证明旧执行者及已发请求都不会再产生效果，才允许重试。“暂未查到结果”“取消请求已发送”“本地进程已退出”均不充分。否则保持hold。shell、代码执行、Git、数据库/远端写入默认按不透明副作用处理。模型/工具因失权立即取消；无法围栏的外部动作进入hold，不能靠租约到期证明旧动作停止。
+
+KTD9. **所有工作入口共用执行所有权与额度。** 前台、notice、子代理恢复、命令消费者均经过持久claim。稳定instance_id与每次boot_id分开；续租持续进行，丢租停止执行；CAS/事务围栏覆盖状态、事件、步骤、工件发布和副作用准入。execution与admission lease关联run/attempt/epoch；恢复终态和已证明失效的许可，禁止一启动就清空全库锁。父任务等待HITL/子任务让出执行额度；持久队列及跨实例等待者有有界唤醒机制。
+
+KTD10. **命令、通知和投影处理后确认。** 命令 pending→claimed(带租约)→applied/rejected，超时claim可重领；取消先从run解析已授权conversation，按逻辑run转交当前owner；HITL验证gate/version与当前权限。notice_id/旧子run的恢复claim、对应新run、消息和销项以事务与唯一约束关联，文件resumed标记仅作投影。outbox成功才ACK，失败保持pending；分批持续drain，不受单次100条限制。
+
+KTD11. **不可变对象加DB发布记录保持文件一致性。** 写新版本对象、完成必要fsync/hash校验后，在事务中发布引用与版本；失败留下可辨认未发布对象，不直接覆盖已发布版本。工作区变更另用既有overlay/CAS与副作用账本核对，不能把可变工作区伪装为不可变对象。checkpoint/JSONL尾部截断须保存原件、识别未确认尾部，已确认部分校验失败阻塞。工件缺失报告损坏，不静默返回空内容。孤立对象按清单、引用、保留期与备份需求回收。
+
+KTD12. **业务readiness与恢复摘要分开。** liveness仅证明进程存活；readiness包含身份/认证、DB/schema、必需目录与插件、恢复决策完成和worker接线。已隔离且不影响其他会话的hold可允许API就绪，并暴露计数与处理入口；损坏权威数据或必需依赖失败不能ready。详细恢复状态只向有权owner/admin开放；公共健康响应不泄漏路径、任务ID、凭据或业务内容。
+
+服务依赖结构（实线为必需；可选项以实例manifest为准）：
+
+```mermaid
+flowchart TB
+  M[持久实例manifest与启动意图] --> S[svc控制入口]
+  S --> P[唯一进程监管者]
+  P --> D[受管PG或SQLite数据]
+  P --> A[应用与恢复协调]
+  X[外部PG或可选Redis：仅探测] --> A
+  D --> A
+  F[持久文件与插件组合] --> A
+  A --> W[任务/命令/通知/投影workers]
+  A --> H[业务readiness]
+  H --> U[Web或下游业务入口]
+```
+
+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 启动和优雅停止
+
+```mermaid
+sequenceDiagram
+  participant C as svc/监管者
+  participant A as 应用生命周期
+  participant D as 持久存储
+  participant W as workers与子进程
+  C->>D: 校验manifest、数据身份与操作锁
+  C->>C: 启动归本组管理的依赖并探测
+  C->>A: 启动固定版本
+  A->>A: SQLite取得活动服务锁；PG按既有执行所有权合同
+  A->>D: 校验schema、文件与恢复候选
+  A->>W: 完成插件/权限/预算/工作区全部装配
+  A->>D: 分类认领、对账未知效果、恢复命令与额度
+  A->>W: 开放安全恢复执行
+  A-->>C: readiness与恢复摘要
+  C->>A: 停止请求
+  A->>A: readiness=false；拒绝新写和新任务
+  A->>W: 停止领取、取消或保存安全边界
+  W-->>A: bounded join与子进程结果
+  A->>D: 持久化恢复意图、flush、收口许可/所有权
+  A->>D: 关闭存储
+  A->>A: 释放本进程SQLite活动服务锁
+  A-->>C: 停机结果（含未完成原因）
+  C->>C: 复核进程组消失；逆序停止独占依赖
+```
+
+停机预算建议应用30秒、监管60秒，必须按最长合法步骤与故障实测调整；SSE连接主动结束，不能占满排空预算。某阶段出错继续运行后续可安全清理，保留聚合结果。工具无法停止或副作用未定时先持久hold并保留现场；强制结束后必须走崩溃恢复路径，不返回“已优雅停止”。
+
+### 5.2 不同工作的恢复策略
+
+| 停机前状态 | 重启处理 | 自动执行边界 |
+|---|---|---|
+| 已完成/失败/明确取消 | 原样加载结果及原因 | 不重新执行 |
+| 已接受但未开始 | 按持久队列、权限和预算重新调度 | 条件满足后自动 |
+| 纯读、可重建的计算 | 从已提交步骤边界继续 | 不重复已提交业务结果；模型回合可重新生成 |
+| 正在执行幂等副作用 | 根据operation_id、目标查询/幂等合同核对 | 确认安全后继续 |
+| 非幂等副作用结果未知 | 自动hold，展示原因和可核对证据 | 有权人对账具体operation；确认完成则记录receipt并检查剩余步骤；确认未执行须满足KTD8终态与旧请求隔离条件；可明确放弃整项任务；禁止直接“放行即重跑” |
+| 等待HITL | 恢复稳定gate/version及持久答案 | 未回答继续等待；已回答幂等消费；撤权/版本变化拒绝并说明 |
+| 子代理/后台notice | DB唯一恢复claim关联旧、新attempt | 不由文件标记决定唯一性，不重复派生/投递 |
+| 索引与缓存 | 从文档/内容权威源重新排队，记录索引generation | Redis可清空重建；恢复模型/维度/版本一致性后发布索引 |
+| 未配置executor、缺文件或未知归属 | 保持blocked并提供处理原因 | 不丢行、不假完成、不盲续跑 |
+
+```mermaid
+stateDiagram-v2
+  [*] --> pending
+  pending --> running: 获得有效owner/预算
+  running --> waiting_hitl: 持久gate
+  waiting_hitl --> running: 当前权限下消费答案
+  running --> completed: 结果与状态原子提交
+  running --> recovering: 停机或失联
+  waiting_hitl --> recovering: 执行者重启
+  recovering --> pending: 核对可安全继续
+  recovering --> waiting_hitl: 恢复原等待
+  recovering --> hold: 副作用未知/权威数据不完整
+  hold --> pending: 有权人对账确认安全
+  hold --> recovering: operation对账结果与receipt已持久化
+  recovering --> completed: 全部必要步骤与业务结果已确认完成
+  hold --> cancelled: 明确放弃
+```
+
+`recovering/hold`在这里是目标业务语义，**不是声称现有Core枚举已支持**。过渡可用恢复账本表达；若新增公开状态，Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留，不强改成成功。
+
+用户侧复用现有任务状态、对话卡和系统管理区，显示恢复原因、进度和动作。当前只有管理员恢复 API 基础，Frontend 对账接线待 U4 实施，不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件，刷新重载权威快照；断连不推断完成。实施界面先读 DESIGN.md，遵守令牌、Collapsible和单异步状态所有者。
+
+## 6. 全量数据与组合备份
+
+| 数据类别 | 权威与恢复方法 | 必须对账 |
+|---|---|---|
+| 用户、项目、成员/权限、会话/消息、文档/版本、卡片/Surface、设置、插件授权 | PG团队库或个人SQLite；包含全部已启用插件/下游的自有存储 | 主键、owner、权限、版本、关键内容摘要；禁止以空库替代 |
+| run/step/命令/通知/审批/取消/额度/恢复hold | 持久账本与状态事务 | 链接、唯一请求、gate版本、owner/epoch、队列位置与外部receipt |
+| 上传、工件、文档大内容、输入附件、转录、派生请求 | 持久对象/文件目录，与DB清单匹配 | 内容hash、尺寸、引用版本、权限与可读性 |
+| 执行工作区、overlay/checkpoint、任务Git现场 | 受管workspace与副作用记录 | 实际修改、基准SHA、未提交文件、执行者退出与恢复边界 |
+| 程序、Web资产、插件版本、实例配置、秘密引用/密钥 | 不可变组合manifest；受限配置/秘密备份 | 摘要、schema兼容、插件签名/授权、恢复凭据可用且未泄漏 |
+| 检索/向量索引、Redis缓存、临时PID/连接 | 从权威数据重建；PID按新boot重新观察 | 模型/维度/generation；不作为任务成功、审批或永久幂等权威 |
+
+普通启停不从备份还原；数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行，禁止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、工件下载和插件业务链；恢复时间从故障触发开始计时。
+
+部署先构建并检查完整候选目录，再切固定组合；失败仅在schema/插件/配置向后兼容时回退程序。数据回退须对账回退点后已接受业务和外部效果，不能“恢复旧库”而静默丢失新写入。
+
+## 7. 实施增量与依赖
+
+以下U-ID属于本案，与协作存储案的同名U-ID独立。每个增量完成设计细化、自检、正式验收与Review后按policy/delivery.md人工评审；本次不授权实施。新增文件名是建议，最终按实际模块边界落位。
+
+### 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均正确拒绝/报告；不得停止其他服务组的共享依赖。
+
+### U3. 应用启动、停机与真实就绪
+
+对应R1/R8/R10；依赖U1，可与U2并行。范围：`modules/backend/internal/app/app.go`、`runmgr/runmgr.go`、`runmgr/events.go`、`plugins/host_v2.go`、server健康接口及其生命周期测试。
+统一lifecycle context、准入开关、消费者停止与worker join；恢复执行移到装配结束；不同停机原因统一条件结算；sidecar受监督并纳入收口；readiness、恢复摘要和受限诊断按KTD12实现。停机预算属预算来源变更：现状HTTP停机超时仅5秒且超时即返回、跳过后续事件清冲（app.go停机序列，SELF源码核验）；“应用30秒/监管60秒”须显式替换该常量并按最长合法步骤与故障实测校准，不得沿用旧值。
+验收：插件/预算/Workflow未装好不启动恢复任务；停机同时提交新run被拒；SSE与慢工具不跳过flush/清理；子run不被cancelled覆盖；sidecar崩溃可检测；DB坏/恢复扫描失败不ready；hold不影响无关会话的正常读写。
+
+### U4. 持久任务恢复与副作用隔离
+
+对应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. 所有权、额度、命令、通知与投影闭环
+
+对应R4/R5/R6/R10；依赖U3；与U4共同验收。范围：`store/execution.go`、`store/admission.go`、`runmgr/admission.go`、`runmgr/commands.go`、server取消/HITL、notice、surfacesvc与PG集成/多进程故障测试。
+续租及失权取消覆盖全部入口；持久队列/额度对账与共享唤醒；命令lease+处理后ACK；notice事务消费；Surface成功后ACK且持续批量drain。租约到期后的外部不确定行为仍进入U4 hold。
+验收：占满额度kill后新工作可前进；长run跨租期不失权；旧owner晚到状态/事件/工件被拒；claim后kill命令可重领；取消正确解析conversation并不越权；HITL答案一次生效；notice及子代理并发恢复只建一个后继；超过100条投影事件全部处理，发送失败不清pending。两真实进程与真实PG是必要证据。
+
+### U6. 文件发布、组合备份与部署回退
+
+对应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. 故障验收与交付放行
+
+对应全部需求；依赖U1–U6。范围：Dev新增隔离`tests/integration/recovery/`、故障注入控制点、运行手册与需求证据表。
+固定Dev/全部组件、运行制品与配置摘要；使用脱敏数据、独立端口/PG库/文件根及工具目标；记录故障点和恢复统计。先执行小规模逐点故障，再在批准规模混合运行。破坏性kill/断电测试只能在隔离环境实施。
+验收：第8节每类故障均有可重放证据；RPO=0档已确认数据零遗漏，灾难档恢复点差距≤批准RPO且点内数据零遗漏、点后缺失和外部效果明确对账；零未识别重复副作用、零越权/双有效写者；时间满足批准指标；用户实际刷新、重连、登录、任务/HITL、文档和工件链通过。服务恢复与数据/任务恢复分别签收。
+
+建议交付批次：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 |
+| PID复用、重复启动、旧进程冻结后复活 | 不误杀其他进程；一个有效owner；旧epoch无发布/副作用权限 | R1/R5/R6 |
+| 排队、HITL、跨实例取消、子代理/notice恢复中途kill | 接受意图不丢；审批一次生效；后继run/消息不重复 | R4/R5/R6 |
+| 外部效果完成而结果未落库、旧请求延迟完成 | 自动hold、有receipt对账和权限检查；暂未发现结果不触发非幂等重试；动作结算后继续未完成步骤 | R4/R5 |
+| 文件rename/发布边界kill、磁盘满、文件/日志截断 | 不确认未耐久结果；原发布版本一致；损坏可定位、原件保留 | R3/R7 |
+| 插件sidecar退出、插件存储缺失、索引重建失败 | 必需失败不ready；可选明确降级；数据与授权保留 | R1/R3/R7/R8 |
+| SSE断开/页面刷新、>100待投影、投递持续失败 | cursor补齐持久事件；旧事件丢弃；失败记录不被ACK | R4/R7/R10 |
+| 主机重启/断电 | 原数据盘恢复、全部期望服务重新就绪、耐久性指标有真实证据 | R1/R3/R7/R8 |
+| 完整备份在新目标恢复、旧实例复活、升级失败/回退 | DB+文件+秘密/版本匹配；旧写路径隔离；恢复点后外部效果对账；灾难档满足批准RPO；权限与业务链可用；回退兼容且不静默丢新写入 | R3/R5/R6/R9/R10 |
+
+验证分层：svc治理桩回归→Backend单元/SQLite→真实PG及多进程→真实工具替身故障链→少量真实模型→真实浏览器与主机级故障→灾难恢复。每层证明不同合同，不相互替代。
+
+执行时使用项目已有`make test-governance`、`make test-backend-pg`、`make test`、`make build`并增加受管隔离recovery入口。真实PG/Redis/模型/主机测试缺环境时必须明确NOT_RUN或SKIP及缺项，禁止把零用例或条件跳过当通过。按AGENTS要求验收/请求审核/合入前分别task-sync；所有precheck、同步、测试原始输出通过make evidence进入任务卡，并区分SELF/REPLAY/GATE。业务行为面的真实模型验证遵循policy/delivery.md，单测不替代。
+
+本轮只进行源码与文档检查，业务/数据库身份查询、故障注入、模型试验、迁移、服务启停、部署均NOT_RUN。方案r2不能作为恢复能力验收结论。
+
+## 9. 兼容、在途任务与批准事项
+
+本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。
+
+原 r2 的 svc-autorecover 二选一属于历史启动现场；当前 recover/watchdog 和 U1 身份已有源码，不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管／RDM UI／端口回收任务，避免重复修改入口。RDM／插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。
+
+备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
+
+实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。
+
+下一任务建议为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
+
+## 10. 全系统完成条件
+
+只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
+
+本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+
+## 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,245 @@
+---
+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 方案 r2
+
+确认状态：**r1 原批准保留；r2 本轮增补待人工评审**。r1 的批准记录为 2026-10-12 用户「批准，继续推进」（五阶段及 U1/U4 规格，允许对应实施和 PR）。本轮用户要求仔细调研、详细方案并「继续」，覆盖方案修订及本地文档准备，不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。
+修订记录：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。新增内容未批准；不以原批准记录代签新增范围。
+需求来源：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. 风险与未授权范围
+
+- 实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
+- 本轮交付终点：r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录；以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准，不推进 Dev gitlink、不推送／建 PR；启动／同步工具的任务元数据提交单独记录。
+- 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
+
+## 10. 规划进展与下一步
+
+- r1 已批准；U1/U4 基础实现存在于当前固定源码，完整浏览器／故障／运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
+- 首选下一任务（待授权）：恢复方案 U8 的 SQLite 服务隔离＋本案 U7 账户一致性；先消除共享测试数据和不可归因密码变化，再落实 U5。U2/U3 保持后续。
+- 前置：审核新增 R13–R15、U7/U8 及 U5 更新，明确实现和隔离测试范围／owner；实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区；正式组合、gitlink 推进与运行验收未执行。

docs/proposals/INDEX.md

@@ -6,12 +6,28 @@
 
 ## 先看哪一份
 
+- [快慢通道展示与动态工作摘要方案 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) 保留为过程权威。
+
+U5 已实施合入（动作闭环，Dev #367）；[U5 动作范围提案 r2](2026-10-11-generative-ui-u5-action-scope.md) 为已批准范围。U6 经用户 2026-10-11 裁定：待 owner 实际体验 U1–U5 产物（人类可用性对照的执行方式）后再定启动。
+r2 U5 条款要求先评审动作范围；本文给出 A/B/C/D 分类、审批挂接（复用既有 DangerHigh 确认卡与
+幂等）、排除项与验收线，待三点裁定后 U5 实施另行开任务。
+
+新增方向（已裁定取舍；U1 试验完成，r2 含结果与修订）：[Generative UI 调研与插件方案 r2](2026-10-10-generative-ui-plugin.md)。
+首试点为对话内完整分析页，交付采用可信编译插件；U1 试验限 MiniMax M3 + M2.7-highspeed、合成或脱敏材料、费用上限 ¥200，作为独立任务另行评审启动。
+此记录独立于下方历史核验快照，不改写历史方案/PR 数量或验收结论。
+
 | 要回答的问题 | 主记录导航 | 规划中的阶段 | 原文负责人 |
 |---|---|---|---|
 | 通用系统的原始边界与架构是什么 | [系统骨架](2026-09-29-system-skeleton-design-and-plan.md)，结合下表专题修订 | 骨架 P0–P5；D1–D16 | weichen |
 | 基座与下游如何分工，如何申请扩展 | [基座路线图](2026-10-01-base-extension-roadmap.md)，配套插件契约与兼容规则 | 公开扩展面、插件 v2、质量回路、工程基座 | weichen |
 | 三个智能体库如何继续演进 | [Agent 栈总案](2026-10-02-agent-stack-completion.md)，阶段细化见 N1/Q1/I1、N2、N3、Q2/Q3 | R0/R1/D1、N1–N3、Q1–Q3、I1–I2、阶段评测 | weichen |
 | RDM 下游的大目标和消费者里程碑是什么 | [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) | P0–P4，对应 MS0'、MS1–MS4及发布前置 | weichen |
+| 10–100 人协作与未来分布式如何演进 | [协作存储与分布式方案](2026-10-11-collaboration-storage-and-distribution.md) | 团队 PG 档 → 迁移恢复 → 多实例执行与故障验收；r1 已批准（2026-10-11），实施自 U1+U2 启动 | 需求：weichen；实施/运维待指定 |
 
 以上是依据文内显式范围和引用形成的阅读入口，不是新增优先级或批准结论。N2 阶段案未单列 owner，
 应由负责人补齐；不能仅凭任务创建人推断全部规划的负责人。
@@ -77,7 +93,7 @@ Dev 链接均指向对应任务 PR，可从其任务卡继续追溯组件 PR；
 | [智能体工作流质量改进](2026-10-09-agent-quality-improvement-plan.md) | 直连主路径质量：诊断→六项裁定→P0–P5 分期 + 模型 A/B；推翻 fs 工具默认关闭裁定 | 已获实施授权（2026-10-09 六项裁定）；首个增量 feature/agent-quality-phase01 | 随本提案 PR；诊断 SELF（真实运行转录）；基线报告见任务卡 |
 | [EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md) | RDM 多人共享契约的基座最小扩展申请（EXT-6…EXT-12）：身份停用/受管配置/授权适配器/索引发布/分发守卫/Host 工厂/投影过滤 | proposed；需求依据=RDM U0 主记录（D1–D9 裁定，2026-10-08 合入） | 随本提案 PR；每条现状证据为 SELF·源码级（Dev 34a2bbe/backend fe7c245），运行态 NOT_RUN；受理后逐条另立实现任务 |
 | [EXT 申请包 G1](2026-10-09-ext-g1-b1-b3-exec-backend.md) | EXT-13…16：回合内共享检索、命令即工具、项目列表共享、执行后端接口 | proposed；需求依据=RDM 方案 V1.1 §3.3/§3.4/§5.3（2026-10-09 批复） | Documents [#52](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/52) 已合入；EXT-16 已实施（Dev #285，见其任务卡），其余受理评审待定。本行由本次索引维护补充 |
-| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录：委派契约与角色路由方案（E1–E5 增量）+ 任务工作区沙箱设计（仅记录不实施）；修正 overlay≠快照等三处假设 | proposed（2026-10-10）；E1、E3、E5(R3) 已完成（E5 选型：默认 chat=MiniMax-M3，Dev #313，2026-10-10）；E2 暂缓、E4(R4 升级规则)/S0 待授权 | 随本提案 PR；现状核查与启动延迟为 SELF（任务卡 evidence）；外部来源 URL 全量随任务卡 |
+| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录：委派契约与角色路由方案（E1–E5 增量）+ 任务工作区沙箱设计（仅记录不实施）；修正 overlay≠快照等三处假设 | proposed（2026-10-10）；E1、E3、E4(R4+账本)、E5(R3)、S0-1 已完成（E4：Dev #315；S0-1：Backend #135/#136、Dev #318，2026-10-11）；E2 暂缓（模型指示）、S0-2 待授权 | 随本提案 PR；现状核查与启动延迟为 SELF（任务卡 evidence）；外部来源 URL 全量随任务卡 |
 
 原查询的 19 份原文中，14 份显式标注 owner 为 weichen。双档存储、启动配置面、跨会话读取、文件预览和
 N2 实施案这五份未单列 owner，其中预览案仅写“作者：weichen + Agent”。同步新增的 N3 与 Q2/Q3 案页首也未单列 owner。
@@ -153,3 +169,17 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
 
 后续维护：主案或任务变化时先更新其唯一主记录，再更新这里的导航和核验快照。
 更换 Docs/Dev 基线后重新核对 PR、版本与在途任务；新的索引状态不自动产生实施授权。
+
+## 2026-10-12 规划补充
+
+- [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 规格）；授权推送/PR 与 U1/U4 实施启动；合入由 owner 执行。规格见 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），其余方案与实施仍待评审。
+
+- [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md)：本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界；覆盖 34 UR／68 SR／10 F、全部69类模板及现有XLSX，当前源复核 RDM d8d7e743。总体方案待评审，实施/迁移/运行验收 NOT_RUN；模板方案为子方案。

docs/records/2026-10-11-collaboration-storage-plan-review.md

@@ -0,0 +1,31 @@
+# 协作存储方案 r1 静态审阅记录
+
+对象：[方案 r1](../proposals/2026-10-11-collaboration-storage-and-distribution.md)。
+日期：2026-10-11（Asia/Shanghai）。来源：SELF，Agent 辅助静态审阅。
+三个 Agent 分别兼任两个视角：coherence/scope-guardian、feasibility/adversarial、security/product。
+同一 Agent 的两个视角不互相独立；没有跨模型审阅、独立测试重放、CI GATE 或人工批准。
+使用 ce-doc-review 的检查视角，覆盖与边界以本记录为准，不声称已运行额外外部模型审阅。
+
+## 发现与处置
+
+| 发现 | 原方案后果 | 修订处置 | 复核 |
+|---|---|---|---|
+| 正式导入与非空目标拒绝冲突 | 预演后可能无法最终导入，或放宽规则混入其他快照 | U4/§6 分开预演与正式空目标；migration_id+快照身份，只有同快照可续传，验证完成后切入口 | 原审阅 Agent 已确认文本闭合 |
+| 恢复隔离晚于首期切换 | 现有 ResumeInterruptedChildren 可能自动重派未知副作用任务 | U3 前移持久 recovery hold，启动续跑跳过，U7 放行前验证 | 原审阅 Agent 已确认文本闭合 |
+| 命令只绑定旧 epoch | owner 切换后取消或审批意图可能丢失 | KTD5 区分逻辑 run 取消、gate/version 审批与按 epoch 验证的执行结果 | 原审阅 Agent 已确认文本闭合 |
+| 父子共享额度可能互等 | 父 run 占满许可并等待不能启动的子 run | §3/U3 区分接纳数与执行许可，等待父 run 让出许可但保留会话所有权 | 原审阅 Agent 已确认文本闭合 |
+| U6 先于 outbox 依赖 | 提前声明事务投递机制完成或重复建设 | U6 分追赶修复、outbox、向量三个切片并分别列前置 | 原审阅 Agent 已确认文本闭合 |
+| P0 权限检查落到后期 | 首期团队版可能未验证 SSE/检索/工具撤权 | U7 单实例放行前验证完整现有 R6 入口矩阵；新增跨机能力另验 | 原审阅 Agent 已确认文本闭合 |
+| 过渡期本地权威未说清 | 尚未迁移的 checkpoint/续跑文件可能被当缓存清除 | KTD2 增加首期与多实例期归属表，联合备份，U5 前禁止跨机接管 | 原审阅 Agent 已确认文本闭合 |
+| 只读适配器不足以判断写入/审批 | 可能把共享可读扩大成可写 | KTD13/U3 指定动作授权矩阵、版本化兼容与默认拒绝，不新建成员权威 | 原审阅 Agent 已确认文本闭合 |
+| 迁移/备份敏感副本保护未列 | 源库秘密可能经备份旁路暴露 | KTD14 指定访问、加密、密钥分离、保留与恢复验证；正式导出前缺项阻塞 | 原审阅 Agent 已确认文本闭合 |
+
+主编另依据 PostgreSQL 官方 PITR 文档修正备份描述：pg_dump 是逻辑备份，不能作为 WAL 回放基础；PITR 使用物理基础备份加连续 WAL。未改变用户确认的规模与未来分布式方向。
+
+## 剩余决策与验证边界
+
+- 10–100 人、多项目、多会话及未来多服务分布式：用户已确认需求方向。
+- 量化容量/恢复目标、正式实例和数据归属、迁移窗口、资源与实施阶段：待人工评审。
+- 本记录只说明文档中的九项问题已经改写并由原 Agent 复读，不说明实现缺陷已修复。
+- 实施、真实 PG/Redis 测试、压测、故障注入、数据迁移、恢复演练与部署：全部 NOT_RUN。
+- 方案正文与调查收据的字节摘要由文档检查命令写入 Dev 任务卡，作为本次候选身份；本文件不手写命令结果。

docs/records/2026-10-11-rdm-final-target-plan-review.md

@@ -0,0 +1,14 @@
+# 最终目标方案文档审阅记录
+
+对象：[总体方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)与[112 项需求矩阵](2026-10-11-rdm-final-target-requirements-matrix.md)。日期 2026-10-11。
+等级 SELF：三组本地模型阅读，覆盖一致性、可行性、产品、范围、交互、权限与失效场景；不是人工批准、独立 GATE/REPLAY 或业务验收。未执行跨供应商审阅。
+
+审阅前增量复核 RDM 从 0081628a 到 d8d7e743 的变化：保留已新增 HostBinding、项目命令守卫、上传项目约束和单行管理员引导事实，不继续按旧缺口排重建；仍需宿主绑定双向权限、成员工作目录与文档资源/职责授权，已进入 G 表及 U2/U3。
+
+| 发现 | 后果 | 已作修订 |
+|---|---|---|
+| U7 全模板真实验收是 U8 生成能力的前置，形成相互等待 | 可能以静态注册检查冒充全量模板可用 | U7 收敛为全量台账/公共契约/两模板；U8 首批闭环；新增 U16 全文档族迁移验收；U14 等 U16 |
+| U8 首批竞品模板含法规要点，却未依赖 U12 | 可能用模型URL或单通道占位完成首批 | U12 加入 U8 前置，同步依赖表和说明，保持无环 |
+
+最终产品/范围/交互复核未提出其他实质问题，34 UR、68 SR、10 F 编号集合无缺项/重复；全部69类及XLSX目标未缩水。权限/失效场景复核确认私域与授权知识快照、三权、防换角色自审、撤权、宿主双向绑定等约束已表达。
+本记录仅证明文档检查及相应修订；实际执行能力、测试通过、部署和用户验收均未据此认定。

docs/records/2026-10-11-rdm-final-target-requirements-matrix.md

@@ -0,0 +1,136 @@
+# 最终目标逐条覆盖矩阵（2026-10-11）
+
+主记录：[完整交付方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)。来源：RDM `docs/requirements/01-用户需求与系统需求.md`（V2.2）及 README/U0/Q 裁定；复核 RDM d8d7e743。
+
+34 UR、68 SR、10 F 均保留原编号。以下为 SELF 源码级盘点，当前运行验收均 NOT_RUN；“已有”不等于已验证/部署，“后移”不等于取消。摘要仅用于定位，语义以原文和用户确认 D1–D6 为准。G/U 均指主记录。
+
+## 系统需求（68 条）
+
+| ID | 原文摘要 | 当前源码级情况 | 仍需完成 | 工作包／差距 | 原文行 |
+|---|---|---|---|---|---|
+| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传，对不支持格式仅提醒不阻断 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14；G9/G10/G15 | 431 |
+| SR-A2 | 上传不强制附带文字指令；无指令时进入默认"记忆构建"流程（见 SR-B 系列），不输出制式化"未识别需求"回复 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14；G9/G10/G15 | 432 |
+| SR-A3 | 支持单文件、多文件批量上传，并记录来源渠道（Web/飞书/其他）与上传人 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14；G9/G10/G15 | 433 |
+| SR-A4 | 上传后 60 秒内输出第一阶段反馈（相关性结论 + 初步阶段归类）；完整入库允许后台异步完成 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14；G9/G10/G15 | 434 |
+| SR-A5 | 入库完整性保障：解析失败、部分内容不可解析或入库异常时，必须显式告知用户并在入库记录中标记，原始文件永久保留可取回；禁止静默降级或静默产出残缺结果（教训来源：旧版曾发生报价单 Excel 数据丢失、P… | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14；G9/G10/G15 | 435 |
+| SR-B1 | 对每份上传资料输出相关性判定（相关 / 存疑 / 无关）及判定依据；存疑时必须挂起并向用户请求确认，确认前不入库 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 441 |
+| SR-B2 | 对资料进行结构化解析，保留章节/页/表格级锚点，锚点在后续所有引用与追溯中可用 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 442 |
+| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项"，映射结合项目当前所处阶段；支持一片段映射多阶段 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 443 |
+| SR-B4 | 每个切片附带结构化标签（JSON）：阶段、工作事项、主题、可行性维度（技术/市场/注册）、关联需求 ID、来源、上传时间、置信度；并生成一句话描述（description） | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 444 |
+| SR-B5 | 支持"两速入库"：快速通道（打标签 + 摘要 + 入库）先行返回，慢速通道（细切片、嵌入向量化）后台补齐，状态对用户可见 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 445 |
+| SR-B6 | 入库完成后向用户输出勾连总结：本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节，以显式清单呈现 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 446 |
+| SR-B7 | 会议纪要类资料按同一管道处理，并可抽取"结论 / 待办 / 待确认"三类条目 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6；G9/G10 | 447 |
+| SR-B8 | 笔记树内一致性检测：同一主题簇下多个切片的陈述不一致（如多人表述冲突）时，系统检测冲突 + 记录入追溯网（何时/何人/何节点/何操作）+ 通知触发冲突的用户 + 挂起待裁决；智能体不自行处理冲突，裁决… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6；G11 | 448 |
+| SR-B9 | 并发更新冲突避免与及时提示：多人几乎同时更新同一树节点时，系统忠实记录全部操作入追溯网，冲突以候选子节点组并存挂起，智能体不自行处理冲突；裁决集中在编制人发起编制时经 HITL 完成（裁决两层，规则同… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6；G11 | 449 |
+| SR-B10 | 任务快慢双速：对用户任务按快慢双速模式执行——快通道同步短链路即时反馈（如上传文档→相关性判断→相关给概要/不相关给理由＋相似文档供选择），慢通道小队（subagent）后台深度执行（逐页解析、建节点… | 内存队列/台账已有 | 持久输入、取消恢复、幂等与通用双速未完成 | U9/U13；G15 | 450 |
+| SR-B11 | 结论节点：结论作为笔记树的节点类型保存（结论入树）；结论节点与切片同受 08 R1–R5 硬规则约束（append-only、软删除、结构事件日志、可重建）；结论节点与其依据切片/来源的关联入追溯网。… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6；G11 | 451 |
+| SR-B12 | 总结触发：何时生成阶段总结交模型自主判断（不设固定阈值）——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档（HITL 确认）；保留人工触发入口（用户明确指令触发）；上传后先快速摘要反馈、后… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6；G11 | 452 |
+| SR-C1 | 内置可配置的研发体系文档树（阶段 → 文档 → 章节），每章有内容要求说明；文档树对应设计开发控制程序，商务对接与策划合并为同一阶段 | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16；G7/G8 | 458 |
+| SR-C2 | 体系文档模板集中注册、版本化管理；模板与阶段/文档节点的关联可配置，不与具体工作流实例硬绑定。模板策略：本期按当前已有模板设计与完善；标准模板待系统完成并通过测试后由用户补充（E-T3，后续目标 F-… | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16；G7/G8 | 459 |
+| SR-C3 | 文档生命周期状态机：草稿 → 评审中 → 已基线 →（变更中）→ 新版本基线；基线文档不可被直接修改 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10；G6/G8/G17 | 460 |
+| SR-C4 | 新切片填充文档章节前，与该章节现有内容比对，输出三分类结论：新增 / 更新 / 冲突；更新与冲突均需用户确认后生效 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10；G6/G8/G17 | 461 |
+| SR-C5 | 缺项分析仅在两种触发条件下输出：文档提交评审时、项目申请推进阶段时；上传节点禁止输出缺项提示 | 简单素材检查已有 | 内容/合规要求检查未接提交和阶段门禁 | U10/U11；G14 | 462 |
+| SR-C6 | 每次文档内容变化生成版本记录，可查看任意两版本差异及差异来源切片 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10；G6/G8/G17 | 463 |
+| SR-C7 | 三权分立流程规则：编制/审核/批准三权异人（编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人）；编制发起唯一；审核/批准仅可批注与通过/驳回，不可修改正文或发起编写；提交审核即锁定；驳回回… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8；G6/G17 | 464 |
+| SR-C8 | 批准后修改的处理：本期路径＝撤回重审（D-12：撤回后修改并重新升版审批）＋影响提示（沿追溯网列出受影响范围给人看，不走流程，见 SR-D3）；松散管理取向，但审计链不断（08 R1/R2/R5 不动… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8；G6/G17 | 465 |
+| SR-D1 | 建立并持久化双向追溯网络：资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例；每条边记录类型、来源（人工/规则/模型候选）与置信度 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 471 |
+| SR-D2 | 需求条目化管理：用户需求与系统需求大表，字段含状态（草稿/已评审/已基线）、版本、关联文档与法规；支持增删改与批量导入 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 472 |
+| SR-D3 | 新内容入库触发变更检测：与已评审条目比对，不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示（V2.1 增补）：批准后修改或引用内容变化时，系统沿追溯网列出受影响范… | 部分关系/变化方法已有 | 来源变化的影响对象和职责闭环待完成 | U6/U11；G11/G16 | 473 |
+| SR-D4 | 变更流程闭环（变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭，全程留痕）：整体后移，不作为本阶段系统实现目标——变更流程走公司内部管理流程，移入后续目标备案 F-02（《10… | 后移目标保留 | 公司流程权威及七步闭环待独立交付 | U15/F-02；G14 | 474 |
+| SR-D5 | 任一需求可导出完整追溯链报告；无法匹配进体系的资料进入"待裁定"清单，提醒用户处理 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 475 |
+| SR-D6 | 追溯主体扩展：追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片，保证所有信息细节的准确性与可追溯性 | 来源字段已有 | 模板/主体/来源版本须贯穿生成历史和导出 | U4/U8/U11；G8/G17 | 476 |
+| SR-D7 | 完整合规追溯模型（权威定义见 08 第十六章）：15 类受控节点（含危害/风险控制措施/设计确认/设计转换/变更）＋11 类合规边（两端=节点 ID@版本，模型仅候选、人工确认转正）＋四条链视图（13… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 477 |
+| SR-D8 | 需求分类与分解框架：用户需求与性能需求分到不同文档；先确认用户需求再分解系统需求；系统需求按六维度分类（功能/交互/安全/运输包装/维护/合规）；智能体可从法规反推部分系统需求，但不完全依赖智能体；先… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 481 |
+| SR-D9 | 风险登记册追溯：危害（HAZ）与风险控制措施（RCM）入网；每个 RCM 同时登记为需求并必须被验证（verifies 边）；每个危害至少被一项 RCM mitigate；措施-危害-验证三向可查（术… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 478 |
+| SR-D10 | 验证结果绑定被测版本：VR 记录对应用例与被测对象版本；被测版本≠当前基线版本时系统报「验证过期」并列入缺口；设计确认（VAL）必须追溯到用户需求 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 479 |
+| SR-D11 | SOUP 组件登记与追溯：软件组成项（含 SOUP）入网为架构项，其需求分配与验证沿用同一边模型 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14；G12/G17 | 480 |
+| SR-E1 | 意图识别分层：规则层（仅限整句完全匹配的高频确定性短指令）→ 语义层 → LLM 层；规则层不得单独触发高风险操作 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 487 |
+| SR-E2 | 规则层命中必须通过上下文校验（上一轮存在对应的待确认事项）才可执行；无上下文时降级为普通对话 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 488 |
+| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成，卡片明示操作对象与后果 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 489 |
+| SR-E4 | 支持意图分类（查询 / 编写 / 命令 / 讨论）与意图切换识别；编写类意图需命中目标文档并确认后执行 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 490 |
+| SR-E5 | 简单询问即时回答；复杂任务先给出执行计划与预计耗时，执行中提供进度反馈 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 491 |
+| SR-E6 | 对话完备路径：从立项到结项的全部状态变更操作（创建项目、提交评审、批准变更、阶段推进、导出、结项等）均可通过对话指令驱动，页面/按钮不是任何步骤的唯一入口；高风险操作的对话路径终点为对话流内联确认卡（… | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10；G1/G8/G14/G15 | 492 |
+| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行：骨架显式定义步骤序列与返回检查节点，角色在骨架内有限自主 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13；G8/G15/G18 | 498 |
+| SR-F2 | 每个角色显式声明：职责、可用工具白名单、禁区；角色提示词作为受控资产版本化管理 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13；G8/G15/G18 | 499 |
+| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道，结果附引用来源；冲突时以权威来源为准并提示 | 知识检索/声明表已有 | 网络通道为模型输出URL，缺实际抓取独立证据 | U12；G13 | 500 |
+| SR-F4 | 长任务后台异步执行，进度可查询、完成有通知；不得阻塞对话主线程 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13；G8/G15/G18 | 501 |
+| SR-F5 | 执行任务时自动组装上下文：项目当前状态、相关记忆切片、目标文档模板、近期对话；上下文构成可解释 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13；G8/G15/G18 | 502 |
+| SR-G1 | 飞书集成：智能助手可加入群聊，支持群内对话、收文件、推送反馈与通知。本期不做飞书功能（J-11），本条与 UR-20 一并后移 → F-01 | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01；外部依赖 | 508 |
+| SR-G2 | 基于角色与项目阶段的权限控制（ABAC），阶段转换需满足准入准出条件并留痕。判定维度（角色 × 项目 × 阶段 × 动作）保留；权限主数据裁决（J-10，R2 关闭）：本期系统内建最小权限系统（管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3；G3/G4 | 509 |
+| SR-G3 | 全量审计日志：上传、入库、更新、变更、确认、生成等动作均可审计 | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11；G5/G17 | 510 |
+| SR-G4 | 系统以自身研发项目为首个运行实例（自举元项目），自身需求与体系文档由本系统管理 | 自举测试资产已有 | 真实材料/模型/登录/浏览器全程验收未完成 | U14；G19 | 511 |
+| SR-G5 | 结构追溯：笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值；删除一律软删除（tombstone）；追溯边有"候选 → 生效 → 废止"全生命周期；支… | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11；G5/G17 | 512 |
+| SR-G6 | 系统管理员与系统级设置：全局唯一管理员拥有所有权限；仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数（工具调用轮数/工具权限等）、系统级插件管理、用户/角色的… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3；G3/G4 | 513 |
+| SR-G7 | 角色管理：角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人；角色可分配给用户（如项… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3；G3/G4 | 514 |
+| SR-G8 | 权限覆盖优先级——上限内覆盖（J-05，原存疑关闭）：管理员设定角色默认权限与权限范围上限（最底层约束）；项目负责人（创建者）在该范围内调整项目成员权限；项目内配置可覆盖角色默认配置，但不得突破管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3；G3/G4 | 515 |
+| SR-G9 | 项目负责人权限：项目创建者即项目负责人，拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3；G1/G2 | 516 |
+| SR-G10 | 项目唯一性与成员自动可见：同名项目全系统唯一；用户被添加为项目成员后，其界面自动出现该项目，并可直接开始项目工作（新建对话等） | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3；G1/G2 | 517 |
+| SR-G11 | 对话隐私：用户之间的对话互相不可见，仅本人可见本人与智能体的对话；智能体会话/中间过程默认互不可见（J-06，原存疑关闭），协作全部经两树一网项目共享层；用户分享分层（整个项目/会话/部分会话）的精细… | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9；G4/G5/G10 | 518 |
+| SR-G12 | 文档分享：上传者可将文档分享给指定成员/部分成员/全部项目成员；被分享者只读、不可编辑；被分享文档进入接收者上下文，支撑其后续对话中查看并基于这些文档对话 | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9；G4/G5/G10 | 519 |
+| SR-G13 | 上下文时间权重：本期最小实现——检索与注入排序新内容优先；替换/冲突场景走 J-02 人裁决（SR-B8/SR-B9）。可配置时间权重衰减模型（权重数值、配置粒度）移入后续目标 F-04（J-07，优… | 排序效果未验收 | 新内容优先不代替裁决，可配置衰减后续实现 | U5/U15/F-04；G10 | 520 |
+| SR-G14 | 飞书项目对接适配（接口层四项功能：产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接；飞书角色权限映射读取）：本期不做飞书功能，整条移入后续目标备案 F-01（J-11）；保留设计预留说… | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01；外部依赖 | 521 |
+| SR-G15 | 虚拟人账号（企业账号下为智能体创建固定账号持有文档/文件夹访问权限；授权范围、审批与定期审计流程待明确，《10》Q-04）：随飞书对接整体后移，移入后续目标备案 F-01（J-11） | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01；外部依赖 | 522 |
+| SR-G16 | 代码执行安全：多用户共享部署在隔离执行档就位前，以启动级硬关闭禁用执行原语（run_shell/run_python/register_artifact 及内核执行配置），用户设置不得覆盖（基座已交付… | 多人执行硬关闭已有 | 最终隔离执行及受控开放待实现验收 | U13；G18 | 523 |
+| SR-N1 | 性能：上传首轮反馈 < 60 秒；单文档完整入库（后台）< 10 分钟；追溯链查询 < 3 秒 | 部分运行机制已有 | 固定样本/数据/并发规模的性能待实测 | U14；G18/G19 | 529 |
+| SR-N2 | 可维护性：模块边界清晰、依赖单向；任一核心功能（如文档入库）可在 5 分钟内定位到对应代码模块；支撑每周代码审查机制 | 模块边界已有 | 公开契约、文档代码可定位性与维护机制待复核 | U1/U14；G19 | 530 |
+| SR-N3 | 可解释性：每个入库、更新、变更动作给出依据（来源切片、命中标签、比对结果） | 部分依据回执已有 | 标签、来源、差异与失败可解释性需全链路验证 | U4/U5/U8；G10/G17 | 531 |
+| SR-N4 | 部署与数据：支持本地化部署；法规知识库本地存储；项目数据按项目隔离 | 领域分片与本地存储已有 | 团队数据权威、私域隔离、安装和恢复未完整验收 | U2/U3/U13；G5/G18 | 532 |
+| SR-N5 | 模型无关性：大模型通过抽象层接入，可替换（当前为 MiniMax，不绑定） | 模型抽象已有 | 模型替换后的真实业务与降级对照待验证 | U9/U13；G8/G18 | 533 |
+
+## 用户需求（34 条）
+
+每条用户需求沿原 UR→SR 关系追溯，其所有适用系统需求通过后才可关闭。
+
+| ID | 用户目标 | 原关联SR | 实施去向 | 当前判定 | 原文行 |
+|---|---|---|---|---|---|
+| UR-01 | 自由上传 | SR-A1, SR-A2, SR-A3 | U5/U9/U14 | 局部组件已有；端到端未验收 | 541 |
+| UR-02 | 相关性把关 | SR-B1 | U5/U6 | 局部组件已有；端到端未验收 | 542 |
+| UR-03 | 自动归纳入库 | SR-A5, SR-B2, SR-B3, SR-B4, SR-B6 | U5/U6/U9/U14 | 局部组件已有；端到端未验收 | 543 |
+| UR-04 | 及时反馈 | SR-A4, SR-B5, SR-E5, SR-F4 | U2/U5/U6/U8/U9/U10/U13/U14 | 局部组件已有；端到端未验收 | 544 |
+| UR-05 | 渐进式清晰 | SR-C1, SR-C2, SR-C3, SR-C4, SR-C6 | U4/U7/U8/U10/U16 | 局部组件已有；端到端未验收 | 545 |
+| UR-06 | 缺项提示时机 | SR-C5 | U10/U11 | 局部组件已有；端到端未验收 | 546 |
+| UR-07 | 冲突与变更 | SR-B8, SR-C3, SR-C4, SR-D3, SR-D4（→ F-02） | U4/U6/U8/U10/U11/U15 | 局部组件已有；端到端未验收 | 547 |
+| UR-08 | 严格可追溯 | SR-B2, SR-D1, SR-D5, SR-G3, SR-G5, SR-C6, SR-D7（合规追溯链，V2.2） | U4/U5/U6/U8/U10/U11/U14 | 局部组件已有；端到端未验收 | 548 |
+| UR-09 | 需求条目化 | SR-D2, SR-D3, SR-D8（需求分类与分解框架，V2.2） | U6/U11/U14 | 局部组件已有；端到端未验收 | 549 |
+| UR-10 | 模糊澄清 | SR-B6, SR-B8, SR-E5（提问交互） | U2/U4/U5/U6/U8/U9/U10 | 局部组件已有；端到端未验收 | 550 |
+| UR-11 | 一键生成文档 | SR-E4, SR-F1, SR-F2, SR-F5 | U2/U8/U9/U10/U13 | 局部组件已有；端到端未验收 | 551 |
+| UR-12 | 主动提问 | SR-E5, SR-B6 | U2/U5/U6/U8/U9/U10 | 局部组件已有；端到端未验收 | 552 |
+| UR-13 | 外部查询入库 | SR-F1, SR-F3, SR-B4 | U5/U6/U8/U9/U12/U13 | 局部组件已有；端到端未验收 | 553 |
+| UR-14 | 法规双通道 | SR-F3 | U12 | 局部组件已有；端到端未验收 | 554 |
+| UR-15 | 商务策划贯通 | SR-C1, SR-C2 | U7/U8/U16 | 局部组件已有；端到端未验收 | 555 |
+| UR-16 | 显式确认 | SR-E1, SR-E2, SR-E3, SR-E6 | U2/U8/U9/U10 | 局部组件已有；端到端未验收 | 556 |
+| UR-17 | 阶段门禁权限 | SR-G2, SR-G3 | U2/U3/U4/U11 | 局部组件已有；端到端未验收 | 557 |
+| UR-18 | 会议纳入记忆 | SR-B7 | U5/U6 | 局部组件已有；端到端未验收 | 558 |
+| UR-19 | 自举 | SR-G4 | U14 | 局部组件已有；端到端未验收 | 559 |
+| UR-20 | 协作平台接入 | SR-A3, SR-G1（本期不做飞书功能，一并后移 → F-01，J-11） | U15 | 后移目标保留 | 560 |
+| UR-21 | 系统角色与权限管理 | SR-G2, SR-G6, SR-G7, SR-G8 | U2/U3 | 局部组件已有；端到端未验收 | 561 |
+| UR-22 | 项目成员与协作 | SR-G9, SR-G10 | U2/U3 | 局部组件已有；端到端未验收 | 562 |
+| UR-23 | 文档分享与上下文注入 | SR-G11, SR-G12, SR-G13（降 P2，衰减模型 → F-04） | U3/U5/U9/U15 | 局部组件已有；端到端未验收 | 563 |
+| UR-24 | 三权分立文档流程 | SR-C7, SR-C8 | U3/U8 | 局部组件已有；端到端未验收 | 564 |
+| UR-25 | 版本全量保留与来源追溯 | SR-C6, SR-D6, SR-G5 | U4/U8/U10/U11 | 局部组件已有；端到端未验收 | 565 |
+| UR-26 | 并发更新冲突避免与提示 | SR-B8, SR-B9（J-02 落地＋U0 D4 两层裁决） | U4/U6 | 局部组件已有；端到端未验收 | 566 |
+| UR-27 | 快慢处理与任务拆解展示 | SR-B10（J-03 已裁决落地） | U9/U13 | 局部组件已有；端到端未验收 | 567 |
+| UR-28 | 简易看板 | SR-C3, SR-D3（编制状态与变更检测为看板数据源；看板与卡片流界面统一 → F-06） | U4/U6/U8/U10/U11 | 局部组件已有；端到端未验收 | 568 |
+| UR-29 | 难度分级与降级使用 | SR-F2（智能体能力边界按项目难度配置；评估表与降级规则细化 → F-08） | U8/U9/U13/U14/U15 | 局部组件已有；端到端未验收 | 569 |
+| UR-30 | 对抗验证机制 | SR-F1（流程骨架中增设独立验证节点；对抗机制形态待设计，属《10》Q-13，维持开放） | U8/U9/U13/U14/U15 | 局部组件已有；端到端未验收 | 570 |
+| UR-31 | 飞书项目对接 | SR-G14, SR-G15（本行整体→ F-01） | U15 | 后移目标保留 | 571 |
+| UR-32 | 代码管理工具集成 | SR-D1（追溯网扩展需求—版本—缺陷关联边；本行整体→ F-05） | U15 | 后移目标保留 | 572 |
+| UR-33 | 法规合规追溯 | SR-D7, SR-D9, SR-D10, SR-D11, SR-D1 | U11/U14 | 局部组件已有；端到端未验收 | 573 |
+| UR-34 | 结论沉淀与阶段总结 | SR-B11, SR-B12 | U6 | 局部组件已有；端到端未验收 | 574 |
+
+## 后续目标（10 项）
+
+| ID | 原目标 | 当前处理 | 交付去向 | 原文行 |
+|---|---|---|---|---|
+| F-01 | 飞书对接全套（渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联） | 保留最终目标，前置与批准见主记录 | U15/F-01 | 637 |
+| F-02 | 变更流程引擎（七步闭环、变更单、完整影响分析） | 保留最终目标，前置与批准见主记录 | U15/F-02 | 638 |
+| F-03 | 用户分享分层（整个项目/会话/部分会话）与智能体可见性的精细设计 | 私有默认已确认，细分分享需明确授权 | U15/F-03 | 639 |
+| F-04 | 可配置上下文时间权重衰减模型 | 保留最终目标，前置与批准见主记录 | U15/F-04 | 640 |
+| F-05 | 代码管理工具集成（GitLab token 只读拉取、需求-版本-缺陷关联） | 保留最终目标，前置与批准见主记录 | U15/F-05 | 641 |
+| F-06 | 看板与卡片流的界面统一（随原型 V2.3） | 并入对话与看板同源收敛 | U9/U14 | 642 |
+| F-07 | 会议遗留问题组（Q-01/02/03/07/10/13/14 等，《12》问题 8 组）；其中 Q-02 经晚会部分裁决（C-03，见 §7.1） | 逐项裁决台账，不当作已确定的一组功能 | U15/F-07 | 643 |
+| F-08 | 难度分级评估表与降级机制的落地细化（UR-29 保留 P1，实施细节备案） | 保留最终目标，前置与批准见主记录 | U15/F-08 | 644 |
+| F-09 | 追溯网可视化（先功能后展示，暂缓） | 较新展示方案已批准，早期暂缓已调整 | U11/U14 | 645 |
+| F-10 | 标准模板替换：本期按当前已有模板设计与完善；待系统完成并通过测试后，由用户补充标准模板（取代晚会 T2「今晚下载官方模板替换」，不执行） | 依赖用户提供标准模板；旧模板先全量实现 | U16＋U15/F-10 | 646 |
+
+验收结果槽：本轮未生成业务通过记录；后续由实施任务/CI/独立重放补入命令、对象 SHA、运行链接与输出。历史任务卡另行映射，原始收据不改。

docs/records/2026-10-11-rdm-template-inventory.md

@@ -0,0 +1,85 @@
+# RDM 文档模板资产盘点（2026-10-11）
+
+关联方案：[对话文档生成方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。本清单为 SELF 静态资产盘点，不表示线上实际文档数或模板已验收。
+
+源：旧 Agent-System `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` 的 `templates/docs/*.md`；RDM `0081628a10ec48a36537c6eced11a57439c986fa` 的 `internal/domain/data/labels_seed.json`、`docs/templates/registry.yaml`。
+旧路径规则为 `templates/docs/<类型键>.md`。下列 H2 数只用于估算拆解工作，不等于最终业务章节数；管理性章节需重新归位。
+
+69 份 Markdown：bd 7、rd 60、pm 1、tm 1；另有 `templates/xlsx/cdo_quote.xlsx` 一份，不计入 69。
+RDM 登记 69 种 docTypes，但只注册 4 个 v1 模板，覆盖 3 个类型；66 个类型未绑定模板。
+“已绑定”仍不表示正确默认、格式兑现或完整生成可用。当前按首项匹配会混用周报/纪要，详情见方案 G3。
+所有历史模板迁移/发布/业务验收均待独立评审，本清单不修改发布状态。
+
+| 类型键 | 字典名称 | 阶段 | 历史 H2 数 | RDM 注册绑定 | 原件 SHA256 前16位 |
+|---|---|---|---|---|---|
+| bd_cdo_quote | CDO 报价单 | BD | 6 | 未绑定 | 4d0cb0b4e4dafecb |
+| bd_feasibility_dev | 设计开发可行性评估报告 | BD | 7 | 未绑定 | dc565be65647250c |
+| bd_feasibility_reg | 注册路径可行性评估报告 | BD | 9 | 未绑定 | 16add9b2558dee31 |
+| bd_intake | 用户初始需求收集表 | BD | 8 | 未绑定 | 427bafe56062f616 |
+| bd_prelim_design | 系统初步设计方案 | BD | 9 | 未绑定 | 4001acdbb5bafa5e |
+| bd_research | 调研报告（竞品/技术/专利/市场/对比/法规） | BD | 11 | review-minutes@v1、competitive-analysis@v1 | 0b64388a16f8c7de |
+| bd_user_requirements | 用户需求表 | BD | 7 | 未绑定 | 547dda49107a4d26 |
+| pm_system_reqs | 系统需求规格书（SR） | 03 | 10 | 未绑定 | 3717c5ff34272088 |
+| rd_adverse_events | 同类产品不良事件信息 | 03 | 11 | 未绑定 | d2cfbfed223d9dd7 |
+| rd_animal_study | 动物试验方案 | 12 | 11 | 未绑定 | f070c80fb84b413d |
+| rd_biocompatibility | 生物学检测方案 | 08 | 11 | 未绑定 | bcb25be8e5d8745d |
+| rd_cleaning | 清洁消毒验证方案 | 08 | 11 | 未绑定 | 42ec75116e247d88 |
+| rd_clinical | 临床试验报告 | 12 | 11 | 未绑定 | 9df8321b7488535d |
+| rd_design_input_list | 设计输入清单 | 03 | 11 | 未绑定 | 51c0d2334a8f0475 |
+| rd_design_input_spec | 设计输入规格书 | 03 | 12 | 未绑定 | a629d1b3e3dc6e9a |
+| rd_design_output_list | 设计输出清单 | 06 | 10 | 未绑定 | 5ffbce9be6d92ccd |
+| rd_design_plan | 设计开发计划任务书 | 01 | 11 | review-minutes@v1 | 589dec73a01b1c75 |
+| rd_design_validation_report | 设计确认报告 | 13 | 11 | 未绑定 | 9ff1744ebdae179f |
+| rd_design_vv | 设计验证方案 | 08 | 11 | 未绑定 | 5ec16dcfbbf55132 |
+| rd_dmr_list | DMR文件清单 | 10 | 10 | 未绑定 | 437bda4f714d756b |
+| rd_drawings_3d | 2D图纸和3D模型（附件清单） | 06 | 10 | 未绑定 | 96b771a7912a6393 |
+| rd_ee_bom | 电子电气BOM（附件清单） | 06 | 10 | 未绑定 | 08052bb640704115 |
+| rd_electrical_sys | 系统电气设计图（附件清单） | 06 | 10 | 未绑定 | df4f8aaeedbf4f5c |
+| rd_emc_safety | EMC及安规摸底报告（附件清单） | 08 | 11 | 未绑定 | 9257a9a02d6ac939 |
+| rd_fqc | 成品检验规范 | 06 | 11 | 未绑定 | 4891c93ff9ce889b |
+| rd_hazard_analysis | 安全性问题清单及可能危险分析表 | 03 | 11 | 未绑定 | 3a8ed0db49b35553 |
+| rd_ifu | 产品使用说明书 | 06 | 11 | 未绑定 | d76bc2e2a531632a |
+| rd_incoming_iqc | 原材料进货检验规范 | 06 | 11 | 未绑定 | 14c21bd69cd9a756 |
+| rd_input_phase_review | 设计开发评审记录（阶段3和4） | 05 | 12 | 未绑定 | 5982bdf27dab55f0 |
+| rd_ipqc | 生产过程检验规范 | 06 | 11 | 未绑定 | 14bf3912f4dc6c4f |
+| rd_lifetime | 产品使用期限研究方案 | 08 | 11 | 未绑定 | f7232dd9750c2369 |
+| rd_output_review | 设计开发评审记录（阶段6） | 07 | 12 | 未绑定 | 87029ef45d4ac5b2 |
+| rd_pack_ship | 包装运输方案 | 10 | 11 | 未绑定 | a368bd102a0535f3 |
+| rd_packaging | 包装图纸和设计要求 | 06 | 11 | 未绑定 | e12a32ded3da14f1 |
+| rd_pcba | PCBA原理图及Layout（附件清单） | 06 | 10 | 未绑定 | 4b91abe3191c36df |
+| rd_planning_review | 设计和开发策划评审记录 | 02 | 12 | 未绑定 | 3bac17e3ef284010 |
+| rd_process_flow | 工艺流程图及作业指导 | 06 | 11 | 未绑定 | c4892f9947ec3cce |
+| rd_product_bom | 产品BOM（附件清单） | 06 | 10 | 未绑定 | ac57d604f77ac754 |
+| rd_proposal | 项目建议书 | 01 | 11 | weekly-report@v1、project-proposal@v1 | 50ed802a9249229e |
+| rd_prototype_photos | 样机照片（附件清单） | 08 | 10 | 未绑定 | be4ff90930f06842 |
+| rd_purchase_spec | 采购技术规范 | 06 | 11 | 未绑定 | 72ee43993c30f01a |
+| rd_qualified_suppliers | 合格供方名录 | 08 | 11 | 未绑定 | 603a9ab37998a21a |
+| rd_regs_stds | 法规和标准清单 | 03 | 11 | 未绑定 | 24b98c273fb04dd8 |
+| rd_req_review | 需求评审记录 | 04 | 12 | 未绑定 | d42e18d5e02b7d5c |
+| rd_risk_plan | 风险管理计划 | 03 | 11 | 未绑定 | 608822eb42aa83bd |
+| rd_risk_report | 风险管理报告 | 06 | 11 | 未绑定 | de4ed137e0c1b76f |
+| rd_risk_report_t | 风险管理报告（转换阶段） | 10 | 11 | 未绑定 | 24c61db854d6a9de |
+| rd_risk_report_v | 风险管理报告（验证阶段） | 08 | 11 | 未绑定 | 762eb5d127698215 |
+| rd_risk_report_val | 风险管理报告（确认阶段） | 12 | 11 | 未绑定 | b3200d74cd74913d |
+| rd_shelf_life | 货架寿命方案 | 08 | 11 | 未绑定 | 9e51627645d7c561 |
+| rd_sw_arch | 软件概要设计方案 | 06 | 11 | 未绑定 | e829e164cf1c825b |
+| rd_sw_config | 软件配置及维护计划 | 03 | 11 | 未绑定 | 8510491f6480b58b |
+| rd_sw_plan | 软件开发计划 | 03 | 11 | 未绑定 | 79ddc781bca8bb9d |
+| rd_sw_quality | 软件质量测试报告 | 12 | 11 | 未绑定 | ef1e7dbbed13abf8 |
+| rd_sw_release | 软件发布清单 | 08 | 10 | 未绑定 | ac4e522903fa6872 |
+| rd_sw_reqs | 软件需求规格书 | 03 | 11 | 未绑定 | eb9a1d75efe1bda1 |
+| rd_sw_sys_test | 软件系统测试报告 | 08 | 11 | 未绑定 | c86e15580ee24d16 |
+| rd_sw_ui | 软件UI设计文档 | 06 | 11 | 未绑定 | 9c041da7d6db8d88 |
+| rd_sw_unit_test | 软件单元测试报告 | 08 | 11 | 未绑定 | 368b5939da695d0e |
+| rd_system_design | 系统设计方案 | 03 | 11 | 未绑定 | adf0b6bf32fe10af |
+| rd_system_reqs | 系统需求规格书（SR） | 03 | 15 | 未绑定 | 1d0aa50c5e8f06d9 |
+| rd_tech_req | 产品技术要求 | 06 | 11 | 未绑定 | 03c39e46300e6719 |
+| rd_transfer_review | 设计开发评审记录（转换阶段） | 11 | 12 | 未绑定 | 4be3b0770a08d6d4 |
+| rd_use_error | 使用错误评估报告 | 12 | 11 | 未绑定 | 67c98d3f26b91c13 |
+| rd_user_needs | 用户需求规格书（UN） | 03 | 11 | 未绑定 | cdc46e46a93bca81 |
+| rd_user_test | 用户测试报告 | 12 | 11 | 未绑定 | 26ad7d32eb59b386 |
+| rd_validation_plan | 设计确认方案 | 12 | 11 | 未绑定 | a0b53fc9a74df218 |
+| rd_verification_review | 设计开发评审记录（验证阶段） | 09 | 12 | 未绑定 | ec68f27212649baf |
+| tm_system_verification | 系统验证方案及计划（SVP） | 04 | 8 | 未绑定 | 7b66de5bd1f6b0f3 |
+
+完整哈希应在正式迁移台账保留；本表短哈希用于阅读定位，不作为独立完整性或身份凭据。

docs/records/2026-10-11-rdm-template-plan-review.md

@@ -0,0 +1,19 @@
+# 模板对话生成方案 r1 文档检查记录
+
+对象：[方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。日期：2026-10-11。
+性质：SELF，三组本地模型审阅覆盖七个视角，不是人工评审、业务验收或独立 GATE/REPLAY；未执行跨供应商模型审阅。
+检查范围：方案一致性、可行性、产品范围、使用流程、权限和关键失效场景。业务测试 NOT_RUN。
+
+| 视角 | 原始发现 | 处理 |
+|---|---|---|
+| 一致性 | 无重要矛盾 | 无修改 |
+| 可行性 | 同文档旧章节职责/签署不同，不能自动合成文档批准 | KTD8/U4 补迁移与旧活动审签处置；首个整文版重新审签 |
+| 产品 | 无实质发现 | 保留首批两模板建议与69类全量登记、分批验收 |
+| 交互 | 新文档未分配职责或当前用户非编制人时缺对话恢复路径 | User Flow/U5 补等待分配、负责人分配、最小信息转交与指定编制人接续 |
+| 范围 | 无实质发现 | 保留既有两树一网/存储分工 |
+| 权限 | 模板发布、退役和默认绑定的管理权未明确 | KTD1/U2 限定首期经批准仓库发布；编制权不继承模板管理权 |
+| 失效场景 | 部分采纳混合新旧章节后未重验整文依赖 | KTD6/U4 补对实际目标组合的依赖、术语、指标检查及版本/hash 绑定 |
+
+四条原始发现均为 P2、置信度 75。主审核对依据：旧 review.go 以 sectionID 分配职责/保存审批，首期 templates.go 只读受控注册表，方案已有严格编制权与部分采纳行为；四项补充用于使既有目标成立，未扩大业务交付范围。
+四项已在方案中修订并补验收场景；未代签用户保留的路线、首批顺序、文档级审批选择和实施授权。
+本记录只证明文档检查及修订，后续真实业务验证仍按方案执行。

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-service-restart-data-recovery-review.md

@@ -0,0 +1,64 @@
+# 服务重启与全量数据恢复方案 r1 文档审阅
+
+日期：2026-10-12（Asia/Shanghai）。对象：[主方案](../proposals/2026-10-12-service-restart-data-recovery.md)。
+方法：ce-doc-review，non-interactive；六个独立上下文的原生子代理加作者源码复核。以下为审阅意见及处置摘要；来源为SELF，不是人工批准、业务验收、REPLAY或GATE。没有外部跨供应商模型评审；未跑业务测试或故障试验。
+
+| 角色 | 原始发现数 | 处置 |
+|---|---|---|
+| coherence | 1 | 修正灾难恢复的分档RPO验收 |
+| feasibility | 1 | 与design同一问题合并，修正动作与整run的结算边界 |
+| security-lens | 1 | 加入新目标恢复前的旧写路径隔离门禁 |
+| design-lens | 1 | 与feasibility同一问题合并，复用原状态/卡片展示 |
+| scope-guardian | 0 | 无需扩大或缩小当前目标范围 |
+| adversarial | 1 | 收紧非幂等动作的确定未执行证据 |
+
+共5条原始发现、4项独立修正；全部已纳入候选r1，不涉及用户需求的取舍变化。人工评审仍未发生。
+
+## 审阅意见与处置依据
+
+1. **分档验收不一致。** 初稿目标允许灾难档RPO≤5分钟，U7却无条件要求“零已确认数据遗漏”。后果是按目标建设的备份也无法按U7签收。按已声明的故障分档，R3/U7/故障矩阵明确RPO=0档零遗漏，灾难档恢复点差距在批准范围内、点内完整并报告点后缺失。没有暗改用户的零丢失合同，所有量化指标仍待人工批准。
+2. **一个外部动作完成不等于整任务完成。** 初稿状态图直接 `hold→completed`，可能跳过必要后续步骤。作者复核Native `runtime/loop.go:385–402`确认工具结果持久化后还继续模型回合；因此与design/feasibility意见一致。现改为记录operation receipt后回recovering，继续剩余步骤，只有全部必要步骤及业务结果完成才结算整run。
+3. **独立恢复库不能围栏旧库的执行者。** 初稿对新目标恢复已有数据、权限和组合对账，但未明确切生产前如何阻断原权威复活。旧、新库各有有效epoch时，单库租约不能避免双执行。现加入默认隔离验证模式、旧执行者/已发请求写路径隔离、新恢复权威代次、专用资源权限边界及无法证明时hold；同时对账恢复点后的外部效果。验收增加旧实例复活和恢复点后已执行动作。
+4. **暂未查到结果不足以安全重试。** 初稿“查询确认未执行”可能被理解为目标当前无结果；旧请求稍后完成则重复副作用。现要求确定未执行的终态及旧执行者/已发请求不会再生效的证明；普通查询空结果、发送取消或本地退出均不充分。补外部请求延迟完成而恢复者不得发第二次请求的故障场景。
+
+作者另核实并修正一处事实表述：Native已有tool intent/result与safe replay机制，Backend生产Session已接线；本案复用该基础，将其与run/epoch/hold关联、指定统一恢复裁决，而不是重建第二套彼此独立的恢复政策。证据命令原始输出由Dev任务卡make evidence保存。
+
+## 最终对象与检查
+
+主方案SHA256：`cfc9b768a4596a268810e20101cddc2a6040e24a640e6e34dbda17b838cd45ed`。
+固定源码对象：Dev `5e57029b439e5690f28dc6002f9784f0b08920eb`，Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`；任务分支中的后续提交只记录启动/同步元数据，业务源码未改变。
+
+任务卡保留precheck、task-sync、源码调查、Native接线核对以及最终文档检查的工具收据。检查范围为差异空白、相对链接、需求/增量/决策ID、证据完整性；通过仅证明对应文档检查，不证明服务或数据恢复。
+
+草稿、入口和子仓改动尚未提交为固定组合；`check-evidence.py`对含未提交非任务卡改动的收据报告`unverified`。原始输出及方案内容摘要已保存，这些记录仅作为本地调查辅助，不能用于正式合入/运行验收。后续正式审核应先固定候选组合、同步并由有权审阅者重放对应检查，不能靠反复执行或更换来源标签消除此限制。
+
+实施前仍需人工确认故障档/RPO/RTO、目标实例与独占管理权、数据归属清单和在途任务分工。按policy/delivery.md，此次审阅与候选修正不能代替任何阶段的人工批准。
+
+## 第二轮：外部源码复核（2026-10-11）
+
+复核者：ZCode 独立上下文；对象：r1（SHA256 `cfc9b768…`）。方法：对主案第2节差距表、基线与自审记录引用的源码断言逐项独立重验；未运行服务、测试或故障试验。来源SELF。
+
+核验结果（抽查全部命中）：五个基线SHA与任务工作区一致且Dev基线为HEAD祖先；`svc.sh:1373` resolve_db_config统一解析；runmgr `ReconcileInterrupted`（≈2046）统一封印中断；`SetRecoveryHold`与`RenewExecution`均仅有定义、无生产调用；`claimCommand` pending→consumed后执行（kill窗口无重领）；app.go HTTP停机超时（现状5秒）即返回并跳过`mgr.Shutdown`事件清冲；`ListSurfaceEventsPending`默认limit=100；notice启动载入内存队列、投递后独立DELETE非事务；native `loop.go:385–402`工具结果持久化后继续模型回合。
+
+修订处置（r1→r2，需求与指标未变）：
+1. U3补停机预算来源变更：现状5秒须显式替换为批准预算并实测校准。
+2. U1验收补“更换二进制路径/程序版本、不同cwd调用svc后身份一致”场景（对齐R2）。
+3. U4补“新增公开状态前先交付Core→Backend→Frontend→下游最小状态映射表”。
+4. 第9节svc-autorecover协调改为明确的人工二选一归属决策项（实施载体 vs 放弃合并，两权威不得并存）。
+
+流程修订：r1先按被审对象原样提交固定（documents `54fc24e`、Dev `39f719f`），r2为后续修订提交；恢复会话按门禁完成precheck（READY，R0 `555fb2162f`）并task-sync后实施修订。r2 SHA256：`9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd`。
+
+遗留（人工事项）：svc-autorecover归属二选一、首批实施范围、故障档/RPO/RTO与停机预算批准；全部指标维持待批准未实测。
+
+### 追加（2026-10-11 task-sync 后）：漂移检查与 svc-autorecover 实况
+
+- task-sync 将 backend 指针由 eb12f102 前移至 25fbea85（collab-storage U5-outbox #157 合入）。漂移检查（工具收据见任务卡证据表）确认 r2 引用的差距在新指针全部成立：RenewExecution 与 SetRecoveryHold 仍无生产调用、claimCommand 仍为认领即 consumed、HTTP 停机超时仍跳过事件清冲、Surface 待投影默认仍 100 条。该合入新增 `EnqueueCommandInTx`（与业务提交同事务投递命令）与 `AppendEvents` 内同事务 `pg_notify`，属 KTD10 可直接复用的原语，不改变差距结论。
+- svc-autorecover 实况修正归属决策的信息基础：其工作区并非空壳，含未提交的 autostart 期望态 + `svc.sh recover`（postgres 先于应用）+ systemd 用户级 watchdog（每分钟拉回）+ `.start.lock` 生命周期锁 + pidfile/cmdline 校验（svc.sh +317 行、docs/svc.md +61 行、Makefile +10 行）及回归测试 tests/test_svc_recover.py；但任务卡零登记（无 precheck 收据、无卡内记录、无提交），且 2026-10-11 观察其自测 10 例中 5 例未过（failures=2、errors=3）——定位是“有价值的半成品”，不是可合入实现。选项 (a)（作 U2 实施载体）价值因此上调，但需先补登记（precheck/任务卡/提交）、修复未过用例，并与本案 manifest 合同（KTD1/KTD2）对齐；选项 (b) 则须显式处置这批在途工作而非视同空白。裁定仍属人工。
+
+## 批准记录（2026-10-12）
+
+用户（weichen）批准方案 r2（拆解/评估/需求表/方案设计/实施计划五阶段一并），并裁定 svc-autorecover 归属选项 (a)：作 U2 实施载体，先补登记、修复未过用例、对齐 KTD1/KTD2。实施按第 7 节 U1–U7 与批次 A/B/C 推进；量化指标（RPO/RTO/停机预算）在对应增量验收前固定。来源：用户对话（本记录为 SELF 转述）；阶段评审明细见 Dev 任务卡。方案 r2 正文未因批准改动（SHA256 9cfda252… 不变），批准状态以本记录、任务卡与 INDEX 为准。
+
+### 落地追踪（2026-10-12 补记）
+
+裁定后核实：svc-autorecover 在途工作已由另一会话完成并合入 main——PR #396（autostart 期望态 + recover + watchdog）、#400（任务卡回填）、#401（KillMode=process 修复）、#402（闭卡归档）。归档卡验证摘要：tests/test_svc_recover.py 10/10、make test-governance 146/146（SELF）、CI GATE 绿（PR HEAD e0b49d1，test+test-pg，一次抖动重跑）；如实登记的残留：postgres 实例真实 recover 仅代码审查未实测、agent SQLite 数据目录尚无自动备份。裁定 (a) 的“补登记、修复未过用例”已被事实完成；其对齐要求（KTD1/KTD2 manifest 合同、服务组依赖与单一监管者）转为 U2 余量增量。本记录早前“373 行未登记半成品”的表述为当时（2026-10-11）观察，已被后续事件取代。

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,85 @@
+# 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. 放行
+
+B6、C4 为 SELF 通过。C5 的库恢复为 SELF 通过，工件恢复失败。第二实例写流量仍不放行。
+
+还没做、本任务不启动的两项：
+
+- 独立 REPLAY，或把 C4/C5 的快速档接进 CI 成为 GATE（需要平台准入）。
+- C3 双主机。
+- 上传在未配置对象存储时 panic，需要单独的产品修复后才能重测 K4。