Merge Documents main into svc unified-deploy proposal branch

Why: Dev #422 conflicted on modules/documents gitlink after main advanced past the proposal pin.

docs/guides/architecture-overview.md

@@ -0,0 +1,213 @@
+# Agent-System 系统结构与架构
+
+> 基准：Agent-System-Dev 组合 `218fc4b1ba00b0a03b5bb79f292b3eba6c987a58`（R0，2026-10-08 锚点核验）。
+> 行号为该提交下的函数入口位置（个别内部区段为约略范围），随代码演进漂移；文件与函数名是稳定锚点。
+> 文中路径均为 Dev 组合仓内相对路径。
+
+---
+
+## 1. 总体形态：一个父仓 + 12 个子模块仓的组合系统
+
+Agent-System 是**多仓组合（gitlink 固定指针）**的开发集成父仓，不是单一代码库。
+`.gitmodules` 定义了 12 个子仓，分两类：
+
+**modules/（5 个产品模块仓）**
+
+| 仓 | 目录 | 定位 | 技术栈 |
+|---|---|---|---|
+| Agent-System-Core | `modules/core` | 核心契约库：纯数据类型 + 线格式权威，零第三方依赖 | Go（附 `ts/types.ts` TS 镜像） |
+| Agent-System-Backend | `modules/backend` | 后端模块化单体，默认单二进制（内嵌前端 + 嵌入式 SQLite） | Go |
+| Agent-System-Frontend | `modules/frontend` | Web 前端 | React 19 + Vite + TypeScript |
+| Agent-System-UI | `modules/ui` | 纯展示组件库：props 进 events 出，不持状态不调 API | React + CSS 令牌 |
+| Agent-System-Documents | `modules/documents` | 文档过程仓（设计提案/记录/报告），无代码 | Markdown |
+
+**deps/（7 个基础库仓）**
+
+| 仓 | go module 名 | 一句话职责 |
+|---|---|---|
+| agent-native | `agent-native` | Agent 执行内核：ReAct 循环、LLM 客户端、工具注册表、会话转录、MCP、技能 |
+| agent-squad | `agent-squad` | 小队编排底座：规划器、Leader 委派、黑板、HITL 挂起恢复、调度 |
+| agent-intent | `agent-intent` | 确定性意图识别：四级漏斗（Guard→Expectation→Rules→Adjudicate） |
+| agent-command | `agent-command` | 命令总线基础库：命令 spec、危险分级、审计信封（零依赖） |
+| error-code-system | `error-code-system` | 跨系统错误码目录 + HTTP 错误信封 + 查询服务 |
+| logging-system | `logging-system` | 结构化日志库 + 采集服务 |
+| development-guidelines | —（非 Go） | 人与 Agent 共用的开发规范文档基线 |
+
+**依赖方向铁律**（`README.md`）：
+
+```
+frontend → core ← backend → { agent-native, agent-squad, agent-intent, agent-command }
+                                        ↘ error-code-system / logging-system
+```
+
+core 与各生态仓互不依赖；backend 对 8 个库的引用经自己仓内 `deps/` 子模块 +
+`modules/backend/go.mod` 的 `replace` 收敛（父仓顶层 `deps/` 与 `modules/backend/deps/`
+是同一批仓的两份 gitlink，`scripts/check-pins.sh` 核对一致）。仓库**不使用 go.work**
+（避免工作区最小版本选择抬高 backend 单独构建的依赖版本，见 `PROJECT.md`）。
+
+**三态一致的契约机制**：core 的每个契约同时存在 ① Go 类型（camelCase JSON）、
+② `modules/core/testdata/golden/*.json` 黄金样本（线格式权威）、③ `modules/core/ts/types.ts`
+手工 TS 镜像。父仓 `make contracts` 把 TS 镜像生成到 frontend 与 ui 的 `src/contracts.ts`。
+
+---
+
+## 2. Backend 功能分布（产品核心）
+
+单二进制入口：`modules/backend/cmd/agent-system/main.go`（子命令 serve/version/apikey/user/config）。
+组合根与装配顺序在 `modules/backend/internal/app/app.go` 的 `Run()`：
+存储 → 总线 → 工具注册 → settings/prompts/skills/profiles → runmgr（三个 runner + SquadRunner 注入）→
+intentgate → 插件宿主 + hostapi → workflow 注册表 → RAG → 可选 intentsem →
+cardsvc/cmdbus → server + 限流 + 认证 → HTTP 监听（默认 `127.0.0.1:8787`）。
+
+### internal 包职责一览（功能 → 代码分布）
+
+| 包 | 主文件 | 职责 |
+|---|---|---|
+| app | `internal/app/app.go` | 组合根：装配一切组件 |
+| config | `internal/config/config.go` | 启动配置单一管道：内置默认→`--config` JSON→环境变量→CLI |
+| store | `internal/store/store.go` | 持久化唯一入口；SQLite（默认，modernc 纯 Go）/ PostgreSQL 双档；`dialect.go` 方言收敛、`migrate.go` 版本化迁移 |
+| blobstore | `internal/blobstore/blobstore.go` | 工件对象存储抽象，默认本地目录 `<data>/artifacts/` |
+| bus | `internal/bus/bus.go` | 进程内事件总线：按会话转发已持久化事件给 SSE 订阅者 |
+| pgbus | `internal/pgbus/pgbus.go` | PG 档跨实例扇出：`NOTIFY/LISTEN agent_events` |
+| cmdbus | `internal/cmdbus/cmdbus.go` | 命令总线宿主：button/card/slash/chat 四入口归一分发、危险命令确认卡、审计 |
+| cardsvc | `internal/cardsvc/cardsvc.go` | 收件箱任务卡服务（card.* 事件投影） |
+| runmgr | `internal/runmgr/runmgr.go` | **Run 生命周期枢纽**：状态机、事件持久化+广播、HITL、子代理任务树、工具执行策略、取消级联 |
+| route | `internal/route/route.go` | 唯一意图 Router：命令总线 > 工作流 > 普通回合 |
+| intentgate | `internal/intentgate/gate.go` | 意图闸门：接入 agent-intent 库，插件意图 overlay |
+| intentsem | `internal/intentsem/scorer.go` `generator.go` | 意图慢通道：embedding 语义重排 + 轻量模型命令生成（默认关） |
+| runtime | `internal/runtime/runner.go` `llm.go` `llm_direct.go` `sub_loop.go` `workflow_compiled.go` `squad_runner.go` `model.go` | 四类 Runner（LLM/Mock/Sub/Squad）+ 工作流执行入口 + 模型路由 |
+| wfcompile | `internal/wfcompile/run.go` `compiler.go` | 工作流编译执行驱动：编译图 → 小队引擎装配 → 步进循环 → critic 终判 |
+| ctxasm | `internal/ctxasm/ctxasm.go` `finish.go` | 上下文组装与预算裁剪 |
+| prompts | `internal/prompts/service.go` | 提示词模块库：embed 内置 + DB 用户覆盖链 |
+| skills | `internal/skills/skills.go` | 内置技能种子（go:embed recipes → `<data>/skills/`） |
+| tools | `internal/tools/registry.go` | 统一工具注册表：内置/声明式 HTTP/插件工具同形态 |
+| plugins | `internal/plugins/host.go` `host_v2.go` | 插件宿主：fail-closed 热加载；sidecar 进程拉起 |
+| hostapi | `internal/hostapi/server.go` | sidecar 本机回调面 `/host/v1`（127.0.0.1 随机端口 + 随机 token） |
+| workflow | `internal/workflow/registry.go` | 工作流**定义**注册表（编译执行器在 wfcompile） |
+| ingest / docgen / rag / quality | 各主文件 | 文档摄取 → ParsedDocument IR；Markdown→docx；混合检索 rerank；交付物六维打分 |
+| profiles / settings / ratelimit | 各主文件 | 画像；system→user→project 分层设置；租户限流（内存/Redis） |
+
+### 其他目录
+
+- `modules/backend/pkg/extension/`：对下游仓的**公开扩展面**（下游只许依赖本包与 core，
+  `surface.txt` 锁导出面）；`link/` 把 extension.Main 接回组合根。
+- `modules/backend/web/embed.go`：`go:embed` 内嵌前端构建产物。
+- `modules/backend/deps/`：8 个库的 submodule 副本（replace 目标）。
+
+---
+
+## 3. 前端与 UI 分工
+
+- **frontend**（`modules/frontend/src/`）：`App.tsx` 四栏布局 —— 左（项目/会话树
+  `TaskSidebar.tsx`）、中（流式对话 `Conversation.tsx` + `ProcessTimeline.tsx`）、
+  预览区（`PreviewPane.tsx` / `ArtifactsPanel.tsx`）、右（工作台卡流 `Workbench.tsx`）。
+  职能文件：`api.ts`（HTTP 客户端）、`live.ts`（SSE 到达序投影纯逻辑）、
+  `store.ts`、`runstate.ts`、`pluginHost.ts`、`outbox.ts`。
+- **ui**（`modules/ui/src/`）：只渲染词汇有限的 UI schema —— `UIRenderer.tsx`、
+  `InboxList.tsx`、`InlineConfirmCard.tsx`（危险命令确认卡）、`ToolBlock.tsx`、
+  `tokens.css`（设计令牌唯一来源）。frontend 经 `@ui` 别名直接源码组合（`vite.config.ts`）。
+
+---
+
+## 4. 通信架构：HTTP + SSE，无 WebSocket
+
+- **全部 HTTP 路由**集中在 `modules/backend/internal/server/server.go` 的 `Handler()`
+  （约 90 条 `mux.HandleFunc`）：auth/users、projects/conversations/messages、cards、
+  artifacts/uploads、profiles/prompts/settings、tools/plugins、commands/audit、
+  plan/todos、knowledge、hitl 等。
+- **SSE** 是唯一增量通道：`GET /api/events?conversationId=...`（`server.go:171` 注册，
+  `server.go:275` 处理器），带 `Last-Event-ID`/`since` 游标重放；项目级流用伪会话键
+  `project:<id>`（`modules/core/events.go:30` `ProjectChannelKey`）。全仓 grep 无 websocket。
+- **事件三层转发**：
+  1. `runmgr/events.go` 事件缓冲：高频 delta 合并（150ms/64 条，`events.go:42-43`），先落
+     store（会话内单调 seq）再 `bus.Publish`（`events.go:83`）；
+  2. `internal/bus` 内存总线 → 在线 SSE 订阅者；
+  3. `internal/pgbus`（仅 PG 多实例档）：事务提交后 NOTIFY，其他实例 LISTEN 后按 seq 从库
+     取回转发本地 bus。
+- **事件词汇**全部定义在 `modules/core/events.go` 的 `StreamEvent` 信封
+  （message.delta / thinking.delta / tool.* / run.phase / hitl.request / plan.update /
+  agent.spawn / agent.progress / card.* / artifact.* 等 20+ 类型）。
+
+---
+
+## 5. 持久化与磁盘布局
+
+- 主库：`<data>/agent-system.db`（SQLite，FTS5 全文 + CJK LIKE 兜底）或 PostgreSQL
+  （`--dsn`，pgx 驱动）；迁移双方言可回滚；租户隔离靠 owner 列硬过滤。
+- 工件：`<data>/artifacts/`（blobstore 本地档，Put 原子落盘）+ store 登记。
+- 技能：`<data>/skills/`（内置种子 + 用户覆盖）。
+- 工作区沙箱：`<data>/workspaces/<owner>/<conversationID>/`（fs 工具根）。
+- 小队运行态：编排目录下 `runs/<run_id>/*.json`（磁盘即权威，见小队篇）。
+- 本机服务实例（`scripts/svc.sh` 管理）：`runtime/dev/`（agent 后端 + SQLite）、
+  `runtime/pg1/`（PostgreSQL）；`data/`、`data-test/` 为默认/测试数据目录。
+
+---
+
+## 6. 插件系统
+
+- 契约：`modules/core/plugin.go`（manifest v1：tools/workflows/intents/prompts/panels/
+  cards/commands 等 provides）；`modules/core/plugin_v2.go`（2.0-experimental 窗口：
+  PluginScope 可见性、PluginBackend{inproc|sidecar}、技能/MCP/知识集/解析器/代理声明）。
+- 宿主：`modules/backend/internal/plugins/host.go` —— 「manifest + 声明资产 + 可选代码」，
+  任一资产解析失败整批拒绝（fail-closed），支持热加载 `Reload`；`host_v2.go` 拉起 sidecar
+  进程（注入 `AGENT_HOST_API`/`AGENT_HOST_TOKEN` 环境变量）。
+- sidecar 回调经 `internal/hostapi/server.go` 的 `/host/v1`（kv/audit/commands/llm/search）；
+  进程内插件走 `pkg/extension`（EXT-1）+ `link` 包。
+- 示例：父仓 `plugins/example/`、`examples/sidecar-demo/`、`examples/downstream-rdm/`。
+
+---
+
+## 7. 端到端数据流（用户输入 → 结果返回）
+
+```
+用户输入（中栏）
+  │  POST /api/conversations/{id}/messages        server.go:574 postMessage
+  ├─ "/" 前缀 → cmdbus 命令总线（不启 run，server.go:623）
+  ├─ 附件   → ingest.Parse 文档摄取（并行，互不依赖，server.go:643）
+  ├─ 意图识别 → intentgate（agent-intent 四级漏斗，server.go:655）
+  ├─ 路由裁决 → route.Decide                      route.go:60
+  │     ├─ KindCommand   → cmdbus.Dispatch（直接执行命令）
+  │     ├─ KindWorkflow  → runmgr.StartClaimedWorkflowRun（:996）
+  │     └─ KindTurn      → runmgr.StartClaimedConversationRun（:991）
+  ├─ runmgr 建 Run（pending）落库 → 选 Runner（runmgr.go:918）→ go execute()
+  │     ├─ LLMRunner             → agent-native 内核 ReAct 循环（默认）
+  │     ├─ CompiledWorkflowRunner → wfcompile 编译执行（可由规划子代理生成）
+  │     └─ SquadRunner           → squadadapter → agent-squad 引擎
+  ├─ 一切增量皆事件 → runmgr 缓冲 → store（seq 权威）→ bus → SSE
+  └─ 前端 live.ts 到达序投影 → 中栏对话 / 右栏卡流 / AgentTracker
+```
+
+- HITL：`hitl.request` 卡片（choice/input/confirm/form）→ 用户 `POST /api/hitl/{id}/resolve`
+  → `runmgr.ResolveHITL`（runmgr.go:1261）恢复或转轨。
+- 工件：产物落 blobstore + store → `artifact.created` 事件 → 预览区；quality 六维打分。
+
+---
+
+## 8. 设计文档索引
+
+架构权威文档在 `modules/documents/docs/proposals/`：
+
+- 整体：`2026-09-29-system-skeleton-design-and-plan.md`（骨架设计 + D1–D16 决策，主设计）、
+  `2026-09-30-dual-tier-storage-and-multitenancy.md`（双档存储/多租户）、
+  `2026-10-01-base-extension-roadmap.md`（基座不可改、下游二开）。
+- Agent 栈：`2026-10-01-agent-harness.md`（回合循环、多代理编排）、
+  `2026-10-02-agent-stack-completion.md`（通用智能体/小队/意图）、
+  `2026-10-07-agent-stack-n1q1i1-plans.md`、`n2-plan.md`、`n3-plan.md`（N 系列阶段方案）。
+- 其他：卡片流/收件箱/命令总线/工作区（2026-09-30 三篇）、插件契约 v2、UI 重构等。
+
+---
+
+## 9. 关键文件速查
+
+| 想了解什么 | 看哪里 |
+|---|---|
+| 程序入口与装配 | `modules/backend/cmd/agent-system/main.go`、`internal/app/app.go` |
+| 全部 HTTP 路由 | `modules/backend/internal/server/server.go`（`Handler()`） |
+| Run 状态机与事件 | `modules/core/model.go`、`modules/core/events.go`、`internal/runmgr/runmgr.go` |
+| Agent 执行循环 | `deps/agent-native/runtime/loop.go`、`internal/runtime/llm_direct.go` |
+| 意图识别 | `deps/agent-intent/intent/`、`internal/intentgate/gate.go`、`internal/route/route.go` |
+| 小队引擎 | `deps/agent-squad/squad/`、`internal/squadadapter/adapter.go`、`entry.go` |
+| 工作流 | `internal/workflow/registry.go`（定义）、`internal/wfcompile/`（编译执行）、`internal/runtime/workflow_compiled.go`（入口） |
+| 工具体系 | `modules/core/tools.go`、`internal/tools/registry.go`、`internal/runmgr/runmgr.go:740` |
+| 提示词/技能 | `internal/prompts/service.go`、`internal/skills/skills.go` |
+| 前端投影 | `modules/frontend/src/live.ts`、`src/store.ts` |

docs/guides/intent-recognition.md

