Compare commits

...
Author SHA1 Message Date
weichen a73c84b5be Add RDM settings, members, duties and permissions increment plan r1
Why: 固化 2026-10-13 评审通过的 RDM 完善增量方案(承接总案 U3/U4/U6,衔接 U5),含三处技术评审补充与顺序裁定。
Evidence: 方案核查记录见提案文末;源码锚点 Backend settings.go / RDM perms.go, plugin.go / Frontend adminRdmSections.tsx。
Impact: 仅新增提案文档与索引条目,无代码变更。
Refs: 2026-10-12-rdm-function-implementation-plan.md
2026-10-13 03:22:46 +00:00
weichen 05c13a42b1 Merge pull request 'Record the K4 artifact retest in the collaboration plan' (#92) from fix/u7-k4-artifact-upload into main
Why: the retest changed the K4 SELF result, and the plan has to record that without opening write traffic.
Evidence: SELF drill backup-20261013-013354, K1-K7 true. Documents has no CI workflow.
Impact: proposal r2.3. Second-instance writes stay closed.
Refs: #92
2026-10-13 01:53:03 +00:00
weichenandCursor 53354996f2 Record the K4 artifact retest in the collaboration plan
Why: the 2026-10-12 drill left artifact recovery failed, and the retest changed that SELF result without changing the write-traffic gate.
Evidence: backup-20261013-013354 on Dev a83588dd and backend 46073d30; K1-K7 true, RPO 65s, RTO 3s, five artifacts matched and cross-user access returned 404. SELF.
Impact: proposal moves to r2.3. Second-instance writes stay closed until REPLAY or CI and the second host exist.
Refs: docs/records/2026-10-12-u7-ops-drill-report.md docs/proposals/2026-10-11-collaboration-storage-and-distribution.md
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-13 01:44:03 +00:00
weichen cf74a200e8 Record the corrected workbench candidate and single delivery record
Why: Keep planning progress aligned with actual implemented corrections without duplicating CI and merge state.

Evidence: Reference UI155, Frontend210 and 19 local browser cases via Dev native receipts; final GATE remains separately tracked.

Impact: Planning metadata only; no deployment or model-routing claim.

Refs: work-companion-ui r0.2/r1, UI01-UI13
2026-10-12 19:07:32 +00:00
weichen f7ae1ecce6 Record workbench implementation evidence and remaining delivery gates
Why: Keep the approved design and implementation plan consistent with the current candidate.

Evidence: Reference actual SELF verification and pending independent Review and GATE, without copying command output.

Impact: Planning progress only; inherited live-model capabilities and deployment remain separate.

Refs: UI01-UI13, work-companion-ui U5
2026-10-12 16:59:30 +00:00
weichen b184bfb109 Merge current Documents main into the workbench design branch
Why: preserve concurrent planning records before the Dev combination sync.

Evidence: fetched authoritative Documents main f76cce9e32.

Impact: planning record integration without rewriting history.

Refs: work-companion-ui U5.
2026-10-12 16:32:44 +00:00
weichen f76cce9e32 Merge pull request 'Record the U7 ops drill and advance the storage plan to r2.2' (#90) from feature/u7-ops-drills into main
Merge pull request 'Record the U7 ops drill and advance the storage plan to r2.2' (#90) from feature/u7-ops-drills into main
2026-10-12 15:52:51 +00:00
weichenandCursor 95c2ec260c Record the U7 ops drill and advance the storage plan to r2.2
Why: B6, C4, and C5 now have same-host results, and the plan still said the ops drills were not done and that replay was the next step.
Evidence: Dev results pgbench-20261012-131948, fault-20261012-142734, and backup-20261012-153441 (SELF). The user declined a capacity replay on 2026-10-12.
Impact: Second-instance writes stay closed. K4 remains a product defect. Replay and C3 are not started.
Refs: feature/u7-ops-drills
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 15:49:44 +00:00
weichen 733f32c671 Merge pull request 'Record D1-D3 deploy remediation' (#88) from feature/recovery-d1-d3 into main
Why: the recovery plan needs the D1-D3 remediation record before the Dev pin moves.
Evidence: repository has no .gitea workflow; combined status has zero checks. Diff is one recovery-plan section.
Impact: documents only.
Refs: #88
2026-10-12 15:07:07 +00:00
weichen 8d8600024d Record the approved progressive workbench design and implementation plan
Why: implement a simple workbench for nontechnical users under continuous authorization.

Evidence: current source audit and the reviewed r0.1 prototype; runtime verification remains pending.

Impact: design and plan only; task execution state stays in the Dev task card.

Refs: UI01-UI13 and the existing fast-slow display design r1.1.
2026-10-12 15:03:27 +00:00
weichenandCursor cb7e25439a Record D1-D3 deploy remediation on the recovery plan
Why: the 2026-10-12 batch-update failure still had identity, rollback, and real-combo gaps after Dev #474, Backend #180, and RDM #276. The recovery plan is the single record for that work, and the rdmcand data-ownership check needed a written result before any restore.
Evidence: read-only queries on runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z and the matching domain backups. No business rows were moved.
Impact: adds r3.1 sections D1/D2/D3 and the ownership finding that dev conversations predate rdmcand's use of dev/data, so no cross-instance restore is indicated. r3's earlier unapproved text stays unapproved.
Refs: Dev feature/svc-d1-identity-flow; Backend feature/d1-identity-open
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 13:47:46 +00:00
weichen 3cc6438030 Merge pull request 'Revise svc account durability and recovery plans (r2/r3)' (#87) from feature/svc-account-durability-plan into main
Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/87
2026-10-12 12:18:24 +00:00
weichen 0952b50aef Merge pull request 'Add fast-slow channel display design r1.1 and U1 plan' (#84) from feature/fast-slow-display-design into main
Reviewed-on: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/84
2026-10-12 12:16:07 +00:00
weichen 9c31d3c308 Merge Documents main into account durability plan branch
Why: keep r2/r3 proposal updates rebase-friendly before PR.
Evidence: origin/main at fetch time.
Impact: Documents feature tip includes latest main.
Refs: feature/svc-account-durability-plan
2026-10-12 12:11:40 +00:00
weichen b8319d24f2 Merge pull request 'Record U7 capacity window SELF report and plan r2.1' (#86) from feature/u7-capacity-window-report into main 2026-10-12 12:07:26 +00:00
weichenandCursor dbdec82466 Record U7 capacity window SELF report and plan r2.1
Why: Capacity ladder/60m/2h dual-instance windows finished; planning
progress must reflect SELF-pass vs remaining GATE/REPLAY/C3 gaps.
Evidence: SELF load results summarized in the new capacity report.
Impact: Preferred next becomes independent REPLAY or C3/C4/C5.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 12:07:12 +00:00
weichen ebf655c4d7 Merge Documents main into fast-slow display design branch
Why: Dev #451 cannot pin modules/documents while feature tip and main diverge.
Evidence: merge-tree reports submodule conflict 1048e7c vs 9e4ee27.
Impact: Documents #84 tip includes main@1048e7c plus r1.1/U1 plan.
Refs: Dev PR #451; Documents PR #84
2026-10-12 12:07:02 +00:00
weichen fe8d08be21 Record the final baseline and isolated candidate data
Why: distinguish timed observations from current service ownership.

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

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

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

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

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

Refs: Dev feature/svc-account-durability-plan; account r2; recovery r3
2026-10-12 10:09:49 +00:00
weichen 1048e7c6af Merge pull request 'Propose RDM function implementation plan r1' (#85) from feature/rdm-function-plan-r1 into main 2026-10-12 09:29:03 +00:00
weichen a183e663de Propose RDM function implementation plan r1
Why: 2026-10-12 全系统核对产出的功能/实现矩阵与 U1-U9 整改方案需入仓评审;独立文件已过期于共享门禁解除。
Evidence: 报告含冻结源码/运行时快照与逐条需求索引;发布补记记录冻结后部署时序与 U2 已合入切片(RDM PR #251/#254/#256/#258)。
Impact: 仅新增 docs/proposals 一份方案与 README 入口;不改代码与既有文档。
Refs: RDM docs/requirements V2.2、Documents 2026-10-11-rdm-final-target-completion.md
2026-10-12 09:28:44 +00:00
weichen 9e4ee27c7e Mark fast-slow U1 plan approved for implementation
Why: User authorized stage-5 start; record plan status for executors.
Evidence: Chat authorization "开始"; no runtime tests.
Impact: Documents proposal status only.
Refs: 2026-10-12-fast-slow-channel-display-u1-plan.md
2026-10-12 07:39:03 +00:00
weichen 5b71525818 Merge Documents main into fast-slow display design branch 2026-10-12 07:33:22 +00:00
weichenandCursor f9d96dfc59 Add fast-slow display design r1.1 and U1 plan
Why: Record approved stage-4 design with R03 splits and U1 exit
whitelist, plus stage-5 U1 implementation plan for review.
Evidence: Document edits only; no runtime verification.
Impact: Documents proposals INDEX; no business code.
Refs: feature/fast-slow-display-design

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 07:31:46 +00:00
weichen 8d0810bd35 Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83) from feature/u7-capacity-wrap-progress into main
Merge pull request 'Update collab storage plan progress to r2 after U1-U7' (#83) from feature/u7-capacity-wrap-progress into main
2026-10-12 06:39:52 +00:00
weichenandCursor 2cec59016a Update collab storage plan progress to r2 after U1-U7
Why: Delivery requires writing planning progress back after U7
landed; the proposal still claimed U1+U2 start / NOT_RUN.
Evidence: SELF doc edit against archived U7 cards and release
checklist A1-A7/B1 facts.
Impact: Readers see code-done vs capacity-window-pending; adds
HTTP multi-instance vs Manager-test lesson.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md

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

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

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

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

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-12 03:19:03 +00:00
weichen b680142586 Merge pull request 'Add the Generative UI usage guide and U1-U6 evaluation record (final)' (#76) from feature/generative-ui-u7 into main 2026-10-12 02:47:50 +00:00
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
weichen aba1d6a3d6 Record the user approval of the U5 action scope
Why: The user ruled on the three questions (categories and ranges
approved as proposed; C-class limited to plugin KV plus task ledger;
confirm UX reuses the inline card); the proposal becomes the approved
scope and unblocks the U5 implementation task.

Evidence: Ruling collected via the session question panel on
2026-10-11; implementation task feature/generative-ui-u5 starts under
policy/delivery.md.

Impact: Documents-only (proposal r2 + index status).

Refs: r2 master record U5; Dev task feature/generative-ui-u5
EOF
)
2026-10-11 14:09:20 +00:00
weichen 72a098a783 Merge pull request 'Propose the U5 action scope for user review' (#70) from feature/generative-ui-u5-scope into main 2026-10-11 13:50:14 +00:00
weichen c7c5f94b64 Propose the U5 action scope for user review
Why: The r2 U5 clause requires a human review of the action scope
before implementation; this draft grounds the decision in the current
command inventory and existing safety machinery.

Evidence: Source facts cited inline (builtin command list with risk
levels, DangerHigh inline-confirm flow with pendingStore, audit
envelope) verified against backend main on 2026-10-11.

Impact: Documents-only (new proposal + index entry); no code changes.

Refs: 2026-10-10-generative-ui-plugin.md (r2 U5); Dev task
feature/generative-ui-u5-scope
2026-10-11 13:50:10 +00:00
weichen 74e41637e7 Merge pull request 'Record U3 progress in the two-trees master plan and index' (#69) from feature/rdm-u3-closeout into main 2026-10-11 13:40:15 +00:00
weichen a8f1096e78 Record U3 progress in the two-trees master plan and index
Why: U3 landed via RDM PR #201 (merge dbc41b6); the master record must reflect actual progress.

Evidence: SELF U3 closeout doc check exit 0 (receipt in Dev closeout task card).

Impact: proposal status line, U3 progress paragraph, INDEX row only.

Refs: RDM PR #201; Dev feature/rdm-u3-closeout
2026-10-11 13:40:12 +00:00
weichen eb36571653 Merge pull request 'Merge the template/final-target planning branch into the Documents main lineage' (#68) from feature/documents-reconcile-u2 into main 2026-10-11 13:10:50 +00:00
weichen 9cb09b967c Merge the template/final-target planning branch into main lineage
Why: Dev PR #340 pinned this Documents branch tip while it was never merged into Documents main (cross-repo pin discipline); this reconciliation unifies both planning lineages.

Evidence: merge-base 2a5f658; INDEX conflict resolved as union (U1+U2 progress row + two new plan entries).

Impact: docs only.

Refs: Dev #340
2026-10-11 13:10:38 +00:00
weichen 559af219d9 Merge pull request 'Record U2 progress in the two-trees master plan and index' (#67) from feature/rdm-u2-closeout into main 2026-10-11 11:23:07 +00:00
weichen 1673f3cea6 Record U2 progress in the two-trees master plan and index
Why: U2 landed via RDM PR #197 (merge fe8a75b); delivery policy requires the master record to reflect actual progress at task completion.

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

Impact: proposal status line, U2 progress paragraph, and INDEX row only.

Refs: RDM PR #197; Dev feature/rdm-u2-closeout
2026-10-11 11:22:59 +00:00
weichen 10b0dbe908 Merge the current Documents baseline and preserve both planning entries
Why: retain the newly merged RDM U1 progress alongside the final-target plan.

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

Impact: documentation merge only; business validation NOT_RUN.

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

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

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

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

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

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

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

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

Impact: planning metadata only; no business changes.

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

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

Impact: docs only.

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

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

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

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

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

Impact: docs only.

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

Evidence: fetched origin/main=336a90f0ade0ffe049879ca5159a61f0a3948708.

Impact: integrate upstream changes without rewriting task history.

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

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

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

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

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

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

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

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

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

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

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

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

Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md sections 5 (U1/U2), KTD1/KTD8/KTD12/KTD14.
2026-10-11 03:10:45 +00:00
32 changed files with 4946 additions and 10 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 工作包。
+198
View File
@@ -0,0 +1,198 @@
# 团队存储运行手册(协作存储 U1)
适用范围:[协作存储与分布式方案](../proposals/2026-10-11-collaboration-storage-and-distribution.md) U1/U2
(已批准,2026-10-11)落地后的 **team 部署档** 运维与验证。个人 `local` 档(SQLite)
用法不变,见 [usage](usage.md)。本文是 U1 的固定部署清单、配置合同、迁移映射、
容量合同、隔离测试方案与 KTD14 副本保护合同的单一事实源;实施状态以各任务卡为准。
## 1. 目标实例与固定部署清单
| 项 | 值 | 说明 |
|---|---|---|
| 部署形态 | svc.sh 管理的 `runtime/<name>` 实例 | 非容器;单机多实例按名隔离 |
| 当前团队候选 | `runtime/dev`(8788,SQLite)→ 目标切 team 档 PG | 切换窗口与回退按方案 §6,须另行授权 |
| 数据库(本机验证) | PostgreSQL 18.6 + pgvector 0.8.7(brew) | 本机验证用;正式实例待指定 |
| 数据库(CI 门禁) | Ubuntu 24.04 apt:postgresql 16 + postgresql-16-pgvector | 版本以 CI job 输出为准 |
| 缓存/限流 | Redis 8.10.2(本机);CI apt redis-server | 只存可重建状态(KTD10) |
| 应用制品 | `agent-system` 单二进制(make build) | 拷贝即运行;team 档需 `--tier team` |
未知项(正式实例主机、pgvector 正式启用版本、对象存储选型)在正式切换授权前
必须补齐;本清单不把本机验证环境当作正式部署事实。
## 2. team 档配置合同(U2 已实施)
启动语义(KTD1 fail-closed):
- `tier=team`:必须配置 `dsn` 且认证开启(`auth=on`;`auth=auto` 随 DSN 自动开);
任一缺失**拒绝启动**。PG 打开失败**拒绝就绪**,绝不回落 SQLite。未配置执行隔离
(`disableExecTools` 或 `execBackend`)时启动警告(多用户开放前必须补齐)。
- `tier=local`:SQLite;配置 `dsn` 是配置错误,拒绝启动。
- `tier` 缺省(auto):现状语义——`dsn` 非空走 PG,否则 SQLite。
配置键(四源合并:默认 → 文件 → 环境 → 显式 CLI,与 usage §启动一致):
| 键 | env | CLI | 语义(team 档) |
|---|---|---|---|
| `tier` | `AGENT_SYSTEM_TIER` | `--tier` | `local` / `team` / 空=auto |
| `dsn` | `AGENT_SYSTEM_DSN` | `--dsn` | PG 连接串;team 必填 |
| `auth` | `AGENT_SYSTEM_AUTH` | `--auth` | team 档要求最终为 on |
| `instance` | `AGENT_SYSTEM_INSTANCE` | `--instance` | 空=主机名:监听地址(多实例必须互异) |
| `pgMaxOpen` | `AGENT_SYSTEM_PG_MAX_OPEN` | `--pg-max-open` | 每进程最大连接(默认 16) |
| `pgMaxIdle` | `AGENT_SYSTEM_PG_MAX_IDLE` | `--pg-max-idle` | 每进程空闲连接(默认 8) |
| `pgConnMaxIdleSec` | `AGENT_SYSTEM_PG_CONN_MAX_IDLE_SEC` | `--pg-conn-max-idle-sec` | 空闲回收(默认 300s) |
| `pgConnMaxLifetimeSec` | `AGENT_SYSTEM_PG_CONN_MAX_LIFETIME_SEC` | `--pg-conn-max-lifetime-sec` | 连接寿命(默认不限) |
| `pgQueryTimeoutSec` | `AGENT_SYSTEM_PG_QUERY_TIMEOUT_SEC` | `--pg-query-timeout-sec` | statement_timeout 秒(默认不限) |
连接预算(KTD12):预算覆盖全部 API/Worker/LISTEN/migrator/监控连接;
100 在线用户 ≠ 100 连接。`agent-system config explain` 输出脱敏有效值
(DSN 密码打码)。启动日志打印 `storage tier: team (dialect=postgres pool=… schema=v…)`。
迁移(KTD8,U2 已实施):DDL 与版本登记同事务(中途失败整体回滚,不存在
「表已建、账本未记」中间态);PG 并发迁移者按会话咨询锁串行化;SQLite 写事务
`_txlock=immediate` 跨进程排队。库内出现比二进制新的 schema 版本时拒绝启动。
## 3. 迁移映射(SQLite → PG,U4 工具消费)
| SQLite 侧 | PG 侧 | 备注 |
|---|---|---|
| `agent-system.db`(WAL) | 同名逻辑库 | 活跃 WAL 不能只拷 `.db`;一致性备份用 VACUUM INTO |
| INTEGER 0/1 布尔列 | BOOLEAN | v9/v10/v11 起双方言已分型 |
| `INTEGER PRIMARY KEY AUTOINCREMENT` | `BIGSERIAL`/`SERIAL` | events、command_audit、audit_events |
| FTS5 虚表 + 触发器 | tsvector 生成列 + pg_trgm GIN | v4;中文子串走 trigram |
| `vec BLOB` | `BYTEA` | pgvector 类型切换在 U6,不在本映射 |
| `<data>/artifacts/` 工件对象 | 本期仍本地目录 + PG 清单 | 共享对象存储在 U5/U9 |
RDM 独立业务库与旧 Agent-System 治理库**不在**本映射内;迁移工具(U4)只处理
Backend 库,非空目标拒绝、同快照才可续传。
## 4. 容量合同(验收目标,非性能结论)
方案 §3 的量化指标(100 在线 / 300 SSE / 20 执行中 Agent / P95≤300ms 等)是
**待验证合同**。区分两个计数:**接纳的 run 数**(进入队列)与**执行许可**
(同时真正执行,含子代理、初始全局 20、每用户 2、索引 4);等待子代理/HITL 的
父 run 让出执行许可、保留会话所有权。压测在 U7 执行并绑定组件 SHA 出证。
## 5. 隔离测试库/目录/端口方案
| 资源 | 约定 | 生命周期 |
|---|---|---|
| 本机 PG 实例 | `scripts/svc.sh db create collabtest --port 8897 --tag test` | svc.sh 管理;用毕 `svc.sh collabtest stop` + `rm --purge` |
| 测试库/扩展 | 库 `agent_test`;`pg_trgm` 预装 public | 测试辅助幂等预装;CI 启动步显式预装 |
| 用例 schema | `t_*` / `pgbus_*` 前缀,随机名 | 每用例建、Cleanup 级联删 |
| 本机 Redis | `redis-server --port 6399 --save '' --appendonly no` | 纯内存、用毕即停 |
| CI | job `test-pg`:apt 安装 PG16+pgvector+Redis,端口 5432/6399 | 每次 PR 必跑;缺服务失败不跳过 |
本地跑真实库门禁:
```bash
export AGENT_PG_TEST_DSN="$(scripts/svc.sh db dsn collabtest --db agent_test --reveal | tail -1)"
export AGENT_REDIS_TEST_ADDR=127.0.0.1:6399
make test-backend-pg
```
禁止对共享/现役实例(如 `runtime/dev` 的库)跑测试;DSN 不入命令历史与任务卡。
## 6. KTD14 副本保护与保留合同
- 备份/导出/WAL/测试副本使用专用数据库角色(非应用角色),存放于受限目录
(0700,非工作区);传输与静态备份加密,解密材料存独立受管秘密存储。
- 保留期限:迁移演练副本用毕即删,最长 7 天;正式备份保留 30 天滚动 +
每月 1 份年度副本(待正式实例指定后确认)。
- 日志/报告只留统计与哈希:不落 DSN、密钥、文档正文;测试一律用脱敏数据。
- 恢复演练:每次演练恢复到新目标并核对应用可用与权限/文件完整性;
「备份命令成功」不等于可恢复。
- 阻塞项:正式导出前,未知 owner 的数据、未定位的权威文件、缺失的保留期限
任一存在即阻塞(不静默继续)。
## 7. 暂态 Worker 文件分类
| 类 | 内容 | 处置 |
|---|---|---|
| 可重建 | 构建产物 `bin/`、`node_modules/`、测试数据目录、`__pycache__` | 随时删除重建 |
| 必须迁移 | SQLite 库、`artifacts/` 工件、`.agentx/checkpoints.jsonl`、Squad FileStore/续跑标记 | U4 迁移 + 联合备份;U5 前禁止跨机接管 |
| 只读参考 | svc.env(600)、history.jsonl | 保留在实例目录,不入副本外流 |
## 8. 已知边界(诚实清单)
- CLI 子命令(apikey/user 等)不校验 tier;team 档语义只在 `serve` 入口强制。
- 迁移仍随启动执行(已原子 + 锁化);完全独立的 migrator 入口留待 U4 工具。
- 多实例安全**未**因此声明(R4/U5);本档只交付单实例 team 档与真库门禁。
- pgvector 扩展已安装 ≠ 启用;向量检索仍是应用内扫描(U6)。
## 9. 执行预算与动作授权(U3 切片 2 已实施)
### 执行许可(admission,R8)
- 设置键:`runtime.execBudgetGlobal`(全局并发执行上限,含子代理;0=不限,
默认)、`runtime.execBudgetPerUser`(每租户上限;0=不限)、
`runtime.execQueueMax`(待执行队列上限,默认 200)。数值为容量合同初值,
U7 压测后调整。
- 语义:会话回合与子代理同池计数;账本在数据库(`admission_leases`,PG 咨询
锁下原子清点),多实例天然共享;队列满时 API 在落库前 429(不写数据);
父 run 同步等待子代理或等待 HITL 时让出执行许可、保留会话所有权,恢复
执行重新获取——额度占尽时父子不互等。
- 接纳与执行分别计数:队列深度(接纳)与活跃租约(执行)是两个量,
诊断分别看 `Manager.QueueDepth()` 与 `store.ActiveExecutionSlots()`。
### KTD13 动作授权矩阵与公开契约兼容计划
矩阵(宿主侧 `server.ProjectAction`):
| 动作 | 语义 | 未注册 action-aware 时 |
|---|---|---|
| read | 读取项目资源(会话/消息/检索/下载) | 回落旧 EXT-8 只读适配器(兼容现网) |
| edit | 写入与修改 | **默认拒绝** |
| approve | 审批(HITL/命令确认) | **默认拒绝** |
| execute | 触发执行 | **默认拒绝** |
| admin | 管理 | **默认拒绝** |
规则:action-aware 适配器(组合根注入 `SetProjectActionAuthorizer`)注册后
对全部动作权威、出错 fail-closed;旧只读适配器不得自动获得写入能力。
**公开契约兼容计划**(后续版本落地):以版本化扩展把动作级判定并入
EXT-8 的 `ProjectAuthz` 公开契约(新增 action 参数的变体接口 + 契约版本号),
下游适配器按动作逐一声明能力;未声明动作保持默认拒绝,与宿主侧矩阵同语义。
旧 bool 契约在该版本内继续可用(映射为仅 read);Core/Host 与下游适配器
(RDM 的 ProjectAuthz 实现)一起验收,不另建成员权威。
## 10. SQLite → PostgreSQL 切换与恢复演练(U4 已实施)
工具:`make build` 产出 `bin/storage-migrate`(受管迁移入口;只处理 Backend 库,
不执行 SQLite dump 作为 PG SQL)。三个子命令:
```bash
# 1) 只读盘点:schema 版本、完整性、逐表计数、工件清单与哈希(§6.1)
storage-migrate inventory --source runtime/dev/data/agent-system.db \
--artifacts runtime/dev/data/artifacts --out inv.json
# 2) 一致性快照:VACUUM INTO(在线安全含 WAL)+ 可打开校验 + 逐表计数对账(§6.2)
storage-migrate backup --source runtime/dev/data/agent-system.db --out snap.db
# 3) 受管迁移:目标建 schema/扩展后按行复制;身份登记 + 逐表校验和 + 终验(§6.3)
storage-migrate migrate --source snap.db --target "$DSN" \
--migration-id <名> --artifacts runtime/dev/data/artifacts --out report.json
```
迁移身份与续传:`migration_id + source_snapshot_id(快照 SHA-256)+
source_schema_version` 登记在目标 `migration_control`;**仅同一冻结快照可续传**
(换快照/换身份均拒绝);目标业务表已有数据而身份为空即拒绝(不覆盖)。
校验与报告:逐表源/目标计数与主键序哈希链校验和(布尔列按目标 schema 对称
归一);复制后推进 SERIAL 序列;未知 owner(users 之外,''/'local' 单租户默认
除外)阻塞迁移;报告只含计数/校验和/清单哈希——无 DSN、密钥与行正文(KTD14)。
类型映射以目标 schema 为准(SQLite 0/1→BOOLEAN、BLOB→BYTEA、生成列不迁、
FTS5 影子表不迁——PG 侧生成列与索引自动重建);`admission_leases` 为运行态
不随迁。
### 切换顺序(正式窗口须另行授权;当前仅隔离演练已验证)
1. 固定源制品与路径,`inventory` 盘点;指定迁移 owner、窗口、回退判据。
2. `backup` 冻结快照(活跃 WAL 库不得只拷 `.db` 文件)。
3. 预演:独立测试目标 PG 上 `migrate`,核对报告全绿;预演库不作为正式目标。
4. 正式窗口:停新写 → 等待/收口在途 run(未知副作用记 recovery hold)→
停旧写者 → 终快照 → 空正式目标 `migrate` → 报告全绿。
5. 单入口切 team 档冒烟(登录/项目/会话/审批/检索/下载);fail-closed 不回 SQLite。
6. **PG 接受新写入前**可撤回;**之后**禁直切回旧 SQLite(向前修复或专项回迁)。
备份基线(正式目标启用后):pg_dump 逻辑备份 + pg_basebackup 物理基础备份与
WAL 归档/PITR;pg_dump 不能作 WAL 回放基础。每次演练恢复到新目标并核对。
+2 -1
View File
@@ -36,7 +36,7 @@ agent-system config explain [--config envs/prod.json] # 只读诊断:逐字
agent-system version
```
启动参数四源合并,优先级从低到高:**内置默认 → 配置文件(`--config`,显式 JSON,无自动发现)→ 环境变量(`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`)→ 命令行**;未显式传入的命令行参数不参与覆盖,删除 override 恢复继承。字段:`addr`(监听)、`data`(工作区根目录)、`plugins`、`dsn`(空 = 嵌入式 SQLite 档,非空 = PostgreSQL 档)、`artifacts`、`auth`(auto/on/off)、`mock`;未知键与类型错误在启动时定位报错,不静默失效。
启动参数四源合并,优先级从低到高:**内置默认 → 配置文件(`--config`,显式 JSON,无自动发现)→ 环境变量(`AGENT_SYSTEM_ADDR/DATA/PLUGINS/DSN/ARTIFACTS/AUTH/MOCK`)→ 命令行**;未显式传入的命令行参数不参与覆盖,删除 override 恢复继承。字段:`addr`(监听)、`data`(工作区根目录)、`plugins`、`dsn`(空 = 嵌入式 SQLite 档,非空 = PostgreSQL 档)、`artifacts`、`auth`(auto/on/off)、`mock`;未知键与类型错误在启动时定位报错,不静默失效。team 部署档(`tier`/连接预算键)与真实数据库门禁见[团队存储运行手册](team-storage.md)。
**多环境启动**——仓库自带隔离示例 `envs/{dev,test,prod}.json`(data 根与 DB 互不重叠):
@@ -44,6 +44,7 @@ agent-system version
agent-system serve --config envs/dev.json # mock 开、./data-dev
agent-system serve --config envs/test.json # 127.0.0.1:8788、./data-test
agent-system serve --config envs/prod.json # PostgreSQL 档、auth on、独立卷
agent-system serve --tier team --dsn "$DSN" --auth on # team 档:缺 DSN/未认证拒绝启动,PG 故障拒绝就绪(见团队存储手册)
AGENT_SYSTEM_CONFIG=/etc/agent-system.json agent-system serve # 环境变量定位文件
```
@@ -9,6 +9,8 @@
---
> 2026-10-11 补齐候选:[最终目标核对与完整交付方案](2026-10-11-rdm-final-target-completion.md)按本轮用户确认及 RDM d8d7e743 重新映射项目/隐私/三权、全部模板与 34 UR/68 SR/10 F。该方案待评审;本页历史快照和原始证据保留,不能据其旧完成声明推断最终验收。
## 1. 大方向与大目标
### 1.1 一句话目标
@@ -2,7 +2,7 @@
title: Generative UI research and plugin proposal
date: 2026-10-10
type: feat
revision: r1
revision: r2
product_contract_source: user-request-and-current-source
---
@@ -374,7 +374,7 @@ AG-UI 仅在需要跨 Agent 框架互通时评估事件适配;MCP Apps 仅在
### U1. 受控价值与选型试验
- 关联 R1/R4/R10;依赖:已满足——2026-10-11 用户批准试验范围(见文末“用户裁定记录”);作为独立任务另行启动并评审。
- 关联 R1/R4/R10;依赖:已满足并**已执行**(2026-10-11,任务 feature/generative-ui-u1);结果见下节“U1 结果与 r2 修订”。
- 对象:固定当前组件 SHA,在隔离工作区用合成或获准的脱敏材料,覆盖调研比较、任务概览、需求输入三类。
- 方法:先比较“固定 UI/文本”与“原生 UINode 动态组合”;再用少量相同样本比较 json-render/A2UI renderer 接 @ui 的复杂度与缺口。后者是 renderer 选型挑战,不另建全套后端。
- 文件范围:专用实验目录、组件契约夹具与评测说明;全部明确为原型,不替换生产路径。
@@ -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。
@@ -436,6 +441,33 @@ AG-UI 仅在需要跨 Agent 框架互通时评估事件适配;MCP Apps 仅在
---
### U1 结果与 r2 修订(2026-10-11)
U1 三臂对照(B=Markdown 基线 30 任务;G=M3 UINode 生成 30 任务含一次修复;G-hs=highspeed 子集 10)
与 renderer 挑战已完成,全部材料为合成样本,总开销 ≈¥3.0(上限 ¥200)。详细数据与失败样本:
Dev 任务卡 feature/generative-ui-u1 及其 `.task/genui-u1/report.md`(SELF 记录;随任务 PR 留 CI GATE)。
关键结论与修订(构成本 r2 相对 r1 的差异):
1. **R1 结构分化成立**:同料不同目标 6/6 对照全部分化(类型多重集 Jaccard 0.17–0.50)。
2. **生成通道硬约束(修订 KTD2)**:页面规格只能经插件命令工具参数(exposeAsTool)提交,
不接受聊天文本 JSON。依据:文本通道首过合法 60%/修复后 83%,终判失败全部为长中文 JSON
语法违纪;工具参数通道探针解析干净、仅剩可修复语义错误;`response_format` 探针无效。
3. **目录文档要求(修订 KTD5)**:每类型附完整最小示例;按目标类别给推荐/禁用词汇
(实测 order/handover 目标下存在未被要求的 form/actions 超生成);校验器升级为 schema
驱动、目录=提示=校验三同源(借鉴 json-render,不引入其运行时)。
4. **模型路由(修订 KTD2)**:生成档固定 MiniMax-M3(highspeed 文本通道合法率 20%,否决其
生成用途;轻量步骤仍可用 highspeed)。成本实测 ¥0.067/任务(M3),可忽略。
5. **renderer 取舍确认**:首期扩展自研 UIRenderer;json-render(0.21.0)端到端可用但组件
契约重且状态/动作运行时与我方重叠,记为 U5 交互期重评项;A2UI(0.13.0)导入即需 DOM 且
客户端 signal 绑定与 KTD4 宿主解析冲突,不推荐。
6. **验收线移位**:首过 ≥90%/修复后 ≥98% 维持为 U3 工具通道验收线;本轮 60%/83% 记为文本
通道下界。稳定 nodeId 纪律良好(25/25 合法规格全提供),U2 信封先行得到支持。
局限:人类可用性对照 NOT_RUN;合成材料、n=30、每任务单次采样;G-hs 有效样本 n=2 不具统计
意义;首轮 harness token 预算缺陷已修复重跑(事故记录见报告第六节)。
## 验证与评估
### 试点评价方法
@@ -8,10 +8,10 @@ product_contract_source: ce-plan-bootstrap
# 多人协作存储与分布式演进方案 - Plan
修订:r1;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:方案获批发布,实施自首选增量 U1+U2 启动;业务实施/迁移/压测/部署仍为 NOT_RUN,逐项以实施任务卡为准。
修订:r2.3;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:U1–U7 **代码与测试已合入**(Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164);Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442);闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等)。正确性 A1–A7 与 B1 已绿(CI/SELF)。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**(见[容量报告](../records/2026-10-12-u7-capacity-window-report.md))。2026-10-12 用户决定不做容量重放;同日 B6 pgbench、C4 断连、C5 库恢复已有本机 SELF(见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md))。2026-10-13 未配置对象存储时的上传 panic 已修,C5 工件恢复 K4 重测为 SELF 通过。**SELF≠GATE/REPLAY**,双主机 C3 未做——**仍不放行第二实例承接写请求**。
需求来源:2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工;随后确认“10–100 人,多人多项目多会话并行,未来支持多服务分布式”。
需求负责人:weichen;方案编制:Codex;实施及运维负责人:待指定。更新时间:2026-10-11(Asia/Shanghai)。
关联任务:Dev `.task/feature-collaboration-storage-plan.md`(方案任务,已发布);后续 U1+U2 实施由独立任务承接。
需求负责人:weichen;方案编制:Codex;实施及运维负责人:待指定。更新时间:2026-10-13(Asia/Shanghai)。
关联任务:方案与 U1–U7 实施卡已归档;容量收尾见 Dev `.task/feature-u7-capacity-wrap-measure.md`。放行检查单:Dev `docs/release-multi-instance.md`。
正文中的源码路径以 Agent-System-Dev 为根;工作包中的 `internal/` 简写指 `modules/backend/internal/`;文内相对链接以本文为根。
## 1. 推荐结论与边界
@@ -246,8 +246,8 @@ SQLite 本身支持可靠事务与多人经同一应用访问;WAL 提升读写
必需观测:API P95/P99与预期/非预期错误,DB pool wait/连接数/慢查询/锁等待,队列长度/最老年龄,run 租约/过期写拒绝/未知副作用,SSE cursor lag/补查次数,Redis 错误与降级,检索耗时/召回抽样,备份时间与恢复结果。日志只记录 request/run/owner 的安全标识,不记录 DSN、密钥或文档正文。
当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认;容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
r1 为方案与 SELF 调查记录。r2 起:U1–U7 代码与测试已合入且正确性 CI 绿。r2.1:本机双实例 contract 容量窗口(ladder / 60m / 2h)SELF 全过,见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。r2.2:用户于 2026-10-12 明确不做容量重放;同日完成 B6 pgbench、C4 PG/Redis 断连、C5 物理备份与 pg_dump 恢复的本机 SELF,见[运维演练报告](../records/2026-10-12-u7-ops-drill-report.md)。C4 通过。C5 的库恢复通过(RPO 64 秒,RTO 4 秒),工件上传在未配置对象存储时 panic,K4 失败,产品代码未改。r2.3:2026-10-13 在 store 边界把带类型的空对象存储当作未配置并回落本地目录;同日 C5 重测 K1–K7 均为 SELF 通过(RPO 65 秒,RTO 3 秒,K4 五个工件 sha256 一致且跨用户拒绝)。本地 SELF 不能冒充 GATE/REPLAY 放行;双主机仍缺。部署与第二实例写流量仍未授权。
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
首选下一增量是 **U1 + U2 的详细实施与测试合同**:固定目标实例与 PG 测试环境,解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行;不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA,再按 Dev 的 evidence/task-sync/组合验证流程交付。
首选下一增量不要自动开工。剩余放行门槛是:独立 REPLAY,或把 C4/C5 快速档接入 CI 形成 GATE(需平台准入);以及 C3 双主机(需第二台机器)。2026-10-13 的上传修复与 K4 SELF 重测不替代这两项。GATE/REPLAY 与 C3 未齐前,不要开放第二实例写。各实现任务启动前复核在途 PR 与依赖 SHA,再按 Dev 的 evidence/task-sync/组合验证流程交付。
@@ -0,0 +1,95 @@
---
title: Generative UI U5 action-scope proposal
date: 2026-10-11
type: feat
revision: r2
status: approved
product_contract_source: generative-ui-r2-U5-clause
---
# Generative UI U5 动作范围提案(待用户评审)
依据:主记录 r2《Generative UI 调研与插件方案》U5 条款「**必须先评审本阶段动作范围**」。
本文是该评审的提案稿:给出动作分类与开放范围、审批挂接要求、明确排除项与验收条件。
用户裁定前不实施;实施另行开任务(U5 实现)。
负责人:裁定 weichen(用户);起草 Agent;更新时间 2026-10-11。
## 一、动作分类与本增量开放范围
| 类 | 定义 | U5 开放范围 | 通道 |
|---|---|---|---|
| **A 客户端本地** | 零副作用:页签切换、折叠展开、排序筛选、复制、doc-ref 打开工件预览 | **全部开放**(U4 已具雏形) | 纯前端,不经命令总线、不审计(无副作用可审);模型不能把 A 类标成"已执行" |
| **B 白名单命令绑定** | 把**既有命令目录**中的命令绑定为页面动作按钮 | **机制全量建设,第一版白名单为空**(见下) | cmdbus 四入口同源分发:审计信封、参数 Schema 校验、DangerHigh 确认卡 |
| **C 插件自身低危写** | generative-ui 表单提交落**插件自有**存储(Host.KVPut / 后台任务台账),不触发任何业务系统变更 | **开放**(场景 3「方案选择和需求表单」的实现面) | 新插件命令 `generative-ui.submit`,经同一分发/审计/幂等 |
| **D 业务写与高危** | 业务系统写(任务/项目/工件/知识库变更、对外发布、外发消息)、DangerHigh 命令直执、跨 owner/跨项目资源、代码执行 | **全部不开放** | U6+ 逐类单独评审后按 B 类机制逐条加白 |
**B 类第一版白名单为空的依据**(2026-10-11 源码事实):当前内置命令为
builtin.help / system.intent / conversation.create / runtime.mock / models.set /
conversation.profile——除 help/intent 外均为中危**写**命令,不存在可安全首开的内置只读命令。
结论:U5 交付「绑定-审计-幂等-确认」管道与测试,白名单从空起步,此后每加一条都走
独立评审(增量为零的机制 + 可验证的拒绝路径,先把地基打牢)。
## 二、审批挂接要求(映射 r2 KTD6 与现有机制,全部为既有能力复用)
1. **生成的按钮不是批准**:页面动作提交 → 宿主校验(启停/epoch/revision/权限/参数)→
`cmdbus.Dispatch`(Entrance=button,归一入审计信封)。模型只能引用允许的 action 名称,
不能伪造执行结果。
2. **DangerHigh 自动挂既有确认卡**:命中 `spec.Danger == high` 且未 Confirmed 时走现有
内联确认卡 + pendingStore 持久化 + Confirm 回道二次分发——**用户点卡确认是唯一批准来源**;
Confirmed 标志只能由卡回道置位,模型路径无法携带(红测断言)。
3. **幂等**:requestId 由客户端生成;服务端绑定 `(owner, surfaceId, revision, actionId,
requestId, 参数哈希)`。重复 requestId 同参数 → 返回已有回执;同 requestId 异参数 → 拒绝
(对齐 KTD6)。
4. **旧修订受控**:动作提交带 revision;revision ≠ 当前 latest → 拒绝并提示刷新
(旧按钮不重放)。
5. **禁用语义**:activation 关闭后新动作 403;在途按 U2 KTD7 表(已提交业务操作按命令台账
收尾,不承诺撤销)。
6. **表单草稿不进模型**:草稿由前端按 surfaceId/nodeId 管理,未提交不上传、不进
ctxasm(KTD4/KTD8;测试断言上下文不含未提交字段值)。
7. **参数校验**:动作参数按命令 ParamsSchema 服务端校验(validateParams 既有),拒绝
越权资源引用(owner 作用域)。
## 三、交付范围(实施任务的文件面,供参考)
- Backend:`POST /api/surfaces/{id}/actions`(提交动作,走 surfacesvc 守卫 + cmdbus);
幂等台账迁移(新表,纯增量);genui 目录文档补 action 绑定语法与「仅允许引用宿主下发的
action 清单」纪律。
- UI:UIRenderer `actions` 分支已有渲染,补 onAction 桥到宿主提交(SurfaceView 转发)。
- Frontend:SurfaceView onAction → 动作端点;确认卡复用现有 HITL 卡 UI;
表单草稿本地态(提交前不外发)。
- Core:优先零变更(action 绑定用服务端表,不扩 UINode 契约)。
## 四、明确排除(本增量不做)
业务实体写路径、跨会话/跨项目动作、自动触发的动作(只响应用户点击)、
动作结果自动改写页面(回执展示后由用户或 Agent 显式重组织)、
MCP/外部 HTTP 直连、任意命令即时全开。
## 五、验收条件(R7 映射,实施任务的判定线)
1. 场景 3 表单可提交、校验失败可修改重试;提交落插件台账可回读。
2. 旧 revision / 越权 action / 重复 requestId 异参数 → 拒绝(红测矩阵)。
3. DangerHigh 路径必须经确认卡;模型伪造 Confirmed 被拒(红测)。
4. 用户未提交的表单字段不出现在下一轮模型上下文(测试断言)。
5. 禁用后动作 403;A 类本地行为不受影响。
6. 幂等重放返回相同回执(并发双击一次生效)。
## 六、裁定记录(2026-10-11,用户已裁定)
三点均经用户裁定**同意**(推荐项全取):
1. **分类与范围**:A 全开 / B 机制先行白名单空起步 / C 限插件自有写 / D 全关——同意。
2. **C 类边界**:限定 KV + 后台任务台账,不建新业务事实表——同意。
3. **确认卡 UX**:复用现有内联确认卡,不新建审批 UI——同意。
本文升级为已批准范围;U5 实施按 policy/delivery.md 开任务(feature/generative-ui-u5),
验收线以第五节为准。
### 七、原裁定请求(历史留档)
1. **分类与范围**:A 全开、B 机制先行白名单空起步、C 限插件自有写、D 全关——是否同意?
2. **C 类边界**:插件自身写是否限定为 KV + 后台任务台账(不建新的业务事实表)?
3. **确认卡 UX**:复用现有内联确认卡(不新建审批 UI)——是否同意?
裁定后:U5 实施按 `policy/delivery.md` 另行开任务;本文升级为已批准范围并回填裁定记录。
@@ -0,0 +1,503 @@
---
title: RDM 最终目标核对、系统差距与完整交付方案
date: 2026-10-11
type: feat
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: legacy-requirements
---
# RDM 最终目标核对、系统差距与完整交付方案
修订 r1;负责人 weichen;编制 Codex;更新时间 2026-10-11(Asia/Shanghai)。
用户已明确最终实现范围:全部文档模板、文档三权、系统级项目及独立两树一网协作;本轮进一步要求先核对目标和差距、形成详细完整方案。
本总体方案待人工评审;业务实现、迁移、真实模型评测、浏览器验收、上线均 NOT_RUN。
本文件承担本次最终目标补齐的统筹记录;不替代 RDM 已批准需求正文。实施负责人按各工作包立项指定,不预设已有人承接。
下文 `RDM:` 为 Agent-System-RDM,`Dev:` 为 Agent-System-Dev,`Legacy:` 为旧 Agent-System 的仓内路径。
## Goal Capsule
让不同用户在同一个系统级项目内,用各自私有的对话和资料工作,通过有权限的项目知识协作,按模板完成全部体系文档的编制、审核、批准,并能追溯来源、版本、决策和验证结果。
采用 RDM 领域实现与基座通用能力组合:先接通项目、权限、资料和持久运行,再完成全部文档及三权、需求和合规链、项目生命周期与交付。
项目建议书、竞品分析仍作为第一条真实验证路径;**最终交付包含全部 69 类现有文档模板与现有报价 XLSX 资产的接入,不以两份试点或目录登记完成作为终点**。
每个项目可按自身适用性选择文档,但平台模板覆盖不能以“不适用”替代未实施。新增模板也必须沿同一发布、生成和验收契约接入。
本次三项关键口径已由用户明确,不再列为待决:系统内同名项目唯一;创建者在平台管理员上限内覆盖管理;个人聊天/原件/草稿私有,受控文档按三权及明确授权读取。
后续遇到模块职责、权限范围、外部集成或交付顺序重大改变时按 `Dev:policy/delivery.md` 回到受影响阶段评审。后移目标逐项保留,不能无记录地消失。
---
## Product Contract
### Authority and Confirmed Decisions
权威顺序:本轮用户明确指示和澄清 → 已批准 U0 D1–D9、V2.2 Q1–Q8/D10 裁定及权威正文 → 未被取代的既有定稿条款 → 原始会议材料 → 派生摘要/旧审计快照。
原始 ASR 与用户补充可用于查清意图;不能用旧会议草案反向覆盖较新的明确裁定。`.tmp` 原件保持不改,正式需求修订仍进入 RDM `docs/requirements/`。
`RDM:docs/requirements/README.md:15–21` 明确 01/02/03/04/08/09 已于 2026-10-09 合入定稿 V2.2;05/06/07/10 未重发,但解读服从新裁定。U0 页首 proposed、部分 V2.2 正文“待评审”等是残留状态文字,不能据此宣称需求未批准。
前一份模板生成方案对这些残留文字的判断在本次纠正;其具体实现建议依然是待评审方案。
| 编号 | 用户重申与最终口径 | 与最终设计的关系及依据 |
|---|---|---|
| D1 | 系统可有多个不同项目;同一名称只对应一个权威项目身份,用户加入后访问同一个项目 | 符合 UR-22、SR-G10;01:312、517;用户补充 S:50 |
| D2 | 创建者默认项目负责人,在平台管理员设置的范围和上限内管理成员、覆盖权限、分配每文档三权 | 符合 SR-G8/G9、U0 D2;用户设计意见 D:76;本轮再次确认 |
| D3 | 每项目有独立笔记树、文档树、追溯网;成员及其智能体通过授权后的项目知识协作 | 符合 SR-G11、SR-N4、08 数据模型;S:60–61 |
| D4 | 个人聊天、上传原件、个人草稿默认私有,受控文档只向三权人员与明确授权者开放,不自动全员共享 | 用户本轮明确确认;与 U0 D3 私域边界及 SR-C7 三权相容;SR-G12 的主动只读分享仍须明确授权 |
| D5 | 管理权不自动包含读取私人资料、发起代编、代审、代批 | 已批准 U0 D2、V2.2 A4;S:65–72;创建者也受职责分离约束 |
| D6 | 先项目建议书/竞品分析验证,最终扩展所有文档 | 上轮用户选择与本轮“所有文档加入并实现”;阶段顺序不缩减最终范围 |
S=`Dev:.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`;D=同目录 `user-design-ideas.txt`。原文 S:35–36 提出上限内覆盖,D:75–76 的直接用户意见收敛该选择;S:40–73 同时定义项目、私聊、共享知识和三权。
晚会原始 ASR(2026-10-08_19-36,00:37:00–00:37:21,正文段落 P329–P338)确认共同项目根,不能单独拿它证明私有权限;该部分依据以前述用户补充及本轮确认为准。
### Problem Frame
目前存在“基座界面里的用户项目”和“RDM 领域项目”两条没有完整贯通的路径。RDM 已实现项目表、部分权限计算和章节审签,但用户还无法通过统一界面完成研发项目管理及全部文档工作。
多份历史任务卡把局部领域方法、测试桩或直接处理器调用概括成阶段完成,掩盖了真实入口、授权、持久恢复、资料来源和部署组合的差距。
因此需要围绕最终用户路径重新映射证据、补齐已有实现,而不是从零重建或只补一页项目设置。
### Current State
本轮证据等级为 SELF:当前源码、测试资产、原始会议材料、只读进程构建元数据。未读业务数据库、未操作业务数据、未执行模型/业务测试。
调查基线:Dev `80a518628c526fd6ddece4abeb707ab4bb0b5618`;Backend `c8d66ca3cd21b055a8605e9eb4d8e525037618a6`;Frontend `3ed10e122042a64180fb24a42d9cc6438cd2d2d6`;RDM 初查 `0081628a10ec48a36537c6eced11a57439c986fa`,本轮期间项目授权改动合入后已增量复核至 **`d8d7e7436ca501e3ae03bbea9cc60405c74b9afc`**;RDM Backend pin `421fee81c314c05530bc809e224b5d0818ec3472`,Frontend pin `84b73ab32848e623d0a0ab7ade552784dca8cf3c`。
原始命令、固定对象和输出见 [调查收据](../records/2026-10-11-rdm-final-target-source-receipt.json)。源码基线不等于部署组合。
只读观察到 Dev `runtime/dev/bin/agent-system` 正运行 Backend c8d66ca 基座入口;另有较早、位于临时或已删除工作区的 RDM 进程。用户当前访问的 URL/实例尚未核对,不能据此直接判定其浏览器所见部署了哪个产品。正式验收须固定实例、端口、二进制摘要、组件 pins 和数据根;本轮不停止或清理这些进程。
| 差距 | 当前已有 | 尚未完成及影响 | 源码定位 |
|---|---|---|---|
| G1 项目入口 | Dev 有新建/切换/通用设置;RDM 有项目/成员命令 | Dev 创建走 owner 项目,无同名全局约束;未接研发成员/职责管理 | Dev frontend store.ts:286、ProjectSettingsModal.tsx:23;Backend store/projects.go:15 |
| G2 唯一身份 | RDM name UNIQUE、TrimSpace、创建者字段;新增一对一 HostBinding 与映射读取 | 绑定尚缺宿主项目存在性/绑定权限核验;成员不在 ListProjectsFor 目录中,页面仍首项/默认选择;新建与负责人写入非原子 | projects/projects.go:69、89;rdmapp/projects_api.go:23–87;web/app.js:98 起 |
| G3 权限覆盖 | 已有 cap∩override/default、12 动作;新增命令守卫,删除建项目自动引导管理员,改部署引导+单行约束 | cap 管理仍认 RDM 台账,平台管理员可信接入未完成;专业角色/资源策略不足;doc.write 不等于编制职责;超管槽未接 | perms/perms.go:18–60、112、172、302;perms_api.go 的 AuthorizeCmd;runtime.go:172 起 |
| G4 私域与协作 | 私有会话 owner 边界;RDM 禁止上传预索引/会话卡镜像 | EXT-8 项目布尔授权会放大到整项目工件,无法区分原件/发布快照;Host 仍 owner-only;成员上传、发布、检索不一致 | plugin.go:31;runtime.go:136;Dev server.go:1134、1199;RDM pin hostcaps.go:219 |
| G5 两树项目分片 | WorldFor、项目事件重放;主要命令新增非空项目/动作守卫,图走审计权限,上传台账按项目过滤 | rdm.init 仍可进入全量自举写路径;仍需全入口与对象归属验证;业务读/导出与审计读须分开,原件不能仅按项目过滤 | runtime.go:81–117;plugin.go:850、879;init.go:39、52;upload.go 的 UploadsList |
| G6 文档三权 | 章节角色异人、锁定、全员审核、正式链;生成已有通用动作权限检查 | 非文档级;指派对象未核有效账号/成员;通用 doc.write 未收紧到指定编制人;审签 schema 与可信 actor 处理仍矛盾 | domain/review.go:31、69;plugin.go 的 review 规格、rdmDraftCompose/Apply |
| G7 模板覆盖 | 69 种 docType;旧 69 Markdown+1 XLSX;当前 4 模板 | 仅覆盖 3 类;首项模板误选、模板可静默缺失;结构/格式/版本未统一 | 模板盘点与生成子方案 G1–G10 |
| G8 对话生成 | Compose 实际调用模型;Draft/Apply 存在;UI 新增领域项目注入与绑定尝试 | intent 类型键错误、未投影工具;缺持久提案/整文版本;旧依据可能丢失;独立页面普通文本 cmd=null 后 startsWith 仍在 | compose.go、draft.go、plugin.go 的编写 intent/compose 规格;web/app.js:410–448 |
| G9 解析与锚点 | 原件保留、md/txt/docx、部分表格/标题锚点 | 未接 ParseDocument;PDF/表格/演示文稿/图片未完整消费;慢切片改 slow:batch 丢原定位 | parse.go:33、346;slow.go:267 |
| G10 统一摄取 | 上传相关性三态、纯文本公共入库终点、发布方法 | 普通 ingest 可绕过相关性;发布未带 ProjectID,失败无持久补偿;上传非空摘要占位跳过真实摘要;聊天自动沉淀未接 | ingest.go:89、122;upload.go:406–409;llm_summary.go:20 |
| G11 结论与冲突 | 结论提议/确认、词面冲突检测、supersedes;拒绝提议已校验所属项目 | 确认提议仍按 id 查询未限定项目;固定阈值且已有结论后不再触发;无完整候选组/两层裁决;Resolve 可误关其他争议 | conclusions.go:125–135、264、310;domain/fc/collide.go:35、125 |
| G12 需求与合规 | UR/SR 台账;15 节点/11 边、四视图、八规则、矩阵/导出 | 六维/父子分解不足;受控节点和边写方法无生产调用;只有读命令,缺真实业务生产者 | requirements.go:21;compliance.go:155;plugin cgraph commands |
| G13 法规双通道 | 知识检索与法规声明记录 | “网络通道”用 Complete 生成 URL JSON,无实际搜索/抓取;不能作为独立网络核验 | regcheck.go:35、58–72 |
| G14 阶段与完整性 | 部分素材数/待确认文字检查 | 项目无阶段状态;缺推进/结项用户路径;审核提交未接内容/合规缺口门禁 | projects/projects.go:17;baseline.go:82;review.go |
| G15 长任务 | 内存队列、慢任务台账、重启标 failed | 不保存恢复所需项目/owner/原输入;不能续跑;通用快慢任务与取消恢复未闭合 | slowledger.go:31–43、74–77;slow.go |
| G16 看板与影响 | 职责/编制状态/正文变化投影 | 来源变了而正文未变时看板无法反映;缺影响对象、责任人、解决状态的闭环 | kanban.go:26、67;todo.go |
| G17 版本导出 | DOCX/XLSX 代码和测试 | 未按模板渲染格式、未绑定整文批准快照;合规导出正文为当前图却展示最新快照 hash | docx.go:155、298;cgraph_export.go:114 |
| G18 团队部署与执行 | 基座 PG/Redis、预算与动作矩阵;RDM 执行硬关闭 | RDM 领域仍 SQLite;动作矩阵公开接线不足;隔离执行尚未替代禁用;缺真实 RDM 双实例与备份恢复 | RDM domain/store/store.go:21、main.go:188;Dev server.go:90 |
| G19 完成证据 | 单测、桩 E2E、历史任务卡与 smoke | 真实三用户/两项目/模型/浏览器/安装包验收缺项;历史广义完成声明不能覆盖实际缺口 | v01_e2e_test.go:28、61、99、120;selfhost.go:130 |
“部分已有”表示可复用,绝不表示运行通过;“未接通”也不应改写为“所有组件都没有”。
RDM 数据库名唯一仅证明该源码对单数据库的精确字符串约束,尚未核实部署旧库索引;多数据库、多实例及名称规范化另需验收。
本轮新增实现来自 RDM 项目授权 #195/#196 的提交;上传来源项目解析、批次授权及结论拒绝的项目约束也已补入。未受此次改动影响的解析、模板、语义检索、任务恢复和合规生产缺口继续有效。U2/U3 必须复用这些新能力并补闭环,不能重复建设。
当前最高优先级之一是宿主绑定的双向权限:仅证明“我是 RDM 项目创建者”不足以绑定一个任意宿主项目。绑定前必须在宿主核验真实项目身份及调用者管理/绑定资格,并在服务端绑定可信上下文;否则已有共享读回调会扩大到不属于该主体的宿主资料。
绑定管理不能复用只读 AuthorizeAudit(当前 canManageBinding 的回落会在未来超管接线后扩大写权)。同理,合法三权人员查看/导出自己的文档不应要求其具备整个项目审计权限;当前 doc.export 的审计守卫需要按业务资源重新分类。
### Requirements and Acceptance
完整逐条索引见 [34 UR/68 SR/10 F 对照矩阵](../records/2026-10-11-rdm-final-target-requirements-matrix.md)。下表以 R-ID 固定本次设计不变量,保留原 UR/SR 作为正式需求身份。
| ID | 必须成立的最终行为 | 可判定验收 |
|---|---|---|
| R1 | 同系统项目名称与身份全局唯一 | 不同用户并发创建同名只有一个成功;加入成员看到同一 projectId;不存在按用户复制 |
| R2 | 上限内覆盖权限,并在执行端生效 | 撤销上限后旧 override 立即不生效;页面/API/命令/工具/任务恢复均拒绝越界 |
| R3 | 创建者可管理项目成员与每文档职责 | 项目负责人完成分配;平台全局权限不因建项目增加;职责对象必须有效且是成员 |
| R4 | 私聊/原件/草稿私有,受控文档按职责或明确授权读取 | 同项目其他成员无法通过正文、计数、搜索、摘要、预览、下载、追溯、模型输出读取未授权内容 |
| R5 | 每项目两树一网独立且内部按权限协作 | A 项目成员/智能体可使用 A 的发布知识,不能读取 B 项目或 A 的私有原文 |
| R6 | 全部现有文档类型可用,模板发布后结构/格式固定 | 69 类逐份有发布模板和真实生成验收;报价 XLSX 独立验收;项目不适用不减少平台覆盖 |
| R7 | 原件、解析、锚点、标签、知识发布可解释且可恢复 | 多格式能力分档声明;失败原件可取回;慢处理不丢页表锚点;存疑/拒绝不进共享检索 |
| R8 | 结论、冲突、依据选择受控 | 新资料可触发结论更新;文档层选择不改变项目全局结论;裁决只关闭指定争议 |
| R9 | 对话生成整文可修改可恢复,采纳才生效 | 模板与输入版本固定;无依据不编造;旧引用不丢;重复提交不重复写;部分采纳后整文仍一致 |
| R10 | 文档三权完整执行 | 编制一人、批准一人、审核至少一人且互异;审核/批准不可改正文;提交锁定,全员审核后才能批准 |
| R11 | 文档/需求/验证/风险/合规链真实生产和历史可重建 | 业务操作产生版本节点与候选边,人确认生效;导出内容/哈希/批准快照一致;无伪造验证结论 |
| R12 | 项目有阶段、准入准出和结项 | 仅在提交审核/申请推进时执行正式缺项门禁;不合格不能推进;按固定快照决策并可追溯 |
| R13 | 对话、卡片、工作区为同一对象的入口 | 右栏收起仍能完成任务;刷新/重启不丢;过期卡片不生效;不以假数据替代真实产物 |
| R14 | 团队运行具备当前授权、事务一致、恢复和隔离执行 | 两项目多人并行、撤权、故障注入、备份恢复通过;禁执行仅为过渡,最终隔离后按策略开放 |
| R15 | 全部已批准目标有去向和真实证据 | 34 UR/68 SR/10 F 无漏项;实现、测试、部署分别登记,只有显式裁决可取消目标 |
### Scope and Completion Levels
核心完整交付 C1:U1–U14 加 U16,覆盖项目/权限、私域与协同、全部模板、三权、资料、知识、需求合规、生命周期及团队可用性。
最终扩展交付 C2:U15 的 F-01…F-10 各项完成或经用户明确裁定取消/替代;外部系统接入受凭据、平台授权与独立交付条件约束。
**C1 通过不能写成所有最终目标完成。** C2 未完成的目标保留在同一矩阵,不将“后移”改成永久非目标。F-09 已有较新两树一网展示方案,应并入 U11/U14,而不继续沿用早期延期状态。
完整方案不意味在一个大 PR 同时改完;按依赖交付,每阶段保留可回退、可独立验收的增量。
---
## Planning Contract
### KTD1. One Project Identity
推荐继续由 RDM 保存研发项目、成员、职责权威;基座提供共享项目上下文及私有会话/工件能力。用户看到的是**一个系统级项目**,宿主内部 ID 只作一对一技术映射,不能再产生每用户一个同名研发项目。
对照备选:把研发项目权威搬入基座需重新划分领域职责,成本更大;为每位成员复制基座项目会破坏唯一身份与追溯,不采用。
统一入口的创建/改名/归档均调用项目应用服务。RDM 产品界面不再暴露绕过该服务的独立“个人研发项目”创建路径;通用基座个人项目保留为基座模式能力,不混入 RDM 项目目录。
复用新合入的 HostBinding 表与命令,补宿主端存在性、绑定资格和实例域校验;不能仅凭 RDM 创建者权限接受任意 hostProjectId。项目目录分为成员工作目录与受限审计目录:普通成员必须看到加入的项目,但不因看见项目获得审计权。
项目对象包含稳定 ID、名称与规范化键、创建者、生命周期、权限策略版本、文档目录版本及宿主绑定。建议名称规则为去首尾空白、Unicode 规范化、拉丁字符大小写归一;展示原名,规范化键由数据库唯一约束保护。规则在迁移前用现有名称干跑确认,冲突由人裁定,禁止静默合并。
归档保留名称与身份;删除采用受控归档/软删除,不让新项目复用同名后被误认成旧项目。名称变更的历史同样留存。
成员可见同一项目不等于全系统用户可列出所有项目;未加入者的同名创建返回名称不可用,不泄漏成员、内容或审计。
RDM 项目+创建者成员角色+名称保留在同库事务建立;跨库宿主绑定采用幂等 provisioning→ready/failed 与可恢复补偿。绑定未完成显示初始化状态,禁止继续向默认项目写入。
业务只接受服务端从当前会话/对象解析的项目;客户端 projectId 是定位符,跨项目参数或不一致绑定拒绝。外部旧命令的空项目全量回退关闭;未归属历史仅受信迁移工具可访问。
### KTD2. Policy and Duties
普通业务动作的允许条件为:有效账号与项目成员身份 ∧ 平台上限 ∧ 项目 override(未设置则角色默认)∧ 资源可见范围 ∧ 适用阶段/状态 ∧ 操作所需文档职责。
“显式拒绝”优先;平台上限收紧不需逐一改旧 override 才生效。多角色合并仍受同一上限,冲突按显式拒绝收敛,不依靠前端按钮控制。
平台管理员维护角色、默认权限、可覆盖上限及受管配置;项目创建者/负责人只调整项目内范围。支持专业角色目录,但编制/审核/批准是**文档职责**,不等同于“工程师角色”或广义 doc.write。
项目创建不得触发管理员引导;管理员初始化与移交走受信管理入口和事务唯一约束。既有“双层管理员”裁定用于审计可见性,不自动扩大成私人内容阅读或三权签字豁免。
CreatedBy 固定记录创建事实;负责人变更另有显式委任/接替记录,不重写创建事实。任何接替均不能跨过管理员上限。
权限、成员与职责变更写入审计并递增 policy/duty 版本;长任务开始、敏感读取、恢复、结果投递、提交、下载都重验。前端撤按钮不足以撤权。
### KTD3. Private Data and Shared Knowledge
| 资源 | 默认读者 | 共享/派生规则 |
|---|---|---|
| 个人会话、Agent 中间过程 | 本人 | 不自动镜像项目流;他人模型也不能间接读取 |
| 上传原件、个人草稿 | 本人 | 文件分享只产生明确的只读授权;不因 projectId 相同开放 |
| 项目发布知识快照 | 被授权项目成员 | 原件作者明确将选定内容发布为项目知识;可检索内容与原件权限分离,保留来源/发布版本 |
| 受控文档正文与修订 | 指定三权人员及明确获授权者 | 角色授权随职责/状态校验;全员只读必须明确授予,不默认开放 |
| 文档树目录、状态、待办 | 按所需最小范围 | 不通过标题、摘要、计数或引用暴露无权文档;负责人可管理职责元数据不代表可读全文 |
| 项目审计中心 | 按已有创建者/管理员审计方案 | 私人原文、秘密和隐藏推理仍不直接出现在审计 DTO/导出 |
两树一网在项目内共享其业务知识和组织结构,**不等于每个节点的所有载荷对所有成员可见**。文档树仍保存要求+正文版本(Q8),正文节点继承文档 ACL;追溯遍历使用受限投影,不直接返回内部 payload。
明确“提交为项目资料”只发布选定知识内容;保留的原文件仍可私人。普通上传不自动发布全文,混合/存疑材料先确认。资料作者可发布脱敏摘要/摘录并保留批准的发布快照,使其他成员能使用该快照而无需读取私人原件。
审核所需依据应提供职责范围内的证据包:可读发布快照、明确原件授权或经确认的脱敏材料;仅有无权访问的私人引用时不能宣称证据已可核验。文档存储了私人资料的事实也属于披露,提交前必须处理发布授权。
撤销原件分享立即停止新访问与上下文注入;已经明确发布的知识快照按其独立发布生命周期处理,不把撤销文件链接误当成回收所有已批准知识。撤回发布知识时停止新使用,标记依赖文档 stale;历史受控快照的保留与可读性分别受记录保全及当前授权控制。
所有 HTTP、Host、索引/检索、卡片/SSE、预览下载、导出、图查询采用同一资源级决策;授权参数包含主体、项目、动作、资源类型/ID/版本、policyVersion。只读布尔项目授权无法表达这些边界,不因补齐项目 ID 就直接开放全项目工件。
### KTD4. Transaction and History Foundation
复用现有两树一网方案的原子事件、幂等、历史重建和 outbox,不再另造第二套事件中心。
在领域事务内完成预期版本校验、写台账、事件批次及幂等结果;提交后更新投影。跨宿主存储操作通过幂等步骤与 outbox,提交未知时先查结果再重试。
历史对象为 ID@version,切片原文与历史版本不可变;结构删改用软删除/取代/新事件。普通哈希用于一致性检查,不宣称具备外部防篡改或电子签名保证。
部分更新、角色调整、关系变化、合规 stale 标记与重放对等;同一历史水位必须还原同一文档/图/职责/审批事实,未知事件版本不得静默忽略。
旧数据先盘点归属及 ACL。旧 Agent-System 业务数据仍按 O9 不迁移;旧模板内容属于可复用资产,当前 RDM 数据必须保全,二者不得混淆。
### KTD5. Source-to-Knowledge Pipeline
统一上传、明确发布的对话内容、会议和外部研究的摄取契约:来源对象→私域留档→解析状态→相关性/发布决策→带锚点切片/标签→知识快照/索引→冲突与结论候选。
接入基座公开 ParseDocument,按原件保全、文本、表格、OCR、图像描述、页表锚点逐档标能力;不支持时留原件并明确说明,不把“收到了文件”当作“完整理解了内容”。
锚点使用 sourceId@version+页/表/段/偏移;快慢处理沿同一解析块精化,不把锚点替换成不可回跳的 slow:batch。chunk 与 slice 是显式多对多映射。
共享标签字典版本化,记忆侧描述标签与文档章节需求条件同源;已确认强制材料/旧有效依据不能被 topK 静默挤掉。自动分类及摘要用独立人工金标验证,不以同源样本给自己评分。
知识发布失败留下可重试任务,不静默计零后报全部入库成功。待裁定、拒绝、撤回的资料不进入共享检索;原件取回与上传台账同样鉴权。
### KTD6. Conclusions, Conflicts and Impact
结论必须绑定依据和材料水位,允许随着新内容提出新结论;模型决定是否足够形成有价值总结,冷却只控制通知频率,不能让“已有结论”永久阻止更新。
会议纪要结构化抽取结论/待办/待确认,各条带原发言或资料锚点。模型提炼不等于已批准项目事实;采纳由人完成,结果回两树一网。
冲突对象使用明确 conflictId/groupId 和候选版本。相似度只提供检测线索,不能充当语义矛盾的证据;保留双方陈述、出处、影响与建议。
文档层裁决选择本文档的依据;项目层裁决改变项目有效结论,由负责人或明确指定知识责任人完成。只关闭该争议,不把两个节点参与的其他争议一起关闭。
来源、需求、测试结果或规则变化产生影响清单,指向受影响文档和负责人;正文未改变也要显示“依据有更新/验证过期”。看板与收件箱被动汇聚,对话按任务节点集中处理,不频繁插话。
### KTD7. All Templates and Controlled Documents
复用 [模板对话生成子方案](2026-10-11-rdm-template-dialog-generation.md) 的模板元数据、结构、检索条件、格式和发布清单,以及 Run/ContextManifest/Proposal/DocumentRevision 设计。
完整模板台账覆盖 [69 类旧资产](../records/2026-10-11-rdm-template-inventory.md) 与报价 XLSX。逐份保留来源 SHA,拆分内容要求、格式约束和管理记录;去除旧“任务键=模板文件名”绑定。
模板按用途区分正文、纪要、汇报,绑定明确默认;缺模板或版本失效时拒绝“按模板生成”路径,不静默用自由文本代替。v10/v2 使用正式版本语义,不按字典序。
首批两模板先验证闭环,随后按资产台账完整迁入。每份上线模板均需有材料的成功样本及空缺/冲突反例;不能仅通过注册表计数宣称 69 类可用。
模板目录是组织资产,项目实例按适用性选择,但全部类型保持可配置可用。标准模板由用户后续提供(F-10),导入需差异评审及版本迁移;用户没有提供的标准模板不伪称已经替换。
三权面向每份文档:编制唯一、批准唯一、审核可多人且至少一人;三者互异。所有审核人通过后才可批准;审核/批准只能批注和通过/驳回,不改正文、不发起生成。
新文档无职责时任务停在可见“等待分配”,负责人可通过对话或管理页分配;其他成员可转交最小编制请求,不能转发其私人聊天全文。负责人可在上限内给自己分配其中一种职责,但不能同时兼任冲突职责。
提交冻结整文版本、模板、依据、职责与策略版本。职责变更、成员撤销或正文变动使受影响的待审决定失效;不能先让本人编制,再改职责给本人审核/批准同一提交版本。历史职责/操作身份参与分离校验,角色改名不洗掉已执行事实。
生成、人工修改、导入、旧命令、直接状态迁移必须经过同一编制与版本服务,不能从旧入口绕过。
旧章节职责和签署作为历史保留,不能拼成“整文已批准”;启用文档级流程前明确职责并处理旧活动审签,首个整文正式版本重新审签。驳回只增加内部修订,终批才产生新正式版并建立取代关系。
实际采纳的新旧章节组合须重新验依赖、术语、指标一致性;确认绑定该组合 hash,事务前重验版本。版本+引用/追溯+提案状态+领域事件全成或全败。
### KTD8. Requirements and Compliance Producers
复用已有 15 类受控节点、11 类边、四链视图、八完整性规则、快照、矩阵和导出器;补真实业务生产者及写入/确认入口。
需求台账支持批准基线要求的 UR/PR/SWR/HWR 等类型、父子分解及六维分类;保留原 UR/SR 编号兼容映射。用户需求先确认后分解,法规反推产生候选,不直接替人定需求。
设计、风险、风险控制、测试计划/执行结果、验证、确认、设计转换、SOUP 等对象通过各自业务动作产生版本节点;字符串 LinkedSections/LinkedTests 迁为受控版本边,映射歧义保留待处理。
模型只推荐合规关系,授权人确认转正;目标升版标 stale,不自动转移旧签名/旧验证结论。验证结果必须关联实际被测版本、执行者与证据文件;没有实际结果时仅可生成计划、空表或 NOT_RUN 草稿。
法规双通道必须是受控知识库+真实联网搜索/抓取的独立证据,保存 URL、取得时间、文档版本、片段锚点与可复核快照。模型生成 URL 不算网络核验;失败清楚标单通道/未核实。
本方案使用项目已批准的合规数据模型,不作具体标准符合性认定。专家校准负责规则、链视图与交付格式,保留意见来源及版本;不以数据结构存在代替合规验收。
### KTD9. Lifecycle, UI and Agent Execution
项目阶段配置、文档适用目录与准入准出规则版本化;当前字典为既有种子基线,关于进一步阶段合并的旧未裁定意见不擅自生效。
提交审核和申请推进时执行模板内容要求、缺项、职责、冲突、合规完整性门禁;有材料不等于满足要求,所有候选边也不等于冲突。可接受的不适用必须说明理由并由有权者确认。
阶段推进/回退/结项记录固定对象集合、规则和决策;外部完整变更引擎在 F-02 交付前,当前保留撤回重审、冲突和影响提示,不能直接改批准基线。
沿三栏工作台:左侧统一项目及私有会话;项目管理承载成员/权限/文档职责/阶段;工作区承载树、文档、追溯与看板;右侧工作/文件用于待办和唯一预览。对话与这些入口访问同一服务。
所有业务操作均可经自然语言准备并在必要节点显式确认。查询/总结不触发写入;模糊“继续”只作用于已展示且未过期的请求。工具说明渐进注入,RDM 编制/审阅配方作为产品资产,内核保持通用。
执行自由度遵 Q7/D10:检索、解析、归纳、候选生成可自主;三权、基线、正文生效和合规边确认受确定性门禁约束。模型不能自签或借工具权限继承管理员能力。
### KTD10. Durable Jobs, Storage and Deployment
Run/Step 保存发起主体、项目、输入引用、模板/提示词版本、检查点、水位、幂等键和恢复状态;模型调用不持数据库长事务。取消、审批与恢复针对同一持久对象,权限变化后拒绝续跑或投递。
重启仅标 failed 是可观察失败,不是任务恢复。最终必须能安全续跑,或对未知副作用停在需人工确认的恢复状态;禁止无条件重放。
复用多人存储方案已有工作:团队 PostgreSQL 为权威、Redis 可丢失、预算可配置、单实例先行。RDM 领域库、原件、知识发布、任务与检查点必须显式纳入迁移/备份,不能只设置 Backend PG DSN。
多实例验收包括领域唯一性、事务、数据库发号、运行 owner/epoch、队列领取、事件追赶和共享工件;两个 dataDir 的宿主 smoke 不证明 RDM 多实例写入一致。
多人隔离前继续硬禁高风险代码执行;最终交付隔离执行后端、目录/网络/资源约束和受控开放,符合 SR-G16,不以永久禁用替代能力。
发布包必须包含 RDM 插件接线、模板/字典/提示词资产和明确组件清单;离开源码目录仍可启动。部署另设固定环境与授权,安装、升级、备份、恢复、回滚均有可执行操作说明与演练证据。
### High-Level Technical Design
```mermaid
flowchart TB
P[平台账号与角色上限] --> A[统一动作与资源授权]
C[系统级项目目录和成员] --> A
U[各用户私有会话 原件 草稿] --> A
A --> K[明确发布的项目知识快照]
K --> N[项目笔记树]
T[已发布模板及文档职责] --> D[项目文档树 要求和版本]
N --> G[项目追溯网 依据 决策 影响]
D --> G
A --> R[持久任务与提案]
N --> R
D --> R
G --> R
R --> H[编制确认 审核 批准]
H --> V[固定整文及合规快照]
V --> X[DOCX XLSX 可审计导出]
```
```mermaid
sequenceDiagram
participant U as 编制人
participant S as 领域应用服务
participant J as 持久任务
participant D as 领域存储
participant R as 审核和批准人员
U->>S: 项目内编制请求
S->>S: 当前权限 职责 资源检查
S->>J: 固定模板 输入和目标版本
J-->>U: 进度 持久提案 差异
U->>S: 采纳固定提案
S->>D: 事务提交版本 依据 追溯
U->>S: 提交审核
S->>D: 完整性门禁并冻结整文
R->>S: 当前身份审签固定快照
S->>D: 正式版及批准记录
S-->>U: 可预览下载的固定版本
```
```mermaid
stateDiagram-v2
[*] --> Provisioning
Provisioning --> Active: 项目和绑定均就绪
Provisioning --> Recovery: 初始化失败
Recovery --> Provisioning: 幂等恢复
Active --> StageReview: 申请推进
StageReview --> Active: 通过并进入下一阶段
StageReview --> Active: 驳回维持原阶段
Active --> Closing: 申请结项
Closing --> Archived: 准出与确认通过
```
文档状态独立为编制中→审核中→待批准→已批准;驳回回编制中,新版本获批才取代旧正式版。任务运行、文档审批与项目阶段不能合并成一个“完成”标记。
### Public Contracts and Existing Plans
| 契约组 | 场景与公开面候选 | 现有缺口及兼容方式 |
|---|---|---|
| X1 项目绑定和生命周期 | RDM 项目服务与 Host 项目上下文创建/解析/成员目录 | 现有个人项目 CRUD 无统一约束;新增可选插件适配,RDM 启用时所有入口走同一服务;通用基座模式不被偷换 |
| X2 资源动作授权 | 身份+项目+action+resourceRef+version;HTTP/Host/检索/下载同判定 | EXT-8 只读 bool 太粗;动作矩阵尚非完整公开生产接线;版本化扩展、默认拒绝,旧读取适配器不获得写权 |
| X3 资料发布与解析 | 原件保全、ParseDocument、知识发布/撤销、chunk 映射 | 部分能力已在基座;RDM 逐项采纳并组合验证,缺失能力才申请新面 |
| X4 持久任务和恢复 | 受限 Host 工厂、Run/Step、取消/确认/状态事件 | 复用现有能力及团队存储路线,RDM 不保存旧 Host 凭据,不创建第二套账号 |
| X5 工件和外部证据 | 固定文档/图快照导出、artifact 绑定、真实 web search/fetch | 输出引用不等于实际文件/网络证据;受控任务产物与可核验抓取结果走公开面 |
每个缺失扩展按 RDM AGENTS 的场景、期望符号/路径、现有组合不足原因、兼容方式四要素申请;不导入 Backend internal,不修改 RDM pins 内实现。
与 [两树一网方案](2026-10-11-rdm-two-trees-trace-audit-integration.md) 共用项目绑定/授权、事务历史和审计展示;与 [多人存储方案](2026-10-11-collaboration-storage-and-distribution.md) 共用 PG、运行所有权、预算、恢复和隔离;模板子方案为 U7/U8 的详细设计输入。
在途核对:本轮远端查询 Dev #337 为存储迁移工具/恢复操作说明组合,#336 为 Generative UI U2,#317 为启动检查;不能把它们的未合入能力计入当前基线,也不重复立项。RDM 新增 `docs/proposals/2026-10-11-u1-base-extension-requests.md` 已提出平台身份能力与可信当前项目两项扩展,X1/X2 应承接该申请而不是再写第二份。正式立项时再次刷新在途状态。
原 [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) 的历史进度保留,新补齐顺序批准后回填该案及 RDM requirements/10,不制造多份互相覆盖的“最终状态”。旧广义完成声明只保留为历史记录,另做需求→证据重新映射,不改写其原始收据。
---
## Implementation Units
优先级 P0 为核心安全/正确性与用户路径,P1 为完整核心交付,P2 为外部扩展;P1/P2 不表示可永久省略。责任为仓/模块,具体 owner 在立项时明确。
依赖顺序:U1→U2→U3;U4 与 U7 可在各自契约固定后并行;U9→U5→U6,同时 U5→U12 真实法规双通道;U7 的首批模板和 U12 就绪→U8 首批闭环→U16 全文档族推广;U8/U11 汇合到 U10(经 U8 已包含 U12);U13 与业务开发并行收敛,最后 U14;U15 按子目标独立立项。
| 单元 | 交付主题 | 主要范围 | 前置 |
|---|---|---|---|
| U1 | 需求、证据和组合契约 | Documents/RDM requirements 与 pins 清单 | 无 |
| U2 | 系统级项目与管理入口 | RDM projects/members、基座项目适配、Frontend | U1 |
| U3 | 权限上限、私域与资源授权 | RDM perms、基座资源/Host/检索边界 | U2 |
| U4 | 原子事件、历史和旧数据归属 | RDM domain/store/eventlog/replay | U1、U2 契约 |
| U5 | 完整资料摄取与检索 | upload/parse/ingest/fbhost | U3、U4、U9 |
| U6 | 结论、冲突、两层裁决与影响 | conclusions/fc/kanban | U5 |
| U7 | 全资产台账与首批模板契约 | templates/structure、资产 bundle | U1 |
| U8 | 整文生成、三权和版本导出 | compose/draft/review/docx | U3、U4、U5、U6、U7、U9、U12 |
| U16 | 全部文档族迁移和真实验收 | 69 模板及 XLSX、契约与样本 | U8 |
| U9 | 持久快慢任务与对话入口 | RDM jobs/plugin、基座运行/卡片、UI | U3、U4 |
| U10 | 项目阶段、缺项门禁与结项 | projects/baseline/review | U8、U11 |
| U11 | 需求/风险/验证/合规生产闭环 | requirements/compliance/chainviews/exports | U3、U4、U6 |
| U12 | 真实外部研究与法规双通道 | regcheck、公开检索/抓取能力 | U3、U5、U9 |
| U13 | 团队存储、隔离执行和运行恢复 | RDM store、Backend/Squad/Native、发布包 | U1、U4、U9 |
| U14 | 全量验收、自举和用户上线 | 测试、CI、部署/恢复资料 | U1–U13、U16 |
| U15 | 最终后续目标逐项实现 | F-01…F-10 责任模块 | 各子项按下表 |
### U1. Baseline and Evidence Reconciliation
覆盖 R15。统一 34 UR、68 SR、10 F 的解释,明确本轮 D1–D6;修正文档状态漂移及历史测试覆盖映射,固定实际 RDM/Backend/Frontend/UI/Native/Squad 组合。
文件:RDM requirements/README、01/03/04/08/09/10、U0/V2.2 主记录;Dev proposals/INDEX 与扩展申请;新增需求证据矩阵(本轮候选已给出)。
方法:先评审来源和范围,再按最小契约申请/采纳 X1–X5;已有能力只补接线,不重新立项重写。U1 保留在途 PR 及 owner、版本和接受条件。
验收:全部原编号各有最终行为/工作包/测试入口;没有历史 PASS 自动变成当前 PASS;被覆盖的旧表述有指向当前解释的入口。
### U2. System Project and Management
覆盖 R1/R3/R5。交付创建/改名/归档、授权目录、成员加入/移除、创建者管理、宿主绑定及用户可用项目管理页面/对话路径。
文件:RDM internal/projects/projects.go、internal/members/members.go、rdmapp/projects_api.go、runtime.go、plugins/rdm/plugin.go;Backend store/projects.go/server 项目入口/公开适配;Frontend TaskSidebar/ProjectSettings 与 RDM 工作区。
测试:扩展 projects_test.go、成员测试及新合入 u1_auth/u1_surface 用例;新增项目绑定和浏览器流程用例。两用户同名并发、规范化碰撞、改名碰撞、归档、创建者角色写失败、宿主绑定失败重试、绑定他人宿主项目拒绝、成员加入后同 ID 可见、非成员目录及默认项目回退拒绝。
出口:真实用户可用统一研发项目管理;测试不能直接向数据库播种一个“已经绑定”的项目绕过创建路径。
### U3. Policy, Resource Access and Privacy
覆盖 R2/R3/R4/R5/R10。完成专业角色默认/上限/覆盖、文档职责分配授权、资源级读写策略与即时撤权;交付 X2 公开契约和全部生产入口接线。
文件:RDM perms、perms_api.go、sharing.go(实际路径在实施时核对)、upload 台账/确认、plugin 守卫;Backend extension、server、hostcaps、retriever、cardsvc;新增 resource_authz_test.go、隐私浏览器用例。
测试:上限拒绝覆盖、撤上限后旧许可失效、无效/停用/非成员职责指派拒绝;同项目私聊/原件/草稿、关键词/计数/摘要/导出不泄漏;职责读取与明确分享允许;普通三权人员可合法导出本文档而无全项目审计权;审计读取许可不能变绑定写权;撤权后 SSE/模型结果/下载立即拒绝;建项目不成为管理员。
出口:原件私有且项目发布知识可被其他成员合法检索;HTTP 与 Host 行为一致,不出现“页面可读但模型不可读”或反向泄漏。
### U4. Atomic Domain and History
覆盖 R5/R8/R9/R10/R11/R14。将多事件操作、台账、幂等和 outbox 收入单一领域事务,修复投影先写、重放不对等与历史快照不完整。
文件:RDM domain/eventlog.go、replay.go、payloads.go、store、doctree.go、tracenet.go、compliance.go;新增 transaction_fault_test.go/history_replay_test.go、迁移映射清单。
测试:在版本、建边、职责记录、快照阶段注入失败;提交全成/全败,重试唯一;跨项目边拒绝;同水位重启前后对象/签署/stale 相同;未知事件拒绝;遗留空项目只读隔离且不自动归属。
出口:真实持久库故障证明一致性;授权不明历史留待裁定,不以清空数据修复测试。
### U5. Ingestion, Parsing and Retrieval
覆盖 R4/R5/R7。统一原件、上传对象、相关性、发布、解析锚点、标签、知识索引与补偿;消费公开 ParseDocument。
文件:RDM upload.go、parse.go、ingest.go、relevance.go、llm_summary.go、fbhost/adapter.go;公开能力差距经 Backend 扩展;测试 upload/parse/publish_consumption,新增 anchor_roundtrip_test.go。
测试:PDF/Word/Excel/PPT/图片与文本各能力档、重名重传、损坏/大文件/解析中断、表格宽列、部分成功、私有和待裁定不发布、确认重试不重入、慢处理保留页表位置、发布失败重试、跨项目检索负例。
出口:真实素材的原文→切片→检索→引用可回跳;性能按已批准 SR-N1 的样本规模协议测量,不用空文件证明时限。
### U6. Knowledge, Decisions and Notifications
覆盖 R5/R8/R11/R13。结论水位更新、会议三类抽取、冲突组、两层裁决、依据变化影响清单与低打扰通知。
文件:RDM conclusions.go、domain/fc、pending/todo、kanban.go;新增 conflict_scope_test.go、conclusion_update_test.go、impact_notification_test.go。
测试:已存在结论后新增资料仍可提出更新;相似但不冲突的反例;同一切片参与多个争议只关闭指定争议;编制人只改本文档选择,负责人裁定共享结论;正文未变但依据更新仍提醒;受限来源不在通知泄漏。
出口:知识更新和文档写入是独立受控动作,用户能知道“谁改变了哪条依据、影响谁”。
### U7. Template Contract and Pilot Assets
覆盖 R6/R9。登记全部 69 类及 XLSX 资产;按模板子方案 U1/U2 建立公共章节结构、内容/格式约束、发布版本、默认用途、稳定 sectionKey 和 bundle,先结构化项目建议书、竞品分析两模板。
文件:RDM docs/templates、templates.go、structure.go、domain/doctree.go;69 类台账及 XLSX 资产;template_contract_test.go/template_instance_test.go 与每模板验收样本。
测试:台账无遗漏,首批用途匹配、v2/v10、多版本保留、模板升级迁移提案、无源代码运行和格式契约;两模板能正确实例化,不用静态检查冒充真实生成。
出口:公共模板契约和首批两模板可供 U8 使用;其余模板标记待迁移/验收,全部完成由 U16 承接,避免 U7 与生成能力互相等待。
### U8. Document Generation and Three Duties
覆盖 R6/R9/R10/R11/R13。复用模板子方案 U3–U5,交付文档级职责、持久提案、完整来源、差异采纳、锁定审签、正式版本和批准快照导出。
首批竞品分析模板含法规要点,完整验收以前置 U12 的真实双通道就绪为条件,不能用模型生成 URL 或单通道占位降低模板要求。
文件:RDM compose.go、draft.go、domain/fb/writegate.go、domain/review.go、docx.go、plugin、编制 skill;新增 document_revision_test.go/document_duties_test.go,真实三人浏览器编制案例。
测试:无职责等待/分配/接续;非编制人所有写入口拒绝;审核人不能改正文;审签走真实总线不传伪造身份;多审核人缺一不能批准;更换职责不能让原作者自审;旧卡/旧版本拒绝;部分采纳重验整文;撤权/并发/故障原子性;真实 DOCX 打开和引用可达。
出口:两份试点从真实资料经真实模型和三人账号完整通过,随后 U16 全量文档族推广;有实际结果才能生成验证报告通过结论。
### U16. All Document Families
覆盖 R6/R9/R10/R11,依赖 U8 首批真实闭环。按原 69 类台账逐族迁移、发布和验证,现有报价 XLSX 独立交付;需求、设计、风险、测试/验证、评审等文档族全部有结果。
文件:RDM docs/templates/registry 与全部模板、XLSX 资产/renderer、各模板结构/格式/样本测试;原件哈希与迁移差异写入台账。
测试:每份至少一个有材料的真实生成与审签导出正例、一个空缺/冲突反例;特有表格、章节、引用、公式、格式与职责均检查。编制共同契约复用 U8,不为每份模板新写一套业务流程。
出口:69 类均有已发布可用正文模板及对应运行证据,XLSX 实际打开检查通过。公司新标准模板另列 F-10;平台全量覆盖不得用项目内“不适用”豁免。
### U9. Durable Task and Conversation Infrastructure
覆盖 R7/R9/R13/R14。建立持久快慢任务、输入与检查点、取消/恢复/幂等、对话内卡与工作区同源;修正 RDM 普通文本入口和插件工具投影。
文件:RDM slow.go/slowledger.go/plugin/web;Backend 公共任务/HostFactory/事件面;现 slow_persist_test.go 加真实恢复语义,新增 task_recovery_test.go 与对话路由用例。
测试:跨刷新/重启/断网恢复;任务接纳后权限撤回;重复取消/确认;模型超时与外部结果未知先查询;seq 乱序丢弃;普通自然语言不触发空值异常,查询不落写任务;持久记录与页面计数同一状态。
出口:任务失败、部分完成、待确认、恢复中均可见,后台工作不会在进程重启后仅静默丢失。
### U10. Stage Gates and Project Closure
覆盖 R10/R11/R12/R13。阶段配置、推进/回退/结项、文档提交门禁、条件性不适用和决策快照;与内容/合规规则共用判断结果。
文件:RDM projects、baseline.go、review 服务、plugin;新增 stage_transition_test.go/document_submit_gate_test.go 与生命周期浏览器路径。
测试:有资料但未满足内容要求不能提交;无关候选边不误阻断;必需验证缺失/过期阻断;合法不适用可经有权者确认;上传不催缺项;陈旧推进卡和并发阶段变更拒绝;结项后只读与受控恢复。
出口:用户从立项到结项均可通过对话完成,不靠管理者手改状态。
### U11. Requirements and Compliance End to End
覆盖 R8/R11/R12/R15。实现需求分解/六维分类、风险/验证/确认/SOUP 业务录入和版本生产,合规边建议/确认、完整性规则、四链视图、审计展示与精确快照导出。
文件:RDM requirements.go、compliance.go、cderived.go、chainviews.go、cgraph_export.go、plugin/web;新增 producer_to_graph_test.go/compliance_replay_test.go;复用既有合规测试而不只域层播种。
测试:真实命令新增/升版需求到图、分解来源可追、候选边不能自动生效、风险控制缺验证、验证版本不一致、SOUP 标记、旧快照查询/导出相同、受限端点不泄漏、规则版本变化导致缺口重新评估。
出口:已有读模型真正有生产数据;专家校准意见、规则版本与证据映射齐备。全图视图保持渐进,不强迫用户操作大图。
### U12. Real External Evidence
覆盖 R7/R11/R15 与 UR-13/14。真实法规知识库与网络双通道,外部资料入树,冲突和降级明确;模型答案与取得的网页原文分开。
文件:RDM regcheck.go/domain/regcheck;Backend 公共搜索/抓取接入(有则复用);regcheck_test.go 扩展真实受控来源回放及失败样本。
测试:模型编造 URL、链接不可达、标准版本不一致、两通道冲突、仅单通道、来源权限撤回、摘录与正文不符;均不能显示双通道已核验。
出口:每条外部结论有实际检索/获取记录、原文快照和支持关系;外网不可用时仍可工作但不伪称核验。
### U13. Team Runtime and Isolated Execution
覆盖 R14 与 SR-G16/SR-N1/N4/N5。复用团队存储计划,把 RDM 领域数据纳入 PG/事务/任务恢复;实现隔离执行档、资产发布包、备份恢复/迁移回滚和运行可观察性。
文件:RDM domain/store、projects/members/perms、原件/慢任务存储;Backend/Squad/Native 对应公开边界;migrations、安装/升级清单;新增 rdm_pg_test.go/rdm_multi_instance_test.go 与隔离执行黑盒用例。
测试:SQLite→PG 干跑/核对/失败回滚、旧库名称冲突、原件与 DB 一致恢复;双实例同名/同文档竞写、epoch 过期写入拒绝、重连追赶;执行不能越目录/越项目/读秘密/超资源;取消后子进程停止或进入明确恢复状态。
出口:先单实例团队版通过,再开放双实例;使用脱敏固定数据集,记录容量阈值而非仅声称支持 100 人。
### U14. Full Acceptance and Operational Delivery
覆盖 R1–R15。逐条重放需求矩阵、全部文档、真实三用户/两项目、真实模型、真实浏览器、自举与安装包;接上固定 HEAD CI 和独立重放。
文件:RDM docs/requirements/09、业务 E2E/fixtures、CI、release manifest、安装/回滚/恢复说明;Dev 组合记录;新增最终验收台账,不篡改历史原始收据。
测试:上述正常/拒绝/故障全部场景;真实自举材料不能由测试临时编造“支撑资料”;全部上线模板实际打开产物;项目/私域/职责隔离、性能、重启恢复和安装包离线资产校验。
出口:每条声明绑定命令、精确对象、输出和来源;业务完成、合入、部署、用户验收分别签收。用户当前实例在部署阶段明确选定,先备份再切换,不擅自清理旧进程。
### U15. Remaining Final Goals
| 原目标 | 完整路线与本轮去向 | 前置/责任与完成判据 |
|---|---|---|
| F-01 飞书全套 | 渠道、身份绑定、权限映射、虚拟人、文件/版本链接 | 核心授权和固定文档快照先完成;独立连接器任务固定外部租户/权限/凭据;外部回调不能绕过同一三权和资源权限 |
| F-02 完整变更流程 | 按公司流程选择系统内流程或外部集成,七步闭环逐项有对象和状态 | 先评审业务权威及外部 owner;实施追溯的申请、影响、评审、批准、执行、验证、关闭;当前影响提示不冒充闭环 |
| F-03 精细分享 | 保留显式授权与撤销;会话/部分会话分享仅在用户再次明确启用后开放 | 本轮私聊私有为硬默认,不能以最终扩展名义自动共享;范围、接收者、版本及撤销语义需独立批准 |
| F-04 时间权重 | 内容新旧、版本、来源质量可配置排序,冲突仍由人裁决 | U5/U6 后,固定检索评估集及配置版本;效果对照和公平覆盖达标,不靠“越新必正确” |
| F-05 代码工具 | GitLab 等只读代码、版本、缺陷与需求关联 | 外部仓库授权与读取契约、可验证 commit 绑定;不包含擅自写代码/推送权限 |
| F-06 交互收敛 | 纳入 U9/U14:看板、卡片、领域工作区同源 | 单一状态所有者、刷新/事件/撤权一致、右栏关闭无能力缺失 |
| F-07 遗留决策 | 重建 Q/O 决策台账,逐项定论或保留具体阻塞 | 不能把问题组当已确定功能;阶段划分、专家规则、对抗验证形态等按来源和裁定处理 |
| F-08 难度与人机边界 | 评估表、任务分工建议、人工为主的降级、独立质量检查 | U7/U9 后,明确谁评估、输入和证据;高难任务不伪装全自动完成,人工意见留痕 |
| F-09 追溯可视化 | 按 10 月 11 日已批准展示方案纳入 U11/U14 | 项目树/一跳关联/审计时间线/四链与矩阵可用且鉴权;不是继续无限延期 |
| F-10 公司标准模板 | 用户提供后按 U7 模板发布/映射/差异迁移机制替换 | 需实际模板文件及评审责任人;旧文档版本保留,标准模板逐份真实生成验收 |
这些目标没有被删除。F-01/02/03/05/07/08/10 所需外部授权、组织裁定或输入未齐时,分别记阻塞对象与责任人;核心已有能力可继续交付,但最终全范围不得提前关闭。
---
## Verification Contract
本轮仅调查与文档验证;业务 PASS 一律不得由本方案文字推断。
| 验证层 | 范围与工具入口 | 证据与退出条件 |
|---|---|---|
| 资产和静态 | 需求矩阵、模板契约、安装包资产 | 34 UR/68 SR/10 F/69 模板全部有去向;链接、schema、版本和文件均可核 |
| 领域单元 | RDM `make test`、针对变更新增拒绝/边界/故障用例 | 事务/职责/版本/门禁明确正确;mock 只证明机制 |
| 总线/公开契约 | 注册 schema→可信身份→handler→领域服务;实际工具投影目录 | 不绕过 schema、登录与权限;旧命令和 UI/API 同一行为 |
| 持久集成 | 真实 SQLite/PG、原件/索引/任务、进程故障重放 | 无已确认数据丢失/静默重复生效/跨项目泄漏;迁移和恢复可复核 |
| 用户全链路 | 真实三权账号及普通成员、两个项目,真实浏览器 | 立项、分配、私有上传、发布知识、生成、审签、导出、阶段推进;刷新/重启/撤权一致 |
| 模型任务级 | 固定素材与版本,前后对照并保留真实调用 | 正确模板/来源、冲突与空缺诚实、权限不越界;人工盲审语义支持,不只看引用 ID 存在 |
| 交付文件 | 实际 DOCX/XLSX 与 Office/LibreOffice 打开 | 内容、表格、格式、来源、签署和快照一致;报告不能编造真实测试结果 |
| 运维与容量 | 固定环境,10→30→100 用户阶梯与故障演练 | 以已批准存储方案量化合同及 SR-N1 为准;预算和数据规模公开记录,跳过的 PG/Redis 项目不算通过 |
| 正式准入 | RDM 与 Dev 固定组件 SHA、CI 链接/身份、独立重放 | SELF/GATE/REPLAY 分开;本地通过不能代替人工评审、平台准入或线上验收 |
关键用户验收样例:
1. A 创建项目,B 同名创建被拒;A 加入 B/C/D 后大家看到同一个项目,彼此会话仍不可见。
2. 平台允许成员管理但禁止某动作,A 的项目 override 不能放大;管理员撤销上限后旧任务和旧卡片也失效。
3. B 上传私有原件并发布一段经确认知识;C 可使用该知识而不能打开 B 的原件,D 的搜索、计数、摘要不泄漏它。
4. A 指派 B 编制、C 审核、D 批准;B 生成,C 只能批注;D 等全部审核通过后批准,A 不能凭负责人身份代批。
5. B 在审核中改正文、切换成审核人后自审、旧卡批准新版本、跨项目伪造 sectionId 均被服务端拒绝。
6. 资料升级但文档未变,看板仍显示依据更新;编制人选本文档依据不自动改变共享结论。
7. 断网/重启后恢复同一任务与提案;重复采纳只有一次内容版本;版本写入或建边失败不出现半条追溯。
8. 已批准旧快照与当前修改并存,导出旧正式版仍得到旧内容/旧依据/旧签署;合规报告使用同一水位图和 hash。
9. 69 类模板及报价 XLSX 分批全部真实验收;没有资料的报告不生成不存在的实验/测试结果。
## Definition of Done
当前方案阶段:用户关键口径准确落盘,所有原需求与后续目标有追溯映射,源码差距与运行未知分开,工作包含依赖、责任模块、文件、验收与停止条件。
核心产品 C1:U1–U14 及 U16 对应矩阵证据全部齐备,真实项目管理、隐私协同、全部文档三权与导出运行可用;没有把历史桩测试当真实验收。
最终目标 C2:U15 每项实现验证,或用户明确取消/替代并更新权威需求。只“已备案”或“后移”不能关闭最终目标。
正式上线:固定目标实例和制品、完成迁移/备份/恢复/回滚验证、取得对应部署授权并通过用户运行验收;上线与代码合入分别记录。
优先下一步为 U1:固化本次总体范围、修正基线/证据口径,并细化 U2/U3 的项目与资源授权公开契约。其直接解决当前用户无法管理同一项目、创建者无法完整配置三权、私域与共享层可能混用的问题。
本轮“所有文档都加入并实现”和“三权要实现”已作为明确交付要求记录;由于同时要求先完成全系统目标核对和完整方案,本轮停在可评审总体方案,不把尚未评审的新跨仓/权限设计直接实施。
### Decisions Still Required
用户已确认的 D1–D6 不重复请求。仍需评审的是本总体方案的技术路线、U1–U16 分工和交付边界;实施前固定目标运行实例、团队部署档及具体负责人。
进一步阶段合并、外部完整变更流程归属、外部系统租户/凭据、公司标准模板和专家校准结果有明确后续依赖,不阻塞当前项目/权限/模板地基工作;未齐备时不伪造完成。
各阶段沿 `Dev:policy/delivery.md` 人工评审;若后续要求连续实施,应明确覆盖的阶段和终点,发布、保护规则变更等双钥匙边界继续保留。
## Appendix
原始来源:S:35–76 与 D:75–88;RDM requirements/README、00、01/03/04/08/09/10;U0、V2.2 已批准裁定。矩阵中给出每条需求的原文位置。
设计依赖:两树一网展示方案 r1、多人存储方案 r1、模板对话生成方案及 69 类资产盘点。涉及 API 的名称均为候选设计,正式符号由公开契约申请确定。
本轮没有联网核验法律或标准条款,也没有声称系统已符合任何特定法规;本方案讨论项目既定需求、数据追溯与实现验收。
@@ -0,0 +1,399 @@
---
title: RDM 基于模板与两树一网的对话文档生成方案
type: feat
date: 2026-10-11
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: legacy-requirements
---
# RDM 基于模板与两树一网的对话文档生成方案
修订:r1.1,首批顺序已确认,其余方案待用户评审。需求负责人:weichen;方案编制:Codex;实施负责人:待立项指定。
本轮授权终点是调查和方案;业务实施、模板迁移、模型试验、部署与运行验收均为 NOT_RUN。
本文件为模板生成子方案正文;总体范围、最新现状及优先级以[最终目标完整交付方案](2026-10-11-rdm-final-target-completion.md)为准。任务记录:Dev `.task/feature-rdm-template-dialog-plan.md`。
本案资产/代码表固定于 RDM 0081628a;本轮期间 d8d7e743 已新增项目绑定、部分命令授权和管理员引导修复,增量差距见总体方案,不再把旧表当作最新全系统状态。
路径前缀约定:`RDM:` 指 Agent-System-RDM;`Legacy:` 指旧 Agent-System;`Dev:` 指 Agent-System-Dev。
## Goal Capsule
用户在项目对话中说出需要编制或更新的文档,系统选用明确版本的模板,从该项目有权使用的知识与文档中组织依据,生成可审阅、可追溯、可继续修改的草稿;编制人确认后形成内部版本,再经三权流程产生可导出的正式文档。
推荐在已有 RDM 插件内补齐生成闭环,复用基座的模型、任务、卡片和工件能力。模板决定文档结构与格式;笔记树提供知识;文档树承载文档及章节版本;追溯网记录依据、派生与影响关系。
本方案涵盖 69 类历史文档资产的接入路线,首批用项目建议书和竞品分析验证完整链路,再扩展全部文档。此顺序已由用户于 2026-10-11 明确确认:“先打通项目建议书、竞品分析,再扩展全部文档”;需求、设计、验证和其他文档族的后续批次仍待细化。
实施前先评审本方案及与既有两树一网方案的任务分工;任何设计批准不自动包含迁移、发布、合入或部署授权。
---
## Product Contract
### Problem Frame
系统确实有大量历史模板,但当前 RDM 的文档类型目录、模板注册表、章节树、对话命令和导出器尚未形成一致的产品路径。
需要解决的是“用户能在对话中可靠地编制整份体系文档”,不能以模板文件存在、命令注册或模型返回一段正文作为完成标准。
### Current State
调查为 SELF·源码与资产检查,未查询业务数据库、未登录应用、未做真实模型或浏览器验收。
命令原始输出和对象 SHA 经 `make evidence` 记录于任务卡;静态控制流推导与运行结果分开。
| 对象 | 本次调查基线 |
|---|---|
| Dev | `95992d751f0a6ea8e345109dbb6b9367d9055e92` |
| Dev Backend | `3def5259023806a49ab84f885b7d220333cccde6` |
| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
| 旧 Agent-System | `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` |
| RDM Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
Dev 与 RDM 实际依赖组合不同;不能以 Dev 最新扩展已存在推断下游已接通。
| 资产/能力 | 盘点结果 | 含义 |
|---|---|---|
| 旧 Markdown 业务模板 | 69 份:bd 7、rd 60、pm 1、tm 1 | 是可复用的历史内容资产 |
| 旧报价 XLSX | 1 份 `templates/xlsx/cdo_quote.xlsx` | 单独登记,不并入 69 个 Markdown 文档类型 |
| RDM 文档类型字典 | 69 个,与旧模板文件名集合一致 | 目录已迁入,不等于模板已迁入 |
| RDM 注册模板 | 4 个,均为 v1 | 项目建议书、竞品分析、周报、评审纪要 |
| 已绑定文档类型 | 3 个:`rd_proposal`、`bd_research`、`rd_design_plan` | 其余 66 种未绑定注册模板 |
| RDM 自举文档树 | 10 份文档、22 个章节 | 是一个自举项目结构,不是 69 类的通用实例化 |
| 章节生成 | `Compose` 调用 `Host.Complete` | 已有真实模型调用路径,运行质量未验证 |
| 写入/审签/导出 | 有 apply、版本、三权域模型和 DOCX 代码 | 需补端到端契约与运行验收 |
资产依据:`Legacy:templates/docs/`、`RDM:internal/domain/data/labels_seed.json:68`、`RDM:docs/templates/registry.yaml:4`、`RDM:docs/structure/rdm-self.yaml:1`。
| 模板 | 绑定类型 | 当前用途与问题 |
|---|---|---|
| `review-minutes@v1` | bd_research、rd_design_plan | 评审纪要,不应默认替代调研/计划正文 |
| `weekly-report@v1` | rd_proposal | 周报,不应默认替代项目建议书 |
| `project-proposal@v1` | rd_proposal | 业务正文模板,含内容要求与排版说明 |
| `competitive-analysis@v1` | bd_research | 业务正文模板,含内容要求与排版说明 |
当前关键缺口:
| ID | 源码事实或静态推导 | 对本方案的影响 |
|---|---|---|
| G1 | 两条编写 intent 只调用 templates.for,且传 project-proposal-v1/competitive-analysis-v1;该接口要求字典 docType(plugin.go:212–230,templates.go:127–138) | 自然语言入口参数不一致,尚不是完整编制入口 |
| G2 | RDM 命令未声明 exposeAsTool;实际 pin 的 EXT-14 仅投影显式声明命令(pins/.../internal/cmdbus/cmdbus.go:47) | 注册命令不等于模型可调用;须核对实际工具目录与 schema |
| G3 | Compose 模板开关可缺省;按第一个适用 key 选模板,读取失败静默返回空串(compose.go:17、63–85、150) | 可能选周报/纪要,或者无模板继续起草 |
| G4 | 单章提示词注入整份模板;章节结构另存 YAML,文档/版本无 templateKey/version/hash(compose.go:35–47,doctree.go:29–65) | 模板、章节和历史无法一致固定 |
| G5 | Compose 返回即时内容;apply 重新检索,固定 topK=8;skip 旧依据参与起草却不能进入 accepted,Basis 直接取 accepted(draft.go:93–108,writegate.go:158–186) | 候选漂移、旧依据丢失、无法固定确认对象 |
| G6 | 写版本后逐条建 supports 边(writegate.go:186 起) | 中途失败可导致正文与追溯不一致;复用既有原子事件工作项 |
| G7 | draft/compose/apply 仍可空项目回退,处理器缺少对应编制人检查(runtime.go:106,plugins/rdm/plugin.go:1645 起) | 上下文、生成和提交均须领域授权;只靠宿主 owner 不够 |
| G8 | approve/reject/final schema 必填 reviewer/actor/approver,处理器却拒绝这些参数(plugin.go:295–320、945–1001) | 总线契约矛盾;必须从真实分发入口验证审签 |
| G9 | 模板从工作目录或编译时源码路径读取;构建仅生成二进制(templates.go:45,prompts.go:42–52,Makefile:40) | 需验证安装包脱离源码仍能加载模板 |
| G10 | DOCX renderer 接收标题与章节,未消费模板排版规格;导出取章节当前版本(docx.go:155、298–306) | 排版要求未兑现,正式版需绑定整文批准快照 |
这些是实施前应验证和修复的具体断点,不声明现网已经复现。
### Requirements
| ID | 用户可见要求 | 来源 | 验收判据 |
|---|---|---|---|
| R1 | 对话中查询、选择并预览模板 | SR-C2、SR-E6 | 显示用途、版本、适用类型和可用状态;不混淆类型数量与模板数量 |
| R2 | 一句话编制整文或指定章节 | UR-11、F4、SR-E4 | 确定当前项目、目标文档、操作范围及模板后进入生成任务;歧义时澄清 |
| R3 | 文档结构来自固定模板 | SR-C1/C2、M5 | 文档绑定已发布模板版本;每章有稳定标识、内容要求、检索条件及顺序 |
| R4 | 只使用当前有权使用的依据 | SR-G2、U0 R09/R21 | 跨项目、私人未发布、待裁定、撤销资料不能进入共享生成正文 |
| R5 | 每段事实可回到实际来源 | UR-11、SR-D1/D6、08 R1–R5 | 引用能定位切片/结论/已有文档的准确版本与锚点,历史可复核 |
| R6 | 缺证据明确标出,冲突由有权者裁决 | F4、SR-B8/B9、U0 D4 | 不编造内容;文档层选择不改变项目共享结论;未裁决冲突不混入有效事实 |
| R7 | 草稿提案经确认才改正文 | F-B、SR-C4/C6 | 展示新增/更新/冲突与差异;确认对象固定;未接受内容不写入 |
| R8 | 保留已有正文与依据,支持增量更新 | UR-05、SR-C6 | 只修改用户选择范围;保留、增加、删除的依据与最终正文一致 |
| R9 | 编制、审核、批准职责与版本固定 | SR-C7/C8、U0 D2/D5 | 非编制人不能生成/改正文;提交锁定;审签绑定完整文档版本 |
| R10 | 长任务可查看、取消、恢复 | SR-F4、SR-B10、U0 R21 | 刷新/重启后看到同一任务;重复点击不重复生效;失败章节不冒充整文完成 |
| R11 | 输出可打开、下载、追溯的 DOCX | U0 R14、10 号定稿决议 | 内容、格式、引用及版本与选定草稿/正式快照一致;下载再次鉴权 |
| R12 | 旧模板逐份纳入可管理的目录 | 03 §7、SR-C2 | 69 份都有资产处置记录;已发布/待整理/不适用分别显示,不能批量冒充可用 |
| R13 | 对话、卡片、工作区使用同一状态 | SR-E6、U0 D7、DESIGN.md | 收起右栏仍可完成编制;陈旧卡片不能批准新内容;按 seq 丢弃旧事件 |
R1–R13 为方案候选范围,人工评审均未完成。R12 的登记全覆盖与各模板运行验收是两个阶段。
### User Flow
示例:“用已有资料生成这个项目的设计开发任务书。”
1. 从可信会话解析项目,辨认是新建、更新、只改某章还是查询;“总结一下任务书”不能触发写入。
2. 查现有文档与职责。已有同类文档时确认更新对象,缺模板或有多个正文模板时给出可选项,不随意选第一项。新文档无职责时保留请求为“等待职责分配”;有权负责人可在对话中指定异人的编制/审核/批准角色,其他成员可提出分配请求,由负责人处理。若当前用户不是编制人,则显示当前职责并允许转交编制请求,不把原私聊全文传给他人。职责就绪后由指定编制人接续同一目标、重验权限并确认启动,负责人不自动获得编制权。
3. 展示一张编制卡:文档名称、模板版本、章节范围、使用的资料范围、将创建草稿的效果。确认后启动任务;已明确提供的信息不重复询问。
4. 按章准备依据,必要时集中呈现冲突双方、来源、建议及理由,由相应角色裁决。
5. 后台逐章起草与校验;对话即时显示计划和阶段,允许继续讨论或取消。无材料章节注明待确认。
6. 完成后提供正文预览、逐章差异、来源和未决项;编制人可要求“只重写第二章”“采用这个依据”“保留现有市场分析”。
7. 编制人采纳所选提案后产生内部版本;提交审核时执行完整性检查并锁定完整文档版本。
8. 审核人和批准人分别以真实身份确认。完成后可导出 DOCX,继续通过对话查看来源或发起受控修订。
编制卡、冲突卡、差异采纳卡和审签卡是不同决策,不合并成一次模糊的“确认全部”。同一决策可以在对话与工作区投影,使用同一服务端对象。
编制过程中说明空缺不等于强制补齐所有字段;沿 SR-C5,资料上传阶段不推送缺项清单,正式完整性门禁只在提交审核/申请推进阶段执行。
### Scope Boundaries
本期设计复用现有模板,先完成内容与格式结构化、生成和受控落盘,再分批扩大覆盖。
标准模板替换沿 F-10,待系统测试后由用户提供;不擅自下载其他“官方模板”替代旧资产。
不把合规边有来源等同于满足具体法规;法规结论继续走既有双通道及人工复核,本方案不作标准符合性判定。
飞书对接、变更流程引擎、跨项目自动取材、无人审批、所有文档自动重写不纳入本次实施建议。
最新两树一网可视化方案已单列,生成能力不等待全局大图;文档引用浏览与项目审计中心沿各自权限开放。
---
## Planning Contract
### Alternatives
| 路线 | 收益 | 代价及结论 |
|---|---|---|
| 复用 RDM,补齐模板/候选/整文契约 | 保留已有知识、版本、审签与追溯,职责清楚 | 推荐;先修跨层契约,再扩模板 |
| 将旧生成系统整体搬回新系统 | 可快速得到旧模板和流程 | 会带回任务键绑定、多份目录及旧状态治理,不采用 |
| 把整份模板和检索结果直接交模型输出文件 | 演示快 | 难保证固定依据、增量更新、三权和恢复,只能用于隔离试验 |
### KTD1. Template Contract
将“文档类型”“模板资产”“项目文档实例”分开管理。
文档类型保留兼容键;模板使用 `templateId + version + hash`;文档实例使用项目内稳定 docId。
注册表是模板权威入口,避免再增一套手写目录;缓存和索引只能由它生成。
| 模板层 | 核心内容 | 执行方式 |
|---|---|---|
| 资产元数据 | 名称、用途(正文/纪要/汇报)、别名、适用类型、版本、生命周期、来源 SHA | 可查询、受控发布;禁止字典序判断版本新旧 |
| 内容结构 | 稳定 sectionKey、标题层级、内容要求、表格列、条件适用、允许缺省 | 编译为文档树实例与内容校验规则 |
| 依据规则 | 共享标签条件、资料类型、强制输入、可用结论/文档类型 | 编译检索计划;保留人工选择与审阅 |
| 格式规格 | 页型/页边距、字体、标题编号、页眉页脚、表格、引用呈现 | 由确定性 DOCX renderer 消费,不靠模型猜排版 |
| 发布清单 | schema 版本、资产哈希、依赖字典、审批记录、兼容范围 | 安装包自包含;运行时清楚报告缺失或不兼容 |
模板生命周期建议为 draft→published→retired。模板先评审再发布,再实例化文档树;同一已发布版本不可原地改写。
首期内置共享模板及默认绑定只由获批的仓库发布流程变更,模板发布权不继承文档编制权。普通编制人只能选择已发布版本。后续用户上传模板只形成待评审候选;运行时发布/退役/改默认的责任主体与项目或共享作用域须另行评审后开放,不能借上传模板修改其他项目规则。
普通编制人只选已发布版本,不因生成一次文档重复审批模板。退役不删除历史快照。
默认绑定使用“docType+purpose+显式 default”;候选多于一个且无明确默认则询问;用户指定模板优先,但须校验适用性。
用户指定“按模板生成”时,模板缺失/失效须停止该路径并解释,不能静默按自由文本起草。
更新模板不自动改已有文档;迁移章节映射、内容影响和格式变化以单独提案确认。旧文档保持原 templateRef。
### KTD2. Template Migration
建立 69 份历史模板的逐项台账:原路径与 SHA、对应类型、目标 key、用途、章节数、内容差异、格式要求、处置结果、发布与验收状态。
先保全原件与哈希,再拆出正文要求、管理信息、格式约束。追溯表、签署记录、缺项登记、已有材料摘要等管理信息进入相应台账或附属视图,不直接复制成正文章节。
模板提取可以由模型提出候选,但发布结构与章节映射须人工审核;不因 Markdown 有二级标题就认定它是合格模板。
10 份自举文档逐份做语义映射,避免仅凭原 docType 将“实施推进方案”套成“项目建议书”。已有内容只生成映射候选,不覆盖。
建议发布包内置受控资产 bundle;后续用户模板使用同一校验/发布协议,从受管目录或存储载入,禁止依赖编译机器的源码路径。
### KTD3. Three Structures and Context
每项目独立解析两树一网;共享模板通过固定版本引用,不建立跨项目业务边。
笔记树切片及结论提供内容;文档树章节提供输出目标、既有内容及版本;追溯网提供已有依据、取代关系、冲突和受影响对象。
检索先判权限和资料发布状态,再检索和排序,不能先读全库再让模型筛项目。
章节强制依赖、现版有效依据、已选结论及其原始 basis 应完整保留;其余素材用标签、语义、图关系合并、去重和有界排序。
语义路须传确定项目;知识 chunk 到领域切片建立稳定映射,不能同一原件只取第一个 slice。
超出上下文预算时分章节、分资料批次处理并保留覆盖账本;不得以 topK 截断后声称“已查全部资料”。检索降级向编制人可见。
新内容优先是排序线索,不自动推翻已生效结论;已废止、待裁定资料只能用于有权限的冲突说明,不能作为已生效事实。
私人对话原文不因关联项目就共享。模型从对话提炼的资料须沿既有发布/相关性边界进入共享知识;私有资料确需用于共享文档时,先获得明确发布授权。
模板、上传原文和引用资料是任务数据,不得提升为系统指令或扩大工具权限。
### KTD4. Durable Generation Objects
建议增加四类持久对象,字段名为设计候选,不是已发布 API:
| 对象 | 固定什么 | 主要作用 |
|---|---|---|
| GenerationRun | 项目、文档、编制人、会话、范围、templateRef、章节基线、知识水位、模型/提示词与检索版本 | 任务进度、恢复、成本与产出可追溯 |
| ContextManifest | 选中来源 ID/版本/hash/锚点、授权/发布依据、保留与排除集合、冲突裁决 | 解释实际给模型的材料,不保存隐藏推理 |
| SectionProposal | sectionKey、baseVersion、结构化正文、段落引用、差异、空缺、校验结果、状态 | 供人修改/比较/采纳;不改变生效正文 |
| DocumentRevision | 全部章节版本集合、模板与布局版本、内容/hash、依据集合、审批快照 | 固定整文审签和导出,防止“各章最新”拼装 |
段落引用持久化为稳定对象引用,短编号仅用于显示,必须保留编号映射。来源包括 slice、结论及依据、受控文档版本、模板版本、明确授权的外部材料。
引用存在性、项目归属、版本和采纳范围由服务端校验;引用能打开不证明语义支持,另用模型检查加人工抽验判断事实是否被证据支撑。
保留旧依据、增加新依据、移除依据分别记录,最终 Basis 从实际成文引用聚合并校验。用户取消某素材后,相关事实必须删除、重写或改为未证实,不能只删脚注。
人工修改提案后重新计算 hash 并校验;内容、选材或目标版本变化使旧确认失效。
### KTD5. Generation and Human Decisions
起草遵循“检索并固定输入→模型组织正文→结构/引用/冲突检查→持久提案→人工采纳”,允许模型自主拆任务和选择可用工具,受控写入口保持确定性。
现有 Compose 和 Gate 应重构复用,修正“仅有 skip 旧依据时被视作无素材”、旧依据不能保留等路径,不另起第二条正文写入链。
模板内容要求决定章节任务;不能把整份模板重复塞入每一章。独立章节可并行,共享术语/数据依赖按章节依赖顺序生成,最终做全篇一致性检查。
无法证实的数据不得补成事实。临时草稿允许“待确认”标记;正式版不能含未处理的必需项,处理方式是补证、明确不适用及有权确认,不能改规则绕过。
冲突分两层:编制人决定本文档引用哪条依据;改变项目共享结论由项目负责人或指定知识责任人裁决。后台模型不自动做这两个决策。
### KTD6. Authorized Atomic Apply
从可信请求身份解析 actor,不接受前端 actor/reviewer/approver 自报。所有生成、读取、确认、导出及旧命令统一经过领域授权。
生成开始、关键读取、恢复、结果投递和最终采纳时重验项目与职责;管理员/负责人不因角色高就自动拥有文档编制权。
apply 接收固定 proposalId、预期章节/文档版本、采纳范围和幂等键,不再重跑检索重建“当时的候选”。
事务内验证权限、版本和引用,原子提交版本、依据/追溯边、提案状态和领域事件;提交后更新投影。跨库宿主审计通过可靠 outbox 投递。
多章节整文采纳默认同一业务事务;用户主动选择部分采纳时,生成包含未改章节原版本的新 DocumentRevision,清楚标记剩余未采纳章节。
部分采纳先构造实际将保存的新旧章节组合,重新校验章节依赖、共享术语及关键指标一致性;后继章节依赖未采纳的前置改动时暂停采纳,列出必须一同处理的章节供编制人选择。校验绑定该组合的 hash 与版本;事务提交前再核对版本,不能沿用整份候选曾经通过的检查。
模型调用不占持久写锁;候选失效返回具体变化,保留提案供比较,禁止覆盖新版本或静默再生成。
断连/超时先按幂等键查询提交结果,再决定是否重试。跨库工件生成与领域提交不冒充一个事务,以导出任务和可恢复映射协调。
### KTD7. Conversation Tools and UI
RDM 提供模板查询/预览、文档实例化、生成准备/启动/状态/取消、提案查看/修改/采纳、提交审核、审签与导出能力;名称和 schema 在实施契约中固定。
先统一 docType/templateId/version 含义及 schema 与处理器身份约定,再将需要模型访问的命令显式投影到工具目录;保留确定性命令入口用于卡片与测试。
RDM 编制 skill 提供渐进说明与编制规则,业务权限与确认不靠提示词约束。skill 的新增/变更纳入真实模型任务级对照。
审签决策由指定人通过认证确认产生,Agent 只准备与呈递,不因用户一句模糊“继续”批准未展示的新版本。
基座负责通用模型路由、运行/卡片、工件字节、资源授权执行;RDM 负责模板、领域项目、资料发布、两树一网、提案、三权与版本。
公开面不足时按 RDM AGENTS 四要素提扩展申请;禁止下游导入 Backend internal 或修改 pins。
界面沿 `Dev:DESIGN.md`:对话为完整主入口,右栏“工作”看任务/待办,“文件”看文档;同一工件只有一个预览落位。
对话展示模板名/版本、章节进度、需处理事项、最终文件和来源入口,不直接倾倒 slice ID、事件 JSON 或内部工程术语。
一个服务端对象拥有异步状态,对话与工作区只作投影;按 seq 处理事件,刷新从服务端恢复,陈旧卡片显示已过期及原因。
UI 使用令牌、MotionKit、Collapsible 和安全 HTML 原语;无额外第四栏或新的平行预览器。
### KTD8. Review and Export
现有审签主要按章节实现;推荐面向用户升级为文档级职责与审签,章节审签仅作为可选内部协作步骤,不要求用户为每章重复三权操作。
文档提交时冻结 DocumentRevision:章节版本、模板、内容要求、依据及当时职责。后续撤权或职责变化使待处理授权失效或要求重新提交,不能接续旧签名批准新版本。
审核期间所有正文入口拒写;驳回回编制态产生新内部修订,不提前增加正式版号;原正式版在新正式版批准前仍可查看。
旧章节职责、审签和正式版作为原始历史保留,不自动合并为文档级授权或“已批准整文”。同一旧文档的章节可能由不同人编制/批准:转入新流程前由有权负责人明确文档职责;迁移清单列出旧活动审签,经有权人确认撤回后重提,未完成该处置的文档保持旧态只读查询并暂不启用新整文流程。首个文档正式版须重新完成整文审签;历史导出明确标识为旧章节版本集合,不冒充整文批准。
草稿导出清楚标记草稿。正式版导出只读取批准快照,不读取当前各章最新;正文、引用附录、签署元数据与格式使用同一快照。
DOCX 由结构化内容和布局规格确定性渲染,保存 artifact 与文档版本的关联。导出生成、预览、下载分别鉴权;权限撤销后已有任务不得继续泄露结果。
允许异步重试导出,不因文件生成失败回滚已获批准的文档状态,也不把导出文件反向作为领域内容权威。
### High-Level Technical Design
```mermaid
flowchart TB
U[项目对话或工作区] --> A[可信项目与角色解析]
A --> T[固定模板与文档目标]
T --> C[按章准备依据快照]
N[笔记树与有效结论] --> C
D[文档树及原版本] --> C
G[追溯网与冲突] --> C
C --> M[模型起草与确定性校验]
M --> P[持久提案和差异]
P --> H[编制人确认]
H --> W[原子写版本与追溯]
W --> R[冻结整文审核与批准]
R --> E[按快照生成 DOCX]
```
```mermaid
stateDiagram-v2
[*] --> Preparing
Preparing --> AwaitingDecision: 目标或冲突待确认
AwaitingDecision --> Preparing: 有权人决定
Preparing --> Generating: 输入固定
Generating --> Validating
Validating --> Proposed: 校验通过
Validating --> NeedsRevision: 检查发现问题
NeedsRevision --> Generating: 修订受影响章节
Proposed --> Applied: 编制人采纳及事务成功
Proposed --> Stale: 依据权限或目标版本失效
Generating --> Failed
Generating --> Cancelled
Failed --> Preparing: 重验后恢复
```
生成运行状态与文档审批状态分开。Applied 仅表示形成内部内容版本;随后仍需“编制中→审核中→待批准→已批准”,驳回回编制中,批准绑定固定整文快照。
取消只停止未完成任务,不撤销已经确认提交的版本;状态未知时先查事务结果。恢复重新取得受限 Host 与权限,不能序列化旧凭据或长期复用旧 Host。
### Dependencies and Assumptions
与 [两树一网集成方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md) 复用项目绑定/授权、原子事件、历史重放和可读引用能力,不建立第二套项目或审计服务。
该方案文档记录已批准,不能据此声称实现已经完成;本生成方案把相关能力作为实施前置条件,是否复用已合入实现以启动时源码和证据为准。
与 [多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md) 复用持久任务、事务与团队存储方向。RDM 仍需自己的事件/领域存储适配,不因基座使用 PG 就宣称 RDM 已支持多实例。
近期建议单实例完成两项目隔离和三人职责验收;团队多实例单独通过并发、恢复与迁移验证后开放。
基线更正:RDM requirements/README 已确认相关 V2.2 正文于 2026-10-09 合入定稿;正文残留“待评审”不推翻该裁定。本案新增实现契约仍待用户评审。
---
## Implementation Units
以下为待批准的分期,U-ID 只在本方案内有效;责任模块已明确,人员在立项时确定。每阶段均按 `policy/delivery.md` 人工评审,允许阶段内根据证据迭代。
### U1. Contracts and Asset Ledger
目标:形成完整资产清单与可运行入口的修复设计。覆盖 R1/R2/R9/R12。
范围:RDM templates.go、plugins/rdm/plugin.go、labels_seed.json;新增资产迁移台账、总线契约测试,复用 templates_test.go/templates_v01_test.go。
措施:记录 69+1 旧资产;统一类型/模板键、默认用途和真实身份字段;声明工具投影;确认现有项目/权限前置工作由哪项任务交付。
验证:两条中文编写请求匹配合法文档类型;同类型周报不抢正文模板;审签经总线可达且伪造身份拒绝;查询/总结不得生成;69 类处置无遗漏。
出口:资产及契约评审完成;未把全部模板标为可用。无需先搬迁所有正文。
### U2. Published Template and Document Instantiation
目标:模板成为结构与排版的唯一版本依据。依赖 U1;覆盖 R1/R3/R12。
范围:RDM docs/templates、rdmapp/templates.go、structure.go、domain/doctree.go、payloads.go/replay.go;新增 template_contract_test.go、template_instance_test.go、发布包资产检查。
措施:发布生命周期、稳定章节键、固定 templateRef、显式默认、版本比较、资产 bundle;两个已有业务模板先结构化,旧自举树做映射而非覆盖。
验证:v2/v10 顺序正确;缺模板明确失败;不同用途不误选;模板新版本不改历史文档;同名章节、可选章节、模板退役、无源码安装包启动均覆盖;普通编制人不能发布共享模板或修改其他项目默认。
出口:从两个已发布模板产生正确文档树,内容要求与导出规格可供后续步骤读取。
### U3. Context Snapshot and Durable Proposal
目标:固定依据并可恢复地起草整文。依赖 U2 及项目授权/读取边界;覆盖 R2/R4/R5/R6/R10。
范围:RDM draft.go、compose.go、fbhost/adapter.go、domain/fb/writegate.go;新增 generation.go、proposal_store.go 及相应测试,具体命名实施时固定。
措施:持久 Run/ContextManifest/Proposal;精确来源映射;章级计划与预算;固定模型/提示词版本;空缺与冲突单列;持续进度与取消/恢复。
验证:无素材、只有旧依据、只有冲突、多切片同原件、跨项目/私有资料、超长上下文、模型失败、检索降级、取消、重启、撤权,均有真实可观察结果。
出口:两份文档可形成整文候选,逐段回到稳定来源,刷新和重启不丢;尚未自动写生效正文。
### U4. Confirmed Atomic Document Revision
目标:采纳提案后内容、版本和追溯保持一致。依赖 U3 及两树一网原子事件能力;覆盖 R5/R7/R8/R9。
范围:RDM draft.go、domain/fb/writegate.go、doctree.go、eventlog.go、replay.go、review.go;新增 proposal_apply_test.go、document_revision_test.go、故障重放测试。
措施:固定 proposalId、CAS、幂等、保留/新增/删除依据;整文版本清单;统一编制权限;修正文档级审签;旧入口适配同一服务。
验证:两个标签页竞写、确认前版本变化、撤回依据、取消引用却残留事实、重复点击、写版本后建边失败、提交审核后旧卡片执行、部分采纳与整文导出一致性;只采纳后继章节而保留旧前置章节须被依赖校验拦下;迁移中同文档不同章节职责/正式版、审核中记录不得自动转成整文授权与批准。
出口:事务全成或全败;重放还原同一版本和引用;旧候选不会覆盖新内容。
### U5. Chat Workflow and DOCX Delivery
目标:用户仅凭对话完成首批真实编制闭环。依赖 U4;覆盖 R2/R9/R10/R11/R13。
范围:RDM plugins/rdm/plugin.go、编制 skill、web/app.js、docx.go;必要基座公开契约申请;新增总线全链路、浏览器与 DOCX 文件验证用例。
措施:准备/冲突/采纳/审签卡同源状态;固定模板与章节的编制配方;文档级审批快照;草稿与正式 DOCX;文件卡复用基座预览下载。
验证:三名真实用户分别编制/审核/批准,两项目隔离;无职责的新文档经负责人在对话分配后由指定编制人接续,非编制人只可转交;收起右栏完成全程;刷新/重启、陈旧卡片、下载撤权;实际 DOCX 标题、表格、分页、页眉页脚、引用可见且版本一致。
真实模型对照:固定同一批素材与任务,记录改造前后正确模板选择、必需内容覆盖、引用支持、编造事实、人工修订量、耗时与失败恢复;单测/mock 不替代此项。
出口:项目建议书和竞品分析经真实 UI 与模型完成,产物持久可见可下载;评审人独立重放。
### U6. Document Families and Legacy Migration
目标:按业务文档族逐批覆盖其余历史资产。依赖 U5,且每批模板先评审发布;覆盖 R3/R11/R12。
范围:RDM 模板资产/注册表/迁移台账及模板契约回归集;参考 Legacy:templates/docs,不再依赖旧工作流实现。
推荐顺序:用户需求与系统/软件需求→设计任务与计划→设计方案与记录→验证/确认与测试→评审/风险/其他体系文档;精确文档名和批次以 U1 台账与用户优先级确认。
验证:每个上线模板至少一个有材料的完整生成例和一个空缺/冲突例;每类特有表格、引用及 DOCX 规则有针对性验收,不能只跑注册表计数。
出口:69 类均有明确结果,所有声明已支持的类型通过对应验收;不适用由人裁定,未交付保留可见状态。报价 XLSX 单列,不偷换为 DOCX。
---
## Verification Contract
测试在后续获批实施阶段执行,本轮结果全部 NOT_RUN。源码检查只能证明路径存在与静态矛盾,不能证明真实编制体验。
| 层级 | 对象与方法 | 必须证明 |
|---|---|---|
| 资产 | 69 类迁移台账、模板契约校验、安装包 smoke | 类型/模板/默认/结构/格式一致;没有源目录依赖 |
| 单元与领域 | RDM `make test` 的 Go 测试;模板、检索、版本、权限、状态机测试 | 正常、拒绝、边界、依据保留与失败事务行为 |
| 总线与工具 | 真实注册表→schema→认证主体→处理器→领域服务;实际模型工具清单 | 文本入口与 UI 共用真实可达能力;审签身份无自相矛盾 |
| 持久集成 | 实际领域存储、原子事件、重启重放、幂等与并发故障注入 | 内容/引用/审批不出现半完成;未知结果可查 |
| 浏览器 | 真实三用户、两项目、对话+卡片+预览+下载;现 `make test-web` 只作局部辅助 | 刷新、断连、重启、权限变化后结果仍正确,右栏关闭不丢操作路径 |
| 模型行为 | 固定素材和模板的任务级前后对照、人工盲审结果 | 模板选对、事实有支持、缺项诚实、未授权内容不出现 |
| 交付物 | 解包检查 DOCX OOXML+实际 Office/LibreOffice 打开检查 | 正确内容、格式、表格、引用和批准快照;不能只检查扩展名 |
| 跨仓 | 固定 RDM pins 与 Dev 公开契约 SHA,相关 CI 及独立重放 | 下游实际组合可运行,禁止用另一组组件证据替代 |
首批硬判据:所选模板/version 必须正确;持久引用全部存在且在授权范围内;负向越权与静默基线覆盖为零;已声明完成的章节无未标注的证据缺口;相同幂等请求只生效一次。
“引用存在”与“语义支撑”分别评分。测试/验证报告不得虚构执行记录、测量值或通过结论;无实际执行证据只能生成计划、空表或标注未执行的报告草稿。
耗时、费用、引用支持率和人工修订量先建立基线,再由用户确认可接受阈值;上传首轮 60 秒指标不套用为整文生成时限。
项目审计中心权限沿既有两树一网方案;编制人可查看完成本职责所需且有权访问的引用,不能借生成工具读取整个项目审计或他人私聊。
证据分 SELF/GATE/REPLAY;正式验收固定对象与环境,按仓库要求经 evidence 记录,不把模型自评作为独立通过。
## Definition of Done
本轮方案交付:资产盘点、关键源码断点、需求与方案、分期和验收可追溯,待决事项与未执行内容明确;本地方案尚未获得人工批准。
业务完成:U1–U5 首批真实闭环有完整证据;后续 U6 每批独立验收和发布,不把首批成功写成 69 模板全部可用。
上线声明另需固定安装包、目标实例、迁移/恢复记录及运行验收;当前没有上线声明。
建议下一任务是 U1 的契约核对与模板台账,而不是直接批量生成 69 份文档。先复核远端在途任务,和两树一网授权/事务工作项分工;本建议不启动实施。
### Review Decisions
请评审以下具体选择:
1. 采用“RDM 内补齐闭环+69 类资产分批接入”的路线,复用现有模板内容。
2. 首批项目建议书、竞品分析,随后扩展全部文档——已确认(session-settled: user-approved,2026-10-11,用户对首批优先级问题的回复)。后续各文档族之间的顺序尚未确认。
3. 以文档级版本快照进行三权审签,章节作为生成、差异与增量采纳单位。
4. 固定模板和依据后生成持久提案,编制人确认才写入;标准模板替换仍待用户后续提供。
第 2 项首批及扩展方向已确认;第 1、3、4 项及完整实施/测试计划仍待评审。本次优先级确认不构成业务实施、迁移或部署授权。计划中确定性契约与测试细节可在评审意见内迭代,改变权限/模块职责/范围时重新评审。
## Appendix
主要依据:
- RDM:docs/requirements/01-用户需求与系统需求.md:UR-11、SR-C1–C8、SR-D1/D6、SR-E4/E6、SR-F1/F4/F5、F-10。
- RDM:docs/requirements/03-产品设计方案.md:M5/M6/M9/M10、F4/F6、§7 旧版 69 模板处置。
- RDM:docs/requirements/08-核心数据模型-两树一网.md:两树职责、共用标签、F-B、R1–R5、模板来源维度。
- RDM:docs/proposals/2026-10-08-U0-baseline-and-shared-contracts.md:项目共享、三权、两层冲突裁决、固定版本和对话同源约束;其中旧源码缺口已重新核对,不原样当作当前事实。
- Dev:DESIGN.md:对话优先、工作/文件双入口、一个状态所有者、一个预览落位。
- 本目录 2026-10-11-rdm-two-trees-trace-audit-integration.md 与 2026-10-11-collaboration-storage-and-distribution.md:本方案的授权/事件/存储依赖;不复制作另一条实施主线。
完整资产目录见 [模板资产盘点](../records/2026-10-11-rdm-template-inventory.md)。目录仅报告源码资产状态,不包含线上项目的实际文档数量。
@@ -0,0 +1,401 @@
---
title: RDM 两树一网集成、完善与追溯审计展示方案
type: feat
date: 2026-10-11
execution: code
artifact_contract: ce-unified-plan/v1
product_contract_source: ce-plan-bootstrap
---
# RDM 两树一网集成、完善与追溯审计展示方案
修订:r1(2026-10-11 并入用户裁定);确认状态:用户评审通过(2026-10-11,需求拆解至实施计划五阶段一并,含 KTD4 双层管理员裁定);推进状态:U1–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;所有建议接口名均为候选契约。
关联任务:Dev `.task/feature-rdm-two-trees-audit-plan.md`;本文件是本次方案唯一正文。
## Goal Capsule
推荐按**每项目一套笔记树、文档树和追溯网**管理,在现有 RDM 实现上补齐隔离、历史完整性和产品入口。
项目创建者查看自己创建项目的追溯审计;RDM 域管理员与基座超管(基座 isAdmin)查看全部项目。
管理员使用跨项目目录和筛选器进入各项目,默认不展示混合的全局关系大图。
本轮只交付现状、方案和实施验收计划;方案已于 2026-10-11 获用户评审通过,业务实施与数据迁移仍须另行立项授权。
项目独立是数据归属、授权、版本和查询范围独立,不要求每项目部署一套服务或建立一个数据库。
先用一个项目跑通业务闭环,同时用第二项目验证隔离;管理员全项目目录与历史导出随后接入,本批默认范围为 U1–U5。
---
## Product Contract
### Current State
**结论:已经实现相当一部分,适合做集成与完善;尚不能认定为满足本次要求的完整产品。**
调查基线(SELF·源码检查):
| 对象 | 固定提交 |
|---|---|
| Dev 集成仓 | `5771d4f1e5b692bce95eb64cc30dc9931079ad12` |
| Dev Backend | `ea4651b1f870d84ab9b72cfa79363b3432d113b3` |
| Dev Frontend | `3ed10e122042a64180fb24a42d9cc6438cd2d2d6` |
| RDM | `0081628a10ec48a36537c6eced11a57439c986fa` |
| RDM 实际 Backend pin | `421fee81c314c05530bc809e224b5d0818ec3472` |
| RDM 实际 Frontend pin | `84b73ab32848e623d0a0ab7ade552784dca8cf3c` |
Dev 当前源码与 RDM 实际依赖不是同一组合,升级前须分别核验公开契约。
本次没有运行业务测试、登录服务、读取业务数据库或进行浏览器验收;下列“已有”指源码存在,不能转换为“已部署/已验收”。
命令、对象 SHA、原始输出和远端在途查询由工具保存于[调查收据](../records/2026-10-11-rdm-two-trees-source-receipt.json);收据为 SELF,不是 GATE 或独立 REPLAY。
| 对象 | 源码现状 | 本次需要补齐 |
|---|---|---|
| 笔记树 | `RDM:internal/domain/notetree.go` 已有骨架、切片、锚点、标签、多点挂载、软删除;树是浏览骨架,切片可多挂载 | 独立浏览和详情读取接口;完整树导航;层级与挂载一致性 |
| 文档树 | `RDM:internal/domain/doctree.go` 已有文档、章节、正文版本与依据、状态;已有基线和审签能力 | 树式浏览、真实版本元数据、来源与变更联动 |
| 一般追溯网 | `tracenet.go`、`rdmapp/trace.go` 已有关系生命周期、邻域、多跳和图查询 | 端点完整性、同项目约束、版本定位及统一读模型 |
| 受控合规图 | `compliance.go`、`chainviews.go`、`cgraph_export.go` 已有受控节点、版本边、链视图、矩阵及导出 | 与一般关系网整合展示;补重放一致性和历史快照 |
| 项目分片 | `events.project`、`WorldFor`、按项目重放已经存在 | 清除外部入口的空项目全量回退;贯通基座项目与 RDM 项目;端到端鉴权 |
| 结构历史 | `eventlog.go`、`replay.go` 已有 seq、操作者、时间、来源、payload 和重放 | 原子批次、幂等、完整状态还原、对用户可读的时间线 |
| 现有界面 | `RDM:web/app.js` 有基线表、章节弹层、SVG 追溯图和多跳高亮 | 缺独立笔记树、统一审计页、完整项目上下文;合规图与导出尚未接入 Web |
| 基座审计 | `Host.Audit`、`audit_events`、`command_audit` 已有通用记录 | 缺显式项目作用域、结构事件关联、跨项目管理员查询及稳定分页 |
旧 `RDM:docs/design/data-model.md` 中“当前单 World、需求无产生路径”等结论已被后续代码改变,不作为当前缺口依据。
旧追溯网和受控合规图目前是分别维护的边集合;共用事件日志不等于已有一张覆盖所有对象的完整网。
### Material Gaps
以下为源码事实及控制流推导,失败/越权场景尚未动态重放。
| 编号 | 问题与依据 | 影响与处理 |
|---|---|---|
| G1 | `runtime.go:108` 空项目返回全库重放的 `rt.World`;`plugin.go:737` 的 trace/graph/hops 未检查 actor;实际 pinned Backend 的 `compiled.go:31` 和 `cmdbus.go:228` 没有领域项目授权 | 只隐藏页面入口无法隔离;旧命令、工具、图、计数、详情、导出均须使用同一服务端策略 |
| G2 | `web/app.js:69,170` 使用基座项目,命令不自动注入领域项目;`projects_api.go:43` 列出全部 RDM 项目 | 必须先建立项目身份绑定及授权后的目录,不能依赖前端选择器过滤 |
| G3 | `projects.go:18` 的 CreatedBy 与 `members.go` 的 owner 角色分离;`rdm_admins` 与基座 isAdmin 分离 | 按创建者事实授权;不能用“负责人”“成员”替代创建者;审计可见性按 KTD4 双层口径(基座超管+RDM 台账域管理员)执行,域管理员不因此获得平台管理权 |
| G4 | `notetree.go:77` 的入库/挂载逐事件提交;`tracenet.go:67` 的 candidate/confirm 分开提交;`Retag` 等先改内存再写日志 | 中途失败可能遗留部分事件或内存/数据库不一致;先补事务批次和提交后投影 |
| G5 | `compliance.go:170` 升版标 stale,但 `replay.go:230` 未对等重建;快照事件仅保存计数/hash;`replay.go:379` 正式版审签重建缺少时间/操作者 | 重启和历史回看可能与提交时不同;不得在修复前展示“历史已完整还原” |
| G6 | `conclusions.go:264` 取提案只有 id 没有 project 条件;`tracenet.go:59` 未校验关系端点归属 | 全部节点、版本、提案和关系必须在同一项目作用域解析;跨项目对象拒绝 |
| G7 | 成员/权限主要保存当前态;部分 `h.Audit` 错误被忽略;`review.go:95` 职责事件 Actor 使用受托编制人 | 补真实操作者与被操作主体分离、变更历史及可靠审计投递 |
| G8 | `Dev:modules/backend/internal/store/platform.go:187` 审计无 project 字段;命令审计按 owner/会话读取 | 不能按 target 字符串猜项目,也不能把创建者自己的动作记录冒充整个项目审计 |
### Requirements
用户明确的范围与权限优先于旧方案:RDM 负责领域,基座只补通用能力(session-settled: user-directed — chosen over 所有基座项目内建两树一网:用户选择完善 RDM)。
| ID | 需求 | 可判定验收条件 |
|---|---|---|
| R1 | 每项目独立两树一网 | A 项目查询、遍历、计数、详情、历史、导出均不出现 B 项目对象;跨项目建边被拒绝 |
| R2 | 仅项目创建者和系统管理员查看追溯审计 | 创建者可读所建项目;RDM 域管理员与基座超管可读全部;非创建者负责人、成员、非成员均不能访问审计能力;域管理员不因此获得平台管理权 |
| R3 | 展示来源与影响 | 任一支持的对象能查看来源、去向、版本与待确认关系,并打开有权限的证据 |
| R4 | 操作记录直观可读 | 能回答谁、何时、改了什么、为什么、结果如何;未知信息明确标缺失 |
| R5 | 历史真实且可重建 | 同一项目同一 seq 下,重启前后节点/关系/版本/审签/缺口一致;不可重建时明确报错 |
| R6 | 提交与记录一致 | 单命令多事件全部提交或全部不生效;重试不重复生效;并发覆盖返回明确冲突 |
| R7 | 简单、渐进展示 | 默认显示摘要、树和所选对象的一跳关系;不强制用户理解节点类型、内部事件码或原始 JSON |
| R8 | 可导出可复核结果 | 导出绑定项目、截止 seq、对象版本、规则版本、身份与生成时间;文件下载再次鉴权 |
| R9 | 复用现有能力和开发边界 | 保留 RDM 模型/计算/导出器,基座扩展经公开契约交付;无下游导入基座 internal |
| R10 | 历史数据及私人资料有清楚边界 | 未归属记录不自动塞入默认项目;项目审计不绕过私人原文访问控制 |
R2 约束项目审计中心及能返回等价审计数据的接口;普通文档阅读、协作、合法的引用展示继续遵守既有业务权限,不能顺手全部收紧为创建者专属。
模型工具同样受调用者权限约束,不通过智能体转述绕过审计读取限制。
---
## Planning Contract
### Key Technical Decisions
以下为待评审的推荐技术决策;只有显式 session-settled 标注的用户选择已在本轮确认。
- KTD1. **项目为隔离根,逻辑分区共享存储。** 查询及复合键携带实例域与 projectId;项目内对象采用稳定 ID,受控对象另带不可变版本。关系两端在同项目内解析,项目归属创建后不随意改动。共享模板/法规以固定版本引用或项目内快照进入,保留来源;第一版不建立项目 A 到项目 B 的业务边。
- KTD2. **复用两套图,通过读适配器形成统一项目视图。** 一般事实关系与受控合规关系保留不同确认及版本规则,避免一次重写两套存储。统一对象引用包含项目、类型、ID、版本、图层,防止 ID 碰撞或把不同版本误并为一个节点。`candidate` 显示“待确认”、active 显示“已确认/已生效”、retired 显示“已废止”;stale 显示“依据版本已变更”。不将模型候选画成已生效事实。
- KTD3. **一个服务端授权入口。** RDM 审计能力判定为“可信认证主体是 RDM 域管理员或基座超管(isAdmin),或等于项目 CreatedBy”。CreatedBy 固定;负责人调整不转移此权利。另设审计 read/export/history 能力映射,普通成员不能被项目负责人额外授予这些能力。权限异常拒绝读取,授权后的项目范围再进入存储,禁止先读全量后前端过滤。
- KTD4. **双层管理员:基座超管保底+RDM 台账域管理员。**(session-settled: user-directed — chosen over 两套真值完全分离与基座 isAdmin 单层直通:用户 2026-10-11 评审裁定)基座提供认证身份;基座 isAdmin 作为超管始终可查看全部项目审计,是跨项目审计的保底入口。RDM 现有唯一管理员台账继续判定域审计管理员:域管理员可读全部项目,但不因此获得平台用户/插件等管理权。基座管理区承载的 RDM 审计分区对两类管理员开放;capability 仍由服务端下发,前端只消费、不自行合并角色。历史身份不一致需显式核对,不自动提升为域管理员。普通 project.create 不自动引导域管理员;首个域管理员经受信部署引导产生,初始化唯一性由事务及数据库约束保证。台账为空、多管理员或来源不明时,域管理员路径关闭等待授权核对,超管保底路径不受影响。超管的审计访问同样落入动作审计并标记身份层级。
- KTD5. **基座项目与 RDM 项目显式一对一绑定。** 新增受约束的 hostProjectId 映射并带实例域;查询会话/工件所属基座项目后解析到 RDM 项目。不得用项目名称或默认第一个项目推断。两库创建无法单事务时用可恢复的 provisioning→ready/failed 流程和幂等标识,绑定未就绪不开放审计。EXT-8 共享资源检查使用映射后的领域项目,但不扩大成审计授权。
- KTD6. **项目命令原子写,事件为结构历史依据。** 在 RDM 存储事务内验证预期版本、端点归属与幂等键,一次提交整批事件、必要台账和 outbox;提交后更新内存投影。缓存失效或更新失败时重建,不暴露半新状态。关键事件落库失败则命令失败;跨库基座审计通过可靠 outbox 补送,不能用两次独立写入冒充事务。
- KTD7. **历史按项目+截止 seq 固定。** 可见水位只取已提交操作批次的结束 seq,时间按批次提交时间解析;显式 seq 落入批次内部时拒绝并提示可选的完整水位,不展示半次操作。保留当前全局 seq 的顺序语义,项目过滤后允许 seq 有间隙,不把它当作丢事件。快照保存完整节点/版本/边/审签/规则版本及哈希,含事件 schemaVersion;只有计数的旧快照不可作为恢复依据。未知事件版本须停止还原并说明缺口,不能静默跳过。
- KTD8. **先沿用单实例,再与团队 PG 方案衔接。** RDM 当前领域库仍是 SQLite,基座配置 PG 不会迁移它。先修事务和项目串行写入;团队档上线前将 RDM 权威事件/台账纳入有唯一写入 owner 的 PG 存储适配。多实例需数据库发号/并发控制及缓存刷新验证,不因基座支持 PG 就宣称 RDM 支持多实例。
- KTD9. **当前项目公开事实与私人过程分开。** 项目创建者能看项目审计,不因此得到成员私人会话/原件全文。内部重放载荷与对外审计 DTO 分离,原始 payload 不直接返回。摘要、正文、差异、历史快照和导出中的复制内容统一进行披露检查:当前来源 ACL 允许,或存在可核验的项目发布快照,方可输出。旧数据无来源/发布依据时默认遮蔽并标“来源受限/归属待核实”,不泄漏标题、摘要或路径。管理员看全部项目审计,仍不把凭证、模型隐藏推理或无关私聊放进审计输出。
### Architecture
```mermaid
flowchart TB
U[创建者:自己项目 / 域管理员与基座超管:全部项目] --> A[认证身份 + 审计能力校验]
A --> P[解析当前项目绑定]
P --> Q[RDM统一审计读服务]
Q --> N[笔记树与文档树投影]
Q --> G[一般追溯与受控合规图适配]
Q --> H[事件历史与完整快照]
Q --> B[基座动作审计:经授权关联查询]
Q --> V[同一追溯审计工作区]
```
两树说明“资料怎样整理、文档怎样组织”;关系说明“依据来自哪里、影响到哪里”;审计说明“谁在什么时候作出了什么变更”。
它们共用项目和对象身份,各回答一个问题,不要求用户先学习图数据库概念。
### Data and Event Contract
领域事件补足项目、operationId/requestId、真实 actor、actorType、被操作主体、对象版本、发生时间、提交 seq、原因、事件 schemaVersion,以及必要的前后差异。
一个 operationId 关联多个结构事件和基座动作审计;前端按一次操作归组,技术明细按需展开。
纠正错误通过新事件完成,保留更正者和原因;关系失效、软删除和权限变更不覆盖原历史。
权限变更审计保留当时的政策版本/决策摘要,便于解释过去为何允许;**现在能否查看**仍按当前权限判断。
前端自报审计只能标为客户端报告,不得伪装成服务端核实的批准或业务成功。
普通 hash 用于校验导出/快照一致性,不宣称具备防数据库管理员篡改或电子签名保证。
```mermaid
sequenceDiagram
participant C as 调用者
participant A as RDM命令应用层
participant D as RDM存储
participant B as 基座审计
C->>A: 项目、操作、预期版本、幂等键
A->>A: 当前授权与同项目端点检查
A->>D: 原子提交事件批次、幂等结果、outbox
D-->>A: 已提交seq及结果
A-->>C: 业务结果与可追溯操作编号
A->>A: 刷新或重建项目投影
D->>B: outbox可靠补送关联审计
```
基座暂不可用时,已提交结构事实继续保存,动作审计显示“同步中”;恢复后幂等补送。
关键业务规则需要同一库的证据记录才能放行时,在业务事务内保存;不将异步投递当作批准的前提已满足。
导出需先固定截止水位、检查完整性;审计关联仍缺失时明确标为不完整,正式完整报告应阻止导出或要求用户选择带缺口的草稿。
### Read Interfaces
优先通过现有命令总线及页面 SDK 提供 RDM 查询,所有入口落到同一应用服务;不另建绕过权限的调试 API。
| 候选读契约 | 返回内容与限制 |
|---|---|
| inspect.capabilities / inspect.projects | 可见项目、当前项目是否可审计、是否可跨项目;管理员全项目目录独立分页 |
| inspect.summary | 两树规模、待确认关系、缺口、最新动作、数据截止水位;不把缺失当作零 |
| inspect.tree / inspect.object | 树子节点分页;所选对象版本、出处、状态;只展开需要的分支 |
| inspect.relations | 方向、图层、关系状态、版本、深度;默认一跳,后续点选扩展;有数量上限和截断提示 |
| inspect.events | 按项目、对象、时间、操作者、动作、结果过滤,游标分页;可展开一次操作的差异 |
| inspect.history | 固定 seq/基线下的对象、关系和当时规则;缺少重放材料返回明确不可还原状态 |
| inspect.export | 导出同一筛选条件和截止水位;生成、取状态、下载都重新校验主体及项目权限 |
分页游标绑定项目/筛选条件/排序/权限版本,不能拿 A 项目游标读 B。
缓存、导出缓存及订阅键包含主体能力范围、项目和截止水位,撤权后不可复用旧授权结果。
异步数据只有一个状态所有者:项目切换取消旧请求并递增 generation,过期响应丢弃;事件按 seq 去重、有序应用。
### Base Extension Requests
先验证现有注册点能否组合;不足部分按 RDM 的四要素扩展申请办理,保持公开面可选、向后兼容。
| 场景 | 希望的通用能力 | 现有能力不足 | 兼容方式 |
|---|---|---|---|
| 创建者看项目内所有人的动作 | 审计 envelope 的 projectId、operationId、对象版本及按项目查询 | Host.Audit 只有 owner/action/target/evidence;按 owner 会遗漏其他成员动作 | 增加可选的结构化审计能力/接口,不直接强改所有 Host 实现;旧记录标项目未知 |
| 宿主页面展示 RDM 审计入口 | 插件提供当前主体的审计能力和可见项目,宿主提供可信身份与项目上下文 | EXT-8 只有资源共享读取布尔判断;基座 AdminZone 仅看 isAdmin | 新增可选的动作级 capability/provider;不改变旧资源授权器含义 |
| 私人来源与项目发布证据联动 | 已授权工件/版本链接与受限占位,导出后下载再校验 | 不能让全项目审计器任意扩大 owner-scoped Host | 复用现有工件访问契约,仅按实测缺口增加窄接口;禁止任意 owner impersonation |
两树对象、边规则、合规矩阵和领域重放保留在 RDM,基座不内置这些领域表。
---
## Display Design
### Entrances and Layout
项目创建者从当前项目菜单进入“追溯与审计”;RDM 域管理员与基座超管从管理区“项目追溯与审计”进入项目目录,选定项目后复用同一页面。
管理员选择项目后,审计工作区的项目上下文必须更新为实际被审计项目,所有请求与标题保持一致。宿主支持审计项目切换时,项目身份集中显示在宿主项目位置;宿主不能切至该项目时,审计页必须显示明确项目标题和“返回项目目录”,并避免让宿主旧项目标题被误认为审计范围。管理员目录显示项目名、创建者、最近活动、待关注数量。
第一版为只读审计工作区,审批、确认关系和编辑仍跳回原受控业务流程,不在审计页面创造第二套写入口。
页面保留四个入口:**概览、资料与文档、关联追溯、操作记录**。
左侧按需显示笔记树/文档树导航;主区显示当前选择;对象详情在页面内展开,原件仍进入宿主唯一文件预览区。
不叠加弹窗,不默认铺满全部节点。
| 入口 | 默认看到什么 | 深入查看 |
|---|---|---|
| 概览 | 已收集资料、已形成文档、需要确认的关系、需要补齐的证据;最近几次重要变更 | 点击数字进入带筛选的列表;明确“统计截至…”和“不完整”状态 |
| 资料与文档 | 笔记树:阶段→事项→主题→资料切片;文档树:阶段→文档→章节 | 同一资料多个挂载不重复计数;缺主题可显示未分类,不伪造层级 |
| 关联追溯 | 所选对象居中,左右分别为“来源依据”和“影响对象” | 列表优先;切换为局部关系图;合规链/矩阵在此页按需切换 |
| 操作记录 | 自然语言时间线,按一次业务操作归组 | 展开前后差异、批准依据、对象版本与技术记录 |
### Human-readable Trace
关系展示示意,实际节点与连线必须来自已保存数据:
```mermaid
flowchart LR
A[会议纪要中的原文] -->|支持| B[用户需求]
B -->|落实到| C[方案章节 v3]
C -->|由此验证| D[验证记录]
```
点选“方案章节 v3”后首先看到:这是什么、当前版本、依据哪几条材料、影响哪几项需求/验证、最近谁改过。
缺少验证记录时显示“验证依据待补齐”,不画虚构的完整链;候选边使用虚线和文字“待确认”,不能仅靠颜色区分。
“没有已知关联”与“尚未完成关系索引/本次查询被截断”分开呈现。
关系被废止后可在历史模式中看到;跨版本关系明确标注版本,不让 v4 的证据替代 v3 的事实。
### Audit Timeline
时间线示意:
- 10:32 张三将《需求说明》从 v2 更新为 v3;修改了“使用环境”章节,依据为评审纪要第 4 条。
- 10:41 李四确认该章节与 UR-012 的关联;确认理由为“已覆盖用户场景”。
- 11:05 王五批准 v3;点击可查看批准时的版本和证据。
每条默认仅显示时间、操作者、动作、对象、结果;“查看变更”再展开前后差异与理由。
后台归档、重试等技术事件默认归组收起,失败、拒绝、未知结果有文字说明;原始 JSON 不作为主界面。
Actor 为真实执行者,Subject 为被分配职责或被变更权限的人,界面不混写两者。
默认显示北京时间并注明时区,底层保留 UTC;历史模式顶部醒目标注“查看截至某时间/某基线的记录”。
### Interaction Boundaries
提供“当前/历史”切换,历史可选择时间或基线;从批准记录可直接打开批准时的版本。两树、关系与记录共用一个截止水位,“返回当前”恢复对象当前版本;对象已删除则显示删除说明,不切到同名对象。
对象名称支持搜索;树节点懒加载;记录使用“加载更多”;关系默认一跳,上限和截断状态由服务端返回。
加载、空项目、无权限、部分数据、同步中、历史不可还原、请求失败分别展示,不都渲染成“暂无数据”。
首屏不显示 SQL、事件 opcode、内部 UUID、hash;复制技术编号放在详情中。
推荐验收任务:创建者在三次主要点击内找到某章节的原始依据和最近修改原因;管理员能清楚确认当前查看哪个项目。
实现遵循 `Dev:DESIGN.md`:颜色/圆角/字号消费 `@ui` 令牌;折叠用 Collapsible;动效只用 `mk-*`;键盘可导航,状态同时有文字与形状。
优先在当前宿主工作区体系内以 RDM 插件页面提供,避免长期维护第二套静态工作台。
旧 `web/app.js` 保留过渡兼容范围,但图与审计能力接同一授权服务;最终页面交付形式在 U4 固定,不能假设在途 Generative UI 已能直接承载。
---
## Implementation Units
本批默认顺序:U1→U2→U3→U4→U5,按 `policy/delivery.md` 分增量评审。U6 是独立后续衔接项,不纳入本批完成条件。
U1 是首选下一任务;这份方案不构成启动它的授权。
### U1. 项目身份与读取授权闭环
目标/需求:R1、R2、R9、R10;依赖:方案已批准(2026-10-11)、KTD4 已按双层口径裁定;剩余既有项目映射盘点在立项时完成。
范围:`RDM:internal/projects`、`members`、`perms`、`rdmapp/runtime.go`、`projects_api.go`、`perms_api.go`、`plugins/rdm/plugin.go`、`web/app.js` 的旧客户端项目上下文;测试 `rdmapp/perms_test.go`、`sharding_test.go`、`plugins/rdm/plugin_test.go`;必要基座 capability 扩展单独申请。
建立显式项目绑定;增加审计读取策略和管理员受信引导门禁;统一包裹旧/新 trace、cgraph、项目列表、历史和导出入口。
U1 同批接通旧客户端的项目选择和命令封装,并解析可信会话/工件上下文到显式绑定;随后启用对外 projectId 必填门禁。无映射时显示“项目待绑定”,不回退全量世界。仅管理员专用迁移/调查路径能够处理未归属域,并单独留痕。
检查结论提案、引用、关系两端和版本归属,不接受来自别的项目的 ID。
普通文档协作仍使用原业务权限,避免用审计策略误封工作流程。
验证:创建者、非创建者负责人、成员、非成员、RDM 域管理员、仅基座超管六类主体(后两类均为跨项目审计正例,域管理员访问平台管理分区须为负例);空项目、伪造项目、跨项目对象、旧命令/模型工具绕过、撤权后的新请求与下载均有正负例。
增加首次启动、恢复后空台账、并发初始化、普通建项目不提权的验证。
完成条件:至少两个项目、多用户、真实认证入口下全部读取边界可复核;不依赖隐藏按钮。
进展(2026-10-11,RDM PR #195 merge 05b7d1a):U1 已实施合入——审计判定统一入口(创建者∨域管理员∨超管槽,`AuthorizeAudit`/`AuthorizeCmd`,命令面全接线,空 projectId 显式拒绝);KTD4 双层管理员落地(`rdm_admins` 单行台账+`-bootstrap-admin` 受信引导,`project.create` 不再自动引导);KTD5 宿主显式绑定(`rdm_host_project_map`+`rdm.project.bind/unbind`+EXT-8 映射解析+上传可信上下文解析);项目列表按主体过滤;旧客户端 `web/app.js` 统一注入 projectId。两项基座扩展申请已随该 PR 落盘(`RDM:docs/proposals/2026-10-11-u1-base-extension-requests.md`):超管槽在基座能力发版前保持 fail-closed,「仅基座超管」负例†待接线翻正;真实认证入口运行验收随 U4/U5 复核。
### U2. 原子事件与历史还原
目标/需求:R5、R6、R10;依赖:U1 的项目合同。
范围:`RDM:internal/domain/{eventlog,notetree,doctree,tracenet,compliance,replay,persist,review}.go`、`domain/store/store.go`、`rdmapp/conclusions.go`、`upload.go` 及上传状态台账,对应 `persist_test.go`、`integrity_test.go`、`compliance_test.go`、`conclusions_test.go`、`upload_test.go`。
补事件批次事务、项目内写入串行/预期版本和操作幂等;内存变更置于提交之后。
上传原件先不可变留存,再由同一 RDM 数据库事务发布引用、状态、项目归属、切片关联、pending 关闭和幂等结果;meta.json 降为可重建镜像。上传确认/拒绝中断后按操作结果恢复,不重复入库;此项在 SQLite 首期完成,不等待 U6。
修复升版 stale、正式版审签元数据和完整快照重放;记录成员/权限/职责变化及真实 actor。
建立结构事件到基座审计的 outbox,显示投递状态;旧缺失事实明确为不可恢复,不能补造批准人或时间。
验证:第二条/最后一条事件失败、提交后进程退出、投影刷新失败、相同请求重试、并发同版本更新;重启前后对节点/版本/边/审签/缺口深比较;旧快照与未知 schemaVersion 明确拒绝冒充完整;历史/导出截止落在批次中间时拒绝,上传发布/确认中断后状态与切片不重复、不矛盾。
进展(2026-10-11,RDM PR #197 merge fe8a75b):U2 已实施合入——`Runtime.TxProject` 事务批次(项目写锁+tx 绑定写穿+失败回滚并从库重建,零部分提交);入库拆事务内核/提交后宿主侧;结论确认/拒绝与上传五步同事务(`rdm_uploads` 表为事实源,meta.json 降为镜像);Retag 事件先行;重放保真(正式版 At/Actor 入载荷、CNode 升版重放重算 stale、cSnap 全量载荷+旧计数快照标 CountOnly、events schema_version 未知版本停止还原);`rdm_op_log` 幂等(结论/上传确认 opId);`rdm_audit_outbox` 同事务入箱+尽力投递+`rdm.audit.status`。写串行覆盖=事务面+已转换命令(用户裁定口径);进程级 kill 注入与运行验收随 U4/U5 复核。
完成条件:命令结果、持久记录、重建投影一致,故障不造成不可解释的部分成功。
### U3. 统一项目审计读服务
目标/需求:R3、R4、R5、R8;依赖:U1、U2。
范围:`RDM:internal/rdmapp/trace.go`、`baseline.go`、`cgraph_export.go`、拟增 inspection 读投影;`plugins/rdm/plugin.go`;测试 `trace_test.go`、`chainviews_test.go` 及新增 inspection 集成测试。
把两树、一般关系、受控关系、结构事件和基座动作记录适配到统一对象详情及分页查询。
为查询绑定项目、当前授权、截止水位及版本;返回覆盖状态和截断状态。
补公开面需要的 project/operation 审计查询与能力 provider;不从字符串解析项目归属。
验证:旧网和合规网的同名 ID 不冲突,历史 v3 与当前 v4 不串用;未知/受限来源在旧 payload、差异、快照及导出副本中也不泄漏;游标换项目拒绝,分页期间新增事件不重不漏;动作审计同步延迟可见。
完成条件:无需读数据库即可通过受控接口回答来源、影响、变更与历史问题。
进展(2026-10-11,RDM PR #201 merge dbc41b6):U3 已实施合入——`inspection.go` 七面读服务(Capabilities/Summary/Tree/Object/Relations/Events/History)+统一响应壳(键集分页+截断+coverage 诚实标注);游标 base64 绑定项目(跨项目/过滤不一致拒绝);水位=已提交 max(seq);双网合流(layer 标注/kind 路由不串/ver 标注);schema v6 events.operation_id 列+TxProject BeginOperation 归组注入;披露标记(legacy-unattributed/model-candidate);`rdm.inspect.*` 七命令+审计面授权。基座侧动作审计待基座扩展(申请一/二)。
### U4. 项目追溯审计工作区
目标/需求:R2、R3、R4、R7;依赖:U3;页面载体在本增量设计评审时固定为宿主支持的 RDM 插件工作区。
范围:RDM 页面资源及宿主注册声明;必要时 `Dev:modules/frontend/src/components/{Workspaces,AdminZone,adminSections}.tsx`、`store.ts`、`api.ts`;交互测试沿用 frontend test/e2e 体系,旧 Web 的兼容测试留在 `RDM:web/workbench_test.mjs`。
实现四入口、两树导航、对象详情、一跳关系和自然语言记录;普通用户无入口且接口拒绝。
管理员目录按授权后的项目查询,选项目复用页面;RDM 管理 capability 不解锁其他平台管理分区。
沿用宿主文件预览、令牌和折叠;删除/替换旧重复图入口需另列兼容清单。
验证:真实浏览器完成来源查询、选择历史时间/基线并返回当前、管理员从宿主 A 打开审计 B 后标题和请求一致;模拟慢请求后快速切项目无串页;键盘、窄屏、长标题、千级节点懒加载、空/失败/受限/不可还原状态可理解。
完成条件:用户按三次主要点击任务完成取证,并人工评审界面是否直观;业务可用与视觉通过分别记录。
进展(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。
范围:`RDM:internal/rdmapp/{cgraph_export,docx,xlsx}.go`、页面导出入口、导出临时工件及下载授权;测试 `domain/export_test.go`、`plugins/rdm/xlsx_export_test.go` 和浏览器下载场景。
复用 docx/xlsx 导出器,固定项目/版本/规则/截止 seq,补证据来源清单和完整性说明。
导出按请求身份和范围生成,撤权后下载失败;历史受限来源不随导出泄漏。
固定基座发布版本、RDM pins 与页面资源组合后,重放真实端到端流程。
验证:导出中途有新写入不改变已固定内容;历史来源软删除仍可按授权追溯;未归属/缺失事件可见;跨项目下载、过期下载、权限撤销均拒绝。
完成条件:同一版本在 UI 与报告中结论一致,并有正式 GATE/REPLAY 证据。
进展(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
### U6. 团队部署存储衔接(独立后续任务)
本项不纳入 U1–U5 的默认实施与验收范围,另经团队存储方案授权后立项。
目标/需求:R1、R5、R6、R9;依赖:U2,以及[多人协作存储方案](2026-10-11-collaboration-storage-and-distribution.md)适用增量。
范围:RDM 领域 store/迁移、项目/成员/权限/结论/慢通道台账、上传原件与导出清单;基座只补通用连接/生命周期公开契约。
明确 RDM SQLite 与团队 PG 的适配和备份清单,避免一半事实在 PG、一半未受保护地留在本机文件。
先验证单实例团队档;多实例的发号、执行所有权、缓存失效与故障恢复在独立验收前保持关闭。
本次不复制基座在途 PG 档位和迁移能力,也不把基座 PR 完成当作 RDM 迁移完成。
验证:真实 PG 的隔离/事务/重放、迁移前后对象与事件数及哈希对账、备份恢复含原件;PG 不可用不静默退回空 SQLite。
完成条件:团队部署具备明确权威存储与恢复证据;若本批仅交付单实例 SQLite,验收报告必须声明该限制。
---
## Migration and Delivery
历史归属先做只读盘点:未归属事件、缺少项目绑定、对象依赖闭包、旧快照和私人来源。
现有 seq 区间迁移接口不能作为任意截取的安全保证;归属以完整对象及依赖闭包为单位校验,并保留批准映射和原因。
不把存量自动分给首个项目,不根据当前 owner 猜历史创建者。
迁移前保存备份和对账清单,在隔离副本上验证,再取得共享环境迁移授权。
采用新增字段/投影、保留原事件、按项目启用;观察期内可关闭新页面和新读取投影,但不能恢复越权的全量读取入口。
停止条件:发现跨项目泄漏、重放不一致、无法确定历史归属、投影滞后超出可解释范围或恢复失败;保留现场和失败证据。
跨仓顺序为基座扩展申请→基座实现/测试/发布→RDM 升级固定版本→RDM 集成验证→Dev 文档与组合记录更新。
必要令牌调整按 DESIGN.md 成对关联 UI 与 Dev 组合;仅消费令牌时不制造无关令牌 PR。
在途核对(本次 Gitea API 只读,SELF;实施前须刷新):Dev #325 为团队 PG 档与迁移组合,#317 为服务启动 DSN;RDM #194 为已合入 xlsx 工作的任务卡闭合,不能重复安排 xlsx 从零实现;Backend、Documents 查询未返回开放 PR。
关联规划为 RDM 阶段总案 P3/MS3、U0 项目共享合同、V2.2 合规图方案和上述团队存储方案;本案补充集成/授权/显示,不声称这些里程碑已验收。
---
## Verification Contract
以下为实施时的验收计划,本轮结果均 NOT_RUN;文档自检另以任务收据记录。
| 组 | 覆盖需求 | 最小可复核场景 |
|---|---|---|
| 授权/隔离 | R1、R2、R10 | 六类角色×两个项目;列表、统计、详情、关系、历史、工具、导出、下载、订阅均验证;普通文档协作无误封 |
| 数据完整性 | R3、R5、R6 | 跨项目提案和边拒绝;多事件中途失败;重试/并发;重启及指定 seq 深比较;完整快照哈希 |
| 真实业务闭环 | R3–R6 | 项目创建→纪要入库→切片→需求→章节 v1→依据变化→v2→审签→历史回看→报告;缺失链节明确显示 |
| 可用性 | R4、R7 | 创建者找依据/变更原因,管理员选项目,键盘/窄屏/长文本,加载/失败/受限状态,过期响应丢弃 |
| 导出 | R8、R10 | 同一 cutoff UI/报告一致;创建与下载分别鉴权;撤权/受限来源/不完整记录不泄漏或冒充完整 |
| 组合与运行 | R9 | 固定 Backend/Core/Frontend/UI/RDM SHA;RDM 测试与构建、Dev 适用组合检查;部署后二进制身份和真实浏览器路径 |
| 团队档(U6另行立项时) | R1、R5、R6 | 真 PG、迁移与恢复;单实例和多实例证据分别记录,无变量或无环境即 NOT_RUN/SKIP |
性能建议作为待批准目标:单项目 1 万对象/5 万关系、100 万事件的样本;首屏仅取分页摘要与当前树分支;普通分页查询 P95≤1s,首屏可操作≤2s。
记录实际硬件、数据分布、过滤条件和组件版本,不能以空库或缓存命中替代容量结论。
正式审核先重放最小集再读作者证据;来源标记遵循 GATE/REPLAY/SELF,用户界面演示与正式验收分开。
---
## Definition of Done
本方案阶段完成条件:现状依据可定位、原有能力不重复建设、项目和角色边界明确、展示可理解、工作项与验收对应;r1 已于 2026-10-11 经用户评审通过(五阶段一并,含 KTD4 双层管理员裁定)。
实现阶段完成条件:R1–R10 对应证据齐备,固定组合通过正式测试和独立审核,部署与浏览器验收有独立记录;源码存在不等于完成。
已裁定决策:KTD4 采用双层管理员——基座 isAdmin 超管保底+RDM 台账域管理员(session-settled: user-directed,2026-10-11)。剩余待定决策:RDM 宿主工作区入口的具体交付契约(U4 设计评审时固定);U6 如需提前并入本批,应另行批准范围及目标环境,默认不包含。
推荐先批准 U1 的细化设计与测试范围;U2–U5 按依赖逐阶段评审,U6 单独立项,不把本轮范围确认当作连续实施授权。
后续再考虑跨项目引用审批、全局关系图、电子签名/外部防篡改存证及复杂图分析;这些不属于首个可用闭环。
@@ -0,0 +1,252 @@
---
title: 快慢通道展示 U1 实施计划
date: 2026-10-12
revision: r1
status: approved
owner: weichen
execution: implementation
parent: 2026-10-12-fast-slow-channel-display.md@r1.1
---
# 快慢通道展示 U1 实施计划 r1
> **For agentic workers:** 按本计划逐工作项实施;每项先写失败测试再改实现。规格依据主方案 [r1.1](2026-10-12-fast-slow-channel-display.md)。阶段 5 已于 2026-10-12 经用户「开始」批准;批准不等于推送/合入授权。
**Goal:** 统一后台任务真实状态语义,用 L1 精炼骨架替换「原始指令占主视图」,使失败不再显示为完成,并为后续 U2 快照契约留下兼容字段草图。
**Architecture:** 服务端在建卡/终态时写入精炼 Body 与正确 `CardStatus`;UI 按状态灯/状态词渲染;旧 `done+danger` 客户端兼容映射为失败。不引入持久 `TaskSnapshot`、不按任务路由 `agent.progress`、不发布阶段 findings(属 U2/U3)。
**Tech Stack:** Go(Core/Backend)、React+TypeScript(UI/Frontend)、既有 ActivityCard / UINode / cardsvc 事件流。
**Spec:** [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md) §4 R03-a、§7.1、§10.1、§14 U1 出口白名单。
## Global Constraints
- 首批仅 U1;禁止顺手实现 U2/U3 范围(材料内容 hash、持久快照、检查点摘要、HITL 双入口完备)。
- 颜色/圆角/字号只消费 `@ui/tokens.css`;动效只用 `mk-*`;折叠用 Collapsible。
- 证据经 `CMD=… make evidence` 写入任务卡;声明通过须标 SELF/GATE。
- 跨仓顺序:Core(若有契约)→ Backend → UI → Frontend → Dev gitlink 组合 `make test`。
- 现有「停止」按钮语义不在本增量改名为「仅停前台」;不暴露暂停/独立取消/续跑。
## Review Focus
1. 失败卡若仍为 `done`,用户会当成成功收纳——须 `CardFailed` 或等价失败灯。
2. 建卡若仍塞入 task 原文,用户会把指令当进度——须 L1 骨架。
3. 材料去重若仍只认 `CardDone`,改为 `CardFailed` 后可能卡死重试门禁——须同步测试。
4. 快通道在登记前说「已启动」——须与真实登记/开跑事件对齐。
5. `CurrentTaskCard`(plan/todos)与后台 progress 卡同目标叠卡——U1 须定义合并或降噪规则,避免双标题。
---
## 0. 范围与非目标
### 纳入(映射需求)
| 需求 | U1 验收子集 |
|---|---|
| R01 | 简单问答无空进度卡;复杂任务短答可含已确认范围与后台真实状态 |
| R02 | 已登记任务有稳定卡对象;未登记不显示「已启动」 |
| R03-a | L1 骨架 + 诚实无发现占位;不验收运行中真实发现 |
| R08 | 失败 ≠ 成功灯;状态词「执行失败」 |
| R10 | 完成卡骨架(结论/要点/缺项/入口);完备来源与版本定位可留 U3 |
| R13 | 守护测试通过;状态不只靠颜色(沿用 StatusLamp 形状) |
### 排除
见主方案 §14「明确排除」。另:不改 `CancelRun` 父句柄行为;不改 Surface 抢占策略(属 U2/U4)。
### 与 CurrentTaskCard 的合并规则(U1)
- 后台 `CardKindProgress` 卡是慢通道权威对象。
- 若同一会话同时存在前台 `plan`/`todos` 的 `CurrentTaskCard` 与后台 progress 卡:**右栏「工作」优先列出 progress 卡**;`CurrentTaskCard` 仅在无后台 progress 卡且 plan/todos 非空时展示。
- 不在 U1 把 plan steps 写入后台卡 Body。
---
## 1. 工作项与文件
### W1 — Core:精炼摘要契约草图与旧卡映射说明
**Files:**
- Modify: `modules/core/activity.go`(若增加可选字段)或新增 `modules/core/task_summary.go`
- Test: `modules/core/activity_test.go` 或同目录新测
**内容(最小):**
```go
// TaskSummaryView 是 U1 写入 ActivityCard.Body 的权威语义草图;
// 完整 TaskSnapshot(findings/revision/streamScope)留待 U2。
type TaskSummaryView struct {
Title string // 业务动宾短标题
Focus string // 正在做什么,≤2 行
FindingsNote string // U1:无成果时固定诚实文案;有结构化 findings 属 U3
Remaining string
NextStep string
OutcomeLine string // 完成后的结论一行;运行中可空
}
```
可选:在 `ActivityCard` 增加 `Summary *TaskSummaryView \`json:"summary,omitempty"\``;**Body 仍为旧客户端回退投影**,新客户端优先读 Summary。若为降低跨仓面,U1 可仅约定 Body 的 Markdown/KV 形状而不加字段——但须在 Core 注释或本计划冻结 Body 键名:
| KV 键 | 含义 |
|---|---|
| 状态 | 排队中 / 进行中 / 已完成 / 执行失败 |
| 正在做 | Focus |
| 当前发现 | FindingsNote(U1 占位或完成后要点摘要) |
| 剩余 | Remaining |
| 下一步 | NextStep |
- [ ] 冻结 Body 键名或 `Summary` 字段二选一,写入 Core 并单测序列化往返
- [ ] 文档注释标明 findings[] 属 U2/U3
- [ ] Commit:`docs(core): freeze U1 task summary body contract`
### W2 — Backend:建卡/终态状态与精炼 Body
**Files:**
- Modify: `modules/backend/internal/runmgr/runmgr.go`(`createBackgroundCard` ~1942、`promoteQueuedCard` ~1970、`finishBackgroundCard` ~1992)
- Modify: `modules/backend/internal/runmgr/material_test.go`(及同类依赖 `CardDone+danger` 的测试)
- Test: 新增 `modules/backend/internal/runmgr/background_card_test.go`
**当前问题(源码):**
```go
// create:Body 首节点 = truncate(task, 400)
// finish:SetStatus(..., CardDone, tone) 且失败 tone=danger、状态行仍写「已完成」
```
**目标行为:**
```go
func backgroundRunningBody(focus string, kv [][2]string, statusLabel string) []core.UINode {
return []core.UINode{
{Type: core.UIMarkdown, Markdown: "尚无阶段结论,正在读取材料"},
{Type: core.UIKV, KV: append(append([][2]string(nil), kv...),
[2]string{"状态", statusLabel},
[2]string{"正在做", focus},
[2]string{"当前发现", "尚无阶段结论"},
[2]string{"剩余", "待任务进展后更新"},
[2]string{"下一步", "继续处理已登记工作"},
)},
}
}
// finish 成功:CardDone + tone ok;状态「已完成」;Markdown = 结论骨架
// finish 失败:CardFailed + tone danger;状态「执行失败」;保留已有可读摘要
```
- [ ] 失败测试:`finishBackgroundCard` 在 `err != nil` 时 `Status==CardFailed` 且 Body 状态键 ≠「已完成」
- [ ] 失败测试:`createBackgroundCard` Body Markdown 不含原始 task 长指令(可用固定长 task 断言不出现)
- [ ] 实现最小改动;`promoteQueuedCard` 只更新状态键为「进行中…」
- [ ] 更新 `material_test`:成功路径仍等 `CardDone`;失败/重试路径认 `CardFailed` 或释放 `materialActive`
- [ ] 快通道诚实:spawn/登记路径日志与用户可见文案——仅在 `Create` 成功后可称「已登记」;仅在子 run 启动后可称「进行中」(检查 `spawnBackground*` / material 入口提示,必要时改 system 提示片段;**不做**阶段发现生成)
- [ ] Commit:`fix(backend): map background card fail to CardFailed and use L1 body`
### W3 — UI:状态灯与旧卡兼容
**Files:**
- Modify: `modules/ui/src/ActivityCardView.tsx`(`StatusLamp`)
- Test: 既有 UI 测试或新增 `ActivityCardView` 测例;跑 `design-guard.test.ts`
**目标:**
```tsx
// done → 完成灯;failed → 失败灯(已有)
// 兼容:status===done && tone==='danger' → 按失败灯展示,title「执行失败(兼容)」
```
- [ ] 失败测试:`done+danger` 渲染失败形状灯,不渲染 `lamp-ok`
- [ ] 实现兼容映射;不新增裸色值
- [ ] `pnpm test` / 仓内 UI 测试目标通过
- [ ] Commit:`fix(ui): treat done+danger progress cards as failed`
### W4 — Frontend:工作区排序与空卡
**Files:**
- Modify: `modules/frontend/src/components/Workbench.tsx`(`CurrentTaskCard` 展示条件)
- Modify: 若 Inbox 过滤依赖 status,核对 `store.ts` 对 `failed` 的分区(完成区 vs 进行中)
- Test: 前端既有测试或最小组件测
**目标:**
- 存在 `kind===progress && status===active`(或排队文案)时隐藏与同会话抢注意力的空 `CurrentTaskCard`(按 §0 合并规则)
- `failed` 卡进入可收纳/结果区逻辑与 `done` 区分(失败可收纳但不显示成功语义)
- 简单问答路径不因误触发材料整理产生空卡——若属既有路由,仅加回归断言「无附件无后台登记时 progress 卡数为 0」
- [ ] 实现合并规则
- [ ] 回归:无后台任务时 plan 仍可显示
- [ ] Commit:`fix(frontend): prefer progress cards over duplicate CurrentTaskCard`
### W5 — Dev 组合与文档收口
**Files:**
- Modify: Dev gitlink(Core/Backend/UI/Frontend 精确 SHA)
- Modify: 实施任务卡证据段;主方案进展指针(若本增量合入时)
- Test: 工作区根 `make test`、`make build`
- [ ] 各组件 PR 顺序合入或同批组合验证
- [ ] Dev `make test` + `make build`;evidence 写入
- [ ] 更新主方案「规划进展」:U1 实施状态(仅在真实合入后)
---
## 2. 测试与环境
| 层 | 命令/方法 | 证明什么 |
|---|---|---|
| 单元 | Backend `go test ./internal/runmgr/…`;Core 序列化;UI StatusLamp | 状态映射、Body 骨架、兼容灯 |
| 守护 | UI/Frontend `design-guard.test.ts` | 无新增裸色值/私有 keyframes/行内字号 |
| 组合 | Dev `make test`、`make build` | gitlink 组合可编译可测 |
| 手工冒烟(SELF) | 本地起服务:发材料看建卡;制造子任务失败看灯;简单问答无空卡 | U1 白名单场景 |
| 真实模型阶段成果 | **NOT_RUN / 不在 U1** | — |
| 浏览器窄屏全矩阵 | **NOT_RUN / 属 U4** | — |
被测对象:各仓 PR HEAD;组合声明须含精确 SHA。
---
## 3. 完成条件
1. U1 出口白名单全部可判定项有 SELF 或 GATE 证据。
2. R03-a 有测例;无人用「五问完整」拒绝 U1。
3. 材料整理去重/重试在 `CardFailed` 下仍可再次登记(或文档说明与测例固定行为)。
4. 无 U2/U3 范围代码混入同一变更集(审 Diff)。
---
## 4. 停止与回退条件
- 失败状态与存储不一致(卡显示失败但去重门禁认为仍在跑,或相反)→ 停止合入,修 W2/材料门禁。
- 新旧客户端之一崩溃或空白卡 → 回退 Summary 字段改动,保留 Body 回退投影。
- 发现实现滑入持久快照/检查点摘要 → 拆出变更,不进本 PR。
- DESIGN 守护失败 → 先改令牌消费再继续。
回退策略:回退受影响展示映射与 Body 生成;不删除已保存 run 结果。
---
## 5. 依赖顺序与责任
```text
W1 Core 契约(可选字段或 Body 键冻结)
→ W2 Backend 建卡/终态
→ W3 UI 灯兼容
→ W4 Frontend 工作区
→ W5 Dev gitlink + 组合测试
```
责任人:实施阶段指定;需求/评审:weichen。
预估:单增量跨 4 仓,以状态映射 + Body 重排为主,不含模型评测费用。
---
## 6. 计划评审状态
| 项 | 状态 |
|---|---|
| 关联方案 | r1.1 设计已批准;首批仅 U1 |
| 本实施计划 | **已批准**(2026-10-12,用户「开始」) |
| 业务代码 | 实施中:`feature/fast-slow-display-u1` |
| 推送/PR/合入 | 未授权(完成自检后另请) |
首选动作已执行:`make task-start NAME=feature/fast-slow-display-u1`,按 W1→W5 推进;设计任务卡可在文档 PR 合入后 `task-close`。
@@ -0,0 +1,517 @@
---
title: 快慢通道展示与动态工作摘要方案
date: 2026-10-12
revision: r1.1
status: design-approved
owner: weichen
execution: design-only
---
# 快慢通道展示与动态工作摘要方案 r1.1
状态:**方案设计已批准(阶段 4)**。需求依据:用户要求改善快慢通道的内容、排版与直观性,让慢通道执行期间持续呈现精准、精炼且有工作价值的状态、发现、摘要和总结。
批准依据:2026-10-12 用户确认评审结论计划并指示按该计划落地文档修订与 U1 实施计划;批准范围覆盖四层阅读、任务卡骨架、动态回投规则、U1→U2→U3→U4 顺序及**首批仅 U1**。本修订相对 r1 增加 R03 增量切分与 U1 出口白名单。业务代码实施仍须另批阶段 5 实施计划后启动。更新日期:2026-10-12(北京时间)。需求与评审负责人:weichen;实施负责人在实施阶段指定。
## 1. 推荐方向与成功标准
采用**对话推进工作、任务卡持续更新、结果按需展开**的方案。快通道负责即时理解、当前可回答的结论和必要确认;慢通道负责持续处理材料、研究、分析、生成及检查,并把当前工作成果逐步汇总给用户。两者共享任务与事实,不形成两份独立聊天记录。
用户应当可以在一个视野里回答五个问题:
1. 这项工作现在处于什么状态?
2. 已经完成什么、目前知道什么?
3. 这些发现对我的任务有什么影响?
4. 还缺什么、下一步准备做什么?
5. 是否需要我做决定或补充材料?
默认阅读只需一行状态和一张紧凑任务卡。深入查看时可看到阶段成果、依据和执行记录。正式交付后直接给出结论、关键要点、限制与文件入口。
设计的初始验收目标:代表性用户看到默认视图后,10 秒内可正确回答状态、主要发现、是否需处理三个问题;这个目标是**待验证的可用性指标**,不是当前体验已经达标的声明。
## 2. 当前实现依据及差距
本次依据本地固定源码核对,来源为 SELF。启动基线为 Dev `4bf6e4a0cf8b509320d54de2a6a41c5abb2f5bba`;任务同步后读取的 Dev HEAD 为 `3496d1af37827dc536559ed5bbfe23c381c329cd`,其包含同步基线 `dec25692c247c8923b0f9396c8f674aefec47521`。
组件:Backend `dcc180dcad2489a170edca154e39e335220854f1`、Core `89f3906c390027512ef47b5333088c3d3a019e84`、Frontend `d01a3ebd819da29bf7e7dd06e74c92ef34231774`、UI `bfecf8b51f9a0fdbd9a13590cddf8fc06b7ae700`。Documents 写作分支从单独获取的 `origin/main=52bf525ef8750999e5e7dbff0b2decac5b1155f7` 建立,未改变受测业务组件。源码审阅原始记录见 Dev 任务卡 `.task/feature-fast-slow-display-design.md` 的 source-audit 收据。本轮未开展真实模型、浏览器或部署验证;以下“已有”只表示源码中存在相应机制。
| 已有源码机制 | 位置 | 与本需求相关的差距 |
|---|---|---|
| 快通道是当前对话回合,慢通道是后台子任务;同会话后台槽位上限 3 | Backend `internal/runmgr/runmgr.go` 的 `spawnBackgroundOpts`、`startBackgroundSlot` | 缺少统一面向用户的任务概览;通道不是用户可切换的速度档位 |
| 带附件可自动启动材料整理;无文字/大材料可预启动,小材料有结束兜底;支持排队 | Backend `internal/runmgr/material.go` | 已有入口应复用;当前材料键仅由文件名与解析字数生成,同名等长更新可能复用旧结果。启动信息不等于材料已经读完 |
| 进度卡创建时放入最多约 400 字任务正文和“执行中”状态 | Backend `internal/runmgr/runmgr.go:1942` | 用户主要看到任务说明和指令,不能据此理解实际进度 |
| 完成时替换卡身;成功/失败统一置 `done`,用 tone 区分 | 同文件 `finishBackgroundCard`;UI `src/ActivityCardView.tsx:23` | 执行期间缺少成果投影;失败卡可能带“完成”灯,业务结果与卡收纳状态混在一起 |
| `agent.progress` 发布子任务文本前约 80 字及“调用工具”消息 | Backend `internal/runtime/sub_loop.go:208` | 原始文本片段不具备稳定摘要语义,也没有结构化来源和成果完整性 |
| `agent.progress` 写进单个 `live.agentNotes`;`touchLive` 维护单个 LiveState | Frontend `src/store.ts:514`、`:986` | 需避免后台进展串入当前对话回合;缺少按任务持久维护的独立展示投影 |
| 会话/项目事件流、卡片更新事件及断线重放契约已有;客户端读取 seq | Core `events.go`;Frontend `src/api.ts:192` | 客户端 `Math.max` 推进游标本身不等于拒绝旧帧;新投影必须显式处理去重、顺序和恢复 |
| 三栏“上下文 / 对话 / 工作与文件”、HITL、工件预览、Surface 已有 | Frontend `Workbench.tsx`、`Conversation.tsx`、`store.ts`;Core `activity.go` | 需要在现有落位整合,不增加第四栏;Surface 更新当前有自动打开预览行为,后台更新应控制抢占 |
| 后台完成结果在会话空闲时启动汇报回合 | Backend `deliverNotices` | 结果就绪与汇报已送达需要分开;用户不应因前台忙而误以为任务尚未完成 |
| 取消子 run 的现有路径还会尝试取消父句柄 | Backend `CancelRun` | 不直接提供承诺独立取消、暂停或重试的按钮 |
由源码推导的主要原因:运行事件、任务卡和最终回复之间缺少一层稳定的**用户工作摘要**。只调整卡片样式不能补齐这些信息。
## 3. 方案选择与边界
| 方案 | 收益 | 代价与限制 | 结论 |
|---|---|---|---|
| 直接把慢通道日志流到卡片 | 改动较少、容易看到活动 | 原始指令与工具输出增多;难提炼发现;并发时噪声更大 | 作为执行记录层,不作为默认视图 |
| 快慢通道各有一份完整对话流 | 两条执行线直观 | 重复回复、重复确认、用户需要拼接上下文;占用阅读空间 | 不采用 |
| 统一任务摘要 + 同一卡片更新 + 对话关键回投 | 结论可读、状态可见、细节可追溯 | 需要结构化成果与持久投影 | **推荐** |
范围包括信息架构、快通道内容、慢通道摘要、状态语义、更新策略、来源与恢复、UI 组件适配。通用基座提供任务、发现、来源与动作能力;文档审签、业务风险等级等由下游提供适配,不写进基座。
本轮不执行业务代码修改、模型实验、迁移、重启或部署。候选设计中的新契约、持久化和操作能力均为待批准内容。本方案不依赖 Generative UI 插件启用才能工作;结构化任务卡提供基础体验,Surface 可用于适合的成果展示。
## 4. 需求与可判定验收
以下为已批准方案范围内的需求表。P0 是核心闭环,P1 是增强项。首批实施仅覆盖 U1 出口白名单中的子集;“纳入候选”不等于该子集已获实施授权。
| ID | 需求 | 优先级 | 可判定验收条件 | 依赖/处理 |
|---|---|---|---|---|
| R01 | 快通道首先给用户可用的即时答复 | P0 | 简单问答无空任务卡;复杂任务短答能说明已确认范围、当前可回答内容及后台工作 | 既有对话;U1 纳入 |
| R02 | 所有已登记后台任务都有稳定可见对象 | P0 | 排队、运行、结束都定位到同一任务;未登记时不显示“已启动” | 任务登记;U1 纳入 |
| R03 | 默认卡呈现当前工作、发现与剩余项 | P0 | 见下方 R03 增量切分;完整五问仅在 U3 验收 | R02;按增量切分 |
| R04 | 阶段成果动态更新且不重复刷屏 | P0 | 有可用阶段成果时及时更新同一卡;选定长任务验收至少两个真实成果检查点;短任务可直接完成,普通更新不新增对话消息 | 事件投影;U2/U3 |
| R05 | 事实、分析判断和待确认内容可区分 | P0 | 关键发现可定位依据;尚未核实的推断带限定;不得以模型自报覆盖工具实际结果 | 来源契约;U2/U3 |
| R06 | 并行任务不会互相污染状态或正文 | P0 | 3 个后台任务与前台回合同时活动,各任务标题、发现和终态归属正确 | 按任务路由;U2 |
| R07 | 等待用户的动作明确且双入口一致 | P0 | 对话/右栏提交任一入口后另一个同步更新;重复点击只执行一次 | 既有 HITL/动作;U3 |
| R08 | 成功、部分结果、失败、中断明确区分 | P0 | 失败不显示成功灯;部分结果标明缺项;未保存的结果不显示“已交付” | 结果契约;U1 纳入 |
| R09 | 断线/刷新不丢失成果,也不伪造状态 | P0 | 重连可恢复阶段摘要;重复/乱序事件不回退;连接异常不改写业务终态 | 持久快照;U2 |
| R10 | 完成回投精炼且可取回产物 | P0 | 显示结论、最多 3 个默认要点、缺项、文件入口;定位真实文件且版本明确 | 工件/通知;U1 骨架,U3 完备 |
| R11 | 右栏关闭与窄屏时主要能力完整 | P0 | 不打开右栏即可读摘要、看依据、处理确认、打开文件 | 对话内展开;U4 |
| R12 | 更新尊重正在阅读的内容 | P0 | 不自动切文件、不夺取焦点、不把用户滚回底部;展开与阅读位置保留 | 更新策略;U2/U4 |
| R13 | 视觉与可访问性符合 DESIGN.md | P0 | 令牌、Collapsible、MotionKit 守护通过;键盘可达;状态不只靠颜色 | UI/Frontend;U1 纳入 |
| R14 | 摘要成本受控,摘要失败不影响任务 | P0 | 不按 token 调用摘要模型;预算耗尽仍有真实阶段状态与既有发现 | 发布策略;U3 |
| R15 | 修改任务要求可解释地衔接 | P1 | 新要求明确“尚未生效/已用于后续任务”;不假称已改变在跑任务 | 新任务/输入确认;U4 |
| R16 | 合适成果可以切换对比、清单或报告 | P1 | 比较任务给差异表;审查给问题清单;插件关闭仍能读取核心摘要 | 可选 Surface;U4 |
| R17 | 每次尝试与结果采用状态可追溯 | P0 | 新尝试不覆盖旧失败;生成、用户认可、正式发布三者独立显示 | task/attempt/result;U2 |
| R18 | 跨任务发现有总览且不重复计数 | P1 | 同一来源同一发现合并引用;冲突并列呈现,关联到各自任务 | 稳定发现 ID;U4 |
### R03 增量切分(定稿)
完整 R03「运行卡无需展开即可回答第 1 节五问」不得用单一增量字面验收。切分为:
| 子集 | 归属 | 可判定出口 |
|---|---|---|
| R03-a | U1 | 默认卡采用固定 L1 骨架(标题+状态、正在做什么、当前发现区、剩余/下一步);无阶段成果时诚实显示「尚无阶段结论…」;不把原始任务指令当作进度正文;**不**要求运行中出现真实业务发现 |
| R03-b | U2 | 活动行与覆盖/剩余可随确定性事件持续更新;刷新/重连后骨架与活动状态仍可读 |
| R03-c | U3 | 带来源的 1–3 条阶段发现;运行中即可回答五问中的「知道什么 / 影响 / 还缺什么」 |
项目符合度:R01–R18 与对话优先、服务端权威、通用基座定位相符;其中 R02–R09、R14、R17 需要契约及实现调整,R15/R16/R18 的完整能力需进一步设计。运行可行性尚未验证。
## 5. 信息架构与阅读层级
维持三栏。左侧提供项目、会话、材料上下文;中间负责对话、关键进展和决定;右侧“工作”集中当前任务与待处理事项,“文件”负责既有唯一预览入口。
| 层级 | 默认展示 | 用户目的 | 展开方式 |
|---|---|---|---|
| L0 一行概览 | 前台状态、后台任务数量、待处理数量 | 一眼判断是否忙、是否需要行动 | 点击对应任务或待处理项 |
| L1 工作摘要 | 目标、状态、正在做什么、1–3 条重要发现、剩余项、必要动作 | 快速理解并继续工作 | 当前任务卡;对话内同对象锚点 |
| L2 阶段与依据 | 阶段成果、发现列表、覆盖范围、未决事项、来源 | 检查判断、准备评审 | 在原位置用 Collapsible 展开 |
| L3 执行记录 | 工具调用、可授权查看的参数/输出、事件、错误详情 | 排障和审计 | “执行记录”,默认折叠、按阶段分组 |
默认先提供 L0/L1;不同时展开所有任务。正在查看文件时,工作更新只改变概览及未读提示。右栏收起时,中栏任务锚点可展开 L1/L2/L3,关键功能不依赖右栏。两处共享同一 taskId 和服务端快照,不分别生成摘要。
右栏顺序:**需要你处理 → 当前正在查看的任务 → 其他进行中/排队 → 新结果 → 已收纳历史**。置顶任务保留位置;普通更新不因时间变化反复重新排序。排序规则只负责注意力,不改变执行优先级。已有“当前任务卡”的计划/待办融入同一概览,避免再叠一张同目标卡。
### 5.1 桌面示意
下列内容均为设计示例,不是真实运行结果。
```text
上下文 对话 工作 | 文件
项目 / 会话 收到 3 份材料,已登记材料整理任务 需要你处理 0
材料与历史 我会先核对事实和差异,再给摘要 材料整理 · 进行中
[材料整理 · 已有 2 条阶段发现] 正在核对:需求与会议结论
当前发现
你:先重点看验收要求 • 3 项需求缺少验收条件
助手:补充尚未作用于在跑整理 • 上线日期存在两种表述
[以此重点创建后续分析任务] 剩余:核查评审意见
下一步:整理待确认事项
… [查看依据] [阶段与记录]
后台 1 项 · 无需你处理
[输入消息 ]
```
中栏进展锚点只给一条高价值提示,不复制右栏全文。新目标通过新任务或已有受支持的输入动作落实,不默认承诺能动态改写在跑任务。
## 6. 快通道内容规范
### 6.1 不同场景怎样回复
| 场景 | 默认回复 | 后台信息 |
|---|---|---|
| 简单问答、短文本修改 | 先给答案,必要时给短依据或结果 | 无实际后台任务则不显示通道卡 |
| 发送材料、任务尚未登记 | “收到 3 份材料,正在准备整理”及已确认的接收/解析信息 | 不提前声称“已启动” |
| 材料任务已登记 | “已登记材料整理,完成后给出事实、差异与待确认事项” | 显示排队或运行真实状态 |
| 有明确分析/生成目标 | 一句话复述目标 + 当前能回答的内容 + 本次处理范围 | 实际启动后显示相应任务 |
| 用户追问后台知道了什么 | 基于最新快照给 2–3 条已发布发现,标出仍在核查的部分 | 不重复启动同一工作 |
| 发现阻塞/需要决定 | 直接说问题、对结果的影响及所需输入 | 复用同一个确认对象 |
| 后台结束 | 结论 → 关键要点 → 限制/缺项 → 产物或下一动作 | 回投当前结果版本 |
“每份材料一句概览”只在已有解析或阶段成果能够支持时给出。快通道尚未读到材料正文时,给文件清单和整理范围即可,不由文件名推断业务结论。
### 6.2 精炼但有用的内容骨架
短答默认 2–5 行;复杂结论默认一段总括、最多 3 个要点和一个主要动作。字数是初始排版预算,不硬截关键风险、金额、日期、否定条件或来源。
示例:
> 已收到需求说明、会议纪要和评审意见,材料整理任务已进入队列。整理会先核对关键事实、冲突与待办。你可以继续补充希望重点关注的问题。
有阶段成果后的示例:
> 目前发现 3 项需求缺少验收条件;两份材料中的上线日期不一致。评审意见仍在核查,完整结论尚未形成。你现在可以先确认上线日期的权威来源。
避免空泛重复“我正在深入分析”“请耐心等待”。工具名、系统提示词、模型自我描述不进入默认业务回复。无需用户决定时,不为了显得主动而硬加问题或三个无依据建议。
## 7. 慢通道任务卡与阶段摘要
### 7.1 运行中固定骨架
1. **标题与状态**:业务动宾短标题,如“核对三份材料”“生成需求说明”;状态词独立显示。
2. **正在做什么**:一句业务阶段说明,最多两行。如“核对需求条目与评审结论”。
3. **当前发现**:默认 1–3 条,按对目标的影响排序;每条表达“发现 + 意义”,有来源入口。
4. **剩余与下一步**:一句说明尚未覆盖部分及接下来处理内容。
5. **操作与时间**:只有真实可用的主动作;注明最近成果更新时间,耗时为次要信息。
任务刚开始时,“当前发现”显示“尚无阶段结论,正在读取材料”,不制造空白占位成果。无需用户操作的任务明确“无需你处理”,而非放一个不可执行的“继续”按钮。
```text
核对三份材料 进行中
正在核对需求与会议决定
当前发现
• 3 项需求缺少验收条件,暂无法判定是否可验收 [来源]
• 上线日期存在两种表述,需要确定权威版本 [来源]
已覆盖:需求说明、会议纪要的目标章节
剩余:评审意见中的变更记录
下一步:整理冲突与待确认事项
最近成果更新 14:32 [查看阶段与依据]
```
“已覆盖”必须来自已确认处理的章节、工具返回或有效检查点。解析完成与分析完成分开显示;“读过一份文件”不能自动计为该文件已全部分析。数量与统计只能来自可数、可去重的对象。
### 7.2 有工作价值的阶段成果
每次阶段发布应至少带来一个用户能利用的变化:确认事实、揭示差异、形成可用初稿、发现缺项、完成检查、给出必要决定。普通“调用工具”只更新活动状态和执行记录,不算业务成果。
| 工作类型 | 推荐业务阶段,按实际任务选用 | 默认最有价值的内容 | 最终呈现 |
|---|---|---|---|
| 材料整理 | 接收/解析 → 提取事实 → 核对差异 → 汇总 | 核心事实、共同结论、冲突、待办 | 短摘要 + 重要发现 + 来源 |
| 研究检索 | 明确问题 → 查找来源 → 对照证据 → 形成判断 | 已找到的依据、尚缺的证据、判断如何变化 | 结论 + 对比/依据 |
| 方案/需求分析 | 提取约束 → 检查覆盖 → 比较取舍 → 整理建议 | 缺项、约束、关键取舍及影响 | 建议 + 清单/对比 |
| 文档生成 | 确认范围 → 编排结构 → 生成草稿 → 校验保存 | 结构已定、待补材料、草稿状态、检查结果 | 精炼结论 + 正式工件入口 |
| 审查验证 | 确定对象 → 执行检查 → 归纳问题 → 汇总结果 | 会阻塞交付的问题、证据、未覆盖项 | 问题清单 + 实际检查结果 |
阶段不固定为所有任务必经的四步。检索/检查可能迭代回到前一阶段;通过阶段 ID 与版本记录,不以动画线性前进。没有领域阶段数据时降级为“读取材料 / 使用工具 / 整理结果”等确定性活动描述,不凭计时自动切阶段。
### 7.3 成果不是思维链
发布公开工作摘要、工具确认的事实、可交付的阶段产物和待确认问题,不把隐藏推理、系统提示词、原始任务提示或未完成 token 片段包装成发现。执行记录仅展示真实已有且当前用户有权限查看的记录;“展开”不意味着获得额外权限。
## 8. 精炼、来源与结论修订
### 8.1 发现的表达与排序
发现由一句结论和一句影响组成,通常合为一行:“指标定义不同,两个方案的达成率不能直接比较”。排序优先级为:需要用户决定的事项、会改变当前建议的风险、与用户目标直接相关的事实、其他背景信息。
去重按稳定 findingId 及来源版本处理;同一事实由两个任务发现时,展示一次并保留两条依据。差异表、审查清单按内容结构选择,不把所有成果强塞进统一长 Markdown。
### 8.2 用户可理解的结论标签
| 内容类型 | 展示文案 | 发布要求 |
|---|---|---|
| 材料直接记载的内容 | “材料记载” | 指向文件版本与位置;不等于事实已被外部验证 |
| 工具检查直接确认的结果 | “已核对” | 指向具体检查对象和真实结果;本地/独立/受信来源保留对应证据等级 |
| 基于若干来源推导的建议 | “分析判断” | 提供依据,说明影响结论的假设 |
| 尚有关键缺口的判断 | “初步判断” | 显示缺口、覆盖范围;不得写成最终结论 |
| 需要人决定的口径/事实 | “待确认” | 给明确问题和影响,并关联确认入口 |
这些标签描述内容性质,不提升 SELF/REPLAY/GATE 信任等级。不显示没有校准依据的“可信度 95%”。重要来源失效时保留历史结论,当前摘要标“依据已更新,需重新核查”。
### 8.3 来源定位与修订
来源至少包含项目/会话归属、文件或工件 ID、版本或内容摘要、可用定位信息及发布事件。优先页码、章节、段落;现有解析器没有页码时显示章节/片段,不编造定位。权限失效显示“当前无法访问该来源”,摘要权限同步重新检查,不以历史缓存继续泄漏内容。
输入复用身份必须包含实际内容摘要:优先原始文件内容 hash 与解析版本,缺少原始 hash 时至少包含实际解析文本 hash、解析版本与相关处理配置,不能仅用文件名和字数当版本。保留既有附件路由,但不同内容不得复用旧任务成果。当前材料键校正作为 U2 来源修订的前置依赖,可用关联修复增量交付;旧卡无法证明内容一致时仅作历史结果,不自动认定本次输入已经整理。材料键等兼容凭据应保留在受控元数据与旧客户端回退投影中,用户默认卡身不展示内部键。
发现具有稳定 ID、有效状态与版本:当前有效 / 已修正 / 已撤回 / 已被替代。后续推翻早先发现时,摘要替换当前有效项,阶段历史留一条“此前判断已修正”并给原因、影响和新依据。若曾需要用户据此行动,必须发一次有意义的更正提醒。
### 8.4 任务结束后的内容
```text
材料整理已完成
结论:当前材料可用于需求草稿,仍有 2 项关键口径需确认
• 核对出 3 项缺少验收条件的需求
• 上线日期冲突,需要项目负责人确认
• 评审意见的 2 条调整尚未反映到需求说明
范围:已覆盖三份材料的可解析文本;图片附件未纳入
[查看完整摘要] [查看来源] [确认交付物]
```
生成文件不代表用户已认可或文档已审签。另显示交付状态:草稿已保存 / 等待评审 / 已认可 / 已发布;正式状态只采用业务宿主确认结果。检查未执行时写“未检查”,不以“已生成”代替“已验证”。示例中的完成与发现仍为设计数据。
## 9. 动态更新、通知与阅读稳定性
### 9.1 更新来源与频率
采用两条信息路径:**确定性活动状态**来自任务登记、工具开始/结束、等待用户、存储结果等事件;**业务摘要**来自显式阶段成果或对已完成结果的受控压缩。模型只提交摘要候选,服务端校验来源、覆盖范围、版本与终态后发布。
| 变化 | 更新位置 | 初始调度策略 |
|---|---|---|
| 入队、执行开始、等待用户、失败/结束 | L0 + 原任务卡 | 持久化成功后立即发布;在线端到端目标 p95 ≤2 秒,待测 |
| 工具开始/结束、活动描述变化 | 原卡的活动行 + L3 | 同任务合并高频变化,普通视觉更新最多每秒一次 |
| 新阶段成果、建议发生实质变化 | 原卡 L1/L2 | 检查点发布;连续普通成果可在 8–15 秒窗口合并,首条有效成果不必等待窗口 |
| 必须用户决定、关键风险、更正重要结论 | 对话提示 + 原任务卡 | 绕过普通摘要窗口;同一事件幂等提示一次 |
| 没有新业务成果 | 活动行/连接提示 | 保留已有摘要;不自动追加“仍在分析”消息 |
| 多任务相继完成 | 各卡 + 合并完成汇报 | 原卡先显示结果;父会话空闲再合并汇报,不阻塞结果可读 |
时间参数是初始设计值,实施后通过可用性与性能验证调整,不是实时性已经达标的结论。执行日志收集不按视觉节流丢弃;合并的是显示更新和重复语义通知。
### 9.2 控制摘要成本
优先由当前执行器在自然检查点提交简短成果;必要时才另行压缩已完成的工具结果或阶段文本。不按每个 token、每个工具调用或每个定时 tick 运行新模型。
候选边界:单任务最多 6 次额外摘要模型调用;普通额外摘要最小间隔 15 秒;最终主任务的结果汇总属于执行预算,仍受已有整体预算控制。费用上限在实施评审时与模型、材料范围一起批准。预算耗尽或摘要生成失败时,保留已发布发现并继续显示真实活动;不阻塞主任务,不伪造阶段成果。
阶段成果发布应由运行时检查点驱动,不能只依赖模型自觉调用工具。没有可安全提取成果的长单次模型调用期间,只展示已确认活动与最近成果时间。若任务需要持续提供发现,可在不改变业务结论前提下拆成有产出的处理批次;这些提示词/行为改动需真实模型前后对照。
### 9.3 不打断阅读
用户阅读历史消息时不自动滚动;输入中不夺取焦点;正在看文件时不自动切“工作”或打开另一文件。出现新结果显示“1 项结果已更新”,由用户点击查看。用户主动等待的首次前台产物可沿用既有打开策略,但后台卡更新与 Surface 更新默认不抢占预览。
同一卡片稳定 DOM 与区块 ID;不逐字重打整段摘要。更新相应段落并可轻标“新”,保留展开、选择、滚动和置顶。屏幕阅读器只播报阶段结束、关键发现和需要处理;不播报每个日志增量。减少动态效果时不播放状态动效。
### 9.4 用户继续对话与调整要求
后台任务运行时,对话依然可用;前台忙时沿用现有输入排队语义,并明确“消息待发送”。追问“现在发现了什么”读取已发布快照,无需新派任务。
当前不假定在跑任务可动态接收新要求。补充内容应说明它将用于后续回合/新任务;如用户希望据此重新分析,创建关联的新尝试并保留原结果。未来可支持安全的任务输入修订,但必须有服务端确认“已接收并生效”后才显示生效。
### 9.5 确认双入口的提交反馈
对话与右栏按同一 confirmationRef 维护提交状态。点击后两处同步显示“提交中”并暂时禁用,收到服务端成功确认后才显示“已处理”。明确拒绝或提交失败时保留原问题、选项和错误原因;服务端返回已处理/版本过期时刷新共同对象,不能继续提交旧选项。
请求超时或连接中断不能证明动作未执行,先显示“确认结果待核实”并查询既有动作记录,不盲目重复执行。重试使用同一幂等请求标识和相同参数;参数已改变则按新动作重新检查。前端不得以一个入口关闭为另一个入口业务完成的依据。
## 10. 状态、异常与操作能力
把三个维度分开:执行状态、成果完整性、连接状态。卡片的收纳/已读状态属于第四个展示维度,不驱动业务终态。
### 10.1 执行状态
| 状态 | 用户文案 | 说明与动作 |
|---|---|---|
| preparing | 准备中 | 只确认接收范围;持久登记后进入 queued/running |
| queued | 排队中 | 队列已确认;只有服务器提供可信位置时显示序号,不给虚构等待时间 |
| running | 进行中 | 显示真实阶段及最新有效发现 |
| waiting_input | 需要你确认/补充 | 显示问题、影响、选项;无超时契约则不暗示自动继续 |
| succeeded | 已完成 | 执行及必要结果保存均成功;是否满足全部用户要求由成果维度说明 |
| failed | 执行失败 | 原因、影响、已保留内容和真实可用的恢复方式 |
| cancel_requested / cancelled | 正在停止 / 已停止 | 仅在支持相应控制契约时暴露操作;请求送达不等于停止确认 |
| interrupted | 执行中断 | 显示最后已保存检查点;恢复动作通过既有服务端支持判断 |
这些是候选展示语义,不宣称 Core 已具备全部同名枚举。`waiting_input` 映射现有 waiting_hitl 等明确状态;旧后台卡 `done + danger` 要由 run 终态与 tone 映射为失败。没有可靠 run 对应时使用保守文案“任务已结束,结果状态待核对”,不解析任意正文来推断成功。
成果完整性采用 complete / partial / none,并列出已覆盖和未覆盖范围。生成内容已经保存但汇报尚未送达时,显示“结果可查看,稍后在对话汇报”。交付保存失败时不能标“已交付”;可保留可读摘要并显示保存失败。
### 10.2 连接与恢复
在线 / 重连中 / 当前状态未核实只影响连接提示。60 秒没有新**成果**不等于执行失活;可显示“最近成果更新于…”,不能仅凭此声明失败。若要展示执行存活,须来自运行时心跳/执行所有权确认,另记录 lastActivityAt;现有源码没有已核实的通用任务存活契约,本方案将其作为新增设计。
断线期间保留最后已确认结果,停止“实时”声明。重连先取得带流游标的快照,再重放游标之后事件;历史保留不足时重新获取完整快照。服务重启导致 run interrupted 时,依据真实终态显示中断;是否可恢复、恢复是否可能重放副作用由既有恢复能力决定,UI 不自动重试。
### 10.3 按能力显示操作
基础动作:查看摘要、查看来源、查看阶段/执行记录、处理既有确认、打开已保存文件、收纳结果。动作带服务端能力和禁用原因;UI 不根据模型写出的按钮名自行分发。
暂停、独立取消、续跑、自动重试、改变在跑任务优先级不作为首期承诺。后台运行卡隐藏“关闭”式歧义动作,只提供折叠;收纳只影响历史呈现,不停止执行。现有输入区“停止”仍绑定现有前台能力;若其真实影响范围包含其他运行,必须如实说明,不能在本方案中改名为“仅停前台”而不修复契约。
失败提示采用“问题 + 影响 + 已保留内容 + 下一动作”。例如:“评审意见未能解析,本轮只完成其余两份材料;已保存两份摘要。请补充可解析版本后重新核对。”有保存凭据才声明已保存。
## 11. 多任务协作与领域展示
一个用户目标下的任务组只给一份整体概览,各后台任务保持独立摘要。后台上限沿用当前 3 个槽位,队列与入场等待按运行时确认展示,不另造默认无限并发。
总览优先突出阻塞与结论:“材料核对、竞品检索已完成;方案整理等待你确认预算”。只有明确可数的工作项才显示“2/3 项已完成”;这个比例不代表剩余时长或模型完成度。不能用工具次数、token 数或耗时估算百分比。
并行发现经规则合并引用,冲突同时展示:“来源 A 写 6 月上线;来源 B 写 7 月,尚未确认权威口径”。完成任务先稳定保存成果再通知;父会话忙时新结果可读,业务汇报待空闲,多个结果可合并为一条简短汇报。去重键包括任务、尝试和结果版本,防止通知回合再派发原工作。
领域可通过通用内容种类输出事实、差异、缺项、待办、建议和结果引用。RDM 类场景可由下游提供“受影响文档、验收条件缺项、审签状态”等内容与动作;基座不把材料整理“完成”解释为业务文档“已批准”。领域内容缺失时降级到通用摘要,不构造业务状态。
## 12. 视觉与排版规范
严格消费根 DESIGN.md,保持冷静、紧凑、内容优先的工作台。沿用用户此前选择的浅色克制方向,同时适配已有深色/墨绿主题。主题、字号与布局属于既有能力,实施不另造皮肤体系。
| 元素 | 排版建议 | 规则 |
|---|---|---|
| 任务标题 | 基准字号、中等字重,状态靠右 | 优先业务名称,完整标题可换行;不挤满任务 ID |
| 当前工作行 | 基准字号,主文本或次级文本 | 动宾语句;不重复标题或“慢通道”标签 |
| 发现 | 基准字号;每条一至两行,3 条以内默认可见 | 保留影响与关键限定;来源紧邻对应发现 |
| 范围、下一步、更新时间 | caption/sm 标尺;使用可读次级文字色 | 关键状态不能用 faint |
| 进度 | 有数据时用步骤清单与真实数量 | 无百分比/ETA 表盘;活动用既有 mk-sweep/mk-breathe |
| 动作 | 每张卡最多一个主动作,查看类为 ghost/链接 | 无需处理时不硬凑按钮 |
| 长表/完整报告 | 详情/文件阅读档 | 默认卡只留摘要;宽表按需横向阅读 |
卡内用 8/12/16 的重复间距;通过标题、段落和表面层级组织,避免一层卡套一层卡。圆角只用既有令牌,折叠统一 `@ui` Collapsible,状态动画只用 `mk-*`。所有图形状态同时有状态词与可访问名称。颜色不能替代状态语义。
桌面沿用可拖三栏,右栏工作宽 280–560、文件阅读宽 420–1100 的现有规范。窄屏优先保留对话与 L0,任务摘要内联展开;文件仍通过同一预览对象打开。长文件名、中文长标题、18px 用户字号、320px 宽度都不得丢失必要动作。不得靠把全卡文字缩到 11px 解决拥挤。
运行卡与完成卡沿用相同结构:结束后移除活动动效,当前工作区变为最终结论,保留来源与缺项。不要整张卡消失后另造结果卡造成位置跳变。最终文件卡的显示遵守 DESIGN.md:执行期仅说明草稿/保存状态,正式可打开交付物在结束并确认保存后出现;中途检查点文字可读,但不伪装成最终交付物。
## 13. 技术设计:确定性状态 + 可验证摘要
### 13.1 职责
| 层 | 职责 | 不承担的职责 |
|---|---|---|
| Core | 定义任务摘要、发现、来源、动作能力的共享契约 | 不生成领域结论 |
| Runtime | 提供真实执行阶段、工具结果、检查点和摘要候选 | 不自行宣告权限/存储/最终成功 |
| Backend | 服务端权威投影、校验、持久化、事件发布与通知 | 不把模型叙述当执行证据 |
| Frontend store | 按 task/run 与事件作用域更新同一快照 | 不由计时编造进度,不分别生成两套摘要 |
| UI | 纯展示,稳定折叠/排版/动作事件 | 不直连模型,不拥有业务异步状态 |
| Documents | 本方案、内容规范、验收与关联记录 | 不承担运行状态 |
| 下游/插件 | 提供领域成果与受控丰富视图 | 不替代基座任务状态与权限 |
优先在既有 runmgr/card/store 链路补齐投影,不另建进度微服务或独立状态仓。后台与前台按 runId 路由,前台消息仍用现有 live;后台进度使用按任务键控的结构化快照,防止共用单个 live 正文。
### 13.2 候选数据形状
以下是契约草图,字段名在 Core 设计评审时固定,不是可直接执行的 API。
```text
TaskSnapshot
taskId, projectId, conversationId, sourceMessageId
parentTaskId?, attemptId, runId? # 排队时可以尚无 runId
revision, streamScope, sourceSeq
title, goal, inputRevision
executionState, outcomeCompleteness
phase { id, label, observedAt }
focus, coverage, remaining, nextStep
findings[] { id, text, impact, kind, status, sources[], revision }
actions[] { id, capability, enabled, reason?, confirmationRef? }
resultRefs[] { artifactId?, surfaceId?, version, availability }
lastActivityAt?, lastMeaningfulUpdateAt
deliveryState, error?
ClientViewState # 展示偏好,不改业务状态
taskId, collapsedSections, pinned, readRevision, scrollAnchor
connectionState
```
taskId 在排队前持久登记并关联同一张卡;runId 表示一次实际执行,attemptId 区分新尝试。旧失败和新尝试不互相覆盖。readRevision 与 dismissed/收纳分离,用户读过不意味着执行已完成。
为兼容旧客户端,ActivityCard 可添加可选结构化摘要字段并保留 Body 的精炼回退投影;旧客户端看 Body,新客户端用结构化内容。核心信息的唯一权威仍是服务端快照;不得用独立 JSON、Markdown 和 Surface 各维护一份互不核对的业务状态。Body 与 Surface 是从同一快照派生的展示。
### 13.3 发布与恢复流程
```text
真实运行事件/阶段成果
→ 运行时语义映射与摘要候选
→ 服务端校验:归属/执行对象/来源/权限/版本/长度
→ 原子保存快照 revision 与对应投影事件
→ 既有 card.updated 会话流发布
→ 前端按作用域 seq、taskId 和 revision 更新
→ L0/L1/L2 同步呈现
→ 关键变化进入幂等通知;L3 保留执行记录
```
持久化与事件写入须原子一致;优先使用既有事务/持久事件机制,若当前 cards API 不能支持原子更新,先补齐内部事务入口。终态正文、状态、tone 应作为同一快照发布,避免先出现失败正文后仍亮成功灯。不能只靠客户端临时合并掩盖持久状态不一致。
消费顺序按**会话流或项目流各自游标**;不同流的 seq 不可比较。重复事件不二次通知,旧 revision 不覆盖新快照;出现游标间隙先对账/重放,不仅执行 `max(seq)` 后跳过未知事件。会话切换隔离响应,迟到事件按归属放回缓存或丢弃,不能写到新会话。
快照读取返回与其一致的重放水位;获取期间继续到来的事件需缓冲并在快照后顺序应用。排队、启动、最终保存、通知待发送均可刷新恢复;不得只把动态发现放在内存 `agentNotes`。恢复与副作用规则与既有服务恢复方案衔接,本次不建立第二套恢复执行器。
**重启对账不能把展示快照当作执行队列。** 当前等待后台槽位的 bgQueue 仅在内存,无 runId 的排队卡不在既有 run 恢复扫描范围。U2 启动对账须区分“可读历史快照”与“已确认重新拥有执行者”:没有可信持久入队凭据或执行所有者的 queued 任务转为 interrupted,并同步旧卡回退状态与材料去重状态,显示“排队任务未恢复,未开始执行”,不自动重派。只有既有执行系统确认队列恢复后,才可继续显示排队并允许晋升;首次增量不承诺队列自动续跑。
### 13.4 生成式成果与普通任务卡
已有 Surface 可用于对比表、报告页、审查清单;基础状态、风险提示、确认与失败始终由确定性组件呈现。后台 Surface 更新只提示“结果页已更新”,不自动切预览;需要在现有 Surface 投影策略中区分前台主动呈现与后台更新。
插件禁用或页面渲染失败时,任务摘要仍可读,来源和基本动作仍可用。Surface 的动作继续走现有受控命令能力,不从摘要文本或外部材料解析可执行命令。
## 14. 落地顺序与 U1 出口白名单
下表是已批准的分期顺序。**首批锁定仅 U1**;U1 业务代码须另批 [U1 实施计划](2026-10-12-fast-slow-channel-display-u1-plan.md) 后方可启动。各增量的具体文件、迁移、运行材料与费用以对应实施计划为准。
| 增量 | 关联需求 | 范围与依赖 | 出口 |
|---|---|---|---|
| U1 统一状态与精炼内容 | R01/R02/R03-a/R08/R10(骨架)/R13 | Core/UI/Frontend/Backend;旧卡兼容及状态映射;L1 骨架重排;去除原始提示词默认展示 | 见下方 U1 出口白名单 |
| U2 持久动态任务投影 | R04(活动投影)/R05(结构)/R06/R09/R12/R17/R03-b | 依赖 U1;材料内容版本身份校正前置;Core 契约 → Backend 快照/事务/事件及无 runId 排队重启对账 → Frontend 按任务路由 → UI 动态渲染;运行时确定性阶段 | 并发、刷新、重连、乱序和终态一致;阶段活动持续更新;无执行凭据的排队任务不得永久显示排队 |
| U3 有价值的阶段成果 | R03-c/R04/R05/R07/R10(完备)/R14 | 依赖 U2;Runtime 检查点、来源、候选摘要、通知去重;优先材料整理,再研究/生成/审查 | 选定长任务至少两个真实成果检查点;短任务可直接完成;事实、判断、缺项可分;必要动作闭环 |
| U4 场景与可用性完善 | R11/R12/R13/R15/R16/R18 | 依赖 U3;多任务总览、修订提醒、窄屏、可选 Surface、领域适配;未支持控制能力仍不暴露 | 典型场景完成真实浏览器及用户评审;精炼度与可用性目标有实际记录 |
跨仓以 Core 类型权威优先;Backend vendored Core、Frontend/UI 消费固定提交;Dev 推进精确 gitlink,组合测试后评审。视觉规则变动需要与 DESIGN.md 配套;只消费既有令牌时不为本任务无故新增色板。
### U1 出口白名单(定稿)
**须交付并可判定**
- 排队 / 进行中 / 已完成 / 执行失败 状态词与状态灯一致;失败使用失败语义(不得再以「完成」灯表示失败)
- 建卡默认 Body 为 L1 骨架,不以原始任务指令(≤400 字截断)作为主视图
- 无阶段成果时显示诚实占位:「尚无阶段结论,正在读取材料」或等价文案
- 完成卡骨架:结论 → 最多 3 要点 → 范围/缺项 → 产物入口(有则显示)→ 必要下一动作
- 简单问答不产生空进度卡;仅登记成功才说「已登记」,仅实际开跑才显示「进行中」
- 旧卡兼容:历史 `done + danger` 在新客户端映射为失败展示,不崩溃
- DESIGN.md / 令牌 / Collapsible / `mk-*` 相关守护通过
**明确排除(不得用 U1 验收)**
- 运行中真实业务发现、来源定位、检查点驱动摘要(R03-c / U3)
- 按 `taskId` 持久 `TaskSnapshot`、revision/seq 对账、材料内容 hash 身份(U2)
- 无 runId 排队任务重启 → interrupted 对账(U2)
- HITL 双入口提交中 / 超时未知 / 幂等闭环完备(U3)
- 窄屏完整能力、多任务总览、Surface 增强、修订提醒(U4)
- 暂停 / 独立取消 / 续跑等未支持控制能力
合并 U1+U2 为基础投影批须**另行明确批准**;即便合并,阶段发现仍属 U3。
## 15. 验收、证据与失败判据
所有下面的运行场景为**计划验收,NOT_RUN**。示例数据只用于评审排版,不当作真实链路通过证据。
| 用例 | 关联需求 | 关键观察 |
|---|---|---|
| A01 三个附件、无文字直接发送 | R01–R05/R10 | 已确认接收 → 同卡排队/运行 → 有成果则发布 → 完成摘要与选择;选定长材料验证两个真实成果检查点,短材料可直接完成;不重复派发 |
| A02 小材料加明确分析要求 | R01/R02/R04 | 即时答复与现有兜底路由一致;不声称尚未登记的任务已运行 |
| A03 三个后台任务 + 前台对话 + 第四任务排队 | R02/R06/R09 | 各任务归属正确;排队晋升复用 ID/卡;前台正文不串后台 token |
| A04 部分解析失败/无可解析文本/材料超预算 | R03/R05/R08 | 显示已覆盖、缺项与影响;解析与分析完成不混同;无法分析则不生成假摘要 |
| A05 用户追问与补充重点 | R01/R07/R15 | 读取当前快照;新要求生效范围明确,未实现动态输入时不假承诺 |
| A06 早期发现被推翻、来源文件更新 | R05/R17/R18 | 当前结论修正、历史可追溯;重要更正通知一次;同名等长内容更新不得命中旧材料结果;过期版本不覆盖最新 |
| A07 断网、刷新、换会话、重复/乱序事件 | R06/R09/R12 | 保留最后快照;恢复水位一致;状态不回退;旧会话数据不写入新会话 |
| A08 模型失败、预算耗尽、摘要不可用、服务中断 | R08/R09/R14 | 正确显示失败/中断;包含无 runId 的排队任务重启后对账及材料去重释放;基础状态与既有成果仍可读;无自动副作用重试 |
| A09 前台忙时后台完成、通知重投 | R04/R10/R17 | 结果卡先可读;汇报待空闲;重投不重复通知或派任务 |
| A10 同确认双入口与重复点击 | R07/R11 | 提交中、成功、拒绝、超时未知、过期/已处理响应都一致;重复点击只执行一次;右栏关闭也可处理 |
| A11 文件正被阅读、Surface 后台更新/插件关闭 | R11/R12/R16 | 不抢焦点、不切文件;插件关闭核心任务卡不缺失 |
| A12 未授权跨项目/用户来源、读权限撤销 | R05/R09 | 新摘要、来源与历史缓存无越权;只显示许可范围内内容 |
| A13 文件保存失败、文件已更新/已移除 | R08/R10/R17 | 不出现虚假可打开工件;版本与保存状态准确;有可读摘要不等于已保存文件 |
| A14 320/390/736/1024/1440 宽度与用户字号档 | R11/R13 | 无页面级横向溢出,必要动作可达,键盘/屏幕阅读/减少动效符合规范 |
验证分三层:契约与投影测试确认状态/顺序/并发;真实模型任务前后对照确认阶段成果质量;真实浏览器与用户任务确认排版和工作价值。不能用 mock 进度验证真实模型发布了有用摘要。
行为改动按 policy/delivery.md 真实模型要求执行:固定候选组合、同材料同任务前后对照、记录模型/参数/费用/失败及来源。正式检查使用 `make evidence` 写入 precheck、task-sync 和相关测试原始输出;Dev CI 在 PR HEAD 上的 `make test`、`make build` 作为 GATE,作者本地记录仍为 SELF。设计文档检查不代替这些运行验证。
可用性记录至少覆盖三类任务:材料整理、分析审查、文档生成。请代表性用户完成第 1 节三问并定位一条来源、处理一次确认、找到一份结果;记录完成时间与错误。精炼度以“是否漏掉关键限定/风险、是否能支持下一步工作”评判,不能只统计字数变短。
实施停止/回退条件:发现状态串任务或越权内容;终态与存储不一致;修订导致当前有效结论丢失;摘要循环显著超预算;关键确认被折叠藏起;真实模型阶段成果持续无依据。先回退受影响展示/摘要增量,保留原执行与已保存结果,按实际影响重审。
## 16. 评审与当前进展
| 项目 | 当前状态 |
|---|---|
| 当前源码核对 | SELF;固定对象与输出在任务卡;不等于运行验收 |
| 需求拆解 / 需求评估 / 需求表 / 方案设计(阶段 1–4) | **已通过**(2026-10-12,对象版本 r1.1;评审人 weichen;依据:用户确认评审结论计划并指示落地) |
| 实施计划(阶段 5) | U1 计划见 [u1-plan](2026-10-12-fast-slow-channel-display-u1-plan.md);**待用户批准该计划后**方可启动业务代码 |
| 辅助设计审阅 | 七个视角 SELF 辅助分析已纳入 r1;不提升为 REPLAY/GATE |
| 业务实施、真实模型实验、运行与浏览器验收 | NOT_RUN |
| 推送、PR、合入、部署 | 本方案任务未执行;文档推送/PR 须另获授权 |
本次推进的是快慢通道用户展示设计,不改变现有附件路由和生成式 UI 规划的批准状态。与既有恢复/团队存储方案的重叠仅为消费其执行终态、权限与恢复能力;新增持久字段和事务入口须评审后协调,不自行修改其他任务的主记录。
辅助审阅覆盖一致性、范围、可行性、设计、产品、对抗与安全七个视角(其中一致性/范围、设计/产品/对抗/安全分别由同一子代理分析,并非七名独立审阅者)。采纳并自行核对后修订五类问题:两次成果检查点只用于代表性长任务;新增要求的生效文案不误导;确认双入口补提交与未知结果状态;材料版本复用需实际内容身份;无 runId 排队任务重启时不能假装仍有执行者。
r1.1 相对 r1 的定稿修订:R03 切分为 a/b/c;U1 出口白名单与排除项写入 §14;首批锁定仅 U1。摘要次数/窗口与性能数字仍为候选参数。**设计批准不等于实施授权**;批准 U1 实施计划后另开实施任务,本设计任务不自动启动写代码。
@@ -0,0 +1,48 @@
---
title: Generative UI auto-trigger opt-in design
date: 2026-10-12
type: feat
revision: r1
status: approved
product_contract_source: generative-ui-r2-U6-U7-boundary
---
# Generative UI 自动触发 opt-in 设计(r1)
依据:主记录 r2(语义事件 / 预算 / 防自激);收口稿已知边界;用户 2026-10-12
计划确认「边界三项全部做」并将本表定案作为实施基线。
负责人:裁定 weichen(用户,经执行计划确认);起草 Agent;更新时间 2026-10-12。
## 定案表
| 项 | 定案 |
|---|---|
| 开关 | owner 级 settings:`plugins.generative-ui.autoPresent`,默认 `false`;**不**写入 `plugin_activation`(避免 bump epoch) |
| 前提 | `plugin_activation(generative-ui).enabled` 为真;否则 auto 无效 |
| 事件 | 仅:任务阶段跃迁(plan/todo 状态变化)、材料/工件完成(material notice、document artifact) |
| 禁止事件 | per-token / 每条 SSE、`surface.updated`、动作回执、present 成功路径 |
| 动作 | 注入 system-reminder,**只**建议调用一次 `generative-ui.present`;不自动点 actions;不改写任务事实 |
| 预算 | 每任务(conversation)每小时 ≤3 次;耗尽写审计 `genui.auto_present_exhausted` |
| 冷却 | 同会话自动触发间隔 ≥60s |
| UX | 复用 U6 pin/follow;固定后新页不抢占 |
| 门槛 | 扩大范围仍以人类效率约 +20% 为后续条件;本增量只落地最小 opt-in |
## 实施面
- Backend:settings schema/defaults;`genui.Auto` 闸门;runmgr 语义钩子;审计。
- Frontend:SettingsModal 经 schema 出开关(无需专用页)。
- Documents:本提案 + 使用说明边界条目更新。
## 验收线
1. 默认关:无 reminder / 无额外 present 建议。
2. 仅 activation∧opt-in 时,材料完成 / 阶段跃迁 / document 工件可触发。
3. surface/action/present 路径不重入。
4. 第 4 次/小时审计耗尽并停止。
5. 冷却内跳过。
## 裁定记录
用户经「Implement the plan」确认本定案表;本文 `status: approved`,实施任务
`feature/genui-auto-trigger-optin` 按本表交付。
@@ -0,0 +1,59 @@
---
title: Generative UI B-class whitelist — builtin.help and system.intent
date: 2026-10-12
type: feat
revision: r1
status: approved
product_contract_source: generative-ui-u5-action-scope-r2
---
# Generative UI B 类加白提案:builtin.help / system.intent
依据:[U5 动作范围 r2](./2026-10-11-generative-ui-u5-action-scope.md)「每加一条走独立评审」。
本提案对两条命令分别裁定;实施与本提案同批合入。
负责人:裁定 weichen(用户);起草 Agent;更新时间 2026-10-12。
## 授权
用户 2026-10-12 计划确认:边界三项全部推进;B 类首批加白 `builtin.help` 与
`system.intent`。交付模式:authorized-continuous(本增量实施至 Dev 合入)。
## 一、builtin.help(独立裁定)
| 项 | 内容 |
|---|---|
| 命令 id / action id | `builtin.help` |
| 类 | B(白名单命令绑定) |
| 危险级 | 低(只读说明,无写副作用) |
| 参数 | 无必填 |
| 通道 | `POST /api/surfaces/{id}/actions` → cmdbus Entrance=`button` |
| 用途 | 页面按钮展示可用命令/入口说明 |
| 排除项对照 | 非业务写、非跨会话、非自动触发动作、非 MCP |
**裁定**:同意加白。
## 二、system.intent(独立裁定)
| 项 | 内容 |
|---|---|
| 命令 id / action id | `system.intent` |
| 类 | B(白名单命令绑定) |
| 危险级 | 入口本身低;**命中后嵌套分发可触达写命令**(既有 chat 行为) |
| 参数 | `text`(string,必填) |
| 通道 | 同上 Entrance=`button` |
| 硬化(加白前提) | **button 入口只返回 match / candidates,禁止嵌套 `Dispatch` 目标命令**;chat/slash/api 等既有入口行为不变 |
| 用途 | 页面上做意图探测/候选展示,不经按钮偷渡 D 类写 |
| 排除项对照 | 嵌套业务写在 button 路径关闭;仍禁止自动触发动作、MCP、任意命令全开 |
**裁定**:同意加白,前提硬化生效并有红测。
## 三、实施面
- Backend:`surfacesvc.AllowedActions`;`genui.ValidateActionIDs` / Catalog;`handleSystemIntent` button 只读。
- Documents:本提案 + 使用说明 API/动作表白名单更新。
- 红测:白名单外拒绝;help 可分发;intent button 命中写意图零副作用;chat 仍可嵌套。
## 四、明确不做
D 类业务写直执、扩大白名单至其他内置写命令、自动触发动作、动作结果自动改写页面。
@@ -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,383 @@
---
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 单实例保护及近期验证合同。原故障档和时间指标保持候选值,未宣称实测达标。
r3.1=同日增补 D1/D2/D3(部署根治;编号避开本案 U1–U8)。映射:D1 补 U1 身份消费缺口,D2 补 U6 部署回退,D3 补 U7 真实组合门禁。确认状态:用户 2026-10-12 授权按实施计划连续推进到 PR 可合入;本节新增条款仍供人工评审,不代签 r3 其余未批内容。
需求来源:2026-10-12(Asia/Shanghai)用户要求“系统应该在停止并再次启动(通过 svc 或异常终止)后,应当能够恢复所有服务和数据,给我一个完善方案”。负责人:weichen;编制:Codex;实施与运维负责人在启动对应增量时指定。
主记录:本文;任务卡:Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
## 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通过并完成合入/部署后,才可声明“系统停止或异常终止后能够恢复所有服务和数据”。
本轮交付状态止于**待审核方案**;不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。
## 11. D1/D2/D3 部署根治补充(r3.1)
编号 D1/D2/D3 只属于本补充,避免与本案 U1–U8 重名。已合入且不再重做:Dev #474(按实例重置身份变量、停旧前候选门禁、update 走 manifest 迁移、普通启动只验证)、Backend #180(`pkg/identity`)、RDM #276(identity 子命令与未知位置参数退出)、Dev #477(backend pin 到含 #180 的 `acabb85`)。
### 11.1 现场快照与 rdmcand 数据归属(SELF,2026-10-12T13:39:21Z)
快照目录(在线 `sqlite3 .backup` / RDM `VACUUM INTO`,未停服务):
- `runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z`
- `runtime-backups/{dev,rdm1,rdmcand}/domain-20261012T133921Z`
只读核对副本,未移动任何业务数据。rdmcand 在 `2026-10-12T06:51:14Z`–`10:02:40Z` 使用 `runtime/dev/data`。该窗口内:
- dev 库的会话、消息、事件均不落在窗口内。最后一条消息时间 `06:50:43Z`,早于 rdmcand 挂上该目录。会话与用户属于 dev(owner `weichen`、`genui-smoke`)。
- 窗口内仅有 13 条 `command_audit`,全部是 `rdm.inspect.*`,owner `weichen`,没有领域事件。
- 三份 `rdm.db` 的 `events` 均为 0。dev 的领域库更大(含权限表,schema_version=6),rdm1/rdmcand 的领域库只有字典与 schema 行。
- rdm1/rdmcand 的 `agent-system.db` 只有 `2026-10-12T13:19:47Z` / `13:20:12Z` 由候选门禁写入的身份行,没有业务行。
处置(未执行,需逐项授权):不把 dev 的会话或领域库迁到 rdmcand。没有一份应属于 rdmcand 的历史领域数据需要回迁,因此不触发身份 `adopt` 重审。rdm1/rdmcand 当前库是空壳加已建立的身份行。
### 11.2 D1 身份流程收尾
对应 U1 的消费缺口。完成条件:
- 身份 CLI 只打开既有库:不建文件、不建目录、不迁移。`agent_system_identity` 表(v27 起,列冻结为 instance_id/dbref/schema_version/created_at)缺失则拒绝并提示受控迁移。比本二进制更旧或更新的 schema,只要该表仍在,verify 仍可读。
- verify 输出带 `schema_version`。DSN 走 `AGENT_SYSTEM_DSN` 或权限恰好 0600 的 `--dsn-file`;`--dsn` 保留并告警。
- 能力文档一份 JSON,经 `version --json` 与 `identity capabilities` 输出。探测只跑 `version --json`,在空目录、清空环境、超时内执行。非 JSON 视为无能力。
- 顶层未知子命令 exit 2,不以 `-` 开头才拦截,避免落入 serve。
- manifest `identity.db_marker`:`fresh` | `pending` | `established`。新实例首次部署目标目录必须为空,启动建库后 ensure 变为 established。领养时有能力且库已存在则 ensure,否则 pending。pending 只在库文件存在时补齐,不迁移。established 缺行或不匹配时,start/restart/deploy/update/recover/init 全部拒绝;唯一修复入口是显式 `adopt --confirm <instance_id>`,并先打印库大小、关键表行数和最近写入时间。
- `svc_lifecycle` 是 start/restart/deploy/update/recover 的共同入口。update 与 recover 逐服务以 `env -i` 启动子进程,不传入 `AGENT_SYSTEM_*`。serve 使用显式环境,并写入 0600 的 `serve.env` 供裸启动与 recover 复用。
### 11.3 D2 切换事务
对应 U6 的部署回退。制品进入 `runtime/<name>/releases/<rid>/`,`current` 用临时符号链接加 `mv -T` 切换。`bin`/`plugins`/`htdocs` 改为指向 `current/` 的稳定链接。切换日志 `deploy-journal.json`(0600)先写 phase 再执行。失败回到上一版本并恢复原期望运行态,不覆盖业务库。schema 不兼容时在停旧服务前拒绝。前进迁移必须 `deploy --migrate-schema --confirm <instance_id>` 且先 backup,日志标记 forward-only。能力文档增加 `schema.target` 与 `schema.compatFloor`;每条迁移登记是否破坏旧版读取,漏登记则测试失败。
### 11.4 D3 真实组合门禁
对应 U7 的故障验收入口,范围限于部署生命周期。Dev 用 `tests/integration/lifecycle/rdm.pin` 固定 RDM SHA(当前、上一版、无 identity 的旧版)。CI test-pg 按 pin 取固定 SHA,白名单加入 RDM 及其 pins。`make test-lifecycle` 缺 PG、源码或制品即失败,不静默跳过。桩测试不能代替该门禁。RDM 登录入口与账户 CLI 的 DSN 退出命令行依赖账户方案 U7/U5;未就绪的项保持 NOT_RUN,D3 不得标完成。
### 11.5 验收
缺一项则对应增量保持未完成:双向混合批次身份不串用;无 manifest 时 deploy/update/recover 一致;无能力、缺行、不匹配在停旧前拒绝且不建库;两次裸重启及换端口、换版本、换目录后身份不变;构建失败、启动即退、健康超时、工作台失败可回滚;切换中断后登记与制品一致;真实 PG 绑定与多实例检查通过且凭据不进命令行、日志和证据;RDM 页面、登录、领域命令和原有数据可验证,不能只看 HTTP 200。
@@ -0,0 +1,245 @@
---
title: svc 统一部署与一次性登录 Key 方案
type: feature
date: 2026-10-12
artifact_contract: ce-unified-plan/v1
execution: code
product_contract_source: ce-plan-bootstrap
---
# svc 统一部署与一次性登录 Key 方案 r2
确认状态:**r1 原批准保留;r2 本轮增补待人工评审**。r1 的批准记录为 2026-10-12 用户「批准,继续推进」(五阶段及 U1/U4 规格,允许对应实施和 PR)。本轮用户要求仔细调研、详细方案并「继续」,覆盖方案修订及本地文档准备,不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。
修订记录:r1=2026-10-12 草案经源码复核后定稿(四项取舍采纳;补齐 §6 合同;对齐恢复方案 KTD 与已合入的 recovery U1 实例身份);同日获批并进入推送与 U1/U4 实施。
r2=同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口;保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号,补充 R13–R15、KTD11–KTD14、U7/U8,并细化 U5。新增内容未批准;不以原批准记录代签新增范围。
需求来源:2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口(二进制与源码、环境准备、无初始密码开户与账户恢复),并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人:weichen;编制:Cursor Agent。
主记录:本文;任务卡:Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。
## 1. 目标与成功边界
**目标:在干净或既有机器上,用同一套 `svc` 入口完成二进制或源码部署、按档准备依赖,并通过后端账户能力完成无初始密码开户与账户恢复;一次性登录 Key 只能兑换设密受限会话,完成设密前不能访问业务数据。**
必须区分三类能力:
| 能力 | 结果 | 非目标 |
|---|---|---|
| 统一安装 / 升级 | 指定版本或提交物化为可切换候选;切换后实例身份、DB、数据根与账户不变 | 不接管共享 PostgreSQL;不因发现端口而认领外部服务 |
| 环境检测与准备 | `doctor` 只报告;`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建;工具链版本读自所选提交或发布清单 |
| 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key;原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户;不迁移业务归属;普通找回默认不撤销长期集成 Key |
与 [服务重启与全量数据恢复方案](2026-10-12-service-restart-data-recovery.md) 的关系:
- **复用** KTD1–5、KTD12:持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。
- **复用** 已合入的 recovery U1(Dev #415):`runtime/<name>/manifest.json`、启动身份校验、`svc init`、原子写路径(见 Dev `docs/recovery/u1-identity-manifest.md`)。
- **本方案新增**:部署来源统一(binary/source)、doctor/env prepare、账户生命周期与一次性登录 Key、安装入口与双轨收敛。
- 命名区分:**账户恢复 Key** ≠ **服务数据恢复**。
## 2. 当前事实及重点差距
本轮 source 基线(SELF):权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`;文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`(增加任务元数据);Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`;Frontend `cc233fec908d0f8c12193042942b94ad68508091`;Dev 固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。本轮 Documents 草案从其独立权威 main `1048e7c6afc2bb4efc541e68575c3fb2669ee332` 起步;与 Dev 固定版相比,两份目标方案正文没有上游差异。Dev gitlink 未推进。原 r1 基线只作历史,不用于当前能力判断。
2026-10-12 17:37:03(Asia/Shanghai)的只读运行观察和启动/同步命令,原始脱敏输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。这是 SELF 观察,不是登录、故障或恢复验收,后者均 NOT_RUN。
最终同步基线为 Dev `d6d46fde6d903d0d8e37440d830fb5183d6ef5e9`:主干另已推进固定 Documents 至 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`,并修复 svc 批量操作的 PIDCHECK/EXEC 等内存态串用;本轮未重复该修复,也未推进本轮 Documents 草案 gitlink。Backend/Frontend 固定 SHA 未变;上述初始基线和17:37观察保留历史时点,不冒充最终 HEAD。
| 对象 | 已存在的基础 | 尚需补齐 |
|---|---|---|
| 部署来源 | `deploy --from local\|dev\|release\|rdm`;dev/rdm 独立缓存物化;release 读本地 Releases 仓并校验 sha256 | 远程下载/离线导入;统一 `install`;release@ver 钉扎(现 `sort -V\|tail -1` 取最大版本,见 `scripts/svc.sh` `resolve_release`) |
| 部署生命周期 | 预检失败不停机;预检通过后 **先停再构建**;无程序备份/自动回滚 | 候选获取与校验全程不停旧服务;缺摘要硬失败;迁移后回退独立判断 |
| 实例身份 | recovery U1:manifest + marker + init;`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置;缺绑定拒绝,禁止回落 `./data` |
| 环境 | 端口/`flock`/pg 工具链按需检查;文档列前提 | `doctor` / `env prepare`;无 `flock` 时不得放行冲突操作(现状直通) |
| 账户 CLI | Backend 已有 create/reset-password/list/issue-login-key/revoke-login-key/bootstrap-admin;svc 已接 `user` 且附加 OpenExisting | 顶层/专题帮助未列账户入口;OpenExisting 仍 migrate;账户路径未完整验证 DB identity;参数回显及 argv 凭据需整改 |
| 登录凭据 | 长期 `api_keys` 与独立 `login_keys` 已分离;一次性 Key 原子兑换为短期受限会话 | 原子开户+签发、统一密码变更及审计仍有缺口;不能把基础实现等同于整体验收 |
| 强制改密 | Backend 已有受限会话和 must-change 中间件,强制设密成功销毁会话并要求重新登录 | Frontend 仍只有密码/长期 Key 两个入口,未接兑换及 sessionScope/reloginRequired;设密后直接 onDone 与后端不兼容 |
| 安装双轨 | Dev `svc deploy` 多实例;Releases `install.sh` 系统 systemd | 统一部署计划;`install.sh` 薄封装或明确遗留 |
命题裁定(源码复核):
1. 长期 API Key 是 show-once plaintext,不是 single-use;一次性登录 Key 是独立类型,当前代码已区分。
2. r1 所记「无统一改密门」已被 U4 源码覆盖,不能继续作为待建能力;普通改密/管理员重置仍缺统一事务及旧恢复 Key 作废,见 `modules/backend/internal/server/accounts.go:208`、`modules/backend/internal/store/auth.go:244`。
3. `scripts/svc.sh:1503` 已实现 user 转发,但帮助未列;`modules/backend/internal/app/app.go:743` 的账户插入和 Key 签发分别提交,不能采信注释中的「同事务」。
### 2.1 dev 8788 事件与归因边界
用户明确故障对象为 dev(127.0.0.1:8788)。17:37 的实际进程打开 `runtime/dev/data/agent-system.db`,数据库 marker 为 dev 的 SQLite 身份;该现场没有使用 PostgreSQL,不能沿用旧报告的 pg1/agent 描述。
| 只读对象(北京时间) | 账户身份 | 最后设密时间 | 与 live 摘要比较 |
|---|---|---|---|
| 12:35:03 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
| 14:50:37 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 |
| 17:37 的 live | 同一账户,must-change=0 | 16:03:20 | 当前值 |
比较仅输出时间、状态及相等性,不输出摘要或凭据。它证明字段重写,不证明明文改变;随机盐使同一明文的重新散列也可能不同。未发现正常启动/更新/迁移 up/设置播种自动覆盖既有密码的路径;现有 audit_events 只有 Surface 事件,无法归因此次写入。另有已消费恢复 Key,但其消费时间不能证明之后哪次设密由它触发。
前一轮观察到 dev 与候选 rdmcand 指向同一数据根;17:37 候选处于停止,因此历史共享不写成该时点双进程事实。18:14:09 续查时,外部流程已将候选重新启动于独立的 `runtime/rdmcand/data/agent-system.db`,实际文件 inode 与 dev 不同,登记和制品版本相符;dev 最后设密时间仍为16:03:20。这缓解了当前共享现场,不能代替 Backend 防误用锁或完整验收。历史共享说明跨实例影响范围,不证明某次更新主动改密;本轮未执行这些现场变更。
本轮不进行真实账户登录尝试或再次重置来验证旧密码;故障重放仅在脱敏、独立数据副本上执行。首批完成还需另行授权的 dev 原账户正常登录验收,见 U5/U8 合同;该验收不在 live 进行 kill、并发或故障注入。历史操作者归因仍未证实,新增审计不能反向补造旧事件。
## 3. 需求合同
| ID | 范围 | 要求与可判定验收 |
|---|---|---|
| R1 | 安装入口 | `doctor` / `install` / 兼容 `--from` 生成同一部署计划;二进制无需 Go/Node;源码固定提交且子模块组合可核验 |
| R2 | 实例身份 | 启停、升级、开户、签发 Key 命中同一 store 与 data 根;缺失/不符拒绝;与恢复案 R2/manifest 一致 |
| R3 | 切换安全 | 构建/下载/摘要失败时旧服务继续;程序+插件+前端作为版本组合切换;固定版本不得被「最大版本」替代 |
| R4 | 存储档 | team 默认 PG+auth;`existing` / `managed-local` / `local(SQLite)` 显式选择;PG 失败不回落 SQLite |
| R5 | 开户 | 无初始密码;角色明确;创建与激活 Key 同事务;同名冲突不覆盖 |
| R6 | 账户恢复 | 精确命中既有账户;不改密码/不吊销会话/不改业务数据于签发时;保持 owner/角色/成员关系 |
| R7 | 一次性 Key | ≥256bit、只存摘要、activate\|recover、默认 TTL 30min、状态机、原子兑换、专用 POST body |
| R8 | 受限会话 | 仅身份查询、设密、退出;业务/下载/SSE/admin/插件拒绝;普通 `must_change` 同样服务端限制 |
| R9 | 设密事务 | 写 hash、清待激活/待改密、作废未用恢复凭据、失效相关会话同事务;成功后销毁受限会话并要求密码重新登录 |
| R10 | 集成 Key | 普通找回默认保留长期 API Key;失陷恢复显式 `--revoke-all-credentials` |
| R11 | 首次管理员 | 仅核验为新实例(无用户且无历史业务标记);事务防并发;不得因「未发现管理员」接管有数据环境 |
| R12 | 证据 | 验收绑定固定源码/制品摘要/环境;SELF/REPLAY/GATE 分源 |
| R13 | 可发现与兼容 | 完整/短帮助、help user、实例 user --help 和文档列出实际账户能力;不支持的制品在调用前拒绝;帮助/探测不建库、不迁移、不启动服务 |
| R14 | 账户稳定与审计 | 普通启停/更新不隐式重置;密码变更、恢复凭据/会话处理及成功审计原子提交;记录 actor、入口、实例、operation 与时间,不记录密码、摘要或 Key 明文 |
| R15 | 运维既有库 | 账户操作核验预期库和实例;读操作不建库或 migrate;schema 不兼容明确拒绝,迁移走独立入口;CLI 参数和日志不暴露凭据 |
## 4. 技术决策(KTD)
KTD1. **部署方式只决定程序来源,不决定数据位置。** binary ↔ source 可切换;切换保持 DB、数据根、账户与 instance_id。
KTD2. **账户规则只在 Go 后端。** 脚本调用实例对应版本的 CLI;不直接改用户表。
KTD3. **一次性登录凭据独立于长期 `api_keys`。** 专用表与兑换 API;普通 Bearer、SSE `?key=`、长期 Key 路径均拒绝。
KTD4. **受限会话为独立 scope。** 默认 10 分钟;allowlist 仅 me / 设密 / logout。
KTD5. **团队安装默认 PostgreSQL;存储选择显式。** 与恢复 KTD5、`config.Tier=team` 一致。
KTD6. **一次性 Key 默认 30 分钟**(可配置建议范围 5–120 分钟);审计记实际 TTL。
KTD7. **激活/恢复设密成功后必须重新密码登录**(销毁受限会话、清 cookie)。普通主动改密可保留「要求原密码」路径;激活路径不要求原密码。
KTD8. **普通账户恢复默认保留长期集成 Key;失陷显式撤销全部凭据。** 两种情况均保留业务数据。
KTD9. **候选校验完成前不停旧服务**;切换短窗;schema 迁移后能否自动回退旧程序另行判断,失败不自动用备份覆盖业务库。
KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端;Releases `install.sh` 变为薄封装或文档降级为遗留,禁止第三套生命周期。
KTD11. **能力声明与帮助同源,但后端仍是执行权威。** 新制品提供无副作用的结构化能力声明;旧制品仅按已验证版本兼容,未知形态拒绝。禁止尝试未知子命令或靠 strings 包含某词推断能力。保留 reset-password 的直接重置语义,不偷偷改成签发恢复 Key。
KTD12. **统一密码与开户事务。** 严格唯一 INSERT;散列计算在事务外,事务内重新核验权限/账户版本。主动改密、CLI/管理员重置、恢复设密共同执行密码+标志+旧登录 Key 作废+规定会话处理+审计。普通路径保留集成 Key,失陷模式按 KTD8 明确撤销;失败全部回滚。
首次管理员按实例串行,不能只依赖 owner UNIQUE:PG 锁定既有实例身份行,SQLite 使用立即事务,取得串行权后重新核验无用户、无历史业务;引导与能改变此前置条件的开户共用串行点。管理员、激活 Key 和审计共同提交;marker 缺失时由显式 init 处理,账户命令不得补建身份。
KTD13. **审计可归因,运维不隐式迁移。** 成功审计与变化同事务;失败记录注明未提交;HTTP actor 来自已认证会话,CLI 记录受信 OS 运维 UID/身份来源,不接受调用方填写的 actor 作为证明。实例身份和操作 ID 实填。既有库读命令只校验兼容性;迁移另行批准和执行。
KTD14. **凭据只经安全输入和单次交付。** 优先无回显输入/stdin/受保护文件,DSN 不传 argv。serve 已消费 AGENT_SYSTEM_DSN,账户 CLI 的等价安全输入需在 U7 显式接入并以能力声明核验,不能假定当前 user flags 已读取环境。非交互输出独占创建 0600 文件,日志/evidence 只记凭据 ID。提交后交付失败按 operation 查询,再撤销/重发;库存摘要不能重新打印旧明文,不把重试当首次创建。
## 5. 职责划分与接口示例
| 部分 | 负责 |
|---|---|
| `svc.sh` | doctor、env prepare、获取制品、构建、实例配置、生命周期、调用账户 CLI |
| 后端 CLI | 创建账户、签发/撤销一次性 Key、核验目标库、OpenExisting、操作审计 |
| 后端认证 | 原子消费 Key、受限会话、设密事务、中间件限制 |
| 登录页 | 输入一次性 Key、设密、过期/重发提示;遵循 `DESIGN.md` |
| 发布制品 | 版本、平台、摘要、组件版本、能力声明 |
拟新增 CLI(当前脚本尚不支持;兼容 `--from` 保留):
```bash
./svc.sh doctor --mode binary --tier team
./svc.sh install prod --mode binary --version <固定版本>
./svc.sh install prod --mode source --repo <仓库> --ref <固定提交>
./svc.sh prod deploy --mode binary --version <固定版本>
./svc.sh prod user create --owner alice --role user
./svc.sh prod user issue-login-key --owner alice --purpose recover
./svc.sh prod user list
./svc.sh prod user revoke-login-key --id <凭据编号>
```
Linux 服务账户与应用账户分开管理。
## 6. 规格合同(实施前必须写进 U1/U4,否则返工)
1. 独立凭据类型 + `POST` body 兑换 API。
2. 会话 scope / 中间件 allowlist;覆盖 `must_change` 普通首登。
3. 设密接口分型:受限会话不校验原密码;普通改密继续要求原密码;同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。
4. 密码未设置状态:`password_hash` 可空或 sentinel;`VerifyLogin` 拒绝未设密;创建 = 用户行 + 激活 Key 同事务。
5. CLI `OpenExisting`:目录/DB 不存在则失败;账户运维默认只校验兼容 schema,不 migrate;迁移独立执行。配套 U1 v0.2 候选同此合同,原 requireCompatible 自动 migrate 是历史实现。
6. `release@<ver>` 必须解析到该版本目录;缺摘要硬失败。
7. 部署:获取/构建/校验不停旧服务;组合切换;迁移后回退独立判断。
8. `install` 与 `--from` 同一计划;双轨收敛(KTD10)。
9. 首次管理员仅新实例;事务防并发。
10. 凭据交付:交互 stdout 一次 / 非交互 `chmod 600` 文件;日志与 evidence 只记凭据 ID;随机密码路径首期可并存但默认无密码 + Key。
11. 无 `flock` 时拒绝冲突生命周期与账户操作(收紧现状「直通」)。
详细设计(正文在 Dev 仓,随本任务分支提交):
- U1:`docs/svc-deploy/u1-instance-account-binding.md`
- U4:`docs/svc-deploy/u4-one-time-login-key.md`
## 7. 增量与完成门槛
| 增量 | 主要范围 | 完成条件 |
|---|---|---|
| **U1** 实例—账户绑定补齐 | 账户 CLI 读实例 manifest;OpenExisting;锁缺失拒绝;install 骨架对接既有 identity | 开户/签发命中同一 store;错误 data/DSN 拒绝;与 recovery U1 字段对齐 |
| **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署;固定版本与摘要可核验;修复 release 钉扎 |
| **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验;幂等;不接管共享服务;binary 不装 Go/Node |
| **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密;受限会话无法调业务 API;并发兑换单胜 |
| **U5** 脚本与登录页接线 | 账户帮助、无副作用能力探测、凭据安全交付、Login/设密页 | 新建与恢复走通;设密后清受限会话并返回密码登录;不支持的产品明确拒绝;DESIGN.md |
| **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档;故障注入;浏览器 + 真机;治理回归 |
| **U7** 账户事务与稳定性补齐 | 原子开户/引导、统一改密与撤销、审计、只读兼容打开 | 并发建号不覆盖;中断无半状态;旧恢复 Key 失效;身份缺失不改库;升级保持登录能力 |
| **U8** 实例运维核验与凭据诊断 | 账户状态/事件查询、绑定和制品诊断;补齐 U1 身份消费 | 可定位合法变更来源、识别错库/失效会话/错误 Key 类型;只展示非秘密元信息 |
**当前 U1/U4 基础已在源码中,近期优先 U7 和 U5,并与恢复方案 U8 隔离保护协调。** U7 先冻结后端账户事务/审计及能力声明合同;U5 随后完成浏览器与脚本;U8 诊断复用其记录。U2/U3 保留后续,不让通用安装器阻塞 dev 账户稳定。各仓从共同批准基线起独立任务;Backend → Frontend → Dev 组合,正式组合验证后才推进 gitlink。
### U7 近期实施与验证合同
覆盖 R5/R6/R9/R10/R11/R14/R15;依赖既有 U1/U4,实施负责人待指定。
范围(相对于 Backend):`internal/store/auth.go`、`internal/store/login_keys.go`、`internal/store/platform.go`、`internal/app/app.go`、`internal/server/accounts.go`、`cmd/agent-system/main.go`;迁移目录仅在 schema 需要时改动。
先刻画现有显式改密、重置及建号行为,再修复并发与中断窗口。账户校验、禁止隐式 migrate、严格 INSERT 和统一密码事务是单一后端实现,脚本不直接写表。
现有测试参考 `internal/store/login_keys_test.go`、`internal/server/login_key_test.go`、`auth_e2e_test.go`;新增 `internal/store/account_lifecycle_test.go` 与真实 PG 跨进程用例(路径相对于 Backend)。
T7-1:两个独立进程同名开户,只有一个账户/激活 Key 成功,败者不改变胜者角色、密码和成员。
T7-2:开户、Key 签发、改密、会话处理、审计提交各故障点,最终只见完整旧态/新态;输出失败但提交未知时按 operation 查询。
T7-3:普通改密、临时重置、恢复设密后旧未用 Key 都不可兑换;长期集成 Key 按 R10 保留/撤销。
T7-4:读命令命中旧 schema、缺库、错 marker 均拒绝且不 DDL/建库;两个独立进程以不同 owner 并发首次引导单胜,另覆盖引导与普通开户竞争;有历史业务而无用户时拒绝。
T7-5:普通重启、两次更新、SIGTERM/SIGKILL 后测试账户原密码仍验证成功,账户权限及成员不变;不以摘要是否变化替代密码可用性。
执行环境:独立 SQLite 副本、真实 PostgreSQL 独立库、独立端口;不在当前 weichen 账户上故障注入。所有 T7 用例当前 NOT_RUN。
### U5/U8 近期接线与验证合同
U5 覆盖 R7/R8/R9/R13/R15,依赖 U7 对外字段合同;范围 `scripts/svc.sh`、`docs/svc.md`、Frontend `src/api.ts`、`src/auth.ts`、`src/components/LoginPage.tsx`、`src/App.tsx`。复用现有登录/设密页,类型明确消费 sessionScope、passwordSet、reloginRequired;恢复 Key 不写持久浏览器存储或 URL。
同一登录页保留默认账号密码入口,增加「激活/恢复 Key」入口并说明只用于设密;长期 API 密钥入口标清集成用途。错类型提示指向正确入口,切换清输入,更新初始密码旧说明,不新增独立恢复页面。
刷新/兑换响应不确定时先查询会话,有效受限会话恢复设密;会话不存在且 Key 已消费/过期时提示联系账户管理员重发,返回「激活/恢复 Key」入口。无密码账户不得被引导用旧密码登录。
测试参考 `tests/test_svc_user_binding.py`、Frontend `test/auth.test.ts`、`e2e/changepw-form.playwright.ts`;新增 Dev `tests/test_svc_user_help.py`、Frontend `e2e/login-key.playwright.ts`(计划文件)。
T5-1:完整/短/专题/实例帮助覆盖六个账户命令,并均无 DB/目录/服务副作用。
T5-2:旧产品和 RDM 不支持账户 CLI 时在执行前拒绝;stdout 单次交付,stderr/进程参数/history 无秘密;两类 Key 双向填错有正确引导且切换清输入。
T5-3:激活/恢复完成兑换→设密→重新密码登录;刷新/响应丢失先核会话;Key 已消费而会话失效时经管理员重发的新 Key 可以续办;过期、重复兑换、CSRF 错误有准确提示。
T5-4:受限会话无法访问业务/下载/SSE/admin/插件;设密成功后不得因直接 onDone 误放行。
U8 覆盖 R2/R14/R15,依赖 U7 审计;在 `user info`/账户事件查询(拟新增)展示实例、设密时间、凭据类型及状态。错误配置、注销、Key 失效与密码错误分别诊断,普通登录错误不泄漏他人账户信息。CLI/HTTP 两入口产生可追溯同一 operation 记录;历史无审计事件保持未知。
首批 dev 原账户闭环(NOT_RUN):实现及隔离验证通过后,另行确认运行验收窗口/实例/版本,由 owner 在浏览器输入已知密码,检查原 user ID、角色、成员及原数据访问。若确实不能登录,明确恢复授权后才签发恢复 Key,保持账户和业务归属;不能为验收先重置能用的密码。随后在授权窗口验证普通重启及两次受控更新后原账户仍可登录。密码不交给 Agent、不进入证据;本轮不操作 live。
### 必须覆盖的验收场景(摘要)
干净机器二进制安装;源码固定提交与子模块;两种部署互切后数据不变;构建/摘要/配置失败旧服务可用;PG 身份不符拒绝且不回落 SQLite;无密码开户且不覆盖既有;同 Key 并发兑换仅一次成功;受限会话拒业务/SSE/admin;消费后建会话失败与设密中途失败无半完成态;恢复前后业务与权限对账;SQLite 与真实 PG;治理回归;源码测试不代替浏览器与真机。
额外钉住:`release@v` 多版本不得装成更高版本;账户 CLI 不得回落默认 `./data`。
## 8. 一次性 Key 流程
```mermaid
flowchart LR
A["创建账户或签发恢复 Key"] --> B["输入一次性 Key"]
B --> C["后端原子消费"]
C --> D["仅允许设置密码的短期会话"]
D --> E["设置并确认新密码"]
E --> F["作废恢复凭据及相关旧会话"]
F --> G["使用新密码正常登录"]
```
凭据规则:独立前缀;只存摘要;用途 `activate`|`recover`;状态未使用/已消费/已撤销/已过期;密码变更后旧恢复凭据不可再用。符合 [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 与 [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html);保留现有 CSRF 校验。
## 9. 风险与未授权范围
- 实施、故障注入、真机部署、浏览器验收:**未授权 / NOT_RUN**。
- 本轮交付终点:r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录;以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准,不推进 Dev gitlink、不推送/建 PR;启动/同步工具的任务元数据提交单独记录。
- 与 recovery U1 重叠处只做增量,不重做已合入的 manifest 层。
## 10. 规划进展与下一步
- r1 已批准;U1/U4 基础实现存在于当前固定源码,完整浏览器/故障/运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。
- 首选下一任务(待授权):恢复方案 U8 的 SQLite 服务隔离+本案 U7 账户一致性;先消除共享测试数据和不可归因密码变化,再落实 U5。U2/U3 保持后续。
- 前置:审核新增 R13–R15、U7/U8 及 U5 更新,明确实现和隔离测试范围/owner;实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区;正式组合、gitlink 推进与运行验收未执行。
@@ -0,0 +1,176 @@
---
title: 面向非专业用户的工作台整体界面重设计
revision: r0.2
status: approved-for-continuous-implementation
date: 2026-10-12
owner: weichen
scope: requirements-and-design
implementation: implemented
delivery: tracked-in-dev-task-record
project-record: persisted
---
# 工作台整体界面重设计 r0.2
用户在评审 r0.1 后明确授权“开始实施直到完成”。本稿 r0.2 保留已选设计,并通过本次独立任务连续实施、验证、Review 与合入。已有快慢通道执行方案的其他增量不由界面授权自动扩大。
## 1. 设计目标
让不懂命令、脚本、模型和代理的用户,通过表达目标、提供材料、查看结果、完成必要确认来推进工作。
默认界面回答三件事:现在在做什么,已经得到什么,下一步是否需要我处理。用户能够只用对话完成主要工作,也能在需要时展开工作摘要、阅读文件、核对依据。
用户明确要求:不要过于复杂;以辅助工作为中心;渐进、多层级展示;减少命令和脚本细节;大气、现代、简约、美观、易用。
本稿的场景假设:主要工作包括材料整理、分析比较、问题审查和文档生成,兼顾日常问答。业务领域的具体审批和发布入口按当前服务端能力提供。
## 2. 推荐形态与备选
推荐**渐进展开的三栏工作台**。左侧找项目与历史,中间通过对话推进工作,右侧按需处理工作或文件。普通问答默认收起右栏,复杂工作时提供概览;用户手动收起后不因普通更新反复打开。
| 形态 | 适用和取舍 | 本稿选择 |
|---|---|---|
| 渐进三栏 | 对话入口清晰,复杂任务可展开,文件有稳定位置 | 推荐 |
| 纯对话 | 学习成本低;长文件、并行工作和多次确认容易淹没在历史消息中 | 作为轻量状态 |
| 总览仪表盘 | 跨任务监控方便;默认要求用户理解更多指标和导航 | 仅在确有项目总览需求时另审 |
不单独建设快通道页、慢通道页或后台管理页。新增功能先判断能否放进现有对话、工作和文件入口。
## 3. 界面布局
**左栏:上下文。** 项目身份集中出现一次;新建对话、最近对话、搜索;文件和已启用的领域工作区放底部;账户与个人设置沉底。管理员操作只由管理员入口提供。
**中栏:推进工作。** 当前对话标题;用户的目标和材料;助手的结论、简短说明、必要动作;输入区上方一条工作状态。附件入口始终易找。权限设置保留清晰入口,展开说明其实际含义;初次使用采用现有默认值,不暗中扩大授权。
**右栏:工作 / 文件。** 工作按需要你处理、当前关注的工作、其他进行中或排队、新成果排列。完成历史收纳后仍可找回。文件负责列表、预览、编辑和下载;全屏阅读是同一个预览的放大。来源点击也进入同一预览对象,定位能力不足时说明定位范围。
左栏约 200–240,工作右栏约 320–420,中央弹性。正式落地继续消费已有拖拽宽度和文件阅读档规则。空间不足时先隐藏辅助栏;手机显示一个主视图,工作和文件按需打开,并有明确返回对话入口。
## 4. 渐进展示层级
| 层级 | 显示内容 | 打开方式 |
|---|---|---|
| L0 概览 | 后台工作数量、必要确认、新成果 | 一条状态行或小徽标 |
| L1 摘要 | 业务目标、真实状态、当前工作、最多 3 条重要发现、缺项、下一步 | 当前任务卡或对话锚点 |
| L2 依据与范围 | 阶段结果、来源、覆盖范围、未决问题和结论更正 | 原位置展开 |
| L3 执行记录 | 按工作阶段分组的动作、结果和有权限查看的诊断信息 | 明确点击执行记录 |
默认 L0/L1,不展开所有任务。必要确认、重要限制和失败影响不能藏在 L2/L3。L3 不是模型内部思考的展示入口,也不改变日志和来源的访问权限。
示例任务卡:
> 整理三份项目材料 · 进行中
> 正在核对:会议结论与需求说明
> 当前发现:上线时间出现两种说法;3 项需求缺少验收条件
> 待核查:评审意见中的补充要求
> 查看依据与范围
没有阶段成果时诚实显示“尚无阶段结论,正在读取材料”。以上业务发现是示例数据,当前 U1 骨架并不证明已经具备真实阶段发现发布能力。
## 5. 快慢通道的连续体验
用户界面主要使用“助手正在处理”“后台继续整理”等业务语言。快通道是当前对话回合,慢通道是后台工作,不是由用户选择的快慢速度档位。
| 时刻 | 用户看到的内容 | 表述边界 |
|---|---|---|
| 发消息或材料 | 接收结果、可先回答的内容、接下来处理的范围 | 已选文件不等于上传成功;解析不等于分析完成 |
| 任务登记或排队 | 同一工作对象显示已登记、排队中 | 登记成功才能说已登记;未开跑不能写进行中 |
| 工作进行中 | 当前工作、真实阶段结果、缺项 | 没有可信进度就不显示百分比或预计完成时间 |
| 用户继续输入 | 后台继续工作时可继续对话;前台忙时说明消息排队 | 发送不等于即时执行,不承诺已改变正在跑的任务 |
| 有新成果 | 更新原卡;重要结果提供一条对话通知 | 不逐条回投工具动作,不把所有任务复制成另一条聊天流 |
| 等待用户 | 操作、范围、影响和明确选择 | 等待、执行、生成、用户认可和正式发布分开 |
| 完成或失败 | 结论、最多 3 个要点、范围或缺项、文件和下一步 | 保存失败不得声称已交付;部分完成不能冒充完整结果 |
后台更新不切换用户正在读的文件,不抢焦点,不把历史阅读强行滚到底部。状态恢复期间保留最后已知内容并注明“正在重新连接,最新进展待确认”。
## 6. 按工作选择展示形式
统一骨架保持稳定,内容形态随任务改变。默认由工作目的决定,用户无需先学习或配置一种展示模式。
| 工作 | 默认成果形式 | 进一步展开 |
|---|---|---|
| 简单问答 | 一段结论,必要说明 | 依据与例子 |
| 材料整理 | 主要结论、问题和缺项 | 材料覆盖清单、来源 |
| 方案比较 | 一条建议、关键差异表 | 判断依据、取舍和适用条件 |
| 问题审查 | 按影响排列的问题清单 | 原文、影响、处理建议 |
| 文档生成 | 草稿文件、完成范围、需要评审的事项 | 文件预览与后续修订 |
| 多步骤流程 | 当前阶段、已完成阶段、必要动作 | 阶段结果与历史 |
| 用户确认 | 简明操作说明、影响、选择 | 参数与诊断详情 |
图表仅在数量、趋势或关系能帮助判断时使用;可理解的短表不升级成图表。生成式任务页面作为可选增强,关闭插件后仍能通过任务卡、文字和文件读到主要结果。领域审批不能成为所有基座任务的固定步骤。
## 7. 等待确认与异常
确认卡先写操作及影响,例如“依据三份材料新增 1 份项目草稿,保留原件,不对外发送”。涉及覆盖、发送、发布或权限变化时,关键对象和影响必须在默认层显示。避免只有“是否执行”而没有范围。
对话和右栏操作同一确认对象。提交中阻止重复提交;已处理同步更新;超时显示“正在核实处理结果”,查清后再允许后续动作。示例稿只演示本地状态同步,不证明服务端幂等和恢复。
异常表述使用“发生了什么 → 对结果的影响 → 用户可以做什么”。例:“评审意见未能读取;已整理另外两份材料,完整结论尚未生成;可补充清晰版本或先讨论已有结果”。错误代码、脚本与输出置于授权可读的详情。动作只按服务端当前能力显示;未核验的暂停、独立取消、续跑、自动重试不进入默认设计。
## 8. 视觉规则
沿用 DESIGN.md 和 @ui/tokens.css:灰白表面阶梯、单色反色主按钮、发丝边框、克制语义色;清晰的标题与正文层级;常用信息保持可读,不以缩小字号装下所有内容。
大气来自稳定分栏、整齐对齐、合理阅读行长和区块间距;简约来自减少同时出现的内容。没有营销式大标题、装饰渐变、速度表盘、满屏彩色卡片或默认工具日志。
字型走 --fs-ui-*,界面字号可调。状态同时有文字和形状。折叠消费 @ui Collapsible,动效只用 mk-* 并响应减少动效。交互稿复制固定 UI 令牌,实际使用当前 Collapsible 源码与 MotionKit,不新建颜色和动效体系。
## 9. 当前依据与依赖
本轮只读源码核对,来源 SELF;没有对生产或当前 dev 服务作功能验收。
| 对象 | 固定提交 | 核对点 |
|---|---|---|
| Dev | 4d362537d0e8755a03b1757b5bad92779a064b33 | DESIGN.md、policy/delivery.md、既有规划 |
| Frontend | 1edd872c554f666ba43353da7e6f0605ecec311b | Workbench.tsx、Conversation.tsx、Workspaces.tsx |
| Backend | acabb85e2ae970f834defae916c7539d0a47993d | spawnBackgroundOpts、CancelRun、createBackgroundCard、finishBackgroundCard |
| UI | 83e80f5648649c3cc070f4dbc6bf118996828ae8 | tokens.css、Collapsible.tsx、motion.css |
| Documents | 3cc6438030803b8e2355d2867766e9654203f265 | 快慢通道展示 r1.1 及 U1 实施计划 |
当前读到的源码已有三栏“工作 / 文件”、前台忙时输入排队、后台并行限制、排队工作、精炼卡片骨架以及失败 CardFailed 映射。这里只说明源码形状,不推断已部署与运行表现。
与既有方案衔接:`modules/documents/docs/proposals/2026-10-12-fast-slow-channel-display.md` 是快慢通道摘要与异步投影的已有主记录;本稿补充整体交互与各种成果形式,不另起一套状态或快照契约。U2/U3/U4 的真实阶段发现、持久恢复、确认闭环和窄屏完善继续以原记录及后续批准为准。
## 10. 实施需求
以下为本次界面实施与验收范围;实现消费真实已有能力,不伪造尚未发布的阶段发现。
| ID | 需求 | 优先级 | 可判定的验收方向 |
|---|---|---|---|
| UI01 | 对话能完成主要工作 | P0 | 关右栏仍能读摘要、核对依据、处理确认、打开成果 |
| UI02 | 普通问答保持轻量 | P0 | 无后台工作时不生成空任务卡和空进度条 |
| UI03 | 默认内容可支持下一步 | P0 | 用户能说明当前工作、结果范围、必要下一动作 |
| UI04 | 快慢通道连续展现 | P0 | 前后台并行、排队和完成状态归属正确且不重复刷屏 |
| UI05 | 四层渐进阅读 | P0 | 默认无命令日志,关键限制和确认不被折叠藏起 |
| UI06 | 成果按目的呈现 | P1 | 整理、比较、审查和生成各能支持对应工作判断 |
| UI07 | 状态与动作忠实 | P0 | 不伪造进度,不暴露未支持控制,不把失败显示成功 |
| UI08 | 同一文件同一预览 | P0 | 对话、来源、文件列表均进入同一预览位置 |
| UI09 | 确认结果一致 | P0 | 双入口、重复点击、超时未知和已处理均有一致表现 |
| UI10 | 阅读稳定 | P0 | 普通后台更新不抢焦点、换文件或改阅读位置 |
| UI11 | 窄屏和大字可用 | P0 | 320/390/736/1024/1440 及 18px 字号必要动作可达 |
| UI12 | 遵守设计系统 | P0 | 令牌、Collapsible、MotionKit、对比度守护符合规范 |
| UI13 | 能力与权限匹配 | P0 | 未启用领域入口不显示;摘要与来源不绕过访问控制 |
最终产品验收场景:三个附件无文字发送;前后台并行及排队;确认双入口;完整/部分/失败结果;查看来源与文件;刷新和断线;新对话;窄屏、大字、键盘及减少动效。r0.1 设计评审时,真实模型、真实后端和真实浏览器任务验收均为 NOT_RUN;实施期结果见第 13 节,示例交互稿不能代替验收。
## 11. 落地次序建议
1. **整体界面与文案。** 在既有三栏和 U1 上整理默认内容、必要操作和阅读路径。优先确定 UI01–UI03/UI05/UI08/UI12;不在此增量改变后台执行契约。
2. **动态工作摘要。** 接续既有快慢通道 U2/U3,在真实快照与检查点之上显示业务发现、范围和恢复状态;避免另外安排重复任务。
3. **成果形式与适配。** 衔接 U4,完成比较、审查、可选任务页面、窄屏和具体领域入口。先用结构化文字/表格,再增强生成式展示。
r0.1 布局与展示已获连续实施授权,当前按 r1 计划交付界面。完成本增量后的首选衔接仍是既有快慢通道 U2/U3 的真实阶段发现与恢复验收;需先核对其在途任务和批准范围,不能由本界面任务重复启动或改变路由。
## 12. 授权与实施记录
来源:2026-10-12 用户在本聊天评审 r0.1 后指示“开始实施直到完成”。模式 authorized-continuous;阶段 1–10 在本稿界面范围内连续推进,平台门禁和高后果双钥匙保留。启动检查从已登记干净 Dev 检出捕获,后由 make task-start 创建 feature/work-companion-ui,并导入原始 SELF 收据。保护主检出的 Frontend 更新与其他任务现场。
实施计划见 [r1](2026-10-12-work-companion-ui-plan.md);进展和原始证据仅维护于 Dev .task/feature-work-companion-ui.md。PR、CI、Review、合入与部署分别记载,不因本授权预先标为通过。
## 13. 实施进展与能力边界
2026-10-12:渐进任务卡、轻量对话/输入、响应三栏和单一异步状态投影已形成可审阅候选。SELF 验证包括 Frontend 210 与 UI 155 单元测试、类型/设计守护/knip、Dev make test 与 make build;现有 Playwright 11 个展示场景、6 个移动导航场景及隔离 HTTP/MockRunner 2 个真实接口链路场景通过。原始命令、精确对象和完整输出以 Dev 任务卡为准,测试成功不推断已经合入或部署。
原始独立代码 Review 已完成,必要问题均已有整改候选;最终精确版本复审、组合 CI 与合入进展只维护在 Dev 任务主记录,方案正文不复制第二份交付状态。UI 仓原 CI 在下载 GitHub action 时失败,交付补充改用既有平台固定 SHA 检出和 Node22 镜像,保留原测试;安全和规范 Review 及实际平台结果均须记录。
动态摘要只消费系统发布的真实内容:缺少阶段发现时显示诚实占位,不生成示例百分比、ETA 或虚构成果。真实模型阶段发现质量 NOT_RUN,后台自动路由和模型提示词未在本增量修改。旧运行服务未更新;最终组合、Review、GATE 和本任务安全收口以 Dev 主记录为准。
@@ -0,0 +1,154 @@
# Work companion interface implementation plan r1
> **For agentic workers:** Implement in independent units with ce-work native workers; the orchestrator owns integration, evidence, commits, Review and Gitea delivery. Use test-first coverage for behavior changes. User authorization: “开始实施直到完成”; continuous execution is limited to the approved interface design.
**Goal:** Deliver the approved simple, modern, progressive workbench through real project, conversation, activity-card, confirmation and file APIs.
**Architecture:** Keep the three existing pane responsibilities. Project existing ActivityCard bodies into readable summaries in the UI library; Frontend integrates them into conversation and work panes. Preserve server authority and harden event, query and action races in the one Frontend store. No new task executor, model routing, database schema or UI vocabulary is required.
**Tech Stack:** React 19, TypeScript, existing @ui Collapsible/MotionKit/tokens, Vitest, Playwright, Go backend with existing API and SSE.
**Spec:** [Approved interface design](2026-10-12-work-companion-ui-design.md), UI01–UI13; [existing fast/slow design](2026-10-12-fast-slow-channel-display.md), U1 skeleton and applicable presentation rules. Dynamic model-generated findings remain dependent on the existing U2/U3 work; this interface renders real available content and an honest placeholder otherwise.
## Global constraints
- Settled user decision: three pane workbench, conversation first, “工作 / 文件” in the same right pane, one preview object.
- Settled user decision: concise default content and progressive depth; necessary confirmation and outcome limits stay visible.
- Colors/radii/type consume @ui/tokens.css, type uses --fs-ui-*, motion only mk-*, folds use Collapsible.
- No percentage, ETA, pause, independent cancel, resume or retry buttons unless supplied by a verified server action.
- State is derived from real cards, runs, files and responses; no prototype example data enters production.
- Model internal thinking and command parameters/output do not occupy the normal reading layer.
- Main checkout and other task worktrees are protected. All owned changes live in feature/work-companion-ui.
- Evidence uses the Dev make evidence tool. Local checks are SELF; current PR HEAD CI is GATE.
- Component branches are based on their authoritative origin/main. Dev is based on R0 4d362537d0e8755a03b1757b5bad92779a064b33.
- No deployment/restart of existing services, data migration, credentials or branch-protection changes.
## Review focus
1. Older SSE frames or delayed queries must not replace newer cards or inject data into a different conversation/project.
2. Replay of a currently running conversation must still reconstruct its live output while duplicates are dropped.
3. A confirmation submitted through either view must block duplicate submission and represent unknown results honestly.
4. Closing auxiliary panes and opening files must leave necessary work and confirmation paths accessible at 320px and 18px UI type.
5. New background results must not take over an existing file, focus or reading position; result summaries must retain failure and coverage limits.
## U1 — Progressive activity cards and work groups
**Own files:** UI src/ActivityCardView.tsx, src/InlineConfirmCard.tsx, src/InboxList.tsx, src/index.ts, src/ui.css, new src/activitySummary.ts, src/ProgressCardBody.tsx and focused UI tests. Do not change generated contracts or tokens.
**Consumes:** Existing ActivityCard/UINode and DocBridge; U1 body keys 状态/正在做/当前发现/剩余/下一步. Unknown words remain supported by the generic renderer.
**Produces:** Existing ActivityCardView remains source-compatible; export activitySummary/cardStatusLabel/groupActivityCards as pure projections. CardViewCallbacks and InlineConfirmCallbacks may add `actionState?: (card: ActivityCard) => 'submitting' | 'unknown' | undefined`; existing callbacks remain optional. Core vocabulary is unchanged.
- [ ] Add tests for queued and running labels, modern failed and legacy done+danger, no-findings placeholder, internal material keys hidden by default, real document nodes still reachable, and confirmation buttons disabled for submitting/unknown.
- [ ] Run the focused Vitest tests before production edits; record expected red assertions through evidence.
- [ ] Build the projection with literal canonical body keys and card states; never interpret arbitrary output as a new execution fact.
- [ ] Render L1 summary first, remaining body and source/range information in Collapsible, diagnostic metadata behind a nested explicit record entry. Known failure/remaining/next-step content must remain visible.
- [ ] Keep unknown/legacy bodies intact in the generic detail renderer. Tables, structured lists and document references retain their current renderer.
- [ ] Group unpinned work as needs-action, active, results, history, preserving order inside each group. Pinned items remain stable.
- [ ] Simplify chrome; use text plus status shape and existing neutral surfaces.
- [ ] Verify full UI suite, tsc and design/contrast guards; hand off files and red/green evidence without committing.
Example behavioral expectation:
```ts
const queued = { ...card, status: 'active', body: [{ type: 'kv', kv: [['状态', '排队中'], ['材料键', 'mk_private']] }] }
expect(cardStatusLabel(queued)).toBe('排队中')
expect(groupActivityCards([completed, pending, queued]).map(g => g.key)).toEqual(['needs-action', 'active', 'results'])
```
## U2 — Conversation, input and inline work reading
**Own files:** Frontend src/components/Conversation.tsx, src/components/ProcessTimeline.tsx, src/messageparts.ts if required by process policy, new src/components/ConversationWork.tsx, new src/companion-conversation.css, focused conversation/messagepart tests. Do not edit styles.css, App, Workbench or store.
**Consumes:** Existing store fields and actions; existing UI ActivityCardView/Collapsible/DocBridge, including the additive actionState callback. The orchestrator supplies state.cardActionStates.
**Produces:** ConversationWork renders current cards from the same store in an inline Collapsible; default ordinary Q&A has no empty progress. Component CSS imports live in the owned component file.
- [ ] Add failing behavior tests for normal Q&A without progress, task summary reachable while right pane is closed, progress record folded by default, failure/limits visible, and process final answer outside its fold.
- [ ] Replace command-oriented empty states with goal/material prompts and three optional natural-language examples that fill input rather than trigger hidden work.
- [ ] Simplify header; keep execution profile, cross-reading and session settings inside a clearly labeled settings fold, preserving existing behavior and consent.
- [ ] Keep add-materials and send visible; move permission selector into operation settings without changing its effective value. Explain queue state and upload failures in user language.
- [ ] Show a light continuity line from real runs/cards with confirmed counts; inline work uses the same cards/actions as the work pane.
- [ ] Fold tool parameters and output even during running by default; keep a compact real phase label and preserve manual expansion. Do not display model internal thinking as ordinary content.
- [ ] Protect scroll reading and reset compose/expanded context correctly on conversation switches; do not remove artifact or rewind capabilities.
- [ ] Verify focused tests and the integrated Frontend suite; hand off files and evidence without committing.
Example behavioral expectation:
```ts
expect(showProcessInline(live, true)).toBe(false)
expect(showProcessInline(live, false)).toBe(true)
// Render real ConversationWork with zero cards: no progress object is produced.
// Render with a real active progress card: summary is present independent of rightCollapsed.
```
## U3 — Responsive shell and context navigation
**Own files:** Frontend src/App.tsx, src/components/TopBar.tsx, src/components/TaskSidebar.tsx, new src/companion-shell.css, new src/workbenchLayout.ts and focused shell/layout tests. Do not edit store, Conversation, Workbench, shared styles.css or UI.
**Consumes:** Existing leftCollapsed/rightCollapsed/rightTab/previewExpanded and store pane/file operations. May add only local ephemeral responsive state, not another asynchronous task owner.
**Produces:** Desktop three pane layout; narrow screen one active pane with clear contextual return actions, using the same Workbench/PreviewPane objects. Export a pure layout selector if a decision is needed for tests.
- [ ] Write failing behavioral tests for single-pane navigation, restoring conversation, expanded file reading, and no hidden-only essential operation.
- [ ] Match the approved calm prototype through spacing and type hierarchy, preserving canonical palette and default existing theme preferences.
- [ ] Keep project identity on the left, conversation identity central, work/files on the right. Rename primary creation to 新建对话 where it actually creates a conversation.
- [ ] Reduce duplicate permanent chrome; retain project creation/search/account/admin/available workspace paths.
- [ ] Adapt to 320/390/736/1024/1440; hide/return controls remain keyboard- and touch-accessible. Do not let stored pane widths force horizontal overflow.
- [ ] Keep file expansion as one preview enlargement, not another overlay or fourth pane.
- [ ] Verify layout tests and report desktop/mobile screenshots after integration; hand off owned files without committing.
## U4 — One state owner, safe updates and confirmation feedback
**Own files:** Frontend src/store.ts, new src/eventProjection.ts if a pure helper is useful, src/components/Workbench.tsx, src/components/PreviewPane.tsx only when integration requires it, focused store tests. Orchestrator implements this unit.
**Consumes:** Existing SSE event identity/seq/runId, conversation detail resumeSeq/lastSeq, cards API, project events, cardAction and resolveHITL APIs.
**Produces:** Store `cardActionStates: Record<string, 'submitting' | 'unknown'>`; both work and inline confirmation callbacks read this same map. Current session/project cursors and query generation checks remain in one store.
- [ ] Add red tests for duplicated and stale cards; delayed conversation/project list queries after switching contexts; foreground replay versus background agent notes; duplicate action submission; unknown response followed by a server query; new Surface while reading a file.
- [ ] Guard event application by current context and per-stream applied sequence. Live replay uses its own replay cursor and never re-applies older card/plan/status projection effects.
- [ ] Guard asynchronous queries by their requested context and generation/sequence so slow snapshots do not wipe newer events or another context's state.
- [ ] Suppress background progress in foreground token output; update actual runs/cards instead of creating an unrelated LiveState.
- [ ] Lock confirmation/action submission by card or HITL identity before awaiting. Clear on observed server outcome. Unknown results remain disabled until read-only reconciliation determines the current state; do not blindly resend an effect.
- [ ] Show submitting and unknown feedback at both entrances. Preserve all server-supplied actions and their original scope.
- [ ] Leave current file/Surface selection and explicit pane preference intact on background updates; show a small new-result cue rather than auto-opening.
- [ ] Default new users to a light, compact conversation layout with right pane closed; keep saved theme/layout choices and explicit file opening.
- [ ] Verify focused store tests, integrated Frontend tests, and browser cross-view flows.
Example behavioral expectations:
```ts
store.applyEvent({ ...newerStatus, seq: 12 })
store.applyEvent({ ...olderStatus, seq: 11 })
expect(store.getState().cards[0].status).toBe('done')
// Hold the first action response; call through the second view and assert one API request.
// Resolve or query the real returned card and assert both views leave submitting together.
```
## U5 — Integration, browser acceptance and delivery
**Own files:** Dev DESIGN.md, PROJECT.md, task card and exact gitlinks; Documents design/plan/index and delivery record; Frontend e2e/work-companion.playwright.ts and isolated browser fixtures if required; external screenshots and receipts.
- [x] Record authorization and implementation units; retain original startup evidence unchanged.
- [x] Integrate all workers, inspect owned paths and contracts, run authoritative focused tests, and commit logical component changes with Why/Evidence/Impact/Refs bodies.
- [x] Update DESIGN §9.6 and information architecture to the approved progressive behavior; no palette changes are planned, so do not change canonical token values merely to create a paired diff.
- [ ] Run make task-sync through evidence at acceptance, review and merge checkpoints; resolve any parent/component conflicts without altering unrelated owner work.
- [x] Pin exact committed component revisions and run Dev make test plus make build through evidence.
- [x] Browser checks: normal conversation; three selected attachments; background task plus foreground input/queue; pending confirmation through either entrance; done/failed/partial results; real file preview; reading preserved during update; duplicate/stale updates; refresh/switch; all five widths and 18px type.
- [x] UI fixture-driven browser cases validate presentation only. Use an isolated real backend/browser smoke for API wiring, file/confirmation/card persistence where feasible. No mock model findings are reported as live-model acceptance.
- [ ] Run required simplification and independent code review; fix findings, re-run affected checks, and record reviewer/object identity.
- [ ] Push component branches, create and attach Gitea PRs, verify their current HEAD required CI and merge in dependency order. Update Dev pins to merged revisions, verify combination CI at current Dev HEAD, Review and merge Dev PR.
- [ ] Fold/close only this task card under continuous authorization. Preserve or safely reclaim only owned workspace artifacts. Do not modify active main checkout state for other tasks.
## Definition of done
UI01–UI13 are mapped to observed source/tests/browser outcomes or an explicit inherited capability limit; no prototype fixture enters product state. All changed components compile and relevant tests pass. Current-head mandatory CI is verified before merge. Review findings are closed. The actual merged Dev combination and saved evidence are recorded. Existing running services remain unchanged; deployment is a separately identified operation.
Continuous authorization covers implementation, verification, reversible isolation, documentation, commit/push/PR, agent Review/merge and task-specific safe closure. Stops apply to genuine scope changes, unowned content collisions, missing current-head platform gates and high-consequence dual-key operations. These conditions do not require re-approval of routine already-authorized work.
## Delivery status
2026-10-12: U1–U4 implementation candidates are integrated; U5 local combination and browser checks passed as SELF evidence. Original independent review is complete; the required fixes are implemented and locally verified. Final fixed-version review, current-head platform CI/merge and safe closure are tracked only in the Dev task main record; this plan does not maintain a second delivery-status copy. Code review may produce small corrective iterations; each has its own fixed object and relevant replay. The UI CI bootstrap repair is required to run the retained checks, not a waiver of them. Actual merged versions and final verification remain recorded in the Dev task card; no existing service is deployed by this task.
2026-10-12 corrective candidate: UI0da2e3a / Frontend43d1933. SELF: UI155 and Frontend210 tests with type/knip checks, 11 presentation plus6 mobile-navigation browser cases,2 isolated realHTTP/MockRunner cases. The live attachment case now proves exact upload→send→persist associations across reload. The review repairs cover source links, per-option context, real browser scroll/focus, terminal reconciliation, action feedback ownership, explicit preview intent, latest outcomes and visible public explanations. These are interface and state-projection corrections; no live-model routing, prompt or existing-service deployment change. Final delivery facts are recorded in the linked Dev PR/task archive.
@@ -0,0 +1,243 @@
---
title: RDM 设置归属、成员、文档职责与权限矩阵完善增量方案
date: 2026-10-13
type: feature
execution: code
artifact_contract: rdm-increment-plan/v1
product_contract_source: legacy-requirements
---
# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1
负责人:weichen;编制:ZCode;核对日期:2026-10-13(北京时间)。
上游方案:[2026-10-12 RDM 功能、实现与计划矩阵及整改方案](2026-10-12-rdm-function-implementation-plan.md)(下称"总案"),本增量承接其本稿 U3、U4、U6,涉及职责一致性的部分衔接 U5。
评审状态:2026-10-13 用户评审通过(同意方案及技术评审意见),并授权按本方案实施(P1–P8 两批推进;正式验收与清理回收节点保留人工确认)。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。
## Goal Capsule
以现有 RDM 实施总案的一个完整增量,先厘清设置归属和服务端权限,再补齐搜索、选择、职责分配与权限矩阵交互,保证界面显示、保存结果和实际执行一致。终点:创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存,且服务端边界(受管设置、成员校验、原子职责变更、权限范围)全部经真实请求验证。
非目标:不扩展飞书集成、组织架构、多角色叠加或全量文档生成工程。
## 一、当前实现与需要补齐的内容
| 方面 | 当前源码情况 | 本次需要完成 |
|---|---|---|
| 设置归属 | 项目设置展示完整 schema;用户、项目设置都能覆盖模型等配置 | 设置作用域、管理员系统设置入口、写入与最终生效值双重约束 |
| 成员管理 | 手填账号;已有分页账号目录,但只有账号和有效态 | 账号/姓名搜索、提示选择、下拉浏览、专业角色过滤、明确的项目身份修改 |
| 文档职责 | 手填文档 ID 和人员账号;主要读取提交快照 | 文档搜索/列表/树选择、当前职责回填、项目成员选择、提交校验 |
| 权限查看 | 已有单成员权限解释表 | 单成员详情与多人矩阵、中文标签、项目动作范围、上限内配置 |
| 一致性 | 存在职责目标未校验成员、职责更新与审签失效分步执行等缺口 | 服务端统一校验、原子变更、版本冲突、撤权及历史保全 |
对应实现锚点:Frontend `src/components/ProjectSettingsModal.tsx`、`src/components/adminRdmSections.tsx`;Backend `internal/settings/settings.go`(覆盖链 `defaults → system → user → project`);RDM `plugins/rdm/plugin.go`、`internal/perms/perms.go`、`internal/rdmapp/docsubmission.go`。
## 二、设置归属与界面结构
沿用现有设置入口和 `SettingsShell`,项目设置收敛为四个页面:
| 页面 | 内容 |
|---|---|
| 项目设置 | 真正属于本项目的共享配置与协作规则 |
| 项目成员 | 成员搜索、添加、项目身份调整、移除 |
| 文档职责 | 文档查找、职责查看与分配、相关审签状态 |
| 项目权限 | 单成员权限详情、成员权限矩阵、允许范围内的配置 |
系统管理中补齐“模型与服务配置”,承接主模型、轻量模型、Embedding、Rerank、模型密钥与 Tavily 等系统配置;Agent 工具限制、系统插件、全局专业角色和权限上限也归系统管理。个人设置只保留个人偏好。
实施时需要处理三个层面:
- **展示范围**:设置描述携带允许作用域、管理资格、生效时机;项目页面只消费项目项。
- **写入范围**:用户/项目 API 拒绝写入系统受管项,包括嵌套字段和点路径形式,插件设置也遵守同一规则。
- **实际生效**:旧用户/项目覆盖值不能继续影响系统模型;个人画像的模型路由及个人模型密钥也必须纳入受管校验,堵住其他覆盖入口。
另外,当前“项目设置”实际上按“用户+项目”保存(Backend `Effective(owner, projectID)`,project scope 物理存储在各 owner 名下)。需要区分:
- **共享项目业务配置**:以项目为权威,同一项目不同成员读取一致。
- **个人在该项目中的偏好**:继续属于个人。
跨会话读取必须保留本人会话的隐私边界,不能因项目配置共享而开放其他成员的私聊、上传原件或个人草稿。
## 三、成员管理交互
采用**一个可搜索的人员选择器**,同时支持输入、提示选择和下拉浏览,不为每种途径增加独立页面。
添加流程:打开人员选择器 → 输入账号或姓名,或浏览候选 → 可按专业角色过滤 → 选择人员 → 设置项目身份 → 添加。
具体行为:
- 输入账号支持精确匹配;姓名、账号支持模糊检索。
- 未输入时显示分页候选;选择器内提供“全部专业角色/系统工程师/软件工程师……”筛选。
- 候选显示“姓名、账号、专业角色”;同名人员通过账号区分,姓名为空时使用账号。
- 已加入人员标记“已加入”,避免重复添加造成隐式身份变更。
- 最终提交稳定账号标识,不能直接提交搜索文字。
- 成员表分别展示“专业角色”和“项目身份”,不混用两者。
项目身份使用“项目负责人/项目成员”等中文名称。成员行提供明确的“调整项目身份”和“移除”操作;继续保护最后一位负责人。
服务端复用已有 `rdm.account.list`,补齐受限的姓名搜索、精确账号校验和专业角色摘要。**不能直接把管理员用户列表或包含全部账号绑定的角色管理接口开放给项目负责人。**
角色筛选只帮助找到人员;项目负责人不能借此修改账号的全局专业角色。账号有效状态必须来自基座实际能力,不能把当前简单的 `valid=true` 当作完整的账号停用机制。
## 四、文档查找与职责分配
文档职责页面采用“**文档清单+选中文档的职责详情**”:
- 上方提供统一搜索框,支持文档 ID 精确检索、标题精确/模糊匹配。
- 支持文档列表与树形浏览;阶段、文档类型、未分配/已分配、审签状态可用于筛选。
- 树形视图忠实呈现当前文档结构,只有文档节点可以作为职责分配对象,章节不能误作 `docId`。
- 搜索、列表和树选择共用同一目录与选中状态。
- 结果显示名称、阶段/类型、职责概况和状态;ID 保留为辅助定位信息。
已有文档树查询属于审计面,不能降低它的授权规则来供选择器使用。应补齐专用的职责管理元数据读面:
- 有职责分配权的管理者可以读取必要的管理元数据。
- 普通成员只获得其有权查看的文档范围。
- 标题、数量、筛选结果和树节点均在服务端过滤,避免通过搜索泄露不可见资源。
选中文档后,立即读取并回填**当前职责**,包括尚未提交过审签的文档。当前职责与“某轮提交冻结的职责名单”分别展示,不能混为一份数据。
人员选择规则:
| 职责 | 选择方式 | 约束 |
|---|---|---|
| 编制人 | 搜索、下拉、专业角色过滤 | 单选 |
| 审核人 | 搜索、下拉、专业角色过滤 | 多选,至少一人 |
| 批准人 | 搜索、下拉、专业角色过滤 | 单选 |
**所有候选只能来自当前项目成员。**保存时服务端再次校验账号、项目成员关系、对象归属、操作资格和职责版本;文档级(`rdm.review.assign.doc`)、章节级(`rdm.review.assign`)及旧命令入口均遵守同一规则。
保留编制、审核、批准互异的规则。专业角色筛选不自动授予文档职责;管理权也不自动获得代编、代审或代批资格。
职责变更需要补齐以下行为:
- 在途审签受影响时,先显示受影响轮次与“需要重新提交”的提示。
- 明确确认后,职责更新、在途审签失效和事件记录原子完成。
- 保留旧冻结名单、审核记录和已批准历史,不把旧票带入新轮次。
- 无变化保存保持幂等;并发修改返回明确冲突。
- 移除仍承担当前职责的成员前,展示受影响文档并引导处理,防止留下无人可执行的职责。
总案要求的批量分配放在同一文档清单中:勾选文档、预览统一职责方案、确认提交。首版采用有界批次,任一文档校验失败则整批不写入,并列出原因。
## 五、单成员权限与多人矩阵
“项目权限”提供两个视图,共享同一服务端权限解释:
| 视图 | 默认行为 | 用途 |
|---|---|---|
| 按成员查看 | 普通成员查看自己;管理者可搜索其他成员 | 查看具体权限、配置来源和拒绝原因 |
| 权限矩阵 | 管理者查看成员×项目动作 | 比较成员权限,发现缺失或差异 |
矩阵支持成员搜索、专业角色/项目身份过滤、分页及权限分组。点击单元格可展开解释,显示角色默认、管理员上限、项目覆盖及结果。
项目覆盖使用三态:沿用角色默认/项目内允许/项目内禁止。管理员上限禁止的动作不能通过项目覆盖授予;“恢复默认”需要实际撤销覆盖,不能用一个布尔值模拟。
权限目录必须明确动作所属范围:
| 内部标识 | 显示名称 | 所属范围 |
|---|---|---|
| `project.create` | 创建项目 | 系统角色权限,项目页面不出现 |
| `member.manage` | 管理项目成员 | 项目 |
| `duty.assign` | 分配文档职责 | 项目 |
| `stage.advance` | 推进项目阶段 | 项目 |
| `doc.read` | 读取文档 | 项目动作,具体文档仍须授权 |
| `doc.write` | 编制与编辑文档 | 项目动作,仍受职责和状态限制 |
| `knowledge.publish` | 发布项目知识 | 项目 |
这个范围划分同时约束矩阵读面和覆盖写面:**不能只是隐藏 `project.create`,服务端也必须拒绝在项目中配置它。**
权限名称、项目身份、来源、状态及拒绝原因统一使用人类可读文案。内部标识只保留在按需展开的技术详情中。
同时核对每项权限与真实操作门禁。例如当前项目归档还有创建者/域管理员条件,矩阵解释必须反映真实条件。矩阵中的“允许编制文档”也不能意味着能修改项目内所有文档。
普通成员自查权限的条件收敛为“当前有效项目成员”,避免文档读取权限被收回后,连自身权限与原因也无法查看。
## 六、技术划分与实施工作包
基座负责身份、基本资料、受管设置机制与通用契约;RDM 负责项目成员、专业角色、权限策略及文档职责;Frontend 负责业务交互;UI 仓提供通用选择器原语。
| 工作包 | 内容与主要范围 | 依赖 | 完成条件 |
|---|---|---|---|
| P1 契约与需求固定 | 设置作用域、项目动作目录、人员/文档候选 DTO、能力与版本语义;更新关联方案 | 无 | 本次五项要求都有稳定验收条件,四类身份/角色/职责概念明确 |
| P2 系统设置闭环 | Core 设置描述、Backend 设置 API/存储/生效链/模型及密钥解析;系统管理入口 | P1;**基座发版与 RDM/Dev 升 pins**(见评审补充 1) | 系统受管项只能由有权管理员配置,旧个人/项目值不能覆盖 |
| P3 人员与成员接口 | 扩展公开账号搜索;RDM 专业角色摘要、成员查询、项目身份调整与提交校验 | P1;姓名来源核实(见评审补充 3) | 账号/姓名/角色过滤同源,添加与身份调整明确分离 |
| P4 文档与职责接口 | 专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动 | P1、P3 | 跨项目/非成员指派被拒,职责与审签变更全成或全败 |
| P5 通用选择器 | UI 仓搜索选择、单/多选、键盘操作、分页与状态;Frontend 人员/文档适配 | P1,接线依赖 P3、P4 | 三类使用场景共享交互,无自由文本误提交 |
| P6 权限解释与矩阵 | RDM 项目动作目录、单人/批量解释、覆盖三态、来源与拒绝原因 | P1、P3 | 矩阵与执行规则一致,系统动作无法写入项目覆盖 |
| P7 项目设置集成 | 重构现有项目页,连接四个页面、能力状态、读取回填与保存结果 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程 |
| P8 迁移与组合验收 | 旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填 | P2—P7 | 需求到证据闭合,无越权、隐私泄露或数据丢失 |
前端主要改动落在现有 `ProjectSettingsModal`、`adminRdmSections`、`rdmManagement`、`api` 和 `store`;按业务拆分成员、职责及权限组件,避免继续扩大一个管理组件文件。
目前 Dev 与 RDM 固定的 Backend 版本存在能力差异。实施时必须按公开契约推进相关版本,再完成组合验证,不能因为独立 RDM 仓已有某个接口就假定 Dev 组合可直接使用。
## 七、界面与异步状态要求
按根目录 `DESIGN.md` 实施,复用现有令牌、动效、设置外壳和折叠原语。
- 一种对象只有一个主要选择路径,搜索和浏览在同一选择器完成。
- 姓名、文档名为主要信息,账号和 ID 为辅助信息。
- 下拉支持键盘移动、确认、关闭;审核人多选使用清晰标签。
- 加载、空结果、权限不足、接口未装配、查询失败分别呈现。
- 切项目、切文档、改筛选时清除不适用的选中项和结果;迟到响应不能覆盖当前对象。
- 异步状态只有一个所有者,按请求代次/事件顺序丢弃过期结果。
- 保存后读取服务端结果;网络断开且结果未知时先核对状态,避免盲目重放。
- 未保存改动提供轻量离开提示;需重启的设置明确显示待生效,不能统一宣称即时生效。
- 窄屏按成员查看权限,矩阵可横向浏览,不压缩成不可读的小格子。
## 八、迁移、验证与交付安排
旧配置先做脱敏盘点,列出配置路径、来源和冲突状态。不能任取某个用户/项目的模型配置提升为全系统配置。先确定并验证系统配置,再启用受管策略;旧值保留受保护的恢复依据,退出生效链。
旧项目内 `project.create` 覆盖退出项目策略,保留历史依据。历史职责、审核与批准记录保留;无效的当前职责列入修复清单,不自动替换人员。
正式验收至少覆盖:
| 验收场景 | 预期结果 |
|---|---|
| 项目与个人设置写入系统模型项,包括手造请求 | 拒绝;旧覆盖也不影响运行结果 |
| 账号、姓名、下拉、专业角色过滤查找成员 | 能找到并选择稳定账号;同名不会误选 |
| 重复添加已有负责人、并发修改最后负责人 | 不发生隐式降级,不破坏负责人约束 |
| 文档 ID、标题、列表、树查找 | 指向同一文档;章节及其他项目对象不能误提交 |
| 搜索后人员被移出项目,再保存职责 | 服务端拒绝 |
| 职责变更中途失败 | 职责、审签状态与事件完整回滚 |
| 单成员详情与多人矩阵对照实际操作 | 结果与原因一致;具体资源限制清晰 |
| 项目覆盖授予超上限动作或 `project.create` | 拒绝;恢复默认真正生效 |
| 快速切项目/文档、断网、迟到响应 | 不显示旧对象数据,不误报成功 |
| 同项目多成员使用、刷新及重启 | 共享配置一致,个人会话与原件仍私有 |
验证分为领域与契约测试、真实 SQLite/PostgreSQL 集成、真实身份浏览器流程,以及 Dev 精确组合的 `make test`、`make build`。浏览器需要覆盖非管理员项目负责人、普通成员、互异的编制/审核/批准人员及两个项目;不能用全管理员账号代替权限验收。
分两批形成可审查实现:先完成 P1—P4、P6 的服务端边界与契约,再完成 P5、P7 和 P8 的交互及组合验收。界面设计可在第一批同时评审。
## 评审补充(2026-10-13 技术评审并入,随方案一并批准)
1. **P2 显式依赖基座发版。** 受管设置机制是基座(Backend/Core)公开契约扩展,按总案交付顺序走“扩展申请评审→基座实现→基座发版→RDM/Dev 升 pins→组合验证”。P2 完成条件在原基础上追加:基座版本已发、pins 已升、Dev 组合 `make test` 通过。
2. **项目共享配置的存储迁移规则。** 当前 project scope 物理存储在各 owner 名下;改为“以项目为权威”需要:新项目作用域存储、存量多 owner 副本的合并策略(默认规则:同键取最近写入时间,冲突清单列出不自动合并的键并交项目负责人裁定)、旧键退出生效链并保留只读恢复依据。P8 交付物含迁移清单与执行记录。
3. **姓名来源与账号停用能力须先过 facts。** 基座账号目录当前明确“不含姓名/联系方式”。P3 的姓名搜索依赖基座账号模型是否存有姓名/显示名字段;P1 契约先定姓名来源(基座扩契约,或 RDM 专业角色档案补姓名)。账号停用机制现状同样按 `policy/facts.md` 登记验证,未证实前不把 `valid=true` 当作停用语义。
## 顺序裁定(2026-10-13)
本增量按自身 P1→P8 顺序推进;P2 的基座契约扩展按总案 369 行发版顺序执行,与总案 U1/U9 残余项的交织在扩展申请评审时统一排队,不因本增量跳过 U1(正式产物)与 U9(公开授权契约)的既有优先级。
## 评审核查记录(2026-10-13,源码 3fb8210 / RDM 255f9cb)
评审对方案“当前源码情况”逐项核查,全部属实:
| 声明 | 证据 |
|---|---|
| 项目设置按“用户+项目”保存 | Backend `settings.go` `Effective(owner, projectID)`,project scope 以 owner 为键 |
| user/project 覆盖可改模型设置,无受管拦截 | 同上覆盖链,无“系统受管”概念 |
| 成员手填账号 | `adminRdmSections.tsx` RdmMembersSection |
| 账号目录仅 owner+有效态 | RDM `rdm.account.list` 描述“owner+有效态;不含姓名/联系方式” |
| 职责手填 docId 与账号 | RdmDutiesSection placeholder |
| 已有单成员权限解释表 | `rdm.perm.check`(动作/生效/来源/原因),前端默认自省 |
| 权限标识与所属范围 | RDM `internal/perms/perms.go:21-31`,`project.create` 注释即“全局动作” |
| 职责目标未校验成员 | `rdmReviewAssign` handler 注释“数据,非身份”——按 G1-5 旧裁定绕过成员校验;**本方案 P4 推翻该裁定,属规则变更,在 P1 契约中记录** |
| 职责更新与审签失效分步 | 文档级 assign 先写职责再调 `InvalidateActiveDocSubmission`,两步顺序非原子;**章节级 assign 完全未接失效** |
## 主记录与推进
- 主记录:本文件(唯一正文);任务卡 `.task/feature-rdm-increment-settings-duties.md` 承载需求表、证据与阶段结论。
- 来源:`.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`(原始用户补充)、2026-10-13 会话评审。
- 下一步:P1 已随本稿固定;按两批顺序进入 P2(基座受管设置契约扩展申请)与 P3/P4/P6 服务端实现。
+32 -1
View File
@@ -6,7 +6,18 @@
## 先看哪一份
新增方向(2026-10-11 用户已裁定关键取舍):[Generative UI 调研与插件方案 r1](2026-10-10-generative-ui-plugin.md)。
- [快慢通道展示与动态工作摘要方案 r1.1](2026-10-12-fast-slow-channel-display.md):
运行卡呈现状态、已完成工作、当前发现与剩余项;四层阅读、阶段成果、来源、异常恢复及 U1–U4。
2026-10-12 方案设计已批准(阶段 1–4);首批仅 U1;[U1 实施计划 r1](2026-10-12-fast-slow-channel-display-u1-plan.md) 待阶段 5 批准;业务实施和运行验收 NOT_RUN。
Generative UI 方向已收口(U1–U7 全部落地,2026-10-12):[使用说明与评测记录](2026-10-12-generative-ui-usage-and-evaluation.md)(final);
主记录 [r2](2026-10-10-generative-ui-plugin.md) 与 [U5 动作范围 r2](2026-10-11-generative-ui-u5-action-scope.md) 保留为过程权威。
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 实施另行开任务。
新增方向(已裁定取舍;U1 试验完成,r2 含结果与修订):[Generative UI 调研与插件方案 r2](2026-10-10-generative-ui-plugin.md)。
首试点为对话内完整分析页,交付采用可信编译插件;U1 试验限 MiniMax M3 + M2.7-highspeed、合成或脱敏材料、费用上限 ¥200,作为独立任务另行评审启动。
此记录独立于下方历史核验快照,不改写历史方案/PR 数量或验收结论。
@@ -158,3 +169,23 @@ RDM 总案把库分期作为支撑与依赖,不覆盖库分期的原始范围
后续维护:主案或任务变化时先更新其唯一主记录,再更新这里的导航和核验快照。
更换 Docs/Dev 基线后重新核对 PR、版本与在途任务;新的索引状态不自动产生实施授权。
## 2026-10-13 规划补充
- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md):承接总案 U3/U4/U6(衔接 U5)的完整增量——设置作用域与受管项、可搜索人员选择器、文档清单+职责分配、单成员/多人权限矩阵与三态项目覆盖;含服务端一致性修复(职责目标成员校验推翻 G1-5 旧裁定、职责变更与审签失效原子化)与 P1–P8 工作包。**2026-10-13 用户评审通过并授权实施**(两批推进;正式验收与清理回收保留人工节点);P1 契约随本稿固定,P2 基座契约扩展按总案发版顺序排队。
## 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–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),其余方案与实施仍待评审。
- [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md):本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界;覆盖 34 UR/68 SR/10 F、全部69类模板及现有XLSX,当前源复核 RDM d8d7e743。总体方案待评审,实施/迁移/运行验收 NOT_RUN;模板方案为子方案。
- [工作台界面重设计 r0.2](2026-10-12-work-companion-ui-design.md)及[实施计划 r1](2026-10-12-work-companion-ui-plan.md):对话优先、渐进任务摘要、窄屏与单一状态投影;已获本次连续实施授权。
@@ -0,0 +1,14 @@
# 最终目标方案文档审阅记录
对象:[总体方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)与[112 项需求矩阵](2026-10-11-rdm-final-target-requirements-matrix.md)。日期 2026-10-11。
等级 SELF:三组本地模型阅读,覆盖一致性、可行性、产品、范围、交互、权限与失效场景;不是人工批准、独立 GATE/REPLAY 或业务验收。未执行跨供应商审阅。
审阅前增量复核 RDM 从 0081628a 到 d8d7e743 的变化:保留已新增 HostBinding、项目命令守卫、上传项目约束和单行管理员引导事实,不继续按旧缺口排重建;仍需宿主绑定双向权限、成员工作目录与文档资源/职责授权,已进入 G 表及 U2/U3。
| 发现 | 后果 | 已作修订 |
|---|---|---|
| U7 全模板真实验收是 U8 生成能力的前置,形成相互等待 | 可能以静态注册检查冒充全量模板可用 | U7 收敛为全量台账/公共契约/两模板;U8 首批闭环;新增 U16 全文档族迁移验收;U14 等 U16 |
| U8 首批竞品模板含法规要点,却未依赖 U12 | 可能用模型URL或单通道占位完成首批 | U12 加入 U8 前置,同步依赖表和说明,保持无环 |
最终产品/范围/交互复核未提出其他实质问题,34 UR、68 SR、10 F 编号集合无缺项/重复;全部69类及XLSX目标未缩水。权限/失效场景复核确认私域与授权知识快照、三权、防换角色自审、撤权、宿主双向绑定等约束已表达。
本记录仅证明文档检查及相应修订;实际执行能力、测试通过、部署和用户验收均未据此认定。
@@ -0,0 +1,136 @@
# 最终目标逐条覆盖矩阵(2026-10-11)
主记录:[完整交付方案 r1](../proposals/2026-10-11-rdm-final-target-completion.md)。来源:RDM `docs/requirements/01-用户需求与系统需求.md`(V2.2)及 README/U0/Q 裁定;复核 RDM d8d7e743。
34 UR、68 SR、10 F 均保留原编号。以下为 SELF 源码级盘点,当前运行验收均 NOT_RUN;“已有”不等于已验证/部署,“后移”不等于取消。摘要仅用于定位,语义以原文和用户确认 D1–D6 为准。G/U 均指主记录。
## 系统需求(68 条)
| ID | 原文摘要 | 当前源码级情况 | 仍需完成 | 工作包/差距 | 原文行 |
|---|---|---|---|---|---|
| SR-A1 | 系统应支持 doc/docx/pdf/ppt/pptx/xls/xlsx/md/txt/图片等常见格式上传,对不支持格式仅提醒不阻断 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 431 |
| SR-A2 | 上传不强制附带文字指令;无指令时进入默认"记忆构建"流程(见 SR-B 系列),不输出制式化"未识别需求"回复 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 432 |
| SR-A3 | 支持单文件、多文件批量上传,并记录来源渠道(Web/飞书/其他)与上传人 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 433 |
| SR-A4 | 上传后 60 秒内输出第一阶段反馈(相关性结论 + 初步阶段归类);完整入库允许后台异步完成 | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 434 |
| SR-A5 | 入库完整性保障:解析失败、部分内容不可解析或入库异常时,必须显式告知用户并在入库记录中标记,原始文件永久保留可取回;禁止静默降级或静默产出残缺结果(教训来源:旧版曾发生报价单 Excel 数据丢失、P… | 接收/解析部分已有 | 多格式、保真、发布边界、渐进反馈及实际时限需补齐 | U5/U9/U14;G9/G10/G15 | 435 |
| SR-B1 | 对每份上传资料输出相关性判定(相关 / 存疑 / 无关)及判定依据;存疑时必须挂起并向用户请求确认,确认前不入库 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 441 |
| SR-B2 | 对资料进行结构化解析,保留章节/页/表格级锚点,锚点在后续所有引用与追溯中可用 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 442 |
| SR-B3 | 将内容片段映射到研发阶段及"该阶段应从事的具体工作事项",映射结合项目当前所处阶段;支持一片段映射多阶段 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 443 |
| SR-B4 | 每个切片附带结构化标签(JSON):阶段、工作事项、主题、可行性维度(技术/市场/注册)、关联需求 ID、来源、上传时间、置信度;并生成一句话描述(description) | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 444 |
| SR-B5 | 支持"两速入库":快速通道(打标签 + 摘要 + 入库)先行返回,慢速通道(细切片、嵌入向量化)后台补齐,状态对用户可见 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 445 |
| SR-B6 | 入库完成后向用户输出勾连总结:本文档涉及哪些内容、对应哪些阶段/工作事项/文档章节,以显式清单呈现 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 446 |
| SR-B7 | 会议纪要类资料按同一管道处理,并可抽取"结论 / 待办 / 待确认"三类条目 | 摄取/标签组件已有 | 统一来源发布、锚点、摘要、共享检索和会议三类抽取未闭合 | U5/U6;G9/G10 | 447 |
| SR-B8 | 笔记树内一致性检测:同一主题簇下多个切片的陈述不一致(如多人表述冲突)时,系统检测冲突 + 记录入追溯网(何时/何人/何节点/何操作)+ 通知触发冲突的用户 + 挂起待裁决;智能体不自行处理冲突,裁决… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6;G11 | 448 |
| SR-B9 | 并发更新冲突避免与及时提示:多人几乎同时更新同一树节点时,系统忠实记录全部操作入追溯网,冲突以候选子节点组并存挂起,智能体不自行处理冲突;裁决集中在编制人发起编制时经 HITL 完成(裁决两层,规则同… | 检测/裁决基础已有 | 冲突组、精确争议关闭与两层裁决未闭合 | U4/U6;G11 | 449 |
| SR-B10 | 任务快慢双速:对用户任务按快慢双速模式执行——快通道同步短链路即时反馈(如上传文档→相关性判断→相关给概要/不相关给理由+相似文档供选择),慢通道小队(subagent)后台深度执行(逐页解析、建节点… | 内存队列/台账已有 | 持久输入、取消恢复、幂等与通用双速未完成 | U9/U13;G15 | 450 |
| SR-B11 | 结论节点:结论作为笔记树的节点类型保存(结论入树);结论节点与切片同受 08 R1–R5 硬规则约束(append-only、软删除、结构事件日志、可重建);结论节点与其依据切片/来源的关联入追溯网。… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6;G11 | 451 |
| SR-B12 | 总结触发:何时生成阶段总结交模型自主判断(不设固定阈值)——信息足够支撑结论时自动生成阶段性总结并询问用户是否纳入文档(HITL 确认);保留人工触发入口(用户明确指令触发);上传后先快速摘要反馈、后… | 结论提议/确认已有 | 总结水位更新、项目约束和原子采纳未闭合 | U6;G11 | 452 |
| SR-C1 | 内置可配置的研发体系文档树(阶段 → 文档 → 章节),每章有内容要求说明;文档树对应设计开发控制程序,商务对接与策划合并为同一阶段 | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16;G7/G8 | 458 |
| SR-C2 | 体系文档模板集中注册、版本化管理;模板与阶段/文档节点的关联可配置,不与具体工作流实例硬绑定。模板策略:本期按当前已有模板设计与完善;标准模板待系统完成并通过测试后由用户补充(E-T3,后续目标 F-… | 目录69类、注册4模板 | 完整模板结构/格式/版本、生成与全文档族覆盖未完成 | U7/U8/U16;G7/G8 | 459 |
| SR-C3 | 文档生命周期状态机:草稿 → 评审中 → 已基线 →(变更中)→ 新版本基线;基线文档不可被直接修改 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 460 |
| SR-C4 | 新切片填充文档章节前,与该章节现有内容比对,输出三分类结论:新增 / 更新 / 冲突;更新与冲突均需用户确认后生效 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 461 |
| SR-C5 | 缺项分析仅在两种触发条件下输出:文档提交评审时、项目申请推进阶段时;上传节点禁止输出缺项提示 | 简单素材检查已有 | 内容/合规要求检查未接提交和阶段门禁 | U10/U11;G14 | 462 |
| SR-C6 | 每次文档内容变化生成版本记录,可查看任意两版本差异及差异来源切片 | 章节版本/Apply已有 | 持久提案、依据保留、原子采纳和整文快照待补齐 | U4/U8/U10;G6/G8/G17 | 463 |
| SR-C7 | 三权分立流程规则:编制/审核/批准三权异人(编制唯一、批准唯一且异于编制人、审核可多人但异于编制与批准人);编制发起唯一;审核/批准仅可批注与通过/驳回,不可修改正文或发起编写;提交审核即锁定;驳回回… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8;G6/G17 | 464 |
| SR-C8 | 批准后修改的处理:本期路径=撤回重审(D-12:撤回后修改并重新升版审批)+影响提示(沿追溯网列出受影响范围给人看,不走流程,见 SR-D3);松散管理取向,但审计链不断(08 R1/R2/R5 不动… | 章节三权已有 | 文档级职责、资源读取、总线身份和固定整文审签未闭合 | U3/U8;G6/G17 | 465 |
| SR-D1 | 建立并持久化双向追溯网络:资料切片 ↔ 需求条目 ↔ 文档章节 ↔ 法规条款 ↔ 测试用例;每条边记录类型、来源(人工/规则/模型候选)与置信度 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 471 |
| SR-D2 | 需求条目化管理:用户需求与系统需求大表,字段含状态(草稿/已评审/已基线)、版本、关联文档与法规;支持增删改与批量导入 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 472 |
| SR-D3 | 新内容入库触发变更检测:与已评审条目比对,不一致时向用户提示风险并给出"确认变更 / 维持原样 / 发起变更流程"选项。影响提示(V2.1 增补):批准后修改或引用内容变化时,系统沿追溯网列出受影响范… | 部分关系/变化方法已有 | 来源变化的影响对象和职责闭环待完成 | U6/U11;G11/G16 | 473 |
| SR-D4 | 变更流程闭环(变更申请 → 影响分析 → 评审 → 批准 → 执行 → 验证 → 关闭,全程留痕):整体后移,不作为本阶段系统实现目标——变更流程走公司内部管理流程,移入后续目标备案 F-02(《10… | 后移目标保留 | 公司流程权威及七步闭环待独立交付 | U15/F-02;G14 | 474 |
| SR-D5 | 任一需求可导出完整追溯链报告;无法匹配进体系的资料进入"待裁定"清单,提醒用户处理 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 475 |
| SR-D6 | 追溯主体扩展:追溯网每个节点的信息来源可溯——来自哪个用户、哪个智能体、哪次网络搜索、哪个文档树模板、哪条知识树切片,保证所有信息细节的准确性与可追溯性 | 来源字段已有 | 模板/主体/来源版本须贯穿生成历史和导出 | U4/U8/U11;G8/G17 | 476 |
| SR-D7 | 完整合规追溯模型(权威定义见 08 第十六章):15 类受控节点(含危害/风险控制措施/设计确认/设计转换/变更)+11 类合规边(两端=节点 ID@版本,模型仅候选、人工确认转正)+四条链视图(13… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 477 |
| SR-D8 | 需求分类与分解框架:用户需求与性能需求分到不同文档;先确认用户需求再分解系统需求;系统需求按六维度分类(功能/交互/安全/运输包装/维护/合规);智能体可从法规反推部分系统需求,但不完全依赖智能体;先… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 481 |
| SR-D9 | 风险登记册追溯:危害(HAZ)与风险控制措施(RCM)入网;每个 RCM 同时登记为需求并必须被验证(verifies 边);每个危害至少被一项 RCM mitigate;措施-危害-验证三向可查(术… | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 478 |
| SR-D10 | 验证结果绑定被测版本:VR 记录对应用例与被测对象版本;被测版本≠当前基线版本时系统报「验证过期」并列入缺口;设计确认(VAL)必须追溯到用户需求 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 479 |
| SR-D11 | SOUP 组件登记与追溯:软件组成项(含 SOUP)入网为架构项,其需求分配与验证沿用同一边模型 | 台账/受控图读模型已有 | 业务生产者、版本边确认、分解规则与历史导出需补齐 | U11/U14;G12/G17 | 480 |
| SR-E1 | 意图识别分层:规则层(仅限整句完全匹配的高频确定性短指令)→ 语义层 → LLM 层;规则层不得单独触发高风险操作 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 487 |
| SR-E2 | 规则层命中必须通过上下文校验(上一轮存在对应的待确认事项)才可执行;无上下文时降级为普通对话 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 488 |
| SR-E3 | 确认、变更、删除、阶段推进等操作一律通过标签卡/按钮交互完成,卡片明示操作对象与后果 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 489 |
| SR-E4 | 支持意图分类(查询 / 编写 / 命令 / 讨论)与意图切换识别;编写类意图需命中目标文档并确认后执行 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 490 |
| SR-E5 | 简单询问即时回答;复杂任务先给出执行计划与预计耗时,执行中提供进度反馈 | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 491 |
| SR-E6 | 对话完备路径:从立项到结项的全部状态变更操作(创建项目、提交评审、批准变更、阶段推进、导出、结项等)均可通过对话指令驱动,页面/按钮不是任何步骤的唯一入口;高风险操作的对话路径终点为对话流内联确认卡(… | 基座意图/卡片与RDM命令已有 | 工具可达、对话完备、固定确认对象与恢复需补齐 | U2/U8/U9/U10;G1/G8/G14/G15 | 492 |
| SR-F1 | 复杂任务由多角色"小队"在固定流程骨架约束下执行:骨架显式定义步骤序列与返回检查节点,角色在骨架内有限自主 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 498 |
| SR-F2 | 每个角色显式声明:职责、可用工具白名单、禁区;角色提示词作为受控资产版本化管理 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 499 |
| SR-F3 | 涉及法规的任务强制执行"法规知识库检索 + 网络检索"双通道,结果附引用来源;冲突时以权威来源为准并提示 | 知识检索/声明表已有 | 网络通道为模型输出URL,缺实际抓取独立证据 | U12;G13 | 500 |
| SR-F4 | 长任务后台异步执行,进度可查询、完成有通知;不得阻塞对话主线程 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 501 |
| SR-F5 | 执行任务时自动组装上下文:项目当前状态、相关记忆切片、目标文档模板、近期对话;上下文构成可解释 | 运行与部分模型调用已有 | 受控业务配方、固定上下文、恢复和真实模型对照待完成 | U8/U9/U13;G8/G15/G18 | 502 |
| SR-G1 | 飞书集成:智能助手可加入群聊,支持群内对话、收文件、推送反馈与通知。本期不做飞书功能(J-11),本条与 UR-20 一并后移 → F-01 | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 508 |
| SR-G2 | 基于角色与项目阶段的权限控制(ABAC),阶段转换需满足准入准出条件并留痕。判定维度(角色 × 项目 × 阶段 × 动作)保留;权限主数据裁决(J-10,R2 关闭):本期系统内建最小权限系统(管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 509 |
| SR-G3 | 全量审计日志:上传、入库、更新、变更、确认、生成等动作均可审计 | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11;G5/G17 | 510 |
| SR-G4 | 系统以自身研发项目为首个运行实例(自举元项目),自身需求与体系文档由本系统管理 | 自举测试资产已有 | 真实材料/模型/登录/浏览器全程验收未完成 | U14;G19 | 511 |
| SR-G5 | 结构追溯:笔记树、文档树、追溯网自身的结构变更全程留痕——节点与关系的增/删/改记录操作者、时间、理由与前后值;删除一律软删除(tombstone);追溯边有"候选 → 生效 → 废止"全生命周期;支… | 事件/重放基础已有 | 原子批次、权限投影、完整历史与导出一致性待补齐 | U4/U11;G5/G17 | 512 |
| SR-G6 | 系统管理员与系统级设置:全局唯一管理员拥有所有权限;仅管理员可进行系统级设置——Tavily API Key、大模型相关设置、Agent 参数(工具调用轮数/工具权限等)、系统级插件管理、用户/角色的… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 513 |
| SR-G7 | 角色管理:角色定义与默认权限集——能否创建项目/是否拥有某些文档的读取权限/能否推进项目到下一阶段/能否为项目添加成员/能否为成员配置项目内权限/能否为各模板文档分配三权负责人;角色可分配给用户(如项… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 514 |
| SR-G8 | 权限覆盖优先级——上限内覆盖(J-05,原存疑关闭):管理员设定角色默认权限与权限范围上限(最底层约束);项目负责人(创建者)在该范围内调整项目成员权限;项目内配置可覆盖角色默认配置,但不得突破管理员… | cap/override与命令守卫已有 | 平台身份接入、专业角色、资源授权与全入口待补齐 | U2/U3;G3/G4 | 515 |
| SR-G9 | 项目负责人权限:项目创建者即项目负责人,拥有项目内全部权限——添加项目成员、编辑项目成员权限、为各模板文档分配编制/审核/批准负责人 | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3;G1/G2 | 516 |
| SR-G10 | 项目唯一性与成员自动可见:同名项目全系统唯一;用户被添加为项目成员后,其界面自动出现该项目,并可直接开始项目工作(新建对话等) | 域项目唯一、成员、绑定已有 | 成员目录、可信当前项目、双向绑定权和界面未闭合 | U2/U3;G1/G2 | 517 |
| SR-G11 | 对话隐私:用户之间的对话互相不可见,仅本人可见本人与智能体的对话;智能体会话/中间过程默认互不可见(J-06,原存疑关闭),协作全部经两树一网项目共享层;用户分享分层(整个项目/会话/部分会话)的精细… | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9;G4/G5/G10 | 518 |
| SR-G12 | 文档分享:上传者可将文档分享给指定成员/部分成员/全部项目成员;被分享者只读、不可编辑;被分享文档进入接收者上下文,支撑其后续对话中查看并基于这些文档对话 | 会话owner隔离已有 | 私有原件/草稿/文档ACL与授权发布/共享上下文待贯通 | U3/U5/U9;G4/G5/G10 | 519 |
| SR-G13 | 上下文时间权重:本期最小实现——检索与注入排序新内容优先;替换/冲突场景走 J-02 人裁决(SR-B8/SR-B9)。可配置时间权重衰减模型(权重数值、配置粒度)移入后续目标 F-04(J-07,优… | 排序效果未验收 | 新内容优先不代替裁决,可配置衰减后续实现 | U5/U15/F-04;G10 | 520 |
| SR-G14 | 飞书项目对接适配(接口层四项功能:产品创建/账户绑定扫码登录/URL 协同连接/知识库上传生成链接;飞书角色权限映射读取):本期不做飞书功能,整条移入后续目标备案 F-01(J-11);保留设计预留说… | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 521 |
| SR-G15 | 虚拟人账号(企业账号下为智能体创建固定账号持有文档/文件夹访问权限;授权范围、审批与定期审计流程待明确,《10》Q-04):随飞书对接整体后移,移入后续目标备案 F-01(J-11) | 后移目标保留 | 外部身份/租户/渠道/同步授权与适配待交付 | U15/F-01;外部依赖 | 522 |
| SR-G16 | 代码执行安全:多用户共享部署在隔离执行档就位前,以启动级硬关闭禁用执行原语(run_shell/run_python/register_artifact 及内核执行配置),用户设置不得覆盖(基座已交付… | 多人执行硬关闭已有 | 最终隔离执行及受控开放待实现验收 | U13;G18 | 523 |
| SR-N1 | 性能:上传首轮反馈 < 60 秒;单文档完整入库(后台)< 10 分钟;追溯链查询 < 3 秒 | 部分运行机制已有 | 固定样本/数据/并发规模的性能待实测 | U14;G18/G19 | 529 |
| SR-N2 | 可维护性:模块边界清晰、依赖单向;任一核心功能(如文档入库)可在 5 分钟内定位到对应代码模块;支撑每周代码审查机制 | 模块边界已有 | 公开契约、文档代码可定位性与维护机制待复核 | U1/U14;G19 | 530 |
| SR-N3 | 可解释性:每个入库、更新、变更动作给出依据(来源切片、命中标签、比对结果) | 部分依据回执已有 | 标签、来源、差异与失败可解释性需全链路验证 | U4/U5/U8;G10/G17 | 531 |
| SR-N4 | 部署与数据:支持本地化部署;法规知识库本地存储;项目数据按项目隔离 | 领域分片与本地存储已有 | 团队数据权威、私域隔离、安装和恢复未完整验收 | U2/U3/U13;G5/G18 | 532 |
| SR-N5 | 模型无关性:大模型通过抽象层接入,可替换(当前为 MiniMax,不绑定) | 模型抽象已有 | 模型替换后的真实业务与降级对照待验证 | U9/U13;G8/G18 | 533 |
## 用户需求(34 条)
每条用户需求沿原 UR→SR 关系追溯,其所有适用系统需求通过后才可关闭。
| ID | 用户目标 | 原关联SR | 实施去向 | 当前判定 | 原文行 |
|---|---|---|---|---|---|
| UR-01 | 自由上传 | SR-A1, SR-A2, SR-A3 | U5/U9/U14 | 局部组件已有;端到端未验收 | 541 |
| UR-02 | 相关性把关 | SR-B1 | U5/U6 | 局部组件已有;端到端未验收 | 542 |
| UR-03 | 自动归纳入库 | SR-A5, SR-B2, SR-B3, SR-B4, SR-B6 | U5/U6/U9/U14 | 局部组件已有;端到端未验收 | 543 |
| UR-04 | 及时反馈 | SR-A4, SR-B5, SR-E5, SR-F4 | U2/U5/U6/U8/U9/U10/U13/U14 | 局部组件已有;端到端未验收 | 544 |
| UR-05 | 渐进式清晰 | SR-C1, SR-C2, SR-C3, SR-C4, SR-C6 | U4/U7/U8/U10/U16 | 局部组件已有;端到端未验收 | 545 |
| UR-06 | 缺项提示时机 | SR-C5 | U10/U11 | 局部组件已有;端到端未验收 | 546 |
| UR-07 | 冲突与变更 | SR-B8, SR-C3, SR-C4, SR-D3, SR-D4(→ F-02) | U4/U6/U8/U10/U11/U15 | 局部组件已有;端到端未验收 | 547 |
| UR-08 | 严格可追溯 | SR-B2, SR-D1, SR-D5, SR-G3, SR-G5, SR-C6, SR-D7(合规追溯链,V2.2) | U4/U5/U6/U8/U10/U11/U14 | 局部组件已有;端到端未验收 | 548 |
| UR-09 | 需求条目化 | SR-D2, SR-D3, SR-D8(需求分类与分解框架,V2.2) | U6/U11/U14 | 局部组件已有;端到端未验收 | 549 |
| UR-10 | 模糊澄清 | SR-B6, SR-B8, SR-E5(提问交互) | U2/U4/U5/U6/U8/U9/U10 | 局部组件已有;端到端未验收 | 550 |
| UR-11 | 一键生成文档 | SR-E4, SR-F1, SR-F2, SR-F5 | U2/U8/U9/U10/U13 | 局部组件已有;端到端未验收 | 551 |
| UR-12 | 主动提问 | SR-E5, SR-B6 | U2/U5/U6/U8/U9/U10 | 局部组件已有;端到端未验收 | 552 |
| UR-13 | 外部查询入库 | SR-F1, SR-F3, SR-B4 | U5/U6/U8/U9/U12/U13 | 局部组件已有;端到端未验收 | 553 |
| UR-14 | 法规双通道 | SR-F3 | U12 | 局部组件已有;端到端未验收 | 554 |
| UR-15 | 商务策划贯通 | SR-C1, SR-C2 | U7/U8/U16 | 局部组件已有;端到端未验收 | 555 |
| UR-16 | 显式确认 | SR-E1, SR-E2, SR-E3, SR-E6 | U2/U8/U9/U10 | 局部组件已有;端到端未验收 | 556 |
| UR-17 | 阶段门禁权限 | SR-G2, SR-G3 | U2/U3/U4/U11 | 局部组件已有;端到端未验收 | 557 |
| UR-18 | 会议纳入记忆 | SR-B7 | U5/U6 | 局部组件已有;端到端未验收 | 558 |
| UR-19 | 自举 | SR-G4 | U14 | 局部组件已有;端到端未验收 | 559 |
| UR-20 | 协作平台接入 | SR-A3, SR-G1(本期不做飞书功能,一并后移 → F-01,J-11) | U15 | 后移目标保留 | 560 |
| UR-21 | 系统角色与权限管理 | SR-G2, SR-G6, SR-G7, SR-G8 | U2/U3 | 局部组件已有;端到端未验收 | 561 |
| UR-22 | 项目成员与协作 | SR-G9, SR-G10 | U2/U3 | 局部组件已有;端到端未验收 | 562 |
| UR-23 | 文档分享与上下文注入 | SR-G11, SR-G12, SR-G13(降 P2,衰减模型 → F-04) | U3/U5/U9/U15 | 局部组件已有;端到端未验收 | 563 |
| UR-24 | 三权分立文档流程 | SR-C7, SR-C8 | U3/U8 | 局部组件已有;端到端未验收 | 564 |
| UR-25 | 版本全量保留与来源追溯 | SR-C6, SR-D6, SR-G5 | U4/U8/U10/U11 | 局部组件已有;端到端未验收 | 565 |
| UR-26 | 并发更新冲突避免与提示 | SR-B8, SR-B9(J-02 落地+U0 D4 两层裁决) | U4/U6 | 局部组件已有;端到端未验收 | 566 |
| UR-27 | 快慢处理与任务拆解展示 | SR-B10(J-03 已裁决落地) | U9/U13 | 局部组件已有;端到端未验收 | 567 |
| UR-28 | 简易看板 | SR-C3, SR-D3(编制状态与变更检测为看板数据源;看板与卡片流界面统一 → F-06) | U4/U6/U8/U10/U11 | 局部组件已有;端到端未验收 | 568 |
| UR-29 | 难度分级与降级使用 | SR-F2(智能体能力边界按项目难度配置;评估表与降级规则细化 → F-08) | U8/U9/U13/U14/U15 | 局部组件已有;端到端未验收 | 569 |
| UR-30 | 对抗验证机制 | SR-F1(流程骨架中增设独立验证节点;对抗机制形态待设计,属《10》Q-13,维持开放) | U8/U9/U13/U14/U15 | 局部组件已有;端到端未验收 | 570 |
| UR-31 | 飞书项目对接 | SR-G14, SR-G15(本行整体→ F-01) | U15 | 后移目标保留 | 571 |
| UR-32 | 代码管理工具集成 | SR-D1(追溯网扩展需求—版本—缺陷关联边;本行整体→ F-05) | U15 | 后移目标保留 | 572 |
| UR-33 | 法规合规追溯 | SR-D7, SR-D9, SR-D10, SR-D11, SR-D1 | U11/U14 | 局部组件已有;端到端未验收 | 573 |
| UR-34 | 结论沉淀与阶段总结 | SR-B11, SR-B12 | U6 | 局部组件已有;端到端未验收 | 574 |
## 后续目标(10 项)
| ID | 原目标 | 当前处理 | 交付去向 | 原文行 |
|---|---|---|---|---|
| F-01 | 飞书对接全套(渠道 EXT-3、扫码登录、权限映射、虚拟人账号、文档同步/版本关联) | 保留最终目标,前置与批准见主记录 | U15/F-01 | 637 |
| F-02 | 变更流程引擎(七步闭环、变更单、完整影响分析) | 保留最终目标,前置与批准见主记录 | U15/F-02 | 638 |
| F-03 | 用户分享分层(整个项目/会话/部分会话)与智能体可见性的精细设计 | 私有默认已确认,细分分享需明确授权 | U15/F-03 | 639 |
| F-04 | 可配置上下文时间权重衰减模型 | 保留最终目标,前置与批准见主记录 | U15/F-04 | 640 |
| F-05 | 代码管理工具集成(GitLab token 只读拉取、需求-版本-缺陷关联) | 保留最终目标,前置与批准见主记录 | U15/F-05 | 641 |
| F-06 | 看板与卡片流的界面统一(随原型 V2.3) | 并入对话与看板同源收敛 | U9/U14 | 642 |
| F-07 | 会议遗留问题组(Q-01/02/03/07/10/13/14 等,《12》问题 8 组);其中 Q-02 经晚会部分裁决(C-03,见 §7.1) | 逐项裁决台账,不当作已确定的一组功能 | U15/F-07 | 643 |
| F-08 | 难度分级评估表与降级机制的落地细化(UR-29 保留 P1,实施细节备案) | 保留最终目标,前置与批准见主记录 | U15/F-08 | 644 |
| F-09 | 追溯网可视化(先功能后展示,暂缓) | 较新展示方案已批准,早期暂缓已调整 | U11/U14 | 645 |
| F-10 | 标准模板替换:本期按当前已有模板设计与完善;待系统完成并通过测试后,由用户补充标准模板(取代晚会 T2「今晚下载官方模板替换」,不执行) | 依赖用户提供标准模板;旧模板先全量实现 | U16+U15/F-10 | 646 |
验收结果槽:本轮未生成业务通过记录;后续由实施任务/CI/独立重放补入命令、对象 SHA、运行链接与输出。历史任务卡另行映射,原始收据不改。
File diff suppressed because one or more lines are too long
@@ -0,0 +1,85 @@
# RDM 文档模板资产盘点(2026-10-11)
关联方案:[对话文档生成方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。本清单为 SELF 静态资产盘点,不表示线上实际文档数或模板已验收。
源:旧 Agent-System `ed4e17c81974c6d2b126fedb1ca4ed1e2c6c207f` 的 `templates/docs/*.md`;RDM `0081628a10ec48a36537c6eced11a57439c986fa` 的 `internal/domain/data/labels_seed.json`、`docs/templates/registry.yaml`。
旧路径规则为 `templates/docs/<类型键>.md`。下列 H2 数只用于估算拆解工作,不等于最终业务章节数;管理性章节需重新归位。
69 份 Markdown:bd 7、rd 60、pm 1、tm 1;另有 `templates/xlsx/cdo_quote.xlsx` 一份,不计入 69。
RDM 登记 69 种 docTypes,但只注册 4 个 v1 模板,覆盖 3 个类型;66 个类型未绑定模板。
“已绑定”仍不表示正确默认、格式兑现或完整生成可用。当前按首项匹配会混用周报/纪要,详情见方案 G3。
所有历史模板迁移/发布/业务验收均待独立评审,本清单不修改发布状态。
| 类型键 | 字典名称 | 阶段 | 历史 H2 数 | RDM 注册绑定 | 原件 SHA256 前16位 |
|---|---|---|---|---|---|
| bd_cdo_quote | CDO 报价单 | BD | 6 | 未绑定 | 4d0cb0b4e4dafecb |
| bd_feasibility_dev | 设计开发可行性评估报告 | BD | 7 | 未绑定 | dc565be65647250c |
| bd_feasibility_reg | 注册路径可行性评估报告 | BD | 9 | 未绑定 | 16add9b2558dee31 |
| bd_intake | 用户初始需求收集表 | BD | 8 | 未绑定 | 427bafe56062f616 |
| bd_prelim_design | 系统初步设计方案 | BD | 9 | 未绑定 | 4001acdbb5bafa5e |
| bd_research | 调研报告(竞品/技术/专利/市场/对比/法规) | BD | 11 | review-minutes@v1、competitive-analysis@v1 | 0b64388a16f8c7de |
| bd_user_requirements | 用户需求表 | BD | 7 | 未绑定 | 547dda49107a4d26 |
| pm_system_reqs | 系统需求规格书(SR) | 03 | 10 | 未绑定 | 3717c5ff34272088 |
| rd_adverse_events | 同类产品不良事件信息 | 03 | 11 | 未绑定 | d2cfbfed223d9dd7 |
| rd_animal_study | 动物试验方案 | 12 | 11 | 未绑定 | f070c80fb84b413d |
| rd_biocompatibility | 生物学检测方案 | 08 | 11 | 未绑定 | bcb25be8e5d8745d |
| rd_cleaning | 清洁消毒验证方案 | 08 | 11 | 未绑定 | 42ec75116e247d88 |
| rd_clinical | 临床试验报告 | 12 | 11 | 未绑定 | 9df8321b7488535d |
| rd_design_input_list | 设计输入清单 | 03 | 11 | 未绑定 | 51c0d2334a8f0475 |
| rd_design_input_spec | 设计输入规格书 | 03 | 12 | 未绑定 | a629d1b3e3dc6e9a |
| rd_design_output_list | 设计输出清单 | 06 | 10 | 未绑定 | 5ffbce9be6d92ccd |
| rd_design_plan | 设计开发计划任务书 | 01 | 11 | review-minutes@v1 | 589dec73a01b1c75 |
| rd_design_validation_report | 设计确认报告 | 13 | 11 | 未绑定 | 9ff1744ebdae179f |
| rd_design_vv | 设计验证方案 | 08 | 11 | 未绑定 | 5ec16dcfbbf55132 |
| rd_dmr_list | DMR文件清单 | 10 | 10 | 未绑定 | 437bda4f714d756b |
| rd_drawings_3d | 2D图纸和3D模型(附件清单) | 06 | 10 | 未绑定 | 96b771a7912a6393 |
| rd_ee_bom | 电子电气BOM(附件清单) | 06 | 10 | 未绑定 | 08052bb640704115 |
| rd_electrical_sys | 系统电气设计图(附件清单) | 06 | 10 | 未绑定 | df4f8aaeedbf4f5c |
| rd_emc_safety | EMC及安规摸底报告(附件清单) | 08 | 11 | 未绑定 | 9257a9a02d6ac939 |
| rd_fqc | 成品检验规范 | 06 | 11 | 未绑定 | 4891c93ff9ce889b |
| rd_hazard_analysis | 安全性问题清单及可能危险分析表 | 03 | 11 | 未绑定 | 3a8ed0db49b35553 |
| rd_ifu | 产品使用说明书 | 06 | 11 | 未绑定 | d76bc2e2a531632a |
| rd_incoming_iqc | 原材料进货检验规范 | 06 | 11 | 未绑定 | 14c21bd69cd9a756 |
| rd_input_phase_review | 设计开发评审记录(阶段3和4) | 05 | 12 | 未绑定 | 5982bdf27dab55f0 |
| rd_ipqc | 生产过程检验规范 | 06 | 11 | 未绑定 | 14bf3912f4dc6c4f |
| rd_lifetime | 产品使用期限研究方案 | 08 | 11 | 未绑定 | f7232dd9750c2369 |
| rd_output_review | 设计开发评审记录(阶段6) | 07 | 12 | 未绑定 | 87029ef45d4ac5b2 |
| rd_pack_ship | 包装运输方案 | 10 | 11 | 未绑定 | a368bd102a0535f3 |
| rd_packaging | 包装图纸和设计要求 | 06 | 11 | 未绑定 | e12a32ded3da14f1 |
| rd_pcba | PCBA原理图及Layout(附件清单) | 06 | 10 | 未绑定 | 4b91abe3191c36df |
| rd_planning_review | 设计和开发策划评审记录 | 02 | 12 | 未绑定 | 3bac17e3ef284010 |
| rd_process_flow | 工艺流程图及作业指导 | 06 | 11 | 未绑定 | c4892f9947ec3cce |
| rd_product_bom | 产品BOM(附件清单) | 06 | 10 | 未绑定 | ac57d604f77ac754 |
| rd_proposal | 项目建议书 | 01 | 11 | weekly-report@v1、project-proposal@v1 | 50ed802a9249229e |
| rd_prototype_photos | 样机照片(附件清单) | 08 | 10 | 未绑定 | be4ff90930f06842 |
| rd_purchase_spec | 采购技术规范 | 06 | 11 | 未绑定 | 72ee43993c30f01a |
| rd_qualified_suppliers | 合格供方名录 | 08 | 11 | 未绑定 | 603a9ab37998a21a |
| rd_regs_stds | 法规和标准清单 | 03 | 11 | 未绑定 | 24b98c273fb04dd8 |
| rd_req_review | 需求评审记录 | 04 | 12 | 未绑定 | d42e18d5e02b7d5c |
| rd_risk_plan | 风险管理计划 | 03 | 11 | 未绑定 | 608822eb42aa83bd |
| rd_risk_report | 风险管理报告 | 06 | 11 | 未绑定 | de4ed137e0c1b76f |
| rd_risk_report_t | 风险管理报告(转换阶段) | 10 | 11 | 未绑定 | 24c61db854d6a9de |
| rd_risk_report_v | 风险管理报告(验证阶段) | 08 | 11 | 未绑定 | 762eb5d127698215 |
| rd_risk_report_val | 风险管理报告(确认阶段) | 12 | 11 | 未绑定 | b3200d74cd74913d |
| rd_shelf_life | 货架寿命方案 | 08 | 11 | 未绑定 | 9e51627645d7c561 |
| rd_sw_arch | 软件概要设计方案 | 06 | 11 | 未绑定 | e829e164cf1c825b |
| rd_sw_config | 软件配置及维护计划 | 03 | 11 | 未绑定 | 8510491f6480b58b |
| rd_sw_plan | 软件开发计划 | 03 | 11 | 未绑定 | 79ddc781bca8bb9d |
| rd_sw_quality | 软件质量测试报告 | 12 | 11 | 未绑定 | ef1e7dbbed13abf8 |
| rd_sw_release | 软件发布清单 | 08 | 10 | 未绑定 | ac4e522903fa6872 |
| rd_sw_reqs | 软件需求规格书 | 03 | 11 | 未绑定 | eb9a1d75efe1bda1 |
| rd_sw_sys_test | 软件系统测试报告 | 08 | 11 | 未绑定 | c86e15580ee24d16 |
| rd_sw_ui | 软件UI设计文档 | 06 | 11 | 未绑定 | 9c041da7d6db8d88 |
| rd_sw_unit_test | 软件单元测试报告 | 08 | 11 | 未绑定 | 368b5939da695d0e |
| rd_system_design | 系统设计方案 | 03 | 11 | 未绑定 | adf0b6bf32fe10af |
| rd_system_reqs | 系统需求规格书(SR) | 03 | 15 | 未绑定 | 1d0aa50c5e8f06d9 |
| rd_tech_req | 产品技术要求 | 06 | 11 | 未绑定 | 03c39e46300e6719 |
| rd_transfer_review | 设计开发评审记录(转换阶段) | 11 | 12 | 未绑定 | 4be3b0770a08d6d4 |
| rd_use_error | 使用错误评估报告 | 12 | 11 | 未绑定 | 67c98d3f26b91c13 |
| rd_user_needs | 用户需求规格书(UN) | 03 | 11 | 未绑定 | cdc46e46a93bca81 |
| rd_user_test | 用户测试报告 | 12 | 11 | 未绑定 | 26ad7d32eb59b386 |
| rd_validation_plan | 设计确认方案 | 12 | 11 | 未绑定 | a0b53fc9a74df218 |
| rd_verification_review | 设计开发评审记录(验证阶段) | 09 | 12 | 未绑定 | ec68f27212649baf |
| tm_system_verification | 系统验证方案及计划(SVP) | 04 | 8 | 未绑定 | 7b66de5bd1f6b0f3 |
完整哈希应在正式迁移台账保留;本表短哈希用于阅读定位,不作为独立完整性或身份凭据。
@@ -0,0 +1,19 @@
# 模板对话生成方案 r1 文档检查记录
对象:[方案 r1](../proposals/2026-10-11-rdm-template-dialog-generation.md)。日期:2026-10-11。
性质:SELF,三组本地模型审阅覆盖七个视角,不是人工评审、业务验收或独立 GATE/REPLAY;未执行跨供应商模型审阅。
检查范围:方案一致性、可行性、产品范围、使用流程、权限和关键失效场景。业务测试 NOT_RUN。
| 视角 | 原始发现 | 处理 |
|---|---|---|
| 一致性 | 无重要矛盾 | 无修改 |
| 可行性 | 同文档旧章节职责/签署不同,不能自动合成文档批准 | KTD8/U4 补迁移与旧活动审签处置;首个整文版重新审签 |
| 产品 | 无实质发现 | 保留首批两模板建议与69类全量登记、分批验收 |
| 交互 | 新文档未分配职责或当前用户非编制人时缺对话恢复路径 | User Flow/U5 补等待分配、负责人分配、最小信息转交与指定编制人接续 |
| 范围 | 无实质发现 | 保留既有两树一网/存储分工 |
| 权限 | 模板发布、退役和默认绑定的管理权未明确 | KTD1/U2 限定首期经批准仓库发布;编制权不继承模板管理权 |
| 失效场景 | 部分采纳混合新旧章节后未重验整文依赖 | KTD6/U4 补对实际目标组合的依赖、术语、指标检查及版本/hash 绑定 |
四条原始发现均为 P2、置信度 75。主审核对依据:旧 review.go 以 sectionID 分配职责/保存审批,首期 templates.go 只读受控注册表,方案已有严格编制权与部分采纳行为;四项补充用于使既有目标成立,未扩大业务交付范围。
四项已在方案中修订并补验收场景;未代签用户保留的路线、首批顺序、文档级审批选择和实施授权。
本记录只证明文档检查及修订,后续真实业务验证仍按方案执行。
File diff suppressed because one or more lines are too long
@@ -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 只读基线。
@@ -0,0 +1,100 @@
# U7 运维演练与数据库基线报告(SELF,2026-10-12)
来源标注:**SELF**(本机隔离栈执行;非 CI GATE、非独立 REPLAY)。用户 2026-10-12 决定不做容量重放。不得据此放行第二实例写流量。
## 1. 被测对象
| 项 | 值 |
|---|---|
| Backend gitlink | `8e509775d39d1455b69be44803037faa7af844b4` |
| B6 Dev HEAD | `b2e129ab3f3bdf222f16040fcd0513872d0e2a3c` |
| C4 Dev HEAD | `308f33665eb2dfaf9ae661e87df8898c3c2ecb3a` |
| C5 Dev HEAD | `792574692609d9bfdf113e2dc5af6f43c9a176dd` |
| 主机 | 32 逻辑 CPU,122 GiB RAM;演练开始时 load average 见各 `host.txt` |
| 入口 | `tests/load/collaboration/run_pgbench.sh`;`tests/ops/run_fault_drill.sh`;`tests/ops/run_backup_drill.sh` |
原始输出在测量 worktree 的 `results/`(gitignore),不入库。任务卡 evidence 为 SELF。
## 2. B6 pgbench
结果目录 `tests/load/collaboration/results/pgbench-20261012-131948`。隔离实例 `u7bench`,scale 100,每档 60 秒,`-M prepared`。`max_connections=100`,`superuser_reserved_connections=3`,100 客户端封顶为 95。六档失败事务均为 0。
| 模式 | 客户端 | tps | P50 | P95 | P99 |
|---|---|---|---|---|---|
| select-only | 10 | 535646 | 0.018 ms | 0.024 ms | 0.030 ms |
| TPC-B 类 | 10 | 18798 | 0.339 ms | 0.673 ms | 5.560 ms |
| select-only | 30 | 952115 | 0.026 ms | 0.057 ms | 0.078 ms |
| TPC-B 类 | 30 | 52224 | 0.493 ms | 1.002 ms | 1.777 ms |
| select-only | 95 | 904708 | 0.087 ms | 0.180 ms | 0.417 ms |
| TPC-B 类 | 95 | 50607 | 1.041 ms | 3.361 ms | 18.106 ms |
主机不空闲。这是数据库参考基线,没有业务阈值,也不替代容量窗口。
## 3. C4 断连
结果目录 `tests/ops/results/fault-20261012-142734`。PG 18991,应用 18990/18992,Redis 18993。
| 判据 | pg-stop | pg-kill |
|---|---|---|
| F1 有界失败、进程仍在 | 过 | 过 |
| F2 不回落 SQLite,新进程拒绝就绪 | 过 | 过 |
| F3 恢复后两侧各 5 次写入 | 过,RTO 不到 1 秒,未重启应用 | 同左 |
| F4 失败 requestId 重放恰好一条 | 过 | 过 |
| F5 dup_seq=0、seq 无洞、无非终态 run | 过 | 过 |
Redis 限额 20 次/分钟,两实例各突发 40 个读:
| 判据 | 结果 |
|---|---|
| G1 共享限额 | 放行 20、429 为 60、其他错误 0 |
| G2 断连 | 放行 40、429 为 40、其他错误 0;已确认写入仍在 |
| G3 只拉起 Redis | 放行回到 20;`rl:*` 均有过期时间 |
| G4 | 发现:日志看不到降级计数 |
| G5 | 发现:Redis 不通时新进程拒绝启动 |
`runtime.redisAddr` 没有调用者可写的产品入口。演练用 SQL 写入默认 owner `local` 的 `user` 设置,并保留 mock。
## 4. C5 备份与恢复
结果目录 `tests/ops/results/backup-20261012-153441`。源 PG 18994,恢复目标 18997。合同数据量 seed 约 12 秒。
| 判据 | 结果 |
|---|---|
| K1 备份有效 | 过。`failed_count=0`,`archived_count=80`,`pg_verifybackup` 与 `pg_restore --list` 退出码 0 |
| K2 RPO≤5 分钟 | 过。64 秒 |
| K3 RTO≤60 分钟 | 过。4 秒。恢复后登录、列项目、读会话均为 200 |
| K4 工件与权限 | **FAIL**。五次上传都没有拿到工件编号 |
| K5 不变量 | 过。dup_seq=0,seq 无洞;恢复后消息/事件/知识/run 计数与故障前一致(消息 1 000 120);非终态 run 为 0 |
| K6 逻辑恢复 | 过。`pg_restore` 退出码 0,约 4 秒;计数等于 dump 时快照(消息 1 000 000,知识 100 000) |
| K7 权限与泄密 | 过。备份目录 700、文件 600;结果文本里没有连接串。静态加密与凭据演练记 N/A。归档和数据在同一块盘,没有模拟存储全毁 |
恢复后的计数与故障前一致,说明已提交的标记都在。64 秒是最后一条成功标记的确认时间到故障时刻的间隔;窗口末尾有的写入因为会话仍被 mock run 占用而没有落库。
K4 的原因在源应用日志:未设置 `BLOBSTORE_S3_ENDPOINT` 时,`NewS3FromEnv` 返回空的 `*S3`。这个空指针被放进 `blobstore.Store` 接口后不再等于 nil,`finishOpen` 不会回落本地目录,上传在 `blobstore.(*S3).Put` 空指针 panic。产品代码未改。因此工件 sha256 和跨用户拒绝没有测成。代码里本地后端的 `content_path` 是绝对路径;这次没有成功上传,所以没有用恢复后的下载来核验。
同日另一次恢复(`backup-20261012-150713`)在数据目录复制之后起不来,因为 socket 路径超过 107 字节。正式这次把 socket 放到 `/tmp/u7bk-18997`。
## 5. 放行(2026-10-12 当时)
B6、C4 为 SELF 通过。C5 的库恢复为 SELF 通过,工件恢复失败。第二实例写流量仍不放行。
当时还没做、该任务不启动的三项:
- 独立 REPLAY,或把 C4/C5 的快速档接进 CI 成为 GATE(需要平台准入)。
- C3 双主机。
- 上传在未配置对象存储时 panic,需要单独的产品修复后才能重测 K4。
## 6. 2026-10-13 K4 重测
上传 panic 已在 store 边界修复:带类型的空对象存储(未设置 `BLOBSTORE_S3_ENDPOINT` 时的 `(*S3)(nil)`)视为未配置,回落本地工件目录。已构造的对象存储保持不变。Backend 提交 `46073d30`,Dev 被测头 `a83588dd`,backend gitlink 同为 `46073d30`。
重跑入口仍是 `tests/ops/run_backup_drill.sh`。结果目录 `tests/ops/results/backup-20261013-013354`(SELF)。原始结果另存于仓外 `/home/weichen/projects/u7-k4-retest-preserved-20261013`。
| 判据 | 结果 |
|---|---|
| K1–K3、K5–K7 | 过。RPO 65 秒,RTO 3 秒。`pg_verifybackup` 与 `pg_restore --list` 退出码 0,逻辑恢复约 5 秒,恢复后计数与故障前一致 |
| K4 工件与权限 | **过**。5 个工件 `checked=5`、`missing=0`、`mismatch=0`。跨用户访问项目和工件均为 404 |
`content_path` 仍是绝对路径,快照继续还原到原目录。静态加密、凭据演练和整盘损坏仍是 N/A。
第二实例写流量仍不放行。剩下的门槛是独立 REPLAY 或经平台准入后的 C4/C5 CI 快速档,以及 C3 双主机。