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
Merge pull request 'Propose RDM function implementation plan r1' (#85 ) from feature/rdm-function-plan-r1 into main
2026-10-12 12:07:02 +00:00 · 2026-10-12 09:29:03 +00:00 · 2026-10-12 09:28:44 +00:00 · 2026-10-12 07:39:03 +00:00 · 2026-10-12 07:33:22 +00:00 · 2026-10-12 07:31:46 +00:00
12 changed files with 1641 additions and 13 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；确认状态：**已批准（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 正式双实例负载 **测量中/待回填**；双主机 C3、运维演练 C4/C5 未做。**不承诺容量数字，不放行第二实例承接写请求**，直至检查单对应项有可复核证据。
 需求来源：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 实施由独立任务承接。
+关联任务：方案卡已归档 `.task/archive/feature-collaboration-storage-plan.md`；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 绿；容量阈值的正式测量、双主机部署目标、灾难恢复运维演练仍待窗口证据。本地 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/组合验证流程交付。
+首选下一增量是 **完成本机容量测量窗口并回填检查单**（`--seed contract` + 双实例 `ladder` / `sustained60m` / `sustained2h`，入口 `tests/load/collaboration/`；结果写入 Dev `docs/release-multi-instance.md` 与本仓容量报告）。其后候选项：**C3 双主机验证**（需用户指定第二主机）或 **C4/C5 运维演练**（PG/Redis 断连恢复与备份恢复）。不要在容量与双进程负载未过前开放第二实例写。各实现任务启动前复核在途 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 |
@@ -0,0 +1,182 @@
 ---
 title: svc 统一部署与一次性登录 Key 方案
 type: feature
 date: 2026-10-12
 artifact_contract: ce-unified-plan/v1
 execution: code
 product_contract_source: ce-plan-bootstrap
 ---
 # svc 统一部署与一次性登录 Key 方案 r1
 确认状态：**已批准**（2026-10-12 用户「批准，继续推进」：需求拆解→实施计划五阶段及 U1/U4 规格一并批准；授权推送/PR 与启动 U1/U4 实施；合入仍由 owner 执行）。业务实施、测试、部署与运行验收在批准时仍为 **NOT_RUN**，由后续实施任务推进。
 修订记录：r1＝2026-10-12 草案经源码复核后定稿（四项取舍采纳；补齐 §6 合同；对齐恢复方案 KTD 与已合入的 recovery U1 实例身份）；同日获批并进入推送与 U1/U4 实施。
 需求来源：2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口（二进制与源码、环境准备、无初始密码开户与账户恢复），并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人：weichen；编制：Cursor Agent。
 主记录：本文；任务卡：Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。
 ## 1. 目标与成功边界
 **目标：在干净或既有机器上，用同一套 `svc` 入口完成二进制或源码部署、按档准备依赖，并通过后端账户能力完成无初始密码开户与账户恢复；一次性登录 Key 只能兑换设密受限会话，完成设密前不能访问业务数据。**
 必须区分三类能力：
 | 能力 | 结果 | 非目标 |
 |---|---|---|
 | 统一安装 / 升级 | 指定版本或提交物化为可切换候选；切换后实例身份、DB、数据根与账户不变 | 不接管共享 PostgreSQL；不因发现端口而认领外部服务 |
 | 环境检测与准备 | `doctor` 只报告；`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建；工具链版本读自所选提交或发布清单 |
 | 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key；原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户；不迁移业务归属；普通找回默认不撤销长期集成 Key |
 与 [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md) 的关系：
 - **复用** KTD1–5、KTD12：持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。
 - **复用** 已合入的 recovery U1（Dev #415）：`runtime/<name>/manifest.json`、启动身份校验、`svc init`、原子写路径（见 Dev `docs/recovery/u1-identity-manifest.md`）。
 - **本方案新增**：部署来源统一（binary/source）、doctor/env prepare、账户生命周期与一次性登录 Key、安装入口与双轨收敛。
 - 命名区分：**账户恢复 Key** ≠ **服务数据恢复**。
 ## 2. 当前事实及重点差距
 源码基线（SELF·工作区观察，启动 precheck READY）：Dev `af9c2de663be5ff102dcab7698464a645832f569`；Backend gitlink 以该提交为准；本地评审时曾对照 `3fa0d3a` / Backend `696ef15`，与当前 main 可能有漂移，实施前以 `task-sync` 后 SHA 为准。运行验收 **NOT_RUN**。
 | 对象 | 已存在的基础 | 尚需补齐 |
 |---|---|---|
 | 部署来源 | `deploy --from local\|dev\|release\|rdm`；dev/rdm 独立缓存物化；release 读本地 Releases 仓并校验 sha256 | 远程下载/离线导入；统一 `install`；release@ver 钉扎（现 `sort -V\|tail -1` 取最大版本，见 `scripts/svc.sh` `resolve_release`） |
 | 部署生命周期 | 预检失败不停机；预检通过后 **先停再构建**；无程序备份/自动回滚 | 候选获取与校验全程不停旧服务；缺摘要硬失败；迁移后回退独立判断 |
 | 实例身份 | recovery U1：manifest + marker + init；`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置；缺绑定拒绝，禁止回落 `./data` |
 | 环境 | 端口/`flock`/pg 工具链按需检查；文档列前提 | `doctor` / `env prepare`；无 `flock` 时不得放行冲突操作（现状直通） |
 | 账户 CLI | `user create\|reset-password\|list`；省略密码 → 随机明文一次 + `must_change` | 无密码创建 + 激活 Key；恢复 Key；OpenExisting（不建空库、不静默 migrate） |
 | API Key | 明文只显示一次；可长期复用；无 TTL/次数 | **独立**一次性登录凭据表；不可走 Bearer/`?key=` |
 | 强制改密 | 前端门控 + `/api/me` 标志；`changePassword` 要求原密码 | 服务端中间件拦截待改密/受限会话；设密分型（一次性会话不要求原密码） |
 | 安装双轨 | Dev `svc deploy` 多实例；Releases `install.sh` 系统 systemd | 统一部署计划；`install.sh` 薄封装或明确遗留 |
 命题裁定（源码复核）：
 1. 长期 API Key 是 **show-once plaintext，不是 single-use** — **成立**。
 2. **无**统一中间件拦截 `must_change_password` — **成立**。
 ## 3. 需求合同
 | ID | 范围 | 要求与可判定验收 |
 |---|---|---|
 | R1 | 安装入口 | `doctor` / `install` / 兼容 `--from` 生成同一部署计划；二进制无需 Go/Node；源码固定提交且子模块组合可核验 |
 | R2 | 实例身份 | 启停、升级、开户、签发 Key 命中同一 store 与 data 根；缺失/不符拒绝；与恢复案 R2/manifest 一致 |
 | R3 | 切换安全 | 构建/下载/摘要失败时旧服务继续；程序+插件+前端作为版本组合切换；固定版本不得被「最大版本」替代 |
 | R4 | 存储档 | team 默认 PG+auth；`existing` / `managed-local` / `local(SQLite)` 显式选择；PG 失败不回落 SQLite |
 | R5 | 开户 | 无初始密码；角色明确；创建与激活 Key 同事务；同名冲突不覆盖 |
 | R6 | 账户恢复 | 精确命中既有账户；不改密码/不吊销会话/不改业务数据于签发时；保持 owner/角色/成员关系 |
 | R7 | 一次性 Key | ≥256bit、只存摘要、activate\|recover、默认 TTL 30min、状态机、原子兑换、专用 POST body |
 | R8 | 受限会话 | 仅身份查询、设密、退出；业务/下载/SSE/admin/插件拒绝；普通 `must_change` 同样服务端限制 |
 | R9 | 设密事务 | 写 hash、清待激活/待改密、作废未用恢复凭据、失效相关会话同事务；成功后销毁受限会话并要求密码重新登录 |
 | R10 | 集成 Key | 普通找回默认保留长期 API Key；失陷恢复显式 `--revoke-all-credentials` |
 | R11 | 首次管理员 | 仅核验为新实例（无用户且无历史业务标记）；事务防并发；不得因「未发现管理员」接管有数据环境 |
 | R12 | 证据 | 验收绑定固定源码/制品摘要/环境；SELF/REPLAY/GATE 分源 |
 ## 4. 技术决策（KTD）
 KTD1. **部署方式只决定程序来源，不决定数据位置。** binary ↔ source 可切换；切换保持 DB、数据根、账户与 instance_id。
 KTD2. **账户规则只在 Go 后端。** 脚本调用实例对应版本的 CLI；不直接改用户表。
 KTD3. **一次性登录凭据独立于长期 `api_keys`。** 专用表与兑换 API；普通 Bearer、SSE `?key=`、长期 Key 路径均拒绝。
 KTD4. **受限会话为独立 scope。** 默认 10 分钟；allowlist 仅 me / 设密 / logout。
 KTD5. **团队安装默认 PostgreSQL；存储选择显式。** 与恢复 KTD5、`config.Tier=team` 一致。
 KTD6. **一次性 Key 默认 30 分钟**（可配置建议范围 5–120 分钟）；审计记实际 TTL。
 KTD7. **激活/恢复设密成功后必须重新密码登录**（销毁受限会话、清 cookie）。普通主动改密可保留「要求原密码」路径；激活路径不要求原密码。
 KTD8. **普通账户恢复默认保留长期集成 Key；失陷显式撤销全部凭据。** 两种情况均保留业务数据。
 KTD9. **候选校验完成前不停旧服务**；切换短窗；schema 迁移后能否自动回退旧程序另行判断，失败不自动用备份覆盖业务库。
 KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端；Releases `install.sh` 变为薄封装或文档降级为遗留，禁止第三套生命周期。
 ## 5. 职责划分与接口示例
 | 部分 | 负责 |
 |---|---|
 | `svc.sh` | doctor、env prepare、获取制品、构建、实例配置、生命周期、调用账户 CLI |
 | 后端 CLI | 创建账户、签发/撤销一次性 Key、核验目标库、OpenExisting、操作审计 |
 | 后端认证 | 原子消费 Key、受限会话、设密事务、中间件限制 |
 | 登录页 | 输入一次性 Key、设密、过期/重发提示；遵循 `DESIGN.md` |
 | 发布制品 | 版本、平台、摘要、组件版本、能力声明 |
 拟新增 CLI（当前脚本尚不支持；兼容 `--from` 保留）：
 ```bash
 ./svc.sh doctor --mode binary --tier team
 ./svc.sh install prod --mode binary --version <固定版本>
 ./svc.sh install prod --mode source --repo <仓库> --ref <固定提交>
 ./svc.sh prod deploy --mode binary --version <固定版本>
 ./svc.sh prod user create --owner alice --role user
 ./svc.sh prod user issue-login-key --owner alice --purpose recover
 ./svc.sh prod user list
 ./svc.sh prod user revoke-login-key --id <凭据编号>
 ```
 Linux 服务账户与应用账户分开管理。
 ## 6. 规格合同（实施前必须写进 U1/U4，否则返工）
 1. 独立凭据类型 + `POST` body 兑换 API。
 2. 会话 scope / 中间件 allowlist；覆盖 `must_change` 普通首登。
 3. 设密接口分型：受限会话不校验原密码；普通改密继续要求原密码；同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。
 4. 密码未设置状态：`password_hash` 可空或 sentinel；`VerifyLogin` 拒绝未设密；创建 = 用户行 + 激活 Key 同事务。
 5. CLI `OpenExisting`：目录/DB 不存在则失败；运维模式可禁止自动 migrate / 要求 schema 兼容。
 6. `release@<ver>` 必须解析到该版本目录；缺摘要硬失败。
 7. 部署：获取/构建/校验不停旧服务；组合切换；迁移后回退独立判断。
 8. `install` 与 `--from` 同一计划；双轨收敛（KTD10）。
 9. 首次管理员仅新实例；事务防并发。
 10. 凭据交付：交互 stdout 一次 / 非交互 `chmod 600` 文件；日志与 evidence 只记凭据 ID；随机密码路径首期可并存但默认无密码 + Key。
 11. 无 `flock` 时拒绝冲突生命周期与账户操作（收紧现状「直通」）。
 详细设计（正文在 Dev 仓，随本任务分支提交）：
 - U1：`docs/svc-deploy/u1-instance-account-binding.md`
 - U4：`docs/svc-deploy/u4-one-time-login-key.md`
 ## 7. 增量与完成门槛
 | 增量 | 主要范围 | 完成条件 |
 |---|---|---|
 | **U1** 实例—账户绑定补齐 | 账户 CLI 读实例 manifest；OpenExisting；锁缺失拒绝；install 骨架对接既有 identity | 开户/签发命中同一 store；错误 data/DSN 拒绝；与 recovery U1 字段对齐 |
 | **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署；固定版本与摘要可核验；修复 release 钉扎 |
 | **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验；幂等；不接管共享服务；binary 不装 Go/Node |
 | **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密；受限会话无法调业务 API；并发兑换单胜 |
 | **U5** 脚本与登录页接线 | 账户命令、首次管理员、凭据交付、Login/设密页 | 新建与恢复走通；刷新与异常可续；DESIGN.md |
 | **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档；故障注入；浏览器 + 真机；治理回归 |
 **近期优先 U1、U4**（可并行兄弟分支、共用 R0）。跨仓顺序：Backend（U4）→ Frontend（U5）→ Dev gitlink + `svc.sh`（U1/U2/U3/U5）；组合 `make test` 后宣称可合入。
 ### 必须覆盖的验收场景（摘要）
 干净机器二进制安装；源码固定提交与子模块；两种部署互切后数据不变；构建/摘要/配置失败旧服务可用；PG 身份不符拒绝且不回落 SQLite；无密码开户且不覆盖既有；同 Key 并发兑换仅一次成功；受限会话拒业务/SSE/admin；消费后建会话失败与设密中途失败无半完成态；恢复前后业务与权限对账；SQLite 与真实 PG；治理回归；源码测试不代替浏览器与真机。
 额外钉住：`release@v` 多版本不得装成更高版本；账户 CLI 不得回落默认 `./data`。
 ## 8. 一次性 Key 流程
 ```mermaid
 flowchart LR
  A["创建账户或签发恢复 Key"] --> B["输入一次性 Key"]
  B --> C["后端原子消费"]
  C --> D["仅允许设置密码的短期会话"]
  D --> E["设置并确认新密码"]
  E --> F["作废恢复凭据及相关旧会话"]
  F --> G["使用新密码正常登录"]
 ```
 凭据规则：独立前缀；只存摘要；用途 `activate`|`recover`；状态未使用/已消费/已撤销/已过期；密码变更后旧恢复凭据不可再用。符合 [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 与 [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)；保留现有 CSRF 校验。
 ## 9. 风险与未授权范围
 - 实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。
 - 本任务交付终点：正式提案 r1 + U1/U4 规格 + 任务卡与索引入口；推送/PR 须另获授权。
 - 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。
 ## 10. 规划进展与下一步
 - 本次推进：源码复核；四项取舍定案；正式提案 r1；U1/U4 规格细化。
 - 首选下一任务（**待授权**）：并行启动 U1 实施与 U4 实施（兄弟分支、共用 R0）；U2/U3 规格可随后写作但不阻塞 U1/U4。
 - 前置：人工批准本提案 r1（至少需求表 + 方案设计 + U1/U4 实施计划阶段）；实施前 `make precheck` 与 `task-sync`。
@@ -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→命令总线集成测试门禁，且历史三条回归仍绿，可将本条降为参考；不得在无门禁时退役。
Author	SHA1	Message	Date
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	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