Identify the provider snapshot used by the IAM contract

Why: Avoid presenting an earlier extension surface as the current provider after main advances. Evidence: Independent documentation review identified a non-blocking version attribution issue. Impact: Attribute the existing-capability table to Backend 0f192a48; preserve contract semantics and approved plan digest. Refs: IAM I1 stage 8 document review.
Align IAM contract navigation with accepted delivery stage
2026-10-13 15:37:31 +00:00 · 2026-10-13 15:34:16 +00:00 · 2026-10-13 15:30:37 +00:00 · 2026-10-13 15:27:22 +00:00 · 2026-10-13 14:52:43 +00:00 · 2026-10-13 14:31:56 +00:00
68 changed files with 12658 additions and 5 deletions
@@ -0,0 +1,19 @@
+# Agent-System-Documents 项目事实
+
+## 职责与边界
+
+本仓保存系统架构方案、使用指南、验证报告与实施记录。目录入口见 [README](README.md)。
+通用开发规范由 Dev 仓固定的 Development-Guidelines 提供；本仓不复制通用规则，
+不承载业务实现、凭证、运行数据或部署制品。
+
+方案、已实现、已验证、已合入与已部署分别记录；历史报告只证明其指定版本和环境。
+系统级记录关联组件 PR 与 Dev 组合 PR，不以文档状态代替运行事实。
+
+## 验证
+
+纯文档修改执行 `git diff --check`，核对受影响相对链接、引用来源、版本及规则一致性。
+报告中的通过断言关联真实命令、被测对象和证据来源；未验证事项写 NOT_RUN。
+修改运行提示词或有效策略时，按行为影响追加对应系统验证，不能按普通文字编辑验收。
+
+本仓没有可编译程序或独立业务测试套件。跨仓固定组合在 Dev 仓运行 `make test`；
+过程记录中的命令和环境须按当次任务核实，不能机械重放旧运维命令。
@@ -2,6 +2,9 @@

 系统文档与过程记录仓：架构决策、方案与验证记录、使用与插件开发指南；不含产品代码。

+从 [项目方向与规划索引](docs/proposals/INDEX.md) 查找主记录、里程碑、关联任务及待确认差异。
+索引给出固定版本的核验快照；方案批准、PR 合入和运行验收分别记录。
+
 ## 目录

 ```text
@@ -18,3 +21,5 @@ docs/
 [实施记录](docs/records/2026-09-29-implementation.md) · [设计方案](docs/proposals/2026-09-29-system-skeleton-design-and-plan.md)

 规范基线：Development-Guidelines（Dev 仓 `deps/development-guidelines`）。
+
+相关方案：[RDM 功能、实现与计划矩阵及整改方案 r1（2026-10-12）](docs/proposals/2026-10-12-rdm-function-implementation-plan.md)——RDM 全系统缺口矩阵与 U1–U9 工作包。
@@ -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` |
@@ -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） |
@@ -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` |
@@ -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/` |
@@ -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` |
@@ -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 回放基础。每次演练恢复到新目标并核对。
@@ -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   # 环境变量定位文件
 ```

@@ -85,7 +86,7 @@ AGENT_SYSTEM_CONFIG=/etc/agent-system.json agent-system serve   # 环境变量
 - **长回复折叠**：终态后超过 800 字的回复自动收成「📄 长回复 · N 字（点击展开）」摘要行——流式期间全文可见，历史消息同样适用。
 - **长结果进右侧卡片（默认关）**：设置 → 界面 →「长结果进右侧卡片」开启后，报告/纪要/方案/对比/文档草稿等**产物型**长内容进右栏收件箱（result 卡，可置顶/收纳）；长正文优先流式三段式——`card_begin` 建卡（收件箱即时出现 active 卡）→ `card_append` 逐段追加（卡片实时刷新，事件按 250ms 窗口节流）→ `card_commit` 收尾（转 done 并锚定到对话）；一次性短产物走 `submit_card`。中栏保留结论摘要 + 锚点部件（`📄 标题 · N 字 ▸ 展开全文 · ↗ 收件箱`）——锚点可无跳转展开全文，右栏收起时阅读不残废；解释型长回答不进卡。下一轮对话上下文自动回填卡片全文（「🧩 上下文构成」可见 card(n) 条目）；run 异常终止时未收尾的流式卡自动置 done/failed 并标注「未正常收尾」，内容不丢。
 - **上下文构成观测**：每条助手消息尾部「🧩 上下文构成」折叠芯片——该轮模型实际看到什么（系统提示/历史条数/附件/知识命中）与裁剪记录（历史超窗/工具结果超限），输入规模可解释。
- **附件**：📎 上传 md/txt/docx/pdf/图片——文档经内置解析器（确定性代码解析：md/txt 直读、docx 解 OOXML、pdf 提取文本层）转为中间表示注入对话；解析结果与警告显式可见（不静默）。
+- **附件**：📎 上传 md/txt/docx/pdf/xlsx/pptx/图片——文档经内置解析器（确定性代码解析：md/txt 直读、docx/xlsx/pptx 解 OOXML、pdf 提取文本层）转为中间表示注入对话；解析结果与警告显式可见（不静默）。
 - **输入增强**：`/` 唤起命令菜单（/new /mock /model /profile /help）；`@knowledge` 在消息中触发知识检索注入。

 ### 3.3 mock 演示指令（无需模型）
@@ -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:`，至少一个下游可升级的版本之后才删除。实验窗口内的删除仍要改快照测试，不能静默。
@@ -24,6 +24,8 @@

 `modules/backend/pkg/extension/surface_test.go` 用 AST 列出 `pkg/extension` 的导出类型与函数，与 `surface.txt` 比较。CI 通过 `make test`（含 `go test ./...`）执行。未更新快照的导出变更会失败。

+导出**接口**同时记录其方法（`Host.ParseDocument` 形态）——只加方法、不改顶层名的变更同样触发快照失败（2026-10-06 EXT-5 起执行）。
+
 依赖边界：`make test-boundaries` 拒绝

 - `pkg/extension` 导入 `agent-system-backend/internal`
@@ -43,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
 ```

@@ -184,6 +184,8 @@ flowchart TB

 每阶段单独任务。依赖：R0 先做。R1 在三个库内并行。R1 之后做 D1。D1 之后 N1、Q1、I1 可以同时做。它们完成后再做 N2、Q2、I2。N3 在 N2 之后。Q3 在 Q2、N1、I1 之后。

+N1 / Q1 / I1 的实施方案见 [2026-10-07-agent-stack-n1q1i1-plans.md](2026-10-07-agent-stack-n1q1i1-plans.md)。
+
 ### R0 组合一致性

 Dev 根 `go.work`。检查脚本对比 Backend `deps/` 与 Dev 指针。`lint-boundaries` 加上文第 3 节的依赖断言。核对 Releases 导出是否跟随 `go.work`。
@@ -250,6 +252,13 @@ Backend 把 `WorkflowDef` 编译成 Squad 的图。`internal/workflow` 与把小

 验收：分类器返回未知 ID 时结果保持 Ambiguous。eval 对一份不少于现有语料规模的多轮夹具给出指标，而不是只打印分支名。

+状态回填（2026-10-08）：I2 已实施并合入（Dev #242，merge d308ed6；R1–R4 验收声明 PASS，
+SELF；各组件仓 CI 在 merge 前 success，GATE）。本节是 I2 的唯一规划主记录——I2 任务卡
+原先误引「N1/Q1/I1 实施案的 I2 部分」（该文档不含 I2），链接已在 Dev 侧修正指向本节。
+剩余项：慢通道开启态的端到端灰度与阈值调参（原记随 RDM MS1 插件语料一并）、
+SetSlot/Cancel/Handoff 命令的运行时消费（无阶段载体，见
+[N1/Q1/I1 案回填 §7.3](2026-10-07-agent-stack-n1q1i1-plans.md)）。开启态完整用户验收未重放。
+
 ### E 评测（每阶段都带，不单列阻塞）

 Native：配对、取消、预算、压缩。Squad：步边界杀进程。Intent：多轮语料。Dev 组合：少量真实任务加人工复核，不把模型自报当通过。
@@ -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 项）

@@ -0,0 +1,51 @@
+# EXT-5：宿主句柄开放内置文档解析（含 xlsx/pptx 内置解析器）
+
+状态：**实施中（2026-10-06）**；owner：weichen；主任务：Dev 仓 `feature/ext-5-host-parse`。
+规范依据：[扩展面兼容与演进](2026-10-01-extension-compat-policy.md)（§6 扩展点申请模板）；前序 [EXT-1](2026-10-05-ext-1-inproc-command-handler.md)（Host 最小集）。相关：EXT-4（下游注册 inproc 解析器，备选、未提交）——方向相反，本申请不依赖它。
+撰写日期：2026-10-06。
+
+## 1. 申请四要素（compat-policy §6）
+
+- **场景**：Agent-System-RDM 的 F1 上传主链（`rdm.upload`，PR #103）需要解析用户上传的文档；基座 `internal/ingest` 有内置解析器但没有经 `extension.Host` 开放——下游拿到的只有 `ArtifactGet/ArtifactContent`（原件字节），要解析就得自带一份解析代码（RDM 现状：自带 md/txt/docx 解析器，pdf/pptx/xlsx 一律回「不支持」）。MS1（W4，11-01）验收第 4 条要求「报价单 Excel + 图文混排 PPT 解析完整性核对」，当前两条路都走不通：句柄没有解析方法，基座自身也没有 xlsx/pptx 解析器。
+- **希望符号**：`pkg/extension` 的 `Host` 新增一个方法：
+
+  ```go
+  // ParseDocument 用基座内置解析器把文档字节解析为 ParsedDocument（EXT-5）。
+  ParseDocument(ctx context.Context, filename, mime string, content []byte) (core.ParsedDocument, error)
+  ```
+
+  同时 `internal/ingest` 新增 `builtin:xlsx`（xlsx/xlsm）与 `builtin:pptx`（pptx/pptm/ppsx）两个内置解析器——这两个是基座能力补齐，不依赖 EXT-5，上传/附件路径同步受益。
+- **为何现有注册点组合不出来**：`ParsersDescription` 只是注册表描述（设置页/文档用），没有执行入口；`PluginParserDecl.Tool` 仅接受内置名或 sidecar 工具名（core/plugin_v2.go 注释明示）；Host 最小集里与文档相关的只有工件只读两个方法。下游唯一替代是复制基座解析代码进自己仓库——违背「引擎在基座」的接缝表裁定。
+- **兼容**：只加符号。实验窗口内给 `Host` 接口加方法会破坏第三方 fake 的编译（compat-policy §1 允许，须改快照并在提案里写一句）；`SurfaceVersion` 保持 `2.0.0-experimental`。本次同时把契约快照升级为**记录导出接口的方法**（此前只记顶层名，加方法这类变更检测不到）。
+
+## 2. 接口语义
+
+- 分派按文件扩展名，与 `ingest.Parse` 完全一致（同一实现，`hostcaps.parse` 委托）。
+- 返回 error 的只有两种情况：`ctx` 已取消；输入超过 100 MiB（与上传端点 `io.LimitReader(file, 100<<20)` 同口径）。除此之外的「不可解析」都返回带 `Warnings` 的文档（显式失败，不静默），`Meta.Confidence` 相应降低。
+- 纯计算：不读写 owner 数据、不走存储。要解析工件原件，先调 `ArtifactContent`（owner 作用域由它保证），把字节传进来——不另造句柄、不新增凭证面。
+- 参数为位置参数（filename/mime/content），与 Host 既有方法风格一致；不引入 options 结构。
+
+## 3. 新解析器格式与限制
+
+**xlsx/xlsm（builtin:xlsx）**：工作表顺序取 `workbook.xml` 的 sheets 列表（不按文件名），target 经 rels 解析（相对/绝对路径）；共享字符串含富文本 run（排除注音 `rPh`）；单元格覆盖 `t=inlineStr/str/b/e/n`（布尔输出 TRUE/FALSE、错误值原样）、公式取缓存值（无缓存输出 `=公式`）、日期按内置格式 ID 与含 y/m/d/h/s 记号的自定义格式转 ISO（1900/1904 双日期系统）；稀疏列按单元格引用就位，去行尾空与全空行；隐藏工作表标题标「（隐藏）」；每个工作表产出一个 heading 块 + 一个 table 块，空表跳过。
+
+**pptx/pptm/ppsx（builtin:pptx）**：幻灯片顺序取 `presentation.xml` 的 `sldIdLst`；标题占位符（title/ctrTitle）产「幻灯片 N：标题」heading 块；正文形状每形状一个 para 块（`a:br` 换行）；组合形状递归；`mc:AlternateContent` 只取 Choice 分支；graphicFrame 表格产 table 块（合并单元格位置留空以保持列对齐）；备注页正文产「备注：…」；跳过页码/日期/页脚占位符。图片、SmartArt 不解析（无 OCR/图形理解，属远期档）。
+
+**旧二进制格式 doc/xls/ppt**：不做解析，Warnings 给可操作提示（请转存 docx/xlsx/pptx 后重传）。
+
+**上限**（包级变量，测试可覆盖）：单元格总数 200000、列数 1024、zip 内单部件解压 64 MiB（zip 炸弹防护，docx 一并受益）；超限保留已解析部分 + Warnings + `Confidence` 降 0.6，原件不受影响。
+
+## 4. 验证
+
+- 手工构造 OOXML zip 的单元测试：xlsx（表序/富文本/公式/日期/稀疏列/隐藏表）、pptx（sldIdLst 序/标题/组合/AlternateContent/表格/备注）、失败路径（损坏 zip/缺 workbook.xml/部件超限/超上限）。
+- openpyxl 与 python-pptx 现场生成真实文件的轮测（依赖缺失时 t.Skip；CI 已装这两个包）。
+- `internal/app` 走真实 `applyCompiled → cmdbus.Dispatch → inprocHost` 链路：alice 解析自己的 xlsx 工件成功、bob 同 ID 被拒（owner 作用域不因新方法放宽）；ctx 取消与超限两条 error 路径。
+- 上传端点 e2e：xlsx 上传返回 `parser=builtin:xlsx` 且无 Warnings，知识检索命中单元格文本。
+- surface 快照按「顶层名 + 接口方法」新口径重建并通过。
+
+## 5. 不在本文范围
+
+- sidecar `/host/v1` 的 HTTP 解析路由（sidecar 形态可继续读字节走自己的解析；出现真实需求再申请）。
+- MinerU 交叉验证、OCR、SmartArt、旧 OLE 格式解析。
+- 上传超过 100 MiB 被静默截断的问题、`kindOf` 与 `artifactKindOf` 口径不一致——已登记为 EXT-5 盘点发现的缺陷，另行修复。
+- 下游把上传链路切到 Host 解析、RDM pin 升级到 v0.2.0：RDM 仓自己的任务卡。
@@ -0,0 +1,383 @@
+# N1 / Q1 / I1 实施方案：内核 harness、图执行、命令化识别
+
+状态：**proposed（2026-10-07）**；owner：weichen；主任务：Dev 仓 `feature/agent-stack-n1q1i1-plans`。
+上游：[2026-10-02-agent-stack-completion.md](2026-10-02-agent-stack-completion.md) §5 分期（下称「总提案」，行号以该文件为准）；审计：[2026-10-02-agent-stack-audit.md](../records/2026-10-02-agent-stack-audit.md)。
+规范依据：Development-Guidelines（workflows/delivery.md、standards/collaboration.md、standards/agent-execution.md、standards/verification.md）；本文是项目级消费，不复制其正文。
+
+本文把总提案的 N1、Q1、I1 三个阶段落成可启动的实施方案：现状基线、工作包分解、文件级落点、测试与验收、风险。本文不实施代码；三个阶段的实现各走各的任务（总提案「每阶段单独任务」）。
+
+---
+
+## 1. 共同基线与三任务协调
+
+### 1.1 现状基线（撰写日实测）
+
+| 仓 | pin | 说明 |
+|---|---|---|
+| Agent-Native | `3a110a728cf520cfbbbafc0c4c75f14bf78bec3f` | durable-rewind-3 与 permission-hooks（PR #173）之后 |
+| Agent-Squad | `5a57636cc0b8426a86a72bbbdd5b7f30e4fcac88` | 同上 |
+| Agent-Intent | `65aaebca1ea69ab7d48eda51d33ef1d4eea5a0bf` | agent-stack-d1（R2）之后 |
+| Backend | `e7fb276ee9b3af51329a0c6df27517184b26edee` | v0.1.0-4 |
+| Core | `0b5c7747a3165bf0d0f2219204b7b70ec3ed7645` | v0.1.0 |
+
+两个要点：
+
+- **审计基线已旧**。审计写于 native `c6d867c` / squad `590fd86`；R1/R2 之后多条审计项在当前 pin 已修（native 侧 N1/N7/N8/N21/N22/N30/X4，squad 侧 Q1–Q5/Q7/Q14–Q16/Q18/Q19）。本文逐节标注「已修 / 仍开放」，实施时不得以审计原文为唯一依据，须以当前代码为准。
+- **D1 的借力点已成**：三库核心互不依赖（native `go.mod` 只依赖 error-code-system 与 logging-system）、Options 已按端口拆分、跨库类型只出现在 adapters 子模块。N1/Q1/I1 都假设这个地基，不再返工。
+
+### 1.2 分支与合入协调
+
+按 AGENTS.md「同批互不依赖的子任务用同一 R0 的兄弟分支」：
+
+- 三个任务分支：`feature/agent-stack-n1`、`feature/agent-stack-q1`、`feature/agent-stack-i1`，从同一权威 `origin/main`（同一 R0）切出，互不嵌套。
+- 每个任务的 PR 链固定为三段、按序合入：**库仓 PR → Backend 仓 PR（bump 嵌套 pin + 适配）→ Dev 仓 gitlink PR（bump 顶层 pin 与 modules/backend）**。R0 已落地的检查脚本核对 Backend `deps/` 与 Dev 指针一致，不允许只推一层。
+- 三任务并行时的冲突面：N1 与 I1 都动 Backend（N1 在 `internal/app`、`internal/runtime`、`internal/runmgr`；I1 在 `internal/server`、`internal/intentgate`、`internal/runmgr`），`internal/runmgr` 是唯一重叠文件，**后合入者按 `make task-sync` 并入最新 main 后解决**；Dev 仓 gitlink pin 同理，后到者 sync 后重指。
+- Q1 若涉及 `modules/backend/internal/squadadapter` 消费方适配，改动限制在「驱动循环跟上新引擎 API」范围内；编排收敛（WorkflowDef 编译、internal/workflow 退役）是 Q3，不在 Q1。
+
+### 1.3 共同验收纪律
+
+- 每阶段都带 E 评测（总提案 §5 E 节）：Native 的对照用脚本化模型输出，不把模型自报当通过。
+- 证据按 AGENTS.md「证据与验证门禁」：完成声明的 precheck / task-sync / 测试三段输出由 `make evidence` 写入任务卡；测试通过的权威源是 CI（PR HEAD 上 `make test`+`make build`），本地输出是 SELF 级辅助线索。
+- 各阶段验收条款在本文 §2.6 / §3.6 / §4.6 给出机器可核对的形式，与总提案对应条目逐条映射。
+
+---
+
+## 2. N1 内核 harness
+
+总提案原文（§5 N1）：「AgentSpec、HookBus、PermissionPolicy、三类 guardrail。CompletionGate 与提醒从 Backend 下沉。`adapters/native` 透传钩子。Backend 改为消费，A/B 对照直连行为。」
+
+### 2.1 现状与 gap
+
+| 需求项 | 现状（证据） | gap |
+|---|---|---|
+| AgentSpec | **不存在**（全库无此类型）。最接近的是 `deps/agent-native/runtime/subagent/subagent.go:21-33` 的委派 `Request`（Goal/Inputs/WriteScope/NonGoals/DoneCriteria/Deliverables + Deadline/MaxToolCalls）；backend 子代理画像是 `prompts.SubagentSpec` + `fallbackSubagentSpec`（`modules/backend/internal/runtime/sub_loop.go:18-27`） | 类型、文件格式、插件校验入口全缺 |
+| HookBus | 已有：`runtime/hooks/hooks.go:56-107`（On/Emit，决策优先级 block/deny>ask>modify>allow）。事件枚举 hooks.go:9-20 有 SessionStart/UserPromptSubmit/PreToolUse/PermissionRequest/PostToolUse/PostToolUseFailure/Stop/SubagentStart/SubagentStop/PreCompact。**实际发射点只有 3 处**：`runtime/loop.go:512`（Stop）、`:532`（PreToolUse）、`:557`（PostToolUse/Failure） | 缺 PostToolBatch、SessionEnd 两个事件；6 个已枚举事件无发射点；无「已在续跑中」防递归标志（hooks.go:33-43）；**Ask 决策被当拒绝处理**（loop.go:534-540），无 ask→宿主审批→放行回路 |
+| PermissionPolicy | 以函数式存在：`runtime/policy/policy.go` 三档 Mode（:9-13）、Rule（:30-34）、Decide（:55-93，deny>计划禁写>本会话放行>ask>auto_edit>allow）、TraitsFor（:113-128）、ClassifyCommand（:145-158）、Visible（:96-101）。backend 直接消费（`internal/runmgr/runmgr.go:681-685`） | 无 Policy 命名类型、无规则序列化形态；会话放行记忆在 backend 内存 map（runmgr.go:265-286），未下沉 |
+| 三类 guardrail | **不存在**（输入/输出/工具三层全无，grep 无命中）；内核只有 `RepeatGuard` 布尔（loop.go:93-95） | 三层端口与执行点全缺 |
+| CompletionGate 下沉 | 在 backend 直连路径三层串联：`deliverableGate`（`internal/runtime/llm.go:477-510`，上限 `maxDeliverableGuards=2`）→ `checkDeliverables`（`runtime/verify.go:48-84`，工件存在+非空+`quality.ScoreBytes`）→ `runVerifier`（verify.go:86-122，开关 `runtime.verify`，提示词 `aux.verify.final`）。经自建 hooks 总线挂一个 Stop 处理器注册进内核（`internal/runtime/llm_direct.go:162-172`） | 依赖 `core.ArtifactRef`、`rc.Artifact`、`quality.ScoreBytes`、提示词库——未端口化；**子代理（sub_loop.go:98-112 无 Stop/Hooks）与小队步骤（app.go:202-217 未注入 Stop）都无此门禁**；小队只有事后 `claimsFalseDeliverable` 判失败（`runtime/squad_runner.go:90-92`） |
+| 提醒下沉 | backend 侧 `directRun.reminders`（verify.go:223-250，连续 3 个工具轮未更新计划/待办则提醒，`reminderToolGap=3`、`maxChecklistReminders=3`，用库侧 `reminders.Bus` 节流去重）。内核有通用 `Reminders func(turn)` 回调（loop.go:90-92） | `rc.Todos()/Plan()` 与 `core.TodoList/PlanSnapshot` 是产品接口，未端口化；小队/子代理路径未注入 |
+| adapters/native 透传 | **库侧管道已修**：`GateOptions`（`adapters/native/backend.go:70-80`，含 BeforeTool/AfterTool/Stop/Reminders/RepeatGuard/Hooks/Ask）、透传（:370-372）、`gateBus`（:464-496）；squad 侧映射（`deps/agent-squad/adapters/native/register.go:39-49,92-96`） | **装配未接通（N31 剩余部分）**：backend 组合根只注入 `RepeatGuard:true` 与 plan 模式 BeforeTool（`internal/app/app.go:207-217`）；直连与子代理绕过 `exec.Backend` 直接调 `nruntime.Run`（llm_direct.go:173、sub_loop.go:98） |
+| Backend 改为消费 | `adapters/native.Backend` 只实现旧门面 `exec.Backend`（backend.go:130/140），未实现 `ContractBackend`；`conformance.Suite`（conformance/fake.go:106，三条用例）无真实实现调用方 | ContractBackend 实现与 conformance 接入 |
+
+### 2.2 工作包分解
+
+**WP1 AgentSpec 与插件校验**（新类型，库侧 `runtime/subagent` 或新 `runtime/agentspec` 包）
+
+- 定义 `AgentSpec{Name, Description, Prompt, Tools, DisallowedTools, Model, PermissionMode, Skills, MaxTurns, MemoryScope, Effort, Background, WorktreeIsolation, OutputSchema}`，字段对齐总提案 §2.1 子代理行（Claude subagents frontmatter 集 + `outputSchema`）。
+- 文件格式：Markdown frontmatter（`agent-*.md`），加载器在库侧；backend 现有 `prompts.SubagentSpec` 迁移为读 AgentSpec 文件，`fallbackSubagentSpec` 保留为内置兜底。
+- **校验红线**：插件清单里的 AgentSpec **不得声明 hooks、MCP、权限模式**（总提案 §2.1 权限行），校验在插件装载期 fail-closed。
+- 测试：字段 round-trip、缺省值、插件声明 hooks/权限模式被拒、backend 旧画像到 AgentSpec 的等价映射。
+
+**WP2 HookBus 补全与 ask 回路**
+
+- 事件枚举加 `PostToolBatch`、`SessionEnd`（对齐总提案 §2.1 事件名单）；`Call` 增加「已在续跑中」标志位，hook 触发续跑时下游可见、禁止递归触发 Stop 系事件。
+- 发射点补齐：`SessionStart`（Run 入口）、`UserPromptSubmit`（用户消息入列）、`PermissionRequest`（gateTool ask 时）、`SubagentStart/SubagentStop`（委派创建/收口）、`PreCompact`（compact 前）、`SessionEnd`（Run 出口）、`PostToolBatch`（工具批结束）。
+- **ask 回路（本阶段最关键的行为变化）**：`gateTool` 收到 ask 不再当拒绝（loop.go:534-540 现状），改为发 `PermissionRequest` 并等待宿主决策端口；宿主默认实现 = backend HITL 确认卡（runmgr.go:384-424 现有 AskHITL/waitHITL 机制接为端口实现）。`deny` 语义不变；`block` 不变。
+- 风险与兜底：ask 从「拒绝」变「挂起审批」是行为变化；用 A/B 对照（WP6）证明「无 hook 注册时行为与现状逐字节一致」，把行为变化严格限制在「注册了审批端点」的场景。
+- 测试：每个新发射点一例；ask→批准→执行、ask→拒绝→配对结果两条回路；续跑标志防递归；与既有 `ab_gate_test.go` 对照不回归。
+
+**WP3 PermissionPolicy 命名类型与会话放行下沉**
+
+- 在 `runtime/policy` 增加 `Policy` 结构体：`{Mode, Rules []Rule, SessionAllow AllowStore}`，`Decide` 收为方法；`AllowStore` 是端口（Get/Add/List，`key = 工具+参数模式`），库内给内存实现，backend 把 `sessionAllows`（runmgr.go:265-286）替换为该端口的实现（本会话内存即可，持久化形态留给 N3 的 Memory/RunState）。
+- `Visible`、模式切换（含 `ExitPlanMode`，runmgr.go:257-263）改走 `Policy`。
+- 测试：规则优先级矩阵在结构体形态下全等复现现有 `policy_test.go` 四例 + backend `perm_test.go`；会话放行跨调用存活。
+
+**WP4 三类 guardrail 端口**
+
+- 端口定义：`InputGuardrail`（只作用于入口智能体的用户输入）、`OutputGuardrail`（只作用于给出最终结果的那个智能体）、`ToolGuardrail`（每次工具调用）。形态 = `func(ctx, payload) (allow / deny / modify + 原因)`，与 HookBus 决策词汇一致。
+- 执行点：输入在 UserPromptSubmit 处、输出在 Stop 判定前、工具在 PreToolUse 链内。guardrail 与 hook 的关系写清：guardrail 是类型化语义层，hook 是通用事件层，guardrail 以 hook 实现注册。
+- 测试：三层各自 deny/modify/allow 各一例；只入口、只最终输出的作用域限定各一例。
+
+**WP5 CompletionGate 与提醒下沉**
+
+- 下沉的不是实现而是**组合点**：库侧新增「输出 guardrail 注册位 + 提醒源注册位」，产品依赖端口化：
+  - 工件存在/非空/质量分：端口 `ArtifactVerifier`（backend 用 `rc.Artifact` + `quality.ScoreBytes` 实现，verify.go:48-84 逻辑迁入 adapters 侧实现）；
+  - 独立验证器：端口 `FinalVerifier`（backend 用 `aux.verify.final` 提示词 + 独立模型调用实现，verify.go:86-122 迁入）；
+  - 计划/待办提醒源：端口 `ProgressProbe`（backend 用 `rc.Todos()/Plan()` 实现，verify.go:223-250 迁入）；`maxDeliverableGuards=2`、`maxVerifyContinuations=3`、`reminderToolGap=3`、`maxChecklistReminders=3` 等阈值随端口配置走，默认值不变。
+- 迁移后 `deliverableGate`/`checkDeliverables`/`runVerifier`/`directRun.reminders` 在 backend 只剩端口实现与装配，判定逻辑（正则族、续跑上限、节流）进库。
+- 测试：库内脚本化夹具复现 backend `llm_test.go`/`llm_verify_test.go` 的全部门禁用例（GuardTwiceThenNotice、验证器拒绝后通过、垃圾失败关闭、提醒节流等），确保下沉后逐条等价。
+
+**WP6 Backend 装配接通与 A/B 对照（N31 收口）**
+
+- `internal/app/app.go`：直连、子代理（sub_loop.go:98-112）、小队（squadadapter `AgentNativeOptions`，app.go:207-217）三条路径注入同一套 `Hooks/Stop/Reminders/Ask`；小队经 squad→native 两级 GateOptions 透传（管道已在，只装配）。
+- 直连与子代理改为经 `adapters/native` 消费（不再裸调 `nruntime.Run`）；`adapters/native.Backend` 实现 `ContractBackend`（补 Descriptor），`conformance.Suite` 挂到 native 后端跑（现有三条用例起步）。
+- **A/B 对照（提案验收核心）**：同一组脚本化模型输出（含停止、提醒、工具拒绝、HITL 分支），分别在「旧直连装配」与「新下沉装配」下跑，断言停止原因、提醒次数、工具拒绝序列一致。`runtime/ab_gate_test.go` 是库内雏形，本 WP 把它扩成 backend 侧对照。
+- 小队路径行为变化明示：小队步骤首次获得 Stop 门禁与提醒——这是本阶段有意的行为拉齐，写进 PR 影响段。
+
+### 2.3 涉及仓与落点汇总
+
+- Agent-Native：`runtime/hooks`、`runtime/policy`、`runtime/loop.go`、`runtime/subagent`（或新 agentspec 包）、新 `runtime/guardrails`（或并入 hooks）、`adapters/native`、`conformance`。
+- Backend：`internal/app/app.go`、`internal/runtime/{llm.go,llm_direct.go,verify.go,sub_loop.go,squad_runner.go}`、`internal/runmgr/runmgr.go`（AskHITL 接端口、sessionAllows 替换）、`internal/squadadapter`（透传配置）。
+- Dev：两层 pin。
+
+### 2.4 实施顺序
+
+WP2（ask 回路）与 WP3（Policy 类型）先行（其余都依赖决策与权限语义）→ WP1 AgentSpec、WP4 guardrail 端口 → WP5 下沉 → WP6 装配与 A/B。每 WP 单独提交，库内测试绿了再进下一 WP。
+
+### 2.5 风险
+
+- ask 语义变化是最大风险点：必须有 A/B 对照证明默认行为不变（见 WP2/WP6）。
+- 下沉搬移正则族与阈值时容易丢行为：WP5 的「逐条等价」测试先行（先在库内写好对现网行为的刻画，再搬）。
+- 小队首次上门禁可能暴露存量提示词的虚假交付习惯：`claimsFalseDeliverable` 与 Stop 门禁并存期要观察误报率，必要时给小队入口单独的宽松阈值（配置项，不硬编码）。
+
+### 2.6 N1 验收（对照总提案 §5 N1 验收逐条）
+
+| 总提案条款 | 机器可核对的验收 |
+|---|---|
+| 同一组脚本化模型输出，下沉前后停止原因、提醒次数、工具拒绝一致 | backend 侧 A/B 对照测试在 CI 通过；对照夹具覆盖 deliverableGate 命中/未命中、verifier 拒绝/通过/垃圾、提醒触发/节流、工具拒绝 |
+| 插件里的 AgentSpec 不能带钩子和权限模式 | 插件装载测试：声明 hooks/permissionMode 的 AgentSpec 被拒且错误可定位到字段 |
+
+## 3. Q1 图执行
+
+总提案原文（§5 Q1）：「superstep、三档检查点、attempt id、interrupt / resume。`Needs` 驱动依赖。读写集。可组合 Termination。Store 接口。platform 的 SQLite 成为 Store 的一个实现，不再单独驱动一套运行。」
+
+### 3.1 现状与 gap
+
+| 需求项 | 现状（证据） | gap |
+|---|---|---|
+| superstep | 无。执行是「线性步骤数组 + 状态机扫描」：`flowDriver.advance`（`deps/agent-squad/squad/workflow.go:22-101`）一个大循环扫到挂起/终态；leader 是独立大循环（leader.go:178-372）；`WorkflowPlan.CurrentStepIndex`（models.go:124）是从未写入的死字段 | 整个推进模型 |
+| 三档检查点 | 无 checkpoint 类型。最接近的是「步骤完成即 `st.save()` 全量落盘」（workflow.go:367-371，同步单档）+ 挂起时 pending.json。原子写已修（`AtomicWrite`，workspace.go:307-349） | 检查点类型与退出时/异步/同步三档全缺 |
+| attempt id | 只有计数器 `Attempts`（models.go:93-94）与不变的 `ExecutionID = runID+"-"+stepID`（workflow.go:286）；恢复靠「running + Attempts>=2 + HITL 模式」启发式（engine.go:879-925），无产物校验 | attempt id、幂等键、「副作用次数=1」的判定基础 |
+| interrupt/resume 同一对原语 | 挂起原语面向人：`hitlGate`/pending.json + `Respond`/`Resume`（engine.go:481,928）；事件唤醒是旁路 `WaitCondition` + `SweepWakeups`（engine.go:1080-1163）；`SweepExpired`（engine.go:1107-1130）**无调用方，是死代码** | 统一原语；SweepExpired 接线 |
+| Needs 驱动依赖 | 字段已声明（models.go:90）但**调度完全不读**（全仓唯一引用即声明行）；调度只看「相邻 Parallel 标记」（workflow.go:44-72） | DAG、拓扑排序全缺 |
+| 读写集 | 无 Reads/Writes 字段；「写同一工件必须串行」无判定；并行安全靠 `st.mu` 串行化写回 | 字段与调度判定全缺 |
+| 可组合 Termination | 无该类型。四个停止条件硬编码分散：leader 轮次（leader.go:207/371，达上限直接 leaderFail 无降级，Q23 仍开放）、修复预算（engine.go:36-37 默认 1，workflow.go:583-596 扣减，engine.go:698 人工 retry 加预算无上限，Q26 仍开放）、唤醒上限（hitl.go:68 `MaxWakeupFires=5`）、StepTimeout/HITL 超时（engine.go:32-33、hitl.go:23-30、hitl.go:119-137） | 类型与 AND/OR 组合全缺 |
+| Store 接口 | squad 核心无 Store 端口；运行状态由引擎直接管文件（runstate.go:52-76 一次写六文件）；`store.FileStore` 只管 roles/blueprints；`store/eventsink.go` 是事件 jsonl 装饰器 | 接口不存在 |
+| platform 收编 | `adapters/sqlite`（包名 platform）是**独立第二套运行系统**：23 张表无 run/step/checkpoint 表（db.go:51-149）；task 队列自有一套 Claim/FinishTask/RecoverOrphans（queue.go:194-348）；`RunInProcess` 绕过 Executor 端口直驱 agent-native（runtime.go:201-229，X6 仍开放）；与 squad 文件态 runs 双真相源并列挂载（cmd/agent-squad/server/server.go:31-41,94-96） | 双系统合一 + schema 扩展 + X6 |
+| 顺带瑕疵（Q1 会踩到） | 并行组 `wg.Wait()` 等全部结束才收口（workflow.go:172）；黑板是快照不是增量（blackboard.go:12-38）；动态调整直接 splice Steps（workflow.go:510-534）——与「图结构不变」的恢复要求冲突；产品侧消费方是 squadadapter 的外层 Run/Resume 循环（`modules/backend/internal/squadadapter/adapter.go:92-117`、entry.go:115-139） | 在设计中显式裁定，见 §3.2 WP1/WP4 |
+
+已修不再返工（R1/R2 已落）：原子写、授权/预算落盘、批准键写入（Q1）、中断步骤挂起分流（Q4 部分）、跨进程锁（Q5）、Respond 幂等（Q7）、WAL（Q19）、事件 seq 续号（Q18）。
+
+### 3.2 工作包分解
+
+**WP1 图模型与 Needs 调度**
+
+- `StepSpec` 增补 `Writes []string`（写集，工件路径）与 `Reads []string`（读集，可空=不声明）；`Needs` 从死字段激活为依赖声明。
+- 编译期（`planAndExecute` 入口）把 Steps 编译成图：节点=步骤，边=Needs；拓扑分层（Kahn），同层可并行。**兼容映射**：无 Needs 的旧蓝图按「相邻 Parallel」规则自动分层（相邻且 Parallel=true 的步骤入同层），行为不变量由现有测试保证。
+- **动态调整裁定**（与恢复语义冲突的解决）：`AllowDynamicAdjustment` 步骤的 splice（workflow.go:510-534）改为「追加节点生成新图版本」——图带 `version`，已完成的 superstep 结果按节点 id+图版本键保存；恢复时要求图版本与检查点一致，不一致则拒绝恢复并提示重新规划（对齐总提案 §2.2「恢复要求图结构不变」）。
+- 调度隔离：同层内**写同一工件（Writes 交集非空）的步骤强制串行**；只读步骤并行。交集判定在分层时做，拒绝或串行化在调度时做（默认串行化 + 事件提示，不拒绝）。
+- 测试：Needs 分层顺序、环检测拒绝、旧蓝图兼容映射等价、写集交集串行化、图版本不一致拒绝恢复。
+
+**WP2 superstep 推进**
+
+- `advance` 重写为 superstep 循环：每 superstep = 「取当前可执行层 → 层内调度（写集串行）→ 层结束做检查点」。leader 循环映射为「leader 节点 + 动态追加成员节点」的图形态（委派=追加，close=终止边），leader.json 的状态并入检查点。
+- `CurrentStepIndex` 死字段删除或改作「当前 superstep 序号」。
+- 并行组 fail-fast 裁定：保持 cancel 传播（现状），superstep 边界统一收口失败，不再 `wg.Wait()` 空等——失败即终止本 superstep 剩余节点。
+- 测试：多蓝图（standard/router/leader）在新循环下现有 engine_test/leader_test 全绿；层边界事件序列断言。
+
+**WP3 attempt id 与幂等**
+
+- 每次执行生成 `AttemptID = runID/stepID/N`（N=Attempts+1），随步骤状态落盘；执行事件、产物、副作用记录都挂 AttemptID。
+- 恢复判定升级：`recoverInterrupted`（engine.go:879-925）从启发式改为「attempt 记录 + 产物校验」——步骤标 running 且其 attempt 无完成记录时，按 HITL 模式分流（现状三分支保留），选择 retry 时新 attempt 执行前校验该步骤已登记副作用（产物文件存在性）并在事件流标注「第 N 次尝试」。
+- 验收硬指标「副作用次数=1」的判定基础：已完成（有完成记录）的 attempt 永不重跑；瞬态重试（MaxTransientStepInvocations=2，workflow.go:260）共享同一 AttemptID 的「子尝试」标记，不计为新 attempt。
+- 测试：杀进程于每个 superstep 边界（见 §3.6）；retry/skip/abort 三分支；瞬态重试不增 AttemptID。
+
+**WP4 Store 端口与三档检查点**
+
+- 新端口 `Store`（squad 包内）：`SaveRun/LoadRun/SaveStep/LoadStep/SaveAttempt/AppendEvent/LoadEvents/SaveCheckpoint/LoadCheckpoint/ListRuns`，以 run（thread）为键。
+- 现状文件态收编为 `FileStore`（runs/ 目录六文件 + pending.json + leader.json 的全部读写走 Store 接口）；检查点三档：`sync`（superstep 边界同步写，默认）、`async`（批量刷盘）、`on_exit`（进程退出时）——档位在 RunOptions 声明，默认 sync。
+- 黑板裁定：Q1 只把黑板快照纳入检查点载荷；「可回放增量」留给 Q2 拓扑（总提案 §2.2 把黑板增量列在拓扑行）。
+- 测试：三档各自的一致性；检查点以 run 为键的隔离；FileStore 与现状文件布局的读取兼容（老 runs 目录可恢复）。
+
+**WP5 SQLiteStore 与 platform 收编**
+
+- `adapters/sqlite` schema 增加 `run / step / attempt / checkpoint / event` 五表；`SQLiteStore` 实现 Store 端口。
+- **收编裁定**（双真相源合一）：platform 的 task 队列不再自行驱动执行——`Claim` 到的任务翻译为 squad run 并交给引擎（Store=SQLiteStore），`RunInProcess` 改走 `Executor` 端口（修 X6）；platform 的 wakeup 表与 squad 的 WaitCondition 合并为一处（保留 squad 语义，platform 表改为投影或下线，迁移期双写只读旧表）。
+- 过渡：platform 现有 23 表中非运行类（workspace/member/issue/skill/autopilot/webhook/chat/project 等）不动；本 WP 只合一「运行」这一层。
+- 测试：同一蓝图分别在 FileStore 与 SQLiteStore 上跑通 conformance（见 §3.6）；孤儿恢复（RecoverOrphans）在合并后语义不变；server 并列挂载改为单引擎。
+
+**WP6 可组合 Termination**
+
+- 新类型 `Termination = And(...)|Or(...)|MaxTurns(n)|RepairBudget(n)|MaxWakeups(n)|Timeout(d)|StepTimeout(d)`；四处硬编码收编为默认组合：`And(MaxLeaderTurns(8), RepairBudget(1), MaxWakeups(5))` + 步骤级 StepTimeout（默认 10min，语义不变：重试共享截止，Q24 维持现状并写进文档）。
+- 顺手关账：leader 达上限的降级收口（Q23：不再裸 leaderFail，走一次收口质检或挂起人工）；人工 retry 加预算设上限（Q26：默认累计不超过初始值的 2 倍，可配）；`SweepExpired` 接入 serve 周期循环（与 SweepWakeups 并列），补 Q6 另一半。
+- 测试：AND/OR 组合矩阵；三个关账项各一例回归。
+
+**WP7 interrupt/resume 统一原语**
+
+- 把「HITL 挂起（pending.json）」与「事件等待（WaitCondition/SweepWakeups）」统一为 `Interrupt{Kind: human|event|expired, Key, Payload}` / `Resume(Key, Response)` 一对原语；pending.json 与 wakeup 成为 interrupt 的两种持久化形态。
+- 对外 API（Respond/Resume/steer）语义不变，内部改走统一原语。
+- 测试：两种 interrupt 的挂起/恢复/过期三态；API 兼容（现有 server_test、engine_test 绿）。
+
+### 3.3 涉及仓与落点汇总
+
+- Agent-Squad：`squad/{workflow.go,engine.go,leader.go,models.go,runstate.go,blackboard.go,hitl.go}`（重写面大）、新 `squad/{graph.go,superstep.go,store.go,termination.go,interrupt.go}`、`adapters/sqlite`（schema+Store）、`store/`（FileStore 归位）、`cmd/agent-squad/server`（挂载合一、SweepExpired 接线）。
+- Backend：`internal/squadadapter`（驱动循环跟上引擎 API；入口/步进循环适配）。
+- Dev：两层 pin。
+
+### 3.4 实施顺序
+
+WP1 图模型 → WP2 superstep（旧行为兼容先绿）→ WP3 attempt id → WP4 Store+检查点 → WP7 统一原语 → WP6 Termination → WP5 SQLite 收编排最后（风险最高，前面 WP 已各自可独立交付）。
+
+### 3.5 风险
+
+- **advance 重写是心脏手术**：WP2 必须先建立「旧蓝图兼容等价」的测试网（现有 engine/leader/recovery/r2_regression 套件就是网底），重写中任何一绿变红即停。
+- 动态调整与图版本：产品端目前依赖动态调整的蓝图（如有）在恢复时会被要求重新规划——行为变化写进 PR 影响段，并把「图版本不一致」的报错做成可操作提示。
+- platform 收编（WP5）触及双系统合一与 X6，体量接近一个小阶段：允许 WP5 在 Q1 任务内再拆子 PR 序列（Store 实现先行、驱动合一随后），但不允许只交一半——「不再单独驱动一套运行」是验收条款。
+- 消费方只有 squadadapter 一处（backend）与 squad CLI/serve 一处，适配面可控。
+
+### 3.6 Q1 验收（对照总提案 §5 Q1 验收逐条）
+
+| 总提案条款 | 机器可核对的验收 |
+|---|---|
+| 在每个 superstep 边界杀进程再恢复，已成功步骤的副作用次数为 1 | 新测试：脚本化蓝图（≥3 个 superstep），逐边界 kill -9 后 Resume，断言每个已完成步骤的产物写入次数=1、事件流无重复完成记录 |
+| 两个写同一工件的步骤不会并行 | 调度测试：写集交集步骤的执行区间不重叠（事件时间戳断言） |
+| 文件 run 与 SQLite 不再各记一份步骤状态 | conformance 套件在 FileStore 与 SQLiteStore 双实现上通过；server 单引擎挂载；platform 侧无独立 run 状态表残留（schema 断言） |
+
+## 4. I1 命令化识别
+
+总提案原文（§5 I1）：「命令列表与 ActionRef。中文匹配的词界或最短词长。同分时可按 priority 决胜。Catalog 白名单与 top-k。Backend 唯一 Router 消费 ActionRef。」验收点名审计 I1、I2、I3、I5 有回归（I1/I2 在当前 pin 已修并有测试，I3/I5 开放，见下）。
+
+### 4.1 现状与 gap
+
+| 需求项 | 现状（证据） | gap |
+|---|---|---|
+| 命令列表 | **不存在**。`Result = {Input, Branch, Top *Candidate, Candidates, SnapshotRevision}`（`deps/agent-intent/intent/result.go:44-50`），输出是单 Top 意图；`ActionRef`/`Start`/`SetSlot` 全仓零代码命中 | 命令类型、序列化、校验全缺 |
+| ActionRef 统一 | **四种动作键并存**：(a) `IntentSpec.Handler`（spec.go:81，squadintent Runner 消费）；(b) `Metadata["blueprint"]`（adapters/intent/gate.go:123-131 → engine.go:228-237）；(c) `CommandSpec.ID`（agent-command，backend server.go:653-654 把意图 ID 当命令 ID）；(d) `WorkflowDef.IntentID`（core plugin.go:60，workflow/registry.go:40-42 索引） | 统一表示与迁移映射 |
+| Backend 唯一 Router | **不存在**。消费分散三处：chat 路由内联 if-else（`internal/server/server.go:647-660`，命令优先于工作流写死）、HITL 自由输入转轨（`internal/runmgr/runmgr.go:1203-1248`）、装配（`internal/app/app.go:300-301,316,381`）。squad 的蓝图意图链 backend **完全没接**（squadadapter/entry.go:98-110 不设 IntentGate/IntentCatalog/IntentRunner；全 backend grep `squadintent` 零命中） | Router 组件与优先级裁定 |
+| 中文词界/最短词长（I3） | 纯子串 `strings.Contains`（registry.go:142/147/154）；无词界设施、无最短词长告警（grep 零命中）；NFKC 已落地（fold.go:11-28）但**两个宿主都没开**（backend intentgate gate.go:57 只设 TopN；squadintent gate.go:37-44 只设 Guard/Protected 域）；语料中文负例只有一条靠 excludes_any 硬回避（testdata/corpus.json 第 6 行 + specs/base.json:10） | 词界设施、lint 告警、负例语料、宿主开 NFKC |
+| 同分 priority 决胜（I5） | `Priority` 字段已在（spec.go:74）且是排序第二键（registry.go:327-335、recognizer.go:172-183）；但裁决要求分差 ≥ margin（recognizer.go:92），`AmbiguityMargin <= 0` 强制回 0.1（registry.go:61-63）——**同分恒 ambiguous，priority 不参与决胜** | 裁决逻辑调整 |
+| Catalog 白名单与 top-k | Metadata 白名单已有（fold.go:61-64，只放 blueprint/guidance 两键）；但 `CatalogSpec.Handler` 仍进 JSON 视图（catalog.go:20-30）；目录全量输出无 top-k、无相关度（catalog.go:34-62） | top-k 与相关度参数；Handler 是否进目录的裁定 |
+| eval | `intentctl eval` 单轮（cmd/intentctl/main.go:229-292，recognizer 以 nil expectation/classifier 构建于 main.go:254）；语料 10 条（testdata/corpus.json）；输出只有 PASS/FAIL 计数（main.go:285-290） | 多轮夹具格式与逐轮命令期望（precision/recall 指标输出属 I2，I1 先扩格式） |
+| 命令层前置概念 | 否定只认 excludes_any（recognizer.go:66 注释明说「不要写入」交给命令层 Cancel——命令层尚不存在，审计 I12）；ExpectationProvider 接口在（expectation.go:7-19）但宿主侧零实现；L2 Classifier 同理（classifier.go:9-15，全部 NewRecognizer 传 nil） | I1 只需命令层与宿主编排；L2 实现、语义端口在 I2 |
+
+另外注意：overlay 解析 `DisallowUnknownFields`（loader.go:21-24、51）——spec 加字段不做显式注册会硬失败旧配置；backend 插件读的是**裸 spec 数组**（internal/plugins/host.go:216-222），不是 `{intents, disable}` overlayDoc——两种载体的兼容都要照顾。
+
+### 4.2 工作包分解
+
+**WP1 命令模型（库侧核心）**
+
+- 新类型：`Command` 联合 `{Kind, ...}`——`Start{ActionRef, Slots}` / `SetSlot{Name, Value}` / `ChangeSlot{Name, Value}` / `Cancel{Scope}` / `Clarify{Question, Missing}` / `Chitchat{}` / `Handoff{Target}`；`ActionRef{Kind: command|workflow|blueprint|handler, ID string}`。
+- `Result` 增加 `Commands []Command`（Branch/Top 保留作诊断与兼容，逐步退役由 Router 封装）；从候选到命令的展开规则：Top 命中 → Start（带 ActionRef 推导）；槽位缺失 → Clarify（或 ExpectationProvider 命中时 SetSlot/ChangeSlot）；多候选 → Clarify 消歧或 Ambiguous 保持（见 WP4/WP5 裁决）；否定/取消语义 → Cancel（命令层首次承认否定，收编 recognizer.go:66 的注释承诺）。
+- 命令的校验与现有候选校验同级（ID 集合、槽位作用域）；序列化进 schema 包并给 JSON 样例（对齐 D1 的「三库发布 JSON Schema 样例」做法）。
+- 测试：每种命令的展开路径；校验拒绝；round-trip。
+
+**WP2 ActionRef 推导与四种动作键迁移**
+
+- spec 增加显式字段承载 ActionRef（`action: {kind, id}`），`DisallowUnknownFields` 下注册；推导规则（兼容期）：`action` 缺省时按旧键推导——`Handler` → `{handler, <值>}`、`Metadata["blueprint"]` → `{blueprint, <值>}`、命中 backend 命令总线 → `{command, <ID>}`、命中 workflow 索引 → `{workflow, <IntentID>}`。
+- backend 插件装载（host.go:216-222 裸数组）与库 overlay 两种载体都接受新字段；旧字段在 I1 不删除（退役留给 I2 之后的发版任务）。
+- 测试：四种旧键的推导等价于现状路由结果（对照 server.go:647-660 现行为刻画测试先行）；新字段优先于旧键。
+
+**WP3 Backend 唯一 Router**
+
+- 新组件（建议 `internal/route`，或收进 `internal/server` 的独立文件）：输入 = 命令列表 + 会话状态，输出 = 路由决策（command 分发 / workflow 启动 / squad 入口 / 普通回合 / 澄清回问）。
+- 收编两处现有消费：server.go:647-660 的内联 if-else 与 runmgr.go:1203-1248 的 HITL 自由输入转轨，统一改调 Router；slash 命令（server.go:741-758）保持旁路不过在优先级文档里写明。
+- **优先级明文**（提案 §6 要求 I1 写明）：`command > workflow > blueprint > 普通回合`；`PromptTrigger`（技能触发）与 Intent 同命中时的裁定：**技能触发是提示词装配、不参与路由决胜；若 Intent 产出 Start/SetSlot 类命令则路由优先，纯提示词命中不产生命令**——写进 Router 文档与测试。
+- squad 蓝图链（`{blueprint, key}`）经 ActionRef 到达 Router 后，Router 调 squad 入口；**backend 接入 squadintent 适配器（entry.go:98-110 的缺口）在本 WP 一并补上**——这是「blueprint 经 ActionRef 到 Router」验收的必要条件，范围可控（装配 + 映射，不改 squad 库）。
+- 测试：命令优先于工作流（现有 `TestCommandBusBeatsWorkflow` 迁移）、workflow 经 ActionRef 启动、blueprint 经 ActionRef 进 squad 入口、HITL 自由输入转轨走同一路由、fallback 进普通回合。
+
+**WP4 中文词界与最短词长（I3）**
+
+- `MatchSpec` 增加 `boundary`（词界模式：CJK 按「非汉字或首尾」为界，拉丁按词字符边界）与 `min_len`（词条最短长度，低于则 lint 告警）——二选一还是并存由实施期原型定，但 lint 告警（`intentctl lint`）必须覆盖「短词条 + 无词界」组合。
+- 两宿主开启 NFKC：backend `intentgate.Rebuild`（gate.go:57）与 squadintent（gate.go:37-44）的 Options 显式开 `NFKC:true`，并补开启前后对照测试。
+- 语料补负例：中文子串误命中系列（如「配置」误中「配置项」、「写入」误中「不要写入」的否定场景交给 Cancel 的正例对照）。
+- 测试：词界开/关矩阵、最短词长告警、新负例全过、既有 10 条语料不回归。
+
+**WP5 同分 priority 决胜（I5）**
+
+- 裁决调整：前两名置信度同分（差 < margin）时，若 `Priority` 不同则高优先者判 `matched`；priority 也相同才 ambiguous。`AmbiguityMargin` 语义不变（仍防分数过近误判），margin 强制下限 0.1 保留。
+- 测试：同分高 priority 命中、同分同 priority 标歧、margin 边界三例；既有漏斗测试不回归。
+
+**WP6 eval 格式扩展**
+
+- 语料格式 v2：用例带 `turns: [{input, expect: {commands: [...]}}]`，逐轮期望命令列表；`intentctl eval` 读 v2 时构建 ExpectationProvider 夹具实现（库内给测试用 Provider），逐轮比对命令序列；v1 单轮格式兼容读取并自动映射为单 turn。
+- 指标输出在本阶段只加「逐轮命令匹配率」明细（precision/recall 的正式定义与输出属 I2，不在 I1 提前承诺）。
+- 测试：v2 多轮夹具端到端（含 SetSlot+Start 组合用例——验收条款的载体）、v1 兼容、误期望 FAIL。
+
+### 4.3 涉及仓与落点汇总
+
+- Agent-Intent：`intent/{result.go,recognizer.go,registry.go,spec.go,loader.go,catalog.go}`、新 `intent/command.go`、`schema/`、`cmd/intentctl`、`testdata/`。
+- Backend：`internal/server/server.go`、`internal/server/`（新 Router）、`internal/intentgate/`（Recognize 返回命令、NFKC 开启）、`internal/runmgr/runmgr.go`（HITL 转轨改调 Router）、`internal/squadadapter/entry.go`（接 squadintent）、`internal/plugins/host.go`（spec 新字段）。
+- Agent-Squad：`adapters/intent` 只在映射 ActionRef 时动（blueprint 键推导），核心不动。
+- Dev：两层 pin。
+
+### 4.4 实施顺序
+
+WP1 命令模型 → WP2 ActionRef 迁移（刻画测试先行）→ WP5 决胜 + WP4 词界（库内独立，可并行）→ WP3 Router（依赖 WP1/WP2）→ WP6 eval（收尾，验收载体）。
+
+### 4.5 风险
+
+- **路由行为变化面**：Router 收编两处消费 + squad 蓝图链接入，是产品可见行为。对策：WP2 的刻画测试先把现路由行为钉死，Router 切换后逐条等价；蓝图链接入属新增能力，单独一组测试，不改动有路由。
+- overlay 严格解析：spec 新字段必须同步注册进 loader 与 backend 裸数组装载两处，漏一边即硬失败——测试覆盖两种载体。
+- NFKC 默认开启是行为变化：只动两个宿主的显式配置，库默认不变（库保持 fail-closed 哲学，宿主显式选择）。
+- 命令列表与「单 Top」并存期，`Result.Top` 的消费方（squadintent gate 等）保持可用；退役由后续发版任务评估，不在 I1。
+
+### 4.6 I1 验收（对照总提案 §5 I1 验收逐条）
+
+| 总提案条款 | 机器可核对的验收 |
+|---|---|
+| 审计 I1、I2、I3、I5 有回归 | I1（分类器篡改拒绝，recognizer_test.go:188/238/269 现存）与 I2（作用域校验器，slots_catalog_test.go:70 现存）保持绿；I3 新增词界/负例测试；I5 新增决胜测试——四个测试名写进任务卡 |
+| 一条用户话可以产出 SetSlot 加 Start | eval v2 多轮夹具含该用例并通过 |
+| 命令 id、工作流 IntentID、小队 blueprint 都通过 ActionRef 到达 Router | Router 测试三条各一；插件清单字段名不变的 diff 断言（装载测试比对字段名清单） |
+| 插件清单不改字段名 | 插件装载兼容测试：现有插件 intents/workflows 清单零修改装载通过 |
+
+## 5. 三任务之外的说明
+
+- N2/Q2/I2 及更后的阶段不在本文范围；本文的 WP 划分假定 N1/Q1/I1 全部合入后才启动它们。
+- 三任务的验收都依赖「脚本化模型 + 库内夹具」，不依赖真实模型密钥；真实任务 A/B（总提案 E 节「少量真实任务加人工复核」）在各阶段验收时由所有者安排。
+- 本文档本身不修任何代码；如评审要求改设计，在本文档上修订后再启动对应任务。
+
+## 6. 验收（本文）
+
+- 三个阶段的实施方案各自满足：工作包可独立派生任务卡、验收条款可机器核对、与总提案逐条映射（§2.6 / §3.6 / §4.6 的表）。
+- 现状陈述均有 file:line 证据（撰写日 pin 见 §1.1）；评审重放 = 按表中证据抽查。
+- 三任务协调规则（§1.2）与 AGENTS.md 分支层级一致。
+
+## 7. 实施状态回填与范围差异（2026-10-08）
+
+本节回填三个阶段的实施结果与本文原设计的范围差异，来源为已归档任务卡（SELF 声明）与
+Dev main 的合入记录（2026-10-08 经 `git log --merges` 核对，#230/#231/#234/#235/#237/#240
+均在 main）。本节不重放各任务测试，不把闭卡文案升级为重新验收；「完成」指卡内验收条款
+声明 PASS 且 PR 已合入。每个转出/待做项标注依据、归属与适用版本，供 N2/Q3 之后的工作
+与 RDM 依赖判断使用。
+
+### 7.1 N1 内核 harness
+
+已合入：Dev #230（merge 42f5ac4）/ #231（merge b6974fa）；组件链 Agent-Native
+#17–#20、Agent-Squad #16–#18、Backend #69–#73（卡内记录，CI 在各 merge 前 success，GATE）。
+卡内验收两条（A/B 对照、插件 AgentSpec 校验）声明 PASS（SELF）。
+
+与本文 §2.2 的范围差异（依据：N1 卡增量三/四及「影响与剩余项」）：
+
+| 项 | 本文原设计 | 实施结果 | 状态 | 归属/载体 |
+|---|---|---|---|---|
+| WP6b 小队成员级 deliverable Stop/提醒拉齐 | §2.2 WP6「三条路径注入同一套…」的小队成员级部分 | 任务内裁定转出：需 adapters 成员级执行信号（工件产出追踪+工具轮计数） | 待做；原建议载体 Q1 未承接（Q1 卡剩余项无此项，Q2/Q3 亦未涉及） | owner weichen；载体待定 |
+| WP6c 直连/子代理改经 adapters 消费 | §2.2 WP6「不再裸调 nruntime.Run」 | 转出：需 exec.Request 表达 History/工件追踪/证据回收；ContractBackend+conformance 部分已落地（卡增量四②） | 待做；未承接 | owner weichen；载体待定 |
+| prompts.SubagentSpec 迁移 | §2.2 WP1「迁移为读 AgentSpec 文件」 | 裁定不迁移：与 agent-*.md 两套格式并存，新字段暂无消费者（卡增量三） | 有意搁置 | owner weichen；有消费者时再启动 |
+| runmgr 派生路径 Start/Stop | §2.2 WP2 发射点补齐的产品侧外延 | 裁定不覆盖：非工具调用、无总线上下文（卡增量三） | 有意搁置 | 同上 |
+| AllowStore 持久化 | §2.2 WP3「持久化形态留给 N3」 | N3 再转出（N3 卡「影响与剩余项」：memory 回合后抽取接线与 AllowStore 持久化转后续） | 待做；已经 N3 二次转出 | 见 N3 卡记录 |
+
+### 7.2 Q1 图执行
+
+已合入：Dev #237（merge 3bf2441）/ #240（merge ba36d47）；组件链 Agent-Squad #23–#26、
+Backend #79–#82。卡内验收三条声明 PASS（SELF）。
+
+与本文 §3 的范围差异（依据：Q1 卡增量四及「影响与剩余项」；Q2/Q3 卡对照）：
+
+| 项 | 本文原设计 | 实施结果 | 状态 | 归属/载体 |
+|---|---|---|---|---|
+| platform task 队列翻译成 squad run | §3.2 WP5 收编裁定「Claim 到的任务翻译为 squad run 并交给引擎」 | Store 层合一已做（SQLiteStore、X6 改走 Executor 端口、serve 单库挂载）；task 队列本身的翻译转出为「更深的产品合一，Q 系列/EXT 范畴」；Q2 卡明确记非目标（「平台队列桥接…（后续）」），Q3 未涉及 | 待做；Q 系列已收口仍未承接 | owner weichen；按 RDM 总案 §3.3 走 EXT 申请或后续产品任务 |
+| 黑板可回放增量与 Reads 读集 | §3.2 WP4「留给 Q2 拓扑」 | Q1 卡转出至 Q2；Q2 卡通篇无黑板/读集内容（实施为拓扑注册表等） | 待做；Q2 未承接 | owner weichen；载体待定 |
+| leader 模式 SQLite 端到端 | §3.2 WP2「leader.json 的状态并入检查点」 | Store 已实现 SaveLeader/LoadLeader；leader 模式回归在 FileStore 上证明（卡「影响与剩余项」） | 待做（回归补证） | owner weichen |
+| 验收表「schema 断言」 | §3.6 第三条「platform 侧无独立 run 状态表残留（schema 断言）」 | 卡内验证记录为 TestSQLiteStoreRoundTrip、TestEngineRunsOnSQLiteStore 与单库挂载；未见 schema 断言测试记录 | 证据口径差异；补断言或由负责人裁定豁免 | owner weichen |
+| 拓扑库 | Q1 卡转出至 Q2 | Q2 已落地（Dev #250/#251） | 完成（在 Q2） | — |
+
+### 7.3 I1 命令化识别
+
+已合入：Dev #234（merge 1f7217f）/ #235（merge eafe1e1）；组件链 Agent-Intent #6–#8、
+Agent-Squad #19–#22、Agent-Native #21/#22、Backend #74–#78。卡内验收四条声明 PASS（SELF）。
+
+与本文 §4.2 的范围差异（依据：I1 卡「影响与剩余项」；代码核对 command.go:18-25/78-84）：
+
+| 项 | 本文原设计 | 实施结果 | 状态 | 归属/载体 |
+|---|---|---|---|---|
+| blueprint per-run entry 覆盖 | §4.2 WP3 squad 蓝图链接入的延伸 | 裁定为独立设计项；blueprint 决策已达 Router | 待做 | owner weichen |
+| ambiguous→Clarify 产品化 | §4.2 WP1 消歧路径 | Router v1 保持普通回合；产品化需澄清 UI/HITL | 待做 | owner weichen |
+| SetSlot/Cancel/Handoff 的产出与消费 | §4.2 WP1「否定/取消语义 → Cancel（收编 recognizer.go:66 注释承诺）」与命令展开 | Command 类型已定义且有意裁定「规则漏斗不产出 Cancel/Handoff」（command.go:78-84 注释：留给声明 action 的意图与语义层）；运行时消费（会话槽位状态机）未做 | 待做；原记「I2 附近」，I2 已收口未承接（I2 卡同项转出） | owner weichen；无阶段载体，需排期 |
+
+### 7.4 对后续依赖的提示
+
+- N2/N3/Q2/Q3/I2 均已各自合入（见[规划索引](INDEX.md)阶段导航），但上表转出项无一被
+  这些阶段承接；引用「N1/Q1/I1 已完成」作依赖判断时，须扣除上表待做项。
+- RDM MS3 依赖的 Q1 图执行与 Q3 编排收敛不受上表影响；受影响的是「platform task 队列
+  合一」与「SetSlot/Cancel/Handoff 消费」两条产品化路径。
+- 本节维护规则与索引一致：状态再次变化时先更新本节并同步索引导航。
@@ -0,0 +1,148 @@
+# 方案：N2 上下文、协议与工具——现状核验与增量实施
+
+日期：2026-10-07。上游：[2026-10-02-agent-stack-completion.md](2026-10-02-agent-stack-completion.md)「N2 上下文、协议与工具」节（范围与三条验收的唯一权威）、[2026-10-02-agent-stack-audit.md](../records/2026-10-02-agent-stack-audit.md)（审计项逐条对当前代码复核后引用）。
+
+基线 pin：agent-native `ead690b`、backend `68addfd`、agent-squad `029edc0`、agent-intent `343b1e6`（均为已合入 main）。本文所有 file:line 以这些 SHA 为准；实施时先复核再引用（与 N1/Q1/I1 同一纪律：审计与本文都不是证据，当前代码才是）。
+
+依赖状态：N1/Q1/I1/I2 全部闭卡（任务卡归档）。总提案依赖序「N1/Q1/I1 → N2/Q2/I2；N3 在 N2 之后」满足，N2 开工。
+
+## 一、现状核验（六路侦察 + 关键处亲验）
+
+### 1. 上下文与压缩
+
+库层三件已就位且配对安全：
+
+- **会话压缩**：`runtime/session/compact.go:78-146`；`alignToolTail`（compact.go:148-154）回退 tailStart 至工具结果组之外，头段整体换摘要，不留孤立调用。回归：`TestR2CompactKeepsToolPair`、`TestCompactLeavesNoOrphanToolCall`（runtime/session/r2_regression_test.go:12-46,105-162）。
+- **微压缩**：`runtime/session/microcompact.go:44-70` 只改写旧工具结果正文为转录指针占位，不增删消息、不动配对（loop.go:759-776 接入）。
+- **适配层自动压缩**：`adapters/native/backend.go:95-103,412-470`。
+- **提醒**：`runtime/reminders/reminders.go:70-97` 并入最后一条消息，不新建 user 消息（审计 N22 已修）。
+
+仍开放：
+
+- **产品侧裁切破坏配对（验收②的真缺口）**：`modules/backend/internal/ctxasm/finish.go:200-242` `trimOldest→oldestDrop` 逐条丢弃「系统前缀后第一条」，无工具配对意识——丢掉带 tool_calls 的 assistant 会留下孤立结果，丢掉结果会留下悬空调用。渲染阶段（ctxasm.go:174-277）本是配对安全的，裁切在其后发生，把安全性破坏掉。
+- **旧工具结果没有落盘路径**：微压缩占位指向转录调用 ID（microcompact.go:58-68），不是文件路径；总提案 N2 行「运行内把旧工具结果换成路径」（ZCode compact 模式）未实现。
+- **缓存友好无契约**：全仓无 `cache_control`；系统文本+工具清单的稳定性是事实性而非设计（registry.go:136-148 注册序、loop.go:380-401 拼接），无测试钉住；backend 有 PrefixHash 观测（finish.go:252-277）但无稳定契约测试。
+- **`alignToolTail` 无直接单测**（仅经 Store.Compact 端到端覆盖，边界形态靠偶然）。
+- filestate 读后才能写只在 agent-native 路径（backend.go:210）；产品直连路径不过 `WorkspaceToolsTracked`（llm_direct.go:191-193）——划归 Q3 收敛范畴（见边界节）。
+
+### 2. Anthropic 原生协议（审计 N4 仍开放）
+
+- 线上 Client 只讲 OpenAI chat：`runtime/llm/client.go:14,71,76` 固定 POST `…/chat/completions` + Bearer。
+- `Protocol` 枚举五方言（providers.go:123-129），`ClientFor` 只实现 `openai-chat`，其余 fail-closed（providers.go:201-208）。审计 N4 的「选了不能用」已被缓解：anthropic/google 预设改指 OpenAI 兼容端点（providers.go:143,146）——但**原生方言不存在**。
+- 离线组包 `anthropicMessages`（providers.go:320-352）丢 tool_use/tool_result、不挂 tools（providers.go:270-289）；`Message`（types.go:48-57）无 thinking/signature 存储，签名块无法往返。
+- 无录制 HTTP 夹具机制（无 testdata/；现有测试全是内联 httptest 脚本）。
+- 审计 N4 验证结论：**部分缓解、主体仍开放**。
+
+### 3. 延迟工具 / tool_search / 代码编排（基座已在，剩收口）
+
+已就位（agent-native）：`ExposureDeferred` 两级暴露（runtime/tools/registry.go:56-73）、`tool_search`/`call_tool` 元工具（deferred.go:13-68）、激活持久化（deferred.go:94-128 → `.agentx/activated-tools.json`）、MCP 延迟连接 `StartBackground`（manager.go:124-135）与 >8 工具自动 deferred（manager.go:197-207）、代码编排 `run_tool_script`（code_tool.go:14；codeorch/host.go 进程外执行、中间结果不进上下文、50 次上限、禁名单）。backend 双路径接线：`runtime.codeOrchestration` 默认关（settings.go:95；app.go:241 agent-native 路径；codeorch_tool.go:15-78 + runmgr.go:348-355 直连路径）。
+
+仍开放/风险：
+
+- 激活恢复只记名字，激活工具永不进 `Decls()`（deferred.go:100 注释为有意设计，call_tool 间接层即机制）——**保持，不扩**。
+- 代码编排在两处各有一份实现（库 code_tool.go vs 产品 codeorch_tool.go），开关两点判定，可漂移；N2 只做「同一语义」契约测试，不做合并（合并属 Q3 退役直连路径时自然发生）。
+- 审计 N30（native.Options 单件）仍在；本阶段不做大重构，只在新端口上不再加字段。
+
+### 4. MCP（审计 N3/N18/N19 已修；2026-07-28 未对齐）
+
+- **验收③已满足**：stdio 单读循环按 id 分发（stdio.go:192-231），取消只 dropPending；回归 `TestStdioSlowCancelThenEcho`（mcp_test.go:78-105）断言 `Readers()==1`。审计 N3 关闭；N18（重连一次，manager.go:243-250）、N19（HTTP 会话 DELETE，http.go:95-119）同闭。
+- **未对齐 2026-07-28**：`ProtocolVersion="2024-11-05"`（protocol.go:16）且服务端协商版本从不检查；`callToolResult` 无 `resultType`（protocol.go:138-141）；`input_required` 只是成功结果里的内容块特例（ask.go:20-27），应答直接当终态返回（manager.go:254-264），不**重试原请求**；ask 端口（ask.go:7-18）接的是自由输入而非审批面；`tasks/get|update|cancel` 客户端面无；工具 schema 透传无 2020-12 声明（manager.go:174-177 合成默认 schema 时也未声明）。
+
+### 5. skills 校验（开放规范未对齐）
+
+- 现校验仅：目录名字符集 `[a-zA-Z0-9_-]`、64KiB 截断、描述 200 字截断、每根 100 个（runtime/skills/skills.go:22-26,140-186）。frontmatter 只按行前缀扫 `description:`（有意不引入 YAML 依赖，skills.go:4）；`name:` 被忽略（目录名权威）；未知键静默通过；不合规范式静默跳过（skills.go:79-81）。
+- 开放规范差距：name 必填且须 kebab-case 并与目录同名、description 必填（规范上限 1024）、已知键白名单（license/compatibility/metadata/allowed-tools）、字段形态校验、**错误上浮**而非静默。
+- backend 侧零校验：种子（internal/skills/skills.go:52-127）与插件技能落盘（plugins/host_v2.go:56-74）都不验；内置 recipes 只有 `description:`，缺 `name:`（dogfood 欠账）。
+
+### 6. 子代理后台/转录/恢复
+
+- **后台机制产品层已有**：`spawnBackground`（runmgr.go:1447-1474，上限 3、detached ctx、完成入 notice 队列、空闲合并投递）；模型经 delegate 工具 `background:true` 触发（llm_direct.go:459-492）。但 `AgentSpec.Background`（agentspec.go:28,156-161）**除测试外无消费者**；notice 队列是内存 map（runmgr.go:1487-1494），重启即丢。
+- **无独立转录**：子 run 共享父会话 messages 表、仅 `run_id` 分区（runmgr.go:1352,1426；store/messages.go:101-116 排除）；SubLLMRunner 直连 `nruntime.Run`（sub_loop.go:98），不建 workDir、不写 .agentx。
+- **零恢复**：`ReconcileInterrupted`（runmgr.go:1606-1634）对子 run 只 seal 成 interrupted，无续跑/重跑路径；恢复测试只覆盖会话 run。
+- `WorktreeIsolation/OutputSchema`（agentspec.go:29-30）declared-only——本阶段保持，记为边界。
+
+### 7. 审计 N2（并行工具事件竞争）——已修，仅引用
+
+`serializeHostCallbacks`（loop.go:468-480，Run 入口 :170 调用）用一把锁串行 OnEvent/BeforeTool/AfterTool；`GOWORK=off go test -race ./runtime/` 全绿（本方案亲验，2026-10-07）。不再安排工作，作为既有证据引用。
+
+## 二、工作包划分
+
+| WP | 内容 | 主要仓 | 对应验收 |
+|---|---|---|---|
+| WP1 | 上下文配对收口 + 工具结果落盘 + 前缀稳定契约 | backend + agent-native | ② |
+| WP2 | Anthropic 原生客户端 + 录制夹具端到端 | agent-native | ① |
+| WP3 | MCP 2026-07-28 对齐（版本协商 / resultType / input_required 重试 / approval 接线） | agent-native + backend | ③（回归引用） |
+| WP4 | skills 开放规范校验 + dogfood + 插件路径复用 | agent-native + backend | — |
+| WP5 | 子代理：Background 消费、独立转录、恢复与通知持久化 | backend（+agent-native 小面） | — |
+| WP6 | 装配收口 + A/B 验收证据 + 级联闭链 | backend + Dev | ①②③ 总验 |
+
+依赖：WP1 先行（验收②、风险最小、产品直接受益）；WP2 与 WP3/WP4 可并行；WP5 独立；WP6 收全部。每个 WP 走「库 PR → backend PR → 级联 → Dev gitlink PR」既有链式，逐 WP 合入，不做长分支。
+
+### WP1 上下文配对收口
+
+1. **ctxasm 裁切配对对齐**：`oldestDrop` 改为工具组对齐——候选索引落在 tool 结果组内或带 tool_calls 的 assistant 上时，整组同退（对齐 `alignToolTail` 语义，但方向是丢弃侧）。测试：构造带多轮工具调用的装配输出，裁切后断言（a）无孤立 tool_call（每个 call 有结果）、（b）无悬空结果（每个结果有 call）、（c）`Report.Truncations` 仍记录。**这是验收② 的机器证据。**
+2. **旧工具结果落盘**：微压缩清理时把旧结果写入 `<workDir>/.agentx/results/<toolCallID>.txt`，占位改为路径指引（「完整内容见 <路径>」）；保留 keepLastN 语义。库内实现 + 单测（写盘、占位、配对不变、文件可被 fs 工具读回）。
+3. **前缀稳定契约测试**：钉住系统文本与 `Decls()` 顺序在同一注册序列下逐字节确定（含 tool_search/call_tool 注入位置）；backend 侧钉 `PrefixHash` 在同输入下不变。只测不改行为。
+4. **`alignToolTail` 直接单测**：tail 恰落多调用 assistant、keepLastN 大于工具组、全为 tool 角色三种边界。
+
+### WP2 Anthropic 原生客户端
+
+1. **客户端**：`ClientFor` 增 `ProtocolAnthropic` 分支——POST `{base}/messages`，头 `x-api-key` + `anthropic-version`，SSE 解析 Anthropic 事件族（`message_start`/`content_block_start|delta|stop`/`message_delta`；`text_delta`/`input_json_delta`/`thinking_delta`/`signature_delta`），映射到既有 `Event` 类型；stop_reason `tool_use`→StopToolCalls、`end_turn`→StopEnd。
+2. **消息形态**：`anthropicMessages` 重写——assistant `tool_use` 块（id/name/input）、user `tool_result` 块（tool_use_id/content）、`tools` 数组（name/description/input_schema）；`Message` 增 thinking 块与 `signature`（含 `redacted_thinking`）存储与往返；system 与 tools 挂 `cache_control`（原生路径上的缓存友好，呼应 WP1-3）。
+3. **预设**：`anthropic` 预设切到 `ProtocolAnthropic`（用户预期即原生）；compat shim 经 `models.json` 自定义仍可配。`BuildBody` 的 Anthropic 分支与线上客户端统一（同一组包函数，消灭「离线/线上两张皮」的 N4 根因）。
+4. **录制夹具（验收①）**：新增 `runtime/llm/testdata/anthropic/` 录制字节流（非真实密钥、非线上依赖）：一轮完整工具调用——带 tools 请求 → SSE 含 `tool_use` → `tool_result` 请求 → 终文本。端到端断言：`ClientFor(Lookup("anthropic"))` 走通全程；第二次请求体中 thinking 块带原签名（签名往返）；请求头含 `anthropic-version`。
+5. 审计 N4 随本 WP 关闭（预设即真实客户端；未实现协议仍不出现在预设）。
+
+### WP3 MCP 2026-07-28 对齐
+
+1. **版本协商**：通告 `2026-07-28`；读取服务端 `initializeResult.protocolVersion`，按协商版本分流（低版本回落现行行为，不留半新半旧）。
+2. **resultType**：`callToolResult` 增判别字段；`input_required` 升格为协议级结果类型——经 ask 端口取得应答后**用原参数重试 `tools/call`**（不再把应答当终态内容返回）；重试次数有界（防循环）。
+3. **approval 接线**：ask 端口在 backend 接到审批/确认卡面（复用 N1 的 HITL 卡与 PermissionAsk 通路），自由输入与批准两类语义分清。
+4. **tasks 客户端面**：`Client` 增 `tasks/get|update|cancel` 方法 + 双传输实现 + 假服务器用例；产品侧映射只做最小集（run 中断时对进行中的 MCP task 发 `tasks/cancel`），完整后台任务映射记录为后续项（N3 持久化阶段）。
+5. **schema 2020-12**：合成默认 schema 时声明 `$schema: 2020-12`；透传保持不透明（不重写方言，注释记为有意）。
+6. 回归保持：`TestStdioSlowCancelThenEcho`（验收③）全程原样通过，作为 WP3 不得破坏的既有证据。
+
+### WP4 skills 开放规范校验
+
+1. **严格子集解析器**：坚持不引入 YAML 依赖（skills.go:4 的既有约束），手写支持规范字段形态的子集（标量、`metadata` 字符串映射、`allowed-tools` 空格分隔列表）；形态不合法即错误，不猜测。
+2. **校验规则**：`name` 必填 + kebab-case（小写、1–64、无连续/首尾连字符）+ 与目录同名；`description` 必填、≤1024（上限对齐规范，替换现 200 截断）；已知键白名单 `{name,description,license,compatibility,metadata,allowed-tools}`，未知键带字段定位拒绝；`compatibility` ≤500；不合规**错误上浮**（List 返回逐技能诊断；load_skill/declared-skill fail-closed 带错误正文，替换静默跳过）。
+3. **dogfood**：内置 recipes 全部补 `name:`；不合规目录改名随本 WP 同 PR（不另起 PR）。
+4. **backend 复用**：插件技能落盘（host_v2.go:56-74）过同一校验器，失败带字段定位拒绝装载（与 N1 插件 AgentSpec 拒禁键同款形态）；种子路径在校验失败时拒写并日志上浮。
+
+### WP5 子代理后台/转录/恢复
+
+1. **Background 消费**：`AgentSpec.Background=true` 时 factory 选择后台派生（squadadapter.SubagentFactory 与 delegate 工具同样语义：声明驱动，不再只靠模型参数）。`WorktreeIsolation/OutputSchema` 保持 declared-only，文档记为边界。
+2. **独立转录**：每个子 run 落独立转录文件（`<data>/workspaces/<owner>/<conv>/subagents/<runID>/transcript.jsonl`，由 finishChild 从 messages 表按 run_id 导出 + 后续增量直写）；父会话分区保持系统记录不变。SubLLMRunner 迁 exec.Backend 属 Q3，本 WP 不做（边界记明）。
+3. **恢复**：`ReconcileInterrupted` 对子 run 不再只 seal——有存储请求与转录的子 run 标记 resumable，父会话下一轮空闲时提示/自动续跑（续跑=以原请求+转录起新子 run，接续语义写清）；恢复测试补子代理场景。
+4. **通知持久化**：notice 队列落盘（SQLite 表或 JSONL，随 runmgr 既有存储面），重启后重投未投递的后台完成通知；内存 map 只做热缓存。
+
+### WP6 装配收口与 A/B 验收
+
+1. app 装配复核：新端口/开关全部有默认关或行为不变证明；需要设置项的（如 Anthropic 原生端点 key 环境约定）进 settings Schema。
+2. A/B 验收证据（写任务卡）：① anthropic 录制夹具端到端（WP2-4）；② 配对断言测试 + 既有 `TestCompactLeavesNoOrphanToolCall` 原样通过；③ `TestStdioSlowCancelThenEcho` 原样通过。三条全部 GATE（各仓 CI）+ Dev `make test` 收据。
+3. 级联 pin 收齐、Dev gitlink PR、任务卡闭链。
+
+## 三、验收总表
+
+| 总提案验收 | 机器证据 | 所在 WP | 现状 |
+|---|---|---|---|
+| ① 选 anthropic 预设能完成一轮工具调用（录制 HTTP 夹具，不要求真实密钥） | `runtime/llm/testdata/anthropic/*` 夹具 + `TestAnthropicPresetToolRound`（端到端：tools 请求→tool_use→tool_result→终文本→签名往返） | WP2 | 未实现 |
+| ② 压缩后的历史不出现孤立 tool_call | 库：`TestCompactLeavesNoOrphanToolCall`（既有，原样保持）；产品：`TestTrimOldestKeepsToolPairs`（新，WP1-1） | WP1 | 库已修 / 产品侧仍开放 |
+| ③ MCP 取消不再留下第二个读者 | `TestStdioSlowCancelThenEcho`（既有，`Readers()==1`，WP3 不得破坏） | WP3（回归引用） | 已满足 |
+
+## 四、边界与非目标
+
+- **不做** backend 直连路径的延迟工具层与 filestate 接线：该路径属 Q3 退役对象，避免双线建设；N2 的延迟工具成果经 agent-native 路径消费（已通）。
+- **不做** `SubLLMRunner` 迁 exec.Backend（Q3 范围）；WP5 的独立转录用产品侧导出实现。
+- **不做** native.Options 单件重构（审计 N30）；新端口不再往里加字段。
+- **不做** MCP tasks/* 的完整产品映射（最小集 only：客户端面 + 中断取消）；完整后台任务子系统归 N3。
+- **不做** token 计费口径拆分（审计 N20 残余）、RunState/OTel/模型回退链/流重试——全部是 N3 范围。
+- 激活工具不进 `Decls()` 保持现状（call_tool 间接层即设计）。
+- 审计 N2（事件竞争）、N3/N18/N19（MCP）、N22（提醒角色）、N7/N8（压缩配对/并发）已修，仅引用不返工；审计 N4 随 WP2 关闭。
+
+## 五、风险与回退
+
+- **Anthropic 方言漂移**：以录制夹具锁定请求/响应字节形态，预设切换属行为变化——任务卡明示；回落手段：models.json 自定义指回 compat 端点（无需改码）。
+- **skills 严格化拒旧内容**：bundled recipes 同 PR 修齐；用户/插件目录里的不合规技能从「静默可用」变「报错可见」——这是本 WP 的有意行为变化，验收时以插件演示技能全绿为门槛。
+- **ctxasm 裁切语义变化**：整组同退可能多丢一条 assistant——以配对安全为优先；`Report.Truncations` 文案同步更新。
+- **MCP 版本协商**：服务端低版本时必须逐字节回落现行行为（WP3-1 的回落用例为放行门槛）。
@@ -0,0 +1,170 @@
+# 方案：N3 持久与可观测——现状核验与增量实施
+
+日期：2026-10-07。上游：[2026-10-02-agent-stack-completion.md](2026-10-02-agent-stack-completion.md)「N3 持久与可观测」节（范围与三条验收的唯一权威）、[2026-10-02-agent-stack-audit.md](../records/2026-10-02-agent-stack-audit.md)（审计项逐条对当前代码复核后引用）。
+
+基线 pin：agent-native `74aa60b`、backend `7980a8a`、agent-squad `6306451`、core `0b5c774`（均为已合入 main）。本文所有 file:line 以这些 SHA 为准；实施时先复核再引用。
+
+依赖状态：N1/Q1/I1/I2/N2 全部闭卡（任务卡归档）。总提案依赖序「N3 在 N2 之后」满足，N3 开工。
+
+## 一、现状核验（五路侦察 + 关键处亲验）
+
+### 1. RunState 可恢复（验收①）
+
+已就位（库层、native 适配路径）：
+
+- **意图日志**：`runOne` 先 `commitToolIntent`（记 CallID/参数/Replay 声明）再执行（runtime/loop.go:649-654,738-749；session/intent.go:9-25）；执行失败于写意图即产 IsError 配对。
+- **恢复配对**：`recoverPending`（loop.go:707-736）对未配对意图——存储声明与注册表现行声明**双 safe 才重放**（completion doc row 75 的不变式），否则补「副作用未知，未重试」IsError 配对。任一情形配对不变式都成立。
+- **预算停配对**：`appendSkippedToolResults`（loop.go:452-469，N1 已修，回归 loop_budget_test.go:78）。
+- **毒化轮转**：`rotateIfPoisoned` + `.native-last-failure` 落盘（adapters/native/backend.go:529-593，N21 已修，跨进程回归 r2_regression_test.go:19）。
+- 回归测试：durable_test.go 四组（safe 重放一次/unsafe 不重放/存储 safe+现行 never 不重放/follow-up 持久序）。
+
+仍开放：
+
+- **崩溃窗口无保护**：`persist(assistant)`（loop.go:265）→ 首个 `commitToolIntent`（loop.go:650）之间被杀，转录留下带 tool_calls 的 assistant 且零意图；`recoverPending` 无计可施，新 user 消息追加在孤立尾巴后，下一个请求被提供方拒绝。**无任何与意图无关的尾部配对兜底**。
+- **产品会话路径零持久**：`llm_direct.go:172-193` 调 `nruntime.Run` 不传 `Session`——意图日志/恢复配对在产品会话 run 上全部不生效；中断后部分 parts 只存内存，seal 即丢。**这是验收① 对产品的真缺口。**
+- 无 mid-turn RunState 类型（turn 序号/在途调用/累计用量）；`runtime/checkpoint` 是文件回滚日志，不是循环状态（checkpoint.go:13-22）。
+- 无「杀进程中途」测试：现有 durable 测试手喂意图，没有覆盖 persist→intent 窗口。
+- **N6 残余**：`Stop.Replacement` 仍把内存 assistant 改为替换文（loop.go:339-347），磁盘上 assistant 是原文——内存/转录分叉跨重启可见（追加的 user 替换消息只缓解了「模型能看到」）。
+- **子代理优雅停机不续跑**：`InterruptRunning` 对所有子 run 写 `done.json{status:"interrupted"}`（runmgr.go:1658），而 `ResumeInterruptedChildren` 遇 done.json 即跳过（subagent_transcript.go:119）——WP5 续跑只对 SIGKILL 式死亡生效，优雅停机语义上反而不续。
+
+### 2. 文件检查点可回滚（验收②）
+
+已就位：
+
+- 库 checkpoint 包：append-only JSONL（Record{Seq,Anchor,Root,Path,Existed,Before,After}）、`Plan/Rewind`、内容漂移跳过（stateRestore/Already/Skip，checkpoint.go:194-229）、包注释与结构双重保证「shell/python 不追踪」。
+- write/edit/multi_edit 三工具经 `WorkspaceToolsCheckpointed` 挂 mark（registry.go:370-394；builtin.go:111-117,153-168,333-353）。
+- backend rewind：每会话 `.agentx/checkpoints.jsonl`（rewind.go:12-17）、anchor=用户消息 ID、HTTP 两路由（server.go:169-170）、regenerate 复用（borrow.go:218）、忙时 409。
+- ZCode 边界全符合：只动文件不回滚历史（追加 system 消息而非删除）、不透明续跑（regenerate 显式起新 run）。
+- 测试：checkpoint_test.go 两组、checkpoint_hook_test.go、rewind_test.go（backend 端到端）。
+
+仍开放（收口项，无根缺）：
+
+- 回滚资格**隐式**（struct 有 mark 字段即入集）：无导出断言/注册表查询，未来工具可静默入集或出集。
+- `restore` 用 `os.WriteFile` 跟随符号链接（checkpoint.go:241）——fs_write_file 有符号链接防护（fs.go:142-146），回滚路径没有。
+- `Rewind` 顺序恢复、首错即返（checkpoint.go:108）：中途失败留下部分恢复，且部分态不进 Result。
+- 无保留策略：`Record` 每次全读算 Seq（checkpoint.go:57-62），日志无界增长。
+- HTTP 层无测试；root 移动、空 `ordered` 边界（selected() checkpoint.go:146）未测。
+- backend 自家工具面只有 `fs_write_file` 挂检查点（tools/fs.go:158-162），无 fs_edit/fs_multi_edit（产品面不暴露编辑工具）——验收② 的 write/edit/multi_edit 语义在库与适配层成立，验收测试按层分配（见 WP3）。
+
+### 3. Memory 端口
+
+已就位（全是产品侧资产）：`memory_entries` 表（migrate v13）+ `PutMemory/ListMemory`（platform.go:137,157，仅 INSERT、无 scope 过滤无语义排序）；HTTP 手工面（server.go:245-246）；被动 recall（runmgr.go:409-426 全量过期过滤 + ctxasm.InjectMemory ≤20 条注入系统消息）；`session_note`、plans/todos；预置 prompts（aux-session-memory.md、agent-memory-extractor.md，**无消费者**）；`AgentSpec.MemoryScope` 已解析（agentspec.go:26,152-153）**零消费**。
+
+仍开放：库内零 memory 面（端口不存在）；无写回路径（模型不可自服务，回合后抽取未接线）；recall 无 scope 过滤；MemoryScope 无消费。
+
+### 4. OTel GenAI span（验收③）
+
+已就位：telemetry 包（Span/StartFunc/手写 OTLP HTTP JSON 导出，telemetry.go:18-106）；**`publicAttrs` 拒绝名单丢 prompt/messages/content 且被测试钉住**（telemetry.go:53-62,89；telemetry_test.go:35-41）——验收③「默认不含提示词正文」已满足且有机器证据；Trace 钩子三处 span（loop.go:174 invoke_agent、:407 chat、:655 execute_tool）；backend 全线注入（app.go:87,258,284-285 → llm.go/sub_loop）。
+
+仍开放：
+
+- **span 名无后缀**：约定是 `chat <model>`/`execute_tool <tool>`/`invoke_agent <agent>`，现名裸词。**这是验收③ 的主缺口。**
+- 属性未 `gen_ai.*`：缺 `gen_ai.system`、`gen_ai.request.model`、`gen_ai.tool.name`、`gen_ai.usage.input_tokens/output_tokens`（token 在循环有，从未进 span）。
+- 无 trace 关联：每 span 随机新 TraceID（telemetry.go:33），无 parentSpanId，Span 无 Parent/Status/Kind 字段。
+- 配置面只有环境变量 `OTEL_EXPORTER_OTLP_ENDPOINT`（telemetry.go:30），无 settings 项。
+- resource 无 `service.name`；导出错误丢弃（:46）；属性值全 string（token 应 intValue）。
+
+### 5. 成本「上一请求/累计」
+
+已就位：`Usage.Last*` 三字段（types.go:90-99）+ 循环覆盖（loop.go:262-264）；预算检查用 `LastPromptTokens`（loop.go:872-873，正确——prompt 成本按整段历史计）；`message_end` 事件带单请求值（loop.go:269）。
+
+仍开放：cache tokens 从不累计（loop.go:259-264 只动 Prompt/Completion/Total）；`"usage"` 事件只带累计（loop.go:853-855，且 budgetStop/错误路径不发）；`core.Usage` 无 Last*/cache 字段（modules/core model.go:205-213）；**子代理 run 零 token 记录**（runmgr.go:1399 只记 DurationMs；sub_loop 不调 AddUsage）；前端只显示 total（AgentTracker.tsx:79-83）；无逐请求台账。completion 预算用累计（loop.go:875）经复核为**正确语义**（run 级输出预算），不动。
+
+### 6. 模型回退链（基本已修，剩收口）
+
+已就位：库 `WithFallback`（llm/fallback.go:7-47——5xx 且未出增量才切换，测试 fallback_test.go 三组）；backend `ChatFallbacks` 解析（model.go:65-81）+ 消费（llm_direct.go:103、sub_loop.go:61 chat 档子代理）+ `noteModelSwitch` 通知与 servedModel 落账（llm_direct.go:210-240）。回退条目共享主端点（记录为有意）。
+
+仍开放（收口项）：verifier 与 lightweight 档未接；切换无可观测事件类型（仅 process part 文案）；agent-native CLI 未用 WithFallback。
+
+### 7. 流式错误默认重试
+
+已就位：`WithRetry`（providers.go:447-524——Retryable 分类 408/429/529/≥500 与容量文案、Retry-After 上限 30s、指数退避加抖动、**只在未出增量时重试**、上下文溢出不重试；providers_test.go 五组钉住）；backend `runtime.llmRetries` 默认 2 接直连（llm.go:208-209；settings.go:43,94）；agent-native CLI 接 2 次（main.go:121）。
+
+仍开放：**库循环无默认**——重试是宿主 opt-in，子代理/verifier/squad 路径未接（`sub_loop.go:52-59` 无 WithRetry）；`onEvent` 为 nil，重试不可观测；run 记录无重试次数。
+
+## 二、工作包划分
+
+| WP | 内容 | 主要仓 | 对应验收 |
+|---|---|---|---|
+| WP1 | RunState 收口：崩溃窗口尾部配对兜底 + 杀窗口测试 + N6 残余 + 子代理优雅停机续跑语义 | agent-native + backend | ①（库层） |
+| WP2 | 产品会话路径持久化：llm_direct 接 Session（transcript.jsonl），产品会话 run 获得意图日志与恢复配对 | backend | ①（产品层） |
+| WP3 | 检查点收口：资格断言、符号链接防护、部分恢复进 Result、保留策略、HTTP 与边界测试 | agent-native + backend | ② |
+| WP4 | OTel GenAI 对齐：span 名后缀、gen_ai.* 属性、trace 关联与 parent、resource、settings 面 | agent-native + backend | ③ |
+| WP5 | Memory 端口：runtime/memory 包 + 循环 recall 消费点 + MemoryScope + backend scope 实现 + memory_write 工具 | agent-native + backend | — |
+| WP6 | 计费拆分与回退/重试收口：cache 累计、usage 事件与 run 记录带 Last*/cache、子代理 token、库默认重试、可观测事件 | agent-native + core + backend + frontend | — |
+
+依赖：WP1 先行（验收① 库层核心，WP2 依赖其兜底语义）；WP2 随后（产品落点）；WP3/WP4/WP5 独立可并行；WP6 收尾（含 core 字段级联与重试语义变化，WP6 后做总装与 A/B）。每 WP 走既有链式（库 PR → 级联 → backend PR → Dev gitlink PR），逐 WP 合入。
+
+### WP1 RunState 收口（验收① 库层）
+
+1. **尾部配对兜底**：`recoverPending` 之后加 `repairOrphanTail`——Load 后若活动分支尾部是带 tool_calls 的 assistant 且其 ToolCalls 存在无结果项，对每个无结果调用补一条 `tool` 消息（`Content: "进程中断，该调用未执行"`, IsError: true）并 persist。与意图路径正交：意图已配对的调用不受影响（按 CallID 判重）。这样无论死在哪个窗口，下次 Run 前转录配对恒成立。**这是验收① 的机器核心。**
+2. **杀窗口测试**：循环测试钩子（在 persist(assistant) 之后、首个 intent 之前让测试能停住循环，或直接构造该转录形态——两态都测：窗口内死亡（无意图）与执行中死亡（有意图未配对）），断言：恢复后 assertToolPairs 双向成立 + 兜底结果文案正确 + 已配对项零重复。
+3. **N6 残余**：`Stop.Replacement` 不再改内存 assistant（只追加 user 替换消息）——内存与转录一致；`loop_harness_test.go:17-63` 同步改断言（替换文案不再出现在 res.Messages 的 assistant 上，而是新 user 消息）。行为变化入卡。
+4. **子代理优雅停机续跑语义**：done.json 按 status 分流——`completed/failed/cancelled` 挡续跑；`interrupted` 不挡（优雅停机=可续跑现场）。`ResumeInterruptedChildren` 改判据并补回归（模拟 InterruptRunning 路径后仍被续跑一次且仅一次）。
+
+### WP2 产品会话路径持久化（验收① 产品层）
+
+1. `llm_direct.go` 的 `directRun` 打开会话工作区 transcript：`<workspaceRoot>/<owner>/<conv>/.agentx/transcript.jsonl`，经 `runtime.Session` 传入 `nruntime.Run`——产品会话 run 获得意图日志、恢复配对与（WP1-1 的）尾部兜底。
+2. 历史来源对齐：现 `History` 来自 store 重放；Session 模式以 transcript 为准（库语义：Session 非空时 transcript 是权威，History 仅在 transcript 为空时作种子——llm.History 的既有语义 loop.go:76-78）。迁移语义：首次启用时 transcript 为空 → 用 store 历史种子；此后 transcript 权威。种子与续接的一致性测试（不丢不重）。
+3. **不做透明续跑**（ZCode 边界，入卡）：`ReconcileInterrupted` 对会话 run 仍 seal interrupted；配对修复在下一条用户消息触发的新 run 前完成（WP1-1 兜住），用户看到的是「中断」标记 + 可继续对话，不是自动重跑。
+4. 端到端测试：产品路径杀窗口形态 → 新 run 前配对成立 + 用户可继续发消息（种子不丢历史）。
+
+### WP3 检查点收口（验收②）
+
+1. **资格断言**：导出 `Registry.Checkpointed(name) bool`（struct mark 非空即真）或同语义测试辅助；测试钉住入集集合恰为 {write_file, edit_file, multi_edit}（库）与 {fs_write_file}（backend 自家面），防静默漂移。
+2. **符号链接防护**：`restore` 落盘前 `Lstat`——目标为符号链接时跳过并进 Skipped（与 fs_write_file 的防护同语义）+ 测试。
+3. **部分恢复进 Result**：`Rewind` 单文件失败不中止，记录 `Failed []string` 续跑其余；Result 增字段（additive）；测试（一个失败一个不失败）。
+4. **保留策略**：按 anchor 裁剪——`Log.Compact(keepAnchors int)` 只保留最近 N 个 anchor 的记录（重写日志文件）；backend 在 RewindFiles 成功后以 keepAnchors=200 调用；`Record` 的 Seq 改由文件尾行号维护（去全读）。
+5. **测试补齐**：HTTP happy + busy 409（server 层）；root 移动场景（restore 按记录内 Root 恢复，不窜根）；空 `ordered` 边界行为钉住；「外部同字节改写」分类为 Already 的语义钉住。
+
+### WP4 OTel GenAI 对齐（验收③）
+
+1. **span 名带后缀**：`invoke_agent <agent|agent-native>`、`chat <model>`、`execute_tool <tool>`（loop.go 三处改名；适配器/宿主传 agent 名——invoke_agent 的 agent 名用 Config.ExecutionID 或新增 Config.AgentName，默认 "agent-native"）。
+2. **`gen_ai.*` 属性**：`gen_ai.system`（openai/anthropic，由客户端协议名上抛——Stream 事件或 Config 显式字段，取后者简单：`Config.ProviderName string`，宿主可设，空=openai）；`gen_ai.request.model`（chat span）；`gen_ai.tool.name`（execute_tool span）；`gen_ai.usage.input_tokens/output_tokens`（chat span 结束时由该轮 Usage 填入）。
+3. **trace 关联**：一次 Run 共享一个 TraceID，`invoke_agent` 为根、`chat`/`execute_tool` 为其子（parentSpanId）。Trace 钩子签名扩展：`Trace func(name string, attrs map[string]string) func()` 保持，Span 增 ParentSpanID/TraceID 注入位（telemetry.StartFunc 返回的闭包按 name 层级维护栈——invoke_agent 入栈为根，出栈弹出；简单确定性强）。
+4. **resource 与导出**：resource 增 `service.name=agent-native`（宿主可覆盖：telemetry.StartFunc 的选项参数）；token 属性 intValue；导出失败记日志（不静默吞）。
+5. **settings 面**：`telemetry.otlpEndpoint`（默认 "" = 不导出，保持现状语义；环境变量继续有效，settings 覆盖环境）；`telemetry.serviceName`（默认 agent-native）。两处 default 的行为不变证明测试。
+6. **测试（验收③ 机器证据）**：span 名后缀与属性键枚举断言（钉住约定）；一次 Run 的 span 共享 TraceID 且 parent 链正确；token 进 chat span 且为 intValue；拒绝名单保持（prompt/content 永不序列化——既有测试原样通过）。
+
+### WP5 Memory 端口
+
+1. **runtime/memory 包**：`Entry{ID,Scope,ProjectID,Type,Content,Source,Confidence,CreatedAt,ExpiresAt}` + `RecallQuery{Scope,ProjectID,Limit}` + `Store interface{ Recall(ctx,q) ([]Entry,error); Append(ctx,e Entry) error }`。端口形态对齐 squad/runstore.go 的先例（库定义+宿主实现）。
+2. **循环消费点**：`Config.Memory memory.Store`（nil=不启用）+ `Config.MemoryScope string`（对应 AgentSpec.MemoryScope 的消费）；`prepareRequest` 时在系统前缀后追加 recall 注入块（替换文案形态与 ctxasm.InjectMemory 对齐：`[记忆]\n- (typ) content`，上限 20 条，确定性排序）——行为对齐测试（端口注入的条目出现在请求里、nil 时无变化）。
+3. **backend 适配**：`storeMemory{st, owner}` 实现端口（Recall=ListMemory scope/过期过滤+Limit；Append=PutMemory）；`llm.go` 装配把现 `Memories()` 断言路径（llm.go:231-233 + runmgr.go:409-426）迁到端口（语义等价：同条目同排序同文案——迁移前后注入文本一致的对照测试）。`AgentSpec.MemoryScope` 经 squad/native 适配传入 Config.MemoryScope（plugin agents 的画像驱动 scope）。
+4. **memory_write 工具**：库内工具（模型自服务写回；参数 {scope,type,content,expires_in_days?}，经 `Config.Memory.Append` 落库；未配置不注册）；scope 校验（user|project）与类型校验（fact|preference|decision|episode|procedure）fail-closed。
+5. 后续项（入卡剩余项，不在本 WP）：回合后抽取接线（agent-memory-extractor 子代理 + SessionEnd 事件驱动）、AllowStore 持久化形态（N1  deferred）。
+
+### WP6 计费拆分与回退/重试收口
+
+1. **cache tokens 累计**：loop.go:259-264 增 CacheRead/Write 累计与 Last* 对应位（Usage 增 LastCacheReadTokens/LastCacheWriteTokens?——决策：Last* 只对 Prompt/Completion/Total 已有三字段，cache 只入累计位，避免字段膨胀；记录决策依据）。
+2. **usage 事件与 run 记录**：`emitUsage` 带 Last*+cache；settle 之外的路径（budgetStop/错误）也发一次终态 usage（口径=当时累计，标注终止原因在既有错误面）；`core.Usage` 增 `LastPromptTokens/LastCompletionTokens/CacheReadTokens/CacheWriteTokens`（additive JSON，core 仓 PR+级联）；backend AddUsage 链路上抛新字段；**子代理 token 记账**（sub_loop AddUsage 接线，finishChild 写入 child.Usage 的 token 字段）。
+3. **前端**：contracts.ts Usage 增可选字段；UsageBadge 显示「上一请求 / 累计」（如 `+12.3k · 累计 98.1k`）。
+4. **库默认重试**：`Config.RetryAttempts`（默认 2，0=关）——`Run` 内包装 `cfg.Stream = llm.WithRetry(cfg.Stream, attempts, onEvent)`；backend 直连的显式包装退役（防双重），子代理/verifier/squad 经库默认获得（行为变化：这些路径从 0 次变 2 次重试——入卡；onEvent 接 runCtx 事件面，`auto_retry_start/end` 成为可见事件）。
+5. **可观测**：`auto_retry_start/end` 与 `model_fallback_switch` 事件类型入事件面（库 Event 类型 + backend 映射 + 前端展示沿用现有 process part 形态）。
+6. **回退链接 verifier/lightweight**：verifier 的流包 WithFallback（lightweight 档回落主档的既有语义不动）；CLI 记录边界（不接）。
+
+## 三、验收总表
+
+| 总提案验收 | 机器证据 | 所在 WP | 现状 |
+|---|---|---|---|
+| ① 回合中途杀进程，恢复后工具配对仍成立 | 库：`TestResumePairsOrphanTailAfterCrashWindow`（无意图窗口）+ 既有 durable 四组（原样保持）；产品：`TestDirectRunPairsAfterKillSeed`（种子不丢+配对成立） | WP1+WP2 | 库有意图路径覆盖、窗口无保护；产品零持久 |
+| ② 回滚只撤销 write / edit / multi_edit | 资格集合钉住测试（库 {write_file,edit_file,multi_edit}、backend {fs_write_file}）+ 既有 rewind/checkpoint 测试原样通过 + shell 文件存活断言（既有） | WP3 | 结构性成立、断言隐式 |
+| ③ span 名与约定一致，默认不含提示词正文 | `TestSpanNamesFollowGenAIConvention`（名称后缀+gen_ai.* 键枚举+intValue token+TraceID 共享+parent 链）+ 既有 publicAttrs 拒绝名单测试原样通过 | WP4 | 正文拒绝已有；名称/属性/关联未对齐 |
+
+## 四、边界与非目标
+
+- **不做透明续跑**（ZCode 边界）：配对修复后等新用户消息；会话 run 仍 seal interrupted。WP5 子代理续跑（重派新 run）是既有有意设计，不扩展到会话 run。
+- **不回滚对话历史**（ZCode 边界）：rewind 只动文件，WP3 不碰消息面。
+- **不做** memory 回合后抽取接线、AllowStore 持久化、RAG 语义检索 memory_entries（WP5 是端口与接线，召回排序升级留后续）。
+- **不做** OTel SDK 引入/gRPC/batch/采样（保留手写 HTTP JSON 导出；WP4 只做语义对齐与可靠化小修）。
+- **不做** completion 预算口径改动（loop.go:875 经复核为正确语义）、prompt 预算口径改动。
+- **不做** 回退条目独立端点（共享主端点记录为有意）、CLI 的 fallback 接线（记录边界）。
+- 审计 N1/N21 已修只引用；N6 随 WP1 关闭；N20 随 WP6 关闭（预算语义不动，展示/记录口径拆分）。
+
+## 五、风险与回退
+
+- **产品路径接 Session（WP2）**：transcript 成为权威是会话语义变化——种子迁移必须保「不丢不重」（WP2-2 的对照测试为放行门槛）；出问题回退 = 不传 Session（单点开关，代码内常量而非设置项，回退 PR 即可）。
+- **N6 行为变化（WP1-3）**：Stop.Replacement 的展示形态变化（assistant 不再显示替换文，替换文以 user 消息出现）——guardrails 消费方（verify 回路）逐一回归。
+- **WP6 重试默认化**：子代理/verifier/squad 从 0 变 2 次重试——超时/配额消耗上升；`RetryAttempts=0` 可全关（测试钉住 0=不重试）。
+- **core.Usage 加字段**：additive JSON 兼容旧记录；级联链 core PR → backend PR → frontend PR → Dev。
+- **done.json 语义分流（WP1-4）**：interrupted 从「挡续跑」变「可续跑」——优雅停机后重启会多一次重派；幂等由 resumed.json 保证，测试钉住「一次且仅一次」。
@@ -0,0 +1,100 @@
+# 方案：Q2 拓扑 + Q3 收敛与互通——现状核验与增量实施
+
+日期：2026-10-07。上游：[2026-10-02-agent-stack-completion.md](2026-10-02-agent-stack-completion.md)「Q2 拓扑」「Q3 收敛与互通」节（范围与验收的唯一权威）、[2026-10-01-agent-harness.md](2026-10-01-agent-harness.md) P4 裁定（Q3 行为等价的判据原文）。
+
+基线 pin：agent-squad `c462bc4`、agent-native `1ac21c6`、backend `6e02a1f`、core `a253a40`（均为已合入 main）。本文所有 file:line 以这些 SHA 为准；实施时先复核再引用。
+
+依赖状态：N1/N2/N3/Q1/I1/I2 全部闭卡。总提案依赖序「Q3 在 Q2、N1、I1 之后」满足。两阶段各自单独任务卡（本文覆盖两个方案；Q2 先实施，Q3 在 Q2 闭卡后开工）。
+
+## 第一部分：Q2 拓扑
+
+### 一、现状核验（三路侦察）
+
+引擎面：只有 `standard`/`leader` 两个 mode（engine.go:94-96,383-400，RunMetadata.Metadata 字符串），**无拓扑抽象**。Q1 图层可表达 sequential（graph.go:62-68 链式默认）与 parallel（Parallel/Needs 同层 + 写集串行，graph.go:56-61,165-182）；环 fail-closed（graph.go:71-73）。router 只有 pre-plan 分诊（router.go:24-52）。leader 有 delegation 循环（leader.go:180-385）但账本只有 `Delegations`（leader.go:51-66），无卡顿检测；轮次上限有（MaxLeaderTurns=8，termination.go），**无独立重规划上限**；leader 绕过图循环直接 runOneStep（leader.go:328-341）。Termination 的 Cond/And/Or 组合子（termination.go:59-120）已建但**休眠**（只有测试消费）。`FactItem.Verified`（models.go:148）声明未用。
+
+mailbox 攻击面：`RespondDecision`（hitl.go:99-108）**无 actor 归属**——任何能调 `engine.Respond` 的调用方发 `Choice:"approve"` 都清权限门。现有防线：fireWakeup 只自动决 gap/escalation（engine.go:1216-1227，回归 TestWakeupDoesNotApprovePermission）、自由文本不决议 choice 门、过期只合成 fail/cancel、wakeup 上限自动 abort。mailbox 若经 Respond 投递或扩 fireWakeup 白名单即破防。
+
+review 等价基线（backend runReview，review.go:41-92）：并行 N finder（semaphore 3，真并发被 review_test.go:16-33 钉住）→ 宽松 JSON 解析（首 `[` 末 `]`，丢空 issue）→ 按 (location,issue) 去重、上限 10 → 每条独立 verifier（VERDICT: PASS/FAIL/PARTIAL 尾行判定）→ 只留 PASS（fail-closed）→ severity 稳定排序 → 报告恒带「已丢弃 N 条未验证」。squad 侧今天只有质量 Checker+修复预算（单轮），无此拓扑。
+
+task-board/long-running：平台 SQLite 队列有 claim/lease/heartbeat/orphan 恢复（adapters/sqlite/queue.go:133-348）但未接 Steps 图；checkpoint 三档+图连续性+run 锁已就位（runstore.go:94-212）。conformance 基建齐全：scriptBackend/replayBackend/leaderScriptBackend + MockPlanner（engine_test.go:13-80、conformance_test.go:19-47、leader_test.go:15-90）。
+
+### 二、设计决策
+
+1. **拓扑一等化但不做大重构**：`Blueprint` 与 `RunOptions` 增 `Topology string`（空 = 现行 standard 图，零行为变化）；`squad/topology.go` 注册内置拓扑名与各自 Spec。图可表达的（sequential/parallel/loop/router/evaluator-optimizer/long-running）编译为 Steps+引擎旗标；需要独立驱动的（leader 增强/review/group-chat/task-board）走驱动分支；handoff/mailbox 是**跨拓扑原语**（任何拓扑可用）。
+2. **loop 不做图环**：保持环 fail-closed。`StepSpec.Loop *LoopSpec{MaxIterations, UntilField, UntilEquals}`——步骤完成后条件不满足且预算未尽时**重置为 pending 再武装**（推广 rerunForRepair 语义）；预算走 Termination（唤醒休眠的 Cond 组合子）。
+3. **router 进图**：`StepSpec.Branches []Branch{When{Field,Equals}, Then []stepID}`——router 步完成后按黑板字段/步骤输出判定，未选中分支的步骤置 skipped（skipped=依赖已满足，join 步照常推进）。
+4. **mailbox 的防线是构造性的**：投递路径**永不经过 Respond**；同时给 `RespondDecision` 加 `Actor`（human/system/agent，空=human 保持既有调用方语义），`applyDecision` 对 permission/confirmation/quality_review 三类门拒绝非 human 的 choice 决议（双保险）。
+5. **review 等价以报告字节形态为判据**：squad review 驱动复用 backend runReview 的解析/去重/判定/排序/文案常量（同一格式串），conformance 断言与 review_test.go 同款（并发找、去重后逐条验、丢弃计数、severity 序）。
+6. **task-board 做 squad 侧原语**（claim/lease/complete + 依赖门），语义与平台队列对齐；平台队列桥接记为后续项（completion doc 的「platform 队列改成 task-board」在桥接层，非本 WP 阻塞）。
+
+### 三、工作包
+
+| WP | 内容 | 验收对应 |
+|---|---|---|
+| Q2-WP1 | 拓扑面 + 图可表达五件：Topology 字段与注册表；sequential/parallel conformance；loop 再武装（LoopSpec+Cond 预算）；router 分支（Branches+skipped）；evaluator-optimizer（loop 复合：draft→evaluate→MinScore 不达标再武装，MaxRounds 预算）；long-running（Deadline 打包进 terminationOf + checkpoint 组合 conformance） | 验收一（6/12 拓扑） |
+| Q2-WP2 | leader 增强 + mailbox：进度账本（Progress 条目+卡顿检测 StuckTurns）、重规划上限（Replans/MaxReplans 独立于 MaxTurns，触顶降级收口）；mailbox 原语（RunState 邮箱、PostMessage、步前投递进任务书、永不触 Respond）+ RespondDecision.Actor + 非 human 决议拒绝 | 验收一（8/12）+ 验收三 |
+| Q2-WP3 | review + handoff + group-chat：review 驱动（并行 finder→解析去重→逐条 verify→fail-closed 过滤→等价报告）；handoff 原语（StepSpec.Handoff、所有权转移记录、finalize 取链尾输出、目标收过滤历史）；group-chat 驱动（共享转录、轮转/主持人选人、预算停机） | 验收一（11/12）+ 验收二 |
+| Q2-WP4 | task-board + 收口：claim/lease/complete 原语与依赖门、孤儿租约再武装；全 12 拓扑 conformance 汇总跑；级联（backend 嵌套 pin → Dev） | 验收一（12/12） |
+
+conformance 统一形态：脚本化后端（scriptBackend/replayBackend/leaderScriptBackend 家族扩展），零模型零网络；每拓扑一个 `TestTopologyConformance_<name>`。
+
+### 四、Q2 验收总表
+
+| 总提案验收 | 机器证据 | WP |
+|---|---|---|
+| 每种拓扑有一个脚本化后端的 conformance | 12 个 TestTopologyConformance_*（sequential/parallel/loop/router/leader/handoff/group-chat/review/evaluator-optimizer/long-running/task-board/mailbox） | WP1-4 |
+| review 等价于今天的「并行找问题、逐条验证、丢掉未验证」 | review conformance 断言与 backend review_test.go 同款：finder 真并发、去重后 verify 调用数=unique 数、只留 PASS、「已丢弃 N 条未验证」计数、severity 序 | WP3 |
+| mailbox 消息不能把挂起的权限批准掉 | TestMailboxCannotApprovePermission（挂 permission 门→投「approve」消息→门仍挂起）+ TestWakeupDoesNotApprovePermission 原样通过 + Actor 拒绝路径测试 | WP2 |
+
+### 五、Q2 边界与非目标
+
+- 不改 leader 绕过图循环的执行形态（记为已知债，统一驱动属后续重构）。
+- 平台队列桥接、backend review_findings 切换到 squad review 拓扑：后续项（Q3+ / RDM 阶段按需）。
+- group-chat 的发言人策略只做轮转与主持人两种（脚本可判定）；LLM 选人策略不进库。
+- Termination Cond 组合子被 loop/long-running 唤醒后，既有标量路径不动。
+
+## 第二部分：Q3 收敛与互通
+
+### 一、现状核验
+
+WorkflowDef 在 core（plugin.go:56-84）：六类步骤（prompt/tool/hitl/artifact/card/script）+ StepCritic，**无条件分支字段**；golden 样本 workflow_def.json。执行器 `runtime/workflow.go`（步循环 125-200、critic 重试 202-244、prompt 步压 SpawnSubagent 312-334）+ `workflow_script.go`（脚本宿主 38-56、限额 19-24、DeniedTools 180）。数据层 `internal/workflow/`（registry/render/validate，P4 上限 11-16）。**「压成 SpawnSubagent」退役对象**：squadadapter stepBackend "agent-system"（adapter.go:150-212，DefaultBackend adapter.go:79，内置四角色全部 agent-system 380-392）。
+
+P4 裁定原文（agent-harness.md:102-112）：声明式 ≤20 步；模型生成 ≤8 步、禁 script、执行前必须确认；critic 每步 ≤3（缺省 1）、整条 ≤6、无法解析按不通过；脚本回调 ≤50、单行 ≤1MB、超时 600/1800s 含等人；`runtime.workflowScripts` 默认关；模型脚本必须确认、**插件脚本免确认**；脚本禁 run_python/run_shell/run_workflow/派发类；小队入口无 run_workflow。代码落点齐全（validate.go:11-40,80-83；workflow.go:64-76；workflow_script.go:26-28,38-56,103-115）。
+
+demo 插件在 Dev 仓根 `plugins/example/`：demo.brief（意图 demo.brief，五步：hitl choice→prompt+critic「核对标记：P4」→artifact→card→hitl confirm）、demo.script（单 script 步 → demo.py：wf.tool/wf.ask/wf.artifact/wf.step）。host_test.go:214-256 直接装载它。
+
+a2a：**全仓不存在**，从零建（规划位置 agent-squad/adapters/a2a 独立 go.mod；A2A 1.0 Agent Card/任务状态机对齐，completion doc:54,102,239）。默认执行后端：`runtime.entry` 默认 direct（settings.go:39，灰度注释）；direct 已跑 agent-native 内核；squad 工具路径默认后端 "agent-system"（要切）；RunEntry 已是 agent-native（entry.go:103）。A/B：eval/switch.go 的 DecideSwitch 骨架 + N1 wp5_ab_test.go 先例；缺「同批任务双跑记录差异」harness。委派模板：内核 SubagentFactory 已有 目标/输入/可写范围/非目标/完成判据/交付物（adapter.go:299-343），**缺「输出格式」与「工具面」**两节。
+
+### 二、工作包
+
+| WP | 内容 | 验收对应 |
+|---|---|---|
+| Q3-WP1 | 编译器：core.WorkflowDef → squad Blueprint/Steps（prompt→agent-native 角色步、hitl→RequiresApproval/intent 步、tool/artifact/card→宿主工具步、script→codeorch 宿主步、critic→Checker+MinScore+RepairBudget；P4 全部上限与 DeniedTools 迁入编译器；计划确认与模型脚本确认保留、插件脚本免确认、workflowScripts 开关保留） | demo.brief/demo.script 经编译图跑通 |
+| Q3-WP2 | 退役与切换：删 internal/workflow 数据层执行依赖、runtime/workflow.go+workflow_script.go 退役（run_workflow 三分支改投编译图）、stepBackend "agent-system" 删除、DefaultBackend→agent-native、runmgr WorkflowRunner 分支移除 | P4 行为一致（步数上限/确认/脚本开关逐项测试） |
+| Q3-WP3 | 委派模板补全：任务书增「输出格式」「工具面」两节（SubagentFactory 与 stepBackend 遗产路径统一）；adapter_test 任务书断言扩展 | 委派模板含目标、输出格式、工具和边界 |
+| Q3-WP4 | adapters/a2a（新模块）：Agent Card 发布（描述本团队能力）+ 远端智能体 Executor 客户端（A2A 任务状态机对齐 ExecResult）；双向 conformance（本地起假 A2A 服务端） | adapters/a2a 双向 |
+| Q3-WP5 | A/B 对照与默认后端：任务级 direct vs squad(编译图) 双跑 harness（扩 eval/switch.go），同批任务（含 demo.brief 场景）记录差异（不要求字节级相同）；DecideSwitch 达标则 runtime.entry 默认切 squad 的证据入卡 | A/B 对照记录差异 |
+| Q3-WP6 | 级联闭链 + 任务卡验收证据 | — |
+
+### 三、Q3 验收总表
+
+| 总提案验收 | 机器证据 | WP |
+|---|---|---|
+| demo.brief 与 demo.script 经编译后的图跑通 | 装载 Dev 仓 plugins/example → 编译 → squad 引擎（脚本化后端）跑通两个工作流的 conformance | WP1 |
+| 行为与 P4 裁定一致（步数上限、确认、脚本开关） | 逐项测试：20/8 步上限、3/6 重试、计划确认卡、模型脚本确认、插件脚本免确认、workflowScripts 默认关、DeniedTools、小队入口无 run_workflow | WP1-2 |
+| A/B 对照记录差异，不要求字节级相同 | eval harness 输出差异报告入任务卡（DecideSwitch 判定 + 差异清单） | WP5 |
+
+### 四、Q3 边界与非目标
+
+- `runtime.entry` 默认值切换本身是**设置变更**：A/B 达标后由 WP5 证据支持、在卡上记录，若 DecideSwitch 不达标则保持 direct 并记录差异（验收只要求「对照记录差异」）。
+- a2a 只做库层双向（Card 发布 + Executor 客户端 + 假服务端 conformance）；产品暴露 A2A 端点属后续。
+- 平台 task 队列翻译成 squad run（更深的产品合一）不在 Q3（completion doc 归 Q 系列后续）。
+- internal/workflow 的**数据形态**（WorkflowDef 校验/渲染语义）迁入编译器后原包删除；golden 契约样本随迁。
+
+## 五、风险与回退（两阶段共用）
+
+- **Q2 loop 再武装**与修复重跑共用重置语义：以「预算独立计数」隔离（loop 迭代不占 RepairBudget），测试钉住互不侵占。
+- **Q2 router skipped 传播**：skipped=依赖满足的既有语义使 join 步在分支未选时照常推进——conformance 钉住 join 行为，防止「全分支跳过导致空转完成」被误判成功（报告需列 skipped 分支）。
+- **Q3 退役面大**：以「编译器先行、双轨并行一个增量、退役单独增量」推进；退役 PR 前 demo 插件双轨对照（旧 runner vs 编译图）记录差异。
+- **Q3 默认后端切换**：行为变化门禁是 A/B harness，不达标不切（settings 默认值不动即回退）。
+- mailbox/Actor 默认值兼容：空 Actor=human 保持全部既有调用方与测试语义不变（新增拒绝路径只影响显式非 human）。
@@ -0,0 +1,252 @@
+# 研发记忆与体系文档智能体：大阶段目标与实施方案（RDM 阶段总案）
+
+状态：**proposed（2026-10-07）**；owner：weichen；主任务：Dev 仓 `feature/rdm-phase-plan`。
+愿景依据：《智能体系统/further-objective》01–13（产品愿景文档，未入库；方案 10 已复制到下游仓 `Agent-System-RDM` 的 `docs/` 作奠基文档，本文以「愿景 01/02/03/04/08/10/11/12/13」引用）。
+上游：[2026-10-02-agent-stack-completion.md](2026-10-02-agent-stack-completion.md)（库分期）、[2026-10-07-agent-stack-n1q1i1-plans.md](2026-10-07-agent-stack-n1q1i1-plans.md)（N1/Q1/I1 实施方案）。
+规范依据：Development-Guidelines（workflows/delivery.md、standards/collaboration.md、standards/verification.md）；本文是项目级消费，不复制其正文。
+
+本文把 further-objective 描述的最终系统立为本系统下一个大阶段的目标，设定大方向与架构不变量，给出里程碑对齐的实施方案。本文不实施代码；各阶段的实现各走各的任务卡。
+
+---
+
+> 2026-10-11 补齐候选：[最终目标核对与完整交付方案](2026-10-11-rdm-final-target-completion.md)按本轮用户确认及 RDM d8d7e743 重新映射项目/隐私/三权、全部模板与 34 UR／68 SR／10 F。该方案待评审；本页历史快照和原始证据保留，不能据其旧完成声明推断最终验收。
+
+## 1. 大方向与大目标
+
+### 1.1 一句话目标
+
+把通用智能体基座二次开发为「**面向医疗器械研发企业的研发记忆与体系文档智能体**」：把项目全周期的一切资料持续沉淀为可追溯的研发记忆，让体系文档随项目推进渐进式清晰，并以人在环路的确认机制保证每一步受控（愿景 02 §1）。产品形态为三栏 + 卡片流 + 弹出层（愿景 05/06），数据心智为两树一网：笔记树 + 文档树 + 追溯网（愿景 08）。
+
+按新口径里程碑推进（愿景 10 §10.1，W1 = 2026-10-05~10-11）：
+
+| 里程碑 | 窗口 | 内容 |
+|---|---|---|
+| MS0' | W1（本周） | 需求定稿、双仓就位、决议闭环、v0.1.0 评估基线 tag |
+| v0.2.0 发版 | W2 末，最迟 W3 末（10-25） | 基座含 EXT-1，SurfaceVersion 2.0.0-experimental |
+| MS1 | W4（11-01） | 上传五步法 + 两速入库端到端 |
+| MS2 | W7（11-22） | 文档基线 + 三分类比对 + 版本链 |
+| MS3 | W11（12-20） | 两树一网 + 变更闭环 + 一键生成（结构事件日志先行） |
+| MS4 | W16（2027-01-24） | 自举全程运行、可对外演示（依赖 EXT-3 渠道） |
+
+### 1.2 三条架构不变量（大方向的约束）
+
+**INV-1 双仓纪律（二次开发原则）。** 领域逻辑（两树一网、模板、流程骨架、法规双通道、上传管道）只住在下游仓 `Agent-System-RDM` 与声明式插件规格里；基座（本仓五仓组合）只经「**扩展点申请 → 基座实现并发版 → 下游升级**」演进（愿景 10 §1.1、§七.1）。下游只 import `pkg/extension` 与 core 类型、不碰 internal；改基座 internal 的补丁一律拒绝。
+
+**INV-2 可退化不变量（退回通用智能体）。** RDM 的一切能力——命令处理器、意图规格、工作流、技能、页面、卡片、任务——以插件/声明式规格为唯一承载形态，挂在一个装载开关下。**禁用（或移除）RDM 插件时，系统行为恒等于基座发布物本身**：RDM 路由回落到普通回合、命令/页面/卡片不出现、既有通用场景全通。数据不删（下游自有库表，schemaVersion 自管迁移），重新启用即恢复可见。基座仓的任何 diff 不得出现 RDM 领域字样，评审与 CI 双重检查（见 §3.2）。
+
+**INV-3 证据与验收纪律。** 沿用 AGENTS.md「证据与验证门禁」：声明 ≠ 能力，每个里程碑的验收都是命令 × 对象 SHA × 可复核输出；任务卡、PR、证据收据随分支走；CI（PR HEAD 上 `make test`+`make build`）是测试通过的权威源。
+
+### 1.3 与库分期（基座演进线）的关系
+
+库分期（N1/Q1/I1 → N2/N3/Q2/Q3/I2）是「小队骨架执行、意图分层识别（规则→语义→LLM 的快慢分层）、恢复可靠性」的地基，**服务 RDM 但不阻塞 MS1**。它们的第一批真实消费者：
+
+- MS3 一键生成 ← Q1 图执行、Q3 编排收敛（愿景 03 F4、M10）；
+- 意图命令化与快慢分层（愿景 03 交互与意图层）← I1/I2；
+- 长任务可恢复（愿景 SR-E5/F4 长任务异步）← N3、Q1。
+
+排布原则：库分期按既定方案推进（N1 → Q1/I1 并行 → 后续），在 MS3 窗口前给出最迟合入点（§4.4）。
+
+---
+
+## 2. 现状基线（2026-10-07 实测）
+
+> **历史快照注记（2026-10-08）**：本节为 2026-10-07 撰写日快照，其中三处已随后游
+> 密集交付失效（下游功能为零、库分期进度、O1/O3/O7 阻塞）。原文保留不改写，
+> 逐行复核与现行状态见 §2.3；阅读与排期以 §2.3 为准。
+
+### 2.1 已就位
+
+| 项 | 状态 | 证据/位置 |
+|---|---|---|
+| 基座平台层 | 会话/工件/卡片/HITL/任务/审计、混合检索（向量 RAG + RRF）、PG 多租户档、认证、限流、多实例地基 | modules/backend（dual-tier 阶段 0–3 已合入） |
+| EXT-1 进程内命令处理器 + owner 作用域宿主句柄 | 已合入 main，**MS1 阻塞项解除** | Dev #207/#209；`pkg/extension/surface.txt` 含 `Handler`/`Host`/`Host.ArtifactContent`/`Host.Audit`/`Host.Complete`/`Host.KVGet` 等符号 |
+| EXT-5 宿主文档解析 | 已合入 main（含宽列修复） | Dev #222/#224 |
+| 界面形态 | 三栏 + 卡片流 + 弹出层、收件箱双现投影、交付物卡片与 docx 预览 | modules/frontend、modules/ui（与愿景 05/06 V2.2 原型一致） |
+| 下游仓 | `Agent-System-RDM` 已建仓，种子可编译（29MB 二进制），pins 落位（backend cb26e4c / core 0b5c774 / frontend 50c7244 / ui 27d5adb），8 条 deps replace 就位 | 愿景 13 建仓实录 |
+| v0.1.0 评估基线 tag | Dev / Documents / Backend / Core 等仓 tag 已打（backend 已 +4 提交） | 各仓 `git tag -l v0.1.0` |
+| v0.2.0 前置 | EXT-1 已合入；surface.txt 符号齐；EXT-1 提案已对齐 tag 名与 SurfaceVersion 2.0.0-experimental 兼容承诺 | 愿景 12 核对清单逐项可勾 |
+| 库分期 | R0/R1/R2/D1 已合入；N1 进行中（WP2/WP3 两增量 PR 已开：Agent-Native #17、Backend #69，CI 绿） | 2026-10-02 总提案 §5 |
+| 本大阶段的输入 | N1/Q1/I1 实施方案已评审合入 | Documents #40 / Dev #226 |
+
+### 2.2 缺口
+
+| 缺口 | 性质 | 影响 |
+|---|---|---|
+| v0.2.0 未发版 | owner 双钥匙动作（tag/push） | 下游升级、MS1 依赖的基座面定型；窗口 W2 末–W3 末（10-25 前） |
+| MS1 下游功能为零 | 下游开发未开始 | **当前真实关键路径**（W4=11-01，余约 3.5 周） |
+| O1/O3/O7 组织阻塞 | 评审会产出（权威文档树、标签字典、人选名单） | MS0' 退出条件；O3 阻塞 MS1 阶段映射 |
+| 库分期 N1 剩余、Q1/I1 未启动 | 基座演进 | MS3 一键生成与意图分层的前置 |
+| EXT-3 渠道未申请 | 基座扩展点（申请截止 W10 前） | MS4 飞书群入口 |
+
+### 2.3 现状复核（2026-10-08）
+
+本节为独立复核回填，不改写上文 10-07 快照。固定对象：`Agent-System-RDM` main
+`4feb2f0`（pins=四仓 v0.1.0 tag commit）。方法：`/tmp` 隔离克隆重放 + 归档任务卡与
+PR API 快照；一次性容器跑 PG 档。全部收据为 **SELF**（RDM 仓无 CI，不存在 GATE），
+收据与快照见 `docs/records/2026-10-08-rdm-status-*.json`。
+
+**§2.1/§2.2 逐行复核**：
+
+| 原（10-07） | 复核（10-08） | 证据 |
+|---|---|---|
+| EXT-1/EXT-5 已合入基座 main | 维持；但 **EXT-5 不在下游 pin**（pin=backend v0.1.0 `cb26e4c`，基座 main 已领先 83 提交） | `git submodule status` / `rev-list --count` |
+| 下游仓"种子可编译" | **已过时**：10-05~10-06 合入 103 个 PR、归档 51 张任务卡，P0–P4 各线均有首批实现 | 记录快照 pr_summary / cards |
+| v0.1.0 tag 已打 | 维持（五仓+RDM 六 tag 在位；RDM v0.1.0=`99bbf54`） | tag 核对 |
+| v0.2.0 未发版 | **维持，且为当前关键路径**：六仓远端均无 v0.2 tag（窗口 10-25 前，owner 双钥匙） | `ls-remote --tags` |
+| MS1 下游功能为零 | **失效（最严重失实）**：MS1 工作项大半已有首批——R1-2 骨架、R1-6 两速+SSE+工作台、R1-8 异步、R1-9 审计、D8 烟测、MS1 验收载具（`-ms1`）、R1-1 文档树/模板/提示词注册表大部、R1-3~R1-5/R1-7 的 F1 v1；P2（状态机/版本链/比对）、P3（追溯网/冲突/变更 UI/起草）、P4（周报/自举例程）各有超前首批 | 记录快照 cards 映射 |
+| O1/O3/O7 组织阻塞 | **已闭环**：RDM `docs/requirements/00-V2定稿决议.md`（10-06）——O1 以 ISO 13485 为主口径、O3 以种子字典为 v1（14 阶段/69 docTypes）、O7 owner 本人+系统外机制；P0 已关账（RDM #91） | RDM #89/#91 |
+| 库分期 N1 进行中、Q1/I1 未启动 | **已过时**：N1/Q1/I1/N2/N3/Q2/Q3/I2 全部合入 Dev main（转出项见 N1/Q1/I1 案 §7 回填） | 栈总案与阶段导航 |
+| EXT-3 未申请 | 维持（截止 W10 前） | proposals 目录 |
+
+**MS1 验收核对**（对 §4.2 七条；结论分级：满足=本轮重放通过 / 部分=能力在但有缺口 /
+未满足=该路径不通 / 口径不成立=判据无效）：
+
+| # | 条款 | 结论 | 证据与缺口 |
+|---|---|---|---|
+| 1 | 纪要+竞品 BP 60 秒出结论与初步归类 | **部分** | 真实纪要 0.78s 出回执（重放）；但判定=无关(疑似)零字典命中挂起，**无初步归类**；竞品 BP 无原件未测 |
+| 2 | 切片带标签锚点，笔记树视图可查 | **部分** | 标签+锚点在勾连卡可见（Linkage/Anchors）；独立笔记树视图未实现（web 无对应视图；领域 `NoteTree.Query` 存在但无 UI 消费） |
+| 3 | 无关文件存疑挂起，确认前不入库 | **满足（重放）** | 无关 txt→held；卡内挂起重启存活、reject 零切片测试 |
+| 4 | Excel/PPT 解析完整性；失败显式告知+原件可取回 | **阻塞** | 报价单 xlsx/构造 pptx→`rdm:unsupported`+留档；损坏 docx 显式告知+留档（负例路径满足）；xlsx/pptx 解析依赖 EXT-5，**不在 v0.1.0 pin**——需 v0.2.0 发版+RDM 升钉+上传链切 Host 解析 |
+| 5 | 阶段映射准确率 ≥80% | **口径不成立** | `-ms1` 报 100%（重放 PASS）但金标 `ms1Gold` 与自举打标 `docProfiles` 同表同源（代码注释自认），样本 5 文档全 BD 阶段；上传路径实测纪要零命中——准确率未经有效测度 |
+| 6 | 页面/对话双入口同源 | **未满足（钉入组合）** | 命令入口 200；对话入口发 `/rdm.ping` 得 400"未知命令"（插件命令注册不写 slash 别名，v0.1.0 与基座 main 同）；RDM 未声明 intents；另发现工作台 `sendChat` 调 `/api/chat`——该端点在 v0.1.0 pin、基座 main、RDM 三处均不存在（自由文本 404） |
+| 7 | PG 多用户档身份贯通 | **满足（重放）** | 一次性 PG 容器重放 pg-smoke：alice/bob 审计与知识各 1、零串号；multi-smoke 跨实例扇出+Redis 限流 PASS |
+
+**MS1 整体判定：部分满足，不可签收**。关键路径从"下游从零开发"变为：v0.2.0 发版
+（双钥匙）→ RDM 升钉 → 上传链切 `Host.ParseDocument`（第 4 条）；对话入口路由插件
+命令（第 6 条，需基座侧动作）；准确率金标独立化重测（第 5 条）；笔记树视图补齐（第 2 条）。
+
+**新缺口登记**（本轮只登记不修复；逐项带证据、影响、建议承接与归属）：
+
+| 缺口 | 证据 | 影响 | 建议承接 | 归属 |
+|---|---|---|---|---|
+| 插件命令无 slash 别名，对话入口不可达插件命令 | entrance2 收据（400/200 对照）；`cmdbus.RegisterPluginCommand` 不写 `b.slash`（v0.1.0 与基座 main 相同） | MS1 第 6 条、R3-6 四入口同源 | 基座侧：扩展申请或并入既有 EXT 案（含 intents 命中插件命令的路由） | weichen |
+| RDM 工作台自由文本端点错误（`/api/chat` 不存在） | entrance 收据 404×2；基座前端实际用 `/api/conversations/{id}/messages` | 工作台自由文本路径不可用 | RDM 侧小任务（改端点） | weichen |
+| INV-2 可退化机制未实现（装载开关、禁用态 e2e、基座领域词守护均无） | 两侧 grep 零命中；成因：RDM 10 号 V1.2 定稿（10-05）早于本总案 INV-2（10-07） | §3.2 判定四条均 NOT_RUN | 下游任务（开关+禁用态 e2e）+ 基座守护另行立项 | weichen |
+| 阶段映射准确率无有效测度（金标同源、样本全 BD） | `ms1.go` ms1Gold vs `bootstrap.go` docProfiles 对照 | MS1 第 5 条、MS2 质量基线 | 独立金标集+多阶段样本重测任务 | weichen |
+| RDM 仓无 CI | 仓内无 `.gitea/workflows`；PR status API 无 statuses | INV-3 的 GATE 来源不存在，下游证据止于 SELF | RDM 仓接 act_runner（同基座模式） | weichen |
+| 22 张归档卡「结果与验证」段为模板占位 | grep 模板串 22 命中；结论写在 PR 描述（抽样 6/6 含验证） | 台账完整性 | 低优先：随下一批 RDM 任务补齐或接受现状 | weichen |
+
+本节维护规则：状态再变化时先更新本节（或其后续修订版），并同步索引导航；
+复核不等于里程碑验收，MS2–MS4 的正式验收仍按 §4 各自条款执行。
+
+---
+
+## 3. 架构裁定
+
+### 3.1 二次开发的承载形态（三级，主辅保留）
+
+| 级 | 形态 | 用在哪 |
+|---|---|---|
+| A 进程内编译（主） | 下游仓 import `pkg/extension` + core，实现 EXT-1 `Handler` 命令处理器、`Host` 句柄消费（KV/audit/llm/knowledge search+write(embed)/tasks 台账/artifacts）、页面 SDK | RDM 命令（上传管道、入库、生成、变更）、知识写入、结构事件日志、页面 |
+| B 声明式规格（辅） | intents / workflows / skills / 页面规格文件，插件目录装载 | RDM 意图（闲聊/澄清/取消等命令层消费）、流程骨架 YAML、技能 |
+| C sidecar（保留） | 独立进程，经命令总线/工具被调 | 格式解析器（office/xlsx 深解析）、EXT-3 渠道执行体 |
+
+**裁定**：能用 A 就不用 C；解析器默认走「sidecar 工具或 LLM 抽取」，EXT-4（进程内解析器注册）不提交（愿景 10 §1.5）。
+
+### 3.2 可退化机制（INV-2 的工程形态）
+
+**装载开关**：RDM 插件的一切装载点——命令 Handler 注册、意图 spec、工作流定义、技能目录、页面路由、卡片投影——收在一个开关下（建议设置键 `plugins.rdm.enabled`，默认开启；缺省/禁用 = 通用基态）。禁用语义是**装载期跳过**，不是运行时逐点判断：装载器在开关关闭时不注册任何 RDM 项，路由自然回落到基座既有 fallback（普通回合）。
+
+**通用基态的判定**（机器可核对）：
+1. 禁插件启动后，通用场景 e2e 全绿（对话、工具、工件、卡片、HITL、工作流 demo 插件）——复用 backend 现有 e2e 套件在禁用态重跑；
+2. RDM 命令返回未知命令、RDM 页面 404、收件箱无 RDM 投影卡；
+3. 基座仓 diff 检查：任何 PR 的基座改动不含 RDM 领域标识（词表黑名单进 design-guard 类守护，或评审核对项）；
+4. 数据共存：禁用不触发任何删表/删数迁移；重新启用后 RDM 视图恢复原状（下游测试覆盖）。
+
+**测试形态**：下游仓测试套件固化「禁用态 e2e」一项；基座 CI 天然成立（基座不依赖下游，永远可独立构建测试）。
+
+### 3.3 扩展点申请流程（缺口 → EXT）
+
+下游发现基座面缺口时的唯一合法路径（愿景 10 §七.1）：
+
+1. 下游在任务卡里写明缺口（要的符号、语义、阻塞什么里程碑）；
+2. 基座侧建 EXT 申请卡 → 评审（是否属于通用能力、SurfaceVersion 影响）→ 基座实现并随下一段发版（v0.2.0 之后按 v0.3.0/v0.4.0… 节奏，同样走 12 号清单核对）；
+3. 下游升级动作：pins bump + go.mod replace 切回 tag pin（合入前必须切回，愿景 13）。
+
+已在案的扩展点：EXT-1（已落地）、EXT-3（渠道，W10 前申请，阻塞 MS4）、EXT-4（备选，默认不提交）。预计 MS1–MS3 期间可能出现的新需求（知识写入完整集、页面 SDK 增补、审计结构事件扩展）按本流程逐案评审，不预设全部进基座。
+
+### 3.4 数据模型落地裁定
+
+- 两树一网（笔记树/文档树/追溯网）在下游自建库表、schemaVersion 自管迁移（D-R1 选 A，愿景 10）；基座 core 不加领域实体。
+- **R3-1 结构事件日志最先做**（愿景 10 §五：「追溯网地基」，SR-G5 五硬规则：原文 append-only、软删除、边候选→生效→废止、统一结构事件日志、时间点可重建）。裁定：下游自管事件日志与重放，基座通用审计接口（`Host.Audit`）只写动作审计，不为结构追溯进基座。
+- 标签字典是两树唯一接口语言（愿景 08 §四）；字典实体为项目级资产、版本化，住下游；其字段集与取值枚举依赖组织项 O3，MS1 前先以草案字典起步（见 §5 风险 R-1）。
+
+---
+
+## 4. 阶段方案（里程碑对齐）
+
+每阶段给出：下游工作项 / 基座支撑项 / 组织依赖项 / 验收（机器可核对）。编号 R 沿用愿景 10。
+
+### 4.1 阶段 P0：MS0' 收尾与发版（W1–W3，当前窗口）
+
+- 下游：R0 奠基——文档树模板注册表骨架（阶段→文档→章节）、UR/SR 条目化导入需求大表雏形、建仓自检（`go test .` + link 构建）随仓常驻；奠基文档（方案 10）已就位。
+- 基座：v0.2.0 发版（owner 双钥匙，按愿景 12 清单：core 三处同 SHA、五仓 tag 指向一致、tag 消息固定文案）；N1 合入链走完（Agent-Native #17 → Backend #69 → Dev gitlink PR）并完成 N1 剩余（WP1 AgentSpec、WP4 guardrail、WP5 下沉、WP6 装配与 A/B）。
+- 组织项（MS0' 退出条件，非代码）：01 升 V2.0 定稿；O1/O3/O7 决议闭环；D-R1/D-R2 决议在案；EXT-1 申请卡已受理（已合入可视为闭环）；code review 机制首运行台账。
+- 验收：v0.2.0 五仓 tag 就位且指向一致（命令：各仓 `git tag` + Dev gitlink 比对）；N1 三段 PR 合入且 CI 绿；下游种子构建通过。
+
+### 4.2 阶段 P1：上传五步法 + 两速入库（W4 = MS1，11-01）
+
+上传五步：接入 → 相关性判定 → 结构化解析 → 阶段映射与标签 → 两速入库（愿景 03 F1、04 T1-x、10 §三）。
+
+| 工作项 | 内容 | 承载形态 |
+|---|---|---|
+| R1-1 上传接入 | 复用基座工件/上传端点；渠道记录（SR-A3）留 P1 后 | A（下游命令） |
+| R1-2 相关性判定 | 三态（相关/不相关/存疑），存疑挂起确认前不入库（SR-B1） | A |
+| R1-3 结构化解析 | 拆解为切片：原文锚点 + 结构化字段；office 深解析走 sidecar 工具或 LLM 抽取（EXT-4 不提交） | C 辅 |
+| R1-4 阶段映射与标签 | 按标签字典映射阶段/工作事项/主题簇，生成标签 JSON（M3 schema）；字典草案先行，O3 闭环后替换 | A + 字典资产 |
+| R1-5 两速入库 | **快通道**：60 秒首轮反馈——标签、锚点、一句话摘要即时可见；**慢通道**：向量与深度补齐异步走 EXT-1 `KnowledgeWrite(embed)` 句柄（意图分层「快规则/慢模型」之外产品的第二条快慢线） | A（慢速经 EXT-1 句柄） |
+| R1-6 入库完整性 | 失败显式告知、原件可取回、禁静默降级（SR-A5）；三类负例（报价单 Excel/图文 PPT/构造解析失败）回归 | A + 测试 |
+
+- 基座支撑：v0.2.0 已发版（前置）；`Host` 完整集（含 artifacts 写入）如 MS1 实测不足，走 §3.3 申请进 v0.3.0。
+- 验收（对齐愿景 10 §三 7 条）：上传五步法端到端跑通（三类真实文件）；60 秒首轮反馈实测；存疑挂起确认前库中无记录；标签+锚点在界面可见；SR-A5 三负例回归；**SR-E6 双入口同源早期证据**（页面/对话两个入口同一命令处理器实测）；PG 多用户档身份贯通烟测（D8）。
+
+### 4.3 阶段 P2：基线 + 三分类 + 版本链（W7 = MS2，11-22）
+
+- 下游：文档状态机（草稿→评审中→已基线→变更中→新版本）；三分类比对引擎（新增/更新/冲突）；版本链可溯；基线直改被拒；缺项提示只在评审/推进两触发点出现（SR-C5，上传节点禁止）。
+- 基座：无新需求预期；卡片/HITL 复用。
+- 验收（10 §四 R2-1~R2-5）：状态机迁移合法集测试；三分类对同一文件两版比对正确分类；版本链从任一章节回指到切片锚点；基线直改返回结构化拒绝；上传节点界面无缺项提示。
+
+### 4.4 阶段 P3：两树一网 + 变更闭环 + 一键生成（W11 = MS3，12-20）
+
+| 工作项 | 内容 | 依赖 |
+|---|---|---|
+| R3-1 结构事件日志 | **最先做**：SR-G5 五硬规则全落地；时间点可重建（事件重放 + 周期快照） | 无（下游自管） |
+| R3-2 追溯网 | 切片↔需求↔章节↔法规↔用例 有向边；模型候选边人工转正 | R3-1 |
+| R3-3 需求大表 | UR/SR 版本化条目；变更风险提示 | R3-1 |
+| R3-4 变更闭环 | 检测→影响分析→变更单七步→回写留痕；影响已基线内容的结构变更强制走变更流程 | R3-2 |
+| R3-5 一键生成 | 编写意图确认→小队骨架执行→逐节标源（无素材明示空缺不编造）；一拉一推（章节条件检索笔记树 / 切片标签映射文档树） | **基座 Q1/Q3、I1**（小队骨架与意图命令化）；标签字典 |
+
+- 基座支撑（**最迟合入窗口：W9 末**）：Q1 图执行合入、I1 命令化合入（退化路径：R3-5 先用流程骨架 YAML + 现有小队 standard 模式实现，不强等 Q3 编排收敛；该降级在愿景 03 F4 允许范围内，需任务卡明示）。
+- 验收（10 §五）：结构事件日志对两树一网增删改全程留痕且可重建指定时点；变更七步闭环跑通一次真实变更；一键生成产出的每个章节带切片级来源标注，无素材章节明示空缺；追溯链报告可导出。
+
+### 4.5 阶段 P4：自举与演示（W16 = MS4，2027-01-24）
+
+- 下游/联合：自举 B1–B7（元项目常驻 → 纪要入库 → 本批文档入库 → UR/SR 全部进需求大表 → 一句话生成自身可行性报告 V1 → 用系统管本计划执行 → 每周复盘）；EXT-3 渠道（飞书群收文件/推送，申请截止 W10 前，基座实现随当段发版）；测试群反馈闭环率 ≥80%。
+- 基座支撑：EXT-3（W10 前受理）；N2/N3/Q2 按实际拖累点排期；I2 语义端口（意图慢通道）如被意图误触发率卡脖子则提前。
+- 验收：自举项目全程在系统内运行（纪要入库→可行性报告→追溯链导出，无系统外补录）；反馈闭环率统计达标；owner 认定可对外演示。
+
+---
+
+## 5. 风险与缓解
+
+| # | 风险 | 缓解 |
+|---|---|---|
+| R-1 | MS1 时间紧（余约 3.5 周）且 O3 标签字典是组织阻塞 | 字典草案先行（下游资产、可迭代）；O1/O3/O7 列入 MS0' 评审必须产出的一句话（愿景 11 阻塞项表），评审前下游不赌字典内容 |
+| R-2 | 一键生成依赖基座 Q1/Q3 进度 | 设 W9 末最迟窗口 + 降级路径（YAML 骨架 + standard 模式，§4.4）；库分期优先级因此把 Q1 排在 N2/N3 之前 |
+| R-3 | 可退化不变量被侵蚀（领域逻辑渗入基座） | INV-2 的装载点集中 + 禁用态 e2e（下游常驻）+ 基座 diff 领域词黑名单检查（进评审核对项，必要时落 design-guard 类守护） |
+| R-4 | 双仓 pin 漂移 / replace 忘切回 tag | 愿景 13 规则进下游 AGENTS.md；基座 R0 检查脚本已核对 backend deps 与 Dev 指针；下游 pins 自检进 CI |
+| R-5 | EXT 申请节奏跟不上下游需求 | 缺口提前在任务卡登记（§3.3 第 1 步），发版节奏按里程碑倒排（v0.3.0 对准 MS2/MS3 之间） |
+
+## 6. 不在本方案范围
+
+- 医院端产品与行业输出的远期步（愿景 02 §7 路径第 ③④ 步）。
+- 模型无关性的完整抽象（SR-N5，P2 远期）；token 成本测算口径（待组织认可，愿景 11 #14）。
+- 微信等飞书以外的渠道（前瞻）。
+- 下游仓内部的详细任务分解（本方案是总案；下游按 §4 的阶段在 RDM 仓立各自任务卡，引用本文）。
+
+## 7. 验收（本文）
+
+- 大方向与三条不变量（INV-1/2/3）表述无歧义，可落成检查项。
+- §4 五阶段与愿景 10 §10.1 里程碑逐条映射；每阶段验收均为机器可核对形式；组织项与代码项分列、不混淆。
+- 可退化机制（§3.2）给出判定与测试形态，能直接派生下游测试任务。
+- 与既有方案无冲突：库分期按 2026-10-07 N1/Q1/I1 方案继续；本文只在其上排布消费者与窗口。
@@ -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）。
@@ -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 推翻，以本文为准）。
@@ -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 | 升（加字段） |
@@ -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 全量随卡保存）。
+
@@ -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 评审，部署仍不在本轮范围。
@@ -0,0 +1,253 @@
+---
+title: 多人协作存储与分布式演进方案 - Plan
+type: refactor
+date: 2026-10-11
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# 多人协作存储与分布式演进方案 - Plan
+
+修订：r2.3；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：U1–U7 **代码与测试已合入**（Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164)；Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442)；闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等）。正确性 A1–A7 与 B1 已绿（CI/SELF）。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**（见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)）。2026-10-12 用户决定不做容量重放；同日 B6 pgbench、C4 断连、C5 库恢复已有本机 SELF（见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)）。2026-10-13 未配置对象存储时的上传 panic 已修，C5 工件恢复 K4 重测为 SELF 通过。**SELF≠GATE/REPLAY**，双主机 C3 未做——**仍不放行第二实例承接写请求**。
+需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-13（Asia/Shanghai）。
+关联任务：方案与 U1–U7 实施卡已归档；容量收尾见 Dev `.task/feature-u7-capacity-wrap-measure.md`。放行检查单：Dev `docs/release-multi-instance.md`。
+正文中的源码路径以 Agent-System-Dev 为根；工作包中的 `internal/` 简写指 `modules/backend/internal/`；文内相对链接以本文为根。
+
+## 1. 推荐结论与边界
+
+团队部署以 PostgreSQL 作为共享业务状态的唯一权威，pgvector 承担数据库内向量查询，Redis 承担可丢失的缓存与限流。SQLite 保留给个人嵌入式使用、离线工具及可以重建的本机状态，不承载团队共享写入或跨主机运行所有权。
+
+第一阶段交付单应用实例的可靠团队部署；第二阶段补齐执行所有权、持久命令、共享工件与事件追赶，再开放多个应用实例和 Worker。通过接口和数据归属为服务拆分做准备，当前不要求微服务化、Kubernetes、分片或引入另一套消息中间件。
+
+“不会出现错误”不能成为无条件承诺。工程目标是：在定义的故障模型下，不静默丢失已确认数据、不覆盖他人的并发更新、不产生未经识别的重复副作用、不越权；异常可发现、可追踪、可恢复。冲突可以返回明确的 409，超载可以返回 429，依赖故障可以返回 503，它们必须有清楚的重试语义。
+
+本方案是[双档存储 D17–D24](2026-09-30-dual-tier-storage-and-multitenancy.md)的候选增补，批准前不改写原已采纳决策。拟调整的是团队部署的默认与必需条件，以及 D24 原来排除的跨实例执行能力；保留个人 SQLite 档、非容器部署、现有检索契约与序号语义。
+
+## 2. 当前事实与差距
+
+源码调查基线：Dev `73c901fa341a3653d6e0826d0da3497507995482`，Backend `eda90ed310f37f7352e24a8096d932dbf320cd73`，Documents `9a46785ee0f19540c79f83b4e4544572b5217ac2`，Agent-Squad `490b0b2dfa1567cb16ff7a7230fd78e52bc2938e`，Agent-Native `c348441691e8bdab784a03aa9be64d53dacff341`。
+来源均为 **SELF·源码/本机只读观察**；没有真实并发故障重放。命令、对象 SHA 和原始输出见[调查收据](../records/2026-10-11-collaboration-storage-audit-receipt.json)，启动收据见任务卡。
+
+| 对象 | 当前可核实事实 | 方案含义 |
+|---|---|---|
+| Dev 运行实例 | `runtime/dev/bin/agent-system`、8788 端口打开 `runtime/dev/data/agent-system.db` 及 WAL；二进制 build revision 为 `017b40f76156905eabe8323ae2bfe800f47fb8bd` | 当前服务确实使用 SQLite；运行版本与上述源码基线不同，源码缺陷不冒充已在该二进制重现 |
+| 本机安装 | Homebrew 列出 PostgreSQL 18.6、pgvector 0.8.7、Redis 8.10.2 | 仅证明安装；目标 PG 实例、目标库扩展启用、角色与可用性未验证，不据此批准切换 |
+| Backend 存储 | `internal/app/app.go:105` 按 DSN 选 PG，否则 SQLite；`store/store.go:50` SQLite WAL、busy_timeout=5000、单连接；PG 池固定 16/8 | 无需重写全部存储层；需团队档显式配置、连接预算和真实 PG 测试 |
+| 已有一致性基础 | `store/dialect.go:49` PG 事务咨询锁；消息 seq 唯一约束、requestId 去重和 HITL 条件更新 | 保留并扩展，不把已有能力列作全新建设；这些能力不等于跨实例运行互斥 |
+| Run 所有权 | `runmgr/runmgr.go:1113` 用进程内 map 占用会话；`store/messages.go:120` 直接创建 run | 两实例可能各自认为空闲；需共享占用和有效执行代次 |
+| 取消与审批 | `runmgr/runmgr.go:1326,1422` 依赖本实例 active 句柄；HITL 先落卡，再查句柄 | 请求落在非执行实例时存在命令不生效或卡已处理但执行未被唤醒的风险 |
+| 跨实例事件 | `pgbus/pgbus.go` 每批通知末 seq，Listener 只 `EventAt` 取末条；断线后对原连接继续 Wait | 静态可见批内中间事件遗漏及重连缺口；`server/server.go:376` 的 SSE 重放/去重不能修复已越过的游标 |
+| schema 迁移 | `store/migrate.go:migrate` 每次 Open 执行迁移；DDL 事务提交后另行插入迁移版本 | 并发启动与两步间崩溃存在风险；切 PG 前先改为单迁移入口与原子版本登记 |
+| 向量查询 | `store/vectors.go` 读取 BYTEA，应用内计算余弦；`migrate.go` 未把向量列建成 pgvector 类型 | 安装 pgvector 不代表启用；复用 RRF 管线，分阶段改为数据库 top-k |
+| Redis | `ratelimit/ratelimit.go:65` 独立 INCR/EXPIRE，EXPIRE 错误未处理；请求异常默认放行；app 默认限额 0 | 当前只是可选共享限流，需原子窗口、鉴权/TLS配置、容量保护与可观察的降级 |
+| 本地文件 | `blobstore` 默认本地目录；Backend Squad 入口未传 Store，回落 FileStore；checkpoint 写 `.agentx/checkpoints.jsonl` | PG DSN 不会迁走这些状态；工件、执行工作区、checkpoint 要分别处理 |
+| 独立 Squad | 独立 CLI 使用 `adapters/sqlite/runstore.go` 的 `orchestration.db`；这不是 Backend 实际接线 | 不把迁移该 SQLite 文件当作 Backend 分布式改造完成 |
+| 验证 | PG/Redis 集成由 `AGENT_PG_TEST_DSN`/`AGENT_REDIS_TEST_ADDR` 控制；当前 CI YAML 没有显式准备这两种服务 | 缺变量会跳过关键测试；CI 通过不能自动证明真 PG/Redis 或双进程链路通过 |
+
+已有规划衔接：Q1 已记录 Store 收敛但仍留 platform→squad 队列桥接等余项；N3 原案与归档卡的 JournalOnly 落地不同，应以当前接线确定权威。共享权限沿用 EXT-8 授权适配器与 RDM 的成员/角色职责，不新建第二套成员模型。历史报告用于定位，不能替代当前验收。远端调查发现 Backend [#135](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/135) 正在增加 S0 工作区 overlay/frozen base/CAS apply；U5 必须复用并核对其契约，不能另造冲突的工作区实现。该 PR 尚未作为本案已合入依赖。其他被查仓当时未返回 open PR，详见收据；实施启动时重新核对。
+
+## 3. 需求与可判定结果
+
+| ID | 需求 | 优先级 | 验收条件 |
+|---|---|---|---|
+| R1 | 支持 10–100 人、多项目、多会话并行 | P0 | 在固定环境与下述负载下完成真实业务链路；容量结果绑定组件 SHA、配置和数据集 |
+| R2 | 团队数据有唯一共享权威 | P0 | 团队档无有效 PG 配置或连接失败时拒绝就绪，不自动建立本地 SQLite 继续服务 |
+| R3 | 并发提交和编辑不静默覆盖 | P0 | 同 requestId 返回同一逻辑结果；同版本竞争写入最多一个成功，其余明确冲突；不同会话并行 |
+| R4 | 跨实例运行与命令可恢复 | P1，多实例前置 | 同会话主 run 单一有效 owner；旧 epoch 写入拒绝；任意 API 实例取消/HITL 均到达执行者 |
+| R5 | 事件有序、可追赶 | P0/P1 | 批处理、掉通知、重连和慢消费者后可按游标补齐全部已提交事件；不因收到末 seq 而跳过中间事件 |
+| R6 | 项目权限在所有数据入口一致 | P0 | 读取、写入、SSE、检索、下载与工具入口均校验当前授权；撤权后的新请求无泄漏 |
+| R7 | 数据和运行状态可恢复 | P0 | SQLite→PG 演练无遗漏；备份恢复含文件与权限映射；未知副作用停在可见恢复状态，不盲目重试 |
+| R8 | 高负载下有界且可观察 | P0 | 队列、活跃 Agent、DB 连接、工具/模型请求都有上限；超载行为、等待时间和错误分类可观测 |
+| R9 | 向量检索随数据增长扩展 | P1 | 数据库 top-k 与原精确基线对照；授权过滤正确；模型/维度/版本不混用；ANN 有召回率与延迟证据 |
+| R10 | 支持未来多服务部署 | P1/P2 | 先验证两个真实 API/Worker 进程共享服务；业务表有模块 owner，后续服务通过契约操作他方数据 |
+
+R1 的人数及未来分布式方向由用户确认；下列量化指标是**建议的验收合同，待批准，不是当前性能结论**：
+
+- 基准环境建议：Linux、8 vCPU、32 GiB RAM、NVMe，记录 PG/应用的实际配额与网络；两实例验证分为同机多进程和后续双主机两种证据。
+- 阶梯负载：10→30→100 在线用户，最多 300 SSE 连接；初始全局活跃 Agent 执行预算 20（包含子代理）、每用户 2、索引任务 4。待执行队列最多 200，按用户/项目公平分配。已接纳 run 数与实际执行许可分别计数；父 run 等待子代理/HITL 时让出执行许可、保留会话所有权，恢复执行须重新获许可，避免额度用尽时父子互等。以上阈值由实测调整。
+- 数据量建议：100 万条消息/事件量级、10 万知识分块、多个项目与交叉授权用户；另测 100 万分块扩展档。记录数据分布与热点，不能只测空库。
+- 非模型普通 API：P95≤300ms、P99≤1s；SSE 持久事件可见延迟 P95≤1s；非预期失败率≤0.1%。预期限流/冲突单列，不能排除后不报告。
+- 先跑 60 分钟稳定负载，再跑 2 小时混合长稳；持续记录实际成功吞吐、排队、CPU/内存/IO、连接等待和模型配额。模拟模型用于容量基线，另保留真实模型少量全链路验证。
+- 数据正确性不变量在全部测试中零违反。数据库/Worker 故障恢复建议 RTO≤15 分钟；灾难恢复建议 RPO≤5 分钟、RTO≤60 分钟。主机/存储全毁不在单机“零丢失”承诺内；若要求该场景 RPO=0，需另行批准同步复制、故障域与可用性取舍。
+
+## 4. 技术决策与目标结构
+
+KTD1. **区分 local 与 team 部署档。** local 保留 SQLite；team 强制 PG、认证、独立实例 ID、受控工具执行和启动诊断。PG 暂时不可用时返回未就绪，不切回 SQLite。个人档不因浏览器人数变多而自动升级。
+
+KTD2. **PG 保存持久业务与调度事实。** 用户/项目/会话/消息/卡片/运行/幂等记录/命令/事件/checkpoint 元数据以 PG 为准。Redis 不成为任务完成、审批通过或永久幂等的唯一证据。初期使用同一 PG 实例和有归属的逻辑表/角色；后续拆服务时明确表的唯一写入模块，避免所有服务无约束共享整库。
+
+KTD2 的全部状态收敛以 U5 完成为界；此前有明确的单实例过渡边界，不能提前把本地状态当成缓存：
+
+| 数据 | 首期单实例团队版 | U5 后多实例版 |
+|---|---|---|
+| Backend 业务记录、幂等与恢复隔离标记 | PG 权威 | PG 权威 |
+| 尚未改造的 Squad FileStore、checkpoint、续跑标记 | 唯一实例的本地权威文件，联合备份，禁止跨机接管 | 版本/归属元数据在 PG，大内容在共享对象存储 |
+| 工件 | 本地对象目录，持久备份与 DB 清单绑定 | 共享不可变对象与 PG 发布记录 |
+| 临时执行目录 | 单实例/单 owner；先分类再清理 | owner+epoch 控制的可恢复工作区 |
+
+KTD3. **一个会话一次主执行，不同会话并行。** 推荐独立 conversation_execution 占用行，以 owner/会话唯一键、run_id、epoch、lease_until 约束；不对所有 runs 加“会话唯一”，以免禁止正常子代理。事务内完成权限检查、请求幂等、消息、主 run 和调度记录，接收成功以事务提交为准。
+
+KTD4. **短事务领取，租约与 fencing 配套。** Worker 通过 PG 行锁和 SKIP LOCKED 领取到期任务；事务提交后执行，模型/工具等待不得持有数据库事务。续租、事件追加、checkpoint、终态写入都校验 run+epoch。租约用 DB 时间，执行实例 ID 与每次启动的 generation 分开。旧 Worker 恢复后不能提交；租约过期也不等于外部命令已经停止。
+
+KTD5. **持久命令与提交事件同事务。** 取消/HITL/调度命令写入 PG inbox/outbox，带唯一 command_id、逻辑 run、执行代次与处理状态。运行级取消意图交给当前 owner，即使接受后发生接管也不能丢失；HITL 绑定稳定 gate_id+gate_version，新 owner 消费时重验 gate 与权限，过期审批明确拒绝而不静默丢弃。执行结果及确认仍须校验当前 epoch。批准数据与待投递命令原子提交，执行者幂等消费，处理确认与执行效果分别记录。关键外部动作必须有目标端幂等键、可查询凭据或人工恢复路径；超时结果未知时进入 recovering，不宣称任意工具 exactly-once。
+
+KTD6. **事件表是重放依据，NOTIFY 仅作唤醒。** 事件提交与 outbox 同事务；需要时在同事务使用 pg_notify。监听端维护每流连续 cursor，从 EventsAfter 分页追赶到通知水位；不能直接跳到末 seq。重建连接→LISTEN 生效→补查水位/积压，再转实时。增加周期补查，覆盖通知丢失、断线与通知前后竞争。只有落库事件才能发布可恢复的 SSE ID；纯瞬时进度明确可丢失，不冒充已确认业务数据。
+
+KTD7. **数据库乐观并发控制。** 项目设置、卡片、文档元数据等读改写带 version/expected_version；冲突返回 409 及新版本引用。重要唯一性/外键落在数据库，事务失败按错误类型有界重试整笔事务；提交结果未知先按幂等键查询。不能无限重试模型调用或发送动作。[PG 事务隔离与重试](https://www.postgresql.org/docs/current/transaction-iso.html)。
+
+KTD8. **数据库迁移独立于普通启动。** 单一 migrator 取得数据库锁，执行 append-only 版本；可事务化 DDL 与版本登记同事务。应用仅核对兼容版本和就绪状态。不能放入事务的在线索引变更单列可恢复运维步骤，不夹入普通迁移后声称原子。使用扩展→回填→切读写→收缩，保留兼容窗口。
+
+KTD9. **工件共享，工作区有执行 owner。** 先保留 blobstore 接口；跨主机上线前实现并验收 S3 兼容对象存储，DB 保存不可变对象键、校验和、版本与就绪状态。发布前先完整写对象再提交引用，失败孤儿可清理；删除采用标记和延迟 GC。工作区、检查点与 Squad 状态分开设计：checkpoint/调度版本入 PG，大内容入对象存储，本地工作区是受 owner/epoch 控制的暂存执行目录；需要接管时按清单恢复。共享目录和文件 rename 不能替代跨机所有权。
+
+KTD10. **Redis 只保存可恢复的加速状态。** 保留共享限流，改为 Lua 原子计数+过期或等价原子算法，键包含实例群/完整时间窗/owner，支持 ACL 凭据/TLS、连接与请求超时。故障时普通读取可降到本地保守限流；创建 Agent/昂贵工具等写入口仍受 PG admission 硬预算保护，不能无界放行。缓存带授权/内容版本，撤权同步失效或重新校验；先证明命中收益再加缓存。[Redis INCR 限流模式](https://redis.io/docs/latest/commands/incr/)、[分布式锁限制](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/)。
+
+KTD11. **pgvector 按“正确→测量→ANN”推进。** 复用现有全文+RRF+可选 rerank，先补 embedding profile/model/revision/dimension/content_hash/generation 身份，禁止同维不同模型混查；迁移为 vector 列并在 PG 做过滤和精确 top-k，再用基线对照决定 HNSW。权限适配器不能直接变成 SQL 时，由适配器提供受限授权候选集合或采用有界分批取候选+最终实时鉴权，不得无界加载所有 owner 后在内存过滤。授权过滤后的召回率单独验证；ANN 需要迭代扫描/分区等策略时以模型维度和版本实测选择。[pgvector 官方说明](https://github.com/pgvector/pgvector)。
+
+KTD12. **先管理连接池，再决定 PgBouncer。** 使 MaxOpen/Idle/IdleTime/Lifetime、查询超时可配置并输出脱敏有效值；总连接预算包含所有 API、Worker、LISTEN、migrator、监控与维护预留。100 在线用户不等于 100 DB 连接。未来接 PgBouncer transaction pooling 时 LISTEN 必须使用直连或 session pool 独立 DSN，迁移也走直连，并验证 pgx prepared statement 配置。[PgBouncer 兼容表](https://www.pgbouncer.org/features.html)。
+
+KTD13. **共享可读不等于可写或可批准。** 当前 EXT-8 `ProjectAuthz` 是只读 bool 契约。U3 先列 read/edit/approve/execute/admin 的动作授权矩阵，复用下游角色，不另建成员权威；需要共享写入时以版本化公开契约扩展 action-aware 授权，旧只读适配器不得自动获得写入能力。未配置的动作默认拒绝，Host/工具/API 均走同一授权结论；审批职责分离仍由下游规则判定。SSE 发送后续数据、异步任务开始和工件下载时重新校验当前授权，缓存失效不承担唯一安全责任。
+
+KTD14. **迁移副本按原数据敏感级别保护。** 备份、导出、WAL、工件和测试副本使用专用角色及受限目录；传输与静态备份加密，解密材料保存在独立受管秘密存储并纳入恢复演练。日志/报告只留统计与哈希，禁止正文、令牌及密钥明文；测试使用脱敏数据。U1 固定保留期限、存放位置、访问者与清理责任，未知项阻塞正式导出。正式恢复演练同时验证凭据可用性与非授权者无法访问副本。
+
+```mermaid
+flowchart LR
+  U[10–100 用户] --> G[入口与认证]
+  G --> A[API 实例 A / B]
+  A --> P[(PostgreSQL + pgvector)]
+  A --> R[(Redis 限流 / 可重建缓存)]
+  P --> W[Worker 领取任务 / 持久命令]
+  W --> P
+  W --> X[受控工具工作区 / 模型服务]
+  W --> O[(共享对象存储)]
+  A --> O
+  P --> E[事件追赶 / 本地订阅]
+  E --> U
+```
+
+```mermaid
+sequenceDiagram
+  participant C as 用户
+  participant A as 任意 API
+  participant P as PostgreSQL
+  participant W as 执行 Worker
+  C->>A: 提交 requestId / expected_version
+  A->>P: 短事务：鉴权、幂等、占用、消息、run、任务
+  P-->>A: commit / 冲突
+  A-->>C: 已受理与 runId / 明确冲突
+  W->>P: 领取任务并取得 epoch
+  W->>W: 事务外执行模型与工具
+  W->>P: 按 epoch 提交结果与事件
+  P-->>A: 唤醒后按 cursor 补齐
+  A-->>C: SSE 已提交事件
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> queued
+  queued --> running: 原子领取并分配 epoch
+  running --> waiting: 持久 HITL
+  waiting --> running: 幂等命令消费
+  running --> completed: 有效 epoch 原子结算
+  running --> recovering: 失联或副作用结果未知
+  waiting --> recovering: owner 失效
+  recovering --> queued: 已核对可安全重试
+  recovering --> interrupted: 需人工处理或不可恢复
+  queued --> cancelled: 取消命令生效
+  running --> cancelled: 执行者确认停止
+```
+
+## 5. 实施顺序与工作包
+
+每个阶段评审后再进入下阶段；以下均为待批准计划，不因写入文档取得实施授权。新测试文件标“新增”；现有测试只作为扩展入口，本次未运行。普通基座改动在 Backend；公开持久接口确需变化时才同步 Native/Squad/Core，并由 Dev 固定组合测试，不全库改造。
+
+### U1. 冻结目标、数据归属与基准环境
+
+对应 R1/R2/R7/R8。先确定目标为 Dev 团队实例及其实际发布制品，记录脱敏配置来源、DB 实例/版本/扩展、数据数量与归属、文件清单、磁盘容量、峰值和恢复目标。RDM 独立业务库、旧 Agent-System 治理库另列，不能把一次 DSN 切换宣称覆盖它们。
+范围：`runtime/dev` 部署配置（实施时核对文件位置）、`modules/backend/internal/config/config.go`、文档运行手册。
+产物：固定部署清单、迁移映射、容量合同（区分接纳与执行许可）、隔离测试库/目录/端口方案、KTD14 的副本保护与保留合同；确认暂态 Worker 文件哪些可重建，哪些必须迁移。
+验收：仅操作批准的实例和测试资源；共享数据凭据不打印；未知 owner 或未定位的权威文件阻塞迁移。测试：脱敏配置诊断及缺项校验，业务压测依后续 U7。
+
+### U2. 团队 PG 档、迁移器与真实数据库门禁
+
+依赖 U1；对应 R2/R3/R7。修改 `internal/config/config.go`、`internal/app/app.go`、`internal/store/store.go`、`internal/store/migrate.go` 及 CLI；按 KTD1/KTD8/KTD12 实施。
+CI 增加隔离原生 PG/Redis 生命周期及明确必跑标记，固定组件/扩展版本；缺少真实测试服务时该 job 失败而非跳过。
+测试：扩展 `internal/config/config_test.go`、`internal/store/store_test.go`；新增 `internal/store/migrate_atomic_test.go`。覆盖 team 缺 DSN/PG 故障拒绝启动、local SQLite 正常、两个 migrator 竞争、DDL 与账本中间崩溃、旧 schema 升级、PG bool/时间/空 JSON/唯一约束与全文扩展。
+出口：真 PG 完整 CRUD/认证/会话/SSE/检索/卡片链路通过；仅该出口不宣布多实例安全。schema 变更的组合测试与业务迁移是不同动作。
+
+### U3. 请求原子性、版本冲突与受控容量
+
+依赖 U2；对应 R3/R6/R7/R8。修改 `internal/server/server.go`、`internal/store/messages.go`、`internal/store/cards.go`、`internal/cardsvc/cardsvc.go`、设置读改写及 `internal/runmgr`。收口 KTD3/KTD7 的事务边界；保留现有 seq 约束。按 KTD10 完成 Redis 原子限流、配置与异常策略；PG 记录共享 admission 预算。按 KTD13 完成动作授权矩阵与所需公开扩展的兼容计划；涉及共享编辑时 Core/Host 与下游适配器一起验收。
+先补最小持久恢复隔离：为未知副作用记录 recovery hold，`ResumeInterruptedChildren` 等所有启动续跑入口必须跳过，人工核对后显式解除。概念状态 recovering 可以先由独立隔离记录表达；扩展 Core 枚举时走公开契约版本，不假定当前已有此状态。完整租约接管留 U5。
+测试：扩展 `internal/server/admission_test.go`、`internal/ratelimit/ratelimit_test.go`；新增 `internal/store/admission_pg_test.go`、`internal/store/card_version_test.go`、`internal/runmgr/recovery_hold_test.go`。覆盖相同请求重放、事务部分失败、同版本竞争、动作越权、子代理预算计入全局、所有父 run 占满额度后同时派生仍能前进、未知副作用重启不自动续跑、队列满、Redis 断连/恢复/键过期。
+出口：单 API 团队模式达到不变量与有界行为；不会把 20 个 Agent 配置值当作已证明容量。
+
+### U4. 可切换的迁移与恢复演练
+
+依赖 U2/U3；对应 R2/R7。新增 `modules/backend/cmd/storage-migrate/` 或等价受管运维入口，明确只处理 Backend 库；不得直接执行 SQLite dump 作为 PG SQL。迁移实例以 migration_id、source_snapshot_id、source_schema_version 固定来源，记录表级完成与最终验证完成标记；仅同一冻结快照可续传，其他非空目标拒绝。迁移报告包括每表计数、主键映射、按主键分批规范化内容校验和、外键/owner/权限检查及工件哈希。
+测试：新增迁移工具的 `main_test.go` 与 `integration_test.go`，固定脱敏 SQLite 夹具覆盖全部当前 schema、布尔/空值/时间/JSON/Unicode/二进制向量/秘密字段、幂等重复导入、缺文件、未知 owner、断点重试及目标已含数据拒绝。
+操作顺序与回退见第 6 节。出口：隔离环境迁移与恢复验证完成，由用户批准窗口后才切正式服务。
+
+### U5. 执行所有权、持久命令与共享状态
+
+依赖 U3，团队现网切换不必等待整个 U5；对应 R4/R6/R7/R10。修改 `internal/runmgr`、`internal/store/recovery.go`、`internal/squadadapter`、`internal/runtime/squad_runner.go`、`internal/blobstore`；新增 Store 的 lease/inbox/outbox 与 PG RunStore 适配器。
+按 KTD4/KTD5/KTD9 设计 Native checkpoint 接口，继续支持 local 文件实现；不把 JournalOnly 日志误当作业务上下文权威。Worker 工具沙箱与访问范围沿用现有方向，在执行端检查当前身份和 epoch。
+测试：新增 `internal/runmgr/multi_instance_test.go`、`internal/store/lease_pg_test.go`、`internal/blobstore/object_store_test.go`；扩展 `internal/runmgr/recovery_test.go`。必须启动两个真实进程：同会话争抢、不同会话并行、跨实例取消/HITL、命令提交后消费前 owner 换代、旧 gate 的审批明确失效、Worker 被杀、旧 Worker 迟到结算/写事件/写文件、失联重连、副作用结果未知、文件缺失/重复发布。
+出口：所有写入和工具副作用的失效 owner 处理有实证后，才允许第二实例承接写请求；故障状态可见，不能仅靠粘性路由。
+
+### U6. 事件追赶与数据库向量检索
+
+U6 内分三个交付切片，稳定工作包 ID 不变：事件追赶/重连修复依赖 U2，可与 U3 并行；事务 outbox 与投递闭环依赖 U5；向量 schema 与查询改造依赖 U2 迁移器及 U3 授权合同。对应 R5/R6/R9。
+事件：修改 `internal/pgbus/pgbus.go`、`internal/runmgr/events.go`、`internal/server/server.go`、Store 事件接口。扩展 `internal/pgbus/pgbus_test.go`，新增 `internal/server/sse_gap_test.go`：批次 64 条全部可见、断线补齐、通知丢失、订阅与补查竞争、1000+ 分页、慢消费者、撤权后新事件拒绝。第一切片完成只证明追赶修复，不声称 KTD6 的事务 outbox 已就位。
+向量：修改 `internal/store/vectors.go`、`internal/store/migrate.go` 与现有知识索引管线；新增 `internal/store/pgvector_test.go`。验证模型身份/维度隔离、内容更新/删除原子性、回填中重启、索引未完成可降级、中文全文混合、共享授权后 top-k、撤权、与精确检索 Recall@10 对照（建议≥0.95，待批准）。索引构建不得拖垮前台连接/IO。
+出口：先验证正确与有界，再按容量结果决定 HNSW 与缓存；绝不以 extension 存在替代查询计划/召回证据。
+
+### U7. 压测、故障验收与分布式放行
+
+依赖 U2/U3/U4；双实例验收另依赖 U5/U6。对应全部 R。首期单实例放行必须完整重放现有入口的 R6 权限矩阵（含 SSE 后续事件、共享检索、下载、Host/工具与撤权），并证明 U3 恢复隔离；不能等 U5/U6 才验证这些 P0 要求。跨实例传播与接管的新增验证随 U5/U6。新增 Dev `tests/load/collaboration/` 与 `tests/integration/multi-instance/`，由隔离测试入口负责启动/回收自己创建的资源。
+按第 3 节负载合同和第 7 节矩阵测量，记录原始 k6/pgbench、服务指标与数据不变量；pgbench 只测数据库能力，不能替代业务 API/SSE/Agent 验收。正式测试不打生产服务。
+出口：单实例团队、双进程、双主机分别出具结果；CI 身份/链接/SHA 或独立 REPLAY 可核验才用于放行。本地 SELF 只能作辅助。变更智能体行为时补真实模型前后任务级对照。
+
+远期 P2：需求达到后再拆 API/Worker/索引服务，按表归属收紧角色；引入 PG 高可用与自动故障转移、对象存储冗余、可选 PgBouncer。服务拆分与 DB 复制是两件事；Redis 集群、读副本和缓存不能替代主库一致性，读后写敏感路径保持主库读取或显式一致性令牌。
+
+## 6. SQLite → PostgreSQL 切换和恢复
+
+1. 固定源服务制品、全部数据库/文件路径与目标空库；指定迁移 owner、窗口、可接受中断和回退判据。先做只读盘点与隔离演练，不接触其他服务的数据。
+2. 为 SQLite 做一致性备份（应用已有 Backup/VACUUM INTO 或官方备份路径），同时生成工件/checkpoint/工作区清单。活跃 WAL 数据库不能只复制 `.db` 文件；检查备份可打开且内容与清单匹配。
+3. 预演使用独立测试目标 PG，由 migrator 建 schema/扩展，再按依赖顺序导入。显式保留 ID、幂等键、事件 seq、哈希/秘密、用户归属、共享范围、审批状态，调整序列值和类型。预演库不成为正式目标；所有副本遵守 KTD14。
+4. 最终窗口暂停新写与调度，等待或安全收口在途 run；无法确认外部副作用的 run 写入 U3 的持久 recovery hold。停止全部旧写者后取最终一致性快照，导入新空正式目标；按 U4 的同快照迁移身份续传。全量对账与验收抽样完成并写入完成标记后才可切入口，保留只读源备份及过渡期权威文件。目标已服务或身份不同的非空库不得覆盖。
+5. 仅一个入口切到 PG，检查版本/配置指纹、库身份与数据归属，执行用户登录、项目、会话、审批、检索、下载的冒烟；应用 fail-closed，不能故障后回 SQLite。原库不再写，不使用临时双写制造两个权威。
+6. **PG 接受新写入前**可撤回切换，确认目标未产生业务写后恢复 SQLite。**PG 接受新写入后**禁止直接指回旧 SQLite；优先保留 PG 回退兼容应用或向前修复。确需反向迁移，重新冻结写者、导出 PG 增量、对账并批准专门回迁方案。
+7. 建立 pg_dump 逻辑备份，以及 pg_basebackup（或等价物理基础备份）+ 连续 WAL 归档/PITR，并与对象存储版本/清单联合恢复；pg_dump 不能用作 WAL 回放的基础备份，保留足够不可变对象。每次演练恢复到新目标，核对应用可用与权限/文件完整性，不能把“备份命令成功”当作可恢复。
+
+SQLite 本身支持可靠事务与多人经同一应用访问；WAL 提升读写并发，但同一数据库仍只有一个 writer，且不适合多主机通过网络文件系统共享 WAL。取舍基于写负载、进程拓扑、恢复与运维目标，不用“超过某人数 SQLite 就出错”的判断。[SQLite WAL 官方文档](https://sqlite.org/wal.html)。
+
+## 7. 最小验收矩阵
+
+| 场景 | 必须观察到的结果 | 对应 |
+|---|---|---|
+| 同 requestId 并发/网络超时后重试 | 一个逻辑请求和同一 run，不重做已经确认的副作用 | R3/U3/U5 |
+| 两实例同会话不同请求 | 仅一个主执行；另一个排队或明确冲突，子代理不受错误唯一约束阻断 | R3/R4/U5 |
+| 多项目并行、热点会话、满额度父子派生 | 公平、有界；等待父 run 不阻塞子 run 获得许可，所有任务能前进或得到有界拒绝 | R1/R8/U3/U7 |
+| 并发修改同卡/设置 | 成功与冲突可辨认，无最后写入静默覆盖 | R3/U3 |
+| 在 B 提交 A 所有 run 的取消/HITL，消费前换 owner | 命令持久、唯一消费；取消随逻辑 run 生效，HITL 重验 gate 版本，卡片与 run 最终一致 | R4/U5 |
+| Worker 崩溃/暂停超过租约后恢复 | 新 owner 可受控接管；旧 epoch 不能提交；不明副作用不自动重放 | R4/R7/U5 |
+| PG 断连/提交响应丢失 | 依赖不可用有界失败；恢复按幂等记录核对，不自动切 SQLite | R2/R3/U3 |
+| Redis 断连/INCR 后崩溃 | 不改变业务事实；昂贵任务仍受硬预算；恢复无永久计数键错误 | R8/U3 |
+| 批事件/断开 LISTEN/通知丢失 | 所有已提交事件按连续 cursor 追赶，重放不跳洞 | R5/U6 |
+| 撤销成员权限/跨 owner 猜测 ID | 新请求、流后续事件与下载/检索/工具均不泄漏 | R6/U3/U5/U6 |
+| 多模型向量/过滤后 top-k | 不混模型，权限正确，召回/延迟达批准阈值 | R9/U6 |
+| 迁移崩溃/坏文件/未知 owner | 阻止切换；重试不重复导入，不隐式公开历史数据 | R7/U4 |
+| 磁盘满/备份恢复/整机失效 | 清楚拒绝写入和报警；在约定故障模型与 RPO/RTO 下恢复 | R7/U4/U7 |
+
+## 8. 工具、观测与交付
+
+本轮未安装软件、修改配置、运行迁移、重启服务或压测。brew 已有三项服务软件，当前瓶颈主要是接线与一致性机制，暂不重复安装。未来压测可通过 [brew 安装 k6](https://formulae.brew.sh/formula/k6)；PgBouncer 只在连接测量证明有必要后安装。安装授权不等于对共享数据库升级、创建扩展或变更服务的授权；执行前核对目标、版本与既有占用。
+
+必需观测：API P95/P99与预期/非预期错误，DB pool wait/连接数/慢查询/锁等待，队列长度/最老年龄，run 租约/过期写拒绝/未知副作用，SSE cursor lag/补查次数，Redis 错误与降级，检索耗时/召回抽样，备份时间与恢复结果。日志只记录 request/run/owner 的安全标识，不记录 DSN、密钥或文档正文。
+
+r1 为方案与 SELF 调查记录。r2 起：U1–U7 代码与测试已合入且正确性 CI 绿。r2.1：本机双实例 contract 容量窗口（ladder / 60m / 2h）SELF 全过，见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。r2.2：用户于 2026-10-12 明确不做容量重放；同日完成 B6 pgbench、C4 PG/Redis 断连、C5 物理备份与 pg_dump 恢复的本机 SELF，见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)。C4 通过。C5 的库恢复通过（RPO 64 秒，RTO 4 秒），工件上传在未配置对象存储时 panic，K4 失败，产品代码未改。r2.3：2026-10-13 在 store 边界把带类型的空对象存储当作未配置并回落本地目录；同日 C5 重测 K1–K7 均为 SELF 通过（RPO 65 秒，RTO 3 秒，K4 五个工件 sha256 一致且跨用户拒绝）。本地 SELF 不能冒充 GATE/REPLAY 放行；双主机仍缺。部署与第二实例写流量仍未授权。
+
+方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
+
+首选下一增量不要自动开工。剩余放行门槛是：独立 REPLAY，或把 C4/C5 快速档接入 CI 形成 GATE（需平台准入）；以及 C3 双主机（需第二台机器）。2026-10-13 的上传修复与 K4 SELF 重测不替代这两项。GATE/REPLAY 与 C3 未齐前，不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。
@@ -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` 另行开任务；本文升级为已批准范围并回填裁定记录。
@@ -0,0 +1,507 @@
+---
+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 的名称均为候选设计，正式符号由公开契约申请确定。
+本轮没有联网核验法律或标准条款，也没有声称系统已符合任何特定法规；本方案讨论项目既定需求、数据追溯与实现验收。
+
+## 2026-10-13 项目成员闭环增量
+
+用户复现宿主项目成员保存成功、成员登录不见项目且不能建对话，已批准针对 U2/U3/U5 的方向与阶段 1–9 连续推进。具体实施主记录为 [系统项目、成员工作入口与私域协作闭环 r1.1](2026-10-13-system-project-membership.md)，验证/组件/PR/CI 结果在关联 Dev 任务卡维护。当前实现候选已覆盖统一项目、全局名称、成员个人会话、领域分片、私域与发布知识，以及旧项目显式修复；组合验收与正式 tag 消费仍推进中，不据此声明全部 U2/U3/U5 或总目标完成。部署、8788 数据修复与清理仍未授权。
@@ -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)。目录仅报告源码资产状态，不包含线上项目的实际文档数量。
@@ -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 单独立项，不把本轮范围确认当作连续实施授权。
+
+后续再考虑跨项目引用审批、全局关系图、电子签名/外部防篡改存证及复杂图分析；这些不属于首个可用闭环。
@@ -0,0 +1,252 @@
+---
+title: 快慢通道展示 U1 实施计划
+date: 2026-10-12
+revision: r1
+status: approved
+owner: weichen
+execution: implementation
+parent: 2026-10-12-fast-slow-channel-display.md@r1.1
+---
+
+# 快慢通道展示 U1 实施计划 r1
+
+> **For agentic workers:** 按本计划逐工作项实施；每项先写失败测试再改实现。规格依据主方案 [r1.1](2026-10-12-fast-slow-channel-display.md)。阶段 5 已于 2026-10-12 经用户「开始」批准；批准不等于推送/合入授权。
+
+**Goal:** 统一后台任务真实状态语义，用 L1 精炼骨架替换「原始指令占主视图」，使失败不再显示为完成，并为后续 U2 快照契约留下兼容字段草图。
+
+**Architecture:** 服务端在建卡/终态时写入精炼 Body 与正确 `CardStatus`；UI 按状态灯/状态词渲染；旧 `done+danger` 客户端兼容映射为失败。不引入持久 `TaskSnapshot`、不按任务路由 `agent.progress`、不发布阶段 findings（属 U2/U3）。
+
+**Tech Stack:** Go（Core/Backend）、React+TypeScript（UI/Frontend）、既有 ActivityCard / UINode / cardsvc 事件流。
+
+**Spec:** [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md) §4 R03-a、§7.1、§10.1、§14 U1 出口白名单。
+
+## Global Constraints
+
+- 首批仅 U1；禁止顺手实现 U2/U3 范围（材料内容 hash、持久快照、检查点摘要、HITL 双入口完备）。
+- 颜色/圆角/字号只消费 `@ui/tokens.css`；动效只用 `mk-*`；折叠用 Collapsible。
+- 证据经 `CMD=… make evidence` 写入任务卡；声明通过须标 SELF/GATE。
+- 跨仓顺序：Core（若有契约）→ Backend → UI → Frontend → Dev gitlink 组合 `make test`。
+- 现有「停止」按钮语义不在本增量改名为「仅停前台」；不暴露暂停/独立取消/续跑。
+
+## Review Focus
+
+1. 失败卡若仍为 `done`，用户会当成成功收纳——须 `CardFailed` 或等价失败灯。
+2. 建卡若仍塞入 task 原文，用户会把指令当进度——须 L1 骨架。
+3. 材料去重若仍只认 `CardDone`，改为 `CardFailed` 后可能卡死重试门禁——须同步测试。
+4. 快通道在登记前说「已启动」——须与真实登记/开跑事件对齐。
+5. `CurrentTaskCard`（plan/todos）与后台 progress 卡同目标叠卡——U1 须定义合并或降噪规则，避免双标题。
+
+---
+
+## 0. 范围与非目标
+
+### 纳入（映射需求）
+
+| 需求 | U1 验收子集 |
+|---|---|
+| R01 | 简单问答无空进度卡；复杂任务短答可含已确认范围与后台真实状态 |
+| R02 | 已登记任务有稳定卡对象；未登记不显示「已启动」 |
+| R03-a | L1 骨架 + 诚实无发现占位；不验收运行中真实发现 |
+| R08 | 失败 ≠ 成功灯；状态词「执行失败」 |
+| R10 | 完成卡骨架（结论/要点/缺项/入口）；完备来源与版本定位可留 U3 |
+| R13 | 守护测试通过；状态不只靠颜色（沿用 StatusLamp 形状） |
+
+### 排除
+
+见主方案 §14「明确排除」。另：不改 `CancelRun` 父句柄行为；不改 Surface 抢占策略（属 U2/U4）。
+
+### 与 CurrentTaskCard 的合并规则（U1）
+
+- 后台 `CardKindProgress` 卡是慢通道权威对象。
+- 若同一会话同时存在前台 `plan`/`todos` 的 `CurrentTaskCard` 与后台 progress 卡：**右栏「工作」优先列出 progress 卡**；`CurrentTaskCard` 仅在无后台 progress 卡且 plan/todos 非空时展示。
+- 不在 U1 把 plan steps 写入后台卡 Body。
+
+---
+
+## 1. 工作项与文件
+
+### W1 — Core：精炼摘要契约草图与旧卡映射说明
+
+**Files:**
+- Modify: `modules/core/activity.go`（若增加可选字段）或新增 `modules/core/task_summary.go`
+- Test: `modules/core/activity_test.go` 或同目录新测
+
+**内容（最小）：**
+
+```go
+// TaskSummaryView 是 U1 写入 ActivityCard.Body 的权威语义草图；
+// 完整 TaskSnapshot（findings/revision/streamScope）留待 U2。
+type TaskSummaryView struct {
+	Title       string // 业务动宾短标题
+	Focus       string // 正在做什么，≤2 行
+	FindingsNote string // U1：无成果时固定诚实文案；有结构化 findings 属 U3
+	Remaining   string
+	NextStep    string
+	OutcomeLine string // 完成后的结论一行；运行中可空
+}
+```
+
+可选：在 `ActivityCard` 增加 `Summary *TaskSummaryView \`json:"summary,omitempty"\``；**Body 仍为旧客户端回退投影**，新客户端优先读 Summary。若为降低跨仓面，U1 可仅约定 Body 的 Markdown/KV 形状而不加字段——但须在 Core 注释或本计划冻结 Body 键名：
+
+| KV 键 | 含义 |
+|---|---|
+| 状态 | 排队中 / 进行中 / 已完成 / 执行失败 |
+| 正在做 | Focus |
+| 当前发现 | FindingsNote（U1 占位或完成后要点摘要） |
+| 剩余 | Remaining |
+| 下一步 | NextStep |
+
+- [ ] 冻结 Body 键名或 `Summary` 字段二选一，写入 Core 并单测序列化往返
+- [ ] 文档注释标明 findings[] 属 U2/U3
+- [ ] Commit：`docs(core): freeze U1 task summary body contract`
+
+### W2 — Backend：建卡/终态状态与精炼 Body
+
+**Files:**
+- Modify: `modules/backend/internal/runmgr/runmgr.go`（`createBackgroundCard` ~1942、`promoteQueuedCard` ~1970、`finishBackgroundCard` ~1992）
+- Modify: `modules/backend/internal/runmgr/material_test.go`（及同类依赖 `CardDone+danger` 的测试）
+- Test: 新增 `modules/backend/internal/runmgr/background_card_test.go`
+
+**当前问题（源码）：**
+
+```go
+// create：Body 首节点 = truncate(task, 400)
+// finish：SetStatus(..., CardDone, tone) 且失败 tone=danger、状态行仍写「已完成」
+```
+
+**目标行为：**
+
+```go
+func backgroundRunningBody(focus string, kv [][2]string, statusLabel string) []core.UINode {
+	return []core.UINode{
+		{Type: core.UIMarkdown, Markdown: "尚无阶段结论，正在读取材料"},
+		{Type: core.UIKV, KV: append(append([][2]string(nil), kv...),
+			[2]string{"状态", statusLabel},
+			[2]string{"正在做", focus},
+			[2]string{"当前发现", "尚无阶段结论"},
+			[2]string{"剩余", "待任务进展后更新"},
+			[2]string{"下一步", "继续处理已登记工作"},
+		)},
+	}
+}
+
+// finish 成功：CardDone + tone ok；状态「已完成」；Markdown = 结论骨架
+// finish 失败：CardFailed + tone danger；状态「执行失败」；保留已有可读摘要
+```
+
+- [ ] 失败测试：`finishBackgroundCard` 在 `err != nil` 时 `Status==CardFailed` 且 Body 状态键 ≠「已完成」
+- [ ] 失败测试：`createBackgroundCard` Body Markdown 不含原始 task 长指令（可用固定长 task 断言不出现）
+- [ ] 实现最小改动；`promoteQueuedCard` 只更新状态键为「进行中…」
+- [ ] 更新 `material_test`：成功路径仍等 `CardDone`；失败/重试路径认 `CardFailed` 或释放 `materialActive`
+- [ ] 快通道诚实：spawn/登记路径日志与用户可见文案——仅在 `Create` 成功后可称「已登记」；仅在子 run 启动后可称「进行中」（检查 `spawnBackground*` / material 入口提示，必要时改 system 提示片段；**不做**阶段发现生成）
+- [ ] Commit：`fix(backend): map background card fail to CardFailed and use L1 body`
+
+### W3 — UI：状态灯与旧卡兼容
+
+**Files:**
+- Modify: `modules/ui/src/ActivityCardView.tsx`（`StatusLamp`）
+- Test: 既有 UI 测试或新增 `ActivityCardView` 测例；跑 `design-guard.test.ts`
+
+**目标：**
+
+```tsx
+// done → 完成灯；failed → 失败灯（已有）
+// 兼容：status===done && tone==='danger' → 按失败灯展示，title「执行失败（兼容）」
+```
+
+- [ ] 失败测试：`done+danger` 渲染失败形状灯，不渲染 `lamp-ok`
+- [ ] 实现兼容映射；不新增裸色值
+- [ ] `pnpm test` / 仓内 UI 测试目标通过
+- [ ] Commit：`fix(ui): treat done+danger progress cards as failed`
+
+### W4 — Frontend：工作区排序与空卡
+
+**Files:**
+- Modify: `modules/frontend/src/components/Workbench.tsx`（`CurrentTaskCard` 展示条件）
+- Modify: 若 Inbox 过滤依赖 status，核对 `store.ts` 对 `failed` 的分区（完成区 vs 进行中）
+- Test: 前端既有测试或最小组件测
+
+**目标：**
+
+- 存在 `kind===progress && status===active`（或排队文案）时隐藏与同会话抢注意力的空 `CurrentTaskCard`（按 §0 合并规则）
+- `failed` 卡进入可收纳/结果区逻辑与 `done` 区分（失败可收纳但不显示成功语义）
+- 简单问答路径不因误触发材料整理产生空卡——若属既有路由，仅加回归断言「无附件无后台登记时 progress 卡数为 0」
+
+- [ ] 实现合并规则
+- [ ] 回归：无后台任务时 plan 仍可显示
+- [ ] Commit：`fix(frontend): prefer progress cards over duplicate CurrentTaskCard`
+
+### W5 — Dev 组合与文档收口
+
+**Files:**
+- Modify: Dev gitlink（Core/Backend/UI/Frontend 精确 SHA）
+- Modify: 实施任务卡证据段；主方案进展指针（若本增量合入时）
+- Test: 工作区根 `make test`、`make build`
+
+- [ ] 各组件 PR 顺序合入或同批组合验证
+- [ ] Dev `make test` + `make build`；evidence 写入
+- [ ] 更新主方案「规划进展」：U1 实施状态（仅在真实合入后）
+
+---
+
+## 2. 测试与环境
+
+| 层 | 命令/方法 | 证明什么 |
+|---|---|---|
+| 单元 | Backend `go test ./internal/runmgr/…`；Core 序列化；UI StatusLamp | 状态映射、Body 骨架、兼容灯 |
+| 守护 | UI/Frontend `design-guard.test.ts` | 无新增裸色值/私有 keyframes/行内字号 |
+| 组合 | Dev `make test`、`make build` | gitlink 组合可编译可测 |
+| 手工冒烟（SELF） | 本地起服务：发材料看建卡；制造子任务失败看灯；简单问答无空卡 | U1 白名单场景 |
+| 真实模型阶段成果 | **NOT_RUN / 不在 U1** | — |
+| 浏览器窄屏全矩阵 | **NOT_RUN / 属 U4** | — |
+
+被测对象：各仓 PR HEAD；组合声明须含精确 SHA。
+
+---
+
+## 3. 完成条件
+
+1. U1 出口白名单全部可判定项有 SELF 或 GATE 证据。
+2. R03-a 有测例；无人用「五问完整」拒绝 U1。
+3. 材料整理去重/重试在 `CardFailed` 下仍可再次登记（或文档说明与测例固定行为）。
+4. 无 U2/U3 范围代码混入同一变更集（审 Diff）。
+
+---
+
+## 4. 停止与回退条件
+
+- 失败状态与存储不一致（卡显示失败但去重门禁认为仍在跑，或相反）→ 停止合入，修 W2/材料门禁。
+- 新旧客户端之一崩溃或空白卡 → 回退 Summary 字段改动，保留 Body 回退投影。
+- 发现实现滑入持久快照/检查点摘要 → 拆出变更，不进本 PR。
+- DESIGN 守护失败 → 先改令牌消费再继续。
+
+回退策略：回退受影响展示映射与 Body 生成；不删除已保存 run 结果。
+
+---
+
+## 5. 依赖顺序与责任
+
+```text
+W1 Core 契约（可选字段或 Body 键冻结）
+  → W2 Backend 建卡/终态
+  → W3 UI 灯兼容
+  → W4 Frontend 工作区
+  → W5 Dev gitlink + 组合测试
+```
+
+责任人：实施阶段指定；需求/评审：weichen。
+
+预估：单增量跨 4 仓，以状态映射 + Body 重排为主，不含模型评测费用。
+
+---
+
+## 6. 计划评审状态
+
+| 项 | 状态 |
+|---|---|
+| 关联方案 | r1.1 设计已批准；首批仅 U1 |
+| 本实施计划 | **已批准**（2026-10-12，用户「开始」） |
+| 业务代码 | 实施中：`feature/fast-slow-display-u1` |
+| 推送/PR/合入 | 未授权（完成自检后另请） |
+
+首选动作已执行：`make task-start NAME=feature/fast-slow-display-u1`，按 W1→W5 推进；设计任务卡可在文档 PR 合入后 `task-close`。
@@ -0,0 +1,517 @@
+---
+title: 快慢通道展示与动态工作摘要方案
+date: 2026-10-12
+revision: r1.1
+status: design-approved
+owner: weichen
+execution: design-only
+---
+
+# 快慢通道展示与动态工作摘要方案 r1.1
+
+状态：**方案设计已批准（阶段 4）**。需求依据：用户要求改善快慢通道的内容、排版与直观性，让慢通道执行期间持续呈现精准、精炼且有工作价值的状态、发现、摘要和总结。
+
+批准依据：2026-10-12 用户确认评审结论计划并指示按该计划落地文档修订与 U1 实施计划；批准范围覆盖四层阅读、任务卡骨架、动态回投规则、U1→U2→U3→U4 顺序及**首批仅 U1**。本修订相对 r1 增加 R03 增量切分与 U1 出口白名单。业务代码实施仍须另批阶段 5 实施计划后启动。更新日期：2026-10-12（北京时间）。需求与评审负责人：weichen；实施负责人在实施阶段指定。
+
+## 1. 推荐方向与成功标准
+
+采用**对话推进工作、任务卡持续更新、结果按需展开**的方案。快通道负责即时理解、当前可回答的结论和必要确认；慢通道负责持续处理材料、研究、分析、生成及检查，并把当前工作成果逐步汇总给用户。两者共享任务与事实，不形成两份独立聊天记录。
+
+用户应当可以在一个视野里回答五个问题：
+
+1. 这项工作现在处于什么状态？
+2. 已经完成什么、目前知道什么？
+3. 这些发现对我的任务有什么影响？
+4. 还缺什么、下一步准备做什么？
+5. 是否需要我做决定或补充材料？
+
+默认阅读只需一行状态和一张紧凑任务卡。深入查看时可看到阶段成果、依据和执行记录。正式交付后直接给出结论、关键要点、限制与文件入口。
+
+设计的初始验收目标：代表性用户看到默认视图后，10 秒内可正确回答状态、主要发现、是否需处理三个问题；这个目标是**待验证的可用性指标**，不是当前体验已经达标的声明。
+
+## 2. 当前实现依据及差距
+
+本次依据本地固定源码核对，来源为 SELF。启动基线为 Dev `4bf6e4a0cf8b509320d54de2a6a41c5abb2f5bba`；任务同步后读取的 Dev HEAD 为 `3496d1af37827dc536559ed5bbfe23c381c329cd`，其包含同步基线 `dec25692c247c8923b0f9396c8f674aefec47521`。
+
+组件：Backend `dcc180dcad2489a170edca154e39e335220854f1`、Core `89f3906c390027512ef47b5333088c3d3a019e84`、Frontend `d01a3ebd819da29bf7e7dd06e74c92ef34231774`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`。Documents 写作分支从单独获取的 `origin/main=52bf525ef8750999e5e7dbff0b2decac5b1155f7` 建立，未改变受测业务组件。源码审阅原始记录见 Dev 任务卡 `.task/feature-fast-slow-display-design.md` 的 source-audit 收据。本轮未开展真实模型、浏览器或部署验证；以下“已有”只表示源码中存在相应机制。
+
+| 已有源码机制 | 位置 | 与本需求相关的差距 |
+|---|---|---|
+| 快通道是当前对话回合，慢通道是后台子任务；同会话后台槽位上限 3 | Backend `internal/runmgr/runmgr.go` 的 `spawnBackgroundOpts`、`startBackgroundSlot` | 缺少统一面向用户的任务概览；通道不是用户可切换的速度档位 |
+| 带附件可自动启动材料整理；无文字/大材料可预启动，小材料有结束兜底；支持排队 | Backend `internal/runmgr/material.go` | 已有入口应复用；当前材料键仅由文件名与解析字数生成，同名等长更新可能复用旧结果。启动信息不等于材料已经读完 |
+| 进度卡创建时放入最多约 400 字任务正文和“执行中”状态 | Backend `internal/runmgr/runmgr.go:1942` | 用户主要看到任务说明和指令，不能据此理解实际进度 |
+| 完成时替换卡身；成功/失败统一置 `done`，用 tone 区分 | 同文件 `finishBackgroundCard`；UI `src/ActivityCardView.tsx:23` | 执行期间缺少成果投影；失败卡可能带“完成”灯，业务结果与卡收纳状态混在一起 |
+| `agent.progress` 发布子任务文本前约 80 字及“调用工具”消息 | Backend `internal/runtime/sub_loop.go:208` | 原始文本片段不具备稳定摘要语义，也没有结构化来源和成果完整性 |
+| `agent.progress` 写进单个 `live.agentNotes`；`touchLive` 维护单个 LiveState | Frontend `src/store.ts:514`、`:986` | 需避免后台进展串入当前对话回合；缺少按任务持久维护的独立展示投影 |
+| 会话/项目事件流、卡片更新事件及断线重放契约已有；客户端读取 seq | Core `events.go`；Frontend `src/api.ts:192` | 客户端 `Math.max` 推进游标本身不等于拒绝旧帧；新投影必须显式处理去重、顺序和恢复 |
+| 三栏“上下文 / 对话 / 工作与文件”、HITL、工件预览、Surface 已有 | Frontend `Workbench.tsx`、`Conversation.tsx`、`store.ts`；Core `activity.go` | 需要在现有落位整合，不增加第四栏；Surface 更新当前有自动打开预览行为，后台更新应控制抢占 |
+| 后台完成结果在会话空闲时启动汇报回合 | Backend `deliverNotices` | 结果就绪与汇报已送达需要分开；用户不应因前台忙而误以为任务尚未完成 |
+| 取消子 run 的现有路径还会尝试取消父句柄 | Backend `CancelRun` | 不直接提供承诺独立取消、暂停或重试的按钮 |
+
+由源码推导的主要原因：运行事件、任务卡和最终回复之间缺少一层稳定的**用户工作摘要**。只调整卡片样式不能补齐这些信息。
+
+## 3. 方案选择与边界
+
+| 方案 | 收益 | 代价与限制 | 结论 |
+|---|---|---|---|
+| 直接把慢通道日志流到卡片 | 改动较少、容易看到活动 | 原始指令与工具输出增多；难提炼发现；并发时噪声更大 | 作为执行记录层，不作为默认视图 |
+| 快慢通道各有一份完整对话流 | 两条执行线直观 | 重复回复、重复确认、用户需要拼接上下文；占用阅读空间 | 不采用 |
+| 统一任务摘要 + 同一卡片更新 + 对话关键回投 | 结论可读、状态可见、细节可追溯 | 需要结构化成果与持久投影 | **推荐** |
+
+范围包括信息架构、快通道内容、慢通道摘要、状态语义、更新策略、来源与恢复、UI 组件适配。通用基座提供任务、发现、来源与动作能力；文档审签、业务风险等级等由下游提供适配，不写进基座。
+
+本轮不执行业务代码修改、模型实验、迁移、重启或部署。候选设计中的新契约、持久化和操作能力均为待批准内容。本方案不依赖 Generative UI 插件启用才能工作；结构化任务卡提供基础体验，Surface 可用于适合的成果展示。
+
+## 4. 需求与可判定验收
+
+以下为已批准方案范围内的需求表。P0 是核心闭环，P1 是增强项。首批实施仅覆盖 U1 出口白名单中的子集；“纳入候选”不等于该子集已获实施授权。
+
+| ID | 需求 | 优先级 | 可判定验收条件 | 依赖/处理 |
+|---|---|---|---|---|
+| R01 | 快通道首先给用户可用的即时答复 | P0 | 简单问答无空任务卡；复杂任务短答能说明已确认范围、当前可回答内容及后台工作 | 既有对话；U1 纳入 |
+| R02 | 所有已登记后台任务都有稳定可见对象 | P0 | 排队、运行、结束都定位到同一任务；未登记时不显示“已启动” | 任务登记；U1 纳入 |
+| R03 | 默认卡呈现当前工作、发现与剩余项 | P0 | 见下方 R03 增量切分；完整五问仅在 U3 验收 | R02；按增量切分 |
+| R04 | 阶段成果动态更新且不重复刷屏 | P0 | 有可用阶段成果时及时更新同一卡；选定长任务验收至少两个真实成果检查点；短任务可直接完成，普通更新不新增对话消息 | 事件投影；U2/U3 |
+| R05 | 事实、分析判断和待确认内容可区分 | P0 | 关键发现可定位依据；尚未核实的推断带限定；不得以模型自报覆盖工具实际结果 | 来源契约；U2/U3 |
+| R06 | 并行任务不会互相污染状态或正文 | P0 | 3 个后台任务与前台回合同时活动，各任务标题、发现和终态归属正确 | 按任务路由；U2 |
+| R07 | 等待用户的动作明确且双入口一致 | P0 | 对话/右栏提交任一入口后另一个同步更新；重复点击只执行一次 | 既有 HITL/动作；U3 |
+| R08 | 成功、部分结果、失败、中断明确区分 | P0 | 失败不显示成功灯；部分结果标明缺项；未保存的结果不显示“已交付” | 结果契约；U1 纳入 |
+| R09 | 断线/刷新不丢失成果，也不伪造状态 | P0 | 重连可恢复阶段摘要；重复/乱序事件不回退；连接异常不改写业务终态 | 持久快照；U2 |
+| R10 | 完成回投精炼且可取回产物 | P0 | 显示结论、最多 3 个默认要点、缺项、文件入口；定位真实文件且版本明确 | 工件/通知；U1 骨架，U3 完备 |
+| R11 | 右栏关闭与窄屏时主要能力完整 | P0 | 不打开右栏即可读摘要、看依据、处理确认、打开文件 | 对话内展开；U4 |
+| R12 | 更新尊重正在阅读的内容 | P0 | 不自动切文件、不夺取焦点、不把用户滚回底部；展开与阅读位置保留 | 更新策略；U2/U4 |
+| R13 | 视觉与可访问性符合 DESIGN.md | P0 | 令牌、Collapsible、MotionKit 守护通过；键盘可达；状态不只靠颜色 | UI/Frontend；U1 纳入 |
+| R14 | 摘要成本受控，摘要失败不影响任务 | P0 | 不按 token 调用摘要模型；预算耗尽仍有真实阶段状态与既有发现 | 发布策略；U3 |
+| R15 | 修改任务要求可解释地衔接 | P1 | 新要求明确“尚未生效/已用于后续任务”；不假称已改变在跑任务 | 新任务/输入确认；U4 |
+| R16 | 合适成果可以切换对比、清单或报告 | P1 | 比较任务给差异表；审查给问题清单；插件关闭仍能读取核心摘要 | 可选 Surface；U4 |
+| R17 | 每次尝试与结果采用状态可追溯 | P0 | 新尝试不覆盖旧失败；生成、用户认可、正式发布三者独立显示 | task/attempt/result；U2 |
+| R18 | 跨任务发现有总览且不重复计数 | P1 | 同一来源同一发现合并引用；冲突并列呈现，关联到各自任务 | 稳定发现 ID；U4 |
+
+### R03 增量切分（定稿）
+
+完整 R03「运行卡无需展开即可回答第 1 节五问」不得用单一增量字面验收。切分为：
+
+| 子集 | 归属 | 可判定出口 |
+|---|---|---|
+| R03-a | U1 | 默认卡采用固定 L1 骨架（标题+状态、正在做什么、当前发现区、剩余/下一步）；无阶段成果时诚实显示「尚无阶段结论…」；不把原始任务指令当作进度正文；**不**要求运行中出现真实业务发现 |
+| R03-b | U2 | 活动行与覆盖/剩余可随确定性事件持续更新；刷新/重连后骨架与活动状态仍可读 |
+| R03-c | U3 | 带来源的 1–3 条阶段发现；运行中即可回答五问中的「知道什么 / 影响 / 还缺什么」 |
+
+项目符合度：R01–R18 与对话优先、服务端权威、通用基座定位相符；其中 R02–R09、R14、R17 需要契约及实现调整，R15/R16/R18 的完整能力需进一步设计。运行可行性尚未验证。
+
+## 5. 信息架构与阅读层级
+
+维持三栏。左侧提供项目、会话、材料上下文；中间负责对话、关键进展和决定；右侧“工作”集中当前任务与待处理事项，“文件”负责既有唯一预览入口。
+
+| 层级 | 默认展示 | 用户目的 | 展开方式 |
+|---|---|---|---|
+| L0 一行概览 | 前台状态、后台任务数量、待处理数量 | 一眼判断是否忙、是否需要行动 | 点击对应任务或待处理项 |
+| L1 工作摘要 | 目标、状态、正在做什么、1–3 条重要发现、剩余项、必要动作 | 快速理解并继续工作 | 当前任务卡；对话内同对象锚点 |
+| L2 阶段与依据 | 阶段成果、发现列表、覆盖范围、未决事项、来源 | 检查判断、准备评审 | 在原位置用 Collapsible 展开 |
+| L3 执行记录 | 工具调用、可授权查看的参数/输出、事件、错误详情 | 排障和审计 | “执行记录”，默认折叠、按阶段分组 |
+
+默认先提供 L0/L1；不同时展开所有任务。正在查看文件时，工作更新只改变概览及未读提示。右栏收起时，中栏任务锚点可展开 L1/L2/L3，关键功能不依赖右栏。两处共享同一 taskId 和服务端快照，不分别生成摘要。
+
+右栏顺序：**需要你处理 → 当前正在查看的任务 → 其他进行中/排队 → 新结果 → 已收纳历史**。置顶任务保留位置；普通更新不因时间变化反复重新排序。排序规则只负责注意力，不改变执行优先级。已有“当前任务卡”的计划/待办融入同一概览，避免再叠一张同目标卡。
+
+### 5.1 桌面示意
+
+下列内容均为设计示例，不是真实运行结果。
+
+```text
+上下文                 对话                             工作 | 文件
+项目 / 会话            收到 3 份材料，已登记材料整理任务    需要你处理 0
+材料与历史             我会先核对事实和差异，再给摘要      材料整理 · 进行中
+                       [材料整理 · 已有 2 条阶段发现]      正在核对：需求与会议结论
+                                                        当前发现
+                       你：先重点看验收要求                • 3 项需求缺少验收条件
+                       助手：补充尚未作用于在跑整理         • 上线日期存在两种表述
+                       [以此重点创建后续分析任务]           剩余：核查评审意见
+                                                        下一步：整理待确认事项
+                       …                                [查看依据] [阶段与记录]
+                       后台 1 项 · 无需你处理
+                       [输入消息                          ]
+```
+
+中栏进展锚点只给一条高价值提示，不复制右栏全文。新目标通过新任务或已有受支持的输入动作落实，不默认承诺能动态改写在跑任务。
+
+## 6. 快通道内容规范
+
+### 6.1 不同场景怎样回复
+
+| 场景 | 默认回复 | 后台信息 |
+|---|---|---|
+| 简单问答、短文本修改 | 先给答案，必要时给短依据或结果 | 无实际后台任务则不显示通道卡 |
+| 发送材料、任务尚未登记 | “收到 3 份材料，正在准备整理”及已确认的接收/解析信息 | 不提前声称“已启动” |
+| 材料任务已登记 | “已登记材料整理，完成后给出事实、差异与待确认事项” | 显示排队或运行真实状态 |
+| 有明确分析/生成目标 | 一句话复述目标 + 当前能回答的内容 + 本次处理范围 | 实际启动后显示相应任务 |
+| 用户追问后台知道了什么 | 基于最新快照给 2–3 条已发布发现，标出仍在核查的部分 | 不重复启动同一工作 |
+| 发现阻塞/需要决定 | 直接说问题、对结果的影响及所需输入 | 复用同一个确认对象 |
+| 后台结束 | 结论 → 关键要点 → 限制/缺项 → 产物或下一动作 | 回投当前结果版本 |
+
+“每份材料一句概览”只在已有解析或阶段成果能够支持时给出。快通道尚未读到材料正文时，给文件清单和整理范围即可，不由文件名推断业务结论。
+
+### 6.2 精炼但有用的内容骨架
+
+短答默认 2–5 行；复杂结论默认一段总括、最多 3 个要点和一个主要动作。字数是初始排版预算，不硬截关键风险、金额、日期、否定条件或来源。
+
+示例：
+
+> 已收到需求说明、会议纪要和评审意见，材料整理任务已进入队列。整理会先核对关键事实、冲突与待办。你可以继续补充希望重点关注的问题。
+
+有阶段成果后的示例：
+
+> 目前发现 3 项需求缺少验收条件；两份材料中的上线日期不一致。评审意见仍在核查，完整结论尚未形成。你现在可以先确认上线日期的权威来源。
+
+避免空泛重复“我正在深入分析”“请耐心等待”。工具名、系统提示词、模型自我描述不进入默认业务回复。无需用户决定时，不为了显得主动而硬加问题或三个无依据建议。
+
+## 7. 慢通道任务卡与阶段摘要
+
+### 7.1 运行中固定骨架
+
+1. **标题与状态**：业务动宾短标题，如“核对三份材料”“生成需求说明”；状态词独立显示。
+2. **正在做什么**：一句业务阶段说明，最多两行。如“核对需求条目与评审结论”。
+3. **当前发现**：默认 1–3 条，按对目标的影响排序；每条表达“发现 + 意义”，有来源入口。
+4. **剩余与下一步**：一句说明尚未覆盖部分及接下来处理内容。
+5. **操作与时间**：只有真实可用的主动作；注明最近成果更新时间，耗时为次要信息。
+
+任务刚开始时，“当前发现”显示“尚无阶段结论，正在读取材料”，不制造空白占位成果。无需用户操作的任务明确“无需你处理”，而非放一个不可执行的“继续”按钮。
+
+```text
+核对三份材料                              进行中
+正在核对需求与会议决定
+
+当前发现
+• 3 项需求缺少验收条件，暂无法判定是否可验收  [来源]
+• 上线日期存在两种表述，需要确定权威版本    [来源]
+
+已覆盖：需求说明、会议纪要的目标章节
+剩余：评审意见中的变更记录
+下一步：整理冲突与待确认事项
+最近成果更新 14:32                 [查看阶段与依据]
+```
+
+“已覆盖”必须来自已确认处理的章节、工具返回或有效检查点。解析完成与分析完成分开显示；“读过一份文件”不能自动计为该文件已全部分析。数量与统计只能来自可数、可去重的对象。
+
+### 7.2 有工作价值的阶段成果
+
+每次阶段发布应至少带来一个用户能利用的变化：确认事实、揭示差异、形成可用初稿、发现缺项、完成检查、给出必要决定。普通“调用工具”只更新活动状态和执行记录，不算业务成果。
+
+| 工作类型 | 推荐业务阶段，按实际任务选用 | 默认最有价值的内容 | 最终呈现 |
+|---|---|---|---|
+| 材料整理 | 接收/解析 → 提取事实 → 核对差异 → 汇总 | 核心事实、共同结论、冲突、待办 | 短摘要 + 重要发现 + 来源 |
+| 研究检索 | 明确问题 → 查找来源 → 对照证据 → 形成判断 | 已找到的依据、尚缺的证据、判断如何变化 | 结论 + 对比/依据 |
+| 方案/需求分析 | 提取约束 → 检查覆盖 → 比较取舍 → 整理建议 | 缺项、约束、关键取舍及影响 | 建议 + 清单/对比 |
+| 文档生成 | 确认范围 → 编排结构 → 生成草稿 → 校验保存 | 结构已定、待补材料、草稿状态、检查结果 | 精炼结论 + 正式工件入口 |
+| 审查验证 | 确定对象 → 执行检查 → 归纳问题 → 汇总结果 | 会阻塞交付的问题、证据、未覆盖项 | 问题清单 + 实际检查结果 |
+
+阶段不固定为所有任务必经的四步。检索/检查可能迭代回到前一阶段；通过阶段 ID 与版本记录，不以动画线性前进。没有领域阶段数据时降级为“读取材料 / 使用工具 / 整理结果”等确定性活动描述，不凭计时自动切阶段。
+
+### 7.3 成果不是思维链
+
+发布公开工作摘要、工具确认的事实、可交付的阶段产物和待确认问题，不把隐藏推理、系统提示词、原始任务提示或未完成 token 片段包装成发现。执行记录仅展示真实已有且当前用户有权限查看的记录；“展开”不意味着获得额外权限。
+
+## 8. 精炼、来源与结论修订
+
+### 8.1 发现的表达与排序
+
+发现由一句结论和一句影响组成，通常合为一行：“指标定义不同，两个方案的达成率不能直接比较”。排序优先级为：需要用户决定的事项、会改变当前建议的风险、与用户目标直接相关的事实、其他背景信息。
+
+去重按稳定 findingId 及来源版本处理；同一事实由两个任务发现时，展示一次并保留两条依据。差异表、审查清单按内容结构选择，不把所有成果强塞进统一长 Markdown。
+
+### 8.2 用户可理解的结论标签
+
+| 内容类型 | 展示文案 | 发布要求 |
+|---|---|---|
+| 材料直接记载的内容 | “材料记载” | 指向文件版本与位置；不等于事实已被外部验证 |
+| 工具检查直接确认的结果 | “已核对” | 指向具体检查对象和真实结果；本地/独立/受信来源保留对应证据等级 |
+| 基于若干来源推导的建议 | “分析判断” | 提供依据，说明影响结论的假设 |
+| 尚有关键缺口的判断 | “初步判断” | 显示缺口、覆盖范围；不得写成最终结论 |
+| 需要人决定的口径/事实 | “待确认” | 给明确问题和影响，并关联确认入口 |
+
+这些标签描述内容性质，不提升 SELF/REPLAY/GATE 信任等级。不显示没有校准依据的“可信度 95%”。重要来源失效时保留历史结论，当前摘要标“依据已更新，需重新核查”。
+
+### 8.3 来源定位与修订
+
+来源至少包含项目/会话归属、文件或工件 ID、版本或内容摘要、可用定位信息及发布事件。优先页码、章节、段落；现有解析器没有页码时显示章节/片段，不编造定位。权限失效显示“当前无法访问该来源”，摘要权限同步重新检查，不以历史缓存继续泄漏内容。
+
+输入复用身份必须包含实际内容摘要：优先原始文件内容 hash 与解析版本，缺少原始 hash 时至少包含实际解析文本 hash、解析版本与相关处理配置，不能仅用文件名和字数当版本。保留既有附件路由，但不同内容不得复用旧任务成果。当前材料键校正作为 U2 来源修订的前置依赖，可用关联修复增量交付；旧卡无法证明内容一致时仅作历史结果，不自动认定本次输入已经整理。材料键等兼容凭据应保留在受控元数据与旧客户端回退投影中，用户默认卡身不展示内部键。
+
+发现具有稳定 ID、有效状态与版本：当前有效 / 已修正 / 已撤回 / 已被替代。后续推翻早先发现时，摘要替换当前有效项，阶段历史留一条“此前判断已修正”并给原因、影响和新依据。若曾需要用户据此行动，必须发一次有意义的更正提醒。
+
+### 8.4 任务结束后的内容
+
+```text
+材料整理已完成
+结论：当前材料可用于需求草稿，仍有 2 项关键口径需确认
+
+• 核对出 3 项缺少验收条件的需求
+• 上线日期冲突，需要项目负责人确认
+• 评审意见的 2 条调整尚未反映到需求说明
+
+范围：已覆盖三份材料的可解析文本；图片附件未纳入
+[查看完整摘要]   [查看来源]   [确认交付物]
+```
+
+生成文件不代表用户已认可或文档已审签。另显示交付状态：草稿已保存 / 等待评审 / 已认可 / 已发布；正式状态只采用业务宿主确认结果。检查未执行时写“未检查”，不以“已生成”代替“已验证”。示例中的完成与发现仍为设计数据。
+
+## 9. 动态更新、通知与阅读稳定性
+
+### 9.1 更新来源与频率
+
+采用两条信息路径：**确定性活动状态**来自任务登记、工具开始/结束、等待用户、存储结果等事件；**业务摘要**来自显式阶段成果或对已完成结果的受控压缩。模型只提交摘要候选，服务端校验来源、覆盖范围、版本与终态后发布。
+
+| 变化 | 更新位置 | 初始调度策略 |
+|---|---|---|
+| 入队、执行开始、等待用户、失败/结束 | L0 + 原任务卡 | 持久化成功后立即发布；在线端到端目标 p95 ≤2 秒，待测 |
+| 工具开始/结束、活动描述变化 | 原卡的活动行 + L3 | 同任务合并高频变化，普通视觉更新最多每秒一次 |
+| 新阶段成果、建议发生实质变化 | 原卡 L1/L2 | 检查点发布；连续普通成果可在 8–15 秒窗口合并，首条有效成果不必等待窗口 |
+| 必须用户决定、关键风险、更正重要结论 | 对话提示 + 原任务卡 | 绕过普通摘要窗口；同一事件幂等提示一次 |
+| 没有新业务成果 | 活动行/连接提示 | 保留已有摘要；不自动追加“仍在分析”消息 |
+| 多任务相继完成 | 各卡 + 合并完成汇报 | 原卡先显示结果；父会话空闲再合并汇报，不阻塞结果可读 |
+
+时间参数是初始设计值，实施后通过可用性与性能验证调整，不是实时性已经达标的结论。执行日志收集不按视觉节流丢弃；合并的是显示更新和重复语义通知。
+
+### 9.2 控制摘要成本
+
+优先由当前执行器在自然检查点提交简短成果；必要时才另行压缩已完成的工具结果或阶段文本。不按每个 token、每个工具调用或每个定时 tick 运行新模型。
+
+候选边界：单任务最多 6 次额外摘要模型调用；普通额外摘要最小间隔 15 秒；最终主任务的结果汇总属于执行预算，仍受已有整体预算控制。费用上限在实施评审时与模型、材料范围一起批准。预算耗尽或摘要生成失败时，保留已发布发现并继续显示真实活动；不阻塞主任务，不伪造阶段成果。
+
+阶段成果发布应由运行时检查点驱动，不能只依赖模型自觉调用工具。没有可安全提取成果的长单次模型调用期间，只展示已确认活动与最近成果时间。若任务需要持续提供发现，可在不改变业务结论前提下拆成有产出的处理批次；这些提示词/行为改动需真实模型前后对照。
+
+### 9.3 不打断阅读
+
+用户阅读历史消息时不自动滚动；输入中不夺取焦点；正在看文件时不自动切“工作”或打开另一文件。出现新结果显示“1 项结果已更新”，由用户点击查看。用户主动等待的首次前台产物可沿用既有打开策略，但后台卡更新与 Surface 更新默认不抢占预览。
+
+同一卡片稳定 DOM 与区块 ID；不逐字重打整段摘要。更新相应段落并可轻标“新”，保留展开、选择、滚动和置顶。屏幕阅读器只播报阶段结束、关键发现和需要处理；不播报每个日志增量。减少动态效果时不播放状态动效。
+
+### 9.4 用户继续对话与调整要求
+
+后台任务运行时，对话依然可用；前台忙时沿用现有输入排队语义，并明确“消息待发送”。追问“现在发现了什么”读取已发布快照，无需新派任务。
+
+当前不假定在跑任务可动态接收新要求。补充内容应说明它将用于后续回合/新任务；如用户希望据此重新分析，创建关联的新尝试并保留原结果。未来可支持安全的任务输入修订，但必须有服务端确认“已接收并生效”后才显示生效。
+
+### 9.5 确认双入口的提交反馈
+
+对话与右栏按同一 confirmationRef 维护提交状态。点击后两处同步显示“提交中”并暂时禁用，收到服务端成功确认后才显示“已处理”。明确拒绝或提交失败时保留原问题、选项和错误原因；服务端返回已处理/版本过期时刷新共同对象，不能继续提交旧选项。
+
+请求超时或连接中断不能证明动作未执行，先显示“确认结果待核实”并查询既有动作记录，不盲目重复执行。重试使用同一幂等请求标识和相同参数；参数已改变则按新动作重新检查。前端不得以一个入口关闭为另一个入口业务完成的依据。
+
+## 10. 状态、异常与操作能力
+
+把三个维度分开：执行状态、成果完整性、连接状态。卡片的收纳/已读状态属于第四个展示维度，不驱动业务终态。
+
+### 10.1 执行状态
+
+| 状态 | 用户文案 | 说明与动作 |
+|---|---|---|
+| preparing | 准备中 | 只确认接收范围；持久登记后进入 queued/running |
+| queued | 排队中 | 队列已确认；只有服务器提供可信位置时显示序号，不给虚构等待时间 |
+| running | 进行中 | 显示真实阶段及最新有效发现 |
+| waiting_input | 需要你确认/补充 | 显示问题、影响、选项；无超时契约则不暗示自动继续 |
+| succeeded | 已完成 | 执行及必要结果保存均成功；是否满足全部用户要求由成果维度说明 |
+| failed | 执行失败 | 原因、影响、已保留内容和真实可用的恢复方式 |
+| cancel_requested / cancelled | 正在停止 / 已停止 | 仅在支持相应控制契约时暴露操作；请求送达不等于停止确认 |
+| interrupted | 执行中断 | 显示最后已保存检查点；恢复动作通过既有服务端支持判断 |
+
+这些是候选展示语义，不宣称 Core 已具备全部同名枚举。`waiting_input` 映射现有 waiting_hitl 等明确状态；旧后台卡 `done + danger` 要由 run 终态与 tone 映射为失败。没有可靠 run 对应时使用保守文案“任务已结束，结果状态待核对”，不解析任意正文来推断成功。
+
+成果完整性采用 complete / partial / none，并列出已覆盖和未覆盖范围。生成内容已经保存但汇报尚未送达时，显示“结果可查看，稍后在对话汇报”。交付保存失败时不能标“已交付”；可保留可读摘要并显示保存失败。
+
+### 10.2 连接与恢复
+
+在线 / 重连中 / 当前状态未核实只影响连接提示。60 秒没有新**成果**不等于执行失活；可显示“最近成果更新于…”，不能仅凭此声明失败。若要展示执行存活，须来自运行时心跳/执行所有权确认，另记录 lastActivityAt；现有源码没有已核实的通用任务存活契约，本方案将其作为新增设计。
+
+断线期间保留最后已确认结果，停止“实时”声明。重连先取得带流游标的快照，再重放游标之后事件；历史保留不足时重新获取完整快照。服务重启导致 run interrupted 时，依据真实终态显示中断；是否可恢复、恢复是否可能重放副作用由既有恢复能力决定，UI 不自动重试。
+
+### 10.3 按能力显示操作
+
+基础动作：查看摘要、查看来源、查看阶段/执行记录、处理既有确认、打开已保存文件、收纳结果。动作带服务端能力和禁用原因；UI 不根据模型写出的按钮名自行分发。
+
+暂停、独立取消、续跑、自动重试、改变在跑任务优先级不作为首期承诺。后台运行卡隐藏“关闭”式歧义动作，只提供折叠；收纳只影响历史呈现，不停止执行。现有输入区“停止”仍绑定现有前台能力；若其真实影响范围包含其他运行，必须如实说明，不能在本方案中改名为“仅停前台”而不修复契约。
+
+失败提示采用“问题 + 影响 + 已保留内容 + 下一动作”。例如：“评审意见未能解析，本轮只完成其余两份材料；已保存两份摘要。请补充可解析版本后重新核对。”有保存凭据才声明已保存。
+
+## 11. 多任务协作与领域展示
+
+一个用户目标下的任务组只给一份整体概览，各后台任务保持独立摘要。后台上限沿用当前 3 个槽位，队列与入场等待按运行时确认展示，不另造默认无限并发。
+
+总览优先突出阻塞与结论：“材料核对、竞品检索已完成；方案整理等待你确认预算”。只有明确可数的工作项才显示“2/3 项已完成”；这个比例不代表剩余时长或模型完成度。不能用工具次数、token 数或耗时估算百分比。
+
+并行发现经规则合并引用，冲突同时展示：“来源 A 写 6 月上线；来源 B 写 7 月，尚未确认权威口径”。完成任务先稳定保存成果再通知；父会话忙时新结果可读，业务汇报待空闲，多个结果可合并为一条简短汇报。去重键包括任务、尝试和结果版本，防止通知回合再派发原工作。
+
+领域可通过通用内容种类输出事实、差异、缺项、待办、建议和结果引用。RDM 类场景可由下游提供“受影响文档、验收条件缺项、审签状态”等内容与动作；基座不把材料整理“完成”解释为业务文档“已批准”。领域内容缺失时降级到通用摘要，不构造业务状态。
+
+## 12. 视觉与排版规范
+
+严格消费根 DESIGN.md，保持冷静、紧凑、内容优先的工作台。沿用用户此前选择的浅色克制方向，同时适配已有深色/墨绿主题。主题、字号与布局属于既有能力，实施不另造皮肤体系。
+
+| 元素 | 排版建议 | 规则 |
+|---|---|---|
+| 任务标题 | 基准字号、中等字重，状态靠右 | 优先业务名称，完整标题可换行；不挤满任务 ID |
+| 当前工作行 | 基准字号，主文本或次级文本 | 动宾语句；不重复标题或“慢通道”标签 |
+| 发现 | 基准字号；每条一至两行，3 条以内默认可见 | 保留影响与关键限定；来源紧邻对应发现 |
+| 范围、下一步、更新时间 | caption/sm 标尺；使用可读次级文字色 | 关键状态不能用 faint |
+| 进度 | 有数据时用步骤清单与真实数量 | 无百分比/ETA 表盘；活动用既有 mk-sweep/mk-breathe |
+| 动作 | 每张卡最多一个主动作，查看类为 ghost/链接 | 无需处理时不硬凑按钮 |
+| 长表/完整报告 | 详情/文件阅读档 | 默认卡只留摘要；宽表按需横向阅读 |
+
+卡内用 8/12/16 的重复间距；通过标题、段落和表面层级组织，避免一层卡套一层卡。圆角只用既有令牌，折叠统一 `@ui` Collapsible，状态动画只用 `mk-*`。所有图形状态同时有状态词与可访问名称。颜色不能替代状态语义。
+
+桌面沿用可拖三栏，右栏工作宽 280–560、文件阅读宽 420–1100 的现有规范。窄屏优先保留对话与 L0，任务摘要内联展开；文件仍通过同一预览对象打开。长文件名、中文长标题、18px 用户字号、320px 宽度都不得丢失必要动作。不得靠把全卡文字缩到 11px 解决拥挤。
+
+运行卡与完成卡沿用相同结构：结束后移除活动动效，当前工作区变为最终结论，保留来源与缺项。不要整张卡消失后另造结果卡造成位置跳变。最终文件卡的显示遵守 DESIGN.md：执行期仅说明草稿/保存状态，正式可打开交付物在结束并确认保存后出现；中途检查点文字可读，但不伪装成最终交付物。
+
+## 13. 技术设计：确定性状态 + 可验证摘要
+
+### 13.1 职责
+
+| 层 | 职责 | 不承担的职责 |
+|---|---|---|
+| Core | 定义任务摘要、发现、来源、动作能力的共享契约 | 不生成领域结论 |
+| Runtime | 提供真实执行阶段、工具结果、检查点和摘要候选 | 不自行宣告权限/存储/最终成功 |
+| Backend | 服务端权威投影、校验、持久化、事件发布与通知 | 不把模型叙述当执行证据 |
+| Frontend store | 按 task/run 与事件作用域更新同一快照 | 不由计时编造进度，不分别生成两套摘要 |
+| UI | 纯展示，稳定折叠/排版/动作事件 | 不直连模型，不拥有业务异步状态 |
+| Documents | 本方案、内容规范、验收与关联记录 | 不承担运行状态 |
+| 下游/插件 | 提供领域成果与受控丰富视图 | 不替代基座任务状态与权限 |
+
+优先在既有 runmgr/card/store 链路补齐投影，不另建进度微服务或独立状态仓。后台与前台按 runId 路由，前台消息仍用现有 live；后台进度使用按任务键控的结构化快照，防止共用单个 live 正文。
+
+### 13.2 候选数据形状
+
+以下是契约草图，字段名在 Core 设计评审时固定，不是可直接执行的 API。
+
+```text
+TaskSnapshot
+  taskId, projectId, conversationId, sourceMessageId
+  parentTaskId?, attemptId, runId?       # 排队时可以尚无 runId
+  revision, streamScope, sourceSeq
+  title, goal, inputRevision
+  executionState, outcomeCompleteness
+  phase { id, label, observedAt }
+  focus, coverage, remaining, nextStep
+  findings[] { id, text, impact, kind, status, sources[], revision }
+  actions[] { id, capability, enabled, reason?, confirmationRef? }
+  resultRefs[] { artifactId?, surfaceId?, version, availability }
+  lastActivityAt?, lastMeaningfulUpdateAt
+  deliveryState, error?
+
+ClientViewState                         # 展示偏好，不改业务状态
+  taskId, collapsedSections, pinned, readRevision, scrollAnchor
+  connectionState
+```
+
+taskId 在排队前持久登记并关联同一张卡；runId 表示一次实际执行，attemptId 区分新尝试。旧失败和新尝试不互相覆盖。readRevision 与 dismissed/收纳分离，用户读过不意味着执行已完成。
+
+为兼容旧客户端，ActivityCard 可添加可选结构化摘要字段并保留 Body 的精炼回退投影；旧客户端看 Body，新客户端用结构化内容。核心信息的唯一权威仍是服务端快照；不得用独立 JSON、Markdown 和 Surface 各维护一份互不核对的业务状态。Body 与 Surface 是从同一快照派生的展示。
+
+### 13.3 发布与恢复流程
+
+```text
+真实运行事件/阶段成果
+  → 运行时语义映射与摘要候选
+  → 服务端校验：归属/执行对象/来源/权限/版本/长度
+  → 原子保存快照 revision 与对应投影事件
+  → 既有 card.updated 会话流发布
+  → 前端按作用域 seq、taskId 和 revision 更新
+  → L0/L1/L2 同步呈现
+  → 关键变化进入幂等通知；L3 保留执行记录
+```
+
+持久化与事件写入须原子一致；优先使用既有事务/持久事件机制，若当前 cards API 不能支持原子更新，先补齐内部事务入口。终态正文、状态、tone 应作为同一快照发布，避免先出现失败正文后仍亮成功灯。不能只靠客户端临时合并掩盖持久状态不一致。
+
+消费顺序按**会话流或项目流各自游标**；不同流的 seq 不可比较。重复事件不二次通知，旧 revision 不覆盖新快照；出现游标间隙先对账/重放，不仅执行 `max(seq)` 后跳过未知事件。会话切换隔离响应，迟到事件按归属放回缓存或丢弃，不能写到新会话。
+
+快照读取返回与其一致的重放水位；获取期间继续到来的事件需缓冲并在快照后顺序应用。排队、启动、最终保存、通知待发送均可刷新恢复；不得只把动态发现放在内存 `agentNotes`。恢复与副作用规则与既有服务恢复方案衔接，本次不建立第二套恢复执行器。
+
+**重启对账不能把展示快照当作执行队列。** 当前等待后台槽位的 bgQueue 仅在内存，无 runId 的排队卡不在既有 run 恢复扫描范围。U2 启动对账须区分“可读历史快照”与“已确认重新拥有执行者”：没有可信持久入队凭据或执行所有者的 queued 任务转为 interrupted，并同步旧卡回退状态与材料去重状态，显示“排队任务未恢复，未开始执行”，不自动重派。只有既有执行系统确认队列恢复后，才可继续显示排队并允许晋升；首次增量不承诺队列自动续跑。
+
+### 13.4 生成式成果与普通任务卡
+
+已有 Surface 可用于对比表、报告页、审查清单；基础状态、风险提示、确认与失败始终由确定性组件呈现。后台 Surface 更新只提示“结果页已更新”，不自动切预览；需要在现有 Surface 投影策略中区分前台主动呈现与后台更新。
+
+插件禁用或页面渲染失败时，任务摘要仍可读，来源和基本动作仍可用。Surface 的动作继续走现有受控命令能力，不从摘要文本或外部材料解析可执行命令。
+
+## 14. 落地顺序与 U1 出口白名单
+
+下表是已批准的分期顺序。**首批锁定仅 U1**；U1 业务代码须另批 [U1 实施计划](2026-10-12-fast-slow-channel-display-u1-plan.md) 后方可启动。各增量的具体文件、迁移、运行材料与费用以对应实施计划为准。
+
+| 增量 | 关联需求 | 范围与依赖 | 出口 |
+|---|---|---|---|
+| U1 统一状态与精炼内容 | R01/R02/R03-a/R08/R10（骨架）/R13 | Core/UI/Frontend/Backend；旧卡兼容及状态映射；L1 骨架重排；去除原始提示词默认展示 | 见下方 U1 出口白名单 |
+| U2 持久动态任务投影 | R04（活动投影）/R05（结构）/R06/R09/R12/R17/R03-b | 依赖 U1；材料内容版本身份校正前置；Core 契约 → Backend 快照/事务/事件及无 runId 排队重启对账 → Frontend 按任务路由 → UI 动态渲染；运行时确定性阶段 | 并发、刷新、重连、乱序和终态一致；阶段活动持续更新；无执行凭据的排队任务不得永久显示排队 |
+| U3 有价值的阶段成果 | R03-c/R04/R05/R07/R10（完备）/R14 | 依赖 U2；Runtime 检查点、来源、候选摘要、通知去重；优先材料整理，再研究/生成/审查 | 选定长任务至少两个真实成果检查点；短任务可直接完成；事实、判断、缺项可分；必要动作闭环 |
+| U4 场景与可用性完善 | R11/R12/R13/R15/R16/R18 | 依赖 U3；多任务总览、修订提醒、窄屏、可选 Surface、领域适配；未支持控制能力仍不暴露 | 典型场景完成真实浏览器及用户评审；精炼度与可用性目标有实际记录 |
+
+跨仓以 Core 类型权威优先；Backend vendored Core、Frontend/UI 消费固定提交；Dev 推进精确 gitlink，组合测试后评审。视觉规则变动需要与 DESIGN.md 配套；只消费既有令牌时不为本任务无故新增色板。
+
+### U1 出口白名单（定稿）
+
+**须交付并可判定**
+
+- 排队 / 进行中 / 已完成 / 执行失败 状态词与状态灯一致；失败使用失败语义（不得再以「完成」灯表示失败）
+- 建卡默认 Body 为 L1 骨架，不以原始任务指令（≤400 字截断）作为主视图
+- 无阶段成果时显示诚实占位：「尚无阶段结论，正在读取材料」或等价文案
+- 完成卡骨架：结论 → 最多 3 要点 → 范围/缺项 → 产物入口（有则显示）→ 必要下一动作
+- 简单问答不产生空进度卡；仅登记成功才说「已登记」，仅实际开跑才显示「进行中」
+- 旧卡兼容：历史 `done + danger` 在新客户端映射为失败展示，不崩溃
+- DESIGN.md / 令牌 / Collapsible / `mk-*` 相关守护通过
+
+**明确排除（不得用 U1 验收）**
+
+- 运行中真实业务发现、来源定位、检查点驱动摘要（R03-c / U3）
+- 按 `taskId` 持久 `TaskSnapshot`、revision/seq 对账、材料内容 hash 身份（U2）
+- 无 runId 排队任务重启 → interrupted 对账（U2）
+- HITL 双入口提交中 / 超时未知 / 幂等闭环完备（U3）
+- 窄屏完整能力、多任务总览、Surface 增强、修订提醒（U4）
+- 暂停 / 独立取消 / 续跑等未支持控制能力
+
+合并 U1+U2 为基础投影批须**另行明确批准**；即便合并，阶段发现仍属 U3。
+
+## 15. 验收、证据与失败判据
+
+所有下面的运行场景为**计划验收，NOT_RUN**。示例数据只用于评审排版，不当作真实链路通过证据。
+
+| 用例 | 关联需求 | 关键观察 |
+|---|---|---|
+| A01 三个附件、无文字直接发送 | R01–R05/R10 | 已确认接收 → 同卡排队/运行 → 有成果则发布 → 完成摘要与选择；选定长材料验证两个真实成果检查点，短材料可直接完成；不重复派发 |
+| A02 小材料加明确分析要求 | R01/R02/R04 | 即时答复与现有兜底路由一致；不声称尚未登记的任务已运行 |
+| A03 三个后台任务 + 前台对话 + 第四任务排队 | R02/R06/R09 | 各任务归属正确；排队晋升复用 ID/卡；前台正文不串后台 token |
+| A04 部分解析失败/无可解析文本/材料超预算 | R03/R05/R08 | 显示已覆盖、缺项与影响；解析与分析完成不混同；无法分析则不生成假摘要 |
+| A05 用户追问与补充重点 | R01/R07/R15 | 读取当前快照；新要求生效范围明确，未实现动态输入时不假承诺 |
+| A06 早期发现被推翻、来源文件更新 | R05/R17/R18 | 当前结论修正、历史可追溯；重要更正通知一次；同名等长内容更新不得命中旧材料结果；过期版本不覆盖最新 |
+| A07 断网、刷新、换会话、重复/乱序事件 | R06/R09/R12 | 保留最后快照；恢复水位一致；状态不回退；旧会话数据不写入新会话 |
+| A08 模型失败、预算耗尽、摘要不可用、服务中断 | R08/R09/R14 | 正确显示失败/中断；包含无 runId 的排队任务重启后对账及材料去重释放；基础状态与既有成果仍可读；无自动副作用重试 |
+| A09 前台忙时后台完成、通知重投 | R04/R10/R17 | 结果卡先可读；汇报待空闲；重投不重复通知或派任务 |
+| A10 同确认双入口与重复点击 | R07/R11 | 提交中、成功、拒绝、超时未知、过期/已处理响应都一致；重复点击只执行一次；右栏关闭也可处理 |
+| A11 文件正被阅读、Surface 后台更新/插件关闭 | R11/R12/R16 | 不抢焦点、不切文件；插件关闭核心任务卡不缺失 |
+| A12 未授权跨项目/用户来源、读权限撤销 | R05/R09 | 新摘要、来源与历史缓存无越权；只显示许可范围内内容 |
+| A13 文件保存失败、文件已更新/已移除 | R08/R10/R17 | 不出现虚假可打开工件；版本与保存状态准确；有可读摘要不等于已保存文件 |
+| A14 320/390/736/1024/1440 宽度与用户字号档 | R11/R13 | 无页面级横向溢出，必要动作可达，键盘/屏幕阅读/减少动效符合规范 |
+
+验证分三层：契约与投影测试确认状态/顺序/并发；真实模型任务前后对照确认阶段成果质量；真实浏览器与用户任务确认排版和工作价值。不能用 mock 进度验证真实模型发布了有用摘要。
+
+行为改动按 policy/delivery.md 真实模型要求执行：固定候选组合、同材料同任务前后对照、记录模型/参数/费用/失败及来源。正式检查使用 `make evidence` 写入 precheck、task-sync 和相关测试原始输出；Dev CI 在 PR HEAD 上的 `make test`、`make build` 作为 GATE，作者本地记录仍为 SELF。设计文档检查不代替这些运行验证。
+
+可用性记录至少覆盖三类任务：材料整理、分析审查、文档生成。请代表性用户完成第 1 节三问并定位一条来源、处理一次确认、找到一份结果；记录完成时间与错误。精炼度以“是否漏掉关键限定/风险、是否能支持下一步工作”评判，不能只统计字数变短。
+
+实施停止/回退条件：发现状态串任务或越权内容；终态与存储不一致；修订导致当前有效结论丢失；摘要循环显著超预算；关键确认被折叠藏起；真实模型阶段成果持续无依据。先回退受影响展示/摘要增量，保留原执行与已保存结果，按实际影响重审。
+
+## 16. 评审与当前进展
+
+| 项目 | 当前状态 |
+|---|---|
+| 当前源码核对 | SELF；固定对象与输出在任务卡；不等于运行验收 |
+| 需求拆解 / 需求评估 / 需求表 / 方案设计（阶段 1–4） | **已通过**（2026-10-12，对象版本 r1.1；评审人 weichen；依据：用户确认评审结论计划并指示落地） |
+| 实施计划（阶段 5） | U1 计划见 [u1-plan](2026-10-12-fast-slow-channel-display-u1-plan.md)；**待用户批准该计划后**方可启动业务代码 |
+| 辅助设计审阅 | 七个视角 SELF 辅助分析已纳入 r1；不提升为 REPLAY/GATE |
+| 业务实施、真实模型实验、运行与浏览器验收 | NOT_RUN |
+| 推送、PR、合入、部署 | 本方案任务未执行；文档推送/PR 须另获授权 |
+
+本次推进的是快慢通道用户展示设计，不改变现有附件路由和生成式 UI 规划的批准状态。与既有恢复/团队存储方案的重叠仅为消费其执行终态、权限与恢复能力；新增持久字段和事务入口须评审后协调，不自行修改其他任务的主记录。
+
+辅助审阅覆盖一致性、范围、可行性、设计、产品、对抗与安全七个视角（其中一致性/范围、设计/产品/对抗/安全分别由同一子代理分析，并非七名独立审阅者）。采纳并自行核对后修订五类问题：两次成果检查点只用于代表性长任务；新增要求的生效文案不误导；确认双入口补提交与未知结果状态；材料版本复用需实际内容身份；无 runId 排队任务重启时不能假装仍有执行者。
+
+r1.1 相对 r1 的定稿修订：R03 切分为 a/b/c；U1 出口白名单与排除项写入 §14；首批锁定仅 U1。摘要次数/窗口与性能数字仍为候选参数。**设计批准不等于实施授权**；批准 U1 实施计划后另开实施任务，本设计任务不自动启动写代码。
@@ -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` 按本表交付。
@@ -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 类业务写直执、扩大白名单至其他内置写命令、自动触发动作、动作结果自动改写页面。
@@ -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；后续按「已知边界」清单演进。
@@ -0,0 +1,539 @@
+---
+title: RDM 功能、实现与计划矩阵及追溯审计和权限闭环整改方案
+date: 2026-10-12
+type: fix
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 功能、实现与计划矩阵及整改方案 r1
+
+负责人：weichen；编制：Codex；核对日期：2026-10-12（北京时间）。
+本稿供人工评审，尚未批准实施。此次仅研究、读取运行元数据与保存报告；未实施业务代码、操作业务数据库、执行测试、部署或重启。
+
+保存说明：Dev 首次启动检查因 Backend 的 `index.lock` 返回 `SHARED_WORKSPACE_BUSY`。按 `AGENTS.md` 任务启动门禁，不创建项目 worktree、不写共享检出；报告暂存为独立交付文件。入仓时由项目 owner 排除共享写入冲突后，在登记任务 worktree 保存到 Documents proposals，并更新 INDEX/PROJECT 的入口。此次没有修改这些入口。
+
+### 发布补记（2026-10-12 入仓时）
+
+本稿冻结观察之后的运行时变化（独立于上文，不回改冻结记录）：
+
+- dev 槽位部署时序（北京时间）：14:54 `rdm@310c3fe` → 15:50 回滚普通基座 `dev@4bf6e4a`（根页此时已 200 服务 React 资产）→ 16:37 刷新为 `dev@0d224ff`（权威 main 组合，backend=5e8ada7 / frontend=cc233fe，plugins 目录无 RDM 插件）。「根页 404 与缺少嵌入产物一致」的判断已被 main 组合现状超越；RDM 组合产物与门控验收仍开放（U1/PR #450 线）。
+- 本稿 U2 执行端问题表第 1-5 行与第 7 行前半已按本方案在 Agent-System-RDM 合入（PR #251/#254/#256/#258，红测先行，CI 绿）；第 6 行归 U4、第 7 行后半归 U5、第 8 行待私域语义设计。行号引用基于冻结源码 1ee2b300，合入后有所漂移。
+
+## Goal Capsule
+
+使创建者能在实际使用的 dev 服务中管理项目成员与文档职责，使管理员能创建专业角色并配置权限，使编制、审核、批准人员完成同一份文档的审签，并能从实际页面追溯来源、操作与历史。
+
+复用现有 RDM 项目、成员、权限、两树一网与审签组件，先修组合产物及执行端缺口，再接现有项目设置、系统管理与文档工作区，最后按真实账号验收。完整目标仍覆盖全部 34 UR、68 SR、10 F，不以本次五个问题修好替代全系统交付。
+
+本稿终点为可评审矩阵和方案。实施、真实账号测试、数据迁移、部署及正式验收各在对应授权后进行。当前用户请求未授权这些动作。
+
+## Product Contract
+
+### 来源与权威
+
+1. 本轮用户报错及补充：访问 `localhost:8788`，58880 是 FRP 映射，实例为 dev；要求核对全系统，重点追溯审计、三权、项目成员、系统角色、权限矩阵。
+2. RDM `docs/requirements/README.md:15-32` 规定的 V2.2 正文与 U0/Q 裁定；重点 `01-用户需求与系统需求.md`、`03-产品设计方案.md`、`08-核心数据模型-两树一网.md`、`10-实施推进方案-基座与下游二次开发.md`。
+3. RDM 原始用户补充 `docs/materials/meeting-sources/user-supplement.txt` 和 `user-design-ideas.txt`；原始内容用于解释需求，不反向覆盖较新裁定。
+4. Documents `docs/proposals/2026-10-11-rdm-final-target-completion.md`、模板子方案、两树一网追溯展示方案；主计划与任务卡存在历史批准记录，页首残留“待评审”不能单独否定批准。本次整改路线仍需评审。
+5. RDM `docs/records/2026-10-11-requirements-evidence-matrix.md` 是逐条维护入口；Documents 副本是旧附件。`2026-10-12-final-acceptance-ledger.md:39-53` 全量运行验收仍为 NOT_RUN。
+
+UR-21（系统角色权限）、UR-22（项目和成员）、UR-24（文档三权）均为本期 P0 已定需求，不能再解释为尚未决定是否做。管理权不赋予代编、代审、代批权；文档编制唯一、批准唯一、审核至少一人，三种职责互异。项目创建者在平台上限内覆盖项目权限。私聊、原件和个人草稿私有，受控文档按职责或显式授权读取。
+
+### 核对对象及证据边界
+
+| 对象 | 固定版本 / 观察 |
+|---|---|
+| Dev | `8c1edbebece8212ec8c0cd9e646b4b0592b1503d`；研究初始为 `72f6a679`，期间由其他任务更新 |
+| Backend / Frontend | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` / `cc233fec908d0f8c12193042942b94ad68508091` |
+| Documents / UI | `9d9b1523c87dc4ba178d143a8b966a77be9b320b` / `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700` |
+| RDM 本地源码 | `1ee2b300a9c898ef5b9e2febafa6b0f2eb871c15` |
+| dev 当前 RDM 部署来源 | `310c3fe42fec2416b8b1e1e72e00ad2e53b58130`；相对 1ee2b300 仅四个 pins 与任务卡变化，本文 RDM 业务行号仍适用 |
+| dev 当前进程文件摘要 | `420654002eb0cdc28ce9d90a8d258f215192dee78ff74195db2b2657b3fe3fff`；2026-10-12 15:04:37 核对 |
+| 服务访问 | user 确认 58880→8788；本轮直接 GET 8788 根路径为 404，未登录 GET `/api/commands` 为 401 |
+| 对照实例 | 9015 的命令清单有 enabled 的 inspect 命令；这是另一实例，不能作为 dev 通过依据 |
+
+15:24:29收尾刷新：Dev主检出由其他任务推进至 `0d224ffcab82cab7def2c0b0cc36d2e6d02ce3dd`，Documents至 `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`；RDM业务源码、Backend、Frontend、dev部署来源及进程摘要均与上表一致。8788根页仍404，未登录命令清单仍401。新收据 `runtime-refresh-receipt.json` 保留该时间点，不覆盖15:04的调查收据；本文RDM需求与业务判断仍以固定1ee2b300为对象。
+
+源码阅读、运行登记、HTTP GET 与本稿审阅均为 SELF；没有复核 GATE/独立 REPLAY，不作业务 PASS 判定。完整命令输出由 `make evidence` 保存为随附收据，未手工重构。测试文件存在只表示已有测试资产。
+
+### 追溯审计故障结论
+
+2026-10-12 **14:50:06.701 北京时间** 的 `unknown or disabled command` 是命令总线 `Resolve` 阶段失败（Dev Backend `internal/cmdbus/cmdbus.go:252-254`），服务将 rejected 映射为 HTTP 400（`internal/server/server.go:1012-1014`）。该阶段尚未进入 RDM 的项目/审计权限判断；放宽权限不能注册一个不存在的命令。
+
+同一 dev 的部署历史显示：13:38:38 启动 `dev@4bf6e4a` 普通基座，14:50:48 停止，14:54:49 启动 `rdm@310c3fe`。用户确认访问这台服务。基座入口仅 import 基座 app；RDM `main.go:18-23` 才 import `plugins/rdm`，后者 `plugin.go:17-21,173-179` 注册命令。因此，故障时**正式前端暴露了研发审计入口，而同实例运行普通基座、没有 RDM 命令**，有部署历史和组合根源码支撑。
+
+此后其他任务已切换部署，不意味着审计运行验收完成：当前 8788 根页 404，命令清单需有效登录才能核对。本轮未借用账号、创建凭证或发送会写审计回执的业务 POST，未重现当前登录态下 capabilities 调用；历史故障定位与当前修复验收分开记录。
+
+现有 Frontend 已增加七命令门控及人话错误，见 `src/workspaces.ts:22-36`、`src/store.ts:794-801`、`src/rdmErrors.ts:16-24`。仍有三项接线缺口：
+
+- RDM `Makefile:39-40` 只 Go build；Dev `scripts/svc.sh:1446-1464,1594-1600` 对 RDM 也只构建 Go 并复制独立 `web/`。更新 frontend pin 没有构建及嵌入 React dist；Backend `web/embed.go` 要求构建前具备 dist。当前根页 404 与缺少嵌入产物一致。
+- `AdminZone.tsx:37,67-71` 的声明管理分区没有消费七命令门控；插件注册失败允许保留部分能力（Backend `internal/app/compiled.go:198-202`），所以“插件列表有 rdm”仍不足以证明审计页可用。
+- 错误分类把 403 和 401 都解释成登录失效；实际已登录但无权限时应展示权限拒绝。原始 receipt.reason 要保留。
+
+密码字段未处于 form 的浏览器提示是独立问题，不会造成命令注册失败。React 主动改密、登录及强制改密已有 form 修复；RDM 独立 web 的令牌 password 仍位于普通 div。修复有源码记录，当前浏览器验证 NOT_RUN。
+
+### Requirements：本次整改验收要求
+
+| ID | 用户可见行为 | 原需求映射 | 判据 |
+|---|---|---|---|
+| R1 | 同一正式入口加载匹配的研发前端与 RDM 后端 | UR-08/25，SR-D1/D6/G3/G5 | 登录后七命令齐备并可查询有数据项目；无 RDM 时不出现可进入后即 400 的页面 |
+| R2 | 创建者在项目设置添加、移除、调整成员 | UR-22，SR-G9/G10 | 选择有效系统账号，加入后同 projectId 可见；最后负责人保护；撤权立即影响现有访问 |
+| R3 | 管理员创建/停用专业角色、分配账号并设默认和上限 | UR-21，SR-G6/G7/G8 | 自定义角色持久化；重启保留；项目设置不得扩大系统上限 |
+| R4 | 系统和项目矩阵解释实际允许/拒绝 | UR-17/21，SR-G2/G6/G7/G8 | 同一动作矩阵结果与 API/命令/工具/后台执行一致，能显示默认、上限、覆盖与原因 |
+| R5 | 创建者按文档分配编制、审核、批准 | UR-24，SR-C7/G9 | 有效项目成员、三种职责互异；资格不足明确说明；无职责任务保持可见等待 |
+| R6 | 三个人完成固定整文版本审签 | UR-24/25，SR-C3/C7/C8/D6/G3/G5 | 非编制不可改正文；审核可批注/驳回；所有审核完成才批准；旧票不能签新正文 |
+| R7 | 图、历史、导出及文档读取符合当前授权 | UR-08/23/25/33，SR-D/G/N4 | 合法职责人员能读自己的文档；跨项目/私域不可见；审批与导出是同一固定快照 |
+| R8 | 界面、对话、工具、卡片访问同一对象与执行服务 | UR-10/16/27/28，SR-E/F，F-06 | 右栏关闭仍可完成支持的动作；模型不能伪造身份或自动签字；撤权及迟到结果不旁路 |
+
+### 功能、实现、缺口与计划矩阵
+
+“已有”仅描述固定源码中的能力；“UI 缺口”指正式用户路径未闭合。除特别列出的只读观察，全表运行验收 NOT_RUN。U 编号均带方案名称，避免“追溯展示 U3”和“完整目标 U3”混用。
+
+| 功能域及需求 | 当前已有实现 | UI/对话与执行缺口 | 后续工作与现有计划归属 |
+|---|---|---|---|
+| 项目身份/成员：UR-22；G9/G10 | 全局研发项目、生命周期、成员持久表、成员可见同项目目录；局部 #203 | 项目设置无成员页；有效账号目录及可信宿主映射未闭合；新旧成员守卫不同；建项与owner写入非原子 | 本稿 U3/U6；完整目标 U2 |
+| 角色/权限：UR-21/17；G2/G6-G8 | 12 动作、全局 cap、项目成员 override；cap∩默认/覆盖 | 角色固定 admin/owner/member；没有专业角色CRUD或完整矩阵；多个业务入口绕过 cap | 本稿 U2/U4/U6；完整目标 U3 |
+| 三权/版本：UR-24/25；C3/C6-C8 | 文档职责默认及章节覆盖 #205；章节审签；持久提案、整文内容快照 #217 | 没有分配页；schema 与可信身份互斥；审签仍按章节；非编制写入、审核驳回、整文批准快照未闭合 | 本稿 U2/U5/U6/U7；完整目标 U3/U8，模板子案 U3-U5 |
+| 资料接收/解析：UR-01-04/18；A1-A5/B1-B7 | 原件、三态相关性、MD/TXT/DOCX、快慢处理；台账私域 #209；锚点 #211 | PDF/表格/PPT/图片未完整接线；三个附件无文字实测、60秒反馈及10分钟级管道没有实际签收 | 完整目标 U5/U9/U14；在本稿 U8 衔接 |
+| 结论/冲突：UR-07/26/34；B8/B9/B11/B12 | 提议确认、词面冲突、指定冲突对关闭与水位修复 #215 | 完整候选组、文档依据/项目结论两层裁决、来源变更影响与通知闭环未充分完成 | 完整目标 U6；本稿 U8 衔接 |
+| 模板/全文档：UR-05/15；C1/C2 | 69 类型 catalog #207；正文 registry 仍4模板、3文档类型 | 目录登记不是全部模板；结构/格式/发布版及XLSX、全量生成审签导出未验收 | 完整目标 U7→U8→U16；本稿 U8 衔接 |
+| 对话生成：UR-10/11/12/16；E1-E6/F1-F5 | 模型 compose、持久提案、原子采纳、整文内容快照 #217/#219 | 全动作自然语言及工具投影缺失；依据完整性、差异采纳与真实模型/用户链待验证 | 本稿 U7；完整目标 U8/U9 |
+| 私域/项目协作：UR-23；G11-G13/N4 | 基座owner会话隔离；上传及确认资源约束 #209 | 同项目草稿/原件/受控文档全读面、Host检索、明确只读分享与撤权需贯通 | 本稿 U2/U4/U5；完整目标 U3/U5/U9 |
+| 追溯/审计/历史：UR-08/25；D1/D5/D6/G3/G5 | 两树、一般网/合规网、原子事件、inspect和导出；追溯展示 #195/#197/#201/#213 | 用户dev曾未组合RDM；新产物无React根页；Host审计覆盖仍缺；四链/完整矩阵实际展示未全部接线 | 本稿 U1/U7/U8；完整目标 U4/U11/U14、F-09 |
+| 需求/风险/合规：UR-09/33；D2/D7-D11 | 控制节点/候选边/确认 #231、req→graph #233、UR→SR及需求快照 #235 | 真实风险→措施→验证及SOUP、六维分解、四链业务录入、专家校准及真实交付尚待验证 | 完整目标 U11/U14；本稿 U8 衔接 |
+| 法规双通道：UR-13/14；F3 | #236已实际HTTP抓取候选、摘录核对、快照；“只模型URL”旧结论过期 | 真实权威素材、失败/冲突/版本场景及首批模板法规闭环仍未签收 | 完整目标 U12；本稿 U8 衔接 |
+| 快慢任务/卡片：UR-27/28/29/30；B10/E/F | 卡片/小队；slow保存原文且可重新入队 #219 | slow台账未保存project/owner，恢复入队传空项目；取消/恢复/重新授权、同源卡片与模型结果需闭合 | 本稿 U7/U8；完整目标 U9/U13 |
+| 阶段/结项：UR-06/17；C5/G2 | 阶段序列、三级门禁、close/只读 #226 | 主要检查章节无版本/正文“待确认”；阶段适用文档、批准快照、验证过期、N/A和旧确认缺失 | 完整目标 U10；本稿 U8 衔接 |
+| 团队存储/执行/运维：G16/N1-N5 | PG方言 #224、迁移 #242、sandbox #244、备份发布/长驻工具 #248；Dev存储组合#446于收尾已合入 | dev实际使用档位未核；RDM多实例租约/恢复、容量、故障/回滚验收未签收；复用Dev已交付存储能力 | 完整目标 U13/U14；衔接存储/恢复总案 |
+| 自举/完整交付：UR-19；G4 | U14台账骨架 #246 | R1-R15与九层验证仍NOT_RUN，不能由局部merge宣称“系统完成” | 本稿 U8；完整目标 U14 |
+| 飞书/变更/遗留扩展：UR-20/31/32；G1/G14/G15/D4/F-01-F-10 | 目标和依赖有记录 | 飞书、完整变更引擎、细粒度分享、权重、代码集成、遗留决策、难度机制仍后续；后移不等于取消 | 完整目标 U15；F-06→U9/U14，F-09→U11/U14，F-10待用户标准模板 |
+
+覆盖口径：SR 分组 A5/B12/C8/D11/E6/F5/G16/N5，共68；UR34、F10的逐条定位见附录。项目能力、实际UI、工具路径、部署与验收应各列证据，避免一个“完成”字段盖住五种状态。
+
+### 已静态确认的执行端问题
+
+| 问题 | 固定源码定位 | 必要修正 |
+|---|---|---|
+| 审签接口无可成功参数组合 | RDM `plugin.go:500-501,509-510,518-519` 强制 reviewer/actor/approver；`:1461-1462,1488-1489,1515-1516` 拒绝这些字段；Backend `cmdbus.go:384-402` 检查required | schema删除身份输入，只认认证actor，项目/固定提交对象必需；补真实总线和HTTP测试 |
+| 新旧成员命令绕过不同约束 | RDM `projects_api.go:317-380` 新路径不查member.manage上限；`plugin.go:2212-2245` 旧路径直接Remove；`members.go:54-59` UPSERT可降级最后owner | 所有入口共用服务，原子保持最后owner、归档状态、账号有效性与上限 |
+| 配置的建项权限未作用于创建 | RDM `plugin.go:2041-2054` 仅检Actor非空，ActProjectCreate没有接入 | 按专业角色有效权限判建项，不能一律管理员限定或一律认证即可 |
+| doc.write不等于编制职责 | RDM `plugin.go:2510-2536,2581-2588` 仅通用写动作；`doctree.go:152-168` 仅状态守卫 | 所有生成/编辑/采纳/改来源写入口再查本文档编制职责 |
+| 阶段只读约束未接业务读面 | RDM `perms_api.go:80-100` AuthorizeDocRead生产路径未消费 | 列表、详情、搜索、导出、Host及恢复统一资源授权 |
+| 角色/上限模型维度不足 | RDM `perms.go:42-55,70-94,310-324` 固定默认，cap主键仅action | 持久专业role的默认/上限，解释有效权限，不只在UI加checkbox |
+| 审核人不能驳回，职责可换人继承旧审核 | RDM `review.go:243-245,276-279` 读当前职责，ReviewCard未冻完整职责；`:111-119,141-149` 可覆盖职责 | 冻结整文提交的职责/策略版本；改职责使受影响审核失效；审核人可驳回，编制撤回独立 |
+| 草稿列表未按个人/文档资格过滤 | RDM `draftproposal.go:135-150` 无actor；`plugin.go:2567-2578` 仅doc.read | 私人提案按owner；受控文档按职责/明确授权；分页/计数同样过滤 |
+
+上述为源码确定或静态路径推导，没有在真实账号下重跑。现有 `plugins/rdm/three_sig_test.go:18-25,73-75` 构造Actor并直接调handler，未走登录和总线。函数名“RealAccounts”不能提升为真实账号验收。
+
+## Planning Contract
+
+### KTD1. 组合产物与正式入口
+
+推荐 RDM 产品用固定 pins 的 React 前端与 RDM Go 组合二进制形成正式产物，复用 Backend embed 的公开构建机制。RDM构建必须构建frontend→装入backend/web/dist→Go编译；不能只升级gitlink。构建在独立物化目录完成：从固定pins复制/物化基座组件，以Frontend既有frontend/ui邻接布局构建，将dist写入该目录中的Backend，再由隔离构建映射消费；RDM仓的pins检出保持只读，不把产物或源码修补写进pins。发布清单记录 RDM/backend/frontend/ui SHA、dist摘要、二进制摘要和能力契约版本。构建/安装阶段拒绝声明“完整Web产品”但缺index/bundle的产物。
+
+独立 `RDM:web/` 留作历史诊断入口，退出正式产品唯一流程，迁移前明确旧链接兼容和私有访问策略。若用户选择独立静态React+API部署，则同样固定双产物清单、同源反代与认证；这是部署形态备选，不能复用旧斜杠工作台宣称正式管理界面已完成。
+
+### KTD2. 一套执行端授权及项目身份
+
+账号、认证、平台管理员和通用资源执行边界由基座维护；研发项目/成员、专业角色、领域动作、职责与文档状态由 RDM 维护。公开扩展不足时沿 RDM 的四要素扩展申请，禁止导入基座internal或修改pins源码。
+
+新旧命令、UI、工具、后台恢复都调用同一 RDM 应用服务。平台账号目录只提供授权管理所需的最小公开身份/有效状态与分页，不提供私聊/原件；`AdminProvider.IsAdmin` 已有，不能再当缺失能力重建。创建者、当前owner、RDM域管理员、平台管理员各保留来源，审计能力不自动升级成绑定/成员写权。RDM项目创建与初始负责人必须同事务；Host映射检查双方资格并可恢复重试，不能以复制个人项目解决共享身份。
+
+现有公开EXT-8仅接主体和projectId，HTTP自有工件命中不咨询回调，共享列表按整项目放行；因此本稿U9先提供通用资源级公开授权契约及消费接线。可信资源类型/ID、资源属主、项目和动作由执行端解析，RDM只作领域判定；注册新策略后，域内自有/共享读取、列表、检索、Host及下载均执行同一判定，不能仅在RDM命令handler加守卫。未注册的普通基座保持既有行为；RDM受控产品若缺必要契约，禁止启用扩大共享读取的旧回退。衔接已有协作存储KTD13动作授权，复用当前内部项目动作槽，补资源维度及公开注册，而非再造平行授权器。
+
+读路径不修复业务数据。授权检查覆盖每个请求与资源，未知身份/关键能力默认拒绝；这与现有规范及 [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) 一致。本文更细的项目和职责规则来自已批准需求。
+
+### KTD3. 专业角色与矩阵
+
+区分四个对象：平台管理身份、项目管理关系、专业角色、文档职责。用户界面的 ADMIN/USER、成员表的owner/member以及文档三权不是专业角色CRUD。
+
+专业角色在系统范围建定义，保存稳定roleId、名称、停用状态、版本、动作默认、动作上限及账号关联。owner/member继续表示项目关系，roleId不写入members.role字段。管理员设置每角色上限；负责人只在许可的成员/项目范围覆盖。首版每账号一个生效专业角色，避免未经确认采用多角色叠加；未来多角色规则另行评审。
+
+有效权限在服务端计算：平台硬禁止 ∩ 角色上限 ∩（项目显式覆盖或角色默认）∩ 资源关系/阶段/状态/职责。文档签字资格还要求当前有效成员、已分配职责、互异历史、固定提交轮次；指派职责本身不解除上限。矩阵显示最终结果和第一拒绝原因，UI不重新计算。
+
+旧cap转换为同等限制，固定默认映射到兼容内置角色，旧override不被扩大。变更前干跑列出有效权限差异；同级迁移不得扩大有效权限。新角色或权限新授予由有权管理员明确执行。新增schema迁移需向前迁移及恢复方案，不能把旧二进制直接启动在不兼容新库上。
+
+### KTD4. 整文三权与历史保全
+
+一份受控文档对应一组编制/审核/批准。项目设置提供文档清单与批量分配入口；项目默认职责规则如需提供，须单独定义生效/覆盖语义，不能悄悄把成员的通用角色当所有文档职责。章节可分配贡献工作，正式整文签字不采用章节覆盖改变整文责任。
+
+整文提交冻结：文档ID、有序章节集合及版本、整文内容、模板版本、依据快照、编制/全体审核/批准人、职责版本、策略版本、提交轮次和完整内容摘要。现有整文内容快照可复用，需补这些治理字段并绑定审批、历史和导出。未知事件版本或不可还原必须报错。
+
+签字取可信actor，HTTP不能传reviewer/approver替代主体。智能体可以准备正文、修改提案、批注建议和待提交操作；人的审核/批准须由该人的认证会话确认，模型无自动签字权。审核人可批注/通过/驳回但不改正文；编制撤回单列。职责变更、撤成员、改正文/依据/模板使受影响待审结果失效，不能换职责让原作者自审同一提交。已批准历史保留，下一正式版本重新审签。
+
+旧章节审签作为历史证据保全，不聚合成“整文已批准”；迁移时对活动轮次作显式处理，首个整文版本重新签署。没有明确规则时暂停有关旧轮次，不静默迁移票据。
+
+### KTD5. 现有界面与对话接线
+
+沿三栏：左侧项目/会话，中间对话，右侧工作/文件。系统管理新增“角色”“权限”；现有项目设置新增“成员”“项目权限”“文档职责”；文档预览/工作卡提供“编制、审核、批准”状态及动作。审计仍用四入口并补受控链/矩阵；不新增独立控制台或第二预览。
+
+项目设置读取 `canManageMembers/canConfigurePermissions/canAssignDuties` 等实际能力，普通成员可读自身资格但不可管理。系统角色、账号全局专业角色关联和全局上限由平台有权管理员配置；项目成员页显示该关联并管理项目成员关系，不授予创建者修改账号全局专业角色的权限。RDM域管理员的业务管理范围保留，是否可改平台上限不从审计兜底权限推断。矩阵分“角色×动作”和“项目成员×动作”，职责清单则“文档×编制/审核/批准”，避免一个表混淆三种对象。
+
+所有页面共享单一能力状态所有者；七命令门控同时约束工作区、声明管理分区和已挂载页面。退出登录、切项目、能力撤销应作废旧结果。请求generation/seq处理快速对象切换与历史查询；计数缺失显示“未提供”，失败不显示空数据。401/403、能力缺失、参数/状态冲突、服务失败分别呈现并保留原receipt。
+
+对话和工具投影使用原子领域动作、真实project上下文及typed CommandResult；高危命令带conversationId和确认卡上下文。自然语言解析出的用户/项目名称仅作查找候选，最终使用稳定ID并校验。不把手写斜杠或登记handler当自然语言能力已就位。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart LR
+  UI[系统管理 / 项目设置 / 文档工作区] --> C[同源命令与确认回道]
+  Chat[对话 / 工具 / 工作卡] --> C
+  C --> I[基座可信身份与当前项目]
+  I --> A[RDM统一动作与资源授权]
+  A --> P[项目 / 成员 / 专业角色策略]
+  A --> D[文档职责 / 整文提交 / 审签]
+  D --> E[原子事件 / 正式快照]
+  P --> E
+  E --> R[审计 / 历史 / 合规 / 导出读面]
+  R --> A
+```
+
+```mermaid
+stateDiagram-v2
+  [*] --> 等待分配
+  等待分配 --> 编制中: 指派有效三权
+  编制中 --> 审核中: 编制人提交整文快照
+  审核中 --> 待批准: 所有审核人通过
+  审核中 --> 编制中: 驳回 / 撤回 / 快照失效
+  待批准 --> 编制中: 驳回 / 撤回 / 快照失效
+  待批准 --> 已批准: 指定批准人确认
+  已批准 --> 编制中: 新内部修订
+```
+
+```mermaid
+sequenceDiagram
+  actor Creator as 创建者
+  actor Writer as 编制人
+  actor Reviewer as 审核人
+  actor Approver as 批准人
+  participant Service as 统一文档服务
+  Creator->>Service: 分配有效成员及职责
+  Writer->>Service: 提交固定整文 / 版本 / 职责 / 策略
+  Reviewer->>Service: 认证身份审核同一提交轮次
+  Service->>Service: 校验全部审核及当前授权
+  Approver->>Service: 认证身份批准该提交
+  Service-->>Writer: 正式版本与固定快照导出
+```
+
+## Implementation Units
+
+本稿U1-U9为整改任务包，按依赖安排；不同于既有方案U号。U9为审阅补入的公开契约前置，编号不重排。责任角色为后续立项时指定的Dev组合owner、RDM实施者、Frontend实施者和独立审阅者。本轮不代指具体执行人。工作量是待排期的估计区间，不是工期承诺，项目数据量/迁移规模核定后更新。
+
+| 本稿工作包 | 依赖 | 优先级 | 交付内容 | 粗估工作量 | 对应完整目标总案 |
+|---|---|---|---|---|---|
+| U1 | 无 | P0 | 正式产物/根页/审计入口与实例证据 | 2-4人日 | U4/U11/U14及追溯展示补闭环 |
+| U9 | 无；与U1并行 | P0 | 公开资源/账号/宿主资格契约及基座消费接线 | 4-7人日 | X1/X2、U2/U3及存储KTD13 |
+| U2 | U9发版与RDM升pins；schema局部修正可提前 | P0 | schema、统一执行端与私域安全收口 | 3-5人日 | U2/U3/U8 |
+| U3 | U2；账号目录扩展 | P0 | 项目成员/唯一身份/有效账号闭环 | 3-5人日 | U2 |
+| U4 | U2/U3 | P0 | 专业角色与解释矩阵 | 4-7人日 | U3 |
+| U5 | U2/U3/U4 | P0 | 整文三权与批准快照 | 6-10人日 | U3/U8 |
+| U6 | U3/U4；职责页依赖U5 | P0 | 系统/项目管理页面 | 4-6人日，可与服务契约后并行 | U2/U3/U8 |
+| U7 | U5/U6 | P0 | 对话/卡片、审计完善、真实用户闭环 | 4-7人日 | U8/U9/U11/U14 |
+| U8 | 对应已有基础及U7 | P1并保持既定需求优先级 | 全系统余量、模板/法规/阶段/团队验收 | 各子任务另估 | U5-U16 |
+
+### U1. 固定产品组合并恢复审计正式入口
+
+**Requirements：** R1/R7；**责任：** Dev组合owner＋RDM构建owner。**Files：** RDM `Makefile`、`scripts/pack-release.sh`；Dev `scripts/svc.sh`、`modules/backend/web/embed.go`（复用机制）、Frontend `src/store.ts`、`src/workspaces.ts`、`src/components/AdminZone.tsx`、`src/components/RdmAuditWorkspace.tsx`、`src/rdmErrors.ts`。
+
+**Approach：** 先基于现有实例历史保留故障证据，固定RDM+四pins+实际bundle+二进制和数据绑定。补 pinned React embed构建与产物完整检查；统一全部入口能力门控、可见失败和错误分类。插件必要注册失败不能静默声明完整产品可用，可让启动拒绝或标为不可用，但不可留下可点击的半套管理面。正式环境切换需批准，备份和恢复与已有svc方案衔接。
+
+**Tests：** 扩展 Frontend `test/workspaces.test.ts`、`test/rdm-errors.test.ts`、`e2e/plain-base.playwright.ts`、`e2e/rdm-audit.playwright.ts`；Backend `internal/app/compiled_list_test.go`、`internal/server/compiled_list_test.go`；新增RDM `scripts/rdm-product-smoke.sh`（拟建），验证实际产物而非Vite预览。
+
+- 基座无RDM、只注册部分、命令disabled、声明分区残留：均不自动发失败审计请求；已开页面能转不可用态。
+- 构建后真实根页200及JS/CSS匹配固定frontend SHA；缺dist拒绝作为完整Web安装；清洁重构建不能借旧dist成功。
+- 有效登录后dev命令清单及capabilities成功；创建者/域管理员/纯平台管理员分别查询各自可审计范围；外部账号拒绝。
+- 403权限拒绝与401过期文案不同；query失败保留reason；密码form警告独立回归。
+
+**完成条件：** 实际8788及FRP入口能加载同一批准产物并查询有数据项目；没有以9015对照或health代替。工作树和CI的验证身份仍按SELF/GATE/REPLAY区分。
+
+### U2. 修复命令契约并统一授权服务
+
+**Requirements：** R2/R4/R6/R7/R8；**依赖：** U9的公开契约、基座发布和RDM升pins，schema修正可先独立交付。**责任：** RDM实施者，公开扩展由Dev责任人承接。**Files：** RDM `plugins/rdm/plugin.go`、`internal/rdmapp/perms_api.go`、`projects_api.go`、`draft.go`、`draftproposal.go`、`internal/domain/doctree.go`、`review.go`；Dev公开契约与执行端消费者按U9先交付。
+
+**Approach：** 先写真实注册总线/HTTP用例捕获schema身份矛盾，删除客户端签字身份字段。梳理全部命令、工具、上传、下载、Host和恢复路径；新旧成员命令兼容别名调用同一服务。统一动作+资源+状态守卫，归档/结项禁止新业务写；草稿列表及聚合计数按可见性过滤。合法用户职责可读文档，不错误要求全项目审计权。
+
+**Tests：** RDM `plugins/rdm/three_sig_test.go`、`internal/rdmapp/perms_test.go`、`resource_authz_test.go`；新增 `plugins/rdm/command_bus_contract_test.go`（拟建，消费公开extension启动/注册路径，不导入Backend internal）。
+
+- 不提供身份字段的合法approve/reject/final能通过schema；伪造字段、空project、错对象所属项目拒绝。
+- 各别名在禁member.manage、归档、最后owner更新/移除时结果一致；并发变动不移除最后owner。
+- reviewer/approver/普通成员/管理员无编制职责时各内容写入口拒绝；指定编制且动作上限允许时可写。
+- 禁阶段、私有草稿/原件、撤权后的旧卡/任务/下载均拒绝；过滤后的分页/计数不泄漏。
+
+**完成条件：** 建立入口×动作×身份×资源矩阵，直接handler单测之外有真实总线/HTTP正负例。
+
+### U3. 项目成员与可信账号目录
+
+**Requirements：** R2/R5；**依赖：** U2。**Files：** RDM `internal/members/members.go`、`internal/rdmapp/projects_api.go`、`plugins/rdm/plugin.go`；Dev公开身份/账号目录扩展申请与相应Host实现；Frontend `src/api.ts`。
+
+**Approach：** 研发项目和初始owner原子写，Host一对一映射双方授权核对。有权管理者分页查找最小有效账号，添加/调整/移除均按权限及生命周期；创建者事实保持不可改，owner变动不伪造创建者。幂等请求记录稳定operationId及策略版本，成功后加入账号看到同一项目并新建私有会话。
+
+**Tests：** RDM `internal/members/members_test.go`、`internal/rdmapp/sysproj_test.go`；基座账号/Host扩展新增契约测试（路径立项时固定）。
+
+- 非有效账号/停用账号不能加；非管理者查不到全系统用户目录；搜索和分页只返回必要字段。
+- 双用户同名建项、owner写失败、Host绑定失败/恢复、绑定他人宿主项目均不留下可用的错误项目。
+- 最后owner改为member、旧命令强制member、并发移除均守不变量。
+- 加入→同ID可见→私有对话；移除→现有会话/模型读取/导出立即受限，历史操作保留。
+
+**完成条件：** 真账号项目生命周期闭环，身份目录、领域项目与宿主映射有固定公开契约。
+
+### U4. 专业角色与可解释权限矩阵
+
+**Requirements：** R3/R4；**依赖：** U2/U3。**Files：** RDM `internal/perms/perms.go`、`internal/rdmapp/perms_api.go`、`plugins/rdm/plugin.go`；拟新增 `internal/perms/roles.go`、角色/关联迁移及解释DTO。Frontend渲染由U6承接。
+
+**Approach：** 按KTD3建持久专业角色、版本及账号关联；角色CRUD、默认/上限更新、项目覆盖、解释读面都调用统一evaluator。平台管理员信任来源经Host，不接受param.isAdmin。矩阵查询按管理范围过滤，返回动作目录、默认、上限、覆盖、有效值及来源/拒绝原因，资格变化使旧许可立即失效。
+
+**Tests：** 扩展RDM `internal/rdmapp/perms_test.go`；拟新增 `internal/perms/roles_test.go`、`plugins/rdm/roles_contract_test.go`。
+
+- 创建自定义角色、关联账号、修改/停用/重启，结果持久且内置系统身份不可经角色CRUD伪造。
+- default允许+cap禁止+override允许仍拒绝；撤上限后旧override即时失效；负责人不能改全局角色上限。
+- 矩阵解释与实际业务调用逐动作一致，doc.read与audit.read、assign与approve不混用。
+- 旧数据迁移干跑和故障回滚、停用角色仍有引用的处理、同版本并发编辑冲突可见。
+
+**完成条件：** 角色能实际创建并影响执行，不是仅显示固定三个标签；矩阵不靠浏览器推算。
+
+### U5. 固定整文三权与正式版本
+
+**Requirements：** R5/R6/R7；**依赖：** U2/U3/U4。**Files：** RDM `internal/domain/review.go`、`doctree.go`、`eventlog.go`、`replay.go`、`internal/rdmapp/draftproposal.go`、`review`应用服务、`docx.go`、`plugins/rdm/plugin.go`；拟新增整文submission及annotations实体/迁移。
+
+**Approach：** 复用持久提案与整文快照，补KTD4冻结字段、轮次、事件与审批状态。提交/批注/通过/驳回/撤回/批准共用固定提交对象，数据与事件同事务。无职责等待可见；分配时查当前账号、项目、动作资格和互异。批准读/导出固定快照，不从current章节拼装。
+
+**Tests：** `internal/domain/review_test.go`、`internal/rdmapp/docduties_test.go`、`plugins/rdm/three_sig_test.go`、现有提案/重放/导出测试；拟新增 `internal/domain/document_submission_test.go`。
+
+- 至少三份独立账号：作者提交、多审核缺一拒批、审核驳回、批准批注及批准；作者/管理者代审拒绝。
+- 改正文/依据/模板/职责、撤成员、换批准人使受影响旧票失效；换名字/职责不能洗掉原作者历史。
+- 章节贡献分配不改变整文签字人；旧章节PASS不聚合为整文PASS；旧活动轮次迁移有显式结果。
+- 旧卡签新版本、并发审签、重复提交、事件写失败、重启恢复、未知schema及历史水位查询均有可判定结果。
+- 正式DOCX及合规导出与批准正文/模板/来源/职责摘要一致，新内部修订保留旧正式版。
+
+**完成条件：** 整文状态机及三个真实身份完整签署，管理权和签字权分离，全部写入入口遵守编制职责。
+
+### U6. 补齐系统管理与创建者项目设置
+
+**Requirements：** R2-R6；**依赖：** U3/U4；文档职责依赖U5。**Files：** Frontend `src/components/AdminZone.tsx`、`adminSections.tsx`、`ProjectSettingsModal.tsx`、`TaskSidebar.tsx`、`src/api.ts`、`src/store.ts`；复用UI `src/SettingsShell.tsx`；拟新增RdmRolesSection/RdmPermissionMatrix/RdmMembersSection/RdmDutiesSection组件。
+
+**Approach：** 使用现有入口和SettingsShell。角色表支持创建/修改/停用；系统矩阵支持默认/上限解释；项目成员页支持账号选择及角色关联；项目矩阵只允许上限内override；文档职责页列文档状态、编制/审核/批准与资格不足原因。未分配不伪装有流程。异步对象单一所有者；全部样式和折叠按DESIGN令牌/原语。
+
+**Tests：** 扩展Frontend `test/workspaces.test.ts`及相关组件测试；拟新增 `test/rdm-management.test.tsx`、`e2e/rdm-management.playwright.ts`；执行Frontend/UI design-guard与必要构建。
+
+- 纯创建者而非管理员能看到并完成项目管理；普通成员不可配置；平台角色管理入口与领域项目管理按实际能力展示。
+- 角色创建→系统矩阵→成员添加→项目覆盖→职责分配，刷新/重启保留且readback来自服务端。
+- 同名账号、停用账号、空清单、服务器拒绝、409并发、断网未知结果时有明确状态，不乐观写成成功。
+- 禁止上限勾选不能通过手造请求保存；所有异步取消/切项目/撤权状态一致；键盘、对比度及主题可用。
+
+**完成条件：** 用户指出的四项缺失功能均在既有入口可操作，服务端同一规则强制执行。
+
+### U7. 对话、审签工作卡与审计读面
+
+**Requirements：** R1/R6/R7/R8；**依赖：** U5/U6。**Files：** RDM `plugins/rdm/plugin.go`、意图/工具声明、`internal/rdmapp/inspection.go`、卡片/任务接线；Frontend `src/api.ts`、`src/components/RdmAuditWorkspace.tsx`、工作卡组件。
+
+**Approach：** 将已有原子命令公开为合法工具/意图，带真实当前项目和确认上下文；读状态和写动作同对象。模型只准备签字，用户认证确认执行。审计页补完整分页、另一端关系判定、不可还原/未提供状态、generation处理。Host审计覆盖和领域事件区分，补真实四链/矩阵、导出进度与下载，而不声称当前四页签已覆盖全部合规展示。
+
+**Tests：** Frontend `e2e/rdm-audit.playwright.ts`及管理e2e；RDM `plugins/rdm/intents_test.go`、`internal/rdmapp/u3_inspection_test.go`、导出/任务测试；新增真实对话与审核/批准卡回道用例。
+
+- 按钮和对话完成同一成员/职责对象，返回同operationId归因；工具传Actor、伪造project或旧卡均拒绝。
+- 右栏关闭仍可读取状态并完成允许的用户确认；真实审核与批准始终属于相应人的认证会话。
+- 快速对象A→B、项目切换、不同历史seq并发、撤权事件与迟到响应，不显示旧对象或旧权限正文。
+- 数据多于首屏能分页，读失败与空数据分开，缺count非零；关联另一端正确；事件水位与正式快照一致。
+- dev+FRP真实入口完成角色→成员→职责→整文审签→追溯→固定导出，账号不能全都兼管理员。
+
+**完成条件：** 用户可见完整首批业务链和负例有真实账号、浏览器、固定制品证据；局部单测不是替代。
+
+### U8. 回填全系统矩阵并推进剩余能力
+
+**Requirements：** 全部原UR/SR/F；**依赖：** 按完整目标总案，不新增平行编号权威。**Files：** RDM `docs/records/2026-10-11-requirements-evidence-matrix.md`、`2026-10-12-final-acceptance-ledger.md`、`docs/requirements/10-实施推进方案-基座与下游二次开发.md`；Documents完整目标/模板/追溯/存储/恢复方案入口。
+
+**Approach：** 保存旧快照和真实收据，新增当前SHA实现/剩余/部署/验收列。优先以下切片，逐包立项和评审：
+
+1. 完整目标U9：slow持久project/owner/输入版本与授权恢复；取消、状态读取和卡片同源，先补恢复可信项目断点。
+2. U5/U6/U12：完整格式解析与锚点、发布补偿、共享检索、两层结论裁决；复用#236真实抓取，真实法规双通道为竞品模板前置。
+3. U7/U8/U16：首批建议书/竞品分析真实闭环后扩展所有69模板及报价XLSX，逐类登记模板内容/格式版本与验收。catalog不能结项。
+4. U11/U10：真实需求/风险/措施/验证生产与四链，阶段适用文档/批准/合规/过期门禁，固定对象推进及结项。
+5. U13/U14：复用Dev存储/恢复在途任务，领域PG/多实例租约与故障恢复、容量、迁移及发布包，最终九层验证和用户上线签收。
+6. U15：F-01到F-10保留owner/依赖/状态；F-06/F-09已纳入当前链，F-10待用户标准模板，不隐式取消后续目标。
+
+**Tests：** 延用各总案列出的直接测试，并落实 `make test`/`make build`、发布制品实测、需求到收据映射。每个子任务立项时冻结样本、数据档位、具体命令和验收环境；上述远期任务不以本稿粗粒度条目直接启动未授权实验。
+
+**完成条件：** 112条都有当前对象与证据状态、责任包；已合入局部能力不会重复重建，旧过期缺口不继续冒充现状。所有最终需求仅在真实证据或用户明确取消/替代裁定后闭合。
+
+### U9. 先交付通用公开授权和身份契约
+
+**Requirements：** R2/R4/R5/R7/R8；**依赖：** 无，可与U1并行。**责任：** Dev Backend公开扩展owner；RDM提出/验收契约。**Files：** Dev Backend `pkg/extension/extension.go`、`pkg/extension/host.go`、`internal/app/compiled.go`、`hostcaps.go`、`internal/server/server.go`、`internal/store/content.go`及相应资源/共享检索授权测试；Documents沿既有扩展申请主记录补四要素。RDM消费发布tag并更新pins，不在pins内改代码。
+
+**Approach：** 契约输入包括认证主体、动作、资源类型/ID、真实资源属主和项目，字段从受信存储/执行上下文生成，不能接受body自报资源归属。资源策略安装后对RDM域内所有访问权威，包括owner自有命中和共享读取；列表/统计/检索候选逐项过滤，SSE/下载/模型上下文注入在当前权限下重验。角色/职责/原件可见性仍由RDM判定，基座不硬编码RDM状态机。兼容使用可选注册能力与版本声明，旧普通基座行为保持；RDM缺该必需能力时停止共享启用而非整项目回退。
+
+同包冻结最小账号目录及宿主项目资格读面：授权项目管理者只获得可选账号的稳定身份/有效态，不获得完整系统用户管理权限；Host项目查验包含存在性、当前主体管理/绑定资格和实例域。复用已存在AdminProvider、项目共享/会话公开扩展，只补缺少字段与检查。
+
+交付顺序为扩展申请评审→基座实现与提供者/消费者契约验证→基座发版→RDM升pins/公开能力检查→U2/U3消费；发版按仓库人工双钥匙，由用户执行。本轮不创建发布或迁移。下游只使用公开符号，真实命令总线测试走公开启动/注册与HTTP，不跨internal边界。
+
+**Tests：** 扩展Backend `internal/server/resource_authz_test.go`、`internal/app/compiled_authz_test.go`及Host/检索测试；RDM新增公开契约消费测试，衔接U2真实HTTP负例。
+
+- 同一项目中A私有原件和B获授权文档，列表/详情/内容/下载/搜索/摘要/模型上下文仅返回获许可对象，私域owner自有命中也不绕过受控文档职责。
+- 撤销角色、成员、分享后旧任务及已开流在新输出/使用边界重验；拒绝/错误/未知资源元数据不变成放行，私聊始终owner隔离。
+- 假projectId、假资源属主、跨实例宿主ID、绑定他人项目均被执行端解析/资格检查拒绝。
+- 未注册时普通基座兼容；RDM旧公开契约缺失时明确拒启受控共享；提供者发版和消费者固定pins组合都有证据。
+
+**完成条件：** 不经RDM命令入口的HTTP/Host/检索也遵守同一资源策略，U2/U3可以在不修改基座internal或pins源码的前提下完成私域/项目绑定要求。
+
+## Verification Contract
+
+正式启动前处理共享锁的owner现场，在相应项目各自通过precheck、从权威main建立worktree和任务卡；不删除他人锁兜底。文档、源码、迁移、测试、部署各有授权范围。阶段内可迭代，跨阶段按Dev `policy/delivery.md` 人工评审，用户沉默不是授权。
+
+验证必须包含三层：模块/公开契约；真实注册总线+认证HTTP；固定正式产物+浏览器用户链。命令语义与服务端拒绝优先，不能用直接handler返回或一张页面截图替代。
+
+最小账号集：平台管理员、RDM域管理员、项目创建者/负责人、编制人、审核人（多审核时至少两人）、批准人、普通成员、外部用户。可以在不冲突场景复用账号，但审计兜底和三权签字用例必须拆开；两个独立项目和私有素材，禁止把所有账号均设管理员让负例失效。
+
+| 层级 | 计划检查 | 判定 |
+|---|---|---|
+| 规范/门禁 | 启动precheck、验收/审核/合入各task-sync、共享写入owner核对 | 同步对象和任务范围有收据；本轮共享BUSY不掩盖 |
+| RDM | `make test`；真实cmdbus/HTTP契约；角色/成员/整文事务及回放 | 选中用例且全部必要正负例有输出，非零用例或SKIP不算PASS |
+| Dev组合 | `make test`+`make build`，检查精确pins和被测工作树 | CI PR HEAD为GATE；本地仅SELF；公开扩展兼容及组合构建均核实 |
+| UI | design-guard、相关组件、实际固定产物的管理/审计/三权浏览器流程 | 有用户动作及可见结果；不能只跑Vite测试而遗漏embed产物 |
+| 部署 | 固定dev制品、manifest、数据身份、同源/FRP入口、登录及七命令 | 新旧时点分开；根页200与有数据查询；启动健康不替代业务验收 |
+| 持久/故障 | 并发成员/签字、撤权、断连未知结果、事件失败、重启/备份恢复 | 无越权或半事务，操作有可对账身份；真实DB档位与恢复对象明确 |
+| 审核 | 独立审阅者先重放最小集，再读作者SELF；核对CI身份/链接/SHA | 本稿Agent审阅不代替正式REPLAY/GATE、人审和上线签收 |
+
+完成声明的precheck/task-sync/测试三段输出由evidence写入任务卡；产出物引用任务卡/原收据。本轮仅保存调查与precheck收据，不补写业务测试输出。业务测试、真实模型、迁移、重启、部署、当前登录态审计验收均NOT_RUN。
+
+## Definition of Done
+
+本稿交付：矩阵覆盖全部原需求、故障因果链有固定对象/运行历史、五个问题分别定位到已有与缺口、方案有依赖/模块/测试/验收/兼容及停止条件，报告可审阅并保存。没有要求或宣称此轮实施。
+
+首批整改验收：在实际dev及FRP入口，管理员建角色/配置上限，创建者管理成员/覆盖项目权限/分配文档职责，真实三权完成整文审签，审计历史和导出一致；越权/撤权/旧卡/旧版本负例成立。源码、CI、组合、部署、用户验收分别签收。
+
+全系统C1：完整目标U1-U14及U16全部对应证据齐备；C2额外包含U15最终扩展或用户明确裁定，不把后续备案当已实现。新报告只记录当前差距，不修改旧收据或取消需求。
+
+停止条件：权威需求改变；必要公开扩展不兼容；实际制品/数据身份无法确定；迁移权限扩大或旧审签票迁移规则不明；跨出当前批准范围或共享写者未退出。先保存证据/现场，提交受影响设计评审，不以临时放宽权限继续。
+
+## 待人工评审与下一步
+
+建议优先批准**本稿U1：正式产品构建及审计实际入口**，U9公开契约并行；U2可先在隔离工作区建立schema失败用例，完整资源授权出口依赖U9发版/升pins。上述首批工作不依赖69模板全量完成。随后U3/U4固定服务契约，U5整文三权与U6页面接线按依赖并行，U7交付用户完整流程。
+
+需评审的新增技术选择：RDM组合二进制嵌入React正式入口；RDM专业角色首版单角色；旧cap/角色映射不扩大权限；整文签字替代章节级正式签字并保全历史。项目级批量职责默认若需要，另定义应用范围与显式覆盖，不把它作为此次分配每文档职责的隐藏前置。
+
+这些是待批准设计，不重问是否实现角色/成员/权限/三权。正式实施负责人、隔离测试环境和部署切换窗口在批准启动时登记。此次独立报告入仓仍待共享门禁解除，未创建提交或PR。
+
+## Appendix
+
+随附文件 `source-runtime-receipt.json` 为make evidence原始调查收据，`precheck-receipt.json` 为启动拒绝收据；`readonly-probe.py` 为可复核只读命令脚本。报告审阅记录另保留；同一次作者侧子代理检查仍为SELF。
+
+### 逐条需求定位与计划索引
+
+以下只携带现有权威矩阵ID、摘要与既有工作包，原文位置相对RDM `docs/requirements/01-用户需求与系统需求.md`。摘要可能被原矩阵截断，完整语义以原文为准。历史矩阵中的“源码状态”列不复制，当前实现/缺口以本稿功能域表及固定源码为准；每行运行结论均为NOT_RUN。
+
+| 原ID | 权威摘要 | 既有完整目标工作包 | 原文行 | 当前运行验收 |
+|---|---|---|---|---|
+| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传，对不支持格式仅提醒不阻断 | U5/U9/U14；G9/G10/G15 | 437 | NOT_RUN |
+| SR-A2 | 上传不强制附带文字指令；无指令时进入默认"记忆构建"流程（见 SR-B 系列），不输出制式化"未识别需求"回复 | U5/U9/U14；G9/G10/G15 | 438 | NOT_RUN |
+| SR-A3 | 支持单文件、多文件批量上传，并记录来源渠道（Web/飞书/其他）与上传人 | U5/U9/U14；G9/G10/G15 | 439 | NOT_RUN |
+| SR-A4 | 上传后 60 秒内输出第一阶段反馈（相关性结论 + 初步阶段归类）；完整入库允许后台异步完成 | U5/U9/U14；G9/G10/G15 | 440 | NOT_RUN |
+| SR-A5 | 入库完整性保障：解析失败、部分内容不可解析或入库异常时，必须显式告知用户并在入库记录中标记，原始文件永久保留可取回；禁止静默降级或静默产出残缺结果（教训来源：旧版曾发生报价单 Excel 数据丢失、P… | U5/U9/U14；G9/G10/G15 | 441 | NOT_RUN |
+| SR-B1 | 对每份上传资料输出相关性判定（相关 / 存疑 / 无关）及判定依据；存疑时必须挂起并向用户请求确认，确认前不入库 | U5/U6；G9/G10 | 447 | NOT_RUN |
+| SR-B2 | 对资料进行结构化解析，保留章节/页/表格级锚点，锚点在后续所有引用与追溯中可用 | U5/U6；G9/G10 | 448 | NOT_RUN |
+| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项"，映射结合项目当前所处阶段；支持一片段映射多阶段 | U5/U6；G9/G10 | 449 | NOT_RUN |
+| SR-B4 | 每个切片附带结构化标签（JSON）：阶段、工作事项、主题、可行性维度（技术/市场/注册）、关联需求 ID、来源、上传时间、置信度；并生成一句话描述（description） | U5/U6；G9/G10 | 450 | NOT_RUN |
+| SR-B5 | 支持"两速入库"：快速通道（打标签 + 摘要 + 入库）先行返回，慢速通道（细切片、嵌入向量化）后台补齐，状态对用户可见 | U5/U6；G9/G10 | 451 | NOT_RUN |
+| SR-B6 | 入库完成后向用户输出勾连总结：本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节，以显式清单呈现 | U5/U6；G9/G10 | 452 | NOT_RUN |
+| SR-B7 | 会议纪要类资料按同一管道处理，并可抽取"结论 / 待办 / 待确认"三类条目 | U5/U6；G9/G10 | 453 | NOT_RUN |
+| SR-B8 | 笔记树内一致性检测：同一主题簇下多个切片的陈述不一致（如多人表述冲突）时，系统检测冲突 + 记录入追溯网（何时/何人/何节点/何操作）+ 通知触发冲突的用户 + 挂起待裁决；智能体不自行处理冲突，裁决… | U4/U6；G11 | 454 | NOT_RUN |
+| SR-B9 | 并发更新冲突避免与及时提示：多人几乎同时更新同一树节点时，系统忠实记录全部操作入追溯网，冲突以候选子节点组并存挂起，智能体不自行处理冲突；裁决集中在编制人发起编制时经 HITL 完成（裁决两层，规则同… | U4/U6；G11 | 455 | NOT_RUN |
+| SR-B10 | 任务快慢双速：对用户任务按快慢双速模式执行——快通道同步短链路即时反馈（如上传文档→相关性判断→相关给概要/不相关给理由＋相似文档供选择），慢通道小队（subagent）后台深度执行（逐页解析、建节点… | U9/U13；G15 | 456 | NOT_RUN |
+| SR-B11 | 结论节点：结论作为笔记树的节点类型保存（结论入树）；结论节点与切片同受 08 R1–R5 硬规则约束（append-only、软删除、结构事件日志、可重建）；结论节点与其依据切片/来源的关联入追溯网。… | U6；G11 | 457 | NOT_RUN |
+| SR-B12 | 总结触发：何时生成阶段总结交模型自主判断（不设固定阈值）——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档（HITL 确认）；保留人工触发入口（用户明确指令触发）；上传后先快速摘要反馈、后… | U6；G11 | 458 | NOT_RUN |
+| SR-C1 | 内置可配置的研发体系文档树（阶段 → 文档 → 章节），每章有内容要求说明；文档树对应设计开发控制程序，商务对接与策划合并为同一阶段 | U7/U8/U16；G7/G8 | 464 | NOT_RUN |
+| SR-C2 | 体系文档模板集中注册、版本化管理；模板与阶段/文档节点的关联可配置，不与具体工作流实例硬绑定。模板策略：本期按当前已有模板设计与完善；标准模板待系统完成并通过测试后由用户补充（E-T3，后续目标 F-… | U7/U8/U16；G7/G8 | 465 | NOT_RUN |
+| SR-C3 | 文档生命周期状态机：草稿 → 评审中 → 已基线 →（变更中）→ 新版本基线；基线文档不可被直接修改 | U4/U8/U10；G6/G8/G17 | 466 | NOT_RUN |
+| SR-C4 | 新切片填充文档章节前，与该章节现有内容比对，输出三分类结论：新增 / 更新 / 冲突；更新与冲突均需用户确认后生效 | U4/U8/U10；G6/G8/G17 | 467 | NOT_RUN |
+| SR-C5 | 缺项分析仅在两种触发条件下输出：文档提交评审时、项目申请推进阶段时；上传节点禁止输出缺项提示 | U10/U11；G14 | 468 | NOT_RUN |
+| SR-C6 | 每次文档内容变化生成版本记录，可查看任意两版本差异及差异来源切片 | U4/U8/U10；G6/G8/G17 | 469 | NOT_RUN |
+| SR-C7 | 三权分立流程规则：编制/审核/批准三权异人（编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人）；编制发起唯一；审核/批准仅可批注与通过/驳回，不可修改正文或发起编写；提交审核即锁定；驳回回… | U3/U8；G6/G17 | 470 | NOT_RUN |
+| SR-C8 | 批准后修改的处理：本期路径＝撤回重审（D-12：撤回后修改并重新升版审批）＋影响提示（沿追溯网列出受影响范围给人看，不走流程，见 SR-D3）；松散管理取向，但审计链不断（08 R1/R2/R5 不动… | U3/U8；G6/G17 | 471 | NOT_RUN |
+| SR-D1 | 建立并持久化双向追溯网络：资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例；每条边记录类型、来源（人工/规则/模型候选）与置信度 | U11/U14；G12/G17 | 477 | NOT_RUN |
+| SR-D2 | 需求条目化管理：用户需求与系统需求大表，字段含状态（草稿/已评审/已基线）、版本、关联文档与法规；支持增删改与批量导入 | U11/U14；G12/G17 | 478 | NOT_RUN |
+| SR-D3 | 新内容入库触发变更检测：与已评审条目比对，不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示（V2.1 增补）：批准后修改或引用内容变化时，系统沿追溯网列出受影响范… | U6/U11；G11/G16 | 479 | NOT_RUN |
+| SR-D4 | 变更流程闭环（变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭，全程留痕）：整体后移，不作为本阶段系统实现目标——变更流程走公司内部管理流程，移入后续目标备案 F-02（《10… | U15/F-02；G14 | 480 | NOT_RUN |
+| SR-D5 | 任一需求可导出完整追溯链报告；无法匹配进体系的资料进入"待裁定"清单，提醒用户处理 | U11/U14；G12/G17 | 481 | NOT_RUN |
+| SR-D6 | 追溯主体扩展：追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片，保证所有信息细节的准确性与可追溯性 | U4/U8/U11；G8/G17 | 482 | NOT_RUN |
+| SR-D7 | 完整合规追溯模型（权威定义见 08 第十六章）：15 类受控节点（含危害/风险控制措施/设计确认/设计转换/变更）＋11 类合规边（两端=节点 ID@版本，模型仅候选、人工确认转正）＋四条链视图（13… | U11/U14；G12/G17 | 483 | NOT_RUN |
+| SR-D8 | 需求分类与分解框架：用户需求与性能需求分到不同文档；先确认用户需求再分解系统需求；系统需求按六维度分类（功能/交互/安全/运输包装/维护/合规）；智能体可从法规反推部分系统需求，但不完全依赖智能体；先… | U11/U14；G12/G17 | 487 | NOT_RUN |
+| SR-D9 | 风险登记册追溯：危害（HAZ）与风险控制措施（RCM）入网；每个 RCM 同时登记为需求并必须被验证（verifies 边）；每个危害至少被一项 RCM mitigate；措施-危害-验证三向可查（术… | U11/U14；G12/G17 | 484 | NOT_RUN |
+| SR-D10 | 验证结果绑定被测版本：VR 记录对应用例与被测对象版本；被测版本≠当前基线版本时系统报「验证过期」并列入缺口；设计确认（VAL）必须追溯到用户需求 | U11/U14；G12/G17 | 485 | NOT_RUN |
+| SR-D11 | SOUP 组件登记与追溯：软件组成项（含 SOUP）入网为架构项，其需求分配与验证沿用同一边模型 | U11/U14；G12/G17 | 486 | NOT_RUN |
+| SR-E1 | 意图识别分层：规则层（仅限整句完全匹配的高频确定性短指令）→ 语义层 → LLM 层；规则层不得单独触发高风险操作 | U2/U8/U9/U10；G1/G8/G14/G15 | 493 | NOT_RUN |
+| SR-E2 | 规则层命中必须通过上下文校验（上一轮存在对应的待确认事项）才可执行；无上下文时降级为普通对话 | U2/U8/U9/U10；G1/G8/G14/G15 | 494 | NOT_RUN |
+| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成，卡片明示操作对象与后果 | U2/U8/U9/U10；G1/G8/G14/G15 | 495 | NOT_RUN |
+| SR-E4 | 支持意图分类（查询 / 编写 / 命令 / 讨论）与意图切换识别；编写类意图需命中目标文档并确认后执行 | U2/U8/U9/U10；G1/G8/G14/G15 | 496 | NOT_RUN |
+| SR-E5 | 简单询问即时回答；复杂任务先给出执行计划与预计耗时，执行中提供进度反馈 | U2/U8/U9/U10；G1/G8/G14/G15 | 497 | NOT_RUN |
+| SR-E6 | 对话完备路径：从立项到结项的全部状态变更操作（创建项目、提交评审、批准变更、阶段推进、导出、结项等）均可通过对话指令驱动，页面/按钮不是任何步骤的唯一入口；高风险操作的对话路径终点为对话流内联确认卡（… | U2/U8/U9/U10；G1/G8/G14/G15 | 498 | NOT_RUN |
+| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行：骨架显式定义步骤序列与返回检查节点，角色在骨架内有限自主 | U8/U9/U13；G8/G15/G18 | 504 | NOT_RUN |
+| SR-F2 | 每个角色显式声明：职责、可用工具白名单、禁区；角色提示词作为受控资产版本化管理 | U8/U9/U13；G8/G15/G18 | 505 | NOT_RUN |
+| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道，结果附引用来源；冲突时以权威来源为准并提示 | U12；G13 | 506 | NOT_RUN |
+| SR-F4 | 长任务后台异步执行，进度可查询、完成有通知；不得阻塞对话主线程 | U8/U9/U13；G8/G15/G18 | 507 | NOT_RUN |
+| SR-F5 | 执行任务时自动组装上下文：项目当前状态、相关记忆切片、目标文档模板、近期对话；上下文构成可解释 | U8/U9/U13；G8/G15/G18 | 508 | NOT_RUN |
+| SR-G1 | 飞书集成：智能助手可加入群聊，支持群内对话、收文件、推送反馈与通知。本期不做飞书功能（J-11），本条与 UR-20 一并后移 → F-01 | U15/F-01；外部依赖 | 514 | NOT_RUN |
+| SR-G2 | 基于角色与项目阶段的权限控制（ABAC），阶段转换需满足准入准出条件并留痕。判定维度（角色 × 项目 × 阶段 × 动作）保留；权限主数据裁决（J-10，R2 关闭）：本期系统内建最小权限系统（管理员… | U2/U3；G3/G4 | 515 | NOT_RUN |
+| SR-G3 | 全量审计日志：上传、入库、更新、变更、确认、生成等动作均可审计 | U4/U11；G5/G17 | 516 | NOT_RUN |
+| SR-G4 | 系统以自身研发项目为首个运行实例（自举元项目），自身需求与体系文档由本系统管理 | U14；G19 | 517 | NOT_RUN |
+| SR-G5 | 结构追溯：笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值；删除一律软删除（tombstone）；追溯边有"候选 → 生效 → 废止"全生命周期；支… | U4/U11；G5/G17 | 518 | NOT_RUN |
+| SR-G6 | 系统管理员与系统级设置：全局唯一管理员拥有所有权限；仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数（工具调用轮数/工具权限等）、系统级插件管理、用户/角色的… | U2/U3；G3/G4 | 519 | NOT_RUN |
+| SR-G7 | 角色管理：角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人；角色可分配给用户（如项… | U2/U3；G3/G4 | 520 | NOT_RUN |
+| SR-G8 | 权限覆盖优先级——上限内覆盖（J-05，原存疑关闭）：管理员设定角色默认权限与权限范围上限（最底层约束）；项目负责人（创建者）在该范围内调整项目成员权限；项目内配置可覆盖角色默认配置，但不得突破管理员… | U2/U3；G3/G4 | 521 | NOT_RUN |
+| SR-G9 | 项目负责人权限：项目创建者即项目负责人，拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | U2/U3；G1/G2 | 522 | NOT_RUN |
+| SR-G10 | 项目唯一性与成员自动可见：同名项目全系统唯一；用户被添加为项目成员后，其界面自动出现该项目，并可直接开始项目工作（新建对话等） | U2/U3；G1/G2 | 523 | NOT_RUN |
+| SR-G11 | 对话隐私：用户之间的对话互相不可见，仅本人可见本人与智能体的对话；智能体会话/中间过程默认互不可见（J-06，原存疑关闭），协作全部经两树一网项目共享层；用户分享分层（整个项目/会话/部分会话）的精细… | U3/U5/U9；G4/G5/G10 | 524 | NOT_RUN |
+| SR-G12 | 文档分享：上传者可将文档分享给指定成员/部分成员/全部项目成员；被分享者只读、不可编辑；被分享文档进入接收者上下文，支撑其后续对话中查看并基于这些文档对话 | U3/U5/U9；G4/G5/G10 | 525 | NOT_RUN |
+| SR-G13 | 上下文时间权重：本期最小实现——检索与注入排序新内容优先；替换/冲突场景走 J-02 人裁决（SR-B8/SR-B9）。可配置时间权重衰减模型（权重数值、配置粒度）移入后续目标 F-04（J-07，优… | U5/U15/F-04；G10 | 526 | NOT_RUN |
+| SR-G14 | 飞书项目对接适配（接口层四项功能：产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接；飞书角色权限映射读取）：本期不做飞书功能，整条移入后续目标备案 F-01（J-11）；保留设计预留说… | U15/F-01；外部依赖 | 527 | NOT_RUN |
+| SR-G15 | 虚拟人账号（企业账号下为智能体创建固定账号持有文档/文件夹访问权限；授权范围、审批与定期审计流程待明确，《10》Q-04）：随飞书对接整体后移，移入后续目标备案 F-01（J-11） | U15/F-01；外部依赖 | 528 | NOT_RUN |
+| SR-G16 | 代码执行安全：多用户共享部署在隔离执行档就位前，以启动级硬关闭禁用执行原语（run_shell/run_python/register_artifact 及内核执行配置），用户设置不得覆盖（基座已交付… | U13；G18 | 529 | NOT_RUN |
+| SR-N1 | 性能：上传首轮反馈 < 60 秒；单文档完整入库（后台）< 10 分钟；追溯链查询 < 3 秒 | U14；G18/G19 | 535 | NOT_RUN |
+| SR-N2 | 可维护性：模块边界清晰、依赖单向；任一核心功能（如文档入库）可在 5 分钟内定位到对应代码模块；支撑每周代码审查机制 | U1/U14；G19 | 536 | NOT_RUN |
+| SR-N3 | 可解释性：每个入库、更新、变更动作给出依据（来源切片、命中标签、比对结果） | U4/U5/U8；G10/G17 | 537 | NOT_RUN |
+| SR-N4 | 部署与数据：支持本地化部署；法规知识库本地存储；项目数据按项目隔离 | U2/U3/U13；G5/G18 | 538 | NOT_RUN |
+| SR-N5 | 模型无关性：大模型通过抽象层接入，可替换（当前为 MiniMax，不绑定） | U9/U13；G8/G18 | 539 | NOT_RUN |
+| UR-01 | 自由上传 | U5/U9/U14 | 547 | NOT_RUN |
+| UR-02 | 相关性把关 | U5/U6 | 548 | NOT_RUN |
+| UR-03 | 自动归纳入库 | U5/U6/U9/U14 | 549 | NOT_RUN |
+| UR-04 | 及时反馈 | U2/U5/U6/U8/U9/U10/U13/U14 | 550 | NOT_RUN |
+| UR-05 | 渐进式清晰 | U4/U7/U8/U10/U16 | 551 | NOT_RUN |
+| UR-06 | 缺项提示时机 | U10/U11 | 552 | NOT_RUN |
+| UR-07 | 冲突与变更 | U4/U6/U8/U10/U11/U15 | 553 | NOT_RUN |
+| UR-08 | 严格可追溯 | U4/U5/U6/U8/U10/U11/U14 | 554 | NOT_RUN |
+| UR-09 | 需求条目化 | U6/U11/U14 | 555 | NOT_RUN |
+| UR-10 | 模糊澄清 | U2/U4/U5/U6/U8/U9/U10 | 556 | NOT_RUN |
+| UR-11 | 一键生成文档 | U2/U8/U9/U10/U13 | 557 | NOT_RUN |
+| UR-12 | 主动提问 | U2/U5/U6/U8/U9/U10 | 558 | NOT_RUN |
+| UR-13 | 外部查询入库 | U5/U6/U8/U9/U12/U13 | 559 | NOT_RUN |
+| UR-14 | 法规双通道 | U12 | 560 | NOT_RUN |
+| UR-15 | 商务策划贯通 | U7/U8/U16 | 561 | NOT_RUN |
+| UR-16 | 显式确认 | U2/U8/U9/U10 | 562 | NOT_RUN |
+| UR-17 | 阶段门禁权限 | U2/U3/U4/U11 | 563 | NOT_RUN |
+| UR-18 | 会议纳入记忆 | U5/U6 | 564 | NOT_RUN |
+| UR-19 | 自举 | U14 | 565 | NOT_RUN |
+| UR-20 | 协作平台接入 | U15 | 566 | NOT_RUN |
+| UR-21 | 系统角色与权限管理 | U2/U3 | 567 | NOT_RUN |
+| UR-22 | 项目成员与协作 | U2/U3 | 568 | NOT_RUN |
+| UR-23 | 文档分享与上下文注入 | U3/U5/U9/U15 | 569 | NOT_RUN |
+| UR-24 | 三权分立文档流程 | U3/U8 | 570 | NOT_RUN |
+| UR-25 | 版本全量保留与来源追溯 | U4/U8/U10/U11 | 571 | NOT_RUN |
+| UR-26 | 并发更新冲突避免与提示 | U4/U6 | 572 | NOT_RUN |
+| UR-27 | 快慢处理与任务拆解展示 | U9/U13 | 573 | NOT_RUN |
+| UR-28 | 简易看板 | U4/U6/U8/U10/U11 | 574 | NOT_RUN |
+| UR-29 | 难度分级与降级使用 | U8/U9/U13/U14/U15 | 575 | NOT_RUN |
+| UR-30 | 对抗验证机制 | U8/U9/U13/U14/U15 | 576 | NOT_RUN |
+| UR-31 | 飞书项目对接 | U15 | 577 | NOT_RUN |
+| UR-32 | 代码管理工具集成 | U15 | 578 | NOT_RUN |
+| UR-33 | 法规合规追溯 | U11/U14 | 579 | NOT_RUN |
+| UR-34 | 结论沉淀与阶段总结 | U6 | 580 | NOT_RUN |
+| F-01 | 飞书对接全套（渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联） | U15/F-01 | 643 | NOT_RUN |
+| F-02 | 变更流程引擎（七步闭环、变更单、完整影响分析） | U15/F-02 | 644 | NOT_RUN |
+| F-03 | 用户分享分层（整个项目/会话/部分会话）与智能体可见性的精细设计 | U15/F-03 | 645 | NOT_RUN |
+| F-04 | 可配置上下文时间权重衰减模型 | U15/F-04 | 646 | NOT_RUN |
+| F-05 | 代码管理工具集成（GitLab token 只读拉取、需求-版本-缺陷关联） | U15/F-05 | 647 | NOT_RUN |
+| F-06 | 看板与卡片流的界面统一（随原型 V2.3） | U9/U14 | 648 | NOT_RUN |
+| F-07 | 会议遗留问题组（Q-01/02/03/07/10/13/14 等，《12》问题 8 组）；其中 Q-02 经晚会部分裁决（C-03，见 §7.1） | U15/F-07 | 649 | NOT_RUN |
+| F-08 | 难度分级评估表与降级机制的落地细化（UR-29 保留 P1，实施细节备案） | U15/F-08 | 650 | NOT_RUN |
+| F-09 | 追溯网可视化（先功能后展示，暂缓） | U11/U14 | 651 | NOT_RUN |
+| F-10 | 标准模板替换：本期按当前已有模板设计与完善；待系统完成并通过测试后，由用户补充标准模板（取代晚会 T2「今晚下载官方模板替换」，不执行） | U16＋U15/F-10 | 652 | NOT_RUN |
@@ -0,0 +1,383 @@
+---
+title: 服务重启与全量数据恢复方案
+type: fix
+date: 2026-10-12
+artifact_contract: ce-unified-plan/v1
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# 服务重启与全量数据恢复方案 r3
+
+确认状态：原 r2 批准记录保留（Dev PROJECT.md 记录 2026-10-12 五阶段批准）；**r3 本轮增补待人工评审**。本轮仅调查、修订方案及本地文档核查，不代签历史批准，不授权业务实施、账户变更、迁移、故障注入、部署、推送或合入。
+修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。
+r3＝同日根据 dev 8788 账户故障续查刷新源码／运行事实，保留 R1–R10、KTD1–KTD12、U1–U7；补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值，未宣称实测达标。
+r3.1＝同日增补 D1/D2/D3（部署根治；编号避开本案 U1–U8）。映射：D1 补 U1 身份消费缺口，D2 补 U6 部署回退，D3 补 U7 真实组合门禁。确认状态：用户 2026-10-12 授权按实施计划连续推进到 PR 可合入；本节新增条款仍供人工评审，不代签 r3 其余未批内容。
+需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。
+主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
+
+## 1. 目标与成功边界
+
+**目标：系统停止后再次启动，用户仍能访问原有数据和服务，未完成工作进入可继续或可处理的确定状态。**
+
+采用“稳定实例配置与身份、依赖编排、进程监管、持久恢复账本、一致性文件发布、组合备份与实测验收”的方案。复用现有 PostgreSQL/SQLite、运行表、事件、命令、通知和恢复隔离机制，补齐实际接线与崩溃窗口。首期落实单机完整恢复；多实例所有权沿用已有协作存储方向，不重新设计一套集群平台。
+
+必须区分三类恢复：
+
+| 故障档 | 需要达到的结果 | 数据与时间合同 |
+|---|---|---|
+| `svc stop/start/restart`、进程 SIGTERM/SIGKILL、应用 OOM | 原配置启动；持久数据完整；安全任务继续；未知副作用隔离 | 存储正常、确认结果已持久化的前提下，RPO=0；建议冷启动至业务就绪≤60秒 |
+| 主机重启、操作系统崩溃或断电，磁盘仍可用 | 数据库 WAL 恢复、文件一致性恢复、服务按既定意图启动 | 只有 DB 与文件落盘策略、底层存储满足耐久性且实测后，才承诺已确认数据 RPO=0；建议 RTO≤5分钟 |
+| 数据盘损坏、主机丢失、误删或不可逆污染 | 在新目标恢复匹配的 DB、文件、配置和版本 | 沿用协作存储案建议 RPO≤5分钟、RTO≤60分钟；如要求此档 RPO=0，另行批准跨故障域同步复制 |
+
+以上时间为**待批准的验收目标**，不是已测性能。大规模扫描与冷索引重建不要求全部在60秒内完成：必需数据对账及安全恢复决策完成后可开放API，派生索引按明确降级合同后台重建。故障超出资源预算时报告阻塞及原因，不能以假就绪满足时间指标。
+
+恢复保存的是持久业务状态、步骤和已确认结果。进程内 goroutine、模型连接及未持久化 token 不可原样复活；模型回合从持久上下文和步骤边界重建。已经接受的用户消息、排队任务、审批和取消意图必须先落库再返回接受；尚未确认的结果不能事后冒充成功。
+
+## 2. 当前事实及重点差距
+
+本轮源码基线：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（任务元数据提交）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。草案独立 Documents 基线 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，未推进 Dev gitlink。原 r2 对象为历史，不用于证明当前运行行为。
+来源为 SELF·只读观察；原始脱敏命令和运行输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。故障表现为源码推导，故障／恢复／耐久性验收 NOT_RUN。
+最终 Dev 同步基线 `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9` 已纳入主干的 svc 实例内存态修复和 Documents 指针 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`；Backend／Frontend 未变。旧 gitlink 是启动时点，本轮仅同步权威上游，未推进本轮草案组合或重复实现该修复。
+
+| 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
+|---|---|---|
+| 数据库绑定与身份 | svc 统一解析已接线；manifest/marker 和 Backend DB identity 已存在；manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env；自定义根和 legacy/direct 启动需要完整核验；identity 不等于活动服务独占锁 |
+| 服务生命周期 | svc 已有 desired/autostart、recover、watchdog timer；PG 优先拉起 | 没有完整服务组依赖／单一进程组监管；不管理 Redis 类型；登记版本与实际二进制可能不一致 |
+| 启动与停机 | 启动对账开放 run；优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前；HTTP停机超时可跳过flush；无所有worker等待；子代理 cancelled 可覆盖 interrupted |
+| 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消；子代理先派生再写文件标记；notice消费非事务且绕过PG会话占用 |
+| 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease，终态有fencing；额度有持久表 | 续租只有定义未接入生产调用；15分钟租约可过期；额度无崩溃回收；不能据此宣称安全接管 |
+| 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行，kill窗口丢命令；跨实例取消入队缺conversation；Surface失败仍可清pending且仅扫100条 |
+| 工具副作用 | Native Session已有tool intent/result转录、安全重放判定；Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义；Native的未知效果被写成工具错误后仍可继续模型，尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 |
+| 文件与备份 | blob temp+rename、SQLite 一致性快照、pg_dump 已存在；Native 转录 Write→Sync；manifest 有原子同步链 | 工件原文先覆写再更新 DB，无不可变版本；agent 快照缺权威 manifest，PG 和文件快照不是同一恢复点 |
+| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接；数据库事务可排队 | 无跨进程活动服务独占；恢复扫描全部开放 run，第二个服务可打断第一服务；不具备 PG 的会话执行租约 |
+
+2026-10-12 17:37:03（Asia/Shanghai）实际 dev 进程打开 `runtime/dev/data/agent-system.db`，DB marker 为 `sqlite`，运行 Backend `5e8ada7`；没有登记 PG 绑定。候选 rdmcand 已停止且登记来源与实际文件版本不符。前一轮共享数据观察是历史风险线索，不冒充当前双进程事实。**实际文件／marker 已核对，不等于全栈恢复或断电耐久性 PASS。**
+
+当前 PG 事件总线已有真重连、分页追赶和周期补查，Native 已接持久工具转录；这些基础不重复建设。SQLite 应用连接未显式声明 synchronous；诊断连接 PRAGMA 不能证明应用配置，见 R12。
+18:14:09（Asia/Shanghai）重新实测：外部流程已将 rdmcand 拉起于独立数据根，实际 DB inode 与 dev 不同且制品／登记版本一致；dev 仍打开原库、账户最后设密时间未前进。当前共享现场已缓解；U8 的剩余任务是强制运行时防误用和隔离验收，不重复执行已完成的人工分根。完整停机／恢复和锁能力仍 NOT_RUN，本轮没有改变服务或数据。
+
+旧报告中“DSN重启丢失”“迁移DDL与版本分开提交”“通知仅内存”等问题已有源码改进，本案只验证并复用这些基础，不把旧缺陷重新列成新建设。
+
+## 3. 需求合同
+
+| ID | 范围 | 要求与可判定验收 |
+|---|---|---|
+| R1 | 服务 | 启动显式服务组时，全部已启用的必需服务按依赖就绪；可选失败明确降级；主动停止不被监管误拉起 |
+| R2 | 身份 | 连续裸启停、更换端口/程序/cwd后，DB identity、数据/工件/工作区根、实例ID、认证及插件组合一致；缺配置拒绝启动 |
+| R3 | 已确认数据 | 消息、项目、成员/权限、文档、设置、插件启用/授权、任务、审批、事件、工件原文与版本在RPO=0档零遗漏；灾难档完整恢复批准恢复点内数据，并对账/报告恢复点后的缺失和外部效果 |
+| R4 | 任务 | 已接受排队任务不丢；安全任务从持久步骤继续；HITL保留稳定gate与答案；取消意图在重启/换owner后仍生效 |
+| R5 | 副作用 | started但无确定result的外部动作自动隔离；已确认动作不重做；恢复与发布验证当前权限和执行代次 |
+| R6 | 所有权 | 单一有效写者；旧进程迟到写状态/事件/工件被拒；过期额度回收；恢复本身可重复且可再次中断 |
+| R7 | 文件与派生状态 | DB引用的文件内容、版本和hash一致；损坏现场保留并报告；缓存/检索索引可从权威源重建 |
+| R8 | 停机与就绪 | 停机先拒绝新工作再排空；全部worker、sidecar和工具子进程收口；错误不跳过后续清理；ready反映业务可用 |
+| R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同；备份恢复到新目标并完成业务/权限/文件对账；不在普通启动覆盖现库 |
+| R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 |
+| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时；直接二进制、路径别名和 legacy 入口同样受保护；账户短事务 CLI 不启动第二运行时；测试实例使用独立根 |
+| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略；文件和目录同步覆盖权威对象；DB/文件持久失败不能确认成功；未实测的断电 RPO 保持候选 |
+
+覆盖“所有数据”需要先完成数据归属清单：除Backend业务表，还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性；无法证明可恢复的必需插件阻塞全系统签收，不能只恢复Backend便宣称全部完成。
+
+## 4. 技术决策与服务结构
+
+KTD1. **持久配置是启动权威，PID只是观察。** 每实例保存完整类型化manifest：service/instance ID、配置revision、desired state、服务类型与管理权、依赖、固定程序/插件/资产摘要、DB identity与凭据引用、数据/工作区/工件根、认证、监听、必需/可选属性、恢复政策。临时环境只作显式覆盖；必需字段必须能从持久值或稳定受保护引用重新解析。机密放受保护文件/秘密服务，manifest仅存引用，不把密码或DSN写进日志。
+
+KTD2. **配置整份提交，覆盖按字段合并。** 每实例和服务组串行化生命周期操作，配置以revision做CAS；候选完整解析与校验后，临时文件落盘、原子替换、目录同步。legacy迁移同样一次提交，故障留下旧版或完整新版。更改端口不隐式更改data；数据根迁移是独立操作。恢复启动发现预期DB/marker/目录丢失时阻塞，初次初始化需要明确入口，禁止新建空库掩盖数据丢失。
+
+KTD3. **svc控制期望状态，唯一supervisor管理进程。** Linux部署推荐systemd；svc兼容既有单服务入口，增加显式stack/group控制。每服务仅一个监管者，不能nohup watcher与systemd同时拉起。分发仓已有模板要接入同一manifest合同。外部/共享PG、Redis仅探测连接，不擅自启停；managed-local只管理身份已核实且归该服务组独占的资源。pgvector是PG扩展，不另造守护进程；Redis只有配置并启用时才进入依赖图。
+
+KTD4. **主动停止与异常退出分开。** stop先提交desired=stopped，再关闭服务；普通故障仅desired=running可重启。restart保留最终running意图并记录operation_id、执行阶段和恢复政策，不能因中途stop留下stopped。监管采用有界退避、重试预算与失败阻塞；错误配置不能无限重启。开机只恢复已登记且策略允许的服务。intent、operation、actual state必须分开，不能以pidfile存在视为运行。
+
+KTD5. **团队业务权威沿用PG，个人档沿用SQLite。** 团队PG失败保持未就绪，绝不切SQLite。普通重启让既有数据库完成自身WAL恢复，不导入备份。验证数据库identity/schema/权限和关键记录；SQLite恢复到预期文件并检查完整性，不能只看文件存在。断电承诺要求明确DB同步设置及底层存储合同，不把rename原子性当作落盘保证。依据：[PostgreSQL耐久性](https://www.postgresql.org/docs/current/wal-reliability.html)、[SQLite WAL](https://www.sqlite.org/wal.html)。
+
+KTD6. **恢复扫描与恢复执行分离。** 装配Store、权限、插件/工具、工作区、预算、Workflow、命令消费者与事件投递之后，才分类认领恢复任务。扫描失败或归属未知进入blocked/hold；不能吞掉错误直接ready。恢复有持久cursor/attempt和CAS，支持分批、失败重试及再次重启；禁止全库无归属盲扫并续跑其他实例的任务。
+
+KTD7. **持久执行账本统一主run、子run和后台任务。** 保持稳定logical_run_id、request_id、parent关系；每次执行用新的attempt/boot/epoch。步骤记录输入引用、已提交输出、等待原因、调度位置、恢复决策；完成记录与业务结果原子提交。现有文件修改checkpoint不是完整执行checkpoint，不能直接拿它宣称主对话/工作流可续跑。后台任务表目前仅状态登记；只恢复明确有executor的类型，其他类型进入可见unsupported/blocked，补适配后验收。
+
+KTD8. **副作用先登记，结果未知先对账。** 复用Native `runtime/session/intent.go`和生产接线`internal/runtime/llm_direct.go:245–301`，以同一call/operation ID关联现有intent/result与Backend的run/owner/epoch/hold，不能让两个恢复器各自决定重放。DB账本裁决执行和hold，转录保存完整上下文及结果投影；本地个人档同样须有持久裁决。调用外部工具前持久化operation_id、参数摘要/安全引用、授权与gate、owner/epoch、幂等类别及started；确定结果写result/receipt。启动遇到started无确定result自动hold，不能只把“副作用未知”写成普通工具错误后允许模型继续发起动作。
+
+目标支持可靠幂等键时按同一key重试；非幂等动作必须取得确定未执行的终态证据，并证明旧执行者及已发请求都不会再产生效果，才允许重试。“暂未查到结果”“取消请求已发送”“本地进程已退出”均不充分。否则保持hold。shell、代码执行、Git、数据库/远端写入默认按不透明副作用处理。模型/工具因失权立即取消；无法围栏的外部动作进入hold，不能靠租约到期证明旧动作停止。
+
+KTD9. **所有工作入口共用执行所有权与额度。** 前台、notice、子代理恢复、命令消费者均经过持久claim。稳定instance_id与每次boot_id分开；续租持续进行，丢租停止执行；CAS/事务围栏覆盖状态、事件、步骤、工件发布和副作用准入。execution与admission lease关联run/attempt/epoch；恢复终态和已证明失效的许可，禁止一启动就清空全库锁。父任务等待HITL/子任务让出执行额度；持久队列及跨实例等待者有有界唤醒机制。
+
+KTD10. **命令、通知和投影处理后确认。** 命令 pending→claimed(带租约)→applied/rejected，超时claim可重领；取消先从run解析已授权conversation，按逻辑run转交当前owner；HITL验证gate/version与当前权限。notice_id/旧子run的恢复claim、对应新run、消息和销项以事务与唯一约束关联，文件resumed标记仅作投影。outbox成功才ACK，失败保持pending；分批持续drain，不受单次100条限制。
+
+KTD11. **不可变对象加DB发布记录保持文件一致性。** 写新版本对象、完成必要fsync/hash校验后，在事务中发布引用与版本；失败留下可辨认未发布对象，不直接覆盖已发布版本。工作区变更另用既有overlay/CAS与副作用账本核对，不能把可变工作区伪装为不可变对象。checkpoint/JSONL尾部截断须保存原件、识别未确认尾部，已确认部分校验失败阻塞。工件缺失报告损坏，不静默返回空内容。孤立对象按清单、引用、保留期与备份需求回收。
+
+KTD12. **业务readiness与恢复摘要分开。** liveness仅证明进程存活；readiness包含身份/认证、DB/schema、必需目录与插件、恢复决策完成和worker接线。已隔离且不影响其他会话的hold可允许API就绪，并暴露计数与处理入口；损坏权威数据或必需依赖失败不能ready。详细恢复状态只向有权owner/admin开放；公共健康响应不泄漏路径、任务ID、凭据或业务内容。
+
+服务依赖结构（实线为必需；可选项以实例manifest为准）：
+
+```mermaid
+flowchart TB
+  M[持久实例manifest与启动意图] --> S[svc控制入口]
+  S --> P[唯一进程监管者]
+  P --> D[受管PG或SQLite数据]
+  P --> A[应用与恢复协调]
+  X[外部PG或可选Redis：仅探测] --> A
+  D --> A
+  F[持久文件与插件组合] --> A
+  A --> W[任务/命令/通知/投影workers]
+  A --> H[业务readiness]
+  H --> U[Web或下游业务入口]
+```
+
+systemd的顺序依赖不能替代DB可用性检测；需真实探测，且明确依赖断开后的重连/恢复政策。监管策略参考systemd官方[service契约](https://github.com/systemd/systemd/blob/main/man/systemd.service.xml)与[进程组停止契约](https://github.com/systemd/systemd/blob/main/man/systemd.kill.xml)。
+
+KTD13. **SQLite 活动服务锁由 Backend 强制。** 在迁移和启动 run 对账之前按实际 DB／数据资源取得 OS advisory lock，持有至运行时退出；覆盖规范化路径和文件别名。marker/PID 不替代锁，SIGKILL 后由 OS 释放。合法账户 CLI 只核验同实例和兼容 schema 后做 DB 短事务，不启动 Manager；迁移独立维护。锁文件丢失或 DB 替换导致身份改变时拒绝自动续跑，不能新建可绕过的锁继续。
+
+KTD14. **初始化与事故后缺库分开。** 已登记实例启动和运维先验证预期库／marker，缺失则阻塞；显式 init 才允许创建。SQLite 可靠档明确 WAL＋FULL 并核验每个连接；PG 核验实际 fsync/synchronous_commit/full_page_writes 等，不用诊断连接默认值证明应用配置。[SQLite WAL](https://www.sqlite.org/wal.html)、[PostgreSQL WAL](https://www.postgresql.org/docs/current/runtime-config-wal.html)。
+
+KTD15. **manifest 单一权威与派生视图修复。** 复用现有 temp→fsync→rename→dirsync；读侧直接消费 manifest 或验证派生 revision。manifest 提交后、svc.env 派生前崩溃可重新生成视图，不能按旧派生配置换库。未知制品能力、登记／实际版本不符报告并拒绝危险操作，不猜测。
+
+## 5. 启停流程与恢复政策
+
+### 5.1 启动和优雅停止
+
+```mermaid
+sequenceDiagram
+  participant C as svc/监管者
+  participant A as 应用生命周期
+  participant D as 持久存储
+  participant W as workers与子进程
+  C->>D: 校验manifest、数据身份与操作锁
+  C->>C: 启动归本组管理的依赖并探测
+  C->>A: 启动固定版本
+  A->>A: SQLite取得活动服务锁；PG按既有执行所有权合同
+  A->>D: 校验schema、文件与恢复候选
+  A->>W: 完成插件/权限/预算/工作区全部装配
+  A->>D: 分类认领、对账未知效果、恢复命令与额度
+  A->>W: 开放安全恢复执行
+  A-->>C: readiness与恢复摘要
+  C->>A: 停止请求
+  A->>A: readiness=false；拒绝新写和新任务
+  A->>W: 停止领取、取消或保存安全边界
+  W-->>A: bounded join与子进程结果
+  A->>D: 持久化恢复意图、flush、收口许可/所有权
+  A->>D: 关闭存储
+  A->>A: 释放本进程SQLite活动服务锁
+  A-->>C: 停机结果（含未完成原因）
+  C->>C: 复核进程组消失；逆序停止独占依赖
+```
+
+停机预算建议应用30秒、监管60秒，必须按最长合法步骤与故障实测调整；SSE连接主动结束，不能占满排空预算。某阶段出错继续运行后续可安全清理，保留聚合结果。工具无法停止或副作用未定时先持久hold并保留现场；强制结束后必须走崩溃恢复路径，不返回“已优雅停止”。
+
+### 5.2 不同工作的恢复策略
+
+| 停机前状态 | 重启处理 | 自动执行边界 |
+|---|---|---|
+| 已完成/失败/明确取消 | 原样加载结果及原因 | 不重新执行 |
+| 已接受但未开始 | 按持久队列、权限和预算重新调度 | 条件满足后自动 |
+| 纯读、可重建的计算 | 从已提交步骤边界继续 | 不重复已提交业务结果；模型回合可重新生成 |
+| 正在执行幂等副作用 | 根据operation_id、目标查询/幂等合同核对 | 确认安全后继续 |
+| 非幂等副作用结果未知 | 自动hold，展示原因和可核对证据 | 有权人对账具体operation；确认完成则记录receipt并检查剩余步骤；确认未执行须满足KTD8终态与旧请求隔离条件；可明确放弃整项任务；禁止直接“放行即重跑” |
+| 等待HITL | 恢复稳定gate/version及持久答案 | 未回答继续等待；已回答幂等消费；撤权/版本变化拒绝并说明 |
+| 子代理/后台notice | DB唯一恢复claim关联旧、新attempt | 不由文件标记决定唯一性，不重复派生/投递 |
+| 索引与缓存 | 从文档/内容权威源重新排队，记录索引generation | Redis可清空重建；恢复模型/维度/版本一致性后发布索引 |
+| 未配置executor、缺文件或未知归属 | 保持blocked并提供处理原因 | 不丢行、不假完成、不盲续跑 |
+
+```mermaid
+stateDiagram-v2
+  [*] --> pending
+  pending --> running: 获得有效owner/预算
+  running --> waiting_hitl: 持久gate
+  waiting_hitl --> running: 当前权限下消费答案
+  running --> completed: 结果与状态原子提交
+  running --> recovering: 停机或失联
+  waiting_hitl --> recovering: 执行者重启
+  recovering --> pending: 核对可安全继续
+  recovering --> waiting_hitl: 恢复原等待
+  recovering --> hold: 副作用未知/权威数据不完整
+  hold --> pending: 有权人对账确认安全
+  hold --> recovering: operation对账结果与receipt已持久化
+  recovering --> completed: 全部必要步骤与业务结果已确认完成
+  hold --> cancelled: 明确放弃
+```
+
+`recovering/hold`在这里是目标业务语义，**不是声称现有Core枚举已支持**。过渡可用恢复账本表达；若新增公开状态，Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留，不强改成成功。
+
+用户侧复用现有任务状态、对话卡和系统管理区，显示恢复原因、进度和动作。当前只有管理员恢复 API 基础，Frontend 对账接线待 U4 实施，不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件，刷新重载权威快照；断连不推断完成。实施界面先读 DESIGN.md，遵守令牌、Collapsible和单异步状态所有者。
+
+## 6. 全量数据与组合备份
+
+| 数据类别 | 权威与恢复方法 | 必须对账 |
+|---|---|---|
+| 用户、项目、成员/权限、会话/消息、文档/版本、卡片/Surface、设置、插件授权 | PG团队库或个人SQLite；包含全部已启用插件/下游的自有存储 | 主键、owner、权限、版本、关键内容摘要；禁止以空库替代 |
+| run/step/命令/通知/审批/取消/额度/恢复hold | 持久账本与状态事务 | 链接、唯一请求、gate版本、owner/epoch、队列位置与外部receipt |
+| 上传、工件、文档大内容、输入附件、转录、派生请求 | 持久对象/文件目录，与DB清单匹配 | 内容hash、尺寸、引用版本、权限与可读性 |
+| 执行工作区、overlay/checkpoint、任务Git现场 | 受管workspace与副作用记录 | 实际修改、基准SHA、未提交文件、执行者退出与恢复边界 |
+| 程序、Web资产、插件版本、实例配置、秘密引用/密钥 | 不可变组合manifest；受限配置/秘密备份 | 摘要、schema兼容、插件签名/授权、恢复凭据可用且未泄漏 |
+| 检索/向量索引、Redis缓存、临时PID/连接 | 从权威数据重建；PID按新boot重新观察 | 模型/维度/generation；不作为任务成功、审批或永久幂等权威 |
+
+普通启停不从备份还原；数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行，禁止start自动覆盖当前数据。
+
+当前 agent backup 只复制 svc.env、history 和 data（逐 SQLite 一致性导出），不含权威 manifest，在线非 DB 文件与 DB 没有统一快照时点；它是数据目录快照，不是完整恢复包。当前 pg_dump 默认在 runtime 子目录，完整包及副本须放在数据／runtime 生命周期之外；生成时使用受限临时目录，校验成功后原子发布完成标记。半成品不列作恢复点，完成且验证的新备份存在前不执行保留策略删除。
+
+首期备份取得明确停写窗口：关闭准入、排空或隔离在途操作、停止全部相关写者，核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致；写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点，manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。
+
+恢复到新目标首先处于隔离验证模式，不启动任务调度/副作用，也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离：可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离；不得为此擅自轮换共享凭据。生成新的恢复权威代次，并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏；旧实例不可联系不能当作停止证明。无法核实则保持副作用hold，只开放受权的数据核验。
+
+同时对账恢复点至故障/隔离完成期间的外部效果：它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对，将已确认动作登记到恢复账本，确认安全后逐项解锁；不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。
+
+灾难恢复另设安全状态门禁：开放正常认证前作废备份中的全部会话和未使用登录 Key，防止已注销／消费的凭据复活。恢复点后的改密、长期 Key 撤销、角色／成员／插件授权变更与独立受信记录核对；缺记录或无法证明当前有效性时，相关主体／资源保持鉴权隔离，有权 owner／运维重新建立凭据或确认授权后开放。新执行 epoch 不代替认证撤销。普通启停／更新不执行此规则；普通账户恢复保留集成 Key 的合同也不允许灾难恢复盲目启用旧 Key。
+
+PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续WAL，不能用pg_dump冒充其基础备份，依据[PostgreSQL备份与PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)。SQLite使用现有一致性备份接口，不能在线只复制.db遗漏WAL。文件内容先耐久发布再提交DB引用，备份保留覆盖恢复点所需的对象版本。
+
+备份副本及密钥与原数据同级保护：加密、专用受限目录/角色、异机或异故障域副本、保留期限与清理owner；密钥须独立可恢复。拟定每日日常备份、持续WAL、每月及重大升级前恢复演练，频率按批准的RPO与数据量固定。实际恢复须验证登录、跨项目隔离、历史文档与附件、任务/HITL、工件下载和插件业务链；恢复时间从故障触发开始计时。
+
+部署先构建并检查完整候选目录，再切固定组合；失败仅在schema/插件/配置向后兼容时回退程序。数据回退须对账回退点后已接受业务和外部效果，不能“恢复旧库”而静默丢失新写入。
+
+## 7. 实施增量与依赖
+
+以下U-ID属于本案，与协作存储案的同名U-ID独立。每个增量完成设计细化、自检、正式验收与Review后按policy/delivery.md人工评审；本次不授权实施。新增文件名是建议，最终按实际模块边界落位。
+
+### U1. 实例与数据恢复身份
+
+当前 manifest／DB identity 基础已在源码，既有合同见 Dev `docs/recovery/u1-identity-manifest.md`；本轮只规划消费缺口、派生修复和显式 init/restore，不重复建立身份层。
+
+对应R2/R3/R9；无前置。范围：`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。
+做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口；保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归，再改解析器。
+验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统；更换二进制路径/程序版本或以不同cwd调用svc后，DB identity、数据/工件/工作区根与插件组合保持一致（对应R2更换程序/cwd条款）。使用真实PG特有测试记录核对，桩测试只能辅助。
+
+### U2. 服务组与进程监管
+
+当前 recover/watchdog/desired 已有首切片，余量为服务组、依赖 readiness、唯一监管与完整操作恢复，不再记为全部未实现。
+
+对应R1/R8；依赖U1。范围：svc组编排、可选Redis适配、分发仓`deploy/agent-system.service`及安装接线、新增隔离服务组故障测试。
+按KTD3/KTD4建立依赖图、desired state、可恢复lifecycle operation与单一监管；加入boot/start/exe身份与进程组校验。必需/可选、受管/外部资源由manifest决定。首次切监管在明确停机窗口完成，失败回到原监管且不形成双启动。
+验收：全组停止后启动；先PG后应用；主动stop保持停止；kill自动退避恢复；主机重启按策略恢复；PID复用、残留子进程、端口冲突、依赖启动失败、不透明外部DB均正确拒绝/报告；不得停止其他服务组的共享依赖。
+
+### U3. 应用启动、停机与真实就绪
+
+对应R1/R8/R10；依赖U1，可与U2并行。范围：`modules/backend/internal/app/app.go`、`runmgr/runmgr.go`、`runmgr/events.go`、`plugins/host_v2.go`、server健康接口及其生命周期测试。
+统一lifecycle context、准入开关、消费者停止与worker join；恢复执行移到装配结束；不同停机原因统一条件结算；sidecar受监督并纳入收口；readiness、恢复摘要和受限诊断按KTD12实现。停机预算属预算来源变更：现状HTTP停机超时仅5秒且超时即返回、跳过后续事件清冲（app.go停机序列，SELF源码核验）；“应用30秒/监管60秒”须显式替换该常量并按最长合法步骤与故障实测校准，不得沿用旧值。
+验收：插件/预算/Workflow未装好不启动恢复任务；停机同时提交新run被拒；SSE与慢工具不跳过flush/清理；子run不被cancelled覆盖；sidecar崩溃可检测；DB坏/恢复扫描失败不ready；hold不影响无关会话的正常读写。
+
+### U4. 持久任务恢复与副作用隔离
+
+对应R4/R5/R7；依赖U3，并复用U5所有权接口；U4/U5作为同一安全交付批次，完整性验收前不开放自动续跑。范围：runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。
+落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围；若新增recovering/hold为公开状态，设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表，作为设计评审前提。
+Frontend 接线复用任务／对话卡和系统管理区：有权 owner/admin 查看具体 operation、未知原因和证据引用，提交已完成 receipt、未执行终态及旧请求隔离证明，或明确放弃。提交防重复，失败保留输入与原因，成功重载权威状态；Backend 按 operation 权限／版本／epoch 裁决，不以当前整 run release API 代替逐项对账。浏览器验收覆盖发现 hold→对账→剩余步骤恢复，拒绝越权和「放行即重跑」，不新增页面。
+验收：排队/主run/子run/HITL/索引各类任务kill并两次恢复；工具“完成外部动作、结果未提交”只hold不重做；查询暂未发现但外部请求稍后完成时不发送第二次请求；幂等目标使用同operation key；Native pending intent只由统一账本决策，不生成普通错误后绕过hold；确认一个operation完成后执行剩余必要步骤，不假结算整run；未知工具默认隔离；撤权后禁止续跑；无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源，未跑标NOT_RUN。
+
+### U5. 所有权、额度、命令、通知与投影闭环
+
+对应R4/R5/R6/R10；依赖U3；与U4共同验收。范围：`store/execution.go`、`store/admission.go`、`runmgr/admission.go`、`runmgr/commands.go`、server取消/HITL、notice、surfacesvc与PG集成/多进程故障测试。
+续租及失权取消覆盖全部入口；持久队列/额度对账与共享唤醒；命令lease+处理后ACK；notice事务消费；Surface成功后ACK且持续批量drain。租约到期后的外部不确定行为仍进入U4 hold。
+验收：占满额度kill后新工作可前进；长run跨租期不失权；旧owner晚到状态/事件/工件被拒；claim后kill命令可重领；取消正确解析conversation并不越权；HITL答案一次生效；notice及子代理并发恢复只建一个后继；超过100条投影事件全部处理，发送失败不清pending。两真实进程与真实PG是必要证据。
+
+### U6. 文件发布、组合备份与部署回退
+
+对应R3/R7/R9；依赖U1/U3，恢复账本完整验收依赖U4/U5。范围：blobstore/content、workspace与checkpoint、插件恢复适配合同、svc deploy/update/backup、分发仓安装、备份manifest与restore测试。
+按KTD11发布不可变版本，扫描缺失/孤立对象；登记全部插件/下游存储；按第6节生成一致恢复点、保护副本、恢复到新目标；候选完整构建后切版本，保留兼容上一组合。
+验收：对象写后DB提交前kill；覆盖发布过程中kill；日志尾截断/文件缺失保留现场；备份恢复后原文hash/权限/插件链一致；恢复新目标后旧实例复活仍不能产生外部效果，未完成旧写路径隔离时新目标不调度；恢复点后已发生的外部效果对账完成前保持hold；升级ready失败可在兼容条件下回退；不兼容schema拒绝程序自动回退；数据回退不静默丢新写入。
+另覆盖恢复点后注销会话、消费／撤销登录 Key、撤销集成 Key、改密与撤回角色／项目／插件权限：恢复旧包后旧会话和登录 Key 不再有效，无法证明有效的长期 Key／授权保持隔离；owner 正常确认后的新凭据可用。与普通重启原密码保持分别签收。
+
+### U7. 故障验收与交付放行
+
+对应全部需求；依赖U1–U6。范围：Dev新增隔离`tests/integration/recovery/`、故障注入控制点、运行手册与需求证据表。
+固定Dev/全部组件、运行制品与配置摘要；使用脱敏数据、独立端口/PG库/文件根及工具目标；记录故障点和恢复统计。先执行小规模逐点故障，再在批准规模混合运行。破坏性kill/断电测试只能在隔离环境实施。
+验收：第8节每类故障均有可重放证据；RPO=0档已确认数据零遗漏，灾难档恢复点差距≤批准RPO且点内数据零遗漏、点后缺失和外部效果明确对账；零未识别重复副作用、零越权/双有效写者；时间满足批准指标；用户实际刷新、重连、登录、任务/HITL、文档和工件链通过。服务恢复与数据/任务恢复分别签收。
+
+建议交付批次：A=U1/U2/U3（可靠启动及安全停机，自动任务续跑关闭）；B=U4/U5（安全自动续跑与命令闭环）；C=U6/U7（文件耐久性、灾难恢复及全系统签收）。只交付A不能宣称完成用户的全部需求。
+
+### U8. SQLite 活动服务隔离与既有存储门禁
+
+覆盖 R2/R3/R6/R11/R12，复用 U1 身份；近期优先于自动恢复和共享库测试。范围：Backend `internal/app/app.go`、`internal/store/store.go`、`internal/store/system_identity.go`、新增 `internal/instanceguard/`（拟定）；Dev `scripts/svc.sh`、`docs/svc.md`。锁只控制活动服务运行时，CLI 身份／schema 合同由[账户方案](2026-10-12-svc-unified-deploy-and-login-key.md) U7 负责。负责人待实施批准时指定。
+依赖：既有 U1；联合确认 service／CLI／migration 模式，先刻画原例和别名冲突，再实现；不直接把当前 dev 数据迁往 PG。
+测试：新增 Backend `internal/instanceguard/guard_test.go`，扩展 `internal/store/system_identity_test.go`；Dev 新增 `tests/test_svc_storage_ownership.py`，复用 `tests/test_svc_identity.py`。新增路径为计划。
+T8-1：两个独立进程同时启动同 SQLite，只有一个进入迁移／恢复；第二个明确拒绝，第一个 run/HITL 不变。
+T8-2：直接二进制、legacy、符号链接和可构造的文件别名不能绕过；真实 DB 替换／锁根丢失被识别。
+T8-3：活动服务 SIGKILL 后合法同实例可重启，OS 释放锁；主动停止不被 watchdog 错拉起。
+T8-4：服务运行期间合法账户 CLI 可提交短事务；错实例／缺库拒绝、不建目录、不 migrate；迁移不与活动服务并发。
+T8-5：更换端口、cwd、程序版本保持同一资源；测试候选默认独立根，显式指定共享根也不得绕过保护。
+T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合同核验，磁盘满／写失败不返回成功。
+环境：独立 SQLite 根与端口、真实 PG 独立库回归；双进程和 kill 禁止在当前 dev/candidate 执行。全部 T8 当前 NOT_RUN。
+
+近期批次 A0=U8＋账户方案 U7/U5：先稳定数据归属和账户链路；另行授权后完成 dev 原账户正常登录／重启／更新验收，见账户方案 §7。A/B/C 保留；U4/U5 联合验收后才开放自动续跑，A0 不代替全量恢复。
+
+## 8. 验证合同
+
+| 故障/操作 | 最小判据 | 对应需求 |
+|---|---|---|
+| `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 |
+| SQLite 双进程、直接启动、别名、锁释放 | 第二活动服务在迁移／run对账前拒绝；合法 CLI 可用；kill 后同实例可重启 | R2/R6/R11 |
+| 实际 DB 耐久档、权威文件发布点、磁盘满 | 参数来自应用连接；确认结果已耐久；失败不发布成功；旧版本可读 | R3/R7/R12 |
+| 应用SIGTERM/SIGKILL/OOM | 持久数据完整；安全工作可恢复；额度无永久占用；无残留写者 | R3/R4/R6/R8 |
+| PG停止/重启、断连或提交响应丢失 | 不切SQLite；不假接受；按幂等记录对账；重连后可用 | R2/R3/R5 |
+| 主动stop与异常退出、监管/编排中途kill | 主动停止不拉起；异常按running意图恢复；操作重复安全 | R1/R2/R8 |
+| PID复用、重复启动、旧进程冻结后复活 | 不误杀其他进程；一个有效owner；旧epoch无发布/副作用权限 | R1/R5/R6 |
+| 排队、HITL、跨实例取消、子代理/notice恢复中途kill | 接受意图不丢；审批一次生效；后继run/消息不重复 | R4/R5/R6 |
+| 外部效果完成而结果未落库、旧请求延迟完成 | 自动hold、有receipt对账和权限检查；暂未发现结果不触发非幂等重试；动作结算后继续未完成步骤 | R4/R5 |
+| 文件rename/发布边界kill、磁盘满、文件/日志截断 | 不确认未耐久结果；原发布版本一致；损坏可定位、原件保留 | R3/R7 |
+| 插件sidecar退出、插件存储缺失、索引重建失败 | 必需失败不ready；可选明确降级；数据与授权保留 | R1/R3/R7/R8 |
+| SSE断开/页面刷新、>100待投影、投递持续失败 | cursor补齐持久事件；旧事件丢弃；失败记录不被ACK | R4/R7/R10 |
+| 主机重启/断电 | 原数据盘恢复、全部期望服务重新就绪、耐久性指标有真实证据 | R1/R3/R7/R8 |
+| 完整备份在新目标恢复、旧实例复活、升级失败/回退 | DB+文件+秘密/版本匹配；旧写路径隔离；恢复点后外部效果对账；灾难档满足批准RPO；权限与业务链可用；回退兼容且不静默丢新写入 | R3/R5/R6/R9/R10 |
+
+验证分层：svc治理桩回归→Backend单元/SQLite→真实PG及多进程→真实工具替身故障链→少量真实模型→真实浏览器与主机级故障→灾难恢复。每层证明不同合同，不相互替代。
+
+执行时使用项目已有`make test-governance`、`make test-backend-pg`、`make test`、`make build`并增加受管隔离recovery入口。真实PG/Redis/模型/主机测试缺环境时必须明确NOT_RUN或SKIP及缺项，禁止把零用例或条件跳过当通过。按AGENTS要求验收/请求审核/合入前分别task-sync；所有precheck、同步、测试原始输出通过make evidence进入任务卡，并区分SELF/REPLAY/GATE。业务行为面的真实模型验证遵循policy/delivery.md，单测不替代。
+
+本轮只进行源码与文档检查，业务/数据库身份查询、故障注入、模型试验、迁移、服务启停、部署均NOT_RUN。方案r2不能作为恢复能力验收结论。
+
+## 9. 兼容、在途任务与批准事项
+
+本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。
+
+原 r2 的 svc-autorecover 二选一属于历史启动现场；当前 recover/watchdog 和 U1 身份已有源码，不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管／RDM UI／端口回收任务，避免重复修改入口。RDM／插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。
+
+备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
+
+实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。
+
+下一任务建议为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
+
+## 10. 全系统完成条件
+
+只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
+
+本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+
+## 11. D1/D2/D3 部署根治补充（r3.1）
+
+编号 D1/D2/D3 只属于本补充，避免与本案 U1–U8 重名。已合入且不再重做：Dev #474（按实例重置身份变量、停旧前候选门禁、update 走 manifest 迁移、普通启动只验证）、Backend #180（`pkg/identity`）、RDM #276（identity 子命令与未知位置参数退出）、Dev #477（backend pin 到含 #180 的 `acabb85`）。
+
+### 11.1 现场快照与 rdmcand 数据归属（SELF，2026-10-12T13:39:21Z）
+
+快照目录（在线 `sqlite3 .backup` / RDM `VACUUM INTO`，未停服务）：
+
+- `runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z`
+- `runtime-backups/{dev,rdm1,rdmcand}/domain-20261012T133921Z`
+
+只读核对副本，未移动任何业务数据。rdmcand 在 `2026-10-12T06:51:14Z`–`10:02:40Z` 使用 `runtime/dev/data`。该窗口内：
+
+- dev 库的会话、消息、事件均不落在窗口内。最后一条消息时间 `06:50:43Z`，早于 rdmcand 挂上该目录。会话与用户属于 dev（owner `weichen`、`genui-smoke`）。
+- 窗口内仅有 13 条 `command_audit`，全部是 `rdm.inspect.*`，owner `weichen`，没有领域事件。
+- 三份 `rdm.db` 的 `events` 均为 0。dev 的领域库更大（含权限表，schema_version=6），rdm1/rdmcand 的领域库只有字典与 schema 行。
+- rdm1/rdmcand 的 `agent-system.db` 只有 `2026-10-12T13:19:47Z` / `13:20:12Z` 由候选门禁写入的身份行，没有业务行。
+
+处置（未执行，需逐项授权）：不把 dev 的会话或领域库迁到 rdmcand。没有一份应属于 rdmcand 的历史领域数据需要回迁，因此不触发身份 `adopt` 重审。rdm1/rdmcand 当前库是空壳加已建立的身份行。
+
+### 11.2 D1 身份流程收尾
+
+对应 U1 的消费缺口。完成条件：
+
+- 身份 CLI 只打开既有库：不建文件、不建目录、不迁移。`agent_system_identity` 表（v27 起，列冻结为 instance_id/dbref/schema_version/created_at）缺失则拒绝并提示受控迁移。比本二进制更旧或更新的 schema，只要该表仍在，verify 仍可读。
+- verify 输出带 `schema_version`。DSN 走 `AGENT_SYSTEM_DSN` 或权限恰好 0600 的 `--dsn-file`；`--dsn` 保留并告警。
+- 能力文档一份 JSON，经 `version --json` 与 `identity capabilities` 输出。探测只跑 `version --json`，在空目录、清空环境、超时内执行。非 JSON 视为无能力。
+- 顶层未知子命令 exit 2，不以 `-` 开头才拦截，避免落入 serve。
+- manifest `identity.db_marker`：`fresh` | `pending` | `established`。新实例首次部署目标目录必须为空，启动建库后 ensure 变为 established。领养时有能力且库已存在则 ensure，否则 pending。pending 只在库文件存在时补齐，不迁移。established 缺行或不匹配时，start/restart/deploy/update/recover/init 全部拒绝；唯一修复入口是显式 `adopt --confirm <instance_id>`，并先打印库大小、关键表行数和最近写入时间。
+- `svc_lifecycle` 是 start/restart/deploy/update/recover 的共同入口。update 与 recover 逐服务以 `env -i` 启动子进程，不传入 `AGENT_SYSTEM_*`。serve 使用显式环境，并写入 0600 的 `serve.env` 供裸启动与 recover 复用。
+
+### 11.3 D2 切换事务
+
+对应 U6 的部署回退。制品进入 `runtime/<name>/releases/<rid>/`，`current` 用临时符号链接加 `mv -T` 切换。`bin`/`plugins`/`htdocs` 改为指向 `current/` 的稳定链接。切换日志 `deploy-journal.json`（0600）先写 phase 再执行。失败回到上一版本并恢复原期望运行态，不覆盖业务库。schema 不兼容时在停旧服务前拒绝。前进迁移必须 `deploy --migrate-schema --confirm <instance_id>` 且先 backup，日志标记 forward-only。能力文档增加 `schema.target` 与 `schema.compatFloor`；每条迁移登记是否破坏旧版读取，漏登记则测试失败。
+
+### 11.4 D3 真实组合门禁
+
+对应 U7 的故障验收入口，范围限于部署生命周期。Dev 用 `tests/integration/lifecycle/rdm.pin` 固定 RDM SHA（当前、上一版、无 identity 的旧版）。CI test-pg 按 pin 取固定 SHA，白名单加入 RDM 及其 pins。`make test-lifecycle` 缺 PG、源码或制品即失败，不静默跳过。桩测试不能代替该门禁。RDM 登录入口与账户 CLI 的 DSN 退出命令行依赖账户方案 U7/U5；未就绪的项保持 NOT_RUN，D3 不得标完成。
+
+### 11.5 验收
+
+缺一项则对应增量保持未完成：双向混合批次身份不串用；无 manifest 时 deploy/update/recover 一致；无能力、缺行、不匹配在停旧前拒绝且不建库；两次裸重启及换端口、换版本、换目录后身份不变；构建失败、启动即退、健康超时、工作台失败可回滚；切换中断后登记与制品一致；真实 PG 绑定与多实例检查通过且凭据不进命令行、日志和证据；RDM 页面、登录、领域命令和原有数据可验证，不能只看 HTTP 200。
@@ -0,0 +1,288 @@
+---
+title: svc 统一部署与一次性登录 Key 方案
+type: feature
+date: 2026-10-12
+artifact_contract: ce-unified-plan/v1
+execution: code
+product_contract_source: ce-plan-bootstrap
+---
+
+# svc 统一部署与一次性登录 Key 方案 r3
+
+确认状态：**r1 原批准保留；r2 增补已随 #87 合入（其评审状态以正文与审阅记录为准，不因合入视为已批准）；r3 登录恢复实施记录待人工评审**。r1 的批准记录为 2026-10-12 用户「批准，继续推进」（五阶段及 U1/U4 规格，允许对应实施和 PR）。本轮用户要求仔细调研、详细方案并「继续」，覆盖方案修订及本地文档准备，不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。
+修订记录：r1＝2026-10-12 草案经源码复核后定稿（四项取舍采纳；补齐 §6 合同；对齐恢复方案 KTD 与已合入的 recovery U1 实例身份）；同日获批并进入推送与 U1/U4 实施。
+r2＝同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口；保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号，补充 R13–R15、KTD11–KTD14、U7/U8，并细化 U5。新增内容未批准；不以原批准记录代签新增范围。
+r3＝2026-10-13 用户提交《登录流程方案》并指示「按此方案实施」——该指示即登录恢复范围的实施批准；当日实施合入（Backend #187、Frontend #76、Dev #504），合同定稿于 Dev `docs/svc-deploy/2026-10-13-login-recovery-contract.md`，实施记录见 §11。r3 为实施记录与三裁定回写，不改动 R/KTD/U 编号语义。
+需求来源：2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口（二进制与源码、环境准备、无初始密码开户与账户恢复），并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人：weichen；编制：Cursor Agent。
+主记录：本文；任务卡：Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。
+
+## 1. 目标与成功边界
+
+**目标：在干净或既有机器上，用同一套 `svc` 入口完成二进制或源码部署、按档准备依赖，并通过后端账户能力完成无初始密码开户与账户恢复；一次性登录 Key 只能兑换设密受限会话，完成设密前不能访问业务数据。**
+
+必须区分三类能力：
+
+| 能力 | 结果 | 非目标 |
+|---|---|---|
+| 统一安装 / 升级 | 指定版本或提交物化为可切换候选；切换后实例身份、DB、数据根与账户不变 | 不接管共享 PostgreSQL；不因发现端口而认领外部服务 |
+| 环境检测与准备 | `doctor` 只报告；`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建；工具链版本读自所选提交或发布清单 |
+| 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key；原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户；不迁移业务归属；普通找回默认不撤销长期集成 Key |
+
+与 [服务重启与全量数据恢复方案](2026-10-12-service-restart-data-recovery.md) 的关系：
+
+- **复用** KTD1–5、KTD12：持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。
+- **复用** 已合入的 recovery U1（Dev #415）：`runtime/<name>/manifest.json`、启动身份校验、`svc init`、原子写路径（见 Dev `docs/recovery/u1-identity-manifest.md`）。
+- **本方案新增**：部署来源统一（binary/source）、doctor/env prepare、账户生命周期与一次性登录 Key、安装入口与双轨收敛。
+- 命名区分：**账户恢复 Key** ≠ **服务数据恢复**。
+
+## 2. 当前事实及重点差距
+
+本轮 source 基线（SELF）：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（增加任务元数据）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；Dev 固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。本轮 Documents 草案从其独立权威 main `1048e7c6afc2bb4efc541e68575c3fb2669ee332` 起步；与 Dev 固定版相比，两份目标方案正文没有上游差异。Dev gitlink 未推进。原 r1 基线只作历史，不用于当前能力判断。
+
+2026-10-12 17:37:03（Asia/Shanghai）的只读运行观察和启动／同步命令，原始脱敏输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。这是 SELF 观察，不是登录、故障或恢复验收，后者均 NOT_RUN。
+最终同步基线为 Dev `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9`：主干另已推进固定 Documents 至 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，并修复 svc 批量操作的 PIDCHECK/EXEC 等内存态串用；本轮未重复该修复，也未推进本轮 Documents 草案 gitlink。Backend／Frontend 固定 SHA 未变；上述初始基线和17:37观察保留历史时点，不冒充最终 HEAD。
+
+| 对象 | 已存在的基础 | 尚需补齐 |
+|---|---|---|
+| 部署来源 | `deploy --from local\|dev\|release\|rdm`；dev/rdm 独立缓存物化；release 读本地 Releases 仓并校验 sha256 | 远程下载/离线导入；统一 `install`；release@ver 钉扎（现 `sort -V\|tail -1` 取最大版本，见 `scripts/svc.sh` `resolve_release`） |
+| 部署生命周期 | 预检失败不停机；预检通过后 **先停再构建**；无程序备份/自动回滚 | 候选获取与校验全程不停旧服务；缺摘要硬失败；迁移后回退独立判断 |
+| 实例身份 | recovery U1：manifest + marker + init；`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置；缺绑定拒绝，禁止回落 `./data` |
+| 环境 | 端口/`flock`/pg 工具链按需检查；文档列前提 | `doctor` / `env prepare`；无 `flock` 时不得放行冲突操作（现状直通） |
+| 账户 CLI | Backend 已有 create/reset-password/list/issue-login-key/revoke-login-key/bootstrap-admin；svc 已接 `user` 且附加 OpenExisting | 顶层／专题帮助未列账户入口；OpenExisting 仍 migrate；账户路径未完整验证 DB identity；参数回显及 argv 凭据需整改 |
+| 登录凭据 | 长期 `api_keys` 与独立 `login_keys` 已分离；一次性 Key 原子兑换为短期受限会话 | 原子开户＋签发、统一密码变更及审计仍有缺口；不能把基础实现等同于整体验收 |
+| 强制改密 | Backend 已有受限会话和 must-change 中间件，强制设密成功销毁会话并要求重新登录 | Frontend 仍只有密码／长期 Key 两个入口，未接兑换及 sessionScope/reloginRequired；设密后直接 onDone 与后端不兼容 |
+| 安装双轨 | Dev `svc deploy` 多实例；Releases `install.sh` 系统 systemd | 统一部署计划；`install.sh` 薄封装或明确遗留 |
+
+命题裁定（源码复核）：
+
+1. 长期 API Key 是 show-once plaintext，不是 single-use；一次性登录 Key 是独立类型，当前代码已区分。
+2. r1 所记「无统一改密门」已被 U4 源码覆盖，不能继续作为待建能力；普通改密／管理员重置仍缺统一事务及旧恢复 Key 作废，见 `modules/backend/internal/server/accounts.go:208`、`modules/backend/internal/store/auth.go:244`。
+3. `scripts/svc.sh:1503` 已实现 user 转发，但帮助未列；`modules/backend/internal/app/app.go:743` 的账户插入和 Key 签发分别提交，不能采信注释中的「同事务」。
+
+### 2.1 dev 8788 事件与归因边界
+
+用户明确故障对象为 dev（127.0.0.1:8788）。17:37 的实际进程打开 `runtime/dev/data/agent-system.db`，数据库 marker 为 dev 的 SQLite 身份；该现场没有使用 PostgreSQL，不能沿用旧报告的 pg1/agent 描述。
+
+| 只读对象（北京时间） | 账户身份 | 最后设密时间 | 与 live 摘要比较 |
+|---|---|---|---|
+| 12:35:03 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
+| 14:50:37 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
+| 17:37 的 live | 同一账户，must-change=0 | 16:03:20 | 当前值 |
+
+比较仅输出时间、状态及相等性，不输出摘要或凭据。它证明字段重写，不证明明文改变；随机盐使同一明文的重新散列也可能不同。未发现正常启动／更新／迁移 up／设置播种自动覆盖既有密码的路径；现有 audit_events 只有 Surface 事件，无法归因此次写入。另有已消费恢复 Key，但其消费时间不能证明之后哪次设密由它触发。
+
+前一轮观察到 dev 与候选 rdmcand 指向同一数据根；17:37 候选处于停止，因此历史共享不写成该时点双进程事实。18:14:09 续查时，外部流程已将候选重新启动于独立的 `runtime/rdmcand/data/agent-system.db`，实际文件 inode 与 dev 不同，登记和制品版本相符；dev 最后设密时间仍为16:03:20。这缓解了当前共享现场，不能代替 Backend 防误用锁或完整验收。历史共享说明跨实例影响范围，不证明某次更新主动改密；本轮未执行这些现场变更。
+
+本轮不进行真实账户登录尝试或再次重置来验证旧密码；故障重放仅在脱敏、独立数据副本上执行。首批完成还需另行授权的 dev 原账户正常登录验收，见 U5／U8 合同；该验收不在 live 进行 kill、并发或故障注入。历史操作者归因仍未证实，新增审计不能反向补造旧事件。
+
+## 3. 需求合同
+
+| ID | 范围 | 要求与可判定验收 |
+|---|---|---|
+| R1 | 安装入口 | `doctor` / `install` / 兼容 `--from` 生成同一部署计划；二进制无需 Go/Node；源码固定提交且子模块组合可核验 |
+| R2 | 实例身份 | 启停、升级、开户、签发 Key 命中同一 store 与 data 根；缺失/不符拒绝；与恢复案 R2/manifest 一致 |
+| R3 | 切换安全 | 构建/下载/摘要失败时旧服务继续；程序+插件+前端作为版本组合切换；固定版本不得被「最大版本」替代 |
+| R4 | 存储档 | team 默认 PG+auth；`existing` / `managed-local` / `local(SQLite)` 显式选择；PG 失败不回落 SQLite |
+| R5 | 开户 | 无初始密码；角色明确；创建与激活 Key 同事务；同名冲突不覆盖 |
+| R6 | 账户恢复 | 精确命中既有账户；不改密码/不吊销会话/不改业务数据于签发时；保持 owner/角色/成员关系 |
+| R7 | 一次性 Key | ≥256bit、只存摘要、activate\|recover、默认 TTL 30min、状态机、原子兑换、专用 POST body |
+| R8 | 受限会话 | 仅身份查询、设密、退出；业务/下载/SSE/admin/插件拒绝；普通 `must_change` 同样服务端限制 |
+| R9 | 设密事务 | 写 hash、清待激活/待改密、作废未用恢复凭据、失效相关会话同事务；成功后销毁受限会话并要求密码重新登录 |
+| R10 | 集成 Key | 普通找回默认保留长期 API Key；失陷恢复显式 `--revoke-all-credentials` |
+| R11 | 首次管理员 | 仅核验为新实例（无用户且无历史业务标记）；事务防并发；不得因「未发现管理员」接管有数据环境 |
+| R12 | 证据 | 验收绑定固定源码/制品摘要/环境；SELF/REPLAY/GATE 分源 |
+| R13 | 可发现与兼容 | 完整／短帮助、help user、实例 user --help 和文档列出实际账户能力；不支持的制品在调用前拒绝；帮助／探测不建库、不迁移、不启动服务 |
+| R14 | 账户稳定与审计 | 普通启停／更新不隐式重置；密码变更、恢复凭据／会话处理及成功审计原子提交；记录 actor、入口、实例、operation 与时间，不记录密码、摘要或 Key 明文 |
+| R15 | 运维既有库 | 账户操作核验预期库和实例；读操作不建库或 migrate；schema 不兼容明确拒绝，迁移走独立入口；CLI 参数和日志不暴露凭据 |
+
+## 4. 技术决策（KTD）
+
+KTD1. **部署方式只决定程序来源，不决定数据位置。** binary ↔ source 可切换；切换保持 DB、数据根、账户与 instance_id。
+
+KTD2. **账户规则只在 Go 后端。** 脚本调用实例对应版本的 CLI；不直接改用户表。
+
+KTD3. **一次性登录凭据独立于长期 `api_keys`。** 专用表与兑换 API；普通 Bearer、SSE `?key=`、长期 Key 路径均拒绝。
+
+KTD4. **受限会话为独立 scope。** 默认 10 分钟；allowlist 仅 me / 设密 / logout。
+
+KTD5. **团队安装默认 PostgreSQL；存储选择显式。** 与恢复 KTD5、`config.Tier=team` 一致。
+
+KTD6. **一次性 Key 默认 30 分钟**（可配置建议范围 5–120 分钟）；审计记实际 TTL。
+
+KTD7. **激活/恢复设密成功后必须重新密码登录**（销毁受限会话、清 cookie）。普通主动改密可保留「要求原密码」路径；激活路径不要求原密码。
+
+KTD8. **普通账户恢复默认保留长期集成 Key；失陷显式撤销全部凭据。** 两种情况均保留业务数据。
+
+KTD9. **候选校验完成前不停旧服务**；切换短窗；schema 迁移后能否自动回退旧程序另行判断，失败不自动用备份覆盖业务库。
+
+KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端；Releases `install.sh` 变为薄封装或文档降级为遗留，禁止第三套生命周期。
+
+KTD11. **能力声明与帮助同源，但后端仍是执行权威。** 新制品提供无副作用的结构化能力声明；旧制品仅按已验证版本兼容，未知形态拒绝。禁止尝试未知子命令或靠 strings 包含某词推断能力。保留 reset-password 的直接重置语义，不偷偷改成签发恢复 Key。
+
+KTD12. **统一密码与开户事务。** 严格唯一 INSERT；散列计算在事务外，事务内重新核验权限／账户版本。主动改密、CLI／管理员重置、恢复设密共同执行密码＋标志＋旧登录 Key 作废＋规定会话处理＋审计。普通路径保留集成 Key，失陷模式按 KTD8 明确撤销；失败全部回滚。
+首次管理员按实例串行，不能只依赖 owner UNIQUE：PG 锁定既有实例身份行，SQLite 使用立即事务，取得串行权后重新核验无用户、无历史业务；引导与能改变此前置条件的开户共用串行点。管理员、激活 Key 和审计共同提交；marker 缺失时由显式 init 处理，账户命令不得补建身份。
+
+KTD13. **审计可归因，运维不隐式迁移。** 成功审计与变化同事务；失败记录注明未提交；HTTP actor 来自已认证会话，CLI 记录受信 OS 运维 UID／身份来源，不接受调用方填写的 actor 作为证明。实例身份和操作 ID 实填。既有库读命令只校验兼容性；迁移另行批准和执行。
+
+KTD14. **凭据只经安全输入和单次交付。** 优先无回显输入／stdin／受保护文件，DSN 不传 argv。serve 已消费 AGENT_SYSTEM_DSN，账户 CLI 的等价安全输入需在 U7 显式接入并以能力声明核验，不能假定当前 user flags 已读取环境。非交互输出独占创建 0600 文件，日志／evidence 只记凭据 ID。提交后交付失败按 operation 查询，再撤销／重发；库存摘要不能重新打印旧明文，不把重试当首次创建。
+
+## 5. 职责划分与接口示例
+
+| 部分 | 负责 |
+|---|---|
+| `svc.sh` | doctor、env prepare、获取制品、构建、实例配置、生命周期、调用账户 CLI |
+| 后端 CLI | 创建账户、签发/撤销一次性 Key、核验目标库、OpenExisting、操作审计 |
+| 后端认证 | 原子消费 Key、受限会话、设密事务、中间件限制 |
+| 登录页 | 输入一次性 Key、设密、过期/重发提示；遵循 `DESIGN.md` |
+| 发布制品 | 版本、平台、摘要、组件版本、能力声明 |
+
+拟新增 CLI（当前脚本尚不支持；兼容 `--from` 保留）：
+
+```bash
+./svc.sh doctor --mode binary --tier team
+./svc.sh install prod --mode binary --version <固定版本>
+./svc.sh install prod --mode source --repo <仓库> --ref <固定提交>
+./svc.sh prod deploy --mode binary --version <固定版本>
+./svc.sh prod user create --owner alice --role user
+./svc.sh prod user issue-login-key --owner alice --purpose recover
+./svc.sh prod user list
+./svc.sh prod user revoke-login-key --id <凭据编号>
+```
+
+Linux 服务账户与应用账户分开管理。
+
+## 6. 规格合同（实施前必须写进 U1/U4，否则返工）
+
+1. 独立凭据类型 + `POST` body 兑换 API。
+2. 会话 scope / 中间件 allowlist；覆盖 `must_change` 普通首登。
+3. 设密接口分型：受限会话不校验原密码；普通改密继续要求原密码；同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。
+4. 密码未设置状态：`password_hash` 可空或 sentinel；`VerifyLogin` 拒绝未设密；创建 = 用户行 + 激活 Key 同事务。
+5. CLI `OpenExisting`：目录/DB 不存在则失败；账户运维默认只校验兼容 schema，不 migrate；迁移独立执行。配套 U1 v0.2 候选同此合同，原 requireCompatible 自动 migrate 是历史实现。
+6. `release@<ver>` 必须解析到该版本目录；缺摘要硬失败。
+7. 部署：获取/构建/校验不停旧服务；组合切换；迁移后回退独立判断。
+8. `install` 与 `--from` 同一计划；双轨收敛（KTD10）。
+9. 首次管理员仅新实例；事务防并发。
+10. 凭据交付：交互 stdout 一次 / 非交互 `chmod 600` 文件；日志与 evidence 只记凭据 ID；随机密码路径首期可并存但默认无密码 + Key。
+11. 无 `flock` 时拒绝冲突生命周期与账户操作（收紧现状「直通」）。
+
+详细设计（正文在 Dev 仓，随本任务分支提交）：
+
+- U1：`docs/svc-deploy/u1-instance-account-binding.md`
+- U4：`docs/svc-deploy/u4-one-time-login-key.md`
+
+## 7. 增量与完成门槛
+
+| 增量 | 主要范围 | 完成条件 |
+|---|---|---|
+| **U1** 实例—账户绑定补齐 | 账户 CLI 读实例 manifest；OpenExisting；锁缺失拒绝；install 骨架对接既有 identity | 开户/签发命中同一 store；错误 data/DSN 拒绝；与 recovery U1 字段对齐 |
+| **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署；固定版本与摘要可核验；修复 release 钉扎 |
+| **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验；幂等；不接管共享服务；binary 不装 Go/Node |
+| **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密；受限会话无法调业务 API；并发兑换单胜 |
+| **U5** 脚本与登录页接线 | 账户帮助、无副作用能力探测、凭据安全交付、Login/设密页 | 新建与恢复走通；设密后清受限会话并返回密码登录；不支持的产品明确拒绝；DESIGN.md |
+| **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档；故障注入；浏览器 + 真机；治理回归 |
+| **U7** 账户事务与稳定性补齐 | 原子开户／引导、统一改密与撤销、审计、只读兼容打开 | 并发建号不覆盖；中断无半状态；旧恢复 Key 失效；身份缺失不改库；升级保持登录能力 |
+| **U8** 实例运维核验与凭据诊断 | 账户状态／事件查询、绑定和制品诊断；补齐 U1 身份消费 | 可定位合法变更来源、识别错库／失效会话／错误 Key 类型；只展示非秘密元信息 |
+
+**当前 U1/U4 基础已在源码中，近期优先 U7 和 U5，并与恢复方案 U8 隔离保护协调。** U7 先冻结后端账户事务／审计及能力声明合同；U5 随后完成浏览器与脚本；U8 诊断复用其记录。U2/U3 保留后续，不让通用安装器阻塞 dev 账户稳定。各仓从共同批准基线起独立任务；Backend → Frontend → Dev 组合，正式组合验证后才推进 gitlink。
+
+### U7 近期实施与验证合同
+
+覆盖 R5/R6/R9/R10/R11/R14/R15；依赖既有 U1/U4，实施负责人待指定。
+范围（相对于 Backend）：`internal/store/auth.go`、`internal/store/login_keys.go`、`internal/store/platform.go`、`internal/app/app.go`、`internal/server/accounts.go`、`cmd/agent-system/main.go`；迁移目录仅在 schema 需要时改动。
+先刻画现有显式改密、重置及建号行为，再修复并发与中断窗口。账户校验、禁止隐式 migrate、严格 INSERT 和统一密码事务是单一后端实现，脚本不直接写表。
+
+现有测试参考 `internal/store/login_keys_test.go`、`internal/server/login_key_test.go`、`auth_e2e_test.go`；新增 `internal/store/account_lifecycle_test.go` 与真实 PG 跨进程用例（路径相对于 Backend）。
+T7-1：两个独立进程同名开户，只有一个账户／激活 Key 成功，败者不改变胜者角色、密码和成员。
+T7-2：开户、Key 签发、改密、会话处理、审计提交各故障点，最终只见完整旧态／新态；输出失败但提交未知时按 operation 查询。
+T7-3：普通改密、临时重置、恢复设密后旧未用 Key 都不可兑换；长期集成 Key 按 R10 保留／撤销。
+T7-4：读命令命中旧 schema、缺库、错 marker 均拒绝且不 DDL／建库；两个独立进程以不同 owner 并发首次引导单胜，另覆盖引导与普通开户竞争；有历史业务而无用户时拒绝。
+T7-5：普通重启、两次更新、SIGTERM/SIGKILL 后测试账户原密码仍验证成功，账户权限及成员不变；不以摘要是否变化替代密码可用性。
+执行环境：独立 SQLite 副本、真实 PostgreSQL 独立库、独立端口；不在当前 weichen 账户上故障注入。所有 T7 用例当前 NOT_RUN。
+
+### U5／U8 近期接线与验证合同
+
+U5 覆盖 R7/R8/R9/R13/R15，依赖 U7 对外字段合同；范围 `scripts/svc.sh`、`docs/svc.md`、Frontend `src/api.ts`、`src/auth.ts`、`src/components/LoginPage.tsx`、`src/App.tsx`。复用现有登录／设密页，类型明确消费 sessionScope、passwordSet、reloginRequired；恢复 Key 不写持久浏览器存储或 URL。
+同一登录页保留默认账号密码入口，增加「激活／恢复 Key」入口并说明只用于设密；长期 API 密钥入口标清集成用途。错类型提示指向正确入口，切换清输入，更新初始密码旧说明，不新增独立恢复页面。
+刷新／兑换响应不确定时先查询会话，有效受限会话恢复设密；会话不存在且 Key 已消费／过期时提示联系账户管理员重发，返回「激活／恢复 Key」入口。无密码账户不得被引导用旧密码登录。
+测试参考 `tests/test_svc_user_binding.py`、Frontend `test/auth.test.ts`、`e2e/changepw-form.playwright.ts`；新增 Dev `tests/test_svc_user_help.py`、Frontend `e2e/login-key.playwright.ts`（计划文件）。
+T5-1：完整／短／专题／实例帮助覆盖六个账户命令，并均无 DB／目录／服务副作用。
+T5-2：旧产品和 RDM 不支持账户 CLI 时在执行前拒绝；stdout 单次交付，stderr／进程参数／history 无秘密；两类 Key 双向填错有正确引导且切换清输入。
+T5-3：激活／恢复完成兑换→设密→重新密码登录；刷新／响应丢失先核会话；Key 已消费而会话失效时经管理员重发的新 Key 可以续办；过期、重复兑换、CSRF 错误有准确提示。
+T5-4：受限会话无法访问业务／下载／SSE／admin／插件；设密成功后不得因直接 onDone 误放行。
+U8 覆盖 R2/R14/R15，依赖 U7 审计；在 `user info`／账户事件查询（拟新增）展示实例、设密时间、凭据类型及状态。错误配置、注销、Key 失效与密码错误分别诊断，普通登录错误不泄漏他人账户信息。CLI/HTTP 两入口产生可追溯同一 operation 记录；历史无审计事件保持未知。
+
+首批 dev 原账户闭环（NOT_RUN）：实现及隔离验证通过后，另行确认运行验收窗口／实例／版本，由 owner 在浏览器输入已知密码，检查原 user ID、角色、成员及原数据访问。若确实不能登录，明确恢复授权后才签发恢复 Key，保持账户和业务归属；不能为验收先重置能用的密码。随后在授权窗口验证普通重启及两次受控更新后原账户仍可登录。密码不交给 Agent、不进入证据；本轮不操作 live。
+
+### 必须覆盖的验收场景（摘要）
+
+干净机器二进制安装；源码固定提交与子模块；两种部署互切后数据不变；构建/摘要/配置失败旧服务可用；PG 身份不符拒绝且不回落 SQLite；无密码开户且不覆盖既有；同 Key 并发兑换仅一次成功；受限会话拒业务/SSE/admin；消费后建会话失败与设密中途失败无半完成态；恢复前后业务与权限对账；SQLite 与真实 PG；治理回归；源码测试不代替浏览器与真机。
+
+额外钉住：`release@v` 多版本不得装成更高版本；账户 CLI 不得回落默认 `./data`。
+
+## 8. 一次性 Key 流程
+
+```mermaid
+flowchart LR
+  A["创建账户或签发恢复 Key"] --> B["输入一次性 Key"]
+  B --> C["后端原子消费"]
+  C --> D["仅允许设置密码的短期会话"]
+  D --> E["设置并确认新密码"]
+  E --> F["作废恢复凭据及相关旧会话"]
+  F --> G["使用新密码正常登录"]
+```
+
+凭据规则：独立前缀；只存摘要；用途 `activate`|`recover`；状态未使用/已消费/已撤销/已过期；密码变更后旧恢复凭据不可再用。符合 [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 与 [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)；保留现有 CSRF 校验。
+
+## 9. 风险与未授权范围
+
+- 实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
+- 本轮交付终点：r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录；以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准，不推进 Dev gitlink、不推送／建 PR；启动／同步工具的任务元数据提交单独记录。
+- 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
+
+## 10. 规划进展与下一步
+
+- r1 已批准；U1/U4 基础实现存在于当前固定源码，完整浏览器／故障／运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
+- 首选下一任务（待授权）：恢复方案 U8 的 SQLite 服务隔离＋本案 U7 账户一致性；先消除共享测试数据和不可归因密码变化，再落实 U5。U2/U3 保持后续。
+- 前置：审核新增 R13–R15、U7/U8 及 U5 更新，明确实现和隔离测试范围／owner；实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区；正式组合、gitlink 推进与运行验收未执行。
+
+## 11. r3 实施记录：登录恢复流程（2026-10-13）
+
+授权：用户 2026-10-13「按此方案实施」（会话指示，覆盖登录恢复范围的实施与合入；
+代码 Review 与 PR 合入按 Dev `policy/delivery.md` 由智能体执行）。
+
+### 三项裁定（对 r2/U5 合同的分歧，用户按新方案裁定）
+
+| 分歧 | r2 表述 | r3 裁定 |
+|---|---|---|
+| 登录页长期 API 密钥入口 | 保留并标注集成用途 | 移除日常登录入口；程序化客户端直接带 Authorization 头 |
+| 管理员网页恢复方式 | 直接设置新密码 | 改为签发一次性登录 Key（旧 HTTP 端点兼容保留，仅前端 UI 下线） |
+| must-change 首登会话 | full 会话 + 动态拦截 | 登录即建 `set_password_only` 受限会话，`me.sessionScope` 统一驱动设密门 |
+
+### 已合入（2026-10-13）
+
+- Backend #187（`f103540d`）：迁移 v28（`users/sessions.auth_version` + `account_events` 审计）；
+  管理员 `POST/GET /api/admin/users/{owner}/login-keys`、`DELETE .../login-keys/{id}`；
+  改密事务内复验会话与认证版本；登录会话创建绑定认证版本（竞态窗口关闭）；
+  主动改密/管理员与 CLI 重置统一单事务；兑换入口按 IP 退避；TLS 下 Secure cookie。
+- Frontend #76（`0655bc3`）：登录页双入口（密码默认 + 一次性 Key，移除 `ask_`）；
+  设密门免当前密码、成功后回登录页（消费 `reloginRequired`）；刷新按 `sessionScope` 恢复门；
+  用户管理改签发/撤销 Key（明文仅一次）。
+- Dev #504（`268ef29`）：合同文档 + 组件 pin。
+
+覆盖判定：R7/R8/R9 及 U5 的浏览器接线主体已实现；U7 的登录恢复事务部分已实现，
+**原子开户/引导、CLI 凭据安全交付与 PG 锁串行仍未实施**，U7 不得据此记完成。
+
+### 验收证据
+
+- GATE：Dev #504 HEAD CI 三作业（test / test-pg / svc-realcombo）success；Backend #187 CI success。
+  test-pg 即真实 PostgreSQL 运行本任务 store 测试（含 100 并发兑换单胜、登录竞态）。
+- SELF（收据，绑定 Dev HEAD `268ef29`）：真实浏览器全流程验收 PASS——
+  `login-key.playwright.ts` + `changepw-form.playwright.ts` 于隔离 auth-on 实例
+  （`serve --data /tmp/lr-e2e-data --auth on`，二进制 backend=467718a+frontend=9fc7da2）：
+  管理员签发 → 只输 Key 兑换 → 免旧密码设密 → 新密码登录进工作台 → 同 Key 重复兑换被拒。
+  收据 sha256：`be7ae9a2…`（验收）、`b3a9e691…`（终态）。用例文件待 Dev 工作区解封后入库。
+
+### 遗留（另行任务与授权）
+
+SSE 存量长连接断流通知；`e2e/login-key.playwright.ts` 入库与 Dev pin；U7 余量；
+部署与 live 账户验收。详见合同文档「遗留项」。
@@ -0,0 +1,176 @@
+---
+title: 面向非专业用户的工作台整体界面重设计
+revision: r0.2
+status: approved-for-continuous-implementation
+date: 2026-10-12
+owner: weichen
+scope: requirements-and-design
+implementation: implemented
+delivery: tracked-in-dev-task-record
+project-record: persisted
+---
+
+# 工作台整体界面重设计 r0.2
+
+用户在评审 r0.1 后明确授权“开始实施直到完成”。本稿 r0.2 保留已选设计，并通过本次独立任务连续实施、验证、Review 与合入。已有快慢通道执行方案的其他增量不由界面授权自动扩大。
+
+## 1. 设计目标
+
+让不懂命令、脚本、模型和代理的用户，通过表达目标、提供材料、查看结果、完成必要确认来推进工作。
+
+默认界面回答三件事：现在在做什么，已经得到什么，下一步是否需要我处理。用户能够只用对话完成主要工作，也能在需要时展开工作摘要、阅读文件、核对依据。
+
+用户明确要求：不要过于复杂；以辅助工作为中心；渐进、多层级展示；减少命令和脚本细节；大气、现代、简约、美观、易用。
+
+本稿的场景假设：主要工作包括材料整理、分析比较、问题审查和文档生成，兼顾日常问答。业务领域的具体审批和发布入口按当前服务端能力提供。
+
+## 2. 推荐形态与备选
+
+推荐**渐进展开的三栏工作台**。左侧找项目与历史，中间通过对话推进工作，右侧按需处理工作或文件。普通问答默认收起右栏，复杂工作时提供概览；用户手动收起后不因普通更新反复打开。
+
+| 形态 | 适用和取舍 | 本稿选择 |
+|---|---|---|
+| 渐进三栏 | 对话入口清晰，复杂任务可展开，文件有稳定位置 | 推荐 |
+| 纯对话 | 学习成本低；长文件、并行工作和多次确认容易淹没在历史消息中 | 作为轻量状态 |
+| 总览仪表盘 | 跨任务监控方便；默认要求用户理解更多指标和导航 | 仅在确有项目总览需求时另审 |
+
+不单独建设快通道页、慢通道页或后台管理页。新增功能先判断能否放进现有对话、工作和文件入口。
+
+## 3. 界面布局
+
+**左栏：上下文。** 项目身份集中出现一次；新建对话、最近对话、搜索；文件和已启用的领域工作区放底部；账户与个人设置沉底。管理员操作只由管理员入口提供。
+
+**中栏：推进工作。** 当前对话标题；用户的目标和材料；助手的结论、简短说明、必要动作；输入区上方一条工作状态。附件入口始终易找。权限设置保留清晰入口，展开说明其实际含义；初次使用采用现有默认值，不暗中扩大授权。
+
+**右栏：工作 / 文件。** 工作按需要你处理、当前关注的工作、其他进行中或排队、新成果排列。完成历史收纳后仍可找回。文件负责列表、预览、编辑和下载；全屏阅读是同一个预览的放大。来源点击也进入同一预览对象，定位能力不足时说明定位范围。
+
+左栏约 200–240，工作右栏约 320–420，中央弹性。正式落地继续消费已有拖拽宽度和文件阅读档规则。空间不足时先隐藏辅助栏；手机显示一个主视图，工作和文件按需打开，并有明确返回对话入口。
+
+## 4. 渐进展示层级
+
+| 层级 | 显示内容 | 打开方式 |
+|---|---|---|
+| L0 概览 | 后台工作数量、必要确认、新成果 | 一条状态行或小徽标 |
+| L1 摘要 | 业务目标、真实状态、当前工作、最多 3 条重要发现、缺项、下一步 | 当前任务卡或对话锚点 |
+| L2 依据与范围 | 阶段结果、来源、覆盖范围、未决问题和结论更正 | 原位置展开 |
+| L3 执行记录 | 按工作阶段分组的动作、结果和有权限查看的诊断信息 | 明确点击执行记录 |
+
+默认 L0/L1，不展开所有任务。必要确认、重要限制和失败影响不能藏在 L2/L3。L3 不是模型内部思考的展示入口，也不改变日志和来源的访问权限。
+
+示例任务卡：
+
+> 整理三份项目材料 · 进行中  
+> 正在核对：会议结论与需求说明  
+> 当前发现：上线时间出现两种说法；3 项需求缺少验收条件  
+> 待核查：评审意见中的补充要求  
+> 查看依据与范围
+
+没有阶段成果时诚实显示“尚无阶段结论，正在读取材料”。以上业务发现是示例数据，当前 U1 骨架并不证明已经具备真实阶段发现发布能力。
+
+## 5. 快慢通道的连续体验
+
+用户界面主要使用“助手正在处理”“后台继续整理”等业务语言。快通道是当前对话回合，慢通道是后台工作，不是由用户选择的快慢速度档位。
+
+| 时刻 | 用户看到的内容 | 表述边界 |
+|---|---|---|
+| 发消息或材料 | 接收结果、可先回答的内容、接下来处理的范围 | 已选文件不等于上传成功；解析不等于分析完成 |
+| 任务登记或排队 | 同一工作对象显示已登记、排队中 | 登记成功才能说已登记；未开跑不能写进行中 |
+| 工作进行中 | 当前工作、真实阶段结果、缺项 | 没有可信进度就不显示百分比或预计完成时间 |
+| 用户继续输入 | 后台继续工作时可继续对话；前台忙时说明消息排队 | 发送不等于即时执行，不承诺已改变正在跑的任务 |
+| 有新成果 | 更新原卡；重要结果提供一条对话通知 | 不逐条回投工具动作，不把所有任务复制成另一条聊天流 |
+| 等待用户 | 操作、范围、影响和明确选择 | 等待、执行、生成、用户认可和正式发布分开 |
+| 完成或失败 | 结论、最多 3 个要点、范围或缺项、文件和下一步 | 保存失败不得声称已交付；部分完成不能冒充完整结果 |
+
+后台更新不切换用户正在读的文件，不抢焦点，不把历史阅读强行滚到底部。状态恢复期间保留最后已知内容并注明“正在重新连接，最新进展待确认”。
+
+## 6. 按工作选择展示形式
+
+统一骨架保持稳定，内容形态随任务改变。默认由工作目的决定，用户无需先学习或配置一种展示模式。
+
+| 工作 | 默认成果形式 | 进一步展开 |
+|---|---|---|
+| 简单问答 | 一段结论，必要说明 | 依据与例子 |
+| 材料整理 | 主要结论、问题和缺项 | 材料覆盖清单、来源 |
+| 方案比较 | 一条建议、关键差异表 | 判断依据、取舍和适用条件 |
+| 问题审查 | 按影响排列的问题清单 | 原文、影响、处理建议 |
+| 文档生成 | 草稿文件、完成范围、需要评审的事项 | 文件预览与后续修订 |
+| 多步骤流程 | 当前阶段、已完成阶段、必要动作 | 阶段结果与历史 |
+| 用户确认 | 简明操作说明、影响、选择 | 参数与诊断详情 |
+
+图表仅在数量、趋势或关系能帮助判断时使用；可理解的短表不升级成图表。生成式任务页面作为可选增强，关闭插件后仍能通过任务卡、文字和文件读到主要结果。领域审批不能成为所有基座任务的固定步骤。
+
+## 7. 等待确认与异常
+
+确认卡先写操作及影响，例如“依据三份材料新增 1 份项目草稿，保留原件，不对外发送”。涉及覆盖、发送、发布或权限变化时，关键对象和影响必须在默认层显示。避免只有“是否执行”而没有范围。
+
+对话和右栏操作同一确认对象。提交中阻止重复提交；已处理同步更新；超时显示“正在核实处理结果”，查清后再允许后续动作。示例稿只演示本地状态同步，不证明服务端幂等和恢复。
+
+异常表述使用“发生了什么 → 对结果的影响 → 用户可以做什么”。例：“评审意见未能读取；已整理另外两份材料，完整结论尚未生成；可补充清晰版本或先讨论已有结果”。错误代码、脚本与输出置于授权可读的详情。动作只按服务端当前能力显示；未核验的暂停、独立取消、续跑、自动重试不进入默认设计。
+
+## 8. 视觉规则
+
+沿用 DESIGN.md 和 @ui/tokens.css：灰白表面阶梯、单色反色主按钮、发丝边框、克制语义色；清晰的标题与正文层级；常用信息保持可读，不以缩小字号装下所有内容。
+
+大气来自稳定分栏、整齐对齐、合理阅读行长和区块间距；简约来自减少同时出现的内容。没有营销式大标题、装饰渐变、速度表盘、满屏彩色卡片或默认工具日志。
+
+字型走 --fs-ui-*，界面字号可调。状态同时有文字和形状。折叠消费 @ui Collapsible，动效只用 mk-* 并响应减少动效。交互稿复制固定 UI 令牌，实际使用当前 Collapsible 源码与 MotionKit，不新建颜色和动效体系。
+
+## 9. 当前依据与依赖
+
+本轮只读源码核对，来源 SELF；没有对生产或当前 dev 服务作功能验收。
+
+| 对象 | 固定提交 | 核对点 |
+|---|---|---|
+| Dev | 4d362537d0e8755a03b1757b5bad92779a064b33 | DESIGN.md、policy/delivery.md、既有规划 |
+| Frontend | 1edd872c554f666ba43353da7e6f0605ecec311b | Workbench.tsx、Conversation.tsx、Workspaces.tsx |
+| Backend | acabb85e2ae970f834defae916c7539d0a47993d | spawnBackgroundOpts、CancelRun、createBackgroundCard、finishBackgroundCard |
+| UI | 83e80f5648649c3cc070f4dbc6bf118996828ae8 | tokens.css、Collapsible.tsx、motion.css |
+| Documents | 3cc6438030803b8e2355d2867766e9654203f265 | 快慢通道展示 r1.1 及 U1 实施计划 |
+
+当前读到的源码已有三栏“工作 / 文件”、前台忙时输入排队、后台并行限制、排队工作、精炼卡片骨架以及失败 CardFailed 映射。这里只说明源码形状，不推断已部署与运行表现。
+
+与既有方案衔接：`modules/documents/docs/proposals/2026-10-12-fast-slow-channel-display.md` 是快慢通道摘要与异步投影的已有主记录；本稿补充整体交互与各种成果形式，不另起一套状态或快照契约。U2/U3/U4 的真实阶段发现、持久恢复、确认闭环和窄屏完善继续以原记录及后续批准为准。
+
+## 10. 实施需求
+
+以下为本次界面实施与验收范围；实现消费真实已有能力，不伪造尚未发布的阶段发现。
+
+| ID | 需求 | 优先级 | 可判定的验收方向 |
+|---|---|---|---|
+| UI01 | 对话能完成主要工作 | P0 | 关右栏仍能读摘要、核对依据、处理确认、打开成果 |
+| UI02 | 普通问答保持轻量 | P0 | 无后台工作时不生成空任务卡和空进度条 |
+| UI03 | 默认内容可支持下一步 | P0 | 用户能说明当前工作、结果范围、必要下一动作 |
+| UI04 | 快慢通道连续展现 | P0 | 前后台并行、排队和完成状态归属正确且不重复刷屏 |
+| UI05 | 四层渐进阅读 | P0 | 默认无命令日志，关键限制和确认不被折叠藏起 |
+| UI06 | 成果按目的呈现 | P1 | 整理、比较、审查和生成各能支持对应工作判断 |
+| UI07 | 状态与动作忠实 | P0 | 不伪造进度，不暴露未支持控制，不把失败显示成功 |
+| UI08 | 同一文件同一预览 | P0 | 对话、来源、文件列表均进入同一预览位置 |
+| UI09 | 确认结果一致 | P0 | 双入口、重复点击、超时未知和已处理均有一致表现 |
+| UI10 | 阅读稳定 | P0 | 普通后台更新不抢焦点、换文件或改阅读位置 |
+| UI11 | 窄屏和大字可用 | P0 | 320/390/736/1024/1440 及 18px 字号必要动作可达 |
+| UI12 | 遵守设计系统 | P0 | 令牌、Collapsible、MotionKit、对比度守护符合规范 |
+| UI13 | 能力与权限匹配 | P0 | 未启用领域入口不显示；摘要与来源不绕过访问控制 |
+
+最终产品验收场景：三个附件无文字发送；前后台并行及排队；确认双入口；完整/部分/失败结果；查看来源与文件；刷新和断线；新对话；窄屏、大字、键盘及减少动效。r0.1 设计评审时，真实模型、真实后端和真实浏览器任务验收均为 NOT_RUN；实施期结果见第 13 节，示例交互稿不能代替验收。
+
+## 11. 落地次序建议
+
+1. **整体界面与文案。** 在既有三栏和 U1 上整理默认内容、必要操作和阅读路径。优先确定 UI01–UI03/UI05/UI08/UI12；不在此增量改变后台执行契约。
+2. **动态工作摘要。** 接续既有快慢通道 U2/U3，在真实快照与检查点之上显示业务发现、范围和恢复状态；避免另外安排重复任务。
+3. **成果形式与适配。** 衔接 U4，完成比较、审查、可选任务页面、窄屏和具体领域入口。先用结构化文字/表格，再增强生成式展示。
+
+r0.1 布局与展示已获连续实施授权，当前按 r1 计划交付界面。完成本增量后的首选衔接仍是既有快慢通道 U2/U3 的真实阶段发现与恢复验收；需先核对其在途任务和批准范围，不能由本界面任务重复启动或改变路由。
+
+## 12. 授权与实施记录
+
+来源：2026-10-12 用户在本聊天评审 r0.1 后指示“开始实施直到完成”。模式 authorized-continuous；阶段 1–10 在本稿界面范围内连续推进，平台门禁和高后果双钥匙保留。启动检查从已登记干净 Dev 检出捕获，后由 make task-start 创建 feature/work-companion-ui，并导入原始 SELF 收据。保护主检出的 Frontend 更新与其他任务现场。
+
+实施计划见 [r1](2026-10-12-work-companion-ui-plan.md)；进展和原始证据仅维护于 Dev .task/feature-work-companion-ui.md。PR、CI、Review、合入与部署分别记载，不因本授权预先标为通过。
+
+## 13. 实施进展与能力边界
+
+2026-10-12：渐进任务卡、轻量对话/输入、响应三栏和单一异步状态投影已形成可审阅候选。SELF 验证包括 Frontend 210 与 UI 155 单元测试、类型/设计守护/knip、Dev make test 与 make build；现有 Playwright 11 个展示场景、6 个移动导航场景及隔离 HTTP/MockRunner 2 个真实接口链路场景通过。原始命令、精确对象和完整输出以 Dev 任务卡为准，测试成功不推断已经合入或部署。
+
+原始独立代码 Review 已完成，必要问题均已有整改候选；最终精确版本复审、组合 CI 与合入进展只维护在 Dev 任务主记录，方案正文不复制第二份交付状态。UI 仓原 CI 在下载 GitHub action 时失败，交付补充改用既有平台固定 SHA 检出和 Node22 镜像，保留原测试；安全和规范 Review 及实际平台结果均须记录。
+
+动态摘要只消费系统发布的真实内容：缺少阶段发现时显示诚实占位，不生成示例百分比、ETA 或虚构成果。真实模型阶段发现质量 NOT_RUN，后台自动路由和模型提示词未在本增量修改。旧运行服务未更新；最终组合、Review、GATE 和本任务安全收口以 Dev 主记录为准。
@@ -0,0 +1,154 @@
+# Work companion interface implementation plan r1
+
+> **For agentic workers:** Implement in independent units with ce-work native workers; the orchestrator owns integration, evidence, commits, Review and Gitea delivery. Use test-first coverage for behavior changes. User authorization: “开始实施直到完成”; continuous execution is limited to the approved interface design.
+
+**Goal:** Deliver the approved simple, modern, progressive workbench through real project, conversation, activity-card, confirmation and file APIs.
+
+**Architecture:** Keep the three existing pane responsibilities. Project existing ActivityCard bodies into readable summaries in the UI library; Frontend integrates them into conversation and work panes. Preserve server authority and harden event, query and action races in the one Frontend store. No new task executor, model routing, database schema or UI vocabulary is required.
+
+**Tech Stack:** React 19, TypeScript, existing @ui Collapsible/MotionKit/tokens, Vitest, Playwright, Go backend with existing API and SSE.
+
+**Spec:** [Approved interface design](2026-10-12-work-companion-ui-design.md), UI01–UI13; [existing fast/slow design](2026-10-12-fast-slow-channel-display.md), U1 skeleton and applicable presentation rules. Dynamic model-generated findings remain dependent on the existing U2/U3 work; this interface renders real available content and an honest placeholder otherwise.
+
+## Global constraints
+
+- Settled user decision: three pane workbench, conversation first, “工作 / 文件” in the same right pane, one preview object.
+- Settled user decision: concise default content and progressive depth; necessary confirmation and outcome limits stay visible.
+- Colors/radii/type consume @ui/tokens.css, type uses --fs-ui-*, motion only mk-*, folds use Collapsible.
+- No percentage, ETA, pause, independent cancel, resume or retry buttons unless supplied by a verified server action.
+- State is derived from real cards, runs, files and responses; no prototype example data enters production.
+- Model internal thinking and command parameters/output do not occupy the normal reading layer.
+- Main checkout and other task worktrees are protected. All owned changes live in feature/work-companion-ui.
+- Evidence uses the Dev make evidence tool. Local checks are SELF; current PR HEAD CI is GATE.
+- Component branches are based on their authoritative origin/main. Dev is based on R0 4d362537d0e8755a03b1757b5bad92779a064b33.
+- No deployment/restart of existing services, data migration, credentials or branch-protection changes.
+
+## Review focus
+
+1. Older SSE frames or delayed queries must not replace newer cards or inject data into a different conversation/project.
+2. Replay of a currently running conversation must still reconstruct its live output while duplicates are dropped.
+3. A confirmation submitted through either view must block duplicate submission and represent unknown results honestly.
+4. Closing auxiliary panes and opening files must leave necessary work and confirmation paths accessible at 320px and 18px UI type.
+5. New background results must not take over an existing file, focus or reading position; result summaries must retain failure and coverage limits.
+
+## U1 — Progressive activity cards and work groups
+
+**Own files:** UI src/ActivityCardView.tsx, src/InlineConfirmCard.tsx, src/InboxList.tsx, src/index.ts, src/ui.css, new src/activitySummary.ts, src/ProgressCardBody.tsx and focused UI tests. Do not change generated contracts or tokens.
+
+**Consumes:** Existing ActivityCard/UINode and DocBridge; U1 body keys 状态/正在做/当前发现/剩余/下一步. Unknown words remain supported by the generic renderer.
+
+**Produces:** Existing ActivityCardView remains source-compatible; export activitySummary/cardStatusLabel/groupActivityCards as pure projections. CardViewCallbacks and InlineConfirmCallbacks may add `actionState?: (card: ActivityCard) => 'submitting' | 'unknown' | undefined`; existing callbacks remain optional. Core vocabulary is unchanged.
+
+- [ ] Add tests for queued and running labels, modern failed and legacy done+danger, no-findings placeholder, internal material keys hidden by default, real document nodes still reachable, and confirmation buttons disabled for submitting/unknown.
+- [ ] Run the focused Vitest tests before production edits; record expected red assertions through evidence.
+- [ ] Build the projection with literal canonical body keys and card states; never interpret arbitrary output as a new execution fact.
+- [ ] Render L1 summary first, remaining body and source/range information in Collapsible, diagnostic metadata behind a nested explicit record entry. Known failure/remaining/next-step content must remain visible.
+- [ ] Keep unknown/legacy bodies intact in the generic detail renderer. Tables, structured lists and document references retain their current renderer.
+- [ ] Group unpinned work as needs-action, active, results, history, preserving order inside each group. Pinned items remain stable.
+- [ ] Simplify chrome; use text plus status shape and existing neutral surfaces.
+- [ ] Verify full UI suite, tsc and design/contrast guards; hand off files and red/green evidence without committing.
+
+Example behavioral expectation:
+
+```ts
+const queued = { ...card, status: 'active', body: [{ type: 'kv', kv: [['状态', '排队中'], ['材料键', 'mk_private']] }] }
+expect(cardStatusLabel(queued)).toBe('排队中')
+expect(groupActivityCards([completed, pending, queued]).map(g => g.key)).toEqual(['needs-action', 'active', 'results'])
+```
+
+## U2 — Conversation, input and inline work reading
+
+**Own files:** Frontend src/components/Conversation.tsx, src/components/ProcessTimeline.tsx, src/messageparts.ts if required by process policy, new src/components/ConversationWork.tsx, new src/companion-conversation.css, focused conversation/messagepart tests. Do not edit styles.css, App, Workbench or store.
+
+**Consumes:** Existing store fields and actions; existing UI ActivityCardView/Collapsible/DocBridge, including the additive actionState callback. The orchestrator supplies state.cardActionStates.
+
+**Produces:** ConversationWork renders current cards from the same store in an inline Collapsible; default ordinary Q&A has no empty progress. Component CSS imports live in the owned component file.
+
+- [ ] Add failing behavior tests for normal Q&A without progress, task summary reachable while right pane is closed, progress record folded by default, failure/limits visible, and process final answer outside its fold.
+- [ ] Replace command-oriented empty states with goal/material prompts and three optional natural-language examples that fill input rather than trigger hidden work.
+- [ ] Simplify header; keep execution profile, cross-reading and session settings inside a clearly labeled settings fold, preserving existing behavior and consent.
+- [ ] Keep add-materials and send visible; move permission selector into operation settings without changing its effective value. Explain queue state and upload failures in user language.
+- [ ] Show a light continuity line from real runs/cards with confirmed counts; inline work uses the same cards/actions as the work pane.
+- [ ] Fold tool parameters and output even during running by default; keep a compact real phase label and preserve manual expansion. Do not display model internal thinking as ordinary content.
+- [ ] Protect scroll reading and reset compose/expanded context correctly on conversation switches; do not remove artifact or rewind capabilities.
+- [ ] Verify focused tests and the integrated Frontend suite; hand off files and evidence without committing.
+
+Example behavioral expectation:
+
+```ts
+expect(showProcessInline(live, true)).toBe(false)
+expect(showProcessInline(live, false)).toBe(true)
+// Render real ConversationWork with zero cards: no progress object is produced.
+// Render with a real active progress card: summary is present independent of rightCollapsed.
+```
+
+## U3 — Responsive shell and context navigation
+
+**Own files:** Frontend src/App.tsx, src/components/TopBar.tsx, src/components/TaskSidebar.tsx, new src/companion-shell.css, new src/workbenchLayout.ts and focused shell/layout tests. Do not edit store, Conversation, Workbench, shared styles.css or UI.
+
+**Consumes:** Existing leftCollapsed/rightCollapsed/rightTab/previewExpanded and store pane/file operations. May add only local ephemeral responsive state, not another asynchronous task owner.
+
+**Produces:** Desktop three pane layout; narrow screen one active pane with clear contextual return actions, using the same Workbench/PreviewPane objects. Export a pure layout selector if a decision is needed for tests.
+
+- [ ] Write failing behavioral tests for single-pane navigation, restoring conversation, expanded file reading, and no hidden-only essential operation.
+- [ ] Match the approved calm prototype through spacing and type hierarchy, preserving canonical palette and default existing theme preferences.
+- [ ] Keep project identity on the left, conversation identity central, work/files on the right. Rename primary creation to 新建对话 where it actually creates a conversation.
+- [ ] Reduce duplicate permanent chrome; retain project creation/search/account/admin/available workspace paths.
+- [ ] Adapt to 320/390/736/1024/1440; hide/return controls remain keyboard- and touch-accessible. Do not let stored pane widths force horizontal overflow.
+- [ ] Keep file expansion as one preview enlargement, not another overlay or fourth pane.
+- [ ] Verify layout tests and report desktop/mobile screenshots after integration; hand off owned files without committing.
+
+## U4 — One state owner, safe updates and confirmation feedback
+
+**Own files:** Frontend src/store.ts, new src/eventProjection.ts if a pure helper is useful, src/components/Workbench.tsx, src/components/PreviewPane.tsx only when integration requires it, focused store tests. Orchestrator implements this unit.
+
+**Consumes:** Existing SSE event identity/seq/runId, conversation detail resumeSeq/lastSeq, cards API, project events, cardAction and resolveHITL APIs.
+
+**Produces:** Store `cardActionStates: Record<string, 'submitting' | 'unknown'>`; both work and inline confirmation callbacks read this same map. Current session/project cursors and query generation checks remain in one store.
+
+- [ ] Add red tests for duplicated and stale cards; delayed conversation/project list queries after switching contexts; foreground replay versus background agent notes; duplicate action submission; unknown response followed by a server query; new Surface while reading a file.
+- [ ] Guard event application by current context and per-stream applied sequence. Live replay uses its own replay cursor and never re-applies older card/plan/status projection effects.
+- [ ] Guard asynchronous queries by their requested context and generation/sequence so slow snapshots do not wipe newer events or another context's state.
+- [ ] Suppress background progress in foreground token output; update actual runs/cards instead of creating an unrelated LiveState.
+- [ ] Lock confirmation/action submission by card or HITL identity before awaiting. Clear on observed server outcome. Unknown results remain disabled until read-only reconciliation determines the current state; do not blindly resend an effect.
+- [ ] Show submitting and unknown feedback at both entrances. Preserve all server-supplied actions and their original scope.
+- [ ] Leave current file/Surface selection and explicit pane preference intact on background updates; show a small new-result cue rather than auto-opening.
+- [ ] Default new users to a light, compact conversation layout with right pane closed; keep saved theme/layout choices and explicit file opening.
+- [ ] Verify focused store tests, integrated Frontend tests, and browser cross-view flows.
+
+Example behavioral expectations:
+
+```ts
+store.applyEvent({ ...newerStatus, seq: 12 })
+store.applyEvent({ ...olderStatus, seq: 11 })
+expect(store.getState().cards[0].status).toBe('done')
+// Hold the first action response; call through the second view and assert one API request.
+// Resolve or query the real returned card and assert both views leave submitting together.
+```
+
+## U5 — Integration, browser acceptance and delivery
+
+**Own files:** Dev DESIGN.md, PROJECT.md, task card and exact gitlinks; Documents design/plan/index and delivery record; Frontend e2e/work-companion.playwright.ts and isolated browser fixtures if required; external screenshots and receipts.
+
+- [x] Record authorization and implementation units; retain original startup evidence unchanged.
+- [x] Integrate all workers, inspect owned paths and contracts, run authoritative focused tests, and commit logical component changes with Why/Evidence/Impact/Refs bodies.
+- [x] Update DESIGN §9.6 and information architecture to the approved progressive behavior; no palette changes are planned, so do not change canonical token values merely to create a paired diff.
+- [ ] Run make task-sync through evidence at acceptance, review and merge checkpoints; resolve any parent/component conflicts without altering unrelated owner work.
+- [x] Pin exact committed component revisions and run Dev make test plus make build through evidence.
+- [x] Browser checks: normal conversation; three selected attachments; background task plus foreground input/queue; pending confirmation through either entrance; done/failed/partial results; real file preview; reading preserved during update; duplicate/stale updates; refresh/switch; all five widths and 18px type.
+- [x] UI fixture-driven browser cases validate presentation only. Use an isolated real backend/browser smoke for API wiring, file/confirmation/card persistence where feasible. No mock model findings are reported as live-model acceptance.
+- [ ] Run required simplification and independent code review; fix findings, re-run affected checks, and record reviewer/object identity.
+- [ ] Push component branches, create and attach Gitea PRs, verify their current HEAD required CI and merge in dependency order. Update Dev pins to merged revisions, verify combination CI at current Dev HEAD, Review and merge Dev PR.
+- [ ] Fold/close only this task card under continuous authorization. Preserve or safely reclaim only owned workspace artifacts. Do not modify active main checkout state for other tasks.
+
+## Definition of done
+
+UI01–UI13 are mapped to observed source/tests/browser outcomes or an explicit inherited capability limit; no prototype fixture enters product state. All changed components compile and relevant tests pass. Current-head mandatory CI is verified before merge. Review findings are closed. The actual merged Dev combination and saved evidence are recorded. Existing running services remain unchanged; deployment is a separately identified operation.
+
+Continuous authorization covers implementation, verification, reversible isolation, documentation, commit/push/PR, agent Review/merge and task-specific safe closure. Stops apply to genuine scope changes, unowned content collisions, missing current-head platform gates and high-consequence dual-key operations. These conditions do not require re-approval of routine already-authorized work.
+
+## Delivery status
+
+2026-10-12: U1–U4 implementation candidates are integrated; U5 local combination and browser checks passed as SELF evidence. Original independent review is complete; the required fixes are implemented and locally verified. Final fixed-version review, current-head platform CI/merge and safe closure are tracked only in the Dev task main record; this plan does not maintain a second delivery-status copy. Code review may produce small corrective iterations; each has its own fixed object and relevant replay. The UI CI bootstrap repair is required to run the retained checks, not a waiver of them. Actual merged versions and final verification remain recorded in the Dev task card; no existing service is deployed by this task.
+
+2026-10-12 corrective candidate: UI0da2e3a / Frontend43d1933. SELF: UI155 and Frontend210 tests with type/knip checks, 11 presentation plus6 mobile-navigation browser cases,2 isolated realHTTP/MockRunner cases. The live attachment case now proves exact upload→send→persist associations across reload. The review repairs cover source links, per-option context, real browser scroll/focus, terminal reconciliation, action feedback ownership, explicit preview intent, latest outcomes and visible public explanations. These are interface and state-projection corrections; no live-model routing, prompt or existing-service deployment change. Final delivery facts are recorded in the linked Dev PR/task archive.
@@ -0,0 +1,52 @@
+# IAM I1 阶段 7 正式测试与验收候选
+
+日期：2026-10-13（北京时间）；负责人：weichen；测试执行：Codex；状态：用户已通过阶段 7。正式代码 Review、PR、CI、合入和部署分别记录，不由本页代签。
+
+用户在本会话回复“确认”，对应 Dev `4af5956`、Documents `064d4b5`、RDM `70e27b08` 的阶段 7 报告及下述明确缺项。按 Dev `policy/delivery.md` 进入智能体负责的阶段 8–9；同步后的新组合须重新验证与独立 Review。工作区清理、部署和 U3–U9 仍需各自授权。
+
+## 批准与范围
+
+用户回复“批准”，对应 [阶段 6 实施交付](2026-10-13-iam-i1-review.md) 的 Documents c023551、RDM b93908e、Dev 72ed8b4。批准原版本保留，恢复同步后的测试版本另列。本次按已获批 [统一方案 r1](2026-10-13-identity-role-permission-plan.md) 的 I1＝U1–U2 及 [权限合同](2026-10-13-iam-i1-permission-contract.md) 验证当前公开命令/API边界；不关闭 R1–R20 全部目标，不实施 U3–U9，不操作现有服务、生产数据库或真实账号。
+
+恢复处理包括：Dev Documents 同步冲突保留上游项目成员规划及三份 I1 批准文档原文；RDM 采用上游 `rdm.project.member.set-role` 合法命令 ID，保留 I1 身份包装。没有恢复旧权限旁路，没有变更 RDM pins；所有失败、恢复、同步收据保留。
+
+## 固定对象与完整收据
+
+| 对象 | 固定版本及结果 | 原始记录 |
+|---|---|---|
+| Dev 集成组合 | `10789653f989da6dc8a5ecc72d996dc2764208db`，同步目标 `ee9b437b22b49f96e1bc65f79417b22e8e82a37c`；`make test` 退出 0 | Dev 任务卡 SELF 收据 `ea7b77587b568d968594b0cb90c5362cab27d8eab1492da8cdea14d74e43d11d` |
+| RDM 完整组合及 HTTP | `70e27b08c65d8e966a11b1d30723414ec3e36f8e`，同步目标 `6c689caa1fa271c2a16174427df51a9b8919c4e0`；`make test`＋真实 HTTP＋产物/测试摘要检查退出 0 | RDM 任务卡 SELF 收据 `6e684a9047e43b0bdafbc71604ab5debe06bf437d1e3c95c4169d310f11d70c0` |
+| 独立最小重放 | `/root/i1_phase7_review` 未参与源码修改；先在 `58a23f8c` 重跑 39 个顶层 TestIAMI1，再审查作者材料并重跑最终 HTTP 10 组；退出 0 | 已导入 RDM 卡的完整 SELF 工具收据 `6bbb0f747e41c28d3c2327c587e162072a69495573def6f97a6d1657eb0b0d76`、`c7edde369566552acf4060500985a4a80ea004af80455446de9a215f64f89587`；工具标签不自行升级 |
+| RDM 二进制 | SHA256 `93aabc13041cf5a5c5636ebd0c88979a4d0f6fd0f79ba1272defc75176a75d81`；从实际组合产物运行，没有使用 Vite 或仅源码模拟 | `bin/PRODUCT_MANIFEST.json` 与上述工具收据 |
+| HTTP helper | SHA256 `a7d1d3260f4a62f0cb14b91339506419e9be306f2d0e3f7c74a6e77e76a458d4` | RDM `.task/artifacts/iam-i1-http-acceptance.py`；代码与测试材料已提交 |
+
+RDM 固定 Backend `0f192a481388184df39f81c28b0587a7e16ec3ca`、Frontend `4965de269a441a7df02b46d8533067f044e79b8b`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`；前端 dist 摘要为 `13acbec506086fe8`。Dev 新组合与 RDM 产品各自固定、各自检查；不能用 Dev 新接口存在证明旧 RDM pins 已消费其能力。后续只记录文本的提交不改变这些行为对象；最终记录提交及工作树检查另见任务卡。
+
+完整命令输出由 evidence 工具保存于两个任务卡，本文只提供判据和结果摘要，不转写输出、不提升来源等级。测试本地来源为 SELF；用户批准、受信 CI、平台账号独立批准及部署各自独立。
+
+## 需求到证据
+
+| I1 要求 | 正常／异常／边界判据 | 当前结果与测试 |
+|---|---|---|
+| R6/R12 系统与项目作用域 | 合法管理员创建/配置/任命角色成功；获 A 的 project.settings 者可改 A 名称，但全局 role/cap/admin transfer 被权限拒绝；body 伪造 actor/owner 不改变认证身份 | PASS；注册命令 TestIAMI1＋真实 Bearer HTTP，先检查命令已注册，再要求权限原因，不把未知命令或 schema 拒绝计通过 |
+| R7/R8 管理资格不授 B 业务访问 | /api/me 明确实际平台管理员身份；A 创建者且管理员对 B 的成员、权限、归档和审计操作拒绝，当前项目清单不显示 B；合法角色获授者可建 B | PASS；真实新实例 /api/commands/{id}＋项目/审计相关 Go 正反例 |
+| R9 创建者也受硬 cap | 已确认 Alice 在 A 的 doc.write 允许并有 allow 覆盖；保留 default=true，只关闭 cap；实际高危命令确认后因上限拒绝 | PASS；HTTP 隔离 cap 变量；Go 创建者 cap、平台 cap、未知角色动作与读策略故障等边界 |
+| R11 停用/换岗/旧覆盖 | 旧 doc.write allow 后换到未定义该动作角色，执行及解释拒绝；停用前 doc.read 允许，停用后消失，执行/矩阵均显示已停用原因 | PASS；HTTP 精确原因与前后矩阵＋TestIAMI1；没有借其他已存在拒绝原因替代停用测试 |
+| R18 私人原件/草稿与读取范围 | 真实 held 原件仅上传者可确认；管理员与未知 batch 获相同不透明拒绝且无实际 B 项目或文件信息；私人候选、差异、快照、审核状态、聚合读面/模型输入按当前 owner/阶段/grant 判定 | PASS；真实 HTTP 上传确认＋SQLite/已注册命令实际正文和持久状态负例；本次不声称完整 U5/U6 资源职责模型已实现 |
+| R12/R18 幂等回执和 outbox | 操作/项目/主体/资源不匹配 opID 不返回他人回执；合法重放保留；outbox 归属与业务在同 Tx 写入，仅送到实际 owner Host，未知旧归属保持 pending | PASS；TestIAMI1 实际回执和 SQLite 状态＋既有原子/失败重试回归 |
+| 注册和组合回归 | 当前 set-role 等命令 ID 正确注册并保留身份校验；根页为实际 React embed、未认证命令 401；RDM 29 项 Web、全部 Go；Dev 治理、公开边界/pins、库、Core、Backend、Frontend/UI、命令检查 | PASS；两套 make test 及当前产物真实 HTTP；不把 HTML 获取等同于浏览器交互验收 |
+
+## HTTP 测试过程及独立复核
+
+实际 HTTP 使用全新临时 SQLite、三名合成主体和随机 API Key；平台首位管理员在其他开户之前由可信 CLI 建立，/api/me 核验其真实身份。服务仅绑定随机回环端口，强制关闭执行工具，环境不继承 DSN、服务实例绑定或模型密钥，HTTP 禁用代理。真实私有会话和确认卡到最终回执的路径执行高危命令；native 项目仅为确认上下文，不作为 RDM project.create 政策的通过证据。测试结束只终止自己的 PID；成功临时场景回收，失败场景保留用于诊断，不修改既有实例。
+
+初次 HTTP 在未经过高危确认流程时拒绝，该结果没有被计为权限通过；补齐确认路径后重验。首位管理员创建顺序错误同样保留失败证据，不关闭原防接管机制。独立审阅又指出停用/默认与 cap 的两处测试假阳性风险；已分别加停用前后读权及原因检查、保留 default/allow 只关 cap。最终独立 HTTP 重跑 10 组通过，审阅范围内无剩余 Critical/Important。
+
+## 缺项、兼容边界与验收决定
+
+- 全产品浏览器交互和真实模型任务级前后对照：NOT_RUN。本轮 I1 没有业务 UI 实现，已规划出口为直接命令/API与当前回归；完整浏览器及 Agent 闭合属后续单元。工具描述真实模型对照仍是明确缺项：本轮未建立固定模型/配置/任务集/费用范围，mock 与 HTTP 不能替代模型行为。补救为另行明确测试条件后执行任务级对照，在后续 Agent/全产品验收前闭合；不能计 PASS。
+- PostgreSQL、多实例、在途后台最终提交 epoch、账号有效态/恢复、多职位/项目选用及完整三权：本轮完整验收未执行；按 U3–U9 依赖和各自授权推进，不迁移生产 DB。
+- 已批准的 I1 默认拒绝保留：无范围证明的 whole-prefix 知识撤销和公共全量自举拒绝；没有可信 Host 项目证明/资源分类的共享读取拒绝；audit.read 不随管理员或创建者自动授予；旧未知归属 outbox 不推测 owner。恢复这些能力须新公开提供者/消费者合同，不由此次测试擅自补接口或改 pins。
+- PR/受信 CI/GATE、正式阶段 8 Review、合入、部署及工作区回收：NOT_RUN。独立提前审阅和本地重跑不代替平台条件。
+
+原提交给用户的阶段 7 决定范围：固定 I1 U1–U2 的命令/API边界与回归结果，以及上述明确缺项/既定兼容限制。提交时结论为“本地测试已通过，待人工验收”；用户随后回复“确认”，已在页首记录为阶段 7 通过。原长期方向及下一任务仍为获批方案 I2/U3，需另行授权，当前不启动。
@@ -0,0 +1,181 @@
+# IAM I1 权限边界与公开扩展合同 r1
+
+负责人：weichen；编制：Codex；更新时间：2026-10-13。
+依据：[用户、职位角色与分层权限统一方案 r1](2026-10-13-identity-role-permission-plan.md)
+（Documents `a088809`，原文 SHA256 `39b8e9a6e078dc509bd80118c1807ce6ed23e4466e5902b51f4bfa255d55c0a1`）。
+用户已批准该方案并授权 I1＝U1–U2，原实施终点为本地人工评审；阶段 6、7 已分别获用户“批准”“确认”。当前按 Dev policy/delivery.md 进入智能体 Review、PR、CI 与合入，状态及固定对象见[验收记录](2026-10-13-iam-i1-acceptance.md)。迁移、部署、工作区清理及后续增量未授权。
+本合同为 U1 产物，冻结已批准语义与提供者／消费者责任；新增公开接口仍须对应模块实现、固定版本及合同验证，不能据此宣称能力已提供。
+源码、业务测试及运行验收结果以 I1 任务卡的工具收据为准；本文不复制测试结果。
+
+## 1. 当前增量与最终目标
+
+最新用户裁定取代旧“管理员拥有全部业务权限”“创建者不受职位 cap”“每人仅一个生效职位”的现行解释。
+历史会议、原方案、旧批准记录和 `.tmp` 原件保留；旧结论只用于解释历史行为。
+系统管理员管理系统与授权主数据；读取他人业务内容必须有具体项目和资源授权。
+职位支持一职多人、一人多职，项目明确选用有效职位绑定；新任命不自动增加既有项目权限。
+通用职位、绑定、默认／上限与系统授权迁至 Backend 是已批准设计；RDM 保留项目成员、项目选用绑定、项目覆盖、资源及文档职责／状态。
+
+| 层 | I1 范围 | 后续范围 |
+|---|---|---|
+| 文档 U1 | 需求裁定、动作目录、角色 cap、隐私、公开扩展申请与验收合同 | 按固定公开版本补提供者／消费者验证 |
+| 执行端 U2 | 在现有 RDM 单绑定和旧管理台账上收口可达越权路径；实际结果另见任务卡 | 账号有效态、受控目录及恢复能力 U3；通用职位与多绑定 U4；项目明确选用 U5 |
+| UI／Agent／迁移 | 不以文档保存证明能力已就位 | 矩阵、统一工具、完整撤权与数据迁移分别按 U7–U9 授权实施 |
+
+I1 的 legacy 单绑定适配不是最终多职模型：旧账号至多一个专业角色，项目尚无显式 bindingId 集合。
+已有绑定必须先检查角色有效态、动作定义与 cap，再计算默认／项目覆盖；停用或失效不能回落为无绑定成员默认。
+未绑定旧会员的关系默认只能作为已登记的 legacy 兼容来源，仍受平台 cap、项目关系和资源限制；不能伪装成新的职位绑定或最终模型的资格证明。
+U4/U5 迁移后无有效选用绑定的业务动作默认拒绝；迁移差异须单独评审，不在 I1 静默改造数据。
+旧 RDM 管理台账在 I1 仅为明确系统管理动作的兼容来源，不能生成项目成员关系、业务 grant 或资源 bypass；`Host.IsAdmin()` 同样不能代替业务授权。
+I1 还将当前分发 Host 的平台管理员身份显式适配为上述四项受保护系统动作；必须同时满足认证 actor 与 Host.Owner 一致，不接受 body 的管理员声明，也不把该适配扩展到其他未知动作或业务动作。细粒度系统 grant 的通用权威仍属 U4。
+
+## 2. 动作目录与配置主体
+
+scope 由受信 `ActionMeta`／权限注册表确定，不接受请求自报 scope，不按字符串前缀推断。
+系统动作只消费系统来源；项目动作限定实际项目；资源读取还须匹配实际资源、分类与读取动作。
+下表为 I1 稳定动作合同。“后续”项仅冻结目录，当前尚未提供相关接口。
+
+| actionId | scope | 配置／执行主体 | 附加边界 |
+|---|---|---|---|
+| `system.roles.manage` | system | 受保护系统管理者 | 角色创建／编辑／停用／读取；不能经项目覆盖获取 |
+| `system.roles.assign` | system | 受保护任命者 | 任命在可委派上限内；不能间接授予受保护系统权限 |
+| `system.policy.manage` | system | 受保护策略管理者 | 平台 cap 与权限政策；保护最后有效管理者 |
+| `system.admin.transfer` | system | 当前有移交资格的系统管理者 | 明确移交目标；旧 `rdm.perm.transfer` 映射此门禁 |
+| `project.create` | system | 有明确系统／职位建项 grant 的有效用户 | 创建者管理 cap 资格见 §3；不接受项目 allow |
+| `project.archive` | project | 目标项目的合法管理者 | 保留稳定 ID；纠正旧目录误标的 system scope |
+| `project.settings` | project | 目标项目创建者／委任管理者或合法获授者 | 仅本项目设置与覆盖；不能进入全局角色、cap 或管理员移交 |
+| `member.manage` | project | 本项目合法管理者 | 成员及选用角色管理；不得替他人做本人受限重选 |
+| `duty.assign` | project | 本项目合法分配者 | 候选有效成员＋对应资格 cap＋三权异人；分配不代签 |
+| `stage.advance` | project | 有阶段推进 grant 的成员 | 阶段准入准出、当前状态 |
+| `doc.read` | project | 有读取 grant 的成员 | 文档阶段范围＋受控正文职责／明确资源授权 |
+| `doc.write` | project | 有编制资格的指定编制人 | 具体文档、当前状态、冻结版本；不因管理权取得 |
+| `doc.publish` | project | 有发布资格及对应职责的成员 | 固定整文版本及已批准状态，不替代批准签字 |
+| `review.participate` | project | 有评审资格的指定审核／批准人 | 按具体职责决定可执行动作；只能批注及通过／驳回 |
+| `trace.edit` | project | 有追溯编辑 grant 的成员 | 文档层／项目层裁定范围与状态分别检查 |
+| `knowledge.publish` | project | 有发布 grant 的成员 | 明确提交／发布；不能借发布读取私人原件 |
+| `audit.read` | project | 有明确业务审计 grant 的当前成员 | 独立于正文读取；当前角色动作 cap、平台 cap 与范围均满足 |
+| `system.settings.read`／`system.settings.write`及设置子项 | system，后续目录 | 对应系统管理者 | 模型、插件、Agent、检索等设置分项授权 |
+| `system.users.view`／`create`／`edit`／`disable`、`credential.recover` | system，后续目录 | 对应账号管理者／恢复提案者 | 编辑资料不能改管理员资格；恢复见 §6 |
+| `permission.manage`、`knowledge.read`、`trace.read`、`document.read`／`export`、业务审计导出 | 后续目录，project | 按注册元数据和当前业务关系 | 当前 `doc.*` 等 ID 不静默重命名；新增需公开版本映射 |
+
+`audit.read` 是 I1 新独立项目动作：必须由合法项目管理者在上限内明确授予，或来自明确配置的角色默认 grant；管理身份本身不提供审计 grant。
+非成员 admin、仅持 `Host.IsAdmin()` 的主体、无审计 grant 的创建者、cap 已收紧的旧获授者均拒绝。
+系统安全日志只披露必要安全动作、结果及不透明对象标识，不能包含业务正文、文件名、项目名、内容摘要或完整业务差异；业务审计仍走 `audit.read`。
+
+| 旧入口／元数据 | I1 兼容规则 |
+|---|---|
+| `rdm.role.create`／`action`／`disable`／`list` | 命令 ID 保留，系统门禁改为 `system.roles.manage` |
+| `rdm.role.assign` | 命令 ID 保留，系统门禁改为 `system.roles.assign` |
+| `rdm.perm.cap` | 命令 ID 保留，系统门禁改为 `system.policy.manage` |
+| `rdm.perm.transfer` | 命令 ID 保留，系统门禁改为 `system.admin.transfer` |
+| 旧 `project.archive` scope=system | 目录版本标记改为 project；具体项目重验；旧系统覆盖写法不继续接受 |
+| `project.settings` 作为全局门禁 | 不兼容保留；项目 grant 不被翻译成系统 grant |
+| 未登记 ID、旧示例 `admin.transfer`／`business-audit.read` | 不是隐式别名；拒绝执行／写入，采用上表稳定 ID 或显式版本映射 |
+
+## 3. cap、创建者资格与撤权
+
+最终系统动作路径为：有效账号 ∩ 受信系统动作 ∩ 平台允许范围 ∩ 受保护规则 ∩ 明确系统 grant 或完整系统职位默认路径；项目覆盖不能参与。
+最终项目动作对每个有效且本项目选用的 binding 建立完整路径：
+
+`有效成员／管理关系 ∩ 已定义动作 ∩ 平台 cap ∩ 本职位 cap（含范围） ∩ 项目覆盖／当前默认 ∩ 资源关系 ∩ 阶段／状态 ∩ 文档职责`。
+
+至少一条完整路径允许才放行，不拼接不同职位的 grant 与资源范围；平台禁止、项目明确 deny 和资源禁止对所有路径生效。
+`allow` 只能替换默认 grant，不能创造未配置动作或越 cap；`deny` 阻断该成员该项目该动作的全部路径；`inherit` 使用当前默认。
+停用、解绑、换岗、cap 收紧、账号停用和成员移除后重验当前资格；遗留 allow 不能复活旧权。
+创建者关系只提供本项目管理默认，其有效角色 cap 与平台 cap 仍先验；A 创建者不能管理 B，不能读取私人资源或代签。
+
+建项前校验创建者角色组合具备 `project.settings`、`member.manage`、`duty.assign` cap 资格；这些角色 default 可关闭，由创建者关系提供项目内管理默认。
+最终创建项目、创建者成员关系及所选 binding 在同一领域事务落地；宿主绑定以可恢复状态和幂等对账处理。
+已有项目遇 cap 收紧保留 `createdBy` 与历史归属，阻断受影响动作并说明等待重新任命；不能扩大 cap 恢复管理。
+
+受限“重新选择本人项目职位”是后续独立动作，不复用 `project.settings`：仅当前有效负责人本人，从账号当前有效任命中明确选取具备管理 cap 的 binding，按项目当前版本确认。
+仅此动作可使用尚未被本项目选用的任命；它不改变负责人、不恢复遗留 allow、不清除 deny、不授予资源读取或三权。
+系统任命者不能代选；无合格任命时保持等待。项目内移除最后负责人须保护实际可操作管理资格；系统必要撤权不因这一保护而被阻止。
+
+## 4. 资源、正文与审计读取合同
+
+认证 actor、资源真实 owner／projectId／resourceId／分类来自执行端受信上下文；客户端标识只能定位对象，不能授予访问。
+本人的私聊、私人原件和个人草稿属于私人资源；在当前账号有效且资源确属本人时按自有资源规则读取，不因放在项目下变为受控正文。
+受控文档正文即使物理由本人生成，也须具体文档职责或明确资源授权、当前项目资格及当前 cap；真实 owner 相等不绕过受控规则。
+审核／批准职责仅开放送审正文与明确关联材料，不开放未分享原件、私聊或私人草稿；分享只授予指定资源的只读能力，不授予编写或签字。
+项目知识只由明确提交／发布产生；成员身份不意味着私人资源或所有受控正文全量可读。
+历史签字、职责与事件保留；历史内容读取依旧使用当前授权，时间点重建不恢复当时权限。
+读取、下载、列表、搜索、stream、模型上下文均遵循同一分类和当前判定；裁剪列表后再返回数量／分页，拒绝不得泄露存在性。
+I1 现有项目聚合审计 DTO 含正文预览，故除 `audit.read` 外还必须具备当前完整项目 `doc.read`；阶段范围受限者不能通过全项目聚合审计取得范围外正文，按资源裁剪的细粒度审计由 U5 完善。具体文档导出检查该文档的 `doc.read` 和阶段范围，不把审计 grant 当成导出 grant。
+I1 私人 pending/rejected 草稿仅提案人可读与决定；知道 proposalId、拥有项目管理权或文档职责都不能采纳／拒绝他人私稿。已采纳正文仍按当前文档读取授权逐项过滤。原件批次确认只限上传者本人，管理台账可披露经当前管理授权限定的业务元数据，不能因此读取或确认私人原件。
+
+## 5. 公开扩展：现有能力与四要素申请
+
+以下现有公开面是 I1 原合同的 Backend `0f192a481388184df39f81c28b0587a7e16ec3ca` 快照，参考 `pkg/extension/extension.go`、`host.go` 与 `surface.txt`，不导入 Backend internal。
+该快照的 `SurfaceVersion=2.11.0-experimental` 源码声明不是部署或消费者可用性证明，也不代表后续主干能力；同步后的组合必须重新核对提供者及消费者实际固定版本。
+
+| 现有能力 | 提供者／消费者 | 足够性与边界 |
+|---|---|---|
+| EXT-18 `AdminProvider.IsAdmin()`／`Request.HostProjectID` | Backend 分发 Host → RDM | 平台管理身份与宿主项目定位；不能证明系统分项授权、账号有效态、RDM 项目关系或业务访问 |
+| EXT-19 `AccountLister.ListAccounts(cursor, limit)`，`AccountEntry{Owner,Valid}` | Backend → 授权目录消费者 | 最小身份目录，非资料页；不提供姓名、联系方式、多职绑定或写权；缺能力不允许新增产品路径无校验继续 |
+| EXT-8b `ResourceAuthzQuery`／`ResourceAuthorizerV2`／注册口 | Backend 构造受信查询 → RDM 提供策略 → Backend 执行 | 现有六要素为 actor/action/resourceType/resourceId/owner/projectId；读取专用，V2 对域内读权威（含自有命中）；未注册的 V1 回落不能替代 I1 必需的资源限制 |
+
+以下是 U1 冻结的公开扩展申请四要素，符号为合同草案，I1 不新增导出实现、不更改 surface 版本。
+
+| 申请 | 场景 | 希望的公开符号／路径 | 现有注册点为何不足 | 兼容方式 |
+|---|---|---|---|---|
+| IAM-P 政策与动作目录 | UI／命令／工具需查询 scope、cap、有效绑定、权限解释与版本；角色通用权威迁移后供 RDM 同源判定 | 可选 `PermissionCatalogProvider`、`AuthorizationProvider`；公开目录／判定／解释与授权管理预览提交服务 | `IsAdmin` 只有布尔身份；`ActionMeta` 在 RDM 内部；EXT-8b 仅资源读，无法供系统管理或管理写入事务使用 | 新可选接口及版本化 DTO；旧 Host 不加必实现方法；RDM legacy 适配与新权威切换分别固定版本 |
+| IAM-D 受控人员目录 | 项目选人需要稳定身份、有效态和最小辨识字段，系统资料管理需独立授权 | 可选 `AccountDirectoryProvider` 与版本化查询／投影 DTO；既有 EXT-19 保留 | `AccountEntry` 仅 owner+valid，没有字段权限、搜索模式、可披露辨识资料及多职；私自扩展所有账号资料会扩大披露 | 新可选接口；旧 `ListAccounts` 不改变返回隐私范围；不得向旧消费者塞入联系方式 |
+| IAM-R 资源与当前政策上下文 | 跨原件／草稿／正文／审计分类，查询当前 policy／duty epoch，撤权影响读面与后台提交 | 新版资源查询／决策 DTO 及可选政策上下文提供者；保留 `ResourceAuthorizerV2` | 六要素无分类、职责／版本／epoch；bool 返回不能携带可披露原因与版本，读适配器不能承担写入事务 | 新版本资源接口或明确 DTO 增补；禁止未知字段零值放行，必需提供者缺失即拒绝；版本协商与双读仅作诊断 |
+| IAM-C 账号本人恢复 | 管理者只能提出恢复，账号本人经独立证明才能取得可兑换设密能力 | 公开恢复提案／本人确认／兑换回执合同，隔离恢复凭据与业务会话 | `IsAdmin`、目录、资源授权均不提供本人证明或安全凭据交付，不能用个人资料代替 | 新路径／可选能力，不向普通管理员交付目标账户可兑换 Key；旧不满足证明的线上路径明确拒绝 |
+
+| DTO | 必须冻结的字段与版本语义 |
+|---|---|
+| `PermissionDescriptor` | `actionId`、`label`、`description`、`scope`、`resourceTypes`、`group`、`conditions`、`delegationLevel`、`risk`、`descriptorVersion`；稳定 ID 不随改名变化，新增项默认拒绝 |
+| 授权查询／解释 | 受信 actor、actionId、资源定位与实际归属、当前状态／版本、选用 binding；输出 allow/deny、可披露 reason、来源链、`authorityEpoch`；解释只限本人或有权管理对象 |
+| 目录查询／投影 | 稳定 userId／owner、valid、获授权姓名／登录名／工号／职位投影、cursor/limit、精确／模糊模式及字段／状态过滤、`directoryVersion`；未授权字段不返回、不参与匹配；电话、邮箱、部门、备注只在独立授权资料面披露 |
+| 管理 patch／预览 | 固定对象 ID、expectedVersion、authorityEpoch、patch 摘要、幂等键；预览不代替提交授权，非法对象／越 cap／冲突整体拒绝；跨模块写入不冒充单库事务 |
+| 资源决策扩展 | 受信分类（私人／发布知识／受控正文／业务审计）、resourceVersion、policyVersion、dutyVersion、authorityEpoch 与决策原因；缺失或不认识分类拒绝，禁止请求自报归属 |
+
+目录 r1 的 scope 修订不能只改显示标签；执行端必须同时拒绝错误作用域写入。公开版本须同时登记导出面快照、版本号、变更表、提供者／消费者合同及固定组合。
+缺必需能力、未知动作／字段／状态、政策读取失败、归属不一致、过期版本、失效绑定均 fail-closed；不能用 `Host.IsAdmin()`、缓存 allow、V1 粗粒度授权或手填 owner 兜底。
+通用迁移前 legacy 台账只在其声明范围使用；迁移时保留 userId／owner／roleId／projectId／createdBy，禁止双主写入，不生成旧管理员的永久业务 grant，回滚不复活旧越权。
+
+## 5a. 当前公开能力缺口的 I1 处理
+
+以下是 U2 收口所需的默认拒绝策略，不是后续能力已实现声明；本地候选的实际验证见 I1 评审记录。
+
+- 未归属事件盘点、归属迁移、全量 outbox 队列必须另有 owner 批准的精确资源范围。I1 的 `Runtime.SetLegacyAccessAuthorizer` 为实例内受信集成点，查询绑定 actor/action/project/seq；不存在用户自授命令，不持久化、不跨重启继承。无提供者或提供者失败即拒绝。迁移另检查目标 `knowledge.publish`。
+- 当前 `Host.KnowledgeDelete` 仅能删当前 owner 的整个插件前缀，不能限定项目。`rdm.knowledge.revoke` 先验证目标项目 `knowledge.publish`，再明确拒绝执行，不能借 A 项目 grant 删除 B 项目索引。
+- `rdm.init` 当前实现读服务器路径并写全量未归属域，公开命令拒绝；可信本地 CLI/bootstrap 仍需操作授权。本轮不另造公开目录读取和项目初始化能力。
+- Host↔RDM 绑定须证明两个项目的管理资格；旧映射行与请求中的 HostProjectID 都不是此证明。I1 的实例内受信 Host 项目授权集成点必须绑定 actor/action/两个实际项目，缺失即拒绝绑定、解绑及基于映射的共享访问。旧映射不自动升级成授权证明。
+- 现 Backend `project/list` 授权成功后会返回项目下全部 owner 工件元数据，缺少逐资源 owner 裁剪，I1 拒绝此聚合共享。项目级 search 无发布分类证明时也拒绝跨 owner 检索；自有私人资源的具体读取路径保留。
+- 项目聚合 DTO 尚无安全的按阶段裁剪投影时，要求当前完整 `doc.read`；章节/文档接口按实际对象检查阶段。业务审计另需显式 `audit.read`。后续安全裁剪不得用 UI 隐藏代替执行端检查。
+- 新 outbox 回执以事务内 `rdm_audit_outbox_scope` 记录实际 project/owner，只送入对应 owner 的 Host；旧未知归属回执保持 pending，禁止按下一调用者猜测归属。该关联表为新增领域元数据，无历史自动归属，本轮未执行生产数据库变更。
+- status/resume/cancel 按私人批次的真实 owner 判定；恢复另检查当前项目写权及生命周期，取消仅保留本人停止私人任务的能力。opID 重放必须绑定操作、项目、主体与实际资源，冲突不能返回另一资源回执。
+
+| 扩展申请补充 | 场景 | 希望的公开符号／路径 | 现有注册点不足 | 兼容方式 |
+|---|---|---|---|---|
+| IAM-K 项目级知识撤销 | 合法 A 项目发布者仅撤销 A 已发布资源 | 可选项目/资源限定的知识撤销 DTO 与提供者；实际命名待模块评审 | EXT-9 whole-prefix 删除跨同一 owner 多项目；无可靠逐 ref 删除契约 | 新可选公开接口，旧缺失拒绝；固定提供者/消费者版本，不改 pins 猜测能力 |
+| IAM-H 宿主项目管理证明与资源裁剪 | 绑定需双方管理证明，共享读取需当前项目授权与实际资源分类 | 受信 Host 项目授权查询/证明及逐件资源投影提供者；实际命名待模块评审 | EXT-18 仅给当前 actor 的管理员位与项目定位；EXT-8b project/list 是整面 bool，无逐件过滤 | 新可选契约、权威对象与版本；旧映射只作定位，缺失默认拒绝；RDM 私有受信适配不能冒充 Backend 公共实现 |
+
+## 6. 账号恢复证明与交付
+
+普通管理员仅发起恢复提案；本人须使用管理员不能单方改写或取得的既有有效会话确认，或预先建立的本人恢复证明，才取得可兑换设密能力。
+姓名、电话、邮箱、工号均为可选资料，不自动成为恢复证明；新证明建立或更换不能由恢复提案管理员单独完成。
+无独立本人验证条件时拒绝线上恢复，不向普通管理员签发可兑换的目标账户 Key；异常人工恢复由另行批准的 owner 操作处理。
+恢复能力限制为一次消费、目标账号、设密用途与有效期，不生成业务会话；消费后本人使用正式凭证重新认证。
+本合同不证明恢复实现已具备；U3须验证“管理员提出恢复后自行设密接管业务身份”负例，旧路径未收口前 R7 不得闭合。
+
+## 7. 验收矩阵与证据边界
+
+R1–R20 到 RDM 原 UR／SR 的映射由 RDM `docs/proposals/2026-10-13-iam-i1-contract-adoption.md` 维护，原需求 ID 不重新编号。
+
+| 判据 | I1 文档核对 | 行为验收归属 |
+|---|---|---|
+| 系统动作不可由项目 override 或 `project.settings` 获取 | §2逐动作 scope／旧命令映射 | U2：普通成员合法本项目设置成功，全局角色／cap／移交拒绝 |
+| 创建者仍受有效角色 cap，遗留覆盖不越界 | §1／§3 | U2：创建者 cap=false、角色动作未定义、停用／换岗及旧 allow 负例 |
+| 管理员无业务身份旁路，审计独立授权 | §2／§4 | U2：admin／Host.IsAdmin 非成员及无 audit grant 拒绝；合法成员 audit grant∩cap 正例 |
+| 私人资源与受控正文分开 | §4／EXT-8b 消费边界 | U2 可达路径；U5/U6 统一资源及职责、当前版本完整验收 |
+| 一职多人、一人多职、项目明确选用 | §1／§3／IAM-P | U4/U5：新任命不扩既有项目、解绑再任命不复活、完整路径不拼接 |
+| 账号目录敏感投影与本人恢复 | §5／§6 | U3：未授权字段不匹配／不返回；管理员不能取得本人兑换凭据 |
+| 冻结文档轮次、撤权与迟到事件 | §3／§4／IAM-R | U6/U8：当前职责与 cap 重验；旧卡／Surface／SSE／后台最终提交拒旧 |
+| 单权威迁移、版本兼容、完整组合 | §1／§5 | U4/U9：旧→新差异、双主拒绝、当前固定提供者／消费者和制品验收 |
+
+U1 只检查文档差异、链接、动作与 scope 一致性、R1–R20 追溯及原方案摘要保持；无行为变更，不运行业务测试。
+本地检查来源为 SELF；审核与正式验收须按任务规则同步对象、独立重放并核验 GATE／REPLAY 身份及 SHA。
+公开实现、业务测试、浏览器、真实模型、数据库迁移、服务运行、部署与正式验收均不能用本合同的保存结果代替。
@@ -0,0 +1,73 @@
+# IAM I1 实施候选与人工评审记录
+
+负责人：weichen；实施协调：Codex；日期：2026-10-13；状态：阶段 6 已由用户批准；阶段 7 测试候选已形成，待用户验收。原阶段 6 对象与收据保留，最新状态见下方批准记录及验收报告。
+
+本页维护已批准统一方案 I1 的实际进展；原方案原文摘要保持不变。本轮只执行 U1–U2，交付终点为“给我评审”，不启动后续增量。
+
+## 批准对象与当前候选
+
+- [统一方案 r1](2026-10-13-identity-role-permission-plan.md)：用户已批准并授权 I1＝U1–U2；原文 SHA256 `39b8e9a6e078dc509bd80118c1807ce6ed23e4466e5902b51f4bfa255d55c0a1`，Documents `a088809` 保存原批准快照。
+- [I1 权限合同 r1](2026-10-13-iam-i1-permission-contract.md)：稳定动作与 scope、角色／平台 cap、独立业务审计、隐私及公开扩展申请。提供者缺失默认拒绝，合同文档不能证明接口已提供。
+- RDM 初始 R0：`b1fe932883d2a55f0373bb0930950da3d12d2b5e`；同步后的 main：`2f1a36f55a4979262e386150af26085d4d15b2a1`，包含职责批量分配与权限覆盖删除。两项注册冲突已保留主干功能并接入身份包装；组合结果须重新测试。
+- RDM 已独立审阅的行为候选：`dfb9c407858173ba501a623631c17643bd1985b5`（代码截至 `4e3d7665e973838b77d6e81164b8d70540de907d`，后者之后仅同步任务卡；之后旧测试断言／import与证据记录继续收口）。最终收据与记录提交可能前进，测试有效性按行为文件／组件是否变化核对。
+- [Dev 任务卡](/home/weichen/projects/Agent-System-Dev-wt-feature-iam-i1-permission-boundaries/.task/feature-iam-i1-permission-boundaries.md) 与 [RDM 任务卡](/home/weichen/projects/Agent-System-RDM-wt-feature-iam-i1-permission-boundaries/.task/feature-iam-i1-permission-boundaries.md) 保存启动、红测、失败、同步、绿测完整工具输出，来源均为本地 SELF。
+
+## 本次行为变化
+
+| 边界 | 候选中的具体变化 | 对应要求 |
+|---|---|---|
+| 系统与项目 | role/cap/任命/移交走独立受保护系统 action；项目 settings 不能授予这些动作；当前 actor 必须匹配 Host.Owner。新增 unset 也检查注册项目 scope、实际成员与当前管理权 | R6/R8/R12 的 I1 部分 |
+| 当前资格与 cap | 创建者、管理者与成员均受平台 cap；已绑定职位先检查存在／有效／动作定义与 cap；停用、换岗及旧 allow 不能回落或越界。矩阵解释与执行共用评估器 | R9/R11 的当前单绑定部分 |
+| 项目业务访问 | 去掉域管理员和 Host.IsAdmin 的跨项目业务旁路；项目清单按当前成员关系；归档仍可由合法 archive 权限恢复，其他业务写入拒绝 | R7/R8/R11 的 I1 部分 |
+| 业务审计 | 新独立 audit.read，平台 cap 初始关闭，关系默认不授予；实际授权成员还须当前完整 doc.read。聚合审计含正文预览，不能借阶段受限读权读全项目 | R7/R18 的 I1 部分 |
+| 正文读取与导出 | 章节／文档按真实对象检查阶段；标题导出只接受唯一匹配、按同一解析目标授权与生成；差异、审核状态、法规快照检查阶段／真实项目归属。无法安全阶段裁剪的聚合 DTO 要求完整读权 | R12/R18 的 I1 部分 |
+| 私人原件与草稿 | pending/rejected 私人提案只允许提案人查看／采纳／拒绝，采纳还验编制职责；上传原件只允许本人确认；管理上传视图为元数据；历史上传清单不跨项目混入 | R18 的当前可达路径 |
+| 私人批次 | status/resume/cancel 先按真实 owner 判定；私有与不存在统一不透明拒绝；恢复另验当前 doc.write／成员关系／职位／cap／生命周期，不能凭旧属主身份重新入队；本人停止私人流程保留 | R11/R12/R18 的当前入口 |
+| 模型输入与写回结果 | draft.compose 发模型前需要目标正文读取范围；结论确认在返回 stored text 前需完整 doc.read。写权不能代替读权 | R12/R18 的当前入口 |
+| 回执归属 | opID 使用 JSON 元组绑定操作／项目／主体／资源，短路与事务内重放一致，旧不可信 key 拒绝。outbox 新回执以同事务关联真实项目与 owner，只送入对应 Host；旧未知归属项保留 pending | R12/R18/R20 的当前入口 |
+
+完整多职位、项目明确选用绑定、账号有效态、恢复证明、三权全模型、政策 epoch 与所有后台最终提交撤权均未在 I1 实现。这里的 R 行不是完整 R1–R20 关闭声明。
+
+## 验证与证据
+
+U1 为规范文本更新：核对本地链接、17 个稳定 action/scope、R1–R20 追溯、批准原文摘要及固定 RDM 初始基线的 08 核心 R1–R5；无业务行为，不制造文本单元测试。
+U2 先运行真实临时 SQLite 与已注册命令负例，再修改实现并保留相应合法流程。旧测试中期待 admin 跨项目、停用角色回落、他人代确认等断言按批准合同修正，正常路径仍通过真实授权夹具运行；没有删除失败用例以绕过测试。
+
+| 检查 | 当前结果 | 证据边界 |
+|---|---|---|
+| 初始负例与审阅补漏 | 已真实复现并记录；红测保留 | 包含越权写入、实际正文／原件元数据回执、未知归属写入与跨 owner 审计投递；编译失败与夹具失败也保留，不冒充行为证据 |
+| 新回归与相关旧流程 | 通过（SELF）；独立重跑 39 个顶层 I1 回归 | 工具记录命令、HEAD、dirty 摘要与完整输出；本轮编译失败、夹具失败和“no tests to run”均保留，不计为行为通过 |
+| RDM make test | 通过（SELF），对象 ef075bd1 | 完整收据 ab592b80c858543f…见 RDM 任务卡：组合产品构建、29 项 Web 检查、Go 全量均退出 0；不包含部署／生产数据验收 |
+| Dev make test／文档检查 | 已通过（SELF），对象 0ab70b0c；最终文档记录后的对象另见任务卡 | 完整收据 b12914e5136cc405…见 Dev 任务卡；含工作树、gitlink、治理、模块／UI／命令组合检查，本任务未改业务 UI。最终文字记录收口后按固定 gitlink 再核验，新增收据由工具记录，不复制输出 |
+| 独立提前源码审阅与 focused 重放 | 通过，39 组顶层回归全部通过（本地） | 审阅者 /root/i1_security_review 未参与源码写入；对象 dfb9c407，独立重跑命令与完整 SELF 工具收据见 RDM 任务卡；不是用户批准、平台账号独立批准或受信 CI |
+| 正式验收／CI／浏览器／真实模型／生产迁移／部署 | NOT_RUN | 模型注册描述已按实际拒绝边界改写；未建立本轮固定模型任务级前后基线，测试使用 mock Host，不能声称模型行为通过。正式阶段应固定模型／配置／任务集，补真实对照及浏览器链路 |
+
+## 必须审阅的兼容影响
+
+1. 新 audit.read 初始不授予任何人。合法系统管理者先开平台上限，角色有资格后由合法项目管理者授予业务审计；此前 admin／创建者自动审计行为停止。
+2. KnowledgeDelete 只能按当前账号整插件前缀删除，故项目 revoke 明确拒绝，等待项目／资源限定公开接口；公开 rdm.init 也因读服务器目录并写全量未归属域而拒绝，可信本地操作保留。
+3. Host↔RDM 绑定、解绑及映射共享读取需可信双方项目授权提供者；当前未安装生产提供者，缺失默认拒绝。project/list 的整批私人工件元数据共享关闭；现项目级跨 owner search 缺发布分类证明也拒绝。自有资源具体读取和明确的 RDM 项目知识读面保留；不是完整共享 RAG 已验收声明。
+4. 存量未归属盘点／迁移／全量 outbox 状态需独立范围授权；实例内可信集成不是用户自授接口，重启不继承。旧未知归属 outbox 保留 pending，新增关联表仅处理之后的可证明来源；不推测历史 owner、不丢记录。本轮未变更生产 DB。
+5. 有阶段范围的用户无法读取尚未安全裁剪的全项目聚合 DTO；后续应逐对象投影与重算计数。失效绑定和旧不可信 opID 回执拒绝，不能把兼容回退当作当前资格。
+
+这些限制是避免当前公开契约不足扩大授权的 I1 处理；正式产品恢复对应能力需固定提供者／消费者的新公开版本与独立正反例，不能靠当前平台管理员位补足。
+
+## 进展与下一步
+
+U1 权限合同与需求追溯已完成；U2 当前 RDM 可达路径整改、本地组合自检和独立提前复审已完成，等待用户阶段 6 评审。独立提前源码复审已通过；后续测试记录更新必须确认生产源码与此对象等价。未推送、未创建 PR、未合入、未部署，保留两个独立工作区及全部失败收据。
+
+首选下一任务为已规划 I2/U3：账号可选资料、受控人员目录与本人恢复证明。推荐理由是先建立可信身份／有效态与安全恢复边界，随后才能实施 Backend 通用角色和多绑定 U4。前置条件：用户批准 I1 实施结果并另行授权 U3；核对已有账号目录实现，复用最小 EXT-19 边界；公开提供者先审接口，不能绕过 pins。预期产物：资料全空合法、字段授权搜索不泄漏、项目目录只投影获准辨识字段、普通管理员不能获取目标本人可兑换设密能力的真实负例及成功本人流程。此建议不启动新任务。
+
+公开 Host 能力缺口另有 IAM-H／IAM-K 申请；可与 U3 的公开提供者工作协调，恢复共享／撤销前先完成固定契约，不以设计文档存在放行。
+
+## 实施调用与单元记录
+
+实施引擎为 native Codex，委派单元为权限合同、初始负例、旧测试对齐、幂等隐私补漏与独立提前审阅；无外部模型路由绑定／回退／detached run，实际服务模型未独立证明。source_kind=plan，source_digest 为上方批准原文摘要；plan_checkpoint 为 Documents a088809。行为单元 U2 的原始红→绿观察保存于当时工具收据，不能从最终 diff 重构；U1 为非行为文档核对。单位 canonical commit 和完整 changed_files 由所属仓的当前分支与任务卡追溯。此本地交付跳过推送、PR、CI与合入 shipping tail。
+
+Dev 同步 main 到 143e636736 后随主干物化 Backend 15566f9a、Core 5773e740、Frontend c294835f、UI 2c4322ef；本任务相对该 main 只改变 Documents、PROJECT 导航与任务卡。RDM 产品仍按自身 pins 固定 Backend 0f192a48、Frontend 4965de26、UI bfecf8b5，未自行推进 pins；两套组合的检验与状态分开，不用 Dev 测试证明 RDM 的提供者能力。
+
+## 阶段 6 人工批准（2026-10-13，北京时间）
+
+用户在本页 c023551 对应的实施候选与兼容影响交付后回复“批准”。阶段 6 实施与自检结论：通过；对象为 Documents c023551、RDM b93908e、Dev 72ed8b4。该结论不代签尚未完成的阶段 7 验收，也不启动后续 U3–U9 或生产部署。恢复时已有主干推进，正式测试将固定同步后的对象，报告正常／异常／边界／回归证据与缺项，再请求用户验收；原获批对象和所有早期失败收据保留。
+
+阶段 7 当前产物：[正式测试与验收候选](2026-10-13-iam-i1-acceptance.md)。上述阶段 6 测试与缺项记录为当时快照；新的真实 HTTP 结果、独立重跑及仍未执行项目以阶段 7 报告和工具收据为准。
@@ -0,0 +1,574 @@
+---
+title: 用户、职位角色与分层权限统一设计及实施计划 r1
+date: 2026-10-13
+type: refactor
+execution: code
+artifact_contract: ce-unified-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# 用户、职位角色与分层权限统一设计及实施计划 r1
+
+负责人：weichen；编制：Codex；更新时间：2026-10-13（北京时间）。
+确认状态：本轮两项用户裁定已确认；完整需求表、架构调整、迁移与实施计划待人工评审。
+推进状态：源码调研与方案编制；业务修改、业务测试、数据库迁移、部署及运行验收均为 NOT_RUN。
+本文是本次改造的唯一方案主记录；任务卡与索引引用本文，不复制推进状态。
+
+## Goal Capsule
+
+让管理员按企业职位管理人员与能力，让创建者在自己的项目管理成员和文档责任，并让用户清楚知道自己能操作什么、为什么可以或不可以。
+复用现有账号、职位角色、项目成员、权限解释与整文审签能力，修正作用域混用，再补齐资料、搜索、单对象配置与批量矩阵。
+本轮交付终点为完整方案及分阶段计划，业务实施与运行操作需取得对应阶段授权。
+
+用户已明确选择：系统管理员管理账号、角色与权限上限，访问他人项目业务内容需要明确授权；首期支持一人多职，每个项目明确选用该用户的哪些职位角色。
+这两项决定来自本轮对话，完整方案仍为待评审草案。
+
+---
+
+## Product Contract
+
+### Problem Frame
+
+当前存在四种概念：系统账号、企业职位、项目管理关系、文档编制／审核／批准职责。
+它们在部分命名、管理入口和授权函数中混用，导致项目设置权限能够进入全局管理、管理员自动获得业务访问、角色停用或换岗后权限不一致。
+改造的重点是统一权限语义和执行端判定，同时把配置权、作用域和具体资源责任说清楚。
+
+“系统权限、角色权限、项目权限”是同一套权限模型的不同配置来源与作用范围。
+角色是能力模板，系统权限是系统范围的动作，项目权限是限定到一个项目的授权。
+文档三权进一步确定谁对某个版本履行哪项职责。
+
+### Sources and Current Evidence
+
+权威顺序采用 RDM `docs/requirements/README.md`：最新用户指示 → 当前 U0/Q 裁定与权威需求正文 → 当前矩阵 → 未被取代的旧设计 → 原始会议。
+`.tmp` 原件作为设计来源保留，不回写历史原稿。
+本轮优先阅读 `.tmp/Discussion-Meetings/2026-10-08_12-24/Outputs/11-角色与权限管理方案.md`，并与 01／03／08 系列、RDM 当前需求和后续计划交叉核对。
+
+| 对象 | 本轮读取的固定版本 | 证据边界 |
+|---|---|---|
+| Dev 源码基线 | `3fb8210f6495a78e70a67af3661bdfe9c00fb9de` | 本地源码与启动检查，SELF |
+| Dev Backend | `dc736e339d01c59e658abc63c81909059bd6ea02` | 本地源码，SELF |
+| Dev Frontend | `dcd2699933eff51c06193cac7beb15c3d20a01ff` | 本地源码，SELF |
+| Documents / UI | `05c13a42b14d70f878cc8a51c543e018a7f7a663` / `0da2e3acd6c8ae8957825b64ddb54b250c0979c0` | 文档与设计约束 |
+| RDM | `255f9cba0c9e6f981fbff66142be92532d5c5f2d` | 本地源码，SELF |
+
+RDM 自己的 Backend／Frontend pins 与 Dev 组合不同，不能把某一工作树的能力视为另一组合已部署的能力。
+命令、对象与脱敏输出由任务卡的 evidence 收据保存；本稿的源码事实不等于部署重现、GATE 通过或正式验收。
+
+| 已核实的源码情况 | 对方案的影响 | 源码位置，路径以所列仓为根 |
+|---|---|---|
+| 已有独立职位角色、多账号可绑定同一角色；账号当前只能绑定一个角色 | 扩展已有模型，支持多职、描述和编辑 | RDM `internal/perms/roles.go` |
+| 用户资料没有电话、邮箱、工号等；公开目录仅 owner＋valid | 账号资料和受控目录必须有 Backend 公开契约 | Backend `internal/store/auth.go`、`pkg/extension/extension.go`、`internal/app/hostcaps.go` |
+| 角色／全局上限／管理员移交复用 `project.settings` | 首批拆开系统动作与项目动作 | RDM `internal/rdmapp/perms_api.go` 中 `AuthorizeGlobal`、`roleAdminGate` |
+| 域管理员和基座超管在多处自动读取项目、审计、导出、原件或草稿 | 同步修订所有业务读面，取消身份式业务放行 | RDM `perms_api.go`、`runtime.go`、`upload.go`、`draftproposal.go` |
+| owner 跳过职位上限；角色停用回落内置 member；换岗后遗留 override 可跳过未配置动作的角色上限 | 采用完整授权链，覆盖创建者、停用与换岗负例 | RDM `perms_api.go` 中 `evalPerm`、`internal/perms/roles.go` |
+| “权限矩阵”是单成员有效权限解释；角色页每次编辑一个动作 | 保留解释能力，补可编辑角色矩阵与成员矩阵 | Frontend `src/components/adminRdmSections.tsx` |
+| 用户、角色、三权候选主要手输 owner／docId；入口依赖 isAdmin | 接受服务端能力与目录查询结果，使用稳定 ID 选择 | Frontend `adminSections.tsx`、`adminRdmSections.tsx`、`AdminZone.tsx` |
+| 基座建项接口与 RDM 建项命令的门禁不同 | 统一产品入口；区分宿主项目与研发项目后封闭旁路 | Backend `internal/server/server.go`；RDM `plugins/rdm/plugin.go` |
+
+### Requirements
+
+需求编号仅用于本方案，不替换原有 UR／SR 编号。
+
+**身份、职位与人员查找**
+
+| ID | 需求与可判定验收条件 | 来源 |
+|---|---|---|
+| R1 | 角色是独立职位对象，有稳定 ID、名称、可选描述、状态和版本；改名不改变人员身份或历史 | 本轮用户；SR-G7 |
+| R2 | 同一职位可关联多人；一人可关联多个职位；项目只采用明确选定的有效绑定，新增职位不自动扩张既有项目 | 本轮用户裁定；当前概念模型 |
+| R3 | 姓名、电话、邮箱、工号、部门与备注均可选；全部留空仍能建号；资料不成为登录凭证或授权主键 | 本轮用户 |
+| R4 | 支持精确与模糊搜索、字段选择、状态／职位等过滤、分页与同名辨识；最终授权对象是稳定用户 ID | 本轮用户 |
+| R5 | 系统管理者可维护账号资料；本人可编辑非授权资料；项目选人只获得必要目录投影，无权读取完整联系方式或凭证 | 本轮用户；隐私边界 |
+
+**系统与项目授权**
+
+| ID | 需求与可判定验收条件 | 来源 |
+|---|---|---|
+| R6 | 系统设置、用户管理、角色管理、策略管理与建项采用明确系统动作；项目权限编辑不能写入系统动作 | SR-G6/G7/G8；本轮用户 |
+| R7 | 系统管理员无项目／资源授权时不能读取他人业务正文、原件、草稿、业务审计、导出、搜索命中或模型上下文 | 本轮管理员裁定；修订旧跨项目审计口径 |
+| R8 | A 创建者不能凭 A 的管理权管理 B；创建事实固定，负责人接替采用明确委任记录 | SR-G9/G10 |
+| R9 | 创建者在本项目管理成员、覆盖权限与分配三权；项目覆盖可覆盖角色默认，但不能突破平台和角色上限 | SR-G8/G9 |
+| R10 | 多角色按完整授权路径合成；平台禁止、项目明确拒绝与资源限制不能被另一角色绕过 | 本轮多职裁定；SR-G2/G8 |
+| R11 | 角色停用、解绑、换岗、上限收紧、账号停用和成员移除及时撤权；遗留覆盖不能复活旧权 | 当前源码缺口；SR-G8/N4 |
+| R12 | 同一动作的 UI、HTTP、命令、工具、任务恢复与最终提交遵循同一服务端判定；未知或失败状态拒绝 | SR-G2；U0 D1 |
+
+**配置体验与文档职责**
+
+| ID | 需求与可判定验收条件 | 来源 |
+|---|---|---|
+| R13 | 单角色编辑与角色×权限矩阵是同一数据的两种视图，支持分组、精确／模糊搜索、过滤与批量草稿 | 本轮用户 |
+| R14 | 单成员编辑与成员×权限矩阵共享草稿；显示继承／授予／拒绝、角色默认、上限、最终结果与原因 | 本轮用户；SR-G8 |
+| R15 | 批量保存有具体差异、影响预览、版本冲突保护、原子提交和审计；隐藏行不丢草稿，不逐格即时落库 | 配置完整性与当前缺口 |
+| R16 | 每份受控文档编制一人、批准一人、审核至少一人，三类人员互异；候选必须是有效成员并具备对应能力上限 | SR-C7/G9 |
+| R17 | 职位能力只提供资格；实际编写、审核、批准同时检查具体职责、文档状态与冻结版本；管理权不代签 | SR-C7/C8；U0 D2/D5 |
+| R18 | 私聊、私人原件与个人草稿保持私有；项目知识由明确提交／发布产生；受控文档按职责或明确授权读取 | SR-G11/G12；U0 D3 |
+| R19 | 权限变化同步影响已开页面、旧卡、Surface、下载、检索、SSE 和后台任务；迟到事件不能恢复权限 | SR-G2/G11/N4；根 AGENTS.md |
+| R20 | 保留用户／项目／角色稳定标识与历史；迁移输出旧→新差异，不把旧管理员全权转成永久业务授权 | 持久化与兼容要求 |
+
+### Confirmed Decisions and Scope
+
+管理员业务访问边界已经用户选择确认（session-settled: user-directed — chosen over 管理员自动获得全部项目业务访问: 业务访问需要明确授权；Governs R7）。
+首期多职及项目明确选用已经用户更正确认（session-settled: user-directed — chosen over 每人仅一个生效职位: 用户改为采用多职建议；Governs R2/R10）。
+
+本次覆盖用户资料、职位模型、系统／项目授权、配置界面、文档职责与读取授权、Agent 同源执行、迁移及验收。
+飞书／SSO、组织树与岗位继承、全自动任命／签字、全量模板补齐、整个工作流引擎重建和外部权限服务采购不纳入本次。
+本次修订需要更新 RDM 权威需求与相关方案，但 `.tmp` 历史稿保留。
+
+---
+
+## Planning Contract
+
+### KTD1. 数据职责与统一入口
+
+建议把通用账号资料、职位定义、用户—职位绑定、系统动作授权及平台／角色上限集中到 Backend 的通用身份与授权服务。
+RDM 负责项目成员、项目选用角色、项目覆盖、资源归属、阶段状态和文档三权，注册领域动作及资源策略；UI 和 Agent 消费同一公开服务。
+用户主身份沿用基座稳定 ID 与现有 owner 映射，不另建账号；RDM 历史 owner 标识保留。
+
+这是对现行“专业角色主表在 RDM”的明确架构调整建议，须在方案阶段评审，不能借旧 U0 D1 当作已经批准。
+集中通用职位定义可以让账号管理、建项与项目业务共同消费一份授权事实，并避免两个角色台账同步漂移。
+RDM 专有的职责与状态规则仍留在 RDM，基座只知道注册动作、约束及判定协议。
+下游通过正式公开扩展及固定版本消费，禁止修改 pins 源码或导入 Backend internal。
+
+主要备选：保留 RDM 角色主表并让基座经公开策略提供者查询。
+该路径减少角色数据搬迁，但系统管理动作会依赖领域插件及其可用性；若采用，必须冻结单一权威、插件缺失时拒绝策略和根管理恢复通道，不能再建第二套独立职位表。
+不推荐仅补 UI：它不能解决已经存在的服务端 scope 混用。
+
+### KTD2. 概念模型
+
+| 对象 | 核心字段／关系 | 权威 |
+|---|---|---|
+| User / Profile | 稳定 userId、owner 映射、账号有效态；可选姓名、电话、邮箱、工号、部门、备注；profileVersion | Backend |
+| Role | roleId、名称、描述、状态、roleVersion、创建／变更主体 | Backend，拟迁移现有 RDM 角色 |
+| UserRoleBinding | bindingId、userId、roleId、有效态、任命主体／时间、版本；支持多对多 | Backend |
+| PermissionDescriptor | 稳定 actionId、中文名、说明、scope、资源类型、分组、条件、委派级别、风险与版本 | Backend 注册表，RDM 注册领域项 |
+| RolePermission | roleId＋actionId、默认 grant、cap、允许的资源范围；default 范围不得超 cap | Backend |
+| SystemGrant | 明确系统动作授予与上限；受保护管理员／策略管理授权独立记录 | Backend |
+| Project / Membership | 稳定 projectId、固定 createdBy、当前负责人委任；成员身份、明确选用的 bindingId、版本 | RDM |
+| ProjectOverride | 项目＋成员＋动作的 inherit／allow／deny，以及资源范围收缩、版本 | RDM |
+| ResourceGrant | 资源稳定 ID、类型、真实属主、项目、分类、明确接收者／职责、只读范围、撤销版本 | 资源 owner；统一公开判定 |
+| DocumentDuty / Round | 文档职责、冻结正文／职责／策略版本、轮次与真实操作者 | RDM |
+
+这些是逻辑模型，具体表名与迁移编号在实施时确定。
+删除有引用的用户和角色采用停用／归档，保留审计身份；无引用对象才允许物理删除。
+同名职位的规范化重复检查独立于显示名；同名人员允许存在，工号与联系方式不作为强制唯一标识。
+可选资料做长度与格式校验，空值合法；电话仅按明确规则规范化，避免错误匹配。
+
+### KTD3. 权限目录与系统权限
+
+权限目录的 scope 由受信注册表确定，不能凭动作字符串前缀或请求体自报作用域。
+旧 actionId 通过版本化映射兼容，作用域冲突的旧项不继续接受写入。
+
+| 权限类别 | 动作示例 | 谁能配置／怎样生效 |
+|---|---|---|
+| 系统设置 | system.settings.read／write，model／plugin／agent 设置子项 | 具备对应系统管理权者；平台策略限制 |
+| 用户管理 | system.users.view／create／edit／disable；credential.recover 单列 | 分项授权；普通资料编辑不允许改管理员资格 |
+| 职位管理 | system.roles.manage／assign | 管理职位与普通任命；不能越可委派上限 |
+| 高权限管理 | system.policy.manage／privileges.manage；admin.transfer | 受保护动作；项目覆盖和普通职位任命不可间接获得 |
+| 创建项目 | project.create，scope=system | 有效系统／职位 grant；选定产品与创建者角色上下文 |
+| 项目管理 | project.settings、member.manage、permission.manage、duty.assign、stage.advance／archive | 具体项目创建者或明确委任；受 cap 与状态约束 |
+| 项目内容 | knowledge.read／publish、trace.read／edit、business-audit.read／export | 项目关系、角色范围和资源关系同时满足 |
+| 文档动作 | document.read／export、author／review／approve 等资格项 | 能力资格＋具体文档职责／授权＋状态 |
+
+管理员徽标由受保护系统授权产生，职位名称叫“管理员”不会改变其权限。
+首期保留至少一个有效策略管理者与安全恢复通道；并发撤销最后管理者必须在事务中拒绝。
+普通角色管理者不能编辑受保护权限，也不能给自己或别人任命超出其可委派范围的角色。
+系统管理员不自动加入项目，不自动获得业务统计或业务审计。
+系统安全日志仅披露必要的账号、安全动作、结果与不透明对象标识，不含业务正文、文件名、项目名称、内容摘要或完整历史差异。
+访问业务审计采用对应项目的明确授权，与正文授权分别显示。
+
+### KTD4. 单一权限判定与多角色合成
+
+输入由认证会话、受信资源存储和实际执行上下文组成：主体、动作、资源类型／ID、真实项目／属主、当前版本与当前状态。
+请求体里的 actor、owner、projectId 不能替代受信归属；资源与项目不一致时拒绝。
+服务端返回 allow／deny、来源链、拒绝原因及 authorityEpoch，UI 不重新计算权限。
+解释接口只能解释调用者自己或其有权管理的对象，不能成为探测他人资料的旁路。
+
+系统动作只读系统授权来源，不接受 ProjectOverride。
+其有效值为当前有效账号、平台允许范围、对应受保护规则，以及明确 SystemGrant 或一条完整的系统职位默认授权路径；不依赖项目所选职位，也不接受项目 allow 作为系统授权来源。
+项目动作先确认成员／创建者／明确委任与资源归属，再对每个有效且本项目选用的职位绑定建立完整候选路径：
+
+`角色动作已定义且启用 ∩ 角色 cap（含范围） ∩ 平台 cap ∩ 项目 grant/默认 ∩ 资源关系 ∩ 阶段/状态 ∩ 文档职责`。
+
+对具体动作，至少一条完整路径通过才允许。
+一个角色的动作授权不能与另一个角色的资源范围拼接；角色 cap=false 只关闭该角色的路径，平台禁止、项目明确 deny 和资源禁止对全部路径生效。
+项目 override=allow 仅替换默认 grant，不能创造不存在的动作、突破任一 cap 或跳过资源关系。
+override=deny 阻断该成员在该项目对此动作的全部角色路径；inherit 使用当前有效默认。
+多个角色可共同授予不同动作，但一次动作必须有完整证据来源。
+
+加入项目时明确选择该用户的有效 bindingId；只有一个有效角色可预选，多角色需明确选择。
+新任命角色不自动加入已有项目；解绑后旧 binding 立即无效，重新任命产生新 binding，旧项目配置不自动复活。
+停用角色没有回落授予；无有效角色仅保留显式最小账号自助能力，业务动作拒绝并说明缺少资格。
+新增权限默认拒绝；读取策略失败、缺元数据、未知动作或必需提供者缺失时拒绝。
+
+创建者关系提供本项目管理默认，仍经过其有效角色 cap 和平台 cap，不能自动读私域或代签。
+建项前检查创建者角色组合具备本项目设置、成员管理与三权分配的 cap 资格，避免建成无法管理的项目；role default 可关闭这些动作，由创建者关系提供项目内默认。
+已有项目遇 cap 收紧时保留归属，阻断受影响动作，并向授权管理者显示需要调整任命的原因。
+为避免唯一负责人换岗后无法重新选用职位，提供受限的“重新选择本人项目职位”动作：仅当前有效负责人本人，可从其账号当前有效任命中显式选择具备平台和项目管理 cap 资格的 binding，并按当前项目版本确认保存。
+仅该动作可使用尚未被项目选用的当前任命；普通项目动作仍只使用项目已选用的 binding。
+它只修复本人在本项目的角色选择，不改变项目负责人、不恢复旧 allow 覆盖、不清除明确 deny，也不授予资源读取或三权；完成后普通动作重新经过完整判定。
+角色任命者只能处理系统任命，不能代选项目职位；没有合格任命时项目保持等待，不能扩大 cap 恢复。
+项目内移除／降权最后负责人时保护实际可操作的管理资格，而不仅计数 owner 关系；系统 cap 收紧造成的暂停则明确记录与提示，不能阻止管理员执行必要撤权。
+创建项目、创建者成员关系与所选 binding 在同一领域事务落地；宿主绑定采用可恢复状态与幂等对账，失败不能留下可使用的无负责人项目。
+
+判定、解释与所有入口共同调用该服务。
+设计采用最小权限、默认拒绝和每次请求重验，也结合项目关系与资源状态；依据 [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)。
+
+### High-Level Technical Design
+
+```mermaid
+flowchart TB
+  U[用户及多个职位绑定] --> I[基座身份与通用授权服务]
+  C[系统动作与权限目录] --> I
+  R[角色默认与角色上限] --> I
+  P[项目成员 所选绑定 项目覆盖] --> D[统一判定]
+  I --> D
+  A[资源归属 明确分享 文档职责] --> D
+  S[阶段 文档状态 当前版本] --> D
+  D --> E[HTTP 命令 工具 任务提交与读取]
+  D --> X[有效权限解释与矩阵]
+```
+
+```mermaid
+flowchart TB
+  Q[受信主体与资源定位] --> A{账号 动作与归属有效}
+  A -->|否| N[拒绝并给出可披露原因]
+  A -->|是| B{系统动作}
+  B -->|是| C[系统来源与受保护权限检查]
+  B -->|否| D[项目资格与硬限制检查]
+  D --> E[逐角色建立完整路径]
+  E --> F[资源 职责 状态 版本检查]
+  C --> G{当前授权通过}
+  F --> G
+  G -->|否| N
+  G -->|是| H[允许 在提交或输出边界再检查]
+```
+
+### KTD5. 文档三权与读取范围
+
+复用现有整文审签，不建立另一套审批引擎。
+项目创建者通过统一服务选择有效项目成员，系统验证职位资格与文档三权异人要求，再记录真实分配者和受指派人员。
+审核人可多人，全部指定审核人通过后才允许批准；审核／批准只能批注和通过／驳回，不能修改正文。
+审核与批准人员因实际职责可读提交审阅的正文和明确关联材料；这不开放私人对话、未分享原件或私人草稿。
+共享授权只增加规定资源的读取能力，不转为编写或签字资格。
+
+审签轮次冻结正文版本、职责版本与政策版本；人员停用、解绑、移除或权限收紧后，待处理轮次进入明确等待／失效状态，重新指派及提交。
+历史已完成的签字和操作者身份保留，不因换岗改写；历史内容读取仍使用当前授权。
+批准后修改采用既定撤回重审＋影响提示；职责替换不能清洗同一版本实际编制者的记录。
+未分配三权的文档显示等待分配，并阻断受控编写／提交，不回落为全成员可写。
+
+```mermaid
+stateDiagram-v2
+  [*] --> WaitingDuty
+  WaitingDuty --> Drafting: 指派有效三权
+  Drafting --> Reviewing: 编制人提交固定整文版本
+  Reviewing --> Drafting: 驳回或撤回
+  Reviewing --> Approving: 全部指定审核通过
+  Approving --> Drafting: 驳回或撤回
+  Approving --> Approved: 指定批准人签字
+  Approved --> Drafting: 撤回并开启新版本
+  Reviewing --> WaitingDuty: 职责或必要资格失效
+  Approving --> WaitingDuty: 职责或必要资格失效
+```
+
+### KTD6. 查找与配置界面
+
+沿用系统管理区、项目设置和文档入口，遵守 Dev `DESIGN.md`，不新增无用途的权限仪表盘。
+
+1. 系统管理 → 用户：可搜索列表、职位／状态过滤、用户详情；详情显示可选资料、职位绑定、系统能力及来源。创建账号不要求填写人员资料。
+2. 系统管理 → 角色与权限：角色列表＋名称／描述／状态／绑定人数；选中角色后编辑默认与上限，也可切角色×权限矩阵。系统级受保护项按操作者资格显示。
+3. 项目设置 → 成员与权限：选人、选择项目生效职位、项目覆盖；单成员视图与成员×权限矩阵共用草稿，显示最终解释。
+4. 文档现有入口 → 三权：文档×编制／审核／批准矩阵与单文档选择器；候选范围、资格不足、多人审核及冻结状态直接说明。
+
+精确搜索按选定字段规范化后完全匹配，稳定 ID／登录名优先；模糊搜索首期采用包含匹配和明确的前缀排序，不默认增加拼音／向量／模型识人。
+搜索资料范围遵循目录权限；被禁字段既不返回，也不参与未经授权的匹配，防止通过命中数量探测联系方式。
+过滤包括权限 scope、分组、默认／上限／最终允许、继承／覆盖、职位与账号状态、当前修改；精确／模糊与过滤可以组合。
+共享“职位”不代表可查看所有同职位人员的私密资料。
+同名候选显示姓名（如有）、登录名、职位与工号的授权投影；人名不清楚时必须选择具体对象，模糊匹配不能直接完成任命。
+
+矩阵不是一张无限扩展的大表：按分组及分页显示，固定对象标签，提供单元格说明和键盘导航。
+单角色视图的 default 与 cap 两列，成员视图的 inherit／allow／deny，与最终“允许／拒绝”的只读结果有明确区分。
+过滤隐藏项不清空草稿；“全选”只选当前明确列出的结果，服务端提交固定 ID 清单与选择数量，不能把模糊查询直接当成授权范围。
+
+### KTD7. 批量变更、撤权与 Agent
+
+所有配置走“草稿 → 差异及影响预览 → 提交确认 → 服务端重验 → 原子写入与审计回执”。
+预览绑定操作者、对象 ID、策略版本及 patch 摘要；它不能作为跳过提交授权的凭证。
+一批多个角色／成员的修改采用 expectedVersion／authorityEpoch 与事务，任一非法对象、越上限或冲突均不部分提交。
+跨 Backend 与 RDM 的一项业务变更不伪装成单库原子事务；按明确 owner 分开提交，显示实际状态和可恢复步骤。
+超时结果标为未知，以幂等键查询事务回执，避免重复授权或错误声称失败。
+
+权限 epoch 的权威落在存储和服务端判定；进程通知用于使缓存尽快失效，通知丢失不能继续使用旧授权。
+HTTP／检索／下载在输出边界检查当前权限；任务入队、恢复、使用资源和最终提交分别检查；持续流在新输出前重验并在撤权后终止受影响订阅。
+已经交付到客户端或既有模型上下文的内容无法追回，撤权会清除应用缓存并阻断后续读取、工具执行和结果披露；对含已撤数据的模型运行终止并重新构造上下文。
+
+UI、对话、Agent 工具共用权限目录查询、候选选择、解释、预览与提交 primitives。
+沿用公开命令总线，但明确声明工具投影和风险级别；管理写入经宿主的人类确认，模型不能确认自己的授权提案或签署三权。
+管理区发起的确认使用现有确认卡／弹层能力，并提供可发现的返回路径；不能只报“请到对话确认”而丢掉当前草稿。
+异步状态只由一个 store 管理，按 actor＋project＋对象版本＋request generation＋seq 丢弃过期响应，失败时清空对应旧能力。
+
+```mermaid
+sequenceDiagram
+  participant H as 人类管理者
+  participant UI as 单对象或矩阵视图
+  participant API as 公开授权服务
+  participant DB as 权威存储
+  H->>UI: 选择固定对象并修改草稿
+  UI->>API: 请求差异和影响预览
+  API->>DB: 读取当前版本与授权
+  API-->>UI: 返回具体变更和拒绝原因
+  H->>UI: 确认变更
+  UI->>API: patch 版本 幂等键
+  API->>DB: 重验并事务写入与审计
+  API-->>UI: 完成 冲突 拒绝或未知结果
+```
+
+### Compatibility and Migration
+
+迁移必须保持账号 owner／userId、roleId、projectId、createdBy、资源标识及历史签字身份。
+既有单角色绑定导入一个有效 binding；项目只选用该绑定，不自动加入新增角色。
+旧 profile 字段映射到可选资料；未知资料留空，不推断人员姓名或联系方式。
+现有两套管理员身份仅映射为明确的系统动作来源，不生成全项目业务 grant；旧 owner 的正文默认、停用回落与遗留越 cap 覆盖列为权限收缩差异。
+
+角色权威迁移采用版本化清单与冻结写窗口：导出带来源版本及摘要的角色／绑定／cap，导入 Backend 后核对数量、稳定 ID、逐项范围和所有引用，再切换消费者。
+禁止双主写入；过渡 RDM 旧管理命令转发新权威服务或明确只读，旧表只保留可核对历史。
+冻结期间不能取得一致快照时停止迁移，不做无事务的跨库复制。
+
+先在隔离副本执行迁移与双评估，输出用户×项目×动作的旧→新差异；双评估只用于记录，新算法上线时只有一个执行权威。
+扩权项必须有明确新授权；收缩项逐项列出原因和处理人，不能为消除差异恢复旧越权。
+生产迁移前完成备份及恢复演练、固定程序／配置／数据身份，按发布和迁移授权切换。
+回滚不得重新启用身份式业务全权或复活撤销记录；不能满足这一条件时进入维护／拒绝状态，先修复迁移或程序。
+账号恢复需修订既有账户方案的信任与交付合同，防止管理员拿一次性 Key 设密后接管业务身份；一次性本身不满足 R7。
+普通管理员仅发起恢复提案，账号本人须使用管理员不能单方改写或取得的既有有效会话确认或预先建立的本人恢复证明，才能取得可兑换设密能力。
+可选姓名、电话、邮箱和工号只是人员资料，不自动成为恢复证明；新证明的建立或更换不能由发起恢复的管理员单独完成。
+若没有独立本人验证条件，线上恢复拒绝，不向普通管理员交付可兑换的目标账户 Key；异常人工恢复采用另行批准的 owner 操作，不纳入普通角色管理权限。
+U1 冻结证明与交付合同，U3 消费已批准能力并验证该负例；既有恢复命令未收口前不能宣称 R7 完成。
+
+### Dependencies and Existing Work
+
+本方案衔接 [RDM 功能与实现整改方案](2026-10-12-rdm-function-implementation-plan.md)、[RDM 完整交付方案](2026-10-11-rdm-final-target-completion.md)、[两树一网追溯审计方案](2026-10-11-rdm-two-trees-trace-audit-integration.md) 与 [账户和登录 Key 方案](2026-10-12-svc-unified-deploy-and-login-key.md)。
+本轮管理员决定将修订前述审计方案的跨全部项目业务审计放行口径，以及权威 SR-G6 的“所有权限”表述；旧批准记录保留，新候选条款须按本方案评审和切换。
+账户方案中恢复 Key 可交付给签发者的既有口径同样需要按 R7 修订；对已有业务账号不能只保留短时设密限制。
+多职选择将修订 10-12 方案的首版单角色建议。
+U0 D2/D3/D5 的管理不代签、私域与冻结整文规则继续作为约束。
+
+现有 `feature/admin-notes-repair` 涉及管理样式与角色勾选同步；其他 RDM 工作区有审计／导出／pins 相关任务。
+这些仅依据本地任务记录和分支阅读，不代表本轮已经核验远端 PR 或 CI。
+实施启动时查询最新权威 base/head、实际公开契约、已合入内容和在途负责范围，复用有效改动，避免平行修改同一管理页面与审签引擎。
+基座公开扩展的实现、兼容验证及固定版本消费是 U4/U5 的依赖；发布版本仍由用户按高后果双钥匙执行。
+
+---
+
+## Implementation Units
+
+以下均为待批准工作项；U 编号带本方案名称使用，避免与其他方案的 U 编号混淆。
+文件范围以指定仓根目录为基准；标“新增”的文件为规划位置，实施可按项目模块规范调整。
+
+### U1. 冻结需求、权限目录与公开扩展合同
+
+目标：将本轮两项裁定和 R1–R20 落到权威需求、动作 scope、通用服务／领域规则边界及公开提供者／消费者合同。
+依赖：人工确认本方案需求与 KTD1；负责人为产品负责人和基座／RDM 模块 owner。
+文件：RDM `docs/requirements/01-用户需求与系统需求.md`、`03-产品设计方案.md`、`08-核心数据模型-两树一网.md`；Documents 相关方案与扩展申请；Backend `pkg/extension/extension.go` 合同草案。
+方法：冻结权限目录、敏感字段投影、系统管理恢复条件、账号本人恢复证明与凭据交付、项目创建与角色 cap 关系、公开版本兼容和旧命令映射。
+验证：文档差异与链接核对、动作×scope×配置主体表逐项评审；本单元不实施业务，也不制造业务测试 PASS。
+出口：阶段 1–5 对应产物和人工结论齐备，明确选择通用角色权威位置后才能进入其实施。
+
+### U2. 收口现有系统与项目越权路径
+
+目标：先修 R6–R12/R18 的当前路径，为后续迁移建立安全基线。
+依赖：U1 对动作与边界的批准；RDM 执行端 owner 负责。
+文件：RDM `internal/rdmapp/perms_api.go`、`runtime.go`、`upload.go`、`draftproposal.go`、`plugins/rdm/plugin.go`；测试扩展 `plugins/rdm/roles_test.go`、`draft_visibility_test.go`、`internal/rdmapp/perms_test.go`、`u1_auth_test.go`、`resource_authz_test.go`。
+方法：系统管理使用独立资格；清除自动业务 admin 放行；先验证角色动作存在和 cap，再考虑覆盖；停用不回落更宽默认；创建者走相同硬约束。
+执行方向：以当前源码触发方式先建立会失败的公开执行负例，避免仅测试新帮助函数。
+
+测试场景：
+
+- 普通角色获 project.settings 后，全局 cap、角色管理、admin 移交仍拒绝。
+- A 创建者改 B 的成员、权限、职责和归档均拒绝；矩阵解释一致。
+- 管理员未获 B 业务授权，正文／业务审计／原件／私人草稿／导出均拒绝。
+- 先设 allow 覆盖，再换到未配置该动作角色，当前执行与解释均拒绝。
+- 停用受限角色不新增权限；owner 遇 cap=false 同样拒绝；有效合法成员仍可执行原有合法动作。
+
+出口：直接 API／命令负例与正常回归闭合；不得宣称完整迁移或最终产品已验收。
+
+### U3. 基座账号资料、有效态与受控目录
+
+目标：实现 R3–R5/R11，提供真实人员查找而不复制账号。
+依赖：U1 目录及系统管理合同；Backend owner 负责。
+文件：Backend `internal/store/auth.go`、迁移、`internal/server/accounts.go`、`internal/app/hostcaps.go`、`pkg/extension/extension.go`；新增账号资料／有效态测试及扩展 `internal/app/account_lister_test.go`、服务器账户测试。
+方法：资料 CRUD 与停用有明确系统资格；目录查询按系统管理／项目选人／职责候选投影字段，分页稳定；停用同步终止会话与能力。
+
+测试场景：
+
+- 姓名电话邮箱工号均空成功建号；填写和清空资料不改身份。
+- 两名同名用户精确按 ID／登录名正确选定；模糊结果要求再次选择对象。
+- 项目选人未经联系方式权限不能按电话号码探测命中，不能批量导出完整目录。
+- 本人改备注不能改角色、管理员位或有效态；停用账号不能继续操作或作为三权候选。
+- 管理员持有 credential.recover 仍不能取得目标用户可兑换凭据或正常登录能力；无本人验证条件时恢复拒绝；管理员改可选资料不能改变恢复证明。
+- SQLite 与 PostgreSQL 的空值、格式、分页和并发版本冲突行为一致。
+
+出口：公开提供者／消费者契约验证及后台真实目录数据闭合。
+
+### U4. 通用职位、多职、默认与上限及原子批量服务
+
+目标：实现 R1/R2/R6/R10/R13/R15/R20。
+依赖：U1、U3、U2 安全基线；Backend 与 RDM owner 共同负责迁移窗口。
+文件：Backend 新增 `internal/authz/` 通用目录、角色、binding、版本与系统授权存储和测试；公开扩展与注册面；RDM `internal/perms/roles.go` 和 `perms_api.go` 兼容转发；新增 `internal/authz/roles_test.go`、`policy_batch_test.go` 和迁移测试；RDM `plugins/rdm/roles_test.go` 消费契约。
+方法：KTD1–KTD4/KTD7；保留 roleId；用户绑定多职；角色默认与上限范围成对校验；保护高权限任命与最后管理者；预览及提交均授权。
+
+测试场景：
+
+- 一个职位绑定两人，同一人绑定两个职位；编辑说明不影响用户／项目 ID。
+- 默认 grant 超 cap、未知动作、停用角色任命、无权编辑受保护项均拒绝。
+- 一角色有动作无目标范围，另一角色有目标范围无该动作，组合仍拒绝。
+- 批量里一对象非法或版本冲突，全部不写；同一幂等请求只生成一次变更及审计。
+- 旧单角色数据导入保持 ID／绑定，双主写入被阻断；失败迁移恢复不复活撤权。
+
+出口：角色与绑定只有一个权威来源，系统动作与新旧公开消费者结果一致。
+
+### U5. 项目角色选择、覆盖和统一资源读取
+
+目标：实现 R2/R7–R12/R14/R18/R19。
+依赖：U3/U4 与公开版本就位；RDM 项目 owner、Backend 资源接口 owner 配合。
+文件：RDM `internal/members/members.go`、`internal/projects/projects.go`、`internal/rdmapp/projects_api.go`、`perms_api.go`、`runtime.go`、`plugins/rdm/plugin.go`；Backend 项目 API、`internal/server/resource_authz_test.go`、`resource_authz_consumption_test.go`、`internal/app/resource_authz_v2_test.go`；RDM `member_guards_test.go`、`resource_authz_test.go`、`perms_test.go`。
+方法：加入和建项保存明确 binding；项目覆盖只操作本项目；资源策略消费完整 action/type/id/owner/project；列表、计数、检索、历史和导出均过滤；宿主项目和领域项目稳定绑定。
+
+测试场景：
+
+- 新增用户职位不改变已有项目；项目选择新增 binding 后才生效。
+- 解绑再重新任命不能自动恢复旧项目选择／旧覆盖。
+- 唯一负责人解绑后重新任命合格职位，可经受限入口由本人明确重选并恢复管理；普通管理员、前负责人或 cap 不足者不能代修复，也不能借此读资源或恢复旧 allow。
+- 项目明确 deny 在另一角色可 grant 时仍拒绝；allow 超所有可用 cap 拒绝。
+- 创建者可以管理本项目，不能读私聊或未分享原件；无管理资格建项不留下可使用半成品。
+- 篡改 projectId、资源 ID、owner 以及使用基座直连建项／下载／检索不能绕过域策略。
+- 策略提供者错误、缺失或权限通知丢失时拒绝；分页与数量不泄露被过滤对象。
+
+出口：HTTP／Host／命令／模型上下文的直接入口均有同一作用域和资源边界。
+
+### U6. 三权资格、冻结轮次及真实分配者审计
+
+目标：实现 R16/R17/R18，复用已有整文审签能力。
+依赖：U4/U5；RDM 文档模块 owner 负责。
+文件：RDM `internal/domain/review.go`、`internal/rdmapp/docsubmission.go`、`draft.go`、`plugins/rdm/plugin.go`；扩展 `write_duty_stage_test.go`、整文审签测试和职责候选测试。
+方法：统一分配服务检查有效账号、项目成员、选用职位、cap 与异人；审计记录真实操作者；轮次冻结与资格撤销处理按 KTD5。
+
+测试场景：
+
+- 跨项目、停用、非成员和 cap 不足候选拒绝；编制／审核／批准同人拒绝。
+- 多审核人未全部通过时批准拒绝；旧票不能签新正文。
+- 管理员／创建者未被指派不能代编、代审、代批；审核人能读提交正文但不能读取未分享原件。
+- 在途撤权或换职责使待处理轮次失效；历史已签版本和主体保留。
+- 分配者与受指派编制人不同，审计 actor 是真实分配者。
+
+出口：一份整文由真实三个职责完成与拒绝链，资格解释和执行一致。
+
+### U7. 用户、角色、项目权限与三权界面
+
+目标：实现 R4/R5/R13–R16，形成完整管理操作路径。
+依赖：U3–U6 相应服务合同稳定；Frontend／UI owner 负责。
+文件：Frontend `src/components/adminSections.tsx`、`adminRdmSections.tsx`、`AdminZone.tsx`、`rdmManagement.ts`、`api.ts`、`store.ts`；复用 `test/rdmroles-reject.test.ts`，新增角色矩阵／成员矩阵／目录与三权交互测试；沿用两个仓的 `design-guard.test.ts`。
+方法：KTD6/KTD7；先整合在途管理页面改动；消费服务端权限目录与 capabilities，共用草稿模型，选择稳定 ID。
+
+测试场景：
+
+- 单角色与矩阵产生等价 patch；过滤和翻页不丢草稿；全选范围与预览一致。
+- 姓名同名但登录名不同不误选；资料空值正确展示；无资格者看到明确拒绝原因。
+- 两窗口并发编辑返回冲突并保留草稿；等待确认／已完成／结果未知分开显示。
+- 快速切项目／角色／搜索词，迟到结果不能覆盖新目标；403 不被当成登录失效或永久加载。
+- 明暗主题、键盘导航、焦点、窄屏及广告过滤环境可用；令牌和折叠原语门禁成立。
+
+出口：真实用户通过既有页面完成建号／任命／项目选人／覆盖／三权，没有手填 ID 的必要主流程。
+
+### U8. Agent 同源工具、撤权与后台提交
+
+目标：实现 R12/R19，并验证 UI 与对话动作 parity。
+依赖：U4–U7；命令总线与运行时 owner 负责。
+文件：RDM `plugins/rdm/plugin.go` 工具声明和描述、任务资源使用／提交位置；Backend `internal/cmdbus/`、`internal/runmgr/`、公开策略集成测试；Frontend 卡片／Surface／能力 store 相关测试。
+方法：查询、解释、预览和提交用同一 primitives；对角色／项目／三权写操作使用宿主确认；任务恢复与新输出重验，终止含已撤数据的运行。
+
+测试场景：
+
+- 同一动作 UI／命令／工具的允许、拒绝、审计和对象一致，模型不能伪造 actor 或确认自己的提案。
+- 入队后撤权、恢复旧任务、确认旧卡、使用旧 Surface 均不能提交。
+- 已开 SSE／下载／检索遇撤权终止后续读取，权限通知丢失仍由当前存储判定拒绝。
+- 含已撤资料的模型上下文不被继续使用或披露，恢复从新授权上下文开始。
+- 真实模型能查询候选、解释权限和请求人确认；遇歧义人名停止在选人步骤。
+
+出口：mechanism 测试与适用真实模型任务级验证分别留证，不用 mock 代替模型验收。
+
+### U9. 迁移演练、精确组合及正式验收
+
+目标：闭合 R1–R20，交付单一权威的实际产品行为。
+依赖：U2–U8 完成对应评审；迁移、部署和运行测试各有明确授权；集成 owner 与用户验收人负责。
+文件：各仓迁移与验收记录；Dev task evidence、组合 pins 和功能规划；新增多账号权限端到端用例按仓内测试规范保存。
+方法：先隔离副本、SQLite／PG 同构迁移、差异审阅和恢复演练；固定 base/head/pins/config/data identity，再在授权环境执行真实账号验证。
+
+测试场景：
+
+- 至少两个独立项目；系统管理员、A 创建者、B 创建者、同职位两人、一人多职、两名审核人、批准人、普通成员和无关用户。
+- 完成资料／职位／系统能力／项目选择及覆盖／文档三权全过程，并逐项执行跨项目、换岗、停用、上限收紧与私域负例。
+- 重启后任命／覆盖／职责与撤销保持；两实例缓存失效、并发编辑和任务恢复一致。
+- 迁移 diff 无未经批准扩权；回滚保留撤权事实，不启用旧管理员业务旁路。
+- 实际浏览器由最终固定产物提供；系统角色变化、公开契约、模型工具、文档正文和审计结果同一对象。
+
+出口：用户正式验收、独立 Review、当前 HEAD 的权威 CI、合入及部署记录各自齐备；不能用其中一项替代其余。
+
+### Phased Delivery
+
+```mermaid
+flowchart TB
+  U1[U1 需求与公开合同评审] --> U2[U2 当前授权路径收口]
+  U1 --> U3[U3 用户资料与目录]
+  U2 --> U4[U4 统一职位与多职服务]
+  U3 --> U4
+  U4 --> U5[U5 项目与资源授权]
+  U5 --> U6[U6 三权资格与轮次]
+  U3 --> U7[U7 管理界面]
+  U4 --> U7
+  U5 --> U7
+  U6 --> U7
+  U7 --> U8[U8 Agent及撤权全链]
+  U8 --> U9[U9 迁移组合与正式验收]
+```
+
+建议分四个可验增量：I1=U1＋U2 的边界修正；I2=U3＋U4 的人员／职位与目录；I3=U5–U7 的项目、三权及配置体验；I4=U8＋U9 的全链和迁移验收。
+各增量遵循 policy/delivery.md 的需求、方案、实施、验收人工出口；阶段内可继续调查、自检与整改。
+既有公开契约只读、UI 单对象／矩阵模型设计可在依赖批准后并行；服务端迁移和同一页面写入按 owner 协调。
+实施工期在 U1 完成、实际在途任务及公开版本核定后估算，不把未验证的迁移规模写成日期承诺。
+
+---
+
+## Verification Contract
+
+以下是后续验证计划，本轮业务结果全部 NOT_RUN。
+
+| 层 | 验证内容 | 命令／环境与证据要求 |
+|---|---|---|
+| 文档 | 当前引用、需求追溯、两项裁定、规则一致性 | 文档 diff 与链接检查；SELF |
+| 账号与通用授权 | 正常／越权／停用／并发／多职／批量／迁移 | Backend 相关 Go 测试与合同测试；执行时固定 SHA |
+| RDM 领域 | 项目隔离、角色选用、范围、三权、私域和状态 | RDM 相关 Go 测试、公开 HTTP／命令集成；`make test` |
+| UI | 搜索、选择、两种矩阵、确认、冲突与拒旧 | Dev `make test-frontend`、`make test-ui`；固定组合实际浏览器 |
+| 产品组合 | 基座提供者／RDM 消费者／正式前端产物 | 各仓和 Dev `make test`、`make build`，核对实际 pins 与制品 |
+| 存储与恢复 | SQLite／PG 迁移、并发、重启与多实例撤权 | 隔离数据与授权运行环境；最小权限真实账号集 |
+| Agent | 查询／解释／确认／拒绝／恢复／资源使用 | 真实模型任务级测试；机制单测与模型结果分开 |
+| 正式交付 | 同步、测试、Review、CI、合入及部署 | 当前 base/head；precheck／task-sync／检查输出经 evidence；GATE 运行身份＋SHA 或独立 REPLAY |
+
+本地 evidence 为 SELF，不因标签或摘要提升可信级别。
+正式验收固定被测源码、组件 SHA、配置与数据身份；Reviewer 按最小重放集独立核验。
+未执行、跳过、零用例或源代码存在不能写为业务 PASS。
+文档保存只检查文档，不启动业务测试、数据库迁移或服务操作。
+
+---
+
+## Definition of Done
+
+本轮方案交付：本文包含当前差距、完整需求、明确模型与合成规则、界面方案、迁移与兼容、工作项／文件／测试／依赖和评审出口；两项用户决定有准确来源；主入口与任务卡可接续。
+完整功能交付：R1–R20 均能映射至实际实现及固定对象证据，所有必要正常、异常、边界和权限负例成立；用户正式验收后按仓库规则完成独立 Review、当前 CI 与组合核验。
+
+启动实施前需完成的评审选择：KTD1 通用职位权威迁移、创建者管理与角色 cap 的耦合和本人重选规则、受控目录可披露字段、账号本人恢复证明及交付合同，以及生产迁移／切换范围。
+这些是当前草案中已给推荐方案但尚未批准的设计选择，不影响本轮方案交付，不授权实施者自行替换路线。
+实施时再确定的细节：表名／迁移编号、最终 package 位置、目录分页与搜索索引阈值、通知实现和隔离环境，不改变上述产品边界。
+
+停止条件：范围或需求改变；必要公开契约不兼容；角色数据无法取得一致快照；发现未批准扩权；实际制品／数据身份不明；在途任务 owner 冲突；越出迁移／部署授权。
+发生时保存当前证据与现场，返回受影响方案或计划评审，不能放宽授权继续。
+
+推荐下一步为评审 U1 和 I1，先批准本次权限边界与公开合同，再实施已有可达授权路径的收口。
+这项建议不自动启动业务任务；完整用户资料与矩阵设计已有后续依赖和验收，不会在首批完成后遗漏。
@@ -0,0 +1,336 @@
+# 最终验证与合入调度 Implementation Plan r1
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use `executing-plans` for native execution or `subagent-driven-development` when that method is selected. Read the specification and this plan; implement and verify one work item at a time. Checkboxes describe required steps; current progress and fixed objects are recorded in the Dev task card.
+
+**Goal:** 减少多个就绪分支因其他正常合入而反复同步、解决冲突和重跑最终 CI，同时保证实际合入候选通过既有检查。
+
+**Architecture:** 开发并行；同一目标由一个明确协调者安排最终同步至合入核验的串行窗口。首版使用源码外 Gitea 调度 Issue、幂等同步和分级恢复入口；保留现有 workflow 及平台准入，不建设自动调度 daemon。
+
+**Tech Stack:** 现有 Bash/Git 任务脚本、Python 标准库 evidence 工具、Makefile、unittest 临时真实仓库夹具、Gitea PR/Actions。
+
+**Spec:** Agent-System-Dev `policy/merge-queue.md` r1（本地来源提交 `913b214f2826a50b3dab65f79d9ebf83e84f2519`）；Development-Guidelines `standards/merge-queue.md` 与 `templates/merge-queue.md`（本地候选提交 `606f21db99b971aae82c2348a9b7959e6aa2060c`，draft.11）。两项来源尚未推送/合入，不生成不可访问的远端源码链接。
+
+**Status:** approved（阶段 5）；编制日期 2026-10-13（Asia/Shanghai）；负责人 weichen。用户在本计划 r1@ba4044d57e38d0887dd425d052abf26b20a28bf4 交付后回复「批准」，按推荐的原生方式实施。源码与自检已在 Dev 任务分支推进，证据和当前对象以任务卡为准；平台所有者操作及真实三任务 CI 试行 NOT_RUN。
+
+**Document baseline:** Documents `origin/main=5a06acf7cded07797ec4ebfea42c89331359b0bb`。本计划正文只维护于 Documents；任务进度、命令证据和批准依据仍以 Dev 任务卡为准。
+
+## Global Constraints
+
+- 共同起点及最终交付实际同步最新目标保留；正式验收、审核、合入仍分别核验新鲜度与候选身份。
+- 一个目标最多一个交付窗口，覆盖最终同步、正式验证、必要复审、合入及真实内容核对。
+- 队列更新、CI 链接和候选固定后的本地收据位于被测源码之外；不能向 main 提交调度心跳或状态。
+- 当前 HEAD 的全部必需 CI 必须实际通过；不复制旧绿色状态，不把跳过必需作业当通过。
+- 人工阶段结论、独立 Review、SELF/REPLAY/GATE 的身份边界不变。入队与领取不是批准或新的工作授权。
+- 修改治理脚本必须执行 `make test-governance`；跨仓指针推进前执行 Dev `make test`，最终精确 HEAD 的平台 CI 另核验。
+- 首版人工预算沿用规格：无进展 20 分钟、窗口 90 分钟、已知基础设施失败最多额外重试一次、等待队列每 30 分钟复查。实际 runner 容量及长期预算在试行前核验。
+- 分支保护变更由 Agent 准备、用户确认并亲手执行；本计划不授权绕过保护、改写历史或发布版本。
+- 不隐式 stash/reset/强推，不覆盖组件 feature 分支，不丢失现有收据或他人现场。
+
+## Review Focus
+
+1. 同步已经完成，但为记录再创建提交：U1 对有任务卡的真实仓库重复调用，断言 HEAD、索引和卡片不变。
+2. LOCAL_READY 被当作可启动新任务或可合入：U2 覆盖启动拒绝、严格恢复拒绝、未知远端及脏现场继续阻断。
+3. evidence 写回任务卡后才确认候选，或最终 SHA 仍指向记录提交之前：U1 核对输出真实 HEAD，U3 对源码外收据流程核对前后身份。
+4. 队列 Issue 被误认为互斥锁，或失联协调者被盲目接管：U4/U6 分别检查 manual 登记、旧执行者退出确认和未知结果对账。
+5. 分支 CI 绿色但其语义组合、组件或平台必需检查无效：U4/U5/U6 覆盖外部推进、组件版本不回退、精确对象与真实拒绝路径。
+
+## 1. 范围、决策及来源核对
+
+### 本增量
+
+U1–U3 为可在隔离仓库验证的任务与证据改进；U4 将已批准条文和实际能力接到交付入口；
+U5 准备并验证平台准入条件；U6 在已授权真实任务上试行。实施顺序固定 U1 → U2 → U3 → U4 → U5 → U6。
+三个源码单元完成后可先提交实施产物供阶段 6 评审；模式切换需 U4/U5 条件齐备，不能把脚本通过当线上启用。
+
+首版不修改 `.gitea/workflows/ci.yaml` 的触发、必需作业或检查上下文。节省重复最终 CI 的方法是：
+其他就绪分支不因 main 前进推送同步提交；当前窗口分支完成所有必要记录后只推送固定最终候选。
+现有开发提交仍可能运行完整 CI，首版不声称已自动区分轻重检查或能抢占 runner。
+后续 workflow 分流、自动原子领取和执行端 fencing 单独立项，不能为完成本计划顺手建设。
+
+### 已确定的选择
+
+| 决策 | 采用方式与理由 |
+|---|---|
+| 调度方式 | 人工首版：一份共享 Issue、一个协调者；与已批准规格一致，先控制实际推进顺序 |
+| 同步方式 | 保留 merge 历史；只有目标尚未包含时发生同步写入，同基线节点只核验 |
+| 启动/恢复 | 新任务和默认交付模式仍严格；仅既有合法任务可以显式选择局部恢复 |
+| 收据格式 | 本增量保留 schema 1 及原始校验和；局部模式由真实 precheck 输出及验证用途区分，不随意添加 snapshot 字段 |
+| 固定后证据 | 使用已有 RECEIPT 捕获模式，不增加冻结数据库或签名协议；manual 流程每个节点核对实际对象 |
+| 独立审核 | 建议原生逐项实施，末尾按现有交付规范安排独立 Review；编制时仅为计划，尚未启动审阅/实施代理 |
+
+### 编制时实现基线（源码观察 SELF）
+
+| 路径/符号 | 本次确认的行为 | 对计划的约束 |
+|---|---|---|
+| Dev `scripts/task.sh:cmd_sync` | 先获取目标并检查/物化组件；有任务卡时每次追加记录并提交；输出 head 在记录提交前取值 | U1 必须消除无变更提交，并输出记录完成后的 HEAD |
+| Dev `scripts/task.sh:cmd_precheck` | 远端失败为 REMOTE_UNVERIFIED；脏现场为 SHARED_WORKSPACE_BUSY；落后为 SYNC_REQUIRED | U2 不整体改成 READY，保持默认严格 |
+| Dev `scripts/evidence.py:validate_precheck` | 只接受真实 precheck 命令、READY、成功及固定源/目标；用于 task-start | 新任务不能消费局部恢复收据 |
+| Dev `scripts/evidence.py:read_receipt/validate_snapshot` | schema 1 和 snapshot 字段集合严格校验，允许可选 capture_note | 无必要不改 wire schema；历史收据不重写 |
+| Dev `scripts/evidence.py:main/write_receipt` | RECEIPT 模式已存在，绝对未用路径、0600、完整输出、before/after；默认模式写任务卡 | U3 复用能力，最终窗口明确选择源码外路径 |
+| Dev `scripts/zcode/write_guard.py:check_location` | 检查目标实际仓库及分支，未读取 precheck 收据或判断目标落后 | 不把当前守卫描述为阶段/新鲜度强制闸；保留分支检查与负例 |
+| Dev `.gitea/workflows/ci.yaml` | PR/main push 触发 test、test-pg、svc-realcombo；checkout 核对固定 SHA 与仓库 allowlist | 不凭 queue label 跳过检查；不能直接复制此 workflow 到临时仓当作合法等价 CI |
+
+以上为编制时源码观察；当前能力与执行进展见任务主记录及固定候选的 PR/源码外收据。源码单元实施前再次读取实际符号，记录新的 base/head；行号变动不改变接口选择。
+平台配置、runner 容量和在途任务用当场记录核验，不复用旧观察作当前准入证明。
+
+## 2. 公共入口与兼容约定
+
+以下是本计划拟新增或调整的接口；编制时均未声明已实现，当前状态以任务主记录及其固定候选证据为准。
+
+| 入口 | 默认/输入 | 结果及兼容 |
+|---|---|---|
+| `make task-sync` | 正常严格同步；来源仍为权威 origin/目标 | 保留 `[synced]`；完整 sync_base、最终 tested_head、checked_at，追加 changed=0/1；未变不提交卡片 |
+| `make precheck` | `TASK_WORK_MODE=delivery` 默认；可显式 local | delivery 保留 READY/SYNC_REQUIRED；local 仅既有登记任务输出 LOCAL_READY，不称可合入 |
+| `make task-resume PRECHECK_RECEIPT=...` | 复用登记任务；TASK_WORK_MODE 与 precheck 一致 | 验证相应用途的原始收据后原样导入，不建分支、不后台同步 |
+| `make task-start` | 始终用途 start、严格 READY | 无视外部试图选择局部验证用途的参数；LOCAL_READY 必须拒绝 |
+| `VALIDATE_RECEIPT_PURPOSE` | evidence 内部验证用途；默认 start | start、resume-delivery、resume-local 三值；未知值拒绝，两个任务入口显式设置用途 |
+| `RECEIPT=... CMD=... make evidence` | 既有捕获接口 | 保留 schema 1、原命令状态、完整脱敏输出及来源 SELF；固定候选期间路径在当前 checkout 与 Git 元数据之外 |
+
+`LOCAL_READY` 是局部工作的检查结果，不能提升为交付准入。旧的 schema 1 收据和 READY 输出继续可读。
+`VALIDATE_RECEIPT_PURPOSE` 不传给被测命令子进程，避免改变测试环境；不能由它改变来源等级。
+
+## 3. 工作项
+
+### U1：同步幂等化及最终对象输出（R1/R2，MQ3/MQ4）
+
+**Files（Dev 仓）：** Modify `scripts/task.sh`；Test `tests/test_task.py`；对应说明在 U4 同步。
+
+**Interfaces:** 消费 `fetch_target`、`check_worktree` 和原任务卡；产出第 2 节的 `[synced]` 协议。
+
+- [ ] 在现有 `TaskLifecycleTests` 中补有任务卡的夹具。使用已有 `self.git/self.worktree`，记录实际 R0，不创建假测试证据：
+
+```python
+def record_task_card(self, wt):
+    branch = self.git(wt, "branch", "--show-current").stdout.strip()
+    r0 = self.git(wt, "rev-parse", "origin/main").stdout.strip()
+    card = wt / ".task" / (branch.replace("/", "-") + ".md")
+    card.parent.mkdir(exist_ok=True)
+    card.write_text(
+        f"# {branch}\n状态：进行中；owner：Lifecycle Test\n"
+        f"- 权威仓：fixture；目标分支：main；R0（initial_base_sha）= {r0}\n"
+        f"- 工作区：{wt}（worktree）；分支：{branch}\n"
+    )
+    self.git(wt, "add", str(card.relative_to(wt)))
+    self.git(wt, "commit", "-m", "Record fixture task")
+    return card
+
+def test_sync_same_base_preserves_head_and_card(self):
+    wt = self.worktree()
+    card = self.record_task_card(wt)
+    head = self.git(wt, "rev-parse", "HEAD").stdout.strip()
+    content = card.read_bytes()
+    for _ in range(2):
+        result = self.task(wt, "sync")
+        self.assertEqual(self.git(wt, "rev-parse", "HEAD").stdout.strip(), head)
+        self.assertEqual(card.read_bytes(), content)
+        self.assertEqual(self.git(wt, "status", "--porcelain").stdout, "")
+        self.assertIn("changed=0", result.stdout)
+        self.assertIn(f"tested_head={head}", result.stdout)
+```
+
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_task.py' -k sync -v`，确认当前无变更提交行为导致新例失败，再改实现。
+- [ ] 同步前检查父仓未保存内容和活动操作；脏父仓/子仓拒绝，不自动 stash。成功 fetch 后区分祖先检查的 0、1 和其他错误。
+- [ ] 已包含目标时仍核对/物化必要组件，未变则不追加卡片、不提交；未包含时保留 merge、冲突处置和一次必要记录。记录提交完成后再读取最终 HEAD 输出。
+- [ ] 补新增目标成功纳入、重复调用保持 HEAD/索引/卡片、输出等于实际最终 HEAD、脏父仓/子仓/离线拒绝、组件 feature 分支保留和冲突不误报成功的测试。复用原组件夹具和已存在负例。
+- [ ] 重跑上述直接检查，输出经 evidence 保存；按本仓四段提交格式保存此单元，不捎带其他任务文件。
+
+### U2：既有任务局部恢复与严格准入分开（R1/R5，MQ4）
+
+**Files（Dev 仓）：** Modify `scripts/task.sh`、`scripts/evidence.py`、`Makefile`；Test `tests/test_task.py`、`tests/test_evidence.py`、`tests/test_write_guard.py`；独立恢复集成场景放 `tests/test_task_recovery.py`，复用原真实 Git 夹具。
+`scripts/zcode/write_guard.py` 的现有分支级规则保留；无已证实兼容问题时不改它。
+
+**Interfaces:** 使用 TASK_WORK_MODE 和第 2 节验证用途；`task-resume` 验证后复用 IMPORT_RECEIPT，不建立新工作区。
+
+- [ ] 先补局部模式与默认严格模式的对照测试：
+
+```python
+def test_local_precheck_allows_existing_clean_task_behind_target(self):
+    wt = self.worktree()
+    self.record_task_card(wt)
+    head = self.git(wt, "rev-parse", "HEAD").stdout.strip()
+    self.advance_remote()
+    strict = self.task(wt, "precheck", check=False)
+    self.assertNotEqual(strict.returncode, 0)
+    self.assertIn("SYNC_REQUIRED", strict.stdout)
+    local = self.task(wt, "precheck", check=False,
+                      env=self.env | {"TASK_WORK_MODE": "local"})
+    self.assertEqual(local.returncode, 0, local.stdout)
+    self.assertIn("[verdict] LOCAL_READY", local.stdout)
+    self.assertEqual(self.git(wt, "rev-parse", "HEAD").stdout.strip(), head)
+```
+
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_task.py' -k precheck -v`，确认新例失败。新任务入口仍消费严格收据。
+- [ ] local 只允许登记的合法任务 worktree/分支/任务卡，原 R0 必须仍是当前任务及权威目标的祖先；无卡、集成分支、错误归属、异常历史均拒绝。允许已知落后，不允许脏现场、活动操作、组件漂移、远端未知。
+- [ ] `validate_precheck` 增加用途参数，由任务入口显式选择。保留命令、原始输出、源 HEAD、common_dir 等校验；start/resume-delivery 仍要求严格 READY 与当前目标一致。
+- [ ] 测试夹具显式清理 TASK_WORK_MODE/VALIDATE_RECEIPT_PURPOSE，再由目标用例注入，避免开发终端环境污染默认严格模式的测试。
+- [ ] resume-local 接受实际 LOCAL_READY；收到同一来源任务的历史观察后重新 fetch 核对当前目标及 R0，目标正常前进不要求改写原收据或同步分支。读取失败、源 HEAD 变更或 R0 不适用拒绝，两个观察的来源与对象分别记录。
+- [ ] 补 LOCAL_READY 不能 task-start、不能严格恢复、用途未知拒绝、伪造任意命令拒绝、收据串仓/损坏拒绝、旧 READY 兼容、局部恢复不改 HEAD、已知目标前进与异常历史的对照。写守卫原有 main/detached/软链接拒绝测试继续通过，不宣称它已校验阶段批准。
+- [ ] 执行上述 precheck 检查及 `test_evidence.py`、`test_write_guard.py` 的 unittest discover；记录实际输出后提交此单元。
+
+### U3：候选固定前后使用不同证据保存位置（R2/R3，MQ3/MQ4）
+
+**Files（Dev 仓）：** Modify `policy/governance.md` 的证据流程；Test `tests/test_evidence.py`；同步任务卡模板说明于 U4。
+现有 `scripts/evidence.py` 的捕获/导入协议复用；本单元不改 schema，也不增加冻结状态库。
+
+**Interfaces:** RECEIPT 捕获、IMPORT_RECEIPT 导入、真实 snapshot；只有源码外记录满足固定后的流程。
+
+- [ ] 用已有 `tests/test_evidence.py` 的真实仓库夹具补完整使用流程：捕获到仓外唯一路径，断言卡片字节、HEAD、索引不变，校验原始命令输出、before/after 和 0600；重复目标拒绝，旧收据原样导入且幂等。
+
+以下用例放入既有 `EvidenceTests`，复用已核对的 `self.git/self.capture/self.card/self.receipt`：
+
+```python
+def test_fixed_candidate_capture_preserves_checkout(self):
+    self.git("add", ".task/main.md")
+    self.git("commit", "-qm", "Save fixture card before validation")
+    head = self.git("rev-parse", "HEAD")
+    card = self.card.read_bytes()
+    index = self.git("ls-files", "--stage")
+    data = self.capture("printf 'fixed candidate check\\n'")
+    self.assertEqual(data["before"]["head"], head)
+    self.assertEqual(data["after"]["head"], head)
+    self.assertEqual(data["output"], "fixed candidate check\n")
+    self.assertEqual(self.git("rev-parse", "HEAD"), head)
+    self.assertEqual(self.git("ls-files", "--stage"), index)
+    self.assertEqual(self.card.read_bytes(), card)
+    self.assertEqual(self.git("status", "--porcelain"), "")
+    self.assertEqual(self.receipt.stat().st_mode & 0o777, 0o600)
+```
+
+- [ ] 这项是既有能力的流程回归，允许先通过，不伪造“新增机制失败”结果。执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_evidence.py' -v`。
+- [ ] 固定前流程：同步 → 所有必要本地检查及任务卡收据 → 保存/提交卡片 → 核对干净组合 → 读取最终 HEAD → 推送并记录当前 CI 对象。
+- [ ] 固定后流程使用以下既有接口，候选 SHA/组件/相关配置由调度尝试引用；路径须位于 checkout 和 Git 元数据之外：
+
+```bash
+RECEIPT=/tmp/mq-attempt-unique-check.json CMD="make test-worktree" make evidence
+```
+
+每个调用使用新的未占用路径，例中 unique 由执行者替换为该次尝试唯一名称。命令期间若对象变了，保留实际新旧对象和输出，不作为固定候选通过依据，返回 preparing 或退出整改。
+- [ ] 未通过必要检查、未保存内容或新增提交时建立新尝试；既有最终 CI 不能沿用。合入/清理之后再按既有授权闭合，原始收据不能补写成预期输出。
+- [ ] 文档与直接回归记录保存后提交；能力矩阵将此登记为 manual 流程＋现有工具捕获能力，不宣称 OS 级冻结保护。
+
+### U4：将窗口接到实际交付规则及单一记录（R1–R5，MQ1/MQ2/MQ5/MQ6）
+
+**Files：** Guidelines 已有 draft.11 候选；Dev Modify `AGENTS.md`、`PROJECT.md`、`policy/delivery.md`、`policy/governance.md`、`policy/merge-queue.md`、`policy/adoption.md`、`policy/tool-adaptation-matrix.md`、`scripts/task.sh` 的任务卡模板；Test `tests/test_task.py` 的模板行为；Documents 保留本计划及索引。
+
+**Interfaces:** 通用正文固定 SHA＋项目采纳记录；一份实际平台调度 Issue；原任务卡只引用 entry_id/attempt_id。
+
+- [ ] 按既有规范完成 Guidelines 文档 Review 与 PR 交付；Dev 采纳实际合入的完整 SHA，不能直接引用本地候选提交作为远端已交付事实。父仓指针正式推进前完成组合 `make test`。
+- [ ] 根入口只路由到权威条文，修改 AGENTS.md 前应用 writing-for-agents；阶段 7–9 的核验职责不删，改为同一窗口内对象未变只核验。U1–U3 的入口和恢复语义同步到采纳记录、模板与矩阵。
+- [ ] 文档先记录 approved/pending-activation；只在 U5 准入条件满足、协调者和记录建立后切换 active。源码改进可先交付，不由指针更新或本地测试替代上线切换。
+- [ ] 在已获该动作授权的实施阶段建立一份 Gitea 调度 Issue，复制通用模板，填写实际协调者、目标、现有写入者清单、CI 预算与接管者；没有协调者则不开放领取。
+- [ ] 所有正常合入者、闭合 PR、机器人和紧急通道按记录安排。manual 状态由协调者串行修改；Issue 无原子领取能力，不能用编辑成功证明互斥。窗口失联先对账，确认旧执行者停止后交接。
+- [ ] CI 首版按可用资源和实际运行状态安排当前最终候选，不自动取消其他任务、改 runner 配置或建立定时自动化；30 分钟复查由协调者负责。
+- [ ] 模板核对必含记录位置、entry_id、attempt_id、固定对象及实际结果引用。治理脚本/模板变更完成后执行 `CMD="make test-governance" make evidence`，正式交付另核验精确对象的全部 CI。
+
+### U5：平台条件准备及所有者验证（R3/R5，MQ4/MQ8）
+
+**Files（Dev 仓）：** Modify `policy/platform-admission.md`、`policy/tool-adaptation-matrix.md`；必要事实更新经当场验证写 `policy/facts.md`。
+
+**Interfaces:** 现有 Gitea 分支保护、PR head 状态/运行、所有者亲手执行；不新增本地合入权威。
+
+- [ ] 当场读取当前 main、保护配置、合法固定 PR 的状态上下文及运行身份；输出经 evidence 脱敏保存。旧 SELF 观察仅作定位。
+- [ ] 准备保留禁直推与陈旧候选保护、要求实际全部必需 PR 检查的具体配置和恢复步骤；从当次状态确认完整名称，不只保留历史 test 上下文。批准数和身份策略不随本计划擅自调整。
+- [ ] 与所有者确认隔离验证对象与影响范围；Agent 不自行变更分支保护。用户亲手执行后，取得缺检查、失败检查、陈旧候选、无权推进被拒及合法候选可合入的实际结果。
+- [ ] 临时平台仓可验证保护机制，但其 fixture CI 不能宣称覆盖 Dev 的完整业务组合。现有 Dev workflow 有仓库 allowlist，不修改 allowlist/凭据范围来让临时仓冒充 Dev；Dev 精确 HEAD 的实际 CI 另核验。
+- [ ] 已知无法验证的能力标 NOT_RUN/manual；原子准入条件未满足时不切换新模式。自动接管的旧代次拒绝不是人工首版的通过断言，留待后续执行端实现。
+- [ ] 回填真实对象、身份、运行/拒绝链接及 GATE/REPLAY；仅 API 配置成功仍为观察，不标 enforced。
+
+### U6：三个真实任务的受控试行与复盘（R1–R5，MQ1–MQ8）
+
+**Files：** Dev 创建 `tests/test_merge_queue_trial.py`（仅本地临时仓库场景）；Documents 试行后创建 `docs/records/2026-10-13-merge-queue-trial.md`，实际日期不同则用真实日期；状态仍以各任务/调度记录为准。
+
+**Interfaces:** U1–U5 的命令、调度记录和平台入口；不同目标/跨仓依赖使用已有任务授权，不新建业务需求。
+
+- [ ] 隔离真实 Git 夹具覆盖 A/B/C 共同 R0，按窗口顺序最终同步、检查、合入；断言每条目第一次最终同步后重复核验不产生提交，后继不被要求提前同步。该测试的执行次数不冒充真实 Actions CI 次数。
+
+新文件复用已有夹具对象，不继承整套 TestCase，避免旧测试被重复发现。下面固定正常路径；故障用例在同一类内复用该夹具：
+
+```python
+import unittest
+import test_task as lifecycle
+
+class QueueTrialTests(unittest.TestCase):
+    def setUp(self):
+        self.fixture = lifecycle.TaskLifecycleTests(methodName="runTest")
+        self.fixture.setUp()
+        self.addCleanup(self.fixture.doCleanups)
+
+    def test_sequential_delivery_does_not_sync_waiting_branches(self):
+        f = self.fixture
+        branches = ["feature/a", "feature/b", "feature/c"]
+        worktrees = {}
+        waiting_heads = {}
+        for branch in branches:
+            wt = f.root / branch.replace("/", "-")
+            f.git(f.repo, "worktree", "add", "-b", branch, str(wt), "origin/main")
+            f.record_task_card(wt)
+            name = branch.split("/")[1]
+            (wt / name).write_text(name + "\n")
+            f.git(wt, "add", name)
+            f.git(wt, "commit", "-m", "Add independent fixture change")
+            worktrees[branch] = wt
+            waiting_heads[branch] = f.git(wt, "rev-parse", "HEAD").stdout
+        f.advance_remote()
+        for position, branch in enumerate(branches):
+            wt = worktrees[branch]
+            f.task(wt, "sync")
+            candidate = f.git(wt, "rev-parse", "HEAD").stdout
+            f.task(wt, "sync")
+            self.assertEqual(f.git(wt, "rev-parse", "HEAD").stdout, candidate)
+            self.assertEqual(f.git(wt, "status", "--porcelain").stdout, "")
+            f.git(f.repo, "merge", "--no-ff", branch, "-m", "Merge fixture candidate")
+            f.git(f.repo, "push", "origin", "main")
+            for waiting in branches[position + 1:]:
+                self.assertEqual(f.git(worktrees[waiting], "rev-parse", "HEAD").stdout,
+                                 waiting_heads[waiting])
+```
+
+- [ ] 注入冲突、已知失败、紧急插队、目标外部推进、依赖未满足和未知合入结果，核对允许继续的健康对照；不同目标互不阻塞，组件组合不回退。
+
+本地自动用例证明 Git/脚本行为；Issue 状态、失联交接及平台结果未知的处置由受控操作清单和实际对账记录验证，不因本地测试通过而宣称人工流程已自动互斥。
+- [ ] 执行 `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -p 'test_merge_queue_trial.py' -v` 和 `make test-governance`；回归实际 stdout/对象，不制造 GATE 标签。
+- [ ] U5 条件满足且用户批准试行后，由协调者选择三个已经获实施/合入授权且就绪的真实任务；不足三个时保留待试行，不为凑数生成生产 PR，也不干预未纳入的任务。
+- [ ] 记录每个尝试的实际最终同步次数、全部 CI 尝试/运行耗时、因目标移动废弃的运行、等待时长、恢复次数及真实结果。区分开发 CI、最终 CI 和 main 合入后 CI，不能只统计省下的一类。
+- [ ] 正常顺序交付的验收目标是没有因其他正常排队任务的合入而废弃最终 CI；整改、插队等另计。无可比历史数据时只报告本次观察，不给节省百分比。
+- [ ] 人工评审试行结果后决定继续/调整/回退。回退先停止领取、对账活动合入，再恢复旧流程；保留全部记录，不删除未知结果历史。
+
+## 4. 验证、交付与停止条件
+
+| 对象 | 最小验证 | 结果权威 |
+|---|---|---|
+| U1 | 有卡片的重复同步、新目标、真实最终 SHA、父子仓/网络/冲突保护 | 本地 SELF；正式交付补对应 GATE/REPLAY |
+| U2 | 严格/局部对照、启动/恢复用途、历史收据、分支守卫负例 | 同上 |
+| U3 | 原始仓外捕获、固定身份、原样导入、无重复写入 | 同上；不把流程约定标工具冻结 |
+| U4 | 权威条文、采纳、模板、全部写者/协调者安排及 make test-governance | 规范批准与命令证据分别记录 |
+| U5 | 实际缺检查/失败/陈旧/无权拒绝及合法路径 | 固定对象的 GATE/REPLAY，配置观察不替代 |
+| U6 | 临时真实 Git 故障/健康对照＋真实三任务与全部 CI 成本 | 临时测试 SELF，实际平台运行 GATE，人工验收另记 |
+
+每个源码单元只提交其拥有文件。所有完成声明保留 precheck、task-sync 与直接相关检查的工具收据；
+新对象需重新判断结论，固定后收据位于源码之外。验收、Review、合入分别遵循当时仍有效的门禁，不抢先使用未启用的新语义。
+Docs、Guidelines、Dev 各仓 PR 和实际合入 SHA 分别核验；文档计划合入不授权执行所有者操作或启动业务试行。
+
+停止条件：需求/契约或优先顺序变化，原 R0 不再适用，现场归属不明，当前平台/CI 身份无法核验，
+用户批准缺失，或实际合入结果未知。只暂停受影响范围；符合授权的其他局部工作继续。
+
+## 5. 自审与完成定义
+
+| 规格要求 | 计划覆盖 |
+|---|---|
+| 调度对象、记录和共同基线 | U2/U4/U6 |
+| 最终同步至核验串行窗口 | U1/U4/U6 |
+| 源码外证据及真实候选 | U1/U3/U5 |
+| CI 分配、去重与结果适用性 | U4/U5/U6；首版明确现有 workflow 不分流 |
+| 依赖、插队、失败与恢复 | U4/U6；自动接管明确不在首版 |
+| 采纳、能力登记与回退 | U4/U5/U6 |
+
+计划通过评审后，U1–U3 可以开始隔离实施；U4–U6 依前置条件推进。
+源码已实现、规范已采纳、平台已核验、模式已切换、三任务试行通过分别记录，不用一个“完成”代替。
+计划编制时源码与平台试验均 NOT_RUN；编制检查仅覆盖计划来源、路径、链接、状态和需求覆盖。
+
+实施续办：U1–U3 在 Dev 任务分支实现并保留实际验证收据；U4 的规则/模板和待启用 Issue #518 已准备；
+U5 仅完成只读观察、配置与恢复材料；U6 临时真实 Git 场景已运行，真实 CI/业务试行仍待 U5 和相应批准。
+当前源码/自检不从历史计划推断，统一回链
+Dev `.task/feature-merge-queue-policy-draft.md` 的完整对象与原始输出。
+
+建议采用原生逐项实施：三个源码单元紧密依赖同一套任务/evidence 接口，由一个写者修改更易保持兼容。
+实施产物和计划仍需既有人工阶段评审；最终代码 Review 按仓库职责安排独立审阅，不由作者自签。
@@ -0,0 +1,243 @@
+---
+title: RDM 设置归属、成员、文档职责与权限矩阵完善增量方案
+date: 2026-10-13
+type: feature
+execution: code
+artifact_contract: rdm-increment-plan/v1
+product_contract_source: legacy-requirements
+---
+
+# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1
+
+负责人：weichen；编制：ZCode；核对日期：2026-10-13（北京时间）。
+上游方案：[2026-10-12 RDM 功能、实现与计划矩阵及整改方案](2026-10-12-rdm-function-implementation-plan.md)（下称"总案"），本增量承接其本稿 U3、U4、U6，涉及职责一致性的部分衔接 U5。
+
+评审状态：2026-10-13 用户评审通过（同意方案及技术评审意见），并授权按本方案实施（P1–P8 两批推进；正式验收与清理回收节点保留人工确认）。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。
+
+## Goal Capsule
+
+以现有 RDM 实施总案的一个完整增量，先厘清设置归属和服务端权限，再补齐搜索、选择、职责分配与权限矩阵交互，保证界面显示、保存结果和实际执行一致。终点：创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存，且服务端边界（受管设置、成员校验、原子职责变更、权限范围）全部经真实请求验证。
+
+非目标：不扩展飞书集成、组织架构、多角色叠加或全量文档生成工程。
+
+## 一、当前实现与需要补齐的内容
+
+| 方面 | 当前源码情况 | 本次需要完成 |
+|---|---|---|
+| 设置归属 | 项目设置展示完整 schema；用户、项目设置都能覆盖模型等配置 | 设置作用域、管理员系统设置入口、写入与最终生效值双重约束 |
+| 成员管理 | 手填账号；已有分页账号目录，但只有账号和有效态 | 账号／姓名搜索、提示选择、下拉浏览、专业角色过滤、明确的项目身份修改 |
+| 文档职责 | 手填文档 ID 和人员账号；主要读取提交快照 | 文档搜索／列表／树选择、当前职责回填、项目成员选择、提交校验 |
+| 权限查看 | 已有单成员权限解释表 | 单成员详情与多人矩阵、中文标签、项目动作范围、上限内配置 |
+| 一致性 | 存在职责目标未校验成员、职责更新与审签失效分步执行等缺口 | 服务端统一校验、原子变更、版本冲突、撤权及历史保全 |
+
+对应实现锚点：Frontend `src/components/ProjectSettingsModal.tsx`、`src/components/adminRdmSections.tsx`；Backend `internal/settings/settings.go`（覆盖链 `defaults → system → user → project`）；RDM `plugins/rdm/plugin.go`、`internal/perms/perms.go`、`internal/rdmapp/docsubmission.go`。
+
+## 二、设置归属与界面结构
+
+沿用现有设置入口和 `SettingsShell`，项目设置收敛为四个页面：
+
+| 页面 | 内容 |
+|---|---|
+| 项目设置 | 真正属于本项目的共享配置与协作规则 |
+| 项目成员 | 成员搜索、添加、项目身份调整、移除 |
+| 文档职责 | 文档查找、职责查看与分配、相关审签状态 |
+| 项目权限 | 单成员权限详情、成员权限矩阵、允许范围内的配置 |
+
+系统管理中补齐“模型与服务配置”，承接主模型、轻量模型、Embedding、Rerank、模型密钥与 Tavily 等系统配置；Agent 工具限制、系统插件、全局专业角色和权限上限也归系统管理。个人设置只保留个人偏好。
+
+实施时需要处理三个层面：
+
+- **展示范围**：设置描述携带允许作用域、管理资格、生效时机；项目页面只消费项目项。
+- **写入范围**：用户／项目 API 拒绝写入系统受管项，包括嵌套字段和点路径形式，插件设置也遵守同一规则。
+- **实际生效**：旧用户／项目覆盖值不能继续影响系统模型；个人画像的模型路由及个人模型密钥也必须纳入受管校验，堵住其他覆盖入口。
+
+另外，当前“项目设置”实际上按“用户＋项目”保存（Backend `Effective(owner, projectID)`，project scope 物理存储在各 owner 名下）。需要区分：
+
+- **共享项目业务配置**：以项目为权威，同一项目不同成员读取一致。
+- **个人在该项目中的偏好**：继续属于个人。
+
+跨会话读取必须保留本人会话的隐私边界，不能因项目配置共享而开放其他成员的私聊、上传原件或个人草稿。
+
+## 三、成员管理交互
+
+采用**一个可搜索的人员选择器**，同时支持输入、提示选择和下拉浏览，不为每种途径增加独立页面。
+
+添加流程：打开人员选择器 → 输入账号或姓名，或浏览候选 → 可按专业角色过滤 → 选择人员 → 设置项目身份 → 添加。
+
+具体行为：
+
+- 输入账号支持精确匹配；姓名、账号支持模糊检索。
+- 未输入时显示分页候选；选择器内提供“全部专业角色／系统工程师／软件工程师……”筛选。
+- 候选显示“姓名、账号、专业角色”；同名人员通过账号区分，姓名为空时使用账号。
+- 已加入人员标记“已加入”，避免重复添加造成隐式身份变更。
+- 最终提交稳定账号标识，不能直接提交搜索文字。
+- 成员表分别展示“专业角色”和“项目身份”，不混用两者。
+
+项目身份使用“项目负责人／项目成员”等中文名称。成员行提供明确的“调整项目身份”和“移除”操作；继续保护最后一位负责人。
+
+服务端复用已有 `rdm.account.list`，补齐受限的姓名搜索、精确账号校验和专业角色摘要。**不能直接把管理员用户列表或包含全部账号绑定的角色管理接口开放给项目负责人。**
+
+角色筛选只帮助找到人员；项目负责人不能借此修改账号的全局专业角色。账号有效状态必须来自基座实际能力，不能把当前简单的 `valid=true` 当作完整的账号停用机制。
+
+## 四、文档查找与职责分配
+
+文档职责页面采用“**文档清单＋选中文档的职责详情**”：
+
+- 上方提供统一搜索框，支持文档 ID 精确检索、标题精确／模糊匹配。
+- 支持文档列表与树形浏览；阶段、文档类型、未分配／已分配、审签状态可用于筛选。
+- 树形视图忠实呈现当前文档结构，只有文档节点可以作为职责分配对象，章节不能误作 `docId`。
+- 搜索、列表和树选择共用同一目录与选中状态。
+- 结果显示名称、阶段／类型、职责概况和状态；ID 保留为辅助定位信息。
+
+已有文档树查询属于审计面，不能降低它的授权规则来供选择器使用。应补齐专用的职责管理元数据读面：
+
+- 有职责分配权的管理者可以读取必要的管理元数据。
+- 普通成员只获得其有权查看的文档范围。
+- 标题、数量、筛选结果和树节点均在服务端过滤，避免通过搜索泄露不可见资源。
+
+选中文档后，立即读取并回填**当前职责**，包括尚未提交过审签的文档。当前职责与“某轮提交冻结的职责名单”分别展示，不能混为一份数据。
+
+人员选择规则：
+
+| 职责 | 选择方式 | 约束 |
+|---|---|---|
+| 编制人 | 搜索、下拉、专业角色过滤 | 单选 |
+| 审核人 | 搜索、下拉、专业角色过滤 | 多选，至少一人 |
+| 批准人 | 搜索、下拉、专业角色过滤 | 单选 |
+
+**所有候选只能来自当前项目成员。**保存时服务端再次校验账号、项目成员关系、对象归属、操作资格和职责版本；文档级（`rdm.review.assign.doc`）、章节级（`rdm.review.assign`）及旧命令入口均遵守同一规则。
+
+保留编制、审核、批准互异的规则。专业角色筛选不自动授予文档职责；管理权也不自动获得代编、代审或代批资格。
+
+职责变更需要补齐以下行为：
+
+- 在途审签受影响时，先显示受影响轮次与“需要重新提交”的提示。
+- 明确确认后，职责更新、在途审签失效和事件记录原子完成。
+- 保留旧冻结名单、审核记录和已批准历史，不把旧票带入新轮次。
+- 无变化保存保持幂等；并发修改返回明确冲突。
+- 移除仍承担当前职责的成员前，展示受影响文档并引导处理，防止留下无人可执行的职责。
+
+总案要求的批量分配放在同一文档清单中：勾选文档、预览统一职责方案、确认提交。首版采用有界批次，任一文档校验失败则整批不写入，并列出原因。
+
+## 五、单成员权限与多人矩阵
+
+“项目权限”提供两个视图，共享同一服务端权限解释：
+
+| 视图 | 默认行为 | 用途 |
+|---|---|---|
+| 按成员查看 | 普通成员查看自己；管理者可搜索其他成员 | 查看具体权限、配置来源和拒绝原因 |
+| 权限矩阵 | 管理者查看成员×项目动作 | 比较成员权限，发现缺失或差异 |
+
+矩阵支持成员搜索、专业角色／项目身份过滤、分页及权限分组。点击单元格可展开解释，显示角色默认、管理员上限、项目覆盖及结果。
+
+项目覆盖使用三态：沿用角色默认／项目内允许／项目内禁止。管理员上限禁止的动作不能通过项目覆盖授予；“恢复默认”需要实际撤销覆盖，不能用一个布尔值模拟。
+
+权限目录必须明确动作所属范围：
+
+| 内部标识 | 显示名称 | 所属范围 |
+|---|---|---|
+| `project.create` | 创建项目 | 系统角色权限，项目页面不出现 |
+| `member.manage` | 管理项目成员 | 项目 |
+| `duty.assign` | 分配文档职责 | 项目 |
+| `stage.advance` | 推进项目阶段 | 项目 |
+| `doc.read` | 读取文档 | 项目动作，具体文档仍须授权 |
+| `doc.write` | 编制与编辑文档 | 项目动作，仍受职责和状态限制 |
+| `knowledge.publish` | 发布项目知识 | 项目 |
+
+这个范围划分同时约束矩阵读面和覆盖写面：**不能只是隐藏 `project.create`，服务端也必须拒绝在项目中配置它。**
+
+权限名称、项目身份、来源、状态及拒绝原因统一使用人类可读文案。内部标识只保留在按需展开的技术详情中。
+
+同时核对每项权限与真实操作门禁。例如当前项目归档还有创建者／域管理员条件，矩阵解释必须反映真实条件。矩阵中的“允许编制文档”也不能意味着能修改项目内所有文档。
+
+普通成员自查权限的条件收敛为“当前有效项目成员”，避免文档读取权限被收回后，连自身权限与原因也无法查看。
+
+## 六、技术划分与实施工作包
+
+基座负责身份、基本资料、受管设置机制与通用契约；RDM 负责项目成员、专业角色、权限策略及文档职责；Frontend 负责业务交互；UI 仓提供通用选择器原语。
+
+| 工作包 | 内容与主要范围 | 依赖 | 完成条件 |
+|---|---|---|---|
+| P1 契约与需求固定 | 设置作用域、项目动作目录、人员／文档候选 DTO、能力与版本语义；更新关联方案 | 无 | 本次五项要求都有稳定验收条件，四类身份／角色／职责概念明确 |
+| P2 系统设置闭环 | Core 设置描述、Backend 设置 API／存储／生效链／模型及密钥解析；系统管理入口 | P1；**基座发版与 RDM/Dev 升 pins**（见评审补充 1） | 系统受管项只能由有权管理员配置，旧个人／项目值不能覆盖 |
+| P3 人员与成员接口 | 扩展公开账号搜索；RDM 专业角色摘要、成员查询、项目身份调整与提交校验 | P1；姓名来源核实（见评审补充 3） | 账号／姓名／角色过滤同源，添加与身份调整明确分离 |
+| P4 文档与职责接口 | 专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动 | P1、P3 | 跨项目／非成员指派被拒，职责与审签变更全成或全败 |
+| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员／文档适配 | P1，接线依赖 P3、P4 | 三类使用场景共享交互，无自由文本误提交 |
+| P6 权限解释与矩阵 | RDM 项目动作目录、单人／批量解释、覆盖三态、来源与拒绝原因 | P1、P3 | 矩阵与执行规则一致，系统动作无法写入项目覆盖 |
+| P7 项目设置集成 | 重构现有项目页，连接四个页面、能力状态、读取回填与保存结果 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程 |
+| P8 迁移与组合验收 | 旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填 | P2—P7 | 需求到证据闭合，无越权、隐私泄露或数据丢失 |
+
+前端主要改动落在现有 `ProjectSettingsModal`、`adminRdmSections`、`rdmManagement`、`api` 和 `store`；按业务拆分成员、职责及权限组件，避免继续扩大一个管理组件文件。
+
+目前 Dev 与 RDM 固定的 Backend 版本存在能力差异。实施时必须按公开契约推进相关版本，再完成组合验证，不能因为独立 RDM 仓已有某个接口就假定 Dev 组合可直接使用。
+
+## 七、界面与异步状态要求
+
+按根目录 `DESIGN.md` 实施，复用现有令牌、动效、设置外壳和折叠原语。
+
+- 一种对象只有一个主要选择路径，搜索和浏览在同一选择器完成。
+- 姓名、文档名为主要信息，账号和 ID 为辅助信息。
+- 下拉支持键盘移动、确认、关闭；审核人多选使用清晰标签。
+- 加载、空结果、权限不足、接口未装配、查询失败分别呈现。
+- 切项目、切文档、改筛选时清除不适用的选中项和结果；迟到响应不能覆盖当前对象。
+- 异步状态只有一个所有者，按请求代次／事件顺序丢弃过期结果。
+- 保存后读取服务端结果；网络断开且结果未知时先核对状态，避免盲目重放。
+- 未保存改动提供轻量离开提示；需重启的设置明确显示待生效，不能统一宣称即时生效。
+- 窄屏按成员查看权限，矩阵可横向浏览，不压缩成不可读的小格子。
+
+## 八、迁移、验证与交付安排
+
+旧配置先做脱敏盘点，列出配置路径、来源和冲突状态。不能任取某个用户／项目的模型配置提升为全系统配置。先确定并验证系统配置，再启用受管策略；旧值保留受保护的恢复依据，退出生效链。
+
+旧项目内 `project.create` 覆盖退出项目策略，保留历史依据。历史职责、审核与批准记录保留；无效的当前职责列入修复清单，不自动替换人员。
+
+正式验收至少覆盖：
+
+| 验收场景 | 预期结果 |
+|---|---|
+| 项目与个人设置写入系统模型项，包括手造请求 | 拒绝；旧覆盖也不影响运行结果 |
+| 账号、姓名、下拉、专业角色过滤查找成员 | 能找到并选择稳定账号；同名不会误选 |
+| 重复添加已有负责人、并发修改最后负责人 | 不发生隐式降级，不破坏负责人约束 |
+| 文档 ID、标题、列表、树查找 | 指向同一文档；章节及其他项目对象不能误提交 |
+| 搜索后人员被移出项目，再保存职责 | 服务端拒绝 |
+| 职责变更中途失败 | 职责、审签状态与事件完整回滚 |
+| 单成员详情与多人矩阵对照实际操作 | 结果与原因一致；具体资源限制清晰 |
+| 项目覆盖授予超上限动作或 `project.create` | 拒绝；恢复默认真正生效 |
+| 快速切项目／文档、断网、迟到响应 | 不显示旧对象数据，不误报成功 |
+| 同项目多成员使用、刷新及重启 | 共享配置一致，个人会话与原件仍私有 |
+
+验证分为领域与契约测试、真实 SQLite／PostgreSQL 集成、真实身份浏览器流程，以及 Dev 精确组合的 `make test`、`make build`。浏览器需要覆盖非管理员项目负责人、普通成员、互异的编制／审核／批准人员及两个项目；不能用全管理员账号代替权限验收。
+
+分两批形成可审查实现：先完成 P1—P4、P6 的服务端边界与契约，再完成 P5、P7 和 P8 的交互及组合验收。界面设计可在第一批同时评审。
+
+## 评审补充（2026-10-13 技术评审并入，随方案一并批准）
+
+1. **P2 显式依赖基座发版。** 受管设置机制是基座（Backend/Core）公开契约扩展，按总案交付顺序走“扩展申请评审→基座实现→基座发版→RDM/Dev 升 pins→组合验证”。P2 完成条件在原基础上追加：基座版本已发、pins 已升、Dev 组合 `make test` 通过。
+2. **项目共享配置的存储迁移规则。** 当前 project scope 物理存储在各 owner 名下；改为“以项目为权威”需要：新项目作用域存储、存量多 owner 副本的合并策略（默认规则：同键取最近写入时间，冲突清单列出不自动合并的键并交项目负责人裁定）、旧键退出生效链并保留只读恢复依据。P8 交付物含迁移清单与执行记录。
+3. **姓名来源与账号停用能力须先过 facts。** 基座账号目录当前明确“不含姓名/联系方式”。P3 的姓名搜索依赖基座账号模型是否存有姓名/显示名字段；P1 契约先定姓名来源（基座扩契约，或 RDM 专业角色档案补姓名）。账号停用机制现状同样按 `policy/facts.md` 登记验证，未证实前不把 `valid=true` 当作停用语义。
+
+## 顺序裁定（2026-10-13）
+
+本增量按自身 P1→P8 顺序推进；P2 的基座契约扩展按总案 369 行发版顺序执行，与总案 U1/U9 残余项的交织在扩展申请评审时统一排队，不因本增量跳过 U1（正式产物）与 U9（公开授权契约）的既有优先级。
+
+## 评审核查记录（2026-10-13，源码 3fb8210 / RDM 255f9cb）
+
+评审对方案“当前源码情况”逐项核查，全部属实：
+
+| 声明 | 证据 |
+|---|---|
+| 项目设置按“用户＋项目”保存 | Backend `settings.go` `Effective(owner, projectID)`，project scope 以 owner 为键 |
+| user/project 覆盖可改模型设置，无受管拦截 | 同上覆盖链，无“系统受管”概念 |
+| 成员手填账号 | `adminRdmSections.tsx` RdmMembersSection |
+| 账号目录仅 owner+有效态 | RDM `rdm.account.list` 描述“owner+有效态；不含姓名/联系方式” |
+| 职责手填 docId 与账号 | RdmDutiesSection placeholder |
+| 已有单成员权限解释表 | `rdm.perm.check`（动作/生效/来源/原因），前端默认自省 |
+| 权限标识与所属范围 | RDM `internal/perms/perms.go:21-31`，`project.create` 注释即“全局动作” |
+| 职责目标未校验成员 | `rdmReviewAssign` handler 注释“数据，非身份”——按 G1-5 旧裁定绕过成员校验；**本方案 P4 推翻该裁定，属规则变更，在 P1 契约中记录** |
+| 职责更新与审签失效分步 | 文档级 assign 先写职责再调 `InvalidateActiveDocSubmission`，两步顺序非原子；**章节级 assign 完全未接失效** |
+
+## 主记录与推进
+
+- 主记录：本文件（唯一正文）；任务卡 `.task/feature-rdm-increment-settings-duties.md` 承载需求表、证据与阶段结论。
+- 来源：`.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`（原始用户补充）、2026-10-13 会话评审。
+- 下一步：P1 已随本稿固定；按两批顺序进入 P2（基座受管设置契约扩展申请）与 P3/P4/P6 服务端实现。
@@ -0,0 +1,84 @@
+# 系统项目、成员工作入口与私域协作闭环 r1.1
+
+状态：用户 2026-10-13 已批准方向并授权阶段 1–9 连续推进；实现与隔离验证进行中。发布版本、部署、8788 数据修复及工作区清理不在本次授权内。
+
+本增量补齐总案 [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md) 的 U2，以及 U3/U5 与项目成员协作直接相关的边界。需求来源为 2026-10-13 用户复现和 `.tmp` 会议补充中“同名项目唯一、加入后可见且能新建对话、会话私有、每项目共享两树一网”。这不是模板全量迁移或三权流程重设计。
+
+## 已定位的问题
+
+8788 的成员添加记录已保存，但用的是宿主项目 ID；该 ID 没有领域注册或宿主绑定。列表和对话创建的共享适配器因此拒绝它。新建项目走宿主 owner 表，而成员管理、两树一网走领域表，缺少统一生命周期。会话列表还只检查宿主 owner，领域的名称 UNIQUE 也没有覆盖宿主创建入口。
+
+r1.1 增量：合并现行主干的成员 Picker、职责目录和权限矩阵，并闭合其独立重放发现的首次提交、渲染确认、迟到响应、职责幂等和持久版本问题；范围仍为本次成员与私域协作。
+
+运行制品仅有短来源标记，不能把当前源码视为其已证明的组件组合。只读现场证据、对象 SHA 和完整脱敏输出保存在 Dev 本任务卡，不在本文复制命令输出或线上数据。
+
+## 职责与公开契约
+
+RDM 保持项目、成员、职责与领域数据权威。Backend 管认证、宿主技术投影、私人会话/工件和通用资源执行边界。Frontend 只消费服务端身份与状态。
+
+```mermaid
+flowchart LR
+    U[认证用户] --> P[统一项目应用服务]
+    P --> D[RDM 项目与成员]
+    P --> H[宿主一对一投影]
+    H --> C[按用户归属的个人会话和原件]
+    D --> W[按项目分片的两树一网]
+    W --> K[成功发布的知识切片]
+    K --> R[当前项目的授权检索与模型上下文]
+```
+
+基座扩展申请的四要素：
+
+| 要素 | 结论 |
+|---|---|
+| 场景 | 统一产品项目创建/改名/归档，验证映射两端，并允许项目成员创建个人会话 |
+| 公开能力 | 可选 `extension.ProjectHost`、`ProjectLifecycle`、`ProjectLifecycleRegistry`；复用 `/api/projects` 与其会话路径；资源查询追加可选 `Source` |
+| 现有能力不足 | 只读 V1/V2 不承担生命周期、跨库初始化和动作授权；原 Host 没有项目技术投影与管理验证接口；仅项目布尔或已知切片 ID 不能证明索引行仍是发布来源 |
+| 兼容 | 保留必需 Host/Registry 接口；新能力经可选接口注册。未注册生命周期保留通用基座行为。RDM 产品缺该能力拒绝注册，防止悄然回到宿主个人项目路径 |
+
+`ProjectHost` 由执行端按认证主体构造；投影修改和管理查找保持 owner 限制，共享 metadata 经过授权和脱敏。`ProjectLifecycle` 的 List/Create/Rename/Archive/Work 是完整注册的一组回调，公共项目入口委托给它。客户端传入的 projectId 或 `rdm.projectId` 均是定位符。
+
+## 项目身份、名称和恢复
+
+- 领域项目、名称保留和创建者负责人同库事务提交。跨库投影使用确定的宿主 ID 和持久 `provisioning/failed/ready` 映射；失败重试保持身份，不持有领域事务跨宿主调用。
+- 本增量名称为去首尾空白后的精确名称；数据库唯一保护覆盖不同账号和并发。改名、归档后保留旧名归属。Unicode/大小写归一没有在本增量自动引入。
+- 所有产品创建、改名、归档路径使用应用服务；归档保存会话、原件和数据，不能继续新工作。管理重试可定位未完成映射，但仍须 owner/动作检查。
+- 新绑定验证真实宿主的存在和当前主体管理资格；既有绑定的 metadata/工作还验证物理宿主 owner 与映射创建者相符，不能只信映射存在。
+- 现有孤立宿主项目通过 `rdm.project.adopt` 先预览、再显式 apply；保留宿主 ID 和 owner，将成员关系移到领域根。不能凭名称猜测已有领域身份，不把未归属历史默认搬入新根。
+
+## 共享与私域
+
+| 数据 | 默认边界 |
+|---|---|
+| 个人会话/消息/原件/附件 | owner 私有；成员加入不使其对其他成员可读 |
+| 个人 pending/rejected 草稿 | 仅提案人；管理角色及其他职责不自动取得正文 |
+| 受控正文、差异与导出 | 当前项目成员身份、阶段/动作及有效章节或文档职责；审计许可不代替正文许可 |
+| 已采纳提案的本人不可变历史 | 本人自己的原始提案可保留；其他人读取受控内容走职责 |
+| 树结构、元信息、快照哈希 | 项目协作所需的结构视图；不能用元信息入口夹带正文预览 |
+| 历史正文预览 | 当前有效权限，不从历史重放恢复已撤销的职责 |
+| 原件台账、待处理数量 | 当前 actor 在目标项目的条目；管理角色不自动得全员原件视图 |
+| 项目发布知识 | 成员、明确领域根、成功发布台账、当前撤销代际与存活切片共同授权 |
+
+发布切片保留其 ID、owner、原件锚点，索引 `ProjectID` 为领域 ID，来源为 `plugin:rdm:published`。跨 owner 查询还检查实际存储行的 `Source`；手工/私人来源不能借已知切片 ID 绕行。撤销代际阻止已排队或在途任务重新授予共享。替换按 owner、精确项目（含空 ID）、ref、插件命名空间隔离。
+
+会话使用宿主 ID；HTTP、Host 和模型上下文通过服务端 provider 的可信 metadata 解析领域检索范围。每个实际知识对象再经过 V2，不能先按错误 ID 查空，也不能把 private 候选截断置于授权之前而隐藏合法结果。
+
+## 界面与执行
+
+沿用现有侧栏与项目设置，不新增管理屏。服务端 metadata 提供平面的 `rdm.projectId` / `rdm.state`，领域命令用 canonical ID，通用会话接口保留宿主 ID。未就绪项目不能回退创建默认项目；归档/关闭项目仍能读成员、权限和审签状态，不能新工作或修改。
+
+账号切换使所有待返回的列表、工件、卡片和工作续接失效。执行在确认后、排队恢复以及写入前重验当前权限，撤权后的 HITL 回复不能产生工件或恢复执行。
+
+项目 SSE 的历史重放和实时发送也必须按对象过滤。旧上传卡没有可信共享声明，不能因加入成员而暴露文件名、解析器或预览。权限从实际卡片/运行归属取值；明确共享由内部发布入口写入与 channel、seq、type 和 payload hash 绑定的声明，客户端 payload 不授予共享。未知或损坏证明拒绝，跳过私域事件仍推进扫描游标，保留未注册基座兼容。此为内部事件数据约束，不增加下游必需接口。
+
+职责保存先校验对象、三权、成员及版本；无变化不使在途轮次失效，仅实际变更生效前执行既有失效规则。职责版本随事件持久化，旧载荷按实际角色变化重建；写入失败不修改内存职责。
+
+## 验证与交付
+
+追溯：R1 名称→并发/碰撞/旧名保留；R2 身份→真实创建/失败重试/物理 owner/绑定；R3 成员→真实登录、同 ID 项目、个人对话；R4 项目分片→两项目隔离；R5 私域→所有查询/预览/台账/模型上下文及撤权；R6 旧数据→显式预览/幂等修复/保留；R7 真实组合→浏览器、真实模型任务对照、独立 Review 和当前 HEAD CI。
+
+测试原始输出由 evidence 工具写入任务卡，来源分开。单测、桩适配器、源码存在均不作为用户流程已完成的证明。当前完整运行/CI结果在任务卡维护，不在本文预写 PASS。
+
+RDM README/AGENTS 要求合入前回到基座 tag pin；开发期采用隔离 modfile组合验证。发布新 tag 属用户亲手执行的高后果操作，必须先形成已评审且 CI 通过的具体基座候选。tag、合入、部署、运行库修复和清理分别核验，不能合并成一个“完成”。
+
+下一步：完成本增量的组合验收与 tag 消费闭环；随后建议由用户授权在 8788 部署精确组合，并预览/修复已确认的孤立项目。未知历史归属、名称碰撞或身份不一致保留现场交人工裁定。
@@ -0,0 +1,201 @@
+# 项目方向与规划索引
+
+状态：**已获合入授权（2026-10-08）**。编制依据：用户同意整理既有规划主记录、确认状态、里程碑和关联任务；同日授权收尾并合入。
+本索引负责导航与差异提示，规划正文、批准范围和验收条件仍以链接的主记录及其批准版本为准。
+合入授权不批准新方向、不调整里程碑范围、不启动新的业务任务。
+
+## 先看哪一份
+
+- [IAM I1 权限边界与公开扩展合同 r1](2026-10-13-iam-i1-permission-contract.md)：
+  依据已批准的[用户、职位角色与分层权限统一方案 r1](2026-10-13-identity-role-permission-plan.md)
+  （Documents `a088809`）冻结系统／项目／资源边界、管理员无业务 bypass、创建者 cap、独立 `audit.read` 与公开扩展四要素。
+  2026-10-13 已授权 I1（U1–U2）；多职、通用角色迁移、资料目录、矩阵及完整运行验收仍按后续单元推进，不以合同保存宣称已交付。
+  实际进展与证据见 [I1 实施候选与评审记录](2026-10-13-iam-i1-review.md)，用户实施评审及[阶段 7 验收](2026-10-13-iam-i1-acceptance.md) 已通过，当前进入智能体 Review、PR、CI 与合入。
+
+- [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md)：
+  运行卡呈现状态、已完成工作、当前发现与剩余项；四层阅读、阶段成果、来源、异常恢复及 U1–U4。
+  2026-10-12 方案设计已批准（阶段 1–4）；首批仅 U1；[U1 实施计划 r1](2026-10-12-fast-slow-channel-display-u1-plan.md) 待阶段 5 批准；业务实施和运行验收 NOT_RUN。
+
+Generative UI 方向已收口（U1–U7 全部落地，2026-10-12）：[使用说明与评测记录](2026-10-12-generative-ui-usage-and-evaluation.md)（final）；
+主记录 [r2](2026-10-10-generative-ui-plugin.md) 与 [U5 动作范围 r2](2026-10-11-generative-ui-u5-action-scope.md) 保留为过程权威。
+
+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，
+应由负责人补齐；不能仅凭任务创建人推断全部规划的负责人。
+
+## 快照与状态口径
+
+本次只读核验时间：**2026-10-07 13:27 UTC**。来源均为 **SELF** 的文件、Git 与 API 观察，
+原始命令、对象和输出见 [核验收据](../records/2026-10-07-planning-index-source-receipt.json)，
+可检索字段见 [核验快照](../records/2026-10-07-planning-index-source.json)。
+
+- Dev 基线：`eb0d4b5a499322a23155c8d89a024247f6e7830d`。
+- 该基线固定的 Documents：`b8eaa1676f168ad64c437857e2607e2e213f6672`，包含下表前 18 份方案。
+- 查询时 Documents main：`5542319a0474fd4e866b6daacb937b587c833ede`；额外包含 N2 阶段案。
+  前 18 份文件在两个 Documents 版本中的 blob 完全相同。此候选索引基于该 Documents main 编制。
+  因此本地 Dev 候选指针同时包含 N2 方案文件；批准并采纳这个组合会纳入该文件，仍不等于批准其业务实施。
+  远端 Dev 是否采纳及在途 #244 的衔接，按实际合入时重新核对。
+- 查询的 55 个关联 PR 中，54 个已合入且合入提交属于各自固定 main；编制时 Dev #244 尚未合入。
+  所查 PR 的 reviews 数组均为空。这不能证明不存在会话批准，也不能补作人工批准依据。
+- 合入前同步（2026-10-08）：Documents `origin/main` =
+  `16795ed59820eee1d36efe6564e13a2f5a6387a6`，在上述查询版本之上新增 N3（Documents #43）
+  与 Q2/Q3（Documents #44）。Dev `origin/main` =
+  `7f1d87dbb976ebe02ceb632d5a657a416ffb50bc`。新增行与 N2/N3/Q2/Q3 阶段行只按
+  `git log --merges` 核对合入提交；没有重放各任务测试。合入不等于阶段验收重验。
+- 下表“原文确认/状态”保留作者声明；“已合入”只描述本次核实的 Git/PR 状态。
+  这份来源快照不包含业务里程碑、用户流程、部署或下游状态的复验，这些验收为 **NOT_RUN**。
+  本地候选组合的 `make test` 用于检查文档指针组合，不代替各规划的业务验收。
+
+使用更新版本时重新核对快照，不把这里的历史状态当实时任务台账。原文仍为 proposed/待审，
+或批准来源不能关联到确定版本的，保留待核实；已经归档的任务也须检查剩余范围。
+
+复核方法：读取 Gitea 的 `/api/v1/repos/weichen/{repo}/pulls/{number}` 及其 `/reviews`，
+再在对应仓运行 `git merge-base --is-ancestor <merge_sha> <固定 main SHA>`；文档采用情况按
+`git rev-parse <Documents SHA>:<文件路径>` 比较两个版本的 blob。API 状态与 Git 包含关系同时记录。
+
+## 全部规划与关联交付
+
+下表覆盖同步后 Documents main 中的 **21 份 Markdown 方案**（原查询版本 19 份，加上 N3 与 Q2/Q3），不含本索引自身。
+Dev 链接均指向对应任务 PR，可从其任务卡继续追溯组件 PR；不表示完整业务验收通过。
+
+| 主记录 | 角色、里程碑或范围 | 原文确认/状态（声明） | 关联合入记录与待核实项（SELF） |
+|---|---|---|---|
+| [系统骨架](2026-09-29-system-skeleton-design-and-plan.md) | 历史规划起点；P0–P5、D1–D16；后续有专题局部修订 | 待审 r4；决策勾选仍空 | [历史 P0–P5 实施记录](../records/2026-09-29-implementation.md)可定位阶段和提交；本轮未建立完整独立批准/验收链，不把记录勾选当当前验收 |
+| [双档存储与多租户](2026-09-30-dual-tier-storage-and-multitenancy.md) | 明确局部修订骨架：多租户/RAG 前移，SQLite 默认、PG 可选；D17–D24 | accepted，页首称实施完成 | [四阶段实施记录](../records/2026-09-30-dual-tier-implementation.md)及[历史测试报告](../reports/2026-09-30-dual-tier-test-report.md)；本轮未据此宣称当前多租户/RAG 已验收 |
+| [启动配置面](2026-09-30-configuration-surface.md) | 配置管道、实例隔离；配置专题 | 已批准（随实现交付） | Dev [#12](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/12) 已合入 |
+| [跨会话读取](2026-09-30-cross-session-reading.md) | 同项目 transcript 按需读取、权限和入口 | 已批准（随实现交付） | Dev [#67](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/67) 已合入 |
+| [交互底座](2026-09-30-ui-inbox-command-workspace.md) | T0–T5：基础、卡片/命令、收件箱、命令总线、工作区、体验收尾 | 已批准总体方案与 T0 计划 | Dev #14/#15/#19/#21/#23/[#25](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/25) 已合入；各 PR 见快照 |
+| [UI 重构与认证](2026-09-30-ui-redesign-and-auth.md) | 交互底座后的 R1–R4 与补充修订 | accepted（方向及 R2 范围）；页首管理员发放制覆盖旧注册方案 | Dev #30/#37/#43/#53/#61/[#71](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/71) 已合入；R3 与旧正文差异见下表 |
+| [卡流与过程分离](2026-09-30-cardflow-and-process-split.md) | CF0–CF2；D39–D43 | 已批准（原文记录用户五项裁定） | Dev [#79](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/79)、[#90](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/90) 已合入 |
+| [流式卡片、工件统一与项目收件箱](2026-09-30-card-stream-artifact-unify-project-inbox.md) | CF-S → CF-A → CF3；D44–D52；承接卡流案 | 已批准（声明） | Dev [#100](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/100)、[#103](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/103)、[#105](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/105) 已合入；保留后台 producer 等边界 |
+| [文件预览与保留能力](2026-09-30-file-preview-and-reserved-capabilities.md) | 工件管理后续；预览基座、Office、URL、fs | 已裁定（§5）；实施任务已命名 | Dev [#77](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/77)、[#94](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/94) 已合入；PPTX 与右栏口径待对齐 |
+| [基座路线图](2026-10-01-base-extension-roadmap.md) | 基座/下游边界总记录；显式引用 harness 与栈总案 | 实施中 | Dev [#132](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/132) 已合入；不能据此推断 tag、npm 或下游验收完成 |
+| [插件契约 v2](2026-10-01-plugin-contract-v2.md) | 路线图配套；声明、进程内、sidecar、前端 ESM 与生命周期 | 实施中 | 与路线图同任务、Dev #132；四种形态的当前运行状态未重验 |
+| [扩展兼容规则](2026-10-01-extension-compat-policy.md) | 路线图配套；兼容窗口、快照、版本发布与申请流程 | 实施中 | Dev #132；EXT-5 文档补充接口方法快照；发布动作另有双钥匙边界 |
+| [Agent harness](2026-10-01-agent-harness.md) | P0–P4 前序总案；明确后续栈总案不使 P0–P4 作废 | proposed | Dev #134/#136/#138/#140/#142/[#144](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/144) 已合入；参见阶段导航 |
+| [Agent 栈总案](2026-10-02-agent-stack-completion.md) | 当前库分期范围入口；承接 harness | proposed | 文档 Dev [#151](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/151)；R0/R1/R2/D1 及后续交付见阶段导航 |
+| [EXT-1](2026-10-05-ext-1-inproc-command-handler.md) | 扩展申请；owner 作用域 Host 与进程内命令最小集 | 实施中 | Dev [#207](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/207) 已合入；[#209](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/209) 是任务卡恢复/复核轮，不是第二次公开面实现 |
+| [EXT-5](2026-10-06-ext-5-host-parse-document.md) | 继 EXT-1 开放宿主文档解析；不依赖未提交的 EXT-4 | 实施中 | Dev [#222](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/222)、修复 [#224](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/224) 已合入；下游接入和发布不等于完成 |
+| [N1/Q1/I1 实施案](2026-10-07-agent-stack-n1q1i1-plans.md) | 栈总案 §5 的三个阶段细化；明确不包含 N2/Q2/I2 | proposed | 文档 Documents [#40](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/40)、Dev [#226](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/226) 已合入；实施范围差异见下表 |
+| [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) | 下游大目标、双仓及可退化约束；P0–P4 / MS0'–MS4 | proposed；§2.3 现状复核已回填（2026-10-08） | 文档 Documents [#41](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/41)、Dev [#229](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/229) 已合入；不代表 RDM 各阶段获准实施 |
+| [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。
+这些负责关系待确认，不能由作者、任务创建人或 PR 账号代填。确认状态只是上述版本原文的摘录，独立批准凭据需要另行关联。
+UI 的 [演示入口](ui-redesign-demos/index.html) 与四份样稿归属于 UI 重构方案，不是另外五个已批准规划。
+
+## Agent 栈的阶段与关联任务
+
+显式关系：基座路线图 → harness（前序，不作废）→ 栈总案 → N1/Q1/I1、N2、N3、Q2/Q3 阶段案。
+RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围。
+阶段 N2 指“上下文、协议与工具”，不是审计报告中同号的“并行工具事件竞争”缺陷。
+
+| 阶段 | 主记录与关联任务 | 核验结果与继续工作的边界 |
+|---|---|---|
+| harness P0–P4 | harness 对应 `feature/agent-harness-p0` 至 `p4`，含 p3b | 上表六个 Dev PR 已合入；旧卡“后续尚未实施”只属于当时快照 |
+| R0/R1、R2、D1 | 栈总案；`feature/agent-stack-r0-r1`、`r2`、`d1` | Dev [#152](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/152)、[#154](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/154)、[#156](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/156) 已合入；不得把同号审计缺陷误作阶段名 |
+| N1 | N1/Q1/I1 案 §2；`feature/agent-stack-n1` | Dev [#232](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/232) 已合入；状态与范围差异已于 2026-10-08 回填至[主记录 §7.1](2026-10-07-agent-stack-n1q1i1-plans.md)（WP6b/6c 等转出项带归属，均未被后续阶段承接） |
+| Q1 | 同案 §3；`feature/agent-stack-q1` | Dev [#237](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/237)、[#240](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/240) 已合入；platform task 与 squad run 的统一边界已厘清并回填至[主记录 §7.2](2026-10-07-agent-stack-n1q1i1-plans.md)（Store 层合一已做，队列翻译转出且 Q2/Q3 未承接） |
+| I1 | 同案 §4；`feature/agent-stack-i1` | Dev [#234](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/234)、[#235](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/235) 已合入；blueprint entry、SetSlot/Cancel/Handoff 等后续边界已回填至[主记录 §7.3](2026-10-07-agent-stack-n1q1i1-plans.md) |
+| I2 | 栈总案 §5/I2；`feature/agent-stack-i2` | Dev [#242](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/242) 已合入；主记录已加状态回填（[栈总案 I2 节](2026-10-02-agent-stack-completion.md)），I2 卡断链已在 Dev 侧修正；开启态完整用户验收未重放 |
+| N2 | N2 阶段案；Dev [#244](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/244)，闭卡 [#247](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/247) | 2026-10-08 同步时已在 Dev main。#244 标题是接入方案并开启任务；完成声明在已归档任务卡，本索引未重放其测试 |
+| N3 | [N3 实施案](2026-10-07-agent-stack-n3-plan.md)；Dev [#248](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/248)，闭卡 [#249](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/249) | 方案与任务卡已合入。完成声明在已归档任务卡，本索引未重放 |
+| Q2 | [Q2/Q3 实施案](2026-10-07-agent-stack-q2q3-plans.md) 第一部分；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) | #251 已合入。完成声明在已归档任务卡，本索引未重放 |
+| Q3 | 同案第二部分；Dev [#253](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/253) | #253 已合入。完成声明在已归档任务卡，本索引未重放 |
+
+原始任务卡在 Dev 仓 `.task/archive/`。任务主记录和既有分工优先复用，
+索引整理不重新领取或另建相同业务任务。
+
+## RDM 里程碑：规划目标与核验边界
+
+以下名称、窗口与依赖来自 RDM 总案 §1、§4，**只保留计划，不表示已承诺或已验收**。
+
+| 阶段 | 原规划目标 | 核验边界 |
+|---|---|---|
+| P0 / MS0' | 奠基、组织决议、基线与 v0.2.0 前置 | 复核（2026-10-08，[总案 §2.3](2026-10-07-rdm-phase-plan.md)）：v0.1.0 六 tag 在位、O1/O3/O7 已决议（RDM 00-V2定稿决议）、P0 已在下游关账（RDM #91）；**v0.2.0 仍未发版（owner 双钥匙，窗口 10-25 前）** |
+| P1 / MS1 | W4 上传五步与两速入库（原窗口 2026-11-01） | 复核（2026-10-08）：下游首批已落地（F1 v1、两速、D8 等）；七条验收 = 2 满足（重放）/2 部分/1 阻塞（EXT-5 不在 v0.1.0 pin）/1 口径不成立/1 未满足（对话入口），**不可签收**；详见总案 §2.3 MS1 核对表 |
+| P2 / MS2 | W7 基线、三分类与版本链（原窗口 2026-11-22） | 复核（2026-10-08）：状态机/版本链/三分类门控/需求大表等首批已在下游合入；MS2 正式验收 NOT_RUN（含 O2 提案待拍板） |
+| P3 / MS3 | W11 两树一网、变更闭环、一键生成（原窗口 2026-12-20） | 复核（2026-10-08）：追溯网/冲突/变更 UI/起草等首批已在下游合入；库分期前置（Q1/Q3/I1）已全部合入，其转出项见 N1/Q1/I1 案 §7；MS3 正式验收 NOT_RUN |
+| P4 / MS4 | W16 自举与演示（原窗口 2027-01-24） | 复核（2026-10-08）：自举语料/周报/立项例程等首批已在下游合入；EXT-3 仍未申请（截止 W10 前）；MS4 正式验收 NOT_RUN |
+
+~~总案引用未入本仓的 further-objective 01–13，以及下游仓的奠基材料。它们是明确的来源缺口。~~
+**来源缺口已关闭（2026-10-08 复核）**：further-objective 01–10 已权威迁入 RDM 仓
+`docs/requirements/`、11–13 迁入 `docs/materials/`（RDM #42）；抽查 08/10 号与原件逐字
+一致，01 号为 V2.0 定稿升版（属正常演进）。Dev 仓 `.tmp/` 私有目录仍被 exclude，未入 Dev 仓；
+引用愿景编号时以 RDM 仓内权威正文为准。
+
+## 待澄清与待同步项
+
+这些条目登记文档之间的差异，不代替产品裁定，也不静默重写原方案。
+原文已有明确后续裁定的，只需同步旧叙述；缺少可定位的范围变更依据时，才提交负责人确认。
+
+| 项 | 可复核位置 | 需要确认或补齐的内容 |
+|---|---|---|
+| 批准版本 | 各方案页首；核验快照的 reviews | 把原文 proposed/待审/accepted 与实际批准范围、版本和来源关联；PR 合入不能自动补齐实施授权 |
+| 负责人缺项 | 双档、配置、跨会话、预览及 N2 案页首 | 五份未单列 owner，预览只有作者；由项目负责人确认维护与决策职责后回填主记录 |
+| 骨架局部修订 | 骨架 §2.2/§7.2 与双档专题“方向修订”；骨架结尾 D1–D15 与新增 D16 | 保留双档专题明确修订关系，补齐决策范围与批准依据，避免继续照旧“多租户/RAG 远期”执行 |
+| UI/auth 与预览 | UI/auth 页首及 §5.1；预览 §3/§4/§5；交互底座 D25 | 页首管理员发放制已否决旧注册方向，但旧正文仍在；PPTX 全保真裁定与文本大纲叙述、右栏预览与纯收件箱边界需对齐 |
+| 卡流实施口径 | 卡流里程碑的旧 D34–D37 与 D39–D43 表；CF-A/CF3 任务卡剩余项 | 校正编号与阶段范围，保留 CF-A 前端零改动和 CF3 后台 producer 等实施边界 |
+| N1/Q1 完成口径 | **已处理（2026-10-08）**：[N1/Q1/I1 案 §7 回填](2026-10-07-agent-stack-n1q1i1-plans.md) | 各项“完成/转出/待做”已带依据、归属与适用版本；回填为 SELF 层记录，未重放各任务测试 |
+| I1/I2 归属 | **已处理（2026-10-08）**：I2 卡断链已修正（Dev 侧归档卡）；I2 状态回填至[栈总案 I2 节](2026-10-02-agent-stack-completion.md)；未接入消费者归属见 §7.3 | SetSlot/Cancel/Handoff 消费无阶段载体，需负责人排期 |
+| N2/N3/Q2/Q3 合入与验收 | Documents #42–#44；Dev #244/#247/#248/#249/#250/#251/#253 | 这些 PR 已在 2026-10-08 的 Dev main 上。本索引只登记 Git 合入，不把闭卡文案升级为重新验收 |
+| Q2/Q3 归档卡截断 | Dev `.task/archive/feature-agent-stack-q2.md` 与 `-q3.md` 的「影响与剩余项」行 | 两卡该行在归档中截断（106/97 字符，止于半句）；完整表述需对照 PR #251/#253 描述补齐或登记缺损 |
+| RDM 历史快照 | **已处理（2026-10-08）**：[RDM 总案 §2.3 现状复核](2026-10-07-rdm-phase-plan.md) | 逐行复核+MS1 七条核对+六项新缺口登记；收据 SELF（RDM 无 CI），见 records/2026-10-08-rdm-status-* |
+| RDM 双主记录关系 | RDM 仓 `docs/requirements/10-实施推进方案`（V1.2 定稿）与本仓 RDM 总案 | 裁定（2026-10-08，负责人确认）：前者为执行总案（下游任务在其仓内立卡引用），后者为基座侧消费记录（里程碑对齐、扩展点、库分期依赖）；下游执行细节冲突时以前者为准，里程碑与基座依赖以本仓总案为准；本仓总案不回写下游正文 |
+| RDM 仓无 CI | RDM 仓无 `.gitea/workflows`；PR status API 无 statuses | INV-3 的 GATE 来源不存在，下游完成声明止于 SELF；建议 RDM 接 act_runner 后，重大验收（MS1 签收等）以 CI 为权威源 |
+
+## 下一步建议与维护
+
+原首选任务（确认并修订 N1/Q1/I1/I2 阶段主记录的状态与范围差异）已于 2026-10-08 执行完毕：
+回填见 [N1/Q1/I1 案 §7](2026-10-07-agent-stack-n1q1i1-plans.md) 与栈总案 I2 节，I2 卡断链已修正。
+转出项清单显示 WP6b/6c、SetSlot/Cancel/Handoff 消费、platform task 队列合一、黑板可回放增量
+均无阶段载体，需负责人排期；「批准版本关联」与「负责人缺项」两栏仍待负责人确认。
+
+后续维护：主案或任务变化时先更新其唯一主记录，再更新这里的导航和核验快照。
+更换 Docs/Dev 基线后重新核对 PR、版本与在途任务；新的索引状态不自动产生实施授权。
+
+## 2026-10-13 规划补充
+
+- [最终验证与合入调度实施计划 r1](2026-10-13-merge-queue-implementation-plan.md)：阶段 5 已于 2026-10-13 经用户「批准」确认，原生逐项实施；U1–U3 源码与自检在 Dev 任务分支推进，U4 待启用记录及规则已准备，U5 平台所有者操作与 U6 真实三任务 CI 试行仍 NOT_RUN。实际对象、证据和进度回链 Dev 任务卡，不把本索引当第二进度权威。
+
+- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md)：承接总案 U3/U4/U6（衔接 U5）的完整增量——设置作用域与受管项、可搜索人员选择器、文档清单＋职责分配、单成员/多人权限矩阵与三态项目覆盖；含服务端一致性修复（职责目标成员校验推翻 G1-5 旧裁定、职责变更与审签失效原子化）与 P1–P8 工作包。**2026-10-13 用户评审通过并授权实施**（两批推进；正式验收与清理回收保留人工节点）；P1 契约随本稿固定，P2 基座契约扩展按总案发版顺序排队。
+
+## 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 规格）；r2 增补经 #87 合入；**2026-10-13 r3：登录恢复流程按用户「按此方案实施」批准并合入**（Backend #187 / Frontend #76 / Dev #504，浏览器验收 PASS；三裁定与实施记录见 §11）。规格与合同见 Dev `docs/svc-deploy/`。
+
+- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。**2026-10-12 用户批准 r2（五阶段一并）**；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7；U2 首切片已由 svc-autorecover 任务合入 main（PR #396/#401，2026-10-11）；U1 实例身份已合入（Dev #415，2026-10-12），余量按 KTD 对齐后续增量。
+
+## 2026-10-11 规划补充
+
+- [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md)：对应 P3/MS3，源码已有部分实现；优先补项目绑定、创建者/管理员读取隔离与历史完整性，再接统一展示。用户确认范围为 RDM 与必要基座能力；r1 已获用户评审通过（2026-10-11，五阶段一并，含 KTD4 双层管理员裁定）。U1–U5 全部实施合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11；超管槽待基座能力接线，见 RDM 仓 U1 基座扩展申请）。U6 团队存储独立后续；运行验收属部署环境。
+
+- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md)：69 类旧资产、4 个当前注册模板的盘点及生成闭环设计；待评审，实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认（2026-10-11），其余方案与实施仍待评审。
+
+- [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md)：本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界；覆盖 34 UR／68 SR／10 F、全部69类模板及现有XLSX，当前源复核 RDM d8d7e743。总体方案待评审，实施/迁移/运行验收 NOT_RUN；模板方案为子方案。
+
+- [工作台界面重设计 r0.2](2026-10-12-work-companion-ui-design.md)及[实施计划 r1](2026-10-12-work-companion-ui-plan.md)：对话优先、渐进任务摘要、窄屏与单一状态投影；已获本次连续实施授权。
+
+- [系统项目、成员工作入口与私域协作闭环 r1.1](2026-10-13-system-project-membership.md)：2026-10-13 已批准方向及阶段 1–9 连续推进；统一生命周期、成员个人会话、每项目两树一网与私域权限；组合验收/CI/tag 消费推进中，部署和线上修复未授权。
@@ -0,0 +1,963 @@
+{
+  "source": "SELF",
+  "checked_at": "2026-10-07T13:27:59.195848+00:00",
+  "dev_base": "eb0d4b5a499322a23155c8d89a024247f6e7830d",
+  "docs_pin": "b8eaa1676f168ad64c437857e2607e2e213f6672",
+  "docs_main": "5542319a0474fd4e866b6daacb937b587c833ede",
+  "limits": "API/Git state only; no runtime testing or assertion of human implementation approval",
+  "proposals": [
+    {
+      "path": "docs/proposals/2026-09-29-system-skeleton-design-and-plan.md",
+      "source_blob": "2ba08d7017e7f45c6bc1493a46c050765613f7ac",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-card-stream-artifact-unify-project-inbox.md",
+      "source_blob": "0066c25a1f737fc6fe213cec677803d4d1163cbf",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-cardflow-and-process-split.md",
+      "source_blob": "fb737b396ec35d7d848b71f8c30c39779b64366b",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-configuration-surface.md",
+      "source_blob": "abd37122514d0aeded245a23167b78e12c7b0833",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-cross-session-reading.md",
+      "source_blob": "b96c0dae76b347841f46380d06d53806869e338a",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-dual-tier-storage-and-multitenancy.md",
+      "source_blob": "1880c2ac14e91f6db24d9b104f1f7bb2547fe166",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-file-preview-and-reserved-capabilities.md",
+      "source_blob": "f48af6d25937d2e5aacc946d0023a53e3c09bde4",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-ui-inbox-command-workspace.md",
+      "source_blob": "e78e19732856cbfc9d0105302aae2ff2c453c2d4",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-09-30-ui-redesign-and-auth.md",
+      "source_blob": "155cbf0993b40f4ea616aef95aaee7ff71d7db6b",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-01-agent-harness.md",
+      "source_blob": "b3b304c9f31fca632ffa47326c48556ee0ee7cca",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-01-base-extension-roadmap.md",
+      "source_blob": "b2b99878dd1fc95f86f28f0b007d012c5171d597",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-01-extension-compat-policy.md",
+      "source_blob": "1daba9f4f7441bdde8d648cd08f663ffa36cc7e9",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-01-plugin-contract-v2.md",
+      "source_blob": "08395fbf53a306b76d692e1ded8ee0d1f41716af",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-02-agent-stack-completion.md",
+      "source_blob": "a6e7cb732ae4c7b403b81e5597620b58644438fc",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-05-ext-1-inproc-command-handler.md",
+      "source_blob": "988e5516b4b3f7919071f667d543b55dcbdb08fe",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-06-ext-5-host-parse-document.md",
+      "source_blob": "2a54cfd98874e4f94d2b74967e0541fa27f4601d",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-07-agent-stack-n1q1i1-plans.md",
+      "source_blob": "ee44529a8c283693875f4bb1c11dde7b9939e60c",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    },
+    {
+      "path": "docs/proposals/2026-10-07-agent-stack-n2-plan.md",
+      "source_blob": "647b04848a6a77a68b1754f200ae61804d1a0740",
+      "present_in_dev_pin": false,
+      "same_blob_as_dev_pin": false
+    },
+    {
+      "path": "docs/proposals/2026-10-07-rdm-phase-plan.md",
+      "source_blob": "d2a491849ef8d04ea04bfeb885ba6a15a3bdc1f5",
+      "present_in_dev_pin": true,
+      "same_blob_as_dev_pin": true
+    }
+  ],
+  "pull_requests": [
+    {
+      "repo": "Agent-System-Dev",
+      "number": 12,
+      "title": "Pin backend with the configuration pipe and documents with its design",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/12",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T04:27:51Z",
+      "head_ref": "refs/pull/12/head",
+      "head_sha": "6f72c0d4dd99e5162339b57489446ef9b0b0534f",
+      "base_ref": "main",
+      "merge_sha": "a58f85e0d0ade6e8b4da3afe9985985a38bae47a",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 14,
+      "title": "Wire Agent-System-UI and Agent-Command into the Dev combo (T0)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/14",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T06:11:54Z",
+      "head_ref": "refs/pull/14/head",
+      "head_sha": "cc9d8ec66d2597f47b6c7bafc7a607957c2de188",
+      "base_ref": "main",
+      "merge_sha": "69e9471dafd275f98928ff005732b94c4b18b638",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 15,
+      "title": "T1: pin contracts combo (core cards/commands, agent-command v0) and guard task-finish",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/15",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T06:34:06Z",
+      "head_ref": "refs/pull/15/head",
+      "head_sha": "3ca7f374e63748e41476fbf0244b06ef0711d6dc",
+      "base_ref": "main",
+      "merge_sha": "69fd335deac237f5291298cb06a50bf03d11add7",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 19,
+      "title": "T2: pin the inbox combo (cardsvc backend, ui components, frontend wiring)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/19",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T07:36:09Z",
+      "head_ref": "refs/pull/19/head",
+      "head_sha": "d8dd604b8ab823f742c6e7b0f4ae43e23e4fda12",
+      "base_ref": "main",
+      "merge_sha": "10405f9479c83a7eccb9ab6133229d37013a9da5",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 21,
+      "title": "T3: pin the command-bus combo (cmdbus, InlineConfirmCard, symmetric entries)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/21",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T07:56:27Z",
+      "head_ref": "refs/pull/21/head",
+      "head_sha": "b9d4df056116128e450f163cb3de568c032f8d91",
+      "base_ref": "main",
+      "merge_sha": "7393d6b95850982043b5d31aa2db6953a5bcd031",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 23,
+      "title": "T4: pin the workspaces combo (OverlayHost, pure-inbox rail, Cmd shortcuts)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/23",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T08:09:48Z",
+      "head_ref": "refs/pull/23/head",
+      "head_sha": "4318a0bad8cb1025a3323d2942486812f7aeff5a",
+      "base_ref": "main",
+      "merge_sha": "b6822096834853942439a4069a78b519b354731c",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 25,
+      "title": "T5: pin the polish combo (zero-page walkthrough, tidy, guide) - proposal complete",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/25",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T08:18:34Z",
+      "head_ref": "refs/pull/25/head",
+      "head_sha": "61dc542e56fa64f78c5da3cdc69da2890db122f3",
+      "base_ref": "main",
+      "merge_sha": "3be968af731eecc7b9cd4699c54671b7a9c9cbd9",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 30,
+      "title": "界面重构与多用户认证设计提案（documents gitlink + 任务卡）",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/30",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T10:02:29Z",
+      "head_ref": "refs/pull/30/head",
+      "head_sha": "f9d2aaa2739f9678ee4df7040c7ca80afcfca180",
+      "base_ref": "main",
+      "merge_sha": "32bb3457d174e6c837ef9b411138d2b57f5839f6",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 37,
+      "title": "Task-centric sidebar R1 (option A): gitlinks + task card",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/37",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T10:46:46Z",
+      "head_ref": "refs/pull/37/head",
+      "head_sha": "6cfdb89f21945a0c9f5dae9451bde5c9f099d05b",
+      "base_ref": "main",
+      "merge_sha": "075c187be28c15b3b66c14adf3edcbeeafb5c05f",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 43,
+      "title": "Admin-issued accounts R2: gitlinks + task card",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/43",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T11:17:31Z",
+      "head_ref": "refs/pull/43/head",
+      "head_sha": "66eae890170c2373681384ddb1b8ae84454a4e87",
+      "base_ref": "main",
+      "merge_sha": "2f319ca0f5b86e12796042e72f65d3d939b97182",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 53,
+      "title": "R4 visual refresh: gitlinks + task card",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/53",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T12:44:52Z",
+      "head_ref": "refs/pull/53/head",
+      "head_sha": "73b2802b69eb23be4dd16db41f316f0ab8ac99ca",
+      "base_ref": "main",
+      "merge_sha": "b0699598191a51b912aae4e69e39d7d48a38188e",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 61,
+      "title": "UI capability platform: gitlinks + .gitignore + task card",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/61",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T14:23:41Z",
+      "head_ref": "refs/pull/61/head",
+      "head_sha": "0bf2f9beccb806f7201a5b069aebd259fab49320",
+      "base_ref": "main",
+      "merge_sha": "58f191189bf807c86bad3399fa295088ce26a5fa",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 67,
+      "title": "Deliver layered cross-session reading and pin the five module PRs",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/67",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T15:27:41Z",
+      "head_ref": "refs/pull/67/head",
+      "head_sha": "835e3ce187412298060a9fd0e7f60f158ed05796",
+      "base_ref": "main",
+      "merge_sha": "816b40e8f74d27218c2ed321dc88007fd298bed3",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 71,
+      "title": "Deliver part-order fidelity, artifact downloads, file management, and the settings shell fix",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/71",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T15:44:05Z",
+      "head_ref": "refs/pull/71/head",
+      "head_sha": "7e9cac8a40a479d1f4a4790db38fef370aa28724",
+      "base_ref": "main",
+      "merge_sha": "bb1bf06aec6d3f848ce6a1ca291c6ef6dc4da4ab",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 77,
+      "title": "Pin the file-preview proposal and restore the regressed module gitlinks",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/77",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T16:06:43Z",
+      "head_ref": "refs/pull/77/head",
+      "head_sha": "937c4ed9011dbc86dac85eaaa691335b9a2393e3",
+      "base_ref": "main",
+      "merge_sha": "a3f3cb0a841c7d918982b24590bb58bcf804a2ad",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 79,
+      "title": "Agent-System-Dev: review fixes for chat-process-split-r1 (symlink, live interleaving, artifact process)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/79",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T16:17:03Z",
+      "head_ref": "refs/pull/79/head",
+      "head_sha": "f3056cb9d6bdbb0061848661afb8b61a7d8dc06f",
+      "base_ref": "main",
+      "merge_sha": "eb1877b3f707fc5bc6e59cd531e6d9d69424129b",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 90,
+      "title": "Pin cardflow-r1 module combination (CF1: submit_card, card anchor, process split)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/90",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T17:14:50Z",
+      "head_ref": "feature/cardflow-r1",
+      "head_sha": "9451887c059fac7fe987544ac455b51f39911201",
+      "base_ref": "main",
+      "merge_sha": "75d5a1721e928eb832f54b5d4aaf1def304021e6",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 94,
+      "title": "Deliver file previews, dual-dock placement, and reserved delete/fs capabilities",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/94",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T17:21:30Z",
+      "head_ref": "feature/file-preview-caps",
+      "head_sha": "f958bfb326c7dae646fb1dd6dabc5faf2d63221d",
+      "base_ref": "main",
+      "merge_sha": "2c8e1b8d5762685256e2e9bb27eb29b4008d738e",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 100,
+      "title": "Land card streaming (CF-S: card_begin/card_append/card_commit)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/100",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T18:23:29Z",
+      "head_ref": "feature/card-stream-r1",
+      "head_sha": "e240f909113ccf96fd2241da6aeb3804fa6cb414",
+      "base_ref": "main",
+      "merge_sha": "a8faa967cdc0fe0d20a3cb20ed17f74518b6cff7",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 103,
+      "title": "Land artifact unification (CF-A: backfill symmetry + facade cards)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/103",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T18:44:17Z",
+      "head_ref": "feature/artifact-unify-r1",
+      "head_sha": "a4c0d1ad1b53f4c8831bcd8abfb824c112947802",
+      "base_ref": "main",
+      "merge_sha": "675e6f8483e11d67a49f3c68b8b98a44cb42b7e1",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 105,
+      "title": "Land cross-session project inbox (CF3: D48-D51)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/105",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T19:20:29Z",
+      "head_ref": "feature/project-inbox-r1",
+      "head_sha": "25f65559ae45751fea811f06955641345d56c1d9",
+      "base_ref": "main",
+      "merge_sha": "0b82976c66aaaaf0515fd31eaee9abfa5cde193c",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 132,
+      "title": "Pin the extension roadmap and downstream spike",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/132",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T10:47:14Z",
+      "head_ref": "feature/base-extension-roadmap",
+      "head_sha": "94b7de3a9f0debb5a5afb8e09974cc72a8a08e54",
+      "base_ref": "main",
+      "merge_sha": "db9c4690478b4fa4973efa1111e8764c73011ebb",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 134,
+      "title": "Pin the harness proposal and native tool-call replay",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/134",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T12:43:41Z",
+      "head_ref": "feature/agent-harness-p0",
+      "head_sha": "5e257192018c2d536ba4f16406e8ce9750c13952",
+      "base_ref": "main",
+      "merge_sha": "46b9e53f75f5383ea1ac961b8e6fa587f88ce64a",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 136,
+      "title": "Pin the harness turn loop across the three native checkouts",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/136",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T13:42:01Z",
+      "head_ref": "feature/agent-harness-p1",
+      "head_sha": "c5ab4c35e56bd762f37a22649fc94a4e2480bc5b",
+      "base_ref": "main",
+      "merge_sha": "def110d784dfeb0139062cb511a0b7de6e59ae81",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 138,
+      "title": "Pin backend to the final-turn result checks",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/138",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T14:00:59Z",
+      "head_ref": "feature/agent-harness-p2",
+      "head_sha": "7244f8c7305f075cc96c647021797677b4b804e8",
+      "base_ref": "main",
+      "merge_sha": "1939d50a7fcb61bdb4bc98cba84173e7e5fc9a11",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 140,
+      "title": "Pin backend to the depth-one subagent loop",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/140",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T14:51:02Z",
+      "head_ref": "feature/agent-harness-p3",
+      "head_sha": "8c43d4b16ce0d5aa700bfebb77b8a022de532b3d",
+      "base_ref": "main",
+      "merge_sha": "5096a052dcaef7ee08a3251ec50a47bf7f066618",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 142,
+      "title": "Pin P3b background subagents, review, and profile overrides",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/142",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T15:51:57Z",
+      "head_ref": "feature/agent-harness-p3b",
+      "head_sha": "79a6a73052920ba3bd2b4909d8287cf7e908a2e2",
+      "base_ref": "main",
+      "merge_sha": "ec4614322eaded96ee13f576992f016b47648200",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 144,
+      "title": "Add intent-to-workflow execution",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/144",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-02T01:04:03Z",
+      "head_ref": "feature/agent-harness-p4",
+      "head_sha": "cd984219da215db5978e7916c0439df74ce7b5aa",
+      "base_ref": "main",
+      "merge_sha": "3ba104c721013f63be249e2f810376d3d8b26ee3",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 151,
+      "title": "Pin documents to the agent stack completion proposal",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/151",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T14:15:52Z",
+      "head_ref": "refs/pull/151/head",
+      "head_sha": "83b2b0912e6e2e891f16590ca011fa374cb79478",
+      "base_ref": "main",
+      "merge_sha": "2a24d8418a7c0da0428481fd03c315a346eb597c",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 152,
+      "title": "Check nested library pins and test the three agent libraries",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/152",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T12:47:36Z",
+      "head_ref": "refs/pull/152/head",
+      "head_sha": "2e43703838a8fcb84cd00d669f28038b8a8d3efd",
+      "base_ref": "main",
+      "merge_sha": "7dd107bae40a203d684b0c9a3fd81ca316fd8c90",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 154,
+      "title": "Pin the R2 library and backend heads",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/154",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T13:22:55Z",
+      "head_ref": "refs/pull/154/head",
+      "head_sha": "a5377ec2347e08c84d428d980c652355fa7785be",
+      "base_ref": "main",
+      "merge_sha": "0a047db5c9c852539c6a839cf85589729f246019",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 156,
+      "title": "Pin the D1 library and backend heads",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/156",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T14:02:34Z",
+      "head_ref": "refs/pull/156/head",
+      "head_sha": "3cd83db5ca01de2227e8ab668355a431708193f9",
+      "base_ref": "main",
+      "merge_sha": "19b93ed09c0b80de78eed45763b482616b54ed06",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 167,
+      "title": "Add an architecture edge ratchet and waiting-state tokens",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/167",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T16:04:36Z",
+      "head_ref": "feature/architecture-baseline",
+      "head_sha": "4afccef8bd222355657da52ea1a9e07debfc3e8f",
+      "base_ref": "main",
+      "merge_sha": "e294729a44e11b15ab7ba2c70b04eafa235d5f95",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 207,
+      "title": "Add EXT-1 inproc command handler and owner-scoped host handle (minimal set)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/207",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-05T11:48:46Z",
+      "head_ref": "feature/ext-1-inproc-handler",
+      "head_sha": "4801a90319254bd8bbef5e22abf47acb10972014",
+      "base_ref": "main",
+      "merge_sha": "63a62a79ac52cc5d0b5d798dc586195ea842bd51",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 209,
+      "title": "Restore and complete the EXT-1 task card after branch recreation (verification round)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/209",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-05T12:07:12Z",
+      "head_ref": "feature/ext-1-inproc-handler",
+      "head_sha": "4801a90319254bd8bbef5e22abf47acb10972014",
+      "base_ref": "main",
+      "merge_sha": "15ec9bfbc57bbc1f9930ac4c3ef91edc8460ea4a",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 222,
+      "title": "Expose builtin document parsing through the host handle (EXT-5)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/222",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-06T15:14:31Z",
+      "head_ref": "refs/pull/222/head",
+      "head_sha": "f5c83534fe2cc3886842e66c2648362c5fa2af7c",
+      "base_ref": "main",
+      "merge_sha": "c06da5735904e63db4cbcdb75b3b10b48aeffc32",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 224,
+      "title": "Pin the wide-columns xlsx fix",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/224",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-06T15:39:48Z",
+      "head_ref": "refs/pull/224/head",
+      "head_sha": "12cda45fe8cd910253dacd75434efcf203f2ba0f",
+      "base_ref": "main",
+      "merge_sha": "c4985e96ce1c49da88f652e9a2d8ac2bec4a8b01",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 226,
+      "title": "Propose N1/Q1/I1 implementation plans (docs only)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/226",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T02:51:40Z",
+      "head_ref": "refs/pull/226/head",
+      "head_sha": "ddfd6a2b67209a1b9b2ba7810cb10919c0bb9743",
+      "base_ref": "main",
+      "merge_sha": "2147d5cb6566c301eaea3c65448bdda873093aea",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 229,
+      "title": "Propose the RDM phase plan (docs only)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/229",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T04:34:51Z",
+      "head_ref": "refs/pull/229/head",
+      "head_sha": "0384abc9aff3b30f23a4b95c6552e60071f5436d",
+      "base_ref": "main",
+      "merge_sha": "9c9483ac54ff5355c86824ac94097e65e59dcb5d",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 232,
+      "title": "Pin the merged WP5 gate-sinking combination",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/232",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T06:50:22Z",
+      "head_ref": "refs/pull/232/head",
+      "head_sha": "1a4053810acde922b68cca802ae2c7dba4e26ad7",
+      "base_ref": "main",
+      "merge_sha": "ae40cee917ca449fa8e75e6f2a665d94a18e3567",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 234,
+      "title": "Pin the merged I1 command-model and router combination",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/234",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T08:04:20Z",
+      "head_ref": "refs/pull/234/head",
+      "head_sha": "e793587677b73f9e0a8b7b200fb89cf002b71a5a",
+      "base_ref": "main",
+      "merge_sha": "1f7217f5bb2657418845d6bec6ae28c56920ddc8",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 235,
+      "title": "Pin the merged I1 eval-v2 combination",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/235",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T08:44:41Z",
+      "head_ref": "refs/pull/235/head",
+      "head_sha": "9c1cdbb10fe6237b80f40cf5184f2e3ae3378643",
+      "base_ref": "main",
+      "merge_sha": "eafe1e1fbf6874b58f851878c815c2c24e6f8db3",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 237,
+      "title": "Pin the merged superstep engine (Q1 WP1/WP2)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/237",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T09:12:58Z",
+      "head_ref": "refs/pull/237/head",
+      "head_sha": "8a1c84193922530c1489572ef6a1e136594bb1ef",
+      "base_ref": "main",
+      "merge_sha": "3bf2441b05489dfb55b3146aa4e0c53068d34b82",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 240,
+      "title": "Pin the merged SQLite convergence (Q1 WP5)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/240",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T10:38:59Z",
+      "head_ref": "refs/pull/240/head",
+      "head_sha": "1a02139026f412c90799bb01fe023bec173a2888",
+      "base_ref": "main",
+      "merge_sha": "ba36d47c2fbfdd0ba759fe251f87c403a5f7ffc7",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 242,
+      "title": "Take the backend intent slow lane and the I2 port pins (I2 WP3)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/242",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T11:58:02Z",
+      "head_ref": "refs/pull/242/head",
+      "head_sha": "733f3c74745ae46ae71a82b092867c7e4b45adf6",
+      "base_ref": "main",
+      "merge_sha": "d308ed66196b67970de19ad657410daffcca3740",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Dev",
+      "number": 244,
+      "title": "Take the N2 implementation plan and open the N2 task",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/244",
+      "state": "open",
+      "merged": false,
+      "merged_at": null,
+      "head_ref": "feature/agent-stack-n2",
+      "head_sha": "eae6992ae81335df5eb016223e2522fab952ae7f",
+      "base_ref": "main",
+      "merge_sha": null,
+      "merge_in_fixed_main": null,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 14,
+      "title": "界面重构与多用户认证设计提案 + HTML demo（方案 A/B/C + 认证）",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/14",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T10:02:04Z",
+      "head_ref": "refs/pull/14/head",
+      "head_sha": "e601b253bc0d6a3fc762c7495d235b68f3910eb6",
+      "base_ref": "main",
+      "merge_sha": "ab14f62534fc8831db694fa580a7d163a3cc19ff",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 27,
+      "title": "Propose card stream, artifact unification, and project inbox (D44-D52)",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/27",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-09-30T17:45:16Z",
+      "head_ref": "feature/cardflow-future-plan",
+      "head_sha": "4a698869521eaa60b2fba9bdb3196226691bf987",
+      "base_ref": "main",
+      "merge_sha": "437af31118814463cc44d379f7269afd7add62b5",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 31,
+      "title": "Document the base extension roadmap and plugin contract v2",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/31",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T10:47:11Z",
+      "head_ref": "feature/base-extension-roadmap",
+      "head_sha": "a0da588f9035e132bcfd1dcc0ac1dacb62924776",
+      "base_ref": "main",
+      "merge_sha": "f3a3a5deb48e5b1c6ceb1b666d71ed912606c49d",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 32,
+      "title": "Propose the agent harness and link it from the roadmap",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/32",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-01T12:43:26Z",
+      "head_ref": "feature/agent-harness-p0",
+      "head_sha": "a3f0b80759fa01094cb9ee26b2a17dba831317e2",
+      "base_ref": "main",
+      "merge_sha": "357e3fdb246a8a8d562e63e01d5170673bf4dcc6",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 34,
+      "title": "Propose the agent stack audit and completion design",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/34",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-03T14:12:17Z",
+      "head_ref": "refs/pull/34/head",
+      "head_sha": "233dfb54ea1cd8e8085769832eef18fb3eaa04b7",
+      "base_ref": "main",
+      "merge_sha": "76044b5895e8abe5bd1e3bf45ccfe3ea7edcdc42",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 39,
+      "title": "Restore the EXT-1 proposal and request EXT-5 host document parse",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/39",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-06T15:14:15Z",
+      "head_ref": "refs/pull/39/head",
+      "head_sha": "5825cd35f2cde87a737d2dacdd2e4a393063e3bc",
+      "base_ref": "main",
+      "merge_sha": "e53c6bf177ee9bfa2ae85e1baa35378e122577e3",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 40,
+      "title": "Propose N1/Q1/I1 implementation plans for the agent stack",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/40",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T02:51:31Z",
+      "head_ref": "feature/agent-stack-n1q1i1-plans",
+      "head_sha": "54ead4197f844b9547a9275dbf9ba8ff639cb5e9",
+      "base_ref": "main",
+      "merge_sha": "dd9c1ba558b9154a66e1d9bcab1d52dd09ad5a8e",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 41,
+      "title": "Propose the RDM phase plan: direction, invariants, and stage gates",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/41",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T04:34:51Z",
+      "head_ref": "feature/rdm-phase-plan",
+      "head_sha": "b8eaa1676f168ad64c437857e2607e2e213f6672",
+      "base_ref": "main",
+      "merge_sha": "0551d003000107a511f26642e68a947680956fc6",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    },
+    {
+      "repo": "Agent-System-Documents",
+      "number": 42,
+      "title": "Propose the N2 implementation plan: context, protocol, and tools",
+      "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/42",
+      "state": "closed",
+      "merged": true,
+      "merged_at": "2026-10-07T12:38:28Z",
+      "head_ref": "refs/pull/42/head",
+      "head_sha": "96fd6599d1f2b60f44830ddae1b21185713269d9",
+      "base_ref": "main",
+      "merge_sha": "5542319a0474fd4e866b6daacb937b587c833ede",
+      "merge_in_fixed_main": true,
+      "reviews": []
+    }
+  ],
+  "open_pull_requests": {
+    "Agent-System-Dev": [
+      {
+        "number": 244,
+        "head_ref": "feature/agent-stack-n2",
+        "head_sha": "eae6992ae81335df5eb016223e2522fab952ae7f",
+        "title": "Take the N2 implementation plan and open the N2 task",
+        "url": "https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/244"
+      }
+    ],
+    "Agent-System-Documents": []
+  }
+}
@@ -0,0 +1,83 @@
+{
+ "generated_at": "2026-10-08T09:17:18+00:00",
+ "object": "Agent-System-RDM @ 4feb2f0 (pins=v0.1.0 四仓)",
+ "replays": {
+  "make test": {
+   "exit": 0,
+   "receipt": "test.json",
+   "receipt_sha256_16": "beadcc1ee93646d5"
+  },
+  "-ms1 ./docs/requirements": {
+   "exit": 0,
+   "verdict": "PASS",
+   "detail": "fa-chain 1130 切片（含重启存活）；stage-accuracy 100%（5/5，金标与 docProfiles 同源，样本全 BD）；two-speed 快速 0ms/慢速 done",
+   "receipt": "ms1.json",
+   "receipt_sha256_16": "be64043ec470b100"
+  },
+  "make ms0-acceptance (PG_CONTAINER=rdm-review-pg 一次性容器)": {
+   "exit": 0,
+   "verdict": "PASS=9 SKIP=0 FAIL=0",
+   "receipt": "ms0-acceptance.json",
+   "receipt_sha256_16": "b6a2c946d4fe9e50"
+  }
+ },
+ "upload_probes": {
+  "minutes.docx（真实纪要原件，私有：收据仅存本地不入库）": {
+   "exit": 0,
+   "wall_s": 0.78,
+   "parse": "rdm:docx parsed=true",
+   "verdict": "held 无关(疑似)",
+   "labels": "stage= workItem= topics=[]",
+   "note": "零字典命中；快速回执时限达标但无初步归类",
+   "local_receipt_sha256_16": "a29912f84b0c51fe"
+  },
+  "quote.xlsx（旧仓报价单模板）": {
+   "exit": 0,
+   "verdict": "unparsed rdm:unsupported",
+   "note": "原件留档可取回——EXT-5 不在 v0.1.0 pin"
+  },
+  "plan.pptx（python-pptx 构造图文稿）": {
+   "exit": 0,
+   "verdict": "unparsed rdm:unsupported",
+   "note": "同上"
+  },
+  "irrelevant.txt": {
+   "exit": 0,
+   "verdict": "held 无关(疑似)",
+   "note": "零命中挂起，确认前不入库（MS1 第3条行为）"
+  },
+  "broken.docx": {
+   "exit": 0,
+   "verdict": "unparsed rdm:docx parsed=false",
+   "note": "显式告知 zip 无效+原件留档（SR-A5 负例）"
+  }
+ },
+ "entrance_probes": {
+  "POST /api/commands/rdm.ping": {
+   "http": 200,
+   "state": "committed",
+   "note": "命令入口通"
+  },
+  "POST /api/conversations/{id}/messages text=/help": {
+   "http": 200,
+   "note": "对话入口 slash 路由对内置命令通"
+  },
+  "POST /api/conversations/{id}/messages text=/rdm.ping": {
+   "http": 400,
+   "body": "未知命令 /rdm.ping（/help 查看）",
+   "note": "插件命令无 slash 别名——对话入口不可达 RDM 命令"
+  },
+  "POST /api/chat (RDM 工作台 sendChat 的目标端点)": {
+   "http": 404,
+   "note": "端点在 v0.1.0 pin、基座 main、RDM 三处均不存在；工作台自由文本路径 404"
+  },
+  "receipts": [
+   "entrance.json",
+   "entrance2.json"
+  ]
+ },
+ "notes": [
+  "全部收据为 SELF（本机隔离克隆重放；RDM 仓无 CI，不存在 GATE）",
+  "残留进程（非本任务所起，未处置）：PID 2784320 (18799, 主检出 ./data) 与 PID 3096018 (18810, /tmp/rdm-init.* 旧实例)"
+ ]
+}
@@ -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 升钉完成后另行评估）。
@@ -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 任务卡，作为本次候选身份；本文件不手写命令结果。
@@ -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目标未缩水。权限/失效场景复核确认私域与授权知识快照、三权、防换角色自审、撤权、宿主双向绑定等约束已表达。
+本记录仅证明文档检查及相应修订；实际执行能力、测试通过、部署和用户验收均未据此认定。
@@ -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、运行链接与输出。历史任务卡另行映射，原始收据不改。
@@ -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 |
+
+完整哈希应在正式迁移台账保留；本表短哈希用于阅读定位，不作为独立完整性或身份凭据。
@@ -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 只读受控注册表，方案已有严格编制权与部分采纳行为；四项补充用于使既有目标成立，未扩大业务交付范围。
+四项已在方案中修订并补验收场景；未代签用户保留的路线、首批顺序、文档级审批选择和实施授权。
+本记录只证明文档检查及修订，后续真实业务验证仍按方案执行。
@@ -0,0 +1,11 @@
+# 经验：库级 Manager 测试通过 ≠ 跨实例 HTTP 路径正确——进程级黑盒才能抓住短路
+
+- 状态：validated（三条缺陷均在 U7 双进程验收中复现、修复并入 CI 回归）
+- 触发条件/检索词：多实例 / 跨实例 HITL / cancel / 命令总线 / Manager 层单测 / HTTP 黑盒 / 假成功 200 / conversation_id 空 / 落卡短路命令 / U5 vs U7
+- 根因与来源：协作存储 U5 用真库直接调 `runmgr.Manager` 覆盖争抢/围栏/命令语义，**绕过 HTTP handler**。U7 `tests/integration/multi-instance/` 起两个真实 `serve` 进程共享 PG 后抓出三条生产路径缺陷（均已有 backend 回归）：① HITL resolve 在非执行实例先把卡标 resolved，命令 fallback 的 `!card.Resolved` 判定被跳过，执行者永远等不到答案；② 跨实例 cancel 命令 `conversation_id` 传空串，消费侧执行权 JOIN 永不命中；③ `CancelRun` 在非执行实例无句柄时返回 nil，HTTP 层 200「假成功」吞掉命令路径。库级绿与进程级红可以同时为真。
+- 下次应做的检查：凡涉及「任意 API 实例发起、执行实例消费」的能力（取消、HITL、命令、租约接管），验收矩阵须含 **至少一条双进程 HTTP/SSE 黑盒**（或等价：经真实 handler + 命令总线落库再消费），不能只用 Manager/Store 直调冒充跨实例已过。写回归时优先钉住「非执行实例的 HTTP 状态码与执行者观测到的最终状态」成对断言。
+- 验证方法与防护：已落实——Dev `make test-multi-instance`（CI `test-pg` 必跑）覆盖跨实例读/SSE/409/HITL/取消/崩溃恢复/重启不变量；三条缺陷各有 backend 回归测试。建议保持：新增跨实例命令路径时先加进程级场景再声称 U5/U7 完成。
+- 适用与不适用：适用多实例共享权威存储、命令经 DB/总线投递的架构；不适用纯单实例本地句柄路径，也不替代库级语义单测（二者互补）。
+- 尚缺证据/防护：双主机（跨机网络）C3 与正式容量窗口不在本教训范围内；本条只固定「测试层级」缺口。
+- 复核人、日期、版本：weichen，2026-10-12；依据 Dev 放行检查单 A6/C1 与 `tests/integration/multi-instance/README.md`「已实测发现并修复的缺陷」
+- 替代/退役条件：若跨实例命令路径全部强制经同一 HTTP→命令总线集成测试门禁，且历史三条回归仍绿，可将本条降为参考；不得在无门禁时退役。
@@ -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）观察，已被后续事件取代。
@@ -0,0 +1,55 @@
+# U7 容量测量窗口报告（SELF，2026-10-12）
+
+来源标注：**SELF**（本机隔离栈执行；非 CI GATE、非独立 REPLAY）。不得单独据此放行第二实例写流量或双主机部署。
+
+## 1. 环境与被测对象
+
+| 项 | 值 |
+|---|---|
+| 主机 | Linux，32 逻辑 CPU，122 GiB RAM（约 98 GiB available），磁盘 1.9T/余 1.1T |
+| k6 | v2.3.0（Homebrew 固定位 `/home/linuxbrew/.linuxbrew/bin/k6`） |
+| 拓扑 | 双 `serve` 进程共享隔离 PG（`u7load`），`--tier team --auth on --mock --disable-exec-tools` |
+| Dev HEAD（任务分支测量时） | `b6f78b503ee2e3d6f71663d5330a18adbe743239`（ladder/s60 证据点；s2h 同工作区续跑） |
+| Backend gitlink | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` |
+| Documents gitlink（测量时） | `8d0810bd35f4934e0ad37fb96d7bab6d7a732473` |
+| 入口 | Dev `tests/load/collaboration/run_load.sh --seed contract --instances 2` |
+
+## 2. 数据集（B5 contract）
+
+每段窗口独立灌库（编排脚本每次 `DROP/CREATE u7load_app`，无法跨次复用）：
+
+| profile | results 目录 | messages | knowledge | seed 耗时 |
+|---|---|---|---|---|
+| ladder | `tests/load/collaboration/results/20261012-064730/` | 1 000 000 | 100 000 | ≈12.0 s |
+| sustained60m | `…/20261012-070510/` | 1 000 000 | 100 000 | ≈14.5 s |
+| sustained2h | `…/20261012-081025/` | 1 000 000 | 100 000 | ≈11.2 s |
+
+拓扑：10 seed 用户 × 5 项目 × 10 会话；约 10% knowledge `owner=''`（共享基座）；**未**写入 `knowledge_vectors`。
+
+## 3. 负载结果（阈值：读 P95≤300ms、P99≤1s、失败率≤0.1%；SSE P95≤1s；dup_seq=0）
+
+| profile | 读 P95 | 读 P99 | fail_rate | checks | expected_contention | SSE A p95 | SSE B p95 | dup_seq | orphan runs |
+|---|---|---|---|---|---|---|---|---|---|
+| ladder（10→30→100，~12m） | 15.5 ms | 44.3 ms | 0 | 134922/0 | 549 | 17.5 ms | 33.0 ms | 0 | 0 |
+| sustained60m（~60m @30 VU） | 3.9 ms | 6.5 ms | 0 | 504399/0 | 69 | 5.7 ms | 4.4 ms | 0 | 0 |
+| sustained2h（~2h @30 VU） | 6.2 ms | 13.5 ms | 0 | 1008771/0 | 477 | 3.9 ms | 4.2 ms | 0 | 0 |
+
+命令（每段）：
+
+```bash
+tests/load/collaboration/run_load.sh --seed contract --profile <ladder|sustained60m|sustained2h> --instances 2
+```
+
+原始产物（gitignore，留在任务 worktree `results/<ts>/`）：`k6-summary.json`、`sse-probe-a.json` / `-b.json`、`seed-manifest.json`、`invariants.txt`。任务卡经 `make evidence` 写入阈值复核脚本输出（SELF）。
+
+## 4. 结论与边界
+
+- **容量合同（B2/B3/B5/B4/C2）本机 SELF 全过**：阈值与不变量满足建议合同；数字绑定上表 SHA 与 results 目录。
+- **仍不放行第二实例写**：检查单要求 CI GATE 或独立 REPLAY 才用于放行；本报告仅为 SELF。C3 双主机、C4/C5 运维演练、B6 pgbench 未做。
+- **不承诺跨机/生产容量**：mock 模型、同机双进程、NVMe/本机 PG；换硬件或真实模型须重测。
+
+## 5. 建议下一步
+
+1. 独立审阅者 REPLAY 最小集（至少 `ladder --seed contract --instances 2`）后，方可讨论双进程写放行。
+2. 用户指定第二主机后跑 C3。
+3. 排期 C4/C5 运维演练；可选 B6 pgbench 只读基线。
@@ -0,0 +1,100 @@
+# U7 运维演练与数据库基线报告（SELF，2026-10-12）
+
+来源标注：**SELF**（本机隔离栈执行；非 CI GATE、非独立 REPLAY）。用户 2026-10-12 决定不做容量重放。不得据此放行第二实例写流量。
+
+## 1. 被测对象
+
+| 项 | 值 |
+|---|---|
+| Backend gitlink | `8e509775d39d1455b69be44803037faa7af844b4` |
+| B6 Dev HEAD | `b2e129ab3f3bdf222f16040fcd0513872d0e2a3c` |
+| C4 Dev HEAD | `308f33665eb2dfaf9ae661e87df8898c3c2ecb3a` |
+| C5 Dev HEAD | `792574692609d9bfdf113e2dc5af6f43c9a176dd` |
+| 主机 | 32 逻辑 CPU，122 GiB RAM；演练开始时 load average 见各 `host.txt` |
+| 入口 | `tests/load/collaboration/run_pgbench.sh`；`tests/ops/run_fault_drill.sh`；`tests/ops/run_backup_drill.sh` |
+
+原始输出在测量 worktree 的 `results/`（gitignore），不入库。任务卡 evidence 为 SELF。
+
+## 2. B6 pgbench
+
+结果目录 `tests/load/collaboration/results/pgbench-20261012-131948`。隔离实例 `u7bench`，scale 100，每档 60 秒，`-M prepared`。`max_connections=100`，`superuser_reserved_connections=3`，100 客户端封顶为 95。六档失败事务均为 0。
+
+| 模式 | 客户端 | tps | P50 | P95 | P99 |
+|---|---|---|---|---|---|
+| select-only | 10 | 535646 | 0.018 ms | 0.024 ms | 0.030 ms |
+| TPC-B 类 | 10 | 18798 | 0.339 ms | 0.673 ms | 5.560 ms |
+| select-only | 30 | 952115 | 0.026 ms | 0.057 ms | 0.078 ms |
+| TPC-B 类 | 30 | 52224 | 0.493 ms | 1.002 ms | 1.777 ms |
+| select-only | 95 | 904708 | 0.087 ms | 0.180 ms | 0.417 ms |
+| TPC-B 类 | 95 | 50607 | 1.041 ms | 3.361 ms | 18.106 ms |
+
+主机不空闲。这是数据库参考基线，没有业务阈值，也不替代容量窗口。
+
+## 3. C4 断连
+
+结果目录 `tests/ops/results/fault-20261012-142734`。PG 18991，应用 18990/18992，Redis 18993。
+
+| 判据 | pg-stop | pg-kill |
+|---|---|---|
+| F1 有界失败、进程仍在 | 过 | 过 |
+| F2 不回落 SQLite，新进程拒绝就绪 | 过 | 过 |
+| F3 恢复后两侧各 5 次写入 | 过，RTO 不到 1 秒，未重启应用 | 同左 |
+| F4 失败 requestId 重放恰好一条 | 过 | 过 |
+| F5 dup_seq=0、seq 无洞、无非终态 run | 过 | 过 |
+
+Redis 限额 20 次/分钟，两实例各突发 40 个读：
+
+| 判据 | 结果 |
+|---|---|
+| G1 共享限额 | 放行 20、429 为 60、其他错误 0 |
+| G2 断连 | 放行 40、429 为 40、其他错误 0；已确认写入仍在 |
+| G3 只拉起 Redis | 放行回到 20；`rl:*` 均有过期时间 |
+| G4 | 发现：日志看不到降级计数 |
+| G5 | 发现：Redis 不通时新进程拒绝启动 |
+
+`runtime.redisAddr` 没有调用者可写的产品入口。演练用 SQL 写入默认 owner `local` 的 `user` 设置，并保留 mock。
+
+## 4. C5 备份与恢复
+
+结果目录 `tests/ops/results/backup-20261012-153441`。源 PG 18994，恢复目标 18997。合同数据量 seed 约 12 秒。
+
+| 判据 | 结果 |
+|---|---|
+| K1 备份有效 | 过。`failed_count=0`，`archived_count=80`，`pg_verifybackup` 与 `pg_restore --list` 退出码 0 |
+| K2 RPO≤5 分钟 | 过。64 秒 |
+| K3 RTO≤60 分钟 | 过。4 秒。恢复后登录、列项目、读会话均为 200 |
+| K4 工件与权限 | **FAIL**。五次上传都没有拿到工件编号 |
+| K5 不变量 | 过。dup_seq=0，seq 无洞；恢复后消息/事件/知识/run 计数与故障前一致（消息 1 000 120）；非终态 run 为 0 |
+| K6 逻辑恢复 | 过。`pg_restore` 退出码 0，约 4 秒；计数等于 dump 时快照（消息 1 000 000，知识 100 000） |
+| K7 权限与泄密 | 过。备份目录 700、文件 600；结果文本里没有连接串。静态加密与凭据演练记 N/A。归档和数据在同一块盘，没有模拟存储全毁 |
+
+恢复后的计数与故障前一致，说明已提交的标记都在。64 秒是最后一条成功标记的确认时间到故障时刻的间隔；窗口末尾有的写入因为会话仍被 mock run 占用而没有落库。
+
+K4 的原因在源应用日志：未设置 `BLOBSTORE_S3_ENDPOINT` 时，`NewS3FromEnv` 返回空的 `*S3`。这个空指针被放进 `blobstore.Store` 接口后不再等于 nil，`finishOpen` 不会回落本地目录，上传在 `blobstore.(*S3).Put` 空指针 panic。产品代码未改。因此工件 sha256 和跨用户拒绝没有测成。代码里本地后端的 `content_path` 是绝对路径；这次没有成功上传，所以没有用恢复后的下载来核验。
+
+同日另一次恢复（`backup-20261012-150713`）在数据目录复制之后起不来，因为 socket 路径超过 107 字节。正式这次把 socket 放到 `/tmp/u7bk-18997`。
+
+## 5. 放行（2026-10-12 当时）
+
+B6、C4 为 SELF 通过。C5 的库恢复为 SELF 通过，工件恢复失败。第二实例写流量仍不放行。
+
+当时还没做、该任务不启动的三项：
+
+- 独立 REPLAY，或把 C4/C5 的快速档接进 CI 成为 GATE（需要平台准入）。
+- C3 双主机。
+- 上传在未配置对象存储时 panic，需要单独的产品修复后才能重测 K4。
+
+## 6. 2026-10-13 K4 重测
+
+上传 panic 已在 store 边界修复：带类型的空对象存储（未设置 `BLOBSTORE_S3_ENDPOINT` 时的 `(*S3)(nil)`）视为未配置，回落本地工件目录。已构造的对象存储保持不变。Backend 提交 `46073d30`，Dev 被测头 `a83588dd`，backend gitlink 同为 `46073d30`。
+
+重跑入口仍是 `tests/ops/run_backup_drill.sh`。结果目录 `tests/ops/results/backup-20261013-013354`（SELF）。原始结果另存于仓外 `/home/weichen/projects/u7-k4-retest-preserved-20261013`。
+
+| 判据 | 结果 |
+|---|---|
+| K1–K3、K5–K7 | 过。RPO 65 秒，RTO 3 秒。`pg_verifybackup` 与 `pg_restore --list` 退出码 0，逻辑恢复约 5 秒，恢复后计数与故障前一致 |
+| K4 工件与权限 | **过**。5 个工件 `checked=5`、`missing=0`、`mismatch=0`。跨用户访问项目和工件均为 404 |
+
+`content_path` 仍是绝对路径，快照继续还原到原目录。静态加密、凭据演练和整盘损坏仍是 N/A。
+
+第二实例写流量仍不放行。剩下的门槛是独立 REPLAY 或经平台准入后的 C4/C5 CI 快速档，以及 C3 双主机。