Record the corrected workbench candidate and single delivery record

Why: Keep planning progress aligned with actual implemented corrections without duplicating CI and merge state. Evidence: Reference UI155, Frontend210 and 19 local browser cases via Dev native receipts; final GATE remains separately tracked. Impact: Planning metadata only; no deployment or model-routing claim. Refs: work-companion-ui r0.2/r1, UI01-UI13
Record workbench implementation evidence and remaining delivery gates
2026-10-12 19:07:32 +00:00 · 2026-10-12 16:59:30 +00:00 · 2026-10-12 16:32:44 +00:00 · 2026-10-12 15:52:51 +00:00 · 2026-10-12 15:49:44 +00:00 · 2026-10-12 15:07:07 +00:00
14 changed files with 2161 additions and 20 deletions
@@ -21,3 +21,5 @@ docs/
 [实施记录](docs/records/2026-09-29-implementation.md) · [设计方案](docs/proposals/2026-09-29-system-skeleton-design-and-plan.md)

 规范基线：Development-Guidelines（Dev 仓 `deps/development-guidelines`）。
+
+相关方案：[RDM 功能、实现与计划矩阵及整改方案 r1（2026-10-12）](docs/proposals/2026-10-12-rdm-function-implementation-plan.md)——RDM 全系统缺口矩阵与 U1–U9 工作包。
@@ -8,10 +8,10 @@ product_contract_source: ce-plan-bootstrap

 # 多人协作存储与分布式演进方案 - Plan

-修订：r1；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：方案获批发布，实施自首选增量 U1+U2 启动；业务实施/迁移/压测/部署仍为 NOT_RUN，逐项以实施任务卡为准。
+修订：r2.2；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：U1–U7 **代码与测试已合入**（Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164)；Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442)；闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等）。正确性 A1–A7 与 B1 已绿（CI/SELF）。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**（见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)）。2026-10-12 用户决定不做容量重放；同日 B6 pgbench、C4 断连、C5 库恢复已有本机 SELF（见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)），C5 工件恢复 K4 失败。**SELF≠GATE/REPLAY**，双主机 C3 未做——**仍不放行第二实例承接写请求**。
 需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
-需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-11（Asia/Shanghai）。
-关联任务：Dev `.task/feature-collaboration-storage-plan.md`（方案任务，已发布）；后续 U1+U2 实施由独立任务承接。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-12（Asia/Shanghai）。
+关联任务：方案与 U1–U7 实施卡已归档；容量收尾见 Dev `.task/feature-u7-capacity-wrap-measure.md`。放行检查单：Dev `docs/release-multi-instance.md`。
 正文中的源码路径以 Agent-System-Dev 为根；工作包中的 `internal/` 简写指 `modules/backend/internal/`；文内相对链接以本文为根。

 ## 1. 推荐结论与边界
@@ -246,8 +246,8 @@ SQLite 本身支持可靠事务与多人经同一应用访问；WAL 提升读写

 必需观测：API P95/P99与预期/非预期错误，DB pool wait/连接数/慢查询/锁等待，队列长度/最老年龄，run 租约/过期写拒绝/未知副作用，SSE cursor lag/补查次数，Redis 错误与降级，检索耗时/召回抽样，备份时间与恢复结果。日志只记录 request/run/owner 的安全标识，不记录 DSN、密钥或文档正文。

-当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认；容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
+r1 为方案与 SELF 调查记录。r2 起：U1–U7 代码与测试已合入且正确性 CI 绿。r2.1：本机双实例 contract 容量窗口（ladder / 60m / 2h）SELF 全过，见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。r2.2：用户于 2026-10-12 明确不做容量重放；同日完成 B6 pgbench、C4 PG/Redis 断连、C5 物理备份与 pg_dump 恢复的本机 SELF，见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)。C4 通过。C5 的库恢复通过（RPO 64 秒，RTO 4 秒），工件上传在未配置对象存储时 panic，K4 失败，产品代码未改。本地 SELF 不能冒充 GATE/REPLAY 放行；双主机仍缺。部署与第二实例写流量仍未授权。

-方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
+方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。

-首选下一增量是 **U1 + U2 的详细实施与测试合同**：固定目标实例与 PG 测试环境，解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行；不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。
+首选下一增量不要自动开工。剩余放行门槛是：独立 REPLAY，或把 C4/C5 快速档接入 CI 形成 GATE（需平台准入）；以及 C3 双主机（需第二台机器）。在此之前要先修上传缺陷：未设置 `BLOBSTORE_S3_ENDPOINT` 时，空的 `*S3` 被放进对象存储接口，上传 panic，C5 的 K4 因此失败。GATE/REPLAY 与 C3 未齐、K4 未重测通过前，不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。
@@ -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 实施计划后另开实施任务，本设计任务不自动启动写代码。
@@ -77,7 +77,14 @@ Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」
 - 工作区：前端「任务页面」容器显示最新页（pin/follow 测试覆盖）。
 - 收据：Dev 任务卡 feature/generative-ui-u7-acceptance（SELF；CI GATE 随发布 PR）。

-### 已知边界与后续项
+### 现场体验驱动的修复记录
+
+| 日期 | 症状 | 修复 | PR |
+|---|---|---|---|
+| 2026-10-12 | `POST /api/surfaces/{id}/actions` 对无确认卡的 committed 动作 panic（nil Card） | dispatcher 空指针守卫 | Backend#173 |
+| 2026-10-12 | `system.intent` button 动作恒报 missing text | action data 键上浮到命令 params | Backend#174 |
+
+## 已知边界与后续项

 - 自动触发 opt-in：settings `plugins.generative-ui.autoPresent`（默认关；须同时
  Surface activation）；语义事件 + 预算≤3/时 + 冷却≥60s；设计见
