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>
Merge pull request 'Record D1-D3 deploy remediation' (#88 ) from feature/recovery-d1-d3 into main
2026-10-12 15:49:44 +00:00 · 2026-10-12 15:07:07 +00:00 · 2026-10-12 13:47:46 +00:00 · 2026-10-12 12:18:24 +00:00 · 2026-10-12 12:16:07 +00:00 · 2026-10-12 12:11:40 +00:00
15 changed files with 1943 additions and 24 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）。
+需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-12（Asia/Shanghai）。
-关联任务：Dev `.task/feature-collaboration-storage-plan.md`（方案任务，已发布）；后续 U1+U2 实施由独立任务承接。
+关联任务：方案与 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/组合验证流程交付。
@@ -9,7 +9,7 @@ product_contract_source: ce-plan-bootstrap
 # RDM 两树一网集成、完善与追溯审计展示方案
-修订：r1（2026-10-11 并入用户裁定）；确认状态：用户评审通过（2026-10-11，需求拆解至实施计划五阶段一并，含 KTD4 双层管理员裁定）；推进状态：U1–U5 全部实施并合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11）；U6（团队存储）独立后续；运行验收属部署环境。
+修订：r1（2026-10-11 并入用户裁定）；确认状态：用户评审通过（2026-10-11，需求拆解至实施计划五阶段一并，含 KTD4 双层管理员裁定）；推进状态：U1–U5 全部实施并合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11）；管理区「项目追溯与审计」入口经通用声明机制补齐（扩展面 2.9.0 Registry.AddAdminZone；Backend #165、Frontend #63/#64、RDM #240、Dev #414，2026-10-12；rdm.audit 分区随 rdm 插件声明，区内能力仍由 rdm.inspect.* fail-closed）；管理页插件清单另合并编译插件条目（Dev #404，2026-10-12）。U6（团队存储）独立后续；运行验收属部署环境。
 需求负责人：weichen；方案编制：Codex；实施负责人：待实施立项时指定。
 来源：2026-10-11 用户要求检查两树一网现状，并设计简单直观的项目追溯、审计展示；同轮明确选择“完善 RDM，并补齐必要的基座能力”。
 目标仓：Agent-System-RDM；下文 `RDM:` 路径相对于该仓，`Dev:` 路径相对于 Agent-System-Dev；所有建议接口名均为候选契约。
@@ -0,0 +1,252 @@
 ---
 title: 快慢通道展示 U1 实施计划
 date: 2026-10-12
 revision: r1
 status: approved
 owner: weichen
 execution: implementation
 parent: 2026-10-12-fast-slow-channel-display.md@r1.1
 ---
 # 快慢通道展示 U1 实施计划 r1
 > **For agentic workers:** 按本计划逐工作项实施；每项先写失败测试再改实现。规格依据主方案 [r1.1](2026-10-12-fast-slow-channel-display.md)。阶段 5 已于 2026-10-12 经用户「开始」批准；批准不等于推送/合入授权。
 **Goal:** 统一后台任务真实状态语义，用 L1 精炼骨架替换「原始指令占主视图」，使失败不再显示为完成，并为后续 U2 快照契约留下兼容字段草图。
 **Architecture:** 服务端在建卡/终态时写入精炼 Body 与正确 `CardStatus`；UI 按状态灯/状态词渲染；旧 `done+danger` 客户端兼容映射为失败。不引入持久 `TaskSnapshot`、不按任务路由 `agent.progress`、不发布阶段 findings（属 U2/U3）。
 **Tech Stack:** Go（Core/Backend）、React+TypeScript（UI/Frontend）、既有 ActivityCard / UINode / cardsvc 事件流。
 **Spec:** [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md) §4 R03-a、§7.1、§10.1、§14 U1 出口白名单。
 ## Global Constraints
 - 首批仅 U1；禁止顺手实现 U2/U3 范围（材料内容 hash、持久快照、检查点摘要、HITL 双入口完备）。
 - 颜色/圆角/字号只消费 `@ui/tokens.css`；动效只用 `mk-*`；折叠用 Collapsible。
 - 证据经 `CMD=… make evidence` 写入任务卡；声明通过须标 SELF/GATE。
 - 跨仓顺序：Core（若有契约）→ Backend → UI → Frontend → Dev gitlink 组合 `make test`。
 - 现有「停止」按钮语义不在本增量改名为「仅停前台」；不暴露暂停/独立取消/续跑。
 ## Review Focus
 1. 失败卡若仍为 `done`，用户会当成成功收纳——须 `CardFailed` 或等价失败灯。
 2. 建卡若仍塞入 task 原文，用户会把指令当进度——须 L1 骨架。
 3. 材料去重若仍只认 `CardDone`，改为 `CardFailed` 后可能卡死重试门禁——须同步测试。
 4. 快通道在登记前说「已启动」——须与真实登记/开跑事件对齐。
 5. `CurrentTaskCard`（plan/todos）与后台 progress 卡同目标叠卡——U1 须定义合并或降噪规则，避免双标题。
 ---
 ## 0. 范围与非目标
 ### 纳入（映射需求）
 | 需求 | U1 验收子集 |
 |---|---|
 | R01 | 简单问答无空进度卡；复杂任务短答可含已确认范围与后台真实状态 |
 | R02 | 已登记任务有稳定卡对象；未登记不显示「已启动」 |
 | R03-a | L1 骨架 + 诚实无发现占位；不验收运行中真实发现 |
 | R08 | 失败 ≠ 成功灯；状态词「执行失败」 |
 | R10 | 完成卡骨架（结论/要点/缺项/入口）；完备来源与版本定位可留 U3 |
 | R13 | 守护测试通过；状态不只靠颜色（沿用 StatusLamp 形状） |
 ### 排除
 见主方案 §14「明确排除」。另：不改 `CancelRun` 父句柄行为；不改 Surface 抢占策略（属 U2/U4）。
 ### 与 CurrentTaskCard 的合并规则（U1）
 - 后台 `CardKindProgress` 卡是慢通道权威对象。
 - 若同一会话同时存在前台 `plan`/`todos` 的 `CurrentTaskCard` 与后台 progress 卡：**右栏「工作」优先列出 progress 卡**；`CurrentTaskCard` 仅在无后台 progress 卡且 plan/todos 非空时展示。
 - 不在 U1 把 plan steps 写入后台卡 Body。
 ---
 ## 1. 工作项与文件
 ### W1 — Core：精炼摘要契约草图与旧卡映射说明
 **Files:**
 - Modify: `modules/core/activity.go`（若增加可选字段）或新增 `modules/core/task_summary.go`
 - Test: `modules/core/activity_test.go` 或同目录新测
 **内容（最小）：**
 ```go
 // TaskSummaryView 是 U1 写入 ActivityCard.Body 的权威语义草图；
 // 完整 TaskSnapshot（findings/revision/streamScope）留待 U2。
 type TaskSummaryView struct {
 	Title       string // 业务动宾短标题
 	Focus       string // 正在做什么，≤2 行
 	FindingsNote string // U1：无成果时固定诚实文案；有结构化 findings 属 U3
 	Remaining   string
 	NextStep    string
 	OutcomeLine string // 完成后的结论一行；运行中可空
 }
 ```
 可选：在 `ActivityCard` 增加 `Summary *TaskSummaryView \`json:"summary,omitempty"\``；**Body 仍为旧客户端回退投影**，新客户端优先读 Summary。若为降低跨仓面，U1 可仅约定 Body 的 Markdown/KV 形状而不加字段——但须在 Core 注释或本计划冻结 Body 键名：
 | KV 键 | 含义 |
 |---|---|
 | 状态 | 排队中 / 进行中 / 已完成 / 执行失败 |
 | 正在做 | Focus |
 | 当前发现 | FindingsNote（U1 占位或完成后要点摘要） |
 | 剩余 | Remaining |
 | 下一步 | NextStep |
 - [ ] 冻结 Body 键名或 `Summary` 字段二选一，写入 Core 并单测序列化往返
 - [ ] 文档注释标明 findings[] 属 U2/U3
 - [ ] Commit：`docs(core): freeze U1 task summary body contract`
 ### W2 — Backend：建卡/终态状态与精炼 Body
 **Files:**
 - Modify: `modules/backend/internal/runmgr/runmgr.go`（`createBackgroundCard` ~1942、`promoteQueuedCard` ~1970、`finishBackgroundCard` ~1992）
 - Modify: `modules/backend/internal/runmgr/material_test.go`（及同类依赖 `CardDone+danger` 的测试）
 - Test: 新增 `modules/backend/internal/runmgr/background_card_test.go`
 **当前问题（源码）：**
 ```go
 // create：Body 首节点 = truncate(task, 400)
 // finish：SetStatus(..., CardDone, tone) 且失败 tone=danger、状态行仍写「已完成」
 ```
 **目标行为：**
 ```go
 func backgroundRunningBody(focus string, kv [][2]string, statusLabel string) []core.UINode {
 	return []core.UINode{
 		{Type: core.UIMarkdown, Markdown: "尚无阶段结论，正在读取材料"},
 		{Type: core.UIKV, KV: append(append([][2]string(nil), kv...),
 			[2]string{"状态", statusLabel},
 			[2]string{"正在做", focus},
 			[2]string{"当前发现", "尚无阶段结论"},
 			[2]string{"剩余", "待任务进展后更新"},
 			[2]string{"下一步", "继续处理已登记工作"},
 		)},
 	}
 }
 // finish 成功：CardDone + tone ok；状态「已完成」；Markdown = 结论骨架
 // finish 失败：CardFailed + tone danger；状态「执行失败」；保留已有可读摘要
 ```
 - [ ] 失败测试：`finishBackgroundCard` 在 `err != nil` 时 `Status==CardFailed` 且 Body 状态键 ≠「已完成」
 - [ ] 失败测试：`createBackgroundCard` Body Markdown 不含原始 task 长指令（可用固定长 task 断言不出现）
 - [ ] 实现最小改动；`promoteQueuedCard` 只更新状态键为「进行中…」
 - [ ] 更新 `material_test`：成功路径仍等 `CardDone`；失败/重试路径认 `CardFailed` 或释放 `materialActive`
 - [ ] 快通道诚实：spawn/登记路径日志与用户可见文案——仅在 `Create` 成功后可称「已登记」；仅在子 run 启动后可称「进行中」（检查 `spawnBackground*` / material 入口提示，必要时改 system 提示片段；**不做**阶段发现生成）
 - [ ] Commit：`fix(backend): map background card fail to CardFailed and use L1 body`
 ### W3 — UI：状态灯与旧卡兼容
 **Files:**
 - Modify: `modules/ui/src/ActivityCardView.tsx`（`StatusLamp`）
 - Test: 既有 UI 测试或新增 `ActivityCardView` 测例；跑 `design-guard.test.ts`
 **目标：**
 ```tsx
 // done → 完成灯；failed → 失败灯（已有）
 // 兼容：status===done && tone==='danger' → 按失败灯展示，title「执行失败（兼容）」
 ```
 - [ ] 失败测试：`done+danger` 渲染失败形状灯，不渲染 `lamp-ok`
 - [ ] 实现兼容映射；不新增裸色值
 - [ ] `pnpm test` / 仓内 UI 测试目标通过
 - [ ] Commit：`fix(ui): treat done+danger progress cards as failed`
 ### W4 — Frontend：工作区排序与空卡
 **Files:**
 - Modify: `modules/frontend/src/components/Workbench.tsx`（`CurrentTaskCard` 展示条件）
 - Modify: 若 Inbox 过滤依赖 status，核对 `store.ts` 对 `failed` 的分区（完成区 vs 进行中）
 - Test: 前端既有测试或最小组件测
 **目标：**
 - 存在 `kind===progress && status===active`（或排队文案）时隐藏与同会话抢注意力的空 `CurrentTaskCard`（按 §0 合并规则）
 - `failed` 卡进入可收纳/结果区逻辑与 `done` 区分（失败可收纳但不显示成功语义）
 - 简单问答路径不因误触发材料整理产生空卡——若属既有路由，仅加回归断言「无附件无后台登记时 progress 卡数为 0」
 - [ ] 实现合并规则
 - [ ] 回归：无后台任务时 plan 仍可显示
 - [ ] Commit：`fix(frontend): prefer progress cards over duplicate CurrentTaskCard`
 ### W5 — Dev 组合与文档收口
 **Files:**
 - Modify: Dev gitlink（Core/Backend/UI/Frontend 精确 SHA）
 - Modify: 实施任务卡证据段；主方案进展指针（若本增量合入时）
 - Test: 工作区根 `make test`、`make build`
 - [ ] 各组件 PR 顺序合入或同批组合验证
 - [ ] Dev `make test` + `make build`；evidence 写入
 - [ ] 更新主方案「规划进展」：U1 实施状态（仅在真实合入后）
 ---
 ## 2. 测试与环境
 | 层 | 命令/方法 | 证明什么 |
 |---|---|---|
 | 单元 | Backend `go test ./internal/runmgr/…`；Core 序列化；UI StatusLamp | 状态映射、Body 骨架、兼容灯 |
 | 守护 | UI/Frontend `design-guard.test.ts` | 无新增裸色值/私有 keyframes/行内字号 |
 | 组合 | Dev `make test`、`make build` | gitlink 组合可编译可测 |
 | 手工冒烟（SELF） | 本地起服务：发材料看建卡；制造子任务失败看灯；简单问答无空卡 | U1 白名单场景 |
 | 真实模型阶段成果 | **NOT_RUN / 不在 U1** | — |
 | 浏览器窄屏全矩阵 | **NOT_RUN / 属 U4** | — |
 被测对象：各仓 PR HEAD；组合声明须含精确 SHA。
 ---
 ## 3. 完成条件
 1. U1 出口白名单全部可判定项有 SELF 或 GATE 证据。
 2. R03-a 有测例；无人用「五问完整」拒绝 U1。
 3. 材料整理去重/重试在 `CardFailed` 下仍可再次登记（或文档说明与测例固定行为）。
 4. 无 U2/U3 范围代码混入同一变更集（审 Diff）。
 ---
 ## 4. 停止与回退条件
 - 失败状态与存储不一致（卡显示失败但去重门禁认为仍在跑，或相反）→ 停止合入，修 W2/材料门禁。
 - 新旧客户端之一崩溃或空白卡 → 回退 Summary 字段改动，保留 Body 回退投影。
 - 发现实现滑入持久快照/检查点摘要 → 拆出变更，不进本 PR。
 - DESIGN 守护失败 → 先改令牌消费再继续。
 回退策略：回退受影响展示映射与 Body 生成；不删除已保存 run 结果。
 ---
 ## 5. 依赖顺序与责任
 ```text
 W1 Core 契约（可选字段或 Body 键冻结）
  → W2 Backend 建卡/终态
  → W3 UI 灯兼容
  → W4 Frontend 工作区
  → W5 Dev gitlink + 组合测试
 ```
 责任人：实施阶段指定；需求/评审：weichen。
 预估：单增量跨 4 仓，以状态映射 + Body 重排为主，不含模型评测费用。
 ---
 ## 6. 计划评审状态
 | 项 | 状态 |
 |---|---|
 | 关联方案 | r1.1 设计已批准；首批仅 U1 |
 | 本实施计划 | **已批准**（2026-10-12，用户「开始」） |
 | 业务代码 | 实施中：`feature/fast-slow-display-u1` |
 | 推送/PR/合入 | 未授权（完成自检后另请） |
 首选动作已执行：`make task-start NAME=feature/fast-slow-display-u1`，按 W1→W5 推进；设计任务卡可在文档 PR 合入后 `task-close`。
@@ -0,0 +1,517 @@
 ---
 title: 快慢通道展示与动态工作摘要方案
 date: 2026-10-12
 revision: r1.1
 status: design-approved
 owner: weichen
 execution: design-only
 ---
 # 快慢通道展示与动态工作摘要方案 r1.1
 状态：**方案设计已批准（阶段 4）**。需求依据：用户要求改善快慢通道的内容、排版与直观性，让慢通道执行期间持续呈现精准、精炼且有工作价值的状态、发现、摘要和总结。
 批准依据：2026-10-12 用户确认评审结论计划并指示按该计划落地文档修订与 U1 实施计划；批准范围覆盖四层阅读、任务卡骨架、动态回投规则、U1→U2→U3→U4 顺序及**首批仅 U1**。本修订相对 r1 增加 R03 增量切分与 U1 出口白名单。业务代码实施仍须另批阶段 5 实施计划后启动。更新日期：2026-10-12（北京时间）。需求与评审负责人：weichen；实施负责人在实施阶段指定。
 ## 1. 推荐方向与成功标准
 采用**对话推进工作、任务卡持续更新、结果按需展开**的方案。快通道负责即时理解、当前可回答的结论和必要确认；慢通道负责持续处理材料、研究、分析、生成及检查，并把当前工作成果逐步汇总给用户。两者共享任务与事实，不形成两份独立聊天记录。
 用户应当可以在一个视野里回答五个问题：
 1. 这项工作现在处于什么状态？
 2. 已经完成什么、目前知道什么？
 3. 这些发现对我的任务有什么影响？
 4. 还缺什么、下一步准备做什么？
 5. 是否需要我做决定或补充材料？
 默认阅读只需一行状态和一张紧凑任务卡。深入查看时可看到阶段成果、依据和执行记录。正式交付后直接给出结论、关键要点、限制与文件入口。
 设计的初始验收目标：代表性用户看到默认视图后，10 秒内可正确回答状态、主要发现、是否需处理三个问题；这个目标是**待验证的可用性指标**，不是当前体验已经达标的声明。
 ## 2. 当前实现依据及差距
 本次依据本地固定源码核对，来源为 SELF。启动基线为 Dev `4bf6e4a0cf8b509320d54de2a6a41c5abb2f5bba`；任务同步后读取的 Dev HEAD 为 `3496d1af37827dc536559ed5bbfe23c381c329cd`，其包含同步基线 `dec25692c247c8923b0f9396c8f674aefec47521`。
 组件：Backend `dcc180dcad2489a170edca154e39e335220854f1`、Core `89f3906c390027512ef47b5333088c3d3a019e84`、Frontend `d01a3ebd819da29bf7e7dd06e74c92ef34231774`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`。Documents 写作分支从单独获取的 `origin/main=52bf525ef8750999e5e7dbff0b2decac5b1155f7` 建立，未改变受测业务组件。源码审阅原始记录见 Dev 任务卡 `.task/feature-fast-slow-display-design.md` 的 source-audit 收据。本轮未开展真实模型、浏览器或部署验证；以下“已有”只表示源码中存在相应机制。
 | 已有源码机制 | 位置 | 与本需求相关的差距 |
 |---|---|---|
 | 快通道是当前对话回合，慢通道是后台子任务；同会话后台槽位上限 3 | Backend `internal/runmgr/runmgr.go` 的 `spawnBackgroundOpts`、`startBackgroundSlot` | 缺少统一面向用户的任务概览；通道不是用户可切换的速度档位 |
 | 带附件可自动启动材料整理；无文字/大材料可预启动，小材料有结束兜底；支持排队 | Backend `internal/runmgr/material.go` | 已有入口应复用；当前材料键仅由文件名与解析字数生成，同名等长更新可能复用旧结果。启动信息不等于材料已经读完 |
 | 进度卡创建时放入最多约 400 字任务正文和“执行中”状态 | Backend `internal/runmgr/runmgr.go:1942` | 用户主要看到任务说明和指令，不能据此理解实际进度 |
 | 完成时替换卡身；成功/失败统一置 `done`，用 tone 区分 | 同文件 `finishBackgroundCard`；UI `src/ActivityCardView.tsx:23` | 执行期间缺少成果投影；失败卡可能带“完成”灯，业务结果与卡收纳状态混在一起 |
 | `agent.progress` 发布子任务文本前约 80 字及“调用工具”消息 | Backend `internal/runtime/sub_loop.go:208` | 原始文本片段不具备稳定摘要语义，也没有结构化来源和成果完整性 |
 | `agent.progress` 写进单个 `live.agentNotes`；`touchLive` 维护单个 LiveState | Frontend `src/store.ts:514`、`:986` | 需避免后台进展串入当前对话回合；缺少按任务持久维护的独立展示投影 |
 | 会话/项目事件流、卡片更新事件及断线重放契约已有；客户端读取 seq | Core `events.go`；Frontend `src/api.ts:192` | 客户端 `Math.max` 推进游标本身不等于拒绝旧帧；新投影必须显式处理去重、顺序和恢复 |
 | 三栏“上下文 / 对话 / 工作与文件”、HITL、工件预览、Surface 已有 | Frontend `Workbench.tsx`、`Conversation.tsx`、`store.ts`；Core `activity.go` | 需要在现有落位整合，不增加第四栏；Surface 更新当前有自动打开预览行为，后台更新应控制抢占 |
 | 后台完成结果在会话空闲时启动汇报回合 | Backend `deliverNotices` | 结果就绪与汇报已送达需要分开；用户不应因前台忙而误以为任务尚未完成 |
 | 取消子 run 的现有路径还会尝试取消父句柄 | Backend `CancelRun` | 不直接提供承诺独立取消、暂停或重试的按钮 |
 由源码推导的主要原因：运行事件、任务卡和最终回复之间缺少一层稳定的**用户工作摘要**。只调整卡片样式不能补齐这些信息。
 ## 3. 方案选择与边界
 | 方案 | 收益 | 代价与限制 | 结论 |
 |---|---|---|---|
 | 直接把慢通道日志流到卡片 | 改动较少、容易看到活动 | 原始指令与工具输出增多；难提炼发现；并发时噪声更大 | 作为执行记录层，不作为默认视图 |
 | 快慢通道各有一份完整对话流 | 两条执行线直观 | 重复回复、重复确认、用户需要拼接上下文；占用阅读空间 | 不采用 |
 | 统一任务摘要 + 同一卡片更新 + 对话关键回投 | 结论可读、状态可见、细节可追溯 | 需要结构化成果与持久投影 | **推荐** |
 范围包括信息架构、快通道内容、慢通道摘要、状态语义、更新策略、来源与恢复、UI 组件适配。通用基座提供任务、发现、来源与动作能力；文档审签、业务风险等级等由下游提供适配，不写进基座。
 本轮不执行业务代码修改、模型实验、迁移、重启或部署。候选设计中的新契约、持久化和操作能力均为待批准内容。本方案不依赖 Generative UI 插件启用才能工作；结构化任务卡提供基础体验，Surface 可用于适合的成果展示。
 ## 4. 需求与可判定验收
 以下为已批准方案范围内的需求表。P0 是核心闭环，P1 是增强项。首批实施仅覆盖 U1 出口白名单中的子集；“纳入候选”不等于该子集已获实施授权。
 | ID | 需求 | 优先级 | 可判定验收条件 | 依赖/处理 |
 |---|---|---|---|---|
 | R01 | 快通道首先给用户可用的即时答复 | P0 | 简单问答无空任务卡；复杂任务短答能说明已确认范围、当前可回答内容及后台工作 | 既有对话；U1 纳入 |
 | R02 | 所有已登记后台任务都有稳定可见对象 | P0 | 排队、运行、结束都定位到同一任务；未登记时不显示“已启动” | 任务登记；U1 纳入 |
 | R03 | 默认卡呈现当前工作、发现与剩余项 | P0 | 见下方 R03 增量切分；完整五问仅在 U3 验收 | R02；按增量切分 |
 | R04 | 阶段成果动态更新且不重复刷屏 | P0 | 有可用阶段成果时及时更新同一卡；选定长任务验收至少两个真实成果检查点；短任务可直接完成，普通更新不新增对话消息 | 事件投影；U2/U3 |
 | R05 | 事实、分析判断和待确认内容可区分 | P0 | 关键发现可定位依据；尚未核实的推断带限定；不得以模型自报覆盖工具实际结果 | 来源契约；U2/U3 |
 | R06 | 并行任务不会互相污染状态或正文 | P0 | 3 个后台任务与前台回合同时活动，各任务标题、发现和终态归属正确 | 按任务路由；U2 |
 | R07 | 等待用户的动作明确且双入口一致 | P0 | 对话/右栏提交任一入口后另一个同步更新；重复点击只执行一次 | 既有 HITL/动作；U3 |
 | R08 | 成功、部分结果、失败、中断明确区分 | P0 | 失败不显示成功灯；部分结果标明缺项；未保存的结果不显示“已交付” | 结果契约；U1 纳入 |
 | R09 | 断线/刷新不丢失成果，也不伪造状态 | P0 | 重连可恢复阶段摘要；重复/乱序事件不回退；连接异常不改写业务终态 | 持久快照；U2 |
 | R10 | 完成回投精炼且可取回产物 | P0 | 显示结论、最多 3 个默认要点、缺项、文件入口；定位真实文件且版本明确 | 工件/通知；U1 骨架，U3 完备 |
 | R11 | 右栏关闭与窄屏时主要能力完整 | P0 | 不打开右栏即可读摘要、看依据、处理确认、打开文件 | 对话内展开；U4 |
 | R12 | 更新尊重正在阅读的内容 | P0 | 不自动切文件、不夺取焦点、不把用户滚回底部；展开与阅读位置保留 | 更新策略；U2/U4 |
 | R13 | 视觉与可访问性符合 DESIGN.md | P0 | 令牌、Collapsible、MotionKit 守护通过；键盘可达；状态不只靠颜色 | UI/Frontend；U1 纳入 |
 | R14 | 摘要成本受控，摘要失败不影响任务 | P0 | 不按 token 调用摘要模型；预算耗尽仍有真实阶段状态与既有发现 | 发布策略；U3 |
 | R15 | 修改任务要求可解释地衔接 | P1 | 新要求明确“尚未生效/已用于后续任务”；不假称已改变在跑任务 | 新任务/输入确认；U4 |
 | R16 | 合适成果可以切换对比、清单或报告 | P1 | 比较任务给差异表；审查给问题清单；插件关闭仍能读取核心摘要 | 可选 Surface；U4 |
 | R17 | 每次尝试与结果采用状态可追溯 | P0 | 新尝试不覆盖旧失败；生成、用户认可、正式发布三者独立显示 | task/attempt/result；U2 |
 | R18 | 跨任务发现有总览且不重复计数 | P1 | 同一来源同一发现合并引用；冲突并列呈现，关联到各自任务 | 稳定发现 ID；U4 |
 ### R03 增量切分（定稿）
 完整 R03「运行卡无需展开即可回答第 1 节五问」不得用单一增量字面验收。切分为：
 | 子集 | 归属 | 可判定出口 |
 |---|---|---|
 | R03-a | U1 | 默认卡采用固定 L1 骨架（标题+状态、正在做什么、当前发现区、剩余/下一步）；无阶段成果时诚实显示「尚无阶段结论…」；不把原始任务指令当作进度正文；**不**要求运行中出现真实业务发现 |
 | R03-b | U2 | 活动行与覆盖/剩余可随确定性事件持续更新；刷新/重连后骨架与活动状态仍可读 |
 | R03-c | U3 | 带来源的 1–3 条阶段发现；运行中即可回答五问中的「知道什么 / 影响 / 还缺什么」 |
 项目符合度：R01–R18 与对话优先、服务端权威、通用基座定位相符；其中 R02–R09、R14、R17 需要契约及实现调整，R15/R16/R18 的完整能力需进一步设计。运行可行性尚未验证。
 ## 5. 信息架构与阅读层级
 维持三栏。左侧提供项目、会话、材料上下文；中间负责对话、关键进展和决定；右侧“工作”集中当前任务与待处理事项，“文件”负责既有唯一预览入口。
 | 层级 | 默认展示 | 用户目的 | 展开方式 |
 |---|---|---|---|
 | L0 一行概览 | 前台状态、后台任务数量、待处理数量 | 一眼判断是否忙、是否需要行动 | 点击对应任务或待处理项 |
 | L1 工作摘要 | 目标、状态、正在做什么、1–3 条重要发现、剩余项、必要动作 | 快速理解并继续工作 | 当前任务卡；对话内同对象锚点 |
 | L2 阶段与依据 | 阶段成果、发现列表、覆盖范围、未决事项、来源 | 检查判断、准备评审 | 在原位置用 Collapsible 展开 |
 | L3 执行记录 | 工具调用、可授权查看的参数/输出、事件、错误详情 | 排障和审计 | “执行记录”，默认折叠、按阶段分组 |
 默认先提供 L0/L1；不同时展开所有任务。正在查看文件时，工作更新只改变概览及未读提示。右栏收起时，中栏任务锚点可展开 L1/L2/L3，关键功能不依赖右栏。两处共享同一 taskId 和服务端快照，不分别生成摘要。
 右栏顺序：**需要你处理 → 当前正在查看的任务 → 其他进行中/排队 → 新结果 → 已收纳历史**。置顶任务保留位置；普通更新不因时间变化反复重新排序。排序规则只负责注意力，不改变执行优先级。已有“当前任务卡”的计划/待办融入同一概览，避免再叠一张同目标卡。
 ### 5.1 桌面示意
 下列内容均为设计示例，不是真实运行结果。
 ```text
 上下文                 对话                             工作 | 文件
 项目 / 会话            收到 3 份材料，已登记材料整理任务    需要你处理 0
 材料与历史             我会先核对事实和差异，再给摘要      材料整理 · 进行中
                       [材料整理 · 已有 2 条阶段发现]      正在核对：需求与会议结论
                                                        当前发现
                       你：先重点看验收要求                • 3 项需求缺少验收条件
                       助手：补充尚未作用于在跑整理         • 上线日期存在两种表述
                       [以此重点创建后续分析任务]           剩余：核查评审意见
                                                        下一步：整理待确认事项
                       …                                [查看依据] [阶段与记录]
                       后台 1 项 · 无需你处理
                       [输入消息                          ]
 ```
 中栏进展锚点只给一条高价值提示，不复制右栏全文。新目标通过新任务或已有受支持的输入动作落实，不默认承诺能动态改写在跑任务。
 ## 6. 快通道内容规范
 ### 6.1 不同场景怎样回复
 | 场景 | 默认回复 | 后台信息 |
 |---|---|---|
 | 简单问答、短文本修改 | 先给答案，必要时给短依据或结果 | 无实际后台任务则不显示通道卡 |
 | 发送材料、任务尚未登记 | “收到 3 份材料，正在准备整理”及已确认的接收/解析信息 | 不提前声称“已启动” |
 | 材料任务已登记 | “已登记材料整理，完成后给出事实、差异与待确认事项” | 显示排队或运行真实状态 |
 | 有明确分析/生成目标 | 一句话复述目标 + 当前能回答的内容 + 本次处理范围 | 实际启动后显示相应任务 |
 | 用户追问后台知道了什么 | 基于最新快照给 2–3 条已发布发现，标出仍在核查的部分 | 不重复启动同一工作 |
 | 发现阻塞/需要决定 | 直接说问题、对结果的影响及所需输入 | 复用同一个确认对象 |
 | 后台结束 | 结论 → 关键要点 → 限制/缺项 → 产物或下一动作 | 回投当前结果版本 |
 “每份材料一句概览”只在已有解析或阶段成果能够支持时给出。快通道尚未读到材料正文时，给文件清单和整理范围即可，不由文件名推断业务结论。
 ### 6.2 精炼但有用的内容骨架
 短答默认 2–5 行；复杂结论默认一段总括、最多 3 个要点和一个主要动作。字数是初始排版预算，不硬截关键风险、金额、日期、否定条件或来源。
 示例：
 > 已收到需求说明、会议纪要和评审意见，材料整理任务已进入队列。整理会先核对关键事实、冲突与待办。你可以继续补充希望重点关注的问题。
 有阶段成果后的示例：
 > 目前发现 3 项需求缺少验收条件；两份材料中的上线日期不一致。评审意见仍在核查，完整结论尚未形成。你现在可以先确认上线日期的权威来源。
 避免空泛重复“我正在深入分析”“请耐心等待”。工具名、系统提示词、模型自我描述不进入默认业务回复。无需用户决定时，不为了显得主动而硬加问题或三个无依据建议。
 ## 7. 慢通道任务卡与阶段摘要
 ### 7.1 运行中固定骨架
 1. **标题与状态**：业务动宾短标题，如“核对三份材料”“生成需求说明”；状态词独立显示。
 2. **正在做什么**：一句业务阶段说明，最多两行。如“核对需求条目与评审结论”。
 3. **当前发现**：默认 1–3 条，按对目标的影响排序；每条表达“发现 + 意义”，有来源入口。
 4. **剩余与下一步**：一句说明尚未覆盖部分及接下来处理内容。
 5. **操作与时间**：只有真实可用的主动作；注明最近成果更新时间，耗时为次要信息。
 任务刚开始时，“当前发现”显示“尚无阶段结论，正在读取材料”，不制造空白占位成果。无需用户操作的任务明确“无需你处理”，而非放一个不可执行的“继续”按钮。
 ```text
 核对三份材料                              进行中
 正在核对需求与会议决定
 当前发现
 • 3 项需求缺少验收条件，暂无法判定是否可验收  [来源]
 • 上线日期存在两种表述，需要确定权威版本    [来源]
 已覆盖：需求说明、会议纪要的目标章节
 剩余：评审意见中的变更记录
 下一步：整理冲突与待确认事项
 最近成果更新 14:32                 [查看阶段与依据]
 ```
 “已覆盖”必须来自已确认处理的章节、工具返回或有效检查点。解析完成与分析完成分开显示；“读过一份文件”不能自动计为该文件已全部分析。数量与统计只能来自可数、可去重的对象。
 ### 7.2 有工作价值的阶段成果
 每次阶段发布应至少带来一个用户能利用的变化：确认事实、揭示差异、形成可用初稿、发现缺项、完成检查、给出必要决定。普通“调用工具”只更新活动状态和执行记录，不算业务成果。
 | 工作类型 | 推荐业务阶段，按实际任务选用 | 默认最有价值的内容 | 最终呈现 |
 |---|---|---|---|
 | 材料整理 | 接收/解析 → 提取事实 → 核对差异 → 汇总 | 核心事实、共同结论、冲突、待办 | 短摘要 + 重要发现 + 来源 |
 | 研究检索 | 明确问题 → 查找来源 → 对照证据 → 形成判断 | 已找到的依据、尚缺的证据、判断如何变化 | 结论 + 对比/依据 |
 | 方案/需求分析 | 提取约束 → 检查覆盖 → 比较取舍 → 整理建议 | 缺项、约束、关键取舍及影响 | 建议 + 清单/对比 |
 | 文档生成 | 确认范围 → 编排结构 → 生成草稿 → 校验保存 | 结构已定、待补材料、草稿状态、检查结果 | 精炼结论 + 正式工件入口 |
 | 审查验证 | 确定对象 → 执行检查 → 归纳问题 → 汇总结果 | 会阻塞交付的问题、证据、未覆盖项 | 问题清单 + 实际检查结果 |
 阶段不固定为所有任务必经的四步。检索/检查可能迭代回到前一阶段；通过阶段 ID 与版本记录，不以动画线性前进。没有领域阶段数据时降级为“读取材料 / 使用工具 / 整理结果”等确定性活动描述，不凭计时自动切阶段。
 ### 7.3 成果不是思维链
 发布公开工作摘要、工具确认的事实、可交付的阶段产物和待确认问题，不把隐藏推理、系统提示词、原始任务提示或未完成 token 片段包装成发现。执行记录仅展示真实已有且当前用户有权限查看的记录；“展开”不意味着获得额外权限。
 ## 8. 精炼、来源与结论修订
 ### 8.1 发现的表达与排序
 发现由一句结论和一句影响组成，通常合为一行：“指标定义不同，两个方案的达成率不能直接比较”。排序优先级为：需要用户决定的事项、会改变当前建议的风险、与用户目标直接相关的事实、其他背景信息。
 去重按稳定 findingId 及来源版本处理；同一事实由两个任务发现时，展示一次并保留两条依据。差异表、审查清单按内容结构选择，不把所有成果强塞进统一长 Markdown。
 ### 8.2 用户可理解的结论标签
 | 内容类型 | 展示文案 | 发布要求 |
 |---|---|---|
 | 材料直接记载的内容 | “材料记载” | 指向文件版本与位置；不等于事实已被外部验证 |
 | 工具检查直接确认的结果 | “已核对” | 指向具体检查对象和真实结果；本地/独立/受信来源保留对应证据等级 |
 | 基于若干来源推导的建议 | “分析判断” | 提供依据，说明影响结论的假设 |
 | 尚有关键缺口的判断 | “初步判断” | 显示缺口、覆盖范围；不得写成最终结论 |
 | 需要人决定的口径/事实 | “待确认” | 给明确问题和影响，并关联确认入口 |
 这些标签描述内容性质，不提升 SELF/REPLAY/GATE 信任等级。不显示没有校准依据的“可信度 95%”。重要来源失效时保留历史结论，当前摘要标“依据已更新，需重新核查”。
 ### 8.3 来源定位与修订
 来源至少包含项目/会话归属、文件或工件 ID、版本或内容摘要、可用定位信息及发布事件。优先页码、章节、段落；现有解析器没有页码时显示章节/片段，不编造定位。权限失效显示“当前无法访问该来源”，摘要权限同步重新检查，不以历史缓存继续泄漏内容。
 输入复用身份必须包含实际内容摘要：优先原始文件内容 hash 与解析版本，缺少原始 hash 时至少包含实际解析文本 hash、解析版本与相关处理配置，不能仅用文件名和字数当版本。保留既有附件路由，但不同内容不得复用旧任务成果。当前材料键校正作为 U2 来源修订的前置依赖，可用关联修复增量交付；旧卡无法证明内容一致时仅作历史结果，不自动认定本次输入已经整理。材料键等兼容凭据应保留在受控元数据与旧客户端回退投影中，用户默认卡身不展示内部键。
 发现具有稳定 ID、有效状态与版本：当前有效 / 已修正 / 已撤回 / 已被替代。后续推翻早先发现时，摘要替换当前有效项，阶段历史留一条“此前判断已修正”并给原因、影响和新依据。若曾需要用户据此行动，必须发一次有意义的更正提醒。
 ### 8.4 任务结束后的内容
 ```text
 材料整理已完成
 结论：当前材料可用于需求草稿，仍有 2 项关键口径需确认
 • 核对出 3 项缺少验收条件的需求
 • 上线日期冲突，需要项目负责人确认
 • 评审意见的 2 条调整尚未反映到需求说明
 范围：已覆盖三份材料的可解析文本；图片附件未纳入
 [查看完整摘要]   [查看来源]   [确认交付物]
 ```
 生成文件不代表用户已认可或文档已审签。另显示交付状态：草稿已保存 / 等待评审 / 已认可 / 已发布；正式状态只采用业务宿主确认结果。检查未执行时写“未检查”，不以“已生成”代替“已验证”。示例中的完成与发现仍为设计数据。
 ## 9. 动态更新、通知与阅读稳定性
 ### 9.1 更新来源与频率
 采用两条信息路径：**确定性活动状态**来自任务登记、工具开始/结束、等待用户、存储结果等事件；**业务摘要**来自显式阶段成果或对已完成结果的受控压缩。模型只提交摘要候选，服务端校验来源、覆盖范围、版本与终态后发布。
 | 变化 | 更新位置 | 初始调度策略 |
 |---|---|---|
 | 入队、执行开始、等待用户、失败/结束 | L0 + 原任务卡 | 持久化成功后立即发布；在线端到端目标 p95 ≤2 秒，待测 |
 | 工具开始/结束、活动描述变化 | 原卡的活动行 + L3 | 同任务合并高频变化，普通视觉更新最多每秒一次 |
 | 新阶段成果、建议发生实质变化 | 原卡 L1/L2 | 检查点发布；连续普通成果可在 8–15 秒窗口合并，首条有效成果不必等待窗口 |
 | 必须用户决定、关键风险、更正重要结论 | 对话提示 + 原任务卡 | 绕过普通摘要窗口；同一事件幂等提示一次 |
 | 没有新业务成果 | 活动行/连接提示 | 保留已有摘要；不自动追加“仍在分析”消息 |
 | 多任务相继完成 | 各卡 + 合并完成汇报 | 原卡先显示结果；父会话空闲再合并汇报，不阻塞结果可读 |
 时间参数是初始设计值，实施后通过可用性与性能验证调整，不是实时性已经达标的结论。执行日志收集不按视觉节流丢弃；合并的是显示更新和重复语义通知。
 ### 9.2 控制摘要成本
 优先由当前执行器在自然检查点提交简短成果；必要时才另行压缩已完成的工具结果或阶段文本。不按每个 token、每个工具调用或每个定时 tick 运行新模型。
 候选边界：单任务最多 6 次额外摘要模型调用；普通额外摘要最小间隔 15 秒；最终主任务的结果汇总属于执行预算，仍受已有整体预算控制。费用上限在实施评审时与模型、材料范围一起批准。预算耗尽或摘要生成失败时，保留已发布发现并继续显示真实活动；不阻塞主任务，不伪造阶段成果。
 阶段成果发布应由运行时检查点驱动，不能只依赖模型自觉调用工具。没有可安全提取成果的长单次模型调用期间，只展示已确认活动与最近成果时间。若任务需要持续提供发现，可在不改变业务结论前提下拆成有产出的处理批次；这些提示词/行为改动需真实模型前后对照。
 ### 9.3 不打断阅读
 用户阅读历史消息时不自动滚动；输入中不夺取焦点；正在看文件时不自动切“工作”或打开另一文件。出现新结果显示“1 项结果已更新”，由用户点击查看。用户主动等待的首次前台产物可沿用既有打开策略，但后台卡更新与 Surface 更新默认不抢占预览。
 同一卡片稳定 DOM 与区块 ID；不逐字重打整段摘要。更新相应段落并可轻标“新”，保留展开、选择、滚动和置顶。屏幕阅读器只播报阶段结束、关键发现和需要处理；不播报每个日志增量。减少动态效果时不播放状态动效。
 ### 9.4 用户继续对话与调整要求
 后台任务运行时，对话依然可用；前台忙时沿用现有输入排队语义，并明确“消息待发送”。追问“现在发现了什么”读取已发布快照，无需新派任务。
 当前不假定在跑任务可动态接收新要求。补充内容应说明它将用于后续回合/新任务；如用户希望据此重新分析，创建关联的新尝试并保留原结果。未来可支持安全的任务输入修订，但必须有服务端确认“已接收并生效”后才显示生效。
 ### 9.5 确认双入口的提交反馈
 对话与右栏按同一 confirmationRef 维护提交状态。点击后两处同步显示“提交中”并暂时禁用，收到服务端成功确认后才显示“已处理”。明确拒绝或提交失败时保留原问题、选项和错误原因；服务端返回已处理/版本过期时刷新共同对象，不能继续提交旧选项。
 请求超时或连接中断不能证明动作未执行，先显示“确认结果待核实”并查询既有动作记录，不盲目重复执行。重试使用同一幂等请求标识和相同参数；参数已改变则按新动作重新检查。前端不得以一个入口关闭为另一个入口业务完成的依据。
 ## 10. 状态、异常与操作能力
 把三个维度分开：执行状态、成果完整性、连接状态。卡片的收纳/已读状态属于第四个展示维度，不驱动业务终态。
 ### 10.1 执行状态
 | 状态 | 用户文案 | 说明与动作 |
 |---|---|---|
 | preparing | 准备中 | 只确认接收范围；持久登记后进入 queued/running |
 | queued | 排队中 | 队列已确认；只有服务器提供可信位置时显示序号，不给虚构等待时间 |
 | running | 进行中 | 显示真实阶段及最新有效发现 |
 | waiting_input | 需要你确认/补充 | 显示问题、影响、选项；无超时契约则不暗示自动继续 |
 | succeeded | 已完成 | 执行及必要结果保存均成功；是否满足全部用户要求由成果维度说明 |
 | failed | 执行失败 | 原因、影响、已保留内容和真实可用的恢复方式 |
 | cancel_requested / cancelled | 正在停止 / 已停止 | 仅在支持相应控制契约时暴露操作；请求送达不等于停止确认 |
 | interrupted | 执行中断 | 显示最后已保存检查点；恢复动作通过既有服务端支持判断 |
 这些是候选展示语义，不宣称 Core 已具备全部同名枚举。`waiting_input` 映射现有 waiting_hitl 等明确状态；旧后台卡 `done + danger` 要由 run 终态与 tone 映射为失败。没有可靠 run 对应时使用保守文案“任务已结束，结果状态待核对”，不解析任意正文来推断成功。
 成果完整性采用 complete / partial / none，并列出已覆盖和未覆盖范围。生成内容已经保存但汇报尚未送达时，显示“结果可查看，稍后在对话汇报”。交付保存失败时不能标“已交付”；可保留可读摘要并显示保存失败。
 ### 10.2 连接与恢复
 在线 / 重连中 / 当前状态未核实只影响连接提示。60 秒没有新**成果**不等于执行失活；可显示“最近成果更新于…”，不能仅凭此声明失败。若要展示执行存活，须来自运行时心跳/执行所有权确认，另记录 lastActivityAt；现有源码没有已核实的通用任务存活契约，本方案将其作为新增设计。
 断线期间保留最后已确认结果，停止“实时”声明。重连先取得带流游标的快照，再重放游标之后事件；历史保留不足时重新获取完整快照。服务重启导致 run interrupted 时，依据真实终态显示中断；是否可恢复、恢复是否可能重放副作用由既有恢复能力决定，UI 不自动重试。
 ### 10.3 按能力显示操作
 基础动作：查看摘要、查看来源、查看阶段/执行记录、处理既有确认、打开已保存文件、收纳结果。动作带服务端能力和禁用原因；UI 不根据模型写出的按钮名自行分发。
 暂停、独立取消、续跑、自动重试、改变在跑任务优先级不作为首期承诺。后台运行卡隐藏“关闭”式歧义动作，只提供折叠；收纳只影响历史呈现，不停止执行。现有输入区“停止”仍绑定现有前台能力；若其真实影响范围包含其他运行，必须如实说明，不能在本方案中改名为“仅停前台”而不修复契约。
 失败提示采用“问题 + 影响 + 已保留内容 + 下一动作”。例如：“评审意见未能解析，本轮只完成其余两份材料；已保存两份摘要。请补充可解析版本后重新核对。”有保存凭据才声明已保存。
 ## 11. 多任务协作与领域展示
 一个用户目标下的任务组只给一份整体概览，各后台任务保持独立摘要。后台上限沿用当前 3 个槽位，队列与入场等待按运行时确认展示，不另造默认无限并发。
 总览优先突出阻塞与结论：“材料核对、竞品检索已完成；方案整理等待你确认预算”。只有明确可数的工作项才显示“2/3 项已完成”；这个比例不代表剩余时长或模型完成度。不能用工具次数、token 数或耗时估算百分比。
 并行发现经规则合并引用，冲突同时展示：“来源 A 写 6 月上线；来源 B 写 7 月，尚未确认权威口径”。完成任务先稳定保存成果再通知；父会话忙时新结果可读，业务汇报待空闲，多个结果可合并为一条简短汇报。去重键包括任务、尝试和结果版本，防止通知回合再派发原工作。
 领域可通过通用内容种类输出事实、差异、缺项、待办、建议和结果引用。RDM 类场景可由下游提供“受影响文档、验收条件缺项、审签状态”等内容与动作；基座不把材料整理“完成”解释为业务文档“已批准”。领域内容缺失时降级到通用摘要，不构造业务状态。
 ## 12. 视觉与排版规范
 严格消费根 DESIGN.md，保持冷静、紧凑、内容优先的工作台。沿用用户此前选择的浅色克制方向，同时适配已有深色/墨绿主题。主题、字号与布局属于既有能力，实施不另造皮肤体系。
 | 元素 | 排版建议 | 规则 |
 |---|---|---|
 | 任务标题 | 基准字号、中等字重，状态靠右 | 优先业务名称，完整标题可换行；不挤满任务 ID |
 | 当前工作行 | 基准字号，主文本或次级文本 | 动宾语句；不重复标题或“慢通道”标签 |
 | 发现 | 基准字号；每条一至两行，3 条以内默认可见 | 保留影响与关键限定；来源紧邻对应发现 |
 | 范围、下一步、更新时间 | caption/sm 标尺；使用可读次级文字色 | 关键状态不能用 faint |
 | 进度 | 有数据时用步骤清单与真实数量 | 无百分比/ETA 表盘；活动用既有 mk-sweep/mk-breathe |
 | 动作 | 每张卡最多一个主动作，查看类为 ghost/链接 | 无需处理时不硬凑按钮 |
 | 长表/完整报告 | 详情/文件阅读档 | 默认卡只留摘要；宽表按需横向阅读 |
 卡内用 8/12/16 的重复间距；通过标题、段落和表面层级组织，避免一层卡套一层卡。圆角只用既有令牌，折叠统一 `@ui` Collapsible，状态动画只用 `mk-*`。所有图形状态同时有状态词与可访问名称。颜色不能替代状态语义。
 桌面沿用可拖三栏，右栏工作宽 280–560、文件阅读宽 420–1100 的现有规范。窄屏优先保留对话与 L0，任务摘要内联展开；文件仍通过同一预览对象打开。长文件名、中文长标题、18px 用户字号、320px 宽度都不得丢失必要动作。不得靠把全卡文字缩到 11px 解决拥挤。
 运行卡与完成卡沿用相同结构：结束后移除活动动效，当前工作区变为最终结论，保留来源与缺项。不要整张卡消失后另造结果卡造成位置跳变。最终文件卡的显示遵守 DESIGN.md：执行期仅说明草稿/保存状态，正式可打开交付物在结束并确认保存后出现；中途检查点文字可读，但不伪装成最终交付物。
 ## 13. 技术设计：确定性状态 + 可验证摘要
 ### 13.1 职责
 | 层 | 职责 | 不承担的职责 |
 |---|---|---|
 | Core | 定义任务摘要、发现、来源、动作能力的共享契约 | 不生成领域结论 |
 | Runtime | 提供真实执行阶段、工具结果、检查点和摘要候选 | 不自行宣告权限/存储/最终成功 |
 | Backend | 服务端权威投影、校验、持久化、事件发布与通知 | 不把模型叙述当执行证据 |
 | Frontend store | 按 task/run 与事件作用域更新同一快照 | 不由计时编造进度，不分别生成两套摘要 |
 | UI | 纯展示，稳定折叠/排版/动作事件 | 不直连模型，不拥有业务异步状态 |
 | Documents | 本方案、内容规范、验收与关联记录 | 不承担运行状态 |
 | 下游/插件 | 提供领域成果与受控丰富视图 | 不替代基座任务状态与权限 |
 优先在既有 runmgr/card/store 链路补齐投影，不另建进度微服务或独立状态仓。后台与前台按 runId 路由，前台消息仍用现有 live；后台进度使用按任务键控的结构化快照，防止共用单个 live 正文。
 ### 13.2 候选数据形状
 以下是契约草图，字段名在 Core 设计评审时固定，不是可直接执行的 API。
 ```text
 TaskSnapshot
  taskId, projectId, conversationId, sourceMessageId
  parentTaskId?, attemptId, runId?       # 排队时可以尚无 runId
  revision, streamScope, sourceSeq
  title, goal, inputRevision
  executionState, outcomeCompleteness
  phase { id, label, observedAt }
  focus, coverage, remaining, nextStep
  findings[] { id, text, impact, kind, status, sources[], revision }
  actions[] { id, capability, enabled, reason?, confirmationRef? }
  resultRefs[] { artifactId?, surfaceId?, version, availability }
  lastActivityAt?, lastMeaningfulUpdateAt
  deliveryState, error?
 ClientViewState                         # 展示偏好，不改业务状态
  taskId, collapsedSections, pinned, readRevision, scrollAnchor
  connectionState
 ```
 taskId 在排队前持久登记并关联同一张卡；runId 表示一次实际执行，attemptId 区分新尝试。旧失败和新尝试不互相覆盖。readRevision 与 dismissed/收纳分离，用户读过不意味着执行已完成。
 为兼容旧客户端，ActivityCard 可添加可选结构化摘要字段并保留 Body 的精炼回退投影；旧客户端看 Body，新客户端用结构化内容。核心信息的唯一权威仍是服务端快照；不得用独立 JSON、Markdown 和 Surface 各维护一份互不核对的业务状态。Body 与 Surface 是从同一快照派生的展示。
 ### 13.3 发布与恢复流程
 ```text
 真实运行事件/阶段成果
  → 运行时语义映射与摘要候选
  → 服务端校验：归属/执行对象/来源/权限/版本/长度
  → 原子保存快照 revision 与对应投影事件
  → 既有 card.updated 会话流发布
  → 前端按作用域 seq、taskId 和 revision 更新
  → L0/L1/L2 同步呈现
  → 关键变化进入幂等通知；L3 保留执行记录
 ```
 持久化与事件写入须原子一致；优先使用既有事务/持久事件机制，若当前 cards API 不能支持原子更新，先补齐内部事务入口。终态正文、状态、tone 应作为同一快照发布，避免先出现失败正文后仍亮成功灯。不能只靠客户端临时合并掩盖持久状态不一致。
 消费顺序按**会话流或项目流各自游标**；不同流的 seq 不可比较。重复事件不二次通知，旧 revision 不覆盖新快照；出现游标间隙先对账/重放，不仅执行 `max(seq)` 后跳过未知事件。会话切换隔离响应，迟到事件按归属放回缓存或丢弃，不能写到新会话。
 快照读取返回与其一致的重放水位；获取期间继续到来的事件需缓冲并在快照后顺序应用。排队、启动、最终保存、通知待发送均可刷新恢复；不得只把动态发现放在内存 `agentNotes`。恢复与副作用规则与既有服务恢复方案衔接，本次不建立第二套恢复执行器。
 **重启对账不能把展示快照当作执行队列。** 当前等待后台槽位的 bgQueue 仅在内存，无 runId 的排队卡不在既有 run 恢复扫描范围。U2 启动对账须区分“可读历史快照”与“已确认重新拥有执行者”：没有可信持久入队凭据或执行所有者的 queued 任务转为 interrupted，并同步旧卡回退状态与材料去重状态，显示“排队任务未恢复，未开始执行”，不自动重派。只有既有执行系统确认队列恢复后，才可继续显示排队并允许晋升；首次增量不承诺队列自动续跑。
 ### 13.4 生成式成果与普通任务卡
 已有 Surface 可用于对比表、报告页、审查清单；基础状态、风险提示、确认与失败始终由确定性组件呈现。后台 Surface 更新只提示“结果页已更新”，不自动切预览；需要在现有 Surface 投影策略中区分前台主动呈现与后台更新。
 插件禁用或页面渲染失败时，任务摘要仍可读，来源和基本动作仍可用。Surface 的动作继续走现有受控命令能力，不从摘要文本或外部材料解析可执行命令。
 ## 14. 落地顺序与 U1 出口白名单
 下表是已批准的分期顺序。**首批锁定仅 U1**；U1 业务代码须另批 [U1 实施计划](2026-10-12-fast-slow-channel-display-u1-plan.md) 后方可启动。各增量的具体文件、迁移、运行材料与费用以对应实施计划为准。
 | 增量 | 关联需求 | 范围与依赖 | 出口 |
 |---|---|---|---|
 | U1 统一状态与精炼内容 | R01/R02/R03-a/R08/R10（骨架）/R13 | Core/UI/Frontend/Backend；旧卡兼容及状态映射；L1 骨架重排；去除原始提示词默认展示 | 见下方 U1 出口白名单 |
 | U2 持久动态任务投影 | R04（活动投影）/R05（结构）/R06/R09/R12/R17/R03-b | 依赖 U1；材料内容版本身份校正前置；Core 契约 → Backend 快照/事务/事件及无 runId 排队重启对账 → Frontend 按任务路由 → UI 动态渲染；运行时确定性阶段 | 并发、刷新、重连、乱序和终态一致；阶段活动持续更新；无执行凭据的排队任务不得永久显示排队 |
 | U3 有价值的阶段成果 | R03-c/R04/R05/R07/R10（完备）/R14 | 依赖 U2；Runtime 检查点、来源、候选摘要、通知去重；优先材料整理，再研究/生成/审查 | 选定长任务至少两个真实成果检查点；短任务可直接完成；事实、判断、缺项可分；必要动作闭环 |
 | U4 场景与可用性完善 | R11/R12/R13/R15/R16/R18 | 依赖 U3；多任务总览、修订提醒、窄屏、可选 Surface、领域适配；未支持控制能力仍不暴露 | 典型场景完成真实浏览器及用户评审；精炼度与可用性目标有实际记录 |
 跨仓以 Core 类型权威优先；Backend vendored Core、Frontend/UI 消费固定提交；Dev 推进精确 gitlink，组合测试后评审。视觉规则变动需要与 DESIGN.md 配套；只消费既有令牌时不为本任务无故新增色板。
 ### U1 出口白名单（定稿）
 **须交付并可判定**
 - 排队 / 进行中 / 已完成 / 执行失败 状态词与状态灯一致；失败使用失败语义（不得再以「完成」灯表示失败）
 - 建卡默认 Body 为 L1 骨架，不以原始任务指令（≤400 字截断）作为主视图
 - 无阶段成果时显示诚实占位：「尚无阶段结论，正在读取材料」或等价文案
 - 完成卡骨架：结论 → 最多 3 要点 → 范围/缺项 → 产物入口（有则显示）→ 必要下一动作
 - 简单问答不产生空进度卡；仅登记成功才说「已登记」，仅实际开跑才显示「进行中」
 - 旧卡兼容：历史 `done + danger` 在新客户端映射为失败展示，不崩溃
 - DESIGN.md / 令牌 / Collapsible / `mk-*` 相关守护通过
 **明确排除（不得用 U1 验收）**
 - 运行中真实业务发现、来源定位、检查点驱动摘要（R03-c / U3）
 - 按 `taskId` 持久 `TaskSnapshot`、revision/seq 对账、材料内容 hash 身份（U2）
 - 无 runId 排队任务重启 → interrupted 对账（U2）
 - HITL 双入口提交中 / 超时未知 / 幂等闭环完备（U3）
 - 窄屏完整能力、多任务总览、Surface 增强、修订提醒（U4）
 - 暂停 / 独立取消 / 续跑等未支持控制能力
 合并 U1+U2 为基础投影批须**另行明确批准**；即便合并，阶段发现仍属 U3。
 ## 15. 验收、证据与失败判据
 所有下面的运行场景为**计划验收，NOT_RUN**。示例数据只用于评审排版，不当作真实链路通过证据。
 | 用例 | 关联需求 | 关键观察 |
 |---|---|---|
 | A01 三个附件、无文字直接发送 | R01–R05/R10 | 已确认接收 → 同卡排队/运行 → 有成果则发布 → 完成摘要与选择；选定长材料验证两个真实成果检查点，短材料可直接完成；不重复派发 |
 | A02 小材料加明确分析要求 | R01/R02/R04 | 即时答复与现有兜底路由一致；不声称尚未登记的任务已运行 |
 | A03 三个后台任务 + 前台对话 + 第四任务排队 | R02/R06/R09 | 各任务归属正确；排队晋升复用 ID/卡；前台正文不串后台 token |
 | A04 部分解析失败/无可解析文本/材料超预算 | R03/R05/R08 | 显示已覆盖、缺项与影响；解析与分析完成不混同；无法分析则不生成假摘要 |
 | A05 用户追问与补充重点 | R01/R07/R15 | 读取当前快照；新要求生效范围明确，未实现动态输入时不假承诺 |
 | A06 早期发现被推翻、来源文件更新 | R05/R17/R18 | 当前结论修正、历史可追溯；重要更正通知一次；同名等长内容更新不得命中旧材料结果；过期版本不覆盖最新 |
 | A07 断网、刷新、换会话、重复/乱序事件 | R06/R09/R12 | 保留最后快照；恢复水位一致；状态不回退；旧会话数据不写入新会话 |
 | A08 模型失败、预算耗尽、摘要不可用、服务中断 | R08/R09/R14 | 正确显示失败/中断；包含无 runId 的排队任务重启后对账及材料去重释放；基础状态与既有成果仍可读；无自动副作用重试 |
 | A09 前台忙时后台完成、通知重投 | R04/R10/R17 | 结果卡先可读；汇报待空闲；重投不重复通知或派任务 |
 | A10 同确认双入口与重复点击 | R07/R11 | 提交中、成功、拒绝、超时未知、过期/已处理响应都一致；重复点击只执行一次；右栏关闭也可处理 |
 | A11 文件正被阅读、Surface 后台更新/插件关闭 | R11/R12/R16 | 不抢焦点、不切文件；插件关闭核心任务卡不缺失 |
 | A12 未授权跨项目/用户来源、读权限撤销 | R05/R09 | 新摘要、来源与历史缓存无越权；只显示许可范围内内容 |
 | A13 文件保存失败、文件已更新/已移除 | R08/R10/R17 | 不出现虚假可打开工件；版本与保存状态准确；有可读摘要不等于已保存文件 |
 | A14 320/390/736/1024/1440 宽度与用户字号档 | R11/R13 | 无页面级横向溢出，必要动作可达，键盘/屏幕阅读/减少动效符合规范 |
 验证分三层：契约与投影测试确认状态/顺序/并发；真实模型任务前后对照确认阶段成果质量；真实浏览器与用户任务确认排版和工作价值。不能用 mock 进度验证真实模型发布了有用摘要。
 行为改动按 policy/delivery.md 真实模型要求执行：固定候选组合、同材料同任务前后对照、记录模型/参数/费用/失败及来源。正式检查使用 `make evidence` 写入 precheck、task-sync 和相关测试原始输出；Dev CI 在 PR HEAD 上的 `make test`、`make build` 作为 GATE，作者本地记录仍为 SELF。设计文档检查不代替这些运行验证。
 可用性记录至少覆盖三类任务：材料整理、分析审查、文档生成。请代表性用户完成第 1 节三问并定位一条来源、处理一次确认、找到一份结果；记录完成时间与错误。精炼度以“是否漏掉关键限定/风险、是否能支持下一步工作”评判，不能只统计字数变短。
 实施停止/回退条件：发现状态串任务或越权内容；终态与存储不一致；修订导致当前有效结论丢失；摘要循环显著超预算；关键确认被折叠藏起；真实模型阶段成果持续无依据。先回退受影响展示/摘要增量，保留原执行与已保存结果，按实际影响重审。
 ## 16. 评审与当前进展
 | 项目 | 当前状态 |
 |---|---|
 | 当前源码核对 | SELF；固定对象与输出在任务卡；不等于运行验收 |
 | 需求拆解 / 需求评估 / 需求表 / 方案设计（阶段 1–4） | **已通过**（2026-10-12，对象版本 r1.1；评审人 weichen；依据：用户确认评审结论计划并指示落地） |
 | 实施计划（阶段 5） | U1 计划见 [u1-plan](2026-10-12-fast-slow-channel-display-u1-plan.md)；**待用户批准该计划后**方可启动业务代码 |
 | 辅助设计审阅 | 七个视角 SELF 辅助分析已纳入 r1；不提升为 REPLAY/GATE |
 | 业务实施、真实模型实验、运行与浏览器验收 | NOT_RUN |
 | 推送、PR、合入、部署 | 本方案任务未执行；文档推送/PR 须另获授权 |
 本次推进的是快慢通道用户展示设计，不改变现有附件路由和生成式 UI 规划的批准状态。与既有恢复/团队存储方案的重叠仅为消费其执行终态、权限与恢复能力；新增持久字段和事务入口须评审后协调，不自行修改其他任务的主记录。
 辅助审阅覆盖一致性、范围、可行性、设计、产品、对抗与安全七个视角（其中一致性/范围、设计/产品/对抗/安全分别由同一子代理分析，并非七名独立审阅者）。采纳并自行核对后修订五类问题：两次成果检查点只用于代表性长任务；新增要求的生效文案不误导；确认双入口补提交与未知结果状态；材料版本复用需实际内容身份；无 runId 排队任务重启时不能假装仍有执行者。
 r1.1 相对 r1 的定稿修订：R03 切分为 a/b/c；U1 出口白名单与排除项写入 §14；首批锁定仅 U1。摘要次数/窗口与性能数字仍为候选参数。**设计批准不等于实施授权**；批准 U1 实施计划后另开实施任务，本设计任务不自动启动写代码。
@@ -0,0 +1,48 @@
 ---
 title: Generative UI auto-trigger opt-in design
 date: 2026-10-12
 type: feat
 revision: r1
 status: approved
 product_contract_source: generative-ui-r2-U6-U7-boundary
 ---
 # Generative UI 自动触发 opt-in 设计（r1）
 依据：主记录 r2（语义事件 / 预算 / 防自激）；收口稿已知边界；用户 2026-10-12
 计划确认「边界三项全部做」并将本表定案作为实施基线。
 负责人：裁定 weichen（用户，经执行计划确认）；起草 Agent；更新时间 2026-10-12。
 ## 定案表
 | 项 | 定案 |
 |---|---|
 | 开关 | owner 级 settings：`plugins.generative-ui.autoPresent`，默认 `false`；**不**写入 `plugin_activation`（避免 bump epoch） |
 | 前提 | `plugin_activation(generative-ui).enabled` 为真；否则 auto 无效 |
 | 事件 | 仅：任务阶段跃迁（plan/todo 状态变化）、材料/工件完成（material notice、document artifact） |
 | 禁止事件 | per-token / 每条 SSE、`surface.updated`、动作回执、present 成功路径 |
 | 动作 | 注入 system-reminder，**只**建议调用一次 `generative-ui.present`；不自动点 actions；不改写任务事实 |
 | 预算 | 每任务（conversation）每小时 ≤3 次；耗尽写审计 `genui.auto_present_exhausted` |
 | 冷却 | 同会话自动触发间隔 ≥60s |
 | UX | 复用 U6 pin/follow；固定后新页不抢占 |
 | 门槛 | 扩大范围仍以人类效率约 +20% 为后续条件；本增量只落地最小 opt-in |
 ## 实施面
 - Backend：settings schema/defaults；`genui.Auto` 闸门；runmgr 语义钩子；审计。
 - Frontend：SettingsModal 经 schema 出开关（无需专用页）。
 - Documents：本提案 + 使用说明边界条目更新。
 ## 验收线
 1. 默认关：无 reminder / 无额外 present 建议。
 2. 仅 activation∧opt-in 时，材料完成 / 阶段跃迁 / document 工件可触发。
 3. surface/action/present 路径不重入。
 4. 第 4 次/小时审计耗尽并停止。
 5. 冷却内跳过。
 ## 裁定记录
 用户经「Implement the plan」确认本定案表；本文 `status: approved`，实施任务
 `feature/genui-auto-trigger-optin` 按本表交付。
@@ -0,0 +1,59 @@
 ---
 title: Generative UI B-class whitelist — builtin.help and system.intent
 date: 2026-10-12
 type: feat
 revision: r1
 status: approved
 product_contract_source: generative-ui-u5-action-scope-r2
 ---
 # Generative UI B 类加白提案：builtin.help / system.intent
 依据：[U5 动作范围 r2](./2026-10-11-generative-ui-u5-action-scope.md)「每加一条走独立评审」。
 本提案对两条命令分别裁定；实施与本提案同批合入。
 负责人：裁定 weichen（用户）；起草 Agent；更新时间 2026-10-12。
 ## 授权
 用户 2026-10-12 计划确认：边界三项全部推进；B 类首批加白 `builtin.help` 与
 `system.intent`。交付模式：authorized-continuous（本增量实施至 Dev 合入）。
 ## 一、builtin.help（独立裁定）
 | 项 | 内容 |
 |---|---|
 | 命令 id / action id | `builtin.help` |
 | 类 | B（白名单命令绑定） |
 | 危险级 | 低（只读说明，无写副作用） |
 | 参数 | 无必填 |
 | 通道 | `POST /api/surfaces/{id}/actions` → cmdbus Entrance=`button` |
 | 用途 | 页面按钮展示可用命令/入口说明 |
 | 排除项对照 | 非业务写、非跨会话、非自动触发动作、非 MCP |
 **裁定**：同意加白。
 ## 二、system.intent（独立裁定）
 | 项 | 内容 |
 |---|---|
 | 命令 id / action id | `system.intent` |
 | 类 | B（白名单命令绑定） |
 | 危险级 | 入口本身低；**命中后嵌套分发可触达写命令**（既有 chat 行为） |
 | 参数 | `text`（string，必填） |
 | 通道 | 同上 Entrance=`button` |
 | 硬化（加白前提） | **button 入口只返回 match / candidates，禁止嵌套 `Dispatch` 目标命令**；chat/slash/api 等既有入口行为不变 |
 | 用途 | 页面上做意图探测/候选展示，不经按钮偷渡 D 类写 |
 | 排除项对照 | 嵌套业务写在 button 路径关闭；仍禁止自动触发动作、MCP、任意命令全开 |
 **裁定**：同意加白，前提硬化生效并有红测。
 ## 三、实施面
 - Backend：`surfacesvc.AllowedActions`；`genui.ValidateActionIDs` / Catalog；`handleSystemIntent` button 只读。
 - Documents：本提案 + 使用说明 API/动作表白名单更新。
 - 红测：白名单外拒绝；help 可分发；intent button 命中写意图零副作用；chat 仍可嵌套。
 ## 四、明确不做
 D 类业务写直执、扩大白名单至其他内置写命令、自动触发动作、动作结果自动改写页面。
@@ -49,7 +49,7 @@ curl -X POST ... -d '{"enabled":false}'
 | GET /api/surfaces/{id} | 读取整页快照（禁用后仍可读） |
 | GET /api/conversations/{id}/surfaces | 会话内页面列表 |
 | GET /api/projects/{id}/surfaces | 项目级跨会话聚合（U6） |
-| POST /api/surfaces/{id}/actions | 页面动作（白名单 generative-ui.submit） |
+| POST /api/surfaces/{id}/actions | 页面动作（白名单：generative-ui.submit、builtin.help、system.intent；后者 button 只读匹配） |
 ## 二、U1–U6 落地与评测结论
@@ -77,13 +77,25 @@ Frontend #58/#59，Dev #381/#382/#387/#388）：工具描述缺「何时用」
 - 工作区：前端「任务页面」容器显示最新页（pin/follow 测试覆盖）。
 - 收据：Dev 任务卡 feature/generative-ui-u7-acceptance（SELF；CI GATE 随发布 PR）。
-### 已知边界与后续项
+### 现场体验驱动的修复记录
- 自动触发模式默认关闭（后续 opt-in，需预算与防自激设计）。
+| 日期 | 症状 | 修复 | PR |
- B 类命令白名单为空起步，逐条经独立评审加白（U5 提案 r2 约定）。
+|---|---|---|---|
 | 2026-10-12 | `POST /api/surfaces/{id}/actions` 对无确认卡的 committed 动作 panic（nil Card） | dispatcher 空指针守卫 | Backend#173 |
 | 2026-10-12 | `system.intent` button 动作恒报 missing text | action data 键上浮到命令 params | Backend#174 |
 ## 已知边界与后续项
 - 自动触发 opt-in：settings `plugins.generative-ui.autoPresent`（默认关；须同时
  Surface activation）；语义事件 + 预算≤3/时 + 冷却≥60s；设计见
  `2026-10-12-generative-ui-auto-trigger.md`。
 - B 类命令：已加白 `builtin.help` / `system.intent`（button 入口 intent 只读匹配、
  不嵌套分发；提案 `2026-10-12-generative-ui-bclass-help-intent.md`）；其余仍逐条评审。
 - 人类可用性对照以 owner 实际使用替代（2026-10-11 用户裁定），本轮体感「初步不错」，
  小问题另行修复。
- 部署与运行验收按独立授权推进。
+- 部署与运行验收：本机 `prod` 实例已登记（`scripts/svc.sh prod`，`--auth on`，
  PG `pg1/prod`，来源 `dev@c76f2bb`+后端 nil-card 修复）；验收覆盖启禁、present、
  B/C 类动作、项目聚合、未登录 401。
 ## 三、结论
@@ -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 统一解析已接线；manifest/marker 和 Backend DB identity 已存在；manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env；自定义根和 legacy/direct 启动需要完整核验；identity 不等于活动服务独占锁 |
-| 服务生命周期 | svc 管理 agent/static/postgres；PostgreSQL 复用 pgdata；分发仓有单应用 systemd 模板 | svc 没有服务组依赖恢复与持久启动意图；无统一进程组监管；不管理 Redis 类型 |
+| 服务生命周期 | 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 推进与运行验收未执行。
@@ -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 规划补充
@@ -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
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
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	16cafca00c	Approve Generative UI auto-trigger opt-in design Why: Capture the fixed opt-in/budget/anti-self-trigger decisions and update the usage guide boundary list. Evidence: proposal r1 status approved Impact: Authority for backend auto-present implementation. Refs: plan GenUI boundaries T2/T3 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 03:46:26 +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
weichen	3e68448f11	Merge pull request 'Record the admin-zone partition delivery in the two-trees plan (WP3-I3)' (#78 ) from feature/adminzone-plan-progress into main	2026-10-12 03:28:53 +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
weichen	0b314e2029	Record the admin-zone partition delivery in the two-trees plan progress Why: policy requires updating applicable plan progress on task completion; WP3-I3 landed the admin-zone entrance via the generic declaration mechanism. Evidence: Dev PR #414 and live verification comment (R5, SELF). Impact: progress line of 2026-10-11-rdm-two-trees-trace-audit-integration.md only. Refs: WP3-I3/KTD4.	2026-10-12 03:24:50 +00:00
weichen	62da617648	Merge pull request 'Approve B-class allowlist for help and intent actions' (#77 ) from feature/genui-bclass-help-intent into main	2026-10-12 03:23:27 +00:00
weichenandCursor	7fbfad1851	Approve B-class allowlist for help and intent actions Why: Record the independent U5-style review for the first two B-class surface actions and update the usage guide allowlist note. Evidence: proposal r1 status approved; usage doc API table updated. Impact: Documents authority for backend whitelist implementation. Refs: U5 action-scope r2; plan GenUI boundaries 2026-10-12 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-12 03:19:03 +00:00
weichen	b680142586	Merge pull request 'Add the Generative UI usage guide and U1-U6 evaluation record (final)' (#76 ) from feature/generative-ui-u7 into main	2026-10-12 02:47:50 +00:00