Compare commits

...
Author SHA1 Message Date
weichen 9c31d3c308 Merge Documents main into account durability plan branch
Why: keep r2/r3 proposal updates rebase-friendly before PR.
Evidence: origin/main at fetch time.
Impact: Documents feature tip includes latest main.
Refs: feature/svc-account-durability-plan
2026-10-12 12:11:40 +00:00
weichen b8319d24f2 Merge pull request 'Record U7 capacity window SELF report and plan r2.1' (#86) from feature/u7-capacity-window-report into main 2026-10-12 12:07:26 +00:00
weichenandCursor dbdec82466 Record U7 capacity window SELF report and plan r2.1
Why: Capacity ladder/60m/2h dual-instance windows finished; planning
progress must reflect SELF-pass vs remaining GATE/REPLAY/C3 gaps.
Evidence: SELF load results summarized in the new capacity report.
Impact: Preferred next becomes independent REPLAY or C3/C4/C5.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 12:07:12 +00:00
weichen fe8d08be21 Record the final baseline and isolated candidate data
Why: distinguish timed observations from current service ownership.

Evidence: SELF task-sync and read-only observations at 18:14 Beijing time.

Impact: planning metadata only; runtime and component deployment unchanged by this task.

Refs: account r2; recovery r3
2026-10-12 10:16:32 +00:00
weichen dca4265e37 Plan stable accounts and durable service recovery
Why: account help, dev credential writes and crash recovery need a current, reviewable contract.

Evidence: SELF source and sanitized runtime observations; seven document review lenses; business and fault validation NOT_RUN.

Impact: revise two planning documents only; preserve prior approvals and mark additions pending review.

Refs: Dev feature/svc-account-durability-plan; account r2; recovery r3
2026-10-12 10:09:49 +00:00
weichen 1048e7c6af Merge pull request 'Propose RDM function implementation plan r1' (#85) from feature/rdm-function-plan-r1 into main 2026-10-12 09:29:03 +00:00
weichen a183e663de Propose RDM function implementation plan r1
Why: 2026-10-12 全系统核对产出的功能/实现矩阵与 U1-U9 整改方案需入仓评审;独立文件已过期于共享门禁解除。
Evidence: 报告含冻结源码/运行时快照与逐条需求索引;发布补记记录冻结后部署时序与 U2 已合入切片(RDM PR #251/#254/#256/#258)。
Impact: 仅新增 docs/proposals 一份方案与 README 入口;不改代码与既有文档。
Refs: RDM docs/requirements V2.2、Documents 2026-10-11-rdm-final-target-completion.md
2026-10-12 09:28:44 +00:00
weichen 8d0810bd35 Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83) from feature/u7-capacity-wrap-progress into main
Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83) from feature/u7-capacity-wrap-progress into main
2026-10-12 06:39:52 +00:00
weichenandCursor 2cec59016a Update collab storage plan progress to r2 after U1-U7
Why: Delivery requires writing planning progress back after U7
landed; the proposal still claimed U1+U2 start / NOT_RUN.
Evidence: SELF doc edit against archived U7 cards and release
checklist A1-A7/B1 facts.
Impact: Readers see code-done vs capacity-window-pending; adds
HTTP multi-instance vs Manager-test lesson.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 06:39:26 +00:00
weichen 52bf525ef8 Merge pull request 'Add svc unified deploy and one-time login key proposal r1' (#79) from feature/svc-unified-deploy-login-key into main
Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/79
2026-10-12 05:27:00 +00:00
weichen 9d9b1523c8 Merge Documents main into svc unified-deploy proposal branch
Why: Dev #422 conflicted on modules/documents gitlink after main advanced past the proposal pin.
2026-10-12 05:26:12 +00:00
weichen bd5fb18519 Merge pull request 'Record GenUI prod-acceptance action fixes on the usage guide' (#82) from feature/genui-fix-action-params into main 2026-10-12 04:17:15 +00:00
weichen e39d327850 Record GenUI prod-acceptance action fixes on the usage guide
Why: Capture nil-card panic and intent data-flatten field fixes found
during local prod acceptance without revising the final closure verdict.
Evidence: Backend#173 #174; prod action checklist
Impact: Field-fix log lists the two hotfixes and their PRs.
Refs: GenUI prod deploy; fix track
2026-10-12 04:17:07 +00:00
weichen 262d467362 Merge pull request 'Note Generative UI prod instance acceptance on the usage guide' (#81) from feature/genui-prod-deploy-note into main 2026-10-12 04:09:06 +00:00
weichen 66ddd37870 Note Generative UI prod instance acceptance on the usage guide
Why: Record that the known-boundary production deploy/acceptance ran
on the local prod svc instance with auth and PG.
Evidence: scripts/svc.sh prod list; acceptance API checklist
Impact: Usage guide boundary list no longer says deploy is pending.
Refs: GenUI prod deploy task
2026-10-12 04:08:58 +00:00
weichen 1fe5b73491 Merge pull request 'Approve Generative UI auto-trigger opt-in design' (#80) from feature/genui-auto-trigger-optin into main 2026-10-12 03:46:28 +00:00
weichenandCursor 16cafca00c Approve Generative UI auto-trigger opt-in design
Why: Capture the fixed opt-in/budget/anti-self-trigger decisions and
update the usage guide boundary list.
Evidence: proposal r1 status approved
Impact: Authority for backend auto-present implementation.
Refs: plan GenUI boundaries T2/T3

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 03:46:26 +00:00
weichenandCursor 7df7d786d0 Record r1 approval for svc unified deploy proposal
Why: user approved the proposal and U1/U4 specs and authorized push/PRs
plus U1/U4 implementation start.
Evidence: SELF conversation approval 2026-10-12; implementation still NOT_RUN.
Impact: planning status only.
Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 03:32:55 +00:00
weichen 3e68448f11 Merge pull request 'Record the admin-zone partition delivery in the two-trees plan (WP3-I3)' (#78) from feature/adminzone-plan-progress into main 2026-10-12 03:28:53 +00:00
weichenandCursor 923537e9a1 Add svc unified deploy and one-time login key proposal r1
Why: capture the reviewed design for binary/source install, env prep,
and passwordless activation via one-time restricted sessions.
Evidence: SELF source review against Dev af9c2de; implementation NOT_RUN.
Impact: Documents planning index only; no runtime change.
Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 03:28:37 +00:00
weichen 0b314e2029 Record the admin-zone partition delivery in the two-trees plan progress
Why: policy requires updating applicable plan progress on task
completion; WP3-I3 landed the admin-zone entrance via the generic
declaration mechanism.
Evidence: Dev PR #414 and live verification comment (R5, SELF).
Impact: progress line of 2026-10-11-rdm-two-trees-trace-audit-integration.md only.
Refs: WP3-I3/KTD4.
2026-10-12 03:24:50 +00:00
weichen 62da617648 Merge pull request 'Approve B-class allowlist for help and intent actions' (#77) from feature/genui-bclass-help-intent into main 2026-10-12 03:23:27 +00:00
weichenandCursor 7fbfad1851 Approve B-class allowlist for help and intent actions
Why: Record the independent U5-style review for the first two B-class
surface actions and update the usage guide allowlist note.
Evidence: proposal r1 status approved; usage doc API table updated.
Impact: Documents authority for backend whitelist implementation.
Refs: U5 action-scope r2; plan GenUI boundaries 2026-10-12

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 03:19:03 +00:00
weichen b680142586 Merge pull request 'Add the Generative UI usage guide and U1-U6 evaluation record (final)' (#76) from feature/generative-ui-u7 into main 2026-10-12 02:47:50 +00:00
weichen 877d0683cd Add the Generative UI usage guide and U1-U6 evaluation record (final)
Why: The direction closes at U7 - the master record needs its
companion usage guide (enable/generate/revise/act/disable for owners)
and the combined evaluation record covering every landed increment
with its evidence chain and known boundaries.

Evidence: Live E2E on dev@b634a27 (real MiniMax-M3): progress page
presented autonomously, conversation surfaces=2, project aggregation
returns cross-conversation pages under the owner scope; receipts in
Dev task feature/generative-ui-u7-acceptance.

Impact: Documents-only (new guide + index closeout).

Refs: r2 master record; U5 scope r2; Dev task
feature/generative-ui-u7-acceptance
2026-10-12 02:47:27 +00:00
weichen b5dceb5e47 Merge pull request 'Add the service restart and recovery proposal r2 with two review rounds' (#75) from feature/service-restart-recovery-plan into main
Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/75
2026-10-12 02:02:12 +00:00
weichen da59ccff04 Track the merged svc-autorecover outcome in the review record and index
Why: between the review round and the approval decision another session completed and merged svc-autorecover (PR #396/#400/#401/#402), so the (a)-decision tracking must reflect the landed slice and the remaining U2 delta.

Evidence: SELF - merged main history c622372 and archived card .task/archive/feature-svc-autorecover.md (10/10 tests, 146/146 governance, CI green on e0b49d1).

Impact: review record, INDEX; proposal r2 body unchanged.

Refs: PR #396 #401
2026-10-12 01:29:31 +00:00
weichen 5a807933c2 Record the r2 approval and the svc-autorecover vehicle decision
Why: the human gate resolved on 2026-10-12 - r2 approved (five stages at once) and option (a) adopted; the review record, proposal index and status navigation must reflect it.

Evidence: SELF - user decision relayed in conversation; stage-review details in the Dev task card; proposal r2 body unchanged (SHA256 9cfda252...).

Impact: review record, INDEX entry; no plan content change.

Refs: Dev task card .task/feature-service-restart-recovery-plan.md
2026-10-12 01:26:50 +00:00
weichen 71cd9d1db2 Record the post-sync drift check and svc-autorecover in-flight findings in the review record
Why: the reviewer record must reflect that all r2 gap claims hold at the post-sync backend pin 25fbea85, and that the svc-autorecover ownership decision now has 373 lines of unregistered, partially failing in-flight work to weigh.

Evidence: SELF - drift-check receipt in the Dev task card (exit 0, all cited gaps hold); svc-autorecover suite observed 5 of 10 tests failing on 2026-10-11.

Impact: review record addendum only; proposal r2 (SHA256 9cfda252...) unchanged.

Refs: Dev task card .task/feature-service-restart-recovery-plan.md
2026-10-11 16:51:54 +00:00
weichen cbc64eb8ab Revise the recovery proposal to r2 with external review findings
Why: absorb the external source-review round - pin the shutdown budget change, close the U1 acceptance gap for program/cwd changes, gate U4 public states on a mapping table, and make the svc-autorecover coordination an explicit human decision.

Evidence: SELF - external review round 2 in the review record; r2 SHA256 9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd; all reviewed claims re-verified against the pinned baselines.

Impact: documents only; four targeted amendments (U1/U3/U4/section 9) plus version bump and INDEX update; requirements and metrics unchanged.

Refs: Dev task card .task/feature-service-restart-recovery-plan.md
2026-10-11 16:45:09 +00:00
weichen 54fc24e4d5 Add the service restart and recovery proposal r1 with review record
Why: pin the reviewed candidate as a fixed git object before human review (external review P1.1); untracked drafts made check-evidence report unverified.

Evidence: SELF - proposal SHA256 cfc9b768a4596a268810e20101cddc2a6040e24a640e6e34dbda17b838cd45ed matches the review record; source baseline Dev 5e57029b, Backend eb12f102, Core 89f3906c, Frontend aaced879, Documents 23e2276.

Impact: documents repo only; adds proposal r1, six-lens review record and INDEX entry; no implementation, NOT_RUN statuses preserved.

Refs: Dev task card .task/feature-service-restart-recovery-plan.md
2026-10-11 16:42:23 +00:00
weichen 23e2276905 Merge pull request 'Mark U1-U5 implementation complete in the two-trees master plan' (#74) from feature/rdm-u5-closeout into main 2026-10-11 15:57:15 +00:00
weichen 2085447701 Record U5 progress and mark U1-U5 implementation complete in the master plan
Why: U5 landed via RDM PR #213 (merge 1dce69d); all five implementation units now complete.

Evidence: RDM PR #213 merged=True.

Impact: plan status + U5 progress + INDEX.

Refs: RDM PR #213
2026-10-11 15:57:13 +00:00
weichen 63d5986819 Merge pull request 'Record U4 progress in the two-trees master plan and index' (#73) from feature/rdm-u4-closeout into main 2026-10-11 15:07:57 +00:00
weichen 895a7204b9 Record U4 progress in the two-trees master plan and index
Why: U4 landed via Dev PR #368 (merge 7aa8fd9).

Evidence: Dev PR #368 merged; CI green.

Impact: status line + U4 progress + INDEX only.

Refs: Dev PR #368
2026-10-11 15:07:53 +00:00
weichen 2e1b39ea68 Merge pull request 'Record the user ruling to gate U6 on owner experience' (#72) from feature/generative-ui-u6-gate into main 2026-10-11 15:01:22 +00:00
weichen b6b6059222 Record the user ruling to gate U6 on owner experience
Why: The U6 precondition (benefit evidence from U4/U5) resolves to the
owner actually using the landed U1-U5 capability - the human usability
comparison marked NOT_RUN since U1 finds its execution path here; the
user ruled 2026-10-11 to evaluate first and decide U6 after.

Evidence: Ruling collected via the session question panel on
2026-10-11; U1-U5 all merged (Dev #329/#336/#345/#351/#367).

Impact: Documents-only (master record U6 gate note + index status).

Refs: r2 U6 clause; Dev task feature/generative-ui-u6-gate-record
EOF
)
2026-10-11 15:01:08 +00:00
weichen 75ddd65c69 Merge pull request 'Record the user approval of the U5 action scope' (#71) from feature/generative-ui-u5 into main 2026-10-11 14:09:47 +00:00
14 changed files with 1493 additions and 9 deletions
+2
View File
@@ -21,3 +21,5 @@ docs/
[实施记录](docs/records/2026-09-29-implementation.md) · [设计方案](docs/proposals/2026-09-29-system-skeleton-design-and-plan.md)
规范基线:Development-Guidelines(Dev 仓 `deps/development-guidelines`)。
相关方案:[RDM 功能、实现与计划矩阵及整改方案 r1(2026-10-12)](docs/proposals/2026-10-12-rdm-function-implementation-plan.md)——RDM 全系统缺口矩阵与 U1–U9 工作包。
@@ -417,6 +417,11 @@ AG-UI 仅在需要跨 Agent 框架互通时评估事件适配;MCP Apps 仅在
### U6. 自适应任务与项目工作区
> **2026-10-11 用户裁定**:U1–U5 已全部落地合入;U6 启动前置(「U4/U5 的收益
> 与可靠性证据」)改为 **owner 实际体验评估**——在真实使用中启用 generative-ui
> 插件、体验页面生成/修订/表单提交(人类可用性对照自 U1 起 NOT_RUN,本裁定即
> 其执行方式)。体验结论(继续/调整/停止)由用户给出后再开 U6。
- 关联 R8,依赖 U4/U5 的收益与可靠性证据。
- 文件范围:Frontend workspace/任务页容器、插件上下文选择与触发策略、Backend 授权聚合适配、相关测试。
- 方法:先当前任务,后项目;任务阶段触发有限更新;固定布局/恢复原视图;自动模式单独 opt-in。
@@ -8,10 +8,10 @@ product_contract_source: ce-plan-bootstrap
# 多人协作存储与分布式演进方案 - Plan
修订:r1;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:方案获批发布,实施自首选增量 U1+U2 启动;业务实施/迁移/压测/部署仍为 NOT_RUN,逐项以实施任务卡为准。
修订:r2.1;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:U1–U7 **代码与测试已合入**(Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164);Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442);闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等)。正确性 A1–A7 与 B1 已绿(CI/SELF)。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**(见[容量报告](../records/2026-10-12-u7-capacity-window-report.md));**SELF≠GATE/REPLAY**,双主机 C3、运维演练 C4/C5 未做——**仍不放行第二实例承接写请求**。
需求来源:2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工;随后确认“10–100 人,多人多项目多会话并行,未来支持多服务分布式”。
需求负责人:weichen;方案编制:Codex;实施及运维负责人:待指定。更新时间:2026-10-11(Asia/Shanghai)。
关联任务:Dev `.task/feature-collaboration-storage-plan.md`(方案任务,已发布);后续 U1+U2 实施由独立任务承接。
需求负责人:weichen;方案编制:Codex;实施及运维负责人:待指定。更新时间:2026-10-12(Asia/Shanghai)。
关联任务:方案与 U1–U7 实施卡已归档;容量收尾见 Dev `.task/feature-u7-capacity-wrap-measure.md`。放行检查单:Dev `docs/release-multi-instance.md`。
正文中的源码路径以 Agent-System-Dev 为根;工作包中的 `internal/` 简写指 `modules/backend/internal/`;文内相对链接以本文为根。
## 1. 推荐结论与边界
@@ -246,8 +246,8 @@ SQLite 本身支持可靠事务与多人经同一应用访问;WAL 提升读写
必需观测:API P95/P99与预期/非预期错误,DB pool wait/连接数/慢查询/锁等待,队列长度/最老年龄,run 租约/过期写拒绝/未知副作用,SSE cursor lag/补查次数,Redis 错误与降级,检索耗时/召回抽样,备份时间与恢复结果。日志只记录 request/run/owner 的安全标识,不记录 DSN、密钥或文档正文。
当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认;容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
r1 为方案与 SELF 调查记录。r2 起:U1–U7 代码与测试已合入且正确性 CI 绿。r2.1:本机双实例 contract 容量窗口(ladder / 60m / 2h)SELF 全过,见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。本地 SELF 不能冒充 GATE/REPLAY 放行;双主机与运维演练仍缺。部署与第二实例写流量仍未授权。
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
首选下一增量是 **U1 + U2 的详细实施与测试合同**:固定目标实例与 PG 测试环境,解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行;不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA,再按 Dev 的 evidence/task-sync/组合验证流程交付。
首选下一增量是 **独立 REPLAY 最小容量集**(至少 `run_load.sh --seed contract --profile ladder --instances 2`)以提升放行证据等级;或其候选项:**C3 双主机验证**(需用户指定第二主机)或 **C4/C5 运维演练**。在 GATE/REPLAY 与 C3 未齐前,不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA,再按 Dev 的 evidence/task-sync/组合验证流程交付。
@@ -9,7 +9,7 @@ product_contract_source: ce-plan-bootstrap
# RDM 两树一网集成、完善与追溯审计展示方案
修订:r1(2026-10-11 并入用户裁定);确认状态:用户评审通过(2026-10-11,需求拆解至实施计划五阶段一并,含 KTD4 双层管理员裁定);推进状态:U1、U2、U3 已实施并合入(RDM PR #195 merge 05b7d1a;PR #197 merge fe8a75b;PR #201 merge dbc41b6,2026-10-11);U4–U5、迁移与运行验收未启动。
修订:r1(2026-10-11 并入用户裁定);确认状态:用户评审通过(2026-10-11,需求拆解至实施计划五阶段一并,含 KTD4 双层管理员裁定);推进状态:U1–U5 全部实施并合入(RDM PR #195/#197/#201/#213;Dev PR #368,2026-10-11);管理区「项目追溯与审计」入口经通用声明机制补齐(扩展面 2.9.0 Registry.AddAdminZone;Backend #165、Frontend #63/#64、RDM #240、Dev #414,2026-10-12;rdm.audit 分区随 rdm 插件声明,区内能力仍由 rdm.inspect.* fail-closed);管理页插件清单另合并编译插件条目(Dev #404,2026-10-12)。U6(团队存储)独立后续;运行验收属部署环境。
需求负责人:weichen;方案编制:Codex;实施负责人:待实施立项时指定。
来源:2026-10-11 用户要求检查两树一网现状,并设计简单直观的项目追溯、审计展示;同轮明确选择“完善 RDM,并补齐必要的基座能力”。
目标仓:Agent-System-RDM;下文 `RDM:` 路径相对于该仓,`Dev:` 路径相对于 Agent-System-Dev;所有建议接口名均为候选契约。
@@ -317,6 +317,8 @@ U1 同批接通旧客户端的项目选择和命令封装,并解析可信会
验证:真实浏览器完成来源查询、选择历史时间/基线并返回当前、管理员从宿主 A 打开审计 B 后标题和请求一致;模拟慢请求后快速切项目无串页;键盘、窄屏、长标题、千级节点懒加载、空/失败/受限/不可还原状态可理解。
完成条件:用户按三次主要点击任务完成取证,并人工评审界面是否直观;业务可用与视觉通过分别记录。
进展(2026-10-11,Dev PR #368 merge 7aa8fd9):U4 已实施合入——`RdmAuditWorkspace.tsx` 四入口(概览/资料文档/关联追溯/操作记录)Dev 前端 builtin 工作区,消费 U3 `rdm.inspect.*` 七命令面;`rdmCommand` 封装(receipt 解包+confirm-card 提示);DESIGN.md 令牌严格合规(0 裸色值/0 行内 fontSize/0 details/0 新增 keyframes)。附带修复 U5 遗留的 PreviewPane TS 类型错误(单参/双参签名匹配)。
### U5. 历史导出与正式集成验收
目标/需求:R5、R8、R9、R10;依赖:U2、U3、U4。
@@ -329,6 +331,8 @@ U1 同批接通旧客户端的项目选择和命令封装,并解析可信会
验证:导出中途有新写入不改变已固定内容;历史来源软删除仍可按授权追溯;未归属/缺失事件可见;跨项目下载、过期下载、权限撤销均拒绝。
完成条件:同一版本在 UI 与报告中结论一致,并有正式 GATE/REPLAY 证据。
进展(2026-10-11,RDM PR #213 merge 1dce69d):U5 已实施合入——`export_artifact.go` 导出工件生命周期(`rdm_export_artifacts` 表+磁盘存储+sha256 完整性+24h 过期);`rdm.inspect.export.{create,status,download}` 三命令(审计面授权、截止水位固定、跨项目绑定拒绝、下载重鉴权);导出文件名携带 `wm<seq>` 水印标记。U1–U5 五个实施单元全部完成,进入部署验收阶段。
---
## Deferred Integration
@@ -0,0 +1,48 @@
---
title: Generative UI auto-trigger opt-in design
date: 2026-10-12
type: feat
revision: r1
status: approved
product_contract_source: generative-ui-r2-U6-U7-boundary
---
# Generative UI 自动触发 opt-in 设计(r1)
依据:主记录 r2(语义事件 / 预算 / 防自激);收口稿已知边界;用户 2026-10-12
计划确认「边界三项全部做」并将本表定案作为实施基线。
负责人:裁定 weichen(用户,经执行计划确认);起草 Agent;更新时间 2026-10-12。
## 定案表
| 项 | 定案 |
|---|---|
| 开关 | owner 级 settings:`plugins.generative-ui.autoPresent`,默认 `false`;**不**写入 `plugin_activation`(避免 bump epoch) |
| 前提 | `plugin_activation(generative-ui).enabled` 为真;否则 auto 无效 |
| 事件 | 仅:任务阶段跃迁(plan/todo 状态变化)、材料/工件完成(material notice、document artifact) |
| 禁止事件 | per-token / 每条 SSE、`surface.updated`、动作回执、present 成功路径 |
| 动作 | 注入 system-reminder,**只**建议调用一次 `generative-ui.present`;不自动点 actions;不改写任务事实 |
| 预算 | 每任务(conversation)每小时 ≤3 次;耗尽写审计 `genui.auto_present_exhausted` |
| 冷却 | 同会话自动触发间隔 ≥60s |
| UX | 复用 U6 pin/follow;固定后新页不抢占 |
| 门槛 | 扩大范围仍以人类效率约 +20% 为后续条件;本增量只落地最小 opt-in |
## 实施面
- Backend:settings schema/defaults;`genui.Auto` 闸门;runmgr 语义钩子;审计。
- Frontend:SettingsModal 经 schema 出开关(无需专用页)。
- Documents:本提案 + 使用说明边界条目更新。
## 验收线
1. 默认关:无 reminder / 无额外 present 建议。
2. 仅 activation∧opt-in 时,材料完成 / 阶段跃迁 / document 工件可触发。
3. surface/action/present 路径不重入。
4. 第 4 次/小时审计耗尽并停止。
5. 冷却内跳过。
## 裁定记录
用户经「Implement the plan」确认本定案表;本文 `status: approved`,实施任务
`feature/genui-auto-trigger-optin` 按本表交付。
@@ -0,0 +1,59 @@
---
title: Generative UI B-class whitelist — builtin.help and system.intent
date: 2026-10-12
type: feat
revision: r1
status: approved
product_contract_source: generative-ui-u5-action-scope-r2
---
# Generative UI B 类加白提案:builtin.help / system.intent
依据:[U5 动作范围 r2](./2026-10-11-generative-ui-u5-action-scope.md)「每加一条走独立评审」。
本提案对两条命令分别裁定;实施与本提案同批合入。
负责人:裁定 weichen(用户);起草 Agent;更新时间 2026-10-12。
## 授权
用户 2026-10-12 计划确认:边界三项全部推进;B 类首批加白 `builtin.help` 与
`system.intent`。交付模式:authorized-continuous(本增量实施至 Dev 合入)。
## 一、builtin.help(独立裁定)
| 项 | 内容 |
|---|---|
| 命令 id / action id | `builtin.help` |
| 类 | B(白名单命令绑定) |
| 危险级 | 低(只读说明,无写副作用) |
| 参数 | 无必填 |
| 通道 | `POST /api/surfaces/{id}/actions` → cmdbus Entrance=`button` |
| 用途 | 页面按钮展示可用命令/入口说明 |
| 排除项对照 | 非业务写、非跨会话、非自动触发动作、非 MCP |
**裁定**:同意加白。
## 二、system.intent(独立裁定)
| 项 | 内容 |
|---|---|
| 命令 id / action id | `system.intent` |
| 类 | B(白名单命令绑定) |
| 危险级 | 入口本身低;**命中后嵌套分发可触达写命令**(既有 chat 行为) |
| 参数 | `text`(string,必填) |
| 通道 | 同上 Entrance=`button` |
| 硬化(加白前提) | **button 入口只返回 match / candidates,禁止嵌套 `Dispatch` 目标命令**;chat/slash/api 等既有入口行为不变 |
| 用途 | 页面上做意图探测/候选展示,不经按钮偷渡 D 类写 |
| 排除项对照 | 嵌套业务写在 button 路径关闭;仍禁止自动触发动作、MCP、任意命令全开 |
**裁定**:同意加白,前提硬化生效并有红测。
## 三、实施面
- Backend:`surfacesvc.AllowedActions`;`genui.ValidateActionIDs` / Catalog;`handleSystemIntent` button 只读。
- Documents:本提案 + 使用说明 API/动作表白名单更新。
- 红测:白名单外拒绝;help 可分发;intent button 命中写意图零副作用;chat 仍可嵌套。
## 四、明确不做
D 类业务写直执、扩大白名单至其他内置写命令、自动触发动作、动作结果自动改写页面。
@@ -0,0 +1,104 @@
---
title: Generative UI usage guide and U1-U6 evaluation record
date: 2026-10-12
type: feat
revision: r1
status: final
product_contract_source: generative-ui-r2
---
# Generative UI 使用说明与 U1–U6 评测记录
本文是主记录 r2(2026-10-10-generative-ui-plugin.md)的配套文档:面向使用者的启用/使用/
禁用说明,以及 U1–U6 各增量落地后的组合评测结论。状态:**final**(方向收口稿)。
## 一、使用说明(dev 实例实测口径,2026-10-12)
### 启用与禁用(owner 级)
```bash
# 启用(需 API key;服务以 --auth on 运行)
curl -X POST http://<host>/api/plugins/generative-ui/activation \
-H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
-d '{"enabled":true}'
# 禁用(新页面/新动作/迟到提交全部拒绝;历史页面保留只读)
curl -X POST ... -d '{"enabled":false}'
```
- 启用后 `generative-ui.present` 工具对模型可见(禁用时工具不注入)。
- 禁用即时生效:进行中的提交按 epoch 失配被拒,已保存页面按权限保留。
### 生成与修订页面(对话内)
对话中说「把 X 整理成一页对比 / 报告页 / 时间线」——模型调用 present 提交声明式页面:
- 页面自动在**文件预览区**打开;修订时说「改为按 Y 组织」,模型带 surfaceId+baseRevision 重提。
- 表单页可直接填写并点「提交」按钮(数据落插件台账,走命令总线审计)。
### 任务工作区(U6)
- **工作**入口的当前任务卡下方出现「任务页面」紧凑区:默认显示最新一页;📌 固定后
新页面不抢占;↗ 跳转文件预览全屏。
- 项目级跨会话聚合:`GET /api/projects/{id}/surfaces`(owner 作用域)。
### API 速查
| 端点 | 说明 |
|---|---|
| POST /api/plugins/{id}/activation | 启禁(epoch 递增) |
| POST /api/surfaces | 提交页面(直接 API,与插件同咽喉) |
| GET /api/surfaces/{id} | 读取整页快照(禁用后仍可读) |
| GET /api/conversations/{id}/surfaces | 会话内页面列表 |
| GET /api/projects/{id}/surfaces | 项目级跨会话聚合(U6) |
| POST /api/surfaces/{id}/actions | 页面动作(白名单:generative-ui.submit、builtin.help、system.intent;后者 button 只读匹配) |
## 二、U1–U6 落地与评测结论
| 增量 | 交付 | 关键证据 | 结论 |
|---|---|---|---|
| U1 受控试验 | Documents #62(r2) | R1 分化 6/6;文本通道下界 60%/83%;工具通道探针消除语法类失败;M3 ¥0.067/页;highspeed 否决为生成档 | 方向成立,生成走工具参数通道 |
| U2 契约/启禁/持久化 | Core #25/#26、Backend #143/#146、Dev #336 | 修订 1→2 冲突守卫、epoch 语义、事件恢复、SQLite/PG 双档 | 宿主地基就位 |
| U3 插件与上下文闭环 | Backend #149、Dev #345 | 真实模型回放 PASS(≈¥0.08);禁用不注入工具;语义投影回灌 | 模型可提交、可修订 |
| U4 只读渲染与恢复 | Core #27/#28、UI #42–#45、Frontend #53、Dev #351 | 刷新恢复、revision 守卫、SurfaceView | 页面用户可见 |
| U5 动作闭环 | Backend #155、UI #46/#47、Frontend #56、Dev #367 | 幂等同参回放/异参拒绝、DangerHigh 经确认卡不可伪造、草稿只在动作载荷 | 表单可提交且受控 |
| U6 工作区与项目聚合 | Backend #163、Frontend #62、Dev #408 | owner 隔离/跨 owner 零可见/禁用保留;pin 固定不抢占 | 页面进工作视图 |
### 现场体验驱动的修复(2026-10-11–12)
用户实测反馈「页面未出现 + 同名工件 ×3」→ 三个根因逐一修复(Backend #156/#160、
Frontend #58/#59,Dev #381/#382/#387/#388):工具描述缺「何时用」引导、事件分支缺
右栏切换、children 对象形状偏差、面板同名并列。修复后 E2E:真实模型 present 成功
(rev 1),surfaces 表落库,前后对照成立。
### U7 组合验收(2026-10-12,dev@b634a27,真实 MiniMax-M3)
- 会话内:新指令「实施进度页」→ 模型自主 present(steps 步骤条、三阶段、状态正确),
会话 surfaces = 2(对比页 rev1 + 进度页 rev1),修订链完整。
- 项目聚合:GET /api/projects/{id}/surfaces 返回跨会话页面(owner 作用域验证)。
- 工作区:前端「任务页面」容器显示最新页(pin/follow 测试覆盖)。
- 收据:Dev 任务卡 feature/generative-ui-u7-acceptance(SELF;CI GATE 随发布 PR)。
### 现场体验驱动的修复记录
| 日期 | 症状 | 修复 | PR |
|---|---|---|---|
| 2026-10-12 | `POST /api/surfaces/{id}/actions` 对无确认卡的 committed 动作 panic(nil Card) | dispatcher 空指针守卫 | Backend#173 |
| 2026-10-12 | `system.intent` button 动作恒报 missing text | action data 键上浮到命令 params | Backend#174 |
## 已知边界与后续项
- 自动触发 opt-in:settings `plugins.generative-ui.autoPresent`(默认关;须同时
Surface activation);语义事件 + 预算≤3/时 + 冷却≥60s;设计见
`2026-10-12-generative-ui-auto-trigger.md`。
- B 类命令:已加白 `builtin.help` / `system.intent`(button 入口 intent 只读匹配、
不嵌套分发;提案 `2026-10-12-generative-ui-bclass-help-intent.md`);其余仍逐条评审。
- 人类可用性对照以 owner 实际使用替代(2026-10-11 用户裁定),本轮体感「初步不错」,
小问题另行修复。
- 部署与运行验收:本机 `prod` 实例已登记(`scripts/svc.sh prod`,`--auth on`,
PG `pg1/prod`,来源 `dev@c76f2bb`+后端 nil-card 修复);验收覆盖启禁、present、
B/C 类动作、项目聚合、未登录 401。
## 三、结论
Generative UI 方向按主记录 r2 的 U1–U7 全部增量落地:调研→契约→生成插件→只读渲染→
动作闭环→工作区→组合验收,每个增量独立走组件 PR + Dev 组合 CI + 任务闭环,真实模型
证据贯穿(试验、回放、现场 E2E)。方案收口为 final;后续按「已知边界」清单演进。
@@ -0,0 +1,539 @@
---
title: RDM 功能、实现与计划矩阵及追溯审计和权限闭环整改方案
date: 2026-10-12
type: fix
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: legacy-requirements
---
# RDM 功能、实现与计划矩阵及整改方案 r1
负责人:weichen;编制:Codex;核对日期:2026-10-12(北京时间)。
本稿供人工评审,尚未批准实施。此次仅研究、读取运行元数据与保存报告;未实施业务代码、操作业务数据库、执行测试、部署或重启。
保存说明:Dev 首次启动检查因 Backend 的 `index.lock` 返回 `SHARED_WORKSPACE_BUSY`。按 `AGENTS.md` 任务启动门禁,不创建项目 worktree、不写共享检出;报告暂存为独立交付文件。入仓时由项目 owner 排除共享写入冲突后,在登记任务 worktree 保存到 Documents proposals,并更新 INDEX/PROJECT 的入口。此次没有修改这些入口。
### 发布补记(2026-10-12 入仓时)
本稿冻结观察之后的运行时变化(独立于上文,不回改冻结记录):
- dev 槽位部署时序(北京时间):14:54 `rdm@310c3fe` → 15:50 回滚普通基座 `dev@4bf6e4a`(根页此时已 200 服务 React 资产)→ 16:37 刷新为 `dev@0d224ff`(权威 main 组合,backend=5e8ada7 / frontend=cc233fe,plugins 目录无 RDM 插件)。「根页 404 与缺少嵌入产物一致」的判断已被 main 组合现状超越;RDM 组合产物与门控验收仍开放(U1/PR #450 线)。
- 本稿 U2 执行端问题表第 1-5 行与第 7 行前半已按本方案在 Agent-System-RDM 合入(PR #251/#254/#256/#258,红测先行,CI 绿);第 6 行归 U4、第 7 行后半归 U5、第 8 行待私域语义设计。行号引用基于冻结源码 1ee2b300,合入后有所漂移。
## Goal Capsule
使创建者能在实际使用的 dev 服务中管理项目成员与文档职责,使管理员能创建专业角色并配置权限,使编制、审核、批准人员完成同一份文档的审签,并能从实际页面追溯来源、操作与历史。
复用现有 RDM 项目、成员、权限、两树一网与审签组件,先修组合产物及执行端缺口,再接现有项目设置、系统管理与文档工作区,最后按真实账号验收。完整目标仍覆盖全部 34 UR、68 SR、10 F,不以本次五个问题修好替代全系统交付。
本稿终点为可评审矩阵和方案。实施、真实账号测试、数据迁移、部署及正式验收各在对应授权后进行。当前用户请求未授权这些动作。
## Product Contract
### 来源与权威
1. 本轮用户报错及补充:访问 `localhost:8788`,58880 是 FRP 映射,实例为 dev;要求核对全系统,重点追溯审计、三权、项目成员、系统角色、权限矩阵。
2. RDM `docs/requirements/README.md:15-32` 规定的 V2.2 正文与 U0/Q 裁定;重点 `01-用户需求与系统需求.md`、`03-产品设计方案.md`、`08-核心数据模型-两树一网.md`、`10-实施推进方案-基座与下游二次开发.md`。
3. RDM 原始用户补充 `docs/materials/meeting-sources/user-supplement.txt` 和 `user-design-ideas.txt`;原始内容用于解释需求,不反向覆盖较新裁定。
4. Documents `docs/proposals/2026-10-11-rdm-final-target-completion.md`、模板子方案、两树一网追溯展示方案;主计划与任务卡存在历史批准记录,页首残留“待评审”不能单独否定批准。本次整改路线仍需评审。
5. RDM `docs/records/2026-10-11-requirements-evidence-matrix.md` 是逐条维护入口;Documents 副本是旧附件。`2026-10-12-final-acceptance-ledger.md:39-53` 全量运行验收仍为 NOT_RUN。
UR-21(系统角色权限)、UR-22(项目和成员)、UR-24(文档三权)均为本期 P0 已定需求,不能再解释为尚未决定是否做。管理权不赋予代编、代审、代批权;文档编制唯一、批准唯一、审核至少一人,三种职责互异。项目创建者在平台上限内覆盖项目权限。私聊、原件和个人草稿私有,受控文档按职责或显式授权读取。
### 核对对象及证据边界
| 对象 | 固定版本 / 观察 |
|---|---|
| Dev | `8c1edbebece8212ec8c0cd9e646b4b0592b1503d`;研究初始为 `72f6a679`,期间由其他任务更新 |
| Backend / Frontend | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` / `cc233fec908d0f8c12193042942b94ad68508091` |
| Documents / UI | `9d9b1523c87dc4ba178d143a8b966a77be9b320b` / `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700` |
| RDM 本地源码 | `1ee2b300a9c898ef5b9e2febafa6b0f2eb871c15` |
| dev 当前 RDM 部署来源 | `310c3fe42fec2416b8b1e1e72e00ad2e53b58130`;相对 1ee2b300 仅四个 pins 与任务卡变化,本文 RDM 业务行号仍适用 |
| dev 当前进程文件摘要 | `420654002eb0cdc28ce9d90a8d258f215192dee78ff74195db2b2657b3fe3fff`;2026-10-12 15:04:37 核对 |
| 服务访问 | user 确认 58880→8788;本轮直接 GET 8788 根路径为 404,未登录 GET `/api/commands` 为 401 |
| 对照实例 | 9015 的命令清单有 enabled 的 inspect 命令;这是另一实例,不能作为 dev 通过依据 |
15:24:29收尾刷新:Dev主检出由其他任务推进至 `0d224ffcab82cab7def2c0b0cc36d2e6d02ce3dd`,Documents至 `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`;RDM业务源码、Backend、Frontend、dev部署来源及进程摘要均与上表一致。8788根页仍404,未登录命令清单仍401。新收据 `runtime-refresh-receipt.json` 保留该时间点,不覆盖15:04的调查收据;本文RDM需求与业务判断仍以固定1ee2b300为对象。
源码阅读、运行登记、HTTP GET 与本稿审阅均为 SELF;没有复核 GATE/独立 REPLAY,不作业务 PASS 判定。完整命令输出由 `make evidence` 保存为随附收据,未手工重构。测试文件存在只表示已有测试资产。
### 追溯审计故障结论
2026-10-12 **14:50:06.701 北京时间** 的 `unknown or disabled command` 是命令总线 `Resolve` 阶段失败(Dev Backend `internal/cmdbus/cmdbus.go:252-254`),服务将 rejected 映射为 HTTP 400(`internal/server/server.go:1012-1014`)。该阶段尚未进入 RDM 的项目/审计权限判断;放宽权限不能注册一个不存在的命令。
同一 dev 的部署历史显示:13:38:38 启动 `dev@4bf6e4a` 普通基座,14:50:48 停止,14:54:49 启动 `rdm@310c3fe`。用户确认访问这台服务。基座入口仅 import 基座 app;RDM `main.go:18-23` 才 import `plugins/rdm`,后者 `plugin.go:17-21,173-179` 注册命令。因此,故障时**正式前端暴露了研发审计入口,而同实例运行普通基座、没有 RDM 命令**,有部署历史和组合根源码支撑。
此后其他任务已切换部署,不意味着审计运行验收完成:当前 8788 根页 404,命令清单需有效登录才能核对。本轮未借用账号、创建凭证或发送会写审计回执的业务 POST,未重现当前登录态下 capabilities 调用;历史故障定位与当前修复验收分开记录。
现有 Frontend 已增加七命令门控及人话错误,见 `src/workspaces.ts:22-36`、`src/store.ts:794-801`、`src/rdmErrors.ts:16-24`。仍有三项接线缺口:
- RDM `Makefile:39-40` 只 Go build;Dev `scripts/svc.sh:1446-1464,1594-1600` 对 RDM 也只构建 Go 并复制独立 `web/`。更新 frontend pin 没有构建及嵌入 React dist;Backend `web/embed.go` 要求构建前具备 dist。当前根页 404 与缺少嵌入产物一致。
- `AdminZone.tsx:37,67-71` 的声明管理分区没有消费七命令门控;插件注册失败允许保留部分能力(Backend `internal/app/compiled.go:198-202`),所以“插件列表有 rdm”仍不足以证明审计页可用。
- 错误分类把 403 和 401 都解释成登录失效;实际已登录但无权限时应展示权限拒绝。原始 receipt.reason 要保留。
密码字段未处于 form 的浏览器提示是独立问题,不会造成命令注册失败。React 主动改密、登录及强制改密已有 form 修复;RDM 独立 web 的令牌 password 仍位于普通 div。修复有源码记录,当前浏览器验证 NOT_RUN。
### Requirements:本次整改验收要求
| ID | 用户可见行为 | 原需求映射 | 判据 |
|---|---|---|---|
| R1 | 同一正式入口加载匹配的研发前端与 RDM 后端 | UR-08/25,SR-D1/D6/G3/G5 | 登录后七命令齐备并可查询有数据项目;无 RDM 时不出现可进入后即 400 的页面 |
| R2 | 创建者在项目设置添加、移除、调整成员 | UR-22,SR-G9/G10 | 选择有效系统账号,加入后同 projectId 可见;最后负责人保护;撤权立即影响现有访问 |
| R3 | 管理员创建/停用专业角色、分配账号并设默认和上限 | UR-21,SR-G6/G7/G8 | 自定义角色持久化;重启保留;项目设置不得扩大系统上限 |
| R4 | 系统和项目矩阵解释实际允许/拒绝 | UR-17/21,SR-G2/G6/G7/G8 | 同一动作矩阵结果与 API/命令/工具/后台执行一致,能显示默认、上限、覆盖与原因 |
| R5 | 创建者按文档分配编制、审核、批准 | UR-24,SR-C7/G9 | 有效项目成员、三种职责互异;资格不足明确说明;无职责任务保持可见等待 |
| R6 | 三个人完成固定整文版本审签 | UR-24/25,SR-C3/C7/C8/D6/G3/G5 | 非编制不可改正文;审核可批注/驳回;所有审核完成才批准;旧票不能签新正文 |
| R7 | 图、历史、导出及文档读取符合当前授权 | UR-08/23/25/33,SR-D/G/N4 | 合法职责人员能读自己的文档;跨项目/私域不可见;审批与导出是同一固定快照 |
| R8 | 界面、对话、工具、卡片访问同一对象与执行服务 | UR-10/16/27/28,SR-E/F,F-06 | 右栏关闭仍可完成支持的动作;模型不能伪造身份或自动签字;撤权及迟到结果不旁路 |
### 功能、实现、缺口与计划矩阵
“已有”仅描述固定源码中的能力;“UI 缺口”指正式用户路径未闭合。除特别列出的只读观察,全表运行验收 NOT_RUN。U 编号均带方案名称,避免“追溯展示 U3”和“完整目标 U3”混用。
| 功能域及需求 | 当前已有实现 | UI/对话与执行缺口 | 后续工作与现有计划归属 |
|---|---|---|---|
| 项目身份/成员:UR-22;G9/G10 | 全局研发项目、生命周期、成员持久表、成员可见同项目目录;局部 #203 | 项目设置无成员页;有效账号目录及可信宿主映射未闭合;新旧成员守卫不同;建项与owner写入非原子 | 本稿 U3/U6;完整目标 U2 |
| 角色/权限:UR-21/17;G2/G6-G8 | 12 动作、全局 cap、项目成员 override;cap∩默认/覆盖 | 角色固定 admin/owner/member;没有专业角色CRUD或完整矩阵;多个业务入口绕过 cap | 本稿 U2/U4/U6;完整目标 U3 |
| 三权/版本:UR-24/25;C3/C6-C8 | 文档职责默认及章节覆盖 #205;章节审签;持久提案、整文内容快照 #217 | 没有分配页;schema 与可信身份互斥;审签仍按章节;非编制写入、审核驳回、整文批准快照未闭合 | 本稿 U2/U5/U6/U7;完整目标 U3/U8,模板子案 U3-U5 |
| 资料接收/解析:UR-01-04/18;A1-A5/B1-B7 | 原件、三态相关性、MD/TXT/DOCX、快慢处理;台账私域 #209;锚点 #211 | PDF/表格/PPT/图片未完整接线;三个附件无文字实测、60秒反馈及10分钟级管道没有实际签收 | 完整目标 U5/U9/U14;在本稿 U8 衔接 |
| 结论/冲突:UR-07/26/34;B8/B9/B11/B12 | 提议确认、词面冲突、指定冲突对关闭与水位修复 #215 | 完整候选组、文档依据/项目结论两层裁决、来源变更影响与通知闭环未充分完成 | 完整目标 U6;本稿 U8 衔接 |
| 模板/全文档:UR-05/15;C1/C2 | 69 类型 catalog #207;正文 registry 仍4模板、3文档类型 | 目录登记不是全部模板;结构/格式/发布版及XLSX、全量生成审签导出未验收 | 完整目标 U7→U8→U16;本稿 U8 衔接 |
| 对话生成:UR-10/11/12/16;E1-E6/F1-F5 | 模型 compose、持久提案、原子采纳、整文内容快照 #217/#219 | 全动作自然语言及工具投影缺失;依据完整性、差异采纳与真实模型/用户链待验证 | 本稿 U7;完整目标 U8/U9 |
| 私域/项目协作:UR-23;G11-G13/N4 | 基座owner会话隔离;上传及确认资源约束 #209 | 同项目草稿/原件/受控文档全读面、Host检索、明确只读分享与撤权需贯通 | 本稿 U2/U4/U5;完整目标 U3/U5/U9 |
| 追溯/审计/历史:UR-08/25;D1/D5/D6/G3/G5 | 两树、一般网/合规网、原子事件、inspect和导出;追溯展示 #195/#197/#201/#213 | 用户dev曾未组合RDM;新产物无React根页;Host审计覆盖仍缺;四链/完整矩阵实际展示未全部接线 | 本稿 U1/U7/U8;完整目标 U4/U11/U14、F-09 |
| 需求/风险/合规:UR-09/33;D2/D7-D11 | 控制节点/候选边/确认 #231、req→graph #233、UR→SR及需求快照 #235 | 真实风险→措施→验证及SOUP、六维分解、四链业务录入、专家校准及真实交付尚待验证 | 完整目标 U11/U14;本稿 U8 衔接 |
| 法规双通道:UR-13/14;F3 | #236已实际HTTP抓取候选、摘录核对、快照;“只模型URL”旧结论过期 | 真实权威素材、失败/冲突/版本场景及首批模板法规闭环仍未签收 | 完整目标 U12;本稿 U8 衔接 |
| 快慢任务/卡片:UR-27/28/29/30;B10/E/F | 卡片/小队;slow保存原文且可重新入队 #219 | slow台账未保存project/owner,恢复入队传空项目;取消/恢复/重新授权、同源卡片与模型结果需闭合 | 本稿 U7/U8;完整目标 U9/U13 |
| 阶段/结项:UR-06/17;C5/G2 | 阶段序列、三级门禁、close/只读 #226 | 主要检查章节无版本/正文“待确认”;阶段适用文档、批准快照、验证过期、N/A和旧确认缺失 | 完整目标 U10;本稿 U8 衔接 |
| 团队存储/执行/运维:G16/N1-N5 | PG方言 #224、迁移 #242、sandbox #244、备份发布/长驻工具 #248;Dev存储组合#446于收尾已合入 | dev实际使用档位未核;RDM多实例租约/恢复、容量、故障/回滚验收未签收;复用Dev已交付存储能力 | 完整目标 U13/U14;衔接存储/恢复总案 |
| 自举/完整交付:UR-19;G4 | U14台账骨架 #246 | R1-R15与九层验证仍NOT_RUN,不能由局部merge宣称“系统完成” | 本稿 U8;完整目标 U14 |
| 飞书/变更/遗留扩展:UR-20/31/32;G1/G14/G15/D4/F-01-F-10 | 目标和依赖有记录 | 飞书、完整变更引擎、细粒度分享、权重、代码集成、遗留决策、难度机制仍后续;后移不等于取消 | 完整目标 U15;F-06→U9/U14,F-09→U11/U14,F-10待用户标准模板 |
覆盖口径:SR 分组 A5/B12/C8/D11/E6/F5/G16/N5,共68;UR34、F10的逐条定位见附录。项目能力、实际UI、工具路径、部署与验收应各列证据,避免一个“完成”字段盖住五种状态。
### 已静态确认的执行端问题
| 问题 | 固定源码定位 | 必要修正 |
|---|---|---|
| 审签接口无可成功参数组合 | RDM `plugin.go:500-501,509-510,518-519` 强制 reviewer/actor/approver;`:1461-1462,1488-1489,1515-1516` 拒绝这些字段;Backend `cmdbus.go:384-402` 检查required | schema删除身份输入,只认认证actor,项目/固定提交对象必需;补真实总线和HTTP测试 |
| 新旧成员命令绕过不同约束 | RDM `projects_api.go:317-380` 新路径不查member.manage上限;`plugin.go:2212-2245` 旧路径直接Remove;`members.go:54-59` UPSERT可降级最后owner | 所有入口共用服务,原子保持最后owner、归档状态、账号有效性与上限 |
| 配置的建项权限未作用于创建 | RDM `plugin.go:2041-2054` 仅检Actor非空,ActProjectCreate没有接入 | 按专业角色有效权限判建项,不能一律管理员限定或一律认证即可 |
| doc.write不等于编制职责 | RDM `plugin.go:2510-2536,2581-2588` 仅通用写动作;`doctree.go:152-168` 仅状态守卫 | 所有生成/编辑/采纳/改来源写入口再查本文档编制职责 |
| 阶段只读约束未接业务读面 | RDM `perms_api.go:80-100` AuthorizeDocRead生产路径未消费 | 列表、详情、搜索、导出、Host及恢复统一资源授权 |
| 角色/上限模型维度不足 | RDM `perms.go:42-55,70-94,310-324` 固定默认,cap主键仅action | 持久专业role的默认/上限,解释有效权限,不只在UI加checkbox |
| 审核人不能驳回,职责可换人继承旧审核 | RDM `review.go:243-245,276-279` 读当前职责,ReviewCard未冻完整职责;`:111-119,141-149` 可覆盖职责 | 冻结整文提交的职责/策略版本;改职责使受影响审核失效;审核人可驳回,编制撤回独立 |
| 草稿列表未按个人/文档资格过滤 | RDM `draftproposal.go:135-150` 无actor;`plugin.go:2567-2578` 仅doc.read | 私人提案按owner;受控文档按职责/明确授权;分页/计数同样过滤 |
上述为源码确定或静态路径推导,没有在真实账号下重跑。现有 `plugins/rdm/three_sig_test.go:18-25,73-75` 构造Actor并直接调handler,未走登录和总线。函数名“RealAccounts”不能提升为真实账号验收。
## Planning Contract
### KTD1. 组合产物与正式入口
推荐 RDM 产品用固定 pins 的 React 前端与 RDM Go 组合二进制形成正式产物,复用 Backend embed 的公开构建机制。RDM构建必须构建frontend→装入backend/web/dist→Go编译;不能只升级gitlink。构建在独立物化目录完成:从固定pins复制/物化基座组件,以Frontend既有frontend/ui邻接布局构建,将dist写入该目录中的Backend,再由隔离构建映射消费;RDM仓的pins检出保持只读,不把产物或源码修补写进pins。发布清单记录 RDM/backend/frontend/ui SHA、dist摘要、二进制摘要和能力契约版本。构建/安装阶段拒绝声明“完整Web产品”但缺index/bundle的产物。
独立 `RDM:web/` 留作历史诊断入口,退出正式产品唯一流程,迁移前明确旧链接兼容和私有访问策略。若用户选择独立静态React+API部署,则同样固定双产物清单、同源反代与认证;这是部署形态备选,不能复用旧斜杠工作台宣称正式管理界面已完成。
### KTD2. 一套执行端授权及项目身份
账号、认证、平台管理员和通用资源执行边界由基座维护;研发项目/成员、专业角色、领域动作、职责与文档状态由 RDM 维护。公开扩展不足时沿 RDM 的四要素扩展申请,禁止导入基座internal或修改pins源码。
新旧命令、UI、工具、后台恢复都调用同一 RDM 应用服务。平台账号目录只提供授权管理所需的最小公开身份/有效状态与分页,不提供私聊/原件;`AdminProvider.IsAdmin` 已有,不能再当缺失能力重建。创建者、当前owner、RDM域管理员、平台管理员各保留来源,审计能力不自动升级成绑定/成员写权。RDM项目创建与初始负责人必须同事务;Host映射检查双方资格并可恢复重试,不能以复制个人项目解决共享身份。
现有公开EXT-8仅接主体和projectId,HTTP自有工件命中不咨询回调,共享列表按整项目放行;因此本稿U9先提供通用资源级公开授权契约及消费接线。可信资源类型/ID、资源属主、项目和动作由执行端解析,RDM只作领域判定;注册新策略后,域内自有/共享读取、列表、检索、Host及下载均执行同一判定,不能仅在RDM命令handler加守卫。未注册的普通基座保持既有行为;RDM受控产品若缺必要契约,禁止启用扩大共享读取的旧回退。衔接已有协作存储KTD13动作授权,复用当前内部项目动作槽,补资源维度及公开注册,而非再造平行授权器。
读路径不修复业务数据。授权检查覆盖每个请求与资源,未知身份/关键能力默认拒绝;这与现有规范及 [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) 一致。本文更细的项目和职责规则来自已批准需求。
### KTD3. 专业角色与矩阵
区分四个对象:平台管理身份、项目管理关系、专业角色、文档职责。用户界面的 ADMIN/USER、成员表的owner/member以及文档三权不是专业角色CRUD。
专业角色在系统范围建定义,保存稳定roleId、名称、停用状态、版本、动作默认、动作上限及账号关联。owner/member继续表示项目关系,roleId不写入members.role字段。管理员设置每角色上限;负责人只在许可的成员/项目范围覆盖。首版每账号一个生效专业角色,避免未经确认采用多角色叠加;未来多角色规则另行评审。
有效权限在服务端计算:平台硬禁止 ∩ 角色上限 ∩(项目显式覆盖或角色默认)∩ 资源关系/阶段/状态/职责。文档签字资格还要求当前有效成员、已分配职责、互异历史、固定提交轮次;指派职责本身不解除上限。矩阵显示最终结果和第一拒绝原因,UI不重新计算。
旧cap转换为同等限制,固定默认映射到兼容内置角色,旧override不被扩大。变更前干跑列出有效权限差异;同级迁移不得扩大有效权限。新角色或权限新授予由有权管理员明确执行。新增schema迁移需向前迁移及恢复方案,不能把旧二进制直接启动在不兼容新库上。
### KTD4. 整文三权与历史保全
一份受控文档对应一组编制/审核/批准。项目设置提供文档清单与批量分配入口;项目默认职责规则如需提供,须单独定义生效/覆盖语义,不能悄悄把成员的通用角色当所有文档职责。章节可分配贡献工作,正式整文签字不采用章节覆盖改变整文责任。
整文提交冻结:文档ID、有序章节集合及版本、整文内容、模板版本、依据快照、编制/全体审核/批准人、职责版本、策略版本、提交轮次和完整内容摘要。现有整文内容快照可复用,需补这些治理字段并绑定审批、历史和导出。未知事件版本或不可还原必须报错。
签字取可信actor,HTTP不能传reviewer/approver替代主体。智能体可以准备正文、修改提案、批注建议和待提交操作;人的审核/批准须由该人的认证会话确认,模型无自动签字权。审核人可批注/通过/驳回但不改正文;编制撤回单列。职责变更、撤成员、改正文/依据/模板使受影响待审结果失效,不能换职责让原作者自审同一提交。已批准历史保留,下一正式版本重新审签。
旧章节审签作为历史证据保全,不聚合成“整文已批准”;迁移时对活动轮次作显式处理,首个整文版本重新签署。没有明确规则时暂停有关旧轮次,不静默迁移票据。
### KTD5. 现有界面与对话接线
沿三栏:左侧项目/会话,中间对话,右侧工作/文件。系统管理新增“角色”“权限”;现有项目设置新增“成员”“项目权限”“文档职责”;文档预览/工作卡提供“编制、审核、批准”状态及动作。审计仍用四入口并补受控链/矩阵;不新增独立控制台或第二预览。
项目设置读取 `canManageMembers/canConfigurePermissions/canAssignDuties` 等实际能力,普通成员可读自身资格但不可管理。系统角色、账号全局专业角色关联和全局上限由平台有权管理员配置;项目成员页显示该关联并管理项目成员关系,不授予创建者修改账号全局专业角色的权限。RDM域管理员的业务管理范围保留,是否可改平台上限不从审计兜底权限推断。矩阵分“角色×动作”和“项目成员×动作”,职责清单则“文档×编制/审核/批准”,避免一个表混淆三种对象。
所有页面共享单一能力状态所有者;七命令门控同时约束工作区、声明管理分区和已挂载页面。退出登录、切项目、能力撤销应作废旧结果。请求generation/seq处理快速对象切换与历史查询;计数缺失显示“未提供”,失败不显示空数据。401/403、能力缺失、参数/状态冲突、服务失败分别呈现并保留原receipt。
对话和工具投影使用原子领域动作、真实project上下文及typed CommandResult;高危命令带conversationId和确认卡上下文。自然语言解析出的用户/项目名称仅作查找候选,最终使用稳定ID并校验。不把手写斜杠或登记handler当自然语言能力已就位。
### High-Level Technical Design
```mermaid
flowchart LR
UI[系统管理 / 项目设置 / 文档工作区] --> C[同源命令与确认回道]
Chat[对话 / 工具 / 工作卡] --> C
C --> I[基座可信身份与当前项目]
I --> A[RDM统一动作与资源授权]
A --> P[项目 / 成员 / 专业角色策略]
A --> D[文档职责 / 整文提交 / 审签]
D --> E[原子事件 / 正式快照]
P --> E
E --> R[审计 / 历史 / 合规 / 导出读面]
R --> A
```
```mermaid
stateDiagram-v2
[*] --> 等待分配
等待分配 --> 编制中: 指派有效三权
编制中 --> 审核中: 编制人提交整文快照
审核中 --> 待批准: 所有审核人通过
审核中 --> 编制中: 驳回 / 撤回 / 快照失效
待批准 --> 编制中: 驳回 / 撤回 / 快照失效
待批准 --> 已批准: 指定批准人确认
已批准 --> 编制中: 新内部修订
```
```mermaid
sequenceDiagram
actor Creator as 创建者
actor Writer as 编制人
actor Reviewer as 审核人
actor Approver as 批准人
participant Service as 统一文档服务
Creator->>Service: 分配有效成员及职责
Writer->>Service: 提交固定整文 / 版本 / 职责 / 策略
Reviewer->>Service: 认证身份审核同一提交轮次
Service->>Service: 校验全部审核及当前授权
Approver->>Service: 认证身份批准该提交
Service-->>Writer: 正式版本与固定快照导出
```
## Implementation Units
本稿U1-U9为整改任务包,按依赖安排;不同于既有方案U号。U9为审阅补入的公开契约前置,编号不重排。责任角色为后续立项时指定的Dev组合owner、RDM实施者、Frontend实施者和独立审阅者。本轮不代指具体执行人。工作量是待排期的估计区间,不是工期承诺,项目数据量/迁移规模核定后更新。
| 本稿工作包 | 依赖 | 优先级 | 交付内容 | 粗估工作量 | 对应完整目标总案 |
|---|---|---|---|---|---|
| U1 | 无 | P0 | 正式产物/根页/审计入口与实例证据 | 2-4人日 | U4/U11/U14及追溯展示补闭环 |
| U9 | 无;与U1并行 | P0 | 公开资源/账号/宿主资格契约及基座消费接线 | 4-7人日 | X1/X2、U2/U3及存储KTD13 |
| U2 | U9发版与RDM升pins;schema局部修正可提前 | P0 | schema、统一执行端与私域安全收口 | 3-5人日 | U2/U3/U8 |
| U3 | U2;账号目录扩展 | P0 | 项目成员/唯一身份/有效账号闭环 | 3-5人日 | U2 |
| U4 | U2/U3 | P0 | 专业角色与解释矩阵 | 4-7人日 | U3 |
| U5 | U2/U3/U4 | P0 | 整文三权与批准快照 | 6-10人日 | U3/U8 |
| U6 | U3/U4;职责页依赖U5 | P0 | 系统/项目管理页面 | 4-6人日,可与服务契约后并行 | U2/U3/U8 |
| U7 | U5/U6 | P0 | 对话/卡片、审计完善、真实用户闭环 | 4-7人日 | U8/U9/U11/U14 |
| U8 | 对应已有基础及U7 | P1并保持既定需求优先级 | 全系统余量、模板/法规/阶段/团队验收 | 各子任务另估 | U5-U16 |
### U1. 固定产品组合并恢复审计正式入口
**Requirements:** R1/R7;**责任:** Dev组合owner+RDM构建owner。**Files:** RDM `Makefile`、`scripts/pack-release.sh`;Dev `scripts/svc.sh`、`modules/backend/web/embed.go`(复用机制)、Frontend `src/store.ts`、`src/workspaces.ts`、`src/components/AdminZone.tsx`、`src/components/RdmAuditWorkspace.tsx`、`src/rdmErrors.ts`。
**Approach:** 先基于现有实例历史保留故障证据,固定RDM+四pins+实际bundle+二进制和数据绑定。补 pinned React embed构建与产物完整检查;统一全部入口能力门控、可见失败和错误分类。插件必要注册失败不能静默声明完整产品可用,可让启动拒绝或标为不可用,但不可留下可点击的半套管理面。正式环境切换需批准,备份和恢复与已有svc方案衔接。
**Tests:** 扩展 Frontend `test/workspaces.test.ts`、`test/rdm-errors.test.ts`、`e2e/plain-base.playwright.ts`、`e2e/rdm-audit.playwright.ts`;Backend `internal/app/compiled_list_test.go`、`internal/server/compiled_list_test.go`;新增RDM `scripts/rdm-product-smoke.sh`(拟建),验证实际产物而非Vite预览。
- 基座无RDM、只注册部分、命令disabled、声明分区残留:均不自动发失败审计请求;已开页面能转不可用态。
- 构建后真实根页200及JS/CSS匹配固定frontend SHA;缺dist拒绝作为完整Web安装;清洁重构建不能借旧dist成功。
- 有效登录后dev命令清单及capabilities成功;创建者/域管理员/纯平台管理员分别查询各自可审计范围;外部账号拒绝。
- 403权限拒绝与401过期文案不同;query失败保留reason;密码form警告独立回归。
**完成条件:** 实际8788及FRP入口能加载同一批准产物并查询有数据项目;没有以9015对照或health代替。工作树和CI的验证身份仍按SELF/GATE/REPLAY区分。
### U2. 修复命令契约并统一授权服务
**Requirements:** R2/R4/R6/R7/R8;**依赖:** U9的公开契约、基座发布和RDM升pins,schema修正可先独立交付。**责任:** RDM实施者,公开扩展由Dev责任人承接。**Files:** RDM `plugins/rdm/plugin.go`、`internal/rdmapp/perms_api.go`、`projects_api.go`、`draft.go`、`draftproposal.go`、`internal/domain/doctree.go`、`review.go`;Dev公开契约与执行端消费者按U9先交付。
**Approach:** 先写真实注册总线/HTTP用例捕获schema身份矛盾,删除客户端签字身份字段。梳理全部命令、工具、上传、下载、Host和恢复路径;新旧成员命令兼容别名调用同一服务。统一动作+资源+状态守卫,归档/结项禁止新业务写;草稿列表及聚合计数按可见性过滤。合法用户职责可读文档,不错误要求全项目审计权。
**Tests:** RDM `plugins/rdm/three_sig_test.go`、`internal/rdmapp/perms_test.go`、`resource_authz_test.go`;新增 `plugins/rdm/command_bus_contract_test.go`(拟建,消费公开extension启动/注册路径,不导入Backend internal)。
- 不提供身份字段的合法approve/reject/final能通过schema;伪造字段、空project、错对象所属项目拒绝。
- 各别名在禁member.manage、归档、最后owner更新/移除时结果一致;并发变动不移除最后owner。
- reviewer/approver/普通成员/管理员无编制职责时各内容写入口拒绝;指定编制且动作上限允许时可写。
- 禁阶段、私有草稿/原件、撤权后的旧卡/任务/下载均拒绝;过滤后的分页/计数不泄漏。
**完成条件:** 建立入口×动作×身份×资源矩阵,直接handler单测之外有真实总线/HTTP正负例。
### U3. 项目成员与可信账号目录
**Requirements:** R2/R5;**依赖:** U2。**Files:** RDM `internal/members/members.go`、`internal/rdmapp/projects_api.go`、`plugins/rdm/plugin.go`;Dev公开身份/账号目录扩展申请与相应Host实现;Frontend `src/api.ts`。
**Approach:** 研发项目和初始owner原子写,Host一对一映射双方授权核对。有权管理者分页查找最小有效账号,添加/调整/移除均按权限及生命周期;创建者事实保持不可改,owner变动不伪造创建者。幂等请求记录稳定operationId及策略版本,成功后加入账号看到同一项目并新建私有会话。
**Tests:** RDM `internal/members/members_test.go`、`internal/rdmapp/sysproj_test.go`;基座账号/Host扩展新增契约测试(路径立项时固定)。
- 非有效账号/停用账号不能加;非管理者查不到全系统用户目录;搜索和分页只返回必要字段。
- 双用户同名建项、owner写失败、Host绑定失败/恢复、绑定他人宿主项目均不留下可用的错误项目。
- 最后owner改为member、旧命令强制member、并发移除均守不变量。
- 加入→同ID可见→私有对话;移除→现有会话/模型读取/导出立即受限,历史操作保留。
**完成条件:** 真账号项目生命周期闭环,身份目录、领域项目与宿主映射有固定公开契约。
### U4. 专业角色与可解释权限矩阵
**Requirements:** R3/R4;**依赖:** U2/U3。**Files:** RDM `internal/perms/perms.go`、`internal/rdmapp/perms_api.go`、`plugins/rdm/plugin.go`;拟新增 `internal/perms/roles.go`、角色/关联迁移及解释DTO。Frontend渲染由U6承接。
**Approach:** 按KTD3建持久专业角色、版本及账号关联;角色CRUD、默认/上限更新、项目覆盖、解释读面都调用统一evaluator。平台管理员信任来源经Host,不接受param.isAdmin。矩阵查询按管理范围过滤,返回动作目录、默认、上限、覆盖、有效值及来源/拒绝原因,资格变化使旧许可立即失效。
**Tests:** 扩展RDM `internal/rdmapp/perms_test.go`;拟新增 `internal/perms/roles_test.go`、`plugins/rdm/roles_contract_test.go`。
- 创建自定义角色、关联账号、修改/停用/重启,结果持久且内置系统身份不可经角色CRUD伪造。
- default允许+cap禁止+override允许仍拒绝;撤上限后旧override即时失效;负责人不能改全局角色上限。
- 矩阵解释与实际业务调用逐动作一致,doc.read与audit.read、assign与approve不混用。
- 旧数据迁移干跑和故障回滚、停用角色仍有引用的处理、同版本并发编辑冲突可见。
**完成条件:** 角色能实际创建并影响执行,不是仅显示固定三个标签;矩阵不靠浏览器推算。
### U5. 固定整文三权与正式版本
**Requirements:** R5/R6/R7;**依赖:** U2/U3/U4。**Files:** RDM `internal/domain/review.go`、`doctree.go`、`eventlog.go`、`replay.go`、`internal/rdmapp/draftproposal.go`、`review`应用服务、`docx.go`、`plugins/rdm/plugin.go`;拟新增整文submission及annotations实体/迁移。
**Approach:** 复用持久提案与整文快照,补KTD4冻结字段、轮次、事件与审批状态。提交/批注/通过/驳回/撤回/批准共用固定提交对象,数据与事件同事务。无职责等待可见;分配时查当前账号、项目、动作资格和互异。批准读/导出固定快照,不从current章节拼装。
**Tests:** `internal/domain/review_test.go`、`internal/rdmapp/docduties_test.go`、`plugins/rdm/three_sig_test.go`、现有提案/重放/导出测试;拟新增 `internal/domain/document_submission_test.go`。
- 至少三份独立账号:作者提交、多审核缺一拒批、审核驳回、批准批注及批准;作者/管理者代审拒绝。
- 改正文/依据/模板/职责、撤成员、换批准人使受影响旧票失效;换名字/职责不能洗掉原作者历史。
- 章节贡献分配不改变整文签字人;旧章节PASS不聚合为整文PASS;旧活动轮次迁移有显式结果。
- 旧卡签新版本、并发审签、重复提交、事件写失败、重启恢复、未知schema及历史水位查询均有可判定结果。
- 正式DOCX及合规导出与批准正文/模板/来源/职责摘要一致,新内部修订保留旧正式版。
**完成条件:** 整文状态机及三个真实身份完整签署,管理权和签字权分离,全部写入入口遵守编制职责。
### U6. 补齐系统管理与创建者项目设置
**Requirements:** R2-R6;**依赖:** U3/U4;文档职责依赖U5。**Files:** Frontend `src/components/AdminZone.tsx`、`adminSections.tsx`、`ProjectSettingsModal.tsx`、`TaskSidebar.tsx`、`src/api.ts`、`src/store.ts`;复用UI `src/SettingsShell.tsx`;拟新增RdmRolesSection/RdmPermissionMatrix/RdmMembersSection/RdmDutiesSection组件。
**Approach:** 使用现有入口和SettingsShell。角色表支持创建/修改/停用;系统矩阵支持默认/上限解释;项目成员页支持账号选择及角色关联;项目矩阵只允许上限内override;文档职责页列文档状态、编制/审核/批准与资格不足原因。未分配不伪装有流程。异步对象单一所有者;全部样式和折叠按DESIGN令牌/原语。
**Tests:** 扩展Frontend `test/workspaces.test.ts`及相关组件测试;拟新增 `test/rdm-management.test.tsx`、`e2e/rdm-management.playwright.ts`;执行Frontend/UI design-guard与必要构建。
- 纯创建者而非管理员能看到并完成项目管理;普通成员不可配置;平台角色管理入口与领域项目管理按实际能力展示。
- 角色创建→系统矩阵→成员添加→项目覆盖→职责分配,刷新/重启保留且readback来自服务端。
- 同名账号、停用账号、空清单、服务器拒绝、409并发、断网未知结果时有明确状态,不乐观写成成功。
- 禁止上限勾选不能通过手造请求保存;所有异步取消/切项目/撤权状态一致;键盘、对比度及主题可用。
**完成条件:** 用户指出的四项缺失功能均在既有入口可操作,服务端同一规则强制执行。
### U7. 对话、审签工作卡与审计读面
**Requirements:** R1/R6/R7/R8;**依赖:** U5/U6。**Files:** RDM `plugins/rdm/plugin.go`、意图/工具声明、`internal/rdmapp/inspection.go`、卡片/任务接线;Frontend `src/api.ts`、`src/components/RdmAuditWorkspace.tsx`、工作卡组件。
**Approach:** 将已有原子命令公开为合法工具/意图,带真实当前项目和确认上下文;读状态和写动作同对象。模型只准备签字,用户认证确认执行。审计页补完整分页、另一端关系判定、不可还原/未提供状态、generation处理。Host审计覆盖和领域事件区分,补真实四链/矩阵、导出进度与下载,而不声称当前四页签已覆盖全部合规展示。
**Tests:** Frontend `e2e/rdm-audit.playwright.ts`及管理e2e;RDM `plugins/rdm/intents_test.go`、`internal/rdmapp/u3_inspection_test.go`、导出/任务测试;新增真实对话与审核/批准卡回道用例。
- 按钮和对话完成同一成员/职责对象,返回同operationId归因;工具传Actor、伪造project或旧卡均拒绝。
- 右栏关闭仍可读取状态并完成允许的用户确认;真实审核与批准始终属于相应人的认证会话。
- 快速对象A→B、项目切换、不同历史seq并发、撤权事件与迟到响应,不显示旧对象或旧权限正文。
- 数据多于首屏能分页,读失败与空数据分开,缺count非零;关联另一端正确;事件水位与正式快照一致。
- dev+FRP真实入口完成角色→成员→职责→整文审签→追溯→固定导出,账号不能全都兼管理员。
**完成条件:** 用户可见完整首批业务链和负例有真实账号、浏览器、固定制品证据;局部单测不是替代。
### U8. 回填全系统矩阵并推进剩余能力
**Requirements:** 全部原UR/SR/F;**依赖:** 按完整目标总案,不新增平行编号权威。**Files:** RDM `docs/records/2026-10-11-requirements-evidence-matrix.md`、`2026-10-12-final-acceptance-ledger.md`、`docs/requirements/10-实施推进方案-基座与下游二次开发.md`;Documents完整目标/模板/追溯/存储/恢复方案入口。
**Approach:** 保存旧快照和真实收据,新增当前SHA实现/剩余/部署/验收列。优先以下切片,逐包立项和评审:
1. 完整目标U9:slow持久project/owner/输入版本与授权恢复;取消、状态读取和卡片同源,先补恢复可信项目断点。
2. U5/U6/U12:完整格式解析与锚点、发布补偿、共享检索、两层结论裁决;复用#236真实抓取,真实法规双通道为竞品模板前置。
3. U7/U8/U16:首批建议书/竞品分析真实闭环后扩展所有69模板及报价XLSX,逐类登记模板内容/格式版本与验收。catalog不能结项。
4. U11/U10:真实需求/风险/措施/验证生产与四链,阶段适用文档/批准/合规/过期门禁,固定对象推进及结项。
5. U13/U14:复用Dev存储/恢复在途任务,领域PG/多实例租约与故障恢复、容量、迁移及发布包,最终九层验证和用户上线签收。
6. U15:F-01到F-10保留owner/依赖/状态;F-06/F-09已纳入当前链,F-10待用户标准模板,不隐式取消后续目标。
**Tests:** 延用各总案列出的直接测试,并落实 `make test`/`make build`、发布制品实测、需求到收据映射。每个子任务立项时冻结样本、数据档位、具体命令和验收环境;上述远期任务不以本稿粗粒度条目直接启动未授权实验。
**完成条件:** 112条都有当前对象与证据状态、责任包;已合入局部能力不会重复重建,旧过期缺口不继续冒充现状。所有最终需求仅在真实证据或用户明确取消/替代裁定后闭合。
### U9. 先交付通用公开授权和身份契约
**Requirements:** R2/R4/R5/R7/R8;**依赖:** 无,可与U1并行。**责任:** Dev Backend公开扩展owner;RDM提出/验收契约。**Files:** Dev Backend `pkg/extension/extension.go`、`pkg/extension/host.go`、`internal/app/compiled.go`、`hostcaps.go`、`internal/server/server.go`、`internal/store/content.go`及相应资源/共享检索授权测试;Documents沿既有扩展申请主记录补四要素。RDM消费发布tag并更新pins,不在pins内改代码。
**Approach:** 契约输入包括认证主体、动作、资源类型/ID、真实资源属主和项目,字段从受信存储/执行上下文生成,不能接受body自报资源归属。资源策略安装后对RDM域内所有访问权威,包括owner自有命中和共享读取;列表/统计/检索候选逐项过滤,SSE/下载/模型上下文注入在当前权限下重验。角色/职责/原件可见性仍由RDM判定,基座不硬编码RDM状态机。兼容使用可选注册能力与版本声明,旧普通基座行为保持;RDM缺该必需能力时停止共享启用而非整项目回退。
同包冻结最小账号目录及宿主项目资格读面:授权项目管理者只获得可选账号的稳定身份/有效态,不获得完整系统用户管理权限;Host项目查验包含存在性、当前主体管理/绑定资格和实例域。复用已存在AdminProvider、项目共享/会话公开扩展,只补缺少字段与检查。
交付顺序为扩展申请评审→基座实现与提供者/消费者契约验证→基座发版→RDM升pins/公开能力检查→U2/U3消费;发版按仓库人工双钥匙,由用户执行。本轮不创建发布或迁移。下游只使用公开符号,真实命令总线测试走公开启动/注册与HTTP,不跨internal边界。
**Tests:** 扩展Backend `internal/server/resource_authz_test.go`、`internal/app/compiled_authz_test.go`及Host/检索测试;RDM新增公开契约消费测试,衔接U2真实HTTP负例。
- 同一项目中A私有原件和B获授权文档,列表/详情/内容/下载/搜索/摘要/模型上下文仅返回获许可对象,私域owner自有命中也不绕过受控文档职责。
- 撤销角色、成员、分享后旧任务及已开流在新输出/使用边界重验;拒绝/错误/未知资源元数据不变成放行,私聊始终owner隔离。
- 假projectId、假资源属主、跨实例宿主ID、绑定他人项目均被执行端解析/资格检查拒绝。
- 未注册时普通基座兼容;RDM旧公开契约缺失时明确拒启受控共享;提供者发版和消费者固定pins组合都有证据。
**完成条件:** 不经RDM命令入口的HTTP/Host/检索也遵守同一资源策略,U2/U3可以在不修改基座internal或pins源码的前提下完成私域/项目绑定要求。
## Verification Contract
正式启动前处理共享锁的owner现场,在相应项目各自通过precheck、从权威main建立worktree和任务卡;不删除他人锁兜底。文档、源码、迁移、测试、部署各有授权范围。阶段内可迭代,跨阶段按Dev `policy/delivery.md` 人工评审,用户沉默不是授权。
验证必须包含三层:模块/公开契约;真实注册总线+认证HTTP;固定正式产物+浏览器用户链。命令语义与服务端拒绝优先,不能用直接handler返回或一张页面截图替代。
最小账号集:平台管理员、RDM域管理员、项目创建者/负责人、编制人、审核人(多审核时至少两人)、批准人、普通成员、外部用户。可以在不冲突场景复用账号,但审计兜底和三权签字用例必须拆开;两个独立项目和私有素材,禁止把所有账号均设管理员让负例失效。
| 层级 | 计划检查 | 判定 |
|---|---|---|
| 规范/门禁 | 启动precheck、验收/审核/合入各task-sync、共享写入owner核对 | 同步对象和任务范围有收据;本轮共享BUSY不掩盖 |
| RDM | `make test`;真实cmdbus/HTTP契约;角色/成员/整文事务及回放 | 选中用例且全部必要正负例有输出,非零用例或SKIP不算PASS |
| Dev组合 | `make test`+`make build`,检查精确pins和被测工作树 | CI PR HEAD为GATE;本地仅SELF;公开扩展兼容及组合构建均核实 |
| UI | design-guard、相关组件、实际固定产物的管理/审计/三权浏览器流程 | 有用户动作及可见结果;不能只跑Vite测试而遗漏embed产物 |
| 部署 | 固定dev制品、manifest、数据身份、同源/FRP入口、登录及七命令 | 新旧时点分开;根页200与有数据查询;启动健康不替代业务验收 |
| 持久/故障 | 并发成员/签字、撤权、断连未知结果、事件失败、重启/备份恢复 | 无越权或半事务,操作有可对账身份;真实DB档位与恢复对象明确 |
| 审核 | 独立审阅者先重放最小集,再读作者SELF;核对CI身份/链接/SHA | 本稿Agent审阅不代替正式REPLAY/GATE、人审和上线签收 |
完成声明的precheck/task-sync/测试三段输出由evidence写入任务卡;产出物引用任务卡/原收据。本轮仅保存调查与precheck收据,不补写业务测试输出。业务测试、真实模型、迁移、重启、部署、当前登录态审计验收均NOT_RUN。
## Definition of Done
本稿交付:矩阵覆盖全部原需求、故障因果链有固定对象/运行历史、五个问题分别定位到已有与缺口、方案有依赖/模块/测试/验收/兼容及停止条件,报告可审阅并保存。没有要求或宣称此轮实施。
首批整改验收:在实际dev及FRP入口,管理员建角色/配置上限,创建者管理成员/覆盖项目权限/分配文档职责,真实三权完成整文审签,审计历史和导出一致;越权/撤权/旧卡/旧版本负例成立。源码、CI、组合、部署、用户验收分别签收。
全系统C1:完整目标U1-U14及U16全部对应证据齐备;C2额外包含U15最终扩展或用户明确裁定,不把后续备案当已实现。新报告只记录当前差距,不修改旧收据或取消需求。
停止条件:权威需求改变;必要公开扩展不兼容;实际制品/数据身份无法确定;迁移权限扩大或旧审签票迁移规则不明;跨出当前批准范围或共享写者未退出。先保存证据/现场,提交受影响设计评审,不以临时放宽权限继续。
## 待人工评审与下一步
建议优先批准**本稿U1:正式产品构建及审计实际入口**,U9公开契约并行;U2可先在隔离工作区建立schema失败用例,完整资源授权出口依赖U9发版/升pins。上述首批工作不依赖69模板全量完成。随后U3/U4固定服务契约,U5整文三权与U6页面接线按依赖并行,U7交付用户完整流程。
需评审的新增技术选择:RDM组合二进制嵌入React正式入口;RDM专业角色首版单角色;旧cap/角色映射不扩大权限;整文签字替代章节级正式签字并保全历史。项目级批量职责默认若需要,另定义应用范围与显式覆盖,不把它作为此次分配每文档职责的隐藏前置。
这些是待批准设计,不重问是否实现角色/成员/权限/三权。正式实施负责人、隔离测试环境和部署切换窗口在批准启动时登记。此次独立报告入仓仍待共享门禁解除,未创建提交或PR。
## Appendix
随附文件 `source-runtime-receipt.json` 为make evidence原始调查收据,`precheck-receipt.json` 为启动拒绝收据;`readonly-probe.py` 为可复核只读命令脚本。报告审阅记录另保留;同一次作者侧子代理检查仍为SELF。
### 逐条需求定位与计划索引
以下只携带现有权威矩阵ID、摘要与既有工作包,原文位置相对RDM `docs/requirements/01-用户需求与系统需求.md`。摘要可能被原矩阵截断,完整语义以原文为准。历史矩阵中的“源码状态”列不复制,当前实现/缺口以本稿功能域表及固定源码为准;每行运行结论均为NOT_RUN。
| 原ID | 权威摘要 | 既有完整目标工作包 | 原文行 | 当前运行验收 |
|---|---|---|---|---|
| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传,对不支持格式仅提醒不阻断 | U5/U9/U14;G9/G10/G15 | 437 | NOT_RUN |
| SR-A2 | 上传不强制附带文字指令;无指令时进入默认"记忆构建"流程(见 SR-B 系列),不输出制式化"未识别需求"回复 | U5/U9/U14;G9/G10/G15 | 438 | NOT_RUN |
| SR-A3 | 支持单文件、多文件批量上传,并记录来源渠道(Web/飞书/其他)与上传人 | U5/U9/U14;G9/G10/G15 | 439 | NOT_RUN |
| SR-A4 | 上传后 60 秒内输出第一阶段反馈(相关性结论 + 初步阶段归类);完整入库允许后台异步完成 | U5/U9/U14;G9/G10/G15 | 440 | NOT_RUN |
| SR-A5 | 入库完整性保障:解析失败、部分内容不可解析或入库异常时,必须显式告知用户并在入库记录中标记,原始文件永久保留可取回;禁止静默降级或静默产出残缺结果(教训来源:旧版曾发生报价单 Excel 数据丢失、P… | U5/U9/U14;G9/G10/G15 | 441 | NOT_RUN |
| SR-B1 | 对每份上传资料输出相关性判定(相关 / 存疑 / 无关)及判定依据;存疑时必须挂起并向用户请求确认,确认前不入库 | U5/U6;G9/G10 | 447 | NOT_RUN |
| SR-B2 | 对资料进行结构化解析,保留章节/页/表格级锚点,锚点在后续所有引用与追溯中可用 | U5/U6;G9/G10 | 448 | NOT_RUN |
| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项",映射结合项目当前所处阶段;支持一片段映射多阶段 | U5/U6;G9/G10 | 449 | NOT_RUN |
| SR-B4 | 每个切片附带结构化标签(JSON):阶段、工作事项、主题、可行性维度(技术/市场/注册)、关联需求 ID、来源、上传时间、置信度;并生成一句话描述(description) | U5/U6;G9/G10 | 450 | NOT_RUN |
| SR-B5 | 支持"两速入库":快速通道(打标签 + 摘要 + 入库)先行返回,慢速通道(细切片、嵌入向量化)后台补齐,状态对用户可见 | U5/U6;G9/G10 | 451 | NOT_RUN |
| SR-B6 | 入库完成后向用户输出勾连总结:本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节,以显式清单呈现 | U5/U6;G9/G10 | 452 | NOT_RUN |
| SR-B7 | 会议纪要类资料按同一管道处理,并可抽取"结论 / 待办 / 待确认"三类条目 | U5/U6;G9/G10 | 453 | NOT_RUN |
| SR-B8 | 笔记树内一致性检测:同一主题簇下多个切片的陈述不一致(如多人表述冲突)时,系统检测冲突 + 记录入追溯网(何时/何人/何节点/何操作)+ 通知触发冲突的用户 + 挂起待裁决;智能体不自行处理冲突,裁决… | U4/U6;G11 | 454 | NOT_RUN |
| SR-B9 | 并发更新冲突避免与及时提示:多人几乎同时更新同一树节点时,系统忠实记录全部操作入追溯网,冲突以候选子节点组并存挂起,智能体不自行处理冲突;裁决集中在编制人发起编制时经 HITL 完成(裁决两层,规则同… | U4/U6;G11 | 455 | NOT_RUN |
| SR-B10 | 任务快慢双速:对用户任务按快慢双速模式执行——快通道同步短链路即时反馈(如上传文档→相关性判断→相关给概要/不相关给理由+相似文档供选择),慢通道小队(subagent)后台深度执行(逐页解析、建节点… | U9/U13;G15 | 456 | NOT_RUN |
| SR-B11 | 结论节点:结论作为笔记树的节点类型保存(结论入树);结论节点与切片同受 08 R1–R5 硬规则约束(append-only、软删除、结构事件日志、可重建);结论节点与其依据切片/来源的关联入追溯网。… | U6;G11 | 457 | NOT_RUN |
| SR-B12 | 总结触发:何时生成阶段总结交模型自主判断(不设固定阈值)——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档(HITL 确认);保留人工触发入口(用户明确指令触发);上传后先快速摘要反馈、后… | U6;G11 | 458 | NOT_RUN |
| SR-C1 | 内置可配置的研发体系文档树(阶段 → 文档 → 章节),每章有内容要求说明;文档树对应设计开发控制程序,商务对接与策划合并为同一阶段 | U7/U8/U16;G7/G8 | 464 | NOT_RUN |
| SR-C2 | 体系文档模板集中注册、版本化管理;模板与阶段/文档节点的关联可配置,不与具体工作流实例硬绑定。模板策略:本期按当前已有模板设计与完善;标准模板待系统完成并通过测试后由用户补充(E-T3,后续目标 F-… | U7/U8/U16;G7/G8 | 465 | NOT_RUN |
| SR-C3 | 文档生命周期状态机:草稿 → 评审中 → 已基线 →(变更中)→ 新版本基线;基线文档不可被直接修改 | U4/U8/U10;G6/G8/G17 | 466 | NOT_RUN |
| SR-C4 | 新切片填充文档章节前,与该章节现有内容比对,输出三分类结论:新增 / 更新 / 冲突;更新与冲突均需用户确认后生效 | U4/U8/U10;G6/G8/G17 | 467 | NOT_RUN |
| SR-C5 | 缺项分析仅在两种触发条件下输出:文档提交评审时、项目申请推进阶段时;上传节点禁止输出缺项提示 | U10/U11;G14 | 468 | NOT_RUN |
| SR-C6 | 每次文档内容变化生成版本记录,可查看任意两版本差异及差异来源切片 | U4/U8/U10;G6/G8/G17 | 469 | NOT_RUN |
| SR-C7 | 三权分立流程规则:编制/审核/批准三权异人(编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人);编制发起唯一;审核/批准仅可批注与通过/驳回,不可修改正文或发起编写;提交审核即锁定;驳回回… | U3/U8;G6/G17 | 470 | NOT_RUN |
| SR-C8 | 批准后修改的处理:本期路径=撤回重审(D-12:撤回后修改并重新升版审批)+影响提示(沿追溯网列出受影响范围给人看,不走流程,见 SR-D3);松散管理取向,但审计链不断(08 R1/R2/R5 不动… | U3/U8;G6/G17 | 471 | NOT_RUN |
| SR-D1 | 建立并持久化双向追溯网络:资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例;每条边记录类型、来源(人工/规则/模型候选)与置信度 | U11/U14;G12/G17 | 477 | NOT_RUN |
| SR-D2 | 需求条目化管理:用户需求与系统需求大表,字段含状态(草稿/已评审/已基线)、版本、关联文档与法规;支持增删改与批量导入 | U11/U14;G12/G17 | 478 | NOT_RUN |
| SR-D3 | 新内容入库触发变更检测:与已评审条目比对,不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示(V2.1 增补):批准后修改或引用内容变化时,系统沿追溯网列出受影响范… | U6/U11;G11/G16 | 479 | NOT_RUN |
| SR-D4 | 变更流程闭环(变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭,全程留痕):整体后移,不作为本阶段系统实现目标——变更流程走公司内部管理流程,移入后续目标备案 F-02(《10… | U15/F-02;G14 | 480 | NOT_RUN |
| SR-D5 | 任一需求可导出完整追溯链报告;无法匹配进体系的资料进入"待裁定"清单,提醒用户处理 | U11/U14;G12/G17 | 481 | NOT_RUN |
| SR-D6 | 追溯主体扩展:追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片,保证所有信息细节的准确性与可追溯性 | U4/U8/U11;G8/G17 | 482 | NOT_RUN |
| SR-D7 | 完整合规追溯模型(权威定义见 08 第十六章):15 类受控节点(含危害/风险控制措施/设计确认/设计转换/变更)+11 类合规边(两端=节点 ID@版本,模型仅候选、人工确认转正)+四条链视图(13… | U11/U14;G12/G17 | 483 | NOT_RUN |
| SR-D8 | 需求分类与分解框架:用户需求与性能需求分到不同文档;先确认用户需求再分解系统需求;系统需求按六维度分类(功能/交互/安全/运输包装/维护/合规);智能体可从法规反推部分系统需求,但不完全依赖智能体;先… | U11/U14;G12/G17 | 487 | NOT_RUN |
| SR-D9 | 风险登记册追溯:危害(HAZ)与风险控制措施(RCM)入网;每个 RCM 同时登记为需求并必须被验证(verifies 边);每个危害至少被一项 RCM mitigate;措施-危害-验证三向可查(术… | U11/U14;G12/G17 | 484 | NOT_RUN |
| SR-D10 | 验证结果绑定被测版本:VR 记录对应用例与被测对象版本;被测版本≠当前基线版本时系统报「验证过期」并列入缺口;设计确认(VAL)必须追溯到用户需求 | U11/U14;G12/G17 | 485 | NOT_RUN |
| SR-D11 | SOUP 组件登记与追溯:软件组成项(含 SOUP)入网为架构项,其需求分配与验证沿用同一边模型 | U11/U14;G12/G17 | 486 | NOT_RUN |
| SR-E1 | 意图识别分层:规则层(仅限整句完全匹配的高频确定性短指令)→ 语义层 → LLM 层;规则层不得单独触发高风险操作 | U2/U8/U9/U10;G1/G8/G14/G15 | 493 | NOT_RUN |
| SR-E2 | 规则层命中必须通过上下文校验(上一轮存在对应的待确认事项)才可执行;无上下文时降级为普通对话 | U2/U8/U9/U10;G1/G8/G14/G15 | 494 | NOT_RUN |
| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成,卡片明示操作对象与后果 | U2/U8/U9/U10;G1/G8/G14/G15 | 495 | NOT_RUN |
| SR-E4 | 支持意图分类(查询 / 编写 / 命令 / 讨论)与意图切换识别;编写类意图需命中目标文档并确认后执行 | U2/U8/U9/U10;G1/G8/G14/G15 | 496 | NOT_RUN |
| SR-E5 | 简单询问即时回答;复杂任务先给出执行计划与预计耗时,执行中提供进度反馈 | U2/U8/U9/U10;G1/G8/G14/G15 | 497 | NOT_RUN |
| SR-E6 | 对话完备路径:从立项到结项的全部状态变更操作(创建项目、提交评审、批准变更、阶段推进、导出、结项等)均可通过对话指令驱动,页面/按钮不是任何步骤的唯一入口;高风险操作的对话路径终点为对话流内联确认卡(… | U2/U8/U9/U10;G1/G8/G14/G15 | 498 | NOT_RUN |
| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行:骨架显式定义步骤序列与返回检查节点,角色在骨架内有限自主 | U8/U9/U13;G8/G15/G18 | 504 | NOT_RUN |
| SR-F2 | 每个角色显式声明:职责、可用工具白名单、禁区;角色提示词作为受控资产版本化管理 | U8/U9/U13;G8/G15/G18 | 505 | NOT_RUN |
| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道,结果附引用来源;冲突时以权威来源为准并提示 | U12;G13 | 506 | NOT_RUN |
| SR-F4 | 长任务后台异步执行,进度可查询、完成有通知;不得阻塞对话主线程 | U8/U9/U13;G8/G15/G18 | 507 | NOT_RUN |
| SR-F5 | 执行任务时自动组装上下文:项目当前状态、相关记忆切片、目标文档模板、近期对话;上下文构成可解释 | U8/U9/U13;G8/G15/G18 | 508 | NOT_RUN |
| SR-G1 | 飞书集成:智能助手可加入群聊,支持群内对话、收文件、推送反馈与通知。本期不做飞书功能(J-11),本条与 UR-20 一并后移 → F-01 | U15/F-01;外部依赖 | 514 | NOT_RUN |
| SR-G2 | 基于角色与项目阶段的权限控制(ABAC),阶段转换需满足准入准出条件并留痕。判定维度(角色 × 项目 × 阶段 × 动作)保留;权限主数据裁决(J-10,R2 关闭):本期系统内建最小权限系统(管理员… | U2/U3;G3/G4 | 515 | NOT_RUN |
| SR-G3 | 全量审计日志:上传、入库、更新、变更、确认、生成等动作均可审计 | U4/U11;G5/G17 | 516 | NOT_RUN |
| SR-G4 | 系统以自身研发项目为首个运行实例(自举元项目),自身需求与体系文档由本系统管理 | U14;G19 | 517 | NOT_RUN |
| SR-G5 | 结构追溯:笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值;删除一律软删除(tombstone);追溯边有"候选 → 生效 → 废止"全生命周期;支… | U4/U11;G5/G17 | 518 | NOT_RUN |
| SR-G6 | 系统管理员与系统级设置:全局唯一管理员拥有所有权限;仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数(工具调用轮数/工具权限等)、系统级插件管理、用户/角色的… | U2/U3;G3/G4 | 519 | NOT_RUN |
| SR-G7 | 角色管理:角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人;角色可分配给用户(如项… | U2/U3;G3/G4 | 520 | NOT_RUN |
| SR-G8 | 权限覆盖优先级——上限内覆盖(J-05,原存疑关闭):管理员设定角色默认权限与权限范围上限(最底层约束);项目负责人(创建者)在该范围内调整项目成员权限;项目内配置可覆盖角色默认配置,但不得突破管理员… | U2/U3;G3/G4 | 521 | NOT_RUN |
| SR-G9 | 项目负责人权限:项目创建者即项目负责人,拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | U2/U3;G1/G2 | 522 | NOT_RUN |
| SR-G10 | 项目唯一性与成员自动可见:同名项目全系统唯一;用户被添加为项目成员后,其界面自动出现该项目,并可直接开始项目工作(新建对话等) | U2/U3;G1/G2 | 523 | NOT_RUN |
| SR-G11 | 对话隐私:用户之间的对话互相不可见,仅本人可见本人与智能体的对话;智能体会话/中间过程默认互不可见(J-06,原存疑关闭),协作全部经两树一网项目共享层;用户分享分层(整个项目/会话/部分会话)的精细… | U3/U5/U9;G4/G5/G10 | 524 | NOT_RUN |
| SR-G12 | 文档分享:上传者可将文档分享给指定成员/部分成员/全部项目成员;被分享者只读、不可编辑;被分享文档进入接收者上下文,支撑其后续对话中查看并基于这些文档对话 | U3/U5/U9;G4/G5/G10 | 525 | NOT_RUN |
| SR-G13 | 上下文时间权重:本期最小实现——检索与注入排序新内容优先;替换/冲突场景走 J-02 人裁决(SR-B8/SR-B9)。可配置时间权重衰减模型(权重数值、配置粒度)移入后续目标 F-04(J-07,优… | U5/U15/F-04;G10 | 526 | NOT_RUN |
| SR-G14 | 飞书项目对接适配(接口层四项功能:产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接;飞书角色权限映射读取):本期不做飞书功能,整条移入后续目标备案 F-01(J-11);保留设计预留说… | U15/F-01;外部依赖 | 527 | NOT_RUN |
| SR-G15 | 虚拟人账号(企业账号下为智能体创建固定账号持有文档/文件夹访问权限;授权范围、审批与定期审计流程待明确,《10》Q-04):随飞书对接整体后移,移入后续目标备案 F-01(J-11) | U15/F-01;外部依赖 | 528 | NOT_RUN |
| SR-G16 | 代码执行安全:多用户共享部署在隔离执行档就位前,以启动级硬关闭禁用执行原语(run_shell/run_python/register_artifact 及内核执行配置),用户设置不得覆盖(基座已交付… | U13;G18 | 529 | NOT_RUN |
| SR-N1 | 性能:上传首轮反馈 < 60 秒;单文档完整入库(后台)< 10 分钟;追溯链查询 < 3 秒 | U14;G18/G19 | 535 | NOT_RUN |
| SR-N2 | 可维护性:模块边界清晰、依赖单向;任一核心功能(如文档入库)可在 5 分钟内定位到对应代码模块;支撑每周代码审查机制 | U1/U14;G19 | 536 | NOT_RUN |
| SR-N3 | 可解释性:每个入库、更新、变更动作给出依据(来源切片、命中标签、比对结果) | U4/U5/U8;G10/G17 | 537 | NOT_RUN |
| SR-N4 | 部署与数据:支持本地化部署;法规知识库本地存储;项目数据按项目隔离 | U2/U3/U13;G5/G18 | 538 | NOT_RUN |
| SR-N5 | 模型无关性:大模型通过抽象层接入,可替换(当前为 MiniMax,不绑定) | U9/U13;G8/G18 | 539 | NOT_RUN |
| UR-01 | 自由上传 | U5/U9/U14 | 547 | NOT_RUN |
| UR-02 | 相关性把关 | U5/U6 | 548 | NOT_RUN |
| UR-03 | 自动归纳入库 | U5/U6/U9/U14 | 549 | NOT_RUN |
| UR-04 | 及时反馈 | U2/U5/U6/U8/U9/U10/U13/U14 | 550 | NOT_RUN |
| UR-05 | 渐进式清晰 | U4/U7/U8/U10/U16 | 551 | NOT_RUN |
| UR-06 | 缺项提示时机 | U10/U11 | 552 | NOT_RUN |
| UR-07 | 冲突与变更 | U4/U6/U8/U10/U11/U15 | 553 | NOT_RUN |
| UR-08 | 严格可追溯 | U4/U5/U6/U8/U10/U11/U14 | 554 | NOT_RUN |
| UR-09 | 需求条目化 | U6/U11/U14 | 555 | NOT_RUN |
| UR-10 | 模糊澄清 | U2/U4/U5/U6/U8/U9/U10 | 556 | NOT_RUN |
| UR-11 | 一键生成文档 | U2/U8/U9/U10/U13 | 557 | NOT_RUN |
| UR-12 | 主动提问 | U2/U5/U6/U8/U9/U10 | 558 | NOT_RUN |
| UR-13 | 外部查询入库 | U5/U6/U8/U9/U12/U13 | 559 | NOT_RUN |
| UR-14 | 法规双通道 | U12 | 560 | NOT_RUN |
| UR-15 | 商务策划贯通 | U7/U8/U16 | 561 | NOT_RUN |
| UR-16 | 显式确认 | U2/U8/U9/U10 | 562 | NOT_RUN |
| UR-17 | 阶段门禁权限 | U2/U3/U4/U11 | 563 | NOT_RUN |
| UR-18 | 会议纳入记忆 | U5/U6 | 564 | NOT_RUN |
| UR-19 | 自举 | U14 | 565 | NOT_RUN |
| UR-20 | 协作平台接入 | U15 | 566 | NOT_RUN |
| UR-21 | 系统角色与权限管理 | U2/U3 | 567 | NOT_RUN |
| UR-22 | 项目成员与协作 | U2/U3 | 568 | NOT_RUN |
| UR-23 | 文档分享与上下文注入 | U3/U5/U9/U15 | 569 | NOT_RUN |
| UR-24 | 三权分立文档流程 | U3/U8 | 570 | NOT_RUN |
| UR-25 | 版本全量保留与来源追溯 | U4/U8/U10/U11 | 571 | NOT_RUN |
| UR-26 | 并发更新冲突避免与提示 | U4/U6 | 572 | NOT_RUN |
| UR-27 | 快慢处理与任务拆解展示 | U9/U13 | 573 | NOT_RUN |
| UR-28 | 简易看板 | U4/U6/U8/U10/U11 | 574 | NOT_RUN |
| UR-29 | 难度分级与降级使用 | U8/U9/U13/U14/U15 | 575 | NOT_RUN |
| UR-30 | 对抗验证机制 | U8/U9/U13/U14/U15 | 576 | NOT_RUN |
| UR-31 | 飞书项目对接 | U15 | 577 | NOT_RUN |
| UR-32 | 代码管理工具集成 | U15 | 578 | NOT_RUN |
| UR-33 | 法规合规追溯 | U11/U14 | 579 | NOT_RUN |
| UR-34 | 结论沉淀与阶段总结 | U6 | 580 | NOT_RUN |
| F-01 | 飞书对接全套(渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联) | U15/F-01 | 643 | NOT_RUN |
| F-02 | 变更流程引擎(七步闭环、变更单、完整影响分析) | U15/F-02 | 644 | NOT_RUN |
| F-03 | 用户分享分层(整个项目/会话/部分会话)与智能体可见性的精细设计 | U15/F-03 | 645 | NOT_RUN |
| F-04 | 可配置上下文时间权重衰减模型 | U15/F-04 | 646 | NOT_RUN |
| F-05 | 代码管理工具集成(GitLab token 只读拉取、需求-版本-缺陷关联) | U15/F-05 | 647 | NOT_RUN |
| F-06 | 看板与卡片流的界面统一(随原型 V2.3) | U9/U14 | 648 | NOT_RUN |
| F-07 | 会议遗留问题组(Q-01/02/03/07/10/13/14 等,《12》问题 8 组);其中 Q-02 经晚会部分裁决(C-03,见 §7.1) | U15/F-07 | 649 | NOT_RUN |
| F-08 | 难度分级评估表与降级机制的落地细化(UR-29 保留 P1,实施细节备案) | U15/F-08 | 650 | NOT_RUN |
| F-09 | 追溯网可视化(先功能后展示,暂缓) | U11/U14 | 651 | NOT_RUN |
| F-10 | 标准模板替换:本期按当前已有模板设计与完善;待系统完成并通过测试后,由用户补充标准模板(取代晚会 T2「今晚下载官方模板替换」,不执行) | U16+U15/F-10 | 652 | NOT_RUN |
@@ -0,0 +1,339 @@
---
title: 服务重启与全量数据恢复方案
type: fix
date: 2026-10-12
artifact_contract: ce-unified-plan/v1
execution: code
product_contract_source: ce-plan-bootstrap
---
# 服务重启与全量数据恢复方案 r3
确认状态:原 r2 批准记录保留(Dev PROJECT.md 记录 2026-10-12 五阶段批准);**r3 本轮增补待人工评审**。本轮仅调查、修订方案及本地文档核查,不代签历史批准,不授权业务实施、账户变更、迁移、故障注入、部署、推送或合入。
修订记录:r1=2026-10-12 初稿并完成六角色文档自审(见同名审阅记录第一轮);r2=2026-10-12 吸收外部源码复核(U1/U3/U4/第9节四处修订,见审阅记录第二轮),需求范围与量化指标未变。
r3=同日根据 dev 8788 账户故障续查刷新源码/运行事实,保留 R1–R10、KTD1–KTD12、U1–U7;补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值,未宣称实测达标。
需求来源:2026-10-12(Asia/Shanghai)用户要求“系统应该在停止并再次启动(通过 svc 或异常终止)后,应当能够恢复所有服务和数据,给我一个完善方案”。负责人:weichen;编制:Codex;实施与运维负责人在启动对应增量时指定。
主记录:本文;任务卡:Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
## 1. 目标与成功边界
**目标:系统停止后再次启动,用户仍能访问原有数据和服务,未完成工作进入可继续或可处理的确定状态。**
采用“稳定实例配置与身份、依赖编排、进程监管、持久恢复账本、一致性文件发布、组合备份与实测验收”的方案。复用现有 PostgreSQL/SQLite、运行表、事件、命令、通知和恢复隔离机制,补齐实际接线与崩溃窗口。首期落实单机完整恢复;多实例所有权沿用已有协作存储方向,不重新设计一套集群平台。
必须区分三类恢复:
| 故障档 | 需要达到的结果 | 数据与时间合同 |
|---|---|---|
| `svc stop/start/restart`、进程 SIGTERM/SIGKILL、应用 OOM | 原配置启动;持久数据完整;安全任务继续;未知副作用隔离 | 存储正常、确认结果已持久化的前提下,RPO=0;建议冷启动至业务就绪≤60秒 |
| 主机重启、操作系统崩溃或断电,磁盘仍可用 | 数据库 WAL 恢复、文件一致性恢复、服务按既定意图启动 | 只有 DB 与文件落盘策略、底层存储满足耐久性且实测后,才承诺已确认数据 RPO=0;建议 RTO≤5分钟 |
| 数据盘损坏、主机丢失、误删或不可逆污染 | 在新目标恢复匹配的 DB、文件、配置和版本 | 沿用协作存储案建议 RPO≤5分钟、RTO≤60分钟;如要求此档 RPO=0,另行批准跨故障域同步复制 |
以上时间为**待批准的验收目标**,不是已测性能。大规模扫描与冷索引重建不要求全部在60秒内完成:必需数据对账及安全恢复决策完成后可开放API,派生索引按明确降级合同后台重建。故障超出资源预算时报告阻塞及原因,不能以假就绪满足时间指标。
恢复保存的是持久业务状态、步骤和已确认结果。进程内 goroutine、模型连接及未持久化 token 不可原样复活;模型回合从持久上下文和步骤边界重建。已经接受的用户消息、排队任务、审批和取消意图必须先落库再返回接受;尚未确认的结果不能事后冒充成功。
## 2. 当前事实及重点差距
本轮源码基线:权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`;文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`(任务元数据提交);Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`;Core `89f3906c390027512ef47b5333088c3d3a019e84`;Frontend `cc233fec908d0f8c12193042942b94ad68508091`;固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。草案独立 Documents 基线 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`,未推进 Dev gitlink。原 r2 对象为历史,不用于证明当前运行行为。
来源为 SELF·只读观察;原始脱敏命令和运行输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。故障表现为源码推导,故障/恢复/耐久性验收 NOT_RUN。
最终 Dev 同步基线 `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9` 已纳入主干的 svc 实例内存态修复和 Documents 指针 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`;Backend/Frontend 未变。旧 gitlink 是启动时点,本轮仅同步权威上游,未推进本轮草案组合或重复实现该修复。
| 对象 | 已存在的基础 | 尚需解决的恢复缺口 |
|---|---|---|
| 数据库绑定与身份 | svc 统一解析已接线;manifest/marker 和 Backend DB identity 已存在;manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env;自定义根和 legacy/direct 启动需要完整核验;identity 不等于活动服务独占锁 |
| 服务生命周期 | svc 已有 desired/autostart、recover、watchdog timer;PG 优先拉起 | 没有完整服务组依赖/单一进程组监管;不管理 Redis 类型;登记版本与实际二进制可能不一致 |
| 启动与停机 | 启动对账开放 run;优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前;HTTP停机超时可跳过flush;无所有worker等待;子代理 cancelled 可覆盖 interrupted |
| 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消;子代理先派生再写文件标记;notice消费非事务且绕过PG会话占用 |
| 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease,终态有fencing;额度有持久表 | 续租只有定义未接入生产调用;15分钟租约可过期;额度无崩溃回收;不能据此宣称安全接管 |
| 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行,kill窗口丢命令;跨实例取消入队缺conversation;Surface失败仍可清pending且仅扫100条 |
| 工具副作用 | Native Session已有tool intent/result转录、安全重放判定;Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义;Native的未知效果被写成工具错误后仍可继续模型,尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 |
| 文件与备份 | blob temp+rename、SQLite 一致性快照、pg_dump 已存在;Native 转录 Write→Sync;manifest 有原子同步链 | 工件原文先覆写再更新 DB,无不可变版本;agent 快照缺权威 manifest,PG 和文件快照不是同一恢复点 |
| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接;数据库事务可排队 | 无跨进程活动服务独占;恢复扫描全部开放 run,第二个服务可打断第一服务;不具备 PG 的会话执行租约 |
2026-10-12 17:37:03(Asia/Shanghai)实际 dev 进程打开 `runtime/dev/data/agent-system.db`,DB marker 为 `sqlite`,运行 Backend `5e8ada7`;没有登记 PG 绑定。候选 rdmcand 已停止且登记来源与实际文件版本不符。前一轮共享数据观察是历史风险线索,不冒充当前双进程事实。**实际文件/marker 已核对,不等于全栈恢复或断电耐久性 PASS。**
当前 PG 事件总线已有真重连、分页追赶和周期补查,Native 已接持久工具转录;这些基础不重复建设。SQLite 应用连接未显式声明 synchronous;诊断连接 PRAGMA 不能证明应用配置,见 R12。
18:14:09(Asia/Shanghai)重新实测:外部流程已将 rdmcand 拉起于独立数据根,实际 DB inode 与 dev 不同且制品/登记版本一致;dev 仍打开原库、账户最后设密时间未前进。当前共享现场已缓解;U8 的剩余任务是强制运行时防误用和隔离验收,不重复执行已完成的人工分根。完整停机/恢复和锁能力仍 NOT_RUN,本轮没有改变服务或数据。
旧报告中“DSN重启丢失”“迁移DDL与版本分开提交”“通知仅内存”等问题已有源码改进,本案只验证并复用这些基础,不把旧缺陷重新列成新建设。
## 3. 需求合同
| ID | 范围 | 要求与可判定验收 |
|---|---|---|
| R1 | 服务 | 启动显式服务组时,全部已启用的必需服务按依赖就绪;可选失败明确降级;主动停止不被监管误拉起 |
| R2 | 身份 | 连续裸启停、更换端口/程序/cwd后,DB identity、数据/工件/工作区根、实例ID、认证及插件组合一致;缺配置拒绝启动 |
| R3 | 已确认数据 | 消息、项目、成员/权限、文档、设置、插件启用/授权、任务、审批、事件、工件原文与版本在RPO=0档零遗漏;灾难档完整恢复批准恢复点内数据,并对账/报告恢复点后的缺失和外部效果 |
| R4 | 任务 | 已接受排队任务不丢;安全任务从持久步骤继续;HITL保留稳定gate与答案;取消意图在重启/换owner后仍生效 |
| R5 | 副作用 | started但无确定result的外部动作自动隔离;已确认动作不重做;恢复与发布验证当前权限和执行代次 |
| R6 | 所有权 | 单一有效写者;旧进程迟到写状态/事件/工件被拒;过期额度回收;恢复本身可重复且可再次中断 |
| R7 | 文件与派生状态 | DB引用的文件内容、版本和hash一致;损坏现场保留并报告;缓存/检索索引可从权威源重建 |
| R8 | 停机与就绪 | 停机先拒绝新工作再排空;全部worker、sidecar和工具子进程收口;错误不跳过后续清理;ready反映业务可用 |
| R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同;备份恢复到新目标并完成业务/权限/文件对账;不在普通启动覆盖现库 |
| R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败;运维能定位阻塞依赖;每项验收绑定精确组合、制品、配置与原始输出 |
| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时;直接二进制、路径别名和 legacy 入口同样受保护;账户短事务 CLI 不启动第二运行时;测试实例使用独立根 |
| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略;文件和目录同步覆盖权威对象;DB/文件持久失败不能确认成功;未实测的断电 RPO 保持候选 |
覆盖“所有数据”需要先完成数据归属清单:除Backend业务表,还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性;无法证明可恢复的必需插件阻塞全系统签收,不能只恢复Backend便宣称全部完成。
## 4. 技术决策与服务结构
KTD1. **持久配置是启动权威,PID只是观察。** 每实例保存完整类型化manifest:service/instance ID、配置revision、desired state、服务类型与管理权、依赖、固定程序/插件/资产摘要、DB identity与凭据引用、数据/工作区/工件根、认证、监听、必需/可选属性、恢复政策。临时环境只作显式覆盖;必需字段必须能从持久值或稳定受保护引用重新解析。机密放受保护文件/秘密服务,manifest仅存引用,不把密码或DSN写进日志。
KTD2. **配置整份提交,覆盖按字段合并。** 每实例和服务组串行化生命周期操作,配置以revision做CAS;候选完整解析与校验后,临时文件落盘、原子替换、目录同步。legacy迁移同样一次提交,故障留下旧版或完整新版。更改端口不隐式更改data;数据根迁移是独立操作。恢复启动发现预期DB/marker/目录丢失时阻塞,初次初始化需要明确入口,禁止新建空库掩盖数据丢失。
KTD3. **svc控制期望状态,唯一supervisor管理进程。** Linux部署推荐systemd;svc兼容既有单服务入口,增加显式stack/group控制。每服务仅一个监管者,不能nohup watcher与systemd同时拉起。分发仓已有模板要接入同一manifest合同。外部/共享PG、Redis仅探测连接,不擅自启停;managed-local只管理身份已核实且归该服务组独占的资源。pgvector是PG扩展,不另造守护进程;Redis只有配置并启用时才进入依赖图。
KTD4. **主动停止与异常退出分开。** stop先提交desired=stopped,再关闭服务;普通故障仅desired=running可重启。restart保留最终running意图并记录operation_id、执行阶段和恢复政策,不能因中途stop留下stopped。监管采用有界退避、重试预算与失败阻塞;错误配置不能无限重启。开机只恢复已登记且策略允许的服务。intent、operation、actual state必须分开,不能以pidfile存在视为运行。
KTD5. **团队业务权威沿用PG,个人档沿用SQLite。** 团队PG失败保持未就绪,绝不切SQLite。普通重启让既有数据库完成自身WAL恢复,不导入备份。验证数据库identity/schema/权限和关键记录;SQLite恢复到预期文件并检查完整性,不能只看文件存在。断电承诺要求明确DB同步设置及底层存储合同,不把rename原子性当作落盘保证。依据:[PostgreSQL耐久性](https://www.postgresql.org/docs/current/wal-reliability.html)、[SQLite WAL](https://www.sqlite.org/wal.html)。
KTD6. **恢复扫描与恢复执行分离。** 装配Store、权限、插件/工具、工作区、预算、Workflow、命令消费者与事件投递之后,才分类认领恢复任务。扫描失败或归属未知进入blocked/hold;不能吞掉错误直接ready。恢复有持久cursor/attempt和CAS,支持分批、失败重试及再次重启;禁止全库无归属盲扫并续跑其他实例的任务。
KTD7. **持久执行账本统一主run、子run和后台任务。** 保持稳定logical_run_id、request_id、parent关系;每次执行用新的attempt/boot/epoch。步骤记录输入引用、已提交输出、等待原因、调度位置、恢复决策;完成记录与业务结果原子提交。现有文件修改checkpoint不是完整执行checkpoint,不能直接拿它宣称主对话/工作流可续跑。后台任务表目前仅状态登记;只恢复明确有executor的类型,其他类型进入可见unsupported/blocked,补适配后验收。
KTD8. **副作用先登记,结果未知先对账。** 复用Native `runtime/session/intent.go`和生产接线`internal/runtime/llm_direct.go:245–301`,以同一call/operation ID关联现有intent/result与Backend的run/owner/epoch/hold,不能让两个恢复器各自决定重放。DB账本裁决执行和hold,转录保存完整上下文及结果投影;本地个人档同样须有持久裁决。调用外部工具前持久化operation_id、参数摘要/安全引用、授权与gate、owner/epoch、幂等类别及started;确定结果写result/receipt。启动遇到started无确定result自动hold,不能只把“副作用未知”写成普通工具错误后允许模型继续发起动作。
目标支持可靠幂等键时按同一key重试;非幂等动作必须取得确定未执行的终态证据,并证明旧执行者及已发请求都不会再产生效果,才允许重试。“暂未查到结果”“取消请求已发送”“本地进程已退出”均不充分。否则保持hold。shell、代码执行、Git、数据库/远端写入默认按不透明副作用处理。模型/工具因失权立即取消;无法围栏的外部动作进入hold,不能靠租约到期证明旧动作停止。
KTD9. **所有工作入口共用执行所有权与额度。** 前台、notice、子代理恢复、命令消费者均经过持久claim。稳定instance_id与每次boot_id分开;续租持续进行,丢租停止执行;CAS/事务围栏覆盖状态、事件、步骤、工件发布和副作用准入。execution与admission lease关联run/attempt/epoch;恢复终态和已证明失效的许可,禁止一启动就清空全库锁。父任务等待HITL/子任务让出执行额度;持久队列及跨实例等待者有有界唤醒机制。
KTD10. **命令、通知和投影处理后确认。** 命令 pending→claimed(带租约)→applied/rejected,超时claim可重领;取消先从run解析已授权conversation,按逻辑run转交当前owner;HITL验证gate/version与当前权限。notice_id/旧子run的恢复claim、对应新run、消息和销项以事务与唯一约束关联,文件resumed标记仅作投影。outbox成功才ACK,失败保持pending;分批持续drain,不受单次100条限制。
KTD11. **不可变对象加DB发布记录保持文件一致性。** 写新版本对象、完成必要fsync/hash校验后,在事务中发布引用与版本;失败留下可辨认未发布对象,不直接覆盖已发布版本。工作区变更另用既有overlay/CAS与副作用账本核对,不能把可变工作区伪装为不可变对象。checkpoint/JSONL尾部截断须保存原件、识别未确认尾部,已确认部分校验失败阻塞。工件缺失报告损坏,不静默返回空内容。孤立对象按清单、引用、保留期与备份需求回收。
KTD12. **业务readiness与恢复摘要分开。** liveness仅证明进程存活;readiness包含身份/认证、DB/schema、必需目录与插件、恢复决策完成和worker接线。已隔离且不影响其他会话的hold可允许API就绪,并暴露计数与处理入口;损坏权威数据或必需依赖失败不能ready。详细恢复状态只向有权owner/admin开放;公共健康响应不泄漏路径、任务ID、凭据或业务内容。
服务依赖结构(实线为必需;可选项以实例manifest为准):
```mermaid
flowchart TB
M[持久实例manifest与启动意图] --> S[svc控制入口]
S --> P[唯一进程监管者]
P --> D[受管PG或SQLite数据]
P --> A[应用与恢复协调]
X[外部PG或可选Redis:仅探测] --> A
D --> A
F[持久文件与插件组合] --> A
A --> W[任务/命令/通知/投影workers]
A --> H[业务readiness]
H --> U[Web或下游业务入口]
```
systemd的顺序依赖不能替代DB可用性检测;需真实探测,且明确依赖断开后的重连/恢复政策。监管策略参考systemd官方[service契约](https://github.com/systemd/systemd/blob/main/man/systemd.service.xml)与[进程组停止契约](https://github.com/systemd/systemd/blob/main/man/systemd.kill.xml)。
KTD13. **SQLite 活动服务锁由 Backend 强制。** 在迁移和启动 run 对账之前按实际 DB/数据资源取得 OS advisory lock,持有至运行时退出;覆盖规范化路径和文件别名。marker/PID 不替代锁,SIGKILL 后由 OS 释放。合法账户 CLI 只核验同实例和兼容 schema 后做 DB 短事务,不启动 Manager;迁移独立维护。锁文件丢失或 DB 替换导致身份改变时拒绝自动续跑,不能新建可绕过的锁继续。
KTD14. **初始化与事故后缺库分开。** 已登记实例启动和运维先验证预期库/marker,缺失则阻塞;显式 init 才允许创建。SQLite 可靠档明确 WAL+FULL 并核验每个连接;PG 核验实际 fsync/synchronous_commit/full_page_writes 等,不用诊断连接默认值证明应用配置。[SQLite WAL](https://www.sqlite.org/wal.html)、[PostgreSQL WAL](https://www.postgresql.org/docs/current/runtime-config-wal.html)。
KTD15. **manifest 单一权威与派生视图修复。** 复用现有 temp→fsync→rename→dirsync;读侧直接消费 manifest 或验证派生 revision。manifest 提交后、svc.env 派生前崩溃可重新生成视图,不能按旧派生配置换库。未知制品能力、登记/实际版本不符报告并拒绝危险操作,不猜测。
## 5. 启停流程与恢复政策
### 5.1 启动和优雅停止
```mermaid
sequenceDiagram
participant C as svc/监管者
participant A as 应用生命周期
participant D as 持久存储
participant W as workers与子进程
C->>D: 校验manifest、数据身份与操作锁
C->>C: 启动归本组管理的依赖并探测
C->>A: 启动固定版本
A->>A: SQLite取得活动服务锁;PG按既有执行所有权合同
A->>D: 校验schema、文件与恢复候选
A->>W: 完成插件/权限/预算/工作区全部装配
A->>D: 分类认领、对账未知效果、恢复命令与额度
A->>W: 开放安全恢复执行
A-->>C: readiness与恢复摘要
C->>A: 停止请求
A->>A: readiness=false;拒绝新写和新任务
A->>W: 停止领取、取消或保存安全边界
W-->>A: bounded join与子进程结果
A->>D: 持久化恢复意图、flush、收口许可/所有权
A->>D: 关闭存储
A->>A: 释放本进程SQLite活动服务锁
A-->>C: 停机结果(含未完成原因)
C->>C: 复核进程组消失;逆序停止独占依赖
```
停机预算建议应用30秒、监管60秒,必须按最长合法步骤与故障实测调整;SSE连接主动结束,不能占满排空预算。某阶段出错继续运行后续可安全清理,保留聚合结果。工具无法停止或副作用未定时先持久hold并保留现场;强制结束后必须走崩溃恢复路径,不返回“已优雅停止”。
### 5.2 不同工作的恢复策略
| 停机前状态 | 重启处理 | 自动执行边界 |
|---|---|---|
| 已完成/失败/明确取消 | 原样加载结果及原因 | 不重新执行 |
| 已接受但未开始 | 按持久队列、权限和预算重新调度 | 条件满足后自动 |
| 纯读、可重建的计算 | 从已提交步骤边界继续 | 不重复已提交业务结果;模型回合可重新生成 |
| 正在执行幂等副作用 | 根据operation_id、目标查询/幂等合同核对 | 确认安全后继续 |
| 非幂等副作用结果未知 | 自动hold,展示原因和可核对证据 | 有权人对账具体operation;确认完成则记录receipt并检查剩余步骤;确认未执行须满足KTD8终态与旧请求隔离条件;可明确放弃整项任务;禁止直接“放行即重跑” |
| 等待HITL | 恢复稳定gate/version及持久答案 | 未回答继续等待;已回答幂等消费;撤权/版本变化拒绝并说明 |
| 子代理/后台notice | DB唯一恢复claim关联旧、新attempt | 不由文件标记决定唯一性,不重复派生/投递 |
| 索引与缓存 | 从文档/内容权威源重新排队,记录索引generation | Redis可清空重建;恢复模型/维度/版本一致性后发布索引 |
| 未配置executor、缺文件或未知归属 | 保持blocked并提供处理原因 | 不丢行、不假完成、不盲续跑 |
```mermaid
stateDiagram-v2
[*] --> pending
pending --> running: 获得有效owner/预算
running --> waiting_hitl: 持久gate
waiting_hitl --> running: 当前权限下消费答案
running --> completed: 结果与状态原子提交
running --> recovering: 停机或失联
waiting_hitl --> recovering: 执行者重启
recovering --> pending: 核对可安全继续
recovering --> waiting_hitl: 恢复原等待
recovering --> hold: 副作用未知/权威数据不完整
hold --> pending: 有权人对账确认安全
hold --> recovering: operation对账结果与receipt已持久化
recovering --> completed: 全部必要步骤与业务结果已确认完成
hold --> cancelled: 明确放弃
```
`recovering/hold`在这里是目标业务语义,**不是声称现有Core枚举已支持**。过渡可用恢复账本表达;若新增公开状态,Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留,不强改成成功。
用户侧复用现有任务状态、对话卡和系统管理区,显示恢复原因、进度和动作。当前只有管理员恢复 API 基础,Frontend 对账接线待 U4 实施,不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件,刷新重载权威快照;断连不推断完成。实施界面先读 DESIGN.md,遵守令牌、Collapsible和单异步状态所有者。
## 6. 全量数据与组合备份
| 数据类别 | 权威与恢复方法 | 必须对账 |
|---|---|---|
| 用户、项目、成员/权限、会话/消息、文档/版本、卡片/Surface、设置、插件授权 | PG团队库或个人SQLite;包含全部已启用插件/下游的自有存储 | 主键、owner、权限、版本、关键内容摘要;禁止以空库替代 |
| run/step/命令/通知/审批/取消/额度/恢复hold | 持久账本与状态事务 | 链接、唯一请求、gate版本、owner/epoch、队列位置与外部receipt |
| 上传、工件、文档大内容、输入附件、转录、派生请求 | 持久对象/文件目录,与DB清单匹配 | 内容hash、尺寸、引用版本、权限与可读性 |
| 执行工作区、overlay/checkpoint、任务Git现场 | 受管workspace与副作用记录 | 实际修改、基准SHA、未提交文件、执行者退出与恢复边界 |
| 程序、Web资产、插件版本、实例配置、秘密引用/密钥 | 不可变组合manifest;受限配置/秘密备份 | 摘要、schema兼容、插件签名/授权、恢复凭据可用且未泄漏 |
| 检索/向量索引、Redis缓存、临时PID/连接 | 从权威数据重建;PID按新boot重新观察 | 模型/维度/generation;不作为任务成功、审批或永久幂等权威 |
普通启停不从备份还原;数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行,禁止start自动覆盖当前数据。
当前 agent backup 只复制 svc.env、history 和 data(逐 SQLite 一致性导出),不含权威 manifest,在线非 DB 文件与 DB 没有统一快照时点;它是数据目录快照,不是完整恢复包。当前 pg_dump 默认在 runtime 子目录,完整包及副本须放在数据/runtime 生命周期之外;生成时使用受限临时目录,校验成功后原子发布完成标记。半成品不列作恢复点,完成且验证的新备份存在前不执行保留策略删除。
首期备份取得明确停写窗口:关闭准入、排空或隔离在途操作、停止全部相关写者,核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致;写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点,manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。
恢复到新目标首先处于隔离验证模式,不启动任务调度/副作用,也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离:可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离;不得为此擅自轮换共享凭据。生成新的恢复权威代次,并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏;旧实例不可联系不能当作停止证明。无法核实则保持副作用hold,只开放受权的数据核验。
同时对账恢复点至故障/隔离完成期间的外部效果:它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对,将已确认动作登记到恢复账本,确认安全后逐项解锁;不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。
灾难恢复另设安全状态门禁:开放正常认证前作废备份中的全部会话和未使用登录 Key,防止已注销/消费的凭据复活。恢复点后的改密、长期 Key 撤销、角色/成员/插件授权变更与独立受信记录核对;缺记录或无法证明当前有效性时,相关主体/资源保持鉴权隔离,有权 owner/运维重新建立凭据或确认授权后开放。新执行 epoch 不代替认证撤销。普通启停/更新不执行此规则;普通账户恢复保留集成 Key 的合同也不允许灾难恢复盲目启用旧 Key。
PG逻辑pg_dump用于独立逻辑恢复;PITR须有物理基础备份和连续WAL,不能用pg_dump冒充其基础备份,依据[PostgreSQL备份与PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)。SQLite使用现有一致性备份接口,不能在线只复制.db遗漏WAL。文件内容先耐久发布再提交DB引用,备份保留覆盖恢复点所需的对象版本。
备份副本及密钥与原数据同级保护:加密、专用受限目录/角色、异机或异故障域副本、保留期限与清理owner;密钥须独立可恢复。拟定每日日常备份、持续WAL、每月及重大升级前恢复演练,频率按批准的RPO与数据量固定。实际恢复须验证登录、跨项目隔离、历史文档与附件、任务/HITL、工件下载和插件业务链;恢复时间从故障触发开始计时。
部署先构建并检查完整候选目录,再切固定组合;失败仅在schema/插件/配置向后兼容时回退程序。数据回退须对账回退点后已接受业务和外部效果,不能“恢复旧库”而静默丢失新写入。
## 7. 实施增量与依赖
以下U-ID属于本案,与协作存储案的同名U-ID独立。每个增量完成设计细化、自检、正式验收与Review后按policy/delivery.md人工评审;本次不授权实施。新增文件名是建议,最终按实际模块边界落位。
### U1. 实例与数据恢复身份
当前 manifest/DB identity 基础已在源码,既有合同见 Dev `docs/recovery/u1-identity-manifest.md`;本轮只规划消费缺口、派生修复和显式 init/restore,不重复建立身份层。
对应R2/R3/R9;无前置。范围:`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。
做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口;保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归,再改解析器。
验收:连续两次裸启停保持同一DB与原始记录;只改端口保持data/plugins;单独data覆盖按合同生效/拒绝;配置迁移每个写边界kill后只能读到完整旧/新版;缺凭据、错DB、丢marker不得新建空系统;更换二进制路径/程序版本或以不同cwd调用svc后,DB identity、数据/工件/工作区根与插件组合保持一致(对应R2更换程序/cwd条款)。使用真实PG特有测试记录核对,桩测试只能辅助。
### U2. 服务组与进程监管
当前 recover/watchdog/desired 已有首切片,余量为服务组、依赖 readiness、唯一监管与完整操作恢复,不再记为全部未实现。
对应R1/R8;依赖U1。范围:svc组编排、可选Redis适配、分发仓`deploy/agent-system.service`及安装接线、新增隔离服务组故障测试。
按KTD3/KTD4建立依赖图、desired state、可恢复lifecycle operation与单一监管;加入boot/start/exe身份与进程组校验。必需/可选、受管/外部资源由manifest决定。首次切监管在明确停机窗口完成,失败回到原监管且不形成双启动。
验收:全组停止后启动;先PG后应用;主动stop保持停止;kill自动退避恢复;主机重启按策略恢复;PID复用、残留子进程、端口冲突、依赖启动失败、不透明外部DB均正确拒绝/报告;不得停止其他服务组的共享依赖。
### U3. 应用启动、停机与真实就绪
对应R1/R8/R10;依赖U1,可与U2并行。范围:`modules/backend/internal/app/app.go`、`runmgr/runmgr.go`、`runmgr/events.go`、`plugins/host_v2.go`、server健康接口及其生命周期测试。
统一lifecycle context、准入开关、消费者停止与worker join;恢复执行移到装配结束;不同停机原因统一条件结算;sidecar受监督并纳入收口;readiness、恢复摘要和受限诊断按KTD12实现。停机预算属预算来源变更:现状HTTP停机超时仅5秒且超时即返回、跳过后续事件清冲(app.go停机序列,SELF源码核验);“应用30秒/监管60秒”须显式替换该常量并按最长合法步骤与故障实测校准,不得沿用旧值。
验收:插件/预算/Workflow未装好不启动恢复任务;停机同时提交新run被拒;SSE与慢工具不跳过flush/清理;子run不被cancelled覆盖;sidecar崩溃可检测;DB坏/恢复扫描失败不ready;hold不影响无关会话的正常读写。
### U4. 持久任务恢复与副作用隔离
对应R4/R5/R7;依赖U3,并复用U5所有权接口;U4/U5作为同一安全交付批次,完整性验收前不开放自动续跑。范围:runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。
落实KTD7/KTD8,主run、Workflow、子代理、已配置后台executor共享恢复政策;持久化步骤/输入/结果/operation;自动hold连接到工具与启动扫描。HITL保持gate、答案和权限;修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围;若新增recovering/hold为公开状态,设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表,作为设计评审前提。
Frontend 接线复用任务/对话卡和系统管理区:有权 owner/admin 查看具体 operation、未知原因和证据引用,提交已完成 receipt、未执行终态及旧请求隔离证明,或明确放弃。提交防重复,失败保留输入与原因,成功重载权威状态;Backend 按 operation 权限/版本/epoch 裁决,不以当前整 run release API 代替逐项对账。浏览器验收覆盖发现 hold→对账→剩余步骤恢复,拒绝越权和「放行即重跑」,不新增页面。
验收:排队/主run/子run/HITL/索引各类任务kill并两次恢复;工具“完成外部动作、结果未提交”只hold不重做;查询暂未发现但外部请求稍后完成时不发送第二次请求;幂等目标使用同operation key;Native pending intent只由统一账本决策,不生成普通错误后绕过hold;确认一个operation完成后执行剩余必要步骤,不假结算整run;未知工具默认隔离;撤权后禁止续跑;无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源,未跑标NOT_RUN。
### U5. 所有权、额度、命令、通知与投影闭环
对应R4/R5/R6/R10;依赖U3;与U4共同验收。范围:`store/execution.go`、`store/admission.go`、`runmgr/admission.go`、`runmgr/commands.go`、server取消/HITL、notice、surfacesvc与PG集成/多进程故障测试。
续租及失权取消覆盖全部入口;持久队列/额度对账与共享唤醒;命令lease+处理后ACK;notice事务消费;Surface成功后ACK且持续批量drain。租约到期后的外部不确定行为仍进入U4 hold。
验收:占满额度kill后新工作可前进;长run跨租期不失权;旧owner晚到状态/事件/工件被拒;claim后kill命令可重领;取消正确解析conversation并不越权;HITL答案一次生效;notice及子代理并发恢复只建一个后继;超过100条投影事件全部处理,发送失败不清pending。两真实进程与真实PG是必要证据。
### U6. 文件发布、组合备份与部署回退
对应R3/R7/R9;依赖U1/U3,恢复账本完整验收依赖U4/U5。范围:blobstore/content、workspace与checkpoint、插件恢复适配合同、svc deploy/update/backup、分发仓安装、备份manifest与restore测试。
按KTD11发布不可变版本,扫描缺失/孤立对象;登记全部插件/下游存储;按第6节生成一致恢复点、保护副本、恢复到新目标;候选完整构建后切版本,保留兼容上一组合。
验收:对象写后DB提交前kill;覆盖发布过程中kill;日志尾截断/文件缺失保留现场;备份恢复后原文hash/权限/插件链一致;恢复新目标后旧实例复活仍不能产生外部效果,未完成旧写路径隔离时新目标不调度;恢复点后已发生的外部效果对账完成前保持hold;升级ready失败可在兼容条件下回退;不兼容schema拒绝程序自动回退;数据回退不静默丢新写入。
另覆盖恢复点后注销会话、消费/撤销登录 Key、撤销集成 Key、改密与撤回角色/项目/插件权限:恢复旧包后旧会话和登录 Key 不再有效,无法证明有效的长期 Key/授权保持隔离;owner 正常确认后的新凭据可用。与普通重启原密码保持分别签收。
### U7. 故障验收与交付放行
对应全部需求;依赖U1–U6。范围:Dev新增隔离`tests/integration/recovery/`、故障注入控制点、运行手册与需求证据表。
固定Dev/全部组件、运行制品与配置摘要;使用脱敏数据、独立端口/PG库/文件根及工具目标;记录故障点和恢复统计。先执行小规模逐点故障,再在批准规模混合运行。破坏性kill/断电测试只能在隔离环境实施。
验收:第8节每类故障均有可重放证据;RPO=0档已确认数据零遗漏,灾难档恢复点差距≤批准RPO且点内数据零遗漏、点后缺失和外部效果明确对账;零未识别重复副作用、零越权/双有效写者;时间满足批准指标;用户实际刷新、重连、登录、任务/HITL、文档和工件链通过。服务恢复与数据/任务恢复分别签收。
建议交付批次:A=U1/U2/U3(可靠启动及安全停机,自动任务续跑关闭);B=U4/U5(安全自动续跑与命令闭环);C=U6/U7(文件耐久性、灾难恢复及全系统签收)。只交付A不能宣称完成用户的全部需求。
### U8. SQLite 活动服务隔离与既有存储门禁
覆盖 R2/R3/R6/R11/R12,复用 U1 身份;近期优先于自动恢复和共享库测试。范围:Backend `internal/app/app.go`、`internal/store/store.go`、`internal/store/system_identity.go`、新增 `internal/instanceguard/`(拟定);Dev `scripts/svc.sh`、`docs/svc.md`。锁只控制活动服务运行时,CLI 身份/schema 合同由[账户方案](2026-10-12-svc-unified-deploy-and-login-key.md) U7 负责。负责人待实施批准时指定。
依赖:既有 U1;联合确认 service/CLI/migration 模式,先刻画原例和别名冲突,再实现;不直接把当前 dev 数据迁往 PG。
测试:新增 Backend `internal/instanceguard/guard_test.go`,扩展 `internal/store/system_identity_test.go`;Dev 新增 `tests/test_svc_storage_ownership.py`,复用 `tests/test_svc_identity.py`。新增路径为计划。
T8-1:两个独立进程同时启动同 SQLite,只有一个进入迁移/恢复;第二个明确拒绝,第一个 run/HITL 不变。
T8-2:直接二进制、legacy、符号链接和可构造的文件别名不能绕过;真实 DB 替换/锁根丢失被识别。
T8-3:活动服务 SIGKILL 后合法同实例可重启,OS 释放锁;主动停止不被 watchdog 错拉起。
T8-4:服务运行期间合法账户 CLI 可提交短事务;错实例/缺库拒绝、不建目录、不 migrate;迁移不与活动服务并发。
T8-5:更换端口、cwd、程序版本保持同一资源;测试候选默认独立根,显式指定共享根也不得绕过保护。
T8-6:参数来自应用实际连接;SQLite FULL/PG 同步设置按批准合同核验,磁盘满/写失败不返回成功。
环境:独立 SQLite 根与端口、真实 PG 独立库回归;双进程和 kill 禁止在当前 dev/candidate 执行。全部 T8 当前 NOT_RUN。
近期批次 A0=U8+账户方案 U7/U5:先稳定数据归属和账户链路;另行授权后完成 dev 原账户正常登录/重启/更新验收,见账户方案 §7。A/B/C 保留;U4/U5 联合验收后才开放自动续跑,A0 不代替全量恢复。
## 8. 验证合同
| 故障/操作 | 最小判据 | 对应需求 |
|---|---|---|
| `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 |
| SQLite 双进程、直接启动、别名、锁释放 | 第二活动服务在迁移/run对账前拒绝;合法 CLI 可用;kill 后同实例可重启 | R2/R6/R11 |
| 实际 DB 耐久档、权威文件发布点、磁盘满 | 参数来自应用连接;确认结果已耐久;失败不发布成功;旧版本可读 | R3/R7/R12 |
| 应用SIGTERM/SIGKILL/OOM | 持久数据完整;安全工作可恢复;额度无永久占用;无残留写者 | R3/R4/R6/R8 |
| PG停止/重启、断连或提交响应丢失 | 不切SQLite;不假接受;按幂等记录对账;重连后可用 | R2/R3/R5 |
| 主动stop与异常退出、监管/编排中途kill | 主动停止不拉起;异常按running意图恢复;操作重复安全 | R1/R2/R8 |
| PID复用、重复启动、旧进程冻结后复活 | 不误杀其他进程;一个有效owner;旧epoch无发布/副作用权限 | R1/R5/R6 |
| 排队、HITL、跨实例取消、子代理/notice恢复中途kill | 接受意图不丢;审批一次生效;后继run/消息不重复 | R4/R5/R6 |
| 外部效果完成而结果未落库、旧请求延迟完成 | 自动hold、有receipt对账和权限检查;暂未发现结果不触发非幂等重试;动作结算后继续未完成步骤 | R4/R5 |
| 文件rename/发布边界kill、磁盘满、文件/日志截断 | 不确认未耐久结果;原发布版本一致;损坏可定位、原件保留 | R3/R7 |
| 插件sidecar退出、插件存储缺失、索引重建失败 | 必需失败不ready;可选明确降级;数据与授权保留 | R1/R3/R7/R8 |
| SSE断开/页面刷新、>100待投影、投递持续失败 | cursor补齐持久事件;旧事件丢弃;失败记录不被ACK | R4/R7/R10 |
| 主机重启/断电 | 原数据盘恢复、全部期望服务重新就绪、耐久性指标有真实证据 | R1/R3/R7/R8 |
| 完整备份在新目标恢复、旧实例复活、升级失败/回退 | DB+文件+秘密/版本匹配;旧写路径隔离;恢复点后外部效果对账;灾难档满足批准RPO;权限与业务链可用;回退兼容且不静默丢新写入 | R3/R5/R6/R9/R10 |
验证分层:svc治理桩回归→Backend单元/SQLite→真实PG及多进程→真实工具替身故障链→少量真实模型→真实浏览器与主机级故障→灾难恢复。每层证明不同合同,不相互替代。
执行时使用项目已有`make test-governance`、`make test-backend-pg`、`make test`、`make build`并增加受管隔离recovery入口。真实PG/Redis/模型/主机测试缺环境时必须明确NOT_RUN或SKIP及缺项,禁止把零用例或条件跳过当通过。按AGENTS要求验收/请求审核/合入前分别task-sync;所有precheck、同步、测试原始输出通过make evidence进入任务卡,并区分SELF/REPLAY/GATE。业务行为面的真实模型验证遵循policy/delivery.md,单测不替代。
本轮只进行源码与文档检查,业务/数据库身份查询、故障注入、模型试验、迁移、服务启停、部署均NOT_RUN。方案r2不能作为恢复能力验收结论。
## 9. 兼容、在途任务与批准事项
本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同;不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续,不另起重复模块。
原 r2 的 svc-autorecover 二选一属于历史启动现场;当前 recover/watchdog 和 U1 身份已有源码,不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管/RDM UI/端口回收任务,避免重复修改入口。RDM/插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。
备选:仅修svc脚本成本较小,只能覆盖启动配置/进程,无法满足在途任务和副作用恢复;另造常驻恢复daemon会增加新的监管者与恢复责任,首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
实施批准时需要固定:目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议;没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置,但未知副作用不得靠默认重试放行。
下一任务建议为 U8 与账户方案 U7/U5 的首批设计/实施评审:先保护 dev 原数据,补足账户一致性与登录语义;随后 U3 停机/就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件;PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。
## 10. 全系统完成条件
只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后,才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
本轮交付状态止于**待审核方案**;不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
@@ -0,0 +1,245 @@
---
title: svc 统一部署与一次性登录 Key 方案
type: feature
date: 2026-10-12
artifact_contract: ce-unified-plan/v1
execution: code
product_contract_source: ce-plan-bootstrap
---
# svc 统一部署与一次性登录 Key 方案 r2
确认状态:**r1 原批准保留;r2 本轮增补待人工评审**。r1 的批准记录为 2026-10-12 用户「批准,继续推进」(五阶段及 U1/U4 规格,允许对应实施和 PR)。本轮用户要求仔细调研、详细方案并「继续」,覆盖方案修订及本地文档准备,不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。
修订记录:r1=2026-10-12 草案经源码复核后定稿(四项取舍采纳;补齐 §6 合同;对齐恢复方案 KTD 与已合入的 recovery U1 实例身份);同日获批并进入推送与 U1/U4 实施。
r2=同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口;保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号,补充 R13–R15、KTD11–KTD14、U7/U8,并细化 U5。新增内容未批准;不以原批准记录代签新增范围。
需求来源:2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口(二进制与源码、环境准备、无初始密码开户与账户恢复),并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人:weichen;编制:Cursor Agent。
主记录:本文;任务卡:Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。
## 1. 目标与成功边界
**目标:在干净或既有机器上,用同一套 `svc` 入口完成二进制或源码部署、按档准备依赖,并通过后端账户能力完成无初始密码开户与账户恢复;一次性登录 Key 只能兑换设密受限会话,完成设密前不能访问业务数据。**
必须区分三类能力:
| 能力 | 结果 | 非目标 |
|---|---|---|
| 统一安装 / 升级 | 指定版本或提交物化为可切换候选;切换后实例身份、DB、数据根与账户不变 | 不接管共享 PostgreSQL;不因发现端口而认领外部服务 |
| 环境检测与准备 | `doctor` 只报告;`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建;工具链版本读自所选提交或发布清单 |
| 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key;原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户;不迁移业务归属;普通找回默认不撤销长期集成 Key |
与 [服务重启与全量数据恢复方案](2026-10-12-service-restart-data-recovery.md) 的关系:
- **复用** KTD1–5、KTD12:持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。
- **复用** 已合入的 recovery U1(Dev #415):`runtime/<name>/manifest.json`、启动身份校验、`svc init`、原子写路径(见 Dev `docs/recovery/u1-identity-manifest.md`)。
- **本方案新增**:部署来源统一(binary/source)、doctor/env prepare、账户生命周期与一次性登录 Key、安装入口与双轨收敛。
- 命名区分:**账户恢复 Key** ≠ **服务数据恢复**。
## 2. 当前事实及重点差距
本轮 source 基线(SELF):权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`;文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`(增加任务元数据);Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`;Frontend `cc233fec908d0f8c12193042942b94ad68508091`;Dev 固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。本轮 Documents 草案从其独立权威 main `1048e7c6afc2bb4efc541e68575c3fb2669ee332` 起步;与 Dev 固定版相比,两份目标方案正文没有上游差异。Dev gitlink 未推进。原 r1 基线只作历史,不用于当前能力判断。
2026-10-12 17:37:03(Asia/Shanghai)的只读运行观察和启动/同步命令,原始脱敏输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。这是 SELF 观察,不是登录、故障或恢复验收,后者均 NOT_RUN。
最终同步基线为 Dev `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9`:主干另已推进固定 Documents 至 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`,并修复 svc 批量操作的 PIDCHECK/EXEC 等内存态串用;本轮未重复该修复,也未推进本轮 Documents 草案 gitlink。Backend/Frontend 固定 SHA 未变;上述初始基线和17:37观察保留历史时点,不冒充最终 HEAD。
| 对象 | 已存在的基础 | 尚需补齐 |
|---|---|---|
| 部署来源 | `deploy --from local\|dev\|release\|rdm`;dev/rdm 独立缓存物化;release 读本地 Releases 仓并校验 sha256 | 远程下载/离线导入;统一 `install`;release@ver 钉扎(现 `sort -V\|tail -1` 取最大版本,见 `scripts/svc.sh` `resolve_release`) |
| 部署生命周期 | 预检失败不停机;预检通过后 **先停再构建**;无程序备份/自动回滚 | 候选获取与校验全程不停旧服务;缺摘要硬失败;迁移后回退独立判断 |
| 实例身份 | recovery U1:manifest + marker + init;`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置;缺绑定拒绝,禁止回落 `./data` |
| 环境 | 端口/`flock`/pg 工具链按需检查;文档列前提 | `doctor` / `env prepare`;无 `flock` 时不得放行冲突操作(现状直通) |
| 账户 CLI | Backend 已有 create/reset-password/list/issue-login-key/revoke-login-key/bootstrap-admin;svc 已接 `user` 且附加 OpenExisting | 顶层/专题帮助未列账户入口;OpenExisting 仍 migrate;账户路径未完整验证 DB identity;参数回显及 argv 凭据需整改 |
| 登录凭据 | 长期 `api_keys` 与独立 `login_keys` 已分离;一次性 Key 原子兑换为短期受限会话 | 原子开户+签发、统一密码变更及审计仍有缺口;不能把基础实现等同于整体验收 |
| 强制改密 | Backend 已有受限会话和 must-change 中间件,强制设密成功销毁会话并要求重新登录 | Frontend 仍只有密码/长期 Key 两个入口,未接兑换及 sessionScope/reloginRequired;设密后直接 onDone 与后端不兼容 |
| 安装双轨 | Dev `svc deploy` 多实例;Releases `install.sh` 系统 systemd | 统一部署计划;`install.sh` 薄封装或明确遗留 |
命题裁定(源码复核):
1. 长期 API Key 是 show-once plaintext,不是 single-use;一次性登录 Key 是独立类型,当前代码已区分。
2. r1 所记「无统一改密门」已被 U4 源码覆盖,不能继续作为待建能力;普通改密/管理员重置仍缺统一事务及旧恢复 Key 作废,见 `modules/backend/internal/server/accounts.go:208`、`modules/backend/internal/store/auth.go:244`。
3. `scripts/svc.sh:1503` 已实现 user 转发,但帮助未列;`modules/backend/internal/app/app.go:743` 的账户插入和 Key 签发分别提交,不能采信注释中的「同事务」。
### 2.1 dev 8788 事件与归因边界
用户明确故障对象为 dev(127.0.0.1:8788)。17:37 的实际进程打开 `runtime/dev/data/agent-system.db`,数据库 marker 为 dev 的 SQLite 身份;该现场没有使用 PostgreSQL,不能沿用旧报告的 pg1/agent 描述。
| 只读对象(北京时间) | 账户身份 | 最后设密时间 | 与 live 摘要比较 |
|---|---|---|---|
| 12:35:03 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
| 14:50:37 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
| 17:37 的 live | 同一账户,must-change=0 | 16:03:20 | 当前值 |
比较仅输出时间、状态及相等性,不输出摘要或凭据。它证明字段重写,不证明明文改变;随机盐使同一明文的重新散列也可能不同。未发现正常启动/更新/迁移 up/设置播种自动覆盖既有密码的路径;现有 audit_events 只有 Surface 事件,无法归因此次写入。另有已消费恢复 Key,但其消费时间不能证明之后哪次设密由它触发。
前一轮观察到 dev 与候选 rdmcand 指向同一数据根;17:37 候选处于停止,因此历史共享不写成该时点双进程事实。18:14:09 续查时,外部流程已将候选重新启动于独立的 `runtime/rdmcand/data/agent-system.db`,实际文件 inode 与 dev 不同,登记和制品版本相符;dev 最后设密时间仍为16:03:20。这缓解了当前共享现场,不能代替 Backend 防误用锁或完整验收。历史共享说明跨实例影响范围,不证明某次更新主动改密;本轮未执行这些现场变更。
本轮不进行真实账户登录尝试或再次重置来验证旧密码;故障重放仅在脱敏、独立数据副本上执行。首批完成还需另行授权的 dev 原账户正常登录验收,见 U5/U8 合同;该验收不在 live 进行 kill、并发或故障注入。历史操作者归因仍未证实,新增审计不能反向补造旧事件。
## 3. 需求合同
| ID | 范围 | 要求与可判定验收 |
|---|---|---|
| R1 | 安装入口 | `doctor` / `install` / 兼容 `--from` 生成同一部署计划;二进制无需 Go/Node;源码固定提交且子模块组合可核验 |
| R2 | 实例身份 | 启停、升级、开户、签发 Key 命中同一 store 与 data 根;缺失/不符拒绝;与恢复案 R2/manifest 一致 |
| R3 | 切换安全 | 构建/下载/摘要失败时旧服务继续;程序+插件+前端作为版本组合切换;固定版本不得被「最大版本」替代 |
| R4 | 存储档 | team 默认 PG+auth;`existing` / `managed-local` / `local(SQLite)` 显式选择;PG 失败不回落 SQLite |
| R5 | 开户 | 无初始密码;角色明确;创建与激活 Key 同事务;同名冲突不覆盖 |
| R6 | 账户恢复 | 精确命中既有账户;不改密码/不吊销会话/不改业务数据于签发时;保持 owner/角色/成员关系 |
| R7 | 一次性 Key | ≥256bit、只存摘要、activate\|recover、默认 TTL 30min、状态机、原子兑换、专用 POST body |
| R8 | 受限会话 | 仅身份查询、设密、退出;业务/下载/SSE/admin/插件拒绝;普通 `must_change` 同样服务端限制 |
| R9 | 设密事务 | 写 hash、清待激活/待改密、作废未用恢复凭据、失效相关会话同事务;成功后销毁受限会话并要求密码重新登录 |
| R10 | 集成 Key | 普通找回默认保留长期 API Key;失陷恢复显式 `--revoke-all-credentials` |
| R11 | 首次管理员 | 仅核验为新实例(无用户且无历史业务标记);事务防并发;不得因「未发现管理员」接管有数据环境 |
| R12 | 证据 | 验收绑定固定源码/制品摘要/环境;SELF/REPLAY/GATE 分源 |
| R13 | 可发现与兼容 | 完整/短帮助、help user、实例 user --help 和文档列出实际账户能力;不支持的制品在调用前拒绝;帮助/探测不建库、不迁移、不启动服务 |
| R14 | 账户稳定与审计 | 普通启停/更新不隐式重置;密码变更、恢复凭据/会话处理及成功审计原子提交;记录 actor、入口、实例、operation 与时间,不记录密码、摘要或 Key 明文 |
| R15 | 运维既有库 | 账户操作核验预期库和实例;读操作不建库或 migrate;schema 不兼容明确拒绝,迁移走独立入口;CLI 参数和日志不暴露凭据 |
## 4. 技术决策(KTD)
KTD1. **部署方式只决定程序来源,不决定数据位置。** binary ↔ source 可切换;切换保持 DB、数据根、账户与 instance_id。
KTD2. **账户规则只在 Go 后端。** 脚本调用实例对应版本的 CLI;不直接改用户表。
KTD3. **一次性登录凭据独立于长期 `api_keys`。** 专用表与兑换 API;普通 Bearer、SSE `?key=`、长期 Key 路径均拒绝。
KTD4. **受限会话为独立 scope。** 默认 10 分钟;allowlist 仅 me / 设密 / logout。
KTD5. **团队安装默认 PostgreSQL;存储选择显式。** 与恢复 KTD5、`config.Tier=team` 一致。
KTD6. **一次性 Key 默认 30 分钟**(可配置建议范围 5–120 分钟);审计记实际 TTL。
KTD7. **激活/恢复设密成功后必须重新密码登录**(销毁受限会话、清 cookie)。普通主动改密可保留「要求原密码」路径;激活路径不要求原密码。
KTD8. **普通账户恢复默认保留长期集成 Key;失陷显式撤销全部凭据。** 两种情况均保留业务数据。
KTD9. **候选校验完成前不停旧服务**;切换短窗;schema 迁移后能否自动回退旧程序另行判断,失败不自动用备份覆盖业务库。
KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端;Releases `install.sh` 变为薄封装或文档降级为遗留,禁止第三套生命周期。
KTD11. **能力声明与帮助同源,但后端仍是执行权威。** 新制品提供无副作用的结构化能力声明;旧制品仅按已验证版本兼容,未知形态拒绝。禁止尝试未知子命令或靠 strings 包含某词推断能力。保留 reset-password 的直接重置语义,不偷偷改成签发恢复 Key。
KTD12. **统一密码与开户事务。** 严格唯一 INSERT;散列计算在事务外,事务内重新核验权限/账户版本。主动改密、CLI/管理员重置、恢复设密共同执行密码+标志+旧登录 Key 作废+规定会话处理+审计。普通路径保留集成 Key,失陷模式按 KTD8 明确撤销;失败全部回滚。
首次管理员按实例串行,不能只依赖 owner UNIQUE:PG 锁定既有实例身份行,SQLite 使用立即事务,取得串行权后重新核验无用户、无历史业务;引导与能改变此前置条件的开户共用串行点。管理员、激活 Key 和审计共同提交;marker 缺失时由显式 init 处理,账户命令不得补建身份。
KTD13. **审计可归因,运维不隐式迁移。** 成功审计与变化同事务;失败记录注明未提交;HTTP actor 来自已认证会话,CLI 记录受信 OS 运维 UID/身份来源,不接受调用方填写的 actor 作为证明。实例身份和操作 ID 实填。既有库读命令只校验兼容性;迁移另行批准和执行。
KTD14. **凭据只经安全输入和单次交付。** 优先无回显输入/stdin/受保护文件,DSN 不传 argv。serve 已消费 AGENT_SYSTEM_DSN,账户 CLI 的等价安全输入需在 U7 显式接入并以能力声明核验,不能假定当前 user flags 已读取环境。非交互输出独占创建 0600 文件,日志/evidence 只记凭据 ID。提交后交付失败按 operation 查询,再撤销/重发;库存摘要不能重新打印旧明文,不把重试当首次创建。
## 5. 职责划分与接口示例
| 部分 | 负责 |
|---|---|
| `svc.sh` | doctor、env prepare、获取制品、构建、实例配置、生命周期、调用账户 CLI |
| 后端 CLI | 创建账户、签发/撤销一次性 Key、核验目标库、OpenExisting、操作审计 |
| 后端认证 | 原子消费 Key、受限会话、设密事务、中间件限制 |
| 登录页 | 输入一次性 Key、设密、过期/重发提示;遵循 `DESIGN.md` |
| 发布制品 | 版本、平台、摘要、组件版本、能力声明 |
拟新增 CLI(当前脚本尚不支持;兼容 `--from` 保留):
```bash
./svc.sh doctor --mode binary --tier team
./svc.sh install prod --mode binary --version <固定版本>
./svc.sh install prod --mode source --repo <仓库> --ref <固定提交>
./svc.sh prod deploy --mode binary --version <固定版本>
./svc.sh prod user create --owner alice --role user
./svc.sh prod user issue-login-key --owner alice --purpose recover
./svc.sh prod user list
./svc.sh prod user revoke-login-key --id <凭据编号>
```
Linux 服务账户与应用账户分开管理。
## 6. 规格合同(实施前必须写进 U1/U4,否则返工)
1. 独立凭据类型 + `POST` body 兑换 API。
2. 会话 scope / 中间件 allowlist;覆盖 `must_change` 普通首登。
3. 设密接口分型:受限会话不校验原密码;普通改密继续要求原密码;同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。
4. 密码未设置状态:`password_hash` 可空或 sentinel;`VerifyLogin` 拒绝未设密;创建 = 用户行 + 激活 Key 同事务。
5. CLI `OpenExisting`:目录/DB 不存在则失败;账户运维默认只校验兼容 schema,不 migrate;迁移独立执行。配套 U1 v0.2 候选同此合同,原 requireCompatible 自动 migrate 是历史实现。
6. `release@<ver>` 必须解析到该版本目录;缺摘要硬失败。
7. 部署:获取/构建/校验不停旧服务;组合切换;迁移后回退独立判断。
8. `install` 与 `--from` 同一计划;双轨收敛(KTD10)。
9. 首次管理员仅新实例;事务防并发。
10. 凭据交付:交互 stdout 一次 / 非交互 `chmod 600` 文件;日志与 evidence 只记凭据 ID;随机密码路径首期可并存但默认无密码 + Key。
11. 无 `flock` 时拒绝冲突生命周期与账户操作(收紧现状「直通」)。
详细设计(正文在 Dev 仓,随本任务分支提交):
- U1:`docs/svc-deploy/u1-instance-account-binding.md`
- U4:`docs/svc-deploy/u4-one-time-login-key.md`
## 7. 增量与完成门槛
| 增量 | 主要范围 | 完成条件 |
|---|---|---|
| **U1** 实例—账户绑定补齐 | 账户 CLI 读实例 manifest;OpenExisting;锁缺失拒绝;install 骨架对接既有 identity | 开户/签发命中同一 store;错误 data/DSN 拒绝;与 recovery U1 字段对齐 |
| **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署;固定版本与摘要可核验;修复 release 钉扎 |
| **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验;幂等;不接管共享服务;binary 不装 Go/Node |
| **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密;受限会话无法调业务 API;并发兑换单胜 |
| **U5** 脚本与登录页接线 | 账户帮助、无副作用能力探测、凭据安全交付、Login/设密页 | 新建与恢复走通;设密后清受限会话并返回密码登录;不支持的产品明确拒绝;DESIGN.md |
| **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档;故障注入;浏览器 + 真机;治理回归 |
| **U7** 账户事务与稳定性补齐 | 原子开户/引导、统一改密与撤销、审计、只读兼容打开 | 并发建号不覆盖;中断无半状态;旧恢复 Key 失效;身份缺失不改库;升级保持登录能力 |
| **U8** 实例运维核验与凭据诊断 | 账户状态/事件查询、绑定和制品诊断;补齐 U1 身份消费 | 可定位合法变更来源、识别错库/失效会话/错误 Key 类型;只展示非秘密元信息 |
**当前 U1/U4 基础已在源码中,近期优先 U7 和 U5,并与恢复方案 U8 隔离保护协调。** U7 先冻结后端账户事务/审计及能力声明合同;U5 随后完成浏览器与脚本;U8 诊断复用其记录。U2/U3 保留后续,不让通用安装器阻塞 dev 账户稳定。各仓从共同批准基线起独立任务;Backend → Frontend → Dev 组合,正式组合验证后才推进 gitlink。
### U7 近期实施与验证合同
覆盖 R5/R6/R9/R10/R11/R14/R15;依赖既有 U1/U4,实施负责人待指定。
范围(相对于 Backend):`internal/store/auth.go`、`internal/store/login_keys.go`、`internal/store/platform.go`、`internal/app/app.go`、`internal/server/accounts.go`、`cmd/agent-system/main.go`;迁移目录仅在 schema 需要时改动。
先刻画现有显式改密、重置及建号行为,再修复并发与中断窗口。账户校验、禁止隐式 migrate、严格 INSERT 和统一密码事务是单一后端实现,脚本不直接写表。
现有测试参考 `internal/store/login_keys_test.go`、`internal/server/login_key_test.go`、`auth_e2e_test.go`;新增 `internal/store/account_lifecycle_test.go` 与真实 PG 跨进程用例(路径相对于 Backend)。
T7-1:两个独立进程同名开户,只有一个账户/激活 Key 成功,败者不改变胜者角色、密码和成员。
T7-2:开户、Key 签发、改密、会话处理、审计提交各故障点,最终只见完整旧态/新态;输出失败但提交未知时按 operation 查询。
T7-3:普通改密、临时重置、恢复设密后旧未用 Key 都不可兑换;长期集成 Key 按 R10 保留/撤销。
T7-4:读命令命中旧 schema、缺库、错 marker 均拒绝且不 DDL/建库;两个独立进程以不同 owner 并发首次引导单胜,另覆盖引导与普通开户竞争;有历史业务而无用户时拒绝。
T7-5:普通重启、两次更新、SIGTERM/SIGKILL 后测试账户原密码仍验证成功,账户权限及成员不变;不以摘要是否变化替代密码可用性。
执行环境:独立 SQLite 副本、真实 PostgreSQL 独立库、独立端口;不在当前 weichen 账户上故障注入。所有 T7 用例当前 NOT_RUN。
### U5/U8 近期接线与验证合同
U5 覆盖 R7/R8/R9/R13/R15,依赖 U7 对外字段合同;范围 `scripts/svc.sh`、`docs/svc.md`、Frontend `src/api.ts`、`src/auth.ts`、`src/components/LoginPage.tsx`、`src/App.tsx`。复用现有登录/设密页,类型明确消费 sessionScope、passwordSet、reloginRequired;恢复 Key 不写持久浏览器存储或 URL。
同一登录页保留默认账号密码入口,增加「激活/恢复 Key」入口并说明只用于设密;长期 API 密钥入口标清集成用途。错类型提示指向正确入口,切换清输入,更新初始密码旧说明,不新增独立恢复页面。
刷新/兑换响应不确定时先查询会话,有效受限会话恢复设密;会话不存在且 Key 已消费/过期时提示联系账户管理员重发,返回「激活/恢复 Key」入口。无密码账户不得被引导用旧密码登录。
测试参考 `tests/test_svc_user_binding.py`、Frontend `test/auth.test.ts`、`e2e/changepw-form.playwright.ts`;新增 Dev `tests/test_svc_user_help.py`、Frontend `e2e/login-key.playwright.ts`(计划文件)。
T5-1:完整/短/专题/实例帮助覆盖六个账户命令,并均无 DB/目录/服务副作用。
T5-2:旧产品和 RDM 不支持账户 CLI 时在执行前拒绝;stdout 单次交付,stderr/进程参数/history 无秘密;两类 Key 双向填错有正确引导且切换清输入。
T5-3:激活/恢复完成兑换→设密→重新密码登录;刷新/响应丢失先核会话;Key 已消费而会话失效时经管理员重发的新 Key 可以续办;过期、重复兑换、CSRF 错误有准确提示。
T5-4:受限会话无法访问业务/下载/SSE/admin/插件;设密成功后不得因直接 onDone 误放行。
U8 覆盖 R2/R14/R15,依赖 U7 审计;在 `user info`/账户事件查询(拟新增)展示实例、设密时间、凭据类型及状态。错误配置、注销、Key 失效与密码错误分别诊断,普通登录错误不泄漏他人账户信息。CLI/HTTP 两入口产生可追溯同一 operation 记录;历史无审计事件保持未知。
首批 dev 原账户闭环(NOT_RUN):实现及隔离验证通过后,另行确认运行验收窗口/实例/版本,由 owner 在浏览器输入已知密码,检查原 user ID、角色、成员及原数据访问。若确实不能登录,明确恢复授权后才签发恢复 Key,保持账户和业务归属;不能为验收先重置能用的密码。随后在授权窗口验证普通重启及两次受控更新后原账户仍可登录。密码不交给 Agent、不进入证据;本轮不操作 live。
### 必须覆盖的验收场景(摘要)
干净机器二进制安装;源码固定提交与子模块;两种部署互切后数据不变;构建/摘要/配置失败旧服务可用;PG 身份不符拒绝且不回落 SQLite;无密码开户且不覆盖既有;同 Key 并发兑换仅一次成功;受限会话拒业务/SSE/admin;消费后建会话失败与设密中途失败无半完成态;恢复前后业务与权限对账;SQLite 与真实 PG;治理回归;源码测试不代替浏览器与真机。
额外钉住:`release@v` 多版本不得装成更高版本;账户 CLI 不得回落默认 `./data`。
## 8. 一次性 Key 流程
```mermaid
flowchart LR
A["创建账户或签发恢复 Key"] --> B["输入一次性 Key"]
B --> C["后端原子消费"]
C --> D["仅允许设置密码的短期会话"]
D --> E["设置并确认新密码"]
E --> F["作废恢复凭据及相关旧会话"]
F --> G["使用新密码正常登录"]
```
凭据规则:独立前缀;只存摘要;用途 `activate`|`recover`;状态未使用/已消费/已撤销/已过期;密码变更后旧恢复凭据不可再用。符合 [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 与 [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html);保留现有 CSRF 校验。
## 9. 风险与未授权范围
- 实施、故障注入、真机部署、浏览器验收:**未授权 / NOT_RUN**。
- 本轮交付终点:r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录;以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准,不推进 Dev gitlink、不推送/建 PR;启动/同步工具的任务元数据提交单独记录。
- 与 recovery U1 重叠处只做增量,不重做已合入的 manifest 层。
## 10. 规划进展与下一步
- r1 已批准;U1/U4 基础实现存在于当前固定源码,完整浏览器/故障/运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
- 首选下一任务(待授权):恢复方案 U8 的 SQLite 服务隔离+本案 U7 账户一致性;先消除共享测试数据和不可归因密码变化,再落实 U5。U2/U3 保持后续。
- 前置:审核新增 R13–R15、U7/U8 及 U5 更新,明确实现和隔离测试范围/owner;实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区;正式组合、gitlink 推进与运行验收未执行。
+11 -2
View File
@@ -6,7 +6,10 @@
## 先看哪一份
已批准:[Generative UI U5 动作范围提案 r2](2026-10-11-generative-ui-u5-action-scope.md)(2026-10-11 用户裁定三点同意;实施自 feature/generative-ui-u5 启动)。
Generative UI 方向已收口(U1–U7 全部落地,2026-10-12):[使用说明与评测记录](2026-10-12-generative-ui-usage-and-evaluation.md)(final);
主记录 [r2](2026-10-10-generative-ui-plugin.md) 与 [U5 动作范围 r2](2026-10-11-generative-ui-u5-action-scope.md) 保留为过程权威。
U5 已实施合入(动作闭环,Dev #367);[U5 动作范围提案 r2](2026-10-11-generative-ui-u5-action-scope.md) 为已批准范围。U6 经用户 2026-10-11 裁定:待 owner 实际体验 U1–U5 产物(人类可用性对照的执行方式)后再定启动。
r2 U5 条款要求先评审动作范围;本文给出 A/B/C/D 分类、审批挂接(复用既有 DangerHigh 确认卡与
幂等)、排除项与验收线,待三点裁定后 U5 实施另行开任务。
@@ -163,9 +166,15 @@ RDM 总案把库分期作为支撑与依赖,不覆盖库分期的原始范围
后续维护:主案或任务变化时先更新其唯一主记录,再更新这里的导航和核验快照。
更换 Docs/Dev 基线后重新核对 PR、版本与在途任务;新的索引状态不自动产生实施授权。
## 2026-10-12 规划补充
- [svc 统一部署与一次性登录 Key 方案 r1](2026-10-12-svc-unified-deploy-and-login-key.md):将 `svc.sh` 增强为二进制/源码统一部署入口,并补齐无初始密码开户与账户恢复;一次性登录 Key 只能兑换设密受限会话。r1 含源码复核与四项取舍定案;复用恢复方案 KTD 与已合入的 recovery U1(Dev #415)。**2026-10-12 已批准**(五阶段+U1/U4 规格);授权推送/PR 与 U1/U4 实施启动;合入由 owner 执行。规格见 Dev `docs/svc-deploy/`。
- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md):2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据;覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审,r2 吸收外部源码复核(见同名 review 记录两轮)。**2026-10-12 用户批准 r2(五阶段一并)**;实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7;U2 首切片已由 svc-autorecover 任务合入 main(PR #396/#401,2026-10-11);U1 实例身份已合入(Dev #415,2026-10-12),余量按 KTD 对齐后续增量。
## 2026-10-11 规划补充
- [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md):对应 P3/MS3,源码已有部分实现;优先补项目绑定、创建者/管理员读取隔离与历史完整性,再接统一展示。用户确认范围为 RDM 与必要基座能力;r1 已获用户评审通过(2026-10-11,五阶段一并,含 KTD4 双层管理员裁定)。U1、U2、U3 已实施合入(RDM PR #195、#197、#201,2026-10-11;超管槽待基座能力接线,见 RDM 仓 U1 基座扩展申请);U4–U5 与运行验收未启动。
- [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md):对应 P3/MS3,源码已有部分实现;优先补项目绑定、创建者/管理员读取隔离与历史完整性,再接统一展示。用户确认范围为 RDM 与必要基座能力;r1 已获用户评审通过(2026-10-11,五阶段一并,含 KTD4 双层管理员裁定)。U1–U5 全部实施合入(RDM PR #195/#197/#201/#213;Dev PR #368,2026-10-11;超管槽待基座能力接线,见 RDM 仓 U1 基座扩展申请)。U6 团队存储独立后续;运行验收属部署环境。
- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md):69 类旧资产、4 个当前注册模板的盘点及生成闭环设计;待评审,实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认(2026-10-11),其余方案与实施仍待评审。
@@ -0,0 +1,11 @@
# 经验:库级 Manager 测试通过 ≠ 跨实例 HTTP 路径正确——进程级黑盒才能抓住短路
- 状态:validated(三条缺陷均在 U7 双进程验收中复现、修复并入 CI 回归)
- 触发条件/检索词:多实例 / 跨实例 HITL / cancel / 命令总线 / Manager 层单测 / HTTP 黑盒 / 假成功 200 / conversation_id 空 / 落卡短路命令 / U5 vs U7
- 根因与来源:协作存储 U5 用真库直接调 `runmgr.Manager` 覆盖争抢/围栏/命令语义,**绕过 HTTP handler**。U7 `tests/integration/multi-instance/` 起两个真实 `serve` 进程共享 PG 后抓出三条生产路径缺陷(均已有 backend 回归):① HITL resolve 在非执行实例先把卡标 resolved,命令 fallback 的 `!card.Resolved` 判定被跳过,执行者永远等不到答案;② 跨实例 cancel 命令 `conversation_id` 传空串,消费侧执行权 JOIN 永不命中;③ `CancelRun` 在非执行实例无句柄时返回 nil,HTTP 层 200「假成功」吞掉命令路径。库级绿与进程级红可以同时为真。
- 下次应做的检查:凡涉及「任意 API 实例发起、执行实例消费」的能力(取消、HITL、命令、租约接管),验收矩阵须含 **至少一条双进程 HTTP/SSE 黑盒**(或等价:经真实 handler + 命令总线落库再消费),不能只用 Manager/Store 直调冒充跨实例已过。写回归时优先钉住「非执行实例的 HTTP 状态码与执行者观测到的最终状态」成对断言。
- 验证方法与防护:已落实——Dev `make test-multi-instance`(CI `test-pg` 必跑)覆盖跨实例读/SSE/409/HITL/取消/崩溃恢复/重启不变量;三条缺陷各有 backend 回归测试。建议保持:新增跨实例命令路径时先加进程级场景再声称 U5/U7 完成。
- 适用与不适用:适用多实例共享权威存储、命令经 DB/总线投递的架构;不适用纯单实例本地句柄路径,也不替代库级语义单测(二者互补)。
- 尚缺证据/防护:双主机(跨机网络)C3 与正式容量窗口不在本教训范围内;本条只固定「测试层级」缺口。
- 复核人、日期、版本:weichen,2026-10-12;依据 Dev 放行检查单 A6/C1 与 `tests/integration/multi-instance/README.md`「已实测发现并修复的缺陷」
- 替代/退役条件:若跨实例命令路径全部强制经同一 HTTP→命令总线集成测试门禁,且历史三条回归仍绿,可将本条降为参考;不得在无门禁时退役。
@@ -0,0 +1,64 @@
# 服务重启与全量数据恢复方案 r1 文档审阅
日期:2026-10-12(Asia/Shanghai)。对象:[主方案](../proposals/2026-10-12-service-restart-data-recovery.md)。
方法:ce-doc-review,non-interactive;六个独立上下文的原生子代理加作者源码复核。以下为审阅意见及处置摘要;来源为SELF,不是人工批准、业务验收、REPLAY或GATE。没有外部跨供应商模型评审;未跑业务测试或故障试验。
| 角色 | 原始发现数 | 处置 |
|---|---|---|
| coherence | 1 | 修正灾难恢复的分档RPO验收 |
| feasibility | 1 | 与design同一问题合并,修正动作与整run的结算边界 |
| security-lens | 1 | 加入新目标恢复前的旧写路径隔离门禁 |
| design-lens | 1 | 与feasibility同一问题合并,复用原状态/卡片展示 |
| scope-guardian | 0 | 无需扩大或缩小当前目标范围 |
| adversarial | 1 | 收紧非幂等动作的确定未执行证据 |
共5条原始发现、4项独立修正;全部已纳入候选r1,不涉及用户需求的取舍变化。人工评审仍未发生。
## 审阅意见与处置依据
1. **分档验收不一致。** 初稿目标允许灾难档RPO≤5分钟,U7却无条件要求“零已确认数据遗漏”。后果是按目标建设的备份也无法按U7签收。按已声明的故障分档,R3/U7/故障矩阵明确RPO=0档零遗漏,灾难档恢复点差距在批准范围内、点内完整并报告点后缺失。没有暗改用户的零丢失合同,所有量化指标仍待人工批准。
2. **一个外部动作完成不等于整任务完成。** 初稿状态图直接 `hold→completed`,可能跳过必要后续步骤。作者复核Native `runtime/loop.go:385–402`确认工具结果持久化后还继续模型回合;因此与design/feasibility意见一致。现改为记录operation receipt后回recovering,继续剩余步骤,只有全部必要步骤及业务结果完成才结算整run。
3. **独立恢复库不能围栏旧库的执行者。** 初稿对新目标恢复已有数据、权限和组合对账,但未明确切生产前如何阻断原权威复活。旧、新库各有有效epoch时,单库租约不能避免双执行。现加入默认隔离验证模式、旧执行者/已发请求写路径隔离、新恢复权威代次、专用资源权限边界及无法证明时hold;同时对账恢复点后的外部效果。验收增加旧实例复活和恢复点后已执行动作。
4. **暂未查到结果不足以安全重试。** 初稿“查询确认未执行”可能被理解为目标当前无结果;旧请求稍后完成则重复副作用。现要求确定未执行的终态及旧执行者/已发请求不会再生效的证明;普通查询空结果、发送取消或本地退出均不充分。补外部请求延迟完成而恢复者不得发第二次请求的故障场景。
作者另核实并修正一处事实表述:Native已有tool intent/result与safe replay机制,Backend生产Session已接线;本案复用该基础,将其与run/epoch/hold关联、指定统一恢复裁决,而不是重建第二套彼此独立的恢复政策。证据命令原始输出由Dev任务卡make evidence保存。
## 最终对象与检查
主方案SHA256:`cfc9b768a4596a268810e20101cddc2a6040e24a640e6e34dbda17b838cd45ed`。
固定源码对象:Dev `5e57029b439e5690f28dc6002f9784f0b08920eb`,Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`;任务分支中的后续提交只记录启动/同步元数据,业务源码未改变。
任务卡保留precheck、task-sync、源码调查、Native接线核对以及最终文档检查的工具收据。检查范围为差异空白、相对链接、需求/增量/决策ID、证据完整性;通过仅证明对应文档检查,不证明服务或数据恢复。
草稿、入口和子仓改动尚未提交为固定组合;`check-evidence.py`对含未提交非任务卡改动的收据报告`unverified`。原始输出及方案内容摘要已保存,这些记录仅作为本地调查辅助,不能用于正式合入/运行验收。后续正式审核应先固定候选组合、同步并由有权审阅者重放对应检查,不能靠反复执行或更换来源标签消除此限制。
实施前仍需人工确认故障档/RPO/RTO、目标实例与独占管理权、数据归属清单和在途任务分工。按policy/delivery.md,此次审阅与候选修正不能代替任何阶段的人工批准。
## 第二轮:外部源码复核(2026-10-11)
复核者:ZCode 独立上下文;对象:r1(SHA256 `cfc9b768…`)。方法:对主案第2节差距表、基线与自审记录引用的源码断言逐项独立重验;未运行服务、测试或故障试验。来源SELF。
核验结果(抽查全部命中):五个基线SHA与任务工作区一致且Dev基线为HEAD祖先;`svc.sh:1373` resolve_db_config统一解析;runmgr `ReconcileInterrupted`(≈2046)统一封印中断;`SetRecoveryHold`与`RenewExecution`均仅有定义、无生产调用;`claimCommand` pending→consumed后执行(kill窗口无重领);app.go HTTP停机超时(现状5秒)即返回并跳过`mgr.Shutdown`事件清冲;`ListSurfaceEventsPending`默认limit=100;notice启动载入内存队列、投递后独立DELETE非事务;native `loop.go:385–402`工具结果持久化后继续模型回合。
修订处置(r1→r2,需求与指标未变):
1. U3补停机预算来源变更:现状5秒须显式替换为批准预算并实测校准。
2. U1验收补“更换二进制路径/程序版本、不同cwd调用svc后身份一致”场景(对齐R2)。
3. U4补“新增公开状态前先交付Core→Backend→Frontend→下游最小状态映射表”。
4. 第9节svc-autorecover协调改为明确的人工二选一归属决策项(实施载体 vs 放弃合并,两权威不得并存)。
流程修订:r1先按被审对象原样提交固定(documents `54fc24e`、Dev `39f719f`),r2为后续修订提交;恢复会话按门禁完成precheck(READY,R0 `555fb2162f`)并task-sync后实施修订。r2 SHA256:`9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd`。
遗留(人工事项):svc-autorecover归属二选一、首批实施范围、故障档/RPO/RTO与停机预算批准;全部指标维持待批准未实测。
### 追加(2026-10-11 task-sync 后):漂移检查与 svc-autorecover 实况
- task-sync 将 backend 指针由 eb12f102 前移至 25fbea85(collab-storage U5-outbox #157 合入)。漂移检查(工具收据见任务卡证据表)确认 r2 引用的差距在新指针全部成立:RenewExecution 与 SetRecoveryHold 仍无生产调用、claimCommand 仍为认领即 consumed、HTTP 停机超时仍跳过事件清冲、Surface 待投影默认仍 100 条。该合入新增 `EnqueueCommandInTx`(与业务提交同事务投递命令)与 `AppendEvents` 内同事务 `pg_notify`,属 KTD10 可直接复用的原语,不改变差距结论。
- svc-autorecover 实况修正归属决策的信息基础:其工作区并非空壳,含未提交的 autostart 期望态 + `svc.sh recover`(postgres 先于应用)+ systemd 用户级 watchdog(每分钟拉回)+ `.start.lock` 生命周期锁 + pidfile/cmdline 校验(svc.sh +317 行、docs/svc.md +61 行、Makefile +10 行)及回归测试 tests/test_svc_recover.py;但任务卡零登记(无 precheck 收据、无卡内记录、无提交),且 2026-10-11 观察其自测 10 例中 5 例未过(failures=2、errors=3)——定位是“有价值的半成品”,不是可合入实现。选项 (a)(作 U2 实施载体)价值因此上调,但需先补登记(precheck/任务卡/提交)、修复未过用例,并与本案 manifest 合同(KTD1/KTD2)对齐;选项 (b) 则须显式处置这批在途工作而非视同空白。裁定仍属人工。
## 批准记录(2026-10-12)
用户(weichen)批准方案 r2(拆解/评估/需求表/方案设计/实施计划五阶段一并),并裁定 svc-autorecover 归属选项 (a):作 U2 实施载体,先补登记、修复未过用例、对齐 KTD1/KTD2。实施按第 7 节 U1–U7 与批次 A/B/C 推进;量化指标(RPO/RTO/停机预算)在对应增量验收前固定。来源:用户对话(本记录为 SELF 转述);阶段评审明细见 Dev 任务卡。方案 r2 正文未因批准改动(SHA256 9cfda252… 不变),批准状态以本记录、任务卡与 INDEX 为准。
### 落地追踪(2026-10-12 补记)
裁定后核实:svc-autorecover 在途工作已由另一会话完成并合入 main——PR #396(autostart 期望态 + recover + watchdog)、#400(任务卡回填)、#401(KillMode=process 修复)、#402(闭卡归档)。归档卡验证摘要:tests/test_svc_recover.py 10/10、make test-governance 146/146(SELF)、CI GATE 绿(PR HEAD e0b49d1,test+test-pg,一次抖动重跑);如实登记的残留:postgres 实例真实 recover 仅代码审查未实测、agent SQLite 数据目录尚无自动备份。裁定 (a) 的“补登记、修复未过用例”已被事实完成;其对齐要求(KTD1/KTD2 manifest 合同、服务组依赖与单一监管者)转为 U2 余量增量。本记录早前“373 行未登记半成品”的表述为当时(2026-10-11)观察,已被后续事件取代。
@@ -0,0 +1,55 @@
# U7 容量测量窗口报告(SELF,2026-10-12)
来源标注:**SELF**(本机隔离栈执行;非 CI GATE、非独立 REPLAY)。不得单独据此放行第二实例写流量或双主机部署。
## 1. 环境与被测对象
| 项 | 值 |
|---|---|
| 主机 | Linux,32 逻辑 CPU,122 GiB RAM(约 98 GiB available),磁盘 1.9T/余 1.1T |
| k6 | v2.3.0(Homebrew 固定位 `/home/linuxbrew/.linuxbrew/bin/k6`) |
| 拓扑 | 双 `serve` 进程共享隔离 PG(`u7load`),`--tier team --auth on --mock --disable-exec-tools` |
| Dev HEAD(任务分支测量时) | `b6f78b503ee2e3d6f71663d5330a18adbe743239`(ladder/s60 证据点;s2h 同工作区续跑) |
| Backend gitlink | `5e8ada727c358438f8ff9f94eabb697e99fe28dc` |
| Documents gitlink(测量时) | `8d0810bd35f4934e0ad37fb96d7bab6d7a732473` |
| 入口 | Dev `tests/load/collaboration/run_load.sh --seed contract --instances 2` |
## 2. 数据集(B5 contract)
每段窗口独立灌库(编排脚本每次 `DROP/CREATE u7load_app`,无法跨次复用):
| profile | results 目录 | messages | knowledge | seed 耗时 |
|---|---|---|---|---|
| ladder | `tests/load/collaboration/results/20261012-064730/` | 1 000 000 | 100 000 | ≈12.0 s |
| sustained60m | `…/20261012-070510/` | 1 000 000 | 100 000 | ≈14.5 s |
| sustained2h | `…/20261012-081025/` | 1 000 000 | 100 000 | ≈11.2 s |
拓扑:10 seed 用户 × 5 项目 × 10 会话;约 10% knowledge `owner=''`(共享基座);**未**写入 `knowledge_vectors`。
## 3. 负载结果(阈值:读 P95≤300ms、P99≤1s、失败率≤0.1%;SSE P95≤1s;dup_seq=0)
| profile | 读 P95 | 读 P99 | fail_rate | checks | expected_contention | SSE A p95 | SSE B p95 | dup_seq | orphan runs |
|---|---|---|---|---|---|---|---|---|---|
| ladder(10→30→100,~12m) | 15.5 ms | 44.3 ms | 0 | 134922/0 | 549 | 17.5 ms | 33.0 ms | 0 | 0 |
| sustained60m(~60m @30 VU) | 3.9 ms | 6.5 ms | 0 | 504399/0 | 69 | 5.7 ms | 4.4 ms | 0 | 0 |
| sustained2h(~2h @30 VU) | 6.2 ms | 13.5 ms | 0 | 1008771/0 | 477 | 3.9 ms | 4.2 ms | 0 | 0 |
命令(每段):
```bash
tests/load/collaboration/run_load.sh --seed contract --profile <ladder|sustained60m|sustained2h> --instances 2
```
原始产物(gitignore,留在任务 worktree `results/<ts>/`):`k6-summary.json`、`sse-probe-a.json` / `-b.json`、`seed-manifest.json`、`invariants.txt`。任务卡经 `make evidence` 写入阈值复核脚本输出(SELF)。
## 4. 结论与边界
- **容量合同(B2/B3/B5/B4/C2)本机 SELF 全过**:阈值与不变量满足建议合同;数字绑定上表 SHA 与 results 目录。
- **仍不放行第二实例写**:检查单要求 CI GATE 或独立 REPLAY 才用于放行;本报告仅为 SELF。C3 双主机、C4/C5 运维演练、B6 pgbench 未做。
- **不承诺跨机/生产容量**:mock 模型、同机双进程、NVMe/本机 PG;换硬件或真实模型须重测。
## 5. 建议下一步
1. 独立审阅者 REPLAY 最小集(至少 `ladder --seed contract --instances 2`)后,方可讨论双进程写放行。
2. 用户指定第二主机后跑 C3。
3. 排期 C4/C5 运维演练;可选 B6 pgbench 只读基线。