@@ -0,0 +1,292 @@
+# Agent 的意图识别：架构、模型与调用链
+
+> 基准：Agent-System-Dev 组合 `218fc4b1ba00b0a03b5bb79f292b3eba6c987a58`（R0，2026-10-08 锚点核验）。
+> 行号为该提交下的函数入口位置（个别内部区段为约略范围），随代码演进漂移；文件与函数名是稳定锚点。
+> `internal/` 指 `modules/backend/internal/`。
+
+---
+
+## 1. 一句话结论
+
+意图识别是**"确定性规则漏斗为主体、语义向量与 LLM 为可选慢通道（默认关闭）"的混合
+分层架构**：识别主体在独立库 `deps/agent-intent`（零 LLM 依赖），backend 通过
+`internal/intentgate` 闸门接入，识别结果由 `internal/route` 统一裁决为
+命令 / 工作流 / 普通回合三分支。
+
+---
+
+## 2. 识别架构：四级漏斗
+
+核心识别器 `FunnelRecognizer`（`deps/agent-intent/intent/recognizer.go:23`，
+入口 `Recognize` 在 `recognizer.go:41`，内部 `recognize` 在 `:71`），四级依次短路：
+
+| 级 | 名称 | 行为 | 代码 |
+|---|---|---|---|
+| Stage 0 | 守卫（guard_hit） | 守卫域 spec 命中即短路，表达"识别即拒绝" | `recognizer.go` 守卫分支 |
+| Stage 1 | 挂起预期（expectation_hit） | 多轮澄清场景：宿主注入 `ExpectationProvider` 声明上轮预期意图 | 接口 `intent/expectation.go:17` |
+| Stage 2+3 | 规则计分 + 置信度裁决 | 全部非守卫 spec 线性扫描（`intent/registry.go` 规则计分与裁决），`score = base + (正则命中 ? pattern_bonus : 0)`，上限 1.0；唯一过阈或前两名分差 ≥ margin（默认 0.1）→ **matched**，同分比 priority → 否则 **ambiguous**，无命中 → **fallback** | `intent/spec.go:17-29`（默认值）、`recognizer.go:146` 附近同分裁决 |
+| Stage 4 | 慢通道（可选） | ambiguous → 语义向量重排 `semanticRerank`（`recognizer.go:292`）；fallback → LLM 命令生成 `generateCommands`（`recognizer.go:333`） | 见下节 |
+
+识别分支共五种（`deps/agent-intent/intent/result.go`）：
+`guard_hit / expectation_hit / matched / ambiguous / fallback`。
+
+---
+
+## 3. 用什么模型：三层各自不同
+
+| 层 | 是否 LLM | 实现与模型来源 | 状态 |
+|---|---|---|---|
+| 规则层（守卫/计分/裁决） | **否，永不引入** | 纯 Go 确定性计算。设计文档明确规则层永不引入 LLM（`deps/agent-intent/docs/records/2026-09-29-decoupling-and-llm-layering.md` §2.1） | **主体，默认生效** |
+| 语义重排（SemanticScorer） | 向量模型（非生成式） | `modules/backend/internal/intentsem/scorer.go:18` `EmbeddingScorer`：对输入与 spec 的 examples 各取向量算最大余弦相似度。Provider 走 OpenAI 兼容 `/embeddings`（`internal/rag/embed.go`），模型/端点来自 settings `models.embedding.*`；默认阈值 0.8（`intent/spec.go`） | 可选，**默认关**（settings `runtime.intentSemantic`） |
+| 命令生成（CommandGenerator） | 生成式 LLM | `modules/backend/internal/intentsem/generator.go:18` `LightGenerator`：走 `agentllm.Client.Stream`，用**轻量档模型**（`internal/runtime/model.go:84` `ResolveLightweightModel`，settings `models.lightweight.model`，缺省回落主 chat 档），MaxTokens 默认 1024；system prompt 在 `generator.go:100-129`（只暴露 id/描述/槽位键，防提示词注入） | 可选，**默认关**（settings `runtime.intentGenerator`） |
+| Classifier（LLM 重打分，L2） | 生成式 LLM | 接口在 `intent/classifier.go:9` | **接口预留，backend 未接线** |
+
+慢通道装配点：`modules/backend/internal/app/app.go:351,357`（开关开启才
+`gate.SetSemantic(...)` / `gate.SetGenerator(...)`）。关闭时行为与纯规则版完全一致。
+
+**失败安全**：agent-intent 库本体零 LLM 依赖，只定义 `SemanticScorer`
+（`intent/semantic.go:9`）与 `CommandGenerator`（`intent/generator.go:14`）窄接口由
+宿主注入；所有慢通道失败均回退规则结论（fail-open/closed 到 safe 分支），识别永不因
+LLM 失败而失败。生成器幻觉有校验兜底：`validateGenerated`
+（`recognizer.go:368`）要求 action.id/槽位键必须都在目录内，否则 fail-closed 回 fallback。
+
+---
+
+## 4. 意图目录（Intent Catalog / Schema）
+
+意图定义 `IntentSpec`（`deps/agent-intent/intent/spec.go:74` 附近，Go 注册与 JSON overlay 共用）：
+
+- **标识**：`id`（必须 `domain.助记` 多段，`spec.go:122` 校验）、`domain`、`version`、
+  `description`、`priority`、`disabled`。
+- **matcher**（`spec.go:32-39`）：`includes_any / includes_all / excludes_any` 词表 +
+  `patterns` 正则 + `case_sensitive` + `boundary`（词界匹配，压制中文子串误命中）。
+- **slots**（`spec.go:44-62`）：`key/required/pattern(抽取正则)/group`，加 HITL 字段
+  `label/question`（建议澄清提问）与校验链 `enum/format/normalize/validator`。
+- **confidence**（`spec.go:66-70`）：base 默认 0.7、pattern_bonus 默认 0.2、threshold 默认 0.6。
+- **动作绑定**：`action`（kind ∈ command/workflow/blueprint/handler，`intent/command.go:32-43`）
+  优先，其次 `metadata["blueprint"]`、再次 `handler`，否则 auto（宿主在命令总线与工作流间裁决）。
+- **risk**（low/medium/high）+ `requires_confirm`（透传宿主做授权确认）。
+- **examples**：示例句数组——语义慢通道按它们算相似度。
+
+配置文件形态（`intent/loader.go:12-19`）：
+
+```json
+{ "intents": [ { …IntentSpec… } ], "disable": ["demo.run.status_query"] }
+```
+
+插件可经 `intents/*.json` overlay 注入（`internal/plugins/host.go:216-220` 采集）。
+样例：`deps/agent-intent/examples/specs/demo.json`。
+
+识别产物命令集（`intent/command.go:11-26`）：`start / set_slot / change_slot / cancel /
+clarify / chitchat / handoff`；规则漏斗只产出 start/set_slot/clarify（`deriveCommands`
+在 `command.go:85`）。能力目录 `Snapshot.Catalog()` / `CatalogMarkdown()`
+（`intent/catalog.go:36,68`）把启用意图渲染为 Markdown，供小队规划者/Leader 提示词注入
+（`deps/agent-squad/adapters/intent/catalog.go` 消费）。
+
+## 4.5 内置与默认意图：默认是空目录
+
+**系统默认不内置任何意图**：backend 组合根 `intentgate.New()`（`app.go:309`）起步是空注册表，
+`g.Match` 在空闸门下直接透传（未启用 = 行为回退，所有消息走普通回合）。意图只能经两条
+overlay 路径进入，且**两种路径的文件形态不同**：
+
+| 路径 | 文件形态 | 装载方 |
+|---|---|---|
+| 插件 overlay（产品路径） | **裸数组** `[ {…IntentSpec…}, … ]` | `plugins/host.go:216-220` 按元素透传 → `gate.Rebuild`（gate.go:104）逐个 unmarshal 成 IntentSpec |
+| registry/loader（库路径：intentctl、BuildFS） | 包装对象 `{"intents":[…], "disable":[…]}` | `intent/loader.go:21` `overlayDoc`，严格 JSON（未知字段报错） |
+
+仓库自带两份样例意图（即"默认能看到的意图"上限——装载对应插件/配置后生效）：
+
+- `plugins/example/intents/demo.json`（插件形态）：`demo.show`（命中"示例/演示"，无槽位）、
+  `demo.brief`（命中"简报"，必填槽位 `topic`，抽取正则 `主题[:：]\s*(\S+)`，缺槽问"主题是什么？"）。
+- `deps/agent-intent/examples/specs/demo.json`（loader 形态）：`demo.run.status_query`
+  （命中"进度/状态"、排除"配置"，槽位 `run_id`，base=0.8/threshold=0.7，handler=`taskrun.query_status`）、
+  `demo.run.restart`（需同时含"重启"+"任务"，`requires_confirm=true`，risk=medium）。
+
+---
+
+## 4.6 实测：一句话怎么被打分、填槽、命中
+
+以下全部为 `intentctl explain` 在样例配置上的**真实输出**（2026-10-08 实测；例 5/6 的配置目录
+= 两份样例意图合并）。打分公式：`score = base + (正则命中 ? pattern_bonus : 0)`（封顶 1.0），
+前两名分差 < `margin`（默认 0.1，`intent/registry.go:55`）判 ambiguous。
+
+**例 1｜命中 + 抽到槽位**（输入"查一下任务 run_42 的进度"）：
+
+```
+分支：matched
+Top：demo.run.status_query 置信度=0.8000 风险=low 确认=false handler=taskrun.query_status
+  槽位 run_id="run"
+候选（1）：
+  0.8000  demo.run.status_query        terms=进度
+裁决轨迹：
+  margin=0.1000
+  守卫：未评估
+  规则 命中 demo.run.status_query        0.8000 进度
+  规则 排除 demo.run.restart             no_positive_match
+```
+
+要点：`terms=进度` 命中词表加 0 分（base 已含）；`restart` 因 `includes_all:["任务"]` 缺"重启"
+被排除（`missing_includes_all`）。槽位 `run_id="run"` 是真实结果——槽位正则
+`(?:run|任务)[:# ]*([A-Za-z0-9-]+)` 的字符类不含下划线，捕获在 `run` 后被 `_` 截断：
+**规则识别完全确定性，槽位 pattern 的质量决定抽取质量**（写 `[A-Za-z0-9_-]+` 即可取到 `run_42`）。
+
+**例 2｜命中但缺必填槽位**（输入"写一份简报"，`demo.brief` 装载时）：
+
+```
+分支：matched
+Top：demo.brief 置信度=0.7000
+  缺失必填槽位：topic
+裁决轨迹：
+  规则 命中 demo.brief                   0.7000 简报
+  规则 排除 demo.run.restart             missing_includes_all:任务
+  规则 排除 demo.run.status_query        no_positive_match
+  规则 排除 demo.show                    no_positive_match
+```
+
+`Missing=[topic]` 连同 spec 的 `question:"主题是什么？"` 一起随 route 进入工作流 run，
+由 HITL 输入卡向用户澄清（见调用链第 10 步）。
+
+**例 3｜槽位填上**（输入"主题：核能 写一份简报"）：同一意图 matched，
+`槽位 topic="核能"`，Missing 为空——正则 `主题[:：]\s*(\S+)` 命中，直接启动。
+
+**例 4｜什么都不像**（输入"随便聊聊今天的天气"）：
+
+```
+分支：fallback
+裁决轨迹：
+  规则 排除 demo.run.restart             missing_includes_all:任务
+  规则 排除 demo.run.status_query        no_positive_match
+```
+
+无命中 → fallback；若装载了语义慢通道（`runtime.intentSemantic`，默认关）会先尝试 embedding
+重排，仍不达阈才 fallback。gate 把 fallback 折叠后 `route.Decide` 判 `KindTurn` → 普通对话回合。
+
+**例 5｜能力目录实测**（`intentctl catalog`，这段 Markdown 就是注入小队规划者/Leader
+提示词的内容，`squad/engine.go:44` 注释明示用途）：
+
+```
+# 系统能力目录（意图快照 revision=1）
+
+以下能力可直接调用，无需派智能体执行。子任务命中其一时，输出携带 intent_id 的步骤并填齐必填槽位；
+必填槽位信息不足时不要编造，改为向用户澄清（优先使用各槽位的提问建议）。
+
+## demo.brief — 写一份简报。必填槽位 topic，没写就问「主题是什么？」。
+- 风险：low；执行前需人工确认：否
+- 槽位 topic（必填，topic）
+  - 提问建议：主题是什么？
+```
+
+---
+
+## 4.7 一句话里有多个意图怎么办
+
+意图层的契约是**一条输入只产出一个 Decision**（top-1），不做多意图拆分。多个候选的
+裁决顺序固定为：
+
+1. **分差裁决**：唯一过阈，或第一名领先 ≥ margin → 直接 matched。
+2. **同分且 priority 不同 → 高优先级直接胜出**（I5，不标歧）。实测（"帮我生成一份报告"，
+   两个意图 base 都是 0.7、词表都命中"报告"）：template 设 `priority:10` 后
+   `分支：matched，Top：demo.report.template 置信度=0.7000`。
+3. **分差 < margin（含同分同优先级）→ ambiguous**，先走可选语义重排 `semanticRerank`
+   （`recognizer.go:292`，默认关）→ 再走 Classifier L2 重打分（backend 未接线）→ 都没有则
+   **保持 ambiguous**。实测同配置去掉 priority 后：
+   `分支：ambiguous，候选（2）：0.7000 demo.report.generate / 0.7000 demo.report.template`。
+4. ambiguous 经 gate 折叠 → `KindTurn` → **交给普通 LLM 回合**：模型在一次 ReAct 循环里
+   自行处理多个请求（这也是多数"一句话多个事"的实际归宿——意图层只接管高确定性的
+   命令/工作流类请求）。
+5. 多轮场景：Stage 1 挂起预期（`ExpectationProvider`）让澄清中的输入优先回到挂起意图；
+   HITL 自由输入命中其他意图时会**取消挂起 run 并转轨**（`runmgr.go:1261` `ResolveHITL`），
+   相当于允许用户中途改道。
+
+---
+
+## 5. 端到端调用链：用户输入一条消息后发生了什么
+
+| # | 步骤 | 调用方 → 被调方 | 位置 |
+|---|---|---|---|
+| 1 | HTTP 入口 | 路由注册 `POST /api/conversations/{id}/messages` | `internal/server/server.go:168`（注册）、`:574` `postMessage` |
+| 2 | slash 短路 | `/` 前缀非技能命令 → `handleCommand`（`server.go:756`）→ 命令总线，**不进意图识别** | `server.go:623` |
+| 3 | 附件摄取 | `ingest.Parse(name, mime, content)` → `core.ParsedDocument`（与意图识别并行、互不依赖） | `server.go:643`；`internal/ingest/ingest.go` |
+| 4 | 识别调用 | `s.recognize(ctx, text)`（端口 `NLIntentGate`，`server.go:79-85`） | `server.go:655` |
+| 5 | 进入闸门 | `intentgate.Gate.Recognize` | `internal/intentgate/gate.go:137` |
+| 6 | 四级漏斗 | `FunnelRecognizer.Recognize(ctx, input, reg.Snapshot())` | `gate.go:144` 附近 → `deps/agent-intent/intent/recognizer.go:41` |
+| 7 | 结果投影 | 库 `Result` → `MatchResult{Branch, ID, Slots, Missing, Commands}`；guard/expectation 折叠为 fallback；缺槽位附 spec 的 Question | `gate.go:148-176` |
+| 8 | 统一路由 | `route.Decide(recognized, route.Env{HasCommand, WorkflowFor, SquadReady})` | `server.go:656`；`internal/route/route.go:60` |
+| 9a | 命令分支 | KindCommand → `s.Bus.Dispatch`（Entrance="chat"，槽位透传 Params） | `server.go:701-717` |
+| 9b | 工作流分支 | KindWorkflow → `mgr.StartClaimedWorkflowRun`（缺槽位列表随行） | `server.go:725`；`internal/runmgr/runmgr.go:996` |
+| 9c | 回合分支 | KindTurn → `ClaimConversation` 抢槽 → `AppendMessageWithRequest` 落库 → `mgr.StartClaimedConversationRun` | `server.go:679, 727`；`runmgr.go:980, 991` |
+| 10 | 澄清/HITL | 工作流缺必填槽位 → 逐个发 `HITLCard{Kind:Input, AllowFreeInput}` 人工输入卡 | `internal/wfcompile/run.go:47` 起 `RunCompiled` 槽位补齐段 |
+| 11 | HITL 转轨 | `POST /api/hitl/{id}/resolve` → `mgr.ResolveHITL`：自由输入以 `/` 开头 → pivot=command；否则再过 `gate.Recognize` + `route.Decide`，命中其他意图则取消挂起 run 并 pivot | `server.go:883`；`runmgr.go:1261`（转轨判定 `:1293` 附近） |
+
+### 启动期装配链
+
+| # | 内容 | 位置 |
+|---|---|---|
+| A1 | `app.Run` 建 `gate := intentgate.New()` 并 `mgr.SetGate(gate)` | `internal/app/app.go:309-310`；`runmgr.go:142` |
+| A2 | 插件装载回调：`pluginHost.OnIntents = overlay → gate.Rebuild(overlay)`（fail-closed：解析失败保留上一快照） | `app.go:324`；`internal/plugins/host.go:216-220`；`gate.go:96` |
+| A3 | 开关开启时接线慢通道：`gate.SetSemantic(intentsem.EmbeddingScorer{…})` / `gate.SetGenerator(intentsem.LightGenerator{…})` | `app.go:351,357`；`gate.go:66,75` |
+
+---
+
+## 6. intentgate 与 intentsem 的分工
+
+- **intentgate**（`internal/intentgate/gate.go`）：宿主闸门适配器。持 Registry +
+  FunnelRecognizer；负责插件 overlay 装载（`Rebuild`，`:96`）、分支折叠（非
+  matched/ambiguous 一律折叠为 fallback，`gate.go:148-155`）、补槽位 Question、
+  类型投影（让 runmgr/route 只依赖本包表面）、慢通道接线（`:66,75`）。
+  **不做缓存**——识别是纯函数 Query，快照不可变无锁读（`intent/registry.go`）。
+- **intentsem**（`internal/intentsem/`）：慢通道实现包。`EmbeddingScorer` 出错原样上抛
+  （库保持 Ambiguous）；`LightGenerator` 解析失败/模型不可达返回错误（库保持 fallback）。
+
+---
+
+## 7. 识别结果的去向与失败路径
+
+- 识别结果 `Result`（`intent/result.go`）是**纯内存 Query 结果，不落库**（store 无
+  intent 表）。去向仅三处：① HTTP 响应；② logsys 结构化日志 `intent recognized`
+  （`recognizer.go:62` 附近，不记原文）；③ 作为 run 启动参数（workflow slots/missing、命令 ID）。
+- **ambiguous**（重排后仍歧义）→ gate 折叠 → `route.Decide` 返回 `KindTurn`
+  （`route.go:61-63`）→ 走普通 LLM 回合自由对话兜底（不是强制澄清）。
+- **matched 但缺必填槽位** → Commands=[start, clarify]（`intent/command.go:110` 附近）→
+  workflow 路径把 Missing（含建议 Question）传入 run → 发 HITL 输入卡澄清。
+- **guard_hit / expectation_hit** → 折叠为 fallback → turn。
+- **低置信度**（未过 threshold）→ fallback → turn。
+
+route 决策细节（`internal/route/route.go:55-114`）：优先级
+命令 > 工作流 > 普通回合；`blueprint` → `KindSquad`，但**当前不可达**——
+`server.go:664` 明确注释 `SquadReady 保持 false`（per-run entry 覆盖未就位），
+小队的实际启动走别的路径（见[小队与子 Agent 启动](squad-and-subagents.md)）。
+声明目标不可解析时不静默错配，回落 turn 并写 Reason。
+
+---
+
+## 8. 辅助工具与测试
+
+- `deps/agent-intent/cmd/intentctl/`：只读诊断 CLI（`lint` 校验配置+词条冲突、
+  `explain` 单条输入裁决轨迹（`recognizer.go:226` `Snapshot.Explain`）、
+  `eval` 语料评测 Precision/Recall、`catalog` 输出目录）。
+- `deps/agent-intent/conformance/conformance.go`：识别器公开契约行为验收
+  （分支/槽位断言 + 确定性 + 并发冒烟）。
+- `deps/agent-intent/catalogcheck/align_test.go`：断言库错误码与 Error-Code-System
+  intent 域种子码逐个相等，防两套平行权威。
+
+---
+
+## 9. 关键文件清单
+
+| 文件 | 职责 |
+|---|---|
+| `deps/agent-intent/intent/recognizer.go` | 四级漏斗识别器、语义重排（:292）、生成兜底（:333）、Explain 诊断（:226） |
+| `deps/agent-intent/intent/spec.go` | IntentSpec/MatchSpec/SlotSpec/ConfidenceSpec 定义与校验 |
+| `deps/agent-intent/intent/registry.go` | 编译、不可变 Snapshot、双源合并、原子 Reload |
+| `deps/agent-intent/intent/loader.go` | JSON overlay 加载 |
+| `deps/agent-intent/intent/command.go` | 命令模型 + deriveCommands（:85）展开 |
+| `deps/agent-intent/intent/catalog.go` | 能力目录与 Markdown 渲染（:36/:68/:128） |
+| `deps/agent-intent/intent/semantic.go` `generator.go` `classifier.go` `expectation.go` | 四个可注入端口 |
+| `deps/agent-intent/cmd/intentctl/main.go` | 诊断 CLI |
+| `modules/backend/internal/intentgate/gate.go` | 闸门适配器（overlay :96、投影、慢通道接线 :66/:75） |
+| `modules/backend/internal/intentsem/generator.go` `scorer.go` | LLM 命令生成（含 system prompt :100）/ embedding 重排 |
+| `modules/backend/internal/route/route.go` | 唯一 Router（Decide :60 三分支裁决） |
+| `modules/backend/internal/server/server.go` | 消息入口 postMessage(:574)、recognize(:655)、resolveHITL(:883)、SSE events(:275) |
+| `modules/backend/internal/plugins/host.go` | 插件 intents/*.json overlay 采集（:216-220） |
+| `modules/backend/internal/app/app.go` | 组合根装配（:309-310、:324、:351/:357） |

docs/guides/squad-and-subagents.md

@@ -0,0 +1,133 @@
+# 何时启动小队或子 Agent：触发条件与调用链
+
+> 基准：Agent-System-Dev 组合 `218fc4b1ba00b0a03b5bb79f292b3eba6c987a58`（R0，2026-10-08 锚点核验）。
+> 行号为该提交下的函数入口位置（个别内部区段为约略范围），随代码演进漂移；文件与函数名是稳定锚点。
+> `internal/` 指 `modules/backend/internal/`。
+
+---
+
+## 1. 一句话结论
+
+系统有两条"委派"线，都发生在**普通 run 的执行过程中**（小队不是独立的一层）：
+
+- **子代理（sub-agent）**：模型在回合中调用 `delegate_task` 工具 → runmgr 派生
+  `Kind=subagent` 的子 run（任务树）。
+- **小队（squad）**：三条触发路径 —— ① 设置 `runtime.entry=squad` 让**对话本身**
+  走 SquadRunner；② 模型调用 `squad_orchestrate` 工具；③ 演示消息含 `#squad`。
+  三者最终都汇入 `deps/agent-squad` 引擎。**成员执行统一走 agent-native 内核**
+  （legacy 的 agent-system 子 run 压缩路径已退役，`internal/squadadapter/adapter.go:289-292`
+  注释明示；后端缺席时 fail-closed，不静默降级）。
+
+另有第三种"规划委派"：`run_workflow` 触发的**规划子代理**（workflowPlannerID），
+见[任务规划与执行](task-planning-and-execution.md)第 7 节。
+
+---
+
+## 2. 子代理：`delegate_task` 触发链
+
+### 触发条件
+
+主对话模型判断某段工作适合独立完成（如长调研、批量整理）时，在 ReAct 循环里发出
+`delegate_task` 工具调用（工具名常量 `internal/runtime/llm.go:58`）。工具声明与门禁在
+`internal/runtime/llm.go:267-315`（编排型工具随上下文声明；子代理 spec 由 prompts 包提供
+tools/model/maxTurns 约束，**禁止子代理再持有派发类工具**，`internal/prompts/service.go`）。
+
+### 调用链
+
+| # | 步骤 | 位置 |
+|---|---|---|
+| 1 | 内核循环解析出 `delegate_task` 调用 → `runTool` 分派 | `internal/runtime/llm_direct.go:471` `runTool`，case 在 `:493` 起 |
+| 2 | 后台模式：经 rc 端口断言调 `SpawnBackground`；前台：`SpawnAgent` | `llm_direct.go:502, 516` 附近 |
+| 3 | runmgr 派生子 run | `internal/runmgr/runmgr.go:1348` `spawnSubagent` → `:1358` `startChild`（**深度检查**在此，注释 `:1356`） |
+| 4 | 建 `Kind=subagent` 子 run，`ParentRunID` 指向父 run（**任务树**） | `runmgr.go` startChild 内；契约 `modules/core/model.go:188` |
+| 5 | 发 `agent.spawn` 事件（前端 AgentTracker 可见） | `runmgr.go:1375` |
+| 6 | 独立 ctx 执行（后台模式 detach） | `runmgr.go` startChild 内 |
+| 7 | 子代理执行器 = `SubLLMRunner.Execute` —— 同样进入 `nruntime.Run` 内核循环（独立转录、按子代理 spec 收窄工具） | `internal/runtime/sub_loop.go:31` |
+| 8 | 完成回填 `AgentResultPayload`；结果截断 32000 字 | `runmgr.go:1401` `finishChild`；`runmgr.go:1780` `capSubagentResult` |
+
+### 后台子代理
+
+- `delegate_task` 可请求后台模式 → `spawnBackground`（`runmgr.go:1475`），
+  **每会话上限 3 个**（`runmgr.go` 常量）。
+- 后台子代理完成后不直接打扰当前回合，而是进通知队列：`deliverNotices`
+  （`runmgr.go:1560`）在会话空闲时以 system-reminder 消息启动一个新父回合汇报结果
+  （`startNoticeRun`，`runmgr.go:1616`）。
+- 取消级联：子 run 的 ctx 派生自父 run，`CancelRun`（`runmgr.go:1222`）取消根 run
+  即级联取消全部子 run。
+
+---
+
+## 3. 小队：三条触发路径
+
+### 路径 A：`squad_orchestrate` 工具调用（工具路径）
+
+| # | 步骤 | 位置 |
+|---|---|---|
+| A1 | 模型在回合中调用 `squad_orchestrate goal=...` | 工具名常量 `internal/runtime/llm.go:62`；声明 `llm.go:268` 附近 |
+| A2 | 声明门禁：settings `runtime.squad`（默认 true）开启才声明；**entry 已是 squad 时不再提供，避免套娃** | `internal/runtime/llm.go:467` `squadToolEnabled`；`:266` 注释 |
+| A3 | runTool 分派 → `squadadapter.Orchestrate(rc, dataDir, goalText)` | `internal/runtime/llm_direct.go:479` → `internal/squadadapter/adapter.go:47` `Orchestrate` |
+| A4 | 之后进入 agent-squad 引擎（规划→调度→质检） | 见[小队工作机制](squad-mechanics.md) |
+
+### 路径 B：对话入口模式（entry=squad）
+
+| # | 步骤 | 位置 |
+|---|---|---|
+| B1 | 灰度开关 `runtime.entry=squad`（默认 `direct`） | `internal/settings/settings.go:90` |
+| B2 | runmgr 选 Runner：`selectConversationRunner` 检查 `runtime.entry=="squad"` → 返回 SquadRunner | `internal/runmgr/runmgr.go:918`（注入点 `:908` `SetSquadRunner`，装配 `internal/app/app.go:306`） |
+| B3 | `SquadRunner.Execute`（`internal/runtime/squad_runner.go:26`）先做 **LLM 分诊**：`modelRouter.Route`（`:146`，轻量模型输出 JSON `direct|plan`，`parseRoute` :167）—— direct = 单步 assistant 直通（`deps/agent-squad/squad/router.go:55` `directAssistantPlan`）；plan = 进 Leader 委派（`router.go:29` `applyRoute` 设 `metadata["mode"]="leader"`） | |
+| B4 | plan 模式 → `squadadapter.RunEntry` → 引擎 leader 模式 | `internal/squadadapter/entry.go:42` `RunEntry`；`deps/agent-squad/squad/engine.go`（`RunOptions.Mode="leader"`，Options 注释 `engine.go:99-105`） |
+
+### 路径 C：演示/脚本
+
+用户消息含 `#squad` → MockRunner 走同样 `Orchestrate`（`internal/runtime/mock.go`）。
+
+### 一条"不可达"的路径（设计预留）
+
+意图识别绑定 `blueprint` 动作可路由到 `KindSquad`（`internal/route/route.go:96-97`），
+但当前**双重不可达**：`server.go:664` 明确注释 `SquadReady 保持 false`（per-run entry
+覆盖未就位）；且系统默认意图目录为空（见[意图识别](intent-recognition.md) 4.5 节），
+不装插件就没有意图可命中 blueprint。小队的实际启动走上面 A/B/C 三条路径；意图目录
+对小队的现实作用是注入规划者/Leader 提示词的能力目录（`deps/agent-squad/adapters/intent/catalog.go`）。
+
+---
+
+## 4. 装配（启动期）
+
+| 内容 | 位置 |
+|---|---|
+| runmgr 注入三个 runner（LLMRunner / SubLLMRunner / MockRunner），SquadRunner 经 `SetSquadRunner` | `internal/app/app.go:287-306` |
+| 角色指令来源接提示词库（`agent.squad.<kind>`） | `app.go:176` → `squadadapter.RoleInstructions`（`adapter.go:303`） |
+| agent-native 内核选项：模型路由、Tavily 搜索、解释器、MCP、技能根、Subagent 桥接、PermissionAsk、检查点 | `app.go:196` `squadadapter.AgentNativeOptions` |
+| 小队后端解析器：**只注册 `"agent-native"` 内核工厂**（legacy `"agent-system"` SpawnSubagent 压缩路径已退役删除；工厂缺席解析 fail-closed） | `internal/squadadapter/adapter.go:292` `BuildBackends`（退役注释 `:289-291`）；`entry.go:103` DefaultBackend="agent-native" |
+| 内核工厂注册 | `deps/agent-squad/adapters/native/register.go:61` `RegisterFull` |
+
+---
+
+## 5. 两条线的对比小结
+
+| | 子代理 delegate_task | 小队 squad |
+|---|---|---|
+| 触发者 | 主对话模型 | 设置开关 / 主对话模型 / 演示脚本 |
+| 执行单位 | 一个子 run（`Kind=subagent`） | 一组角色化步骤（每步一个 agent-native 内核 agent） |
+| 编排者 | 主对话（单层委派，子代理不可再委派） | agent-squad 引擎（DAG 调度 / Leader 循环） |
+| 并发 | 后台最多 3/会话 | 无写集冲突的步骤可并行 |
+| 深度 | 1 层（startChild 深度检查，`runmgr.go:1356-1358`；子代理 spec 禁派发工具） | 成员内核里的 `delegate_task` 经 `SubagentFactory`（`adapter.go:234`）桥回产品 `SpawnSubagent`，**深度恒为 1，子 run 不再嵌套小队** |
+| 汇总 | `AgentResultPayload` 回父 run | 交付物聚合 `output.md` → 主 run 工件（见[小队工作机制](squad-mechanics.md)） |
+
+---
+
+## 6. 关键文件清单
+
+| 职责 | 文件 |
+|---|---|
+| delegate_task 分派 | `internal/runtime/llm_direct.go:493` 起 |
+| 子 run 派生与任务树 | `internal/runmgr/runmgr.go:1348-1475`、`1560-1616` |
+| 子代理执行器 | `internal/runtime/sub_loop.go` |
+| 工具声明与门禁 | `internal/runtime/llm.go:267-315, 466-467` |
+| squad_orchestrate 分派 | `internal/runtime/llm_direct.go:479` |
+| 小队适配器（工具路径 + 后端组装 + Subagent 桥接） | `internal/squadadapter/adapter.go`（Orchestrate :47、SubagentFactory :234、BuildBackends :292、builtinRoles :306） |
+| 小队适配器（入口路径） | `internal/squadadapter/entry.go`（RunEntry :42、kernelRoles :177） |
+| 对话入口 Runner + LLM 分诊 | `internal/runtime/squad_runner.go`（Execute :26、Route :146） |
+| Runner 选择 | `internal/runmgr/runmgr.go:918` |
+| 灰度开关 | `internal/settings/settings.go:90` |
+| 装配 | `internal/app/app.go:176, 196, 287-306` |

docs/guides/squad-mechanics.md

@@ -0,0 +1,226 @@
+# 小队（Squad）工作机制：拆解、执行、汇总的完整调用链
+
+> 基准：Agent-System-Dev 组合 `218fc4b1ba00b0a03b5bb79f292b3eba6c987a58`（R0，2026-10-08 锚点核验）。
+> 行号为该提交下的函数入口位置（个别内部区段为约略范围），随代码演进漂移；文件与函数名是稳定锚点。
+> `internal/` 指 `modules/backend/internal/`；`squad/` 指 `deps/agent-squad/squad/`。
+
+---
+
+## 1. 一句话结论
+
+小队是 run 内的一种**编排执行模式**：由 agent-squad 引擎（`deps/agent-squad`）把目标
+拆成**角色化步骤 DAG**（规则规划器或蓝图模板），每一步交给一个"成员"执行——成员是
+按角色装配的 **agent-native 内核 agent**（独立执行循环；legacy 的 agent-system 子 run
+压缩路径已退役），无写集冲突的步骤并行推进，产出落子工作区并经**黑板**共享，收口时做
+六维质检与自动修复，交付物聚合回主 run。
+
+触发时机（何时启动）：settings `runtime.entry=squad`（对话即小队）、模型调用
+`squad_orchestrate` 工具、演示消息 `#squad`——详见[小队与子 Agent 启动](squad-and-subagents.md)第 3 节。
+
+---
+
+## 2. 概念模型（类型全部在 `deps/agent-squad/squad/models.go`）
+
+| 类型 | 位置 | 含义 |
+|---|---|---|
+| `RoleSpec` 角色 | models.go:25 | role/name、绑定执行后端 `Backend`（stub/llm/agent-native/…）、角色级 Model、工具白名单 Tools、技能 Skills、**BashPermission 三态 allow/ask/deny**、Keywords（规则规划器匹配用）、Instructions、HITL 策略、`MaxConcurrentTasks` 并发限流 |
+| `Goal` | models.go:48 | 目标文本 + Materials 附件 + Constraints + HITL 覆盖 |
+| `Blueprint` | models.go:64 | 任务模板：关键词命中即走基线步骤 |
+| `StepSpec` 步骤 | models.go:86 | Role、Targets（期望交付物文件，缺省 output.md）、`Writes` 写集（写集相交强制串行）、`Needs` 依赖、`Parallel`、`Critical`（失败即终止）、`MinScore` 质检门槛、`RequiresApproval`、`IntentID/IntentSlots`（系统功能步，不走智能体）、Attempts |
+| `WorkflowPlan` + `SquadConfig` | models.go:168, 179 | 拆解结果（与产品 squad workflow.json / squad.json 兼容） |
+| `BlackboardState` 黑板 | models.go:225 | Facts/Gaps/Implications/Assumptions/Fields —— 成员间协作的共享状态载体 |
+
+**小队成员 ≠ 常驻 agent**：成员 = 角色（RoleSpec）。每条步骤由
+`BackendResolver.Resolve`（`squad/backend.go`）解析出一个 Executor 并调用一次
+`Execute`。产品侧**只注册 agent-native 后端**（`internal/squadadapter/adapter.go:292`
+`BuildBackends`；`deps/agent-squad/adapters/native/register.go:61` `RegisterFull`），
+每步构造一个独立内核 agent 执行循环（模型/工具/搜索/MCP/技能根按 RoleSpec 装配）。
+
+---
+
+## 3. 小队 Run 状态机
+
+`squad/models.go:284` 起（`RunStatus`）：
+
+```
+created → planning → (awaiting_clarification | awaiting_confirmation)   ← HITL 挂起
+        → executing → (waiting_human | quality_review)                  ← HITL 挂起
+        → completed | degraded | failed | cancelled                     ← 终态
+```
+
+- 挂起态判定与适配：适配器 `isHoldStatus`（`internal/squadadapter/adapter.go:221`）据此进 HITL。
+- 挂起上下文 `HitlGate`（Request+Plan+PrevStatus）落盘 `pending.json`；`Respond`
+  （`squad/engine.go:637`）按多种 Kind 分派恢复：Clarification 答案并入 Goal 重新规划、
+  Confirmation、Gap、Escalation、Adjustment、Permission、QualityReview；执行态恢复走
+  `Resume`（`squad/engine.go:1127`）。
+
+**事件体系**：引擎 `squad.Event` 13 类（`squad/progress.go:10-24`：run_started /
+phase / step_started / completed / failed / skipped / detail / deliverable /
+human_input_required / human_responded / run_completed / failed / cancelled）。
+产品侧不直连 bus：`onSquadEvent`（`internal/squadadapter/adapter.go:185`）把 step_* 映射为
+`core.EvAgentProgress`，计划经 `mapPlan`（`adapter.go:200`）映射为 `rc.UpdatePlan` →
+`core.EvPlanUpdate`，成员子 run 发 `core.EvAgentSpawn` —— 统一进事件流，**前端可看到
+小队进展**（`modules/frontend/src/store.ts`、`contracts.ts` 消费 agent.spawn/plan.update/agent.progress）。
+
+**运行状态持久化（磁盘即权威）**：`workspace.json / workflow.json / squad.json /
+blackboard.json / pending.json / runstate.json / usage.json`
+（`squad/runstate.go:13` 注释、`:81` `persist`）；崩溃恢复 `Resume → recoverInterrupted`
+（产物已齐判完成防副作用翻倍）。支持运行中 Steering 与黑板字段注入自动唤醒 `SweepWakeups`。
+
+---
+
+## 4. 端到端调用链（以 `squad_orchestrate` 工具路径为主线）
+
+| # | 步骤 | 位置 |
+|---|---|---|
+| 1 | 触发：`llm_direct.go:479` case toolSquad → `squadadapter.Orchestrate` | `internal/runtime/llm_direct.go:479` → `internal/squadadapter/adapter.go:47` |
+| 2 | 编排进度卡（可选）：创建 `CardKindProgress` 卡，终态置态 | adapter.go `Orchestrate` 内（CardSink 端口 `:40`） |
+| 3 | 注册内置角色 `builtinRoles()`（`adapter.go:306`）：规划员/调研员/撰稿员/审校员，**全部 Backend=agent-native**；工具白名单按角色最小化（全员含 write_file，步骤须自己落盘交付物）；撰稿员 `BashPermission=ask` + docx/xlsx/pptx-author 技能，其余角色 Bash=deny；指令来源 `RoleInstructions`（:303，接提示词库 `agent.squad.<kind>`） | |
+| 4 | 组装后端 `BuildBackends`（`adapter.go:292`）：只注册 `"agent-native"` 内核工厂（组合根 `AgentNativeOptions`，`internal/app/app.go:196`）；legacy `"agent-system"` 已退役；工厂缺席 fail-closed | |
+| 5 | 组装引擎 `squad.NewEngine(Options{…})`：Planner=RulePlanner、Checker=quality.Checker、RepairBudget、HitlPolicy、Sink=ProgressFunc(onSquadEvent)；引擎默认 `DefaultBackend="stub"`（`squad/engine.go:169-170`）、单步超时默认 10 分钟（Options 注释 `:32`） | `adapter.go` Orchestrate 内；`squad/engine.go` |
+| 6 | `SquadEngine.Run`（`squad/engine.go:234`）：生成 `run_<UTC时间戳>` ID → `acquire`（`:213`，进程内 mutex + flock 文件锁，单 run 单控制操作）→ `EvRunStarted` → 可选**意图闸门**一次裁决（GuardHit→Reject；命中 blueprint→定向模板；否则不干预；实现 `deps/agent-squad/adapters/intent/gate.go`） | |
+| 7 | **任务拆解（规划）** `planAndExecute`（`squad/engine.go:335`）：先 Router 分诊；未 direct 则蓝图匹配 + `Planner.Plan`（`squad/planner_rule.go:20`）。产品用 **RulePlanner（确定性规则，非 LLM）**：命中 Blueprint 直接用模板步骤/编制（`fromBlueprint`，planner_rule.go:27）；未命中走四阶段骨架 **梳理(organizer)→专项(specialist)→成文(writer)→终审(leader)**（planner_rule.go:85 起），注册表缺角色时 `Registry.Derive` 现场派生并置 `NeedsConfirmation`。LLM 规划器已实现（`squad/planner_llm.go`，严格 JSON+重试+Fallback）但产品未接。拆解结果持久化 `runs/<run_id>/workflow.json + squad.json`（`squad/runstate.go:81` `persist`） | |
+| 8 | 澄清/确认挂起：规划歧义 → `awaiting_clarification`；派生编制 → `awaiting_confirmation`（leader 模式豁免）。适配器驱动循环（`adapter.go` Orchestrate 内）：hold 态 → `askHuman`（`adapter.go:150`，HumanRequest→core.HITLCard→`rc.AskHITL`）→ `engine.Respond`（`engine.go:637`）；执行态 → `engine.Resume`（`engine.go:1127`）。每次推进后 `mapPlan`（`adapter.go:200`）把 WorkflowPlan 映射为右栏计划快照 | |
+| 9 | **工作区物化**：`PrepareWorkspace`（`squad/workspace.go:27`）+ `BuildSubWorkspaces`（workspace.go:127）：每步建 `tasks/NN_<role>/` 子工作区，把 `context/`（goal.md、材料原文 + textextract 抽取文本、index.json）与 template.md 快照进去（`snapshotContextInto` workspace.go:160），并写 **TASK.md**（`writeTaskFile` workspace.go:182：黑板快照、权威等级资源表、产出要求——成员靠它读前序产出）与 **AGENTS.md**（`writeAgentsFile` workspace.go:224：角色指令） | |
+| 10 | **调度执行** `flowDriver.advance`（`squad/workflow.go:25`）：每轮从权威 Steps 现场编译调度图 `compileGraph`（`squad/graph.go:23`：Needs 依赖或相邻 Parallel 同层，环 fail-closed）→ 分并行/串行层 → **无写集冲突的步骤并行**（`runParallel` workflow.go:216，goroutine+WaitGroup，关键失败 cancel 全组），写集冲突按声明序串行 → `gateBeforeRun`（workflow.go:175：bash ask 角色授权 / 步骤审批的 HITL 门）→ `runOneStep` | |
+| 11 | **单步执行** `runOneStep`（`squad/workflow.go:262`）：置 running、Attempts++ → 写 TASK.md → 组装 ExecRequest（ToolAllowlist/Skills/SessionScope/Budget/OnEvent 过程帧）→ 后端 `Execute`（系统功能步改走 IntentRunner）→ 瞬态失败重试并注入重试提示 → **交付物落盘校验** `missingTargets`（workflow.go:1071）→ 完成：`mergeStepArtifacts` 把子工作区 `fields.json/gaps.json` 并入黑板（`squad/blackboard.go:43`）→ `checkBlockingGaps`（workflow.go:652：interactive 挂 HitlGap 卡、auto 记兜底假设继续）→ 每步后可动态调整（评估器加步/跳步）。superstep 边界写检查点快照，Resume 时校验图指纹防形态漂移 | |
+| 12 | **成员执行（统一 agent-native）**：`RegisterFull`（`adapters/native/register.go:61`）按角色构造独立内核 agent（模型/工具/搜索/MCP/技能根按 RoleSpec+BashPermission 装配），过程帧经 eventTap 桥为 `EvDetail`。内核里的 `delegate_task` 经 `SubagentFactory`（`adapter.go:234`，SpawnBackground `:266` / SpawnSubagent `:273`）桥回产品 SpawnSubagent，**深度恒为 1，子 run 不再嵌套小队** | |
+| 13 | **Leader 委派模式**（entry=squad 的 plan 分诊）：`RunOptions.Mode="leader"`（`squad/engine.go:99-105` Options 注释；轮次上限 `MaxLeaderTurns` 默认 8，`squad/leader.go:48` `DefaultMaxLeaderTurns`）——规划被委派循环取代：每轮重写 leader 的 TASK.md（目标+黑板+委派历史）与 AGENTS.md（协调契约），leader 后端执行产出 **delegation.json**（action=delegate/escalate/close/failed）；delegate：临时建 StepSpec、跑 runOneStep、交付快照进 leader 的 `inbox/<stepID>/`、再唤醒 leader 评估（一轮只委派一个成员）；escalate → HitlEscalation 挂起；超限按现有产出降级收口。核心状态与提示词装配：`LeaderState`（leader.go:57）、`DelegationRecord`（:81）、`delegation`（:91）、`leaderPrompt`（:126）、`leaderExecRequest`（:16） | |
+| 14 | **汇总与质检（收口）** `finalize`（`squad/workflow.go:784`）：最后 completed 步骤的主产出复制为 `output.md` → `Checker.Check`（`internal/quality/checker.go:16` 附近 → `score.go`：六维启发式评分——结论先行/结构/完整性/证据/可执行性/可读性；**Passed = 总分≥70 且无单维<40**，score.go:28,72；docx 走段落提取；可选 housestyle lint）→ 未过写 `quality-feedback.md`（checker.go:29）并自动修复 `rerunForRepair` 重跑交付步骤（workflow.go:913）→ 仍不过：interactive 转 `quality_review` 人工裁决（approve=manualPass、retry 追加预算但受上限 `MaxRepairGranted`，`squad/termination.go:14`）→ 写 `manifest.json`（全文件 sha256 防篡改）→ `EvRunCompleted` | |
+| 15 | **聚合回主 run**：`Orchestrate` 返回 summary，交付物经 `rc.WriteArtifact("squad-<runID>.md")` 登记为主 run 工件；`RunEntry` 返回 `EntryResult{Summary, Body}`（`entry.go:34`），SquadRunner 做**虚假交付检查**（`internal/runtime/squad_runner.go:95` 附近 `claimsFalseDeliverable`）后落工件并 `SetAssistantParts`（squad_runner.go:107）。所有 usage 按角色聚合进 `RunResult.Usage` | |
+
+---
+
+## 4.5 实测：离线小队演示（真实输出）
+
+`deps/agent-squad` 自带离线演示（`cmd/agent-squad demo -keep`，stub 脚本成员 + 规划脚本 +
+自动应答 HITL，无需 LLM/网络），以下为其 2026-10-08 实测输出摘录。**引擎机制与产品完全
+同一套**，差异只有三处：成员后端是脚本（产品是 agent-native 内核）、规划器是 MockPlanner
+（产品默认 RulePlanner）、HITL 自动应答（产品走 HITL 卡片）。
+
+```
+═══ agent-squad 离线演示（stub 智能体 + mock 规划器 + HITL）═══
+
+[1] 注册角色（手动注册，backend=demo 脚本智能体）
+    + researcher 调研专员   + writer 撰写专员   + reviewer 审核专员
+
+[2] 发起运行：调研便携式超声诊断仪并产出报告
+    ✔ step_01_research  researcher  市场与技术调研，回填事实与缺口
+      step_02_draft     writer      汇总调研产出，撰写报告初稿
+      step_03_review    reviewer    一致性终审并产出终版
+
+[3] ⏸ HITL 挂起（gap）：发现 1 个阻塞缺口，需要人工补充信息后才能继续：
+      - [gap_1] 目标年产量未提供，影响成本测算（owner=agent）
+     → 自动回应：choice="resolved" answer="年产量 10 万套"
+    ✔ step_01_research   ✔ step_02_draft   ✔ step_03_review
+
+[4] 运行终态：completed
+    步骤 3 个（完成 3/跳过 0/失败 0）。质检得分 100。
+    交付物: <dataDir>/runs/run_20261008T090457.882598947/output.md
+    黑板字段: {"annual_volume":"100000","budget":"15万","device_class":"二类",
+              "review":"passed","target_market":"中国"}
+```
+
+对应真实落盘的工作区（`runs/<run_id>/`）——与第 4 节调用链逐项对应：
+
+```text
+runs/run_20261008T090457.882598947/
+├── context/goal.md, context/index.json     # 9. 目标与材料快照
+├── tasks/01_researcher/                    # 9. 每步一个子工作区
+│   ├── TASK.md        # 步骤任务书（角色、期望产出、资源权威等级、黑板快照、产出要求）
+│   ├── AGENTS.md      # 角色指令
+│   ├── context/       # 快照进来的目标/材料
+│   ├── notes.md  fields.json  gaps.json     # 成员产出（黑板来源）
+│   └── execution.log
+├── tasks/02_writer/{TASK.md,AGENTS.md,context/,output.md,...}
+├── tasks/03_reviewer/{TASK.md,AGENTS.md,context/,output.md,fields.json,...}
+├── blackboard.json                          # 11. 黑板（字段在步骤间累积）
+├── workflow.json  squad.json  runstate.json # 7. 拆解结果与运行态（磁盘即权威）
+├── checkpoints/{001,002,latest}.json        # 11. superstep 检查点
+├── output.md  manifest.json                 # 14. 聚合交付物 + sha256 清单
+└── .lock                                    # 6. acquire 的 flock 文件锁
+```
+
+`tasks/01_researcher/TASK.md` 实拍（节选）：
+
+```markdown
+# 步骤任务：市场与技术调研，回填事实与缺口
+- 角色：调研专员（researcher）
+- 期望产出：[notes.md fields.json gaps.json]
+## 任务上下文资源与权威等级（已快照到本目录，只引用本地路径）
+| 资源路径 | 权威等级 | 用途说明 |
+| `context/goal.md` | **authoritative** | 运行目标 | 不可推翻 |
+## 黑板快照（共享状态）
+## 产出要求
+1. 按期望产出文件名落盘到本子目录；
+2. 结构化事实回填 `fields.json`（字符串键值）；
+3. 发现信息缺口且无法假设时写 `gaps.json`（[{"item":"…","blocking":true}]）。
+```
+
+产品的默认拆解（RulePlanner 四阶段骨架，`squad/planner_rule.go:79` 起）与演示计划同构，
+真实代码里的步骤与交付约定：
+
+```go
+// 通用四阶段骨架：梳理 → 专项 → 成文 → 终审
+{"step_01_organizer", "梳理目标背景与输入材料，产出事实与缺口", "organizer"},
+{"step_02_specialist", "围绕目标开展专业分析与推演", "specialist"},
+{"step_03_writer",     "汇总各角色产出，撰写交付物初稿", "writer"},
+{"step_04_leader",     "一致性终审与交付把关", "leader"},
+// 非末步 targets = ["notes.md","fields.json"]（事实经黑板传给后步）；末步 = ["output.md"]
+```
+
+注册表缺角色时 `Registry.Derive` 现场派生（名为"organizer 专员"等）并置
+`NeedsConfirmation` → `awaiting_confirmation` 挂起等用户确认编制。意图目录注入规划器/
+Leader 的形态见[意图识别](intent-recognition.md) 4.6 节例 5 的 catalog 实测输出。
+
+---
+
+## 5. 小队如何"协作"
+
+- **黑板（Blackboard）**是协作中枢：Facts（已确认事实）/Gaps（信息缺口）/
+  Implications/Assumptions/Fields。每步完成后子工作区的 `fields.json`/`gaps.json`
+  合并进黑板（`squad/blackboard.go:43` `mergeStepArtifacts`）；下一成员的 TASK.md 带
+  黑板快照，据此读前序产出。字段注入可自动唤醒挂起的 run（`SweepWakeups`）。
+- **材料溯源**：输入材料经 `deps/agent-squad/textextract/` 提取纯文本并注入页码锚点，
+  成员引用材料时可标注出处。
+- **防失控上限**：`squad/termination.go` 集中管理修复预算、Leader 轮数等终止条件。
+
+---
+
+## 6. 与 runmgr / workflow 的关系
+
+- 小队**不是独立的一层**：它是 conversation run 内的一种执行模式/入口（`runtime.entry`）
+  或 run 内 LLM 的一次工具调用，在 runCtx 上同步驱动。
+- 成员执行的子 run 经产品 `SpawnSubagent` 进任务树（仅限内核 `delegate_task` 桥接）；
+  工作流（`run_workflow` → wfcompile 编译执行）是另一条平行机制——注意 wfcompile 执行时
+  **也装配到 squad 引擎上步进**，entry=squad 时不再提供 `run_workflow` 声明（互斥，
+  `internal/runtime/llm.go:266-268`）。
+- 依赖方向：agent-squad 核心只依赖 error-code-system（不感知内核）；依赖由 adapters
+  层单向引入——`agent-squad/adapters/native` 同时依赖 agent-native 与 agent-squad；
+  backend require 两者并 replace 到自己 `deps/` 下的库副本。
+
+---
+
+## 7. 关键文件清单
+
+| 职责 | 文件 |
+|---|---|
+| 全部类型与状态机 | `deps/agent-squad/squad/models.go`（RoleSpec :25、StepSpec :86、BlackboardState :225、RunStatus :284） |
+| 门面（Run/Respond/Resume/Inspect/Steer） | `deps/agent-squad/squad/engine.go`（Run :234、acquire :213、planAndExecute :335、Respond :637、Resume :1127） |
+| 调度/单步/收口 | `deps/agent-squad/squad/workflow.go`（advance :25、gateBeforeRun :175、runParallel :216、runOneStep :262、checkBlockingGaps :652、finalize :784、rerunForRepair :913、missingTargets :1071） |
+| DAG 编译与图指纹 | `deps/agent-squad/squad/graph.go`（compileGraph :23） |
+| Leader 委派 | `deps/agent-squad/squad/leader.go`（DefaultMaxLeaderTurns :48、LeaderState :57、leaderPrompt :126） |
+| 规划器（规则/LLM/端口） | `squad/planner_rule.go`（Plan :20、fromBlueprint :27）、`planner_llm.go`、`planner.go` |
+| direct/plan 分诊 | `squad/router.go`（applyRoute :29、directAssistantPlan :55） |
+| 状态持久化（磁盘即权威） | `squad/runstate.go`（persist :81） |
+| 工作区/TASK.md/AGENTS.md | `squad/workspace.go`（PrepareWorkspace :27、BuildSubWorkspaces :127、writeTaskFile :182、writeAgentsFile :224） |
+| 黑板合并 | `squad/blackboard.go`（mergeStepArtifacts :43） |
+| 事件 | `squad/progress.go`、`store/eventsink.go` |
+| 后端解析器 / 防失控上限 | `squad/backend.go`、`termination.go` |
+| backend 工具路径适配 | `internal/squadadapter/adapter.go`（Orchestrate :47、askHuman :150、onSquadEvent :185、mapPlan :200、isHoldStatus :221、SubagentFactory :234、BuildBackends :292、builtinRoles :306） |
+| backend 入口路径适配 | `internal/squadadapter/entry.go`（RunEntry :42、kernelRoles :177） |
+| 对话入口 Runner + LLM 分诊 | `internal/runtime/squad_runner.go`（Execute :26、Route :146） |
+| 质检打分（六维） | `internal/quality/checker.go`、`score.go` |
+| 内核接成小队执行器 | `deps/agent-squad/adapters/native/register.go`（RegisterFull :61） |
+| 意图闸门/能力目录 | `deps/agent-squad/adapters/intent/gate.go`、`catalog.go` |
+| 独立 CLI（serve/run/demo） | `deps/agent-squad/cmd/agent-squad/` |

docs/guides/task-planning-and-execution.md

@@ -0,0 +1,246 @@
+# Agent 的任务规划与执行：架构与调用链
+
+> 基准：Agent-System-Dev 组合 `218fc4b1ba00b0a03b5bb79f292b3eba6c987a58`（R0，2026-10-08 锚点核验）。
+> 行号为该提交下的函数入口位置（个别内部区段为约略范围），随代码演进漂移；文件与函数名是稳定锚点。
+> `internal/` 指 `modules/backend/internal/`；`core/` 指 `modules/core/`；
+> `nruntime/` 指 `deps/agent-native/runtime/`。
+
+---
+
+## 1. 一句话结论
+
+系统有**两套并存的规划机制**：
+
+1. **默认主线 = LLM 自主规划（ReAct 循环）**：没有预置 DAG。普通消息由 backend
+   `LLMRunner` 驱动，进入 `deps/agent-native` 自研内核的单轮循环
+   （组装上下文 → 调 LLM → 解析工具调用 → 执行工具 → 回填 → 直到模型不再调工具），
+   模型可用 `update_plan` / `update_todos` 工具自主维护任务列表（右栏 Plan/Todos 面板）。
+2. **可选结构化路径 = WorkflowDef（数据化步骤列表）**：可由意图绑定启动，也可由模型
+   调用 `run_workflow goal=...` 触发"规划子代理生成步骤 → 用户 HITL 确认 → 编译执行"
+   （`internal/runtime/workflow_compiled.go:91` `planCompiledWorkflow`）。工作流的
+   编译与步进执行在 `internal/wfcompile` 包，执行时**装配到小队引擎上步进**
+   （挂起 → HITL 卡 → Respond；执行态 → Resume），收口带 critic 终判。
+
+执行主体分两层：backend 的 `runmgr`（Run 生命周期/事件/持久化/策略）+
+`internal/runtime`（各 Runner）；真正的智能体循环内核在 `deps/agent-native/runtime/loop.go`。
+
+---
+
+## 2. Run 生命周期与状态机
+
+契约定义在 `modules/core/model.go`：
+
+- `RunStatus`（model.go:166）：
+  `pending → running → (waiting_hitl ⇄ running) → completed | failed | cancelled | interrupted`
+- `RunPhase`（model.go:178）：`thinking → acting → responding → finalizing → done`
+- `RunKind`（model.go:158）：`conversation | subagent | tool`；
+  `Run` 结构体（model.go:188）含 `ParentRunID`（任务树）、Usage、Error。
+
+状态迁移代码位置（均在 `internal/runmgr/runmgr.go`）：
+
+| 迁移 | 代码位置 |
+|---|---|
+| 创建（pending） | `:1023` `startClaimedRun`（建 Run + `store.CreateRun`，`internal/store/messages.go:120`） |
+| 运行 | `:1055` 附近 `execute`（置 running/thinking） |
+| HITL 挂起/恢复 | `:449` `AskHITL` 置 waiting_hitl；`:1261` `ResolveHITL` 恢复 running |
+| 终态 | `:1087` `finishRun` → `internal/store/recovery.go:125` `SettleRun`（条件 UPDATE + 同事务写权威助手消息树，防并发双终态）→ 发 `run.completed/failed` |
+| 取消 | `:1222` `CancelRun`（根 run ctx 取消，子 run 派生自父 ctx 天然级联；并唤醒 HITL 等待） |
+| 停机中断/重启对账 | `:1655` `InterruptRunning`、启动时 `:1689` `ReconcileInterrupted` |
+| 会话并发控制 | `:980` `ClaimConversation`（一会话至多一个在途 run，忙返回 409，`server.go` 错误映射） |
+
+---
+
+## 3. 端到端调用链（普通消息 → 结果落库）
+
+| # | 步骤 | 位置 |
+|---|---|---|
+| 1 | HTTP 入口 `postMessage`：附件经 `ingest.Parse`；`/` 命令不启 run；意图识别 + `route.Decide` 三分支 | `internal/server/server.go:574`；路由调用 `:656` |
+| 2 | 抢会话槽位 + 消息落库（幂等 requestId） | `server.go:679` → `runmgr.go:980`；`server.go:686` 附近 `AppendMessageWithRequest` |
+| 3 | 启动 run：工作流回合 `StartClaimedWorkflowRun`（定义深拷贝进 Launch，插件卸载不影响在跑副本）；普通回合 `StartClaimedConversationRun` → `startClaimedRun`：建 Run 落库 → 注册 runHandle → `selectConversationRunner` → 附件原件落工作区 → `go m.execute(rc, runner)` | `server.go:725,727`；`runmgr.go:991, 996, 1023-1043`；runner 选择 `runmgr.go:918` |
+| 4 | `LLMRunner.Execute`（`internal/runtime/llm.go:198`）准备阶段：模型路由 `ResolveChatModel`（`internal/runtime/model.go:54`，settings `models.chat.*` + 画像 ModelRoute，密钥经 SecretLookup）；`@knowledge` 显式引用触发 RAG（llm.go:216 附近）；system 段 `prompts.Service.ResolveSystem`（`internal/prompts/service.go:290`）；上下文组装 `ctxasm.AssembleInput`/`FinishAssembly`（`internal/ctxasm/ctxasm.go:45`、`finish.go:97`，产出 `ContextObservation` 随 run.completed 下发）；工具声明（编排型内置 + 注册表过滤，llm.go:267-315；计划模式过滤 `filterPlanDecls` llm.go:332） | |
+| 5 | 进入内核：`l.runDirect(...)`（`internal/runtime/llm_direct.go:95`）把声明包成内核工具注册进 `agenttools.NewRegistry`、打开转录 journal（`<sandbox>/.agentx/transcript.jsonl`）、接线 Stop 钩子（交付物门禁 + 验证器）、调 `nruntime.Run(...)` | |
+| 6 | **内核 ReAct 单轮循环** `nruntime.Run`（`deps/agent-native/runtime/loop.go:196`，`for turn < cfg.MaxTurns` 默认 12）：① ctx/预算检查 → ② `prepareRequest`（loop.go:787：转录投影 + 窗口清理 + 记忆注入 + reminders）→ ③ `consume` 流式消费 LLM 事件（loop.go:492）→ ④ 持久化 assistant → ⑤ 有工具调用：`executeTools`（loop.go:595，可并行），每个 `runOne`（loop.go:709）走完整性校验 → `gateTool`（hooks PreToolUse，ask 决策交宿主 PermissionAsk）→ commitToolIntent（崩溃恢复配对）→ `cfg.Tools.Execute` → AfterTool，结果按 Role=tool 回填 → `continue` 下一轮 → ⑥ 无工具调用：`ContinueOnLength` 续写（loop.go:399）+ follow-up drain + Stop 钩子决定续跑（`stopDecision` loop.go:645；宿主侧做交付物门禁与验证，最多 3 次续跑）→ `settle` 结束；轮数耗尽报 max turns exceeded（loop.go:447） | |
+| 7 | 工具执行回落宿主：编排型工具在 runner 内消化——`squad_orchestrate` → squadadapter.Orchestrate（case 在 `llm_direct.go:479`）、`delegate_task` → rc 端口 `SpawnBackground`/`SpawnAgent`（`llm_direct.go:493` 起）、`update_plan/update_todos` → `rc.UpdatePlan/UpdateTodos`、`run_workflow`、`submit_card/card_*`（各 case 依次在 `llm_direct.go:471` `runTool` 内）；其余 → `rc.ExecuteTool`（`runmgr.go:740`）：画像三清单 → policy.Decide（计划模式 deny / ask→HITL 确认卡）→ `registry.Execute`（`internal/tools/registry.go:94`）→ 结果截断转工件 | |
+| 8 | 子代理 run（任务树）：`spawnSubagent/startChild`（`runmgr.go:1348/1358`，startChild 做深度检查）建 `Kind=subagent` 子 run（ParentRunID 指父）→ 发 `agent.spawn`（`runmgr.go:1375`）→ `finishChild`（`runmgr.go:1401`）跑 `SubLLMRunner.Execute`（`internal/runtime/sub_loop.go:31`，同样调 `nruntime.Run`）→ 子转录独立落盘 → 结果截断 32000 字（`runmgr.go:1780` `capSubagentResult`）。后台子代理：`spawnBackground`（`runmgr.go:1475`，每会话上限 3）；完成后 `deliverNotices`（`runmgr.go:1560`）在会话空闲时以 system-reminder 启动新父回合汇报（`startNoticeRun`，`runmgr.go:1616`） | |
+| 9 | 终态收敛：`finishRun`（`runmgr.go:1087`）usage 汇总 → 终态消息树（tool_call/tool_result/thinking/card 部件）→ `SettleRun` 单事务落库 → submit_card 回填锚点 → 发 `run.completed`（含 ContextObservation）/`run.failed`。工件：`runCtx.WriteArtifact` → `store.CreateArtifact` → `artifact.created` 事件 → 文本进检索索引；工件作为 `PartArtifactRef` 挂进助手消息树 | |
+
+完成判定者 = 内核循环 + 宿主 Stop 钩子组合：模型不再调工具且无 follow-up → Stop 钩子
+（交付物门禁说谎检测、可选验证器）决定续跑或放行 → 可选用主模型 `composeFinal` 重写
+最终回复（`nruntime/compose.go`）→ `finishRun` 落终态。
+
+---
+
+## 4. LLM 调用与流式
+
+- **不用第三方 SDK**，自研 HTTP 客户端 `deps/agent-native/runtime/llm/client.go`：
+  默认 OpenAI 兼容 `POST {base}/chat/completions` + `stream:true`；
+  `Protocol=anthropic` 走原生 Messages（`anthropic.go`，带 cache_control 断点与签名思考块）。
+- **Provider 预设**：`llm/providers.go`（anthropic/openai/google/deepseek/minimax/
+  openrouter/groq/azure）+ `models.json` 自定义；`ParseModelRef` 支持 `provider/model:thinking`。
+- **流式解析**：`llm/sse.go` `ParseSSE` → `emitParsed` 产出统一事件
+  （text_delta / reasoning_delta / tool_call_delta / message_end）。
+- **模型配置链**：settings 覆盖链（defaults→system→user→project）+ 画像 ModelRoute
+  （`internal/runtime/model.go:30-62`）；轻量档回落主档（model.go:84）；
+  `models.chat.fallbacks` 故障切换（`llm/fallback.go`，在 runDirect 内接线）；
+  重试（内核 `WithRetry`）。
+- **事件到前端**：内核事件 → `directRun.onEvent`（`llm_direct.go:278`）转 `rc.Emit(...)`
+  → `runmgr.emit`（`runmgr.go:1217`）→ 事件缓冲合并（150ms/64 条，`internal/runmgr/events.go:42-43,83`）
+  → `store.AppendEvents`（事务内分配会话内单调 seq，`internal/store/messages.go:243`）
+  → `bus.Publish` → SSE `GET /api/events`（`server.go:275`，Last-Event-ID 重放，15s 心跳）；
+  PG 多实例经 `internal/pgbus` NOTIFY/LISTEN 扇出。
+
+---
+
+## 5. 工具 / 技能 / 提示词体系
+
+**工具系统**
+- 契约：`modules/core/tools.go:16` `ToolDesc`（JSON Schema 参数、ReadOnly/Edits/Risk 权限声明）、
+  `tools.go:33` `HTTPToolSpec` 无代码声明式 HTTP 工具。
+- 注册：`internal/tools/registry.go:50` `Register`（后注册覆盖）、`:112` `RegisterBuiltin`
+  （time_now、knowledge_search、write_artifact、quality_review、跨会话 peers、ask_user 等）；
+  另有 fs / exec / search / 声明式 HTTP / `run_tool_script`（需开关）各文件。
+- 执行策略在 runmgr：`ExecuteTool`（`runmgr.go:740`）deny→错误、计划模式 deny、
+  confirm/ask→HITL 确认卡、执行后超长截断转工件。
+- 结果回填：内核侧作为 `Role=tool` 消息进转录；UI 侧由 onEvent 聚成 `PartToolCall`+
+  `PartToolResult` 终态落库；下一轮由 ctxasm `renderAssistantTurns`（`internal/ctxasm/ctxasm.go:174` 附近）
+  还原成 provider 原生配对消息。
+
+**skills 包 = 内置技能文件**：go:embed `recipes/**`（`internal/skills/skills.go:23` 附近），
+启动 `Seed`（skills.go:53）落 `<data>/skills/`，带 manifest 哈希做升级/drift 保护；
+供内核的 SKILL.md 加载器与 `load_skill` 渐进披露工具消费
+（`deps/agent-native/runtime/skills/skills.go`）。
+
+**prompts 包 = 提示词模块库**：embed `library/*.md` + DB 用户覆盖链。
+`ResolveSystem`（`internal/prompts/service.go:290`）：base/env 层按画像引用 →
+task 层全员触发匹配（command/intent/attachment 三类触发）→ 正文点名的 `method.*`
+辅助模块跟随注入 → 占位符填充（`{{date}}/{{model}}/{{skillsDir}}`）。
+另提供子代理 spec（tools/model/maxTurns，`service.go:81` 附近；**禁止子代理持有派发类工具**）、
+AgentPrompt、工具描述覆盖。
+
+**ctxasm 包 = 上下文组装**：`AssembleInput`（`internal/ctxasm/ctxasm.go:45`）=
+sys 段 → 历史窗口（默认 40 条，超出注入抽取式摘要）→ 卡片/工件正文回填
+（防"下一轮失忆"）→ 当前轮文本 + 附件解析全文（默认 48000 字符截断）+ knowledge 块；
+`FinishAssembly`（`finish.go:97`）追加条件注入；产出 Report（token 估算、裁剪记录、
+prefixHash）作为可观测 `ContextObservation`。记忆注入在内核按请求完成（`loop.go` prepareRequest 段）。
+
+---
+
+## 5.5 主对话模型手上有哪些工具
+
+模型每轮请求能看到的工具分三类（全部在 `LLMRunner.Execute` 声明阶段组装，`llm.go:267-315`）：
+
+| 类别 | 工具名（实测常量/注册名） | 来源 |
+|---|---|---|
+| **编排型**（在 runner 内消化，不走通用执行器） | `update_plan` / `update_todos`（维护右栏计划/待办）、`delegate_task`（派子代理）、`squad_orchestrate`（发起小队）、`run_workflow`（发起工作流）、`review_findings`、`submit_card`、`card_begin`/`card_append`/`card_commit`（流式产卡三段式） | `internal/runtime/llm.go:56-70` 常量 |
+| **内置产品工具** | `time_now`、`knowledge_search`（项目/插件知识全文检索）、`write_artifact`（写工件）、`quality_review`（交付物打分）、`ask_user`（主动提问=HITL）、跨会话 `peers` 系列 | `internal/tools/registry.go:112` `RegisterBuiltin` |
+| **内核工作区工具**（经 hostbridge 注入内核） | `read_file` / `write_file` / `edit_file` / `multi_edit` / `list_dir` / `grep` / `glob` / `load_skill` / `run_python` / `run_command` / `web_search` / `tavily_search` / `fetch_url` / `delegate_task` | `internal/runtime/hostbridge.go:15-21` `kernelToolNames`；`web_search`/`tavily_search` 仅在配置了搜索密钥时注册 |
+
+实际可见集 = 以上与**画像三清单**（allow/deny/confirm，`core/profile.go`）过滤后的交集；
+计划模式下 `filterPlanDecls`（llm.go:332）会再收窄。
+
+---
+
+## 5.6 实例：一个典型回合的机制走查
+
+> 走查基于上文全部代码锚点；模型输出为示意，机制、工具名与顺序均为代码实测。
+
+用户输入："把我会话里刚上传的季度数据整理成一份摘要文档，并告诉我三个关键结论。"
+
+1. **进入回合**：`postMessage` → 意图 fallback（没有装匹配意图）→ `route.Decide` 判
+   `KindTurn` → 抢会话槽位 → `startClaimedRun` 建 `Run{pending}` → 选 `LLMRunner` →
+   `go execute()`（`runmgr.go:1023, 918`）。
+2. **上下文组装**：`ctxasm.AssembleInput`（ctxasm.go:45）——system 段（base/env/task 提示词
+   模块，`prompts.ResolveSystem`）→ 历史窗口（默认 40 条）→ 当前轮文本 + **附件解析全文**
+   （ingest 已把 xlsx/csv 解成 ParsedDocument，默认 48000 字符截断）→ knowledge 块。
+3. **第 1 轮 LLM**：模型看到数据后先调 `update_todos`（拆 3 个待办）+ `read_file`（读附件
+   解析物）。两个工具经内核 `runTool` 回落宿主执行，结果以 `Role=tool` 消息回填转录
+   （loop.go `executeTools` 段），UI 侧聚成工具过程部件。
+4. **第 2 轮 LLM**：模型调 `write_artifact`（把摘要写成工件）。宿主执行 → `artifact.created`
+   事件 → 工件登记进会话。
+5. **第 3 轮 LLM**：模型输出三个结论的纯文本（无工具调用）→ 内核判定无工具调用 →
+   follow-up drain → **Stop 钩子**：宿主做交付物门禁（`deps/agent-native/runtime/gates/gates.go:52`
+   `ClaimGate`）——它抓三类"说谎"：① 回复正文出现工具调用标记但本轮没有真实调用；
+   ② 引用了不存在的工件 ID；③ **声称"已生成/已登记文件"但这轮没有产出对应工件**。
+   本例模型确实产出了工件，门禁放行；若模型只写了结论却声称"文件已生成"，
+   门禁拒绝结算并附原因让模型续跑（最多 3 次续跑，`loop.go` stopDecision + 宿主接线）。
+6. **收口**：可选用主模型 `composeFinal` 重写最终回复 → `finishRun`（runmgr.go:1087）→
+   `SettleRun` 单事务落 run 终态与助手消息树 → 发 `run.completed`（带 ContextObservation）。
+
+子代理变体：若第 2 轮模型改调 `delegate_task {agent:"researcher", task:"分析季度数据"}`，
+则走 `llm_direct.go:493` → `runmgr.go:1348` 派生 `Kind=subagent` 子 run（任务树 + `agent.spawn`
+事件）→ `SubLLMRunner` 用同一内核循环独立跑完 → 结果回填父轮。
+
+---
+
+## 6. HITL（人工介入）
+
+- 契约：`modules/core/hitl.go:33-36` 四种卡（choice/input/confirm/form）。
+- 挂起：`runCtx.AskHITL`（`runmgr.go:449`）存卡 → run 置 waiting_hitl → 发
+  `hitl.request` → 收件箱投影 → `waitHITL` 阻塞等恢复（支持超时）。
+- 恢复：`POST /api/hitl/{id}/resolve` → `runmgr.ResolveHITL`（`runmgr.go:1261`）
+  三分支：选项回填恢复；自由输入命中其他意图 → 取消挂起 run 并转轨；否则作澄清回答回填。
+- 触发时机：a) 工具确认（画像 confirm 清单 / policy ask，`runmgr.go:757` 附近与内核
+  `PermissionAsk` 端口）；b) 工作流缺槽位提问（`internal/wfcompile/run.go` 槽位补齐段）、
+  显式 hitl 步骤（`internal/wfcompile/host.go:138` `doHitl`）、动态计划执行前确认
+  （`RunOptions.RequireConfirm`，`internal/wfcompile/run.go:34`）；c) `ask_user` 工具。
+
+---
+
+## 7. workflow 体系与"规划器"
+
+- `internal/workflow/registry.go`：工作流**定义注册表**（只依赖 core）。
+  `Registry.Set` 整体替换快照、`ByIntent` 按意图查定义、`Launch` 产启动副本。
+- **编译执行器在 `internal/wfcompile/`**（Q3 WP1）：
+  - `run.go:39` `RunCompiled`：缺槽位逐个 HITL input 卡收齐 → `compiler.go:76` `Compile`
+    编译 WorkflowDef → **装配到小队引擎（squad）步进执行**（挂起 → HITL 卡片 → Respond；
+    执行态 → Resume）→ critic 终判 → outcome 汇总（run.go 文件头注释即此流程）。
+  - `RunOptions`（run.go:27）：`DynamicLimits`（模型生成上限：≤8 步、禁 script）、
+    `RequireConfirm`（模型生成工作流执行前强制 HITL 确认；注册的声明式工作流免确认）、
+    `ModelScript`（脚本步为模型提供，执行前单独确认）。
+- **"先规划任务列表再执行"的 planner 真实存在**：`internal/runtime/workflow_compiled.go:91`
+  `planCompiledWorkflow` —— `rc.SpawnAgent(workflowPlannerID, "规划", …)` 派**规划子代理**
+  输出 WorkflowDef JSON（"只输出 JSON，不要完成目标本身"）→ `wfcompile.ParseWorkflowDef`
+  解析校验 → `runLaunch` 以 `DynamicLimits:true, RequireConfirm:true` 执行（用户 HITL
+  确认计划后步进）。另有 `registeredWorkflowLaunch`（:117，注册定义 + 快照脚本正文）、
+  `modelScriptLaunch`（:138，模型脚本，单独确认）。入口 Runner 是
+  `CompiledWorkflowRunner`（workflow_compiled.go:30，`Execute` :39）。
+
+---
+
+## 8. deps/agent-native 内核的其他部件
+
+- `runtime/` 是**进程内自研内核**（不派子进程）：`loop.go` 循环、`llm/` 客户端、
+  `tools/` 内核注册表（deferred 延迟暴露 + tool_search）、`session/`（JSONL 转录树，
+  可 fork/clone）、`session_agent.go`（headless AgentSession：steer/follow_up/abort/换模型）、
+  `hooks/`、`memory/`、`skills/`、`promptx/`、`mcp/`、`checkpoint/`、`subagent/`、
+  `gates/`（验收+守卫）、`codeorch/`（Python 依序调工具的代码编排）、`policy/`。
+- `rpc/` 是本地 JSONL RPC（一行一命令，双向 pipe），把内核暴露给子进程/外部宿主；
+  **产品后端主路径不走 rpc**，直接进程内调 `nruntime.Run`。
+- `adapters/native/backend.go` 把内核包成 `exec.Backend`（`exec/backend.go` 接口），
+  供小队成员执行使用（见[小队与子 Agent 启动](squad-and-subagents.md)、
+  [小队工作机制](squad-mechanics.md)）；`adapters/pitransport/` 是远程 pi runner 的
+  HTTP/NDJSON 传输适配（产品未用为主）。
+
+---
+
+## 9. 关键文件清单
+
+| 职责 | 文件 |
+|---|---|
+| Run/消息/计划/工件契约 | `modules/core/model.go`、`events.go`、`hitl.go`、`tools.go` |
+| Run 生命周期枢纽 | `modules/backend/internal/runmgr/runmgr.go` |
+| 事件缓冲与 seq | `modules/backend/internal/runmgr/events.go` |
+| Runner 端口与四实现 | `internal/runtime/runner.go`、`llm.go`、`sub_loop.go`、`workflow_compiled.go`、`squad_runner.go` |
+| 内核桥接（工具/事件/Stop 钩子） | `internal/runtime/llm_direct.go`（runDirect :95、onEvent :278、runTool :471） |
+| 模型路由 | `internal/runtime/model.go` |
+| 工作流编译执行 | `internal/wfcompile/run.go`（RunCompiled :39）、`compiler.go`（Compile :76）、`host.go`（doHitl :138） |
+| 工作流入口与 planner | `internal/runtime/workflow_compiled.go`（CompiledWorkflowRunner :30、planCompiledWorkflow :91） |
+| 工作流定义注册表 | `internal/workflow/registry.go` |
+| 内核 ReAct 循环 | `deps/agent-native/runtime/loop.go` |
+| LLM 客户端/协议/预设 | `deps/agent-native/runtime/llm/client.go`、`providers.go`、`sse.go`、`anthropic.go` |
+| 上下文组装 | `internal/ctxasm/ctxasm.go`、`finish.go` |
+| 提示词库 | `internal/prompts/service.go` |
+| 技能种子 | `internal/skills/skills.go` |
+| 工具注册表 | `internal/tools/registry.go` |
+| run/事件/工件落库 | `internal/store/messages.go`、`recovery.go` |
+| HTTP 入口与 SSE | `internal/server/server.go` |

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-01-extension-compat-policy.md

@@ -8,7 +8,7 @@
 | 面 | 标识 | 规则 |
 |---|---|---|
 | 插件清单 | `apiVersion` | 接受 `1.0` 与 `2.0-experimental`。其他值整包拒绝（fail-closed） |
-| 公开 Go 包 | `extension.SurfaceVersion` | `2.0.0-experimental`。实验窗口内允许破坏性调整，但必须改契约快照并在提案里写一句 |
+| 公开 Go 包 | `extension.SurfaceVersion` | 实验系列 `2.x.0-experimental`（2026-10-09 v0.2.0 时为 `2.5.0-experimental`，每次加法升次版本号）。实验窗口内允许破坏性调整，但必须改契约快照并在提案里写一句 |
 | HTTP API | 路径前缀 `/api/` 与 `/host/v1/` | 已发布路径只加字段，不改语义、不删字段。新能力用新路径 |
 
 弃用：公开符号先标记注释 `Deprecated:`，至少一个下游可升级的版本之后才删除。实验窗口内的删除仍要改快照测试，不能静默。
@@ -45,10 +45,11 @@ replace agent-system-core => ../Agent-System-Dev/modules/core
 
 ## 5. 发版命令（owner 执行，本次未执行）
 
-tag 名以 V1.2 实施推进方案批复的 `v0.2.0` 为准（2026-10-05 对齐；五仓 backend/core/frontend/ui/Dev 同打）：
+tag 名以 V1.2 实施推进方案批复的 `v0.2.0` 为准（2026-10-05 对齐；五仓 backend/core/frontend/ui/Dev 同打）。
+具体提交、tag 消息与核对命令以 [v0.2.0 发版记录](../records/2026-10-09-base-v0.2.0-release.md) 为准（消息里的 SurfaceVersion 写发版时的实际值）：
 
 ```
-git tag -a v0.2.0 -m "extension surface 2.0.0-experimental"
+git tag -a v0.2.0 <该仓对应提交> -m "<发版记录里的消息>"
 git push origin v0.2.0
 ```
 

docs/proposals/2026-10-05-ext-1-inproc-command-handler.md

@@ -9,6 +9,7 @@
 - **希望符号**：`pkg/extension` 新增 `Request` / `Handler` / `Host`（owner 作用域宿主句柄最小集）与 `Registry.AddCommandHandler(spec, h)`；基座侧配套 `cmdbus.Bus.RegisterPluginCommand`。
 - **为何现有注册点组合不出来**：`RegisterPluginCommands` 仅登记 spec；`HostClient` 走 sidecar HTTP 且需要进程内不可得的 host token；owner 作用域必须由基座在分发时构造，插件无法自造。
 - **兼容**：只加符号与方法，不改既有路径语义；`SurfaceVersion` 保持 `2.0.0-experimental`，实验窗口内的接口调整以本提案为记录。
+  （2026-10-09 注：此后 EXT-8/9/11/12 与执行原语硬开关按 compat-policy 逐次加法升级，v0.2.0 发版时为 `2.5.0-experimental`，见 [v0.2.0 发版记录](../records/2026-10-09-base-v0.2.0-release.md)。）
 
 ## 2. 公开面变更（surface.txt 12 → 15 项）
 

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-08-ext-c1-c7-rdm-shared-contracts.md

@@ -0,0 +1,166 @@
+# EXT 申请包 · C1–C7：RDM 多人共享契约的基座最小扩展（EXT-6…EXT-12）
+
+| 项目 | 内容 |
+|---|---|
+| 状态 | proposed（2026-10-08）；owner：weichen；任务：Dev `feature/ext-c1-c7-applications` |
+| 性质 | 扩展点申请包（extension-compat-policy 流程第 2 步：基座侧评审）。**本文只立申请，不实施**；各 EXT 实现另立任务卡 |
+| 需求依据 | RDM 仓 U0 主记录 `docs/proposals/2026-10-08-U0-baseline-and-shared-contracts.md` §5 契约 C1–C7（RDM main `ca72cfc` 已合入，含 D1–D9 裁定）；来源=用户 2026-10-08 会话批准的 U0 实施计划 |
+| 现状证据 | 均为 SELF·源码级，引用对象：Dev `34a2bbe`（backend gitlink `fe7c245`）；RDM pin backend `cb26e4c`（v0.1.0）相同结论者已注明。运行态 NOT_RUN |
+| 编号 | 按既有序列（EXT-1/3/4/5 在案）顺延 **EXT-6…EXT-12**；最终编号以受理评审为准 |
+
+## 0. 总则
+
+- **推荐路线**（U0 裁定 D1，修订 V2.1 草稿 J-09「基座不改动」）：领域规则（成员、角色、三权、
+  发布状态）住 RDM 下游仓；基座只补**通用、无领域词汇**的最小扩展面。每条申请遵守 INV-2：
+  基座代码与 diff 不出现 RDM 领域字样，全部以「资源授权/受管配置/投影过滤」等通用语义表述。
+- **事实依据（为何纯下游组合不出来）**：基座一切资源访问按 owner 硬边界
+  （`internal/store/projects.go:22-34`），EXT-1 Host 强制 owner 归属且**无知识删除/更新**
+  （`pkg/extension/host.go:43-46`、`internal/app/hostcaps.go:101`）。RDM 增加成员表不能改变
+  基座过滤；给每人复制知识库被 U0 §4 明确禁止。
+- **SurfaceVersion 影响**：EXT-6/7/9 触及 `pkg/extension` 导出面（Registry/Options/Host 方法），
+  属加法变更——按 extension-compat-policy 升 SurfaceVersion（2.0.0-experimental 内加法，
+  surface.txt 同步）；EXT-8/10/11/12 为 internal/HTTP 行为扩展，不动导出面。
+- **分期建议**（对齐 U0 §10）：EXT-8（授权适配器）与 EXT-9（索引发布）为序 4「项目范围与
+  授权基础」的硬前置；EXT-6/EXT-12 支撑序 4–5；EXT-7/EXT-10 可随后。EXT-8 建议最先评审。
+- **通用默认不变量**：每条扩展的缺省行为=现状（未注册/未配置时与今日基座完全一致），
+  RDM 产品部署显式启用；通用基座与既有下游不受影响。
+
+---
+
+## 1. EXT-6（←C1）可信身份：账号停用与会话吊销
+
+- **场景**：RDM R01 唯一管理员移交后旧凭证须立即失效；成员移除同理。现状基座账号只有
+  创建/改密/列表（`internal/server/accounts.go:184-261`），无停用语义，撤销账号后其 API key
+  与会话仍有效到自然过期。
+- **期望公开面**：①`POST /api/admin/users/{owner}/disable|enable`（requireAdmin 保护）；
+  ②users 表加 `disabled` 布尔（迁移，default false）；③认证链（API key 校验与会话校验，
+  `internal/server/auth.go:29-64`）与 `requireAdmin` 拒绝 disabled 账号并吊销其在途会话。
+  「全局唯一管理员」由 RDM 产品策略约束（部署约定+台账），不强制基座单管理员。
+- **为何组合不出**：无任何现有端点或设置键能改变账号认证状态；RDM 无法经 EXT-1 Host 触达
+  认证层（Host 无账号域能力，也不应有一—属平台面）。
+- **兼容方式**：纯加法（新端点+新列 default false）；未停用=现状。SurfaceVersion 不变
+  （不动 pkg/extension）。
+- **验收**：停用后该账号 API key 与 cookie 即刻 401；管理员功能不受影响；启用可恢复。
+
+## 2. EXT-7（←C2）受管系统配置：最终生效值受策略约束
+
+- **场景**：RDM R01——模型端点/密钥、工具上限、系统插件由管理员控制；个人偏好保留。现状
+  设置链 `defaults → system(启动注入) → user → project`（`internal/settings/settings.go:131-147`），
+  user/project 可覆盖一切；system 层不落库且组合根只注入 dataDir
+  （`internal/app/app.go:130`）——只藏设置页或只禁今后写入都处理不了既有覆盖。
+- **期望公开面**：①`extension.Options` 增受管注入：`ManagedSettings map[string]any`（键集+
+  值，由宿主二进制启动注入）；②设置服务按受管键集跳过 user/project 覆盖（Effective 尊重
+  策略）；③受控键的 user/project 写入返回结构化拒绝并附依据；④`GET /api/settings` 标注
+  哪些键受管。RDM 在自有二进制 main 里以管理员配置注入。
+- **为何组合不出**：Options 无注入口；`SetSystemOverride` 是组合根私有；下游无法让 Effective
+  忽略 user/project 的既有覆盖。
+- **兼容方式**：`ManagedSettings` 缺省 nil=现状（无受管键，行为不变）；pkg/extension Options
+  加字段=导出面加法，SurfaceVersion 与 surface.txt 同步升。
+- **验收**：预置 user 覆盖的受控键，注入策略后生效值=受管值；普通用户写受控键被拒且
+  `GET /api/settings` 可解释；未受管键的个人偏好不受影响。
+
+## 3. EXT-8（←C4）资源授权适配器：项目共享的读取通道 ⭐关键路径
+
+- **场景**：RDM R03/R04/R05——成员 B 依 RDM 成员表读取成员 A 提交的项目资料（工件原件、
+  检索、引用、下载、图查询）；撤销后停止。现状一切资源入口按 owner 过滤
+  （`internal/store/projects.go:22-34`；工件/知识/卡片同理），Host 读取族同样强制本人
+  owner（`pkg/extension/host.go:43-46`）。
+- **期望公开面**：①基座提供**授权适配器注册点**（HTTP 组合根）：`RegisterResourceAuthorizer(
+  func(owner, resourceProjectID core.ID) (allow bool, err error))` 形态的进程内回调，经
+  `extension.Options` 或 Registry 注入（具体挂点评审定）；②资源入口（项目/工件/知识检索/
+  卡片读取的 HTTP 层与 Host 读取族）在 owner 自有判定未命中时回调适配器：返回 true 则按
+  「项目共享」放行，false/未注册=现状 NotFound（不泄露存在性）；③适配器只回答布尔，
+  不接触基座内部状态；④放行日志入审计（owner×resource×decision）。
+- **为何组合不出**：owner 过滤在 SQL 层硬编码；无任何回调或配置可改变跨 owner 可见性；
+  回环 HTTP 模拟他人身份被认证中间件阻止（V1.1 教训，10 号方案已证）。
+- **兼容方式**：未注册适配器=现状零差异；回调失败按拒绝（fail-closed）。pkg/extension
+  加法→SurfaceVersion 升。**注意**：本 EXT 使基座首次具备跨 owner 授权读取语义，评审须
+  重点核对回调契约的最小性（仅 owner×projectID 两参，不透出对象细粒度——细粒度由 RDM
+  在自己的命令层做）。
+- **验收**：同项目两人+另一项目一人（RDM 成员表桩）：共享资源四入口（原件/检索/引用/下载）
+  一致放行；跨项目与替换引用拒绝且 NotFound 不泄露；撤销成员后新访问立即拒绝；审计可查。
+
+## 4. EXT-9（←C5）索引发布与撤销：留存 ≠ 可检索
+
+- **场景**：RDM R07——存疑资料确认前不得进入任何正式检索；发布有稳定版本、撤销即时生效。
+  现状基座上传端点在下游相关性判定**之前**即写检索索引
+  （`internal/server/server.go:1039-1046`；RDM pin 相同）；Host 知识面只有
+  `KnowledgeWrite`（强制 owner），无删除/更新（`pkg/extension/host.go:43-46`）。
+- **期望公开面**：①基座上传预索引开关（`Options` 或项目设置键 `uploads.autoIndex`，缺省
+  true=现状；RDM 部署关闭，索引决定移交其命令层）；②Host 增 `KnowledgeDelete(owner,
+  sourcePrefix string, versions …) / KnowledgeUpdate`（或等价发布令牌语义：写入带稳定
+  `PublishID`，删除按 PublishID 幂等）；③删除仅作用于插件来源（`Source` 前缀
+  `plugin:<id>`），公共 manual 来源不可被插件删。
+- **为何组合不出**：检索索引无删除面；上传索引行为硬编码；RDM 无法撤回已入索引的存疑内容。
+- **兼容方式**：开关缺省现状；Host 删除方法为导出面加法（surface.txt/SurfaceVersion 同步）。
+- **验收**：相关/存疑/拒绝三份样本：仅获准发布版本可检索；重试不重复建索引；撤销后检索与
+  上下文注入立即停止（含 Host 读取族）；manual 来源不可删。
+
+## 5. EXT-10（←C3）分发前校验钩子与会话归属
+
+- **场景**：RDM R18——对话/按钮/卡片/API 四入口同源且对象-会话-项目关联可校验；旧卡片/
+  重复确认不得操作新版本。现状 `POST /api/commands/{id}` 不校验 conversationId 归属
+  （`internal/server/server.go:823-836`），确认卡锚定客户端自报会话
+  （`internal/cmdbus/cmdbus.go:294-316`）；插件命令注册不写 slash 别名，对话入口不可达
+  `rdm.*`（`cmdbus.go:145-153`，v0.1.0 与 main 同——阶段总案 §2.3 已登记）。
+- **期望公开面**：①分发前校验钩子：`RegisterDispatchGuard(func(owner, conversationID string)
+  error)`（未注册=现状放行；RDM 注入「会话属该项目且属于该 owner」判定）；②
+  `RegisterPluginCommand` 增可选 slash 别名参数（或 manifest 字段），对话入口 `/rdm.*`
+  可解析；③别名与 intents 命中路由到插件命令的打通（阶段总案既有缺口，并入本 EXT 或
+  单列由评审定）。
+- **为何组合不出**：execCommand 对 conversationId 零校验也无回调点；slash 表只由内置与
+  用户命令登记写入（`cmdbus.go:109-127`），插件路径不写。
+- **兼容方式**：钩子/别名均缺省=现状；internal 行为扩展为主（Registry 签名若变则属
+  pkg/extension 加法，SurfaceVersion 升）。
+- **验收**：伪造他人会话/项目引用的命令被拒；`/rdm.ping` 在对话入口可达且回执与按钮入口
+  同源（同一审计信封）；陈旧卡片确认不生效（既有 ErrNotAwaiting 之上叠加对象版本校验）。
+
+## 6. EXT-11（←C6）按 owner 重建受限 Host：后台任务恢复
+
+- **场景**：RDM R10/R21——慢任务跨重启不丢不重；撤权后不越权续跑。现状 RDM 慢通道是进程
+  内存队列并把分发时 Host 句柄留在队列（RDM `internal/rdmapp/slow.go:53,66`，重启即丢、
+  撤权不重验）；基座任务台账仅记账（`pkg/extension/host.go:48-50`）。
+- **期望公开面**：基座侧缺口小——提供「按 owner+pluginID 构造受限 Host」的公开工厂
+  （如 `extension.NewScopedHost(owner, pluginID)` 形态或 Registry 上的查询），供下游在
+  恢复任务时重建执行上下文；任务体、输入版本、幂等与重验策略由 RDM 自管（U0 §7）。
+  **不序列化旧 Host**——重建受限上下文，天然以当前权限为准（配合 EXT-8 的授权适配器，
+  撤权即拒绝）。
+- **为何组合不出**：inprocHost 是 internal 类型按分发请求私有构造
+  （`internal/app/compiled.go:42`）；下游无任何入口可在分发期之外获得合法句柄。
+- **兼容方式**：纯加法工厂函数；不改变分发期语义。pkg/extension 加法→SurfaceVersion 升。
+- **验收**：下游以工厂重建的 Host 执行读/写，owner 作用域与分发期一致；重启后同任务不重复
+  执行（RDM 侧幂等）+ 撤权后重建 Host 的读取被适配器拒绝。
+
+## 7. EXT-12（←C7）卡片/事件投影过滤：私人事件与公共投影分离
+
+- **场景**：RDM R04/R18——私人会话卡不得进项目公共流；公共投影只含获准发布的状态；撤权
+  后重放不泄露。现状会话卡**全量镜像**到项目频道（`internal/cardsvc/cardsvc.go:41-60`，
+  注释自述「全量镜像换取口径简单」）——单 owner 下无害，多人项目即隐私泄露路径。
+- **期望公开面**：卡片镜像策略可配置：①按卡属性过滤（kind/来源）的内置开关，或②复用
+  EXT-8 适配器语义的投影可见性回调（`func(owner, card) bool`）——评审择一，倾向①最小。
+  RDM 部署关闭会话卡镜像，只用项目级卡承载公共投影。
+- **为何组合不出**：emitCard 镜像逻辑硬编码；无配置面。
+- **兼容方式**：缺省=现状全量镜像；internal/设置键扩展，不动导出面。
+- **验收**：关闭镜像后会话卡仅出现在本人会话流；项目流只含项目级卡；既有单用户部署行为
+  不变；SSE 重放遵循同一过滤。
+
+## 8. 不在本申请包（显式排除）
+
+- 需求条目化/模板/法规双通道/三权流程等 RDM 领域能力（U0 §2 R08–R16）——全部住下游。
+- 飞书渠道 EXT-3：既有在案申请，节奏不变（MS4 前）。
+- 命令审计跨租户修复：**不是扩展**，是缺陷修复，已另行（Backend PR #104 + Dev PR #262）。
+
+## 9. 受理建议
+
+| EXT | 前置的 U0 序 | 建议评审优先级 | SurfaceVersion |
+|---|---|---|---|
+| EXT-8 授权适配器 | 序 4 硬前置 | **P0 最先** | 升（加法） |
+| EXT-9 索引发布/撤销 | 序 4 硬前置 | P0 | 升（加法） |
+| EXT-6 账号停用 | 序 4–5 | P1 | 不变 |
+| EXT-11 Host 工厂 | 序 4 | P1 | 升（加法） |
+| EXT-10 分发守卫/别名 | 序 3 剩余半边（基座侧） | P1 | 视形状 |
+| EXT-7 受管配置 | 序 4–5（R01） | P2 | 升（加法） |
+| EXT-12 投影过滤 | 序 5 | P2 | 不变 |
+
+每条受理后按 extension-compat-policy 走「基座任务卡实现→发版→RDM 升钉」；预计随 v0.2.0
+之后的 v0.3.x 分批落地（对齐 RDM 阶段总案 §3.3 与风险 R-5）。

docs/proposals/2026-10-09-agent-quality-improvement-plan.md

@@ -0,0 +1,86 @@
+# 智能体工作流质量改进：诊断、裁定与分期计划
+
+状态：**已获实施授权（2026-10-09，六项裁定见 §3）**；owner：weichen；
+主任务：Dev 仓 `feature/agent-quality-phase01`（Phase 0+1 首个增量）。
+撰写日期：2026-10-09。诊断依据：dev 实例真实运行转录（PG pg1 13 次 run + 旧
+SQLite 53 次，共 62 条助手消息、263 次工具调用；模型 MiniMax-M2.7-highspeed，
+direct 入口），对照本机 ZCode v3.14.3 源码与 codex/opencode/pi/Kimi CLI/Cursor
+公开资料（2026-10-09 抓取）。诊断证据级别 SELF（本地观察与复算）。
+
+本文件是该改进方向的主记录：目标、裁定、分期与验收以本文为准；
+各阶段实施细节与结果记在对应任务卡，不回写复述。
+
+---
+
+## 1. 问题陈述
+
+与 codex / pi / kimi / cursor / zcode / opencode 相比，本系统直连对话路径在
+「工作细致、详细、完善」上存在可测差距。真实转录中定位到的失败链（均已复核）：
+
+1. **信息逐轮衰减**：跨轮上下文由界面消息有损重建——工具结果只回放 160 字
+   摘要、参数截断、二进制原件占位、思考内容丢弃；上传材料只在「本轮」注入。
+   后续轮次在摘要的摘要上工作，细节靠编造补齐（实测：「详细方案」中 85%/95%
+   准确率、8000–10000 字等数字在原始转录中不存在；日期星期错配）。
+2. **修改模型倒挂**：交付物由一次性整段生成脚本产出（docx 无源文件），任何
+   修改=整篇重写重跑（实测一轮 24 次工具调用 9 次失败、6KB 脚本重跑 8 次）。
+3. **检查失效且误报**：终轮评分的 lint 子进程无 PYTHONPATH 而静默失败（同一
+   docx 带 PYTHONPATH 9 个 error，评分器里 0 个）；终轮检查重评已被替代的旧
+   工件导致死循环；可读性规则把表格单元格「项目概述撰写」判成栏目式标题；
+   历史工件渲染格式 `[产出工件 …]` 与伪造标记检查同形，模型照抄即被拦。
+4. **最终答复与事实脱节**：composeFinal 只见 160 字摘要，产出了不存在的章节
+   列表和「我会调整后再提交」类未兑现承诺。
+5. **过程性根因**：无任务级评测。任务卡验证=单测+mock，真实模型被列为非目标；
+   evalgold 只有 1 条规则，eval/ab.go 无运行记录。
+
+## 2. 根因归纳（按影响排序）
+
+1. 上下文保真度不足（影响最大）——产品没有把内核的追加式会话记录当权威上下文。
+2. 工具与修改流程不适合交付物领域——没有「读源码→精确改→编译→看诊断」的对应物。
+3. 质量控制是事后把关而非让模型自己做好，且把关本身不可靠。
+4. 行为指引薄弱（何时建计划/失败换路/坚持到完成），工具描述只有一行。
+5. 没有以真实模型结果为准的评测回路。
+
+内核能力（read/edit/grep/glob、超长落盘、压缩、会话树）大多已在 agent-native
+就位，问题主要在产品组装层（`modules/backend/internal/runtime|ctxasm|quality`）。
+
+## 3. 用户裁定（2026-10-09，授权实施）
+
+| # | 事项 | 裁定 |
+|---|---|---|
+| 1 | 直连对话开放工具与能力 | **开放，尽可能实现和开放所有的工具和能力**（推翻 2026-09-30 预览案「fs 工具实现但不默认提供」的默认关闭裁定） |
+| 2 | 跨轮上下文以内核会话记录为准 | **同意**（重新生成/排除/回滚映射为会话树分支操作） |
+| 3 | 交付物 Markdown 源码化 + 构建器 | **可以，但必须保留生成各类文件（docx/xlsx/pptx/pdf/图片等）的能力** |
+| 4 | composeFinal 与关键词评分降级 | **按建议**：Phase 2/3 落地后 composeFinal 默认关闭（仅异常兜底）；关键词评分移出拦截路径、只作评测指标 |
+| 5 | 更强模型评测 | **可以，预算无上限** |
+| 6 | 行为面改动须附真实模型评测 | **按建议**：写入 Dev 仓 policy/delivery.md |
+
+## 4. 分期与验收
+
+每阶段独立任务卡 + PR；改动提示词/工具/上下文/门禁的 PR 须附 eval/live
+真实模型前后对照（裁定 6）。评测口径：`modules/backend/eval/live/`
+（golden 任务集 + 指标：工具失败率、整篇重跑数、是否读原件、计划使用率、
+检查误报/死循环、终轮与工件一致性、未核实数字）。
+
+| 阶段 | 内容 | 验收 |
+|---|---|---|
+| **P0 评测基线** | eval/live 运行器 + tasks.json + 指标报告；before/after 各跑一次 | 基线报告能复现 §1 失败链 |
+| **P1 缺陷修复** | §1.3 的检查失效与误报七项 | 检查误报清零；两条死循环链消失 |
+| **P2 上下文保真** | 内核会话记录为权威跨轮上下文；窗口按模型真实窗口（token，实测校准）；被清结果落盘留路径+预览；上传材料持久 `inputs/*.md`；交错思考模型回传 `<think>`；接上 9 段压缩模板 | 后续轮 100% 读原件；「更详细」不整篇重写；未核实数字显著下降 |
+| **P3 工具开放 + 交付物源码化** | 内核 read/edit/grep/glob 接入直连（沙箱=会话工作区）；交付物 = Markdown 源文件 + `housestyle.build` 确定性渲染（自动 lint，诊断指向源行）；写入即诊断；`housestyle.api` 签名查询；保留 run_python 全类型生成能力（裁定 3） | 工具失败率 ≤8%；修改请求整篇重建 ≤1 次；API 幽灵调用消失 |
+| **P4 行为指引** | 基座提示词「工作方法」段（建计划/失败两次换路/先查 API/坚持到完成/结论先行终稿）；重写高频工具描述；计划提醒常开；按模型分提示词（先 MiniMax） | 多步任务计划使用率 ≥80%；终稿承诺未兑现清零 |
+| **P5 门禁精简** | 拦截型检查只留硬事实（工件存在/lint 零 error/引用存在）；新增事实一致性检查（数字/日期/人名回溯材料）；验证器按需触发+异模型 | 检查死循环 0；未核实数字显著下降 |
+| **模型 A/B** | 同一评测集换更强主模型对照（裁定 5，无预算上限） | 区分模型与 harness 各自的贡献，输出选型建议 |
+
+## 5. 不在本文范围
+
+- 操作系统级沙箱、多租户隔离策略（沿用现状与既有声明）。
+- 小队（squad）路径的同批改造——先修直连主路径，squad 经 A/B 对照跟进。
+- AGENTS.md/DESIGN.md 层面的仓库治理变更。
+
+## 6. 记录与证据
+
+- 诊断细节与复现命令：2026-10-09 会话记录（本文件只留结论与指针）。
+- before 基线：`eval-live/before-main-1ebd46e.json`（任务卡 evidence 引用）。
+- 关联：[Agent 栈总案](2026-10-02-agent-stack-completion.md)（库分期不受本文影响）、
+  [文件预览与保留能力](2026-09-30-file-preview-and-reserved-capabilities.md)（其 §2.3
+  的 fs 工具默认关闭裁定被本文裁定 1 推翻，以本文为准）。

docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md

@@ -0,0 +1,124 @@
+# EXT 申请包 · G1：回合内共享检索、命令即工具、项目列表共享与执行后端接口（B-1/B-2/B-3 + B-5②）
+
+状态：**proposed（2026-10-09）**；owner：weichen；需求依据 = RDM 评审与实施方案 V1.1
+（`Agent-System-RDM docs/proposals/2026-10-09-V22-review-and-implementation-plan.md` §3.3/§3.4/§5.3，
+owner 2026-10-09 Q1–Q8 批复；Q4=方案 A，Q2=暂时禁用＋隔离档）。
+撰写日期：2026-10-09。配套：[扩展面兼容与演进](2026-10-01-extension-compat-policy.md)、
+[EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md)（EXT-6…EXT-12）。
+
+## 0. 总则
+
+- 本包四条申请按既有序列顺延 **EXT-13…EXT-16**；最终编号以受理评审为准。
+- 分期（对齐 RDM 方案 §5.2）：B-1（EXT-13）与 B-3（EXT-15）为 **G1 序 4 的硬前置**
+  （成员智能体看不到项目知识 = R04 路径不通）；B-2（EXT-14）为 G2/V0.1 端到端的硬前置
+  （对话入口无法触达 `rdm.*`）；B-5②（EXT-16）为 G2-8 原型的前置。
+- SurfaceVersion 影响：EXT-14 触及 `pkg/extension` 导出面（命令规格新字段）→ 需升
+  SurfaceVersion 并同步 surface.txt；EXT-13/15/16 为 internal 行为扩展，不改导出面
+  （EXT-16 若只加 `Options` 字段则属加法，见 §4）。
+
+## 1. EXT-13（←B-1）回合内共享检索：智能体的检索遵循项目共享授权
+
+- **场景**：RDM R04/R05——成员 B 的智能体在**回合内**（ReAct 循环的 `knowledge_search`
+  工具与自动知识注入）必须能检索到成员 A 已发布的项目知识；现状只能看到本人 owner 的
+  知识。HTTP 面（`/api/…/search`）已走 `RetrieveShared`（EXT-8 余项，Dev #269/#273），
+  但回合内两条路径仍是 owner-only：
+  - `internal/runmgr/runmgr.go:726-736` `runCtx.Retrieve` → `retriever.Retrieve(ctx, c.run.Owner, q)`（owner-only）；
+  - `internal/app/hostcaps.go:64-66` `hostcaps.search`（进程内 `Host.KnowledgeSearch` 底座）→ `pipe.Retrieve(owner)`（owner-only）。
+  结果：同一个成员，页面搜索能看到共享知识，**智能体对话里看不到**——「所有用户的智能体
+  应当能够看到项目级的共享信息」（用户补充材料 §2树1图）走不通。
+- **希望公开面**：组合根把 EXT-8 适配器（`Server.ProjectAuthz` 同款判定函数）注入
+  runmgr 与 hostcaps：两条检索路径在本人 owner 两路（全文+向量）如常之外，追加
+  「经适配器放行的共享两路」——与 HTTP 面 `rag.Pipeline.RetrieveShared` 完全同一实现与
+  同一授权判定（复用 `sharedVisible`/`SearchKnowledgeShared`，不另造第二套语义）。
+  进程内 `Host.KnowledgeSearch` 同步走共享版。
+- **为何组合不出**：`RetrieveShared` 已存在，但 runmgr/hostcaps 没有适配器的引用——
+  适配器槽在 `internal/app/hostcaps.go` 的 `projectAuthz`，由组合根在装载扩展后注入
+  Server；runmgr 的构造早于扩展装载，且 `Manager` 无该依赖。下游无法经任何公开面把
+  「按 owner 判定共享」的回调递进回合执行路径。
+- **兼容方式**：适配器未注册＝现状（本人两路）；注册后共享命中追加、RRF 融合。
+  不动 `pkg/extension` 导出面，SurfaceVersion 不变。
+- **验收**：同项目两人＋另一项目一人（RDM 成员表桩）：成员 B 发起对话，模型经
+  `knowledge_search` 命中 A 已发布的知识切片（共享命中出现在工具结果）；未授权者与
+  跨项目者为零命中；`Host.KnowledgeSearch`（hostapi 与进程内两形态）行为一致；
+  未注册适配器时与现状逐字节一致（回归）。
+
+## 2. EXT-14（←B-2）插件命令即工具：`exposeAsTool`（Q4 方案 A）
+
+- **场景**：RDM V0.1 端到端（C-11）要求「从空项目创建到生成项目建议书，全对话完成」；
+  RDM 的全部能力（两树一网读写、上传、起草、追溯查询）都登记为 `rdm.*` 命令，而智能体
+  回合的工具清单里没有任何插件命令——模型既不能检索笔记树，也不能发起 `rdm.draft.compose`。
+  U0 §3.3/方案 §3.3 裁定走**方案 A**：命令经命令总线暴露为工具，四入口同源
+  （button/card/slash/chat）自然延伸出第五入口「智能体」。
+- **希望公开面**：命令规格（`agentcommand.CommandSpec` 经 `Registry.AddCommandHandler`
+  登记的 JSON）新增可选字段 `"exposeAsTool": {"risk": "low|medium|high"}`（缺省不暴露）。
+  runmgr 装配工具清单时，把带该字段的命令投影为工具描述（名称=命令 id，参数=命令
+  paramsSchema）；模型调用该工具时，**不分发为工具执行，而是构造 `cmdbus.Request` 经
+  命令总线分发**（Entrance="agent"，Actor=会话 owner，ConversationID=当前会话）——
+  同一审计信封、同一 HITL 内联确认卡（`risk=high` 或命令规格要求确认时照常弹卡）、
+  同一危险分级。
+- **为何组合不出**：`Registry` 只有 AddSkill/AddCommand/AddCommandHandler/Note/
+  RegisterResourceAuthorizer；工具注册表（`tools.Registry`）与命令总线之间没有任何
+  桥接；MCP 通道（方案 B）绕过命令总线与确认卡，与 SR-E6/HITL 门禁冲突，已被 Q4 否决。
+- **兼容方式**：`pkg/extension` 命令规格加可选字段＝导出面加法，SurfaceVersion 升
+  （建议 2.6.0-experimental）＋ surface.txt 同步。缺省（不写 exposeAsTool）＝现状零差异。
+- **验收**：带 `exposeAsTool` 的 `/rdm.ping` 出现在模型工具清单且调用返回回执，
+  审计信封 Entrance="agent" 与按钮入口同源；`risk=high` 的暴露命令在对话内触发内联
+  确认卡；不带字段的命令不出现；RDM 侧 `rdm.trace`/`rdm.baseline` 等只读命令可在
+  回合内被模型调用（成员 B 场景结合 EXT-13）。
+
+## 3. EXT-15（←B-3）项目列表与建会话的共享放行（SR-G10）
+
+- **场景**：RDM R03——成员 B 被加入项目后「界面自动出现该项目，可直接开始工作（新建
+  对话）」。基座 `projects` 表按 owner 硬隔离（`store/projects.go:22-34`）：
+  - `GET /api/projects`（`server.go:438-441` `listProjects`）只返回本人 owner 的项目——成员看不到共享项目；
+  - `POST /api/projects/{id}/conversations`（`store/projects.go:124-130`）校验「项目属于请求者」——成员在共享项目下建会话被 404。
+  EXT-8 已放行的入口（工件三入口、SSE 项目流、检索）不含这两处。
+- **希望公开面**：这两处入口在 owner 自有判定未命中时咨询同一 EXT-8 适配器：
+  `listProjects` 追加经适配器放行的项目（去重、标注 `shared: true` 字段供前端区分
+  展示）；`CreateConversation` 的归属校验放宽为「本人自有 **或** 适配器放行」。会话
+  本身仍归属创建者（owner 不变），只是创建权扩展到成员。
+- **为何组合不出**：`ListProjects(owner)` 的 SQL 按 owner 过滤，无回调；建会话校验在
+  store 层硬编码。与 C4（EXT-8）同因：纯下游无法改变基座 owner 过滤。
+- **兼容方式**：未注册适配器＝现状；放行结果带审计。internal 行为扩展，SurfaceVersion
+  不变。
+- **验收**：成员 B 的 `GET /api/projects` 含共享项目（shared 标注）且不含未授权项目；
+  B 在共享项目下 `POST conversations` 成功、会话 owner=B；撤销成员后两者立即拒绝；
+  项目拥有者视角无任何变化。
+
+## 4. EXT-16（←B-5②）执行后端接口：隔离执行档（Q2 阶段二，G2-8 原型）
+
+- **场景**：Q2 裁定「暂时禁用，但后续执行任务时肯定还是要代码执行能力」。v0.2.0 已
+  交付启动级硬关闭（`Options.DisableExecTools`，Backend #110）；隔离档是恢复执行能力的
+  路径：执行的是**模型生成的代码**，须按不可信代码对待（方案 §3.4）：只读系统根、仅挂
+  会话工作目录与技能目录、默认无网、cgroup 资源限额、硬超时、按项目 venv 只读挂载；
+  本机已实测 `bwrap --unshare-all` 可用（无特权 userns 被 AppArmor 限制，bwrap 专门
+  策略放行）。
+- **希望公开面**：`internal/tools/exec_interpreter.go` 的进程启动点抽象为「执行后端」
+  接口（`ExecBackend`：`Run(spec) → result`），启动参数选择后端：
+  `ExecBackend = direct | sandbox`（缺省 direct＝现状）。sandbox 后端以 bwrap 实现
+  （资源限额经 systemd-run/cgroup v2）。`extension.Options` 增加
+  `ExecBackend string`（加法；空＝direct）。`DisableExecTools` 保留为最终兜底，优先级
+  高于后端选择。
+- **为何组合不出**：现实现直接 `exec.Command`（`runInterpreter`），无后端抽象；沙箱
+  参数组装（bind 清单、网络命名空间、限额）属平台面，下游插件无法注入。
+- **兼容方式**：缺省 direct＝逐字节现状；`Options` 加字段＝SurfaceVersion 升。RDM 在
+  G3-7 才切换 sandbox；G1–G2 期间维持 `DisableExecTools=true`。
+- **验收**：sandbox 后端下逃逸负例全部被拦——读 `~/.secrets`、读其他会话目录、访问
+  外网、fork 炸弹、超时不可杀均为拒绝/杀灭；会话工作目录内 docx 生成任务成功且产物
+  可登记；direct 后端与现状一致（回归）。
+
+## 5. 不在本申请包（显式排除）
+
+- EXT-6/7/10/12 完整形态：仍在 C1–C7 包（EXT-6…12）受理轨道，节奏不变。
+- 提示词随执行可用性切换（`base.deliverables` 在禁用期的降级文案）：基座自有任务，
+  不占 EXT 编号。
+- UI 仓 nightly runner 修复：与代码无关（rolldown 原生绑定缺失），另立任务。
+
+## 6. 受理建议
+
+| 申请 | 内容 | 优先级 | 兼容 |
+|---|---|---|---|
+| EXT-13 回合内共享检索 | G1 序 4 硬前置（R04/R05） | **P0 最先** | 不变（internal） |
+| EXT-15 项目列表/建会话共享 | G1 序 4（R03/SR-G10） | P0 | 不变（internal） |
+| EXT-14 命令即工具 | G2/V0.1 端到端硬前置（Q4 方案 A） | P1 | 升（加字段） |
+| EXT-16 执行后端接口 | G2-8 原型（Q2 阶段二） | P1 | 升（加字段） |

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

@@ -0,0 +1,242 @@
+# 子代理分工、模型分级路由与任务沙箱：调研与方案
+
+状态：**proposed（2026-10-10）**；owner：weichen；方向来源：用户 2026-10-10 会话
+（①充分利用子代理；②复杂任务用 dmxapi 的 Sonnet/Opus，常规任务用 MiniMax-M2.7-highspeed；
+③记录并规划毫秒/亚秒级任务沙箱，**暂不实现**；④对「体感不如 codex/claude code/kimi」的判断）。
+本文是这四件事的主记录；未经评审的部分一律为「待确认」，不因被记录而视为已批准。
+
+依据级别：本机实测为 **SELF**（命令与输出见任务卡 evidence 与 §7 复现脚本）；外部资料为
+一手页面抓取（访问日 2026-10-10，URL 在 §8）；推断明确标注「推断」。
+
+## 0. 结论先行
+
+1. **方向对，落点要改。** 子代理只在「读多写少、可并行、输出冗长」的环节净收益为正；
+   交付物的写作与关键决策保持单线程（单一写者）。把复杂任务**整单**交给 Claude，会把最贵、
+   最慢的模型放在 token 最多的工具循环里——A/B 里 opus-5-5 耗时约 4.7 倍、工具失败更多。
+   证据更支持**按阶段/角色路由**：Claude 只做 token 少、杠杆大的环节（复杂任务的规划简报、
+   终稿综合、独立核查），检索、阅读、抽取、跑 Python、排版留给 MiniMax。
+2. **「体感差」不能主要归因于 MiniMax。** 同一模型换 harness 的分差与相邻代际换模型同量级
+   （MiniMax-M2.1 换 harness 差 7.0 分；同 harness 换成 Opus 4.5 差 3.9–7.4 分 [H11]）。
+   本机实测还发现两处直接拖累体感的协议层问题（§1.2），应先修再下结论。
+3. **「编造数字」更像模型属性，但可以用机制压住。** 同 harness 下 7→0 支持这一点；但
+   24 个相关观测里「0 处」的 95% 置信上界约 12.5%，不足以宣称清零（§1.3）。数字溯源闸门
+   比换模型便宜，且两者可叠加。
+4. **沙箱：现在的需求表述里有三处需要修正**（§4.1）——overlay 不是快照、快照只是把冲突
+   推迟到合并、「立即销毁」必须先留存审计材料。修正后，本机条件下 **bwrap + 冻结基底 +
+   overlay** 能做到约 7ms 启动（实测），足够作为默认档；microVM 档只在需要更强隔离时启用。
+
+## 1. 现状核实（SELF，2026-10-10）
+
+### 1.1 已有能力（源码，backend `421fee8`，其 deps/agent-native `3b92cb6`）
+
+| 能力 | 现状 | 位置 |
+|---|---|---|
+| 子代理委派 | 模型可调 `delegate_task`，参数 `agent∈{general,explore,research,plan,verify,writer}`、`task`、`background`；深度 1（子不能再派） | `internal/runtime/llm.go:310`、`internal/runtime/llm_direct.go:668`、`internal/runmgr/runmgr.go:1462` |
+| 子代理模型 | 由画像 frontmatter 决定：`writer` 用 `chat` 档，其余 7 个用 `lightweight` 档；调用方**不能**指定模型 | `internal/prompts/library/agent-sub-*.md`、`internal/runtime/sub_loop.go:48` |
+| 模型档位 | 只有两档：`models.chat` 与 `models.lightweight`（轻量档空则回落主档），另有 `models.chat.fallbacks` 回退链 | `internal/runtime/model.go:54,84`、`internal/settings/settings.go:73-84` |
+| 评审/验证 | `review_findings` 并行 1–3 个审查子代理再逐条验证；验证子代理输出 `VERDICT` | `internal/runtime/llm.go:311`、`agent-sub-verify.md` |
+| LLM 协议 | 后端恒走 OpenAI chat 协议（`openLLMClient` 不设 `Protocol`）；内核已实现 Anthropic Messages 客户端（含 `cache_control`）但**产品未接线** | `internal/runtime/llm.go:491`、`deps/agent-native/runtime/llm/anthropic.go` |
+| 工具并行 | 内核支持 `ExecParallel`，直连路径未设置 → 默认**串行**执行同一回合的多个工具调用 | `deps/agent-native/runtime/loop.go:203,596`、`internal/runtime/llm_direct.go:268` |
+| 执行隔离 | EXT-16：`run_shell`/`run_python` 可选 bwrap 档（断网、只读根、tmpfs 遮蔽 `/home` `/tmp`、仅会话目录可写、ulimit、超时杀命名空间）；缺省 direct | `internal/tools/exec_backend.go` |
+
+### 1.2 本机实测发现的问题
+
+| # | 发现 | 影响 | 证据 |
+|---|---|---|---|
+| F1 | **子代理结论被压成 160 字**：直连路径 `delegate_task` 只把 `res.Summary` 回给父，而 `Summary` 是子代理全文的前 160 字（全文在 `res.Text` 里，被丢弃） | 子代理做完的检索/调研结论，父代理只看到开头一句；这与「上下文防火墙」的用法正好相反，也会诱发父代理凭摘要补细节 | `llm_direct.go:697-700`、`runmgr.go` finishChild（`Summary = truncate(fullText, 160)`） |
+| F2 | **MiniMax 思考内容混在正文流里**：OpenAI 兼容流式接口默认把思考放进 `content` 的 `<think>` 块；后端在回合结束时才剥离 | 回合进行中前端收到的 `message.delta` 先是一大段思考原文，界面上「正文」区域先显示推理过程；思考计时也不准。官方提供 `reasoning_split=true`，实测开启后思考改走独立的 `reasoning_content`/`reasoning_details` 字段（3/3 次），TTFT 中位数 0.69s | `llm_direct.go:418-475`；probe2 实测（§7） |
+| F3 | **sandbox 档下交付物生成跑不通**：python-docx/openpyxl/python-pptx 装在 `~/.local`，被 `--tmpfs /home` 遮蔽；`run_python` 描述里「缺失时 pip install --user」在断网档也失效 | RDM 计划 G3-7 切 sandbox 时，docx/xlsx/pptx 生成会直接失败；EXT-16 的「docx 生成任务成功」验收用的是 `printf` 桩，未覆盖真实库 | bench2/bench3 实测：EXT-16 同形参数下 `import docx` → ModuleNotFoundError；只读挂载依赖层后 `import docx, openpyxl, pptx` 成功 |
+| F4 | **Claude 走兼容协议丢能力**：经 dmxapi/lmuai 的 OpenAI 兼容接口，4 个 Claude 型号都不返回思考字段；改走 dmxapi 的 `/v1/messages` 原生接口，第二次调用 `cache_read_input_tokens=5043`（缓存生效） | A/B 中 Claude 一侧每步按全价重算前缀、没有思考回传——47 分钟的耗时与工具失败部分可归因于此（推断，需日志确认） | anthropic_probe 实测（§7） |
+| F5 | 直连路径工具串行 | 模型一次发出多个独立检索时逐个等待；4 个被测模型都能在一个回合里给出 2 个并行 tool_calls | probe 实测（§7） |
+
+### 1.3 A/B 数据的正确读法
+
+内部 A/B（`.task/model-ab/ab-opus.json` 对 `.task/phase05-eval/after-p5.json`，4 任务 6 回合）：
+MiniMax 编造数字 7、约 10 分钟、工具 97/失败 19；opus-5-5 编造 0、约 47 分钟、工具 99/失败 33。
+
+- 样本小且相关：「0 处」的 95% 置信上界约 3/24≈12.5%（rule of three）[R39]，不能宣称清零。
+- 两侧都不在最佳状态：Claude 一侧走兼容协议（F4）；MiniMax 一侧思考回传已实现
+  （`context.thinkReplay=auto`，`ctxasm.go:206`），但流式分流有 F2 问题。
+- 速度：公开测速两者相近（opus-5-5 约 96 t/s [H25]，M2.7-highspeed 官方约 100 TPS [H4]；
+  本机短文本实测 48.9 对 50.7 t/s），所以 4.7 倍耗时更可能来自思考量、步数、重试与无缓存（推断）。
+- Vectara 有据摘要幻觉率 M2.7 12.9%、Opus 4.6 12.2%、Sonnet 4.6 10.6% [R40]：「读懂原文」差距
+  不大；差距更可能出在「缺数据时去猜」（推断）。
+
+### 1.4 其余现状（补充核实，SELF）
+
+- 评测：`eval/live` 是 go test（env：`AGENT_EVAL_BASE` 实例地址、`AGENT_EVAL_TASKS` 过滤、
+  `AGENT_EVAL_TURN_TIMEOUT`），golden 任务 4 个（`tasks.json`）；A/B 工具 `eval/ab.go`、`switch.go`。
+- 打断/插话：有 `CancelRun`（停止按钮）与子代理中断续跑；**没有**「运行中用户输入排队、
+  当前工具结束后本轮送达」的 steering 队列（未找到实现）。
+- 检查点：文件写入有改前快照日志（`runmgr/rewind.go` `NoteFileCheckpoint`）。
+- 直连路径声明 13 个工具；提示词库 base-* 共约 6.7KB（base-deliverables 5.2KB 最大）。
+
+## 2. 子代理分工：证据与方案
+
+### 2.1 证据要点（外部，来源见 §8）
+
+- **有益面**：广度优先检索（Anthropic 多智能体研究系统：主+子比单 Opus 高 90.2%，复杂查询
+  耗时最多降 90%，代价 token 约 15 倍 [R13]）；上下文防火墙——18 个模型都随输入变长退化
+  [R14]，子代理只回 1–2k token 摘要 [R17]；fresh-context 审阅（Devin Review 均 2 bug/PR，
+  58% 严重 [R20]）。
+- **有害面**：写入耦合（并行写手风格冲突，「多代理贡献智能、写入保持单线程」是当前可行解
+  [R19][R20]）；顺序任务 −39%~−70%、单代理基线 >45% 时加代理为负收益、无中心校验时误差
+  放大 17.2 倍 [R21]；Claude Code 官方也建议迭代密集/共享上下文/延迟敏感时留在主会话 [R1]。
+- **契约**：委派带目标/输出格式/工具面/边界/预算；回传浓缩结论 + 证据指针（文件/行），
+  大产物落盘只回引用 [R13][R17]；限额：禁嵌套、并发 3–5、按复杂度分档 [R7][R13][R21]。
+
+### 2.2 方案（增量，每项独立任务卡）
+
+| # | 内容 | 验收（可判定） |
+|---|---|---|
+| D1 | **修 F1**：`delegate_task` 回传改为「子代理全文（上限 4k 字）+ 超长落盘 `subagent-result.txt` 只回指针 + 工件摘要行」——内核 `subagent.CapParentText` 已有此语义（backend 侧没走它） | eval/live 前后对照：父代理引用子代理结论的回合，其终稿中来自子代理的事实不再凭摘要补齐；单测覆盖超长截断 |
+| D2 | **委派简报规范**：`delegate_task` 描述与 base-method 提示补「简报四要素」（目标、输出格式、工具/来源边界、完成判据），禁止把大块原文粘进 task | 提示词 diff + eval/live 计划/委派质量指标不回退 |
+| D3 | **并行工具执行**：直连路径设置 `ToolExecution=parallel`（读类工具并发、写类串行的区分后续再议） | 同回合多工具调用 wall-time 下降（评测记录）；事件序号仍单调 |
+| D4 | **证据账本子代理**：research/explore 画像的输出格式改为「结论 + 原文引用（文件/页/行）+ source_id」，数字必须带 source_id 或 Python 计算 ID；终稿前由确定性校验拦截（接质量计划 P5 的事实一致性检查） | 编造数字在闸门处被拦且计数；子代理回传含引用率 100% |
+| D5 | **角色×模型矩阵**（依赖 §3 R2）：新增/调整画像的 `model:` 支持 `claude-*` 档；`writer` 保持 chat 档，新增 `composer`（终稿综合）与 `planner-complex`（复杂任务规划简报）画像走强模型档 | 画像 frontmatter 生效（SubagentSpec 解析）；评测 A3/A5 组可配置 |
+
+边界：子代理深度维持 1（现状即禁嵌套）；并发上限维持产品侧 3；本方案不引入子代理间通信。
+
+## 3. 模型分级路由：证据与方案
+
+### 3.1 证据要点
+
+- **整单路由不划算**：我们的 A/B 中 opus-5-5 耗时约 4.7 倍、工具失败 33 vs 19；公开测速两者
+  相近（§1.3）。Devin Fusion 的教训：强模型当全程主控只降本 33%，且「判断即交付物」的难题
+  上掉分 [R30][R31]。
+- **按阶段/角色路由有正证据**：Sonnet 执行 + Opus 顾问 +2.7pp 且降本 11.9%；Haiku + Opus 顾问
+  在 BrowseComp 19.7%→41.2% [R32]；Aider「强规划+便宜编辑」$13.29 得 64.0% 胜 o1 单跑 $186.5
+  得 61.7% [R12]。反例也存在（BrowseComp-Plus 上弱编排+强子代理更好 [R21]）——**放哪一层必须
+  实测**，这正是 R3 实验的目的。
+- **协议与缓存**：Claude 经 OpenAI 兼容层不回思考、不支持缓存、忽略 strict（官方文档 [H37]，
+  本机 F4 实测缓存恢复）；缓存按 tools→system→messages 前缀匹配，中途改工具集会整缓存失效
+  [R35][R36] → 模型切换只应发生在阶段边界，每角色固定 system/tools 前缀。
+
+### 3.2 方案
+
+| # | 内容 | 验收 |
+|---|---|---|
+| R1 | **Claude 原生协议接线**：`models.chat.protocol = openai-chat \| anthropic`（设置项），anthropic 时用内核现成的 `llm/anthropic.go` 客户端（base 指向 dmxapi `/v1/messages` 根），回传 thinking 块与 signature、挂 `cache_control` 断点、usage 记缓存读写（N3 计费拆分已有字段） | 同会话第二次调用 `cache_read_input_tokens>0`（SELF 复现 F4 的探针即验收集）；thinking 块原样回传（删改会 400 [H24]） |
+| R2 | **角色路由表**：设置新增 `models.<role>`（role∈composer/planner/verifier，缺省回落 chat 档）；画像 frontmatter `model: <role或具体型号>`。默认建议：chat=MiniMax-M2.7-highspeed（不变）、composer=claude-sonnet-5（dmxapi，原生协议）、verifier=异模型（deepseek-v4-flash 或 claude）、复杂任务 planner=claude。Opus 系列留给最难任务手动指定 | 角色解析链单测；`models` 列表来自各端点 `/v1/models`（已核实 dmxapi 有 sonnet-4-6/sonnet-5/opus-4-6/opus-5-5 等，见任务卡 evidence） |
+| R3 | **路由 A/B 实验**（扩展现有 eval/ab.go）：组别 A0 全 MiniMax / A2 MiniMax+数字闸门 / A3 A2+Claude 终稿 / A4 A2+Claude 核查 / A5 Claude 规划+终稿+核查、MiniMax 执行；关键组加 Sonnet 变体。指标：无来源数字占比、含编造交付物比例、pass^3、p50/p95 耗时、分角色成本（含缓存）、工具失败分类。样本：30–50 任务×3 次（宣称编造率<5% 需 ≥60 份零编造样本 [R39]）；<3pp 差异慎下结论 [R49] | 选型报告入任务卡，来源 GATE/SELF 标注 |
+| R4 | **升级规则进 harness**（不依赖模型自觉 [R20]）：连续 N 次工具失败、闸门拦截无来源数字、检索「未找到」三类事件触发 advisor 咨询或角色升级 | 评测中升级触发可观测；误升级率记录 |
+
+运维事实（2026-10-10，SELF）：lmuai 月额度已耗尽（$1303.32/$1300，2026-11-05 重置）——R1/R3
+的 Claude 侧建议先走 dmxapi（余额 ¥0.48，**需充值**，此前 A/B 卡估算全量对照 ¥50–100）。
+
+## 4. 任务沙箱：记录与规划（**不立即实现**）
+
+### 4.1 对原始思路的三处修正
+
+1. **「overlay 隔离他人变更」不成立**：内核文档明确「下层在挂载期间被修改的行为是未定义的」
+   [S1]；本机实测运行中的沙箱能看到下层后续修改（bench2 第 5 段）。**一致视图必须来自不可变
+   基底**（冻结副本或 git commit 物化），而不是叠在活动目录上的 overlay。
+2. **快照只是把冲突推迟到合并**：Codex cloud/container-use/Cursor 都以 diff/PR 回收，冲突在
+   写回时用基线校验暴露 [S23][S28][S26]。「互不影响」的成本是写回时的三方合并与人工兜底，
+   设计里必须显式包含这一步，否则快照只是把失败挪到了最后。
+3. **「立即销毁」与审计有张力**：销毁的应是计算资源与可写层；转录、diff、工件哈希、环境
+   清单要按 TTL 封存（Codex 删前存快照 [S23]、container-use 留命令史 [S28]、Cursor 留工件
+   [S26]）。本仓的证据门禁（AGENTS.md）同样要求可复核输出——封存记录是硬约束。
+
+另一处简化：硬链接克隆（cp -al）对「原子替换写入」是安全的（rename 换 inode），但对原地
+写入会穿透（共享 inode）——本机实测（bench3 第 3 段）。只可作为「可检测」方案并配
+sha256/mtime 清单复核，不可当作完整快照。
+
+### 4.2 目标形态（任务工作区沙箱）
+
+一次任务 = 冻结基底（会话/项目材料的不可变视图）+ 私有可写层 + 确定性依赖层 + 出口管控 +
+回收（diff 与工件清单）+ 封存后销毁。智能体在其中任意折腾不破坏原始资料；产出经校验写回。
+
+### 4.3 分层架构与延迟预算（本机实测，SELF）
+
+| 层 | 机制 | 启动 | 适用 | 备注 |
+|---|---|---|---|---|
+| L0 进程沙箱 | bwrap（EXT-16 现状）+ 依赖层只读挂载 | **p50 7.3ms**（/bin/true，n=30）；带 overlay 同为 ~7ms | 默认：解释器执行、交付物生成 | 修 F3 后 python-docx 全链路可用（import 60ms、1 页 docx 76ms） |
+| L0.5 工作区沙箱 | L0 + `--overlay-src <冻结基底> --overlay <宿主upper>` | ~7ms（实测） | **多任务并发、需要一致基底与可回收 diff 时** | upper 即增量；快照语义来自冻结基底而非 overlay |
+| L1 容器 | docker（overlayfs 驱动） | `run --rm` p50 142ms（redis:7 true，n=10） | 依赖隔离更强、镜像化环境 | 可加 warm pool 压冷启动；单机自托管无障碍 |
+| L2 microVM | Firecracker/gVisor | 未实测；E2B 等托管方当前文档只称 "fast Linux VM"（量化数字已不可得，**未经证实**） | 不可信代码、最强隔离 | 本机有 /dev/kvm；引入与维护成本高，暂缓 |
+
+支撑件（与层正交）：
+
+- **冻结基底**：git 材料以 commit SHA 物化（同 SHA 只物化一次、多任务只读共享）；非 git 材料
+  用 cp -al + sha256 清单（写回前复核，变了即判基底失效）。git worktree add 实测 192 文件
+  11ms，overlay 直接盖工作树 ~10ms，两者都够快。
+- **依赖层**：项目 venv / site-packages 只读 bind（实测修复 F3；RDM 方案 §3.4 原有此意）。
+- **数据库**：SQLite 用 `VACUUM INTO` 取一致快照 [S32]；PG 用零连接模板库克隆（PG18 XFS 上
+  有 CLONE，ext4 上是复制 [S11][S37]——量级以库大小为准，必要时评估独立 XFS 卷给 reflink）。
+- **网络**：默认无网（现状）；将来要放开时，按 sandbox-runtime 的形态做出口代理白名单 +
+  代理侧凭据注入（密钥不进沙箱）[S-RT]。
+- **回收与写回**：沙箱退出后读 upper → 生成 `git diff --binary` 补丁 + 工件 sha256 清单；
+  写回用 CAS（目标当前哈希==基底哈希 → 原子替换；不等 → `git merge-file` 三方合并，冲突停给
+  人）；写回前留前像。git 目标用 `update-ref <ref> <new> <old>`（本身就是 CAS）[S46]。
+- **封存**：base SHA、补丁、工件哈希、转录指针、环境清单（依赖层版本）、退出码，按 TTL 留存
+  后销毁工作区目录。
+
+### 4.4 与现网的关系
+
+- EXT-16 sandbox 档是**进程级**隔离（单次命令）；本节是**任务级工作区**，两者叠加而非替代。
+  首个落地形态：ExecSpec 增加工作区概念，sandbox 档把「会话目录 bind」换成「冻结基底 overlay
+  + 私有 upper」。
+- 已知缺口顺带记录：小队内核 ExecConfig、工作流 ScriptCommand 仍 direct（EXT-16 卡内遗留）；
+  沙箱档覆盖它们是前置条件之一。
+
+### 4.5 非目标与开放问题
+
+- 不做多租户硬隔离与 OS 级安全声明（沿用质量计划 §5 边界）。
+- 开放：是否划独立 XFS 卷换 reflink；gVisor 试用；warm pool 是否值得（L0 已 7ms，大概率不值）；
+  Windows/macOS 不在范围。
+
+## 5. 分期与验收总表
+
+| 增量 | 内容 | 依赖 | 备注 |
+|---|---|---|---|
+| 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 ✅（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-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. 与既有规划的关系
+
+- [智能体工作流质量改进](2026-10-09-agent-quality-improvement-plan.md)：本文是其「模型 A/B」
+  结论的后续与 P4/P5 的延伸（D4 与 P5 合流；E5 继承 A/B 方法论并扩大样本）。
+- [EXT 申请包 G1](2026-10-09-ext-g1-b1-b3-exec-backend.md)：E1-F3 修复其 sandbox 档的交付物
+  缺口；§4 工作区沙箱是 EXT-16 的演进方向。
+- [RDM 阶段总案](2026-10-07-rdm-phase-plan.md)：G3-7 切 sandbox 前置依赖 F3 修复。
+- Agent 栈 N2 WP5（子代理/后台派生）：D1–D5 在产品层消费其内核端口，不改内核契约。
+
+## 7. 本机实测的复现要点（SELF，脚本存于任务卡 evidence 同目录说明）
+
+- 启动延迟：bwrap 命名空间 / +overlay / +持久 upper 各 30 次（bench.sh、bench2.sh §3）。
+- F2：`reasoning_split=true` 前后各 3 次流式（probe2.py，观察 delta 字段分布）。
+- F3：EXT-16 同形参数下 `import docx` 失败 vs 只读挂载 `~/.local/.../site-packages` 后成功
+  （bench2 §1–2、bench3 §1–2）。
+- F4：dmxapi `/v1/messages` 连续两次调用，第二次 `cache_read_input_tokens=5043`。
+- overlay 非快照：运行中沙箱读到下层并发修改（bench2 §5）；cp -al 对 rename 安全、对原地写
+  穿透（bench3 §3）。
+- docker 冷启动 10 次（bench.sh）。
+
+## 8. 来源（除标注 SELF 外均为 2026-10-10 抓取的一手页面）
+
+- [S1] Linux 内核 overlayfs 文档：https://docs.kernel.org/filesystems/overlayfs.html
+- [S11] BoringSQL instant database clones：https://boringsql.com/posts/instant-database-clones/
+- [S23] Codex environments/git-worktrees：https://learn.chatgpt.com/docs/environments/git-worktrees
+- [S26] Cursor cloud agent：https://cursor.com/docs/cloud-agent
+- [S28] container-use CLI：https://container-use.com/cli-reference.md
+- [S32] SQLite VACUUM INTO：https://www.sqlite.org/lang_vacuum.html
+- [S37] PostgreSQL 18 release notes：https://www.postgresql.org/docs/release/18.0/
+- [S46] git-update-ref：https://git-scm.com/docs/git-update-ref
+- [S-RT] Anthropic sandbox-runtime（Linux=bwrap+seccomp、网络默认全拒+代理白名单+凭据注入、
+  Apache-2.0）：https://github.com/anthropics/sandbox-runtime
+- [S-CX] Codex sandboxing（Linux 用 bwrap；read-only/workspace-write/danger-full-access）：
+  https://learn.chatgpt.com/docs/sandboxing
+- [H4] MiniMax 定价与速度：https://platform.minimax.io/docs/pricing/overview 、
+  https://platform.minimax.io/docs/guides/text-generation
+- [H24] Claude thinking 块回传要求：https://platform.claude.com/docs/en/build-with-claude/extended-thinking
+- [H25] Artificial Analysis（opus-5-5 96.4 t/s 等）：https://artificialanalysis.ai/models/claude-opus-5-5
+- [H37] Claude OpenAI SDK 兼容层限制：https://platform.claude.com/docs/en/api/openai-sdk
+- [R1][R12][R13][R14][R17][R19][R20][R21][R30][R31][R32][R35][R36][R39][R40][R49] 子代理与
+  路由调研来源清单见任务卡「调研来源」节（Claude Code docs、Anthropic/Cognition 工程博客、
+  arXiv 2512.08296 等，URL 全量随卡保存）。
+

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
+
+修订：r1；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：方案获批发布，实施自首选增量 U1+U2 启动；业务实施/迁移/压测/部署仍为 NOT_RUN，逐项以实施任务卡为准。
+需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-11（Asia/Shanghai）。
+关联任务：Dev `.task/feature-collaboration-storage-plan.md`（方案任务，已发布）；后续 U1+U2 实施由独立任务承接。
+正文中的源码路径以 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 调查记录。需求人数已确认；容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
+
+方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
+
+首选下一增量是 **U1 + U2 的详细实施与测试合同**：固定目标实例与 PG 测试环境，解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行；不要先增加应用副本。各实现任务启动前复核在途 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-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-service-restart-data-recovery.md

@@ -0,0 +1,295 @@
+---
+title: 服务重启与全量数据恢复方案
+type: fix
+date: 2026-10-12
+artifact_contract: ce-unified-plan/v1
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# 服务重启与全量数据恢复方案 r2
+
+确认状态：待人工评审。当前交付为源码调查、方案与实施/验收计划；业务实施、故障注入、部署、运行验收均为 NOT_RUN。
+修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。
+需求来源：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 `5e57029b439e5690f28dc6002f9784f0b08920eb`；Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `aaced8796bb45d151833e12bc1cc17fc5090ef6d`；Documents `23e2276905eaf3d5b266a5218a53a12a38321284`。来源为 SELF·源码观察，原始命令和输出由 Dev `make evidence` 写入本任务卡；风险是源码推断，不是已重现事故。
+
+| 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
+|---|---|---|
+| 数据库绑定 | `scripts/svc.sh:1373` 已统一解析 dbref/DSN/config；裸启动、restart/deploy 停前预检已接入 | 自定义 data/plugins 在参数重建时可能漂移；临时环境配置无法保证下次存在；配置多次逐键更新有崩溃中间态 |
+| 服务生命周期 | svc 管理 agent/static/postgres；PostgreSQL 复用 pgdata；分发仓有单应用 systemd 模板 | svc 没有服务组依赖恢复与持久启动意图；无统一进程组监管；不管理 Redis 类型 |
+| 启动与停机 | 启动对账开放 run；优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前；HTTP停机超时可跳过flush；无所有worker等待；子代理 cancelled 可覆盖 interrupted |
+| 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消；子代理先派生再写文件标记；notice消费非事务且绕过PG会话占用 |
+| 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease，终态有fencing；额度有持久表 | 续租只有定义未接入生产调用；15分钟租约可过期；额度无崩溃回收；不能据此宣称安全接管 |
+| 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行，kill窗口丢命令；跨实例取消入队缺conversation；Surface失败仍可清pending且仅扫100条 |
+| 工具副作用 | Native Session已有tool intent/result转录、安全重放判定；Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义；Native的未知效果被写成工具错误后仍可继续模型，尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 |
+| 文件与备份 | blob临时写+rename；工件元数据在DB；SQLite在线备份；svc有pg_dump | 覆写文件与更新元数据不是同一原子提交；未显式fsync；DB备份不含上传、工件、工作区、转录、配置/版本 |
+
+当前登记元数据显示 dev 绑定 `pg1/agent`，部署制品的 Backend revision 与上述Backend一致；这只证明登记和制品元数据。**实际运行进程的数据库身份、全栈恢复、数据耐久性尚未实测，不能写为PASS。**
+
+旧报告中“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 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 |
+
+覆盖“所有数据”需要先完成数据归属清单：除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)。
+
+## 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->>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-->>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历史记录保留，不强改成成功。
+
+用户侧复用现有任务状态、对话卡和管理员恢复入口，显示恢复原因、进度和允许动作；SSE按持久seq补发并丢弃旧事件，页面刷新重载权威快照。断连或无增量不能推断任务完成。实施界面前重读根DESIGN.md并遵循UI令牌、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自动覆盖当前数据。
+
+首期备份取得明确停写窗口：关闭准入、排空或隔离在途操作、停止全部相关写者，核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致；写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点，manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。
+
+恢复到新目标首先处于隔离验证模式，不启动任务调度/副作用，也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离：可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离；不得为此擅自轮换共享凭据。生成新的恢复权威代次，并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏；旧实例不可联系不能当作停止证明。无法核实则保持副作用hold，只开放受权的数据核验。
+
+同时对账恢复点至故障/隔离完成期间的外部效果：它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对，将已确认动作登记到恢复账本，确认安全后逐项解锁；不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。
+
+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. 实例与数据恢复身份
+
+对应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. 服务组与进程监管
+
+对应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及下游契约的最小状态映射表，作为设计评审前提。
+验收：排队/主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拒绝程序自动回退；数据回退不静默丢新写入。
+
+### 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不能宣称完成用户的全部需求。
+
+## 8. 验证合同
+
+| 故障/操作 | 最小判据 | 对应需求 |
+|---|---|---|
+| `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 |
+| 应用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实现以当前代码为基础继续，不另起重复模块。
+
+调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。**U1/U2启动实施前必须人工二选一**：(a) 以`feature/svc-autorecover`为实施载体，把本案r2作为其需求与方案来源填入该任务卡后按其流程推进；(b) 记录原因后放弃或合并该任务卡，由本案派生的独立任务实施；两任务不得同时充当svc启动/监管改动的权威，该归属决定与首批实施范围一并报批；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。
+
+备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
+
+实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。
+
+下一任务建议为U1并同步审查U3生命周期缺口：先保证再次启动绝不换库、换数据根或假就绪，再接监管和自动续跑。预计产物为兼容manifest合同、数据归属清单、隔离真实PG恢复回归与生命周期设计；进入实施前人工批准本案的需求、设计和首批测试范围。后续数据库备份、systemd安装、部署/启停与故障实验分别按授权执行。
+
+## 10. 全系统完成条件
+
+只有在所有启用的必需服务/插件被纳入清单、R1–R10均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
+
+本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。

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

@@ -0,0 +1,182 @@
+---
+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 方案 r1
+
+确认状态：**已批准**（2026-10-12 用户「批准，继续推进」：需求拆解→实施计划五阶段及 U1/U4 规格一并批准；授权推送/PR 与启动 U1/U4 实施；合入仍由 owner 执行）。业务实施、测试、部署与运行验收在批准时仍为 **NOT_RUN**，由后续实施任务推进。
+修订记录：r1＝2026-10-12 草案经源码复核后定稿（四项取舍采纳；补齐 §6 合同；对齐恢复方案 KTD 与已合入的 recovery U1 实例身份）；同日获批并进入推送与 U1/U4 实施。
+需求来源：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 |
+
+与 [服务重启与全量数据恢复方案 r2](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. 当前事实及重点差距
+
+源码基线（SELF·工作区观察，启动 precheck READY）：Dev `af9c2de663be5ff102dcab7698464a645832f569`；Backend gitlink 以该提交为准；本地评审时曾对照 `3fa0d3a` / Backend `696ef15`，与当前 main 可能有漂移，实施前以 `task-sync` 后 SHA 为准。运行验收 **NOT_RUN**。
+
+| 对象 | 已存在的基础 | 尚需补齐 |
+|---|---|---|
+| 部署来源 | `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 | `user create\|reset-password\|list`；省略密码 → 随机明文一次 + `must_change` | 无密码创建 + 激活 Key；恢复 Key；OpenExisting（不建空库、不静默 migrate） |
+| API Key | 明文只显示一次；可长期复用；无 TTL/次数 | **独立**一次性登录凭据表；不可走 Bearer/`?key=` |
+| 强制改密 | 前端门控 + `/api/me` 标志；`changePassword` 要求原密码 | 服务端中间件拦截待改密/受限会话；设密分型（一次性会话不要求原密码） |
+| 安装双轨 | Dev `svc deploy` 多实例；Releases `install.sh` 系统 systemd | 统一部署计划；`install.sh` 薄封装或明确遗留 |
+
+命题裁定（源码复核）：
+
+1. 长期 API Key 是 **show-once plaintext，不是 single-use** — **成立**。
+2. **无**统一中间件拦截 `must_change_password` — **成立**。
+
+## 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 分源 |
+
+## 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` 变为薄封装或文档降级为遗留，禁止第三套生命周期。
+
+## 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 不存在则失败；运维模式可禁止自动 migrate / 要求 schema 兼容。
+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 组合、发布包、真机、数据保护 | 两种部署 × 存储档；故障注入；浏览器 + 真机；治理回归 |
+
+**近期优先 U1、U4**（可并行兄弟分支、共用 R0）。跨仓顺序：Backend（U4）→ Frontend（U5）→ Dev gitlink + `svc.sh`（U1/U2/U3/U5）；组合 `make test` 后宣称可合入。
+
+### 必须覆盖的验收场景（摘要）
+
+干净机器二进制安装；源码固定提交与子模块；两种部署互切后数据不变；构建/摘要/配置失败旧服务可用；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**。
+- 本任务交付终点：正式提案 r1 + U1/U4 规格 + 任务卡与索引入口；推送/PR 须另获授权。
+- 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
+
+## 10. 规划进展与下一步
+
+- 本次推进：源码复核；四项取舍定案；正式提案 r1；U1/U4 规格细化。
+- 首选下一任务（**待授权**）：并行启动 U1 实施与 U4 实施（兄弟分支、共用 R0）；U2/U3 规格可随后写作但不阻塞 U1/U4。
+- 前置：人工批准本提案 r1（至少需求表 + 方案设计 + U1/U4 实施计划阶段）；实施前 `make precheck` 与 `task-sync`。

docs/proposals/INDEX.md

@@ -6,12 +6,24 @@
 
 ## 先看哪一份
 
+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，
 应由负责人补齐；不能仅凭任务创建人推断全部规划的负责人。
@@ -74,6 +86,10 @@ Dev 链接均指向对应任务 PR，可从其任务卡继续追溯组件 PR；
 | [N2 实施案](2026-10-07-agent-stack-n2-plan.md) | 栈总案 N2 的六 WP：上下文、协议、工具、skills、子代理、装配 | 未单列确认状态及 owner；正文称 N2 开工 | Documents [#42](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/42) 已合入；Dev [#244](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/244) 已合入（merge `7e3ba10`），闭卡 [#247](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/247)。卡内自述六 WP 落地；本索引未重放 |
 | [N3 实施案](2026-10-07-agent-stack-n3-plan.md) | 栈总案 N3：持久与可观测 | 页首未单列确认状态及 owner；正文称 N3 开工 | Documents [#43](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/43) 已合入；Dev [#248](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/248) 已合入（merge `2836a87`），闭卡 [#249](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/249)。卡内自述六 WP 落地；本索引未重放 |
 | [Q2/Q3 实施案](2026-10-07-agent-stack-q2q3-plans.md) | 栈总案 Q2 拓扑与 Q3 收敛互通 | 页首未单列确认状态及 owner | Documents [#44](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/44) 已合入；Dev [#250](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/250) 采纳方案，[#251](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/251)（merge `452c00a`）与 [#253](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/253)（merge `c8ce4eb`）已合入。卡内自述 Q2/Q3 落地；本索引未重放 |
+| [智能体工作流质量改进](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、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。
@@ -149,3 +165,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-09-base-v0.2.0-release.md

@@ -0,0 +1,102 @@
+# 基座 v0.2.0 发版记录
+
+| 项 | 内容 |
+|---|---|
+| 状态 | **候选已就绪，tag 待 owner 执行**（高后果操作双钥匙：发布版本由 owner 亲手打 tag 并推送） |
+| 发版授权 | owner 2026-10-09 会话：「越快越好，你来执行即可，我已同意」（Q3）。Agent 完成候选组合、验证与本记录；tag 创建与推送按 AGENTS.md 双钥匙规则由 owner 执行 |
+| 主任务 | Dev 仓 `feature/base-v020-release`（任务卡即本次发版的主记录） |
+| 规范依据 | Agent-System-RDM `docs/materials/12-基座发版核对清单.md`；[扩展面兼容与演进](../proposals/2026-10-01-extension-compat-policy.md) §5 |
+
+## 1. 范围
+
+v0.2.0 是第二段发版：在 v0.1.0 评估基线之上，附 experimental 兼容承诺（实验窗口内仍可破坏性调整，但须改快照并在提案记录）。
+
+相对 v0.1.0 的公开面（`pkg/extension`，SurfaceVersion `2.0.0-experimental` → **`2.5.0-experimental`**）：
+
+| 扩展 | 公开面 | 来源 |
+|---|---|---|
+| EXT-1 | `Handler`、`Host`、`Request`、`Registry.AddCommandHandler` | Backend #66 |
+| EXT-5 | `Host.ParseDocument`；内置 xlsx/pptx 解析 | Backend #67、#68 |
+| EXT-8 | `ResourceAuthorizer`、`Registry.RegisterResourceAuthorizer`；工件/检索/项目流/向量/hostapi 共享读取 | Backend #105、#107、#109 |
+| EXT-9 | `Host.KnowledgePublish`、`Host.KnowledgeDelete`、`Options.DisableUploadIndexing` | Backend #106 |
+| EXT-11 | `SetScopedHostFactory`、`NewScopedHost` | Backend #108 |
+| EXT-12 | `Options.DisableConvCardMirror` | Backend #107 |
+| 执行原语硬关闭 | `Options.DisableExecTools`；CLI `--disable-exec-tools`、配置键 `disableExecTools`、环境变量 `AGENT_SYSTEM_DISABLE_EXEC_TOOLS` | Backend #110 |
+
+同时包含的缺陷修复与行为变化（不改公开面）：
+
+- 命令审计按 owner 存储与查询（v0.1.0 的 `GET /api/commands/audit` 跨租户可见；Backend `e0b1c27`，随 #105 合入）；
+- DOCX 解析保留修订插入、超链接与域结果内的文字；删除/移走的原文与域代码不进正文；含修订时显式告警（Backend #110）；
+- agent-stack N1–N3、Q1–Q3、I1–I2 阶段的库与接线（见 Backend #69–#103）。
+
+**升级须知（下游）**：
+
+- 多用户共享部署在执行隔离就位前，应设置 `Options.DisableExecTools = true`。只关闭用户设置 `runtime.exec` 不够，因为任何用户都能经 `PUT /api/settings/user` 把它改回 true。
+- 下游 go.mod 的 8 条 deps replace 不变（compat-policy §4）。
+- 下游兼容验证：RDM PR #113 头 `d49d5c9` 的源码在 replace 指向本次 backend 候选时 `go build ./...` 与 `go test ./...` 通过（SELF，2026-10-09）。
+
+## 2. 候选组合
+
+| 仓 | 提交 | 依据 |
+|---|---|---|
+| Backend | 由 Dev 合入提交的 gitlink 决定（Backend main `f1c9cc0` 或其后） | Backend #110 合入；CI `ci / vet-and-test (push)` success |
+| Core | `a253a40b8e5563119b00c4e71fb61fe0d11d6d6a` | == Dev gitlink == backend `deps/agent-system-core`（同 commit 约束） |
+| Frontend | `84b73ab32848e623d0a0ab7ade552784dca8cf3c` | == Dev gitlink == Frontend main |
+| UI | `76d6633736a7abb36ac1ecca42fe4e6f120d0558` | == Dev gitlink == UI main |
+| Dev | 本任务 PR 合入 main 后的合入提交 | Dev CI（PR HEAD `make test` + `make build`） |
+
+最终 SHA 以 Dev 合入后 `git ls-tree <Dev 合入提交> modules/` 的实际输出为准，执行前按 §4 核对。
+
+**UI 仓自身 CI 现状**：UI 仓 `ci.yml` 跑在 `nightly` 运行器上，自 2026-10-04 起每次都失败于 vitest 启动（`Cannot find native binding`，rolldown 可选依赖），与代码无关。同一 UI 提交在 Dev 组合 CI 中 `npm ci && tsc && vitest` 通过（14 文件 / 103 用例；Dev run 1369），本地 Node 26 复验同样通过。v0.2.0 以 Dev 组合 CI 为 UI 的权威验证；UI 仓 runner 修复另列后续任务。
+
+## 3. tag 消息（五仓一致）
+
+```
+SurfaceVersion 2.5.0-experimental. Adds in-proc command handlers, the owner-scoped host handle, document parsing, resource authorization, knowledge publish/revoke, scoped host recovery, the card mirror switch and the exec hard switch.
+```
+
+## 4. owner 执行步骤
+
+先在 Dev 主检出确认合入后的组合（只读）：
+
+```bash
+cd /home/weichen/projects/Agent-System-Dev && git fetch origin && git checkout main && git pull --ff-only
+git status --porcelain                         # 必须为空
+DEV=$(git rev-parse origin/main); echo $DEV
+git ls-tree $DEV modules/backend modules/core modules/frontend modules/ui
+# core 同 commit：以下三行必须相同
+git ls-tree $DEV modules/core | awk '{print $3}'
+git -C modules/core rev-parse HEAD
+git -C modules/backend/deps/agent-system-core rev-parse HEAD
+```
+
+然后子仓先、Dev 后，逐仓打 tag（`<SHA>` 用上面 `ls-tree` 打印的该仓 gitlink）：
+
+```bash
+MSG='SurfaceVersion 2.5.0-experimental. Adds in-proc command handlers, the owner-scoped host handle, document parsing, resource authorization, knowledge publish/revoke, scoped host recovery, the card mirror switch and the exec hard switch.'
+for m in backend core frontend ui; do
+  SHA=$(git ls-tree $DEV modules/$m | awk '{print $3}')
+  git -C modules/$m fetch origin && git -C modules/$m tag -a v0.2.0 "$SHA" -m "$MSG" && git -C modules/$m push origin v0.2.0
+done
+git tag -a v0.2.0 "$DEV" -m "$MSG" && git push origin v0.2.0
+```
+
+推完核对（五处一致）：
+
+```bash
+for m in backend core frontend ui; do
+  echo "$m tag=$(git -C modules/$m rev-parse v0.2.0^{commit}) gitlink=$(git ls-tree v0.2.0 modules/$m | awk '{print $3}')"
+done
+git ls-remote --tags origin v0.2.0
+```
+
+## 5. 发版后（Agent 可执行，tag 在位后启动）
+
+- RDM 升钉到 v0.2.0 五仓 tag，并重定基合入 #113/#114（RDM 计划 G1-1）；
+- RDM 二进制设置 `DisableExecTools: true`（RDM 计划 G1-7）；
+- Releases 仓按 `scripts/build-release.sh 0.2.0` 构建制品与 manifest（另立任务，内部发布，不公开）。
+
+## 6. 不做的事
+
+- 不使用 `v0.2.0-experimental` 这类 tag 名；不在实验窗口发布 npm；不改 Go module path。
+- RDM 仓 v0.2.0 tag 不在本次范围（RDM 升钉完成后另行评估）。

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-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）观察，已被后续事件取代。