@@ -86,7 +93,9 @@ Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」
  不嵌套分发；提案 `2026-10-12-generative-ui-bclass-help-intent.md`）；其余仍逐条评审。
 - 人类可用性对照以 owner 实际使用替代（2026-10-11 用户裁定），本轮体感「初步不错」，
  小问题另行修复。
- 部署与运行验收按独立授权推进。
+- 部署与运行验收：本机 `prod` 实例已登记（`scripts/svc.sh prod`，`--auth on`，
+  PG `pg1/prod`，来源 `dev@c76f2bb`+后端 nil-card 修复）；验收覆盖启禁、present、
+  B/C 类动作、项目聚合、未登录 401。

 ## 三、结论

@@ -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 |
@@ -7,10 +7,12 @@ execution: code
 product_contract_source: ce-plan-bootstrap
 ---

-# 服务重启与全量数据恢复方案 r2
+# 服务重启与全量数据恢复方案 r3

-确认状态：待人工评审。当前交付为源码调查、方案与实施/验收计划；业务实施、故障注入、部署、运行验收均为 NOT_RUN。
+确认状态：原 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 根目录为基准。

@@ -34,20 +36,26 @@ product_contract_source: ce-plan-bootstrap

 ## 2. 当前事实及重点差距

-本次源码基线：Dev `5e57029b439e5690f28dc6002f9784f0b08920eb`；Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `aaced8796bb45d151833e12bc1cc17fc5090ef6d`；Documents `23e2276905eaf3d5b266a5218a53a12a38321284`。来源为 SELF·源码观察，原始命令和输出由 Dev `make evidence` 写入本任务卡；风险是源码推断，不是已重现事故。
+本轮源码基线：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（任务元数据提交）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。草案独立 Documents 基线 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，未推进 Dev gitlink。原 r2 对象为历史，不用于证明当前运行行为。
+来源为 SELF·只读观察；原始脱敏命令和运行输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。故障表现为源码推导，故障／恢复／耐久性验收 NOT_RUN。
+最终 Dev 同步基线 `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9` 已纳入主干的 svc 实例内存态修复和 Documents 指针 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`；Backend／Frontend 未变。旧 gitlink 是启动时点，本轮仅同步权威上游，未推进本轮草案组合或重复实现该修复。

 | 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
 |---|---|---|
-| 数据库绑定 | `scripts/svc.sh:1373` 已统一解析 dbref/DSN/config；裸启动、restart/deploy 停前预检已接入 | 自定义 data/plugins 在参数重建时可能漂移；临时环境配置无法保证下次存在；配置多次逐键更新有崩溃中间态 |
-| 服务生命周期 | svc 管理 agent/static/postgres；PostgreSQL 复用 pgdata；分发仓有单应用 systemd 模板 | svc 没有服务组依赖恢复与持久启动意图；无统一进程组监管；不管理 Redis 类型 |
+| 数据库绑定与身份 | svc 统一解析已接线；manifest/marker 和 Backend DB identity 已存在；manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env；自定义根和 legacy/direct 启动需要完整核验；identity 不等于活动服务独占锁 |
+| 服务生命周期 | svc 已有 desired/autostart、recover、watchdog timer；PG 优先拉起 | 没有完整服务组依赖／单一进程组监管；不管理 Redis 类型；登记版本与实际二进制可能不一致 |
 | 启动与停机 | 启动对账开放 run；优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前；HTTP停机超时可跳过flush；无所有worker等待；子代理 cancelled 可覆盖 interrupted |
 | 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消；子代理先派生再写文件标记；notice消费非事务且绕过PG会话占用 |
 | 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease，终态有fencing；额度有持久表 | 续租只有定义未接入生产调用；15分钟租约可过期；额度无崩溃回收；不能据此宣称安全接管 |
 | 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行，kill窗口丢命令；跨实例取消入队缺conversation；Surface失败仍可清pending且仅扫100条 |
 | 工具副作用 | Native Session已有tool intent/result转录、安全重放判定；Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义；Native的未知效果被写成工具错误后仍可继续模型，尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 |
-| 文件与备份 | blob临时写+rename；工件元数据在DB；SQLite在线备份；svc有pg_dump | 覆写文件与更新元数据不是同一原子提交；未显式fsync；DB备份不含上传、工件、工作区、转录、配置/版本 |
+| 文件与备份 | blob temp+rename、SQLite 一致性快照、pg_dump 已存在；Native 转录 Write→Sync；manifest 有原子同步链 | 工件原文先覆写再更新 DB，无不可变版本；agent 快照缺权威 manifest，PG 和文件快照不是同一恢复点 |
+| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接；数据库事务可排队 | 无跨进程活动服务独占；恢复扫描全部开放 run，第二个服务可打断第一服务；不具备 PG 的会话执行租约 |

-当前登记元数据显示 dev 绑定 `pg1/agent`，部署制品的 Backend revision 与上述Backend一致；这只证明登记和制品元数据。**实际运行进程的数据库身份、全栈恢复、数据耐久性尚未实测，不能写为PASS。**
+2026-10-12 17:37:03（Asia/Shanghai）实际 dev 进程打开 `runtime/dev/data/agent-system.db`，DB marker 为 `sqlite`，运行 Backend `5e8ada7`；没有登记 PG 绑定。候选 rdmcand 已停止且登记来源与实际文件版本不符。前一轮共享数据观察是历史风险线索，不冒充当前双进程事实。**实际文件／marker 已核对，不等于全栈恢复或断电耐久性 PASS。**
+
+当前 PG 事件总线已有真重连、分页追赶和周期补查，Native 已接持久工具转录；这些基础不重复建设。SQLite 应用连接未显式声明 synchronous；诊断连接 PRAGMA 不能证明应用配置，见 R12。
+18:14:09（Asia/Shanghai）重新实测：外部流程已将 rdmcand 拉起于独立数据根，实际 DB inode 与 dev 不同且制品／登记版本一致；dev 仍打开原库、账户最后设密时间未前进。当前共享现场已缓解；U8 的剩余任务是强制运行时防误用和隔离验收，不重复执行已完成的人工分根。完整停机／恢复和锁能力仍 NOT_RUN，本轮没有改变服务或数据。

 旧报告中“DSN重启丢失”“迁移DDL与版本分开提交”“通知仅内存”等问题已有源码改进，本案只验证并复用这些基础，不把旧缺陷重新列成新建设。

@@ -65,6 +73,8 @@ product_contract_source: ce-plan-bootstrap
 | R8 | 停机与就绪 | 停机先拒绝新工作再排空；全部worker、sidecar和工具子进程收口；错误不跳过后续清理；ready反映业务可用 |
 | R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同；备份恢复到新目标并完成业务/权限/文件对账；不在普通启动覆盖现库 |
 | R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 |
+| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时；直接二进制、路径别名和 legacy 入口同样受保护；账户短事务 CLI 不启动第二运行时；测试实例使用独立根 |
+| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略；文件和目录同步覆盖权威对象；DB/文件持久失败不能确认成功；未实测的断电 RPO 保持候选 |

 覆盖“所有数据”需要先完成数据归属清单：除Backend业务表，还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性；无法证明可恢复的必需插件阻塞全系统签收，不能只恢复Backend便宣称全部完成。

@@ -114,6 +124,12 @@ flowchart TB

 systemd的顺序依赖不能替代DB可用性检测；需真实探测，且明确依赖断开后的重连/恢复政策。监管策略参考systemd官方[service契约](https://github.com/systemd/systemd/blob/main/man/systemd.service.xml)与[进程组停止契约](https://github.com/systemd/systemd/blob/main/man/systemd.kill.xml)。

+KTD13. **SQLite 活动服务锁由 Backend 强制。** 在迁移和启动 run 对账之前按实际 DB／数据资源取得 OS advisory lock，持有至运行时退出；覆盖规范化路径和文件别名。marker/PID 不替代锁，SIGKILL 后由 OS 释放。合法账户 CLI 只核验同实例和兼容 schema 后做 DB 短事务，不启动 Manager；迁移独立维护。锁文件丢失或 DB 替换导致身份改变时拒绝自动续跑，不能新建可绕过的锁继续。
+
+KTD14. **初始化与事故后缺库分开。** 已登记实例启动和运维先验证预期库／marker，缺失则阻塞；显式 init 才允许创建。SQLite 可靠档明确 WAL＋FULL 并核验每个连接；PG 核验实际 fsync/synchronous_commit/full_page_writes 等，不用诊断连接默认值证明应用配置。[SQLite WAL](https://www.sqlite.org/wal.html)、[PostgreSQL WAL](https://www.postgresql.org/docs/current/runtime-config-wal.html)。
+
+KTD15. **manifest 单一权威与派生视图修复。** 复用现有 temp→fsync→rename→dirsync；读侧直接消费 manifest 或验证派生 revision。manifest 提交后、svc.env 派生前崩溃可重新生成视图，不能按旧派生配置换库。未知制品能力、登记／实际版本不符报告并拒绝危险操作，不猜测。
+
 ## 5. 启停流程与恢复政策

 ### 5.1 启动和优雅停止
@@ -127,6 +143,7 @@ sequenceDiagram
  C->>D: 校验manifest、数据身份与操作锁
  C->>C: 启动归本组管理的依赖并探测
  C->>A: 启动固定版本
+  A->>A: SQLite取得活动服务锁；PG按既有执行所有权合同
  A->>D: 校验schema、文件与恢复候选
  A->>W: 完成插件/权限/预算/工作区全部装配
  A->>D: 分类认领、对账未知效果、恢复命令与额度
@@ -138,6 +155,7 @@ sequenceDiagram
  W-->>A: bounded join与子进程结果
  A->>D: 持久化恢复意图、flush、收口许可/所有权
  A->>D: 关闭存储
+  A->>A: 释放本进程SQLite活动服务锁
  A-->>C: 停机结果（含未完成原因）
  C->>C: 复核进程组消失；逆序停止独占依赖
 ```
