Record the K4 artifact retest in the collaboration plan

Why: the 2026-10-12 drill left artifact recovery failed, and the retest changed that SELF result without changing the write-traffic gate.
Evidence: backup-20261013-013354 on Dev a83588dd and backend 46073d30; K1-K7 true, RPO 65s, RTO 3s, five artifacts matched and cross-user access returned 404. SELF.
Impact: proposal moves to r2.3. Second-instance writes stay closed until REPLAY or CI and the second host exist.
Refs: docs/records/2026-10-12-u7-ops-drill-report.md docs/proposals/2026-10-11-collaboration-storage-and-distribution.md
Co-authored-by: Cursor <cursoragent@cursor.com>

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

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

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

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

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

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

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

@@ -12,6 +12,7 @@ product_contract_source: ce-plan-bootstrap
 确认状态：原 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 根目录为基准。
 
@@ -337,3 +338,46 @@ T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合
 只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
 
 本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
+
+## 11. D1/D2/D3 部署根治补充（r3.1）
+
+编号 D1/D2/D3 只属于本补充，避免与本案 U1–U8 重名。已合入且不再重做：Dev #474（按实例重置身份变量、停旧前候选门禁、update 走 manifest 迁移、普通启动只验证）、Backend #180（`pkg/identity`）、RDM #276（identity 子命令与未知位置参数退出）、Dev #477（backend pin 到含 #180 的 `acabb85`）。
+
+### 11.1 现场快照与 rdmcand 数据归属（SELF，2026-10-12T13:39:21Z）
+
+快照目录（在线 `sqlite3 .backup` / RDM `VACUUM INTO`，未停服务）：
+
+- `runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z`
+- `runtime-backups/{dev,rdm1,rdmcand}/domain-20261012T133921Z`
+
+只读核对副本，未移动任何业务数据。rdmcand 在 `2026-10-12T06:51:14Z`–`10:02:40Z` 使用 `runtime/dev/data`。该窗口内：
+
+- dev 库的会话、消息、事件均不落在窗口内。最后一条消息时间 `06:50:43Z`，早于 rdmcand 挂上该目录。会话与用户属于 dev（owner `weichen`、`genui-smoke`）。
+- 窗口内仅有 13 条 `command_audit`，全部是 `rdm.inspect.*`，owner `weichen`，没有领域事件。
+- 三份 `rdm.db` 的 `events` 均为 0。dev 的领域库更大（含权限表，schema_version=6），rdm1/rdmcand 的领域库只有字典与 schema 行。
+- rdm1/rdmcand 的 `agent-system.db` 只有 `2026-10-12T13:19:47Z` / `13:20:12Z` 由候选门禁写入的身份行，没有业务行。
+
+处置（未执行，需逐项授权）：不把 dev 的会话或领域库迁到 rdmcand。没有一份应属于 rdmcand 的历史领域数据需要回迁，因此不触发身份 `adopt` 重审。rdm1/rdmcand 当前库是空壳加已建立的身份行。
+
+### 11.2 D1 身份流程收尾
+
+对应 U1 的消费缺口。完成条件：
+
+- 身份 CLI 只打开既有库：不建文件、不建目录、不迁移。`agent_system_identity` 表（v27 起，列冻结为 instance_id/dbref/schema_version/created_at）缺失则拒绝并提示受控迁移。比本二进制更旧或更新的 schema，只要该表仍在，verify 仍可读。
+- verify 输出带 `schema_version`。DSN 走 `AGENT_SYSTEM_DSN` 或权限恰好 0600 的 `--dsn-file`；`--dsn` 保留并告警。
+- 能力文档一份 JSON，经 `version --json` 与 `identity capabilities` 输出。探测只跑 `version --json`，在空目录、清空环境、超时内执行。非 JSON 视为无能力。
+- 顶层未知子命令 exit 2，不以 `-` 开头才拦截，避免落入 serve。
+- manifest `identity.db_marker`：`fresh` | `pending` | `established`。新实例首次部署目标目录必须为空，启动建库后 ensure 变为 established。领养时有能力且库已存在则 ensure，否则 pending。pending 只在库文件存在时补齐，不迁移。established 缺行或不匹配时，start/restart/deploy/update/recover/init 全部拒绝；唯一修复入口是显式 `adopt --confirm <instance_id>`，并先打印库大小、关键表行数和最近写入时间。
+- `svc_lifecycle` 是 start/restart/deploy/update/recover 的共同入口。update 与 recover 逐服务以 `env -i` 启动子进程，不传入 `AGENT_SYSTEM_*`。serve 使用显式环境，并写入 0600 的 `serve.env` 供裸启动与 recover 复用。
+
+### 11.3 D2 切换事务
+
+对应 U6 的部署回退。制品进入 `runtime/<name>/releases/<rid>/`，`current` 用临时符号链接加 `mv -T` 切换。`bin`/`plugins`/`htdocs` 改为指向 `current/` 的稳定链接。切换日志 `deploy-journal.json`（0600）先写 phase 再执行。失败回到上一版本并恢复原期望运行态，不覆盖业务库。schema 不兼容时在停旧服务前拒绝。前进迁移必须 `deploy --migrate-schema --confirm <instance_id>` 且先 backup，日志标记 forward-only。能力文档增加 `schema.target` 与 `schema.compatFloor`；每条迁移登记是否破坏旧版读取，漏登记则测试失败。
+
+### 11.4 D3 真实组合门禁
+
+对应 U7 的故障验收入口，范围限于部署生命周期。Dev 用 `tests/integration/lifecycle/rdm.pin` 固定 RDM SHA（当前、上一版、无 identity 的旧版）。CI test-pg 按 pin 取固定 SHA，白名单加入 RDM 及其 pins。`make test-lifecycle` 缺 PG、源码或制品即失败，不静默跳过。桩测试不能代替该门禁。RDM 登录入口与账户 CLI 的 DSN 退出命令行依赖账户方案 U7/U5；未就绪的项保持 NOT_RUN，D3 不得标完成。
+
+### 11.5 验收
+
+缺一项则对应增量保持未完成：双向混合批次身份不串用；无 manifest 时 deploy/update/recover 一致；无能力、缺行、不匹配在停旧前拒绝且不建库；两次裸重启及换端口、换版本、换目录后身份不变；构建失败、启动即退、健康超时、工作台失败可回滚；切换中断后登记与制品一致；真实 PG 绑定与多实例检查通过且凭据不进命令行、日志和证据；RDM 页面、登录、领域命令和原有数据可验证，不能只看 HTTP 200。

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

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

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

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

docs/proposals/INDEX.md

@@ -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) 保留为过程权威。
 
@@ -179,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)：对话优先、渐进任务摘要、窄屏与单一状态投影；已获本次连续实施授权。

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

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