Compare commits

..
Author SHA1 Message Date
weichen 10b0dbe908 Merge the current Documents baseline and preserve both planning entries
Why: retain the newly merged RDM U1 progress alongside the final-target plan.

Evidence: resolved the single index conflict by keeping the updated U1 entry and both new plan links; diff check passed.

Impact: documentation merge only; business validation NOT_RUN.

Refs: docs/proposals/INDEX.md
2026-10-11 08:54:39 +00:00
weichen 6183e99cdb Plan full RDM delivery around shared projects and controlled documents
Why: reconcile the confirmed project, privacy and duty rules with all approved product requirements.

Evidence: current RDM d8d7e743 source review, recorded source receipt, and exact 34 UR/68 SR/10 F matrix checks; business validation NOT_RUN.

Impact: reviewed planning documents only, covering all 69 template types and the existing XLSX asset; no runtime changes.

Refs: docs/proposals/2026-10-11-rdm-final-target-completion.md
2026-10-11 08:54:07 +00:00
weichen 2a5f658d25 Merge pull request 'Record U1 progress in the two-trees master plan and index' (#66) from feature/rdm-u1-closeout into main 2026-10-11 08:44:37 +00:00
weichen 6efdd7dbc7 Record U1 progress in the two-trees master plan and index
Why: U1 landed via RDM PR #195 (merge 05b7d1a); delivery policy requires the master record to reflect actual progress at task completion.

Evidence: SELF closeout doc check exit 0 (receipt in the Dev closeout task card); RDM PR #195 merged=True via API.

Impact: proposal status line, U1 progress paragraph, and INDEX row only; no scope or requirement change.

Refs: RDM PR #195; Dev feature/rdm-u1-closeout
2026-10-11 08:44:18 +00:00
weichen 90f73ba4e8 Record the confirmed pilot documents and full-catalog direction
Why: preserve the user decision from the previous planning turn before expanding scope.

Evidence: r1.1 records the explicit user response; prior documentation-check receipt is in the Dev task card.

Impact: planning metadata only; no business changes.

Refs: docs/proposals/2026-10-11-rdm-template-dialog-generation.md
2026-10-11 08:39:47 +00:00
weichen 99a54ed340 Merge pull request 'Document the storage-migrate tool and the switch/drill runbook (U4)' (#65) from feature/collab-storage-u4-migrator into main 2026-10-11 08:30:00 +00:00
weichen ca9b128f18 Document the storage-migrate tool and the switch/drill runbook (U4)
Why: U4 ships the managed migration entry; the runbook is the operator-facing contract for inventory/backup/migrate, migration identity and resume rules, verification semantics, and the authorized-window switch sequence.

Evidence: backend branch feature/collab-storage-u4-migrator - integration tests green against real PostgreSQL (idempotent rerun, resume, foreign-data refusal, wrong-snapshot refusal, unknown-owner block).

Impact: docs only.

Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md U4 and section 6.
2026-10-11 08:29:38 +00:00
weichen db6daafde4 Plan template-driven document generation through project conversations
Why: connect the existing RDM assets and two-trees model to a reviewable document workflow.

Evidence: source inventory at RDM 0081628a; document structure and local link checks recorded as SELF in the Dev task card; business validation NOT_RUN.

Impact: planning and inventory documents only; no implementation or deployment.

Refs: docs/proposals/2026-10-11-rdm-template-dialog-generation.md
2026-10-11 08:23:53 +00:00
weichen 5ac58dcd7e Merge pull request 'Document the execution budget settings and the KTD13 action-authz compat plan' (#64) from feature/collab-storage-u3-budget-authz into main 2026-10-11 05:16:45 +00:00
weichen 0be6c2d3ee Document the execution budget settings and the KTD13 action-authz compat plan
Why: U3 slice 2 ships admission budgets (runtime.* keys, lease semantics, yield/reacquire) and the host-side action matrix; the runbook is the single source for operators and records the versioned public-contract plan KTD13 requires.

Evidence: backend branch feature/collab-storage-u3-budget-authz (admission.go, action matrix in server.go) with admission/matrix tests green.

Impact: docs only.

Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md KTD13/R8, section 5 U3.
2026-10-11 05:15:49 +00:00
weichen d3e40c783d Merge pull request 'Publish the approved two-trees traceability plan r1 with user rulings' (#63) from feature/rdm-two-trees-audit-plan into main 2026-10-11 04:43:31 +00:00
weichen 76f49b2bc7 Merge authoritative main into the task branch
Why: branch protection requires the head to contain the current base before merge.

Evidence: fetched origin/main=336a90f0ade0ffe049879ca5159a61f0a3948708.

Impact: integrate upstream changes without rewriting task history.

Refs: Documents PR #63
2026-10-11 04:43:23 +00:00
weichen 336a90f0ad Merge pull request 'Revise the Generative UI proposal to r2 with the U1 trial results' (#62) from feature/generative-ui-u1 into main 2026-10-11 04:42:48 +00:00
weichen 474955b64d Revise the Generative UI proposal to r2 with the U1 trial results
Why: The U1 controlled trial (three arms on synthetic materials,
MiniMax M3 + M2.7-highspeed, CNY 3 spent of the 200 cap) finished on
2026-10-11; its evidence changes the plan and must live in the master
record: goal-driven structure divergence holds (6/6), generation must
go through tool arguments (text-channel JSON discipline is the floor),
highspeed is rejected as the generator, and the first release keeps the
in-house renderer.

Evidence: Full data and failure taxonomy in Dev task
feature/generative-ui-u1 (.task/genui-u1/report.md, SELF; CI gate on
the Dev PR). Tool-channel and response_format probes recorded there.

Impact: Proposal r1 -> r2 (new results section, catalog/model/channel
revisions); INDEX entry updated. No code or contract changes.

Refs: Dev task feature/generative-ui-u1; Documents PR #60 (r1)
2026-10-11 04:42:37 +00:00
weichen b857595025 Publish the approved two-trees traceability plan r1 with user rulings
Why: the user reviewed and approved the plan (2026-10-11, five stages bundled) and chose a two-tier admin model for KTD4 instead of strict ledger separation.

Evidence: SELF user session rulings recorded in the Dev task card; document-check receipt follows in the task card evidence section.

Impact: proposal r1 and INDEX now record approval and the two-tier admin ruling; no code or deployment change.

Refs: Dev feature/rdm-two-trees-audit-plan
2026-10-11 04:41:29 +00:00
weichen b3171b3d51 Plan RDM project traceability and audit integration
Why: assess existing two-tree and trace-network capabilities and define project-scoped inspection.

Evidence: SELF source receipt and document checks; business and runtime verification were not run.

Impact: pending-review proposal and index only; no product implementation or deployment.

Refs: Dev feature/rdm-two-trees-audit-plan
2026-10-11 04:02:38 +00:00
weichen 3e2d8c9049 Merge pull request 'Add the team-storage runbook for U1 and cross-link usage' (#61) from feature/collab-storage-pg-tier into main 2026-10-11 03:14:09 +00:00
weichen a47ef7ffcf Merge authoritative main into the task branch 2026-10-11 03:14:06 +00:00
weichen 3304efee15 Merge pull request 'Publish the Generative UI research and plugin proposal r1 with user rulings' (#60) from feature/generative-ui-research into main 2026-10-11 03:10:49 +00:00
weichen 4ca58c3d8a Add the team-storage runbook for U1 and cross-link usage
Why: the approved collaboration plan U1 requires a fixed deployment manifest, tier config contract, migration mapping, capacity contract, isolation test scheme and KTD14 copy-protection contract as the single source of truth for team-tier operations.

Evidence: contract keys match backend config.go tier/pool fields (U2, backend branch feature/collab-storage-pg-tier); local verification used svc.sh collabtest on 127.0.0.1:8897 and Redis on 6399.

Impact: docs only (new guide + usage.md cross-links); no code change.

Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md sections 5 (U1/U2), KTD1/KTD8/KTD12/KTD14.
2026-10-11 03:10:45 +00:00
weichen 95a7c111d5 Add the Generative UI research and plugin proposal r1 with user rulings
Why: The user ruled on 2026-10-11 the three open product choices (first
pilot = full analysis page inside the conversation; enable/disable via a
trusted compiled plugin; U1 trial on MiniMax M3 + M2.7-highspeed with
sanitized materials and a CNY 200 cap), so the proposal now publishes as
the direction's master record instead of a local draft.

Evidence: Doc self-check receipts live in the Dev task card
feature/generative-ui-research; the rulings are recorded in the doc's
"用户裁定记录" section and mirrored in INDEX.md.

Impact: Documents-only change (new proposal + index entry). No runtime,
contract, or code changes; U1 trial start and deployment stay separately
reviewed.

Refs: Dev task feature/generative-ui-research
2026-10-11 03:10:16 +00:00
weichen 95e5c9d307 Merge pull request 'Add the approved collaboration storage and distribution plan r1' (#59) from feature/collaboration-storage-plan into main 2026-10-11 02:41:05 +00:00
weichen 228cf74468 Merge authoritative main into the task branch 2026-10-11 02:40:54 +00:00
weichen 0f5df5147e Add the approved collaboration storage and distribution plan r1
Why: freeze the direction for 10-100 user multi-project collaboration storage (PostgreSQL team tier, migration, staged multi-instance) before U1+U2 implementation starts.

Evidence: static review record and SELF audit receipt included; user approval recorded in Dev task card 2026-10-11 (instruction to start the transformation per the plan).

Impact: docs only - new proposal, index entry, review record, audit receipt; no code or runtime change.

Refs: Dev .task/feature-collaboration-storage-plan.md; plan section 5 names U1+U2 as the first increment.
2026-10-11 02:40:02 +00:00
weichen b3ca409cfc Merge pull request 'Backfill the S0-1 completion in the plan and index' (#58) from feature/s0-progress into main 2026-10-11 02:29:57 +00:00
weichen 4a3ca0eb5a Backfill the S0-1 completion in the plan and index 2026-10-11 02:29:16 +00:00
weichen 9a46785ee0 Merge pull request 'Backfill the E4 completion in the plan and index' (#57) from feature/e4-progress into main 2026-10-11 01:34:48 +00:00
weichen cc54cdac76 Backfill the E4 completion in the plan and index 2026-10-11 01:34:07 +00:00
weichen b37f45ff61 Merge pull request 'Backfill the E5 MiniMax-family A/B result' (#56) from feature/e5-progress into main 2026-10-10 17:28:06 +00:00
weichen 077ebdf184 Backfill the E5 MiniMax-family A/B result in the plan and index 2026-10-10 17:27:25 +00:00
weichen e986a85436 Merge pull request 'Backfill the E3 completion in the plan and index' (#55) from feature/e3-progress into main 2026-10-10 16:39:56 +00:00
weichen 19b77a28bc Backfill the E3 completion in the plan and index 2026-10-10 16:39:02 +00:00
weichen 3a82eec74c Merge pull request 'Backfill the E1 increment completion in the plan and index' (#54) from feature/e1-progress into main 2026-10-10 10:03:49 +00:00
weichen 352b7aa540 Backfill the E1 completion status in the index row too 2026-10-10 09:47:50 +00:00
weichen a379a9fbe6 Backfill the E1 increment completion in the plan and index
Why: The E1 quick-fix increment landed (delegate full text, MiniMax
reasoning split, sandbox deps layer, parallel tool execution with kernel
ordering) and the proposal is the master record, so its stage table and
the index row must reflect the actual progress with links.

Evidence: Agent-Native #42/#43/#44, Backend #127, Dev task
feature/agent-e1-parallel-fixes (live verification receipts: F2 zero
think-leak, F3 sandbox IMPORTS-OK, F5 concurrent overlap; eval
toolFailures 19->11, unverifiedFacts 7->12 recorded honestly).

Impact: Documents-only progress backfill; E2-E5/S0 remain unauthorized.
2026-10-10 09:47:25 +00:00
weichen 0f6d6974ef Merge pull request 'Propose the delegation, model-routing and task-sandbox plan' (#53) from feature/agent-exec-routing-sandbox-plan into main 2026-10-10 07:40:41 +00:00
18 changed files with 2688 additions and 7 deletions
+198
View File
@@ -0,0 +1,198 @@
# 团队存储运行手册(协作存储 U1)
适用范围:[协作存储与分布式方案](../proposals/2026-10-11-collaboration-storage-and-distribution.md) U1/U2
(已批准,2026-10-11)落地后的 **team 部署档** 运维与验证。个人 `local` 档(SQLite)
用法不变,见 [usage](usage.md)。本文是 U1 的固定部署清单、配置合同、迁移映射、
容量合同、隔离测试方案与 KTD14 副本保护合同的单一事实源;实施状态以各任务卡为准。
## 1. 目标实例与固定部署清单
| 项 | 值 | 说明 |
|---|---|---|
| 部署形态 | svc.sh 管理的 `runtime/<name>` 实例 | 非容器;单机多实例按名隔离 |
| 当前团队候选 | `runtime/dev`(8788,SQLite)→ 目标切 team 档 PG | 切换窗口与回退按方案 §6,须另行授权 |
| 数据库(本机验证) | PostgreSQL 18.6 + pgvector 0.8.7(brew) | 本机验证用;正式实例待指定 |
| 数据库(CI 门禁) | Ubuntu 24.04 apt:postgresql 16 + postgresql-16-pgvector | 版本以 CI job 输出为准 |
| 缓存/限流 | Redis 8.10.2(本机);CI apt redis-server | 只存可重建状态(KTD10) |
| 应用制品 | `agent-system` 单二进制(make build) | 拷贝即运行;team 档需 `--tier team` |
未知项(正式实例主机、pgvector 正式启用版本、对象存储选型)在正式切换授权前
必须补齐;本清单不把本机验证环境当作正式部署事实。
## 2. team 档配置合同(U2 已实施)
启动语义(KTD1 fail-closed):
- `tier=team`:必须配置 `dsn` 且认证开启(`auth=on`;`auth=auto` 随 DSN 自动开);
任一缺失**拒绝启动**。PG 打开失败**拒绝就绪**,绝不回落 SQLite。未配置执行隔离
(`disableExecTools` 或 `execBackend`)时启动警告(多用户开放前必须补齐)。
- `tier=local`:SQLite;配置 `dsn` 是配置错误,拒绝启动。
- `tier` 缺省(auto):现状语义——`dsn` 非空走 PG,否则 SQLite。
配置键(四源合并:默认 → 文件 → 环境 → 显式 CLI,与 usage §启动一致):
| 键 | env | CLI | 语义(team 档) |
|---|---|---|---|
| `tier` | `AGENT_SYSTEM_TIER` | `--tier` | `local` / `team` / 空=auto |
| `dsn` | `AGENT_SYSTEM_DSN` | `--dsn` | PG 连接串;team 必填 |
| `auth` | `AGENT_SYSTEM_AUTH` | `--auth` | team 档要求最终为 on |
| `instance` | `AGENT_SYSTEM_INSTANCE` | `--instance` | 空=主机名:监听地址(多实例必须互异) |
| `pgMaxOpen` | `AGENT_SYSTEM_PG_MAX_OPEN` | `--pg-max-open` | 每进程最大连接(默认 16) |
| `pgMaxIdle` | `AGENT_SYSTEM_PG_MAX_IDLE` | `--pg-max-idle` | 每进程空闲连接(默认 8) |
| `pgConnMaxIdleSec` | `AGENT_SYSTEM_PG_CONN_MAX_IDLE_SEC` | `--pg-conn-max-idle-sec` | 空闲回收(默认 300s) |
| `pgConnMaxLifetimeSec` | `AGENT_SYSTEM_PG_CONN_MAX_LIFETIME_SEC` | `--pg-conn-max-lifetime-sec` | 连接寿命(默认不限) |
| `pgQueryTimeoutSec` | `AGENT_SYSTEM_PG_QUERY_TIMEOUT_SEC` | `--pg-query-timeout-sec` | statement_timeout 秒(默认不限) |
连接预算(KTD12):预算覆盖全部 API/Worker/LISTEN/migrator/监控连接;
100 在线用户 ≠ 100 连接。`agent-system config explain` 输出脱敏有效值
(DSN 密码打码)。启动日志打印 `storage tier: team (dialect=postgres pool=… schema=v…)`。
迁移(KTD8,U2 已实施):DDL 与版本登记同事务(中途失败整体回滚,不存在
「表已建、账本未记」中间态);PG 并发迁移者按会话咨询锁串行化;SQLite 写事务
`_txlock=immediate` 跨进程排队。库内出现比二进制新的 schema 版本时拒绝启动。
## 3. 迁移映射(SQLite → PG,U4 工具消费)
| SQLite 侧 | PG 侧 | 备注 |
|---|---|---|
| `agent-system.db`(WAL) | 同名逻辑库 | 活跃 WAL 不能只拷 `.db`;一致性备份用 VACUUM INTO |
| INTEGER 0/1 布尔列 | BOOLEAN | v9/v10/v11 起双方言已分型 |
| `INTEGER PRIMARY KEY AUTOINCREMENT` | `BIGSERIAL`/`SERIAL` | events、command_audit、audit_events |
| FTS5 虚表 + 触发器 | tsvector 生成列 + pg_trgm GIN | v4;中文子串走 trigram |
| `vec BLOB` | `BYTEA` | pgvector 类型切换在 U6,不在本映射 |
| `<data>/artifacts/` 工件对象 | 本期仍本地目录 + PG 清单 | 共享对象存储在 U5/U9 |
RDM 独立业务库与旧 Agent-System 治理库**不在**本映射内;迁移工具(U4)只处理
Backend 库,非空目标拒绝、同快照才可续传。
## 4. 容量合同(验收目标,非性能结论)
方案 §3 的量化指标(100 在线 / 300 SSE / 20 执行中 Agent / P95≤300ms 等)是
**待验证合同**。区分两个计数:**接纳的 run 数**(进入队列)与**执行许可**
(同时真正执行,含子代理、初始全局 20、每用户 2、索引 4);等待子代理/HITL 的
父 run 让出执行许可、保留会话所有权。压测在 U7 执行并绑定组件 SHA 出证。
## 5. 隔离测试库/目录/端口方案
| 资源 | 约定 | 生命周期 |
|---|---|---|
| 本机 PG 实例 | `scripts/svc.sh db create collabtest --port 8897 --tag test` | svc.sh 管理;用毕 `svc.sh collabtest stop` + `rm --purge` |
| 测试库/扩展 | 库 `agent_test`;`pg_trgm` 预装 public | 测试辅助幂等预装;CI 启动步显式预装 |
| 用例 schema | `t_*` / `pgbus_*` 前缀,随机名 | 每用例建、Cleanup 级联删 |
| 本机 Redis | `redis-server --port 6399 --save '' --appendonly no` | 纯内存、用毕即停 |
| CI | job `test-pg`:apt 安装 PG16+pgvector+Redis,端口 5432/6399 | 每次 PR 必跑;缺服务失败不跳过 |
本地跑真实库门禁:
```bash
export AGENT_PG_TEST_DSN="$(scripts/svc.sh db dsn collabtest --db agent_test --reveal | tail -1)"
export AGENT_REDIS_TEST_ADDR=127.0.0.1:6399
make test-backend-pg
```
禁止对共享/现役实例(如 `runtime/dev` 的库)跑测试;DSN 不入命令历史与任务卡。
## 6. KTD14 副本保护与保留合同
- 备份/导出/WAL/测试副本使用专用数据库角色(非应用角色),存放于受限目录
(0700,非工作区);传输与静态备份加密,解密材料存独立受管秘密存储。
- 保留期限:迁移演练副本用毕即删,最长 7 天;正式备份保留 30 天滚动 +
每月 1 份年度副本(待正式实例指定后确认)。
- 日志/报告只留统计与哈希:不落 DSN、密钥、文档正文;测试一律用脱敏数据。
- 恢复演练:每次演练恢复到新目标并核对应用可用与权限/文件完整性;
「备份命令成功」不等于可恢复。
- 阻塞项:正式导出前,未知 owner 的数据、未定位的权威文件、缺失的保留期限
任一存在即阻塞(不静默继续)。
## 7. 暂态 Worker 文件分类
| 类 | 内容 | 处置 |
|---|---|---|
| 可重建 | 构建产物 `bin/`、`node_modules/`、测试数据目录、`__pycache__` | 随时删除重建 |
| 必须迁移 | SQLite 库、`artifacts/` 工件、`.agentx/checkpoints.jsonl`、Squad FileStore/续跑标记 | U4 迁移 + 联合备份;U5 前禁止跨机接管 |
| 只读参考 | svc.env(600)、history.jsonl | 保留在实例目录,不入副本外流 |
## 8. 已知边界(诚实清单)
- CLI 子命令(apikey/user 等)不校验 tier;team 档语义只在 `serve` 入口强制。
- 迁移仍随启动执行(已原子 + 锁化);完全独立的 migrator 入口留待 U4 工具。
- 多实例安全**未**因此声明(R4/U5);本档只交付单实例 team 档与真库门禁。
- pgvector 扩展已安装 ≠ 启用;向量检索仍是应用内扫描(U6)。
## 9. 执行预算与动作授权(U3 切片 2 已实施)
### 执行许可(admission,R8)
- 设置键:`runtime.execBudgetGlobal`(全局并发执行上限,含子代理;0=不限,
默认)、`runtime.execBudgetPerUser`(每租户上限;0=不限)、
`runtime.execQueueMax`(待执行队列上限,默认 200)。数值为容量合同初值,
U7 压测后调整。
- 语义:会话回合与子代理同池计数;账本在数据库(`admission_leases`,PG 咨询
锁下原子清点),多实例天然共享;队列满时 API 在落库前 429(不写数据);
父 run 同步等待子代理或等待 HITL 时让出执行许可、保留会话所有权,恢复
执行重新获取——额度占尽时父子不互等。
- 接纳与执行分别计数:队列深度(接纳)与活跃租约(执行)是两个量,
诊断分别看 `Manager.QueueDepth()` 与 `store.ActiveExecutionSlots()`。
### KTD13 动作授权矩阵与公开契约兼容计划
矩阵(宿主侧 `server.ProjectAction`):
| 动作 | 语义 | 未注册 action-aware 时 |
|---|---|---|
| read | 读取项目资源(会话/消息/检索/下载) | 回落旧 EXT-8 只读适配器(兼容现网) |
| edit | 写入与修改 | **默认拒绝** |
| approve | 审批(HITL/命令确认) | **默认拒绝** |
| execute | 触发执行 | **默认拒绝** |
| admin | 管理 | **默认拒绝** |
规则:action-aware 适配器(组合根注入 `SetProjectActionAuthorizer`)注册后
对全部动作权威、出错 fail-closed;旧只读适配器不得自动获得写入能力。
**公开契约兼容计划**(后续版本落地):以版本化扩展把动作级判定并入
EXT-8 的 `ProjectAuthz` 公开契约(新增 action 参数的变体接口 + 契约版本号),
下游适配器按动作逐一声明能力;未声明动作保持默认拒绝,与宿主侧矩阵同语义。
旧 bool 契约在该版本内继续可用(映射为仅 read);Core/Host 与下游适配器
(RDM 的 ProjectAuthz 实现)一起验收,不另建成员权威。
## 10. SQLite → PostgreSQL 切换与恢复演练(U4 已实施)
工具:`make build` 产出 `bin/storage-migrate`(受管迁移入口;只处理 Backend 库,
不执行 SQLite dump 作为 PG SQL)。三个子命令:
```bash
# 1) 只读盘点:schema 版本、完整性、逐表计数、工件清单与哈希(§6.1)
storage-migrate inventory --source runtime/dev/data/agent-system.db \
--artifacts runtime/dev/data/artifacts --out inv.json
# 2) 一致性快照:VACUUM INTO(在线安全含 WAL)+ 可打开校验 + 逐表计数对账(§6.2)
storage-migrate backup --source runtime/dev/data/agent-system.db --out snap.db
# 3) 受管迁移:目标建 schema/扩展后按行复制;身份登记 + 逐表校验和 + 终验(§6.3)
storage-migrate migrate --source snap.db --target "$DSN" \
--migration-id <名> --artifacts runtime/dev/data/artifacts --out report.json
```
迁移身份与续传:`migration_id + source_snapshot_id(快照 SHA-256)+
source_schema_version` 登记在目标 `migration_control`;**仅同一冻结快照可续传**
(换快照/换身份均拒绝);目标业务表已有数据而身份为空即拒绝(不覆盖)。
校验与报告:逐表源/目标计数与主键序哈希链校验和(布尔列按目标 schema 对称
归一);复制后推进 SERIAL 序列;未知 owner(users 之外,''/'local' 单租户默认
除外)阻塞迁移;报告只含计数/校验和/清单哈希——无 DSN、密钥与行正文(KTD14)。
类型映射以目标 schema 为准(SQLite 0/1→BOOLEAN、BLOB→BYTEA、生成列不迁、
FTS5 影子表不迁——PG 侧生成列与索引自动重建);`admission_leases` 为运行态
不随迁。
### 切换顺序(正式窗口须另行授权;当前仅隔离演练已验证)
1. 固定源制品与路径,`inventory` 盘点;指定迁移 owner、窗口、回退判据。
2. `backup` 冻结快照(活跃 WAL 库不得只拷 `.db` 文件)。
3. 预演:独立测试目标 PG 上 `migrate`,核对报告全绿;预演库不作为正式目标。
4. 正式窗口:停新写 → 等待/收口在途 run(未知副作用记 recovery hold)→
停旧写者 → 终快照 → 空正式目标 `migrate` → 报告全绿。
5. 单入口切 team 档冒烟(登录/项目/会话/审批/检索/下载);fail-closed 不回 SQLite。
6. **PG 接受新写入前**可撤回;**之后**禁直切回旧 SQLite(向前修复或专项回迁)。
备份基线(正式目标启用后):pg_dump 逻辑备份 + pg_basebackup 物理基础备份与
WAL 归档/PITR;pg_dump 不能作 WAL 回放基础。每次演练恢复到新目标并核对。
+2 -1
View File
@@ -36,7 +36,7 @@ agent-system config explain [--config envs/prod.json] # 只读诊断:逐字
agent-system version
```
启动参数四源合并,优先级从低到高:**内置默认 → 配置文件(`--config`,显式 JSON,无自动发现)→ 环境变量(`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`)→ 命令行**;未显式传入的命令行参数不参与覆盖,删除 override 恢复继承。字段:`addr`(监听)、`data`(工作区根目录)、`plugins`、`dsn`(空 = 嵌入式 SQLite 档,非空 = PostgreSQL 档)、`artifacts`、`auth`(auto/on/off)、`mock`;未知键与类型错误在启动时定位报错,不静默失效。
启动参数四源合并,优先级从低到高:**内置默认 → 配置文件(`--config`,显式 JSON,无自动发现)→ 环境变量(`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`)→ 命令行**;未显式传入的命令行参数不参与覆盖,删除 override 恢复继承。字段:`addr`(监听)、`data`(工作区根目录)、`plugins`、`dsn`(空 = 嵌入式 SQLite 档,非空 = PostgreSQL 档)、`artifacts`、`auth`(auto/on/off)、`mock`;未知键与类型错误在启动时定位报错,不静默失效。team 部署档(`tier`/连接预算键)与真实数据库门禁见[团队存储运行手册](team-storage.md)。
**多环境启动**——仓库自带隔离示例 `envs/{dev,test,prod}.json`(data 根与 DB 互不重叠):
@@ -44,6 +44,7 @@ agent-system version
agent-system serve --config envs/dev.json # mock 开、./data-dev
agent-system serve --config envs/test.json # 127.0.0.1:8788、./data-test
agent-system serve --config envs/prod.json # PostgreSQL 档、auth on、独立卷
agent-system serve --tier team --dsn "$DSN" --auth on # team 档:缺 DSN/未认证拒绝启动,PG 故障拒绝就绪(见团队存储手册)
AGENT_SYSTEM_CONFIG=/etc/agent-system.json agent-system serve # 环境变量定位文件
```
@@ -9,6 +9,8 @@
---
> 2026-10-11 补齐候选:[最终目标核对与完整交付方案](2026-10-11-rdm-final-target-completion.md)按本轮用户确认及 RDM d8d7e743 重新映射项目/隐私/三权、全部模板与 34 UR/68 SR/10 F。该方案待评审;本页历史快照和原始证据保留,不能据其旧完成声明推断最终验收。
## 1. 大方向与大目标
### 1.1 一句话目标
@@ -190,12 +190,12 @@ sha256/mtime 清单复核,不可当作完整快照。
| 增量 | 内容 | 依赖 | 备注 |
|---|---|---|---|
| E1(P0 快修) | F1 委派回传、F2 reasoning_split、F5 并行工具、F3 依赖层 | 无 | 每项独立小 PR;行为面改动按裁定 6 附 eval/live 前后对照 |
| E1(P0 快修)✅ | F1 委派回传、F2 reasoning_split、F5 并行工具、F3 依赖层 | 无 | **已完成(2026-10-10)**:Agent-Native #42/#43/#44 + Backend #127 + Dev PR(任务卡 feature/agent-e1-parallel-fixes)。验证:F2 实测正文 0 泄漏、F3 sandbox 实测 IMPORTS-OK、F5 实测同回合并发重叠;eval 对照工具失败 19→11,未核实数字 7→12(E3 待做,见任务卡) |
| E2 | R1 Claude 原生协议 + 缓存观测 | E1(F2 同类协议改动可同批) | dmxapi 需充值 |
| E3 | D4 证据账本 + 数字闸门 | 无(接质量计划 P5) | 与 P5 事实一致性检查合流 |
| E4 | R2 角色路由 + D5 画像 | E2 | 设置与画像面 |
| E5 | R3+R4 路由 A/B 与升级规则 | E2–E4 | 出选型报告 |
| S0(仅记录) | §4 工作区沙箱设计定稿为独立实施任务 | 用户批准启动 | 本文即主记录 |
| E3 ✅ | D4 证据账本 + 数字闸门 | 无(接质量计划 P5) | **已完成(2026-10-10)**:Backend #130、Dev #311(任务卡 feature/agent-e3-evidence-gate)。标注感知豁免(分句判定)+ 两轮修正(变化才二拦)+ base.deliverables v6 数字溯源规则 + 子代理引用格式;eval 对照未核实数字 12→5(未标注 3)、工具调用 93→63 |
| E4 ✅(R4+账本) | R2 角色路由 + D5 画像 | E2 | **R4 与账本已完成(2026-10-11,MiniMax 版)**:Backend #131–#134、Dev #315(任务卡 feature/agent-e4-escalation-ledger)——滑窗失败提醒(端到端日志实证)、检索空命中提醒、source_id 账本(83 标记);Claude 角色档按模型指示暂缓;eval 四轮对照无恶化 |
| E5 ✅(R3 部分) | R3+R4 路由 A/B 与升级规则 | E2–E4 | **R3 已完成(2026-10-10,MiniMax 家族版)**:Dev #313(任务卡 feature/agent-e5-model-ab)三臂对照(hs / 全M3 / hs+M3轻量)——建议默认 chat=MiniMax-M3(未标注编造 1、失败最少、时长持平、单价减半);R4 升级规则仍待做 |
| S0-1 ✅ | §4.4 首个落地形态:冻结基底 overlay + CAS 回收 + 变更摘要(--exec-workspace overlay) | 用户 2026-10-11「继续完成下一步」 | **已完成(2026-10-11)**:Backend #135/#136、Dev #318(任务卡 feature/agent-s0-workspace-overlay)——bwrap 集成 3 + live 端到端(失败零落地/新增/修改/-ws 清理);S0-2(fs 联合读/任务级工作区/封存)待授权 |
## 6. 与既有规划的关系
@@ -0,0 +1,532 @@
---
title: Generative UI research and plugin proposal
date: 2026-10-10
type: feat
revision: r2
product_contract_source: user-request-and-current-source
---
# Generative UI 调研与插件方案
确认状态:**三项关键取舍已由用户裁定(2026-10-11,见文末"用户裁定记录")**;全文随发布 PR 评审。推进状态:方案成稿并进入发布评审;原型、业务实现、运行验收、部署均为 **NOT_RUN**。
来源:2026-10-10 用户请求——先调研参考与仓库,再判断能否加入本系统,给出可随时启禁的插件方案。
负责人:裁定与验收 weichen(用户);方案整理与执行 Agent;更新时间:2026-10-11。
本文是唯一主记录;任务卡引用本文。文内路径除相对链接外,均相对 Agent-System-Dev 根目录。
用户授权本轮调研、思考和完整方案准备,不表示已批准本文的产品取舍、原型试验或后续实施。
## 结论与目标
**可以加入,而且当前系统已有合适基础。推荐新增独立的 Generative UI 插件,配合小范围、通用的宿主能力扩展。**
Agent 负责决定何时需要页面、采用哪些组件、怎样排列内容与交互;宿主负责设计系统、身份权限、事实读取、渲染、动作执行和恢复。
页面结构可以每次不同,组件实现与权限规则保持确定。
首选路线:复用现有 Agent-Native、Go Backend、Core UINode 和 React UI;以版本化 Surface 表达可保存、可更新的动态页面。
借鉴 A2UI 的组件目录与数据/交互协议,以及 json-render 的 catalog/registry 分工;首期不要求替换现有运行时或另起 Node 服务。
外部 renderer 是否比扩展现有 UIRenderer 更划算,由受控试验决定,当前没有实际集成证据。
建议先覆盖对话产出的完整阅读/分析页面,再加入交互表单与任务工作页,最后扩展到项目工作区。
登录、项目切换、停止执行、设置和审批保留可预测的宿主入口;业务主内容可以动态组织。
该演进顺序已于 2026-10-11 获用户确认:首试点为对话中的完整分析页(场景 1);它不把长期目标缩减为“几个固定卡片模板”。
插件首期采用**可信 Go 编译扩展 + 声明资产**(该交付方式已于 2026-10-11 获用户确认):功能开关实时生效,安装/升级插件代码需要重新构建组合二进制并重启。
“功能随时启禁”与“无需重启安装任意插件包”是不同能力;用户未把后者列为本期硬要求,sidecar 路线保留为备选并随实际需求重评。
---
## 外部调研
调研日期:2026-10-10。引用来自官方文档或官方源码,说明的是当场文档/仓库状态;本轮未安装或运行这些项目。
不以 star 数量、演示视频或作者自述推断生产可靠性;正式选依赖时仍须固定版本、审许可证与传递依赖并进行组合验证。
### Generative UI 的不同层次
| 类型 | Agent 实际决定什么 | 与本目标的关系 |
|---|---|---|
| 固定工具结果组件 | 调用什么工具、向预制组件传什么参数 | 适合起点,但单独使用不足以实现自由组织页面 |
| 声明式生成页面 | 组件树、布局、内容重点、数据绑定与动作引用 | 本方案主路线;页面可变,执行边界明确 |
| 可持续交互的生成工作区 | 页面随用户输入、任务进展和数据版本变化 | 本系统中期目标;需要状态、版本、权限与回放协议 |
| 生成 HTML/JS/React 小应用 | 连组件实现和程序逻辑一起生成 | 表达力高;需独立沙箱、资源与网络边界,后续单独评估 |
运行时按任务生成页面,与开发期间让 Agent 写前端代码不同。后者交付后仍可能是固定页面。
AG-UI 这类事件协议、A2UI 这类 UI 描述协议、MCP Apps 这类嵌入式应用契约解决的层面也不同,不能互相替代。
### 核心参考与采用判断
| 参考/官方仓库 | 能力定位 | 本系统采用判断 |
|---|---|---|
| [A2UI](https://github.com/a2ui-project/a2ui) / [文档](https://a2ui.org/) | 声明式组件、Surface、数据绑定和用户动作;组件目录可映射自己的设计系统 | 最值得借鉴的协议。Go 可产生 JSON,前端可保持自身 UI。是否严格实现某版本,留给独立适配器与一致性测试 |
| [json-render](https://github.com/vercel-labs/json-render) / [Catalog](https://json-render.dev/docs/catalog) | 为 AI 定义组件与动作词汇,由 registry 绑定真实 React 等实现 | 最值得试验的 renderer 依赖;可将目录映射到 @ui。不能未经比较就再建一套状态和渲染系统 |
| [CopilotKit](https://github.com/CopilotKit/CopilotKit) / [AG-UI](https://github.com/ag-ui-protocol/ag-ui) | Agent 与应用之间的流式事件、状态与交互集成 | 参考工具 UI、共享状态和事件设计;现有系统已有 runtime/SSE/store,首期不整体替换。AG-UI 本身不定义完整页面布局 |
| [Vercel AI SDK](https://github.com/vercel/ai) / [Generative UI 指南](https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces) | 工具调用与结果驱动组件渲染,应用开发者实现组件 | 很好的最小入门与工具组件范例;不是整页自主规划的全部方案,不为此把 Go 后端迁到 TypeScript |
| [assistant-ui](https://github.com/assistant-ui/assistant-ui) / [生成 UI 文档](https://www.assistant-ui.com/docs/tools/generative-ui) | 除工具 UI 外,当前有 present 工具生成组件 JSON 树、动作注册与流式 props | 借鉴显式 present 入口;不必替换聊天壳。官方明确 renderer 不按 props schema 执行校验,仍需自己的运行时验证 |
| [Thesys OpenUI](https://github.com/thesysdev/openui) / [现行文档](https://www.openui.com/docs) | OpenUI Lang、parser、React 流式 renderer 与自定义组件;Crayon 旧仓已转向该仓 | 作为表达能力/流式体验备选。可用自己的模型;开源 runtime 与可选 OpenUI Cloud/Gateway(原 C1)分开评估,不把开源许可等同托管服务条款 |
| [Tambo](https://github.com/tambo-ai/tambo) | 注册 React 组件与 schema,Agent 选择组件并更新状态;包含后端编排 | 设计参考。官方已公告 Tambo Cloud 将于 2026-10-31 关闭 API,2026-11-30 删除托管数据;开源可自托管,但不建议作为新系统的默认托管依赖 |
| [MCP Apps](https://github.com/modelcontextprotocol/ext-apps) | 工具返回交互式 UI resource,宿主通过桥接在隔离容器内嵌应用 | 适合未来插件小应用与外部工具 UI 互通;它不自动生成页面,也不代表现有 Agent-Native MCP 工具支持已具备 Apps 宿主能力 |
A2UI 官方主页当前列出 v0.9.1 为 current、v1.0 为 candidate;它的 [catalog 指南](https://a2ui.org/concepts/catalogs/) 建议成熟应用围绕现有设计系统定义目录。
已有[官方 React renderer](https://a2ui.org/reference/renderers/);这证明有实现可供验证,不证明该版本已经在本系统构建/运行通过。
不能混合旧 v0.8 的消息字段和新版本字段后声称协议兼容。
json-render 的 [registry 文档](https://json-render.dev/docs/registry) 将组件实现与动作处理留在应用侧,适合本系统“生成数据、宿主执行”的边界。
Tambo 的停服状态以[官方仓库公告](https://github.com/tambo-ai/tambo#readme)为依据,旧教程中的 Cloud 快速接入方案已不适合作为新项目默认选型。
许可初筛:A2UI、json-render、AI SDK 为 Apache-2.0;CopilotKit、AG-UI、Tambo、assistant-ui、OpenUI 的当前仓库为 MIT,具体包及附带资产在锁版本时再核对。
[MCP Apps LICENSE](https://github.com/modelcontextprotocol/ext-apps/blob/main/LICENSE) 处于 MIT 向 Apache-2.0 迁移,部分旧贡献保留 MIT,文档另有 CC-BY-4.0,不能统一简写为“任选双许可”。
当场仓库活动检查未发现上述候选被归档;活动不等于稳定或维护承诺,Tambo Cloud 公告说明需要把代码可用与运营持续性分开判断。
AI SDK 的 [RSC 路径仍为实验状态](https://ai-sdk.dev/docs/ai-sdk-rsc/overview),首期没有理由为此将现有 Vite 应用迁到 Next.js/RSC。
### 三条可行路线
| 路线 | 优点 | 主要代价 | 结论 |
|---|---|---|---|
| A. 原生 UINode/Surface 插件 | 复用权限、Agent、事件流、设计系统与部署形态;无强制新服务 | 要补齐 schema 校验、版本、交互和启禁 | **首选** |
| B. json-render/A2UI renderer 嵌入插件 | 利用现成组件目录、绑定和流式能力 | React 集成之外还需 Go 校验、动作授权、版本与状态适配;可能重复 UIRenderer | 受控试验中的挑战方案;显著减少总维护成本才采用 |
| C. 隔离的代码生成小应用或整套平台 | 表达力最高,适合复杂专用工具 | 沙箱、网络、会话桥、制品供应链、依赖升级和审计面明显增加 | 后续独立方向,不作为首个增量 |
路线 A 不是从零重造外部框架:首期范围只包含本系统用得到的有限词汇、快照、授权动作和页面容器。
若需求发展为大量复杂表单、表达式和跨平台 renderer,重新比较 B;不要不断扩展内部 DSL 以维持最初选型。
---
## 当前系统的可行性依据
以下为 **SELF·源码级观察**,不是运行能力验收。审计基线为 Dev `104a4142c918f7325d3a78e3e6e270e46739baea`。
| 组件 | 固定 SHA |
|---|---|
| Core | `a253a40b8e5563119b00c4e71fb61fe0d11d6d6a` |
| Backend | `017b40f76156905eabe8323ae2bfe800f47fb8bd` |
| Frontend | `339a9ebc2d827eaf990346b91d36f4ad5a13f090` |
| UI | `76d6633736a7abb36ac1ecca42fe4e6f120d0558` |
| Agent-Native | `c348441691e8bdab784a03aa9be64d53dacff341` |
| Documents | `3a82eec74ce6b2b548a7a943f8382d64df14316e` |
| 当前源码事实 | 依据(上述固定版本) | 设计影响 |
|---|---|---|
| React 19、Vite 6;Core 已有 16 种有限 UI 词汇 | `modules/frontend/package.json`;`modules/core/ui.go:9-50` | 不必另换技术栈或设计系统 |
| UIRenderer 能画 table、compare、tabs、timeline 等 | `modules/ui/src/UIRenderer.tsx:22-35` 及各 case | 动态选择和组合已有组件有基础 |
| submit_card 的 body 仍是字符串,包装成 Markdown | `modules/backend/internal/runtime/hostbridge.go:128-148` | 当前 Agent 还不能通过这个工具输出任意结构化页面 |
| form 没有提交回传,节点按数组 index 作为 key;table 行 action 未渲染 | `modules/ui/src/UIRenderer.tsx:22-29,73-95,184-200` | 有类型不等于完整交互;稳定 nodeId、草稿与动作桥必须补 |
| 卡片 body 渲染未传 onAction | `modules/ui/src/ActivityCardView.tsx:66-74` | 不能只把按钮塞进 body 就声称接通动作 |
| cardsvc 有保存与事件发布;运行管理有卡片端口 | `modules/backend/internal/cardsvc/cardsvc.go:73-139`;`internal/runmgr/runmgr.go:637-715` | 复用其分层与持久化后发布原则,避免第二条无审计通道 |
| 上下文回灌仅取卡片顶层 markdown/kv | `modules/backend/internal/ctxasm/ctxasm.go:373-411` | 需要递归语义投影;否则下一轮 Agent 不知道页面里有哪些内容 |
| SSE 服务端先订阅再重放并按 seq 过滤;前端没有完整拒旧/切会话保护 | `modules/backend/internal/server/server.go:375-429`;`modules/frontend/src/api.ts:189-194`、`store.ts:375-414` | Surface 投影须明确 seq、revision 与 generation 防卫 |
| enabled 写入 owner+plugin grants,主要被 ListFor 消费 | `modules/backend/internal/server/platform_api.go:130-142`;`internal/store/platform.go:13-32`;`internal/plugins/host_v2.go:160-175` | 现有“禁用”不能当作请求/执行禁用;新能力必须服务端闭环 |
| ESM loader 存在,但未找到实际页面挂载调用;桥未接主认证/命名事件处理 | `modules/frontend/src/pluginHost.ts:9-13`;`modules/ui/src/pluginSdk.ts:9-25` | 首期不能依赖现成 ESM 页面宿主;动态 import 也不是代码沙箱 |
| 公开扩展可注册命令 handler,命令可 exposeAsTool | `modules/backend/pkg/extension/extension.go:34-48`;`internal/cmdbus/cmdbus.go:47-64`;`internal/app/app.go:417-422` | 插件命令可供现有 Agent 调用,无须新增任意 native executor 插口 |
| 公开 Host 缺会话/任务完整上下文及 Surface 发布端口 | `modules/backend/pkg/extension/host.go:26-68` | 需申请最小公开契约,不能从插件导入 Backend internal |
现有 context assembler 可复用消息、附件、可见知识和用户偏好;不等于已经自动读取所有项目背景。
跨会话读取仍须满足现有开关、同项目/租户与隐私限制(`internal/runmgr/runmgr.go:934-1005`);生成页面不能扩大数据可见范围。
当前 `Host.Complete` 是简单 prompt→string,且主要走 owner 路由,不能当作已有 project 级结构化/流式生成接口。
本轮阅读了规划索引、基座路线图、插件 v2 与扩展兼容相关记录;没有发现既有 Generative UI 专项主记录。
2026-10-10 本轮查询 Dev/Documents/Core/Backend/Frontend/UI 的 open PR,结果均为空;这是当时快照,后续开工须重验。
规划索引中的 Agent 质量、模型路由、RDM 扩展仍有剩余范围,不因没有 open PR 就视为全部完成或不冲突。
---
## 需求与用户体验
### 需求表
所有实施需求当前为候选,待人工确认。符合度“需调整后符合”表示本方案指出了必需宿主改动,不表示已实现。
| ID | 需求与来源 | 符合度 / 优先级 | 可判定验收条件 | 处理与依赖 |
|---|---|---|---|---|
| R1 | 根据内容、上下文、任务、项目背景自主组织页面(用户) | 需调整后符合 / P0 | 同一组事实分别完成“比较、风险分析、进度查看”,生成不同且合适的结构;不是同模板换标题 | 纳入试点;U1/U3/U4 |
| R2 | 以插件封装,随时启禁(用户) | 需调整后符合 / P0 | 禁用后 UI、直接 API、旧按钮、在途发布均受控;原有系统仍可用;重启后保持禁用 | 纳入首期;U2/U3/U4 |
| R3 | 页面可追溯事实与来源(本系统约束) | 符合 / P0 | 数据值来自授权数据引用;分析结论标为生成判断;能定位材料与版本 | 纳入首期;U2/U3 |
| R4 | 使用本系统设计系统、易用且可访问(DESIGN) | 符合 / P0 | 令牌/动效/折叠守护通过;键盘与窄屏可完成主要流程;唯一预览落位 | 纳入首期;U4 |
| R5 | 页面可保存、刷新恢复、版本可解释(长期工作流) | 需调整后符合 / P0 | 刷新恢复已保存视图;同版本可确定渲染;断线、旧帧与切项目不串页 | 纳入首期;U2/U4 |
| R6 | 用户继续修改页面,Agent 理解当前结构(用户目标的闭环) | 需调整后符合 / P0 | “改为对比、突出风险”生成新 revision;上下文包含结构、来源与已确认用户输入 | 纳入首期;U3/U4 |
| R7 | 动态表单和动作,沿用权限与审批(扩展交互) | 需调整后符合 / P1 | 表单可提交、校验、重试;旧 revision/越权/重复动作受控;必要审批不能由模型伪造 | 后续增量;U5 |
| R8 | 任务/项目工作区随阶段组织(用户长期目标) | 需调整后符合 / P1 | 当前任务可组织计划/产物/待决策信息;项目聚合符合跨会话读取权限;固定布局可恢复 | 后续增量;U6 |
| R9 | 外部协议可演进,禁用不丢历史(可维护性) | 符合 / P1 | 固定 schema/catalog/插件版本;不兼容时静态/文本降级;旧动作不自动重放 | U2/U7 |
| R10 | 有真实收益与成本证据(交付规范) | 符合 / P0 | 对照固定 UI 的任务成功率、耗时、事实错误、延迟和 token 成本;真实模型结果可复核 | U1/U7;当前 NOT_RUN |
### 三个试点场景
1. **调研和文档分析页**:比较多个方案时,Agent 组织“结论→对比表→证据→风险”;用户改问实施顺序后,调整为阶段与依赖。数据与判断分开,来源能打开原工件。
2. **当前任务工作页**:需求阶段突出待澄清项,执行阶段突出步骤和产物,验收阶段突出验证结果与缺项。完成状态取自真实任务记录,模型不能画一个绿色标记就更改任务状态。
3. **方案选择和需求表单**:Agent 根据缺失信息组织输入项;用户填写后形成明确的结构化输入,再触发下一轮。表单提交不自动批准其后所有业务操作。
首个完整增量以场景 1 为主;保留场景 2/3 的契约扩展空间,但不要求同时交付所有交互。
普通文本回答仍是有效结果;没有可视化价值时 Agent 应保持文本,不强行生成页面。
### 页面落位与自主程度
对话中的卡片是生成页面的入口与简短摘要,完整页面进入现有预览位置的 Surface 模式;全屏是同一实例的放大。
预览区关闭时,用户仍能从对话入口打开或在对话中继续操作,遵守 DESIGN 的“右栏收起零功能缺失”。
之后的项目工作区只是同一 Surface 的另一种打开入口,不复制另一套事实与状态。
可以保留多份页面,活动预览只有一个;新结果不抢占用户当前打开的其他对象。同一 Surface 的入口聚合到同一实例,用户从对话引用选择历史页面。
建议提供三档产品行为:关闭;按需生成;自动建议/生成。
首期默认关闭,启用后按需触发;用户明确请求页面时直接生成,Agent 在复杂比较/时间线等任务中可自主选择组件与结构。
自动触发只监听明确任务阶段/材料完成等语义事件,后续增量再开启;不按每个 token 或每条 SSE 事件重排页面。
用户可以固定布局、切回原视图、重新组织;“固定布局”冻结结构,授权范围内的数据仍可更新,需显示数据时间。
用户正在输入、选择或执行动作时,结构更新暂存并提示应用,不挪动焦点或覆盖草稿。
---
## 架构与关键决策
### KTD1. 插件策略与宿主执行分离
插件拥有组件使用策略、生成提示、布局选择、schema 修复策略、试点场景与质量评估。
宿主拥有授权上下文、持久化、稳定渲染容器、请求鉴权、事件序列、动作执行和插件启禁。
通用组件实现归 UI;契约归 Core;前端投影与导航归 Frontend;Backend 实现受限公开接口。
新目录/仓库位置建议为独立 Generative UI 组件仓,在 Dev 固定组合中引用;正式建仓和最终名称待实施前确认。
```mermaid
flowchart TB
A[用户任务与展示偏好] --> B[既有 Agent Runtime]
C[宿主授权上下文与组件能力] --> B
P[Generative UI 插件策略与命令] --> B
B --> D[插件 present 命令:声明式页面]
D --> E[宿主校验与 Surface 服务]
E --> F[保存快照与事件]
F --> G[Frontend 唯一状态投影]
G --> H[SurfaceHost 与 UI Renderer]
H --> I[用户交互]
I --> J[宿主动作校验与命令总线]
J --> B
K[插件启禁与资源权限] --> C
K --> E
K --> J
```
### KTD2. 复用现有 Agent,不增加独立 UI 模型调用
首选由当前工作 Agent 根据插件提供的能力目录,通过公开命令的 `exposeAsTool` 生成并提交页面规格。
插件命令可概念性分为“读取可用展示能力/上下文”“提交或替换页面”“恢复原视图”;准确命名在接口评审中确定。
页面规格由主 Agent 作为工具参数产生;插件负责校验与发布编排,无需默认再调用一次 `Host.Complete`。
工具返回已接受的 Surface/revision 与语义摘要,或者带字段路径的有限校验错误;后者允许原 Agent 至多重提一次。这会增加原回合的模型轮次,必须计入成本,不能宣称零额外 token。
因此插件可以自主组织页面,而不接管主 Agent 的对话循环、模型凭据或任务执行权。
后续只有真实评测显示收益,才加入专用 UI planner 或轻量模型修复;届时单独定义 project 级模型路由、预算与取消接口。
### KTD3. Surface 是有版本的呈现产物
方向性数据模型(不是已实现接口):
| 层 | 必需内容 | 权威来源 |
|---|---|---|
| 身份信封 | surfaceId、owner、projectId、conversationId、sourceRunId、pluginId | 服务端分配/从当前请求绑定;模型不能自报 owner |
| 兼容标识 | schemaVersion、catalogVersion、pluginVersion、rendererCompatibility | 已安装组件与宿主协商 |
| 版本 | revision、baseRevision、contextVersion、activationEpoch | 服务端事务与当前授权状态 |
| 页面 | title、稳定 nodeId、受限 layout、UINode 内容及结构 | 模型提议,服务端验证 |
| 数据 | resourceRef、源版本、字段白名单、读取时间 | 宿主解析后的授权数据 |
| 交互 | 服务端保存的 action binding、参数 schema、执行级别 | 命令目录与当前授权;模型仅引用允许动作 |
| 回放 | semanticText/结构摘要、来源、生成用途、静态降级文本 | 服务端递归投影为主,不能只信模型自述 |
首期采用完整、经过校验的快照原子替换,不渲染半截 JSON,不把流式 token 当作结构更新。
revision 单调递增,更新必须带 baseRevision;版本冲突拒绝并返回当前版本,不自动覆盖他人更新。
发布以当前身份、插件、sourceRunId、toolCallId/发布请求 ID 建幂等键,重复工具结果返回已保存 revision,不能生成重复页面;相同键但不同规格拒绝。
复杂的流式 patch、表达式求值和跨页面组件引用均后置;若后续引入 patch,必须保留同样的原子性与版本检查。
现有卡片保存 Surface 引用与文本摘要,不把一份可交互页面同时复制进卡片 body、工件和工作区三处。
持久化建议增加宿主通用 Surface 及 revision 记录,支持现有 SQLite/PG 档位;按 owner/project/conversation 建权限索引。
页面快照、最小 action binding 与待发事件在同一事务落盘,再由宿主事件管道发布;发布失败靠持久事件或重建快照恢复,不能只依赖内存总线。
业务实体仍由原业务服务维护,Surface 不成为项目/任务事实的第二份数据库。
新表采用增量迁移,默认关闭功能时不影响老路径;回退应用不删除表和用户产物。保留周期沿用所属会话/工件策略,最终清理策略随数据契约评审,不在开关中隐式删除。
### KTD4. 上下文是授权后的事实快照
宿主根据当前身份和请求,提供任务目的、当前会话摘要、项目允许读取的背景、指定工件、相关检索结果、用户展示偏好与允许动作目录。
浏览器只提供关注对象 ID 和偏好,不能提交可信权限声明或任意数据库查询。
先按权限过滤再裁剪;只按当前任务相关度取必要字段;不直接将整个项目、原始系统提示或敏感凭据塞入模型。
材料与工具结果作为不可信数据处理,不能覆盖组件目录、开关或动作权限;页面内容里的指令不能自行触发后续动作。
上下文快照记录源版本与裁剪情况;缓存必须包含身份、权限版本、项目/会话、源版本、catalog 和配置,不按问题文本跨用户复用。
已有跨会话读取限制保持有效;缺少授权时只生成当前会话范围的页面,并明确范围。
事实字段尽量采用宿主数据绑定,展示值由服务端解析;模型生成的解释、建议和风险判断显式属于分析内容。
快照记录完整来源集合,包括自由文本分析的来源。读取/导出/回放时任一来源权限失效,首版拒绝整份旧快照并提供重新生成入口,不能只隐藏引用链接而继续显示泄露内容。
下一轮上下文提供经过权限复核的结构摘要、来源和确认过的交互结果;不只回灌 markdown/kv,也不把前端未提交草稿当作用户指令。
禁用插件时不再注入生成策略/动作能力;历史语义内容按正常授权保留为普通文本上下文。
### KTD5. 组件目录约束表达,不固定页面模板
首期选取已有 section、markdown、kv、list、table、compare、timeline、steps、chart-lite、doc-ref;需要时扩展受控 row/grid 布局。
每个节点必须有稳定 ID;组件目录定义 props、嵌套、数据类型和支持的动作,禁止任意 CSS、脚本、eval、远程组件 URL。
只允许语义尺寸/密度/强调枚举,映射 @ui tokens;新视觉规则按 DESIGN 与 UI gitlink 组合变更评审。
渲染器采用既有 safeHtml、Collapsible 和 motion 原语;表格提供溢出与分页/截断提示,不能静默丢数据。
未知组件或版本产生可见降级原因与文本视图;未知动作一律拒绝。不能沿用“未知节点静默消失”作为新 Surface 成功状态。
初始试验上限建议:每页 200 节点、8 层嵌套、256 KiB 规格、单表首屏最多 100 行;值为待测的资源预算,不是既有性能承诺。
同时限制字符串、数据总量、图表点数、解析时间和外部资源;图片/链接沿用宿主来源策略。
可访问性检查覆盖标签、标题层级、键盘顺序、焦点、屏幕阅读器状态提示和 reduced-motion;不能只验证 JSON 合法。
### KTD6. 动作由宿主重新授权
生成的按钮不是批准。模型只能选择已允许的 action 名称/资源引用,宿主解析为当前 Surface 的 binding。
客户端提交 surfaceId、revision、actionId、requestId 与受限表单数据;服务端重新验证当前身份、项目、插件状态、参数、资源版本与命令权限。
简单筛选、排序、页签切换留在客户端确定逻辑,不额外调用模型;需要重组织或分析时才进入现有 Agent 回合。
业务变更通过既有命令总线和 HITL,表单通过不扩大其授权范围。
幂等记录绑定身份、Surface、revision、action 和请求内容;重复点击返回已有结果,未知外部结果先查询,不因超时自动重做。
同一 requestId 但不同参数必须拒绝;重试先做当前读权限/启禁检查,再查询已有执行回执,已执行回执不能因资源版本已变化而被当作新动作重放。
```mermaid
sequenceDiagram
participant U as 用户
participant F as SurfaceHost
participant S as 宿主 Surface 服务
participant C as 命令总线
participant A as 既有 Agent
U->>F: 提交输入或点击动作
F->>S: revision、action、requestId、data
S->>S: 当前权限、启禁、参数、资源版本和幂等检查
alt 需要业务审批
S->>C: 既有审批流程
C-->>U: 展示真实动作与参数
else 允许读取或已满足审批
S->>C: 执行已授权动作
end
C-->>S: 确定结果或未知结果状态
S-->>F: 动作状态与最新投影
S->>A: 必要时追加已确认交互结果
A->>S: 新页面提议
S-->>F: 已保存且校验后的新 revision
```
### KTD7. 真正可验证的插件启禁
新插件默认关闭,不沿用现有“缺少 grant 默认 true”的行为。适用关系是安装存在、全局允许、owner 显式启用、manifest 范围与当前资源权限的交集。
首期采用实例总开关 + owner opt-in;project 开关可后续新增,不能允许项目设置覆盖实例禁用或扩大 manifest 范围。
管理员可以全局禁用;用户仅在管理员允许的范围控制自己的使用。
| 状态/动作 | 必须发生的行为 |
|---|---|
| 关闭 | 不贡献可调用工具/提示策略,不启动生成,不接受写页面与动作;原有固定 UI 可用 |
| 启用 | 校验组件兼容与配置,建立新的 activationEpoch,按请求授权能力;不重放旧动作 |
| 禁用请求成功返回 | 先持久化禁用并提升 epoch,再通知前端;返回后新请求、旧按钮和旧 generation 的提交都应被拒绝 |
| 禁用时有生成在途 | 取消该 owner/plugin 的独立宿主操作,撤销发布资格;提交前再次核对 epoch 并拒绝迟到页面。共享主模型回合继续,不调用 CancelRun 取消整个主任务 |
| 禁用时已有动作在执行 | 尚未进入执行的动作拒绝;已提交业务操作按原命令记录收尾,不能承诺撤销既成副作用;结果不明则查询恢复 |
| 历史页面 | 权限仍有效时以宿主通用静态渲染/文本查看,动作禁用;资源权限撤销后旧快照也不能继续泄露数据 |
| 再次启用 | 重验 schema、来源与权限,创建新 capability/binding;保留产物,不自动执行先前点击 |
| 卸载/升级 | 功能停用与代码包移除分开;旧产物靠宿主降级;代码升级走构建兼容验证 |
```mermaid
stateDiagram-v2
[*] --> Disabled
Disabled --> Enabled: 授权启用且兼容
Enabled --> Generating: 当前 Agent 请求页面
Generating --> Ready: 校验与事务提交
Generating --> Fallback: 无效规格或失败
Ready --> Generating: 请求重组织
Ready --> Disabled: 禁用并撤销动作
Generating --> Disabled: 撤销发布并拒绝旧 epoch 提交
Fallback --> Generating: 有限重试或用户重试
Fallback --> Disabled: 禁用
```
该状态图描述呈现能力,不等同业务任务状态。历史快照存在不代表插件 Enabled。
主 Agent 已收到的生成提示和已发生的 token 成本不能在禁用后收回;下一次能力组装移除插件策略,当前回合即使继续提议页面也会被执行端拒绝并转为文本结果。
epoch 核对与页面提交/新动作准入必须共享可证明的事务或串行化边界,不能“先查开关、释放锁、再执行”。禁用返回是准入截止点,截止点前已准入的操作按上表在途语义处理。
启禁守卫覆盖发现、命令分发、工具执行、上下文能力注入、Surface 读取/提交与动作;标明归属的能力不能通过另一入口绕过。
编译插件是可信代码扩展,不是恶意第三方代码的隔离边界。sidecar 目前继承环境并使用共享 Host token 的现状,不足以承担不可信插件沙箱。
首期只补这条能力闭环及共享执行边界;通用热重载原子化、插件市场和所有旧插件资产清理另立任务,不无限扩大本次范围。
### KTD8. 一个状态所有者,明确恢复规则
后端是 Surface 与业务状态权威;Frontend store 维护一份投影;UI 只渲染 props 并发出用户事件。
表单草稿、页签与展开状态归前端按 surfaceId/nodeId 管理;提交后成为服务器确认的输入,不能同时被模型与组件局部 state 无序覆盖。
复用主认证与 SSE 通道,不另用现有未接完整的 pluginSdk EventSource 作为第二所有者。
事件绑定会话/项目/Surface 与 seq;前端丢弃过期 seq、旧 revision、旧页面 generation;检测缺口后获取授权快照重建。
切项目、退出登录、撤权或禁用立即作废在途请求和可见敏感投影;不同身份不复用浏览器缓存。
撤权阻止继续访问和重新加载,不承诺抹去用户此前已合法下载的数据;敏感快照不写入持久浏览器存储。
普通 reconnect 不重新调用模型,先恢复已保存的快照;重新生成是用户动作或经允许的策略动作。
### KTD9. 可演进但不虚报标准兼容
内部首版使用系统自己的版本化 Surface + UINode 扩展,不能命名为“A2UI 兼容实现”后省略协议测试。
未来可加 A2UI 适配器:固定协议版本与目录版本,只支持明确子集,不支持的组件/动作显式报错,不静默损失含义。
AG-UI 仅在需要跨 Agent 框架互通时评估事件适配;MCP Apps 仅在需要外部工具应用时评估宿主资源与沙箱能力。
三者不作为首期串联依赖;避免为了 Generative UI 同时迁移模型运行、传输与前端框架。
---
## 最小宿主改动与插件交付边界
| 模块 | 建议变更 | 明确保留的职责 |
|---|---|---|
| Core | Surface/版本/节点 ID/受控布局/动作信封与兼容标识;保持旧 UINode/卡片可读 | 跨仓公开类型权威;同步 Go、TS 及契约快照 |
| Backend public extension | 授权 ContextSnapshot、Surface 读写/发布、插件 capability/activation;按需要增加受限上下文投影扩展 | 不暴露 raw DB、完整 session、通用任意 HTTP 或事件发射器 |
| Backend internal | 实现上述端口、执行级启禁、事务存储、事件恢复与动作鉴权 | 服务端最终授权与业务事实 |
| UI | 稳定节点与受控布局的通用 renderer;表单事件、行操作、无障碍、降级 | 纯展示、token/motion/Collapsible/safeHtml;不持网络状态 |
| Frontend | SurfaceHost、单一状态投影、预览落位、开关、结构更新/草稿协调 | 身份、路由、事件、用户输入草稿 |
| Generative UI 插件 | prompts/skills、目录选择、present/revise 等命令、生成校验编排、试点策略 | 只消费公开扩展,默认随当前 Agent 生成;无独立任务事实库 |
| Documents/Dev | 契约申请、使用说明、评测结论、精确组件组合与索引 | 方案/实现/验证/部署状态分别记录 |
公开扩展优先使用新增可选能力接口或版本协商,避免给现有必实现 Host 接口直接加方法而破坏所有消费者。
修改公开导出时更新 `SurfaceVersion`、`pkg/extension/surface.txt` 与相关兼容快照;Core/UI/Frontend/Backend 的依赖 gitlink 同步验证。
已有命令投影可以承载 Agent 工具,因此不申请通用 native executor 注册口作为前置。
首期不需要开放任意前端 ESM 注入;插件只输出既有/新批准的通用 UI 词汇。
如果要求“下载插件包后不重启安装”,则改为隔离 sidecar + 同一 Surface 契约。
增加独立身份、最小环境、按插件/owner capability 令牌、健康检查、取消/退出协议、版本升级与回滚;前端仍可用通用 renderer,不必加载任意 JS。
这属于另一档交付成本,不应通过当前 `exec.Command` 与共享 token 简单包装后宣称完成。
---
## 分阶段计划
下列为可评审的实施候选,不是已经获准执行的待办。每个增量继续按 `policy/delivery.md` 人工评审;试验结果允许回改选型和范围。
功能代码与生产实例本轮不变。近期 U1 具体,其余单元在试验评审后细化精确 API 与数据迁移。
### U1. 受控价值与选型试验
- 关联 R1/R4/R10;依赖:已满足并**已执行**(2026-10-11,任务 feature/generative-ui-u1);结果见下节“U1 结果与 r2 修订”。
- 对象:固定当前组件 SHA,在隔离工作区用合成或获准的脱敏材料,覆盖调研比较、任务概览、需求输入三类。
- 方法:先比较“固定 UI/文本”与“原生 UINode 动态组合”;再用少量相同样本比较 json-render/A2UI renderer 接 @ui 的复杂度与缺口。后者是 renderer 选型挑战,不另建全套后端。
- 文件范围:专用实验目录、组件契约夹具与评测说明;全部明确为原型,不替换生产路径。
- 试验预算:3–5 人日;30 个固定任务、每项至少 2 次模型运行;首轮最多 60 次/方案。费用上限已由用户指定为 **¥200**(2026-10-11);模型限 MiniMax M3 与 M2.7-highspeed,材料限合成或已脱敏样本;超限即停。
- 判据:结构选择确实随目标变化;信息来源可追溯;可通过现有设计令牌渲染;列出外部依赖节省与新增的实际代码/状态维护面。
- 停止:出现越权数据、无法限制生成代码执行、超过预算、依赖要求替换既有 runtime,暂停该路线并提交调整。
- 产物:A/B 结果、renderer 取舍、失败样本、建议目录与修订版方案;不是生产代码验收。
### U2. 通用契约、启禁与持久化
- 关联 R2/R3/R5/R9;依赖 U1 的设计评审。
- 文件范围:`modules/core/ui.go`、Core 新 Surface 契约及对应测试;`modules/backend/pkg/extension/`、`internal/plugins/`、`internal/store/`、`internal/server/` 及对应测试/迁移。
- 方法:先固定兼容与授权信封,再实现 owner 隔离的 Surface 存储、revision CAS、activationEpoch 和命令执行守卫;能力缺失明确拒绝。
- 验证:旧消费者可用;关闭状态下 direct API/工具/旧 action 不绕过;并发更新有一方冲突;写快照后事件发布失败可恢复;SQLite/PG 路径一致。
- 完成条件:最小公开契约审过,故障/拒绝路径有证据,插件能通过公开接口保存/读取页面;此时不宣称生成体验完成。
### U3. 生成插件与上下文闭环
- 关联 R1/R2/R3/R6;依赖 U2。
- 文件范围:独立插件的 manifest、commands、prompts/skills、目录和测试;Backend `internal/ctxasm/` 的通用语义投影、授权快照适配及测试。
- 方法:沿用 AddCommandHandler/exposeAsTool;当前 Agent 接收可用词汇和授权快照,产出页面参数;插件校验,宿主原子发布。解析/语义修复最多 1 次,失败回到文本,禁止无限自修复循环。
- 验证:同素材换任务得到合适不同结构;伪造数据引用与未知动作被拒;下一轮可以解释并修改之前的 table/compare/tabs;禁用不再注入能力。
- 完成条件:真实模型“任务→规格→保存→继续修改”闭环可回放,来源与成本被记录;不另造 Agent runtime。
### U4. 只读生成页面与可恢复体验
- 关联 R1/R2/R4/R5/R6;依赖 U2,最终集成依赖 U3。
- 文件范围:`modules/ui/src/UIRenderer.tsx` 及测试、通用 Surface 展示组件、`modules/frontend/src/store.ts`、`api.ts`、预览/卡片入口、插件设置及对应组件/浏览器测试。
- 方法:稳定 nodeId、布局语义、受控 renderer、唯一 SurfaceHost;加载/失败/回退/来源/重新组织入口;单一 store 校验 seq/revision/generation。
- 验证:刷新/断线/切项目/迟到响应;关插件固定界面仍完整;页面未知版本可读;键盘、窄屏、暗浅主题;输入焦点与布局变化规则。
- 完成条件:场景 1 可通过真实浏览器完整使用;此增量提供展示和重新组织,业务写动作未开放。
### U5. 动态表单和动作闭环
- 关联 R7,依赖 U2/U3/U4;必须先评审本阶段动作范围。
- 文件范围:Core 动作/字段 schema、UI 表单与行操作及测试、Frontend 草稿/提交桥、Backend action service/cmdbus 适配及权限/幂等测试。
- 方法:输入草稿由宿主管理;服务端绑定 action;必要时进入既有 HITL;失败留在当前页面并保留可恢复输入。
- 验证:旧 revision、资源被删、撤权、关插件、双击、超时未知结果、两个标签页同时提交;无审批旁路;用户未提交输入不传给模型。
- 完成条件:场景 3 可完成明确读取/决策动作,再逐类批准业务写动作,不能一次开放所有命令。
### U6. 自适应任务与项目工作区
- 关联 R8,依赖 U4/U5 的收益与可靠性证据。
- 文件范围:Frontend workspace/任务页容器、插件上下文选择与触发策略、Backend 授权聚合适配、相关测试。
- 方法:先当前任务,后项目;任务阶段触发有限更新;固定布局/恢复原视图;自动模式单独 opt-in。
- 验证:不同阶段突出不同信息;任务事实不能被页面改写;私有会话不泄露;输入时不自动重排;自动触发有预算且不递归自激。
- 完成条件:实际任务效率改善,关闭后原工作区完整,跨会话汇总授权能复核。
### U7. 组合验收、兼容与交付
- 关联 R2/R5/R9/R10;按每个可交付增量执行,不只在最后一次执行。
- 文件范围:各模块相关测试、Documents 使用/评测记录、Dev 任务卡和精确 gitlink 组合;涉及治理脚本才追加治理测试。
- 方法:先组件 PR,再组合 PR,固定 Dev SHA+组件 SHA+schema/catalog/model/profile;复放正常、异常、权限、禁用与恢复链路。
- 验证:CI `make test`/`make build` 与独立重放;业务智能体改动附真实模型前后对照;本地 SELF 不升级为 GATE。
- 完成条件:用户批准该增量、功能与回退均有证据、文档和开关说明完整;是否部署仍是独立授权与运行验收。
粗估:U1 3–5 人日,U2–U4 首个可靠只读闭环再需约 10–18 人日,U5 约 5–8 人日,U6 约 5–10 人日。
这些是范围估计,假设熟悉现有代码且使用可信编译插件;不含人工等待、全量外部协议兼容和不可信插件沙箱,不是交付承诺。
---
### U1 结果与 r2 修订(2026-10-11)
U1 三臂对照(B=Markdown 基线 30 任务;G=M3 UINode 生成 30 任务含一次修复;G-hs=highspeed 子集 10)
与 renderer 挑战已完成,全部材料为合成样本,总开销 ≈¥3.0(上限 ¥200)。详细数据与失败样本:
Dev 任务卡 feature/generative-ui-u1 及其 `.task/genui-u1/report.md`(SELF 记录;随任务 PR 留 CI GATE)。
关键结论与修订(构成本 r2 相对 r1 的差异):
1. **R1 结构分化成立**:同料不同目标 6/6 对照全部分化(类型多重集 Jaccard 0.17–0.50)。
2. **生成通道硬约束(修订 KTD2)**:页面规格只能经插件命令工具参数(exposeAsTool)提交,
不接受聊天文本 JSON。依据:文本通道首过合法 60%/修复后 83%,终判失败全部为长中文 JSON
语法违纪;工具参数通道探针解析干净、仅剩可修复语义错误;`response_format` 探针无效。
3. **目录文档要求(修订 KTD5)**:每类型附完整最小示例;按目标类别给推荐/禁用词汇
(实测 order/handover 目标下存在未被要求的 form/actions 超生成);校验器升级为 schema
驱动、目录=提示=校验三同源(借鉴 json-render,不引入其运行时)。
4. **模型路由(修订 KTD2)**:生成档固定 MiniMax-M3(highspeed 文本通道合法率 20%,否决其
生成用途;轻量步骤仍可用 highspeed)。成本实测 ¥0.067/任务(M3),可忽略。
5. **renderer 取舍确认**:首期扩展自研 UIRenderer;json-render(0.21.0)端到端可用但组件
契约重且状态/动作运行时与我方重叠,记为 U5 交互期重评项;A2UI(0.13.0)导入即需 DOM 且
客户端 signal 绑定与 KTD4 宿主解析冲突,不推荐。
6. **验收线移位**:首过 ≥90%/修复后 ≥98% 维持为 U3 工具通道验收线;本轮 60%/83% 记为文本
通道下界。稳定 nodeId 纪律良好(25/25 合法规格全提供),U2 信封先行得到支持。
局限:人类可用性对照 NOT_RUN;合成材料、n=30、每任务单次采样;G-hs 有效样本 n=2 不具统计
意义;首轮 harness token 预算缺陷已修复重跑(事故记录见报告第六节)。
## 验证与评估
### 试点评价方法
采用相同材料、权限、模型/profile、任务和重复次数比较固定 UI/文本基线与生成 UI。
分别记录冷启动/缓存、模型时间、验证时间、渲染时间、额外 token 与调用次数;不把缓存命中混作生成加速。
默认观测记录规格/目录版本、耗时、字节数、token、错误码和回退原因;原始上下文、输入值与模型全文不进入普通日志,评测原始材料按既有 eval 规则保存在受控环境且不进仓。
以下阈值为**建议评审目标**,本轮无实测结果:
| 维度 | 建议目标/方法 |
|---|---|
| 任务有效性 | 任务成功率至少不低于基线;选定比较/梳理场景的人类中位完成耗时改善约 20% 才考虑扩大自动模式 |
| 事实可靠性 | 验证集中的资源/数值引用可追溯;关键事实错误为 0;分析判断独立标注 |
| 规格有效率 | 首次合法页面 ≥90%;最多一次修复后 ≥98%;最终失败 100% 有可用文本降级 |
| 延迟 | 浏览器先给确定加载状态;本地校验+渲染 P95 目标 <300ms;模型生成单独统计。显式页面请求的初始展示等待预算为 20s,超时转文字等待/回退并撤销该次发布,不因此中断共享主 Agent 回合 |
| 干扰 | 普通文本任务不额外调用 UI 模型;不会每个 token 重排;用户输入与焦点不丢失 |
| 开销 | 展示额外 token、调用数、失败重试成本与收益;是否可接受在真实模型对照后决定,不先声称“更快更省” |
| 开关正确性 | 禁用成功后所有新副作用入口拒绝;旧 epoch 页面不能提交;保留授权历史与原 UI |
30 个任务的小试验用于发现问题和决策,不足以证明长期生产可靠率;报告样本量、失败数和每类任务结果,不只报百分比。
若收益只体现在“更好看”而任务成功率/效率下降,保留按需模式,收窄场景或停止推广。
### 必测故障与权限矩阵
- 正常:同材料不同任务、纯文本无需页面、生成后改布局、来源打开、刷新恢复。
- 结构:未知节点、循环/过深结构、超大表格、非法数据类型、畸形 JSON、未知 schema/catalog、非法 URL/脚本属性。
- 权限:跨 owner/project/doc 引用、跨会话私有内容、生成后撤权、切账号/项目、直接 API 调用、伪造动作 ID。
- 异步:重复/乱序/缺口事件、断线重放、两个标签页、旧 revision、切页后的迟到响应、保存成功但事件未发布。
- 启禁:生成前/中/提交前禁用,动作前/审批后/执行中禁用,服务重启,重新启用,兼容版本缺失。
- 交互:表单校验、重复提交、业务冲突、输入中更新、取消、失败后保留草稿、外部结果未知不重复执行。
- 回退:插件完全缺失、模型不可用、预算耗尽、renderer 出错;固定 UI 和授权文本历史仍可用。
- 回归:旧 UINode、卡片、命令、工件预览、侧栏关闭、单二进制构建、SQLite/PG、设计守护与可访问性。
正式实现期按各组件 PROJECT 的命令验证,并在 Dev 精确组合运行 `make test`、`make build`。
涉及智能体提示/工具/上下文变化时,按 `policy/delivery.md` 的真实模型任务级前后对照要求执行;mock 只能证明机制。
证据由 `make evidence` 写入任务卡,保留 SELF/REPLAY/GATE 和固定对象,未运行项保持 NOT_RUN。
本轮只检查方案差异、引用与链接、源码对应关系;没有运行上述功能试验或业务测试。
---
## 风险、待确认项与下一步
| 风险 | 具体处置 |
|---|---|
| 页面自主性变成固定模板填充 | 用同事实不同目标的验证例证明结构变化;逐步开放组合能力,而非预设三种页面硬路由 |
| 模型幻觉变成“业务事实” | 事实字段绑定授权源、生成判断标注、来源版本可回查;业务状态只走原服务 |
| 自主重排破坏可用性 | 稳定宿主入口、布局固定、输入期间冻结结构、按语义事件有限更新 |
| 声明式 schema 被误当安全边界 | 仍对资源、URL、动作、执行权限和数据泄露做服务端校验;可信插件代码另有信任边界 |
| 禁用只藏按钮 | 执行端统一守卫、epoch 与提交前复核;直接 API 和在途测试列为必过项 |
| 引入第二套状态/runtime | 复用主 Agent、主 SSE 和 Frontend store;外部包只在明确 renderer 边界试验 |
| 公开接口扩大过快 | 小型能力接口、版本协商、兼容快照;不暴露内部 store,避免泛化插件市场 |
| 外部项目快速变化 | 固定依赖版本,锁 catalog,保留适配层;Tambo Cloud 停服作为实际供应商生命周期样例 |
### 用户裁定记录(2026-10-11)
以下三项已由用户(weichen)裁定,原“进入试验前需确认”问题随之关闭:
1. **接受“动态业务页面 + 稳定宿主入口”**:首试点为对话中的完整分析页(场景 1),随后推进任务/项目工作区。
2. **“随时启禁”采用可信编译插件交付**:功能启禁无需重启,插件代码安装/升级需重建并重启;不要求本期免重启安装,sidecar 路线保留为备选。
3. **试验参数**:裁定与验收负责人为用户(weichen),执行由 Agent 承担;模型限 MiniMax M3 + M2.7-highspeed;材料限合成或已脱敏样本;U1 费用上限 ¥200。
注:裁定后权威 main 又合入前端三栏工作台(Dev PR #322)。本文“当前系统的可行性依据”按调研时固定 SHA 记录、不改写;U1 开工时须在新 HEAD 上重验该源码事实表。
首选下一任务是 **U1 受控价值与选型试验**,不是直接实现所有宿主契约。
其前置(批准试验范围与预算)已由 2026-10-11 裁定满足;产物为固定样本 A/B 报告、实际 renderer 取舍、失败清单与 r2 方案。
验收依据为 R1/R4/R10 的可判定结果,随后再决定 U2–U4 的正式投入。
U1 按独立任务启动并继续逐阶段人工评审;本文发布(推送、合入)随裁定记录一并进入 PR 评审,部署仍不在本轮范围。
@@ -0,0 +1,253 @@
---
title: 多人协作存储与分布式演进方案 - Plan
type: refactor
date: 2026-10-11
execution: code
product_contract_source: ce-plan-bootstrap
---
# 多人协作存储与分布式演进方案 - Plan
修订:r1;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:方案获批发布,实施自首选增量 U1+U2 启动;业务实施/迁移/压测/部署仍为 NOT_RUN,逐项以实施任务卡为准。
需求来源:2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工;随后确认“10–100 人,多人多项目多会话并行,未来支持多服务分布式”。
需求负责人:weichen;方案编制:Codex;实施及运维负责人:待指定。更新时间:2026-10-11(Asia/Shanghai)。
关联任务:Dev `.task/feature-collaboration-storage-plan.md`(方案任务,已发布);后续 U1+U2 实施由独立任务承接。
正文中的源码路径以 Agent-System-Dev 为根;工作包中的 `internal/` 简写指 `modules/backend/internal/`;文内相对链接以本文为根。
## 1. 推荐结论与边界
团队部署以 PostgreSQL 作为共享业务状态的唯一权威,pgvector 承担数据库内向量查询,Redis 承担可丢失的缓存与限流。SQLite 保留给个人嵌入式使用、离线工具及可以重建的本机状态,不承载团队共享写入或跨主机运行所有权。
第一阶段交付单应用实例的可靠团队部署;第二阶段补齐执行所有权、持久命令、共享工件与事件追赶,再开放多个应用实例和 Worker。通过接口和数据归属为服务拆分做准备,当前不要求微服务化、Kubernetes、分片或引入另一套消息中间件。
“不会出现错误”不能成为无条件承诺。工程目标是:在定义的故障模型下,不静默丢失已确认数据、不覆盖他人的并发更新、不产生未经识别的重复副作用、不越权;异常可发现、可追踪、可恢复。冲突可以返回明确的 409,超载可以返回 429,依赖故障可以返回 503,它们必须有清楚的重试语义。
本方案是[双档存储 D17–D24](2026-09-30-dual-tier-storage-and-multitenancy.md)的候选增补,批准前不改写原已采纳决策。拟调整的是团队部署的默认与必需条件,以及 D24 原来排除的跨实例执行能力;保留个人 SQLite 档、非容器部署、现有检索契约与序号语义。
## 2. 当前事实与差距
源码调查基线:Dev `73c901fa341a3653d6e0826d0da3497507995482`,Backend `eda90ed310f37f7352e24a8096d932dbf320cd73`,Documents `9a46785ee0f19540c79f83b4e4544572b5217ac2`,Agent-Squad `490b0b2dfa1567cb16ff7a7230fd78e52bc2938e`,Agent-Native `c348441691e8bdab784a03aa9be64d53dacff341`。
来源均为 **SELF·源码/本机只读观察**;没有真实并发故障重放。命令、对象 SHA 和原始输出见[调查收据](../records/2026-10-11-collaboration-storage-audit-receipt.json),启动收据见任务卡。
| 对象 | 当前可核实事实 | 方案含义 |
|---|---|---|
| Dev 运行实例 | `runtime/dev/bin/agent-system`、8788 端口打开 `runtime/dev/data/agent-system.db` 及 WAL;二进制 build revision 为 `017b40f76156905eabe8323ae2bfe800f47fb8bd` | 当前服务确实使用 SQLite;运行版本与上述源码基线不同,源码缺陷不冒充已在该二进制重现 |
| 本机安装 | Homebrew 列出 PostgreSQL 18.6、pgvector 0.8.7、Redis 8.10.2 | 仅证明安装;目标 PG 实例、目标库扩展启用、角色与可用性未验证,不据此批准切换 |
| Backend 存储 | `internal/app/app.go:105` 按 DSN 选 PG,否则 SQLite;`store/store.go:50` SQLite WAL、busy_timeout=5000、单连接;PG 池固定 16/8 | 无需重写全部存储层;需团队档显式配置、连接预算和真实 PG 测试 |
| 已有一致性基础 | `store/dialect.go:49` PG 事务咨询锁;消息 seq 唯一约束、requestId 去重和 HITL 条件更新 | 保留并扩展,不把已有能力列作全新建设;这些能力不等于跨实例运行互斥 |
| Run 所有权 | `runmgr/runmgr.go:1113` 用进程内 map 占用会话;`store/messages.go:120` 直接创建 run | 两实例可能各自认为空闲;需共享占用和有效执行代次 |
| 取消与审批 | `runmgr/runmgr.go:1326,1422` 依赖本实例 active 句柄;HITL 先落卡,再查句柄 | 请求落在非执行实例时存在命令不生效或卡已处理但执行未被唤醒的风险 |
| 跨实例事件 | `pgbus/pgbus.go` 每批通知末 seq,Listener 只 `EventAt` 取末条;断线后对原连接继续 Wait | 静态可见批内中间事件遗漏及重连缺口;`server/server.go:376` 的 SSE 重放/去重不能修复已越过的游标 |
| schema 迁移 | `store/migrate.go:migrate` 每次 Open 执行迁移;DDL 事务提交后另行插入迁移版本 | 并发启动与两步间崩溃存在风险;切 PG 前先改为单迁移入口与原子版本登记 |
| 向量查询 | `store/vectors.go` 读取 BYTEA,应用内计算余弦;`migrate.go` 未把向量列建成 pgvector 类型 | 安装 pgvector 不代表启用;复用 RRF 管线,分阶段改为数据库 top-k |
| Redis | `ratelimit/ratelimit.go:65` 独立 INCR/EXPIRE,EXPIRE 错误未处理;请求异常默认放行;app 默认限额 0 | 当前只是可选共享限流,需原子窗口、鉴权/TLS配置、容量保护与可观察的降级 |
| 本地文件 | `blobstore` 默认本地目录;Backend Squad 入口未传 Store,回落 FileStore;checkpoint 写 `.agentx/checkpoints.jsonl` | PG DSN 不会迁走这些状态;工件、执行工作区、checkpoint 要分别处理 |
| 独立 Squad | 独立 CLI 使用 `adapters/sqlite/runstore.go` 的 `orchestration.db`;这不是 Backend 实际接线 | 不把迁移该 SQLite 文件当作 Backend 分布式改造完成 |
| 验证 | PG/Redis 集成由 `AGENT_PG_TEST_DSN`/`AGENT_REDIS_TEST_ADDR` 控制;当前 CI YAML 没有显式准备这两种服务 | 缺变量会跳过关键测试;CI 通过不能自动证明真 PG/Redis 或双进程链路通过 |
已有规划衔接:Q1 已记录 Store 收敛但仍留 platform→squad 队列桥接等余项;N3 原案与归档卡的 JournalOnly 落地不同,应以当前接线确定权威。共享权限沿用 EXT-8 授权适配器与 RDM 的成员/角色职责,不新建第二套成员模型。历史报告用于定位,不能替代当前验收。远端调查发现 Backend [#135](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/135) 正在增加 S0 工作区 overlay/frozen base/CAS apply;U5 必须复用并核对其契约,不能另造冲突的工作区实现。该 PR 尚未作为本案已合入依赖。其他被查仓当时未返回 open PR,详见收据;实施启动时重新核对。
## 3. 需求与可判定结果
| ID | 需求 | 优先级 | 验收条件 |
|---|---|---|---|
| R1 | 支持 10–100 人、多项目、多会话并行 | P0 | 在固定环境与下述负载下完成真实业务链路;容量结果绑定组件 SHA、配置和数据集 |
| R2 | 团队数据有唯一共享权威 | P0 | 团队档无有效 PG 配置或连接失败时拒绝就绪,不自动建立本地 SQLite 继续服务 |
| R3 | 并发提交和编辑不静默覆盖 | P0 | 同 requestId 返回同一逻辑结果;同版本竞争写入最多一个成功,其余明确冲突;不同会话并行 |
| R4 | 跨实例运行与命令可恢复 | P1,多实例前置 | 同会话主 run 单一有效 owner;旧 epoch 写入拒绝;任意 API 实例取消/HITL 均到达执行者 |
| R5 | 事件有序、可追赶 | P0/P1 | 批处理、掉通知、重连和慢消费者后可按游标补齐全部已提交事件;不因收到末 seq 而跳过中间事件 |
| R6 | 项目权限在所有数据入口一致 | P0 | 读取、写入、SSE、检索、下载与工具入口均校验当前授权;撤权后的新请求无泄漏 |
| R7 | 数据和运行状态可恢复 | P0 | SQLite→PG 演练无遗漏;备份恢复含文件与权限映射;未知副作用停在可见恢复状态,不盲目重试 |
| R8 | 高负载下有界且可观察 | P0 | 队列、活跃 Agent、DB 连接、工具/模型请求都有上限;超载行为、等待时间和错误分类可观测 |
| R9 | 向量检索随数据增长扩展 | P1 | 数据库 top-k 与原精确基线对照;授权过滤正确;模型/维度/版本不混用;ANN 有召回率与延迟证据 |
| R10 | 支持未来多服务部署 | P1/P2 | 先验证两个真实 API/Worker 进程共享服务;业务表有模块 owner,后续服务通过契约操作他方数据 |
R1 的人数及未来分布式方向由用户确认;下列量化指标是**建议的验收合同,待批准,不是当前性能结论**:
- 基准环境建议:Linux、8 vCPU、32 GiB RAM、NVMe,记录 PG/应用的实际配额与网络;两实例验证分为同机多进程和后续双主机两种证据。
- 阶梯负载:10→30→100 在线用户,最多 300 SSE 连接;初始全局活跃 Agent 执行预算 20(包含子代理)、每用户 2、索引任务 4。待执行队列最多 200,按用户/项目公平分配。已接纳 run 数与实际执行许可分别计数;父 run 等待子代理/HITL 时让出执行许可、保留会话所有权,恢复执行须重新获许可,避免额度用尽时父子互等。以上阈值由实测调整。
- 数据量建议:100 万条消息/事件量级、10 万知识分块、多个项目与交叉授权用户;另测 100 万分块扩展档。记录数据分布与热点,不能只测空库。
- 非模型普通 API:P95≤300ms、P99≤1s;SSE 持久事件可见延迟 P95≤1s;非预期失败率≤0.1%。预期限流/冲突单列,不能排除后不报告。
- 先跑 60 分钟稳定负载,再跑 2 小时混合长稳;持续记录实际成功吞吐、排队、CPU/内存/IO、连接等待和模型配额。模拟模型用于容量基线,另保留真实模型少量全链路验证。
- 数据正确性不变量在全部测试中零违反。数据库/Worker 故障恢复建议 RTO≤15 分钟;灾难恢复建议 RPO≤5 分钟、RTO≤60 分钟。主机/存储全毁不在单机“零丢失”承诺内;若要求该场景 RPO=0,需另行批准同步复制、故障域与可用性取舍。
## 4. 技术决策与目标结构
KTD1. **区分 local 与 team 部署档。** local 保留 SQLite;team 强制 PG、认证、独立实例 ID、受控工具执行和启动诊断。PG 暂时不可用时返回未就绪,不切回 SQLite。个人档不因浏览器人数变多而自动升级。
KTD2. **PG 保存持久业务与调度事实。** 用户/项目/会话/消息/卡片/运行/幂等记录/命令/事件/checkpoint 元数据以 PG 为准。Redis 不成为任务完成、审批通过或永久幂等的唯一证据。初期使用同一 PG 实例和有归属的逻辑表/角色;后续拆服务时明确表的唯一写入模块,避免所有服务无约束共享整库。
KTD2 的全部状态收敛以 U5 完成为界;此前有明确的单实例过渡边界,不能提前把本地状态当成缓存:
| 数据 | 首期单实例团队版 | U5 后多实例版 |
|---|---|---|
| Backend 业务记录、幂等与恢复隔离标记 | PG 权威 | PG 权威 |
| 尚未改造的 Squad FileStore、checkpoint、续跑标记 | 唯一实例的本地权威文件,联合备份,禁止跨机接管 | 版本/归属元数据在 PG,大内容在共享对象存储 |
| 工件 | 本地对象目录,持久备份与 DB 清单绑定 | 共享不可变对象与 PG 发布记录 |
| 临时执行目录 | 单实例/单 owner;先分类再清理 | owner+epoch 控制的可恢复工作区 |
KTD3. **一个会话一次主执行,不同会话并行。** 推荐独立 conversation_execution 占用行,以 owner/会话唯一键、run_id、epoch、lease_until 约束;不对所有 runs 加“会话唯一”,以免禁止正常子代理。事务内完成权限检查、请求幂等、消息、主 run 和调度记录,接收成功以事务提交为准。
KTD4. **短事务领取,租约与 fencing 配套。** Worker 通过 PG 行锁和 SKIP LOCKED 领取到期任务;事务提交后执行,模型/工具等待不得持有数据库事务。续租、事件追加、checkpoint、终态写入都校验 run+epoch。租约用 DB 时间,执行实例 ID 与每次启动的 generation 分开。旧 Worker 恢复后不能提交;租约过期也不等于外部命令已经停止。
KTD5. **持久命令与提交事件同事务。** 取消/HITL/调度命令写入 PG inbox/outbox,带唯一 command_id、逻辑 run、执行代次与处理状态。运行级取消意图交给当前 owner,即使接受后发生接管也不能丢失;HITL 绑定稳定 gate_id+gate_version,新 owner 消费时重验 gate 与权限,过期审批明确拒绝而不静默丢弃。执行结果及确认仍须校验当前 epoch。批准数据与待投递命令原子提交,执行者幂等消费,处理确认与执行效果分别记录。关键外部动作必须有目标端幂等键、可查询凭据或人工恢复路径;超时结果未知时进入 recovering,不宣称任意工具 exactly-once。
KTD6. **事件表是重放依据,NOTIFY 仅作唤醒。** 事件提交与 outbox 同事务;需要时在同事务使用 pg_notify。监听端维护每流连续 cursor,从 EventsAfter 分页追赶到通知水位;不能直接跳到末 seq。重建连接→LISTEN 生效→补查水位/积压,再转实时。增加周期补查,覆盖通知丢失、断线与通知前后竞争。只有落库事件才能发布可恢复的 SSE ID;纯瞬时进度明确可丢失,不冒充已确认业务数据。
KTD7. **数据库乐观并发控制。** 项目设置、卡片、文档元数据等读改写带 version/expected_version;冲突返回 409 及新版本引用。重要唯一性/外键落在数据库,事务失败按错误类型有界重试整笔事务;提交结果未知先按幂等键查询。不能无限重试模型调用或发送动作。[PG 事务隔离与重试](https://www.postgresql.org/docs/current/transaction-iso.html)。
KTD8. **数据库迁移独立于普通启动。** 单一 migrator 取得数据库锁,执行 append-only 版本;可事务化 DDL 与版本登记同事务。应用仅核对兼容版本和就绪状态。不能放入事务的在线索引变更单列可恢复运维步骤,不夹入普通迁移后声称原子。使用扩展→回填→切读写→收缩,保留兼容窗口。
KTD9. **工件共享,工作区有执行 owner。** 先保留 blobstore 接口;跨主机上线前实现并验收 S3 兼容对象存储,DB 保存不可变对象键、校验和、版本与就绪状态。发布前先完整写对象再提交引用,失败孤儿可清理;删除采用标记和延迟 GC。工作区、检查点与 Squad 状态分开设计:checkpoint/调度版本入 PG,大内容入对象存储,本地工作区是受 owner/epoch 控制的暂存执行目录;需要接管时按清单恢复。共享目录和文件 rename 不能替代跨机所有权。
KTD10. **Redis 只保存可恢复的加速状态。** 保留共享限流,改为 Lua 原子计数+过期或等价原子算法,键包含实例群/完整时间窗/owner,支持 ACL 凭据/TLS、连接与请求超时。故障时普通读取可降到本地保守限流;创建 Agent/昂贵工具等写入口仍受 PG admission 硬预算保护,不能无界放行。缓存带授权/内容版本,撤权同步失效或重新校验;先证明命中收益再加缓存。[Redis INCR 限流模式](https://redis.io/docs/latest/commands/incr/)、[分布式锁限制](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/)。
KTD11. **pgvector 按“正确→测量→ANN”推进。** 复用现有全文+RRF+可选 rerank,先补 embedding profile/model/revision/dimension/content_hash/generation 身份,禁止同维不同模型混查;迁移为 vector 列并在 PG 做过滤和精确 top-k,再用基线对照决定 HNSW。权限适配器不能直接变成 SQL 时,由适配器提供受限授权候选集合或采用有界分批取候选+最终实时鉴权,不得无界加载所有 owner 后在内存过滤。授权过滤后的召回率单独验证;ANN 需要迭代扫描/分区等策略时以模型维度和版本实测选择。[pgvector 官方说明](https://github.com/pgvector/pgvector)。
KTD12. **先管理连接池,再决定 PgBouncer。** 使 MaxOpen/Idle/IdleTime/Lifetime、查询超时可配置并输出脱敏有效值;总连接预算包含所有 API、Worker、LISTEN、migrator、监控与维护预留。100 在线用户不等于 100 DB 连接。未来接 PgBouncer transaction pooling 时 LISTEN 必须使用直连或 session pool 独立 DSN,迁移也走直连,并验证 pgx prepared statement 配置。[PgBouncer 兼容表](https://www.pgbouncer.org/features.html)。
KTD13. **共享可读不等于可写或可批准。** 当前 EXT-8 `ProjectAuthz` 是只读 bool 契约。U3 先列 read/edit/approve/execute/admin 的动作授权矩阵,复用下游角色,不另建成员权威;需要共享写入时以版本化公开契约扩展 action-aware 授权,旧只读适配器不得自动获得写入能力。未配置的动作默认拒绝,Host/工具/API 均走同一授权结论;审批职责分离仍由下游规则判定。SSE 发送后续数据、异步任务开始和工件下载时重新校验当前授权,缓存失效不承担唯一安全责任。
KTD14. **迁移副本按原数据敏感级别保护。** 备份、导出、WAL、工件和测试副本使用专用角色及受限目录;传输与静态备份加密,解密材料保存在独立受管秘密存储并纳入恢复演练。日志/报告只留统计与哈希,禁止正文、令牌及密钥明文;测试使用脱敏数据。U1 固定保留期限、存放位置、访问者与清理责任,未知项阻塞正式导出。正式恢复演练同时验证凭据可用性与非授权者无法访问副本。
```mermaid
flowchart LR
U[10–100 用户] --> G[入口与认证]
G --> A[API 实例 A / B]
A --> P[(PostgreSQL + pgvector)]
A --> R[(Redis 限流 / 可重建缓存)]
P --> W[Worker 领取任务 / 持久命令]
W --> P
W --> X[受控工具工作区 / 模型服务]
W --> O[(共享对象存储)]
A --> O
P --> E[事件追赶 / 本地订阅]
E --> U
```
```mermaid
sequenceDiagram
participant C as 用户
participant A as 任意 API
participant P as PostgreSQL
participant W as 执行 Worker
C->>A: 提交 requestId / expected_version
A->>P: 短事务:鉴权、幂等、占用、消息、run、任务
P-->>A: commit / 冲突
A-->>C: 已受理与 runId / 明确冲突
W->>P: 领取任务并取得 epoch
W->>W: 事务外执行模型与工具
W->>P: 按 epoch 提交结果与事件
P-->>A: 唤醒后按 cursor 补齐
A-->>C: SSE 已提交事件
```
```mermaid
stateDiagram-v2
[*] --> queued
queued --> running: 原子领取并分配 epoch
running --> waiting: 持久 HITL
waiting --> running: 幂等命令消费
running --> completed: 有效 epoch 原子结算
running --> recovering: 失联或副作用结果未知
waiting --> recovering: owner 失效
recovering --> queued: 已核对可安全重试
recovering --> interrupted: 需人工处理或不可恢复
queued --> cancelled: 取消命令生效
running --> cancelled: 执行者确认停止
```
## 5. 实施顺序与工作包
每个阶段评审后再进入下阶段;以下均为待批准计划,不因写入文档取得实施授权。新测试文件标“新增”;现有测试只作为扩展入口,本次未运行。普通基座改动在 Backend;公开持久接口确需变化时才同步 Native/Squad/Core,并由 Dev 固定组合测试,不全库改造。
### U1. 冻结目标、数据归属与基准环境
对应 R1/R2/R7/R8。先确定目标为 Dev 团队实例及其实际发布制品,记录脱敏配置来源、DB 实例/版本/扩展、数据数量与归属、文件清单、磁盘容量、峰值和恢复目标。RDM 独立业务库、旧 Agent-System 治理库另列,不能把一次 DSN 切换宣称覆盖它们。
范围:`runtime/dev` 部署配置(实施时核对文件位置)、`modules/backend/internal/config/config.go`、文档运行手册。
产物:固定部署清单、迁移映射、容量合同(区分接纳与执行许可)、隔离测试库/目录/端口方案、KTD14 的副本保护与保留合同;确认暂态 Worker 文件哪些可重建,哪些必须迁移。
验收:仅操作批准的实例和测试资源;共享数据凭据不打印;未知 owner 或未定位的权威文件阻塞迁移。测试:脱敏配置诊断及缺项校验,业务压测依后续 U7。
### U2. 团队 PG 档、迁移器与真实数据库门禁
依赖 U1;对应 R2/R3/R7。修改 `internal/config/config.go`、`internal/app/app.go`、`internal/store/store.go`、`internal/store/migrate.go` 及 CLI;按 KTD1/KTD8/KTD12 实施。
CI 增加隔离原生 PG/Redis 生命周期及明确必跑标记,固定组件/扩展版本;缺少真实测试服务时该 job 失败而非跳过。
测试:扩展 `internal/config/config_test.go`、`internal/store/store_test.go`;新增 `internal/store/migrate_atomic_test.go`。覆盖 team 缺 DSN/PG 故障拒绝启动、local SQLite 正常、两个 migrator 竞争、DDL 与账本中间崩溃、旧 schema 升级、PG bool/时间/空 JSON/唯一约束与全文扩展。
出口:真 PG 完整 CRUD/认证/会话/SSE/检索/卡片链路通过;仅该出口不宣布多实例安全。schema 变更的组合测试与业务迁移是不同动作。
### U3. 请求原子性、版本冲突与受控容量
依赖 U2;对应 R3/R6/R7/R8。修改 `internal/server/server.go`、`internal/store/messages.go`、`internal/store/cards.go`、`internal/cardsvc/cardsvc.go`、设置读改写及 `internal/runmgr`。收口 KTD3/KTD7 的事务边界;保留现有 seq 约束。按 KTD10 完成 Redis 原子限流、配置与异常策略;PG 记录共享 admission 预算。按 KTD13 完成动作授权矩阵与所需公开扩展的兼容计划;涉及共享编辑时 Core/Host 与下游适配器一起验收。
先补最小持久恢复隔离:为未知副作用记录 recovery hold,`ResumeInterruptedChildren` 等所有启动续跑入口必须跳过,人工核对后显式解除。概念状态 recovering 可以先由独立隔离记录表达;扩展 Core 枚举时走公开契约版本,不假定当前已有此状态。完整租约接管留 U5。
测试:扩展 `internal/server/admission_test.go`、`internal/ratelimit/ratelimit_test.go`;新增 `internal/store/admission_pg_test.go`、`internal/store/card_version_test.go`、`internal/runmgr/recovery_hold_test.go`。覆盖相同请求重放、事务部分失败、同版本竞争、动作越权、子代理预算计入全局、所有父 run 占满额度后同时派生仍能前进、未知副作用重启不自动续跑、队列满、Redis 断连/恢复/键过期。
出口:单 API 团队模式达到不变量与有界行为;不会把 20 个 Agent 配置值当作已证明容量。
### U4. 可切换的迁移与恢复演练
依赖 U2/U3;对应 R2/R7。新增 `modules/backend/cmd/storage-migrate/` 或等价受管运维入口,明确只处理 Backend 库;不得直接执行 SQLite dump 作为 PG SQL。迁移实例以 migration_id、source_snapshot_id、source_schema_version 固定来源,记录表级完成与最终验证完成标记;仅同一冻结快照可续传,其他非空目标拒绝。迁移报告包括每表计数、主键映射、按主键分批规范化内容校验和、外键/owner/权限检查及工件哈希。
测试:新增迁移工具的 `main_test.go` 与 `integration_test.go`,固定脱敏 SQLite 夹具覆盖全部当前 schema、布尔/空值/时间/JSON/Unicode/二进制向量/秘密字段、幂等重复导入、缺文件、未知 owner、断点重试及目标已含数据拒绝。
操作顺序与回退见第 6 节。出口:隔离环境迁移与恢复验证完成,由用户批准窗口后才切正式服务。
### U5. 执行所有权、持久命令与共享状态
依赖 U3,团队现网切换不必等待整个 U5;对应 R4/R6/R7/R10。修改 `internal/runmgr`、`internal/store/recovery.go`、`internal/squadadapter`、`internal/runtime/squad_runner.go`、`internal/blobstore`;新增 Store 的 lease/inbox/outbox 与 PG RunStore 适配器。
按 KTD4/KTD5/KTD9 设计 Native checkpoint 接口,继续支持 local 文件实现;不把 JournalOnly 日志误当作业务上下文权威。Worker 工具沙箱与访问范围沿用现有方向,在执行端检查当前身份和 epoch。
测试:新增 `internal/runmgr/multi_instance_test.go`、`internal/store/lease_pg_test.go`、`internal/blobstore/object_store_test.go`;扩展 `internal/runmgr/recovery_test.go`。必须启动两个真实进程:同会话争抢、不同会话并行、跨实例取消/HITL、命令提交后消费前 owner 换代、旧 gate 的审批明确失效、Worker 被杀、旧 Worker 迟到结算/写事件/写文件、失联重连、副作用结果未知、文件缺失/重复发布。
出口:所有写入和工具副作用的失效 owner 处理有实证后,才允许第二实例承接写请求;故障状态可见,不能仅靠粘性路由。
### U6. 事件追赶与数据库向量检索
U6 内分三个交付切片,稳定工作包 ID 不变:事件追赶/重连修复依赖 U2,可与 U3 并行;事务 outbox 与投递闭环依赖 U5;向量 schema 与查询改造依赖 U2 迁移器及 U3 授权合同。对应 R5/R6/R9。
事件:修改 `internal/pgbus/pgbus.go`、`internal/runmgr/events.go`、`internal/server/server.go`、Store 事件接口。扩展 `internal/pgbus/pgbus_test.go`,新增 `internal/server/sse_gap_test.go`:批次 64 条全部可见、断线补齐、通知丢失、订阅与补查竞争、1000+ 分页、慢消费者、撤权后新事件拒绝。第一切片完成只证明追赶修复,不声称 KTD6 的事务 outbox 已就位。
向量:修改 `internal/store/vectors.go`、`internal/store/migrate.go` 与现有知识索引管线;新增 `internal/store/pgvector_test.go`。验证模型身份/维度隔离、内容更新/删除原子性、回填中重启、索引未完成可降级、中文全文混合、共享授权后 top-k、撤权、与精确检索 Recall@10 对照(建议≥0.95,待批准)。索引构建不得拖垮前台连接/IO。
出口:先验证正确与有界,再按容量结果决定 HNSW 与缓存;绝不以 extension 存在替代查询计划/召回证据。
### U7. 压测、故障验收与分布式放行
依赖 U2/U3/U4;双实例验收另依赖 U5/U6。对应全部 R。首期单实例放行必须完整重放现有入口的 R6 权限矩阵(含 SSE 后续事件、共享检索、下载、Host/工具与撤权),并证明 U3 恢复隔离;不能等 U5/U6 才验证这些 P0 要求。跨实例传播与接管的新增验证随 U5/U6。新增 Dev `tests/load/collaboration/` 与 `tests/integration/multi-instance/`,由隔离测试入口负责启动/回收自己创建的资源。
按第 3 节负载合同和第 7 节矩阵测量,记录原始 k6/pgbench、服务指标与数据不变量;pgbench 只测数据库能力,不能替代业务 API/SSE/Agent 验收。正式测试不打生产服务。
出口:单实例团队、双进程、双主机分别出具结果;CI 身份/链接/SHA 或独立 REPLAY 可核验才用于放行。本地 SELF 只能作辅助。变更智能体行为时补真实模型前后任务级对照。
远期 P2:需求达到后再拆 API/Worker/索引服务,按表归属收紧角色;引入 PG 高可用与自动故障转移、对象存储冗余、可选 PgBouncer。服务拆分与 DB 复制是两件事;Redis 集群、读副本和缓存不能替代主库一致性,读后写敏感路径保持主库读取或显式一致性令牌。
## 6. SQLite → PostgreSQL 切换和恢复
1. 固定源服务制品、全部数据库/文件路径与目标空库;指定迁移 owner、窗口、可接受中断和回退判据。先做只读盘点与隔离演练,不接触其他服务的数据。
2. 为 SQLite 做一致性备份(应用已有 Backup/VACUUM INTO 或官方备份路径),同时生成工件/checkpoint/工作区清单。活跃 WAL 数据库不能只复制 `.db` 文件;检查备份可打开且内容与清单匹配。
3. 预演使用独立测试目标 PG,由 migrator 建 schema/扩展,再按依赖顺序导入。显式保留 ID、幂等键、事件 seq、哈希/秘密、用户归属、共享范围、审批状态,调整序列值和类型。预演库不成为正式目标;所有副本遵守 KTD14。
4. 最终窗口暂停新写与调度,等待或安全收口在途 run;无法确认外部副作用的 run 写入 U3 的持久 recovery hold。停止全部旧写者后取最终一致性快照,导入新空正式目标;按 U4 的同快照迁移身份续传。全量对账与验收抽样完成并写入完成标记后才可切入口,保留只读源备份及过渡期权威文件。目标已服务或身份不同的非空库不得覆盖。
5. 仅一个入口切到 PG,检查版本/配置指纹、库身份与数据归属,执行用户登录、项目、会话、审批、检索、下载的冒烟;应用 fail-closed,不能故障后回 SQLite。原库不再写,不使用临时双写制造两个权威。
6. **PG 接受新写入前**可撤回切换,确认目标未产生业务写后恢复 SQLite。**PG 接受新写入后**禁止直接指回旧 SQLite;优先保留 PG 回退兼容应用或向前修复。确需反向迁移,重新冻结写者、导出 PG 增量、对账并批准专门回迁方案。
7. 建立 pg_dump 逻辑备份,以及 pg_basebackup(或等价物理基础备份)+ 连续 WAL 归档/PITR,并与对象存储版本/清单联合恢复;pg_dump 不能用作 WAL 回放的基础备份,保留足够不可变对象。每次演练恢复到新目标,核对应用可用与权限/文件完整性,不能把“备份命令成功”当作可恢复。
SQLite 本身支持可靠事务与多人经同一应用访问;WAL 提升读写并发,但同一数据库仍只有一个 writer,且不适合多主机通过网络文件系统共享 WAL。取舍基于写负载、进程拓扑、恢复与运维目标,不用“超过某人数 SQLite 就出错”的判断。[SQLite WAL 官方文档](https://sqlite.org/wal.html)。
## 7. 最小验收矩阵
| 场景 | 必须观察到的结果 | 对应 |
|---|---|---|
| 同 requestId 并发/网络超时后重试 | 一个逻辑请求和同一 run,不重做已经确认的副作用 | R3/U3/U5 |
| 两实例同会话不同请求 | 仅一个主执行;另一个排队或明确冲突,子代理不受错误唯一约束阻断 | R3/R4/U5 |
| 多项目并行、热点会话、满额度父子派生 | 公平、有界;等待父 run 不阻塞子 run 获得许可,所有任务能前进或得到有界拒绝 | R1/R8/U3/U7 |
| 并发修改同卡/设置 | 成功与冲突可辨认,无最后写入静默覆盖 | R3/U3 |
| 在 B 提交 A 所有 run 的取消/HITL,消费前换 owner | 命令持久、唯一消费;取消随逻辑 run 生效,HITL 重验 gate 版本,卡片与 run 最终一致 | R4/U5 |
| Worker 崩溃/暂停超过租约后恢复 | 新 owner 可受控接管;旧 epoch 不能提交;不明副作用不自动重放 | R4/R7/U5 |
| PG 断连/提交响应丢失 | 依赖不可用有界失败;恢复按幂等记录核对,不自动切 SQLite | R2/R3/U3 |
| Redis 断连/INCR 后崩溃 | 不改变业务事实;昂贵任务仍受硬预算;恢复无永久计数键错误 | R8/U3 |
| 批事件/断开 LISTEN/通知丢失 | 所有已提交事件按连续 cursor 追赶,重放不跳洞 | R5/U6 |
| 撤销成员权限/跨 owner 猜测 ID | 新请求、流后续事件与下载/检索/工具均不泄漏 | R6/U3/U5/U6 |
| 多模型向量/过滤后 top-k | 不混模型,权限正确,召回/延迟达批准阈值 | R9/U6 |
| 迁移崩溃/坏文件/未知 owner | 阻止切换;重试不重复导入,不隐式公开历史数据 | R7/U4 |
| 磁盘满/备份恢复/整机失效 | 清楚拒绝写入和报警;在约定故障模型与 RPO/RTO 下恢复 | R7/U4/U7 |
## 8. 工具、观测与交付
本轮未安装软件、修改配置、运行迁移、重启服务或压测。brew 已有三项服务软件,当前瓶颈主要是接线与一致性机制,暂不重复安装。未来压测可通过 [brew 安装 k6](https://formulae.brew.sh/formula/k6);PgBouncer 只在连接测量证明有必要后安装。安装授权不等于对共享数据库升级、创建扩展或变更服务的授权;执行前核对目标、版本与既有占用。
必需观测:API P95/P99与预期/非预期错误,DB pool wait/连接数/慢查询/锁等待,队列长度/最老年龄,run 租约/过期写拒绝/未知副作用,SSE cursor lag/补查次数,Redis 错误与降级,检索耗时/召回抽样,备份时间与恢复结果。日志只记录 request/run/owner 的安全标识,不记录 DSN、密钥或文档正文。
当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认;容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
首选下一增量是 **U1 + U2 的详细实施与测试合同**:固定目标实例与 PG 测试环境,解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行;不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA,再按 Dev 的 evidence/task-sync/组合验证流程交付。
@@ -0,0 +1,503 @@
---
title: RDM 最终目标核对、系统差距与完整交付方案
date: 2026-10-11
type: feat
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: legacy-requirements
---
# RDM 最终目标核对、系统差距与完整交付方案
修订 r1;负责人 weichen;编制 Codex;更新时间 2026-10-11(Asia/Shanghai)。
用户已明确最终实现范围:全部文档模板、文档三权、系统级项目及独立两树一网协作;本轮进一步要求先核对目标和差距、形成详细完整方案。
本总体方案待人工评审;业务实现、迁移、真实模型评测、浏览器验收、上线均 NOT_RUN。
本文件承担本次最终目标补齐的统筹记录;不替代 RDM 已批准需求正文。实施负责人按各工作包立项指定,不预设已有人承接。
下文 `RDM:` 为 Agent-System-RDM,`Dev:` 为 Agent-System-Dev,`Legacy:` 为旧 Agent-System 的仓内路径。
## Goal Capsule
让不同用户在同一个系统级项目内,用各自私有的对话和资料工作,通过有权限的项目知识协作,按模板完成全部体系文档的编制、审核、批准,并能追溯来源、版本、决策和验证结果。
采用 RDM 领域实现与基座通用能力组合:先接通项目、权限、资料和持久运行,再完成全部文档及三权、需求和合规链、项目生命周期与交付。
项目建议书、竞品分析仍作为第一条真实验证路径;**最终交付包含全部 69 类现有文档模板与现有报价 XLSX 资产的接入,不以两份试点或目录登记完成作为终点**。
每个项目可按自身适用性选择文档,但平台模板覆盖不能以“不适用”替代未实施。新增模板也必须沿同一发布、生成和验收契约接入。
本次三项关键口径已由用户明确,不再列为待决:系统内同名项目唯一;创建者在平台管理员上限内覆盖管理;个人聊天/原件/草稿私有,受控文档按三权及明确授权读取。
后续遇到模块职责、权限范围、外部集成或交付顺序重大改变时按 `Dev:policy/delivery.md` 回到受影响阶段评审。后移目标逐项保留,不能无记录地消失。
---
## Product Contract
### Authority and Confirmed Decisions
权威顺序:本轮用户明确指示和澄清 → 已批准 U0 D1–D9、V2.2 Q1–Q8/D10 裁定及权威正文 → 未被取代的既有定稿条款 → 原始会议材料 → 派生摘要/旧审计快照。
原始 ASR 与用户补充可用于查清意图;不能用旧会议草案反向覆盖较新的明确裁定。`.tmp` 原件保持不改,正式需求修订仍进入 RDM `docs/requirements/`。
`RDM:docs/requirements/README.md:15–21` 明确 01/02/03/04/08/09 已于 2026-10-09 合入定稿 V2.2;05/06/07/10 未重发,但解读服从新裁定。U0 页首 proposed、部分 V2.2 正文“待评审”等是残留状态文字,不能据此宣称需求未批准。
前一份模板生成方案对这些残留文字的判断在本次纠正;其具体实现建议依然是待评审方案。
| 编号 | 用户重申与最终口径 | 与最终设计的关系及依据 |
|---|---|---|
| D1 | 系统可有多个不同项目;同一名称只对应一个权威项目身份,用户加入后访问同一个项目 | 符合 UR-22、SR-G10;01:312、517;用户补充 S:50 |
| D2 | 创建者默认项目负责人,在平台管理员设置的范围和上限内管理成员、覆盖权限、分配每文档三权 | 符合 SR-G8/G9、U0 D2;用户设计意见 D:76;本轮再次确认 |
| D3 | 每项目有独立笔记树、文档树、追溯网;成员及其智能体通过授权后的项目知识协作 | 符合 SR-G11、SR-N4、08 数据模型;S:60–61 |
| D4 | 个人聊天、上传原件、个人草稿默认私有,受控文档只向三权人员与明确授权者开放,不自动全员共享 | 用户本轮明确确认;与 U0 D3 私域边界及 SR-C7 三权相容;SR-G12 的主动只读分享仍须明确授权 |
| D5 | 管理权不自动包含读取私人资料、发起代编、代审、代批 | 已批准 U0 D2、V2.2 A4;S:65–72;创建者也受职责分离约束 |
| D6 | 先项目建议书/竞品分析验证,最终扩展所有文档 | 上轮用户选择与本轮“所有文档加入并实现”;阶段顺序不缩减最终范围 |
S=`Dev:.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`;D=同目录 `user-design-ideas.txt`。原文 S:35–36 提出上限内覆盖,D:75–76 的直接用户意见收敛该选择;S:40–73 同时定义项目、私聊、共享知识和三权。
晚会原始 ASR(2026-10-08_19-36,00:37:00–00:37:21,正文段落 P329–P338)确认共同项目根,不能单独拿它证明私有权限;该部分依据以前述用户补充及本轮确认为准。
### Problem Frame
目前存在“基座界面里的用户项目”和“RDM 领域项目”两条没有完整贯通的路径。RDM 已实现项目表、部分权限计算和章节审签,但用户还无法通过统一界面完成研发项目管理及全部文档工作。
多份历史任务卡把局部领域方法、测试桩或直接处理器调用概括成阶段完成,掩盖了真实入口、授权、持久恢复、资料来源和部署组合的差距。
因此需要围绕最终用户路径重新映射证据、补齐已有实现,而不是从零重建或只补一页项目设置。
### Current State
本轮证据等级为 SELF:当前源码、测试资产、原始会议材料、只读进程构建元数据。未读业务数据库、未操作业务数据、未执行模型/业务测试。
调查基线:Dev `80a518628c526fd6ddece4abeb707ab4bb0b5618`;Backend `c8d66ca3cd21b055a8605e9eb4d8e525037618a6`;Frontend `3ed10e122042a64180fb24a42d9cc6438cd2d2d6`;RDM 初查 `0081628a10ec48a36537c6eced11a57439c986fa`,本轮期间项目授权改动合入后已增量复核至 **`d8d7e7436ca501e3ae03bbea9cc60405c74b9afc`**;RDM Backend pin `421fee81c314c05530bc809e224b5d0818ec3472`,Frontend pin `84b73ab32848e623d0a0ab7ade552784dca8cf3c`。
原始命令、固定对象和输出见 [调查收据](../records/2026-10-11-rdm-final-target-source-receipt.json)。源码基线不等于部署组合。
只读观察到 Dev `runtime/dev/bin/agent-system` 正运行 Backend c8d66ca 基座入口;另有较早、位于临时或已删除工作区的 RDM 进程。用户当前访问的 URL/实例尚未核对,不能据此直接判定其浏览器所见部署了哪个产品。正式验收须固定实例、端口、二进制摘要、组件 pins 和数据根;本轮不停止或清理这些进程。
| 差距 | 当前已有 | 尚未完成及影响 | 源码定位 |
|---|---|---|---|
| G1 项目入口 | Dev 有新建/切换/通用设置;RDM 有项目/成员命令 | Dev 创建走 owner 项目,无同名全局约束;未接研发成员/职责管理 | Dev frontend store.ts:286、ProjectSettingsModal.tsx:23;Backend store/projects.go:15 |
| G2 唯一身份 | RDM name UNIQUE、TrimSpace、创建者字段;新增一对一 HostBinding 与映射读取 | 绑定尚缺宿主项目存在性/绑定权限核验;成员不在 ListProjectsFor 目录中,页面仍首项/默认选择;新建与负责人写入非原子 | projects/projects.go:69、89;rdmapp/projects_api.go:23–87;web/app.js:98 起 |
| G3 权限覆盖 | 已有 cap∩override/default、12 动作;新增命令守卫,删除建项目自动引导管理员,改部署引导+单行约束 | cap 管理仍认 RDM 台账,平台管理员可信接入未完成;专业角色/资源策略不足;doc.write 不等于编制职责;超管槽未接 | perms/perms.go:18–60、112、172、302;perms_api.go 的 AuthorizeCmd;runtime.go:172 起 |
| G4 私域与协作 | 私有会话 owner 边界;RDM 禁止上传预索引/会话卡镜像 | EXT-8 项目布尔授权会放大到整项目工件,无法区分原件/发布快照;Host 仍 owner-only;成员上传、发布、检索不一致 | plugin.go:31;runtime.go:136;Dev server.go:1134、1199;RDM pin hostcaps.go:219 |
| G5 两树项目分片 | WorldFor、项目事件重放;主要命令新增非空项目/动作守卫,图走审计权限,上传台账按项目过滤 | rdm.init 仍可进入全量自举写路径;仍需全入口与对象归属验证;业务读/导出与审计读须分开,原件不能仅按项目过滤 | runtime.go:81–117;plugin.go:850、879;init.go:39、52;upload.go 的 UploadsList |
| G6 文档三权 | 章节角色异人、锁定、全员审核、正式链;生成已有通用动作权限检查 | 非文档级;指派对象未核有效账号/成员;通用 doc.write 未收紧到指定编制人;审签 schema 与可信 actor 处理仍矛盾 | domain/review.go:31、69;plugin.go 的 review 规格、rdmDraftCompose/Apply |
| G7 模板覆盖 | 69 种 docType;旧 69 Markdown+1 XLSX;当前 4 模板 | 仅覆盖 3 类;首项模板误选、模板可静默缺失;结构/格式/版本未统一 | 模板盘点与生成子方案 G1–G10 |
| G8 对话生成 | Compose 实际调用模型;Draft/Apply 存在;UI 新增领域项目注入与绑定尝试 | intent 类型键错误、未投影工具;缺持久提案/整文版本;旧依据可能丢失;独立页面普通文本 cmd=null 后 startsWith 仍在 | compose.go、draft.go、plugin.go 的编写 intent/compose 规格;web/app.js:410–448 |
| G9 解析与锚点 | 原件保留、md/txt/docx、部分表格/标题锚点 | 未接 ParseDocument;PDF/表格/演示文稿/图片未完整消费;慢切片改 slow:batch 丢原定位 | parse.go:33、346;slow.go:267 |
| G10 统一摄取 | 上传相关性三态、纯文本公共入库终点、发布方法 | 普通 ingest 可绕过相关性;发布未带 ProjectID,失败无持久补偿;上传非空摘要占位跳过真实摘要;聊天自动沉淀未接 | ingest.go:89、122;upload.go:406–409;llm_summary.go:20 |
| G11 结论与冲突 | 结论提议/确认、词面冲突检测、supersedes;拒绝提议已校验所属项目 | 确认提议仍按 id 查询未限定项目;固定阈值且已有结论后不再触发;无完整候选组/两层裁决;Resolve 可误关其他争议 | conclusions.go:125–135、264、310;domain/fc/collide.go:35、125 |
| G12 需求与合规 | UR/SR 台账;15 节点/11 边、四视图、八规则、矩阵/导出 | 六维/父子分解不足;受控节点和边写方法无生产调用;只有读命令,缺真实业务生产者 | requirements.go:21;compliance.go:155;plugin cgraph commands |
| G13 法规双通道 | 知识检索与法规声明记录 | “网络通道”用 Complete 生成 URL JSON,无实际搜索/抓取;不能作为独立网络核验 | regcheck.go:35、58–72 |
| G14 阶段与完整性 | 部分素材数/待确认文字检查 | 项目无阶段状态;缺推进/结项用户路径;审核提交未接内容/合规缺口门禁 | projects/projects.go:17;baseline.go:82;review.go |
| G15 长任务 | 内存队列、慢任务台账、重启标 failed | 不保存恢复所需项目/owner/原输入;不能续跑;通用快慢任务与取消恢复未闭合 | slowledger.go:31–43、74–77;slow.go |
| G16 看板与影响 | 职责/编制状态/正文变化投影 | 来源变了而正文未变时看板无法反映;缺影响对象、责任人、解决状态的闭环 | kanban.go:26、67;todo.go |
| G17 版本导出 | DOCX/XLSX 代码和测试 | 未按模板渲染格式、未绑定整文批准快照;合规导出正文为当前图却展示最新快照 hash | docx.go:155、298;cgraph_export.go:114 |
| G18 团队部署与执行 | 基座 PG/Redis、预算与动作矩阵;RDM 执行硬关闭 | RDM 领域仍 SQLite;动作矩阵公开接线不足;隔离执行尚未替代禁用;缺真实 RDM 双实例与备份恢复 | RDM domain/store/store.go:21、main.go:188;Dev server.go:90 |
| G19 完成证据 | 单测、桩 E2E、历史任务卡与 smoke | 真实三用户/两项目/模型/浏览器/安装包验收缺项;历史广义完成声明不能覆盖实际缺口 | v01_e2e_test.go:28、61、99、120;selfhost.go:130 |
“部分已有”表示可复用,绝不表示运行通过;“未接通”也不应改写为“所有组件都没有”。
RDM 数据库名唯一仅证明该源码对单数据库的精确字符串约束,尚未核实部署旧库索引;多数据库、多实例及名称规范化另需验收。
本轮新增实现来自 RDM 项目授权 #195/#196 的提交;上传来源项目解析、批次授权及结论拒绝的项目约束也已补入。未受此次改动影响的解析、模板、语义检索、任务恢复和合规生产缺口继续有效。U2/U3 必须复用这些新能力并补闭环,不能重复建设。
当前最高优先级之一是宿主绑定的双向权限:仅证明“我是 RDM 项目创建者”不足以绑定一个任意宿主项目。绑定前必须在宿主核验真实项目身份及调用者管理/绑定资格,并在服务端绑定可信上下文;否则已有共享读回调会扩大到不属于该主体的宿主资料。
绑定管理不能复用只读 AuthorizeAudit(当前 canManageBinding 的回落会在未来超管接线后扩大写权)。同理,合法三权人员查看/导出自己的文档不应要求其具备整个项目审计权限;当前 doc.export 的审计守卫需要按业务资源重新分类。
### Requirements and Acceptance
完整逐条索引见 [34 UR/68 SR/10 F 对照矩阵](../records/2026-10-11-rdm-final-target-requirements-matrix.md)。下表以 R-ID 固定本次设计不变量,保留原 UR/SR 作为正式需求身份。
| ID | 必须成立的最终行为 | 可判定验收 |
|---|---|---|
| R1 | 同系统项目名称与身份全局唯一 | 不同用户并发创建同名只有一个成功;加入成员看到同一 projectId;不存在按用户复制 |
| R2 | 上限内覆盖权限,并在执行端生效 | 撤销上限后旧 override 立即不生效;页面/API/命令/工具/任务恢复均拒绝越界 |
| R3 | 创建者可管理项目成员与每文档职责 | 项目负责人完成分配;平台全局权限不因建项目增加;职责对象必须有效且是成员 |
| R4 | 私聊/原件/草稿私有,受控文档按职责或明确授权读取 | 同项目其他成员无法通过正文、计数、搜索、摘要、预览、下载、追溯、模型输出读取未授权内容 |
| R5 | 每项目两树一网独立且内部按权限协作 | A 项目成员/智能体可使用 A 的发布知识,不能读取 B 项目或 A 的私有原文 |
| R6 | 全部现有文档类型可用,模板发布后结构/格式固定 | 69 类逐份有发布模板和真实生成验收;报价 XLSX 独立验收;项目不适用不减少平台覆盖 |
| R7 | 原件、解析、锚点、标签、知识发布可解释且可恢复 | 多格式能力分档声明;失败原件可取回;慢处理不丢页表锚点;存疑/拒绝不进共享检索 |
| R8 | 结论、冲突、依据选择受控 | 新资料可触发结论更新;文档层选择不改变项目全局结论;裁决只关闭指定争议 |
| R9 | 对话生成整文可修改可恢复,采纳才生效 | 模板与输入版本固定;无依据不编造;旧引用不丢;重复提交不重复写;部分采纳后整文仍一致 |
| R10 | 文档三权完整执行 | 编制一人、批准一人、审核至少一人且互异;审核/批准不可改正文;提交锁定,全员审核后才能批准 |
| R11 | 文档/需求/验证/风险/合规链真实生产和历史可重建 | 业务操作产生版本节点与候选边,人确认生效;导出内容/哈希/批准快照一致;无伪造验证结论 |
| R12 | 项目有阶段、准入准出和结项 | 仅在提交审核/申请推进时执行正式缺项门禁;不合格不能推进;按固定快照决策并可追溯 |
| R13 | 对话、卡片、工作区为同一对象的入口 | 右栏收起仍能完成任务;刷新/重启不丢;过期卡片不生效;不以假数据替代真实产物 |
| R14 | 团队运行具备当前授权、事务一致、恢复和隔离执行 | 两项目多人并行、撤权、故障注入、备份恢复通过;禁执行仅为过渡,最终隔离后按策略开放 |
| R15 | 全部已批准目标有去向和真实证据 | 34 UR/68 SR/10 F 无漏项;实现、测试、部署分别登记,只有显式裁决可取消目标 |
### Scope and Completion Levels
核心完整交付 C1:U1–U14 加 U16,覆盖项目/权限、私域与协同、全部模板、三权、资料、知识、需求合规、生命周期及团队可用性。
最终扩展交付 C2:U15 的 F-01…F-10 各项完成或经用户明确裁定取消/替代;外部系统接入受凭据、平台授权与独立交付条件约束。
**C1 通过不能写成所有最终目标完成。** C2 未完成的目标保留在同一矩阵,不将“后移”改成永久非目标。F-09 已有较新两树一网展示方案,应并入 U11/U14,而不继续沿用早期延期状态。
完整方案不意味在一个大 PR 同时改完;按依赖交付,每阶段保留可回退、可独立验收的增量。
---
## Planning Contract
### KTD1. One Project Identity
推荐继续由 RDM 保存研发项目、成员、职责权威;基座提供共享项目上下文及私有会话/工件能力。用户看到的是**一个系统级项目**,宿主内部 ID 只作一对一技术映射,不能再产生每用户一个同名研发项目。
对照备选:把研发项目权威搬入基座需重新划分领域职责,成本更大;为每位成员复制基座项目会破坏唯一身份与追溯,不采用。
统一入口的创建/改名/归档均调用项目应用服务。RDM 产品界面不再暴露绕过该服务的独立“个人研发项目”创建路径;通用基座个人项目保留为基座模式能力,不混入 RDM 项目目录。
复用新合入的 HostBinding 表与命令,补宿主端存在性、绑定资格和实例域校验;不能仅凭 RDM 创建者权限接受任意 hostProjectId。项目目录分为成员工作目录与受限审计目录:普通成员必须看到加入的项目,但不因看见项目获得审计权。
项目对象包含稳定 ID、名称与规范化键、创建者、生命周期、权限策略版本、文档目录版本及宿主绑定。建议名称规则为去首尾空白、Unicode 规范化、拉丁字符大小写归一;展示原名,规范化键由数据库唯一约束保护。规则在迁移前用现有名称干跑确认,冲突由人裁定,禁止静默合并。
归档保留名称与身份;删除采用受控归档/软删除,不让新项目复用同名后被误认成旧项目。名称变更的历史同样留存。
成员可见同一项目不等于全系统用户可列出所有项目;未加入者的同名创建返回名称不可用,不泄漏成员、内容或审计。
RDM 项目+创建者成员角色+名称保留在同库事务建立;跨库宿主绑定采用幂等 provisioning→ready/failed 与可恢复补偿。绑定未完成显示初始化状态,禁止继续向默认项目写入。
业务只接受服务端从当前会话/对象解析的项目;客户端 projectId 是定位符,跨项目参数或不一致绑定拒绝。外部旧命令的空项目全量回退关闭;未归属历史仅受信迁移工具可访问。
### KTD2. Policy and Duties
普通业务动作的允许条件为:有效账号与项目成员身份 ∧ 平台上限 ∧ 项目 override(未设置则角色默认)∧ 资源可见范围 ∧ 适用阶段/状态 ∧ 操作所需文档职责。
“显式拒绝”优先;平台上限收紧不需逐一改旧 override 才生效。多角色合并仍受同一上限,冲突按显式拒绝收敛,不依靠前端按钮控制。
平台管理员维护角色、默认权限、可覆盖上限及受管配置;项目创建者/负责人只调整项目内范围。支持专业角色目录,但编制/审核/批准是**文档职责**,不等同于“工程师角色”或广义 doc.write。
项目创建不得触发管理员引导;管理员初始化与移交走受信管理入口和事务唯一约束。既有“双层管理员”裁定用于审计可见性,不自动扩大成私人内容阅读或三权签字豁免。
CreatedBy 固定记录创建事实;负责人变更另有显式委任/接替记录,不重写创建事实。任何接替均不能跨过管理员上限。
权限、成员与职责变更写入审计并递增 policy/duty 版本;长任务开始、敏感读取、恢复、结果投递、提交、下载都重验。前端撤按钮不足以撤权。
### KTD3. Private Data and Shared Knowledge
| 资源 | 默认读者 | 共享/派生规则 |
|---|---|---|
| 个人会话、Agent 中间过程 | 本人 | 不自动镜像项目流;他人模型也不能间接读取 |
| 上传原件、个人草稿 | 本人 | 文件分享只产生明确的只读授权;不因 projectId 相同开放 |
| 项目发布知识快照 | 被授权项目成员 | 原件作者明确将选定内容发布为项目知识;可检索内容与原件权限分离,保留来源/发布版本 |
| 受控文档正文与修订 | 指定三权人员及明确获授权者 | 角色授权随职责/状态校验;全员只读必须明确授予,不默认开放 |
| 文档树目录、状态、待办 | 按所需最小范围 | 不通过标题、摘要、计数或引用暴露无权文档;负责人可管理职责元数据不代表可读全文 |
| 项目审计中心 | 按已有创建者/管理员审计方案 | 私人原文、秘密和隐藏推理仍不直接出现在审计 DTO/导出 |
两树一网在项目内共享其业务知识和组织结构,**不等于每个节点的所有载荷对所有成员可见**。文档树仍保存要求+正文版本(Q8),正文节点继承文档 ACL;追溯遍历使用受限投影,不直接返回内部 payload。
明确“提交为项目资料”只发布选定知识内容;保留的原文件仍可私人。普通上传不自动发布全文,混合/存疑材料先确认。资料作者可发布脱敏摘要/摘录并保留批准的发布快照,使其他成员能使用该快照而无需读取私人原件。
审核所需依据应提供职责范围内的证据包:可读发布快照、明确原件授权或经确认的脱敏材料;仅有无权访问的私人引用时不能宣称证据已可核验。文档存储了私人资料的事实也属于披露,提交前必须处理发布授权。
撤销原件分享立即停止新访问与上下文注入;已经明确发布的知识快照按其独立发布生命周期处理,不把撤销文件链接误当成回收所有已批准知识。撤回发布知识时停止新使用,标记依赖文档 stale;历史受控快照的保留与可读性分别受记录保全及当前授权控制。
所有 HTTP、Host、索引/检索、卡片/SSE、预览下载、导出、图查询采用同一资源级决策;授权参数包含主体、项目、动作、资源类型/ID/版本、policyVersion。只读布尔项目授权无法表达这些边界,不因补齐项目 ID 就直接开放全项目工件。
### KTD4. Transaction and History Foundation
复用现有两树一网方案的原子事件、幂等、历史重建和 outbox,不再另造第二套事件中心。
在领域事务内完成预期版本校验、写台账、事件批次及幂等结果;提交后更新投影。跨宿主存储操作通过幂等步骤与 outbox,提交未知时先查结果再重试。
历史对象为 ID@version,切片原文与历史版本不可变;结构删改用软删除/取代/新事件。普通哈希用于一致性检查,不宣称具备外部防篡改或电子签名保证。
部分更新、角色调整、关系变化、合规 stale 标记与重放对等;同一历史水位必须还原同一文档/图/职责/审批事实,未知事件版本不得静默忽略。
旧数据先盘点归属及 ACL。旧 Agent-System 业务数据仍按 O9 不迁移;旧模板内容属于可复用资产,当前 RDM 数据必须保全,二者不得混淆。
### KTD5. Source-to-Knowledge Pipeline
统一上传、明确发布的对话内容、会议和外部研究的摄取契约:来源对象→私域留档→解析状态→相关性/发布决策→带锚点切片/标签→知识快照/索引→冲突与结论候选。
接入基座公开 ParseDocument,按原件保全、文本、表格、OCR、图像描述、页表锚点逐档标能力;不支持时留原件并明确说明,不把“收到了文件”当作“完整理解了内容”。
锚点使用 sourceId@version+页/表/段/偏移;快慢处理沿同一解析块精化,不把锚点替换成不可回跳的 slow:batch。chunk 与 slice 是显式多对多映射。
共享标签字典版本化,记忆侧描述标签与文档章节需求条件同源;已确认强制材料/旧有效依据不能被 topK 静默挤掉。自动分类及摘要用独立人工金标验证,不以同源样本给自己评分。
知识发布失败留下可重试任务,不静默计零后报全部入库成功。待裁定、拒绝、撤回的资料不进入共享检索;原件取回与上传台账同样鉴权。
### KTD6. Conclusions, Conflicts and Impact
结论必须绑定依据和材料水位,允许随着新内容提出新结论;模型决定是否足够形成有价值总结,冷却只控制通知频率,不能让“已有结论”永久阻止更新。
会议纪要结构化抽取结论/待办/待确认,各条带原发言或资料锚点。模型提炼不等于已批准项目事实;采纳由人完成,结果回两树一网。
冲突对象使用明确 conflictId/groupId 和候选版本。相似度只提供检测线索,不能充当语义矛盾的证据;保留双方陈述、出处、影响与建议。
文档层裁决选择本文档的依据;项目层裁决改变项目有效结论,由负责人或明确指定知识责任人完成。只关闭该争议,不把两个节点参与的其他争议一起关闭。
来源、需求、测试结果或规则变化产生影响清单,指向受影响文档和负责人;正文未改变也要显示“依据有更新/验证过期”。看板与收件箱被动汇聚,对话按任务节点集中处理,不频繁插话。
### KTD7. All Templates and Controlled Documents
复用 [模板对话生成子方案](2026-10-11-rdm-template-dialog-generation.md) 的模板元数据、结构、检索条件、格式和发布清单,以及 Run/ContextManifest/Proposal/DocumentRevision 设计。
完整模板台账覆盖 [69 类旧资产](../records/2026-10-11-rdm-template-inventory.md) 与报价 XLSX。逐份保留来源 SHA,拆分内容要求、格式约束和管理记录;去除旧“任务键=模板文件名”绑定。
模板按用途区分正文、纪要、汇报,绑定明确默认;缺模板或版本失效时拒绝“按模板生成”路径,不静默用自由文本代替。v10/v2 使用正式版本语义,不按字典序。
首批两模板先验证闭环,随后按资产台账完整迁入。每份上线模板均需有材料的成功样本及空缺/冲突反例;不能仅通过注册表计数宣称 69 类可用。
模板目录是组织资产,项目实例按适用性选择,但全部类型保持可配置可用。标准模板由用户后续提供(F-10),导入需差异评审及版本迁移;用户没有提供的标准模板不伪称已经替换。
三权面向每份文档:编制唯一、批准唯一、审核可多人且至少一人;三者互异。所有审核人通过后才可批准;审核/批准只能批注和通过/驳回,不改正文、不发起生成。
新文档无职责时任务停在可见“等待分配”,负责人可通过对话或管理页分配;其他成员可转交最小编制请求,不能转发其私人聊天全文。负责人可在上限内给自己分配其中一种职责,但不能同时兼任冲突职责。
提交冻结整文版本、模板、依据、职责与策略版本。职责变更、成员撤销或正文变动使受影响的待审决定失效;不能先让本人编制,再改职责给本人审核/批准同一提交版本。历史职责/操作身份参与分离校验,角色改名不洗掉已执行事实。
生成、人工修改、导入、旧命令、直接状态迁移必须经过同一编制与版本服务,不能从旧入口绕过。
旧章节职责和签署作为历史保留,不能拼成“整文已批准”;启用文档级流程前明确职责并处理旧活动审签,首个整文正式版本重新审签。驳回只增加内部修订,终批才产生新正式版并建立取代关系。
实际采纳的新旧章节组合须重新验依赖、术语、指标一致性;确认绑定该组合 hash,事务前重验版本。版本+引用/追溯+提案状态+领域事件全成或全败。
### KTD8. Requirements and Compliance Producers
复用已有 15 类受控节点、11 类边、四链视图、八完整性规则、快照、矩阵和导出器;补真实业务生产者及写入/确认入口。
需求台账支持批准基线要求的 UR/PR/SWR/HWR 等类型、父子分解及六维分类;保留原 UR/SR 编号兼容映射。用户需求先确认后分解,法规反推产生候选,不直接替人定需求。
设计、风险、风险控制、测试计划/执行结果、验证、确认、设计转换、SOUP 等对象通过各自业务动作产生版本节点;字符串 LinkedSections/LinkedTests 迁为受控版本边,映射歧义保留待处理。
模型只推荐合规关系,授权人确认转正;目标升版标 stale,不自动转移旧签名/旧验证结论。验证结果必须关联实际被测版本、执行者与证据文件;没有实际结果时仅可生成计划、空表或 NOT_RUN 草稿。
法规双通道必须是受控知识库+真实联网搜索/抓取的独立证据,保存 URL、取得时间、文档版本、片段锚点与可复核快照。模型生成 URL 不算网络核验;失败清楚标单通道/未核实。
本方案使用项目已批准的合规数据模型,不作具体标准符合性认定。专家校准负责规则、链视图与交付格式,保留意见来源及版本;不以数据结构存在代替合规验收。
### KTD9. Lifecycle, UI and Agent Execution
项目阶段配置、文档适用目录与准入准出规则版本化;当前字典为既有种子基线,关于进一步阶段合并的旧未裁定意见不擅自生效。
提交审核和申请推进时执行模板内容要求、缺项、职责、冲突、合规完整性门禁;有材料不等于满足要求,所有候选边也不等于冲突。可接受的不适用必须说明理由并由有权者确认。
阶段推进/回退/结项记录固定对象集合、规则和决策;外部完整变更引擎在 F-02 交付前,当前保留撤回重审、冲突和影响提示,不能直接改批准基线。
沿三栏工作台:左侧统一项目及私有会话;项目管理承载成员/权限/文档职责/阶段;工作区承载树、文档、追溯与看板;右侧工作/文件用于待办和唯一预览。对话与这些入口访问同一服务。
所有业务操作均可经自然语言准备并在必要节点显式确认。查询/总结不触发写入;模糊“继续”只作用于已展示且未过期的请求。工具说明渐进注入,RDM 编制/审阅配方作为产品资产,内核保持通用。
执行自由度遵 Q7/D10:检索、解析、归纳、候选生成可自主;三权、基线、正文生效和合规边确认受确定性门禁约束。模型不能自签或借工具权限继承管理员能力。
### KTD10. Durable Jobs, Storage and Deployment
Run/Step 保存发起主体、项目、输入引用、模板/提示词版本、检查点、水位、幂等键和恢复状态;模型调用不持数据库长事务。取消、审批与恢复针对同一持久对象,权限变化后拒绝续跑或投递。
重启仅标 failed 是可观察失败,不是任务恢复。最终必须能安全续跑,或对未知副作用停在需人工确认的恢复状态;禁止无条件重放。
复用多人存储方案已有工作:团队 PostgreSQL 为权威、Redis 可丢失、预算可配置、单实例先行。RDM 领域库、原件、知识发布、任务与检查点必须显式纳入迁移/备份,不能只设置 Backend PG DSN。
多实例验收包括领域唯一性、事务、数据库发号、运行 owner/epoch、队列领取、事件追赶和共享工件;两个 dataDir 的宿主 smoke 不证明 RDM 多实例写入一致。
多人隔离前继续硬禁高风险代码执行;最终交付隔离执行后端、目录/网络/资源约束和受控开放,符合 SR-G16,不以永久禁用替代能力。
发布包必须包含 RDM 插件接线、模板/字典/提示词资产和明确组件清单;离开源码目录仍可启动。部署另设固定环境与授权,安装、升级、备份、恢复、回滚均有可执行操作说明与演练证据。
### High-Level Technical Design
```mermaid
flowchart TB
P[平台账号与角色上限] --> A[统一动作与资源授权]
C[系统级项目目录和成员] --> A
U[各用户私有会话 原件 草稿] --> A
A --> K[明确发布的项目知识快照]
K --> N[项目笔记树]
T[已发布模板及文档职责] --> D[项目文档树 要求和版本]
N --> G[项目追溯网 依据 决策 影响]
D --> G
A --> R[持久任务与提案]
N --> R
D --> R
G --> R
R --> H[编制确认 审核 批准]
H --> V[固定整文及合规快照]
V --> X[DOCX XLSX 可审计导出]
```
```mermaid
sequenceDiagram
participant U as 编制人
participant S as 领域应用服务
participant J as 持久任务
participant D as 领域存储
participant R as 审核和批准人员
U->>S: 项目内编制请求
S->>S: 当前权限 职责 资源检查
S->>J: 固定模板 输入和目标版本
J-->>U: 进度 持久提案 差异
U->>S: 采纳固定提案
S->>D: 事务提交版本 依据 追溯
U->>S: 提交审核
S->>D: 完整性门禁并冻结整文
R->>S: 当前身份审签固定快照
S->>D: 正式版及批准记录
S-->>U: 可预览下载的固定版本
```
```mermaid
stateDiagram-v2
[*] --> Provisioning
Provisioning --> Active: 项目和绑定均就绪
Provisioning --> Recovery: 初始化失败
Recovery --> Provisioning: 幂等恢复
Active --> StageReview: 申请推进
StageReview --> Active: 通过并进入下一阶段
StageReview --> Active: 驳回维持原阶段
Active --> Closing: 申请结项
Closing --> Archived: 准出与确认通过
```
文档状态独立为编制中→审核中→待批准→已批准;驳回回编制中,新版本获批才取代旧正式版。任务运行、文档审批与项目阶段不能合并成一个“完成”标记。
### Public Contracts and Existing Plans
| 契约组 | 场景与公开面候选 | 现有缺口及兼容方式 |
|---|---|---|
| X1 项目绑定和生命周期 | RDM 项目服务与 Host 项目上下文创建/解析/成员目录 | 现有个人项目 CRUD 无统一约束;新增可选插件适配,RDM 启用时所有入口走同一服务;通用基座模式不被偷换 |
| X2 资源动作授权 | 身份+项目+action+resourceRef+version;HTTP/Host/检索/下载同判定 | EXT-8 只读 bool 太粗;动作矩阵尚非完整公开生产接线;版本化扩展、默认拒绝,旧读取适配器不获得写权 |
| X3 资料发布与解析 | 原件保全、ParseDocument、知识发布/撤销、chunk 映射 | 部分能力已在基座;RDM 逐项采纳并组合验证,缺失能力才申请新面 |
| X4 持久任务和恢复 | 受限 Host 工厂、Run/Step、取消/确认/状态事件 | 复用现有能力及团队存储路线,RDM 不保存旧 Host 凭据,不创建第二套账号 |
| X5 工件和外部证据 | 固定文档/图快照导出、artifact 绑定、真实 web search/fetch | 输出引用不等于实际文件/网络证据;受控任务产物与可核验抓取结果走公开面 |
每个缺失扩展按 RDM AGENTS 的场景、期望符号/路径、现有组合不足原因、兼容方式四要素申请;不导入 Backend internal,不修改 RDM pins 内实现。
与 [两树一网方案](2026-10-11-rdm-two-trees-trace-audit-integration.md) 共用项目绑定/授权、事务历史和审计展示;与 [多人存储方案](2026-10-11-collaboration-storage-and-distribution.md) 共用 PG、运行所有权、预算、恢复和隔离;模板子方案为 U7/U8 的详细设计输入。
在途核对:本轮远端查询 Dev #337 为存储迁移工具/恢复操作说明组合,#336 为 Generative UI U2,#317 为启动检查;不能把它们的未合入能力计入当前基线,也不重复立项。RDM 新增 `docs/proposals/2026-10-11-u1-base-extension-requests.md` 已提出平台身份能力与可信当前项目两项扩展,X1/X2 应承接该申请而不是再写第二份。正式立项时再次刷新在途状态。
原 [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) 的历史进度保留,新补齐顺序批准后回填该案及 RDM requirements/10,不制造多份互相覆盖的“最终状态”。旧广义完成声明只保留为历史记录,另做需求→证据重新映射,不改写其原始收据。
---
## Implementation Units
优先级 P0 为核心安全/正确性与用户路径,P1 为完整核心交付,P2 为外部扩展;P1/P2 不表示可永久省略。责任为仓/模块,具体 owner 在立项时明确。
依赖顺序:U1→U2→U3;U4 与 U7 可在各自契约固定后并行;U9→U5→U6,同时 U5→U12 真实法规双通道;U7 的首批模板和 U12 就绪→U8 首批闭环→U16 全文档族推广;U8/U11 汇合到 U10(经 U8 已包含 U12);U13 与业务开发并行收敛,最后 U14;U15 按子目标独立立项。
| 单元 | 交付主题 | 主要范围 | 前置 |
|---|---|---|---|
| U1 | 需求、证据和组合契约 | Documents/RDM requirements 与 pins 清单 | 无 |
| U2 | 系统级项目与管理入口 | RDM projects/members、基座项目适配、Frontend | U1 |
| U3 | 权限上限、私域与资源授权 | RDM perms、基座资源/Host/检索边界 | U2 |
| U4 | 原子事件、历史和旧数据归属 | RDM domain/store/eventlog/replay | U1、U2 契约 |
| U5 | 完整资料摄取与检索 | upload/parse/ingest/fbhost | U3、U4、U9 |
| U6 | 结论、冲突、两层裁决与影响 | conclusions/fc/kanban | U5 |
| U7 | 全资产台账与首批模板契约 | templates/structure、资产 bundle | U1 |
| U8 | 整文生成、三权和版本导出 | compose/draft/review/docx | U3、U4、U5、U6、U7、U9、U12 |
| U16 | 全部文档族迁移和真实验收 | 69 模板及 XLSX、契约与样本 | U8 |
| U9 | 持久快慢任务与对话入口 | RDM jobs/plugin、基座运行/卡片、UI | U3、U4 |
| U10 | 项目阶段、缺项门禁与结项 | projects/baseline/review | U8、U11 |
| U11 | 需求/风险/验证/合规生产闭环 | requirements/compliance/chainviews/exports | U3、U4、U6 |
| U12 | 真实外部研究与法规双通道 | regcheck、公开检索/抓取能力 | U3、U5、U9 |
| U13 | 团队存储、隔离执行和运行恢复 | RDM store、Backend/Squad/Native、发布包 | U1、U4、U9 |
| U14 | 全量验收、自举和用户上线 | 测试、CI、部署/恢复资料 | U1–U13、U16 |
| U15 | 最终后续目标逐项实现 | F-01…F-10 责任模块 | 各子项按下表 |
### U1. Baseline and Evidence Reconciliation
覆盖 R15。统一 34 UR、68 SR、10 F 的解释,明确本轮 D1–D6;修正文档状态漂移及历史测试覆盖映射,固定实际 RDM/Backend/Frontend/UI/Native/Squad 组合。
文件:RDM requirements/README、01/03/04/08/09/10、U0/V2.2 主记录;Dev proposals/INDEX 与扩展申请;新增需求证据矩阵(本轮候选已给出)。
方法:先评审来源和范围,再按最小契约申请/采纳 X1–X5;已有能力只补接线,不重新立项重写。U1 保留在途 PR 及 owner、版本和接受条件。
验收:全部原编号各有最终行为/工作包/测试入口;没有历史 PASS 自动变成当前 PASS;被覆盖的旧表述有指向当前解释的入口。
### U2. System Project and Management
覆盖 R1/R3/R5。交付创建/改名/归档、授权目录、成员加入/移除、创建者管理、宿主绑定及用户可用项目管理页面/对话路径。
文件:RDM internal/projects/projects.go、internal/members/members.go、rdmapp/projects_api.go、runtime.go、plugins/rdm/plugin.go;Backend store/projects.go/server 项目入口/公开适配;Frontend TaskSidebar/ProjectSettings 与 RDM 工作区。
测试:扩展 projects_test.go、成员测试及新合入 u1_auth/u1_surface 用例;新增项目绑定和浏览器流程用例。两用户同名并发、规范化碰撞、改名碰撞、归档、创建者角色写失败、宿主绑定失败重试、绑定他人宿主项目拒绝、成员加入后同 ID 可见、非成员目录及默认项目回退拒绝。
出口:真实用户可用统一研发项目管理;测试不能直接向数据库播种一个“已经绑定”的项目绕过创建路径。
### U3. Policy, Resource Access and Privacy
覆盖 R2/R3/R4/R5/R10。完成专业角色默认/上限/覆盖、文档职责分配授权、资源级读写策略与即时撤权;交付 X2 公开契约和全部生产入口接线。
文件:RDM perms、perms_api.go、sharing.go(实际路径在实施时核对)、upload 台账/确认、plugin 守卫;Backend extension、server、hostcaps、retriever、cardsvc;新增 resource_authz_test.go、隐私浏览器用例。
测试:上限拒绝覆盖、撤上限后旧许可失效、无效/停用/非成员职责指派拒绝;同项目私聊/原件/草稿、关键词/计数/摘要/导出不泄漏;职责读取与明确分享允许;普通三权人员可合法导出本文档而无全项目审计权;审计读取许可不能变绑定写权;撤权后 SSE/模型结果/下载立即拒绝;建项目不成为管理员。
出口:原件私有且项目发布知识可被其他成员合法检索;HTTP 与 Host 行为一致,不出现“页面可读但模型不可读”或反向泄漏。
### U4. Atomic Domain and History
覆盖 R5/R8/R9/R10/R11/R14。将多事件操作、台账、幂等和 outbox 收入单一领域事务,修复投影先写、重放不对等与历史快照不完整。
文件:RDM domain/eventlog.go、replay.go、payloads.go、store、doctree.go、tracenet.go、compliance.go;新增 transaction_fault_test.go/history_replay_test.go、迁移映射清单。
测试:在版本、建边、职责记录、快照阶段注入失败;提交全成/全败,重试唯一;跨项目边拒绝;同水位重启前后对象/签署/stale 相同;未知事件拒绝;遗留空项目只读隔离且不自动归属。
出口:真实持久库故障证明一致性;授权不明历史留待裁定,不以清空数据修复测试。
### U5. Ingestion, Parsing and Retrieval
覆盖 R4/R5/R7。统一原件、上传对象、相关性、发布、解析锚点、标签、知识索引与补偿;消费公开 ParseDocument。
文件:RDM upload.go、parse.go、ingest.go、relevance.go、llm_summary.go、fbhost/adapter.go;公开能力差距经 Backend 扩展;测试 upload/parse/publish_consumption,新增 anchor_roundtrip_test.go。
测试:PDF/Word/Excel/PPT/图片与文本各能力档、重名重传、损坏/大文件/解析中断、表格宽列、部分成功、私有和待裁定不发布、确认重试不重入、慢处理保留页表位置、发布失败重试、跨项目检索负例。
出口:真实素材的原文→切片→检索→引用可回跳;性能按已批准 SR-N1 的样本规模协议测量,不用空文件证明时限。
### U6. Knowledge, Decisions and Notifications
覆盖 R5/R8/R11/R13。结论水位更新、会议三类抽取、冲突组、两层裁决、依据变化影响清单与低打扰通知。
文件:RDM conclusions.go、domain/fc、pending/todo、kanban.go;新增 conflict_scope_test.go、conclusion_update_test.go、impact_notification_test.go。
测试:已存在结论后新增资料仍可提出更新;相似但不冲突的反例;同一切片参与多个争议只关闭指定争议;编制人只改本文档选择,负责人裁定共享结论;正文未变但依据更新仍提醒;受限来源不在通知泄漏。
出口:知识更新和文档写入是独立受控动作,用户能知道“谁改变了哪条依据、影响谁”。
### U7. Template Contract and Pilot Assets
覆盖 R6/R9。登记全部 69 类及 XLSX 资产;按模板子方案 U1/U2 建立公共章节结构、内容/格式约束、发布版本、默认用途、稳定 sectionKey 和 bundle,先结构化项目建议书、竞品分析两模板。
文件:RDM docs/templates、templates.go、structure.go、domain/doctree.go;69 类台账及 XLSX 资产;template_contract_test.go/template_instance_test.go 与每模板验收样本。
测试:台账无遗漏,首批用途匹配、v2/v10、多版本保留、模板升级迁移提案、无源代码运行和格式契约;两模板能正确实例化,不用静态检查冒充真实生成。
出口:公共模板契约和首批两模板可供 U8 使用;其余模板标记待迁移/验收,全部完成由 U16 承接,避免 U7 与生成能力互相等待。
### U8. Document Generation and Three Duties
覆盖 R6/R9/R10/R11/R13。复用模板子方案 U3–U5,交付文档级职责、持久提案、完整来源、差异采纳、锁定审签、正式版本和批准快照导出。
首批竞品分析模板含法规要点,完整验收以前置 U12 的真实双通道就绪为条件,不能用模型生成 URL 或单通道占位降低模板要求。
文件:RDM compose.go、draft.go、domain/fb/writegate.go、domain/review.go、docx.go、plugin、编制 skill;新增 document_revision_test.go/document_duties_test.go,真实三人浏览器编制案例。
测试:无职责等待/分配/接续;非编制人所有写入口拒绝;审核人不能改正文;审签走真实总线不传伪造身份;多审核人缺一不能批准;更换职责不能让原作者自审;旧卡/旧版本拒绝;部分采纳重验整文;撤权/并发/故障原子性;真实 DOCX 打开和引用可达。
出口:两份试点从真实资料经真实模型和三人账号完整通过,随后 U16 全量文档族推广;有实际结果才能生成验证报告通过结论。
### U16. All Document Families
覆盖 R6/R9/R10/R11,依赖 U8 首批真实闭环。按原 69 类台账逐族迁移、发布和验证,现有报价 XLSX 独立交付;需求、设计、风险、测试/验证、评审等文档族全部有结果。
文件:RDM docs/templates/registry 与全部模板、XLSX 资产/renderer、各模板结构/格式/样本测试;原件哈希与迁移差异写入台账。
测试:每份至少一个有材料的真实生成与审签导出正例、一个空缺/冲突反例;特有表格、章节、引用、公式、格式与职责均检查。编制共同契约复用 U8,不为每份模板新写一套业务流程。
出口:69 类均有已发布可用正文模板及对应运行证据,XLSX 实际打开检查通过。公司新标准模板另列 F-10;平台全量覆盖不得用项目内“不适用”豁免。
### U9. Durable Task and Conversation Infrastructure
覆盖 R7/R9/R13/R14。建立持久快慢任务、输入与检查点、取消/恢复/幂等、对话内卡与工作区同源;修正 RDM 普通文本入口和插件工具投影。
文件:RDM slow.go/slowledger.go/plugin/web;Backend 公共任务/HostFactory/事件面;现 slow_persist_test.go 加真实恢复语义,新增 task_recovery_test.go 与对话路由用例。
测试:跨刷新/重启/断网恢复;任务接纳后权限撤回;重复取消/确认;模型超时与外部结果未知先查询;seq 乱序丢弃;普通自然语言不触发空值异常,查询不落写任务;持久记录与页面计数同一状态。
出口:任务失败、部分完成、待确认、恢复中均可见,后台工作不会在进程重启后仅静默丢失。
### U10. Stage Gates and Project Closure
覆盖 R10/R11/R12/R13。阶段配置、推进/回退/结项、文档提交门禁、条件性不适用和决策快照;与内容/合规规则共用判断结果。
文件:RDM projects、baseline.go、review 服务、plugin;新增 stage_transition_test.go/document_submit_gate_test.go 与生命周期浏览器路径。
测试:有资料但未满足内容要求不能提交;无关候选边不误阻断;必需验证缺失/过期阻断;合法不适用可经有权者确认;上传不催缺项;陈旧推进卡和并发阶段变更拒绝;结项后只读与受控恢复。
出口:用户从立项到结项均可通过对话完成,不靠管理者手改状态。
### U11. Requirements and Compliance End to End
覆盖 R8/R11/R12/R15。实现需求分解/六维分类、风险/验证/确认/SOUP 业务录入和版本生产,合规边建议/确认、完整性规则、四链视图、审计展示与精确快照导出。
文件:RDM requirements.go、compliance.go、cderived.go、chainviews.go、cgraph_export.go、plugin/web;新增 producer_to_graph_test.go/compliance_replay_test.go;复用既有合规测试而不只域层播种。
测试:真实命令新增/升版需求到图、分解来源可追、候选边不能自动生效、风险控制缺验证、验证版本不一致、SOUP 标记、旧快照查询/导出相同、受限端点不泄漏、规则版本变化导致缺口重新评估。
出口:已有读模型真正有生产数据;专家校准意见、规则版本与证据映射齐备。全图视图保持渐进,不强迫用户操作大图。
### U12. Real External Evidence
覆盖 R7/R11/R15 与 UR-13/14。真实法规知识库与网络双通道,外部资料入树,冲突和降级明确;模型答案与取得的网页原文分开。
文件:RDM regcheck.go/domain/regcheck;Backend 公共搜索/抓取接入(有则复用);regcheck_test.go 扩展真实受控来源回放及失败样本。
测试:模型编造 URL、链接不可达、标准版本不一致、两通道冲突、仅单通道、来源权限撤回、摘录与正文不符;均不能显示双通道已核验。
出口:每条外部结论有实际检索/获取记录、原文快照和支持关系;外网不可用时仍可工作但不伪称核验。
### U13. Team Runtime and Isolated Execution
覆盖 R14 与 SR-G16/SR-N1/N4/N5。复用团队存储计划,把 RDM 领域数据纳入 PG/事务/任务恢复;实现隔离执行档、资产发布包、备份恢复/迁移回滚和运行可观察性。
文件:RDM domain/store、projects/members/perms、原件/慢任务存储;Backend/Squad/Native 对应公开边界;migrations、安装/升级清单;新增 rdm_pg_test.go/rdm_multi_instance_test.go 与隔离执行黑盒用例。
测试:SQLite→PG 干跑/核对/失败回滚、旧库名称冲突、原件与 DB 一致恢复;双实例同名/同文档竞写、epoch 过期写入拒绝、重连追赶;执行不能越目录/越项目/读秘密/超资源;取消后子进程停止或进入明确恢复状态。
出口:先单实例团队版通过,再开放双实例;使用脱敏固定数据集,记录容量阈值而非仅声称支持 100 人。
### U14. Full Acceptance and Operational Delivery
覆盖 R1–R15。逐条重放需求矩阵、全部文档、真实三用户/两项目、真实模型、真实浏览器、自举与安装包;接上固定 HEAD CI 和独立重放。
文件:RDM docs/requirements/09、业务 E2E/fixtures、CI、release manifest、安装/回滚/恢复说明;Dev 组合记录;新增最终验收台账,不篡改历史原始收据。
测试:上述正常/拒绝/故障全部场景;真实自举材料不能由测试临时编造“支撑资料”;全部上线模板实际打开产物;项目/私域/职责隔离、性能、重启恢复和安装包离线资产校验。
出口:每条声明绑定命令、精确对象、输出和来源;业务完成、合入、部署、用户验收分别签收。用户当前实例在部署阶段明确选定,先备份再切换,不擅自清理旧进程。
### U15. Remaining Final Goals
| 原目标 | 完整路线与本轮去向 | 前置/责任与完成判据 |
|---|---|---|
| F-01 飞书全套 | 渠道、身份绑定、权限映射、虚拟人、文件/版本链接 | 核心授权和固定文档快照先完成;独立连接器任务固定外部租户/权限/凭据;外部回调不能绕过同一三权和资源权限 |
| F-02 完整变更流程 | 按公司流程选择系统内流程或外部集成,七步闭环逐项有对象和状态 | 先评审业务权威及外部 owner;实施追溯的申请、影响、评审、批准、执行、验证、关闭;当前影响提示不冒充闭环 |
| F-03 精细分享 | 保留显式授权与撤销;会话/部分会话分享仅在用户再次明确启用后开放 | 本轮私聊私有为硬默认,不能以最终扩展名义自动共享;范围、接收者、版本及撤销语义需独立批准 |
| F-04 时间权重 | 内容新旧、版本、来源质量可配置排序,冲突仍由人裁决 | U5/U6 后,固定检索评估集及配置版本;效果对照和公平覆盖达标,不靠“越新必正确” |
| F-05 代码工具 | GitLab 等只读代码、版本、缺陷与需求关联 | 外部仓库授权与读取契约、可验证 commit 绑定;不包含擅自写代码/推送权限 |
| F-06 交互收敛 | 纳入 U9/U14:看板、卡片、领域工作区同源 | 单一状态所有者、刷新/事件/撤权一致、右栏关闭无能力缺失 |
| F-07 遗留决策 | 重建 Q/O 决策台账,逐项定论或保留具体阻塞 | 不能把问题组当已确定功能;阶段划分、专家规则、对抗验证形态等按来源和裁定处理 |
| F-08 难度与人机边界 | 评估表、任务分工建议、人工为主的降级、独立质量检查 | U7/U9 后,明确谁评估、输入和证据;高难任务不伪装全自动完成,人工意见留痕 |
| F-09 追溯可视化 | 按 10 月 11 日已批准展示方案纳入 U11/U14 | 项目树/一跳关联/审计时间线/四链与矩阵可用且鉴权;不是继续无限延期 |
| F-10 公司标准模板 | 用户提供后按 U7 模板发布/映射/差异迁移机制替换 | 需实际模板文件及评审责任人;旧文档版本保留,标准模板逐份真实生成验收 |
这些目标没有被删除。F-01/02/03/05/07/08/10 所需外部授权、组织裁定或输入未齐时,分别记阻塞对象与责任人;核心已有能力可继续交付,但最终全范围不得提前关闭。
---
## Verification Contract
本轮仅调查与文档验证;业务 PASS 一律不得由本方案文字推断。
| 验证层 | 范围与工具入口 | 证据与退出条件 |
|---|---|---|
| 资产和静态 | 需求矩阵、模板契约、安装包资产 | 34 UR/68 SR/10 F/69 模板全部有去向;链接、schema、版本和文件均可核 |
| 领域单元 | RDM `make test`、针对变更新增拒绝/边界/故障用例 | 事务/职责/版本/门禁明确正确;mock 只证明机制 |
| 总线/公开契约 | 注册 schema→可信身份→handler→领域服务;实际工具投影目录 | 不绕过 schema、登录与权限;旧命令和 UI/API 同一行为 |
| 持久集成 | 真实 SQLite/PG、原件/索引/任务、进程故障重放 | 无已确认数据丢失/静默重复生效/跨项目泄漏;迁移和恢复可复核 |
| 用户全链路 | 真实三权账号及普通成员、两个项目,真实浏览器 | 立项、分配、私有上传、发布知识、生成、审签、导出、阶段推进;刷新/重启/撤权一致 |
| 模型任务级 | 固定素材与版本,前后对照并保留真实调用 | 正确模板/来源、冲突与空缺诚实、权限不越界;人工盲审语义支持,不只看引用 ID 存在 |
| 交付文件 | 实际 DOCX/XLSX 与 Office/LibreOffice 打开 | 内容、表格、格式、来源、签署和快照一致;报告不能编造真实测试结果 |
| 运维与容量 | 固定环境,10→30→100 用户阶梯与故障演练 | 以已批准存储方案量化合同及 SR-N1 为准;预算和数据规模公开记录,跳过的 PG/Redis 项目不算通过 |
| 正式准入 | RDM 与 Dev 固定组件 SHA、CI 链接/身份、独立重放 | SELF/GATE/REPLAY 分开;本地通过不能代替人工评审、平台准入或线上验收 |
关键用户验收样例:
1. A 创建项目,B 同名创建被拒;A 加入 B/C/D 后大家看到同一个项目,彼此会话仍不可见。
2. 平台允许成员管理但禁止某动作,A 的项目 override 不能放大;管理员撤销上限后旧任务和旧卡片也失效。
3. B 上传私有原件并发布一段经确认知识;C 可使用该知识而不能打开 B 的原件,D 的搜索、计数、摘要不泄漏它。
4. A 指派 B 编制、C 审核、D 批准;B 生成,C 只能批注;D 等全部审核通过后批准,A 不能凭负责人身份代批。
5. B 在审核中改正文、切换成审核人后自审、旧卡批准新版本、跨项目伪造 sectionId 均被服务端拒绝。
6. 资料升级但文档未变,看板仍显示依据更新;编制人选本文档依据不自动改变共享结论。
7. 断网/重启后恢复同一任务与提案;重复采纳只有一次内容版本;版本写入或建边失败不出现半条追溯。
8. 已批准旧快照与当前修改并存,导出旧正式版仍得到旧内容/旧依据/旧签署;合规报告使用同一水位图和 hash。
9. 69 类模板及报价 XLSX 分批全部真实验收;没有资料的报告不生成不存在的实验/测试结果。
## Definition of Done
当前方案阶段:用户关键口径准确落盘,所有原需求与后续目标有追溯映射,源码差距与运行未知分开,工作包含依赖、责任模块、文件、验收与停止条件。
核心产品 C1:U1–U14 及 U16 对应矩阵证据全部齐备,真实项目管理、隐私协同、全部文档三权与导出运行可用;没有把历史桩测试当真实验收。
最终目标 C2:U15 每项实现验证,或用户明确取消/替代并更新权威需求。只“已备案”或“后移”不能关闭最终目标。
正式上线:固定目标实例和制品、完成迁移/备份/恢复/回滚验证、取得对应部署授权并通过用户运行验收;上线与代码合入分别记录。
优先下一步为 U1:固化本次总体范围、修正基线/证据口径,并细化 U2/U3 的项目与资源授权公开契约。其直接解决当前用户无法管理同一项目、创建者无法完整配置三权、私域与共享层可能混用的问题。
本轮“所有文档都加入并实现”和“三权要实现”已作为明确交付要求记录;由于同时要求先完成全系统目标核对和完整方案,本轮停在可评审总体方案,不把尚未评审的新跨仓/权限设计直接实施。
### Decisions Still Required
用户已确认的 D1–D6 不重复请求。仍需评审的是本总体方案的技术路线、U1–U16 分工和交付边界;实施前固定目标运行实例、团队部署档及具体负责人。
进一步阶段合并、外部完整变更流程归属、外部系统租户/凭据、公司标准模板和专家校准结果有明确后续依赖,不阻塞当前项目/权限/模板地基工作;未齐备时不伪造完成。
各阶段沿 `Dev:policy/delivery.md` 人工评审;若后续要求连续实施,应明确覆盖的阶段和终点,发布、保护规则变更等双钥匙边界继续保留。
## Appendix
原始来源:S:35–76 与 D:75–88;RDM requirements/README、00、01/03/04/08/09/10;U0、V2.2 已批准裁定。矩阵中给出每条需求的原文位置。
设计依赖:两树一网展示方案 r1、多人存储方案 r1、模板对话生成方案及 69 类资产盘点。涉及 API 的名称均为候选设计,正式符号由公开契约申请确定。
本轮没有联网核验法律或标准条款,也没有声称系统已符合任何特定法规;本方案讨论项目既定需求、数据追溯与实现验收。
@@ -0,0 +1,399 @@
---
title: RDM 基于模板与两树一网的对话文档生成方案
type: feat
date: 2026-10-11
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: legacy-requirements
---
# RDM 基于模板与两树一网的对话文档生成方案
修订:r1.1,首批顺序已确认,其余方案待用户评审。需求负责人:weichen;方案编制:Codex;实施负责人:待立项指定。
本轮授权终点是调查和方案;业务实施、模板迁移、模型试验、部署与运行验收均为 NOT_RUN。
本文件为模板生成子方案正文;总体范围、最新现状及优先级以[最终目标完整交付方案](2026-10-11-rdm-final-target-completion.md)为准。任务记录:Dev `.task/feature-rdm-template-dialog-plan.md`。
本案资产/代码表固定于 RDM 0081628a;本轮期间 d8d7e743 已新增项目绑定、部分命令授权和管理员引导修复,增量差距见总体方案,不再把旧表当作最新全系统状态。
路径前缀约定:`RDM:` 指 Agent-System-RDM;`Legacy:` 指旧 Agent-System;`Dev:` 指 Agent-System-Dev。
## Goal Capsule
用户在项目对话中说出需要编制或更新的文档,系统选用明确版本的模板,从该项目有权使用的知识与文档中组织依据,生成可审阅、可追溯、可继续修改的草稿;编制人确认后形成内部版本,再经三权流程产生可导出的正式文档。
推荐在已有 RDM 插件内补齐生成闭环,复用基座的模型、任务、卡片和工件能力。模板决定文档结构与格式;笔记树提供知识;文档树承载文档及章节版本;追溯网记录依据、派生与影响关系。
本方案涵盖 69 类历史文档资产的接入路线,首批用项目建议书和竞品分析验证完整链路,再扩展全部文档。此顺序已由用户于 2026-10-11 明确确认:“先打通项目建议书、竞品分析,再扩展全部文档”;需求、设计、验证和其他文档族的后续批次仍待细化。
实施前先评审本方案及与既有两树一网方案的任务分工;任何设计批准不自动包含迁移、发布、合入或部署授权。
---
## Product Contract
### Problem Frame
系统确实有大量历史模板,但当前 RDM 的文档类型目录、模板注册表、章节树、对话命令和导出器尚未形成一致的产品路径。
需要解决的是“用户能在对话中可靠地编制整份体系文档”,不能以模板文件存在、命令注册或模型返回一段正文作为完成标准。
### Current State
调查为 SELF·源码与资产检查,未查询业务数据库、未登录应用、未做真实模型或浏览器验收。
命令原始输出和对象 SHA 经 `make evidence` 记录于任务卡;静态控制流推导与运行结果分开。
| 对象 | 本次调查基线 |
|---|---|
| Dev | `95992d751f0a6ea8e345109dbb6b9367d9055e92` |
| Dev Backend | `3def5259023806a49ab84f885b7d220333cccde6` |
| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
| 旧 Agent-System | `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` |
| RDM Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
Dev 与 RDM 实际依赖组合不同;不能以 Dev 最新扩展已存在推断下游已接通。
| 资产/能力 | 盘点结果 | 含义 |
|---|---|---|
| 旧 Markdown 业务模板 | 69 份:bd 7、rd 60、pm 1、tm 1 | 是可复用的历史内容资产 |
| 旧报价 XLSX | 1 份 `templates/xlsx/cdo_quote.xlsx` | 单独登记,不并入 69 个 Markdown 文档类型 |
| RDM 文档类型字典 | 69 个,与旧模板文件名集合一致 | 目录已迁入,不等于模板已迁入 |
| RDM 注册模板 | 4 个,均为 v1 | 项目建议书、竞品分析、周报、评审纪要 |
| 已绑定文档类型 | 3 个:`rd_proposal`、`bd_research`、`rd_design_plan` | 其余 66 种未绑定注册模板 |
| RDM 自举文档树 | 10 份文档、22 个章节 | 是一个自举项目结构,不是 69 类的通用实例化 |
| 章节生成 | `Compose` 调用 `Host.Complete` | 已有真实模型调用路径,运行质量未验证 |
| 写入/审签/导出 | 有 apply、版本、三权域模型和 DOCX 代码 | 需补端到端契约与运行验收 |
资产依据:`Legacy:templates/docs/`、`RDM:internal/domain/data/labels_seed.json:68`、`RDM:docs/templates/registry.yaml:4`、`RDM:docs/structure/rdm-self.yaml:1`。
| 模板 | 绑定类型 | 当前用途与问题 |
|---|---|---|
| `review-minutes@v1` | bd_research、rd_design_plan | 评审纪要,不应默认替代调研/计划正文 |
| `weekly-report@v1` | rd_proposal | 周报,不应默认替代项目建议书 |
| `project-proposal@v1` | rd_proposal | 业务正文模板,含内容要求与排版说明 |
| `competitive-analysis@v1` | bd_research | 业务正文模板,含内容要求与排版说明 |
当前关键缺口:
| ID | 源码事实或静态推导 | 对本方案的影响 |
|---|---|---|
| G1 | 两条编写 intent 只调用 templates.for,且传 project-proposal-v1/competitive-analysis-v1;该接口要求字典 docType(plugin.go:212–230,templates.go:127–138) | 自然语言入口参数不一致,尚不是完整编制入口 |
| G2 | RDM 命令未声明 exposeAsTool;实际 pin 的 EXT-14 仅投影显式声明命令(pins/.../internal/cmdbus/cmdbus.go:47) | 注册命令不等于模型可调用;须核对实际工具目录与 schema |
| G3 | Compose 模板开关可缺省;按第一个适用 key 选模板,读取失败静默返回空串(compose.go:17、63–85、150) | 可能选周报/纪要,或者无模板继续起草 |
| G4 | 单章提示词注入整份模板;章节结构另存 YAML,文档/版本无 templateKey/version/hash(compose.go:35–47,doctree.go:29–65) | 模板、章节和历史无法一致固定 |
| G5 | Compose 返回即时内容;apply 重新检索,固定 topK=8;skip 旧依据参与起草却不能进入 accepted,Basis 直接取 accepted(draft.go:93–108,writegate.go:158–186) | 候选漂移、旧依据丢失、无法固定确认对象 |
| G6 | 写版本后逐条建 supports 边(writegate.go:186 起) | 中途失败可导致正文与追溯不一致;复用既有原子事件工作项 |
| G7 | draft/compose/apply 仍可空项目回退,处理器缺少对应编制人检查(runtime.go:106,plugins/rdm/plugin.go:1645 起) | 上下文、生成和提交均须领域授权;只靠宿主 owner 不够 |
| G8 | approve/reject/final schema 必填 reviewer/actor/approver,处理器却拒绝这些参数(plugin.go:295–320、945–1001) | 总线契约矛盾;必须从真实分发入口验证审签 |
| G9 | 模板从工作目录或编译时源码路径读取;构建仅生成二进制(templates.go:45,prompts.go:42–52,Makefile:40) | 需验证安装包脱离源码仍能加载模板 |
| G10 | DOCX renderer 接收标题与章节,未消费模板排版规格;导出取章节当前版本(docx.go:155、298–306) | 排版要求未兑现,正式版需绑定整文批准快照 |
这些是实施前应验证和修复的具体断点,不声明现网已经复现。
### Requirements
| ID | 用户可见要求 | 来源 | 验收判据 |
|---|---|---|---|
| R1 | 对话中查询、选择并预览模板 | SR-C2、SR-E6 | 显示用途、版本、适用类型和可用状态;不混淆类型数量与模板数量 |
| R2 | 一句话编制整文或指定章节 | UR-11、F4、SR-E4 | 确定当前项目、目标文档、操作范围及模板后进入生成任务;歧义时澄清 |
| R3 | 文档结构来自固定模板 | SR-C1/C2、M5 | 文档绑定已发布模板版本;每章有稳定标识、内容要求、检索条件及顺序 |
| R4 | 只使用当前有权使用的依据 | SR-G2、U0 R09/R21 | 跨项目、私人未发布、待裁定、撤销资料不能进入共享生成正文 |
| R5 | 每段事实可回到实际来源 | UR-11、SR-D1/D6、08 R1–R5 | 引用能定位切片/结论/已有文档的准确版本与锚点,历史可复核 |
| R6 | 缺证据明确标出,冲突由有权者裁决 | F4、SR-B8/B9、U0 D4 | 不编造内容;文档层选择不改变项目共享结论;未裁决冲突不混入有效事实 |
| R7 | 草稿提案经确认才改正文 | F-B、SR-C4/C6 | 展示新增/更新/冲突与差异;确认对象固定;未接受内容不写入 |
| R8 | 保留已有正文与依据,支持增量更新 | UR-05、SR-C6 | 只修改用户选择范围;保留、增加、删除的依据与最终正文一致 |
| R9 | 编制、审核、批准职责与版本固定 | SR-C7/C8、U0 D2/D5 | 非编制人不能生成/改正文;提交锁定;审签绑定完整文档版本 |
| R10 | 长任务可查看、取消、恢复 | SR-F4、SR-B10、U0 R21 | 刷新/重启后看到同一任务;重复点击不重复生效;失败章节不冒充整文完成 |
| R11 | 输出可打开、下载、追溯的 DOCX | U0 R14、10 号定稿决议 | 内容、格式、引用及版本与选定草稿/正式快照一致;下载再次鉴权 |
| R12 | 旧模板逐份纳入可管理的目录 | 03 §7、SR-C2 | 69 份都有资产处置记录;已发布/待整理/不适用分别显示,不能批量冒充可用 |
| R13 | 对话、卡片、工作区使用同一状态 | SR-E6、U0 D7、DESIGN.md | 收起右栏仍可完成编制;陈旧卡片不能批准新内容;按 seq 丢弃旧事件 |
R1–R13 为方案候选范围,人工评审均未完成。R12 的登记全覆盖与各模板运行验收是两个阶段。
### User Flow
示例:“用已有资料生成这个项目的设计开发任务书。”
1. 从可信会话解析项目,辨认是新建、更新、只改某章还是查询;“总结一下任务书”不能触发写入。
2. 查现有文档与职责。已有同类文档时确认更新对象,缺模板或有多个正文模板时给出可选项,不随意选第一项。新文档无职责时保留请求为“等待职责分配”;有权负责人可在对话中指定异人的编制/审核/批准角色,其他成员可提出分配请求,由负责人处理。若当前用户不是编制人,则显示当前职责并允许转交编制请求,不把原私聊全文传给他人。职责就绪后由指定编制人接续同一目标、重验权限并确认启动,负责人不自动获得编制权。
3. 展示一张编制卡:文档名称、模板版本、章节范围、使用的资料范围、将创建草稿的效果。确认后启动任务;已明确提供的信息不重复询问。
4. 按章准备依据,必要时集中呈现冲突双方、来源、建议及理由,由相应角色裁决。
5. 后台逐章起草与校验;对话即时显示计划和阶段,允许继续讨论或取消。无材料章节注明待确认。
6. 完成后提供正文预览、逐章差异、来源和未决项;编制人可要求“只重写第二章”“采用这个依据”“保留现有市场分析”。
7. 编制人采纳所选提案后产生内部版本;提交审核时执行完整性检查并锁定完整文档版本。
8. 审核人和批准人分别以真实身份确认。完成后可导出 DOCX,继续通过对话查看来源或发起受控修订。
编制卡、冲突卡、差异采纳卡和审签卡是不同决策,不合并成一次模糊的“确认全部”。同一决策可以在对话与工作区投影,使用同一服务端对象。
编制过程中说明空缺不等于强制补齐所有字段;沿 SR-C5,资料上传阶段不推送缺项清单,正式完整性门禁只在提交审核/申请推进阶段执行。
### Scope Boundaries
本期设计复用现有模板,先完成内容与格式结构化、生成和受控落盘,再分批扩大覆盖。
标准模板替换沿 F-10,待系统测试后由用户提供;不擅自下载其他“官方模板”替代旧资产。
不把合规边有来源等同于满足具体法规;法规结论继续走既有双通道及人工复核,本方案不作标准符合性判定。
飞书对接、变更流程引擎、跨项目自动取材、无人审批、所有文档自动重写不纳入本次实施建议。
最新两树一网可视化方案已单列,生成能力不等待全局大图;文档引用浏览与项目审计中心沿各自权限开放。
---
## Planning Contract
### Alternatives
| 路线 | 收益 | 代价及结论 |
|---|---|---|
| 复用 RDM,补齐模板/候选/整文契约 | 保留已有知识、版本、审签与追溯,职责清楚 | 推荐;先修跨层契约,再扩模板 |
| 将旧生成系统整体搬回新系统 | 可快速得到旧模板和流程 | 会带回任务键绑定、多份目录及旧状态治理,不采用 |
| 把整份模板和检索结果直接交模型输出文件 | 演示快 | 难保证固定依据、增量更新、三权和恢复,只能用于隔离试验 |
### KTD1. Template Contract
将“文档类型”“模板资产”“项目文档实例”分开管理。
文档类型保留兼容键;模板使用 `templateId + version + hash`;文档实例使用项目内稳定 docId。
注册表是模板权威入口,避免再增一套手写目录;缓存和索引只能由它生成。
| 模板层 | 核心内容 | 执行方式 |
|---|---|---|
| 资产元数据 | 名称、用途(正文/纪要/汇报)、别名、适用类型、版本、生命周期、来源 SHA | 可查询、受控发布;禁止字典序判断版本新旧 |
| 内容结构 | 稳定 sectionKey、标题层级、内容要求、表格列、条件适用、允许缺省 | 编译为文档树实例与内容校验规则 |
| 依据规则 | 共享标签条件、资料类型、强制输入、可用结论/文档类型 | 编译检索计划;保留人工选择与审阅 |
| 格式规格 | 页型/页边距、字体、标题编号、页眉页脚、表格、引用呈现 | 由确定性 DOCX renderer 消费,不靠模型猜排版 |
| 发布清单 | schema 版本、资产哈希、依赖字典、审批记录、兼容范围 | 安装包自包含;运行时清楚报告缺失或不兼容 |
模板生命周期建议为 draft→published→retired。模板先评审再发布,再实例化文档树;同一已发布版本不可原地改写。
首期内置共享模板及默认绑定只由获批的仓库发布流程变更,模板发布权不继承文档编制权。普通编制人只能选择已发布版本。后续用户上传模板只形成待评审候选;运行时发布/退役/改默认的责任主体与项目或共享作用域须另行评审后开放,不能借上传模板修改其他项目规则。
普通编制人只选已发布版本,不因生成一次文档重复审批模板。退役不删除历史快照。
默认绑定使用“docType+purpose+显式 default”;候选多于一个且无明确默认则询问;用户指定模板优先,但须校验适用性。
用户指定“按模板生成”时,模板缺失/失效须停止该路径并解释,不能静默按自由文本起草。
更新模板不自动改已有文档;迁移章节映射、内容影响和格式变化以单独提案确认。旧文档保持原 templateRef。
### KTD2. Template Migration
建立 69 份历史模板的逐项台账:原路径与 SHA、对应类型、目标 key、用途、章节数、内容差异、格式要求、处置结果、发布与验收状态。
先保全原件与哈希,再拆出正文要求、管理信息、格式约束。追溯表、签署记录、缺项登记、已有材料摘要等管理信息进入相应台账或附属视图,不直接复制成正文章节。
模板提取可以由模型提出候选,但发布结构与章节映射须人工审核;不因 Markdown 有二级标题就认定它是合格模板。
10 份自举文档逐份做语义映射,避免仅凭原 docType 将“实施推进方案”套成“项目建议书”。已有内容只生成映射候选,不覆盖。
建议发布包内置受控资产 bundle;后续用户模板使用同一校验/发布协议,从受管目录或存储载入,禁止依赖编译机器的源码路径。
### KTD3. Three Structures and Context
每项目独立解析两树一网;共享模板通过固定版本引用,不建立跨项目业务边。
笔记树切片及结论提供内容;文档树章节提供输出目标、既有内容及版本;追溯网提供已有依据、取代关系、冲突和受影响对象。
检索先判权限和资料发布状态,再检索和排序,不能先读全库再让模型筛项目。
章节强制依赖、现版有效依据、已选结论及其原始 basis 应完整保留;其余素材用标签、语义、图关系合并、去重和有界排序。
语义路须传确定项目;知识 chunk 到领域切片建立稳定映射,不能同一原件只取第一个 slice。
超出上下文预算时分章节、分资料批次处理并保留覆盖账本;不得以 topK 截断后声称“已查全部资料”。检索降级向编制人可见。
新内容优先是排序线索,不自动推翻已生效结论;已废止、待裁定资料只能用于有权限的冲突说明,不能作为已生效事实。
私人对话原文不因关联项目就共享。模型从对话提炼的资料须沿既有发布/相关性边界进入共享知识;私有资料确需用于共享文档时,先获得明确发布授权。
模板、上传原文和引用资料是任务数据,不得提升为系统指令或扩大工具权限。
### KTD4. Durable Generation Objects
建议增加四类持久对象,字段名为设计候选,不是已发布 API:
| 对象 | 固定什么 | 主要作用 |
|---|---|---|
| GenerationRun | 项目、文档、编制人、会话、范围、templateRef、章节基线、知识水位、模型/提示词与检索版本 | 任务进度、恢复、成本与产出可追溯 |
| ContextManifest | 选中来源 ID/版本/hash/锚点、授权/发布依据、保留与排除集合、冲突裁决 | 解释实际给模型的材料,不保存隐藏推理 |
| SectionProposal | sectionKey、baseVersion、结构化正文、段落引用、差异、空缺、校验结果、状态 | 供人修改/比较/采纳;不改变生效正文 |
| DocumentRevision | 全部章节版本集合、模板与布局版本、内容/hash、依据集合、审批快照 | 固定整文审签和导出,防止“各章最新”拼装 |
段落引用持久化为稳定对象引用,短编号仅用于显示,必须保留编号映射。来源包括 slice、结论及依据、受控文档版本、模板版本、明确授权的外部材料。
引用存在性、项目归属、版本和采纳范围由服务端校验;引用能打开不证明语义支持,另用模型检查加人工抽验判断事实是否被证据支撑。
保留旧依据、增加新依据、移除依据分别记录,最终 Basis 从实际成文引用聚合并校验。用户取消某素材后,相关事实必须删除、重写或改为未证实,不能只删脚注。
人工修改提案后重新计算 hash 并校验;内容、选材或目标版本变化使旧确认失效。
### KTD5. Generation and Human Decisions
起草遵循“检索并固定输入→模型组织正文→结构/引用/冲突检查→持久提案→人工采纳”,允许模型自主拆任务和选择可用工具,受控写入口保持确定性。
现有 Compose 和 Gate 应重构复用,修正“仅有 skip 旧依据时被视作无素材”、旧依据不能保留等路径,不另起第二条正文写入链。
模板内容要求决定章节任务;不能把整份模板重复塞入每一章。独立章节可并行,共享术语/数据依赖按章节依赖顺序生成,最终做全篇一致性检查。
无法证实的数据不得补成事实。临时草稿允许“待确认”标记;正式版不能含未处理的必需项,处理方式是补证、明确不适用及有权确认,不能改规则绕过。
冲突分两层:编制人决定本文档引用哪条依据;改变项目共享结论由项目负责人或指定知识责任人裁决。后台模型不自动做这两个决策。
### KTD6. Authorized Atomic Apply
从可信请求身份解析 actor,不接受前端 actor/reviewer/approver 自报。所有生成、读取、确认、导出及旧命令统一经过领域授权。
生成开始、关键读取、恢复、结果投递和最终采纳时重验项目与职责;管理员/负责人不因角色高就自动拥有文档编制权。
apply 接收固定 proposalId、预期章节/文档版本、采纳范围和幂等键,不再重跑检索重建“当时的候选”。
事务内验证权限、版本和引用,原子提交版本、依据/追溯边、提案状态和领域事件;提交后更新投影。跨库宿主审计通过可靠 outbox 投递。
多章节整文采纳默认同一业务事务;用户主动选择部分采纳时,生成包含未改章节原版本的新 DocumentRevision,清楚标记剩余未采纳章节。
部分采纳先构造实际将保存的新旧章节组合,重新校验章节依赖、共享术语及关键指标一致性;后继章节依赖未采纳的前置改动时暂停采纳,列出必须一同处理的章节供编制人选择。校验绑定该组合的 hash 与版本;事务提交前再核对版本,不能沿用整份候选曾经通过的检查。
模型调用不占持久写锁;候选失效返回具体变化,保留提案供比较,禁止覆盖新版本或静默再生成。
断连/超时先按幂等键查询提交结果,再决定是否重试。跨库工件生成与领域提交不冒充一个事务,以导出任务和可恢复映射协调。
### KTD7. Conversation Tools and UI
RDM 提供模板查询/预览、文档实例化、生成准备/启动/状态/取消、提案查看/修改/采纳、提交审核、审签与导出能力;名称和 schema 在实施契约中固定。
先统一 docType/templateId/version 含义及 schema 与处理器身份约定,再将需要模型访问的命令显式投影到工具目录;保留确定性命令入口用于卡片与测试。
RDM 编制 skill 提供渐进说明与编制规则,业务权限与确认不靠提示词约束。skill 的新增/变更纳入真实模型任务级对照。
审签决策由指定人通过认证确认产生,Agent 只准备与呈递,不因用户一句模糊“继续”批准未展示的新版本。
基座负责通用模型路由、运行/卡片、工件字节、资源授权执行;RDM 负责模板、领域项目、资料发布、两树一网、提案、三权与版本。
公开面不足时按 RDM AGENTS 四要素提扩展申请;禁止下游导入 Backend internal 或修改 pins。
界面沿 `Dev:DESIGN.md`:对话为完整主入口,右栏“工作”看任务/待办,“文件”看文档;同一工件只有一个预览落位。
对话展示模板名/版本、章节进度、需处理事项、最终文件和来源入口,不直接倾倒 slice ID、事件 JSON 或内部工程术语。
一个服务端对象拥有异步状态,对话与工作区只作投影;按 seq 处理事件,刷新从服务端恢复,陈旧卡片显示已过期及原因。
UI 使用令牌、MotionKit、Collapsible 和安全 HTML 原语;无额外第四栏或新的平行预览器。
### KTD8. Review and Export
现有审签主要按章节实现;推荐面向用户升级为文档级职责与审签,章节审签仅作为可选内部协作步骤,不要求用户为每章重复三权操作。
文档提交时冻结 DocumentRevision:章节版本、模板、内容要求、依据及当时职责。后续撤权或职责变化使待处理授权失效或要求重新提交,不能接续旧签名批准新版本。
审核期间所有正文入口拒写;驳回回编制态产生新内部修订,不提前增加正式版号;原正式版在新正式版批准前仍可查看。
旧章节职责、审签和正式版作为原始历史保留,不自动合并为文档级授权或“已批准整文”。同一旧文档的章节可能由不同人编制/批准:转入新流程前由有权负责人明确文档职责;迁移清单列出旧活动审签,经有权人确认撤回后重提,未完成该处置的文档保持旧态只读查询并暂不启用新整文流程。首个文档正式版须重新完成整文审签;历史导出明确标识为旧章节版本集合,不冒充整文批准。
草稿导出清楚标记草稿。正式版导出只读取批准快照,不读取当前各章最新;正文、引用附录、签署元数据与格式使用同一快照。
DOCX 由结构化内容和布局规格确定性渲染,保存 artifact 与文档版本的关联。导出生成、预览、下载分别鉴权;权限撤销后已有任务不得继续泄露结果。
允许异步重试导出,不因文件生成失败回滚已获批准的文档状态,也不把导出文件反向作为领域内容权威。
### High-Level Technical Design
```mermaid
flowchart TB
U[项目对话或工作区] --> A[可信项目与角色解析]
A --> T[固定模板与文档目标]
T --> C[按章准备依据快照]
N[笔记树与有效结论] --> C
D[文档树及原版本] --> C
G[追溯网与冲突] --> C
C --> M[模型起草与确定性校验]
M --> P[持久提案和差异]
P --> H[编制人确认]
H --> W[原子写版本与追溯]
W --> R[冻结整文审核与批准]
R --> E[按快照生成 DOCX]
```
```mermaid
stateDiagram-v2
[*] --> Preparing
Preparing --> AwaitingDecision: 目标或冲突待确认
AwaitingDecision --> Preparing: 有权人决定
Preparing --> Generating: 输入固定
Generating --> Validating
Validating --> Proposed: 校验通过
Validating --> NeedsRevision: 检查发现问题
NeedsRevision --> Generating: 修订受影响章节
Proposed --> Applied: 编制人采纳及事务成功
Proposed --> Stale: 依据权限或目标版本失效
Generating --> Failed
Generating --> Cancelled
Failed --> Preparing: 重验后恢复
```
生成运行状态与文档审批状态分开。Applied 仅表示形成内部内容版本;随后仍需“编制中→审核中→待批准→已批准”,驳回回编制中,批准绑定固定整文快照。
取消只停止未完成任务,不撤销已经确认提交的版本;状态未知时先查事务结果。恢复重新取得受限 Host 与权限,不能序列化旧凭据或长期复用旧 Host。
### Dependencies and Assumptions
与 [两树一网集成方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md) 复用项目绑定/授权、原子事件、历史重放和可读引用能力,不建立第二套项目或审计服务。
该方案文档记录已批准,不能据此声称实现已经完成;本生成方案把相关能力作为实施前置条件,是否复用已合入实现以启动时源码和证据为准。
与 [多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md) 复用持久任务、事务与团队存储方向。RDM 仍需自己的事件/领域存储适配,不因基座使用 PG 就宣称 RDM 已支持多实例。
近期建议单实例完成两项目隔离和三人职责验收;团队多实例单独通过并发、恢复与迁移验证后开放。
基线更正:RDM requirements/README 已确认相关 V2.2 正文于 2026-10-09 合入定稿;正文残留“待评审”不推翻该裁定。本案新增实现契约仍待用户评审。
---
## Implementation Units
以下为待批准的分期,U-ID 只在本方案内有效;责任模块已明确,人员在立项时确定。每阶段均按 `policy/delivery.md` 人工评审,允许阶段内根据证据迭代。
### U1. Contracts and Asset Ledger
目标:形成完整资产清单与可运行入口的修复设计。覆盖 R1/R2/R9/R12。
范围:RDM templates.go、plugins/rdm/plugin.go、labels_seed.json;新增资产迁移台账、总线契约测试,复用 templates_test.go/templates_v01_test.go。
措施:记录 69+1 旧资产;统一类型/模板键、默认用途和真实身份字段;声明工具投影;确认现有项目/权限前置工作由哪项任务交付。
验证:两条中文编写请求匹配合法文档类型;同类型周报不抢正文模板;审签经总线可达且伪造身份拒绝;查询/总结不得生成;69 类处置无遗漏。
出口:资产及契约评审完成;未把全部模板标为可用。无需先搬迁所有正文。
### U2. Published Template and Document Instantiation
目标:模板成为结构与排版的唯一版本依据。依赖 U1;覆盖 R1/R3/R12。
范围:RDM docs/templates、rdmapp/templates.go、structure.go、domain/doctree.go、payloads.go/replay.go;新增 template_contract_test.go、template_instance_test.go、发布包资产检查。
措施:发布生命周期、稳定章节键、固定 templateRef、显式默认、版本比较、资产 bundle;两个已有业务模板先结构化,旧自举树做映射而非覆盖。
验证:v2/v10 顺序正确;缺模板明确失败;不同用途不误选;模板新版本不改历史文档;同名章节、可选章节、模板退役、无源码安装包启动均覆盖;普通编制人不能发布共享模板或修改其他项目默认。
出口:从两个已发布模板产生正确文档树,内容要求与导出规格可供后续步骤读取。
### U3. Context Snapshot and Durable Proposal
目标:固定依据并可恢复地起草整文。依赖 U2 及项目授权/读取边界;覆盖 R2/R4/R5/R6/R10。
范围:RDM draft.go、compose.go、fbhost/adapter.go、domain/fb/writegate.go;新增 generation.go、proposal_store.go 及相应测试,具体命名实施时固定。
措施:持久 Run/ContextManifest/Proposal;精确来源映射;章级计划与预算;固定模型/提示词版本;空缺与冲突单列;持续进度与取消/恢复。
验证:无素材、只有旧依据、只有冲突、多切片同原件、跨项目/私有资料、超长上下文、模型失败、检索降级、取消、重启、撤权,均有真实可观察结果。
出口:两份文档可形成整文候选,逐段回到稳定来源,刷新和重启不丢;尚未自动写生效正文。
### U4. Confirmed Atomic Document Revision
目标:采纳提案后内容、版本和追溯保持一致。依赖 U3 及两树一网原子事件能力;覆盖 R5/R7/R8/R9。
范围:RDM draft.go、domain/fb/writegate.go、doctree.go、eventlog.go、replay.go、review.go;新增 proposal_apply_test.go、document_revision_test.go、故障重放测试。
措施:固定 proposalId、CAS、幂等、保留/新增/删除依据;整文版本清单;统一编制权限;修正文档级审签;旧入口适配同一服务。
验证:两个标签页竞写、确认前版本变化、撤回依据、取消引用却残留事实、重复点击、写版本后建边失败、提交审核后旧卡片执行、部分采纳与整文导出一致性;只采纳后继章节而保留旧前置章节须被依赖校验拦下;迁移中同文档不同章节职责/正式版、审核中记录不得自动转成整文授权与批准。
出口:事务全成或全败;重放还原同一版本和引用;旧候选不会覆盖新内容。
### U5. Chat Workflow and DOCX Delivery
目标:用户仅凭对话完成首批真实编制闭环。依赖 U4;覆盖 R2/R9/R10/R11/R13。
范围:RDM plugins/rdm/plugin.go、编制 skill、web/app.js、docx.go;必要基座公开契约申请;新增总线全链路、浏览器与 DOCX 文件验证用例。
措施:准备/冲突/采纳/审签卡同源状态;固定模板与章节的编制配方;文档级审批快照;草稿与正式 DOCX;文件卡复用基座预览下载。
验证:三名真实用户分别编制/审核/批准,两项目隔离;无职责的新文档经负责人在对话分配后由指定编制人接续,非编制人只可转交;收起右栏完成全程;刷新/重启、陈旧卡片、下载撤权;实际 DOCX 标题、表格、分页、页眉页脚、引用可见且版本一致。
真实模型对照:固定同一批素材与任务,记录改造前后正确模板选择、必需内容覆盖、引用支持、编造事实、人工修订量、耗时与失败恢复;单测/mock 不替代此项。
出口:项目建议书和竞品分析经真实 UI 与模型完成,产物持久可见可下载;评审人独立重放。
### U6. Document Families and Legacy Migration
目标:按业务文档族逐批覆盖其余历史资产。依赖 U5,且每批模板先评审发布;覆盖 R3/R11/R12。
范围:RDM 模板资产/注册表/迁移台账及模板契约回归集;参考 Legacy:templates/docs,不再依赖旧工作流实现。
推荐顺序:用户需求与系统/软件需求→设计任务与计划→设计方案与记录→验证/确认与测试→评审/风险/其他体系文档;精确文档名和批次以 U1 台账与用户优先级确认。
验证:每个上线模板至少一个有材料的完整生成例和一个空缺/冲突例;每类特有表格、引用及 DOCX 规则有针对性验收,不能只跑注册表计数。
出口:69 类均有明确结果,所有声明已支持的类型通过对应验收;不适用由人裁定,未交付保留可见状态。报价 XLSX 单列,不偷换为 DOCX。
---
## Verification Contract
测试在后续获批实施阶段执行,本轮结果全部 NOT_RUN。源码检查只能证明路径存在与静态矛盾,不能证明真实编制体验。
| 层级 | 对象与方法 | 必须证明 |
|---|---|---|
| 资产 | 69 类迁移台账、模板契约校验、安装包 smoke | 类型/模板/默认/结构/格式一致;没有源目录依赖 |
| 单元与领域 | RDM `make test` 的 Go 测试;模板、检索、版本、权限、状态机测试 | 正常、拒绝、边界、依据保留与失败事务行为 |
| 总线与工具 | 真实注册表→schema→认证主体→处理器→领域服务;实际模型工具清单 | 文本入口与 UI 共用真实可达能力;审签身份无自相矛盾 |
| 持久集成 | 实际领域存储、原子事件、重启重放、幂等与并发故障注入 | 内容/引用/审批不出现半完成;未知结果可查 |
| 浏览器 | 真实三用户、两项目、对话+卡片+预览+下载;现 `make test-web` 只作局部辅助 | 刷新、断连、重启、权限变化后结果仍正确,右栏关闭不丢操作路径 |
| 模型行为 | 固定素材和模板的任务级前后对照、人工盲审结果 | 模板选对、事实有支持、缺项诚实、未授权内容不出现 |
| 交付物 | 解包检查 DOCX OOXML+实际 Office/LibreOffice 打开检查 | 正确内容、格式、表格、引用和批准快照;不能只检查扩展名 |
| 跨仓 | 固定 RDM pins 与 Dev 公开契约 SHA,相关 CI 及独立重放 | 下游实际组合可运行,禁止用另一组组件证据替代 |
首批硬判据:所选模板/version 必须正确;持久引用全部存在且在授权范围内;负向越权与静默基线覆盖为零;已声明完成的章节无未标注的证据缺口;相同幂等请求只生效一次。
“引用存在”与“语义支撑”分别评分。测试/验证报告不得虚构执行记录、测量值或通过结论;无实际执行证据只能生成计划、空表或标注未执行的报告草稿。
耗时、费用、引用支持率和人工修订量先建立基线,再由用户确认可接受阈值;上传首轮 60 秒指标不套用为整文生成时限。
项目审计中心权限沿既有两树一网方案;编制人可查看完成本职责所需且有权访问的引用,不能借生成工具读取整个项目审计或他人私聊。
证据分 SELF/GATE/REPLAY;正式验收固定对象与环境,按仓库要求经 evidence 记录,不把模型自评作为独立通过。
## Definition of Done
本轮方案交付:资产盘点、关键源码断点、需求与方案、分期和验收可追溯,待决事项与未执行内容明确;本地方案尚未获得人工批准。
业务完成:U1–U5 首批真实闭环有完整证据;后续 U6 每批独立验收和发布,不把首批成功写成 69 模板全部可用。
上线声明另需固定安装包、目标实例、迁移/恢复记录及运行验收;当前没有上线声明。
建议下一任务是 U1 的契约核对与模板台账,而不是直接批量生成 69 份文档。先复核远端在途任务,和两树一网授权/事务工作项分工;本建议不启动实施。
### Review Decisions
请评审以下具体选择:
1. 采用“RDM 内补齐闭环+69 类资产分批接入”的路线,复用现有模板内容。
2. 首批项目建议书、竞品分析,随后扩展全部文档——已确认(session-settled: user-approved,2026-10-11,用户对首批优先级问题的回复)。后续各文档族之间的顺序尚未确认。
3. 以文档级版本快照进行三权审签,章节作为生成、差异与增量采纳单位。
4. 固定模板和依据后生成持久提案,编制人确认才写入;标准模板替换仍待用户后续提供。
第 2 项首批及扩展方向已确认;第 1、3、4 项及完整实施/测试计划仍待评审。本次优先级确认不构成业务实施、迁移或部署授权。计划中确定性契约与测试细节可在评审意见内迭代,改变权限/模块职责/范围时重新评审。
## Appendix
主要依据:
- RDM:docs/requirements/01-用户需求与系统需求.md:UR-11、SR-C1–C8、SR-D1/D6、SR-E4/E6、SR-F1/F4/F5、F-10。
- RDM:docs/requirements/03-产品设计方案.md:M5/M6/M9/M10、F4/F6、§7 旧版 69 模板处置。
- RDM:docs/requirements/08-核心数据模型-两树一网.md:两树职责、共用标签、F-B、R1–R5、模板来源维度。
- RDM:docs/proposals/2026-10-08-U0-baseline-and-shared-contracts.md:项目共享、三权、两层冲突裁决、固定版本和对话同源约束;其中旧源码缺口已重新核对,不原样当作当前事实。
- Dev:DESIGN.md:对话优先、工作/文件双入口、一个状态所有者、一个预览落位。
- 本目录 2026-10-11-rdm-two-trees-trace-audit-integration.md 与 2026-10-11-collaboration-storage-and-distribution.md:本方案的授权/事件/存储依赖;不复制作另一条实施主线。
完整资产目录见 [模板资产盘点](../records/2026-10-11-rdm-template-inventory.md)。目录仅报告源码资产状态,不包含线上项目的实际文档数量。
@@ -0,0 +1,393 @@
---
title: RDM 两树一网集成、完善与追溯审计展示方案
type: feat
date: 2026-10-11
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: ce-plan-bootstrap
---
# RDM 两树一网集成、完善与追溯审计展示方案
修订:r1(2026-10-11 并入用户裁定);确认状态:用户评审通过(2026-10-11,需求拆解至实施计划五阶段一并,含 KTD4 双层管理员裁定);推进状态:U1 已实施并合入(RDM PR #195,merge 05b7d1a,2026-10-11);U2–U5、迁移与运行验收未启动。
需求负责人:weichen;方案编制:Codex;实施负责人:待实施立项时指定。
来源:2026-10-11 用户要求检查两树一网现状,并设计简单直观的项目追溯、审计展示;同轮明确选择“完善 RDM,并补齐必要的基座能力”。
目标仓:Agent-System-RDM;下文 `RDM:` 路径相对于该仓,`Dev:` 路径相对于 Agent-System-Dev;所有建议接口名均为候选契约。
关联任务:Dev `.task/feature-rdm-two-trees-audit-plan.md`;本文件是本次方案唯一正文。
## Goal Capsule
推荐按**每项目一套笔记树、文档树和追溯网**管理,在现有 RDM 实现上补齐隔离、历史完整性和产品入口。
项目创建者查看自己创建项目的追溯审计;RDM 域管理员与基座超管(基座 isAdmin)查看全部项目。
管理员使用跨项目目录和筛选器进入各项目,默认不展示混合的全局关系大图。
本轮只交付现状、方案和实施验收计划;方案已于 2026-10-11 获用户评审通过,业务实施与数据迁移仍须另行立项授权。
项目独立是数据归属、授权、版本和查询范围独立,不要求每项目部署一套服务或建立一个数据库。
先用一个项目跑通业务闭环,同时用第二项目验证隔离;管理员全项目目录与历史导出随后接入,本批默认范围为 U1–U5。
---
## Product Contract
### Current State
**结论:已经实现相当一部分,适合做集成与完善;尚不能认定为满足本次要求的完整产品。**
调查基线(SELF·源码检查):
| 对象 | 固定提交 |
|---|---|
| Dev 集成仓 | `5771d4f1e5b692bce95eb64cc30dc9931079ad12` |
| Dev Backend | `ea4651b1f870d84ab9b72cfa79363b3432d113b3` |
| Dev Frontend | `3ed10e122042a64180fb24a42d9cc6438cd2d2d6` |
| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
| RDM 实际 Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
| RDM 实际 Frontend pin | `84b73ab32848e623d0a0ab7ade552784dca8cf3c` |
Dev 当前源码与 RDM 实际依赖不是同一组合,升级前须分别核验公开契约。
本次没有运行业务测试、登录服务、读取业务数据库或进行浏览器验收;下列“已有”指源码存在,不能转换为“已部署/已验收”。
命令、对象 SHA、原始输出和远端在途查询由工具保存于[调查收据](../records/2026-10-11-rdm-two-trees-source-receipt.json);收据为 SELF,不是 GATE 或独立 REPLAY。
| 对象 | 源码现状 | 本次需要补齐 |
|---|---|---|
| 笔记树 | `RDM:internal/domain/notetree.go` 已有骨架、切片、锚点、标签、多点挂载、软删除;树是浏览骨架,切片可多挂载 | 独立浏览和详情读取接口;完整树导航;层级与挂载一致性 |
| 文档树 | `RDM:internal/domain/doctree.go` 已有文档、章节、正文版本与依据、状态;已有基线和审签能力 | 树式浏览、真实版本元数据、来源与变更联动 |
| 一般追溯网 | `tracenet.go`、`rdmapp/trace.go` 已有关系生命周期、邻域、多跳和图查询 | 端点完整性、同项目约束、版本定位及统一读模型 |
| 受控合规图 | `compliance.go`、`chainviews.go`、`cgraph_export.go` 已有受控节点、版本边、链视图、矩阵及导出 | 与一般关系网整合展示;补重放一致性和历史快照 |
| 项目分片 | `events.project`、`WorldFor`、按项目重放已经存在 | 清除外部入口的空项目全量回退;贯通基座项目与 RDM 项目;端到端鉴权 |
| 结构历史 | `eventlog.go`、`replay.go` 已有 seq、操作者、时间、来源、payload 和重放 | 原子批次、幂等、完整状态还原、对用户可读的时间线 |
| 现有界面 | `RDM:web/app.js` 有基线表、章节弹层、SVG 追溯图和多跳高亮 | 缺独立笔记树、统一审计页、完整项目上下文;合规图与导出尚未接入 Web |
| 基座审计 | `Host.Audit`、`audit_events`、`command_audit` 已有通用记录 | 缺显式项目作用域、结构事件关联、跨项目管理员查询及稳定分页 |
旧 `RDM:docs/design/data-model.md` 中“当前单 World、需求无产生路径”等结论已被后续代码改变,不作为当前缺口依据。
旧追溯网和受控合规图目前是分别维护的边集合;共用事件日志不等于已有一张覆盖所有对象的完整网。
### Material Gaps
以下为源码事实及控制流推导,失败/越权场景尚未动态重放。
| 编号 | 问题与依据 | 影响与处理 |
|---|---|---|
| G1 | `runtime.go:108` 空项目返回全库重放的 `rt.World`;`plugin.go:737` 的 trace/graph/hops 未检查 actor;实际 pinned Backend 的 `compiled.go:31` 和 `cmdbus.go:228` 没有领域项目授权 | 只隐藏页面入口无法隔离;旧命令、工具、图、计数、详情、导出均须使用同一服务端策略 |
| G2 | `web/app.js:69,170` 使用基座项目,命令不自动注入领域项目;`projects_api.go:43` 列出全部 RDM 项目 | 必须先建立项目身份绑定及授权后的目录,不能依赖前端选择器过滤 |
| G3 | `projects.go:18` 的 CreatedBy 与 `members.go` 的 owner 角色分离;`rdm_admins` 与基座 isAdmin 分离 | 按创建者事实授权;不能用“负责人”“成员”替代创建者;审计可见性按 KTD4 双层口径(基座超管+RDM 台账域管理员)执行,域管理员不因此获得平台管理权 |
| G4 | `notetree.go:77` 的入库/挂载逐事件提交;`tracenet.go:67` 的 candidate/confirm 分开提交;`Retag` 等先改内存再写日志 | 中途失败可能遗留部分事件或内存/数据库不一致;先补事务批次和提交后投影 |
| G5 | `compliance.go:170` 升版标 stale,但 `replay.go:230` 未对等重建;快照事件仅保存计数/hash;`replay.go:379` 正式版审签重建缺少时间/操作者 | 重启和历史回看可能与提交时不同;不得在修复前展示“历史已完整还原” |
| G6 | `conclusions.go:264` 取提案只有 id 没有 project 条件;`tracenet.go:59` 未校验关系端点归属 | 全部节点、版本、提案和关系必须在同一项目作用域解析;跨项目对象拒绝 |
| G7 | 成员/权限主要保存当前态;部分 `h.Audit` 错误被忽略;`review.go:95` 职责事件 Actor 使用受托编制人 | 补真实操作者与被操作主体分离、变更历史及可靠审计投递 |
| G8 | `Dev:modules/backend/internal/store/platform.go:187` 审计无 project 字段;命令审计按 owner/会话读取 | 不能按 target 字符串猜项目,也不能把创建者自己的动作记录冒充整个项目审计 |
### Requirements
用户明确的范围与权限优先于旧方案:RDM 负责领域,基座只补通用能力(session-settled: user-directed — chosen over 所有基座项目内建两树一网:用户选择完善 RDM)。
| ID | 需求 | 可判定验收条件 |
|---|---|---|
| R1 | 每项目独立两树一网 | A 项目查询、遍历、计数、详情、历史、导出均不出现 B 项目对象;跨项目建边被拒绝 |
| R2 | 仅项目创建者和系统管理员查看追溯审计 | 创建者可读所建项目;RDM 域管理员与基座超管可读全部;非创建者负责人、成员、非成员均不能访问审计能力;域管理员不因此获得平台管理权 |
| R3 | 展示来源与影响 | 任一支持的对象能查看来源、去向、版本与待确认关系,并打开有权限的证据 |
| R4 | 操作记录直观可读 | 能回答谁、何时、改了什么、为什么、结果如何;未知信息明确标缺失 |
| R5 | 历史真实且可重建 | 同一项目同一 seq 下,重启前后节点/关系/版本/审签/缺口一致;不可重建时明确报错 |
| R6 | 提交与记录一致 | 单命令多事件全部提交或全部不生效;重试不重复生效;并发覆盖返回明确冲突 |
| R7 | 简单、渐进展示 | 默认显示摘要、树和所选对象的一跳关系;不强制用户理解节点类型、内部事件码或原始 JSON |
| R8 | 可导出可复核结果 | 导出绑定项目、截止 seq、对象版本、规则版本、身份与生成时间;文件下载再次鉴权 |
| R9 | 复用现有能力和开发边界 | 保留 RDM 模型/计算/导出器,基座扩展经公开契约交付;无下游导入基座 internal |
| R10 | 历史数据及私人资料有清楚边界 | 未归属记录不自动塞入默认项目;项目审计不绕过私人原文访问控制 |
R2 约束项目审计中心及能返回等价审计数据的接口;普通文档阅读、协作、合法的引用展示继续遵守既有业务权限,不能顺手全部收紧为创建者专属。
模型工具同样受调用者权限约束,不通过智能体转述绕过审计读取限制。
---
## Planning Contract
### Key Technical Decisions
以下为待评审的推荐技术决策;只有显式 session-settled 标注的用户选择已在本轮确认。
- KTD1. **项目为隔离根,逻辑分区共享存储。** 查询及复合键携带实例域与 projectId;项目内对象采用稳定 ID,受控对象另带不可变版本。关系两端在同项目内解析,项目归属创建后不随意改动。共享模板/法规以固定版本引用或项目内快照进入,保留来源;第一版不建立项目 A 到项目 B 的业务边。
- KTD2. **复用两套图,通过读适配器形成统一项目视图。** 一般事实关系与受控合规关系保留不同确认及版本规则,避免一次重写两套存储。统一对象引用包含项目、类型、ID、版本、图层,防止 ID 碰撞或把不同版本误并为一个节点。`candidate` 显示“待确认”、active 显示“已确认/已生效”、retired 显示“已废止”;stale 显示“依据版本已变更”。不将模型候选画成已生效事实。
- KTD3. **一个服务端授权入口。** RDM 审计能力判定为“可信认证主体是 RDM 域管理员或基座超管(isAdmin),或等于项目 CreatedBy”。CreatedBy 固定;负责人调整不转移此权利。另设审计 read/export/history 能力映射,普通成员不能被项目负责人额外授予这些能力。权限异常拒绝读取,授权后的项目范围再进入存储,禁止先读全量后前端过滤。
- KTD4. **双层管理员:基座超管保底+RDM 台账域管理员。**(session-settled: user-directed — chosen over 两套真值完全分离与基座 isAdmin 单层直通:用户 2026-10-11 评审裁定)基座提供认证身份;基座 isAdmin 作为超管始终可查看全部项目审计,是跨项目审计的保底入口。RDM 现有唯一管理员台账继续判定域审计管理员:域管理员可读全部项目,但不因此获得平台用户/插件等管理权。基座管理区承载的 RDM 审计分区对两类管理员开放;capability 仍由服务端下发,前端只消费、不自行合并角色。历史身份不一致需显式核对,不自动提升为域管理员。普通 project.create 不自动引导域管理员;首个域管理员经受信部署引导产生,初始化唯一性由事务及数据库约束保证。台账为空、多管理员或来源不明时,域管理员路径关闭等待授权核对,超管保底路径不受影响。超管的审计访问同样落入动作审计并标记身份层级。
- KTD5. **基座项目与 RDM 项目显式一对一绑定。** 新增受约束的 hostProjectId 映射并带实例域;查询会话/工件所属基座项目后解析到 RDM 项目。不得用项目名称或默认第一个项目推断。两库创建无法单事务时用可恢复的 provisioning→ready/failed 流程和幂等标识,绑定未就绪不开放审计。EXT-8 共享资源检查使用映射后的领域项目,但不扩大成审计授权。
- KTD6. **项目命令原子写,事件为结构历史依据。** 在 RDM 存储事务内验证预期版本、端点归属与幂等键,一次提交整批事件、必要台账和 outbox;提交后更新内存投影。缓存失效或更新失败时重建,不暴露半新状态。关键事件落库失败则命令失败;跨库基座审计通过可靠 outbox 补送,不能用两次独立写入冒充事务。
- KTD7. **历史按项目+截止 seq 固定。** 可见水位只取已提交操作批次的结束 seq,时间按批次提交时间解析;显式 seq 落入批次内部时拒绝并提示可选的完整水位,不展示半次操作。保留当前全局 seq 的顺序语义,项目过滤后允许 seq 有间隙,不把它当作丢事件。快照保存完整节点/版本/边/审签/规则版本及哈希,含事件 schemaVersion;只有计数的旧快照不可作为恢复依据。未知事件版本须停止还原并说明缺口,不能静默跳过。
- KTD8. **先沿用单实例,再与团队 PG 方案衔接。** RDM 当前领域库仍是 SQLite,基座配置 PG 不会迁移它。先修事务和项目串行写入;团队档上线前将 RDM 权威事件/台账纳入有唯一写入 owner 的 PG 存储适配。多实例需数据库发号/并发控制及缓存刷新验证,不因基座支持 PG 就宣称 RDM 支持多实例。
- KTD9. **当前项目公开事实与私人过程分开。** 项目创建者能看项目审计,不因此得到成员私人会话/原件全文。内部重放载荷与对外审计 DTO 分离,原始 payload 不直接返回。摘要、正文、差异、历史快照和导出中的复制内容统一进行披露检查:当前来源 ACL 允许,或存在可核验的项目发布快照,方可输出。旧数据无来源/发布依据时默认遮蔽并标“来源受限/归属待核实”,不泄漏标题、摘要或路径。管理员看全部项目审计,仍不把凭证、模型隐藏推理或无关私聊放进审计输出。
### Architecture
```mermaid
flowchart TB
U[创建者:自己项目 / 域管理员与基座超管:全部项目] --> A[认证身份 + 审计能力校验]
A --> P[解析当前项目绑定]
P --> Q[RDM统一审计读服务]
Q --> N[笔记树与文档树投影]
Q --> G[一般追溯与受控合规图适配]
Q --> H[事件历史与完整快照]
Q --> B[基座动作审计:经授权关联查询]
Q --> V[同一追溯审计工作区]
```
两树说明“资料怎样整理、文档怎样组织”;关系说明“依据来自哪里、影响到哪里”;审计说明“谁在什么时候作出了什么变更”。
它们共用项目和对象身份,各回答一个问题,不要求用户先学习图数据库概念。
### Data and Event Contract
领域事件补足项目、operationId/requestId、真实 actor、actorType、被操作主体、对象版本、发生时间、提交 seq、原因、事件 schemaVersion,以及必要的前后差异。
一个 operationId 关联多个结构事件和基座动作审计;前端按一次操作归组,技术明细按需展开。
纠正错误通过新事件完成,保留更正者和原因;关系失效、软删除和权限变更不覆盖原历史。
权限变更审计保留当时的政策版本/决策摘要,便于解释过去为何允许;**现在能否查看**仍按当前权限判断。
前端自报审计只能标为客户端报告,不得伪装成服务端核实的批准或业务成功。
普通 hash 用于校验导出/快照一致性,不宣称具备防数据库管理员篡改或电子签名保证。
```mermaid
sequenceDiagram
participant C as 调用者
participant A as RDM命令应用层
participant D as RDM存储
participant B as 基座审计
C->>A: 项目、操作、预期版本、幂等键
A->>A: 当前授权与同项目端点检查
A->>D: 原子提交事件批次、幂等结果、outbox
D-->>A: 已提交seq及结果
A-->>C: 业务结果与可追溯操作编号
A->>A: 刷新或重建项目投影
D->>B: outbox可靠补送关联审计
```
基座暂不可用时,已提交结构事实继续保存,动作审计显示“同步中”;恢复后幂等补送。
关键业务规则需要同一库的证据记录才能放行时,在业务事务内保存;不将异步投递当作批准的前提已满足。
导出需先固定截止水位、检查完整性;审计关联仍缺失时明确标为不完整,正式完整报告应阻止导出或要求用户选择带缺口的草稿。
### Read Interfaces
优先通过现有命令总线及页面 SDK 提供 RDM 查询,所有入口落到同一应用服务;不另建绕过权限的调试 API。
| 候选读契约 | 返回内容与限制 |
|---|---|
| inspect.capabilities / inspect.projects | 可见项目、当前项目是否可审计、是否可跨项目;管理员全项目目录独立分页 |
| inspect.summary | 两树规模、待确认关系、缺口、最新动作、数据截止水位;不把缺失当作零 |
| inspect.tree / inspect.object | 树子节点分页;所选对象版本、出处、状态;只展开需要的分支 |
| inspect.relations | 方向、图层、关系状态、版本、深度;默认一跳,后续点选扩展;有数量上限和截断提示 |
| inspect.events | 按项目、对象、时间、操作者、动作、结果过滤,游标分页;可展开一次操作的差异 |
| inspect.history | 固定 seq/基线下的对象、关系和当时规则;缺少重放材料返回明确不可还原状态 |
| inspect.export | 导出同一筛选条件和截止水位;生成、取状态、下载都重新校验主体及项目权限 |
分页游标绑定项目/筛选条件/排序/权限版本,不能拿 A 项目游标读 B。
缓存、导出缓存及订阅键包含主体能力范围、项目和截止水位,撤权后不可复用旧授权结果。
异步数据只有一个状态所有者:项目切换取消旧请求并递增 generation,过期响应丢弃;事件按 seq 去重、有序应用。
### Base Extension Requests
先验证现有注册点能否组合;不足部分按 RDM 的四要素扩展申请办理,保持公开面可选、向后兼容。
| 场景 | 希望的通用能力 | 现有能力不足 | 兼容方式 |
|---|---|---|---|
| 创建者看项目内所有人的动作 | 审计 envelope 的 projectId、operationId、对象版本及按项目查询 | Host.Audit 只有 owner/action/target/evidence;按 owner 会遗漏其他成员动作 | 增加可选的结构化审计能力/接口,不直接强改所有 Host 实现;旧记录标项目未知 |
| 宿主页面展示 RDM 审计入口 | 插件提供当前主体的审计能力和可见项目,宿主提供可信身份与项目上下文 | EXT-8 只有资源共享读取布尔判断;基座 AdminZone 仅看 isAdmin | 新增可选的动作级 capability/provider;不改变旧资源授权器含义 |
| 私人来源与项目发布证据联动 | 已授权工件/版本链接与受限占位,导出后下载再校验 | 不能让全项目审计器任意扩大 owner-scoped Host | 复用现有工件访问契约,仅按实测缺口增加窄接口;禁止任意 owner impersonation |
两树对象、边规则、合规矩阵和领域重放保留在 RDM,基座不内置这些领域表。
---
## Display Design
### Entrances and Layout
项目创建者从当前项目菜单进入“追溯与审计”;RDM 域管理员与基座超管从管理区“项目追溯与审计”进入项目目录,选定项目后复用同一页面。
管理员选择项目后,审计工作区的项目上下文必须更新为实际被审计项目,所有请求与标题保持一致。宿主支持审计项目切换时,项目身份集中显示在宿主项目位置;宿主不能切至该项目时,审计页必须显示明确项目标题和“返回项目目录”,并避免让宿主旧项目标题被误认为审计范围。管理员目录显示项目名、创建者、最近活动、待关注数量。
第一版为只读审计工作区,审批、确认关系和编辑仍跳回原受控业务流程,不在审计页面创造第二套写入口。
页面保留四个入口:**概览、资料与文档、关联追溯、操作记录**。
左侧按需显示笔记树/文档树导航;主区显示当前选择;对象详情在页面内展开,原件仍进入宿主唯一文件预览区。
不叠加弹窗,不默认铺满全部节点。
| 入口 | 默认看到什么 | 深入查看 |
|---|---|---|
| 概览 | 已收集资料、已形成文档、需要确认的关系、需要补齐的证据;最近几次重要变更 | 点击数字进入带筛选的列表;明确“统计截至…”和“不完整”状态 |
| 资料与文档 | 笔记树:阶段→事项→主题→资料切片;文档树:阶段→文档→章节 | 同一资料多个挂载不重复计数;缺主题可显示未分类,不伪造层级 |
| 关联追溯 | 所选对象居中,左右分别为“来源依据”和“影响对象” | 列表优先;切换为局部关系图;合规链/矩阵在此页按需切换 |
| 操作记录 | 自然语言时间线,按一次业务操作归组 | 展开前后差异、批准依据、对象版本与技术记录 |
### Human-readable Trace
关系展示示意,实际节点与连线必须来自已保存数据:
```mermaid
flowchart LR
A[会议纪要中的原文] -->|支持| B[用户需求]
B -->|落实到| C[方案章节 v3]
C -->|由此验证| D[验证记录]
```
点选“方案章节 v3”后首先看到:这是什么、当前版本、依据哪几条材料、影响哪几项需求/验证、最近谁改过。
缺少验证记录时显示“验证依据待补齐”,不画虚构的完整链;候选边使用虚线和文字“待确认”,不能仅靠颜色区分。
“没有已知关联”与“尚未完成关系索引/本次查询被截断”分开呈现。
关系被废止后可在历史模式中看到;跨版本关系明确标注版本,不让 v4 的证据替代 v3 的事实。
### Audit Timeline
时间线示意:
- 10:32 张三将《需求说明》从 v2 更新为 v3;修改了“使用环境”章节,依据为评审纪要第 4 条。
- 10:41 李四确认该章节与 UR-012 的关联;确认理由为“已覆盖用户场景”。
- 11:05 王五批准 v3;点击可查看批准时的版本和证据。
每条默认仅显示时间、操作者、动作、对象、结果;“查看变更”再展开前后差异与理由。
后台归档、重试等技术事件默认归组收起,失败、拒绝、未知结果有文字说明;原始 JSON 不作为主界面。
Actor 为真实执行者,Subject 为被分配职责或被变更权限的人,界面不混写两者。
默认显示北京时间并注明时区,底层保留 UTC;历史模式顶部醒目标注“查看截至某时间/某基线的记录”。
### Interaction Boundaries
提供“当前/历史”切换,历史可选择时间或基线;从批准记录可直接打开批准时的版本。两树、关系与记录共用一个截止水位,“返回当前”恢复对象当前版本;对象已删除则显示删除说明,不切到同名对象。
对象名称支持搜索;树节点懒加载;记录使用“加载更多”;关系默认一跳,上限和截断状态由服务端返回。
加载、空项目、无权限、部分数据、同步中、历史不可还原、请求失败分别展示,不都渲染成“暂无数据”。
首屏不显示 SQL、事件 opcode、内部 UUID、hash;复制技术编号放在详情中。
推荐验收任务:创建者在三次主要点击内找到某章节的原始依据和最近修改原因;管理员能清楚确认当前查看哪个项目。
实现遵循 `Dev:DESIGN.md`:颜色/圆角/字号消费 `@ui` 令牌;折叠用 Collapsible;动效只用 `mk-*`;键盘可导航,状态同时有文字与形状。
优先在当前宿主工作区体系内以 RDM 插件页面提供,避免长期维护第二套静态工作台。
旧 `web/app.js` 保留过渡兼容范围,但图与审计能力接同一授权服务;最终页面交付形式在 U4 固定,不能假设在途 Generative UI 已能直接承载。
---
## Implementation Units
本批默认顺序:U1→U2→U3→U4→U5,按 `policy/delivery.md` 分增量评审。U6 是独立后续衔接项,不纳入本批完成条件。
U1 是首选下一任务;这份方案不构成启动它的授权。
### U1. 项目身份与读取授权闭环
目标/需求:R1、R2、R9、R10;依赖:方案已批准(2026-10-11)、KTD4 已按双层口径裁定;剩余既有项目映射盘点在立项时完成。
范围:`RDM:internal/projects`、`members`、`perms`、`rdmapp/runtime.go`、`projects_api.go`、`perms_api.go`、`plugins/rdm/plugin.go`、`web/app.js` 的旧客户端项目上下文;测试 `rdmapp/perms_test.go`、`sharding_test.go`、`plugins/rdm/plugin_test.go`;必要基座 capability 扩展单独申请。
建立显式项目绑定;增加审计读取策略和管理员受信引导门禁;统一包裹旧/新 trace、cgraph、项目列表、历史和导出入口。
U1 同批接通旧客户端的项目选择和命令封装,并解析可信会话/工件上下文到显式绑定;随后启用对外 projectId 必填门禁。无映射时显示“项目待绑定”,不回退全量世界。仅管理员专用迁移/调查路径能够处理未归属域,并单独留痕。
检查结论提案、引用、关系两端和版本归属,不接受来自别的项目的 ID。
普通文档协作仍使用原业务权限,避免用审计策略误封工作流程。
验证:创建者、非创建者负责人、成员、非成员、RDM 域管理员、仅基座超管六类主体(后两类均为跨项目审计正例,域管理员访问平台管理分区须为负例);空项目、伪造项目、跨项目对象、旧命令/模型工具绕过、撤权后的新请求与下载均有正负例。
增加首次启动、恢复后空台账、并发初始化、普通建项目不提权的验证。
完成条件:至少两个项目、多用户、真实认证入口下全部读取边界可复核;不依赖隐藏按钮。
进展(2026-10-11,RDM PR #195 merge 05b7d1a):U1 已实施合入——审计判定统一入口(创建者∨域管理员∨超管槽,`AuthorizeAudit`/`AuthorizeCmd`,命令面全接线,空 projectId 显式拒绝);KTD4 双层管理员落地(`rdm_admins` 单行台账+`-bootstrap-admin` 受信引导,`project.create` 不再自动引导);KTD5 宿主显式绑定(`rdm_host_project_map`+`rdm.project.bind/unbind`+EXT-8 映射解析+上传可信上下文解析);项目列表按主体过滤;旧客户端 `web/app.js` 统一注入 projectId。两项基座扩展申请已随该 PR 落盘(`RDM:docs/proposals/2026-10-11-u1-base-extension-requests.md`):超管槽在基座能力发版前保持 fail-closed,「仅基座超管」负例†待接线翻正;真实认证入口运行验收随 U4/U5 复核。
### U2. 原子事件与历史还原
目标/需求:R5、R6、R10;依赖:U1 的项目合同。
范围:`RDM:internal/domain/{eventlog,notetree,doctree,tracenet,compliance,replay,persist,review}.go`、`domain/store/store.go`、`rdmapp/conclusions.go`、`upload.go` 及上传状态台账,对应 `persist_test.go`、`integrity_test.go`、`compliance_test.go`、`conclusions_test.go`、`upload_test.go`。
补事件批次事务、项目内写入串行/预期版本和操作幂等;内存变更置于提交之后。
上传原件先不可变留存,再由同一 RDM 数据库事务发布引用、状态、项目归属、切片关联、pending 关闭和幂等结果;meta.json 降为可重建镜像。上传确认/拒绝中断后按操作结果恢复,不重复入库;此项在 SQLite 首期完成,不等待 U6。
修复升版 stale、正式版审签元数据和完整快照重放;记录成员/权限/职责变化及真实 actor。
建立结构事件到基座审计的 outbox,显示投递状态;旧缺失事实明确为不可恢复,不能补造批准人或时间。
验证:第二条/最后一条事件失败、提交后进程退出、投影刷新失败、相同请求重试、并发同版本更新;重启前后对节点/版本/边/审签/缺口深比较;旧快照与未知 schemaVersion 明确拒绝冒充完整;历史/导出截止落在批次中间时拒绝,上传发布/确认中断后状态与切片不重复、不矛盾。
完成条件:命令结果、持久记录、重建投影一致,故障不造成不可解释的部分成功。
### U3. 统一项目审计读服务
目标/需求:R3、R4、R5、R8;依赖:U1、U2。
范围:`RDM:internal/rdmapp/trace.go`、`baseline.go`、`cgraph_export.go`、拟增 inspection 读投影;`plugins/rdm/plugin.go`;测试 `trace_test.go`、`chainviews_test.go` 及新增 inspection 集成测试。
把两树、一般关系、受控关系、结构事件和基座动作记录适配到统一对象详情及分页查询。
为查询绑定项目、当前授权、截止水位及版本;返回覆盖状态和截断状态。
补公开面需要的 project/operation 审计查询与能力 provider;不从字符串解析项目归属。
验证:旧网和合规网的同名 ID 不冲突,历史 v3 与当前 v4 不串用;未知/受限来源在旧 payload、差异、快照及导出副本中也不泄漏;游标换项目拒绝,分页期间新增事件不重不漏;动作审计同步延迟可见。
完成条件:无需读数据库即可通过受控接口回答来源、影响、变更与历史问题。
### U4. 项目追溯审计工作区
目标/需求:R2、R3、R4、R7;依赖:U3;页面载体在本增量设计评审时固定为宿主支持的 RDM 插件工作区。
范围:RDM 页面资源及宿主注册声明;必要时 `Dev:modules/frontend/src/components/{Workspaces,AdminZone,adminSections}.tsx`、`store.ts`、`api.ts`;交互测试沿用 frontend test/e2e 体系,旧 Web 的兼容测试留在 `RDM:web/workbench_test.mjs`。
实现四入口、两树导航、对象详情、一跳关系和自然语言记录;普通用户无入口且接口拒绝。
管理员目录按授权后的项目查询,选项目复用页面;RDM 管理 capability 不解锁其他平台管理分区。
沿用宿主文件预览、令牌和折叠;删除/替换旧重复图入口需另列兼容清单。
验证:真实浏览器完成来源查询、选择历史时间/基线并返回当前、管理员从宿主 A 打开审计 B 后标题和请求一致;模拟慢请求后快速切项目无串页;键盘、窄屏、长标题、千级节点懒加载、空/失败/受限/不可还原状态可理解。
完成条件:用户按三次主要点击任务完成取证,并人工评审界面是否直观;业务可用与视觉通过分别记录。
### U5. 历史导出与正式集成验收
目标/需求:R5、R8、R9、R10;依赖:U2、U3、U4。
范围:`RDM:internal/rdmapp/{cgraph_export,docx,xlsx}.go`、页面导出入口、导出临时工件及下载授权;测试 `domain/export_test.go`、`plugins/rdm/xlsx_export_test.go` 和浏览器下载场景。
复用 docx/xlsx 导出器,固定项目/版本/规则/截止 seq,补证据来源清单和完整性说明。
导出按请求身份和范围生成,撤权后下载失败;历史受限来源不随导出泄漏。
固定基座发布版本、RDM pins 与页面资源组合后,重放真实端到端流程。
验证:导出中途有新写入不改变已固定内容;历史来源软删除仍可按授权追溯;未归属/缺失事件可见;跨项目下载、过期下载、权限撤销均拒绝。
完成条件:同一版本在 UI 与报告中结论一致,并有正式 GATE/REPLAY 证据。
---
## Deferred Integration
### U6. 团队部署存储衔接(独立后续任务)
本项不纳入 U1–U5 的默认实施与验收范围,另经团队存储方案授权后立项。
目标/需求:R1、R5、R6、R9;依赖:U2,以及[多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md)适用增量。
范围:RDM 领域 store/迁移、项目/成员/权限/结论/慢通道台账、上传原件与导出清单;基座只补通用连接/生命周期公开契约。
明确 RDM SQLite 与团队 PG 的适配和备份清单,避免一半事实在 PG、一半未受保护地留在本机文件。
先验证单实例团队档;多实例的发号、执行所有权、缓存失效与故障恢复在独立验收前保持关闭。
本次不复制基座在途 PG 档位和迁移能力,也不把基座 PR 完成当作 RDM 迁移完成。
验证:真实 PG 的隔离/事务/重放、迁移前后对象与事件数及哈希对账、备份恢复含原件;PG 不可用不静默退回空 SQLite。
完成条件:团队部署具备明确权威存储与恢复证据;若本批仅交付单实例 SQLite,验收报告必须声明该限制。
---
## Migration and Delivery
历史归属先做只读盘点:未归属事件、缺少项目绑定、对象依赖闭包、旧快照和私人来源。
现有 seq 区间迁移接口不能作为任意截取的安全保证;归属以完整对象及依赖闭包为单位校验,并保留批准映射和原因。
不把存量自动分给首个项目,不根据当前 owner 猜历史创建者。
迁移前保存备份和对账清单,在隔离副本上验证,再取得共享环境迁移授权。
采用新增字段/投影、保留原事件、按项目启用;观察期内可关闭新页面和新读取投影,但不能恢复越权的全量读取入口。
停止条件:发现跨项目泄漏、重放不一致、无法确定历史归属、投影滞后超出可解释范围或恢复失败;保留现场和失败证据。
跨仓顺序为基座扩展申请→基座实现/测试/发布→RDM 升级固定版本→RDM 集成验证→Dev 文档与组合记录更新。
必要令牌调整按 DESIGN.md 成对关联 UI 与 Dev 组合;仅消费令牌时不制造无关令牌 PR。
在途核对(本次 Gitea API 只读,SELF;实施前须刷新):Dev #325 为团队 PG 档与迁移组合,#317 为服务启动 DSN;RDM #194 为已合入 xlsx 工作的任务卡闭合,不能重复安排 xlsx 从零实现;Backend、Documents 查询未返回开放 PR。
关联规划为 RDM 阶段总案 P3/MS3、U0 项目共享合同、V2.2 合规图方案和上述团队存储方案;本案补充集成/授权/显示,不声称这些里程碑已验收。
---
## Verification Contract
以下为实施时的验收计划,本轮结果均 NOT_RUN;文档自检另以任务收据记录。
| 组 | 覆盖需求 | 最小可复核场景 |
|---|---|---|
| 授权/隔离 | R1、R2、R10 | 六类角色×两个项目;列表、统计、详情、关系、历史、工具、导出、下载、订阅均验证;普通文档协作无误封 |
| 数据完整性 | R3、R5、R6 | 跨项目提案和边拒绝;多事件中途失败;重试/并发;重启及指定 seq 深比较;完整快照哈希 |
| 真实业务闭环 | R3–R6 | 项目创建→纪要入库→切片→需求→章节 v1→依据变化→v2→审签→历史回看→报告;缺失链节明确显示 |
| 可用性 | R4、R7 | 创建者找依据/变更原因,管理员选项目,键盘/窄屏/长文本,加载/失败/受限状态,过期响应丢弃 |
| 导出 | R8、R10 | 同一 cutoff UI/报告一致;创建与下载分别鉴权;撤权/受限来源/不完整记录不泄漏或冒充完整 |
| 组合与运行 | R9 | 固定 Backend/Core/Frontend/UI/RDM SHA;RDM 测试与构建、Dev 适用组合检查;部署后二进制身份和真实浏览器路径 |
| 团队档(U6另行立项时) | R1、R5、R6 | 真 PG、迁移与恢复;单实例和多实例证据分别记录,无变量或无环境即 NOT_RUN/SKIP |
性能建议作为待批准目标:单项目 1 万对象/5 万关系、100 万事件的样本;首屏仅取分页摘要与当前树分支;普通分页查询 P95≤1s,首屏可操作≤2s。
记录实际硬件、数据分布、过滤条件和组件版本,不能以空库或缓存命中替代容量结论。
正式审核先重放最小集再读作者证据;来源标记遵循 GATE/REPLAY/SELF,用户界面演示与正式验收分开。
---
## Definition of Done
本方案阶段完成条件:现状依据可定位、原有能力不重复建设、项目和角色边界明确、展示可理解、工作项与验收对应;r1 已于 2026-10-11 经用户评审通过(五阶段一并,含 KTD4 双层管理员裁定)。
实现阶段完成条件:R1–R10 对应证据齐备,固定组合通过正式测试和独立审核,部署与浏览器验收有独立记录;源码存在不等于完成。
已裁定决策:KTD4 采用双层管理员——基座 isAdmin 超管保底+RDM 台账域管理员(session-settled: user-directed,2026-10-11)。剩余待定决策:RDM 宿主工作区入口的具体交付契约(U4 设计评审时固定);U6 如需提前并入本批,应另行批准范围及目标环境,默认不包含。
推荐先批准 U1 的细化设计与测试范围;U2–U5 按依赖逐阶段评审,U6 单独立项,不把本轮范围确认当作连续实施授权。
后续再考虑跨项目引用审批、全局关系图、电子签名/外部防篡改存证及复杂图分析;这些不属于首个可用闭环。
+14 -1
View File
@@ -6,12 +6,17 @@
## 先看哪一份
新增方向(已裁定取舍;U1 试验完成,r2 含结果与修订):[Generative UI 调研与插件方案 r2](2026-10-10-generative-ui-plugin.md)。
首试点为对话内完整分析页,交付采用可信编译插件;U1 试验限 MiniMax M3 + M2.7-highspeed、合成或脱敏材料、费用上限 ¥200,作为独立任务另行评审启动。
此记录独立于下方历史核验快照,不改写历史方案/PR 数量或验收结论。
| 要回答的问题 | 主记录导航 | 规划中的阶段 | 原文负责人 |
|---|---|---|---|
| 通用系统的原始边界与架构是什么 | [系统骨架](2026-09-29-system-skeleton-design-and-plan.md),结合下表专题修订 | 骨架 P0–P5;D1–D16 | weichen |
| 基座与下游如何分工,如何申请扩展 | [基座路线图](2026-10-01-base-extension-roadmap.md),配套插件契约与兼容规则 | 公开扩展面、插件 v2、质量回路、工程基座 | weichen |
| 三个智能体库如何继续演进 | [Agent 栈总案](2026-10-02-agent-stack-completion.md),阶段细化见 N1/Q1/I1、N2、N3、Q2/Q3 | R0/R1/D1、N1–N3、Q1–Q3、I1–I2、阶段评测 | weichen |
| RDM 下游的大目标和消费者里程碑是什么 | [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) | P0–P4,对应 MS0'、MS1–MS4及发布前置 | weichen |
| 10–100 人协作与未来分布式如何演进 | [协作存储与分布式方案](2026-10-11-collaboration-storage-and-distribution.md) | 团队 PG 档 → 迁移恢复 → 多实例执行与故障验收;r1 已批准(2026-10-11),实施自 U1+U2 启动 | 需求:weichen;实施/运维待指定 |
以上是依据文内显式范围和引用形成的阅读入口,不是新增优先级或批准结论。N2 阶段案未单列 owner,
应由负责人补齐;不能仅凭任务创建人推断全部规划的负责人。
@@ -77,7 +82,7 @@ Dev 链接均指向对应任务 PR,可从其任务卡继续追溯组件 PR;
| [智能体工作流质量改进](2026-10-09-agent-quality-improvement-plan.md) | 直连主路径质量:诊断→六项裁定→P0–P5 分期 + 模型 A/B;推翻 fs 工具默认关闭裁定 | 已获实施授权(2026-10-09 六项裁定);首个增量 feature/agent-quality-phase01 | 随本提案 PR;诊断 SELF(真实运行转录);基线报告见任务卡 |
| [EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md) | RDM 多人共享契约的基座最小扩展申请(EXT-6…EXT-12):身份停用/受管配置/授权适配器/索引发布/分发守卫/Host 工厂/投影过滤 | proposed;需求依据=RDM U0 主记录(D1–D9 裁定,2026-10-08 合入) | 随本提案 PR;每条现状证据为 SELF·源码级(Dev 34a2bbe/backend fe7c245),运行态 NOT_RUN;受理后逐条另立实现任务 |
| [EXT 申请包 G1](2026-10-09-ext-g1-b1-b3-exec-backend.md) | EXT-13…16:回合内共享检索、命令即工具、项目列表共享、执行后端接口 | proposed;需求依据=RDM 方案 V1.1 §3.3/§3.4/§5.3(2026-10-09 批复) | Documents [#52](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/52) 已合入;EXT-16 已实施(Dev #285,见其任务卡),其余受理评审待定。本行由本次索引维护补充 |
| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录:委派契约与角色路由方案(E1–E5 增量)+ 任务工作区沙箱设计(仅记录不实施);修正 overlay≠快照等三处假设 | proposed(2026-10-10,方向来自用户会话,未获批实施);快修项 E1 待授权 | 随本提案 PR;现状核查与启动延迟为 SELF(任务卡 evidence);外部来源 URL 全量随任务卡 |
| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录:委派契约与角色路由方案(E1–E5 增量)+ 任务工作区沙箱设计(仅记录不实施);修正 overlay≠快照等三处假设 | proposed(2026-10-10);E1、E3、E4(R4+账本)、E5(R3)、S0-1 已完成(E4:Dev #315;S0-1:Backend #135/#136、Dev #318,2026-10-11);E2 暂缓(模型指示)、S0-2 待授权 | 随本提案 PR;现状核查与启动延迟为 SELF(任务卡 evidence);外部来源 URL 全量随任务卡 |
原查询的 19 份原文中,14 份显式标注 owner 为 weichen。双档存储、启动配置面、跨会话读取、文件预览和
N2 实施案这五份未单列 owner,其中预览案仅写“作者:weichen + Agent”。同步新增的 N3 与 Q2/Q3 案页首也未单列 owner。
@@ -153,3 +158,11 @@ RDM 总案把库分期作为支撑与依赖,不覆盖库分期的原始范围
后续维护:主案或任务变化时先更新其唯一主记录,再更新这里的导航和核验快照。
更换 Docs/Dev 基线后重新核对 PR、版本与在途任务;新的索引状态不自动产生实施授权。
## 2026-10-11 规划补充
- [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md):对应 P3/MS3,源码已有部分实现;优先补项目绑定、创建者/管理员读取隔离与历史完整性,再接统一展示。用户确认范围为 RDM 与必要基座能力;r1 已获用户评审通过(2026-10-11,五阶段一并,含 KTD4 双层管理员裁定)。U1 项目身份与读取授权闭环已实施合入(RDM PR #195,2026-10-11;超管槽待基座能力接线,见 RDM 仓 U1 基座扩展申请);U2–U5 与运行验收未启动。
- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md):69 类旧资产、4 个当前注册模板的盘点及生成闭环设计;待评审,实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认(2026-10-11),其余方案与实施仍待评审。
- [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md):本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界;覆盖 34 UR/68 SR/10 F、全部69类模板及现有XLSX,当前源复核 RDM d8d7e743。总体方案待评审,实施/迁移/运行验收 NOT_RUN;模板方案为子方案。
File diff suppressed because one or more lines are too long
@@ -0,0 +1,31 @@
# 协作存储方案 r1 静态审阅记录
对象:[方案 r1](../proposals/2026-10-11-collaboration-storage-and-distribution.md)。
日期:2026-10-11(Asia/Shanghai)。来源:SELF,Agent 辅助静态审阅。
三个 Agent 分别兼任两个视角:coherence/scope-guardian、feasibility/adversarial、security/product。
同一 Agent 的两个视角不互相独立;没有跨模型审阅、独立测试重放、CI GATE 或人工批准。
使用 ce-doc-review 的检查视角,覆盖与边界以本记录为准,不声称已运行额外外部模型审阅。
## 发现与处置
| 发现 | 原方案后果 | 修订处置 | 复核 |
|---|---|---|---|
| 正式导入与非空目标拒绝冲突 | 预演后可能无法最终导入,或放宽规则混入其他快照 | U4/§6 分开预演与正式空目标;migration_id+快照身份,只有同快照可续传,验证完成后切入口 | 原审阅 Agent 已确认文本闭合 |
| 恢复隔离晚于首期切换 | 现有 ResumeInterruptedChildren 可能自动重派未知副作用任务 | U3 前移持久 recovery hold,启动续跑跳过,U7 放行前验证 | 原审阅 Agent 已确认文本闭合 |
| 命令只绑定旧 epoch | owner 切换后取消或审批意图可能丢失 | KTD5 区分逻辑 run 取消、gate/version 审批与按 epoch 验证的执行结果 | 原审阅 Agent 已确认文本闭合 |
| 父子共享额度可能互等 | 父 run 占满许可并等待不能启动的子 run | §3/U3 区分接纳数与执行许可,等待父 run 让出许可但保留会话所有权 | 原审阅 Agent 已确认文本闭合 |
| U6 先于 outbox 依赖 | 提前声明事务投递机制完成或重复建设 | U6 分追赶修复、outbox、向量三个切片并分别列前置 | 原审阅 Agent 已确认文本闭合 |
| P0 权限检查落到后期 | 首期团队版可能未验证 SSE/检索/工具撤权 | U7 单实例放行前验证完整现有 R6 入口矩阵;新增跨机能力另验 | 原审阅 Agent 已确认文本闭合 |
| 过渡期本地权威未说清 | 尚未迁移的 checkpoint/续跑文件可能被当缓存清除 | KTD2 增加首期与多实例期归属表,联合备份,U5 前禁止跨机接管 | 原审阅 Agent 已确认文本闭合 |
| 只读适配器不足以判断写入/审批 | 可能把共享可读扩大成可写 | KTD13/U3 指定动作授权矩阵、版本化兼容与默认拒绝,不新建成员权威 | 原审阅 Agent 已确认文本闭合 |
| 迁移/备份敏感副本保护未列 | 源库秘密可能经备份旁路暴露 | KTD14 指定访问、加密、密钥分离、保留与恢复验证;正式导出前缺项阻塞 | 原审阅 Agent 已确认文本闭合 |
主编另依据 PostgreSQL 官方 PITR 文档修正备份描述:pg_dump 是逻辑备份,不能作为 WAL 回放基础;PITR 使用物理基础备份加连续 WAL。未改变用户确认的规模与未来分布式方向。
## 剩余决策与验证边界
- 10–100 人、多项目、多会话及未来多服务分布式:用户已确认需求方向。
- 量化容量/恢复目标、正式实例和数据归属、迁移窗口、资源与实施阶段:待人工评审。
- 本记录只说明文档中的九项问题已经改写并由原 Agent 复读,不说明实现缺陷已修复。
- 实施、真实 PG/Redis 测试、压测、故障注入、数据迁移、恢复演练与部署:全部 NOT_RUN。
- 方案正文与调查收据的字节摘要由文档检查命令写入 Dev 任务卡,作为本次候选身份;本文件不手写命令结果。
@@ -0,0 +1,14 @@
# 最终目标方案文档审阅记录
对象:[总体方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)与[112 项需求矩阵](2026-10-11-rdm-final-target-requirements-matrix.md)。日期 2026-10-11。
等级 SELF:三组本地模型阅读,覆盖一致性、可行性、产品、范围、交互、权限与失效场景;不是人工批准、独立 GATE/REPLAY 或业务验收。未执行跨供应商审阅。
审阅前增量复核 RDM 从 0081628a 到 d8d7e743 的变化:保留已新增 HostBinding、项目命令守卫、上传项目约束和单行管理员引导事实,不继续按旧缺口排重建;仍需宿主绑定双向权限、成员工作目录与文档资源/职责授权,已进入 G 表及 U2/U3。
| 发现 | 后果 | 已作修订 |
|---|---|---|
| U7 全模板真实验收是 U8 生成能力的前置,形成相互等待 | 可能以静态注册检查冒充全量模板可用 | U7 收敛为全量台账/公共契约/两模板;U8 首批闭环;新增 U16 全文档族迁移验收;U14 等 U16 |
| U8 首批竞品模板含法规要点,却未依赖 U12 | 可能用模型URL或单通道占位完成首批 | U12 加入 U8 前置,同步依赖表和说明,保持无环 |
最终产品/范围/交互复核未提出其他实质问题,34 UR、68 SR、10 F 编号集合无缺项/重复;全部69类及XLSX目标未缩水。权限/失效场景复核确认私域与授权知识快照、三权、防换角色自审、撤权、宿主双向绑定等约束已表达。
本记录仅证明文档检查及相应修订;实际执行能力、测试通过、部署和用户验收均未据此认定。
@@ -0,0 +1,136 @@
# 最终目标逐条覆盖矩阵(2026-10-11)
主记录:[完整交付方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)。来源:RDM `docs/requirements/01-用户需求与系统需求.md`(V2.2)及 README/U0/Q 裁定;复核 RDM d8d7e743。
34 UR、68 SR、10 F 均保留原编号。以下为 SELF 源码级盘点,当前运行验收均 NOT_RUN;“已有”不等于已验证/部署,“后移”不等于取消。摘要仅用于定位,语义以原文和用户确认 D1–D6 为准。G/U 均指主记录。
## 系统需求(68 条)
| ID | 原文摘要 | 当前源码级情况 | 仍需完成 | 工作包/差距 | 原文行 |
|---|---|---|---|---|---|
| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传,对不支持格式仅提醒不阻断 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 431 |
| SR-A2 | 上传不强制附带文字指令;无指令时进入默认"记忆构建"流程(见 SR-B 系列),不输出制式化"未识别需求"回复 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 432 |
| SR-A3 | 支持单文件、多文件批量上传,并记录来源渠道(Web/飞书/其他)与上传人 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 433 |
| SR-A4 | 上传后 60 秒内输出第一阶段反馈(相关性结论 + 初步阶段归类);完整入库允许后台异步完成 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 434 |
| SR-A5 | 入库完整性保障:解析失败、部分内容不可解析或入库异常时,必须显式告知用户并在入库记录中标记,原始文件永久保留可取回;禁止静默降级或静默产出残缺结果(教训来源:旧版曾发生报价单 Excel 数据丢失、P… | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 435 |
| SR-B1 | 对每份上传资料输出相关性判定(相关 / 存疑 / 无关)及判定依据;存疑时必须挂起并向用户请求确认,确认前不入库 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 441 |
| SR-B2 | 对资料进行结构化解析,保留章节/页/表格级锚点,锚点在后续所有引用与追溯中可用 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 442 |
| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项",映射结合项目当前所处阶段;支持一片段映射多阶段 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 443 |
| SR-B4 | 每个切片附带结构化标签(JSON):阶段、工作事项、主题、可行性维度(技术/市场/注册)、关联需求 ID、来源、上传时间、置信度;并生成一句话描述(description) | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 444 |
| SR-B5 | 支持"两速入库":快速通道(打标签 + 摘要 + 入库)先行返回,慢速通道(细切片、嵌入向量化)后台补齐,状态对用户可见 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 445 |
| SR-B6 | 入库完成后向用户输出勾连总结:本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节,以显式清单呈现 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 446 |
| SR-B7 | 会议纪要类资料按同一管道处理,并可抽取"结论 / 待办 / 待确认"三类条目 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 447 |
| SR-B8 | 笔记树内一致性检测:同一主题簇下多个切片的陈述不一致(如多人表述冲突)时,系统检测冲突 + 记录入追溯网(何时/何人/何节点/何操作)+ 通知触发冲突的用户 + 挂起待裁决;智能体不自行处理冲突,裁决… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6;G11 | 448 |
| SR-B9 | 并发更新冲突避免与及时提示:多人几乎同时更新同一树节点时,系统忠实记录全部操作入追溯网,冲突以候选子节点组并存挂起,智能体不自行处理冲突;裁决集中在编制人发起编制时经 HITL 完成(裁决两层,规则同… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6;G11 | 449 |
| SR-B10 | 任务快慢双速:对用户任务按快慢双速模式执行——快通道同步短链路即时反馈(如上传文档→相关性判断→相关给概要/不相关给理由+相似文档供选择),慢通道小队(subagent)后台深度执行(逐页解析、建节点… | 内存队列/台账已有 | 持久输入、取消恢复、幂等与通用双速未完成 | U9/U13;G15 | 450 |
| SR-B11 | 结论节点:结论作为笔记树的节点类型保存(结论入树);结论节点与切片同受 08 R1–R5 硬规则约束(append-only、软删除、结构事件日志、可重建);结论节点与其依据切片/来源的关联入追溯网。… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6;G11 | 451 |
| SR-B12 | 总结触发:何时生成阶段总结交模型自主判断(不设固定阈值)——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档(HITL 确认);保留人工触发入口(用户明确指令触发);上传后先快速摘要反馈、后… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6;G11 | 452 |
| SR-C1 | 内置可配置的研发体系文档树(阶段 → 文档 → 章节),每章有内容要求说明;文档树对应设计开发控制程序,商务对接与策划合并为同一阶段 | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16;G7/G8 | 458 |
| SR-C2 | 体系文档模板集中注册、版本化管理;模板与阶段/文档节点的关联可配置,不与具体工作流实例硬绑定。模板策略:本期按当前已有模板设计与完善;标准模板待系统完成并通过测试后由用户补充(E-T3,后续目标 F-… | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16;G7/G8 | 459 |
| SR-C3 | 文档生命周期状态机:草稿 → 评审中 → 已基线 →(变更中)→ 新版本基线;基线文档不可被直接修改 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 460 |
| SR-C4 | 新切片填充文档章节前,与该章节现有内容比对,输出三分类结论:新增 / 更新 / 冲突;更新与冲突均需用户确认后生效 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 461 |
| SR-C5 | 缺项分析仅在两种触发条件下输出:文档提交评审时、项目申请推进阶段时;上传节点禁止输出缺项提示 | 简单素材检查已有 | 内容/合规要求检查未接提交和阶段门禁 | U10/U11;G14 | 462 |
| SR-C6 | 每次文档内容变化生成版本记录,可查看任意两版本差异及差异来源切片 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 463 |
| SR-C7 | 三权分立流程规则:编制/审核/批准三权异人(编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人);编制发起唯一;审核/批准仅可批注与通过/驳回,不可修改正文或发起编写;提交审核即锁定;驳回回… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8;G6/G17 | 464 |
| SR-C8 | 批准后修改的处理:本期路径=撤回重审(D-12:撤回后修改并重新升版审批)+影响提示(沿追溯网列出受影响范围给人看,不走流程,见 SR-D3);松散管理取向,但审计链不断(08 R1/R2/R5 不动… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8;G6/G17 | 465 |
| SR-D1 | 建立并持久化双向追溯网络:资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例;每条边记录类型、来源(人工/规则/模型候选)与置信度 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 471 |
| SR-D2 | 需求条目化管理:用户需求与系统需求大表,字段含状态(草稿/已评审/已基线)、版本、关联文档与法规;支持增删改与批量导入 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 472 |
| SR-D3 | 新内容入库触发变更检测:与已评审条目比对,不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示(V2.1 增补):批准后修改或引用内容变化时,系统沿追溯网列出受影响范… | 部分关系/变化方法已有 | 来源变化的影响对象和职责闭环待完成 | U6/U11;G11/G16 | 473 |
| SR-D4 | 变更流程闭环(变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭,全程留痕):整体后移,不作为本阶段系统实现目标——变更流程走公司内部管理流程,移入后续目标备案 F-02(《10… | 后移目标保留 | 公司流程权威及七步闭环待独立交付 | U15/F-02;G14 | 474 |
| SR-D5 | 任一需求可导出完整追溯链报告;无法匹配进体系的资料进入"待裁定"清单,提醒用户处理 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 475 |
| SR-D6 | 追溯主体扩展:追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片,保证所有信息细节的准确性与可追溯性 | 来源字段已有 | 模板/主体/来源版本须贯穿生成历史和导出 | U4/U8/U11;G8/G17 | 476 |
| SR-D7 | 完整合规追溯模型(权威定义见 08 第十六章):15 类受控节点(含危害/风险控制措施/设计确认/设计转换/变更)+11 类合规边(两端=节点 ID@版本,模型仅候选、人工确认转正)+四条链视图(13… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 477 |
| SR-D8 | 需求分类与分解框架:用户需求与性能需求分到不同文档;先确认用户需求再分解系统需求;系统需求按六维度分类(功能/交互/安全/运输包装/维护/合规);智能体可从法规反推部分系统需求,但不完全依赖智能体;先… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 481 |
| SR-D9 | 风险登记册追溯:危害(HAZ)与风险控制措施(RCM)入网;每个 RCM 同时登记为需求并必须被验证(verifies 边);每个危害至少被一项 RCM mitigate;措施-危害-验证三向可查(术… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 478 |
| SR-D10 | 验证结果绑定被测版本:VR 记录对应用例与被测对象版本;被测版本≠当前基线版本时系统报「验证过期」并列入缺口;设计确认(VAL)必须追溯到用户需求 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 479 |
| SR-D11 | SOUP 组件登记与追溯:软件组成项(含 SOUP)入网为架构项,其需求分配与验证沿用同一边模型 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 480 |
| SR-E1 | 意图识别分层:规则层(仅限整句完全匹配的高频确定性短指令)→ 语义层 → LLM 层;规则层不得单独触发高风险操作 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 487 |
| SR-E2 | 规则层命中必须通过上下文校验(上一轮存在对应的待确认事项)才可执行;无上下文时降级为普通对话 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 488 |
| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成,卡片明示操作对象与后果 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 489 |
| SR-E4 | 支持意图分类(查询 / 编写 / 命令 / 讨论)与意图切换识别;编写类意图需命中目标文档并确认后执行 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 490 |
| SR-E5 | 简单询问即时回答;复杂任务先给出执行计划与预计耗时,执行中提供进度反馈 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 491 |
| SR-E6 | 对话完备路径:从立项到结项的全部状态变更操作(创建项目、提交评审、批准变更、阶段推进、导出、结项等)均可通过对话指令驱动,页面/按钮不是任何步骤的唯一入口;高风险操作的对话路径终点为对话流内联确认卡(… | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 492 |
| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行:骨架显式定义步骤序列与返回检查节点,角色在骨架内有限自主 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 498 |
| SR-F2 | 每个角色显式声明:职责、可用工具白名单、禁区;角色提示词作为受控资产版本化管理 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 499 |
| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道,结果附引用来源;冲突时以权威来源为准并提示 | 知识检索/声明表已有 | 网络通道为模型输出URL,缺实际抓取独立证据 | U12;G13 | 500 |
| SR-F4 | 长任务后台异步执行,进度可查询、完成有通知;不得阻塞对话主线程 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 501 |
| SR-F5 | 执行任务时自动组装上下文:项目当前状态、相关记忆切片、目标文档模板、近期对话;上下文构成可解释 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 502 |
| SR-G1 | 飞书集成:智能助手可加入群聊,支持群内对话、收文件、推送反馈与通知。本期不做飞书功能(J-11),本条与 UR-20 一并后移 → F-01 | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 508 |
| SR-G2 | 基于角色与项目阶段的权限控制(ABAC),阶段转换需满足准入准出条件并留痕。判定维度(角色 × 项目 × 阶段 × 动作)保留;权限主数据裁决(J-10,R2 关闭):本期系统内建最小权限系统(管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 509 |
| SR-G3 | 全量审计日志:上传、入库、更新、变更、确认、生成等动作均可审计 | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11;G5/G17 | 510 |
| SR-G4 | 系统以自身研发项目为首个运行实例(自举元项目),自身需求与体系文档由本系统管理 | 自举测试资产已有 | 真实材料/模型/登录/浏览器全程验收未完成 | U14;G19 | 511 |
| SR-G5 | 结构追溯:笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值;删除一律软删除(tombstone);追溯边有"候选 → 生效 → 废止"全生命周期;支… | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11;G5/G17 | 512 |
| SR-G6 | 系统管理员与系统级设置:全局唯一管理员拥有所有权限;仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数(工具调用轮数/工具权限等)、系统级插件管理、用户/角色的… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 513 |
| SR-G7 | 角色管理:角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人;角色可分配给用户(如项… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 514 |
| SR-G8 | 权限覆盖优先级——上限内覆盖(J-05,原存疑关闭):管理员设定角色默认权限与权限范围上限(最底层约束);项目负责人(创建者)在该范围内调整项目成员权限;项目内配置可覆盖角色默认配置,但不得突破管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 515 |
| SR-G9 | 项目负责人权限:项目创建者即项目负责人,拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3;G1/G2 | 516 |
| SR-G10 | 项目唯一性与成员自动可见:同名项目全系统唯一;用户被添加为项目成员后,其界面自动出现该项目,并可直接开始项目工作(新建对话等) | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3;G1/G2 | 517 |
| SR-G11 | 对话隐私:用户之间的对话互相不可见,仅本人可见本人与智能体的对话;智能体会话/中间过程默认互不可见(J-06,原存疑关闭),协作全部经两树一网项目共享层;用户分享分层(整个项目/会话/部分会话)的精细… | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9;G4/G5/G10 | 518 |
| SR-G12 | 文档分享:上传者可将文档分享给指定成员/部分成员/全部项目成员;被分享者只读、不可编辑;被分享文档进入接收者上下文,支撑其后续对话中查看并基于这些文档对话 | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9;G4/G5/G10 | 519 |
| SR-G13 | 上下文时间权重:本期最小实现——检索与注入排序新内容优先;替换/冲突场景走 J-02 人裁决(SR-B8/SR-B9)。可配置时间权重衰减模型(权重数值、配置粒度)移入后续目标 F-04(J-07,优… | 排序效果未验收 | 新内容优先不代替裁决,可配置衰减后续实现 | U5/U15/F-04;G10 | 520 |
| SR-G14 | 飞书项目对接适配(接口层四项功能:产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接;飞书角色权限映射读取):本期不做飞书功能,整条移入后续目标备案 F-01(J-11);保留设计预留说… | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 521 |
| SR-G15 | 虚拟人账号(企业账号下为智能体创建固定账号持有文档/文件夹访问权限;授权范围、审批与定期审计流程待明确,《10》Q-04):随飞书对接整体后移,移入后续目标备案 F-01(J-11) | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 522 |
| SR-G16 | 代码执行安全:多用户共享部署在隔离执行档就位前,以启动级硬关闭禁用执行原语(run_shell/run_python/register_artifact 及内核执行配置),用户设置不得覆盖(基座已交付… | 多人执行硬关闭已有 | 最终隔离执行及受控开放待实现验收 | U13;G18 | 523 |
| SR-N1 | 性能:上传首轮反馈 < 60 秒;单文档完整入库(后台)< 10 分钟;追溯链查询 < 3 秒 | 部分运行机制已有 | 固定样本/数据/并发规模的性能待实测 | U14;G18/G19 | 529 |
| SR-N2 | 可维护性:模块边界清晰、依赖单向;任一核心功能(如文档入库)可在 5 分钟内定位到对应代码模块;支撑每周代码审查机制 | 模块边界已有 | 公开契约、文档代码可定位性与维护机制待复核 | U1/U14;G19 | 530 |
| SR-N3 | 可解释性:每个入库、更新、变更动作给出依据(来源切片、命中标签、比对结果) | 部分依据回执已有 | 标签、来源、差异与失败可解释性需全链路验证 | U4/U5/U8;G10/G17 | 531 |
| SR-N4 | 部署与数据:支持本地化部署;法规知识库本地存储;项目数据按项目隔离 | 领域分片与本地存储已有 | 团队数据权威、私域隔离、安装和恢复未完整验收 | U2/U3/U13;G5/G18 | 532 |
| SR-N5 | 模型无关性:大模型通过抽象层接入,可替换(当前为 MiniMax,不绑定) | 模型抽象已有 | 模型替换后的真实业务与降级对照待验证 | U9/U13;G8/G18 | 533 |
## 用户需求(34 条)
每条用户需求沿原 UR→SR 关系追溯,其所有适用系统需求通过后才可关闭。
| ID | 用户目标 | 原关联SR | 实施去向 | 当前判定 | 原文行 |
|---|---|---|---|---|---|
| UR-01 | 自由上传 | SR-A1, SR-A2, SR-A3 | U5/U9/U14 | 局部组件已有;端到端未验收 | 541 |
| UR-02 | 相关性把关 | SR-B1 | U5/U6 | 局部组件已有;端到端未验收 | 542 |
| UR-03 | 自动归纳入库 | SR-A5, SR-B2, SR-B3, SR-B4, SR-B6 | U5/U6/U9/U14 | 局部组件已有;端到端未验收 | 543 |
| UR-04 | 及时反馈 | SR-A4, SR-B5, SR-E5, SR-F4 | U2/U5/U6/U8/U9/U10/U13/U14 | 局部组件已有;端到端未验收 | 544 |
| UR-05 | 渐进式清晰 | SR-C1, SR-C2, SR-C3, SR-C4, SR-C6 | U4/U7/U8/U10/U16 | 局部组件已有;端到端未验收 | 545 |
| UR-06 | 缺项提示时机 | SR-C5 | U10/U11 | 局部组件已有;端到端未验收 | 546 |
| UR-07 | 冲突与变更 | SR-B8, SR-C3, SR-C4, SR-D3, SR-D4(→ F-02) | U4/U6/U8/U10/U11/U15 | 局部组件已有;端到端未验收 | 547 |
| UR-08 | 严格可追溯 | SR-B2, SR-D1, SR-D5, SR-G3, SR-G5, SR-C6, SR-D7(合规追溯链,V2.2) | U4/U5/U6/U8/U10/U11/U14 | 局部组件已有;端到端未验收 | 548 |
| UR-09 | 需求条目化 | SR-D2, SR-D3, SR-D8(需求分类与分解框架,V2.2) | U6/U11/U14 | 局部组件已有;端到端未验收 | 549 |
| UR-10 | 模糊澄清 | SR-B6, SR-B8, SR-E5(提问交互) | U2/U4/U5/U6/U8/U9/U10 | 局部组件已有;端到端未验收 | 550 |
| UR-11 | 一键生成文档 | SR-E4, SR-F1, SR-F2, SR-F5 | U2/U8/U9/U10/U13 | 局部组件已有;端到端未验收 | 551 |
| UR-12 | 主动提问 | SR-E5, SR-B6 | U2/U5/U6/U8/U9/U10 | 局部组件已有;端到端未验收 | 552 |
| UR-13 | 外部查询入库 | SR-F1, SR-F3, SR-B4 | U5/U6/U8/U9/U12/U13 | 局部组件已有;端到端未验收 | 553 |
| UR-14 | 法规双通道 | SR-F3 | U12 | 局部组件已有;端到端未验收 | 554 |
| UR-15 | 商务策划贯通 | SR-C1, SR-C2 | U7/U8/U16 | 局部组件已有;端到端未验收 | 555 |
| UR-16 | 显式确认 | SR-E1, SR-E2, SR-E3, SR-E6 | U2/U8/U9/U10 | 局部组件已有;端到端未验收 | 556 |
| UR-17 | 阶段门禁权限 | SR-G2, SR-G3 | U2/U3/U4/U11 | 局部组件已有;端到端未验收 | 557 |
| UR-18 | 会议纳入记忆 | SR-B7 | U5/U6 | 局部组件已有;端到端未验收 | 558 |
| UR-19 | 自举 | SR-G4 | U14 | 局部组件已有;端到端未验收 | 559 |
| UR-20 | 协作平台接入 | SR-A3, SR-G1(本期不做飞书功能,一并后移 → F-01,J-11) | U15 | 后移目标保留 | 560 |
| UR-21 | 系统角色与权限管理 | SR-G2, SR-G6, SR-G7, SR-G8 | U2/U3 | 局部组件已有;端到端未验收 | 561 |
| UR-22 | 项目成员与协作 | SR-G9, SR-G10 | U2/U3 | 局部组件已有;端到端未验收 | 562 |
| UR-23 | 文档分享与上下文注入 | SR-G11, SR-G12, SR-G13(降 P2,衰减模型 → F-04) | U3/U5/U9/U15 | 局部组件已有;端到端未验收 | 563 |
| UR-24 | 三权分立文档流程 | SR-C7, SR-C8 | U3/U8 | 局部组件已有;端到端未验收 | 564 |
| UR-25 | 版本全量保留与来源追溯 | SR-C6, SR-D6, SR-G5 | U4/U8/U10/U11 | 局部组件已有;端到端未验收 | 565 |
| UR-26 | 并发更新冲突避免与提示 | SR-B8, SR-B9(J-02 落地+U0 D4 两层裁决) | U4/U6 | 局部组件已有;端到端未验收 | 566 |
| UR-27 | 快慢处理与任务拆解展示 | SR-B10(J-03 已裁决落地) | U9/U13 | 局部组件已有;端到端未验收 | 567 |
| UR-28 | 简易看板 | SR-C3, SR-D3(编制状态与变更检测为看板数据源;看板与卡片流界面统一 → F-06) | U4/U6/U8/U10/U11 | 局部组件已有;端到端未验收 | 568 |
| UR-29 | 难度分级与降级使用 | SR-F2(智能体能力边界按项目难度配置;评估表与降级规则细化 → F-08) | U8/U9/U13/U14/U15 | 局部组件已有;端到端未验收 | 569 |
| UR-30 | 对抗验证机制 | SR-F1(流程骨架中增设独立验证节点;对抗机制形态待设计,属《10》Q-13,维持开放) | U8/U9/U13/U14/U15 | 局部组件已有;端到端未验收 | 570 |
| UR-31 | 飞书项目对接 | SR-G14, SR-G15(本行整体→ F-01) | U15 | 后移目标保留 | 571 |
| UR-32 | 代码管理工具集成 | SR-D1(追溯网扩展需求—版本—缺陷关联边;本行整体→ F-05) | U15 | 后移目标保留 | 572 |
| UR-33 | 法规合规追溯 | SR-D7, SR-D9, SR-D10, SR-D11, SR-D1 | U11/U14 | 局部组件已有;端到端未验收 | 573 |
| UR-34 | 结论沉淀与阶段总结 | SR-B11, SR-B12 | U6 | 局部组件已有;端到端未验收 | 574 |
## 后续目标(10 项)
| ID | 原目标 | 当前处理 | 交付去向 | 原文行 |
|---|---|---|---|---|
| F-01 | 飞书对接全套(渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联) | 保留最终目标,前置与批准见主记录 | U15/F-01 | 637 |
| F-02 | 变更流程引擎(七步闭环、变更单、完整影响分析) | 保留最终目标,前置与批准见主记录 | U15/F-02 | 638 |
| F-03 | 用户分享分层(整个项目/会话/部分会话)与智能体可见性的精细设计 | 私有默认已确认,细分分享需明确授权 | U15/F-03 | 639 |
| F-04 | 可配置上下文时间权重衰减模型 | 保留最终目标,前置与批准见主记录 | U15/F-04 | 640 |
| F-05 | 代码管理工具集成(GitLab token 只读拉取、需求-版本-缺陷关联) | 保留最终目标,前置与批准见主记录 | U15/F-05 | 641 |
| F-06 | 看板与卡片流的界面统一(随原型 V2.3) | 并入对话与看板同源收敛 | U9/U14 | 642 |
| F-07 | 会议遗留问题组(Q-01/02/03/07/10/13/14 等,《12》问题 8 组);其中 Q-02 经晚会部分裁决(C-03,见 §7.1) | 逐项裁决台账,不当作已确定的一组功能 | U15/F-07 | 643 |
| F-08 | 难度分级评估表与降级机制的落地细化(UR-29 保留 P1,实施细节备案) | 保留最终目标,前置与批准见主记录 | U15/F-08 | 644 |
| F-09 | 追溯网可视化(先功能后展示,暂缓) | 较新展示方案已批准,早期暂缓已调整 | U11/U14 | 645 |
| F-10 | 标准模板替换:本期按当前已有模板设计与完善;待系统完成并通过测试后,由用户补充标准模板(取代晚会 T2「今晚下载官方模板替换」,不执行) | 依赖用户提供标准模板;旧模板先全量实现 | U16+U15/F-10 | 646 |
验收结果槽:本轮未生成业务通过记录;后续由实施任务/CI/独立重放补入命令、对象 SHA、运行链接与输出。历史任务卡另行映射,原始收据不改。
File diff suppressed because one or more lines are too long
@@ -0,0 +1,85 @@
# RDM 文档模板资产盘点(2026-10-11)
关联方案:[对话文档生成方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。本清单为 SELF 静态资产盘点,不表示线上实际文档数或模板已验收。
源:旧 Agent-System `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` 的 `templates/docs/*.md`;RDM `0081628a10ec48a36537c6eced11a57439c986fa` 的 `internal/domain/data/labels_seed.json`、`docs/templates/registry.yaml`。
旧路径规则为 `templates/docs/<类型键>.md`。下列 H2 数只用于估算拆解工作,不等于最终业务章节数;管理性章节需重新归位。
69 份 Markdown:bd 7、rd 60、pm 1、tm 1;另有 `templates/xlsx/cdo_quote.xlsx` 一份,不计入 69。
RDM 登记 69 种 docTypes,但只注册 4 个 v1 模板,覆盖 3 个类型;66 个类型未绑定模板。
“已绑定”仍不表示正确默认、格式兑现或完整生成可用。当前按首项匹配会混用周报/纪要,详情见方案 G3。
所有历史模板迁移/发布/业务验收均待独立评审,本清单不修改发布状态。
| 类型键 | 字典名称 | 阶段 | 历史 H2 数 | RDM 注册绑定 | 原件 SHA256 前16位 |
|---|---|---|---|---|---|
| bd_cdo_quote | CDO 报价单 | BD | 6 | 未绑定 | 4d0cb0b4e4dafecb |
| bd_feasibility_dev | 设计开发可行性评估报告 | BD | 7 | 未绑定 | dc565be65647250c |
| bd_feasibility_reg | 注册路径可行性评估报告 | BD | 9 | 未绑定 | 16add9b2558dee31 |
| bd_intake | 用户初始需求收集表 | BD | 8 | 未绑定 | 427bafe56062f616 |
| bd_prelim_design | 系统初步设计方案 | BD | 9 | 未绑定 | 4001acdbb5bafa5e |
| bd_research | 调研报告(竞品/技术/专利/市场/对比/法规) | BD | 11 | review-minutes@v1、competitive-analysis@v1 | 0b64388a16f8c7de |
| bd_user_requirements | 用户需求表 | BD | 7 | 未绑定 | 547dda49107a4d26 |
| pm_system_reqs | 系统需求规格书(SR) | 03 | 10 | 未绑定 | 3717c5ff34272088 |
| rd_adverse_events | 同类产品不良事件信息 | 03 | 11 | 未绑定 | d2cfbfed223d9dd7 |
| rd_animal_study | 动物试验方案 | 12 | 11 | 未绑定 | f070c80fb84b413d |
| rd_biocompatibility | 生物学检测方案 | 08 | 11 | 未绑定 | bcb25be8e5d8745d |
| rd_cleaning | 清洁消毒验证方案 | 08 | 11 | 未绑定 | 42ec75116e247d88 |
| rd_clinical | 临床试验报告 | 12 | 11 | 未绑定 | 9df8321b7488535d |
| rd_design_input_list | 设计输入清单 | 03 | 11 | 未绑定 | 51c0d2334a8f0475 |
| rd_design_input_spec | 设计输入规格书 | 03 | 12 | 未绑定 | a629d1b3e3dc6e9a |
| rd_design_output_list | 设计输出清单 | 06 | 10 | 未绑定 | 5ffbce9be6d92ccd |
| rd_design_plan | 设计开发计划任务书 | 01 | 11 | review-minutes@v1 | 589dec73a01b1c75 |
| rd_design_validation_report | 设计确认报告 | 13 | 11 | 未绑定 | 9ff1744ebdae179f |
| rd_design_vv | 设计验证方案 | 08 | 11 | 未绑定 | 5ec16dcfbbf55132 |
| rd_dmr_list | DMR文件清单 | 10 | 10 | 未绑定 | 437bda4f714d756b |
| rd_drawings_3d | 2D图纸和3D模型(附件清单) | 06 | 10 | 未绑定 | 96b771a7912a6393 |
| rd_ee_bom | 电子电气BOM(附件清单) | 06 | 10 | 未绑定 | 08052bb640704115 |
| rd_electrical_sys | 系统电气设计图(附件清单) | 06 | 10 | 未绑定 | df4f8aaeedbf4f5c |
| rd_emc_safety | EMC及安规摸底报告(附件清单) | 08 | 11 | 未绑定 | 9257a9a02d6ac939 |
| rd_fqc | 成品检验规范 | 06 | 11 | 未绑定 | 4891c93ff9ce889b |
| rd_hazard_analysis | 安全性问题清单及可能危险分析表 | 03 | 11 | 未绑定 | 3a8ed0db49b35553 |
| rd_ifu | 产品使用说明书 | 06 | 11 | 未绑定 | d76bc2e2a531632a |
| rd_incoming_iqc | 原材料进货检验规范 | 06 | 11 | 未绑定 | 14c21bd69cd9a756 |
| rd_input_phase_review | 设计开发评审记录(阶段3和4) | 05 | 12 | 未绑定 | 5982bdf27dab55f0 |
| rd_ipqc | 生产过程检验规范 | 06 | 11 | 未绑定 | 14bf3912f4dc6c4f |
| rd_lifetime | 产品使用期限研究方案 | 08 | 11 | 未绑定 | f7232dd9750c2369 |
| rd_output_review | 设计开发评审记录(阶段6) | 07 | 12 | 未绑定 | 87029ef45d4ac5b2 |
| rd_pack_ship | 包装运输方案 | 10 | 11 | 未绑定 | a368bd102a0535f3 |
| rd_packaging | 包装图纸和设计要求 | 06 | 11 | 未绑定 | e12a32ded3da14f1 |
| rd_pcba | PCBA原理图及Layout(附件清单) | 06 | 10 | 未绑定 | 4b91abe3191c36df |
| rd_planning_review | 设计和开发策划评审记录 | 02 | 12 | 未绑定 | 3bac17e3ef284010 |
| rd_process_flow | 工艺流程图及作业指导 | 06 | 11 | 未绑定 | c4892f9947ec3cce |
| rd_product_bom | 产品BOM(附件清单) | 06 | 10 | 未绑定 | ac57d604f77ac754 |
| rd_proposal | 项目建议书 | 01 | 11 | weekly-report@v1、project-proposal@v1 | 50ed802a9249229e |
| rd_prototype_photos | 样机照片(附件清单) | 08 | 10 | 未绑定 | be4ff90930f06842 |
| rd_purchase_spec | 采购技术规范 | 06 | 11 | 未绑定 | 72ee43993c30f01a |
| rd_qualified_suppliers | 合格供方名录 | 08 | 11 | 未绑定 | 603a9ab37998a21a |
| rd_regs_stds | 法规和标准清单 | 03 | 11 | 未绑定 | 24b98c273fb04dd8 |
| rd_req_review | 需求评审记录 | 04 | 12 | 未绑定 | d42e18d5e02b7d5c |
| rd_risk_plan | 风险管理计划 | 03 | 11 | 未绑定 | 608822eb42aa83bd |
| rd_risk_report | 风险管理报告 | 06 | 11 | 未绑定 | de4ed137e0c1b76f |
| rd_risk_report_t | 风险管理报告(转换阶段) | 10 | 11 | 未绑定 | 24c61db854d6a9de |
| rd_risk_report_v | 风险管理报告(验证阶段) | 08 | 11 | 未绑定 | 762eb5d127698215 |
| rd_risk_report_val | 风险管理报告(确认阶段) | 12 | 11 | 未绑定 | b3200d74cd74913d |
| rd_shelf_life | 货架寿命方案 | 08 | 11 | 未绑定 | 9e51627645d7c561 |
| rd_sw_arch | 软件概要设计方案 | 06 | 11 | 未绑定 | e829e164cf1c825b |
| rd_sw_config | 软件配置及维护计划 | 03 | 11 | 未绑定 | 8510491f6480b58b |
| rd_sw_plan | 软件开发计划 | 03 | 11 | 未绑定 | 79ddc781bca8bb9d |
| rd_sw_quality | 软件质量测试报告 | 12 | 11 | 未绑定 | ef1e7dbbed13abf8 |
| rd_sw_release | 软件发布清单 | 08 | 10 | 未绑定 | ac4e522903fa6872 |
| rd_sw_reqs | 软件需求规格书 | 03 | 11 | 未绑定 | eb9a1d75efe1bda1 |
| rd_sw_sys_test | 软件系统测试报告 | 08 | 11 | 未绑定 | c86e15580ee24d16 |
| rd_sw_ui | 软件UI设计文档 | 06 | 11 | 未绑定 | 9c041da7d6db8d88 |
| rd_sw_unit_test | 软件单元测试报告 | 08 | 11 | 未绑定 | 368b5939da695d0e |
| rd_system_design | 系统设计方案 | 03 | 11 | 未绑定 | adf0b6bf32fe10af |
| rd_system_reqs | 系统需求规格书(SR) | 03 | 15 | 未绑定 | 1d0aa50c5e8f06d9 |
| rd_tech_req | 产品技术要求 | 06 | 11 | 未绑定 | 03c39e46300e6719 |
| rd_transfer_review | 设计开发评审记录(转换阶段) | 11 | 12 | 未绑定 | 4be3b0770a08d6d4 |
| rd_use_error | 使用错误评估报告 | 12 | 11 | 未绑定 | 67c98d3f26b91c13 |
| rd_user_needs | 用户需求规格书(UN) | 03 | 11 | 未绑定 | cdc46e46a93bca81 |
| rd_user_test | 用户测试报告 | 12 | 11 | 未绑定 | 26ad7d32eb59b386 |
| rd_validation_plan | 设计确认方案 | 12 | 11 | 未绑定 | a0b53fc9a74df218 |
| rd_verification_review | 设计开发评审记录(验证阶段) | 09 | 12 | 未绑定 | ec68f27212649baf |
| tm_system_verification | 系统验证方案及计划(SVP) | 04 | 8 | 未绑定 | 7b66de5bd1f6b0f3 |
完整哈希应在正式迁移台账保留;本表短哈希用于阅读定位,不作为独立完整性或身份凭据。
@@ -0,0 +1,19 @@
# 模板对话生成方案 r1 文档检查记录
对象:[方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。日期:2026-10-11。
性质:SELF,三组本地模型审阅覆盖七个视角,不是人工评审、业务验收或独立 GATE/REPLAY;未执行跨供应商模型审阅。
检查范围:方案一致性、可行性、产品范围、使用流程、权限和关键失效场景。业务测试 NOT_RUN。
| 视角 | 原始发现 | 处理 |
|---|---|---|
| 一致性 | 无重要矛盾 | 无修改 |
| 可行性 | 同文档旧章节职责/签署不同,不能自动合成文档批准 | KTD8/U4 补迁移与旧活动审签处置;首个整文版重新审签 |
| 产品 | 无实质发现 | 保留首批两模板建议与69类全量登记、分批验收 |
| 交互 | 新文档未分配职责或当前用户非编制人时缺对话恢复路径 | User Flow/U5 补等待分配、负责人分配、最小信息转交与指定编制人接续 |
| 范围 | 无实质发现 | 保留既有两树一网/存储分工 |
| 权限 | 模板发布、退役和默认绑定的管理权未明确 | KTD1/U2 限定首期经批准仓库发布;编制权不继承模板管理权 |
| 失效场景 | 部分采纳混合新旧章节后未重验整文依赖 | KTD6/U4 补对实际目标组合的依赖、术语、指标检查及版本/hash 绑定 |
四条原始发现均为 P2、置信度 75。主审核对依据:旧 review.go 以 sectionID 分配职责/保存审批,首期 templates.go 只读受控注册表,方案已有严格编制权与部分采纳行为;四项补充用于使既有目标成立,未扩大业务交付范围。
四项已在方案中修订并补验收场景;未代签用户保留的路线、首批顺序、文档级审批选择和实施授权。
本记录只证明文档检查及修订,后续真实业务验证仍按方案执行。
File diff suppressed because one or more lines are too long