@@ -178,7 +196,7 @@ stateDiagram-v2

 `recovering/hold`在这里是目标业务语义，**不是声称现有Core枚举已支持**。过渡可用恢复账本表达；若新增公开状态，Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留，不强改成成功。

-用户侧复用现有任务状态、对话卡和管理员恢复入口，显示恢复原因、进度和允许动作；SSE按持久seq补发并丢弃旧事件，页面刷新重载权威快照。断连或无增量不能推断任务完成。实施界面前重读根DESIGN.md并遵循UI令牌、Collapsible和单异步状态所有者规则。
+用户侧复用现有任务状态、对话卡和系统管理区，显示恢复原因、进度和动作。当前只有管理员恢复 API 基础，Frontend 对账接线待 U4 实施，不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件，刷新重载权威快照；断连不推断完成。实施界面先读 DESIGN.md，遵守令牌、Collapsible和单异步状态所有者。

 ## 6. 全量数据与组合备份

@@ -193,12 +211,16 @@ stateDiagram-v2

 普通启停不从备份还原；数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行，禁止start自动覆盖当前数据。

+当前 agent backup 只复制 svc.env、history 和 data（逐 SQLite 一致性导出），不含权威 manifest，在线非 DB 文件与 DB 没有统一快照时点；它是数据目录快照，不是完整恢复包。当前 pg_dump 默认在 runtime 子目录，完整包及副本须放在数据／runtime 生命周期之外；生成时使用受限临时目录，校验成功后原子发布完成标记。半成品不列作恢复点，完成且验证的新备份存在前不执行保留策略删除。
+
 首期备份取得明确停写窗口：关闭准入、排空或隔离在途操作、停止全部相关写者，核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致；写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点，manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。

 恢复到新目标首先处于隔离验证模式，不启动任务调度/副作用，也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离：可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离；不得为此擅自轮换共享凭据。生成新的恢复权威代次，并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏；旧实例不可联系不能当作停止证明。无法核实则保持副作用hold，只开放受权的数据核验。

 同时对账恢复点至故障/隔离完成期间的外部效果：它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对，将已确认动作登记到恢复账本，确认安全后逐项解锁；不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。

