Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
53354996f2 | ||
|
|
cf74a200e8 | ||
|
|
f7ae1ecce6 | ||
|
|
b184bfb109 | ||
|
|
f76cce9e32 | ||
|
|
95c2ec260c | ||
|
|
733f32c671 | ||
|
|
8d8600024d | ||
|
|
cb7e25439a |
@@ -8,9 +8,9 @@ product_contract_source: ce-plan-bootstrap
|
||||
|
||||
# 多人协作存储与分布式演进方案 - Plan
|
||||
|
||||
修订:r2.1;确认状态:**已批准(2026-10-11 用户指示「按方案开始改造」)**;推进状态:U1–U7 **代码与测试已合入**(Backend [#164](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/164);Dev [#410](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/410)/[#439](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/439)/[#442](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/442);闭卡 [#424](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/424) 等)。正确性 A1–A7 与 B1 已绿(CI/SELF)。容量合同 B2/B3/B5 contract 与双实例 C2 **本机 SELF 窗口已跑通**(见[容量报告](../records/2026-10-12-u7-capacity-window-report.md));**SELF≠GATE/REPLAY**,双主机 C3、运维演练 C4/C5 未做——**仍不放行第二实例承接写请求**。
|
||||
修订: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-12(Asia/Shanghai)。
|
||||
需求负责人: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/`;文内相对链接以本文为根。
|
||||
|
||||
@@ -246,8 +246,8 @@ SQLite 本身支持可靠事务与多人经同一应用访问;WAL 提升读写
|
||||
|
||||
必需观测:API P95/P99与预期/非预期错误,DB pool wait/连接数/慢查询/锁等待,队列长度/最老年龄,run 租约/过期写拒绝/未知副作用,SSE cursor lag/补查次数,Redis 错误与降级,检索耗时/召回抽样,备份时间与恢复结果。日志只记录 request/run/owner 的安全标识,不记录 DSN、密钥或文档正文。
|
||||
|
||||
r1 为方案与 SELF 调查记录。r2 起:U1–U7 代码与测试已合入且正确性 CI 绿。r2.1:本机双实例 contract 容量窗口(ladder / 60m / 2h)SELF 全过,见[容量报告](../records/2026-10-12-u7-capacity-window-report.md)。本地 SELF 不能冒充 GATE/REPLAY 放行;双主机与运维演练仍缺。部署与第二实例写流量仍未授权。
|
||||
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)。进程级黑盒相对库级 Manager 测试的漏检教训见[经验条目](../records/2026-10-12-lesson-http-multi-instance-vs-manager-tests.md)。Agent 审阅不替代人工批准或实现验收。
|
||||
|
||||
首选下一增量是 **独立 REPLAY 最小容量集**(至少 `run_load.sh --seed contract --profile ladder --instances 2`)以提升放行证据等级;或其候选项:**C3 双主机验证**(需用户指定第二主机)或 **C4/C5 运维演练**。在 GATE/REPLAY 与 C3 未齐前,不要开放第二实例写。各实现任务启动前复核在途 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/组合验证流程交付。
|
||||
|
||||
@@ -12,6 +12,7 @@ product_contract_source: ce-plan-bootstrap
|
||||
确认状态:原 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 根目录为基准。
|
||||
|
||||
@@ -337,3 +338,46 @@ T8-6:参数来自应用实际连接;SQLite FULL/PG 同步设置按批准合
|
||||
只有在所有启用的必需服务/插件被纳入清单、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,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.
|
||||
@@ -183,3 +183,5 @@ RDM 总案把库分期作为支撑与依赖,不覆盖库分期的原始范围
|
||||
- [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,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 双主机。
|
||||
Reference in New Issue
Block a user