+灾难恢复另设安全状态门禁：开放正常认证前作废备份中的全部会话和未使用登录 Key，防止已注销／消费的凭据复活。恢复点后的改密、长期 Key 撤销、角色／成员／插件授权变更与独立受信记录核对；缺记录或无法证明当前有效性时，相关主体／资源保持鉴权隔离，有权 owner／运维重新建立凭据或确认授权后开放。新执行 epoch 不代替认证撤销。普通启停／更新不执行此规则；普通账户恢复保留集成 Key 的合同也不允许灾难恢复盲目启用旧 Key。
+
 PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续WAL，不能用pg_dump冒充其基础备份，依据[PostgreSQL备份与PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)。SQLite使用现有一致性备份接口，不能在线只复制.db遗漏WAL。文件内容先耐久发布再提交DB引用，备份保留覆盖恢复点所需的对象版本。

 备份副本及密钥与原数据同级保护：加密、专用受限目录/角色、异机或异故障域副本、保留期限与清理owner；密钥须独立可恢复。拟定每日日常备份、持续WAL、每月及重大升级前恢复演练，频率按批准的RPO与数据量固定。实际恢复须验证登录、跨项目隔离、历史文档与附件、任务/HITL、工件下载和插件业务链；恢复时间从故障触发开始计时。
@@ -211,12 +233,16 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W

 ### U1. 实例与数据恢复身份

+当前 manifest／DB identity 基础已在源码，既有合同见 Dev `docs/recovery/u1-identity-manifest.md`；本轮只规划消费缺口、派生修复和显式 init/restore，不重复建立身份层。
+
 对应R2/R3/R9；无前置。范围：`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。
 做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口；保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归，再改解析器。
 验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统；更换二进制路径/程序版本或以不同cwd调用svc后，DB identity、数据/工件/工作区根与插件组合保持一致（对应R2更换程序/cwd条款）。使用真实PG特有测试记录核对，桩测试只能辅助。

 ### U2. 服务组与进程监管

+当前 recover/watchdog/desired 已有首切片，余量为服务组、依赖 readiness、唯一监管与完整操作恢复，不再记为全部未实现。
+
 对应R1/R8；依赖U1。范围：svc组编排、可选Redis适配、分发仓`deploy/agent-system.service`及安装接线、新增隔离服务组故障测试。
 按KTD3/KTD4建立依赖图、desired state、可恢复lifecycle operation与单一监管；加入boot/start/exe身份与进程组校验。必需/可选、受管/外部资源由manifest决定。首次切监管在明确停机窗口完成，失败回到原监管且不形成双启动。
 验收：全组停止后启动；先PG后应用；主动stop保持停止；kill自动退避恢复；主机重启按策略恢复；PID复用、残留子进程、端口冲突、依赖启动失败、不透明外部DB均正确拒绝/报告；不得停止其他服务组的共享依赖。
@@ -231,6 +257,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W

 对应R4/R5/R7；依赖U3，并复用U5所有权接口；U4/U5作为同一安全交付批次，完整性验收前不开放自动续跑。范围：runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。
 落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围；若新增recovering/hold为公开状态，设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表，作为设计评审前提。
+Frontend 接线复用任务／对话卡和系统管理区：有权 owner/admin 查看具体 operation、未知原因和证据引用，提交已完成 receipt、未执行终态及旧请求隔离证明，或明确放弃。提交防重复，失败保留输入与原因，成功重载权威状态；Backend 按 operation 权限／版本／epoch 裁决，不以当前整 run release API 代替逐项对账。浏览器验收覆盖发现 hold→对账→剩余步骤恢复，拒绝越权和「放行即重跑」，不新增页面。
 验收：排队/主run/子run/HITL/索引各类任务kill并两次恢复；工具“完成外部动作、结果未提交”只hold不重做；查询暂未发现但外部请求稍后完成时不发送第二次请求；幂等目标使用同operation key；Native pending intent只由统一账本决策，不生成普通错误后绕过hold；确认一个operation完成后执行剩余必要步骤，不假结算整run；未知工具默认隔离；撤权后禁止续跑；无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源，未跑标NOT_RUN。

 ### U5. 所有权、额度、命令、通知与投影闭环
@@ -244,6 +271,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
 对应R3/R7/R9；依赖U1/U3，恢复账本完整验收依赖U4/U5。范围：blobstore/content、workspace与checkpoint、插件恢复适配合同、svc deploy/update/backup、分发仓安装、备份manifest与restore测试。
 按KTD11发布不可变版本，扫描缺失/孤立对象；登记全部插件/下游存储；按第6节生成一致恢复点、保护副本、恢复到新目标；候选完整构建后切版本，保留兼容上一组合。
 验收：对象写后DB提交前kill；覆盖发布过程中kill；日志尾截断/文件缺失保留现场；备份恢复后原文hash/权限/插件链一致；恢复新目标后旧实例复活仍不能产生外部效果，未完成旧写路径隔离时新目标不调度；恢复点后已发生的外部效果对账完成前保持hold；升级ready失败可在兼容条件下回退；不兼容schema拒绝程序自动回退；数据回退不静默丢新写入。
+另覆盖恢复点后注销会话、消费／撤销登录 Key、撤销集成 Key、改密与撤回角色／项目／插件权限：恢复旧包后旧会话和登录 Key 不再有效，无法证明有效的长期 Key／授权保持隔离；owner 正常确认后的新凭据可用。与普通重启原密码保持分别签收。

 ### U7. 故障验收与交付放行

@@ -253,11 +281,28 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W

 建议交付批次：A=U1/U2/U3（可靠启动及安全停机，自动任务续跑关闭）；B=U4/U5（安全自动续跑与命令闭环）；C=U6/U7（文件耐久性、灾难恢复及全系统签收）。只交付A不能宣称完成用户的全部需求。

+### U8. SQLite 活动服务隔离与既有存储门禁
+
+覆盖 R2/R3/R6/R11/R12，复用 U1 身份；近期优先于自动恢复和共享库测试。范围：Backend `internal/app/app.go`、`internal/store/store.go`、`internal/store/system_identity.go`、新增 `internal/instanceguard/`（拟定）；Dev `scripts/svc.sh`、`docs/svc.md`。锁只控制活动服务运行时，CLI 身份／schema 合同由[账户方案](2026-10-12-svc-unified-deploy-and-login-key.md) U7 负责。负责人待实施批准时指定。
+依赖：既有 U1；联合确认 service／CLI／migration 模式，先刻画原例和别名冲突，再实现；不直接把当前 dev 数据迁往 PG。
+测试：新增 Backend `internal/instanceguard/guard_test.go`，扩展 `internal/store/system_identity_test.go`；Dev 新增 `tests/test_svc_storage_ownership.py`，复用 `tests/test_svc_identity.py`。新增路径为计划。
+T8-1：两个独立进程同时启动同 SQLite，只有一个进入迁移／恢复；第二个明确拒绝，第一个 run/HITL 不变。
+T8-2：直接二进制、legacy、符号链接和可构造的文件别名不能绕过；真实 DB 替换／锁根丢失被识别。
+T8-3：活动服务 SIGKILL 后合法同实例可重启，OS 释放锁；主动停止不被 watchdog 错拉起。
+T8-4：服务运行期间合法账户 CLI 可提交短事务；错实例／缺库拒绝、不建目录、不 migrate；迁移不与活动服务并发。
+T8-5：更换端口、cwd、程序版本保持同一资源；测试候选默认独立根，显式指定共享根也不得绕过保护。
+T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合同核验，磁盘满／写失败不返回成功。
+环境：独立 SQLite 根与端口、真实 PG 独立库回归；双进程和 kill 禁止在当前 dev/candidate 执行。全部 T8 当前 NOT_RUN。
+
+近期批次 A0=U8＋账户方案 U7/U5：先稳定数据归属和账户链路；另行授权后完成 dev 原账户正常登录／重启／更新验收，见账户方案 §7。A/B/C 保留；U4/U5 联合验收后才开放自动续跑，A0 不代替全量恢复。
+
 ## 8. 验证合同

 | 故障/操作 | 最小判据 | 对应需求 |
 |---|---|---|
 | `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 |
+| SQLite 双进程、直接启动、别名、锁释放 | 第二活动服务在迁移／run对账前拒绝；合法 CLI 可用；kill 后同实例可重启 | R2/R6/R11 |
+| 实际 DB 耐久档、权威文件发布点、磁盘满 | 参数来自应用连接；确认结果已耐久；失败不发布成功；旧版本可读 | R3/R7/R12 |
 | 应用SIGTERM/SIGKILL/OOM | 持久数据完整；安全工作可恢复；额度无永久占用；无残留写者 | R3/R4/R6/R8 |
 | PG停止/重启、断连或提交响应丢失 | 不切SQLite；不假接受；按幂等记录对账；重连后可用 | R2/R3/R5 |
 | 主动stop与异常退出、监管/编排中途kill | 主动停止不拉起；异常按running意图恢复；操作重复安全 | R1/R2/R8 |
@@ -280,16 +325,59 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W

 本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。

-调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。**U1/U2启动实施前必须人工二选一**：(a) 以`feature/svc-autorecover`为实施载体，把本案r2作为其需求与方案来源填入该任务卡后按其流程推进；(b) 记录原因后放弃或合并该任务卡，由本案派生的独立任务实施；两任务不得同时充当svc启动/监管改动的权威，该归属决定与首批实施范围一并报批；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。
+原 r2 的 svc-autorecover 二选一属于历史启动现场；当前 recover/watchdog 和 U1 身份已有源码，不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管／RDM UI／端口回收任务，避免重复修改入口。RDM／插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。

 备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。

 实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。

-下一任务建议为U1并同步审查U3生命周期缺口：先保证再次启动绝不换库、换数据根或假就绪，再接监管和自动续跑。预计产物为兼容manifest合同、数据归属清单、隔离真实PG恢复回归与生命周期设计；进入实施前人工批准本案的需求、设计和首批测试范围。后续数据库备份、systemd安装、部署/启停与故障实验分别按授权执行。
+下一任务建议为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。

 ## 10. 全系统完成条件

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

 ## 先看哪一份

+- [快慢通道展示与动态工作摘要方案 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) 保留为过程权威。

@@ -168,7 +172,9 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围

 ## 2026-10-12 规划补充

- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。**2026-10-12 用户批准 r2（五阶段一并）**；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7；U2 首切片已由 svc-autorecover 任务合入 main（PR #396/#401，2026-10-11），余量按 KTD1/KTD2 对齐后续增量。
+- [svc 统一部署与一次性登录 Key 方案 r1](2026-10-12-svc-unified-deploy-and-login-key.md)：将 `svc.sh` 增强为二进制/源码统一部署入口，并补齐无初始密码开户与账户恢复；一次性登录 Key 只能兑换设密受限会话。r1 含源码复核与四项取舍定案；复用恢复方案 KTD 与已合入的 recovery U1（Dev #415）。**2026-10-12 已批准**（五阶段+U1/U4 规格）；授权推送/PR 与 U1/U4 实施启动；合入由 owner 执行。规格见 Dev `docs/svc-deploy/`。
+
+- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。**2026-10-12 用户批准 r2（五阶段一并）**；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7；U2 首切片已由 svc-autorecover 任务合入 main（PR #396/#401，2026-10-11）；U1 实例身份已合入（Dev #415，2026-10-12），余量按 KTD 对齐后续增量。

 ## 2026-10-11 规划补充

@@ -177,3 +183,5 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
 - [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)：对话优先、渐进任务摘要、窄屏与单一状态投影；已获本次连续实施授权。
@@ -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,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,85 @@
+# U7 运维演练与数据库基线报告（SELF，2026-10-12）
+
+来源标注：**SELF**（本机隔离栈执行；非 CI GATE、非独立 REPLAY）。用户 2026-10-12 决定不做容量重放。不得据此放行第二实例写流量。
+
+## 1. 被测对象
+
+| 项 | 值 |
+|---|---|
+| Backend gitlink | `8e509775d39d1455b69be44803037faa7af844b4` |
+| B6 Dev HEAD | `b2e129ab3f3bdf222f16040fcd0513872d0e2a3c` |
+| C4 Dev HEAD | `308f33665eb2dfaf9ae661e87df8898c3c2ecb3a` |
+| C5 Dev HEAD | `792574692609d9bfdf113e2dc5af6f43c9a176dd` |
+| 主机 | 32 逻辑 CPU，122 GiB RAM；演练开始时 load average 见各 `host.txt` |
+| 入口 | `tests/load/collaboration/run_pgbench.sh`；`tests/ops/run_fault_drill.sh`；`tests/ops/run_backup_drill.sh` |
+
+原始输出在测量 worktree 的 `results/`（gitignore），不入库。任务卡 evidence 为 SELF。
+
+## 2. B6 pgbench
+
+结果目录 `tests/load/collaboration/results/pgbench-20261012-131948`。隔离实例 `u7bench`，scale 100，每档 60 秒，`-M prepared`。`max_connections=100`，`superuser_reserved_connections=3`，100 客户端封顶为 95。六档失败事务均为 0。
+
+| 模式 | 客户端 | tps | P50 | P95 | P99 |
+|---|---|---|---|---|---|
+| select-only | 10 | 535646 | 0.018 ms | 0.024 ms | 0.030 ms |
+| TPC-B 类 | 10 | 18798 | 0.339 ms | 0.673 ms | 5.560 ms |
+| select-only | 30 | 952115 | 0.026 ms | 0.057 ms | 0.078 ms |
+| TPC-B 类 | 30 | 52224 | 0.493 ms | 1.002 ms | 1.777 ms |
+| select-only | 95 | 904708 | 0.087 ms | 0.180 ms | 0.417 ms |
+| TPC-B 类 | 95 | 50607 | 1.041 ms | 3.361 ms | 18.106 ms |
+
+主机不空闲。这是数据库参考基线，没有业务阈值，也不替代容量窗口。
+
+## 3. C4 断连
+
+结果目录 `tests/ops/results/fault-20261012-142734`。PG 18991，应用 18990/18992，Redis 18993。
+
+| 判据 | pg-stop | pg-kill |
+|---|---|---|
+| F1 有界失败、进程仍在 | 过 | 过 |
+| F2 不回落 SQLite，新进程拒绝就绪 | 过 | 过 |
+| F3 恢复后两侧各 5 次写入 | 过，RTO 不到 1 秒，未重启应用 | 同左 |
+| F4 失败 requestId 重放恰好一条 | 过 | 过 |
+| F5 dup_seq=0、seq 无洞、无非终态 run | 过 | 过 |
+
+Redis 限额 20 次/分钟，两实例各突发 40 个读：
+
+| 判据 | 结果 |
+|---|---|
+| G1 共享限额 | 放行 20、429 为 60、其他错误 0 |
+| G2 断连 | 放行 40、429 为 40、其他错误 0；已确认写入仍在 |
+| G3 只拉起 Redis | 放行回到 20；`rl:*` 均有过期时间 |
+| G4 | 发现：日志看不到降级计数 |
+| G5 | 发现：Redis 不通时新进程拒绝启动 |
+
+`runtime.redisAddr` 没有调用者可写的产品入口。演练用 SQL 写入默认 owner `local` 的 `user` 设置，并保留 mock。
+
+## 4. C5 备份与恢复
+
+结果目录 `tests/ops/results/backup-20261012-153441`。源 PG 18994，恢复目标 18997。合同数据量 seed 约 12 秒。
+
+| 判据 | 结果 |
+|---|---|
+| K1 备份有效 | 过。`failed_count=0`，`archived_count=80`，`pg_verifybackup` 与 `pg_restore --list` 退出码 0 |
+| K2 RPO≤5 分钟 | 过。64 秒 |
+| K3 RTO≤60 分钟 | 过。4 秒。恢复后登录、列项目、读会话均为 200 |
+| K4 工件与权限 | **FAIL**。五次上传都没有拿到工件编号 |
+| K5 不变量 | 过。dup_seq=0，seq 无洞；恢复后消息/事件/知识/run 计数与故障前一致（消息 1 000 120）；非终态 run 为 0 |
+| K6 逻辑恢复 | 过。`pg_restore` 退出码 0，约 4 秒；计数等于 dump 时快照（消息 1 000 000，知识 100 000） |
+| K7 权限与泄密 | 过。备份目录 700、文件 600；结果文本里没有连接串。静态加密与凭据演练记 N/A。归档和数据在同一块盘，没有模拟存储全毁 |
+
+恢复后的计数与故障前一致，说明已提交的标记都在。64 秒是最后一条成功标记的确认时间到故障时刻的间隔；窗口末尾有的写入因为会话仍被 mock run 占用而没有落库。
+
+K4 的原因在源应用日志：未设置 `BLOBSTORE_S3_ENDPOINT` 时，`NewS3FromEnv` 返回空的 `*S3`。这个空指针被放进 `blobstore.Store` 接口后不再等于 nil，`finishOpen` 不会回落本地目录，上传在 `blobstore.(*S3).Put` 空指针 panic。产品代码未改。因此工件 sha256 和跨用户拒绝没有测成。代码里本地后端的 `content_path` 是绝对路径；这次没有成功上传，所以没有用恢复后的下载来核验。
+
+同日另一次恢复（`backup-20261012-150713`）在数据目录复制之后起不来，因为 socket 路径超过 107 字节。正式这次把 socket 放到 `/tmp/u7bk-18997`。
+
+## 5. 放行
+
+B6、C4 为 SELF 通过。C5 的库恢复为 SELF 通过，工件恢复失败。第二实例写流量仍不放行。
+
+还没做、本任务不启动的两项：
+
+- 独立 REPLAY，或把 C4/C5 的快速档接进 CI 成为 GATE（需要平台准入）。
+- C3 双主机。
+- 上传在未配置对象存储时 panic，需要单独的产品修复后才能重测 K4。
Author	SHA1	Message	Date
weichen	cf74a200e8	Record the corrected workbench candidate and single delivery record Why: Keep planning progress aligned with actual implemented corrections without duplicating CI and merge state. Evidence: Reference UI155, Frontend210 and 19 local browser cases via Dev native receipts; final GATE remains separately tracked. Impact: Planning metadata only; no deployment or model-routing claim. Refs: work-companion-ui r0.2/r1, UI01-UI13	2026-10-12 19:07:32 +00:00
weichen	f7ae1ecce6	Record workbench implementation evidence and remaining delivery gates Why: Keep the approved design and implementation plan consistent with the current candidate. Evidence: Reference actual SELF verification and pending independent Review and GATE, without copying command output. Impact: Planning progress only; inherited live-model capabilities and deployment remain separate. Refs: UI01-UI13, work-companion-ui U5	2026-10-12 16:59:30 +00:00
weichen	b184bfb109	Merge current Documents main into the workbench design branch Why: preserve concurrent planning records before the Dev combination sync. Evidence: fetched authoritative Documents main `f76cce9e32`. Impact: planning record integration without rewriting history. Refs: work-companion-ui U5.	2026-10-12 16:32:44 +00:00
weichen	f76cce9e32	Merge pull request 'Record the U7 ops drill and advance the storage plan to r2.2' (#90 ) from feature/u7-ops-drills into main Merge pull request 'Record the U7 ops drill and advance the storage plan to r2.2' (#90) from feature/u7-ops-drills into main	2026-10-12 15:52:51 +00:00
weichenandCursor	95c2ec260c	Record the U7 ops drill and advance the storage plan to r2.2 Why: B6, C4, and C5 now have same-host results, and the plan still said the ops drills were not done and that replay was the next step. Evidence: Dev results pgbench-20261012-131948, fault-20261012-142734, and backup-20261012-153441 (SELF). The user declined a capacity replay on 2026-10-12. Impact: Second-instance writes stay closed. K4 remains a product defect. Replay and C3 are not started. Refs: feature/u7-ops-drills Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 15:49:44 +00:00
weichen	733f32c671	Merge pull request 'Record D1-D3 deploy remediation' (#88 ) from feature/recovery-d1-d3 into main Why: the recovery plan needs the D1-D3 remediation record before the Dev pin moves. Evidence: repository has no .gitea workflow; combined status has zero checks. Diff is one recovery-plan section. Impact: documents only. Refs: #88	2026-10-12 15:07:07 +00:00
weichen	8d8600024d	Record the approved progressive workbench design and implementation plan Why: implement a simple workbench for nontechnical users under continuous authorization. Evidence: current source audit and the reviewed r0.1 prototype; runtime verification remains pending. Impact: design and plan only; task execution state stays in the Dev task card. Refs: UI01-UI13 and the existing fast-slow display design r1.1.	2026-10-12 15:03:27 +00:00
weichenandCursor	cb7e25439a	Record D1-D3 deploy remediation on the recovery plan Why: the 2026-10-12 batch-update failure still had identity, rollback, and real-combo gaps after Dev #474, Backend #180, and RDM #276. The recovery plan is the single record for that work, and the rdmcand data-ownership check needed a written result before any restore. Evidence: read-only queries on runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z and the matching domain backups. No business rows were moved. Impact: adds r3.1 sections D1/D2/D3 and the ownership finding that dev conversations predate rdmcand's use of dev/data, so no cross-instance restore is indicated. r3's earlier unapproved text stays unapproved. Refs: Dev feature/svc-d1-identity-flow; Backend feature/d1-identity-open Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 13:47:46 +00:00
weichen	3cc6438030	Merge pull request 'Revise svc account durability and recovery plans (r2/r3)' (#87 ) from feature/svc-account-durability-plan into main Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/87	2026-10-12 12:18:24 +00:00
weichen	0952b50aef	Merge pull request 'Add fast-slow channel display design r1.1 and U1 plan' (#84 ) from feature/fast-slow-display-design into main Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/84	2026-10-12 12:16:07 +00:00
weichen	9c31d3c308	Merge Documents main into account durability plan branch Why: keep r2/r3 proposal updates rebase-friendly before PR. Evidence: origin/main at fetch time. Impact: Documents feature tip includes latest main. Refs: feature/svc-account-durability-plan	2026-10-12 12:11:40 +00:00
weichen	b8319d24f2	Merge pull request 'Record U7 capacity window SELF report and plan r2.1' (#86 ) from feature/u7-capacity-window-report into main	2026-10-12 12:07:26 +00:00
weichenandCursor	dbdec82466	Record U7 capacity window SELF report and plan r2.1 Why: Capacity ladder/60m/2h dual-instance windows finished; planning progress must reflect SELF-pass vs remaining GATE/REPLAY/C3 gaps. Evidence: SELF load results summarized in the new capacity report. Impact: Preferred next becomes independent REPLAY or C3/C4/C5. Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 12:07:12 +00:00
weichen	ebf655c4d7	Merge Documents main into fast-slow display design branch Why: Dev #451 cannot pin modules/documents while feature tip and main diverge. Evidence: merge-tree reports submodule conflict `1048e7c` vs `9e4ee27`. Impact: Documents #84 tip includes main@1048e7c plus r1.1/U1 plan. Refs: Dev PR #451; Documents PR #84	2026-10-12 12:07:02 +00:00
weichen	fe8d08be21	Record the final baseline and isolated candidate data Why: distinguish timed observations from current service ownership. Evidence: SELF task-sync and read-only observations at 18:14 Beijing time. Impact: planning metadata only; runtime and component deployment unchanged by this task. Refs: account r2; recovery r3	2026-10-12 10:16:32 +00:00
weichen	dca4265e37	Plan stable accounts and durable service recovery Why: account help, dev credential writes and crash recovery need a current, reviewable contract. Evidence: SELF source and sanitized runtime observations; seven document review lenses; business and fault validation NOT_RUN. Impact: revise two planning documents only; preserve prior approvals and mark additions pending review. Refs: Dev feature/svc-account-durability-plan; account r2; recovery r3	2026-10-12 10:09:49 +00:00
weichen	1048e7c6af	Merge pull request 'Propose RDM function implementation plan r1' (#85 ) from feature/rdm-function-plan-r1 into main	2026-10-12 09:29:03 +00:00
weichen	a183e663de	Propose RDM function implementation plan r1 Why: 2026-10-12 全系统核对产出的功能/实现矩阵与 U1-U9 整改方案需入仓评审；独立文件已过期于共享门禁解除。 Evidence: 报告含冻结源码/运行时快照与逐条需求索引；发布补记记录冻结后部署时序与 U2 已合入切片（RDM PR #251/#254/#256/#258）。 Impact: 仅新增 docs/proposals 一份方案与 README 入口；不改代码与既有文档。 Refs: RDM docs/requirements V2.2、Documents 2026-10-11-rdm-final-target-completion.md	2026-10-12 09:28:44 +00:00
weichen	9e4ee27c7e	Mark fast-slow U1 plan approved for implementation Why: User authorized stage-5 start; record plan status for executors. Evidence: Chat authorization "开始"; no runtime tests. Impact: Documents proposal status only. Refs: 2026-10-12-fast-slow-channel-display-u1-plan.md	2026-10-12 07:39:03 +00:00
weichen	5b71525818	Merge Documents main into fast-slow display design branch	2026-10-12 07:33:22 +00:00
weichenandCursor	f9d96dfc59	Add fast-slow display design r1.1 and U1 plan Why: Record approved stage-4 design with R03 splits and U1 exit whitelist, plus stage-5 U1 implementation plan for review. Evidence: Document edits only; no runtime verification. Impact: Documents proposals INDEX; no business code. Refs: feature/fast-slow-display-design Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 07:31:46 +00:00
weichen	8d0810bd35	Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83 ) from feature/u7-capacity-wrap-progress into main Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83) from feature/u7-capacity-wrap-progress into main	2026-10-12 06:39:52 +00:00
weichenandCursor	2cec59016a	Update collab storage plan progress to r2 after U1-U7 Why: Delivery requires writing planning progress back after U7 landed; the proposal still claimed U1+U2 start / NOT_RUN. Evidence: SELF doc edit against archived U7 cards and release checklist A1-A7/B1 facts. Impact: Readers see code-done vs capacity-window-pending; adds HTTP multi-instance vs Manager-test lesson. Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 06:39:26 +00:00
weichen	52bf525ef8	Merge pull request 'Add svc unified deploy and one-time login key proposal r1' (#79 ) from feature/svc-unified-deploy-login-key into main Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/79	2026-10-12 05:27:00 +00:00
weichen	9d9b1523c8	Merge Documents main into svc unified-deploy proposal branch Why: Dev #422 conflicted on modules/documents gitlink after main advanced past the proposal pin.	2026-10-12 05:26:12 +00:00
weichen	bd5fb18519	Merge pull request 'Record GenUI prod-acceptance action fixes on the usage guide' (#82 ) from feature/genui-fix-action-params into main	2026-10-12 04:17:15 +00:00
weichen	e39d327850	Record GenUI prod-acceptance action fixes on the usage guide Why: Capture nil-card panic and intent data-flatten field fixes found during local prod acceptance without revising the final closure verdict. Evidence: Backend#173 #174; prod action checklist Impact: Field-fix log lists the two hotfixes and their PRs. Refs: GenUI prod deploy; fix track	2026-10-12 04:17:07 +00:00
weichen	262d467362	Merge pull request 'Note Generative UI prod instance acceptance on the usage guide' (#81 ) from feature/genui-prod-deploy-note into main	2026-10-12 04:09:06 +00:00
weichen	66ddd37870	Note Generative UI prod instance acceptance on the usage guide Why: Record that the known-boundary production deploy/acceptance ran on the local prod svc instance with auth and PG. Evidence: scripts/svc.sh prod list; acceptance API checklist Impact: Usage guide boundary list no longer says deploy is pending. Refs: GenUI prod deploy task	2026-10-12 04:08:58 +00:00
weichen	1fe5b73491	Merge pull request 'Approve Generative UI auto-trigger opt-in design' (#80 ) from feature/genui-auto-trigger-optin into main	2026-10-12 03:46:28 +00:00
weichenandCursor	7df7d786d0	Record r1 approval for svc unified deploy proposal Why: user approved the proposal and U1/U4 specs and authorized push/PRs plus U1/U4 implementation start. Evidence: SELF conversation approval 2026-10-12; implementation still NOT_RUN. Impact: planning status only. Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 03:32:55 +00:00
weichenandCursor	923537e9a1	Add svc unified deploy and one-time login key proposal r1 Why: capture the reviewed design for binary/source install, env prep, and passwordless activation via one-time restricted sessions. Evidence: SELF source review against Dev af9c2de; implementation NOT_RUN. Impact: Documents planning index only; no runtime change. Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 03:28:37 +00:00